December 30, 2008
Weed пишет:
> Andrei Alexandrescu пишет:
>> Weed wrote:
>> [about structs vs. classes]
>>> It is very a pity.
>>> My small opinion: it is impossible to reduce performance for struggle
>>> against potential errors - such languages already are, it more
>>> high-level. It how to refuse pointers because they are dangerous,
>>> difficult for beginners and without them it is possible to make any
>>> algorithm.
>> It's attractive to deal in absolutes, but also dangerous. When C came about, naysayers complained that it was consistently 30% slower than assembler, and generated larger code by an even higher margin. Then, some asked, what would you choose, one OS that's cool because it's written in C, or one that's one third faster? and so on. What people have forgotten by now is that C *was* high level. And it *did* incur a performance hit. It also had desirable properties that overcame that hit.
>>
> 
> Can in C# (it uses as far as I know too such sharing) such approach and it is justified - microsoft accelerates replacement of hardware for new OS. :) But we after all not blindly copy C#?
> 
> After all this problem can be solved, IMHO.
> I suggest to make so:
> 
> 1. To leave structures in that kind in which they is (POD)
> 
> 2. To permit classes declaration such what they in C++
> 
> 3. To permit transfer the classes on value (for compulsory pass by reference and for declaration through "new" now we have "ref" keyword)
> 
> 3. To check slicing during compilation. It is possible?

For example prohibit assigning on value to the types, not being base or this type

> 
> 4. "scope" for classes to deprecate as superfluous
> 
> 
> In that case there will be problems?
> 
> 
>>> What is D?
>>> D is a general purpose systems and applications programming language. It
>>> is a higher level language than C++, but *retains* the ability to write
>>> high performance code and interface directly with the operating system
>>> API's and with hardware.
>>> http://www.digitalmars.com/d/2.0/overview.html
>> Probably the worst thing that could happen to that description is it Kafka-esquely morphing into a dogma.
> 
> Seriously, I trusted it
January 01, 2009
Andrei Alexandrescu wrote:
> Don wrote:
>> Andrei Alexandrescu wrote:
>>> Don wrote:
>>>> Christopher Wright wrote:
>>>>> Don wrote:
>>>>>> The creation of temporaries during expressions is something I'm currently working on solving. The case you mentioned is addressed by a proposal I made long ago:
>>>>>
>>>>> The easiest way is to add an intermediate struct. This takes a fair bit of manual effort, though, and prevents you from using auto.
>>>>
>>>> That particular case is the easiest possible one. The case x = y - x, for example, is much more difficult to recognize.
>>>>
>>>>>
>>>>> Essentially, you need a struct MyClassAddition that just records operands. Then give it an implicit cast to MyClass that does the work. This is an ugly solution because you need to duplicate the operator overloads on MyClassXXX as well as MyClass.
>>>>>
>>>>> I believe I got this solution from an article by Andrei. It should work pretty well for classes that define few overloads.
>>>>
>>>> I'm talking about a language solution. I want to solve this for the general case.
>>>
>>> Don't forget that the case you are solving is not general enough because  you are focusing on eliminating temporaries, which is only part of the story. I suggest you make place in your thoughts for loop fusion.
>>
>> Yes. That's the classic problem for matrices, but I'm still trying to work out if it is really a general problem. I was hoping to see some new use cases, but none so far.
> 
> I think the matrices case is important enough to make it its own class of problems. For example, bitmap processing is another instance of matrix usefulness, just one that doesn't usually jump to mind when thinking of matrices.

Yes, bitmap processing almost always uses the adjacent pixels, which doesn't translate naturally to BLAS operations.
The disturbing thing about both these use cases is that you normally want to involve other operations, such as dot product, which aren't operators. So an optimal solution is pretty elusive.

> Then how about BigInt and arbitrary precision numbers? Wouldn't fusing some operations together be useful?

Not really, since they are rarely cache-limited.
Combining slicing operations with arithmetic might be interesting, but it's pretty obscure I think.
January 02, 2009
bearophile wrote:
> But probably C compilers (and JavaVirtualMachines) have improved from
> the first ones, so the performance difference is now smaller. And in
> GCC if you use C you find lot of intrinsics (for example one for each
> new SIMD instruction) that mitigates the problem even more.

Not that much smaller.

January 04, 2009
Weed пишет:
> Weed пишет:
>> Andrei Alexandrescu пишет:
>>> Weed wrote:
>>> [about structs vs. classes]
>>>> It is very a pity.
>>>> My small opinion: it is impossible to reduce performance for struggle
>>>> against potential errors - such languages already are, it more
>>>> high-level. It how to refuse pointers because they are dangerous,
>>>> difficult for beginners and without them it is possible to make any
>>>> algorithm.
>>> It's attractive to deal in absolutes, but also dangerous. When C came about, naysayers complained that it was consistently 30% slower than assembler, and generated larger code by an even higher margin. Then, some asked, what would you choose, one OS that's cool because it's written in C, or one that's one third faster? and so on. What people have forgotten by now is that C *was* high level. And it *did* incur a performance hit. It also had desirable properties that overcame that hit.
>>>
>> Can in C# (it uses as far as I know too such sharing) such approach and it is justified - microsoft accelerates replacement of hardware for new OS. :) But we after all not blindly copy C#?
>>
>> After all this problem can be solved, IMHO.
>> I suggest to make so:
>>
>> 1. To leave structures in that kind in which they is (POD)
>>
>> 2. To permit classes declaration such what they in C++
>>
>> 3. To permit transfer the classes on value (for compulsory pass by reference and for declaration through "new" now we have "ref" keyword)
>>
>> 3. To check slicing during compilation. It is possible?
> 
> For example prohibit assigning on value to the types, not being base or this type
> 
>> 4. "scope" for classes to deprecate as superfluous
>>
>>
>> In that case there will be problems?
>>
>>

Who agrees with me? There are still ideas as it is possible to solve this problem and not to destroy language?
January 06, 2009
Weed пишет:
> Weed пишет:
>> Weed пишет:
>>> Andrei Alexandrescu пишет:
>>>> Weed wrote:
>>>> [about structs vs. classes]
>>>>> It is very a pity.
>>>>> My small opinion: it is impossible to reduce performance for struggle
>>>>> against potential errors - such languages already are, it more
>>>>> high-level. It how to refuse pointers because they are dangerous,
>>>>> difficult for beginners and without them it is possible to make any
>>>>> algorithm.
>>>> It's attractive to deal in absolutes, but also dangerous. When C came about, naysayers complained that it was consistently 30% slower than assembler, and generated larger code by an even higher margin. Then, some asked, what would you choose, one OS that's cool because it's written in C, or one that's one third faster? and so on. What people have forgotten by now is that C *was* high level. And it *did* incur a performance hit. It also had desirable properties that overcame that hit.
>>>>
>>> Can in C# (it uses as far as I know too such sharing) such approach and it is justified - microsoft accelerates replacement of hardware for new OS. :) But we after all not blindly copy C#?
>>>
>>> After all this problem can be solved, IMHO.
>>> I suggest to make so:
>>>
>>> 1. To leave structures in that kind in which they is (POD)
>>>
>>> 2. To permit classes declaration such what they in C++
>>>
>>> 3. To permit transfer the classes on value (for compulsory pass by reference and for declaration through "new" now we have "ref" keyword)
>>>
>>> 3. To check slicing during compilation. It is possible?
>> For example prohibit assigning on value to the types, not being base or this type
>>
>>> 4. "scope" for classes to deprecate as superfluous
>>>
>>>
>>> In that case there will be problems?
>>>
>>>
> 
> Who agrees with me? There are still ideas as it is possible to solve this problem and not to destroy language?

And against arguments are still necessary
January 06, 2009
Weed wrote:
> Who agrees with me? There are still ideas as it is possible to solve
> this problem and not to destroy language?

When you reply to your reply to your reply to your post and nobody else replies to any of your posts, you might start thinking that nobody agrees with you, or cares enough to respond.

As to your suggestion that there be compile-time checks for object slicing... well, you'd end up with almost everything with any polymorphism being done by reference for safety. In the remaining situations, scope will usually suffice.

I don't think anyone sees sufficient reason to give Walter as much work as you suggest. When would you use this?
 - In place of the current scope keyword.
 - For more efficiency with object composition (though scope could be used for this, potentially).
 - Implementing value semantics with runtime polymorphism.

The only interesting thing there is value semantics with polymorphism. If you really care, you can implement polymorphism with structs.
January 06, 2009
Christopher Wright пишет:
> Weed wrote:
>> Who agrees with me? There are still ideas as it is possible to solve this problem and not to destroy language?
> 
> When you reply to your reply to your reply to your post and nobody else replies to any of your posts, you might start thinking that nobody agrees with you, or cares enough to respond.

I consoled myself that the letter has got lost in the big thread

> As to your suggestion that there be compile-time checks for object slicing... well, you'd end up with almost everything with any polymorphism being done by reference for safety. In the remaining situations, scope will usually suffice.
> 
> I don't think anyone sees sufficient reason to give Walter as much work as you suggest.

D2.0 not released, it changes supplemented. I seriously consider at it there is a chance to become the most good language, a "silver bullet". :) This discussion - my small contribution.

> When would you use this?
>  - In place of the current scope keyword.

I consider that "scope" is attempt to fix bad design.
Have come to that that on a stack all the same it is necessary to place
classes and have added a word, but it does not solve all problems.

>  - For more efficiency with object composition (though scope could be
> used for this, potentially).
>  - Implementing value semantics with runtime polymorphism.
> 

And, probably, in the future it will help to add other possibilities. For example compile-time initialization of classes about which I here spoke too (not in this thread)


> The only interesting thing there is value semantics with polymorphism. If you really care, you can implement polymorphism with structs.

Excellent templates, unit tests, closures, delegates, threads... And after all it is offered to the programmer most implement OOP by hands?
January 06, 2009
On Tue, Jan 6, 2009 at 1:41 PM, Christopher Wright <dhasenan@gmail.com> wrote:
> Weed wrote:
>>
>> Who agrees with me? There are still ideas as it is possible to solve this problem and not to destroy language?
>
> When you reply to your reply to your reply to your post and nobody else replies to any of your posts, you might start thinking that nobody agrees with you, or cares enough to respond.
>
> As to your suggestion that there be compile-time checks for object slicing... well, you'd end up with almost everything with any polymorphism being done by reference for safety. In the remaining situations, scope will usually suffice.
>
> I don't think anyone sees sufficient reason to give Walter as much work as
> you suggest. When would you use this?
>  - In place of the current scope keyword.
>  - For more efficiency with object composition (though scope could be used
> for this, potentially).
>  - Implementing value semantics with runtime polymorphism.
>
> The only interesting thing there is value semantics with polymorphism. If you really care, you can implement polymorphism with structs.
>

My problem is more that I just can't understand the guy so I don't know if I agree with him or not.

I think the choice between  just

   value semantics / POD / no polymorphism / heap or stack    and
   reference semantics / non-POD / polymorphism / heap only

Are not quite sufficent.  I find myself often wanting things that are mixes of these two attribute sets, and it's often difficult for me to decide up front which is more appropriate for a given case.  For instance reference-semantics POD.     And other times it's out of my hands writing a library -- the more appropriate one depends on the person using the library not me.  So I've played around with things like implementing the guts of something entirely as a mixin that gets mixed in to both a struct and a class shell.  It sorta works but it's a lot more work than the unified model in C++ where I just write one class and the user decides how to use it.  And scope has a lot of holes.   You can't create a scope member of a class.   I don't think you can create an array of scope objects, either.

So I'm not really convinced that D got the distinction right.  It's never really felt right to me and it still doesn't today.  But I don't have any better suggestions at the moment.  It just feels very un-orthogonal to me.  Different unrelated choices are all bundled under the same big toggle switch rather than being able to toggle the different attributes the way I want them.

--bb
January 06, 2009
Bill Baxter пишет:
> On Tue, Jan 6, 2009 at 1:41 PM, Christopher Wright <dhasenan@gmail.com> wrote:
>> Weed wrote:
>>> Who agrees with me? There are still ideas as it is possible to solve this problem and not to destroy language?
>> When you reply to your reply to your reply to your post and nobody else replies to any of your posts, you might start thinking that nobody agrees with you, or cares enough to respond.
>>
>> As to your suggestion that there be compile-time checks for object slicing... well, you'd end up with almost everything with any polymorphism being done by reference for safety. In the remaining situations, scope will usually suffice.
>>
>> I don't think anyone sees sufficient reason to give Walter as much work as
>> you suggest. When would you use this?
>>  - In place of the current scope keyword.
>>  - For more efficiency with object composition (though scope could be used
>> for this, potentially).
>>  - Implementing value semantics with runtime polymorphism.
>>
>> The only interesting thing there is value semantics with polymorphism. If you really care, you can implement polymorphism with structs.
>>
> 
> My problem is more that I just can't understand the guy so I don't know if I agree with him or not.
> 
> I think the choice between  just
> 
>    value semantics / POD / no polymorphism / heap or stack    and
>    reference semantics / non-POD / polymorphism / heap only

No, for classes I suggest to choose between:
reference semantics / non-POD / polymorphism / heap only (current state)
and
value or reference semantics / non-POD / polymorphism / heap or stack

As a matter of fact how it was in C++, but with check slicing or simply prohibition of assignment to other types by value. Syntax will demand attention before change - it is necessary to make so that there was no mixing of names of references and classes on value.
January 06, 2009
Weed пишет:
> Bill Baxter пишет:
>> On Tue, Jan 6, 2009 at 1:41 PM, Christopher Wright <dhasenan@gmail.com> wrote:
>>> Weed wrote:
>>>> Who agrees with me? There are still ideas as it is possible to solve this problem and not to destroy language?
>>> When you reply to your reply to your reply to your post and nobody else replies to any of your posts, you might start thinking that nobody agrees with you, or cares enough to respond.
>>>
>>> As to your suggestion that there be compile-time checks for object slicing... well, you'd end up with almost everything with any polymorphism being done by reference for safety. In the remaining situations, scope will usually suffice.
>>>
>>> I don't think anyone sees sufficient reason to give Walter as much work as
>>> you suggest. When would you use this?
>>>  - In place of the current scope keyword.
>>>  - For more efficiency with object composition (though scope could be used
>>> for this, potentially).
>>>  - Implementing value semantics with runtime polymorphism.
>>>
>>> The only interesting thing there is value semantics with polymorphism. If you really care, you can implement polymorphism with structs.
>>>
>> My problem is more that I just can't understand the guy so I don't know if I agree with him or not.
>>
>> I think the choice between  just
>>
>>    value semantics / POD / no polymorphism / heap or stack    and
>>    reference semantics / non-POD / polymorphism / heap only
> 
> No, for classes I suggest to choose between:
> reference semantics / non-POD / polymorphism / heap only (current state)
> and
> value or reference semantics / non-POD / polymorphism / heap or stack
> 
> As a matter of fact how it was in C++, but with check slicing or simply prohibition of assignment to other types by value.

====
> Syntax will demand
> attention before change - it is necessary to make so that there was no
> mixing of names of references and classes on value.
====
^^^^^^^^ Here the nonsense is written, it is not necessary to be afraid
of mixing. I should sleep more:)