Re: New release of the Dynace OO extension to C
On Jul 23, 3:39 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
In article <f2fa1862-a8f8-4d94-b6fa-4591dde9e9c3
@n11g2000yqb.googlegroups.com>, james.ka...@gmail.com says...
On Jul 22, 5:37 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
In article <iiC9m.59496$OO7.53...@text.news.virginmedia.com>,
ba...@freeuk.com says...
[...]
Nearly the only hard piece that's hard to avoid is exception
safety. Quite a few parts of the C++ library (and even the
base language) can end up throwing exceptions to signal
problems, so if you use any of those features, you're pretty
much stuck with making your code act sanely in the face of
exceptions.
Everybody keeps saying this, but... except for new, what
part of the library/language throws exceptions unless you
explicitly ask for them? And if you replace the new_handler
so that it aborts (many of my applications do), then new
can't throw exceptions either.
Everything else that uses new can also throw exceptions, so
unless you write your own allocators, essentially all the
containers will do so (and writing your own allocator doesn't
seem to fit very well with the use case of a C programmer who
wants to use a few handy bits and pieces of C++ without
getting into all its gory details).
That's why the standard requires the default allocators to use
::operator new (and not e.g. malloc). Once you've replaced the
new_handler so that it aborts, rather than throwing, anything
that uses the standard allocator will abort, rather than
throwing.
That also leaves an obvious question: if you didn't use
exceptions, how WOULD you signal failure? Some situations are
undoubtedly easy, but others are a lot less so. For example:
std::map<std::string, int> collection;
collection["whatever"] = 1;
You could have it abort, but that's not always a reasonable
response.
But it is more often than not.
Don't get me wrong. If you're writing a large, transaction
based system, you'll definitely want to use exceptions for
anything which will abort a transaction. And even in smaller
systems, they have advantages in specific cases (e.g.
constructors). But they're not forced on you by the language,
or the library---you choose to use them because they solve a
particular problem better than the alternatives.
The part of the language that "forces" them on you is
dynamic_cast of a reference, which can throw an exception. As
long as you're not using inheritance, however, that's pretty
easy to avoid. Even if you are using inheritance AND use
dynamic_cast, you can pretty easily restrict yourself to
working with pointers instead of references though.
Yes.
As I said, my point wasn't that you shouldn't use exceptions
(although there may be some special cases where you shouldn't),
but rather that what "forces" them on you is the fact that the
alternative solutions are a lot more work, and not the language
or the library, per se.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34