Re: Bug in C++ /CLI 2005

Tech-Archive recommends: Fix windows errors by optimizing your registry

Mark Salsbery [MVP] wrote:
"Ben Voigt [C++ MVP]" <rbv@xxxxxxxxxxxxx> wrote in message
news:ex5QaOhKJHA.1160@xxxxxxxxxxxxxxxxxxxxxxx
Mark Salsbery [MVP] wrote:
"Howard Swope" <howard_swopeAThms3DOTcom> wrote in message
news:Oyv$tJgJJHA.1308@xxxxxxxxxxxxxxxxxxxxxxx

Declaring variables with stack semantics is one of the Advertised
features in C++ CLI

Not member variables.

It makes no sense to have member variables with stack semantics -
there's no "stack" involved unless you have an actual object.

I definitely do NOT agree with this. Stack semantics give you all
the correct calls to Dispose in all the corner cases, like
exceptions thrown in constructor initializer lists, automatically. Stack
semantics is perhaps not the best description -- scoped
variable lifetime (vs dynamic lifetime) might be better.


Hi Ben,

How does scoped variable lifetime apply to member variables?
The scoped variable lifetime of a member variable is determined by
it's containing class, right?

For this to work, the compiler would need to generate the gcnew calls
for the member variables. That means one would be stuck with a
parameterless constructor, unless some (possibly obscure) construct
syntax was added to the language to allow other constructor calls for
these "automatic" variables.

Whoa, is someone impersonating the real Mark, the C++ MVP? Or are you just
having an off day?

Because ctor initializer-lists are hardly obscure and fully standard. I
even mentioned them in my post.

The same thing effectively happens for members of native types which take
parameters to their constructors, except it's use of placement new vs gcnew,
and the managed type isn't actually inside the containing class (although
they will be placed contiguously in memory under the most obvious
implementation of the managed heap, which is a stack not a heap anyway).


I imagine a similar argument occurred when this feature of the
language was designed. :)

Is it a bug or by design?

I still think, given the way it currently works, that stack semantics
on ref class member variables shouldn't be allowed.

Mark


.

Relevant Pages

  • Re: Bug in C++ /CLI 2005
    ... It makes no sense to have member variables with stack semantics - there's no "stack" involved unless you have an actual object. ... And, as mentioned by others, you can't expect a member marked to be handled at ALL by the deserialize code in the framework. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Bug in C++ /CLI 2005
    ... It makes no sense to have member variables with stack semantics - ... Stack semantics give you all the correct calls to Dispose in all the corner cases, like exceptions thrown in constructor initializer lists, automatically. ... Stack semantics is perhaps not the best description -- scoped variable lifetime might be better. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Bug in C++ /CLI 2005
    ... features in C++ CLI ... It makes no sense to have member variables with stack semantics - ... not the best description -- scoped variable lifetime ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Rules for constructors
    ... Alex Hunsley wrote: ... > constructor for A, the initialisation of the member variables in class B ... realising of GUI items from a constructor. ...
    (comp.lang.java.programmer)
  • Rules for constructors
    ... This is because the constructor of B calls super, and by ... the initialisation of the member variables in class B ... (or else they will be overridden causing chaos as I have experienced ... overridden methods should not access member variables that are ...
    (comp.lang.java.programmer)