Joe Halpin wrote:
> The way to
> do that is to invoke `new (nothrow) Blah' instead of `new Blah'.

Is 'nothrow' a new ISO C++ keyword?
It is not listed in Table 3- keywords of the 28 Apr 1995 draft.

- Rick Hollinbeck (rickh@westernwares.com)
(http://www.westernwares.com/ccrider/)
---
[ 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                             ]

Rick Hollinbeck <rickh@westernwares.com> writes:

>Joe Halpin wrote:
>> The way to
>> do that is to invoke `new (nothrow) Blah' instead of `new Blah'.
>
>Is 'nothrow' a new ISO C++ keyword?
>It is not listed in Table 3- keywords of the 28 Apr 1995 draft.

No.  It's the name of a constant defined in <new>.
The type of this constant is `nothrow_t', and there is
an overloaded version of operator new declared in <new>
that takes an extra argument of this type:

 void * operator new (size_t, const nothrow_t &);

This operator new returns a null pointer rather than throwing
an exception, and it can be invoked using the placement
new syntax `new (nothrow) Blah', presuming you have a
`#include <new>' directive somewhere preceding.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4q9bhl$ch1@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU
(Fergus Henderson) writes:

|> "joe (j.) halpin" <jhalpin@nortel.ca> writes:

|> >Is there any standard way of turning exceptions off, and is there any
|> >defined behaviour for the new operator if this is done?

|> There's no standard way of turning exceptions off, but there is a
|> standard way of preventing `new' from throwing exceptions.  The way to
|> do that is to invoke `new (nothrow) Blah' instead of `new Blah'.  The
|> effect of this is to that `new (nothrow) Blah' will return a null
|> pointer rather than throwing a `bad_alloc' exception.  (However, it will
|> first try calling the handler installed by set_new_handler(), if any.
|> Only if there is no new_handler or if the installed new_handler
|> throws a bad_alloc exception will it return a null pointer.)

But this only turns exceptions off for the specific instance of
operator new that uses nothrow.  Libraries will generally use the
normal version.

You do mention a possible solution: replace the new handler with one
that doesn't throw an exception.  Note, however, that there is no way
of making the standard operator new return NULL.  This is probably a
good thing: I'll bet that none of the libraries are checking the return
value anyway (since it normally cannot be NULL).
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <fjh-960621-015104@cs.mu.oz.au>,
joe (j.) halpin <jhalpin@nortel.ca> wrote:

>Will the comittee consider defining a standard alternative for
>exception handling if exceptions and threads are really incompatible now?

They are not intrinsically incompatible.  Some implementors are more
behind than others.  I favor the less behind ones, myself, both
because it will give me a minor head-start on the draft-drift-induced
obsolence of my code, and because it demonstrates that they think that
standards are important, and they are capable of acting on that
thought (have I insulted anyone yet?  Good.  The companies I'm
thinking about have plenty of money, if they cared to spend it.)
Don't buy hardware without first checking out the compilers on it.
Ask them what version of the draft they are currently supporting, and
hold them to it.

As for considering them in the standard, I think that some people
(certainly not all) think about threads when considering C++ features
and how they interact.

If that's not good enough for you, there are other languages where the
support for threads is more explicit (e.g., Ada, Modula-3, Java).
Personally, I'm a fan of Modula-3, but if that's not a big enough
bandwagon, there's also Java and Ada.

speaking for myself,

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

In article <4ql0jn$gb5@wcap.centerline.com> chase@centerline.com (David
Chase) writes:

|> In article <fjh-960621-015104@cs.mu.oz.au>,
|> joe (j.) halpin <jhalpin@nortel.ca> wrote:

|> >Will the comittee consider defining a standard alternative for
|> >exception handling if exceptions and threads are really incompatible now?

|> They are not intrinsically incompatible.  Some implementors are more
|> behind than others.  I favor the less behind ones, myself, both
|> because it will give me a minor head-start on the draft-drift-induced
|> obsolence of my code, and because it demonstrates that they think that
|> standards are important, and they are capable of acting on that
|> thought (have I insulted anyone yet?  Good.

I'm curious about this point of view, especially as I know that David
Chase sets great importance on correct code.

I tend to favor implementors who invest their time and effort in making
the features they have work, rather than adding more that don't work.
While I would like to have a compiler that tracks the working papers for
playing around, I certainly wouldn't use it in a production environment,
where every new version would break working code (both because of
changes in the standard, and because implementing those changes
introduced new bugs in the compiler).  IMHO, for production code, the
ARM *IS* the standard, at least for now; the proposed standard is just
too volatile for use at present.  (I personally regret this situation,
and would have preferred a few less features and a bit more stability in
the draft standard.)

IMHO, adapting my production code to the current draft only means that I
will have to change it twice, once now, and again when the standard is
finalised.

It's worth noting that most of the compilers available don't even comply
with the ARM at present.  What's the point of adding, say, working
templates, if template instantiation is only a sometimes affair anyway?

|> The companies I'm
|> thinking about have plenty of money, if they cared to spend it.)
|> Don't buy hardware without first checking out the compilers on it.
|> Ask them what version of the draft they are currently supporting, and
|> hold them to it.

I do.  If they cannot handle ARM conformant code, I don't want to use
them:-).

In this regard, I like the attitude of Sun.  From private email with
Mike Ball, I gather that they have internal implementations of the
compiler which support the standard's lifetime of temporaries.  It will
not be released, however, until there is an upgrade strategy which will
support current users who counted on the longer lifetime of their
previous (CFront based) versions.  (This is probably an extreme case,
since according to the ARM, such code was already broken.)

(Of course, this can be carried a bit too far.  The Sun C compiler still
makes a separate copy of each string, and puts it in writable memory,
because this is what Johnson's PCC compiler did, although strings have
been "non-modifiable" at least since the C standard in 1990.)
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <KANZE.96Jun21204154@slsvgqt.lts.sel.alcatel.de> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
>In article <4q9bhl$ch1@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU
>(Fergus Henderson) writes:
>
>|> "joe (j.) halpin" <jhalpin@nortel.ca> writes:
>
>|> >Is there any standard way of turning exceptions off, and is there any
>|> >defined behaviour for the new operator if this is done?
>
>|> There's no standard way of turning exceptions off, but there is a
>|> standard way of preventing `new' from throwing exceptions.  The way to
>|> do that is to invoke `new (nothrow) Blah' instead of `new Blah'.  The
>|> effect of this is to that `new (nothrow) Blah' will return a null
>|> pointer rather than throwing a `bad_alloc' exception.  (However, it will
>|> first try calling the handler installed by set_new_handler(), if any.
>|> Only if there is no new_handler or if the installed new_handler
>|> throws a bad_alloc exception will it return a null pointer.)
>
>But this only turns exceptions off for the specific instance of
>operator new that uses nothrow.  Libraries will generally use the
>normal version.
>
>You do mention a possible solution: replace the new handler with one
>that doesn't throw an exception.  Note, however, that there is no way
>of making the standard operator new return NULL.  This is probably a
>good thing: I'll bet that none of the libraries are checking the return
>value anyway (since it normally cannot be NULL).

Right, which is where my problem comes from. How do you handle
situations in which you need to use C++ and threads together? The
implementation I'm familiar with has two versions of the runtime
libraries. Is that the only way to do it?

It appears that C++ is simply not useable in any kind of standard way
in a multithreaded environment. Nevertheless, people seem to be doing
it as evidenced by the ACE libraries, and others. Do we just wink at
the standard when using threads, or does the standard simply assume
that we never will use threads?

Does the standard committee have an intention to deal with threads, or
must we more and more simply rely on undefined behaviour provided by
individual vendors? Threads, after all, are not going away, they're
going to be as normal as processes before too much longer.

Joe


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <KANZE.96Jun26111819@gabi.gabi-soft.fr>, kanze@gabi-soft.fr (J. Kanze) writes:
|> I tend to favor implementors who invest their time and effort in making
|> the features they have work, rather than adding more that don't work.
|> While I would like to have a compiler that tracks the working papers for
|> playing around, I certainly wouldn't use it in a production environment,
|> where every new version would break working code (both because of
|> changes in the standard, and because implementing those changes
|> introduced new bugs in the compiler).  IMHO, for production code, the
|> ARM *IS* the standard, at least for now; the proposed standard is just
|> too volatile for use at present.  (I personally regret this situation,
|> and would have preferred a few less features and a bit more stability in
|> the draft standard.)

There is always a tension between those who want a stable, working
compiler above all else and those who want access to the latest features
even if it means some instability.  Walking the fine line between the
two extremes can prematurely turn a compiler maintainers hair gray.  Or
make it fall out as in my case.  ;-)

Supporting several versions would seem to satisfy both camps.  But how many
teams can realistically afford the dual/triple/... maintenance that might
involve?  And what do you do when there is some fundamental incompatibility
between them and someone decides to share code between the two camps?

There probably isn't a workable solution.
--

- Bill Seurer     ID Tools and Compiler Development      IBM Rochester, MN
  Business: BillSeurer@vnet.ibm.com               Home: BillSeurer@aol.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
]

An upcoming project may require a multithreaded implementation, and
I'm trying to understand the consequences of trying to be standard
compliant in that environment - or if it's possible.

I know that the draft standard requires the new operator to throw a
bad_alloc exception if memory cannot be allocated, and forbids the
returning of 0 in that event. However, it's not clear to me if this is
compatible with a multithreaded environment.

We need to write code that will work with either the HP or IBM C++
compiler. HP C++ does not currently support exceptions when threads
are being used, new in that implementation returns 0 when exceptions
are turned off with the +eh command line option. I'm not sure how the
IBM compiler handles it.

Is there any standard way of turning exceptions off, and is there any
defined behaviour for the new operator if this is done?

Is there any defined behaviour that can be expected when using
exceptions and threads together?

I suspect that the answer to all the above is no, but I'll ask anyway.

Thanks

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

"joe (j.) halpin" <jhalpin@nortel.ca> writes:

>Is there any standard way of turning exceptions off, and is there any
>defined behaviour for the new operator if this is done?

There's no standard way of turning exceptions off, but there is a
standard way of preventing `new' from throwing exceptions.  The way to
do that is to invoke `new (nothrow) Blah' instead of `new Blah'.  The
effect of this is to that `new (nothrow) Blah' will return a null
pointer rather than throwing a `bad_alloc' exception.  (However, it will
first try calling the handler installed by set_new_handler(), if any.
Only if there is no new_handler or if the installed new_handler
throws a bad_alloc exception will it return a null pointer.)

This is a quite recent change; some compilers which have been tracking
the draft very closely might use the syntax `new (nothrow()) Blah'
instead of `new (nothrow) Blah', and many not yet support it
at all.

>Is there any defined behaviour that can be expected when using
>exceptions and threads together?

The draft C++ standard doesn't define any behaviour at all with respect
to threads.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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                             ]

Fergus Henderson wrote:
>
> "joe (j.) halpin" <jhalpin@nortel.ca> writes:
>
> >Is there any standard way of turning exceptions off, and is there any
> >defined behaviour for the new operator if this is done?
>
> This is a quite recent change; some compilers which have been tracking
> the draft very closely might use the syntax `new (nothrow()) Blah'
> instead of `new (nothrow) Blah', and many not yet support it
> at all.
>If one was to override operator new, how is the (nothrow)
passed to the function so that it may return 0 rather than
throwing an exception.
--------------------------------------------------------------
Warwick Slade                            | sladew@ccsc.com
Software Consultant                      | (wk) +1-770-3938646
Computer Consulting Services Corporation |
--------------------------------------------------------------
Plus Tax, Plus Tax, Plus Tax, Plus Tax, Plus Tax, Plus Tax.
--------------------------------------------------------------
--------------------------------------------------------------
Plus Tax, Plus Tax, Plus Tax, Plus Tax, Plus Tax, Plus Tax.
--------------------------------------------------------------
---
[ 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
]

In article <4q9bhl$ch1@mulga.cs.mu.OZ.AU>,
Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote:
>"joe (j.) halpin" <jhalpin@nortel.ca> writes:
[...]
>>Is there any defined behaviour that can be expected when using
>>exceptions and threads together?
>
>The draft C++ standard doesn't define any behaviour at all with respect
>to threads.

Given that threads are going to be part of the programming landscape,
is there any intent on the standards committee to deal with them? It
might be enough to assume that vendors will work out more or less
compatible, non-standard, methods to make C++ work with threads, but
wouldn't it be better for some standard behaviour to be expected?

Will the comittee consider defining a standard alternative for
exception handling if exceptions and threads are really incompatible now?

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

Warwick Slade <sladew@ccsc.com> writes:

>Fergus Henderson wrote:
>>
>>If one was to override operator new, how is the (nothrow)
>passed to the function so that it may return 0 rather than
>throwing an exception.

Are you asking how the `new (nothrow) Foo' syntax would be implemented?
Something like this should do the trick:

 struct nothrow_t {};
 const nothrow_t nothrow;
 void * operator new (size_t size, nothrow_t) {
  try {
      return operator new (size);
  } catch (bad_alloc) {
      return NULL;
  }
 }

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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
]