Andrei Alexandrescu wrote:
> Not wanting to start a language war, but to just say C has plenty of design holes and then patronize it with the comment that designing languages is hard - well, you better have a hell of an argument up your sleeve.

C really has only one major design flaw - the conflation of arrays and pointers.

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Not wanting to start a language war, but to just say C has plenty of design holes and then patronize it with the comment that designing languages is hard - well, you better have a hell of an argument up your sleeve.
> 
> C really has only one major design flaw - the conflation of arrays and pointers.

Great insight.

Andrei

Walter Bright wrote:
> Probably the biggest thing is opDispatch!
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.053.zip
> 
> 
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.037.zip
> 
> Many thanks to the numerous people who contributed to this update.


Thanks, guys! This is a pretty awesome release. :) I especially like that opPow made it in, and also the changes to std.math look very useful.

I have one question regarding the latter: What exactly is supposed to happen when I run the example in the FloatingPointControl documentation? Is the program supposed to crash with some informative error message, or do I have to do something to catch the exception? Currently, nothing out of the ordinary happens when I run it on my computer -- y just becomes NaN when x is NaN.

-Lars

On Sun, 06 Dec 2009 23:43:16 -0600, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

>Walter Bright wrote:
>> Andrei Alexandrescu wrote:
>>> Not wanting to start a language war, but to just say C has plenty of design holes and then patronize it with the comment that designing languages is hard - well, you better have a hell of an argument up your sleeve.
>> 
>> C really has only one major design flaw - the conflation of arrays and pointers.
>
>Great insight.
>
>Andrei

I think the following real-world code is a good argument against comma operators:

template <typename T>
Q_INLINE_TEMPLATE void QList<T>::node_destruct(Node *from, Node *to)
{
    if (QTypeInfo<T>::isLarge || QTypeInfo<T>::isStatic)
        while(from != to) --to, delete reinterpret_cast<T*>(to->v);
    else if (QTypeInfo<T>::isComplex)
        while (from != to) --to, reinterpret_cast<T*>(to)->~T();
}

Don wrote:
> Walter Bright wrote:
>> Probably the biggest thing is opDispatch!
>>
>> http://www.digitalmars.com/d/1.0/changelog.html
>> http://ftp.digitalmars.com/dmd.1.053.zip
>>
>>
>> http://www.digitalmars.com/d/2.0/changelog.html
>> http://ftp.digitalmars.com/dmd.2.037.zip
>>
>> Many thanks to the numerous people who contributed to this update.
> 
> I just noticed: I don't see @property in the changelog anywhere, but it's now in the spec. @safe, @trusted, @system aren't there either.


Do @safe, @trusted and @system actually do anything yet?

It seems @property now enforces the "0 or 1 parameter" constraint, but one can still use property syntax to call non-@property functions.

-Lars

Lars T. Kyllingstad wrote:
> Walter Bright wrote:
>> Probably the biggest thing is opDispatch!
>>
>> http://www.digitalmars.com/d/1.0/changelog.html
>> http://ftp.digitalmars.com/dmd.1.053.zip
>>
>>
>> http://www.digitalmars.com/d/2.0/changelog.html
>> http://ftp.digitalmars.com/dmd.2.037.zip
>>
>> Many thanks to the numerous people who contributed to this update.
> 
> 
> Thanks, guys! This is a pretty awesome release. :) I especially like that opPow made it in, and also the changes to std.math look very useful.
> 
> I have one question regarding the latter: What exactly is supposed to happen when I run the example in the FloatingPointControl documentation? Is the program supposed to crash with some informative error message, or do I have to do something to catch the exception? Currently, nothing out of the ordinary happens when I run it on my computer -- y just becomes NaN when x is NaN.

Aargh, the example's wrong. DMD optimizes the assignment into a blit. Try setting y = x*2.

Don wrote:
> Lars T. Kyllingstad wrote:
>> Walter Bright wrote:
>>> Probably the biggest thing is opDispatch!
>>>
>>> http://www.digitalmars.com/d/1.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.1.053.zip
>>>
>>>
>>> http://www.digitalmars.com/d/2.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.2.037.zip
>>>
>>> Many thanks to the numerous people who contributed to this update.
>>
>>
>> Thanks, guys! This is a pretty awesome release. :) I especially like that opPow made it in, and also the changes to std.math look very useful.
>>
>> I have one question regarding the latter: What exactly is supposed to happen when I run the example in the FloatingPointControl documentation? Is the program supposed to crash with some informative error message, or do I have to do something to catch the exception? Currently, nothing out of the ordinary happens when I run it on my computer -- y just becomes NaN when x is NaN.
> 
> Aargh, the example's wrong. DMD optimizes the assignment into a blit. Try setting y = x*2.
I take that back. The example is correct. This code...
-----
import std.math;

void main()
{
    real x;
    FloatingPointControl fpctrl;
    fpctrl.enableExceptions(FloatingPointControl.severeExceptions);
    double y = x*3.0;
}
----
results in:
object.Error: Invalid Floating Point Operation

However, it seems that the compiler is no longer creating variables of type double and float as signalling NaNs. That's a bug.

Don wrote:
> Don wrote:
>> Lars T. Kyllingstad wrote:
>>> Walter Bright wrote:
>>>> Probably the biggest thing is opDispatch!
>>>>
>>>> http://www.digitalmars.com/d/1.0/changelog.html
>>>> http://ftp.digitalmars.com/dmd.1.053.zip
>>>>
>>>>
>>>> http://www.digitalmars.com/d/2.0/changelog.html
>>>> http://ftp.digitalmars.com/dmd.2.037.zip
>>>>
>>>> Many thanks to the numerous people who contributed to this update.
>>>
>>>
>>> Thanks, guys! This is a pretty awesome release. :) I especially like that opPow made it in, and also the changes to std.math look very useful.
>>>
>>> I have one question regarding the latter: What exactly is supposed to happen when I run the example in the FloatingPointControl documentation? Is the program supposed to crash with some informative error message, or do I have to do something to catch the exception? Currently, nothing out of the ordinary happens when I run it on my computer -- y just becomes NaN when x is NaN.
>>
>> Aargh, the example's wrong. DMD optimizes the assignment into a blit. Try setting y = x*2.
> I take that back. The example is correct. This code...
> -----
> import std.math;
> 
> void main()
> {
>     real x;
>     FloatingPointControl fpctrl;
>     fpctrl.enableExceptions(FloatingPointControl.severeExceptions);
>     double y = x*3.0;
> }
> ----
> results in:
> object.Error: Invalid Floating Point Operation
> 
> However, it seems that the compiler is no longer creating variables of type double and float as signalling NaNs. That's a bug.

OK, thanks for explaining. :)

-Lars

Max Samukha wrote:
> 
> I think the following real-world code is a good argument against comma operators:
> 
> template <typename T>
> Q_INLINE_TEMPLATE void QList<T>::node_destruct(Node *from, Node *to)
> {
>     if (QTypeInfo<T>::isLarge || QTypeInfo<T>::isStatic)
>         while(from != to) --to, delete reinterpret_cast<T*>(to->v);
>     else if (QTypeInfo<T>::isComplex)
>         while (from != to) --to, reinterpret_cast<T*>(to)->~T();
> }

I have never used the comma operator in my own code, but in my opinion this particular piece of code is really easy and fluent to read. »Maintainability« is admittedly, however, a different topic.

klickverbot wrote:
> Max Samukha wrote:
>> I think the following real-world code is a good argument against comma
>> operators:
>>
>> template <typename T>
>> Q_INLINE_TEMPLATE void QList<T>::node_destruct(Node *from, Node *to)
>> {
>>     if (QTypeInfo<T>::isLarge || QTypeInfo<T>::isStatic)
>>         while(from != to) --to, delete reinterpret_cast<T*>(to->v);
>>     else if (QTypeInfo<T>::isComplex)
>>         while (from != to) --to, reinterpret_cast<T*>(to)->~T();
>> }
> 
> I have never used the comma operator in my own code, but in my opinion this particular piece of code is really easy and fluent to read. »Maintainability« is admittedly, however, a different topic.

It is still more readable than 'while(from != to--)' or '((--to)->v)'.

I myself use the comma operator in for loops and simple assignments such as 'if(something) x = a, y = b;'.

The boost::assign namespace also declares operator,() overloads to ease up assignments in C++ such as 'myVector += 1,2,3,4,5;'.