destructors not permitted for __value types.

[PaulW]

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?

[Gerhard Menzl]

PaulW wrote:

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?

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
--
Humans may reply by replacing the obviously faked part of my e-mail
address with "kapsch".

" deterministic and reliable handling of resources"

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

"Gerhard Menzl" <ge***********@spambucket.net> wrote in message
news:40********@news.kapsch.co.at...

PaulW wrote:

> 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?

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
--
Humans may reply by replacing the obviously faked part of my e-mail
address with "kapsch".

[Brandon Bray [MSFT]]

PaulW wrote:

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.

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).

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

[Gerhard Menzl]

.. wrote:

" deterministic and reliable handling of resources"

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

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

Gerhard Menzl
--
Humans may reply by replacing the obviously faked part of my e-mail
address with "kapsch".

[Hendrik Schober]

.. <.> wrote:

" deterministic and reliable handling of resources"

Thats up the the developer, no?
I would hardly call it "reliable" then.
The language allows you to do it in
a reliable way. That doesn't mean it
does it for you.
[...]

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

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