Don пишет:
> Weed wrote:
>> Weed пишет:
>>> Bill Baxter пишет:
>>>> On Sun, Feb 22, 2009 at 1:02 AM, Weed <resume755@mail.ru> wrote:
>>>>> Bill Baxter пишет:
>>>>>> 2009/2/21 Weed <resume755@mail.ru>:
>>>>>>> Weed пишет:
>>>>>>>> Bill Baxter пишет:
>>>>>>>>
>>>>>>>>> Why don't you just show us the class in the way you would like to
>>>>>>>>> write it in C++, and we'll show you how to write it in D, or
>>>>>>>>> finally
>>>>>>>>> agree with you that it's not possible.   But as long as you
>>>>>>>>> continue
>>>>>>>>> to be hand-wavy about "common base classes" we're at a bit of an
>>>>>>>>> impasse.  So far everyone thinks D can do what you want it to
>>>>>>>>> do based
>>>>>>>>> on your vague descriptions.
>>>>>>> As I said, you can write everything using "goto" and "if".
>>>>>>>
>>>>>>> ...But why you do not like the original example of this thread?
>>>>>> Please post again.  I don't seem to recall any detailed example.
>>>>>>
>>>>>> --bb
>>>>> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=83506
>>>>>
>>>> You should use a struct there!   Your code does not show you doing
>>>> anything that would even remotely suggest using a class is worthwhile.
>>>>  You're doing value operations on value types.  That's what structs
>>>> are for.
>>> 
>>> Why?
>>>
>>> What if I have not substantiated the fact that c1 is a class I should use there a structure?
>>>
>>> Used in D a model of placement classes only in heap have a rule "if you made the class and trying to pass it by value is somewhere in your code, there is a design error?
>>
>> Explains why the question is given in this form:
>>
>> I am received or wrote a classes. Is it right to overload the operator
>> opAdd and use them? I think yes.
>> But why not allow this operation at the same speed that allows C++?
> 
> Actually, in D, it's really difficult to give a class value semantics.
> If a, b are members of some class, consider
> (1) a = a + b;
> (2) a += b;
> It is nearly impossible to efficiently make both of these have the same
> effect!!
> You can only do it with either copy-on-write, ie, even case (2) always
> allocates; or by using a proxy class.
> This is something which I consider to be a serious problem.
> Much more serious than the speed issue.

We already talked about this idea:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81432
(see text "It is possible to think up other example where there is no
overload:")

Weed wrote:
> Don пишет:
>> Weed wrote:
>>> naryl пишет:
>>>
>>>>>>>>> --bb
>>>>>>>> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=83506
>>>>>>>>
>>>>>>> You should use a struct there!   Your code does not show you doing
>>>>>>> anything that would even remotely suggest using a class is
>>>>>>> worthwhile.
>>>>>>>  You're doing value operations on value types.  That's what structs
>>>>>>> are for.
>>>>>>     Why?
>>>>>>
>>>>>> What if I have not substantiated the fact that c1 is a class I should
>>>>>> use there a structure?
>>>>>>
>>>>>> Used in D a model of placement classes only in heap have a rule "if
>>>>>> you
>>>>>> made the class and trying to pass it by value is somewhere in your
>>>>>> code,
>>>>>> there is a design error?
>>>>> Explains why the question is given in this form:
>>>>>
>>>>> I am received or wrote a classes. Is it right to overload the operator
>>>>> opAdd and use them? I think yes.
>>>>>
>>>>> But why not allow this operation at the same speed that allows C++?
>>>> If you pass it by value you'll lose polymorphism.
>>> Debatable
>>>
>>> By the way, in my example the transfer class by value is not
>>> important(!), it is important to create a temporary class on the stack.
>>> Then we can pass a reference without problem (C++ allows this through
>>> the "&")
>> Sure, but you're not using polymorphism.
>>
> 	
> There is no, but the same object can be used in other places, including
> the polymorphism
> 
>>>> That must mean that you inherit that class only to avoid duplicating
>>>> code. And that is easily done with template mixins.
>>> It is possible that this polymorphism is not needed and should be
>>> prohibited for operations by value. The class is ready, why it should
>>> not be used and have to redo it?
>>>
>>> Can not think about changing when the class is ready - he could have
>>> enormous complexity and hierarchy.
>> This is the fundamental tradeoff at the heart of the matter.
>> In D, the choice of whether an object will use polymorphism or not is
>> considered a fundamental design decision.
> 
> This is awful! Much easier to give to the application programmer to
> decide how it will use the derived class somewhere. Such a division
> should be a basic principle of designing a complex program.

Even in C++, all of your base classes should be abstract.
If you want to move between polymorphism and non-polymorphism in C++, it's a non-trivial refactoring.


>> D gets significant benefits
>> from this.
> 
> Benefits:
> 
> 1. Disappeared slicing
> 2. ?

That's not what I had in mind at all. I don't think slicing is such a big deal in itself; it's just a symptom.

>> C++ allows you to defer the decision, but it doesn't come for
>> free.
> 
> Clarify what you mean?
> 
>> (Generally speaking, statically typed languages do force you to make
>> more decisions at design time). Notice that you have little gotchas in
>> C++, such as the need to declare a virtual destructor on every struct
>> you think you might "someday" use polymorphically. It sticks around,
>> even if it never gets used.
>> One of the nice things about a D struct, compared to a C++ struct, is
>> that you *know* it's simple, it never has that kind of baggage.
>>
>> D does choose different trade-offs from C++. If it was always the same,
>> it'd be the same language!
> 
> There is no need to compare the structs from C++ and D. In fact, in C++
> classes and structures are the same.

Well, although the keywords are identical, there are two different varieties of C++ objects muddied together: PODs, and polymorphic types. You declare a type to be polymorphic by declaring a virtual function inside it. In D, you do it with the 'class' keyword.


> I like D's idea of POD structs + without them you can not ensure
> compatibility with C, but it is very important.
> 
> Now we are talking about classes.
> 
> In C++ classes with the same problems, such as what they do not have a
> common base class (Object in D). Passing classes by value is not a
> problem - is an advantage.

Passing a polymorphic class by value rarely makes sense.
You can't get (runtime) polymorphism unless you go through a pointer.

> As I said earlier, the presence of pointers is also an advantage,
> although they are dangerous and can lead to complex bugs.

I don't think that is analagous. The issue is not primarily about with the 'danger' of passing classes by value. It's about clear separation of concepts.

>> BTW, if you're concerned about performance, you'd do well to use
>> compile-time polymorphism rather than run-time, when possible. D's
>> metaprogramming support leaves C++ for dead.
>>
> 
> I think if there was a language with all the features as in D but with
> the model objects from C++, he would have won great popularity. Mainly
> it would have moved C++ developers who are satisfied with the model
> classes of C++ but not satisfied with the absence of other modern
> features: metaprogramming, contracts, delegates, closures etc.

I think D will get adequate popularity once it has a good library situation. It only needs language changes inasfaras they are necessary for library design.

Don пишет:

>>>>> That must mean that you inherit that class only to avoid duplicating code. And that is easily done with template mixins.
>>>> It is possible that this polymorphism is not needed and should be prohibited for operations by value. The class is ready, why it should not be used and have to redo it?
>>>>
>>>> Can not think about changing when the class is ready - he could have enormous complexity and hierarchy.
>>> This is the fundamental tradeoff at the heart of the matter.
>>> In D, the choice of whether an object will use polymorphism or not is
>>> considered a fundamental design decision.
>>
>> This is awful! Much easier to give to the application programmer to decide how it will use the derived class somewhere. Such a division should be a basic principle of designing a complex program.
> 
> Even in C++, all of your base classes should be abstract.

Why?

> If you want to move between polymorphism and non-polymorphism in C++, it's a non-trivial refactoring.
> 
> 
>>> D gets significant benefits
>>> from this.
>>
>> Benefits:
>>
>> 1. Disappeared slicing
>> 2. ?
> 
> That's not what I had in mind at all. I don't think slicing is such a big deal in itself; it's just a symptom.
> 

What do you mean?

>>> C++ allows you to defer the decision, but it doesn't come for free.
>>
>> Clarify what you mean?
>>
>>> (Generally speaking, statically typed languages do force you to make
>>> more decisions at design time). Notice that you have little gotchas in
>>> C++, such as the need to declare a virtual destructor on every struct
>>> you think you might "someday" use polymorphically. It sticks around,
>>> even if it never gets used.
>>> One of the nice things about a D struct, compared to a C++ struct, is
>>> that you *know* it's simple, it never has that kind of baggage.
>>>
>>> D does choose different trade-offs from C++. If it was always the same, it'd be the same language!
>>
>> There is no need to compare the structs from C++ and D. In fact, in C++ classes and structures are the same.
> 
> Well, although the keywords are identical, there are two different varieties of C++ objects muddied together: PODs, and polymorphic types. You declare a type to be polymorphic by declaring a virtual function inside it. In D, you do it with the 'class' keyword.
> 
> 
>> I like D's idea of POD structs + without them you can not ensure compatibility with C, but it is very important.
>>
>> Now we are talking about classes.
>>
>> In C++ classes with the same problems, such as what they do not have a common base class (Object in D). Passing classes by value is not a problem - is an advantage.
> 
> Passing a polymorphic class by value rarely makes sense.
> You can't get (runtime) polymorphism unless you go through a pointer.

Or reference (&). Thus, even polymorphic class on stack can be used
safely in C++.

> 
>> As I said earlier, the presence of pointers is also an advantage, although they are dangerous and can lead to complex bugs.
> 
> I don't think that is analagous. The issue is not primarily about with the 'danger' of passing classes by value. It's about clear separation of concepts.
> 
>>> BTW, if you're concerned about performance, you'd do well to use compile-time polymorphism rather than run-time, when possible. D's metaprogramming support leaves C++ for dead.
>>>
>>
>> I think if there was a language with all the features as in D but with the model objects from C++, he would have won great popularity. Mainly it would have moved C++ developers who are satisfied with the model classes of C++ but not satisfied with the absence of other modern features: metaprogramming, contracts, delegates, closures etc.
> 
> I think D will get adequate popularity once it has a good library situation. It only needs language changes inasfaras they are necessary for library design.

What D better than Java or C#?

Weed wrote:
> As a result, classes will be slow, or require more code to achieve
> speeds comparable to C++.
> 
> That is actually a model of classes D harder than C++.

Yes, C++ offers more unsafe optimizations than D.

Weed wrote:
> Don пишет:
> 
>>>>>> That must mean that you inherit that class only to avoid duplicating
>>>>>> code. And that is easily done with template mixins.
>>>>> It is possible that this polymorphism is not needed and should be
>>>>> prohibited for operations by value. The class is ready, why it should
>>>>> not be used and have to redo it?
>>>>>
>>>>> Can not think about changing when the class is ready - he could have
>>>>> enormous complexity and hierarchy.
>>>> This is the fundamental tradeoff at the heart of the matter.
>>>> In D, the choice of whether an object will use polymorphism or not is
>>>> considered a fundamental design decision.
>>> This is awful! Much easier to give to the application programmer to
>>> decide how it will use the derived class somewhere. Such a division
>>> should be a basic principle of designing a complex program.
>> Even in C++, all of your base classes should be abstract.
> 
> Why?

See, for example,

http://www.artima.com/intv/modern.html

> 
>> If you want to move between polymorphism and non-polymorphism in C++,
>> it's a non-trivial refactoring.
>>
>>
>>>> D gets significant benefits
>>>> from this.
>>> Benefits:
>>>
>>> 1. Disappeared slicing
>>> 2. ?
>> That's not what I had in mind at all. I don't think slicing is such a
>> big deal in itself; it's just a symptom.
>>
> 
> What do you mean?

Language complexity.

> 
>>>> C++ allows you to defer the decision, but it doesn't come for
>>>> free.
>>> Clarify what you mean?
>>>
>>>> (Generally speaking, statically typed languages do force you to make
>>>> more decisions at design time). Notice that you have little gotchas in
>>>> C++, such as the need to declare a virtual destructor on every struct
>>>> you think you might "someday" use polymorphically. It sticks around,
>>>> even if it never gets used.
>>>> One of the nice things about a D struct, compared to a C++ struct, is
>>>> that you *know* it's simple, it never has that kind of baggage.
>>>>
>>>> D does choose different trade-offs from C++. If it was always the same,
>>>> it'd be the same language!
>>> There is no need to compare the structs from C++ and D. In fact, in C++
>>> classes and structures are the same.
>> Well, although the keywords are identical, there are two different
>> varieties of C++ objects muddied together: PODs, and polymorphic types.
>> You declare a type to be polymorphic by declaring a virtual function
>> inside it. In D, you do it with the 'class' keyword.
>>
>>
>>> I like D's idea of POD structs + without them you can not ensure
>>> compatibility with C, but it is very important.
>>>
>>> Now we are talking about classes.
>>>
>>> In C++ classes with the same problems, such as what they do not have a
>>> common base class (Object in D). Passing classes by value is not a
>>> problem - is an advantage.
>> Passing a polymorphic class by value rarely makes sense.
>> You can't get (runtime) polymorphism unless you go through a pointer.
> 
> Or reference (&). Thus, even polymorphic class on stack can be used
> safely in C++.

Same thing. You're either not using value semantics, or not using polymorphism. Not both at once.

> 
>>> As I said earlier, the presence of pointers is also an advantage,
>>> although they are dangerous and can lead to complex bugs.
>> I don't think that is analagous. The issue is not primarily about with
>> the 'danger' of passing classes by value. It's about clear separation of
>> concepts.
>>
>>>> BTW, if you're concerned about performance, you'd do well to use
>>>> compile-time polymorphism rather than run-time, when possible. D's
>>>> metaprogramming support leaves C++ for dead.
>>>>
>>> I think if there was a language with all the features as in D but with
>>> the model objects from C++, he would have won great popularity. Mainly
>>> it would have moved C++ developers who are satisfied with the model
>>> classes of C++ but not satisfied with the absence of other modern
>>> features: metaprogramming, contracts, delegates, closures etc.
>> I think D will get adequate popularity once it has a good library
>> situation. It only needs language changes inasfaras they are necessary
>> for library design.
> 
> What D better than Java or C#?

I'm wasting my time here. I'll not make any further comments on this subject.

Christopher Wright пишет:
> Weed wrote:
>> As a result, classes will be slow, or require more code to achieve speeds comparable to C++.
>>
>> That is actually a model of classes D harder than C++.
> 
> Yes, C++ offers more unsafe optimizations than D.


Straight to the point!
I am choosing unsafe but fast code. Unsafe at so much on how much is
unsafe any code on C++.

I think the issue is closed. :)

Don пишет:
> Weed wrote:
>> Don пишет:
>>
>>>>>>> That must mean that you inherit that class only to avoid duplicating code. And that is easily done with template mixins.
>>>>>> It is possible that this polymorphism is not needed and should be prohibited for operations by value. The class is ready, why it should not be used and have to redo it?
>>>>>>
>>>>>> Can not think about changing when the class is ready - he could have enormous complexity and hierarchy.
>>>>> This is the fundamental tradeoff at the heart of the matter.
>>>>> In D, the choice of whether an object will use polymorphism or not is
>>>>> considered a fundamental design decision.
>>>> This is awful! Much easier to give to the application programmer to decide how it will use the derived class somewhere. Such a division should be a basic principle of designing a complex program.
>>> Even in C++, all of your base classes should be abstract.
>>
>> Why?
> 
> See, for example,
> 
> http://www.artima.com/intv/modern.html

It did not say how that all base classes should be abstract


> 
>>
>>> If you want to move between polymorphism and non-polymorphism in C++, it's a non-trivial refactoring.
>>>
>>>
>>>>> D gets significant benefits
>>>>> from this.
>>>> Benefits:
>>>>
>>>> 1. Disappeared slicing
>>>> 2. ?
>>> That's not what I had in mind at all. I don't think slicing is such a big deal in itself; it's just a symptom.
>>>
>>
>> What do you mean?
> 
> Language complexity.
> 

We do not schoolgirls! :) Who is afraid of the complexity should use BASIC.

>>
>>>>> C++ allows you to defer the decision, but it doesn't come for free.
>>>> Clarify what you mean?
>>>>
>>>>> (Generally speaking, statically typed languages do force you to make
>>>>> more decisions at design time). Notice that you have little gotchas in
>>>>> C++, such as the need to declare a virtual destructor on every struct
>>>>> you think you might "someday" use polymorphically. It sticks around,
>>>>> even if it never gets used.
>>>>> One of the nice things about a D struct, compared to a C++ struct, is
>>>>> that you *know* it's simple, it never has that kind of baggage.
>>>>>
>>>>> D does choose different trade-offs from C++. If it was always the
>>>>> same,
>>>>> it'd be the same language!
>>>> There is no need to compare the structs from C++ and D. In fact, in C++ classes and structures are the same.
>>> Well, although the keywords are identical, there are two different varieties of C++ objects muddied together: PODs, and polymorphic types. You declare a type to be polymorphic by declaring a virtual function inside it. In D, you do it with the 'class' keyword.
>>>
>>>
>>>> I like D's idea of POD structs + without them you can not ensure compatibility with C, but it is very important.
>>>>
>>>> Now we are talking about classes.
>>>>
>>>> In C++ classes with the same problems, such as what they do not have a common base class (Object in D). Passing classes by value is not a problem - is an advantage.
>>> Passing a polymorphic class by value rarely makes sense.
>>> You can't get (runtime) polymorphism unless you go through a pointer.
>>
>> Or reference (&). Thus, even polymorphic class on stack can be used
>> safely in C++.
> 
> Same thing. You're either not using value semantics, or not using polymorphism. Not both at once.

If you needed polymorphism you should use references or pointers, where necessary performance you use value semantics. C++ allows both options, D - no.

> 
>>
>>>> As I said earlier, the presence of pointers is also an advantage, although they are dangerous and can lead to complex bugs.
>>> I don't think that is analagous. The issue is not primarily about with the 'danger' of passing classes by value. It's about clear separation of concepts.
>>>
>>>>> BTW, if you're concerned about performance, you'd do well to use compile-time polymorphism rather than run-time, when possible. D's metaprogramming support leaves C++ for dead.
>>>>>
>>>> I think if there was a language with all the features as in D but with the model objects from C++, he would have won great popularity. Mainly it would have moved C++ developers who are satisfied with the model classes of C++ but not satisfied with the absence of other modern features: metaprogramming, contracts, delegates, closures etc.
>>> I think D will get adequate popularity once it has a good library situation. It only needs language changes inasfaras they are necessary for library design.
>>
>> What D better than Java or C#?
> 
> I'm wasting my time here. I'll not make any further comments on this subject.

Okay

Weed:
> We do not schoolgirls! :) Who is afraid of the complexity should use BASIC.

I like D1 mostly because it's quite less complex that C++, that's the first thing I ask to a new language like D. Complexity "kills".
You probably don't want D, you want ATS:
http://www.ats-lang.org/

Bye,
bearophile

bearophile пишет:
> Weed:
>> We do not schoolgirls! :) Who is afraid of the complexity should use BASIC.
> 
> I like D1 mostly because it's quite less complex that C++, that's the first thing I ask to a new language like D. Complexity "kills".

I am cite myself:
"That is actually a model of classes D harder than C++."

> You probably don't want D, you want ATS: http://www.ats-lang.org/

There uses preprocessor. It is wrong.

Weed wrote:
> Don пишет:
>> Language complexity.
>>
> 
> We do not schoolgirls! :)

I guess superdan might disagree here :o).

Andrei