View mode: basic / threaded / horizontal-split · Log in · Help
December 30, 2008
Re: division of objects into classes and structures is bad
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
Re: division of objects into classes and structures is bad
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
Re: division of objects into classes and structures is bad
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
Re: division of objects into classes and structures is bad
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
Re: division of objects into classes and structures is bad
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
Re: division of objects into classes and structures is bad
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
Re: division of objects into classes and structures is bad
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
Re: division of objects into classes and structures is bad
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
Re: division of objects into classes and structures is bad
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
Re: division of objects into classes and structures is bad
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:)
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home