Thread

Topic: RFD: C++ Compiler/Library Conformance Issues

Author: kanze@gabi-soft.de
Date: 2000/07/04 Raw View

Martin Sebor <marts@att.net> writes:

|>  kanze@gabi-soft.de wrote:

|>  ....
|>  > Section 17.4.4.1, paragraph 1: "A C++ header may include other C++
|>  > headers."  I think this is a difference with respect to C; although=
 the
|>  > C standard doesn't explicitly forbid including other headers, it do=
esn't
|>  > authorize the header to define symbols other than those generally
|>  > reserved or those "listed in its associated subclause".

|>  > This raises an interesting question.  Is the following program requ=
ired
|>  > to work?

|>  >     #define NDEBUG
|>  >     #include <cassert>
|>  >     #undef NDEBUG
|>  >     #include <iostream>

|>  >     int
|>  >     main()
|>  >     {
|>  >         assert( 0 =3D=3D 1 ) ;
|>  >         std::cout << "works\n" ;
|>  >         return 0 ;
|>  >     }

|>  > If <iostream> includes <cassert>, it won't.

|>  I think whether it works or not will probably depend on the quality o=
f
|>  implementation.

In practice, I think it will generally work, because the implementations
of <iostream> don't include cassert.  Whether it is required to work,
however, depends on the interpretation of the quoted phrase.  If
<cassert> is a C++ header, in the sense of the quoted phrase (and I
think it is), then it is not guaranteed to work.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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              ]

Author: John_Maddock@compuserve.com (John Maddock)
Date: 2000/06/25 Raw View

OK here is at least some of the issues that have bitten me:

1) Run time problems: these are the hardest of all to track down, and
may take the form of either compiler or library bugs, some of those
that have hit me include:
* buggy destructor cleanup on thrown exception (some versions of the
Borland compilers)
* Bad assembly generation when combining certain headers
(gcc2.95/mingw32 port).
* Apparently buggy std::getline implementations (C++ Builder 5 and
VC6).

2) compile time problems (and I don't mean features that are
documented as not supported):
* Internal compiler errors (mostly VC6)
* Template friend functions (most current compilers)
* Wide character support - I don't think I've yet found a compiler
that even bothers to define WCHAR_MAX, and that's just the start....
* non-standard <cheader> versions of the C standard headers - frankly
these are vertually unuseable (declarations not in namespace std,
headers just plain missing, declarations as macros instead of
inlines...)

3) unsupport features:
* export (obviously)
* template friends
* Koenig lookup (can't find associated operators without it)
* partial ordering of template functions (just try overloading
template functions without this)
* covariant returns
* etc etc etc....

Hope this helps... :-)


John Maddock
http://ourworld.compuserve.com/homepages/John_Maddock/

---
[ 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              ]

Author: "David Abrahams" <abrahams@mediaone.net>
Date: 2000/06/25 Raw View

<llewelly@brownie.frogger.foobar.snot> wrote in message
news:m2snu5assk.fsf@brownie.frogger.foobar.snot...
> "David Abrahams" <abrahams@mediaone.net> writes:

> I have not used msvc++ (well, not in over 2 years), but I would claim
>   that for most modern c++ compilers, the bugs cannot be easily
>   summarized. In general, one cannot simply say 'Compiler X does not
>   support feature Y'. (If one does, one often finds out one was thinking
>   of compiler X as it was a few years ago.)

You have captured my point exactly. Msvc++ just happens to be (much) worse
in this regard than the other compilers I use. I was really trying to
express frustration with this conformance question. It's a good question,
but answering it usefully without dealing with the bugs issue is probably
hopeless. That's probably not as true on the library side, of course.

-Dave

P.S. for balance, here's a GCC 2.95.2 bug which bites me a lot: it gets
confused about Koenig lookup when friend functions are written inline in a
namespace:

namespace foo {
   // won't work unless addable is in the global namespace.
   template <class T>
   struct addable
   {
      friend T operator+(T x, T y) { return x += y; }
   };

   struct Long : addable<Long>
   {
      Long& operator+=(const Long& rhs);
      long value;
   };
}

---
[ 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              ]

Author: kanze@gabi-soft.de
Date: 2000/06/26 Raw View

James Kuyper <kuyper@wizard.net> writes:

|>  If portability to non-standard implementations is an issue, you must
|>  also ban <iostream.h>. It worked in many different incompatible ways
|>  under different pre-standard implementations. Your only choice, if
|>  your code must be compatible with non-standard implementations, is
|>  to define your own string library, that doesn't use reserved names,
|>  and package it with your code.

Not in the real world.  There were (and certainly still are) variations
in <iostream.h>, but there was a sufficiently large subset that was
pretty universel, and could be used without problem.

There's an old saying, which says that the only portable program is one
that has been ported.  Strictly speaking, no program can be guaranteed
portable to a machine to which it hasn't been ported.  Even if it is
100% standard conform, it might just trigger some exotic error in a
"conforming" compiler.  Normally, writing conforming code is an
effective means of increasing the probability that the program will
port, not of guaranteeing it 100%.  With C++ today, however, writing
100% conforming code is almost a way of guaranteeing that your program
won't port.  In particular, a program which uses <iostream.h> will have
a higher probability of being portable to the widest range of compilers.

|>  > |>  My issues, or at least the ones which occur to me now, are

|>  > |>  - Inability to catch exceptions thrown by initialisers to a
|>  > |>    constructor.

|>  > There's no way to do this in portable code.

|>  See section 15p3, describing and demonstrating the use
|>  function-try-blocks in a constructor, to catch exceptions generated
|>  by the initializers. That code is supposed to be portable to any
|>  conforming implementation. Since this thread is about conformance
|>  issues, that is an entirely legitimate complaint, even (or perhaps
|>  especially) if this is an extremely common form of non-conformance.

OK.  I've lost the initial context, but yes, it is a bother not to be
able to do it (portably, at least), and the standard says we *should* be
able to do it.  If that was the context, then I agree.

    [...]
|>  You're missing the point. Look at the title of this thread. The
|>  overloaded abs() function is supposed to be portably available. The
|>  fact that it isn't is a legitimate conformance issue.

I think I was missing the point.  I missed the initial posting in the
thread, and since the posting talked about portability, I proposed
portability solutions.  You're perfectly right that we shouldn't need
these solutions, and given from what I've since seen of the thread, I
understand the posters point.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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              ]

Author: kanze@gabi-soft.de
Date: 2000/06/26 Raw View

cmd@gmrc.gecm.com (Chris Dearlove) writes:

|>  kanze@gabi-soft.de wrote:
|>  : cmd@gmrc.gecm.com (Chris Dearlove) writes:

|>  : If portability is one of the project requirements, such
|>  : guidelines should ban <iostream> (and a host of other new features).

|>  This I think misses the point of this thread, which is that if more
|>  compilers were more standard compliant then we could Do The Right
|>  Thing (which banning <iostream> is definitely not) and be portable.

|>  : |>  - Inability to catch exceptions thrown by initialisers to a
|>  : |>    constructor.

|>  : There's no way to do this in portable code.

|>  But there is in the standard (reference not to hand, Stroustrup 3rd e=
d.
|>  14.4.6.1) and that is the point of his thread.

Agreed.  I hadn't seen the beginning of the thread.  In fact, the fact
that I still have to use <iostream.h> and above all <strstream.h> in
portable code is probably what I miss most with regards to standards
conformance.

|>  : |>  - Polluted headers (the principal problem being that of acciden=
tally
|>  : |>    omitting a standard required header because the code still
|>  : |>    compiles but won't elsewhere of course).

|>  : The standard won't help you here.  A standard header is allowed
|>  (but not : required) to include any other standard headers it wants.

|>  Have you got a standard reference for this. I believe this is not the
|>  case in C, is C++ that different?

Section 17.4.4.1, paragraph 1: "A C++ header may include other C++
headers."  I think this is a difference with respect to C; although the
C standard doesn't explicitly forbid including other headers, it doesn't
authorize the header to define symbols other than those generally
reserved or those "listed in its associated subclause".

This raises an interesting question.  Is the following program required
to work?

    #define NDEBUG
    #include <cassert>
    #undef NDEBUG
    #include <iostream>

    int
    main()
    {
        assert( 0 =3D=3D 1 ) ;
        std::cout << "works\n" ;
        return 0 ;
    }

If <iostream> includes <cassert>, it won't.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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              ]

Author: kanze@gabi-soft.de
Date: 2000/06/26 Raw View

"Sam Lindley" <sam@redsnapper.net> writes:

|>  <kanze@gabi-soft.de> wrote in message news:86g0q5q4dq.fsf@gabi-soft.d=
e...
|>  "Sebastian Moleski" <sebmol@gmx.net> writes:
|>  [...]
|>  > I know.  On the other hand, standard conforming code doesn't work w=
ith
|>  > many compilers, starting with g++.  You have the choice: standard
|>  > conforming, or portable working code.

|>  > In the end, today, the easiest way to write portable code is just t=
o
|>  > choose a single, retargeted compiler, and write to it.  The one I'm
|>  > familiar with is g++ 2.95.2: very strong in templates, but decidely
|>  > mixed in the library.  So my code contains <strstream.h> but
|>  > <vector>:-).  I'd obviously prefer everything standard, but not as =
much
|>  > as I prefer working code.

|>  Why not use SGIs implementation?
|>  (http://www.sgi.com/Technology/STL/standard_library.html)

Because I have other things to do than building up a development system
by hand.  I telecharged g++ 2.95.2 and installed it in under 5 minutes
of my time.  I know that the full system has been tested by Cygnus, and
is fully supported by a top rate team.  I know that if I have a problem,
I don't have to try and figure out if it is the library, or the compiler
-- there is exactly one address to send bug reports to.

I'm certain that some time in the future (near or far, I don't know),
g++ will integrate a new library.  At that point, I presume that there
will be a number of pre-releases, and bug fixes.  And that only
following that experimental phase, the new version will appear as the
"standard" release.  And then, I'll download it, and use it.

Until then, I'd rather deal with old libraries than with instability.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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              ]

Author: James Kuyper <kuyper@wizard.net>
Date: 2000/06/26 Raw View

kanze@gabi-soft.de wrote:
>
> comeau@panix.com (Greg Comeau) writes:
....
> Today, there is a greater probability that your code will work with
> different compilers if you include <iostream.h> than if you include
> <iostream>.  The opposite should be true, but in practice, it's not.

In the context of a discussion titled "... Conformance Issues", "should
be" is more relevant than "in practice".

---
[ 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              ]

Author: Martin Sebor <marts@att.net>
Date: 2000/06/26 Raw View

kanze@gabi-soft.de wrote:
>=20
....
> Section 17.4.4.1, paragraph 1: "A C++ header may include other C++
> headers."  I think this is a difference with respect to C; although the
> C standard doesn't explicitly forbid including other headers, it doesn'=
t
> authorize the header to define symbols other than those generally
> reserved or those "listed in its associated subclause".
>=20
> This raises an interesting question.  Is the following program required
> to work?
>=20
>     #define NDEBUG
>     #include <cassert>
>     #undef NDEBUG
>     #include <iostream>
>=20
>     int
>     main()
>     {
>         assert( 0 =3D=3D 1 ) ;
>         std::cout << "works\n" ;
>         return 0 ;
>     }
>=20
> If <iostream> includes <cassert>, it won't.

I think whether it works or not will probably depend on the quality of
implementation. While the footnote in 17.4.2.1 says that the behavior of
<assert.h> and <cassert> wrt. to NDEBUG is the same as in the Standard C
library, I believe the C++ standard should specifically address this
issue.

Martin


>=20
> --
> James Kanze                               mailto:kanze@gabi-soft.de
> Conseils en informatique orient=E9e objet/
>                    Beratung in objektorientierter Datenverarbeitung
> Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
>=20
> ---
> [ 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             =
 ]

---
[ 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              ]

Author: Martin Sebor <marts@att.net>
Date: 2000/06/26 Raw View

kanze@gabi-soft.de wrote:
>
> Jim Hyslop <jim.hyslop@leitch.com> writes:
>
> |>  F'rinstance, someone mentioned the scope of a variable declared in a
> |>  for-init-statement - is that really important, or just an annoyance?
> |>  IMO it's an annoyance, because it's something you can work around
> |>  quite easily.
>
> Right.  In practice, in my code, if it works with the new scope, it will
> work with the old, since my functions are all extremely small, and I
> can't think of any where I have multiple for loops.

While it may be just an annoyance to some, it is an excellent example
where a modern compiler still doesn't follow a simple rule required by
the standard. Many (most?) compilers do allow the old rule for backwards
compatibility but provide a switch when a strict conformance is required
(or the other way around). MSVC also has an option that lets you turn on
the new rule. Unfortunately flipping it disables otherwise useful
extensions that even Microsoft's own code depends on, so for many it's
not a viable alternative. What it means in practice is that it's
unnecessarily hard to port conforming code to that compiler (even if the
workaround is as simple as -D"for=if (0) ; else for").

Martin

---
[ 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              ]

Author: herwin@gmu.edu (Harry Erwin)
Date: 2000/06/27 Raw View

<llewelly@brownie.frogger.foobar.snot> wrote:

>
> The fact that almost no-one has time to become familiar with more than
>   one compiler is an additional problem.
>

When you teach, you are forced to gain that familiarity. I require all
programs to eventually compile under gcc 2.9.5 on the school UNIX
cluster, but the students still insist on developing the code elsewhere
(for excellent reasons) and then come to me for help. To retain my
sanity--I have to keep multiple compilers around anyway--I simply give a
red card to certain compilers (e.g., MSVC++ 6.0) whose deficiencies are
so numerous that I don't want to go there.

--
Harry Erwin, PhD, <herwin@gmu.edu>, Bat Researcher, Senior SW Analyst
and Security Engineer, and Adjunct Professor of Computer Science,
George Mason University.

---
[ 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              ]

Author: Mitch Adler <mitch@intelligentparadigm.com>
Date: 2000/06/28 Raw View

In article <20000623.17525046@jb-11116.stardiv.de>,
joerg.barfurth@attglobal.net wrote:

>The error message is misleading, but you might try this without
>'template<>' on the member definition.
>What does yout compiler say then ?

Quite!

It works without the template<> prefixes.

OK, so I again refine my report:

Some compilers don't support template<> when used for out of line
template definitions.

Phew.

Thanks J   rg, for your persistence in showing me the true source of my
headache.

Mitch

------------------------------------------------------------------------
Mitch Adler                   "There are people in the world who
Intelligent Paradigm           do not love their fellow human beings,
Mitch@mitch.org                and I hate people like that."
Mitch@IntelligentParadigm.com      - Tom Lehrer

---
[ 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              ]

Author: James Kuyper <kuyper@wizard.net>
Date: 2000/06/20 Raw View

Sebastian Moleski wrote:
....
> It might work but it's not standard. If the following code compiles,
> the compiler cannot be called compliant:
>
> #include <iostream.h>
>
> int main() {
>     cout << "Hello, World!" << endl;
> }

False. A conforming implementation is almost never required to reject
any code. The standard often requires at least one diagnostic. However,
the only case I can remember offhand where it prohibits successful
translation is for code that contains a #error directive that survives
conditional compilation.

---
[ 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              ]

Author: "David Abrahams" <abrahams@mediaone.net>
Date: 2000/06/20 Raw View

"Scott Meyers" <smeyers@aristeia.com> wrote in message
news:MPG.13b75ee032fae4f39896fd@news.supernews.com...

> MSVC offers member templates, though my understanding is that they have
> their limitations.

Ugh! Let me just go out on a limb here and say that the non-conformance
issues with MSVC are too gnarly and numerous to list properly. It isn't so
much that any one particular feature is missing (well, partial
specialization is a big one), but that there are so many $&#*! bugs in the
compiler it's almost impossible to predict what will work in any given
situation. Often I don't find a way to name these bugs because they aren't
easily reduced to a simple test case - I just find a workaround and move on.
If you're really going to deal with non-conformance, you *have to* deal with
out-and-out compiler bugs, which are much harder to deal with than something
which is *doucumented* somewhere as non-conforming in a particular way.

So what if MSVC supports member templates if it doesn't support them fully?
Eventually you find out that you can't write object->member_function<Type>()
*after* you've already checked your code with a more competent compiler!
Eventually you find out that they only work if you declare them in the class
body. Maybe it's better to just assume they don't work!

<rant off>

Actually, I use member templates in MSVC, but it's incredibly capricious and
frustrating ;)

-Dave

---
[ 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              ]

Author: Alain Miniussi <alainm@cup.hp.com>
Date: 2000/06/21 Raw View

Sebastian Moleski wrote:
>
> <kanze@gabi-soft.de>:
> | "Garth A. Dickie" <Garth_Dickie@avid.com> writes:
> |>  1. New-style header names, with the standard library in namespace
> std.
> |
> |>  When I write code which is intended to be portable between
> |>  compilers, and I want to use the C++ standard library, I would
> like
> |>  to use the new style header names. This is particularly important
> |>  for <iostream> and <sstream>, where the old header names provide
> |>  different functionality.
> |>  When I have to deal with a mixture of behavior in the compilers, I
> end
> |>  up with a mess of #ifdef stuff, and no namespaces.
> |
> |I just use the old names: <iostream.h>.  I've yet to encounter a
> |compiler where this didn't work.
>
> It might work but it's not standard. If the following code compiles,
> the compiler cannot be called compliant:
>
> #include <iostream.h>
>
> int main() {
>     cout << "Hello, World!" << endl;
> }

Why ? I don't think the standard does specify what's in <iostream.h>
anyway.

> |>  2. Non-inline template definitions.
> |
> |>  I want to have the linker instantiate templates whose
> implementation
> |>  is separate from their declaration.  This is the only way to
> |>  break #include dependencies. The code which makes use of a
> template
> |>  should not have to include all of the interfaces used by the
> |>  implementation of the template.
> |
> |>  Of the compilers with which I have experience, SGI's compiler does
> this,
> |>  while the Metrowerks and MSVC++ compilers do not.
> |
> | And I'm willing to bet that in this regard, it's VC++ which is
> conform,
> | and NOT SGI.
>
> Why? Do you think it is right that compilers require template
> definitions to be in header files?

He did not wrote "right" but "conform". And it is not required by the
compiler (that sometime provide a non conformant way to avoid that)
but by the standard.

Alain

---
[ 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              ]

Author: Steve Clamage <stephen.clamage@sun.com>
Date: 2000/06/21 Raw View

Sebastian Moleski wrote:
>
> <kanze@gabi-soft.de>:
> |
> |I just use the old names: <iostream.h>.  I've yet to encounter a
> |compiler where this didn't work.
>
> It might work but it's not standard. If the following code compiles,
> the compiler cannot be called compliant:
>
> #include <iostream.h>
>
> int main() {
>     cout << "Hello, World!" << endl;
> }

Not so.  The standard says a compiler must accept particular header
spellings. It does not say a compiler cannot accept any others.
The standard does not mention a header spelled <iostream.h>,
so an implementation can choose to accept such a header without
violating any provision of the standard.

The use of <iostream.h> is not fully portable, however, because
1. No compiler is required by the standard to supply such a header, and
2. Among compilers that provide such a header, the meaning varies.
With some compilers, you get "classic" rather than standard iostreams.
With others, you get standard iostreams, but with the declarations
available in the global namespace. With Sun C++, you can get either
behavior, depending on a command-line option.

--
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              ]

Author: Steve Clamage <stephen.clamage@sun.com>
Date: 2000/06/21 Raw View

James Kuyper wrote:
>
>
> ... A conforming implementation is almost never required to reject
> any code. The standard often requires at least one diagnostic.

Right.

> However,
> the only case I can remember offhand where it prohibits successful
> translation is for code that contains a #error directive that survives
> conditional compilation.

Not even then. The only requirement on the #error directive is that
it result in a diagnostic message. The directive also renders the
program ill-formed, which means the standard places no further
requirements on the implemetation.

An implementation could choose to abort immediately, to continue
translating, or even to produce an object file.

--
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              ]

Author: Jim Hyslop <jim.hyslop@leitch.com>
Date: 2000/06/22 Raw View

Well, I already replied to this via RemarQ but that post doesn't seem to
have made it through for some reason.  So this may be a duplicate post,
sorry about that.

In any case:
In article <mitch-3E4D27.12400619062000@news.brainstorm.net>,
  Mitch Adler <mitch@intelligentparadigm.com> wrote:
> I trust that that Herb will independently verify any claims of
> non-conformance through direct testing and not just publish claims
> posted here, as many of these claims can be out of date from the
> current compiler state.
Speaking as one of those participating in the article, I can attest that
this newsgroup thread is only one aspect of the article Herb will
publish.  Each compiler will be evaluated independently by several
people, and their comments will be reviewed by an expert panel.

The purpose of this thread is not necessarily to enumerate all known
non-conformance issues (particularly of a well-known compiler) but
rather to find out from the front-line programmer, who has to work with
these tools day in and day out, exactly what is important as far as
standards conformance goes.

F'rinstance, someone mentioned the scope of a variable declared in a
for-init-statement - is that really important, or just an annoyance?
IMO it's an annoyance, because it's something you can work around quite
easily.

--
Jim
I ignore all email from recruitment agencies.  Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.

Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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              ]

Author: Thomas Engelmeier <moof4e4@my-deja.com>
Date: 2000/06/22 Raw View

> 2. Non-inline template definitions.
>
> I want to have the linker instantiate templates whose
implementation
> is separate from their declaration.  This is the only way to
> break #include dependencies. The code which makes use of a
template
> should not have to include all of the interfaces used by the
> implementation of the template.
>
> Of the compilers with which I have experience, SGI's compiler
does this,

AND WILL BREAK SOME DAY LINKING IT...
reported three times, was "Not reproducible" in tiny testcases, sent
of..
Turning off precompiled headers helps..

> while the Metrowerks and MSVC++ compilers do not.

Why not?

Split it up into Template declaration (in  a header), the
implemantation (in a source) and use explicit template
instantiation (in that source):

// this will generate all code for the Template TSmallInput<T, I>:

template class TSmallInput<int, CAdapter::kInt>;

Works on MIPS Pro xxx and Metrowerks CWP 4.x / 5.
AFAIR I used explicit instantiation also on VC++.

Have fun,
              Tom_E





Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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              ]

Author: Niels Dekker <ndekker@REMOVETHISnki.nl>
Date: 2000/06/22 Raw View

Herb Sutter wrote:
>   What compiler/library conformance weaknesses matter to you in
>   real-world production code?

Two wishes from me:

1. Better support for reference-to-C-style-array

In combination with templates, reference-to-C-style-arrays often
get rejected by compilers that we use at my work. The following
example will not compile for MSVC++ 5.0 and 6.0 (both SP 3):

  template<typename ELEMENT_TYPE, unsigned uNumElements>
  unsigned GetNumElements(
    const ELEMENT_TYPE (&)[uNumElements])  // MSVC++ compiler error
  {
    return uNumElements;
  }

The following use of a reference-to-C-style-array does no longer
compile with MSVC++ 6.0 (it did with MSVC++ 5.0):

  template<unsigned uNumElements>
  class TCMyIntegerArray
  {
    typedef int INT_ARRAY[uNumElements];
    INT_ARRAY m_aiData;
  public:
    INT_ARRAY & GetData(void)  // MSVC++ 6.0 compiler error
    {
      return m_aiData;
    }
  };

So now I always use a pointer-to-the-first-array-element even if a
reference-to-C-style-array would have been more appropriate.
Result: less strict type-checking, less solid coding  :-(

2. Better support for alternative tokens of logical operators, like
"and", "or", and "not"

I still use &&, || and !, but personally I think "and", "or", and
"not" are much more readable. Especially if these tokens would have
been given syntax-highlighting in the IDE! Also we sometimes have to
convert Delphi/Pascal code to C++ and vise versa. This would have been
easier with the support of "and", "or", and "not", because these
tokens mean the same in both languages.

I'm surprised that even Borland C++ does not support "and", "or", and
"not", because in other aspects they made their C++Builder look very
simular to their Delphi/Pascal builder.

Regards from Amsterdam,

  Niels Dekker
  ndekker "at" nki "dot" nl

---
[ 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              ]

Author: Tom <the_wid@my-deja.com>
Date: 2000/06/22 Raw View

In article <jBA35.77033$nl3.267095@typhoon.ne.mediaone.net>,
  "David Abrahams" <abrahams@mediaone.net> wrote:
[SNIP]
> So what if MSVC supports member templates if it doesn't support them
fully?
> Eventually you find out that you can't write object-
>member_function<Type>()
> *after* you've already checked your code with a more competent
compiler!

object->member_function<Type>();

Are you sure that's correct syntax? In my Stroustrup (section 17.5.3.3)
this line appears:
"cout << b.template to_string<char,char_traits<char>,allocator<char> >()
<< '\n';"
along with a comment about this being an elaborate and rare syntax. It
references C.13.6, but I searched this section in vain for a
description or explanation of this syntax. Josuttis' "The Standard C++
Library" has similar in its bitset section (just before the end of 10.4)

Can someone shed some light on this please? Is this the standard way of
explicitly specifying template arguments for member template functions?

Tom

Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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              ]

Author: James Kuyper <kuyper@wizard.net>
Date: 2000/06/22 Raw View

Steve Clamage wrote:
>
> James Kuyper wrote:
> >
> >
> > ... A conforming implementation is almost never required to reject
> > any code. The standard often requires at least one diagnostic.
>
> Right.
>
> > However,
> > the only case I can remember offhand where it prohibits successful
> > translation is for code that contains a #error directive that survives
> > conditional compilation.
>
> Not even then. The only requirement on the #error directive is that
> it result in a diagnostic message. The directive also renders the
> program ill-formed, which means the standard places no further
> requirements on the implemetation.
>
> An implementation could choose to abort immediately, to continue
> translating, or even to produce an object file.

My apologies. The last time I said "the standard doesn't require the
rejection of any program", I was refuted with a reference to #error. The
problem is, that was on comp.std.c, not comp.std.c++.

Section 4 p4 of the C99 standard says "The implementation shall not
successfully translate a preprocessing translation unit containing a
#error preprocessing directive unless it is part of a group skipped by
conditional inclusion." However, you're right - the C++98 standard
contains no such wording.

I know someone out there was keeping a list of the differences between
the languages. Does this need to be added to your list?

---
[ 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              ]

Author: "Jim.Hyslop" <Jim.Hyslop@Leitch.com>
Date: 2000/06/22 Raw View

> In article <6oliksk6j5le2mhvqriabfqfr5eld15n4k@4ax.com>,
>   Herb Sutter <hsutter@peerdirect.com> wrote:
> [snip]
> >   What compiler/library conformance weaknesses matter to you in
> >   real-world production code?
> Inconsistent adherence to the standard.
>
> I recently had to re-work a section of code that used a dynamic_cast to
> downcast a reference (not my design!!).  I found that the following
> program:
>
> #include <iostream>
> #include <typeinfo>
>
> class base
> {
> public:
>    virtual ~base() {}
> };
>
> class derived : public base
> {
> };
>
> int main()
> {
>    try {
>       base b;
>       derived &d=dynamic_cast<derived &>(b);
>    }
>    catch (std::bad_cast &)
>    {
>       std::cout << "Good" << std::endl;
>    }
>    catch (...)
>    {
>       std::cout << "OH NO!!" << std::endl;
>    }
>    return 0; // BTW, this is a minor annoyance
> }
>
> would output "OH NO!!" instead of "Good".
>
> VC throws a "::bad_cast" class, which is defined in typeinfo.h  Even
> using the compiler option which forces ANSI compliance (which, by the
> way, does not allow any standard headers to compile) results in
> ::bad_cast being thrown.
>
> To make matters worse, typeinfo.h is incompatible with *any* standard
> header, so I couldn't even insert a conditional section to catch
> ::bad_cast on MSVC, and std::bad_cast on other platforms, because I was
> using standard headers as well.
>
> --
> Jim
> I ignore all email from recruitment agencies.  Except that
> I reserve the right to send rude, nasty replies to recruiters.
> Please do not send me email with questions - post
> here.
>

---
[ 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              ]