destructors not permitted for __value types.

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Personally, I like to use simple abstractions to wrap resources
For example consider a class that wraps a resource - say an IntPtr which is allocated in the constructor and deallocated in the destructor.
In the managed world I find that I can not use this because destructors (and copy constructors) for value types are not allowed. Of all the restrictions when compiling managed C++ code (and there are many!) this one is one of my pet hates
To me this was quite unexpected
I do not want to allocate the class as a object on the managed heap (__gc) because that would either require explicit calling of Dispose - which defeats the purpose of the abstraction or waiting for gc - which is not what I want to do either
Are there any ways round this?
 
PaulW said:
Personally, I like to use simple abstractions to wrap resources.
For example consider a class that wraps a resource - say an IntPtr
which is allocated in the constructor and deallocated in the
destructor.
In the managed world I find that I can not use this because
destructors (and copy constructors) for value types are not allowed.
Of all the restrictions when compiling managed C++ code (and there are
many!) this one is one of my pet hates.
To me this was quite unexpected.
I do not want to allocate the class as a object on the managed heap
(__gc) because that would either require explicit calling of Dispose -
which defeats the purpose of the abstraction or waiting for gc - which
is not what I want to do either.
Are there any ways round this?
Click to expand...

I wish I knew how to overcome this myself, but all I can do is to assure
you that I share your sentiments. The mess called Managed C++ is a
result of foisting the design philosophy of a certain language which is
based on the illusion that garbage collection is the end of manual
resource management (Java) on a language which emphasizes deterministic
and reliable handling of resources (C++), thereby crippling it beyond
recognition.

Gerhard Menzl
 
" deterministic and reliable handling of resources"

Thats up the the developer, no?
I would hardly call it "reliable" then.
 
PaulW said:
In the managed world I find that I can not use this because destructors
(and copy constructors) for value types are not allowed. Of all the
restrictions when compiling managed C++ code (and there are many!) this
one is one of my pet hates.
Click to expand...

The main reason for not having a copy constructor and a destructor in value
classes is that the semantics would not always be adhered to. It is far
worse to allow something to work some of the time than to disallow a
behavior in total.

That said, we're addressing this issue head on in Whidbey. Value classes
will still not be allowed to have special member functions (things like
default constructors, copy constructors, destructors, and finalizers). Ref
classes will be allowed to have all of these, and ref classes will be
allowed to have stack based semantics (i.e. the language will let you put a
ref class on the stack).
 
.. said:
" deterministic and reliable handling of resources"

Thats up the the developer, no?
I would hardly call it "reliable" then.
Click to expand...

Of course it's up to the developer. It always is. What is your point?

Gerhard Menzl
 
.. said:
" deterministic and reliable handling of resources"

Thats up the the developer, no?
I would hardly call it "reliable" then.
Click to expand...

The language allows you to do it in
a reliable way. That doesn't mean it
does it for you.
[...]
Click to expand...

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 
Back
Top