EduardoS (no@spam.com) on 8/26/09 wrote:
---------------------------
>JasonB (no@spam.com) on 8/25/09 wrote:
>---------------------------
>>GC typically implies non-deterministic object destruction. Non-deterministic object
>>destruction implies RAII cannot be used. Not being able to use RAII makes it nearly
>>impossible to write exception-safe code.
>
>finally
>{
>myObject.Dispose();
>}

The problem with finally is that you either wrap one around every statement that acquires a resource (which is even uglier and more error-prone than the old-fashion if-style checking of return values) or you have to take extra steps in the finally handler to figure out what was already acquired and what never got reached.

Neither of those problems exist with RAII -- every object constructed on the stack is guaranteed to be destructed in reverse order, so you simply construct the object when the resource is acquired and put the code for releasing the resource in the destructor -- and if you're using legacy interfaces that don't use RAII internally, then use scopeguard instead, and have the added advantage that the code to release the resource is written right below the code to aquire it, making it easier to ensure you didn't forget to do it -- something a finally block at the bottom of your method doesn't help with.

>Or with the more elegante using(){} C# constructor

I strongly applauded MS's decision to include using. I find them to be far more pragmatic than Sun. using even allows you to write scopeguard in C#, with a small syntactic burden relative to C++.

It was precisely because of C# that my original comment used the phrase "typically implies", although I should have used it for the second sentence as well because I forgot that using doesn't actually destruct the object at the end of the block. My bad.

>I know, the memory won't be freed, but routines to free the resource will run,
>sure, the program may pass a pointer of this object to some other and when the other
>call it after the Dispose will get an exception, but this could be done in C++,
>with more severe damages (silenty corruption of the stack as the worse of them),
>it also could skip this constructor, but this could be done in C++ too, look at
>Richard's example of how an exception breaking code ;)

Anything "could" be done in C++. C++ is a toolbox full of tools intended for a craftsman, not an apprentice. It contains tools that allow you to write safer code with less effort than could ever be accomplished with Java, for example -- but it doesn't enforce it. It can't, primarily because it's meant to be as compatible with C as it possibly can, and it has a much wider scope of applications than Java or C# has.

So writing safer code is a matter of discipline and coding style rather than a straightjacket imposed on you by the language (which, in Java's case at least, actually makes writing really robust code nearly impossible); the difference with using something like C and relying on discipline and coding style is that C++ actually supplies you the tools to enforce that discipline if you choose to use them. If you want range-checked arrays, you can have them; if you want to eliminate dangerous pointer casts, only use the safe ones (if you need to use any at all, which is rare); if you want to ensure exception safety, use RAII everywhere, and so on.

>A much more delicated case of resource not being freed is when they they are at
>a global shared scope and for some reason the last code using it forgot to finalize
>(I think there is only two absolute truths in computer science, the first is a slot
>reserved for future use and the second is that reference counting does not work
>:D), ie: it leaks, at this point GC may not be 100% safe, but it's safer than C++.

C++ is as safe or unsafe as you make it. It can be safer than a GC language if you choose to restrict yourself to the subset that makes it possible, and it can be less safe if you choose the opposite. Sometimes the same program can be both depending on the operation.

It would be nice if there was a compiler option to enable warnings for potentially unsafe code (VC++ already includes lots of warnings about potential buffer overflows and underflows when you don't use range-checked C functions, and can check at runtime for buffer overflows and return value corruption (and stack corruption in general), loss of data from assigning values from a larger type to a smaller one, use of an unitialised variable, etc.).

And of course C++ can be a GC language as well (and in VC++ you can mix-and-match native code and CLR assemblies on an object file by object file basis).