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

[Daniel Morissette]

Frank Warmerdam wrote:
> 
> 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?
> 

Frank,

My opinion is that you should still try to take advantage of C++ for the
internals of GDAL and for any other part that would benefit from using
C++. This sounds like an obvious choice to me... I hope I'm not missing
something.

And for the applications that need C linkage, I think that providing
cover functions for the C++ public methods as you suggest in your
example makes lots of sense. And actually, that's exactly the way I
thought you were going to handle the C linkage problem... I didn't know
you had these magic tricks with C vs C++ headers in mind ;-)

> 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 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???


Brian Koehler wrote:
> 
> This whole discussion has got me thinking: wouldn't it be cool if there
> was a tool that took a C or C++ API and generated the appropriate
> C cover functions and whatever else was required to link up with another
> language such as C/Java/Perl/Python/Tcl. Something like:
> 
> c++api_to_{C,Java,Perl,Python,Tcl} some_c++_api.h
> 
> which would spew out all the required code which is a pain
> to do by hand now, not to mention boring.
> 

Brian's suggestion to have a tool that generates the cover functions
automatically could be nice... and actually Stephane Villeneuve told me
that he was interested by compilers and pre-processors... I'll CC: this
message to him, and he may be interested in looking at this?!?


And BTW, I also had problems accessing Frank's system, and his page at
members.home.com for the most part of the day yesterday... but it's back
today.

Later,
-- 
------------------------------------------------------------
Daniel Morissette danmo at v...
http://pages.infinit.net/danmo/
------------------------------------------------------------
Don't put for tomorrow what you can do today, because if 
you enjoy it today you can do it again tomorrow.
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com