Re: Go ahead. Stop programming. This ensures you from any mistakes.

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

valentin tihomirov <V_tihomirov@xxxxxxx> wrote:
But if the object itself were "uncreated" then that wouldn't make any
odds. The object is clearly still alive, contrary to your previous
statement.

Yes, I have overlooked the posibility to establish a reference to an object,
construction of which fails. However, I have never claimed there is a need
to "uncreate" an object. All what is realliy needed is to free allocated
resources. Both in destructor, which is called by user, and in constructor,
which destroys partially created object in case of exception.

Again, there's no such term as "destructor" in C#, but yes - the
constructor should clear up all resources if an exception is thrown
during construction. My point was just that the object itself is *not*
automatically "deleted" immediately.

I'm perfectly happy to use try/catch where appropriate. Using try/catch
and then rethrowing is another alternative to using try/finally.

So, now we have two different ways, neither of which require using
fallthrough/"goto" in a switch/case statement. So much for it being
indispensible.

I repeat third time: the catch/finally replaces C macros. It does not
replace the jumping to entry point of code.

Okay - so in the rare situation where I actually have more than one
resource I need to dispose of (heck, it's rare enough that my objects
have member state with *any* disposable resources) I would almost
always be able to tell whether or not the resource had been allocated
using "null". I can't immediately think of a situation where I wouldn't
be able to tell from the state itself whether or not I needed to
release that state.

At that point, it's very easy to write code which does a check-then-
release, check-then-release etc. It's also reasonably easy to make that
exception safe.

As I say though - this is incredibly rare for me.


No, IDisposable is *not* a destructor. I believe that there's some
relationship in C++/CLI between IDisposable and destructors, but in C#
(post v1) there is no such thing as a destructor. In particular, there
is nothing which will automatically be called in C# at the end of the
scope of a variable.

I call a destructor a method which is needed to be called to free allocated
resources regardless of who makes the call.

Then you're reusing existing and quite specific terminology to cover
similar situations which aren't exactly the same. That's just a recipe
for miscommunication.

You seem to take it for granted that reducing the amount of code
improves code readability. Quite often I'll find that the most readable
form of some code is *not* the shortest.

I agree that a bitmap in jpeg form is hard to read/edit but when you have a
common pattern which is repeated 1000 times in a text of program it is not
just easier to read when the pattern is packed in reusable routine, it is
easiter to mantain for reusability reason. I'm sure the redundant approach
based on quich and durty copy-and-paste is a bad practice.

You are free to write

<snip straw man>

Hey, I can come up with straw men too: you like short code? Better use
single letter variables everywhere and have all your code on one line,
right?

No, of course not.

There are times when the shortest code is the most readable. There are
plenty of times when it isn't.

Macros can introduce subtle bugs very easily, as well as often being a
nightmare to debug. I for one am glad that C# doesn't have them.

There is a razor principle, put by Einstain: things must be done as simple
as possible. I know that the really beautiful things are those which have
nothing redundant. Overcomplication is bad design. I beleive the programmers
are undergraduated creatures vocated to produce loads of "sw".

So you don't believe there's any situation where longer code can be
more readable than shorter code? We'll have to agree to disagree on
that one.

Here's an example: I don't want everyone who ever reads my code to have
to know all of the operator precedence of C#. I'll assume they know
that * binds tighter than + and basics like that, but nothing *very*
complicated - so if there's anything which might introduce confusion in
a reader's mind, I'll put brackets in to make it explicit.

Those brackets are redundant, in that the compiler certainly doesn't
need them - but they help readability.

Compile it with the "TESTING" symbol defined, and it'll print the two
strings. Compile it without the "TESTING" symbol defined, and nothing
will be printed.

I have heard of conditional compilation. The problem is however that the
debug level can be changed on the same executable. You cannot avoid code
generation to implement lazy evaluation. The macros check the condition
before passing to the message construction code execution.

I don't understand what you want to be able to do which I didn't just
demonstrate in the example. In my example the message construcvtion
code was not executed - isn't that exactly what you wanted?

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Exception unwinding base destructor called - why?
    ... construction Derived throws an exception and the handler's unwinding ... mechanism is calling the destructor for the base class. ... Where is the logic in partially deconstructing an aggregate object that's ...
    (comp.lang.cpp)
  • Re: MS Project - scheduling similar but unrelated activities
    ... On a construction project there are activities, like laying foootings, ... availability of resources (i.e. normal dependency-based scheduling). ... In a kitchen it's best to get the pastry work done before the main ...
    (microsoft.public.project)
  • Re: mixing C and assembly
    ... needed for a specific construction. ... code generation differs for logically equivalent blocks of code. ... resources a specific construct will require on your platform. ...
    (comp.arch.embedded)
  • Re: I cannot see the need for auto_ptr?!
    ... >> No copy construction for a, and the copy constructor clearly works. ... >Point destructor ... RVO and NRVO are two different things. ...
    (comp.lang.cpp)
  • Re: first time
    ... construction side but i dont have any idea in access can before this is first ... Jeff Conrad's resources page: ... Roger Carlson's tutorials, samples and tips: ...
    (microsoft.public.access.gettingstarted)