include headers: <X>, <X.h> and global namespaces

  • Thread starter Santiago de Compostela
  • Start date
S

Santiago de Compostela

Hi

The following program doesn't compile on MS VC++ or Bloodshed Dev-C++



#include <iostream>

int strlen(const char *in)
{
int count=0;
while (*in++) count++;
return count;
}

int main()
{
std::cout << "the length of string \"hey diddle diddle\" is ";
std::cout << strlen("hey diddle diddle") << '\n';
}


I always thought that using <iostream> rather than <iostream.h> would
keep standard library definitions out of the global namespace. Am I
incorrect in this assumption, or do those two compilers really suck
that bad? TIA
 
T

Thomas Tutone

Santiago de Compostela said:
The following program doesn't compile on MS VC++ or Bloodshed Dev-C++

#include <iostream>

int strlen(const char *in)
{
int count=0;
while (*in++) count++;
return count;
}

int main()
{
std::cout << "the length of string \"hey diddle diddle\" is ";
std::cout << strlen("hey diddle diddle") << '\n';
}


I always thought that using <iostream> rather than <iostream.h> would
keep standard library definitions out of the global namespace. Am I
incorrect in this assumption, or do those two compilers really suck
that bad? TIA

For what it's worth, Comeau rejects it as well:

Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:strict errors C++

"ComeauTest.c", line 3: error: cannot overload functions distinguished by
return
type alone
int strlen(const char *in)
^
1 error detected in the compilation of "ComeauTest.c".

For what it's worth, it's usually considered good form to identify which
version of the
compiler you're using. Which version of VC++? And Dev-C++ isn't a
compiler, it's
just an IDE that runs minGW, which is a port of gcc. I don't know whether
Dev-C++
includes the latest version of minGW - you can get a beta port of gcc 3.4
from mingw.com.

Best regards,

Tom
 
A

Alan Johnson

Santiago said:
Hi

The following program doesn't compile on MS VC++ or Bloodshed Dev-C++



#include <iostream>

int strlen(const char *in)
{
int count=0;
while (*in++) count++;
return count;
}

int main()
{
std::cout << "the length of string \"hey diddle diddle\" is ";
std::cout << strlen("hey diddle diddle") << '\n';
}


I always thought that using <iostream> rather than <iostream.h> would
keep standard library definitions out of the global namespace. Am I
incorrect in this assumption, or do those two compilers really suck
that bad? TIA

VC++6 (and presumably previous versions) don't put the C library
functions in namespace std. I don't know about later versions, or about
Bloodshed Dev-C++.

Alan
 
I

Ioannis Vranos

Santiago said:
Hi

The following program doesn't compile on MS VC++ or Bloodshed Dev-C++



#include <iostream>

int strlen(const char *in)
{
int count=0;
while (*in++) count++;
return count;
}

int main()
{
std::cout << "the length of string \"hey diddle diddle\" is ";
std::cout << strlen("hey diddle diddle") << '\n';
}


I always thought that using <iostream> rather than <iostream.h> would
keep standard library definitions out of the global namespace. Am I
incorrect in this assumption, or do those two compilers really suck
that bad? TIA




Yes you are right about the assumption, this is a bad implementation
issue. In fact you can report it as a defect in MINGW development team
(in their mailing list or something).

A work-around is to define your strlen() in another namespace, a thing
you *should* do anyway when defining new versions of standard library
facilities.






Regards,

Ioannis Vranos
 
S

Santiago de Compostela

Alan Johnson said:
VC++6 (and presumably previous versions) don't put the C library
functions in namespace std. I don't know about later versions, or about
Bloodshed Dev-C++.

Alan

Thanks for your (and everyone else's) help. I use Visual Studio .NET;
also, the program won't compile under Borland's BCC32 (version 5.5.1)
for the same reasons, whichc is even more surprising since I always
thought they were sticklers about conforming to standards.

Anyway, the program does work putting strlen() in its own namespace,
but still, it would have been nice to give a solution to an exrecise
in TC++PL (6.6.10) without such workarounds.
 
P

P.J. Plauger

Thanks for your (and everyone else's) help. I use Visual Studio .NET;
also, the program won't compile under Borland's BCC32 (version 5.5.1)
for the same reasons, whichc is even more surprising since I always
thought they were sticklers about conforming to standards.

They are -- they've licensed our libraries.
Anyway, the program does work putting strlen() in its own namespace,
but still, it would have been nice to give a solution to an exrecise
in TC++PL (6.6.10) without such workarounds.

Stroustrup was one of the people on the C++ committee who held out
against multiple vendor protests, insisting on a namespace model
which isn't practical in the real world. If the exercises in his
book don't agree with reality in all cases, I'm not surprised.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
 
I

Ioannis Vranos

Santiago said:
Thanks for your (and everyone else's) help. I use Visual Studio .NET;
also, the program won't compile under Borland's BCC32 (version 5.5.1)
for the same reasons, whichc is even more surprising since I always
thought they were sticklers about conforming to standards.

Anyway, the program does work putting strlen() in its own namespace,
but still, it would have been nice to give a solution to an exrecise
in TC++PL (6.6.10) without such workarounds.


You are absolutely, right. My guess is that these have remained from the
pre-standard era, since there were versions of these compilers in those
days too.

Again report this as a defect. Especially I know that they accept bug
reports to MS newsgroups microsoft.public.dotnet.languages.vc and
microsoft.public.dotnet.languages.vc.libraries .

In fact I urge you to report this there, so they can fix it (I am 100%
percent that they will).

If you can't find these newsgroups in your Usenet server, use the public
one:

msnews.microsoft.com






Regards,

Ioannis Vranos
 
I

Ioannis Vranos

P.J. Plauger said:
They are -- they've licensed our libraries.


Please correct me if am wrong, but are you saying that the error is due
to your libraries? If yes, it would be great if you fixed them.


Stroustrup was one of the people on the C++ committee who held out
against multiple vendor protests, insisting on a namespace model
which isn't practical in the real world. If the exercises in his
book don't agree with reality in all cases, I'm not surprised.


What do you mean that it is not practical?






Regards,

Ioannis Vranos
 
T

tom_usenet

Hi

The following program doesn't compile on MS VC++ or Bloodshed Dev-C++



#include <iostream>

int strlen(const char *in)
{
int count=0;
while (*in++) count++;
return count;
}

int main()
{
std::cout << "the length of string \"hey diddle diddle\" is ";
std::cout << strlen("hey diddle diddle") << '\n';
}


I always thought that using <iostream> rather than <iostream.h> would
keep standard library definitions out of the global namespace. Am I
incorrect in this assumption, or do those two compilers really suck
that bad? TIA

That's the theory, but the practice is very different. Very few
compiler/library combos correctly place C library names in the std
namespace. What's more, some compilers have "strlen" as a compiler
"intrinsic" for performance reasons, so that you don't even have to
include any headers at all to cause your code to break.

The moral? Avoid using identifiers from the C standard library in your
own code. C++ library only names are generally ok, since they are
generally placed correctly in namespace std (although some older
compilers get even this wrong).

Tom
 
J

Jack Klein

Hi

The following program doesn't compile on MS VC++ or Bloodshed Dev-C++



#include <iostream>

int strlen(const char *in)
{
int count=0;
while (*in++) count++;
return count;
}

int main()
{
std::cout << "the length of string \"hey diddle diddle\" is ";
std::cout << strlen("hey diddle diddle") << '\n';
}


I always thought that using <iostream> rather than <iostream.h> would
keep standard library definitions out of the global namespace. Am I
incorrect in this assumption, or do those two compilers really suck
that bad? TIA

Despite quite a few name-calling, mud-slinging responses to the
contrary, there are things wrong with both your assumptions and your
program.

First, <iostream> is a standard header. <iostream.h> is not, and the
C++ standard says nothing at all about what it will or will not do.

Second, your program is invalid because it intrudes on names reserved
to the implementation. Here is what the C++ standard actually says:

[begin quotation]
17.4.3.1.3 External linkage

1 Each name declared as an object with external linkage in a header is
reserved to the implementation to designate that library object with
external linkage,166) both in namespace std and in the global
namespace.

2 Each global function signature declared with external linkage in a
header is reserved to the implementation to designate that function
signature with external linkage.167)

3 Each name having two consecutive underscores (2.11) is reserved to
the implementation for use as a name with both extern "C" and extern
"C++" linkage.

4 Each name from the Standard C library declared with external linkage
is reserved to the implementation for use as a name with extern "C"
linkage, both in namespace std and in the global namespace.

5 Each function signature from the Standard C library declared with
external linkage is reserved to the implementation for use as a
function signature with both extern "C" and extern "C++" linkage,168)
or as a name of namespace scope in the global namespace.
[end quotation]

I think I can make a case that your program violates all but paragraph
3.

The names of all standard C library functions are reserved with
external linkage in both the global and standard namespaces, and even
without external linkage are reserved at namespace scope in both
namespaces.

So the compilers you tried are quite within their rights to reject
your code.
 
J

Jack Klein

Yes you are right about the assumption, this is a bad implementation
issue. In fact you can report it as a defect in MINGW development team
(in their mailing list or something).

No, he is wrong about the assumption, and you are wrong to suggest he
file defect reports for perfectly legitimate compiler behavior.
A work-around is to define your strlen() in another namespace, a thing
you *should* do anyway when defining new versions of standard library
facilities.

Since you ventured into the realm of opinion, the thing one *should*
do when defining new versions of standard library facilities is to
*not*, under any circumstances, give them the name of standard
functions or types, even if do so in such a way that there is no
collision. Doing so is a monstrous crime.

Are you through making a fool out of yourself and being totally wrong?

See my reply to the OP, his original program is invalid.
 
I

Ioannis Vranos

Jack said:
Since you ventured into the realm of opinion, the thing one *should*
do when defining new versions of standard library facilities is to
*not*, under any circumstances, give them the name of standard
functions or types, even if do so in such a way that there is no
collision. Doing so is a monstrous crime.


Yes however standard library facilities are defined in namespace std
(except of the .h header file cases of the C subset).

Also can't one write his own versions of standard library facilities in
his own namespace?






Regards,

Ioannis Vranos
 
T

Tom

Ioannis said:
Yes however standard library facilities are defined in namespace std
(except of the .h header file cases of the C subset).

Also can't one write his own versions of standard library facilities in
his own namespace?

Uhhmmm, did you read Jack Klein's quotation from the standard? This
section looks most relevant (although he says that most of the other
provisions he quotes are violated as well):

"Each name from the Standard C library declared with external linkage
is reserved to the implementation for use as a name with extern "C"
linkage, both in namespace std and in the global namespace."

Seems pretty dispositive to me.

I didn't know whether the program was conforming or nonconforming, but
the fact that Comeau rejected it was quite telling.

Best regards,

Tom
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,171
Messages
2,570,935
Members
47,472
Latest member
KarissaBor

Latest Threads

Top