new principle of division between structures and classes

Weed resume755 at mail.ru
Sun Jan 11 00:40:05 PST 2009


Denis Koroskin пишет:
> On Sun, 11 Jan 2009 05:04:11 +0300, Weed <resume755 at mail.ru> wrote:
> 
>> Bill Baxter пишет:
>>> 2009/1/11 Weed <resume755 at mail.ru>:
>>>> Bill Baxter пишет:
>>>>
>>>>> But since classes can be polymorphic, value copying gets you into
>>>>> slicing problems.  That's why value copying is disabled to begin with.
>>>>>  So disabling value copies is a good thing.
>>>> It is not always a good thing.
>>>
>>> Yeh, I just mean there is some merit in disabling value copies.  But I
>>> don't rule out the possibility that there may be an even better way
>>> that banning them altogether.
>>>
>>>> I propose to prohibit only the copying by value of the base type to
>>>> derivative type
>>>
>>> Ok, this is key.  How do you propose to do this?  In general it
>>> requires a runtime check, I think.
>>> And I think you need to say that you prohibit copying unless
>>> typeA==typeB exactly.  If you allow copying either way between base
>>> and derived you are asking for trouble.
>>>
>>> But still given
>>>   Base x = get_one();
>>>   Base y = get_another();
>>>   *x = *y; // presumed value copy syntax
>>>
>>> you have no way in general to know that x and y are really both a Base
>>> at compile time.  So you must have a run-time check there.  Perhaps it
>>> could be omitted for -release builds, though.
>>
>> It can lead to a difficult and non-reproduceable errors than old
>> C++-style splitting.
>>
>> It is possible to try to prohibit assignment of the dereferenced
>> pointers? Simply to prohibit assignment too it is possible, essentially
>> it changes nothing.
>>
> 
> Err.. I don't get what you say. The *x = *y is just one of the possible
> syntaxes, nothing else.
> 

(I have incorrectly expressed)

If dereferencing was not used in lvalue or rvalue and is both a classes
by value it is possible to assignment, except cases when the base type
to the derivative is assigned.

Example:

class C {}
class C2 : C {}

C c();
C2 c2();

C* c_p = &c;
C2* c2_p = &c2;

c = c2; // ok
c2 = c; // err
*c_p = *c2_p; // err
*c2_p = *c_p; // err
c2 = *c2_p; // err

and:
c = c2 + *c2_p; // ok

>>>>> And that's also the problem with putting scope'd things inside another
>>>>> class or an array.  Since they don't have value semantics,
>>>> Yes, this is what I mean
>>>
>>> So assuming you had this, the important question is what would you do
>>> with it?
>>
>> The most difficult. My arguments:
>>
>> 1. Problem of a choice of correct type for the object. A mathematical
>> matrix - a classical example. A class it should be or structure?
>>
>> My offer without serious consequences allows to move solution of this
>> problem from a design stage to a programming stage - is it will be
>> simple by replacement keyword class to struct.
>>
> 
> Having the same syntax for both classes and struct is a nice goal, I agree.
> But it should be taken as a different issue and solved separately, too.

So I offer: the inheritance of structures this one of offers, which in
itself it seems insignificant, but useful if to make classes by value.

>>
>> 2. Performance increases. It is not necessary to allocate at the
>> slightest pretext memory in a heap.
>>
>>
>> 3. I offer syntax which presumably does not break an existing code.
>> + On how many I understand, in the existing compiler all necessary for
>> implementation already is, a problem only in syntax addition.
>>
>>
>> 4. Java and C# also uses objects by reference? But both these of
>> language are interpreted. I assume that the interpreter generally with
>> identical speed allocates memory in a heap and in a stack, therefore
>> authors of these languages and used reference model.
>>
> 
> Neither of these languages are interpreted, they both are compiled into
> native code at runtime.

Oh!:) but I suspect such classes scheme somehow correspond with
JIT-compilation.

> 
>> D is compiled language and to borrow reference model incorrectly. In D
>> the programmer should have possibility most to decide where to place
>> object.
>>
>>
>>> You still have the problem that the current system works pretty well.
>>> And has a lot of history.  So you need a very compelling use case to
>>> convince Walter that something should change.
>>
>> Thus, actually Java and C# systems works pretty well. And they has a lot
>> of history. But not D.
>>
> 
> DMD 0.001 was released 7 years ago. Long enough, I think.

Yes, I know.
I hint at that that it seems this scheme have copied because it is
popular but have not considered characteristic for C++-like compiled
language nuances.



More information about the Digitalmars-d mailing list