Just to clarify further:

The vote on Fortran 95 was the FDIS, but it is not clear to me whether
the comments were provided as a formal part of the vote. The vote was
not unaminous, the French did explicitly vote NO, and the cause of the
no vote was not the document as provided by the committees, but the
formal title as provided by ITTF. In addition to the French objections,
the Japanese and UK comments objected to spelling Fortran as FORTRAN.

--

William B. Clodius  Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323     Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov
---
[ 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              ]

Jerry Coffin wrote:
> <snip>
>
> As I understand it, all they can do is vote "Yes" or "No" on accepting
> it as-is.  OTOH, if they reject it as-is, it can be sent back to
> committee for further technical changes to make it acceptable to the
> body as a whole.  A more likely scenario would be something similar to
> what happened in the ANSI process for C, in which an administrative
> oversight is found, and the committee has to handle that before the
> standard can be ratified.
> <snip>
> I pretty much do -- I can hardly imagine a country's representative
> voting against a standard that his country's representatives on the
> committee have already voted FOR.
> <snip>

As of at least two years ago the votes could include comments or
conditions, and they can have an impact on standardization. For example,
The Fortran 95 standard received uniformly yes votes, however, the
original English title (subtitle?), (something like "The Basic Fortran
Language Standard") was transliterated with little thought into the
French one, yielding something that was the equivalent of "The
Schoolchidren's Fortran Language Standard." The French aproval vote was
conditional on the French title being changed, which led to the English
title also being changed, (along with a few typos) which led to an
additonal six month+ delay in standardization. (Puplication occurred a
year after voting completed.)

--

William B. Clodius  Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323     Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov
---
[ 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 <MPG.fae63fd81546af989a16@news.rmi.net> jcoffin@taeus.com (Jerry Coffin) writes:
>In article <6i25uh$418@panix.com>, comeau@panix.com says...
>
>[ ... ]
>
>> >Since there IS no standard as yet, nothing could possibly comply with
>> >it.  Most compilers based on the EDG front-end ARE quite close to
>> >what's defined in the Final Draft of the standard, which seems likely
>> >to be accepted by the ISO, when (and if) they eventually get around to
>> >voting on it.  (For reasons completely unknown, there has been no vote
>> >even though the final draft was delivered to the authorities quite a
>> >while ago.)
>>
>> All more or less correct, except that outstanding ISO vote will not be
>> changing technical things.
>
>As I understand it, all they can do is vote "Yes" or "No" on accepting
>it as-is.  OTOH, if they reject it as-is, it can be sent back to
>committee for further technical changes to make it acceptable to the
>body as a whole.

The possibilities are probably many, however the reality is that
(as I recall hearing numerous times)  the national bodies are ok with it,
so when the ballots finally go out, it should be ok.

>A more likely scenario would be something similar to
>what happened in the ANSI process for C, in which an administrative
>oversight is found, and the committee has to handle that before the
>standard can be ratified.

Although the circumstances are not the same at all, I honestly think that
we are being held up by an administrative oversight of sorts.

>> Consider it a formality at this point (but an important one).
>
>I pretty much do -- I can hardly imagine a country's representative
>voting against a standard that his country's representatives on the
>committee have already voted FOR.

I could think of some reason why but it is definitely not expected here.
Note too though that some countries w/o reps will also be voting
(you may argue such votes weight, etc, but that's a seperate issue).

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

"Peter" == Peter Garner <peter.garner@toward.com> writes:
>
> Peter>   char * pc = new char [1000000000000000] ;

Bryan Bartone wrote:
> I think you are experiencing overflow in your declaration;
>
> Try:
 [bobbit]
>
> int main()
> {
>    set_new_handler(my_new_handler);
>    char* c = new char[999999999L];
>    cerr << "set_new_handler(my_new_handler); failed\n";
> }
>
> I ran this on a Intel-based Linux box using egcs 1.02.
> "my_new_handler" was called correctly.

set_new_handler() has been around for some time now, and is the
correct choice if you want to catch new() failures by means other
than exceptions.  It works quite well with new(nothrow).

FWIW, Microsoft VC++ 5.0 does not implement set_new_handler()
properly, and it ends up being little more than a no-op function;
you must use _set_new_handler() instead, which of course has a
different prototype and semantics.  We've had to add a wrapper
around it for our code (which is ported to several Unixes and
Lose/NT).  All of the other Unix compilers do it correctly.

-- David R. Tribble, david.tribble@noSPAM.central.beasys.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              ]

William Clodius <wclodius@lanl.gov> writes:

>Jerry Coffin wrote:
>> <snip>
>>
>> As I understand it, all they can do is vote "Yes" or "No" on accepting
>> it as-is.  OTOH, if they reject it as-is, it can be sent back to
>> committee for further technical changes to make it acceptable to the
>> body as a whole.  ...

>As of at least two years ago the votes could include comments or
>conditions, and they can have an impact on standardization.

Acceptance of a standard goes through several stages. Under current
ISO rules (the rules have changed several times over the last few
years), the technical committee issues one or more Commitee Drafts
(CD) for consideration. A CD goes out for a vote. The allowed votes
on a CD are "Yes", "Yes, with comments", and "No, with comments".

A "No" vote must be accompanied by comments which explain what
would be required to turn the "No" into a "Yes". Comments
accompanying a "Yes" vote are not binding, but it is expected
that the technical committe would take them seriously.

After a Final CD (FCD) passes the ISO member nation vote, the
technical committee can issue a Final Draft International
Standard (FDIS) which does not differ substantially from the FCD.
The FDIS goes out for a simple yes/no vote.  No comments are
allowed on an FDIS vote.

The FDIS vote is the next step in approving the C++ standard.

If the vote passes, the FDIS becomes the International Standard (IS).

If the vote fails, the technical committee reverts to CD
stage and tries again. Or gives up in despair. :-)

On 22 Apr 1998, Jerry Coffin wrote:

> In article <MDRLdUlulsRd-pn2-9M0Iu7OmOdqw@localhost>,
> peter.garner@toward.com says...
>
> >   Can anyone recommend a compiler that meets the
> > ANSI/ISO standard and runs under either OS/2 OR
> > Linux.
>
> Since there IS no standard as yet, nothing could possibly comply with

I thought ISO/IEC 14882 was the latest standard.

In response to the original poster's question, I think egcs might be your
best bet.  It is an experimental variant of gcc with a very fast
development cycle (see http://egcs.cygnus.com).  I am using the latest
snapshot of it under Linux (RedHat 5) and it is very close**.  It is
distributed with the latest versions of libstdc++, as well.

** The only parts that do not appear finished are namespace support (there
is partial support now) and the <sstream> header.  But development is
advancing very quickly! :)

cheers,
-bp
--
B. James Phillippe <bryan@terran.org>
Linux Software Engineer, WGT Inc.
http://earth.terran.org/~bryan
---
[ 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              ]

"B. James Phillippe" <bryan@terran.org> writes:

>On 22 Apr 1998, Jerry Coffin wrote:

>> >   Can anyone recommend a compiler that meets the ANSI/ISO standard ...
>>
>> Since there IS no standard as yet, nothing could possibly comply with

>I thought ISO/IEC 14882 was the latest standard.

It is the Final Draft International Standard, and has not yet
been been voted on by the ISO member nations. (For unexplained
reasons, ISO has not yet sent it out for a vote.)

In principle, ISO could decline to send the FDIS out for a vote
(if, for example, the draft did not meet ISO documentation
standards) or the vote could fail. We all ferverently hope
and expect neither of those things happen.

Assuming the vote passes, approval by ISO itself is needed (a
formality), after which the FDIS becomes the actual International
Standard.
--
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              ]

In article <MPG.fa7bc844690c3f09899e9@news.rmi.net> jcoffin@taeus.com (Jerry Coffin) writes:
>In article <MDRLdUlulsRd-pn2-9M0Iu7OmOdqw@localhost>,
>peter.garner@toward.com says...
>>   Can anyone recommend a compiler that meets the
>> ANSI/ISO standard and runs under either OS/2 OR
>> Linux.
>
>Since there IS no standard as yet, nothing could possibly comply with
>it.  Most compilers based on the EDG front-end ARE quite close to
>what's defined in the Final Draft of the standard, which seems likely
>to be accepted by the ISO, when (and if) they eventually get around to
>voting on it.  (For reasons completely unknown, there has been no vote
>even though the final draft was delivered to the authorities quite a
>while ago.)

All more or less correct, except that outstanding ISO vote will not be
changing technical things.  Consider it a formality at this point (but an
important one).  That part (the tech stuff) should be considered a done deal.
That said and done, vendors are moving forward in complying...
as you mentioned EDG-based compilers are close. Others are too.

>> (I do not mean runs under both, just runs under
>> any ONE of those OSes.)  I had the priviledge to work
>> with the HP aCC+ compiler, a TRUE ISO compiler.
>
>See above.  It was doubtless close to a more recent incarnation of the
>draft standard than the others you mention, but little more than that
>is possible.

Agreed.   Also, this notion of "TRUE" is somewhat pressing things,
as it always will.

>If memory serves, HP's compiler uses the EDG front-end,
>which is probably the closest to full compliance at the present time.

I don't believe HP uses the EDG front-end, but is still far along
from what I hear.

>If you want a similar compiler, you might want to try to find another
>that's based on the EDG front-end -- I believe Comeau Computing's is
>among these...

Indeed, Comeau C++ is available for LINUX/ELF.

- 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 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 <6i25uh$418@panix.com>, comeau@panix.com says...

[ ... ]

> >Since there IS no standard as yet, nothing could possibly comply with
> >it.  Most compilers based on the EDG front-end ARE quite close to
> >what's defined in the Final Draft of the standard, which seems likely
> >to be accepted by the ISO, when (and if) they eventually get around to
> >voting on it.  (For reasons completely unknown, there has been no vote
> >even though the final draft was delivered to the authorities quite a
> >while ago.)
>
> All more or less correct, except that outstanding ISO vote will not be
> changing technical things.

As I understand it, all they can do is vote "Yes" or "No" on accepting
it as-is.  OTOH, if they reject it as-is, it can be sent back to
committee for further technical changes to make it acceptable to the
body as a whole.  A more likely scenario would be something similar to
what happened in the ANSI process for C, in which an administrative
oversight is found, and the committee has to handle that before the
standard can be ratified.

> Consider it a formality at this point (but an important one).

I pretty much do -- I can hardly imagine a country's representative
voting against a standard that his country's representatives on the
committee have already voted FOR.

> >If memory serves, HP's compiler uses the EDG front-end,
> >which is probably the closest to full compliance at the present time.
>
> I don't believe HP uses the EDG front-end, but is still far along
> from what I hear.

Apparently true -- I'd already gotten an email from somebody else who
believes they do their own front-end.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
---
[ 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              ]

mejzlik@anxur.fi.muni.cz (Petr Mejzlik) writes:

> On my Linux machine, this statement prints "Virtual memory exceeded in `new'"
> (after reducing the constant to fit into long :-) when compiled by
> egcs 1.0.2. IMHO the only way how to force new to throw bad_alloc with
> egcs is to define your own error handler, like the following one:
> void myNewHandler() { throw bad_alloc(); }

With the current egcs, the operator new implementation in libgcc2.a
throws bad_alloc. Unfortunately, it doesn't get used with libc 5, as
the C library comes with its own (pre-2.8) implementation of
__builtin_new.

So another work-around is to switch to libc 6.

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              ]

Good Day All!

  Can anyone recommend a compiler that meets the
ANSI/ISO standard and runs under either OS/2 OR
Linux.  (I do not mean runs under both, just runs under
any ONE of those OSes.)  I had the priviledge to work
with the HP aCC+ compiler, a TRUE ISO compiler.
I cannot find such an animal for either OS/2 OR Linux.
Any ideas anyone?  egcs for Linux seems close, but
the libraries do not seem to be standard, e.g.
executing something like :

  char * pc = new char [1000000000000000] ;

simply places 0 in pc as opposed to throwing
'bad_alloc'.


Thanks

Peter
---
[ 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 <MDRLdUlulsRd-pn2-9M0Iu7OmOdqw@localhost>,
peter.garner@toward.com says...
> Good Day All!

Indeed it is...

>   Can anyone recommend a compiler that meets the
> ANSI/ISO standard and runs under either OS/2 OR
> Linux.

Since there IS no standard as yet, nothing could possibly comply with
it.  Most compilers based on the EDG front-end ARE quite close to
what's defined in the Final Draft of the standard, which seems likely
to be accepted by the ISO, when (and if) they eventually get around to
voting on it.  (For reasons completely unknown, there has been no vote
even though the final draft was delivered to the authorities quite a
while ago.)

> (I do not mean runs under both, just runs under
> any ONE of those OSes.)  I had the priviledge to work
> with the HP aCC+ compiler, a TRUE ISO compiler.

See above.  It was doubtless close to a more recent incarnation of the
draft standard than the others you mention, but little more than that
is possible.  If memory serves, HP's compiler uses the EDG front-end,
which is probably the closest to full compliance at the present time.

If you want a similar compiler, you might want to try to find another
that's based on the EDG front-end -- I believe Comeau Computing's is
among these...

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.


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

>>>>> "Peter" == Peter Garner <peter.garner@toward.com> writes:

Peter> Good Day All!
Peter>   Can anyone recommend a compiler that meets the
Peter> ANSI/ISO standard and runs under either OS/2 OR Linux.  (I do
Peter> not mean runs under both, just runs under any ONE of those
Peter> OSes.)  I had the priviledge to work with the HP aCC+ compiler,
Peter> a TRUE ISO compiler.  I cannot find such an animal for either
Peter> OS/2 OR Linux.  Any ideas anyone?  egcs for Linux seems close,
Peter> but the libraries do not seem to be standard, e.g.  executing
Peter> something like :

Peter>   char * pc = new char [1000000000000000] ;

I think you are experiencing overflow in your declaration;

Try:

#include <limits.h>
#include <iostream.h>
#include <defalloc.h>

void my_new_handler()
{
   cerr << "calling my_new_handler\n";
   exit(1);
}

int main()
{
   set_new_handler(my_new_handler);
   char* c = new char[999999999L];
   cerr << "set_new_handler(my_new_handler); failed\n";
}


I ran this on a Intel-based Linux box using egcs 1.02. "my_new_handler"
was called correctly.

Peter> simply places 0 in pc as opposed to throwing 'bad_alloc'.


Peter> 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Peter Garner wrote:

> Good Day All!
>
>   Can anyone recommend a compiler that meets the
> ANSI/ISO standard and runs under either OS/2 OR
> Linux.  (I do not mean runs under both, just runs under
> any ONE of those OSes.)  I had the priviledge to work
> with the HP aCC+ compiler, a TRUE ISO compiler.
> I cannot find such an animal for either OS/2 OR Linux.
> Any ideas anyone?  egcs for Linux seems close, but
> the libraries do not seem to be standard, e.g.
> executing something like :
>
>   char * pc = new char [1000000000000000] ;
>
> simply places 0 in pc as opposed to throwing
> 'bad_alloc'.
>

Few days ago this topic was in egcs mailing list.  The latest snapshots now
work right,  I you don't wont to reinstall,
   than  you can throw needed exception in new_handler.

--

    @=
     //RSSH                              mailto:Ruslan@Shevchenko.Kiev.UA


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

peter.garner@toward.com (Peter Garner) writes:

>  Can anyone recommend a compiler that meets the
>ANSI/ISO standard and runs under either OS/2 OR
>Linux.  [...]

Concerning Linux, I think that the compiler that is most consistent with
the forthcoming ANSI/ISO C++ standard is KAI C++ (see
http://www.kai.com/C_plus_plus/).

>Any ideas anyone?  egcs for Linux seems close, but
>the libraries do not seem to be standard, e.g.
>executing something like :

>  char * pc = new char [1000000000000000] ;

>simply places 0 in pc as opposed to throwing
>'bad_alloc'.

On my Linux machine, this statement prints "Virtual memory exceeded in `new'"
(after reducing the constant to fit into long :-) when compiled by
egcs 1.0.2. IMHO the only way how to force new to throw bad_alloc with
egcs is to define your own error handler, like the following one:
void myNewHandler() { throw bad_alloc(); }
Then you can install it using set_new_handler(myNewHandler) at the beginning
of the program. I think that the reason for this "obsolete" behavior is
the idea of backward compatibility rather than immaturity of the compiler.
However, some features, especially namespaces, are still missing in egcs.

With best regards,
Petr Mejzlik
--
Dept. of Information Technology, Faculty of Informatics
Masaryk University                            Internet: mejzlik@fi.muni.cz
Botanicka 68a                                 FAX : +42-05-4121 2568
CZ-602 00 Brno, Czech Republic                Tel.: +42-05-4151 2338


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