>Visual C++ 4.0's libraries do not place anything in the "std" namespace.

Sorry, I meant 5.0.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote in article <6m7205$4fb$1@nnrp1.dejanews.com>...
> (Irrelevant Question:  If they come out with a new Windows OS, 2 years after
> Windows 98, what the heck will they call it? Windows 00?  Looks like their
> naming scheme isn't Y2K compliant...)

I favor Windows 1900.

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



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <gUfh1.11135$08.2626187@newscene.newscene.com>,
  "Al Stevens" <alstevens@midifitz.com> wrote:
>
>
> Steve Clamage wrote in message <6ltvb4$78v@netlab.cs.rpi.edu>...
> >Are you sure that is the case? For example, do these programs compile?
> > #include <stdio.h>
> > int main() { std::printf("Hello\n"); }
xxx.cpp
xxx.cpp(2) : error C2653: 'std' : is not a class or namespace name
xxx.cpp(2) : warning C4508: 'main' : function should return a value;
    'void' return type assumed
> >
> > #include <cstdio>
> > int main() { std::printf("Hello\n"); }
yyy.cpp
yyy.cpp(2) : error C2653: 'std' : is not a class or namespace name
yyy.cpp(2) : warning C4508: 'main' : function should return a value;
    'void' return type assumed
>
> Neither program compiles with Visual C++ 4.0. Both report that std is
> not a class or namespace name.
Same with Visual C++ 5.0.  However:

namespace std {
#include <cstdio>
}
int main() { std::printf("Hello\n"); }
zzz.cpp
zzz.cpp(2) : warning C4508: 'main' : function should return a value;
    'void' return type assumed
Microsoft (R) 32-Bit Incremental Linker Version 5.02.7132
Copyright (C) Microsoft Corp 1992-1997. All rights reserved.

/out:zzz.exe
zzz.obj

This version compiles with one warning, then links with no errors or
warnings, and runs just fine.

I think that PJP explained the reason for this quite well in a different post.
He also said that there were currently no plans to change it for 6.0, so it
looks like I'll be waiting for VC++6.1 (or VC++7.0? or VC++99?)

(Irrelevant Question:  If they come out with a new Windows OS, 2 years after
Windows 98, what the heck will they call it? Windows 00?  Looks like their
naming scheme isn't Y2K compliant...)

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Al Stevens <alstevens@midifitz.com> wrote:

: >Neither program compiles with Visual C++ 4.0. Both report that std is
: >not a class or namespace name.


: (They also warn that you should have returned a value from main and will
: assume void main, one of my pet peeves.)

The use of void main is a standard violation and a valid Peeve.  The
warning for main not returning a value is allowed as long as they
accept the program.  It is also one of my pet peeves because it
usually results in the novice writing "void main" instead of "return
0;" to make the warning go away.  There are many who object to the
special treatment of main which returns an int, yet requires no return
statement.  I think these complaints will settle down as we get used
to a standard.

John




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jbuck@best.com (Joe Buck) writes:
> > The idea that the "Hello world" program of the ARM was broken is, when
> > you think about it, rather shocking.

Bjarne Stroustrup <bs@research.att.com> wrote:
>Similarly, the ANSI C committee broke the K&R "Hello, world" program
>(by requiring a prototype for varadic functions, such as printf).

Not to anywhere near the same degree.  Inclusion of <stdio.h> is required,
but in the vast majority of implementations it can be omitted.  That
relaxation isn't possible with namespaces.

A specification that, say, <iostream.h> includes <iostream> and then
uses using directives to import the names from std would have been analogous.
In practice, many vendors are doing just this.  The problem is getting
them to do it in a semi-consistent manner.

This is a very real problem, as C++ developers now must support an odd
mixture of compilers that support the ANSI draft to varying degrees, or
not at all.

>The iostreams library is an example. It was decided that a 100% upwards
>compatible iostream library couldn't be provided. Some of the differences
>between the new and the old appeared to be silent - in particular,
>implementations of iostreams from major vendors had significant different
>behavior in places.

It could have been better, eg by deriving istream and ostream from
basic_istream<char> and basic_ostream<char> instead of using a typedef.



--
-- Joe Buck
   work: jbuck@synopsys.com, otherwise jbuck@welsh-buck.org or jbuck@best.com
http://www.welsh-buck.org/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Joe Buck<jbuck@best.com> wrote:
>Bjarne Stroustrup <bs@research.att.com> wrote:
>>
>>The iostreams library is an example. It was decided that a 100% upwards
>>compatible iostream library couldn't be provided. Some of the differences
>>between the new and the old appeared to be silent - in particular,
>>implementations of iostreams from major vendors had significant different
>>behavior in places.
>
>It could have been better, eg by deriving istream and ostream from
>basic_istream<char> and basic_ostream<char> instead of using a typedef.

As has been pointed out several times before in this forum,
this option was considered at length.  It had serious problems,
and was rejected because of those problems, and not through some
oversight or prejudice.

To see this, consider the (very common) code where somebody
has written:

  ostream& operator<<(ostream&, MyType const&);

Imagine somebody else with a basic_ostream<char> instance, str:

  basic_ostream<char> str;
  str << my;  // error, in this alternate reality

str cannot be passed to operator<<, because that would require a
(forbidden) downcast.  The committee considered specifying
conversion operators, such as a member of basic_ostream<char>:

  operator ostream&()

This opens a can of worms associated with the (large) differences
between the language's builtin conversions and programmed conversions.
The effect on template matching (never a simple matter to begin with)
would be thornier yet.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Al Stevens wrote in message ...
>Neither program compiles with Visual C++ 4.0. Both report that std is
>not a
>class or namespace name.

Visual C++ 4.0's libraries do not place anything in the "std" namespace.

 { End of antiquated platform/compiler specific discussion.  VC++5.X
   maybe?  -jep }


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>Neither program compiles with Visual C++ 4.0. Both report that std is
>not a class or namespace name.


(They also warn that you should have returned a value from main and will
assume void main, one of my pet peeves.)




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6lop9f$8p3@netlab.cs.rpi.edu>,
  stephen.clamage@sun.com (Steve Clamage) wrote:
> The rules are:
> 1. <stdlib.h> puts all the names of the standard C header <stdlib.h>
> in both the std and the global namespaces.
> 2. <cstdlib> put all the names of the standard C header <stdlib.h>
> in just the std namespace.
>
> There are specific additions and changes, usually minor, for
> many of the standard C headers. In the case of <stdlib.h>, one
> function signature is added to the C++ version. (Three of
> the functions have additional behavior requirements, but that
> doesn't show up in the headers.)
>
> Macro names are irrelevant, since they disappear before namespaces
> are taken into account in the phases of processing.
>
> It is just barely possible to read the requirements to allow
> <cstdlib> to put the C names in the global namespace, making
> the two headers equivalent. That wasn't the intention of the
> requirements, however. We might see a clarification later.

This all started when I looked at the implementation of <cstdlib> on
my compiler (Microsoft VC++ 5.0).  The only important part looks like
this:
    #ifdef _STD_USING
      #undef _STD_USING
      #include <stdlib.h>
      #define _STD_USING
    #else
      #include <stdlib.h>
    #endif /* _STD_USING */
This seemed to have very clear meaning to me, which was: If we're already
inside a "namespace std {" section, temporarily erase the macro _STD_USING
so that we don't try to nest another one.  Either way, include the normal
<stdlib.h> implementation.

But I also knew that <stdlib.h> has an "include guard":
    #ifndef _INC_STDLIB
    #define _INC_STDLIB
    // ... Do all of the "real" work ...
    #endif // _INC_STDLIB
so that it can't be included twice.  My conclusion was that code like this:
    #include <stdio.h> // Bring it into global name space
    #include <cstdio>  // and also into namespace "std"
would fail, since the second #include would be ignored.

This seemed important to me, because although this is unlikely to happen
deliberately (as above), it might happen accidentally:
    // Thirdparty.H
    #include <stdio.h>
    class ThirdParty {
        int x, y;
        // ...
    public:
        int sum() { return x+y; }
        void DebugDump()
            { printf("ThirdParty: x=%d, y=%d\n", x, y); }
    }

    // Main.Cpp
    #include <cstdio>        // Or this one?
    #include <ThirdParty.H>  // Should this header file go first?
    int main(int argc, char*argv[]) {
        ThirdParty t;
        std::printf("Sum=%d\n", t.sum());
    }

If my library conforms to rules 1. and 2. above, but my theory about the
"include guard" was correct, then anytime I need these symbols in the global
namespace I would have to be careful to include <stdio.h> (or some include
file that itself includes <stdio.h>) before including any include file that
might include <cstdio>.  I hate these "Header File Hell" situations in which
if two header files are needed, they must be in just the right order.

When I finally got around to testing it, however, I found something
completely different from what I expected.  Neither cstdlib nor stdlib.h
EVER put any symbols in namespace std.  In fact, header file <stdlib.h>
never makes any use of preprocessor symbol _STD_USING, which <cstdlib>
was so careful to set and preserve.  Both files always put all of the
library functions in global namespace, unless I intentionally wrap them
in a different namespace manually:
    using namespace std {
        #include <cstdlib>
    }
    using namespace std; // Bring them into global namespace as well

Curiously, even though the header files will NEVER declare function printf()
to be in namespace std, it has no trouble linking if I manually force it to
be this way.  But that's not true just for namespace std -- it seems that
it works for any namespace name!  For instance:
    namespace AllanW {
        #include <cstdlib>
    }
    int main(int argc, char*argv[]) {
        AllanW::printf("Argc=%d", argc);
    }
I never supplied a definition for AllanW::printf(), but the linker
automatically used the library version.  Shouldn't this fail if my compiler
truely supports namespaces?

Anyway, both of the above rules for C-style include files are broken.  The
two header files give equivalent results, declaring the functions in global
namespace but not in std.  Therefore, how the two header files interact with
each other is completely irrelevant.

Perhaps VC++ 6.0 will change all of this...

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

J. Kanze wrote in message ...
>"Matt Seitz" <mseitz@meridian-data.com> writes:
>I don't think that was the problem; it didn't stop them with regards to
>the libraries inherited from C.  The problem was that the iostream.h
>differed from one implementation to the next -- to provide an upgrade
>path, the implementor must provide an iostream.h conform to his previous
>implementation, and not to one defined by the standard.


That's a good point, and one that is mentioned in the C++ PROGRAMMING
LANGUAGE reference I cited.  But it seemed to me that is was not necessarily
reason enough for the committee to not require an iostream.h.  The committee
could have required some functionality from iostream.h and left the rest up
to implementers.  To use a previous writer's example, the committee could
have mandated an iosteam.h that could at least support the ARM's "Hello,
World" program.  Did iostream.h implementations vary so widely that even
that program would be unportable?

Perhaps the committe's thinking was that
a) for toy program's like Hello World, the effort to convert iostream is
trivial
b) for large programs, the diversity of current iostream.h implementations
makes it impossible to come up with a standard version that supports them
all.  Since programmers would have to modify code to be compatible with a
new standard iostream.h, why not just have them make the modifications to be
compatible with the new standard iostream.

Not having contact with the committee, I can only speculate.  Perhaps a
committee member can give us the actual reason for not including an
iostream.h



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jbuck@best.com (Joe Buck) writes:

 > The idea that the "Hello world" program of the ARM was broken is, when
 > you think about it, rather shocking.

Similarly, the ANSI C committee broke the K&R "Hello, world" program
(by requiring a prototype for varadic functions, such as printf).


 > I'm not proposing that the topic be reopened (it's too late), but I can't
 > stomach people saying there was no existing standard so the committee had
 > a clean slate.

I guess that formally, there was a clean slate, but in reality there certainly
wasn't and the committee spent endless time agonizing over compatibility issues.
That is, issues about compatibility with C, the ARM, etc. implementations of
C++, various libraries, and previous drafts of the standard.

There were many concerns that needed to be balanced. Compatibility with
existing code and documentation is important, but not the only concern.
All in all, I think the committee did well.

Code were not broken unless there seemed to be no alternative way of
gaining a significant advantage at the cost of a relatively minor problem.

It was an explict criteria that there should always be an upgrade path
available in the few cases where code had to be broken. Ideally, a change
is never "silent" (that is, the compiler detects old usage as an error,
rather than quietly giving a different result) and a simple change allows
the programmer to modify the code to get a desired result (usually, the
result that used to be achieved).

The iostreams library is an example. It was decided that a 100% upwards
compatible iostream library couldn't be provided. Some of the differences
between the new and the old appeared to be silent - in particular,
implementations of iostreams from major vendors had significant different
behavior in places.

Using <iostream> rather than <iostream.h> gives a clue that something new is
happening. Had the committee provided an <iostream.h> for compatibility, it
would have caused silent changes that affected many users.

I and others expected that various vendors would continue to provide a
(non-standard) <iostream.h> (or something similar) to aid their users through
the transition.

Compatibility issues can be nasty and their resolutions are rarely pretty
(especially in the short run). However, I see nothing "rather shocking" in
the way the iostream compatibility issues were handled.

 - Bjarne

Bjarne Stroustrup, AT&T Labs, http://www.research.att.com/~bs



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote in article
<6lrgcn$nsh@netlab.cs.rpi.edu>...
> In article <6lop9f$8p3@netlab.cs.rpi.edu>,
>   stephen.clamage@sun.com (Steve Clamage) wrote:
> > The rules are:
> > 1. <stdlib.h> puts all the names of the standard C header <stdlib.h>
> > in both the std and the global namespaces.
> > 2. <cstdlib> put all the names of the standard C header <stdlib.h>
> > in just the std namespace.

This has been basically true since shortly after namespaces were added
to the draft C++ Standard in mid 1993. Several major compiler vendors
have repeatedly objected, over the years, but to no avail. I could be
wrong, but I believe that no current commercial offering exactly matches
these rules to date (except mine, but nobody wants to ship it in this
form).

> > There are specific additions and changes, usually minor, for
> > many of the standard C headers. In the case of <stdlib.h>, one
> > function signature is added to the C++ version. (Three of
> > the functions have additional behavior requirements, but that
> > doesn't show up in the headers.)

It's not quite that simple. See
http://www.dinkumware.com/htm_cpl/stdlib.html. Look for the C++-specific
features, marked with bold tags. And this page does not reflect more
recent additions to atexit, bsearch, and qsort. Still, I would say that
*a few* of the Standard C headers require additions for C++. Look around
further in that directory (starting from index.html) to see what I mean.
(See also the restrictions on use at
http://www.dinkumware.com/refxcpp.html.)

> > Macro names are irrelevant, since they disappear before namespaces
> > are taken into account in the phases of processing.

Except, of course, that the old practice of overriding C function names
with macro definitions is now outlawed. For example, C++ reserves just
the *signature* isspace(int), so an implementor can no longer define the
function macro isspace. You have to use inlines instead for good
performance.

> > It is just barely possible to read the requirements to allow
> > <cstdlib> to put the C names in the global namespace, making
> > the two headers equivalent. That wasn't the intention of the
> > requirements, however. We might see a clarification later.

I really want to read the requirements this way, and a lot of people
have, but I still can't. Nevertheless, I'm happy to pretend that this
approach is permissible, if everyone else will pretend along with me.

> This all started when I looked at the implementation of <cstdlib> on
> my compiler (Microsoft VC++ 5.0).  The only important part looks like
> this:
>     #ifdef _STD_USING
>       #undef _STD_USING
>       #include <stdlib.h>
>       #define _STD_USING
>     #else
>       #include <stdlib.h>
>     #endif /* _STD_USING */
> This seemed to have very clear meaning to me, which was: If we're
already
> inside a "namespace std {" section, temporarily erase the macro
_STD_USING
> so that we don't try to nest another one.  Either way, include the
normal
> <stdlib.h> implementation.

Not exactly. This macro logic is used by the Dinkum C Library, to
conform to the rules outlined by Clamage above. Our C and C++ libraries
combined have obeyed the draft C++ Standard namespace rules for years,
as I indicated earlier.

> .....
> When I finally got around to testing it, however, I found something
> completely different from what I expected.  Neither cstdlib nor
stdlib.h
> EVER put any symbols in namespace std.  In fact, header file
<stdlib.h>
> never makes any use of preprocessor symbol _STD_USING, which <cstdlib>
> was so careful to set and preserve.  Both files always put all of the
> library functions in global namespace, unless I intentionally wrap
them
> in a different namespace manually:

Correct. That was the choice that I made, in close consultation with
Microsoft, at the time this implementation was first frozen in early
1996. We have not yet had occasion to reconsider the matter. At the
time, nobody thought it was ``just barely possible to read'' the draft
in such a way as to avoid rather extensive changes to *all* the C
headers. We didn't want to risk namespace antics that would affect
essentially all existing C++ code, not with a brand new implementation,
and not while the namespace rules were still being baked in by the C++
committee. So we did what more than one compiler vendor did at the time
and left the C headers completely out of namespace std.

> Anyway, both of the above rules for C-style include files are broken.
The
> two header files give equivalent results, declaring the functions in
global
> namespace but not in std.  Therefore, how the two header files
interact with
> each other is completely irrelevant.

A concise summary of status quo. I merely emphasize that the behavior is
intentional, not an oversight, and VC++ is far from alone in choosing to
break these rules.

> Perhaps VC++ 6.0 will change all of this...

Not yet, AFAIK. What I'm hoping is that most implementations will settle
on the ``just barely possible to read'' approach, which lets you leave
the C headers alone. Then, you can implement <cstdlib> as:

#include <stdlib.h>
namespace std {
 using ::size_t; using ::div_t; using ::ldiv_t;
 using ::atexit; using ::exit; using ::getenv;
 // etc.
 };

Clamage's rules then read:

1. <stdlib.h> puts all the names of the standard C header <stdlib.h> in
the global namespaces.
2. <cstdlib> put all the names of the standard C header <stdlib.h> in
both the std and the global namespaces.

Some implementations may go ahead and do what the FDIS clearly says, in
which case the pragmatic usage rules for C headers should be:

1. If you want to be sure that the names are defined in the global
namespace, include <XXX.h>.

2. If you want to be sure that the names are defined in namespace std,
include <cXXX>.

3. Always assume that the names might be defined in both the global
namespace and namespace std.

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


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Matt Seitz" <mseitz@meridian-data.com> writes:

>J. Kanze wrote in message ...
>>"Matt Seitz" <mseitz@meridian-data.com> writes:
>>I don't think that was the problem; it didn't stop them with regards to
>>the libraries inherited from C.  The problem was that the iostream.h
>>differed from one implementation to the next -- to provide an upgrade
>>path, the implementor must provide an iostream.h conform to his previous
>>implementation, and not to one defined by the standard.

>That's a good point, and one that is mentioned in the C++ PROGRAMMING
>LANGUAGE reference I cited.  But it seemed to me that is was not necessarily
>reason enough for the committee to not require an iostream.h.  The committee
>could have required some functionality from iostream.h and left the rest up
>to implementers.  To use a previous writer's example, the committee could
>have mandated an iosteam.h that could at least support the ARM's "Hello,
>World" program.  Did iostream.h implementations vary so widely that even
>that program would be unportable?

No. But if the standard says that <iostream.h> must be supplied,
it must also say what its contents are, and describe all the
semantics. You wouldn't be satisfied with a requirement that
said only that the "Hello world" example must work. Other things
would also have to work. Which other things, and exactly how
would they work?

To pick just one example, existing implementations of classic
iostreams are split (approximately 50-50) on whether
 cout << 'a';
applies the formatting flags to the character when it is output.
In this case (my favorite example), the documentation for iostreams
was clear that formatting should be applied. Nevertheless, due to
a bug in the code, the original implementation did not apply
formatting, and some later implementations felt constrained to
duplicate that bug. Others did what was "obviously correct".

There are numerous places in the original iostream documentation
where semantics are not supplied, and implementations of course
differ on those.

Now, what about other headers: <fstream.h>, <iomanip.h>,
<stdiofile.h>, <stdiostream.h>, and <generic.h>? If you want to
maintain any sort of backwards compatibility, you'd have to
mandate at least some of the contents of some of those headers.

For the C++ standard to mandate a backwards-compatible version
of iostreams would be a large task with no net benefit -- the
standard either would leave things as muddled as they are now,
or force implementations to choose between conforming to the
standard or remaining compatible with their earlier releases.

The existing situation actually leaves you (as a C++ programmer)
better off than if the standard required <iostream.h>. There
was never any hope that different implemenations of classic
iostreams would be completely compatible. But any self-
respecting implementor will continue to supply a version of
classic iostreams compatible with the previous delivered version
of iostreams. The C++ standard cannot make a vendor do that --
only market pressure can, and market pressure forces that
result no matter what the standard says.

This is one of many areas best left as a "quality of
implementation" issue.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:

> [ regarding the MSC++ implementation ]
>
>... My conclusion was that code like this:
>    #include <stdio.h> // Bring it into global name space
>    #include <cstdio>  // and also into namespace "std"
>would fail, since the second #include would be ignored.

It is quite reasonable for the second include to be ignored.
The <stdio.h> header is required to put the standard names in
both namespace std and in the global namespace. There is then
nothing for <cstdio> to do. It's only function is to put
names into namespace std that <stdio.h> has already done.

>This seemed important to me, because although this is unlikely to happen
>deliberately (as above), it might happen accidentally: ...

Whether it happens accidently or deliberately, you are supposed
to be able to include any of the standard headers in any order
any number of times with no bad effects. (With some caveats
about the "assert" header.)

> ... When I finally got around to testing it, however, I found something
>completely different from what I expected.  Neither cstdlib nor stdlib.h
>EVER put any symbols in namespace std.

Are you sure that is the case? For example, do these programs compile?

 #include <stdio.h>
 int main() { std::printf("Hello\n"); }

 #include <cstdio>
 int main() { std::printf("Hello\n"); }

If either of them fails to compile, the implementation is
non-conforming.

That might be deliberate, of course. Perhaps the version of
the compiler you are using does not (yet) intend to conform to
this part of the draft standard. The documentation should say
whether it does.

--
Steve Clamage, stephen.clamage@sun.com

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:

>I'm curious about functions in "C-Style" header files.  With the old-style
>header files, they're in the global namespace.  But with the new-style
header
>files, they're in namespace std.  Are they the same function?

While you might get replies on this topic more useful than mine, remember
that any header ending in *.h, and any library symbol in the '::' except
'std' is now called "vendor specific". Therefor the result of mixing the
headers can only also be called "vendor specific".

I do this too often - to thrust a snip of STL into legacy code, for example.

But the linking rules say they must be a different function. Then the As-If
rule says they can be the same function so long as the result behaves the
same As If they were a different function. Must this include
function-pointer comparison situations?

I, too, await clearer answers to this question, including a "don't" list...

  --  Phlip
======= http://users.deltanet.com/~tegan/home.html =======
  --  Still seeking professional help to overcome my
      fear of editing HTML in anything but Notepad...  --
---

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6liufe$sta@netlab.cs.rpi.edu>,
  "Phlip" <tegan@deltanet.com> wrote:
> While you might get replies on this topic more useful than mine, remember
> that any header ending in *.h, and any library symbol in the '::' except
> 'std' is now called "vendor specific". Therefor the result of mixing the
> headers can only also be called "vendor specific".

Is this true?  Is it really completely optional for vendors to continue to
supply <iostream.h> et. al.?

If so, this would be bitter irony.  Much of the C++ language still has roots
in compatibility with another language, namely C.  (For instance,
    Foo bar1(a,b), bar2(a), bar3(), bar4;
declares bar3 to be a function, althought it's probably just a programmer
error!)  And yet here is a case where a compiler wouldn't be required to be
compatible with the previous ANSI version of the same language -- C++!

This doesn't sound right to me; I hope you're wrong.  I trust ANSI to do
better than this.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:

> In article <6liufe$sta@netlab.cs.rpi.edu>,
>   "Phlip" <tegan@deltanet.com> wrote:
> > While you might get replies on this topic more useful than mine, remember
> > that any header ending in *.h, and any library symbol in the '::' except
> > 'std' is now called "vendor specific". Therefor the result of mixing the
> > headers can only also be called "vendor specific".
>
> Is this true?  Is it really completely optional for vendors to continue to
> supply <iostream.h> et. al.?

Yes, with one exception: vendors are required to provide the old-style
C header files.  For example, vendors are required to provide both
<stdio.h> and <cstdio>.  The standard is very explicit about the
relationship between <stdio.h> and <cstdio>.

The point is that this is the first C++ standard, so there is no
earlier version of standard C++ that we have to be compatible with.
There was (and is) an existing C standard, though.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Phlip<tegan@deltanet.com> wrote:
>AllanW@my-dejanews.com wrote:
>
>>I'm curious about functions in "C-Style" header files.  With the old-style
>>header files, they're in the global namespace.  But with the new-style
>header files, they're in namespace std.  Are they the same function?

Yes, they are.  That is, the address must even be the same.

>... remember
>that any header ending in *.h, and any library symbol in the '::' except
>'std' is now called "vendor specific". Therefor the result of mixing the
>headers can only also be called "vendor specific".

Of course this remark doesn't apply to any of the traditional
Standard C headers.  Both <cstdio> and <stdio.h> headers are
standard in C++.

>But the linking rules say they must be a different function.

Not so.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:

>Is this true?  Is it really completely optional for vendors to continue to
>supply <iostream.h> et. al.?

>If so, this would be bitter irony.  Much of the C++ language still has roots
>in compatibility with another language, namely C.  ...
>And yet here is a case where a compiler wouldn't be required to be
>compatible with the previous ANSI version of the same language -- C++!

>This doesn't sound right to me; I hope you're wrong.  I trust ANSI to do
>better than this.

The C++ standard defines the C++ language. It does not define
earlier dialects.

The headers for classic iostreams (never formally defined anywhere)
provided certain capabilities, which varied in detail among systems.
The C++ standard could say that a standard <iostream.h> header
must be provided, but then its contents become problematical.

Should the contents be identical to <iostream>? If so, it
would deny implementors the possibility of providing a
migration path for their customers. If not, what should it
contain? It can't be identical to classic iostreams, since
classic iostreams is not fully compatible with standard
iostreams.

As a C++ vendor, I'd be remiss to provide a new, standard-
conforming implementation without a migration path for my
customers using older versions of my system.

Consequently, I'd want to provide a header <iostream.h> that
provided as much basic functionality of my implementation of
classic iostreams as possible, consistent with the new standard.
Customers using only simple I/O could migrate to the new
compiler without changing source code, then gradually update the
code to the standard while continuing to have a working program.

Because the standard does not prescribe <iostream.h>, I can
do just that, and so can other vendors.
--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote in message <6lkdrv$vme$1@nnrp1.dejanews.com>...
>Is this true?  Is it really completely optional for vendors to continue to
>supply <iostream.h> et. al.?

>[...]here is a case where a compiler wouldn't be required to be
>compatible with the previous ANSI version of the same language -- C++!


What previous ANSI version?  My understanding is that the current proposed
ISO C++ standard will become the first one.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>
>
> Is this true?  Is it really completely optional for vendors to continue to
> supply <iostream.h> et. al.?

It's optional, just as any other non-standard header is "optional". The
standard says nothing about <iostream.h>.

>
> If so, this would be bitter irony.  Much of the C++ language still has roots
> in compatibility with another language, namely C.  (For instance,
>     Foo bar1(a,b), bar2(a), bar3(), bar4;
> declares bar3 to be a function, althought it's probably just a programmer
> error!)  And yet here is a case where a compiler wouldn't be required to be
> compatible with the previous ANSI version of the same language -- C++!

There was no "previous ANSI version of ... C++". Technically there isn't
even an ANSI version now: the Final Draft Information Standard (FDIS) is
still in the approval process. There's little doubt that it will be
approved, however, and then we will have the first ISO and ANSI standard
for C++.
 -- Pete


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

<AllanW@my-dejanews.com> wrote:
>I'm curious about functions in "C-Style" header files.  With the old-style
>header files, they're in the global namespace.  But with the new-style header
>files, they're in namespace std.  Are they the same function?
>
>@@@
>
>On my compiler, <stdlib.h> looks like this:
>    #ifndef _INC_STDLIB
>    #define _INC_STDLIB
>    // ... A zillion declarations ...
>    #endif // _INC_STDLIB
>and <cstdlib> looks like this:
>    namespace std {
>        #include <stdlib.h>
>    };
>I realize that the first one is provided for backward compatibility (and for
>C compatibility) only.

Not so, <stdlib.h> is required.  But of course it doesn't have to be
the same file as your C compiler would see.

>   But if I'm crazy enough to include BOTH of them,
>they'll end up declaring exactly ONE of ::abort and std::abort (depends on
>which header file was first).  Examining as many libraries as I can (which
>isn't many), this seems to be the status quo, but isn't this non-conforming?

Absolutely.  Furthermore, it's likely to cause you serious trouble.

The ::abort you get from <stdlib.h> and the std::abort() you get
from <csdlib> must be the same function.

>Is there a standard way for me to write a single function which is in both the
>global and some specific-named namespace?  The only way I can think of is to
>declare it in a namespace and then "pull" it into the global namespace:
>    namespace AllanW {
>        void func();
>    };
>    using AllanW::func;>

An outline (with some inaccuracies, I fear) for how to do this
sort of thing properly may be found at

  http://www.cantrip.org/cheader.html

(The inaccuracies I know about relate to what it says about
which macros are permitted/required in standard C headers as
provided in a C++ implementation.)

[Incidentally... it's considered bad form to post to both
 comp.std.c++ *and* comp.lang.c++.moderated.]

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6lhkpa$14g$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com wrote:
>
> I'm curious about functions in "C-Style" header files.  With the
old-style
> header files, they're in the global namespace.  But with the new-style
header
> files, they're in namespace std.

Are you sure?  It was my understanding that the old style header should
be the equivalent of:

    #include <cstdlib>
    using std::abort ;
    using ...

This makes the specified functions visible in global namespace, even
though
they are defined in namespace std.

---
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

ncm@nospam.cantrip.org (Nathan Myers) writes:

> >   But if I'm crazy enough to include BOTH of them,
> >they'll end up declaring exactly ONE of ::abort and std::abort (depends on
> >which header file was first).  Examining as many libraries as I can (which
> >isn't many), this seems to be the status quo, but isn't this non-conforming?
>
> Absolutely.  Furthermore, it's likely to cause you serious trouble.

Well, you know...

Assuming that abort() is declared to be extern "C", it's not so bad as
all that.  There's a special rule about extern "C" in the C++
standard, and the two declarations
  extern "C" void abort()
and
  namespace std {
    extern "C" void abort()
  }
refer to the very same function.

But more generally: yes, it doesn't work to implement <cstdlib> as a
file that just #includes <stdlib.h> within a namespace.  That sort of
approach will fail for some of the declarations that are required to
exist in that header.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matt Austern  <austern@sgi.com> wrote:
>The point is that this is the first C++ standard, so there is no
>earlier version of standard C++ that we have to be compatible with.

It is unfortunate that the committee took this approach.  They were
given the task of standardizing an existing language, which should
have imposed more of a constraint of compatibility with existing
practice.

>There was (and is) an existing C standard, though.

Ah, but ANSI/ISO C accepts K&R C.  They did not require conversion of
all programs (e.g. to add prototypes).  So they acted as though there
were an existing "standard" (the K&R book).

While it is too late now, the committee could have made more effort to
comply, where possible, with the existing "standard" (the ARM), maybe
breaking things most programmers would consider bad practice but not
breaking basic programs that use streams.

Two such methods might have been to specify that iostream.h corresponds
to iostream plus exports of names mentioned in the ARM with "using std::name",
and making ostream a class derived from basic_ostream<...> rather than a
typedef (to support "class ostream;").

The idea that the "Hello world" program of the ARM was broken is, when
you think about it, rather shocking.

I'm not proposing that the topic be reopened (it's too late), but I can't
stomach people saying there was no existing standard so the committee had
a clean slate.
--
-- Joe Buck
   work: jbuck@synopsys.com, otherwise jbuck@welsh-buck.org or jbuck@best.com
http://www.welsh-buck.org/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jkanze@otelo.ibmmail.com writes:

>In article <6lhkpa$14g$1@nnrp1.dejanews.com>,
>  AllanW@my-dejanews.com wrote:
>>
>> I'm curious about functions in "C-Style" header files.  With the
>old-style
>> header files, they're in the global namespace.  But with the
new-style
>header files, they're in namespace std.

>Are you sure?  It was my understanding that the old style header should
>be the equivalent of:

>    #include <cstdlib>
>    using std::abort ;
>    using ...

>This makes the specified functions visible in global namespace, even
>though they are defined in namespace std.

What you show is a possible implementation.

The rules are:
1. <stdlib.h> puts all the names of the standard C header <stdlib.h>
in both the std and the global namespaces.
2. <cstdlib> put all the names of the standard C header <stdlib.h>
in just the std namespace.

There are specific additions and changes, usually minor, for
many of the standard C headers. In the case of <stdlib.h>, one
function signature is added to the C++ version. (Three of
the functions have additional behavior requirements, but that
doesn't show up in the headers.)

Macro names are irrelevant, since they disappear before namespaces
are taken into account in the phases of processing.

It is just barely possible to read the requirements to allow
<cstdlib> to put the C names in the global namespace, making
the two headers equivalent. That wasn't the intention of the
requirements, however. We might see a clarification later.

--
Steve Clamage, stephen.clamage@sun.com

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Joe Buck wrote in message <6lmobm$d5f$1@shell17.ba.best.com>...
>Two such methods might have been to specify that iostream.h corresponds
>to iostream plus exports of names mentioned in the ARM with "using
std::name",

>and making ostream a class derived from basic_ostream<...> rather than a
>typedef (to support "class ostream;").

This issue is discussed in THE C++ PROGRAMMING LANGUAGE 3rd edition, section
B.3.1.  It points out that compilers can and often do exactly what you
suggest:  continue to include an "iostream.h" header that support the old
stream facilities.

I think the comittee was right to not make iostream.h part of the new
standard.  I think having two, nearly identical libraries as part of the
standard library would be redundant and confusing for new users.  It would
also mean that every new compiler would have to keep including and
maintaining both the old iostream.h library and the new iostream library.
Better to have just the current library as the standard, and allow library
vendors to include their old library for backwards compatability.







[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Matt Seitz" <mseitz@meridian-data.com> writes:

|>  Joe Buck wrote in message <6lmobm$d5f$1@shell17.ba.best.com>...
|>  >Two such methods might have been to specify that iostream.h corresponds
|>  >to iostream plus exports of names mentioned in the ARM with "using
|>  std::name",
|>
|>  >and making ostream a class derived from basic_ostream<...> rather than a
|>  >typedef (to support "class ostream;").
|>
|>  This issue is discussed in THE C++ PROGRAMMING LANGUAGE 3rd edition, section
|>  B.3.1.  It points out that compilers can and often do exactly what you
|>  suggest:  continue to include an "iostream.h" header that support the old
|>  stream facilities.
|>
|>  I think the comittee was right to not make iostream.h part of the new
|>  standard.  I think having two, nearly identical libraries as part of the
|>  standard library would be redundant and confusing for new users.  It would
|>  also mean that every new compiler would have to keep including and
|>  maintaining both the old iostream.h library and the new iostream library.
|>  Better to have just the current library as the standard, and allow library
|>  vendors to include their old library for backwards compatability.

I don't think that was the problem; it didn't stop them with regards to
the libraries inherited from C.  The problem was that the iostream.h
differed from one implementation to the next -- to provide an upgrade
path, the implementor must provide an iostream.h conform to his previous
implementation, and not to one defined by the standard.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jbuck@best.com (Joe Buck) writes:

|>  Matt Austern  <austern@sgi.com> wrote:
|>  >The point is that this is the first C++ standard, so there is no
|>  >earlier version of standard C++ that we have to be compatible with.
|>
|>  It is unfortunate that the committee took this approach.  They were
|>  given the task of standardizing an existing language, which should
|>  have imposed more of a constraint of compatibility with existing
|>  practice.

My impression is that they didn't take the approach Matt says, and that
compatibility with existing code was an issue.

|>  >There was (and is) an existing C standard, though.
|>
|>  Ah, but ANSI/ISO C accepts K&R C.  They did not require conversion of
|>  all programs (e.g. to add prototypes).  So they acted as though there
|>  were an existing "standard" (the K&R book).

The ANSI C accepted the existing de-facto standard.  For the basic
language, this was K&R, with extensions.  (K&R1 didn't describe enum's,
but it was a quasi-standard extension by the time ANSI went to work.)
On the other hand, there were cases, like the preprocessor, where there
were two de-facto standards.  In this case, the C committee inovated,
and there were problems for people upgrading -- most C compilers still
have a switch to control which preprocessor model they use: ISO, or
whatever was current on their platform before ISO.

|>  While it is too late now, the committee could have made more effort to
|>  comply, where possible, with the existing "standard" (the ARM), maybe
|>  breaking things most programmers would consider bad practice but not
|>  breaking basic programs that use streams.

The problem is that there was no real de-facto standard for streams.  My
experience is that it is less work to upgrade CFront based stream code
(including some pretty exotic stuff, including some streambuf templates)
to ISO (or at least the version of it delivered with VC++) that it was
to port the stream code between different pre-standard compilers (but
YMMV, as they say).  There are a number of points where I disagree with
what the committee has done, but in this case, I have to say that I
can't imagine how they could have done it better.

|>  Two such methods might have been to specify that iostream.h corresponds
|>  to iostream plus exports of names mentioned in the ARM with "using std::name",
|>  and making ostream a class derived from basic_ostream<...> rather than a
|>  typedef (to support "class ostream;").

Well, I used compilers where the iostream file was iostream.hpp, so I
guess you'd have to define that as well.  More important, I find that
the semantics of the functions defined in iostream.h varied from one
compiler to the other; which semantics should be required for the
standard iostream.h.

|>  The idea that the "Hello world" program of the ARM was broken is, when
|>  you think about it, rather shocking.

You could say so.  On the other hand, the ANSI C committee also broke
the "Hello world" program in K&R1, so I guess there is precedence.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I'm curious about functions in "C-Style" header files.  With the old-style
header files, they're in the global namespace.  But with the new-style header
files, they're in namespace std.  Are they the same function?

@@@

On my compiler, <stdlib.h> looks like this:
    #ifndef _INC_STDLIB
    #define _INC_STDLIB
    // ... A zillion declarations ...
    #endif // _INC_STDLIB
and <cstdlib> looks like this:
    namespace std {
        #include <stdlib.h>
    };
I realize that the first one is provided for backward compatibility (and for
C compatibility) only.  But if I'm crazy enough to include BOTH of them,
they'll end up declaring exactly ONE of ::abort and std::abort (depends on
which header file was first).  Examining as many libraries as I can (which
isn't many), this seems to be the status quo, but isn't this non-conforming?

@@@

Is this:
    // Clash.Cpp
    #include <stdlib.h>
    #include <cstdlib>
    // ...
guaranteed to compile correctly?

@@@

    // Prog1.Cpp
    #include <stdlib.h>
    typedef void(*VOIDFUNC)(void);
    VOIDFUNC func1() { return abort; }

    // Prog2.Cpp
    #include <cstdlib>
    typedef void(*VOIDFUNC)(void);
    VOIDFUNC func2() { return std::abort; }

    // Prog.Cpp
    #include <iostream>
    typedef void(*VOIDFUNC)(void);
    VOIDFUNC func1();  // Returns the address of ::abort
    VOIDFUNC func2();  // Returns the address of std::abort
    int main() {
        std::cout << (func1()==func2() ? "Yes" : "No") << std::endl;
        return 0;
    }
Will this always print "Yes"?

@@@

Is there a standard way for me to write a single function which is in both the
global and some specific-named namespace?  The only way I can think of is to
declare it in a namespace and then "pull" it into the global namespace:
    namespace AllanW {
        void func();
    };
    using AllanW::func;>
<input type=

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]