Re: Bug in C++ /CLI 2005

Tech-Archive recommends: Speed Up your PC by fixing your registry

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

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

--
Mark Salsbery
Microsoft MVP - Visual C++



.

Relevant Pages

  • Re: Bug in C++ /CLI 2005
    ... It makes no sense to have member variables with stack semantics - ... exceptions thrown in constructor initializer lists, ... Whoa, is someone impersonating the real Mark, the C++ MVP? ...
    (microsoft.public.dotnet.languages.vc)
  • 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
    ... 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)