digitalmars.D - TDPL notes, part 2
- bearophile (57/57) Jul 15 2010 I hope Andrei appreciated my efforts :-)
- retard (6/9) Jul 15 2010 I suppose this mostly explains why the real tuples aren't coming to D.
- Andrei Alexandrescu (7/16) Jul 15 2010 For what it's worth - I don't care much about the comma operator, and I
- Yao G. (4/13) Jul 15 2010 --
I hope Andrei appreciated my efforts :-)
- The non-alphabetical index page 439 is a good idea.
- The page thickness is OK for me.
--------------------
More comments on Chapter 1:
Page 17: using null to represent empty arrays is not good. In D there is []
that's better for this.
P 18: "foo in associativeArray" returns a pointer. So can this work in SafeD
too? Maybe it can be accepted by SafeD is the pointer is not used and just
tested if it's null or not.
P 22: In this code:
Object.factory("stats." ~ arg);
This code is OK, but in my code I'd like to apply the DRY principle and use
something similar to (that keeps workins even if I change the name fo the
module):
Object.factory(__traits(thisModuleName) ~ arg);
This currently works, but it's not nice:
Object.factory(split(to!string({class C {}; return new C;}()), ".")[0] ~
".Foo");
(Probably there are already better ways to do it, but all of them, including
the __traits one can't be used in the first pages of the book, so the book page
is OK).
--------------------
Chapter 2:
P 35: adjacent string concatenation: this is bug-prone, see:
http://d.puremagic.com/issues/show_bug.cgi?id=3827
P 38, first code example: the D strings contain immutable chars as the text
says, but the book has to show this gotcha, that true immutable strings as
Python ones don't have (this code runs):
void main() {
string s = "Hello";
s.length += 1;
}
P 49: the explanations on is() don't seem complete:
is ( Type Identifier : TypeSpecialization, TemplateParameterList )
is ( Type Identifier == TypeSpecialization, TemplateParameterList )
But I think this is for the better, that syntax becomes unreadable.
P 50: The part 2.3.5.3 on function calls is good. I hope dmd will eventually do
what is written here.
P 55: part 2.3.9: there's an error, the concat (~) is not an addition because
it's not commutative, generally:
(s1 ~ s2) != (s2 ~ s1)
P 56, usage examples of 'in':
- LDC has shown to be able to optimize away to nearby associative array lookups
in all situations (and storing the pointer for a much later usage is not a
common usage pattern), and the usage of pointers in SafeD is not easy to do. So
consider returning a more clean boolean and improving the compiler instead.
- I have just filed this bug:
http://d.puremagic.com/issues/show_bug.cgi?id=4463
- For being an usage example it is OK. In D1 I have avoided that if/else using:
typedef double Double1 = 0.0;
So you can just increment the default double initialization.
Now you can probably use:
static struct Double2 { double d = 0.0; alias d this; }
But there's a bug and Double2 can't be used yet as associative array value.
P 57: a small note can be added for the equality among associative arrays.
P 58 part 2.3.12.2: Thanks to Don too those FP exceptions can be loud, this
helps debug code (I can even appreciate the severeExceptions to be switched on
on default in nonrelease builds):
import std.math: FloatingPointControl;
void main() {
FloatingPointControl fpctrl;
fpctrl.enableExceptions(FloatingPointControl.severeExceptions);
double x;
double y = x * 2.0;
}
P 59: using void with && and || is a ugly hack, if I find a line like this in
production code I kill it with fire. This is not a good example to be present
in the D2 reference book:
P 60: this is another bad example, it's a cute trick, but it's bad for
production code:
(predicate ? x : y) += 5
P 61: this is so hard to read that I don't want to see anything similar even in
small script-like programs. The D compiler can even disallow such long chains:
int c = (a = b, b = 7, 8);
Bye,
bearophile
Jul 15 2010
Thu, 15 Jul 2010 07:51:55 -0400, bearophile wrote:P 61: this is so hard to read that I don't want to see anything similar even in small script-like programs. The D compiler can even disallow such long chains: int c = (a = b, b = 7, 8);I suppose this mostly explains why the real tuples aren't coming to D. Both of the authors love the C/C++ style comma operator for "code generation purposes" as you can see above. Another advantage is that your time won't be wasted when you switch from D to C++ to do some real world programming.
Jul 15 2010
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> On 07/15/2010 09:10 AM, retard wrote:Thu, 15 Jul 2010 07:51:55 -0400, bearophile wrote:For what it's worth - I don't care much about the comma operator, and I extremely strongly believe Walter's argument involving code generation has no validity whatsoever. The contrived example mentioned above is given as an illustration for the section on the comma operator. AndreiP 61: this is so hard to read that I don't want to see anything similar even in small script-like programs. The D compiler can even disallow such long chains: int c = (a = b, b = 7, 8);I suppose this mostly explains why the real tuples aren't coming to D. Both of the authors love the C/C++ style comma operator for "code generation purposes" as you can see above. Another advantage is that your time won't be wasted when you switch from D to C++ to do some real world programming.
Jul 15 2010
Weren't you leaving for good this list? On Thu, 15 Jul 2010 09:10:03 -0500, retard <re tard.com.invalid> wrote:Thu, 15 Jul 2010 07:51:55 -0400, bearophile wrote:-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/P 61: this is so hard to read that I don't want to see anything similar even in small script-like programs. The D compiler can even disallow such long chains: int c = (a = b, b = 7, 8);I suppose this mostly explains why the real tuples aren't coming to D. Both of the authors love the C/C++ style comma operator for "code generation purposes" as you can see above. Another advantage is that your time won't be wasted when you switch from D to C++ to do some real world programming.
Jul 15 2010