[libannodex-dev] C++ clients and the use of 'class' asstructmember names.

[Ben Martin]

On Fri, 2006-03-10 at 11:08 +0100, David Kuehling wrote:
> >>>>> "Ben" == Ben Martin <monkeyiq at users.sourceforge.net> writes:
> 
> > One option would be to ifdef guard the "class" member. This shouldn't
> > break API because it would only come into effect if you are compiling
> > with C++ which is not currently cleanly possible.
> 
> > As there are only a handful of "class" members this doesn't really
> > pollute the header too much and you retain full compatibility with
> > your C clients.
> 
> Well, why not do 
> 
> #ifdef __cplusplus
>     #define class _class
> #endif
> 
> At the start of the header file, and
> 
> #undef class
> 
> at the end?
> 

Although this would also work it also leaves you open to modifying those
5 characters if they appear anywhere in an Annodex, CMML or any header
that those libraries include.

An interesting example would be something anx_int64.h includes on a
particular platform which might have a function or struct member with
"class" somewhere in it. Inside the anx_int64.h scope the class ->
_class would be valid and any system headers it included which, by
chance, were not previously included in the client would have this 
modification done too.

Also the "class" word is only used a few times in any header. Either
method will still preserve the C API.

While such abrasive bandages could let me compile against the existing
releases I tend to try to avoid the preprocessor for short lower case
strings.

Inside some murky C++ client file against the existing non-c++ friendly
headers....

extern "C" {
//
// cross fingers this works only on annodex headers and not something
// they include that we have forgotten to previously include.
//
#define class _class

  #include <annodex/annodex.h>
  #include <cmml.h>
#undef class
};

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.annodex.net/archives/libannodex-dev/attachments/20060310/d5e7802c/attachment.pgp