Re: dmd 1.053 and 2.037 release
On Sun, 06 Dec 2009 23:43:16 -0600, Andrei Alexandrescu
seewebsiteforem...@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 QListT::node_destruct(Node *from, Node *to)
{
if (QTypeInfoT::isLarge || QTypeInfoT::isStatic)
while(from != to) --to, delete reinterpret_castT*(to-v);
else if (QTypeInfoT::isComplex)
while (from != to) --to, reinterpret_castT*(to)-~T();
}
Re: dmd 1.053 and 2.037 release
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
Re: dmd 1.053 and 2.037 release
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 n...@property functions. -Lars
Re: dmd 1.053 and 2.037 release
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.
Re: dmd 1.053 and 2.037 release
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
Re: dmd 1.053 and 2.037 release
Max Samukha wrote:
I think the following real-world code is a good argument against comma
operators:
template typename T
Q_INLINE_TEMPLATE void QListT::node_destruct(Node *from, Node *to)
{
if (QTypeInfoT::isLarge || QTypeInfoT::isStatic)
while(from != to) --to, delete reinterpret_castT*(to-v);
else if (QTypeInfoT::isComplex)
while (from != to) --to, reinterpret_castT*(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.
Re: dmd 1.053 and 2.037 release
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 QListT::node_destruct(Node *from, Node *to)
{
if (QTypeInfoT::isLarge || QTypeInfoT::isStatic)
while(from != to) --to, delete reinterpret_castT*(to-v);
else if (QTypeInfoT::isComplex)
while (from != to) --to, reinterpret_castT*(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;'.
Re: dmd 1.053 and 2.037 release
Jeremie Pelletier jerem...@gmail.com wrote in message
news:hfjbs4$v3...@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 QListT::node_destruct(Node *from, Node *to)
{
if (QTypeInfoT::isLarge || QTypeInfoT::isStatic)
while(from != to) --to, delete reinterpret_castT*(to-v);
else if (QTypeInfoT::isComplex)
while (from != to) --to, reinterpret_castT*(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.
D in the ix magazine about programming today
It is always interesting what the technical press writes about our beloved D. Today i read about D in the ix, a german IT magazine on the subject programming today (see here: http://www.heise.de/newsticker/meldung/iX-Special-Programmieren-heute-ab-sofort-am-Kiosk-875489.html) Here are some quotes (freely translated by myself): And D [..] is not going to become big enough [..] cause there is no big company backing it up - well this is quite a controversal statement D, the clean alternative to C++ - i can not agree more According to the language designers D is inappropriate as a first language for beginners - i strongly disagree to that In the near future D won't steal C++ the show but the potential is certainly present - feature-wise i think D2.0 already steals C++ the show
Re: D in the ix magazine about programming today
Extrawurst wrote: It is always interesting what the technical press writes about our beloved D. Today i read about D in the ix, a german IT magazine on the subject programming today (see here: http://www.heise.de/newsticker/meldung/iX-Special-Programmieren-heute-ab-sofort-am-Kiosk-875489.html) Here are some quotes (freely translated by myself): And D [..] is not going to become big enough [..] cause there is no big company backing it up - well this is quite a controversal statement D is also relatively new, I'm pretty confident once programs and libraries written in D begin to get widely used big companies will stand in line to get on the train. D, the clean alternative to C++ - i can not agree more Idem, not only is it a clean language, its also a practical one; I do a lot of C++ these days and I often find that I need to use complex libraries such as boost::bind to emulate something as simple as a delegate. According to the language designers D is inappropriate as a first language for beginners - i strongly disagree to that Well, D, just like any other systems language, it's not always easy for programmers to begin with when compared to scripting languages such as php or javascript. However, with TDPL soon to hit shelves, this will definitely change for the better. In the near future D won't steal C++ the show but the potential is certainly present - feature-wise i think D2.0 already steals C++ the show I agree, even C++0x won't beat D2.0 in terms of features. But the lack of C++ bindings in D will slow down it's adoption until the libraries have D equivalents.
