471,075 Members | 1,332 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,075 software developers and data experts.

C library in C++ code

For code that was part of the C library, being used in C++, should you
always prefix std::

Specific examples:

std::fopen
std::fclose
std::atexit

Should I include

<cstdio> or <cstdlib>?

g++ 3.4.2 in mingw doesn't seem to care one way or the other. No
warnings or errors are produced even with -W -Wall.

Thanks,

--John Ratliff
Aug 25 '05 #1
5 1334
Ian
John Ratliff wrote:
For code that was part of the C library, being used in C++, should you
always prefix std::

Specific examples:

std::fopen
std::fclose
std::atexit

Should I include

<cstdio> or <cstdlib>?

g++ 3.4.2 in mingw doesn't seem to care one way or the other. No
warnings or errors are produced even with -W -Wall.

One probably includes the other.

Ian
Aug 25 '05 #2
>>
Should I include

<cstdio> or <cstdlib>?

g++ 3.4.2 in mingw doesn't seem to care one way or the other. No
warnings or errors are produced even with -W -Wall.

One probably includes the other.

Ian


Sorry, my post was unclear.

I meant should I include cstdio for std::fclose/std::fopen/std::freopen
and should I include cstdlib for std::atexit.

I wasn't including either, and still no warnings. I was including
iostream, vector, and stdexcept.

--John Ratliff
Aug 25 '05 #3
John Ratliff wrote:
<snip>
I wasn't including either, and still no warnings. I was
including iostream, vector, and stdexcept.

<snip>

In C++, unlike in C, the standard doesn't specify which
header files include each other. So always err on the
safe side and include headers for all functions/classes
you use in a translation unit. Specifically, don't rely
on <iostream> including <cstdio>.

Marc
Aug 25 '05 #4
In message <2dfPe.64649$084.1631@attbi_s22>, John Ratliff
<us**@example.net> writes
For code that was part of the C library, being used in C++, should you
always prefix std::
Assuming you're using #include <cxxx> rather than #include <xxx.h>, you
*should*, but some implementations hoist those declarations into the
global namespace willy-nilly, so you might get away without the prefix.
But the first time you try to compile using something that doesn't,
you're in for a lot of editing :-(
Specific examples:

std::fopen
std::fclose
std::atexit

Should I include

<cstdio> or <cstdlib>?
You *should* include both, but in some implementations one will include
the other in any case. Again, you can't rely on this.
g++ 3.4.2 in mingw doesn't seem to care one way or the other. No
warnings or errors are produced even with -W -Wall.


--
Richard Herring
Aug 25 '05 #5
Richard Herring wrote:
In message <2dfPe.64649$084.1631@attbi_s22>, John Ratliff
<us**@example.net> writes
For code that was part of the C library, being used in C++, should you
always prefix std::

Assuming you're using #include <cxxx> rather than #include <xxx.h>, you
*should*, but some implementations hoist those declarations into the
global namespace willy-nilly, so you might get away without the prefix.
But the first time you try to compile using something that doesn't,
you're in for a lot of editing :-(

Specific examples:

std::fopen
std::fclose
std::atexit

Should I include

<cstdio> or <cstdlib>?

You *should* include both, but in some implementations one will include
the other in any case. Again, you can't rely on this.
g++ 3.4.2 in mingw doesn't seem to care one way or the other. No
warnings or errors are produced even with -W -Wall.


Thanks, I've done both. And yes, I don't want to rely on any specific
implementation.

--John Ratliff
Aug 25 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Chris F Clark | last post: by
87 posts views Thread by Robert Seacord | last post: by
20 posts views Thread by Frank-O | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.