#include <cstdio> and #include <stdio.h> in the SAME FILE?

[james.d.m...@googlemail.com]

{ Please limit your text to fit within 80 columns, preferably around 70,
so that readers don't have to scroll horizontally to read each line.
This article has been reformatted manually by the moderator. -mod }

I was having a look through the header files for a SAT-solver that I
needed to work out how to use, and which for some reason seemed to be
using a lot of the C versions of the headers (<stdlib.h> instead of
<cstdlib> for instance) alongside C++ headers such as <algorithm>.

Which is how I encountered this:

#include <cstdio>
#include <string.h>
#include <stdio.h>

Does anyone know of any reason why someone would want to #include both
stdio.h and cstdio in the same file? More importantly, are there any
potential pitfalls to doing this? If there are, can I just fix them by
commenting out the line with stdio.h?

A slightly less important question as well - does anyone know of any
reason not to change <string.h> to <cstring> in the above? I can easily
go through the file putting std:: before function names and the like.

Many thanks,

James McLaughlin.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Daniel Krügler]

Am 22.01.2013 20:01, schrieb james.d.m...@googlemail.com:
> I was having a look through the header files for a SAT-solver that I
> needed to work out how to use, and which for some reason seemed to be
> using a lot of the C versions of the headers (<stdlib.h> instead of
> <cstdlib> for instance) alongside C++ headers such as <algorithm>.
>
> Which is how I encountered this:
>
> #include <cstdio>
> #include <string.h>
> #include <stdio.h>

Am I understanding you correctly that this #include series is part of
headers that are from a thirdparty source (and not "yours")? If so, I
strongly recommend not to touch it unless you are considering to fork
and take full responsibility for what you are doing.

> Does anyone know of any reason why someone would want to #include both
> stdio.h and cstdio in the same file?

Maybe providing support for some very old compilers/libraries?

> More importantly, are there any
> potential pitfalls to doing this?

Nowadays (and given my general warning above) I would solely use the
officially supported <c*> headers instead of the deprecated
compatibility <*.h> headers. I haven't seen problems with recent gcc or
MSVC versions at all. But this does not properly answer your question:
In fact, there is at least one possible pitfalls here when considering
to modify source code that you have not fully understood:

If you simply add std:: qualifiers to functions that are currently
invoked unqualified to stop ADL to work properly. You need to have a
careful look whether the correct action is indeed an explicit
qualification or adding a (local) using-directive or using-declaration
from namespace std. Problem here is that the wrong choice may still
compile but will presumably take a unwanted code flow. If you add such
using directives, ensure that you do that solely within function bodies
(It is possibly to to that also in a safe way within namespace scope,
but this requires a little bit of discipline to discriminate localized
"receiver" namespaces from other public API namespaces).

> A slightly less important question as well - does anyone know of any
> reason not to change <string.h> to <cstring> in the above?

Not except the general statements above.

HTH & Greetings from Bremen,

Daniel Krügler

[Balog Pal]

On 1/22/2013 8:01 PM, james.d.m...@googlemail.com wrote:
> #include <cstdio>
> #include <string.h>
> #include <stdio.h>

IIRC the rules are something like this:
- original C headers (like stdio.h) put all names in :: but are allowed
to also add them to std::
- the new headers (like cstdio) put all names in std:: but are allowed
to also add them at ::

> Does anyone know of any reason why someone would want to #include both
> stdio.h and cstdio in the same file? More importantly, are there any
> potential pitfalls to doing this?

If the implementation is conforming there should not be any problem, and
having both includes ensure all names in both places.

Why would someone want that is honestly beats me -- in code under my
control I'd allow exactly one and forbid the other to avoid confusion.
Due to the fact the names can appear in the "other" place, plus that any
standard header allows to include any number of other standard headers
means that any of the above includes may is allows to leave you with all
C standard defined symbols in the global namespace. Then why fight them?
Easiest way is IMHO to use them from global and treat them as reserved.

> If there are, can I just fix them by
> commenting out the line with stdio.h?

No, if the TU uses the symbols in global. You first need to consolidate
the usage to one form or the other, then can remove the excess include.

> A slightly less important question as well - does anyone know of any
> reason not to change <string.h> to <cstring> in the above?

Not being forced to add noise to the code in form of std:: prefixes
sounds like a **** good reason to me. :)

> I can easily
> go through the file putting std:: before function names and the like.

And your answer to the obvious review question "What is the benefit of
that?" "How hat make the code simpler and better to handle?" is?

[james.d.m...@googlemail.com]

Thanks everyone
Especially the mods for the reformatting.

> And your answer to the obvious review question "What is the benefit of
> that?" "How hat make the code simpler and better to handle?" is?

Several of the header files referred to both vector and std::vector,
(without containing any ``using'' declarations/directives), forcing
me to spend quite a while checking other headers to confirm that the
former was in fact the standard library vector, and not some other
type which had been given the same name in an example of really bad
practice.
There's very little documentation for this SAT-solver, and I had seen
some classes criticised for having names too similar to standard C++
classes. Prefixing the standard library functions etc. with std::
where applicable seemed a good way to eliminate the ambiguity.

[Balog Pal]

On 1/23/2013 9:07 PM, james.d.m...@googlemail.com wrote:
> Thanks everyone
> Especially the mods for the reformatting.
>
>> And your answer to the obvious review question "What is the benefit of
>> that?" "How hat make the code simpler and better to handle?" is?
>
> Several of the header files referred to both vector and std::vector,
> (without containing any ``using'' declarations/directives), forcing
> me to spend quite a while checking other headers to confirm that the
> former was in fact the standard library vector, and not some other
> type which had been given the same name in an example of really bad
> practice.

Exactly my point. Having a type named 'vector' in today's C++ code that
is something else than std::vector is nothing but a source of confusion
and a time-sink. So it shall be eliminated for good. Then not allowing
to get back. Leaving the pure world where vector meand std::vector
without doubt and no need to add noise.

> There's very little documentation for this SAT-solver, and I had seen
> some classes criticised for having names too similar to standard C++
> classes. Prefixing the standard library functions etc. with std::
> where applicable seemed a good way to eliminate the ambiguity.

For the compiler perhaps. Not for any human reader, as you demonstrated
above. :)

For 1st-party code I see very little excuse to use confusing names. For
3rd-party stuff that can't be avoided, if it's with source, I'd build a
transformed version. If it's binary, I'd write a wrapper. (IME that is
pretty common anyway, especially if the component will get updates in
the meantime).