jonathan@cae.ca (Jonathan Hutchinson) writes:

>I have two questions that I would appreciate any and all help on.
>
>1: Including C code in C++:
> I am coding an XX application in C++ that will be making
> extensive use of existing C libraries. Unfortunately, these
> existing libs introduce the following problems that are not
> addressed with extern "C" {#include<>}.
>
> a) There is a struct defined that has a field named
>  operator (and another with a field named class).
>  NOTE: I do not use these structs, but the header file
>  is included indirectly over which I have no control.
>
> I have a (terrible) fix for the a) where I #define operator to
> _operator before the include and redefine it afterward (yuk!).

That's the only way I can think of doing it.  Surely it's not any
messier than some of the convoluted macros in some header files.
The only thing that you must be careful of is if you start using code
that expects the ``operator'' and ``class'' data members.

> b) There are structs defined to be linked list nodes
>  that cause re-definition errors in C++.
>
>  struct Node {
>   int some_data;
>   struct Node *next;
>   ^^^^^^^^^^^
>  }
                 ^
You need a semi-colon here.

>2: References

> I have a simple question concerning when to user references
> for parameters that are to be changed by a function.

> [BEGIN CODE]
> int getDataPtr( char **DataPtr);
> int getDataRef( char *&DataPtr);

> char *data, *data2;
> result = getDataPtr(&data1);
> result = getDataRef(data1);
> [END CODE]

> Is there any reason that the getDataRef function is
> prefereable over that getDataPtr()? My concern is that C
> programmers will look at the getDataRef(data1) call and their
> first reaction will be that since the address is not being
> passed, then the pointer is not being affected. I realize that
> this is not a justification to use the getDataPtr() style, but
> I would like to hear more about the reasons to use the
> reference version (which is what I have so far chosen to use).

I find the code for call-by-reference functions easier to read as you
eliminate a bunch of extraneous asterisks.  :^)

Dave
--
David D. Kilzer              \        Emergency Holographic Doctor:
ddkilzer@iastate.edu         /   ``Don't worry, I'm not going to kiss you.
Computer Engineer 4          \      I'm only adjusting the restraint.''
Iowa State University, Ames  /         _Star_Trek_Voyager:__Phage_

I have two questions that I would appreciate any and all help on.

1: Including C code in C++:
 I am coding an XX application in C++ that will be making
 extensive use of existing C libraries. Unfortunately, these
 existing libs introduce the following problems that are not
 addressed with extern "C" {#include<>}.

 a) There is a struct defined that has a field named
  operator (and another with a field named class).
  NOTE: I do not use these structs, but the header file
  is included indirectly over which I have no control.

 b) There are structs defined to be linked list nodes
  that cause re-definition errors in C++.

  struct Node {
   int some_data;
   struct Node *next;
   ^^^^^^^^^^^
  }

 I have a (terrible) fix for the a) where I #define operator to
 _operator before the include and redefine it afterward (yuk!).

2: References

 I have a simple question concerning when to user references
 for parameters that are to be changed by a function.

 [BEGIN CODE]
 int getDataPtr( char **DataPtr);
 int getDataRef( char *&DataPtr);

 char *data, *data2;
 result = getDataPtr(&data1);
 result = getDataRef(data1);
 [END CODE]

 Is there any reason that the getDataRef function is
 prefereable over that getDataPtr()? My concern is that C
 programmers will look at the getDataRef(data1) call and their
 first reaction will be that since the address is not being
 passed, then the pointer is not being affected. I realize that
 this is not a justification to use the getDataPtr() style, but
 I would like to hear more about the reasons to use the
 reference version (which is what I have so far chosen to use).

Thanks for any help on these questions.

Jonathan Hutchinson
jonathan@cae.ca