paul@ra.avid.com (Paul Miller) writes:

|>  >Well, generally speaking, the name of the file can be anything; the .h
|>  >isn't a language requirement:
|>
|>  > #include <wonka>
|>  > #include "local.defs"
|>
|>  Symbolic links, dude! ;^)

Just a reminder that this only works if the semantic content of the new
file is roughly the same as that of the old one.  In the case of
iostream, this is NOT the case: including <iostream> does not guarantee
that streambuf is available (if I understand it right).

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
            -- Conseils en informatique industrielle --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In a recent job, we were exposed to compilers from Sun, IBM, HP, Metaware,
Microsoft, the Edison Design Group, and Gnu.  These were not necessarily
the most recent copies of the various compilers.  Of the bunch, I would
recommend either G++ or EDG-based compilers (SGI and Tera use EDG, not sure
who else does) for ability to track the standard and general usability.
However, EDG (bless their helpful souls) also provides a variety of
switches and flags that can be used to dumb down their otherwise capable
product to roughly match other vendors dialects of C++, so mere use of EDG
does not guarantee a compiler that carefully follows the draft standard.

The problems we encountered with the other compilers included:

Template trouble.  Several vendors have instantiation schemes that
either require special hacks in your build scripts, or are generally
not robust.  A one-time bad compilation can corrupt the repository.

Insufficient support for "recent" changes such as "bool" and "String".

Exception-handling not there yet.  Or, only enabled if you read
the documentation, and remember to throw a funny flag to the compiler.
(Does g++ do exception handling?  I'm not sure that it does across
all platforms.)

On the other hand, I don't know if I was ever able to build a shared
library with g++ on AIX.

All compilers were quirky on some of the corner cases.  We encountered
more of these because the product we were working on inserted "interesting"
instrumentation into the source code, much weirder than the stuff that
mere humans usually generate.  I recall that we had a problem with the
lifetime of temporaries in conditional expressions, for instance, in
that three different compilers did it three different ways.  This problem
shouldn't bother you in practice, and if it does, you should think
seriously about simplifying the code that you write.

I'm sure that the various vendors have their best people working on
all these problems, but it was still very frustrating.

Another "solution" to the compiler problem is to simply target
Windows, quit worrying about the letter and verse of the standard,
and forget about portability anywhere else (it's not like you had
it, anyway).  To a first approximation, all machines run Windows.
This is not necessarily my first choice of OS, but C++ is not my
first choice of language, and I'll make compromises to pay the
bills.  I rather wish the workstation vendors would do a better
job of making the C++ implementations more alike -- presumably this
is part of each vendor's plan to preserve their existing C++ customer
base, and to discourage tools competition from third party vendors.

David Chase
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David Chase wrote:
...
> Another "solution" to the compiler problem is to simply target
> Windows, quit worrying about the letter and verse of the standard,
> and forget about portability anywhere else (it's not like you had
> it, anyway).  To a first approximation, all machines run Windows.
...
There might be Windows emulators on a wide variety of non-Intel
machines, but on most of them are slow and expensive. You also lose most
of the portability gains you might otherwise hope for, due to the fact
that there are usually important features that are not correctly
emulated.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Does anyone know which compiler currently is most compliant with the
C++ draft standard?

I notice that MS VC doesn't even include the setbase() parameterized
stream manipulator, yet most other compilers do.

Also, MS VC doesn't treat the ostream member function put() the way
most other compilers seem to, which is when you pass an int, most
compilers convert it to char, but MS VC requires an explicit cast
to char.

Finally, I am curious which compiler currently supports including
C++ headers without the .h extension, such as   #include <iostream>


Thanks
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Michael H. Chen wrote:
>
> Does anyone know which compiler currently is most compliant with the
> C++ draft standard?

First you would have to specify how to determine whether one
compiler is more compliant than another.

For example, you mentioned supporting
 #include <iostream> // without the .h
 cout.put(j); // j has type int
 the setbase manipulator

Are these all of equal importance? Do they have the same
importance as supporting member templates? The new function
template syntax? Requiring the "typename" keyword to specify
a member type? If the importances are not all equal, you
need to specify a system for deciding whether a compiler
that has A but not B is better than one which has B but
not A.

One way would be to run a test suite like the ones from
Perennial or Plum Hall and count failures. Fewer failures
would mean better compliance. When all compilers of interest
claim to implement the entire standard, that might be a useful
metric. (But I don't think so. Vendors work hard to get
their compilers to pass test suites. It doesn't mean that
compilers that have similar scores have similar support
for combinations of features that didn't get tested. For
example, is a test suite likely to test cout.put() with all
built-in data types to verify it is not improperly overloaded?)

Currently, I don't think any compiler claims to implement
the entire draft standard, so the above metric IMHO
is not of any use. (A missing feature will generate some
number of failures depending on how the test suite is
organized. The differing failure counts for different
missing features is unlikely to represent the relative
importance of those features to you.)

Another way would be to list features that you care about
and create a check list. A compiler with more checked items
is better than one with fewer. Creating such a list is
problematical (you still have the question of relative
importance of features), and you would also have to take into
account how well the feature is actually supported. That just
begs the question. (How do you measure whether one compiler
supports a feature better than another? Back to square one.)

Maybe you just want a compiler that agressively tries to
track the emerging standard. See what the vendor claims,
and use that as a starting point. In the end, you have to
run your own evaluation according to how you rank the
importance of various features, many of which are likely
to be unrelated to C++ language rules.

--
Steve Clamage, stephen.clamage@eng.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <MPG.e193a0a3684f96b98968a@news.slip.net>, mhc@slip.net
(Michael H. Chen) wrote:

<snip>
>
> Finally, I am curious which compiler currently supports including
> C++ headers without the .h extension, such as   #include <iostream>
>

Metrowerks supports #include <iostream>, but currently lacks support in
other areas such as default template arguments and namespaces.  My limited
experience has been that different vendors are implementing different
features first, making it difficult to say who's out front.  If I had to
guess, I would say KAI.  But this opinion is gathered only from reading
literature, not actual use.  So take it with a grain of salt.

-Howard
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

You might want to look into KAI C++ or Comeau C++.  Comeau has the
advantage of being substantially cheaper, but it lacks the standard
libraries.  I've been trying out KAI, and it seems to be a pretty nice
compiler; it's been a great relief after continually battling with other
compilers that seem to have a nervous breakdown whenever you try to
practice generic programming.  Both the KAI and Comeau compilers are based
on the Edison Design Group's C++ front end, so you might want to visit the
EDG web site to find other compilers that use their front-end technology.

Michael H. Chen <mhc@slip.net> wrote in article
<MPG.e193a0a3684f96b98968a@news.slip.net>...
> Does anyone know which compiler currently is most compliant with the
> C++ draft standard?

----------------------------
Kevin S. Van Horn
KSVH Software and Consulting
Payson, Utah
kevin.s.vanhorn@iname.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

mhc@slip.net (Michael H. Chen) writes:

|>  Does anyone know which compiler currently is most compliant with the
|>  C++ draft standard?

I don't think that the question is relevant.  The set of new features
supported will vary from one compiler to the next.  Which is "more
compliant", a compiler that supports the new for scope, or one that
supports member templates?

In addition, new features generally mean new bugs.  In production code,
stability is probably more important than new features.  (And if
portability is an issue, you don't want to use the new features, even if
they happen to be present and stable in the compiler you use.)  In this
regard, I tend to prefer compilers which don't rush to implement the
latest features.  (For production code, of course.  I do like to have an
advanced compiler around to play around with, so that when the time
comes to use the new features in production code, I will have some
experience with them.)

Concerning the specific issues you mentioned: they are not compiler
issues, but library issues.  Which means, in principle, that they can be
solved separately from the compiler issues.  Thus, for example, although
the STL is very new, I think one could seriously consider using a subset
of it (no user defined allocators, for example) in production code, by
standardizing on a third party library, and porting it to each new
release of the compiler.  (Even here, however, I'm in no rush.  My
DLList class may not have all of the flexibility of the STL, but it
works, and it ports to any compiler supporting templates.  If I didn't
already have this class, however, I would certainly use the STL version,
rather than inventing my own.)

|>  I notice that MS VC doesn't even include the setbase() parameterized
|>  stream manipulator, yet most other compilers do.

Probably just an oversite.  This was present in the original
implementation, many years ago.  On the other hand, it is also possible
that there was a version of the draft in which it accidentally didn't
appear, and that MS had the bad luck to standardize their implementation
on this version.  (I know of at least one implementation which didn't
support seeking on streams, for this reason.)

|>  Also, MS VC doesn't treat the ostream member function put() the way
|>  most other compilers seem to, which is when you pass an int, most
|>  compilers convert it to char, but MS VC requires an explicit cast
|>  to char.

It is currently unclear what the correct treatment should be.  It is
entirely possible that when the standard is finally adopted, that MS's
treatment is correct, and the others wrong.

IMHO: if you want to convert an integer to a character, you should say
so, with a cast.  Whether the language requires it or not, I don't see
any reason to try and hide the conversion from a maintainance
programmer.  (FWIW: I think that there was even a proposal to deprecate
"lossy" implicit conversions, like this one.)

|>  Finally, I am curious which compiler currently supports including
|>  C++ headers without the .h extension, such as   #include <iostream>

All of the compilers support it, IF you have a file named iostream (and
not iostream.h) in your path.

With regards to iostream, I've started using <ios.hh>, <streambuf.hh>,
etc.  (One .hh file for each header file in the iostreams chapter.)
According to the system, these might just include <ios> or <streambuf>,
or both might include <iostream.h> (or <iostream.hpp>).  And it provides
a solution for <iosfwd>, as well.  <iosfwd.hh> either includes <iosfwd>,
or it contains the necessary forward declarations.

For the other chapters in the library section, I'm assuming that by the
time they are stable enough for production code, they will be <list> in
the versions provided by the vendor.  (As mentioned above, any use of
STL today is conditioned on the existance of portable third party
implementations.  These implementations should use <list>, etc.  And
none of the compilers I've seen have any problem including a file
without a .something.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
            -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

pedwards@cs.wright.TOAST.edu (Phil Edwards) writes:

>Michael H. Chen <mhc@slip.net> wrote:
>+ Does anyone know which compiler currently is most compliant with the
>+ C++ draft standard?

>Our latest SGI compiler ("CC") doesn't have a string class, which my
>latest project uses extensively, so I don't spend much time there and
>can't tell you much.

It does - it's called "mstring.h" and is in /usr/include/CC. I assume
you mean the "latest" compilers - MIPSPro 7.1?

All in all, I think the SGI compiler has the best support of the
"standard" I've seen, especially in the template area. The next version
(7.2) promises to be even better, with member templates and the new
for-loop scoping thing (yeehaw!).

>A few friends of mine which work mostly on Windoze platforms tell me that
>MSVC4.x is horrible, and 5.x is better but still doesn't fix /enough/.
>That's thirdhand info, though; I haven't touched the stuff.

I can attest to that. Just TRY using nested classes with the STL in
VC 5.0! But hey, they've got 47 new ActiveX wizards...

>+ Finally, I am curious which compiler currently supports including
>+ C++ headers without the .h extension, such as   #include <iostream>

>Well, generally speaking, the name of the file can be anything; the .h
>isn't a language requirement:

> #include <wonka>
> #include "local.defs"

Symbolic links, dude! ;^)


--
Paul Miller                  | paul@elastic.avid.com
SGI Software Engineer        | Opinions expressed here are my own.
     Elastic Reality - a division of Avid Technology, Inc.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]