byval keyword to make objects act as value types

BC NOTmi_emayl_adrez at hotmail.com.remove.not
Sat Dec 22 21:40:34 PST 2007


On Sun, 23 Dec 2007 05:09:43 -0000, BC  
<NOTmi_emayl_adrez at hotmail.com.remove.not> wrote:

> On Sun, 23 Dec 2007 04:01:30 -0000, Christopher Wright  
> <dhasenan at gmail.com> wrote:
>
>> BC wrote:
>>> so that 'byval MyClass' is a new type that acts like MyClass in all  
>>> ways (ie. is polymorphic) except that it gets dupped on non-const  
>>> assignment from other byval MyClasses and normal MyClasses. possibly  
>>> also on assignment to normal MyClasses. this would require that it  
>>> *has* a dup method, or maybe a copy constructor
>>
>> Perhaps this would be better as a class declaration modifier?
>>
>> byval class Foo {} // acts like a struct
>>
>> Or:
>> valueclass Foo {}
>>
>> It would be simpler, at least: an opAssign overload.
>>
> true, it's just that I don't buy that classes are always either value or
> reference types, I think flexibility is desirable. you could still do
>
> class Foo{}
> alias byval Foo VFoo;
>
>>> byval Base b = new Derived;
>>>  despite the name 'byval' b actually holds a reference to a copy of  
>>> Derived, so slicing is avoided.
>>> or, if that's too inefficient perhaps the linker can figure out the  
>>> size of the largest class derived from Base and allocate that much on  
>>> the stack/inside a containing class.
>>
>> If we get this, I'm going to ask for virtual template methods in  
>> classes again. It's not happening.
>>
> no, i'm not holding my breath. it could for final classes though.
>
>>> myFunction(ref Base arg)
>>> {
>>>    ++arg;
>>> }
>>>  myFunction(b)
>>>  i'm thinking it should be overridable so that the above function  
>>> *does* change the value of b
>>
>> Besides which, arg isn't assigned to...
>>
>> void func(ref ValueClass arg) {
>>     arg = new ValueClass();
>> }
>>
i didn't realise you could have a reference to a reference

>>> question: are calls to final class member functions non-virtual?
>>
>> Well, yes. But do you mean, are they found in the vtbl? You could check:
>> class Foo {
>>     final void a(){}
>>     final void b(){}
>>     final void c(){}
>> }
>>
>> assert (Foo.classinfo.vtbl.length == Object.classinfo.vtbl.length);
>>
> i should have said 'member functions of final classes'. both are found
> in the vtbl. i was wondering how close to struct behaviour we can bring
> classes.
>
>>> i notice the tango iterators are classes. surely we want to use  
>>> iterators as value types... this way, we can.
>>>  alternatively, since scope objects are a bit like value types  
>>> already, perhaps we can just add the functionality to that.
>>
>> Ugh. No.
>>
> no? currently the spec says you can't assign to them (although i see now
> that you can, if you like access violations), so i thought that might be
> the plan.
>
don't forget that if you assign it to something else such as a scope object
inside another class, you get a copy, which won't get destroyed,
so they could then outlast the function scope and be just like a value
type as far as i can see.

>>> then, we just need to return refs from functions, and it's goodbye C++!
>




More information about the Digitalmars-d mailing list