Ok, I'll buy that. Sort of. BUT --- doesn't this feature reverse the concept
of type-checking? One of the reasons for passing something by value is so
the original can't be changed. Doesn't this feature violate that concept?
In my example code, the call Test_Method(inf o) looks like it will pass a
value. But Test_Method is passed a pointer, so it can validly be written
with changing what it is passed as a legal method. For example:
void Test_Method( Test_Struct^ info )
{
info->x = 1 ;
}
I just tried this, and if passed the value the code doesn't change the value
of 'x', but if passed a pointer it does. This caused me a half-day of
looking at the code, since I saw the value change in the method and assumed
it remained changed outside the method. But when I finally looked at 'info'
outside the call it had changed, at which point I realized I had forgotten
the '%' and was passing the value instead of the pointer.
AT THE VERY LEAST THIS SHOULD GENERATE A LOW-LEVEL WARNING.
This also brings up the concept that If I HAD overloaded Test_Method() with
a version that DID take a value instead of a pointer, note that my code
would start executing in this new version all of a sudden. So code that
'worked' because it was incorrectly going to a method assuming a pointer now
goes to the new one made for a value type, and the code stops working for
reasons that seem bizarre. And now one must look at code that has not been
changed but is reacting differently since some of the calls it it have been
're-routed' without any warning.
These scenario's couldn't happen if this flagged an error (or a warning)
instead of being a feature...
[==P==]
"Holger Grund" <ho**********@r emove.ix-n.net> wrote in message
news:%2******** *********@TK2MS FTNGP12.phx.gbl ...
"Peter Oliphant" <po*******@Roun dTripInc.com> wrote
value struct Test_Struct
{
long x ;
} ;
[..] Test_Struct info ;
Test_Method( info ) ; // shouldn't compile, but does!!!
Test_Method( %info ) ; // ok
}
void Test_Method( Test_Struct^ info ) {}
} ;
I think it's feature. That's "implicit boxing". There's
a boxing conversion from every V to V^ to support
certain types of polymorphism.
For instance, you couldn't write
Console::WriteL ine( info );
without it.
You can think of every Value type having a magic
member
value struct V { V^ operator() const; };
Now there's a conversion sequence from gclvalue V
to Object^ via the boxing conversion followed by
the base class handle conversion.
-hg