Re: throwing exception from constructor

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Barry Kelly" <barry.j.kelly@xxxxxxxxx> a écrit dans le message de news:
gf55d25vi26gqbfm8p72mfskjjt6ihbjeg@xxxxxxxxxx
"Arnaud Debaene" <adebaene@xxxxxxxxxxxxxxxx> wrote:

"Barry Kelly" <barry.j.kelly@xxxxxxxxx> a écrit dans le message de news:
acf1d2pj19bjlppmfs4r3qbsmg5termkpg@xxxxxxxxxx
adebaene@xxxxxxxxxxxxxxxx wrote:

In my view, C++'s destructors along with the RAII pattern are basically
required to be overused in order to hack around a limitation in the
language.
Which limitation? The limitation is rather on the .NET finalizer side
IMHO :
since you don't know when they are run, there is almost nothing you can
do
inside them!

We'll have to agree to disagree - I think it's a limitation of the
language definition, nothing to do with .NET or otherwise, in the
context of "throwing an exception from the constructor".

But which limitation are you talking about exactly? That's what I don't
understand...

The RAII pattern works very well for simple scenarios (and
they should be used in such reusable scenarios), like an owned pointer
or a ref-counted pointer, but not every paired operation between
constructor and destructor is so reusable that it merits a new type.

That's why there are generic solutions to the RAII idiom, such as
ScopeGuard
(http://www.ddj.com/dept/cpp/184403758)

Yes, more hacks and crutches...

Huuh? Andrei Alexdandrescu doing "hacks and crutchs" ??? Care to justify
your appreciation?

More seriously, I believe there is a true divergence ni philosophy here :
The C++ approach is "do as little as possible in language itself, and as
much as possible in libraries", whereas your approach (I am not really sure
this is indeed the C# approach) is "put everything in language and compiler
itself, so that there is nothing left to do in libraries". I believe the 1st
approach is more flexible because, first, it makes it much easier to replace
a defective component....

Arnaud
MVP - VC


.

Relevant Pages

  • Re: The Promise of Forth
    ... out routine solutions. ... This is a limitation for Forth. ... If Forth is a good language for "thinking people" I don't see why ... This is not a technical problem, and as much as you'd love to find a technical problem and solve it, there's not a technical solution. ...
    (comp.lang.forth)
  • Re: C# equivalent of some SML code
    ... techniques that the SML code relies upon. ... C# is a strongly, statically typed language. ... rely on dynamic techniques, then yes...C# isn't going to be appropriate ... This is a limitation of .NET's type system that C# inherited. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: periodic reminder
    ... compatible code with it or you can write horrible hacks which nobody ... developers to write clean code and not the fault of the language ... documentation was a real problem so that many projects used bad hacks ...
    (comp.unix.programmer)
  • Re: Fortran is not viable
    ... It seems to me that if every implementation has a restriction, then the language has that restriction. ... Most languages do not put such specific requirements on the data types, ... Most compilers targeting 32 bit processors limit array subscripts to 32 bits, though there is no reason to consider it a language limitation. ...
    (comp.lang.pl1)
  • Re: throwing exception from constructor
    ... required to be overused in order to hack around a limitation in the ... We'll have to agree to disagree - I think it's a limitation of the ... language definition, nothing to do with .NET or otherwise, in the ... or a ref-counted pointer, but not every paired operation between ...
    (microsoft.public.dotnet.languages.csharp)