In article <32bab444.13674401@news.atl.mindspring.com> abell@atl.mindspring.com (Andrew C. Bell) writes:
>Volker Apelt <va@org.chemie.uni-frankfurt.de> wrote:
>>I try to collect a checklist of supported language features of
>>current c++ compilers. The goal is to have one document from which one
>>can easily find out how close each compiler follows the "draft standard"
>>and the "ARM".
>
>What might be even more useful is code to test the compliance of
>various compilers, since then it could be used on newer versions of
>said compilers.

Both seem useful things to have around.

>For example, I created the following code for testing
>templates (though I'm not sure I have the terminology right.)  For
>Visual C++ 4.2, I get a result of:
>
>Compiler does not support explicit template function specialization.
>Compiler supports explicit template specialization.
>
>#include <iostream.h>
>
>template <class Type>
>class Foo
>{
> public:
>  const char *Out() const { return "does not support"; }
>};
>
>const char *
>Foo<int>::Out() const
>{
> return "supports";
>}
>
>class Foo<float>
>{
> public:
>  const char *Out() const { return "supports"; }
>};
>
>main()
>{
> Foo<int> myIntFoo;
> cout << "Compiler " << myIntFoo.Out()
>  << " template function specialization.\n";
> Foo<float> myFloatFoo;
> cout << "Compiler " << myFloatFoo.Out() <<
>  " template specialization.\n";
> return 0;
>}

Your code compiles with Comeau C++ 4.0 Pre-release ok and I'm
sure on others too.  This is obviously not an exhaustive test,
but I would be very interested to see something in the PD materialize
which is a collection of stuff like this.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
 ***WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421
---
[ 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
]

I try to collect a checklist of supported language features of
current c++ compilers. The goal is to have one document from which one
can easily find out how close each compiler follows the "draft standard"
and the "ARM".

Below is my current incomplete  checklist. It contains differences in the
implementaion of templates, newer keywords, rtti and some other
features which have changed since the ARM.

Could you have a look at and make some sugestions how to improve it?
Am I missing some major incompatibilities?

Thanks

BTW, if there already is such a list, please let me know.
(and feel free to fix or rephrase any formulation, I'm not a nativ speaker.)

------------------------------------------------------------------------
Compiler i have tried.
IBM VisualAge C++ VAC     3.0
GNU C++           GCC     v2.7.2

------------------------------------------------------------------------
[ARM COMPLIANT]
 yes
 no

[TEMPLATES]
[compiles HP-STL without errors/patches]
 yes
 no
[nested templates]
 yes(gcc fragil),(vac)
 no
[static template members]
 yes
 no
[initialization of static template members]
 yes
 no
[auto instantiation of templates through compiler]
 yes(gcc needs special cpp-keywords or fat obj files)
 yes(vac keeps decl in a cache, cache needs manual cleanup)
[manual instantiation possible with _standard_ syntax]
 yes(gcc)
 non-std-syntax(vac)

[rtti]
 yes(gcc with compiler-flag)
 no(vac)

[scope of variables defined in for(;;)]
 local to for-block(standard)(gcc with warning)
 is local to enclosing block(ARM)(vac)

[lifetime of temporaries]
 standard(at next;)(gcc)
 as soon as possible, before terminating;(==too early) (gcc<6.x)
 at the end of enclosing curly braces/end of block(==too late)(vac??)

[NEW KEYWORDS]
[cast operators]
 complete(gcc)
 reserves keyword
 no(vac)
[bool]
 is a builtin(gcc),
 reserves keyword,
 class/macro/typedef(VAC,int)
[mutable]
 yes(gcc)
 reserves keyword,
 no(vac)
[explicit]
 yes(gcc),
 reserves keyword,
 no(vac)
[typename]
 yes,
 reserves keyword(gcc,no-op),
 no(vac)
[namespace]
 yes(gcc, partly),
 reserves keyword
 no(vac)

[EXCEPTIONS]
 yes(gcc, only for exact matches and without optimization)
 yes(vac)

[RETURN VALUE OPTIMIZATION]
 standard(automatic)
 only with nonstandard keyword(gcc)

[STD STREAM LIBRARY]
[redirecting streams]
 rdbuf (gcc)
 ostream_with_assign(vac)


---
Volker Apelt                              Group of Prof. Dr. Ch. Griesinger
                                          Johann Wolfgang Goethe Universitaet
                                          Frankfurt am Main (Germany)
va@krypton.org.chemie.uni-frankfurt.de
---
[ 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                             ]

Volker Apelt wrote:
>
> I try to collect a checklist of supported language features of
> current c++ compilers. The goal is to have one document from which one
> can easily find out how close each compiler follows the "draft standard"
> and the "ARM".
>
> Below is my current incomplete  checklist. It contains differences in the
> implementaion of templates, newer keywords, rtti and some other
> features which have changed since the ARM.
>
> Could you have a look at and make some sugestions how to improve it?
> Am I missing some major incompatibilities?
>

It's an interesting list, but unfortunately I'm not always able to
figure
out which answer belongs to which compiler (see comments below).
If you correct this problem, the list will be a very good thing
(I'm assuming the contents are correct). Maybe you should upload it to
an anonymous ftp server or put it to www.

> Thanks
>
> BTW, if there already is such a list, please let me know.
> (and feel free to fix or rephrase any formulation, I'm not a nativ speaker.)
>
> ------------------------------------------------------------------------
> Compiler i have tried.
> IBM VisualAge C++ VAC     3.0
> GNU C++           GCC     v2.7.2
>
>

Clear up to here.

> ------------------------------------------------------------------------
> [ARM COMPLIANT]
>         yes
>         no

>From the above I conclude, the first line is for vac
(mentioned above in the compiler list in the first line),
the second line is for gcc (mentioned above in the second line),
so: vac: yes, gcc: no.
Is this the correct interpretation?

BTW, what did you check? In which way is the second one
non-ARM-compliant?

>
> [TEMPLATES]
> [compiles HP-STL without errors/patches]
>         yes
>         no
> [nested templates]
>         yes(gcc fragil),(vac)
>         no

Oops. Now gcc *and* vac in the first line? And what does the
second refer to?

> [static template members]
>         yes
>         no
> [initialization of static template members]
>         yes
>         no
> [auto instantiation of templates through compiler]
>         yes(gcc needs special cpp-keywords or fat obj files)
>         yes(vac keeps decl in a cache, cache needs manual cleanup)

Ah, so gcc is first, vac is second? So does this apply to the items
above as well?
BTW, what do you mean with "fat obj files"?

> [manual instantiation possible with _standard_ syntax]
>         yes(gcc)
>         non-std-syntax(vac)
>
> [rtti]
>         yes(gcc with compiler-flag)
>         no(vac)
>
> [scope of variables defined in for(;;)]
>         local to for-block(standard)(gcc with warning)
>         is local to enclosing block(ARM)(vac)
>
> [lifetime of temporaries]
>         standard(at next;)(gcc)
>         as soon as possible, before terminating;(==too early) (gcc<6.x)
>         at the end of enclosing curly braces/end of block(==too late)(vac??)

rtti, variable scope and lifetime of temporaries should not be in the
templates
main section, as they have nothing to do with templates.

>
> [NEW KEYWORDS]
> [cast operators]
>         complete(gcc)
>         reserves keyword
>         no(vac)

is the second line to gcc or to vac?

> [bool]
>         is a builtin(gcc),
>         reserves keyword,
>         class/macro/typedef(VAC,int)
> [mutable]
>         yes(gcc)
>         reserves keyword,
>         no(vac)
> [explicit]
>         yes(gcc),
>         reserves keyword,
>         no(vac)
> [typename]
>         yes,
>         reserves keyword(gcc,no-op),
>         no(vac)
> [namespace]
>         yes(gcc, partly),
>         reserves keyword
>         no(vac)
>
> [EXCEPTIONS]
>         yes(gcc, only for exact matches and without optimization)
>         yes(vac)
>
> [RETURN VALUE OPTIMIZATION]
>         standard(automatic)
>         only with nonstandard keyword(gcc)

Oops, now gcc second? So again no conclusion for the order of the
first items...

>
> [STD STREAM LIBRARY]
> [redirecting streams]
>         rdbuf (gcc)
>         ostream_with_assign(vac)

Maybe a better formatting for the list would be like the following
(taking a part of your list where association to compiler is completely
possible,
comments to suggested format added in C++ style):

[manual instantiation possible]
  vac:                      // same order as in listing of compilers,
    non standard syntax     // first the compiler, then the statements
                            // with indentation, so you see immideatly
                            // what belongs to which compiler
  gcc:
    yes (standard syntax)

[rtti]
  vac:
    no
  gcc:
    yes (with compiler option)

With this formatting there would be no doubt which statement belongs to
which
compiler.

But again, the list itself is a good idea, and might be very helpful in
choosing a compiler.
Maybe there are some people out there who own other compilers and are
willing
to check those for the list, too.
---
[ 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
]

On 17 Dec 1996 09:38:11 PST, Christopher Eltschka
<celtschk@physik.tu-muenchen.de> wrote:
>Volker Apelt wrote:
>> I try to collect a checklist of supported language features of
>> current c++ compilers. The goal is to have one document from which one
>> can easily find out how close each compiler follows the "draft standard"
>> and the "ARM".

See also "Templates and Today's Compilers" in the current (Jan 97)
issue of C/C++ User's Journal.  It's very useful research, and
includes a summary table of 23 template-related bugs and weaknesses
found on some or all of 10 current compilers on various platforms.


---
Herb Sutter (herbs@cntc.com)

Current Network Technologies Corp.
3100 Ridgeway, Suite 42, Mississauga ON Canada L5L 5M5
Tel 416-805-9088  Fax 905-608-2611


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

Volker Apelt <va@org.chemie.uni-frankfurt.de> wrote:
>I try to collect a checklist of supported language features of
>current c++ compilers. The goal is to have one document from which one
>can easily find out how close each compiler follows the "draft standard"
>and the "ARM".

What might be even more useful is code to test the compliance of
various compilers, since then it could be used on newer versions of
said compilers.  For example, I created the following code for testing
templates (though I'm not sure I have the terminology right.)  For
Visual C++ 4.2, I get a result of:

Compiler does not support explicit template function specialization.
Compiler supports explicit template specialization.

#include <iostream.h>

template <class Type>
class Foo
{
 public:
  const char *Out() const { return "does not support"; }
};

const char *
Foo<int>::Out() const
{
 return "supports";
}

class Foo<float>
{
 public:
  const char *Out() const { return "supports"; }
};

main()
{
 Foo<int> myIntFoo;
 cout << "Compiler " << myIntFoo.Out()
  << " template function specialization.\n";
 Foo<float> myFloatFoo;
 cout << "Compiler " << myFloatFoo.Out() <<
  " template specialization.\n";
 return 0;
}

Andrew Bell
abell@mindspring.com
---
[ 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
]