using namespace std; this one line of code is really confusing the heck outta me. as i understand it, several C++ libraries define several standard objects, such as cout, cin, ios, etc, etc... in order to use these objects, we can either do: // for C++ libraries #include // no .h // for old C libraries #include // no .h using namespace std // go on with our code here.. OR #include #include // and keep doing stuff like std::cout<<" "; -- however, this isn''t working. i''m working on a project in C++ -- but i''ll be using a lot of the old ansi c libraries. the code needs to compile on both linux & win32 (gcc in linux, vc in win32) should i be including all my headers w/o the .h extension?? in all my includes, should i be include the C++ version of it? (ie, ctime, instead of time.h) thanks... ~khal --- ~khal

This isn''t really a namespace question - it''s about headers.

The reason why

#include <iostream>//and#include <iostream.h>

both work is because they include 2 different files. namely "iostream" and "iostream.h". "iostream.h" is the traditional include file, while "iostream" is the newfangled STL include.

I think the "iostream" include file defines the same classes as the iostream.h, except they are contained within the std namespace. Beyond that I''m not sure what the distinction is.

Magmai Kai Holmlor
- The disgruntled & disillusioned

If you use things from the STL or iostream library, you should use includes without the .h, and use the std namespace. You can do that in three ways:

- using namespace std; This will enable you to use all the things that are in namespace std without qualifying the namespace. Eg cout << "hello". The disadvantage is that everything from namespace std will be in global namespace, so that it becomes polluted.
- fully qualify everything you use that is in namespace std; Eg std::cout << "hello".
- specify which things that are in namespace std you''ll be using. You can do using std::cout;, and then refer to cout without qualifying it. Disadvantage is that you have to type a lot more, and forgetting a qualifier is easily done.

The new C++ headers for C library things are in fact only wrappers for the old header files (with .h) that put all the things in those old header files in namespace std.

So, I think you should at least use new C++ style headers for iostream and STL things. For C lib things it isn''t really necessary, but I''d do it anyway. If the latter doesn''t work (what doesn''t work exactly?), then you can always use old C style headers for C lib things.

Here''s a tip, btw: check out STLport (http://www.stlport.com/). It''s a free STL and iostream implementation that works on many platforms (including linux and win32), and it''s a better implementation than the one that comes with Visual C++.

HTH

mmm..i can''t be sure what works & what doesn''t. i can''t seem to find a consistent way of doing things. SO far, i''ve only attempted to port this to win32...i''ve been using:

/*
* Standard C++ includes (STL)
*/
#include

/*
* Standard C includes
*/
#include

/*
* Local includes
*/
#include "logstream.h"

using namespace std;

I''m trying to fully comply w/ STL in both my C++ and C includes. this means, i should not try to include
and , right? instead, i should include the C++ wrapper for time.h (ctime).

i see a problem coming up, however. in unix, i need to
#include
...for a C program.

when, i rewrite the program in C++ should i try to include the ctime w/ or w/o the path?

#include
or
#include // and expect the compiler to know where it is?

---
~khal

khal, your post is a bit unreadable because <, > and the header file names are missing. If you get < or > in the message, you have to type &lt; or &gt; resp.

Lol, I keep forgetting that...

/*
* Standard C++ includes (STL)
*/
#include <iostream>

/*
* Standard C includes
*/
#include <ctime>

/*
* Local includes
*/
#include "logstream.h"

using namespace std;



---
~khal

That should work on both win32 and linux, as long as the STL and iostream lib you use are reasonably compliant. No need for full paths or anything.

However, there''s nothing wrong with including .h style headers for C lib things, as long as you''re doing that in a consistent way.