Hello!
I put my copy of TDPL in a hardcover (to last longer :-) and since
it's back from the shop and I've some time to start learning D
seriously, I wonder if there is source code from the book available
somewhere?
Sincerely,
Gour
--
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
But this disallows comparisons with rvalues.
eg,
Foo bar() { Foo x = 1; return x; }
Foo y=1;
assert( y == bar() ); // doesn't compile
You can get around this by declaring a
On Sat, 4 Dec 2010 09:00:05 + (UTC)
Franciszek Czekala h...@valentimex.com wrote:
Anyway, if struct has value semantics then perhaps the argument to
opEquals should have simply 'in' mode? In Ada95 the 'in' mode of
the arguments does not determine how the arguments are passed
internally to
On Friday 03 December 2010 22:42:06 Don wrote:
(1) Should temporaries be allowed to be passed as 'const ref'?
I honestly do not understand why they can't be already. C++ definitely allows
this. Is there something bad about it? I'd probably use const ref a lot more,
but because it will only
On Friday 03 December 2010 22:42:06 Don wrote:
(1) Should temporaries be allowed to be passed as 'const ref'?
I honestly do not understand why they can't be already. C++ definitely
allows
this.
If you don't mean new C++ standards, this is not true. It is supported by
non-standard
I'm a bit uncertain as to how this is all supposed to work.
(1) Should temporaries be allowed to be passed as 'const ref'?
Rather, what keeps compiler from interpreting A fun() like const ref A
fun() when it is necessary?
After all D's const system has no holes in this case unlike C++.
--
Le 25/11/10 14:03, biozic a écrit :
Hello.
This leads to a compilation error:
import std.algorithm;
void main() {
string foo = "foo";
immutable string bar = "bar";
auto f =
On 2010-12-04 02:48:26 -0500, Dmitry Olshansky dmitry.o...@gmail.com said:
On 04.12.2010 6:23, Andrei Alexandrescu wrote:
On 12/3/10 7:40 PM, Michel Fortin wrote:
I have an idea that would fix those: make a template struct/class
instance implicitly convertible to another instance of that same
On 3/12/10 1:42 PM, Andrei Alexandrescu wrote:
We certainly could learn from it:
http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html
Andrei
Seems to have touched a nerve with Bartosz!
...
Bartosz Milewski said...
Whatever bit you, Stevey? Why rant against
On 2010-12-04 07:13:30 -0500, Michel Fortin michel.for...@michelf.com said:
On 2010-12-04 02:48:26 -0500, Dmitry Olshansky dmitry.o...@gmail.com said:
On 04.12.2010 6:23, Andrei Alexandrescu wrote:
On 12/3/10 7:40 PM, Michel Fortin wrote:
I have an idea that would fix those: make a template
On Saturday 04 December 2010 03:49:26 so wrote:
On Friday 03 December 2010 22:42:06 Don wrote:
(1) Should temporaries be allowed to be passed as 'const ref'?
I honestly do not understand why they can't be already. C++ definitely
allows
this.
If you don't mean new C++ standards,
I'm 99.99% certain that it's perfectly legal to pass a temporary to a
function
that takes a const T and that it's in the standard
Oh that is right, but both are different things.
Say, when you have:
T fun() {...}
void bar(const T) {...}
bar(fun()) // 1. this is perfectly legal.
const T a =
I'm a bit uncertain as to how this is all supposed to work.
(1) Should temporaries be allowed to be passed as 'const ref'?
Oh... we are saying exact same thing but i interpreted passed as 'const
ref' out of the context!
I guess Jonathan also saying the same thing.
Sorry about that!
--
On 12/4/10 2:40 AM, Gour wrote:
Hello!
I put my copy of TDPL in a hardcover (to last longer :-) and since
it's back from the shop and I've some time to start learning D
seriously, I wonder if there is source code from the book available
somewhere?
Not at the moment, but I plan to make it
On 12/4/10 1:48 AM, Dmitry Olshansky wrote:
On 04.12.2010 6:23, Andrei Alexandrescu wrote:
On 12/3/10 7:40 PM, Michel Fortin wrote:
I have an idea that would fix those: make a template struct/class
instance implicitly convertible to another instance of that same
template if all members share
On 12/4/10 4:35 AM, Jonathan M Davis wrote:
On Friday 03 December 2010 22:42:06 Don wrote:
(1) Should temporaries be allowed to be passed as 'const ref'?
I honestly do not understand why they can't be already. C++ definitely allows
this.
C++'s second biggest mistake.
Andrei
On 12/4/10 6:50 AM, so wrote:
I'm 99.99% certain that it's perfectly legal to pass a temporary to a
function
that takes a const T and that it's in the standard
Oh that is right, but both are different things.
Say, when you have:
T fun() {...}
void bar(const T) {...}
bar(fun()) // 1. this is
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
This is a compiler bug. For structs there should be no official
implementation of opEquals, opCmp etc. All the compiler needs to worry
about is to
On Saturday 04 December 2010 06:00:58 Andrei Alexandrescu wrote:
On 12/4/10 4:35 AM, Jonathan M Davis wrote:
On Friday 03 December 2010 22:42:06 Don wrote:
(1) Should temporaries be allowed to be passed as 'const ref'?
I honestly do not understand why they can't be already. C++
On Sat, 04 Dec 2010 16:05:07 +0200, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 6:50 AM, so wrote:
I'm 99.99% certain that it's perfectly legal to pass a temporary to a
function
that takes a const T and that it's in the standard
Oh that is right, but both are
On 12/4/10 8:29 AM, Jonathan M Davis wrote:
On Saturday 04 December 2010 06:00:58 Andrei Alexandrescu wrote:
On 12/4/10 4:35 AM, Jonathan M Davis wrote:
On Friday 03 December 2010 22:42:06 Don wrote:
(1) Should temporaries be allowed to be passed as 'const ref'?
I honestly do not understand
i would take take the address of a temporary function...
Should be:
i would take the address of a temporary object/value.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
This is a compiler bug. For structs there should be no official
implementation of opEquals, opCmp etc. All the compiler needs
Andrei, your explanation is almost the same as was my understanding. Thank you.
My shallow thought:
const T makes automatically reference. It is convenient.
Right thinking:
D has no semantics dividing copying/referencing, against has
dividing rvalue/lvalue.
D should support this like
On 2010-12-04 08:55:19 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
If conversion is allowed only for values (i.e. perform a memberwise
copy of one struct to another), it looks like things could work.
Almost. The problem is that that surreptitious copy completely bypasses
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
This is a compiler bug. For structs there should be no official
implementation of opEquals,
On 12/4/10 9:58 AM, Michel Fortin wrote:
On 2010-12-04 08:55:19 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
If conversion is allowed only for values (i.e. perform a memberwise
copy of one struct to another), it looks like things could work.
Almost. The problem is that that
bool opEquals(auto ref inout Tuple rhs) inout {
foreach (i, T; Types) {
if (this[i] != rhs[i]) return false;
}
return true;
}
It looks a bit alembicated but let's not forget that Tuple is supposed
to be very flexible and to do a lot of things.
Const-system is a one big
Keyword cocktails..
2010/12/4 so s...@so.do:
bool opEquals(auto ref inout Tuple rhs) inout {
foreach (i, T; Types) {
if (this[i] != rhs[i]) return false;
}
return true;
}
It looks a bit alembicated but let's not forget that Tuple is supposed to
be very flexible and to do a lot
Simen kjaeraas simen.kja...@gmail.com wrote:
What might be appropriate is a function tailconst( T )( T t ) that
returns a tail const version of the passed type. That is, given a
T[], const(T[]), const(T)[], immutable(T[]), or immutable(T)[], it
returns a const(T)[]. For a MyRange!R,
is it just me, or does this fail for
minA = 0
minB = 0
maxA = 0x80_00_00_00
maxB = 0x80_00_00_00
I'm pretty sure you need to handle 1 32 specially
On 12/04/2010 01:21 PM, Ellery Newcomer wrote:
is it just me, or does this fail for
minA = 0
minB = 0
maxA = 0x80_00_00_00
maxB = 0x80_00_00_00
I'm pretty sure you need to handle 1 32 specially
i'm thinking this is better:
uint32_t maxOr (uint32_t minA, uint32_t minB,
uint32_t
Andrei Alexandrescu wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
This is a compiler bug. For structs there should be no official
On 12/4/10 2:39 PM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
This is a compiler bug. For structs
On 12/4/10 12:23 PM, Simen kjaeraas wrote:
Simen kjaeraas simen.kja...@gmail.com wrote:
What might be appropriate is a function tailconst( T )( T t ) that
returns a tail const version of the passed type. That is, given a
T[], const(T[]), const(T)[], immutable(T[]), or immutable(T)[], it
On 2010-12-04 11:06:14 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
On 12/4/10 9:58 AM, Michel Fortin wrote:
On 2010-12-04 08:55:19 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
If conversion is allowed only for values (i.e. perform a memberwise
copy of
Well, to keep things short, double.min returns something weird.
See the following for demonstration:
import std.stdio;
void main(){
double r = double.max, r2 = double.min;
writeln(r);//1.79769e+308
r *= 2;//test if it's max
writeln(r); // infinity, ok
On 05.12.2010 0:19, Michel Fortin wrote:
On 2010-12-04 11:06:14 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
I'm not sure why you imply it won't work for references. That's the
whole point of the proposal. It can work for references as long as the
memory layout is the same and
writeln(r2);//2.22507e-308, wtf ?
What is wrong? It is the smallest representable double. not (-double.max)
r2 /= 2.0;
writeln(r2);// 1.11254e-308, a logical consequence of above
That is something weird, you get a double smaller than the smallest
representable!
--
Using Opera's
On 05.12.2010 0:22, Dmitry Olshansky wrote:
Well, to keep things short, double.min returns something weird.
See the following for demonstration:
import std.stdio;
void main(){
double r = double.max, r2 = double.min;
writeln(r);//1.79769e+308
r *= 2;//test if it's max
See what you mean, but it is the standard value from c's float.h.
This is not my day, i should just stop posting...
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
On 05.12.2010 0:48, so wrote:
writeln(r2);//2.22507e-308, wtf ?
What is wrong? It is the smallest representable double. not (-double.max)
The smallest is 5e-324 as I (hopefully) showed.
r2 /= 2.0;
writeln(r2);// 1.11254e-308, a logical consequence of above
That is something weird, you
On 12/04/2010 03:22 PM, Dmitry Olshansky wrote:
Well, to keep things short, double.min returns something weird.
See the following for demonstration:
import std.stdio;
void main(){
double r = double.max, r2 = double.min;
writeln(r);//1.79769e+308
r *= 2;//test if it's max
writeln(r); //
On 12/04/2010 04:22 PM, Dmitry Olshansky wrote:
Well, to keep things short, double.min returns something weird.
See the following for demonstration:
import std.stdio;
void main(){
double r = double.max, r2 = double.min;
writeln(r);//1.79769e+308
r *= 2;//test if it's max
writeln(r); //
On 4-dic-10, at 02:26, Steven Schveighoffer wrote:
On Fri, 03 Dec 2010 19:06:36 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org
wrote:
On 12/3/10 5:17 PM, Steven Schveighoffer wrote:
On Thu, 02 Dec 2010 17:02:42 -0500, Michel Fortin
michel.for...@michelf.com wrote:
On
bearophile Wrote:
Walter:
There are a thousand languages out there. I could spend multiple lifetimes
studying them, and then have to start all over with the new crop of
languages,
and accomplish absolutely nothing.
It's a matter of balance. If you want to design something new you
Ellery Newcomer wrote:
looks like double.min is returning double.min_normal
oddly enough, double.min is undefined in the spec
Yeah, things got changed a while back for floating point types. .min now
returns the minimum normal. To get the actual minimum value, we need to
use the negative of
On 12/4/10 3:19 PM, Michel Fortin wrote:
On 2010-12-04 11:06:14 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
On 12/4/10 9:58 AM, Michel Fortin wrote:
On 2010-12-04 08:55:19 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
If conversion is allowed only for
On Sat, 04 Dec 2010 08:55:19 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 1:48 AM, Dmitry Olshansky wrote:
On 04.12.2010 6:23, Andrei Alexandrescu wrote:
On 12/3/10 7:40 PM, Michel Fortin wrote:
I have an idea that would fix those: make a template struct/class
On Sat, 04 Dec 2010 11:00:58 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct Foo {
bool opEquals(const ref Foo x) const {...}
}
Gary Whatmore wrote:
Jack Wrote:
The post C#'s greatest mistakes prompts/begs this post. Have at it,
pick up the ball and run with it, don't be shy. I expect Walter and
Andrei to answer (if Walter and Andrei so dare!) after others' posts
have stopped or stagnated into that cesspool of
Walter Bright wrote:
Robert Jacques wrote:
D's omissible parenthesis strike me as being half-way between C#'s
properties and Eiffel's Uniform Access Principle. Given Eiffel's
influence on D, was there a reason why you didn't implement the
uniform access principal instead of omissible
Craig Black wrote:
Andrei,
I long while back I remember you talking about the next big thing
being sealed containers and that you would give a presentation on it.
Did this fall through or are you still working on it?
The concept of sealing is not Andrei's. Stop feeding those who don't
need
spir wrote:
On Mon, 29 Nov 2010 08:17:23 +0300
Denis Koroskin 2kor...@gmail.com wrote:
I'd go with omissible parens. There are SO many bugs and stuff that
can't be worked around due to this.
+++
(Once again, allowing a few less key-strokes makes a language
uselessly complicated, harder
Gary Whatmore wrote:
Jack Wrote:
The post C#'s greatest mistakes prompts/begs this post. Have at it,
pick up the ball and run with it, don't be shy. I expect Walter and
Andrei to answer (if Walter and Andrei so dare!) after others' posts
have stopped or stagnated into that cesspool of
Walter Bright wrote:
Denis Koroskin wrote:
I'd go with omissible parens. There are SO many bugs and stuff that
can't be worked around due to this.
For function calls? Yeah, I fell into that one. Oops. I should have
learned my lesson with the problems that C has with implicitly taking
the
Walter Bright wrote:
architect wrote:
You should study Eiffel that much.
There are a thousand languages out there. I could spend multiple
lifetimes studying them, and then have to start all over with the new
crop of languages, and accomplish absolutely nothing.
Why persist in this? Your
bearophile wrote:
Walter:
There are a thousand languages out there. I could spend multiple
lifetimes studying them, and then have to start all over with the
new crop of languages, and accomplish absolutely nothing.
It's a matter of balance.
No it isn't.
If you want to design something
Steven Schveighoffer wrote:
On Sun, 28 Nov 2010 23:19:44 -0500, Jack j...@overlook.biz wrote:
The post C#'s greatest mistakes prompts/begs this post. Have at it,
pick up the ball and run with it, don't be shy. I expect Walter and
Andrei to answer (if Walter and Andrei so dare!) after others'
What I don't understand is why so much effort went into this and whay it
wants to continue to suck valuable effort, when there important things to
be doing. Someone here explain this to me please (yes, in pvt, if need
be: ask for my email if you don't already have it).
On 12/4/10 22:19 CST, Json wrote:
Craig Black wrote:
Andrei,
I long while back I remember you talking about the next big thing
being sealed containers and that you would give a presentation on it.
Did this fall through or are you still working on it?
The concept of sealing is not Andrei's.
On 12/4/10 22:42 CST, Steven Schveighoffer wrote:
On Sat, 04 Dec 2010 15:58:43 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 2:39 PM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
On 12/4/10 22:36 CST, Steven Schveighoffer wrote:
On Sat, 04 Dec 2010 11:00:58 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:42 AM, Don wrote:
Officially, opEquals has to have the signature:
struct
On 12/4/10 23:40 CST, Andrei Alexandrescu wrote:
Yah. Method calls are already passed by reference (I'd prefer not but
that's just me).
Sorry, I meant: method calls are already allowed for rvalues. Sleepy...
Andrei
Dmitry Olshansky wrote:
Well, to keep things short, double.min returns something weird.
See the following for demonstration:
import std.stdio;
void main(){
double r = double.max, r2 = double.min;
writeln(r);//1.79769e+308
r *= 2;//test if it's max
writeln(r); // infinity, ok
Don wrote:
Dmitry Olshansky wrote:
Well, to keep things short, double.min returns something weird.
See the following for demonstration:
import std.stdio;
void main(){
double r = double.max, r2 = double.min;
writeln(r);//1.79769e+308
r *= 2;//test if it's max
writeln(r); //
On Sun, 05 Dec 2010 00:40:26 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 22:36 CST, Steven Schveighoffer wrote:
On Sat, 04 Dec 2010 11:00:58 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/4/10 9:23 AM, Don wrote:
Andrei Alexandrescu
On Sun, 05 Dec 2010 00:42:20 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Yah, still not getting the original point there.
I responded better in another part of this thread.
Basically, inout doesn't mean what you think it means.
-Steve
http://d.puremagic.com/issues/show_bug.cgi?id=5314
--- Comment #5 from Haruki Shigemori rayerd@gmail.com 2010-12-04 00:18:22
PST ---
- filename.d(4): struct ID has not both postblit and immutable member value
+ filename.d(4): struct ID cannot have both postblit and immutable member value
http://d.puremagic.com/issues/show_bug.cgi?id=5316
--- Comment #1 from Andrei Alexandrescu and...@metalanguage.com 2010-12-04
08:26:22 PST ---
Created an attachment (id=838)
Implementation
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving
http://d.puremagic.com/issues/show_bug.cgi?id=5317
Summary: Assertion is not work in a function called by
std.concurrency.spawn
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
http://d.puremagic.com/issues/show_bug.cgi?id=5318
Summary: core.sys.osx: add version (OSX) at top of all files.
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
http://d.puremagic.com/issues/show_bug.cgi?id=5293
--- Comment #3 from Iain Buclaw ibuc...@ubuntu.com 2010-12-04 15:18:46 PST ---
Looks good, makes more sense to use , thanks!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail
http://d.puremagic.com/issues/show_bug.cgi?id=3905
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=5218
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=5191
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=5107
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=2206
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=5293
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=3905
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://d.puremagic.com/issues/show_bug.cgi?id=4864
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
CC|
http://d.puremagic.com/issues/show_bug.cgi?id=4864
--- Comment #4 from Walter Bright bugzi...@digitalmars.com 2010-12-04
22:57:26 PST ---
http://www.dsource.org/projects/dmd/changeset/778
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving
http://d.puremagic.com/issues/show_bug.cgi?id=5182
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
83 matches
Mail list logo
