Re: I think this is a bug...

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(info) 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" <holger.grund@xxxxxxxxxxxxxxx> wrote in message
news:%235yuIEo%23FHA.140@xxxxxxxxxxxxxxxxxxxxxxx
> "Peter Oliphant" <poliphant@xxxxxxxxxxxxxxxx> 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::WriteLine( 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
>
>


.

Relevant Pages

  • Re: Inheriting from std::vector?
    ... >> (through a pointer to the base class object). ... >> It's illogical to ban usage of a feature just because that feature ... One should learn how to use them and never abuse them at all. ...
    (comp.lang.cpp)
  • Re: new laptop
    ... near-essential feature if the touchpad has to be where typing hands ... tweaks for my touchpad has like a zillion settings on it. ... them turns the pointer off while you are typing. ...
    (uk.comp.sys.laptops)
  • Re: PAPI in the ports
    ... But to have a such feature on a production system is ... If I get a problem I can easily debug ... If you cast a pointer to an integer, ... it becomes a struct. ...
    (freebsd-performance)
  • Re: Out-of-bounds nonsense
    ... programming languages like C and C++, ... being illegal is that the "ranged-pointer" feature I described above is ... I, for one, would find such a pointer very useful for debugging. ...
    (comp.lang.c)