[gdal-dev] C/C++ Divide

[Frank Warmerdam]

GDAL Folks,

I am having a crisis figuring out how to handle the division of GDAL 
between C and C++.

On the one hand I want to retain C linkage for externally callable
functions so that:
o C applications can easily be built against it. 
o Functions can be easily loaded from shared libraries and DLLs. This
is particularly convenient when building links to the library from 
other languages such as Tcl, or Java. 

On the other hand, there are lots of nice things about C++, and so I was
hoping to build the internals as C++ classes, just taking care to avoid
dependencies on C++ runtime support that might limit the portability of
the library in non-C++ environments. For instance, the RTTI support 
with gcc depends on linking against a special GNU C++ support library.
A library (.a file) build of GDAL would be difficult for someone using
another compiler to utilize. 

My approach to mixing the languages was to have ``stub types'' for some
of the classes when compiled as C. For instance, GDALDataset is defined
in gdal_priv.h (think of this as being an include file for C++ 
applications). gdal_priv.h includes gdal.h which includes prototypes
for stuff like ``GDALDataset * GDALOpen( const char *, GDALAccess );''.

The GDALOpen prototype is include in GDAL_C_START/GDAL_C_END which 
evaluates to ``extern "C" {}'' for C++ code. Basically this marks the
prototype as having C linkage. 

A C application just includes gdal.h directly. In this case GDALDataset
is typedef to be a void *. 

The idea is that the type for stuff like GDALDataset would be defined
in a manner specific to the include files pulled in. A simlar approach
was used with native information structures in SGL, but there all the
items were structures in either case ... however, inclusion of different
include files determine whether you saw the ``private data members'' or
not. 

However, my use for GDAL doesn't work as I expected, because a 
prototype which returns a type known to be a C++ class is given C++ 
linkage by GCC, even if it is bracketed by extern "C" {}. In retrospect, 
it is reasonable that this is an ill-defined (likely illegal action) with 
different compilers. 

---

What to do? I am deluded trying to cross this C/C++ chasm?

Should I just have two sets of types for each application visible class. 
One a C ``handle'' type which gets cast to a C++ type within the C 
jacket functions? In this case we would need to have two names, one
for the C handle type, and one for the C++ class. 

eg. 

typedef void *GDALDatasetH;

#ifdef __cplusplus
class GDALDataset;
#endif

int GDALGetRasterXSize( GDALDatasetH hDS )

{
GDALDataset *poDS = (GDALDataset *) hDS;

return( poDS->GetRasterXSize() );
}

Should I just abandon C++ classes, and do everything with C linkage, no 
methods, and just use a C++ compiler as a better C compiler? 

Should I worry less about the C linkage API, and just graft cover functions
over a clean, application visible C++ implementation?

Also, what API should I provide documentation for? Given how much fun 
documenting APIs are, I would prefer to write the documentation once, 
perhaps just showing two prototypes, once for C and one for C++, but 
argument handling and so forth the same for both language. This might
extend well to other languages if I don't do anything too tricky with
arguments. For instance, I might avoid C++ polymorphism, or defaulted
arguments. 

I am interested in anyones thoughts (well OK, I am intersted in Brian 
and Daniel's thoughts since they are the only ones here!).

PS, the core code can be found at http://24.65.38.156/gdal/dev/core

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