Warp wrote:
>   Maybe the fact that C++ basically removed the need for manual cleanup of
> resources (if you use its constructs properly) made it much safer and
> cleaner to use early returns.

Exactly the point I'm making. In C++, "return" doesn't mean return from the 
function any more. It means basically "branch to all the clean-up code for 
anything allocated in any of the scopes I'm nested in." :-)

>   If you see something like this in C++:

Yep. Rather than "checked and unchecked exceptions", I think Java (and C#) 
would have been better off issuing warnings or errors for potential leaks of 
disposable items.

If you have a file handle in C#, you're supposed to put it inside a "using" 
so it gets closed if you exit the scope.

using (FileHandle handle = File.Open(...))
{
    handle.read(); handle.write(); ...
}

Any time you exit the block after you've created the file handle, it'll get 
cleaned up (in the sense that the Dispose call will be made).  Kind of 
poor-man's C++ destructors.  If they were going to do that, they should have 
put in some mechanism to keep you from accidentally making a handle (or 
anything else that inherits Disposable) without clearly disposing it.

Sing# does something much like this by basically making it so that kind of 
object can't get assigned to more than one variable at once (i.e., you can't 
have two pointers/references to the same value), and it tracks and enforces 
this at compile time. So "File.Open" would declare it returns a new file 
handle, "File.Close" would declare it consumes the handle, and everything in 
between would be unable to overwrite it or copy it or whatever (outside of, 
of course, passing it to subroutines, etc).

The destructor semantics is one of the things I think C++ really did get 
just right.  It's really all the C compatibility that makes it awkward, I find.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message