Oops, it looks like we need to update that web page. Version 3.3d is
thread safe in the presence of exceptions.

> >   You may want to check again.  Version 3.3d DOES CLAIM to be thread
> > safe.
>
> From their web page FAQ:
>
> 1.Is KAI C++ thread-safe?
>      The code generated by KAI C++ is thread-safe as long as you do not
>      turn on exceptions. The current versions of KAI C++
>      are not thread-safe with exceptions enabled.

--
#include <std/disclaimer.h>                 Kuck and Associates
David Nelson (david@kai.com)                1906 Fox Drive
http://www.kai.com/C_plus_plus/_index.html  Champaign, IL   61820
KAI C++ - Cross Platform C++ Compiler       (217) 356-2288 ext 36



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

>It implements (almost!) all the required features, and rejects almost
>all invalid programs with useful error messages.  It translates to C,
>and its optimization is limited, so performance is not optimal --
>particularly in the case of exceptions.  It probably does not have
>thread-safe exception handling.

Thanks for the info.  Also, it is 1/6 the price of KAI compiler with the
educational discount!  Do you know if anyone has done a comparison of
the programs produced with g++, KAI, and como?  Like the kind you read
in PC Magazine for the Windows compilers.


>It is *excellent* for educational use.   I use it whenever I have
>a question about what the standard says should happen.  It's not
>_always_ right, but it's right more often than most other compilers.

Great.


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


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

David R Tribble <dtribble@technologist.com> wrote:
>
>C++ has additional MT-safety problems beyond the std library;
>exception handling is one.  MT-safe operation of ::new and ::delete
>are another.  And there are probably others...

C++ is easier to make thread-safe than C, because its standard
library doesn't mandate unsafe interfaces.  Thread-safe (and
signal-safe) exception handling is hard if you translate to C,
but not extraordinarily difficult otherwise.

>(I've read that there are difficult problems to solve in making
>MT-safe versions of the STL, though.)

Difficult problems, but solved.  The current SGI STL (release 3.11) can
be configured to be thread-safe.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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

Siemel Naran<sbnaran@uiuc.edu> wrote:
>
>>It implements (almost!) all the required features, and rejects almost
>>all invalid programs with useful error messages.  It translates to C,
>>and its optimization is limited, so performance is not optimal --
>>particularly in the case of exceptions.  It probably does not have
>>thread-safe exception handling.
>
>Thanks for the info.  Also, it is 1/6 the price of KAI compiler with the
>educational discount!  Do you know if anyone has done a comparison of
>the programs produced with g++, KAI, and como?  Like the kind you read
>in PC Magazine for the Windows compilers.

I don't know of any publications on the subject.

KAI "kcc" is a fully professional compiler that does an almost
supernatural grade of optimization.  gcc-2.8 is stagnant and not
well-tested.  Egcs-1.0.x implements lots of language features,
but not "enough"; Egcs-1.1 (due out "soon") will implement them
all, and with lots of new optimizations.  Comeau doesn't optimize
much, but does OK except for exception handling.  Only KAI comes
with conforming iostreams.

Be warned though, KAI's is not a fast compiler.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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

David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:
>> So even if a compiler conforms to the ISO language std, that
>> doesn't mean it is useful for writing real-life MT-safe programs.
>> Hopefully, vendors will realize this and make the appropriate
>> improvements to their compilers and libraries.

Matt Austern wrote:
> A different problem is that "MT-safe" means different things to
> different people.

Yes.  I use a very simple definition: A function can be considered
thread-safe if it does not have problems accessing global data
when it is called at the "same" time by two different threads.

This typically means that the function either 1) properly
serializes access to global memory, or 2) operates on "thread
local" global memory, or 3) simply doesn't use global memory.
All of these ensure that multiple simultaneous invocations do
not interfere with each other.

Of course, I'm probably using a oversimplified definition here...

BTW, POSIX has thread-safe equivalents to the dozen or so ISO
thread-unsafe functions; they take an additional argument to
implement scheme (3) above.

-- David R. Tribble, dtribble@technologist.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              ]

Actually, some implementations do this pretty well. For instance,
SGI's version was designed with thread safety in mind. An excerpt
from http://www.sgi.com/Technology/STL/thread_safety.html :

    The SGI implementation of STL is thread-safe only in the sense
    that simultaneous accesses to distinct containers are safe, and
    simultaneous read accesses to to shared containers are safe. If
    multiple threads access a single container, and at least one
    thread may potentially write, then the user is responsible for
    ensuring mutual exclusion between the threads during the
    container accesses.

One reason for this is performance:

    This is the only way to ensure full performance for containers
    that do not need concurrent access. Locking or other forms of
    synchronization are typically expensive and should be avoided
    when not necessary.

This may sound restrictive, but SGI goes on to explain that there's
not really any other way to do it:

    It is easy for the client or another library to provide the
    necessary locking by wrapping the underlying container operations
    with a lock acquisition and release. For example, it would be
    possible to provide a locked_queue container adapter that provided
    a container with atomic queue operations.

    For most clients, it would be insufficient to simply make container
    operations atomic; larger grain atomic actions are needed. If a
    user's code needs to increment the third element in a vector of
    counters, it would be insuffcient to guarantee that fetching the
    third element and storing the third element is atomic; it is also
    necessary to guarantee that no other updates occur in the middle.
    Thus it would be useless for vector operations to acquire the lock;
    the user code must provide for locking in any case.

Also, the basic_stream class, as defined in CD2, has several problems
including MT. As a partial solution, the SGI version doesn't use reference
counting; see http://www.sgi.com/Technology/STL/string_discussion.html
for an explanation of why not.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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 <35c8b2c8.0@news.primary.net>,
  peter.garner@toward.com (Crazy Pete) wrote:
> In article <6q9m1g$mr7$1@nnrp1.dejanews.com>,
>  saroj@bear.com writes:
> > In article <35c762a5.0@news.primary.net>,
> >   peter.garner@toward.com (Crazy Pete) wrote:
> >> In article <01bdbfc0$bbeadf80$d615b080@novus>,
> >>  "Christian Verbeek" <verbeek@uni-muenster.de> writes:
> >>
> >>   The most conforming compiler of which I am aware is KAI
> >> C++.  You can get a 30 day free demo from
> >>
> >> http://www.kai.com
>
> > It is an excellent compiler, but it does not generate thread-safe
> > code for throw (last time, I checked). This is a major problem.
> > Writing MT-safe code is already hard, so the compiler should not
> > aggravate the problem.
>
> Howdy!  ;-)
>
>   You may want to check again.  Version 3.3d DOES CLAIM to be thread
> safe.

 Siemel Naran<sbnaran@KILL.uiuc.edu> wrote:
>How about comeau c++?
>
>It doesn't come with a standard library, but you can download (or write!)
>your own.
>
>Anyone have thoughts on this compiler?  It seems to be very conforming.

It implements (almost!) all the required features, and rejects almost
all invalid programs with useful error messages.  It translates to C,
and its optimization is limited, so performance is not optimal --
particularly in the case of exceptions.  It probably does not have
thread-safe exception handling.

It is *excellent* for educational use.   I use it whenever I have
a question about what the standard says should happen.  It's not
_always_ right, but it's right more often than most other compilers.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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

Crazy Pete wrote:
> ...
> BTW what exactly do you
> mean by thread safe code for throw?  BTW as far as I know, the ISO
> standard makes no mention of threads so this does not impact the
> ISO conformance of the compiler.

One of the problems with the ISO language standard is that it does
not make any mention of multithreaded environments; in effect, it
assumes that there is only a single execution flow within a
C++ program.  Thus a truly conforming C++ implementation need not
operate correctly on a MT environment.

Which doesn't help, of course, when trying to build real MT-safe
applications on MT environments.

I submitted a comment (to the ISO C9X committee, not the C++
committee) that the std library should make some attempt to be
thread-safe; the worst problem is the use of global data (in
functions such as strtok() and localtime()).  Replacing such
functions (or simply adding new functions that coexist with the
old ones) that don't behave this way would be a step in the right
direction.  (There are only about a dozen or so such functions
anyway.)  Unfortunately, my comment was rejected.

C++ has additional MT-safety problems beyond the std library;
exception handling is one.  MT-safe operation of ::new and ::delete
are another.  And there are probably others...

So even if a compiler conforms to the ISO language std, that
doesn't mean it is useful for writing real-life MT-safe programs.
Hopefully, vendors will realize this and make the appropriate
improvements to their compilers and libraries.  (I've read
that there are difficult problems to solve in making MT-safe
versions of the STL, though.)

-- David R. Tribble, dtribble@technologist.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              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:

> So even if a compiler conforms to the ISO language std, that
> doesn't mean it is useful for writing real-life MT-safe programs.
> Hopefully, vendors will realize this and make the appropriate
> improvements to their compilers and libraries.  (I've read
> that there are difficult problems to solve in making MT-safe
> versions of the STL, though.)

There are technical issues, yes.

A different problem is that "MT-safe" means different things to
different people.


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

Of course there's no reason to implement the CD2 version.  It is possible
to do an MT-safe reference-counted _standard_ basic_string<>.  SGI chose
not to do it for reasons that don't apply to everyone (and maybe not even
to them).

Regarding the argument on the web page: most strings are constructed,
passed around, stored, retrieved, and written out without ever
operating on individual characters via operator[] or iterators.
Hence, the argument on the web page against efficiency of conforming
reference-counted string is rather weak.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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 <01bdbfc0$bbeadf80$d615b080@novus>,
 "Christian Verbeek" <verbeek@uni-muenster.de> writes:
> dear newsgroup,
> i recently left my win32 development enviroment and want to write programs
> under linux. what compiler do i best use? where do i get the libraries
> (specially the c++-libraries conform with the latest ansi/iso
> c++-standard). the gcc libraries seem not to be conform (e.g. there is no
> valarray).

Hello Christian!

  The most conforming compiler of which I am aware is KAI
C++.  You can get a 30 day free demo from

http://www.kai.com

They are based in Illinois, USA, but they have a very good
ISO conforming C++ compiler for Linux.  A word of warning is
that most C++ compilers are not object compatible with the
C++ from other compilers.  I.e. you can link to C libraries
but any C++ libraries must be recompiled with KAI C++.  I
think you will find this to be far more ISO compliant than
g++, however.

Best of Luck

Peace

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 <35c762a5.0@news.primary.net>,
  peter.garner@toward.com (Crazy Pete) wrote:
> In article <01bdbfc0$bbeadf80$d615b080@novus>,
>  "Christian Verbeek" <verbeek@uni-muenster.de> writes:
>
>   The most conforming compiler of which I am aware is KAI
> C++.  You can get a 30 day free demo from
>
> http://www.kai.com
>
> They are based in Illinois, USA, but they have a very good
> ISO conforming C++ compiler for Linux.  A word of warning is
> that most C++ compilers are not object compatible with the
> C++ from other compilers.  I.e. you can link to C libraries
> but any C++ libraries must be recompiled with KAI C++.  I
> think you will find this to be far more ISO compliant than
> g++, however.
>
>
It is an excellent compiler, but it does not generate thread-safe
code for throw (last time, I checked). This is a major problem.
Writing MT-safe code is already hard, so the compiler should not
aggravate the problem.

               -- Saroj Mahapatra



-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


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

Christian Verbeek wrote:
>
> i recently left my win32 development enviroment and want to write
> programs under linux. what compiler do i best use?

I would think that it would be a good idea to stick with gc++, because
that's the compiler that is most commonly used in Linux. This is
especially true if the code you write is likely to be shared with other
Linux users. But even if it's proprietary code, I'd expect some setup
conflicts since gc++ and its related header files and tools will likely
still be visible.

--

Ciao,
Paul


[ 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 <6q9m1g$mr7$1@nnrp1.dejanews.com>,
 saroj@bear.com writes:
> In article <35c762a5.0@news.primary.net>,
>   peter.garner@toward.com (Crazy Pete) wrote:
>> In article <01bdbfc0$bbeadf80$d615b080@novus>,
>>  "Christian Verbeek" <verbeek@uni-muenster.de> writes:
>>
>>   The most conforming compiler of which I am aware is KAI
>> C++.  You can get a 30 day free demo from
>>
>> http://www.kai.com

> It is an excellent compiler, but it does not generate thread-safe
> code for throw (last time, I checked). This is a major problem.
> Writing MT-safe code is already hard, so the compiler should not
> aggravate the problem.

Howdy!  ;-)

  You may want to check again.  Version 3.3d DOES CLAIM to be thread
safe.  Now much as I like KAI, I place the claims of any salesman in
the same bucket as political campaign speeches.  ;-)  Version 3.3d
is already out for many platforms and should be out for Linux in a
few days if it is not already available.  BTW what exactly do you
mean by thread safe code for throw?  BTW as far as I know, the ISO
standard makes no mention of threads so this does not impact the
ISO conformance of the compiler.

Peace

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              ]

>> i recently left my win32 development enviroment and want to write
>> programs under linux. what compiler do i best use?

>I would think that it would be a good idea to stick with gc++, because
>that's the compiler that is most commonly used in Linux. This is
>especially true if the code you write is likely to be shared with other
>Linux users. But even if it's proprietary code, I'd expect some setup
>conflicts since gc++ and its related header files and tools will likely
>still be visible.

How about comeau c++?

It doesn't come with a standard library, but you can download (or write!)
your own.

Anyone have thoughts on this compiler?  It seems to be very conforming.


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


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

dear newsgroup,
i recently left my win32 development enviroment and want to write programs
under linux. what compiler do i best use? where do i get the libraries
(specially the c++-libraries conform with the latest ansi/iso
c++-standard). the gcc libraries seem not to be conform (e.g. there is no
valarray).

please answer via email too. thanx in advance, christian
---
[ 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              ]

Christian Verbeek<verbeek@uni-muenster.de> wrote:
>i recently left my win32 development enviroment and want to write programs
>under linux. what compiler do i best use? where do i get the libraries
>(specially the c++-libraries conform with the latest ansi/iso
>c++-standard). the gcc libraries seem not to be conform (e.g. there is no
>valarray).

Kuck & Associates sells a very fine compiler.  Some time this
week the free Egcs-1.1 will be out, though its libraries are
obsolete.  You can get an excellent STL from
http://www.sgi.com/Technology/STL (release 3.11 is out).

Gabriel dos Reis's valarray is available (along with SGI
STL release 3.11 and a string class) via

   http://egcs.cygnus.com/libstdc++-v3.html

if you're feeling adventurous and like to contribute.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



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