Re: GCC

• Previous message: Vale Kenny: "Re: Deb. installer - advansys scsi controller"
• In reply to: Dave Carrigan: "Re: GCC"
• Next in thread: John L Fjellstad: "Re: GCC"
• Reply: John L Fjellstad: "Re: GCC"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Tue, 17 Feb 2004 17:22:52 -0500
To: debian-user@lists.debian.org

On Tue, Feb 17, 2004 at 09:14:02AM -0800, Dave Carrigan wrote:
> On Tue, Feb 17, 2004 at 12:23:37PM -0500, Mike M wrote:
>
> > The discussion of declaring main is off the point though. The example
> > is to show that the C++ compilers weren't complaining about the .h on the
> > #includes.
>
> Off the point, but still important: portable C++ requires that main()
> returns an int.

Agreed. But not in small code examples. It's plain to see from the
example that the -Wall option caught the infraction and described it
quite plainly. I always use -Wall and I always clean up the warnings.
>
> > It's puzzling to me why it was necessary to make iostream when
> > iostream.h works just fine. (That's a retorical question aimed at
> > the C++ godz).

Me thinks the godz are running out of room for improving C++. They
have reached the point of rapidly diminishing returns.
>
> Part of the formal C++ standard includes the specification of the C++
> Standard Library. That spec says what the names of the standard header
> files should be, and the spec says that none of the standard header
> files have an extension.
>
> Vendors can do whatever they want behind the scenes to implement the
> spec. In the case of GNU C++, they choose to implement it by putting an
> "iostream" file in the standard include search path, and that file
> #include's an "iostream.h". In theory, a vendor could choose to
> implement "#include <iostream>" by loading a pre-compiled header file
> from a database, and not providing an actual file called iostream at
> all. The only important thing is that the vendor supports #include
> <iostream> correctly.
>
> If you want to write portable C++, you must also use the proper header
> name. That means
>
> #include <iostream>
>
> NOT
>
> #include <iostream.h>

It's important if you want to the use the namespace feature. However,
as detailed below, the namespace feature is esoteric and not widely
available. According to the advice above 100% of C++ programmers
must change to accomodate the namespace feature which is used by a
small percentage of C++ coders.
>
> The latter might work for GNU C++, but it might not work for somebody
> else's C++. To reiterate: when you #include <iostream.h>, you are
> emphatically NOT getting definitions for the C++ Standard Library's
> iostream classes.

With GNU C++ you emphatically are. The GNU C++ maintainers implemented
iostream as wrapper to iostream.h. The GNU C++ implementors are a smart
bunch and they obviously are not making much of a distintion between
iostream and iostream.h. Besides, what use is a compiler that does
not support iostream.h with reliable functionality? I think the real
issue is that the C++ godz want mortal coders to change their habits
so that their latest features will work.

> You might think you are, but you're not, and your code
> won't be portable.

You cannot simply write C++ to the standard and expect to be portable.
The mozilla guide bears this position.

There is portability defined by the standard and then there is
portability defined by practical application of a variety compilers
against a code set. The two methods disagree at times and the
second method settles the arguments at the the mozilla project.
>
> The main reason why this became the standard is because they needed to
> provide backwards compatibility. Vendors had already been shipping
> iostream.h, but the Standard put iostream into the std namespace, and
> many vendors' iostream.h did not. So, they needed to come up with new
> headers that could follow the Standard without breaking backwards
> compatibility with existing code that #include's iostream.h.

So iostream.h is still valid. It has to be or old code can't be
compiled with the new compiler, and that makes the new compiler
less valuable.
>
> The standards committee decided that the most straightforward approach
> would be to eliminate the extension altogether.

They didn't eliminate the extension. They just sternly say you
shouldn't use .h extrensions anymore. Nevermind the fact that there
are unfathomable person-hours of human engineering to use the .h
extension in include files. The removal of the .h extension is in
support of the namespace feature which seems to be implemented
unevenly.

From the mozilla C++ portability guide:

<quote>

5. Don't use namespace facility.

Support of namespaces (through the namespace and using keywords) is a
relatively new C++ feature, and not supported in many compilers. Don't
use it.
</quote>

BTW, the user controllable namespace concept is truly frightening from a code
maintenance point of view. The maintainer must learn the new namespace
functionality like it was a new and poorly documented language.
>
> Not also that if you want to include C headers (e.g., stdlib.h), the
> correct include is
>
> #include <cstdlib>
>
> NOT
>
> #include <stdlib.h>

The C standard committee has surely lost its way if this is true. I'll
change when there's something in it for me:
1. compiler rejects .h extension
2. include files with .h extrensions are no longer available
3. someone pays me

-- 
Mike
Two hundred years ago, we note mischievously, the average American or 
European had a standard of living not very much superior to that of the
average man in India or China. -- dailyreckoning.com
-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

• Previous message: Vale Kenny: "Re: Deb. installer - advansys scsi controller"
• In reply to: Dave Carrigan: "Re: GCC"
• Next in thread: John L Fjellstad: "Re: GCC"
• Reply: John L Fjellstad: "Re: GCC"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]