division of objects into classes and structures is bad
Weed
resume755 at mail.ru
Tue Dec 30 14:24:59 PST 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
More information about the Digitalmars-d
mailing list