[gdal-dev] Re: C/C++ Divide

Frank Warmerdam warmerda at h...
Thu Nov 19 23:51:29 EST 1998


Stephane Villeneuve wrote:
> Hi,
> 
> I agree with Daniel, using C++ give many avantages, and a C library is a
> MUST:

Folks,

Well, this seemed settled. We will use a (hopefully clean, and object
oriented) underlying implementation with a well maintained C 
interface layer. 

> My idea is :
> 
> Use a function (same type of a Promote() to select the object)
...
> By this way, you don't need to add a extra parameter for the C call.
> If you transfere information between 2 file you will add many calls to
> promote() :-(((((

Well, of course I was responsible for the extensive use of Promote() in
GDB, but I don't think it is one of the things I want to carry out of it.
In fact, I think this approach would be very prone to bugs with surprising
changes to what is the current object. 

I really don't mind the extra argument to the C functions. In that sense
it is just a modest transformation on the syntax of invoking a method on
a data object. 

> I don't think that it's very hard to create cover functions in other
> languages,
> Jacket functions should call only the C function. I'am sure it will be
> possible to create a parser to do that.
> Is some one already call C functions in a other language (Not me) ????

How complex it is to write jacket functions for other languages depends on
a variety of factors. 

o The complexities inherent in the languages mechanisms. For instance, 
Python requires reference counting on all language objects, and this
(from what I have seen) can complicate intrinsics.

o The extent to which you want to modify the API to follow the conventions
and fit in with the datatypes of the language. Many EASI intrinsics
are straightforward, but others take advantage of builtin EASI types like
MStrings, attempt to simplify the interface (use of defaulted arguments
or variable argument types) or to supply greater safety (better error 
checking, which may make sense in a user scripting language). 

o The lack of functionality in the calling language corresponding to 
stuff in the API. For instance, if polymorphisms was used in an 
underlying API, but wasn't available in the language there would be
extra work needed.

o The fundamental incompatibilty of the data types in the language and
the datatypes in the library. For instance, Tcl doesn't seem to have
structure/object datatypes, so the OGDI binding in Tcl has to transform 
structures into lists, and lists of lists and so forth. 

I imagine there are other issues. 

My intention is to make GDAL's C API not very fancy (no polymorphism,
or defaulted arguments for instance). However, I can still a fair amount
of hand effort going into binding it effectively into some languages. 

For instance, if you want to treat a GDALShape (I imagine this will be
similar to a GDBShape) as a proper structured data type in the language,
more work han just building a bunch of function jackets will be required. 

Another approach is to ensure that all accesses are done via functions, and
that no non-basic datatypes are exposed to the application (or at least
are not needed).

Of course the more transformation you do as you bind GDAL into different
languages, the more language specific online help will be needed. 

Hmmpf.

Daniel says:
>I agree with the idea of having only one set of documentation that
>combines both the C++ and C equivalents of each function.
>
>It would be good if you could still use polymorphism though (I like
>it!)... there may be some ways that you could still use polymorphism in
>C++, and provide a clean equivalent in C by appending a standardized
>suffix to the C function name.
>
>Suppose that you provide the following methods to set projections:
>
> void GDALDataset::GDALSetProj(GDALProj *poProjInfo);
> void GDALDataset::GDALSetProj(const char *pszProjInfo);
>
>The C cover functions could be:
>
> void GDALSetProj_ProjH(GDALProjH hProjInfo);
> void GDALSetProj_sz(const char *pszProjInfo);
>
>It's just a thought... maybe it would make things more complicated???

This would work, but I don't think I would like the C API to appear to 
arcane. This reminds me of C++ name mangling. Under the assumption
that most applications will be built on the C API, I would want the 
C API to appear pretty clean. 

One of the challenges in this is how to name the C API. In C++ methods
you have the object on which the method is being invoked as context and
to provide a specialized namespace. In C, that isn't the case. 

Ideally, I would like to have C API names just be GDAL prepended on the
name of the method for everything, and with the first argument being the
object it is being invoked on. 

However, imagine a GDALRasterBand, and GDALVectorLayer objects, both with
GetName() methods. You can't just have one GDALGetName() function with
the argument being ambiguous.

We could:

o Just prepend the method names with GDAL, and disambiguate when 
necessary. This might still leave us situations ``GDALGetCount()'' with
no idea what kind of object it is. 

o Always prepend with the object type. GDALRasterBand_GetName(), and do 
this for all methods. It would provide a very clean name space and 
resolve all ambiguitites, but it would tend to cause very long names. 

o Don't follow a strict convention ... just aim for understandability in
the C API, and the C++ names, but without fixes rules relating them. 

The more I think about it, the more I like the second approach. It is very
predictable. If we take this, I think I would try harder to have short
type names though, and to keep method names brief. 

For instance, currently I have defined GDALRasterBand, and it has the
GetRasterDatatype() method. I might just name the type GDALBand, and the 
method GetDatatype(), so this would result in the C function 
GDALBand_GetDatatype() instead of GDALRasterBand_GetRasterDatatype(). 

With a few clues in the C include file we might even be able to give 
automatic translators like SWIG enough information to build object oriented
interfaces to the GDAL classes (even if operating through the C intermediate
types). 

How does everyone else feel about a C API convention of typename_methodname()?

Later,

-----------------------------------+---------------------------------------
Who can give them back their lives | Frank Warmerdam, Software Developer
and all those wasted years? - Rush | URL http://members.home.com/warmerda
| warmerda at h...
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com





More information about the Gdal-dev mailing list