From: Adam 

Paul Ranson wrote:

> I'm sure you actually know this stuff but a C++ programmer can write (or if
> (s)he's one of the incompetent 'really only suitable for Java' types...)


ROFLMAO. As in "he's too old to learn anything new & moving from C
& Cobol to C++ nearly killed him so leave him maintaining the legacy
kit where eee's appy".


> have written a class that manages a database channel and releases it in its
> destructor. Now the compiler does the hard work. This has nothing to do with
> memory management. AFAIK Java has the concept of scopes but not any
> deterministic way for an object to know when it's gone out of scope. The C#
> people just seem to be be perverse about this.
>

Gee so you have to close a connection. Heck use a proper pooling mechanism
& this isn't a problem anyway as the pool handles maintaining the conns
to the db.

> So, literally, C++ users don't have to release channels to databases, and
> generally they have to spend very little time indeed worrying about
> allocating or releasing memory. They can even use GC if they wish, perhaps
> under the aegis of .NET...
>

Gosh the shock wll kill most of them given their age & infirmity.

Adam


> Paul
>
> "Adam"  wrote in message
> news:428afc6a{at}w3.nls.net...
>
>>Paul Ranson wrote:
>>
>>>Object lifetime isn't the same thing as memory management. Consider a
>>>database transaction, or any resource lock. Why you want your
>>>underpressure, tired etc programmers time after time having to do their
>>>own rollbacks or releases is beyond me.
>>
>>A) So people doing C++ don't have to release channels to db'es or to deal
>>with transactions? If so then hey there's one more thing they have to do
>>as well as allocating & reclaiming memory.
>>
>>B) Rollbacks etc i.e. transaction handling is most often a business matter
>>& not a languge matter esp wrt distributed transactions where 5 different
>>systems must all get the message & understand it & then the
whole can be
>>committed.
>>
>>
>>
>>>OTOH garbage collection isn't a panacea, however you manage memory if
>>>your programmers don't know what they're doing you're heading for
>>>trouble.
>>>
>>
>>Indeed howeve rnot having to deallocate memory is one less point of
>>failure to worry about. Yes you do get hanging references & yes they can
>>be annoying to track down but I have yet to see a hanging ref steadily
>>chew up memory till there s none left.
>>
>>Adam
>
>
>

--- BBBS/NT v4.01 Flag-5