Connecting Tech Pros Worldwide Forums | Help | Site Map

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

Santiago de Compostela
Guest
 
Posts: n/a
#1: Jul 22 '05
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

Thomas Tutone
Guest
 
Posts: n/a
#2: Jul 22 '05

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



"Santiago de Compostela" <santiago538@yahoo.com> wrote:
[color=blue]
> 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[/color]

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




Alan Johnson
Guest
 
Posts: n/a
#3: Jul 22 '05

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


Santiago de Compostela wrote:
[color=blue]
> 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[/color]

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
Ioannis Vranos
Guest
 
Posts: n/a
#4: Jul 22 '05

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


Santiago de Compostela wrote:
[color=blue]
> 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[/color]




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
Santiago de Compostela
Guest
 
Posts: n/a
#5: Jul 22 '05

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


Alan Johnson <alanwj@mailandnews.com> wrote in message news:<40d688ff$1@news.ua.edu>...[color=blue]
> Santiago de Compostela wrote:
>[color=green]
> > 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[/color]
>
> 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[/color]

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.J. Plauger
Guest
 
Posts: n/a
#6: Jul 22 '05

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


"Santiago de Compostela" <santiago538@yahoo.com> wrote in message
news:c2730559.0406210525.214e2223@posting.google.c om...
[color=blue]
> 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.[/color]

They are -- they've licensed our libraries.
[color=blue]
> 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.[/color]

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


Ioannis Vranos
Guest
 
Posts: n/a
#7: Jul 22 '05

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


Santiago de Compostela wrote:[color=blue]
> Alan Johnson <alanwj@mailandnews.com> wrote in message news:<40d688ff$1@news.ua.edu>...
>
>
> 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.[/color]


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
Ioannis Vranos
Guest
 
Posts: n/a
#8: Jul 22 '05

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


P.J. Plauger wrote:
[color=blue]
> They are -- they've licensed our libraries.[/color]


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.


[color=blue]
> 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.[/color]


What do you mean that it is not practical?






Regards,

Ioannis Vranos
tom_usenet
Guest
 
Posts: n/a
#9: Jul 22 '05

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


On 20 Jun 2004 20:46:29 -0700, santiago538@yahoo.com (Santiago de
Compostela) wrote:
[color=blue]
>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[/color]

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
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Jack Klein
Guest
 
Posts: n/a
#10: Jul 22 '05

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


On 20 Jun 2004 20:46:29 -0700, santiago538@yahoo.com (Santiago de
Compostela) wrote in comp.lang.c++:
[color=blue]
> 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[/color]

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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Jack Klein
Guest
 
Posts: n/a
#11: Jul 22 '05

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


On Mon, 21 Jun 2004 13:03:57 +0300, Ioannis Vranos
<ivr@guesswh.at.grad.com> wrote in comp.lang.c++:
[color=blue]
> Santiago de Compostela wrote:
>[color=green]
> > 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[/color]
>
>
>
>
> 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).[/color]

No, he is wrong about the assumption, and you are wrong to suggest he
file defect reports for perfectly legitimate compiler behavior.
[color=blue]
> 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.[/color]

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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Ioannis Vranos
Guest
 
Posts: n/a
#12: Jul 22 '05

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


Jack Klein wrote:
[color=blue]
> 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.[/color]


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
Tom
Guest
 
Posts: n/a
#13: Jul 22 '05

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


Ioannis Vranos wrote:
[color=blue]
> Jack Klein wrote:
>[color=green]
> > 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.[/color]
>
>
> 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?[/color]

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
Closed Thread