"Jeremie Pelletier" <jeremiep@gmail.com> wrote in message news:hfjbs4$v35$1@digitalmars.com...
> 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;'.

I've noticed that every use I've ever seen mentioned of the comma operator has only been a half-use of it. They all seem to fall into two categories: In one group, there's things like 'for' loops and the QList and if() examples above that don't make any use whatsoever of the comma operator's return value. Then in the other group there are operator overloading uses like boost::assign above that use only the comma operator's syntax, but throw away its semantics.

Jeremie Pelletier Wrote:

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

also:

for(...)
  if(test) found=TRUE, break;
if(found)...

On Fri, 04 Dec 2009 20:05:13 -0800, Walter Bright wrote:

> Probably the biggest thing is opDispatch!

Sounds great :)

But I think there's a minor typo here: http://www.digitalmars.com/d/2.0/operatoroverloading.html#Dispatch


class C
{
    void opDispatch(string s)(int i)
    {
	writefln("S.opDispatch('%s', %s)", s, i);


The writefln should be C.opDispatch

Apologies if already reported elsewhere...

Nick Treleaven wrote:
> Apologies if already reported elsewhere...

Nope. Thanks! Fixed.

Leandro Lucarella, el  5 de diciembre a las 13:07 me escribiste:
> Walter Bright, el  4 de diciembre a las 20:05 me escribiste:
> > 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.
> 
> Great! Can you tag the new releases? (and maybe the old ones too ;)
> 
> This should be enough:
> svn cp http://svn.dsource.org/projects/dmd/branches/dmd-1.x http://svn.dsource.org/projects/dmd/tags/dmd-1.053
> svn cp http://svn.dsource.org/projects/dmd/trunk http://svn.dsource.org/projects/dmd/tags/dmd-2.037

Thanks for the tagging :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
If you do not change your beliefs
Your life will always be like this

Lars T. Kyllingstad wrote:
> 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

I had a further look at this. The compiler *is* creating doubles and floats as signalling NaNs. Turns out, that there are slight differences between processors in the way they treat signalling NaNs, especially between Intel vs AMD. Intel Core2 triggers SNANs when loading floats & doubles, but *doesn't* trigger for 80-bit SNANs. The Pentium M that I did most of my testing on, didn't trigger for any of them. AMD's docs say that it triggers for all of them.
Won't be too hard to fix.

Don wrote:
> I had a further look at this. The compiler *is* creating doubles and floats as signalling NaNs. Turns out, that there are slight differences between processors in the way they treat signalling NaNs, especially between Intel vs AMD. Intel Core2 triggers SNANs when loading floats & doubles, but *doesn't* trigger for 80-bit SNANs. The Pentium M that I did most of my testing on, didn't trigger for any of them. AMD's docs say that it triggers for all of them.
> Won't be too hard to fix.


How do we fix the CPU? ;-)

On Thu, 10 Dec 2009, Walter Bright wrote:

> Don wrote:
> > I had a further look at this. The compiler *is* creating doubles and floats
> > as signalling NaNs. Turns out, that there are slight differences between
> > processors in the way they treat signalling NaNs, especially between Intel
> > vs AMD. Intel Core2 triggers SNANs when loading floats & doubles, but
> > *doesn't* trigger for 80-bit SNANs. The Pentium M that I did most of my
> > testing on, didn't trigger for any of them. AMD's docs say that it triggers
> > for all of them.
> > Won't be too hard to fix.
> 
> 
> How do we fix the CPU? ;-)

A soldering iron with a really sharp point?

Or maybe a sledgehammer.

Brad Roberts wrote:
> On Thu, 10 Dec 2009, Walter Bright wrote:
> 
>> Don wrote:
>>> I had a further look at this. The compiler *is* creating doubles and floats
>>> as signalling NaNs. Turns out, that there are slight differences between
>>> processors in the way they treat signalling NaNs, especially between Intel
>>> vs AMD. Intel Core2 triggers SNANs when loading floats & doubles, but
>>> *doesn't* trigger for 80-bit SNANs. The Pentium M that I did most of my
>>> testing on, didn't trigger for any of them. AMD's docs say that it triggers
>>> for all of them.
>>> Won't be too hard to fix.
>>
>> How do we fix the CPU? ;-)
> 
> A soldering iron with a really sharp point?
> 
> Or maybe a sledgehammer.

I was thinking 220VAC might help!

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Brad Roberts wrote:
> > On Thu, 10 Dec 2009, Walter Bright wrote:
> >
> >> Don wrote:
> >>> I had a further look at this. The compiler *is* creating doubles and floats
> >>> as signalling NaNs. Turns out, that there are slight differences between
> >>> processors in the way they treat signalling NaNs, especially between Intel
> >>> vs AMD. Intel Core2 triggers SNANs when loading floats & doubles, but
> >>> *doesn't* trigger for 80-bit SNANs. The Pentium M that I did most of my
> >>> testing on, didn't trigger for any of them. AMD's docs say that it triggers
> >>> for all of them.
> >>> Won't be too hard to fix.
> >>
> >> How do we fix the CPU? ;-)
> >
> > A soldering iron with a really sharp point?
> >
> > Or maybe a sledgehammer.
> I was thinking 220VAC might help!

Yep, on that voltage 10 GHz overclocks seems possible.