View mode: basic / threaded / horizontal-split · Log in · Help
February 24, 2009
Re: Old problem with performance
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:")
February 24, 2009
Re: Old problem with performance
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.
February 24, 2009
Re: Old problem with performance
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#?
February 24, 2009
Re: Old problem with performance
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.
February 25, 2009
Re: Old problem with performance
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.
February 25, 2009
Re: Old problem with performance
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. :)
February 25, 2009
Re: Old problem with performance
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
February 25, 2009
Re: Old problem with performance
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
February 25, 2009
Re: Old problem with performance
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.
February 25, 2009
Re: Old problem with performance
Weed wrote:
> Don пишет:
>> Language complexity.
>>
> 
> We do not schoolgirls! :)

I guess superdan might disagree here :o).

Andrei
1 2 3 4
Top | Discussion index | About this forum | D home