C and C++ naming issues?

[Noah Roberts]

http://www.gubbe.ch/code/libcfgparse/cfgtypes_8h-source.html

That page contains a header that when included does not define any of
the typedefs or any of the value references that are in that file. For
instance, I included that file and then tried this:

switch (file.get_type("valid_operating_systems"))
{
case CFG_ITEM_NONE: cerr << "NONE" << endl; break;
case CFG_ITEM_INTEGER: cerr << "INT" << endl; break;
case CFG_ITEM_BOOLEAN: cerr << "BOOL" << endl; break;
case CFG_ITEM_FLOATINGPOINT: cerr << "FLOAT" << endl; break;
case CFG_ITEM_STRING: cerr << "STR" << endl; break;
case CFG_ITEM_CONTAINER: cerr << "CONTAINER" << endl; break;
default: cerr << "WHO THE **** KNOWS?!" << endl;
}

When compiled with g++ I get an error saying that none of those
identifiers exist. But they are quite obviously defined right there in
the file I included! If I copy the definition for CfgItemType into my
source file it compiles just fine. I would really like to understand
what the hell is going on here if anyone can figure that out.

Thanks.

 

[Victor Bazarov]

http://www.gubbe.ch/code/libcfgparse/cfgtypes_8h-source.html

That page contains a header that when included does not define any of
the typedefs or any of the value references that are in that file. For
instance, I included that file and then tried this:

switch (file.get_type("valid_operating_systems"))
{
case CFG_ITEM_NONE: cerr << "NONE" << endl; break;
case CFG_ITEM_INTEGER: cerr << "INT" << endl; break;
case CFG_ITEM_BOOLEAN: cerr << "BOOL" << endl; break;
case CFG_ITEM_FLOATINGPOINT: cerr << "FLOAT" << endl; break;
case CFG_ITEM_STRING: cerr << "STR" << endl; break;
case CFG_ITEM_CONTAINER: cerr << "CONTAINER" << endl; break;
default: cerr << "WHO THE **** KNOWS?!" << endl;
}

When compiled with g++ I get an error saying that none of those
identifiers exist. But they are quite obviously defined right there in
the file I included! If I copy the definition for CfgItemType into my
source file it compiles just fine. I would really like to understand
what the hell is going on here if anyone can figure that out.

I believe the answer is in the FAQ 5.8. Find the FAQ by following this
link: http://www.parashift.com/c++-faq-lite/

V

 

[Noah Roberts]

I believe the answer is in the FAQ 5.8. Find the FAQ by following this
link: http://www.parashift.com/c++-faq-lite/

I don't think so, smartass.

 

[Noah Roberts]

I have figured out what is going on. Thanks anyway.

 

[=?iso-8859-1?Q?Ali_=C7ehreli?=]

I have figured out what is going on. Thanks anyway.

I did spend some time trying to figure out your problem. Would you please
let us know what it was...

Thank you,
Ali

 

[Victor Bazarov]

Victor Bazarov wrote:




I don't think so, smartass.

Do they teach you that language at Saint Martin's or are you just
naturally so sweet?

 

[Noah Roberts]

I did spend some time trying to figure out your problem. Would you please
let us know what it was...

The file was being included by another file which was wrapping it in a
namespace. When I included it after the fact the #ifdef protection of
course kept anything in that file from being included because it
already was...but in a namespace.

How common is that when dealing with C++ wrapped libraries? I don't
like it...I think there should be

#ifdef __cplusplus
namespace x {
#endif

in any file that is going to be used in C++ that should be in a
namespace when so used.

Thanks for trying to figure out the problem. In my opinion the problem
was poor header design.

I figured it out when trying to pass one of those identifiers as a
parameter to a function that was set to accept only those values. Got
one of these:

test_cfg.cpp: In function `int main()':
test_cfg.cpp:116: no matching function for call to
`Cfg::Container::Container(
CfgContainerType)'
C:/msys/1.0/local/include/cfgparse/container.hpp:78: candidates are:
....
C:/msys/1.0/local/include/cfgparse/container.hpp:57:
Cfg::Container::Container(Cfg::CfgContainerType)

And that pretty much told me what was wrong.

 

[Default User]

I don't think so, smartass.

And that'll be *plonk* for you.




Brian

 

[Raymond Martineau]

I don't think so, smartass.

In section 5.8:

2. Post complete code: put in all necessary #includes and declarations
of needed types and functions

As you mentioned in another posting, you had an include file being used
that was wrapped in a namespace. Providing this information to the group
would have allowed the problem to be solved much more quickly (if it wasn't
solved on the spot.)

 

[Noah Roberts]

As you mentioned in another posting, you had an include file being used
that was wrapped in a namespace. Providing this information to the group
would have allowed the problem to be solved much more quickly (if it wasn't
solved on the spot.)

Very well. Next time I will make sure to paste my entire program and
the source for all libraries and header files as well. I am sure that
will make it much easier to diagnose any problems.

Unfortunately it looks like my last post got lost. Oh well.

Man, you guys need something better to do. You are wound WAY too
tight. I just don't have the patience.

 

[Victor Bazarov]

[..] I just don't have the patience.

Isn't that the real problem here?

 

[Larry Brasfield]

Quite true and good input at this point.

Very well. Next time I will make sure to paste my entire program and
the source for all libraries and header files as well. I am sure that
will make it much easier to diagnose any problems.

Please try to suppress your more juvenile responses
and consider why the expectations here differ from
what you have done. It is a mistake to think of this
forum as simply a free help center.

People are commonly asked to provide a minimal
but complete program that demonstrates the problem
they are asking about. If you had done this, you could
have found your problem without posting anything.
Posting a whole, unreduced project will lead only to
some wasted storage and time. And it tells those who
might help you that you are not interested in helping to
solve your own problem. When I see that, my interest
dwindles rapidly to none.

Unfortunately it looks like my last post got lost. Oh well.

As far as I can see, this has about as much meaning to
the other participants here as if you had announced
that you once had an itch and got it scratched.

Man, you guys need something better to do. You are wound
WAY too tight. I just don't have the patience.

If you continue on your present trend, you are
likely to find that the feeling has become mutual.

 

[Noah Roberts]

Larry Brasfield wrote:
It is a mistake to think of this

forum as simply a free help center.

I have frequented this particular newsgroup for many years. I know
what it is. Thanks anyway.

 

[Ben Hetland]

How common is that when dealing with C++ wrapped libraries? I don't
like it...I think there should be

#ifdef __cplusplus
namespace x {
#endif

in any file that is going to be used in C++ that should be in a
namespace when so used.

Doesn't sound like a good idea to me. It should often be the _user_ of
such a library that needs to distinguish between the different libraries
used when they share some common names or definitions. Otherwise, what
if two library creators both decide to use the same namespace, and
happen to also collide on some identifier names?

IMHO, much better when I can say something like this in my code:

-----
namespace win32 {
#include <windows.h>
}
namespace mailer {
#include "somevendor.h"
}

::
win32:ostMessage(wnd_handle, mymsg, 1, 5);
mailer:ostMessage(recipient, mymsg, 1, 5);