On 12/11/10 22:41, Matthias Walter wrote:
> Hi all,
>
> I wrote a ByToken tokenizer that models Range, i.e. it can be used in a
> foreach loop to read from a std.stdio.File. For it to work one has to
> supply it with a delegate, taking a current buffer and a controller
> class instance. It is call
Jason House wrote:
I wish I had your problems. I ported a sizable set of C++ code to D2 and
discovered D2 with dmd was 50x slower than C++ with gcc! I've been to
busy/disappointed to track down the bug(s) causing such a slowdown. If anyone
is sufficiently inspired to find the bugs, I can make the
Jason House Wrote:
> Craig Black Wrote:
>
> > > One more thing - to clarify, Craig, are you implying that it's acceptable
> > > for performance to be within 20%? If not, there are tweaks on the
> > > algorithmic side we can do to improve sorting.
> >
> > 20% slower would be acceptable if I did
Craig Black Wrote:
> > One more thing - to clarify, Craig, are you implying that it's acceptable
> > for performance to be within 20%? If not, there are tweaks on the
> > algorithmic side we can do to improve sorting.
>
> 20% slower would be acceptable if I didn't have to do my own inlining.
>
There's a number of things that currently stop dmd from inlining.
Several exist
as bug reports. I don't recall if there's one about ref return results
or not.
These limitations are certainly worth working to lift, but they're lower
priority than a lot of other bugs. That said, they're the
David Nadlinger wrote:
On 12/11/10 8:18 PM, Andrej Mitrovic wrote:
I've seen some tools that can convert OMF> COFF, but never the other
way around.
Well, there is e.g. »coff2omf« from DigitalMars, but I haven't had any
success with it.
David
objconv (available at www.agner.org) now claim
One more thing - to clarify, Craig, are you implying that it's acceptable
for performance to be within 20%? If not, there are tweaks on the
algorithmic side we can do to improve sorting.
20% slower would be acceptable if I didn't have to do my own inlining.
Closing the gap even more would be n
Not sure if this is the de facto answer, but I found this one from back in
the day.
R delegate(T) toDg(R, T...)(R function(T) fp) {
struct dg {
R opCall(T t) {
return (cast(R function(T)) this) (t);
}
}
R delegate(T) t;
t.ptr = fp;
t.funcptr = &dg.opCall;
Show us the code and how you invoked DMD. I'm sure there are experts
lurking around here ready to investigate. ;)
On 12/12/10, Brad Roberts wrote:
> On 12/11/2010 8:22 PM, Craig Black wrote:
>> I did some benchmarking with a simple quick sort algorithm and was very
>> disappointed that dmd was ov
On 12/11/10 10:36 PM, Brad Roberts wrote:
On 12/11/2010 8:22 PM, Craig Black wrote:
I did some benchmarking with a simple quick sort algorithm and was very
disappointed that dmd was over twice as slow as Visual C++. Investigation
revealed most of the slowness was due to the fact that dmd was no
Hi all,
I wrote a ByToken tokenizer that models Range, i.e. it can be used in a
foreach loop to read from a std.stdio.File. For it to work one has to
supply it with a delegate, taking a current buffer and a controller
class instance. It is called to extract a token from the unprocessed
part of the
On 12/11/2010 8:22 PM, Craig Black wrote:
> I did some benchmarking with a simple quick sort algorithm and was very
> disappointed that dmd was over twice as slow as Visual C++. Investigation
> revealed most of the slowness was due to the fact that dmd was not inlining a
> simple function that ret
I did some benchmarking with a simple quick sort algorithm and was very
disappointed that dmd was over twice as slow as Visual C++. Investigation
revealed most of the slowness was due to the fact that dmd was not inlining
a simple function that returned a reference. After hand-inlining some co
Hi all,
there was a discussion in 2006 but w/o a result, and I didn't find any
bugs about implicitely casting functions to delegates. It seems to be
impossible as long as function-pointer calls work differently than
delegate calls in the ABI. Will this at some point be fixed?
If not, is there a c
On Saturday 11 December 2010 19:16:29 Jonathan M Davis wrote:
> On Saturday 11 December 2010 19:08:33 Simen kjaeraas wrote:
> > Jonathan M Davis wrote:
> > > This behavior is intended. Arrays are actually something like this
> > > under the hood:
> > >
> > > struct array(T)
> > > {
> > >
> > >
Coolio. I should pay a visit to druntime.. sometime. :)
On 12/12/10, Jonathan M Davis wrote:
> On Saturday 11 December 2010 19:00:55 Jonathan M Davis wrote:
>> On Saturday 11 December 2010 18:18:54 Tomek Sowiński wrote:
>> > string s = "";
>> > assert(s); // ok
>> > assert(s != null); // fails
On Saturday 11 December 2010 19:08:33 Simen kjaeraas wrote:
> Jonathan M Davis wrote:
> > This behavior is intended. Arrays are actually something like this under
> > the hood:
> >
> > struct array(T)
> > {
> >
> > T* arr;
> > size_t length;
> >
> > }
>
> Actually, that is:
>
> struct
On Saturday 11 December 2010 19:00:55 Jonathan M Davis wrote:
> On Saturday 11 December 2010 18:18:54 Tomek Sowiński wrote:
> > string s = "";
> > assert(s); // ok
> > assert(s != null); // fails
> >
> > I guess that's a bug. But which one is right?
>
> A null array and an empty array are essen
Jonathan M Davis wrote:
This behavior is intended. Arrays are actually something like this under
the hood:
struct array(T)
{
T* arr;
size_t length;
}
Actually, that is:
struct array(T)
{
size_t length;
T* ptr;
}
To get the layout and names right.
( http://digitalmars.com/
Simen kjaeraas wrote:
Ellery Newcomer wrote:
I forget, why are we supposed to use is instead of == with null?
'[] is null' compares ptr and length, while '[] == null' compares only
the length. Weirdly though, '[] is null' is false for ptr == 0,
length != 0. Not likely to happen much in pra
Ellery Newcomer wrote:
I forget, why are we supposed to use is instead of == with null?
'[] is null' compares ptr and length, while '[] == null' compares only
the length. Weirdly though, '[] is null' is false for ptr == 0,
length != 0. Not likely to happen much in practice.
--
Simen
Andrej Mitrovic wrote:
Actually I'm having a hard time understanding this:
void main()
{
string s = "";
assert(s); // pass, but why?
assert(s !is null); // pass
}
void main()
{
string s = "".idup;
assert(s); // fail
assert(s !is null); // pass
}
Try adding writeln( s.ptr ); in there. S
On Saturday 11 December 2010 18:18:54 Tomek Sowiński wrote:
> string s = "";
> assert(s); // ok
> assert(s != null); // fails
>
> I guess that's a bug. But which one is right?
A null array and an empty array are essentially the same thing as far as D is
concerned. I believe that the only diffe
Actually I'm having a hard time understanding this:
void main()
{
string s = "";
assert(s); // pass, but why?
assert(s !is null); // pass
}
void main()
{
string s = "".idup;
assert(s); // fail
assert(s !is null); // pass
}
On 12/12/10, Andrej Mitrovic wrote:
> The first one should fail sinc
The first one should fail since the string has length 0. If you use an
.idup you would get the correct results:
void main()
{
string s = "".idup;
assert(s); // fails
assert(s != null); // ok
}
So I guess it's a bug.
On 12/12/10, Tomek Sowiński wrote:
> string s = "";
> assert(s); // ok
> ass
I forget, why are we supposed to use is instead of == with null?
On 12/11/2010 08:18 PM, Tomek Sowiński wrote:
string s = "";
assert(s); // ok
assert(s != null); // fails
I guess that's a bug. But which one is right?
--
Tomek
string s = "";
assert(s); // ok
assert(s != null); // fails
I guess that's a bug. But which one is right?
--
Tomek
so wrote:
I am not here asking for syntax or commanding phobos team to implement
something, I just want to know about technical limitations and license
issues, but got no answer to these.
Why? Either i am labeled here as a troll (maybe something worse since my
usage of English is not the b
Ary Borenszweig wrote:
Code is read many more times than it is written and so it is of huge
important that code is as readable as possible. Of course this is a
subjective matter, but I don't understand why some people think __traits
or __gshared are ok.
__gshared is ok. It is supposed to
On 12/10/2010 08:07 PM, Andrei Alexandrescu wrote:
Includes discussion of and insights into problems that are also of high
interest to the D programming language.
http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf
A little more info, since I had no I idea who Jeff De
On 12/11/10 1:33 PM, Lutger Blijdestijn wrote:
Andrei Alexandrescu wrote:
I'll share the tool when it's more complete, if this is something
that is
wanted for phobos I am willing to put it together.
Yes please. Other Phobosites?
Andrei
I'm sorry, I did not understand what yo
On 12/11/10 1:32 PM, Jonathan M Davis wrote:
On Saturday 11 December 2010 11:06:45 Jesse Phillips wrote:
Andrei Alexandrescu Wrote:
This program will generate a valid executable, but will also print
during compilation:
Type int is not a random access range because:
no empty property
no
Dmitry Olshansky napisał(a):
I think you could still get something very related by
const {
// entire module here
}
True, but you can't opt out to mutable.
--
Tomek
Don Wrote:
> Andrei Alexandrescu wrote:
> > On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote:
> >> On 12/10/10 19:26, Ary Borenszweig wrote:
> >>> http://vimeo.com/17420638
> >>>
> >>> A very interesting talk.
> >>>
> >>> I used to like D. To write code in a high level while at the same
> >
On 12.12.2010 1:20, Simen kjaeraas wrote:
Jonathan M Davis wrote:
It has definitely been suggested before that const should be the
default, and
some people would love that, but there's no way that it's going to
happen in D2,
and much as I like const, I think that it would be a huge mistake to
Jonathan M Davis wrote:
It has definitely been suggested before that const should be the
default, and
some people would love that, but there's no way that it's going to
happen in D2,
and much as I like const, I think that it would be a huge mistake to do
it in
any version of D and likely a
Jonathan M Davis wrote:
It would be great if dmd said which constraint failed, but since you're
dealing
with an arbitary boolean expression, in many cases, would not be
particularly
straightforward to say what failed, and I expect that it would be a
_big_ change
for the compiler.
Not to
"so" wrote in message news:op.vnj620a17dt...@so-pc...
>
> Why? Either i am labeled here as a troll (maybe something worse since my
> usage of English is not the best)
You're definitely not a troll. Sometimes I have difficulty understanding
what you mean, though. (But I can't complain - I've tri
On Sat, 11 Dec 2010 11:56:25 -0600
Jimmy Cao wrote:
> With the json files dmd produces it can be automated, and you can do it the
> ddoc way (so latex and other formats would also be supported.) A
> disadvantage is that ddoc processor has to be ran twice plus an additional
> pass over the json is
And to further hijack the topic, a hypothetical piece of code with
constraint blocks might look something like this:
http://dpaste.org/xB2N/
On 12/11/10, Andrej Mitrovic wrote:
> Why not just add an extra string parameter to constraint functions
> that will show a custom error message? This kind
Why not just add an extra string parameter to constraint functions
that will show a custom error message? This kind of works (although
you still get standard errors):
import std.conv;
import std.stdio;
alias int cool;
bool isCool(T, string X)()
{
static if (is(T : cool))
{
return
On Saturday 11 December 2010 11:48:36 David Nadlinger wrote:
> On 12/11/10 8:30 PM, Jonathan M Davis wrote:
> > You don't need that compatability with dlls? _That_ I did not know. That
> > would help a _lot_ in my case then, because most of our projects are
> > shared libraries. It doesn't entirely
On 12/11/10 8:30 PM, Jonathan M Davis wrote:
You don't need that compatability with dlls? _That_ I did not know. That would
help a _lot_ in my case then, because most of our projects are shared libraries.
It doesn't entirely solve the problem, but in this case, it's enough that it may
make it fea
On Sat, 11 Dec 2010 12:15:31 -0500, Andrei Alexandrescu
wrote:
[snip]
This program will generate a valid executable, but will also print
during compilation:
Type int is not a random access range because:
no empty property
no front property
no popFront method
no indexing
no sl
On 12/11/10, David Nadlinger wrote:
> On 12/11/10 8:06 PM, Andrej Mitrovic wrote:
>> Maybe if we have any luck with SWIG we'll be able to make some
>> primitive wrappers for common C++ libraries. I'm just trying SWIG out
>> these days, but some people have reported success in wrapping some
>> libr
On 12/11/10, Jonathan M Davis wrote:
> On Saturday 11 December 2010 11:06:45 Jesse Phillips wrote:
>> Andrei Alexandrescu Wrote:
>> > This program will generate a valid executable, but will also print
>> > during compilation:
>> >
>> > Type int is not a random access range because:
>> >no empt
Andrei Alexandrescu wrote:
>>
>> I'll share the tool when it's more complete, if this is something
>> that is
>> wanted for phobos I am willing to put it together.
>
> Yes please. Other Phobosites?
>
> Andrei
I'm sorry, I did not understand what you meant.
On Saturday 11 December 2010 11:06:45 Jesse Phillips wrote:
> Andrei Alexandrescu Wrote:
> > This program will generate a valid executable, but will also print
> > during compilation:
> >
> > Type int is not a random access range because:
> >no empty property
> >no front property
> >no
On Saturday 11 December 2010 11:17:27 David Nadlinger wrote:
> On 12/11/10 8:06 PM, Andrej Mitrovic wrote:
> > Maybe if we have any luck with SWIG we'll be able to make some
> > primitive wrappers for common C++ libraries. I'm just trying SWIG out
> > these days, but some people have reported succe
On 12/11/10 8:18 PM, Andrej Mitrovic wrote:
I've seen some tools that can convert OMF> COFF, but never the other
way around.
Well, there is e.g. »coff2omf« from DigitalMars, but I haven't had any
success with it.
David
On Saturday 11 December 2010 04:41:55 Bernard Helyer wrote:
> On Thu, 09 Dec 2010 20:54:14 -0800, Jonathan M Davis wrote:
> > In any case, you've found bugs, please point them out. I can't fix it if
> > I don't know that it's broken.
>
> The localtime it retrieves is incorrect, over here. It is al
On 12/11/10 8:06 PM, Andrej Mitrovic wrote:
Maybe if we have any luck with SWIG we'll be able to make some
primitive wrappers for common C++ libraries. I'm just trying SWIG out
these days, but some people have reported success in wrapping some
libraries.
While I certainly appreciate the adverti
I've seen some tools that can convert OMF > COFF, but never the other
way around.
On 12/11/10, David Nadlinger wrote:
> On 12/11/10 2:46 PM, Michael Stover wrote:
>> Having to use the dmc compiler on windows in order to leverage legacy
>> C++ code while being able to move on with new D code doesn
On Saturday 11 December 2010 04:33:07 spir wrote:
> Hello,
>
>
> Just stepped on the const faq page at
> http://www.digitalmars.com/d/2.0/const-faq.html. Illuminating :-)
>
> But I really wonder about the following topic:
>
> ==
> Why aren't function parameters const
On 12/11/10 11:56 CST, Jimmy Cao wrote:
I think bold instead of all caps would be better. Either way is fine,
though.
On Fri, Dec 10, 2010 at 4:05 PM, Lutger Blijdestijn
mailto:lutger.blijdest...@gmail.com>> wrote:
Andrei Alexandrescu wrote:
> On 12/9/10 8:04 PM, Andrej Mitrovic wrot
On 12/11/10 2:46 PM, Michael Stover wrote:
Having to use the dmc compiler on windows in order to leverage legacy
C++ code while being able to move on with new D code doesn't sound like
too much of a restriction. Is there a similar tool that allows linking
D and C++ on linux and mac?
You don't
Andrei Alexandrescu Wrote:
> This program will generate a valid executable, but will also print
> during compilation:
>
> Type int is not a random access range because:
>no empty property
>no front property
>no popFront method
>no indexing
>no slicing
>
> When a programmer h
On 12/11/10, Jonathan M Davis wrote:
> On Saturday 11 December 2010 05:46:33 Michael Stover wrote:
>> > LOL. I'd _love_ to use D at work, but so much of our code is in C++ and
>> > must
>>
>> compile with Visual Studio that the fact that C++ doesn't integrate with D
>> all
>>
>> that well and the
On Saturday 11 December 2010 03:35:29 Walter Bright wrote:
> Jonathan M Davis wrote:
> > I think that it's good to strive to a have a language that is excellent
> > for most use cases, but ultimately, you always have to pick the best
> > tool for the job. No language is the best for all scenarios e
On Saturday 11 December 2010 05:46:33 Michael Stover wrote:
> > LOL. I'd _love_ to use D at work, but so much of our code is in C++ and
> > must
>
> compile with Visual Studio that the fact that C++ doesn't integrate with D
> all
>
> that well and the fact that you have to use dmc on Windows for
If parameters are 'in' or 'const' by default, then whether they are
passed by value or by ref has no consequence, I guess. The compiler can
then safely choose the most efficent more --what it can do as it knows
sizeof-- grossly structs by ref, the rest by value. Is this reasoning
correct?
I think bold instead of all caps would be better. Either way is fine,
though.
On Fri, Dec 10, 2010 at 4:05 PM, Lutger Blijdestijn <
lutger.blijdest...@gmail.com> wrote:
> Andrei Alexandrescu wrote:
>
> > On 12/9/10 8:04 PM, Andrej Mitrovic wrote:
> >> The D website is 404'ing for the library pag
It would be a welcome improvement. One downside is that the relation between
the mismatched template and the range check is not there. I worry that it
will be hard to understand when facing a lot of errors, but will have to try
to find out. The error message dmd produces in the face of ambiguous
Those are the same ways of saying the same thing. You use C to implement
Ruby's garbage collector. Why? Because you have to. Why again? Because
it's the right tool for the job. In particular, C can do that because it
has pointer arithmetic - a freedom discriminated against by the speaker.
C
On 12/11/10 11:05 AM, so wrote:
Not to hijack this one but on the other thread i asked why this is needed.
I am not here asking for syntax or commanding phobos team to implement
something, I just want to know about technical limitations and license
issues, but got no answer to these.
Why? Either
On 12/11/10 11:05 AM, so wrote:
I find this issue interesting. I think the "the right tool for the job"
is justification for the existence of multiple languages, but on the
other hand, I'd agree with him that it's overused.
If you consider all problem domains, and then ask: what is the minimum
n
On 2010-12-11 11:48:36 -0500, spir said:
If parameters are 'in' or 'const' by default, then whether they are passed
by value or by ref has no consequence, I guess. The compiler can then safel
y choose the most efficent more --what it can do as it knows sizeof-- gross
ly structs by ref, the rest
Hello,
Following Craig's questions about sort(), I was thinking of the
following idea. How about defining a flag rangeCheckVerbose that emits
explanatory messages during compilation whenever a range check fails?
Consider this prototype:
import std.stdio;
version = rangeCheckVerbose;
templ
I find this issue interesting. I think the "the right tool for the job"
is justification for the existence of multiple languages, but on the
other hand, I'd agree with him that it's overused.
If you consider all problem domains, and then ask: what is the minimum
number of languages required
On Sat, 11 Dec 2010 09:06:33 -0500
Michel Fortin wrote:
> On 2010-12-10 19:32:30 -0500, Andrei Alexandrescu
> said:
>
> > On 12/10/10 4:10 PM, foobar wrote:
> >> Don Wrote:
> >>
> >>> Steven Schveighoffer wrote:
> To summarize for those looking for the C++ behavior, the equivalent
>
"Michael Stover" wrote in message
news:mailman.900.1292075203.21107.digitalmar...@puremagic.com...
> >
>> LOL. I'd _love_ to use D at work, but so much of our code is in C++ and
>> must
>
> compile with Visual Studio that the fact that C++ doesn't integrate with D
> all
>
> that well and the fact
On 12/11/10, Andrei Alexandrescu wrote:
> We stand to lose the ability to express designs clearly and in good
> detail whichever of the above we eliminate. What do we take away?
>
>
> Andrei
>
Nothing. Keep D2 as it is. We have to use D2 for a few years and build
some cool apps, before we can fig
On Sat, Dec 11, 2010 at 10:28:06AM +0100, spir wrote:
> "the code is really hard to read": People should stop thinking & feeling
> everybody should think & feel the way they do.
That's essentially my point. For every ruby or python fan who talks about
beauty you can probably find a C fan to say
On 12/11/10 2:49 CST, spir wrote:
On Fri, 10 Dec 2010 18:28:08 -0800
Andrei Alexandrescu wrote:
It's sort of ironic. Tu viens d'implementing yet another type
constructor yourself!
The need for yet another one signifie sûrement (probably means) their semantics
(in the human sense) are wrongl
On 12/11/10 2:42 CST, spir wrote:
On Fri, 10 Dec 2010 21:25:49 -0500
Michel Fortin wrote:
On 2010-12-10 17:12:16 -0500, Don said:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent would be:
void foo(auto ref const Widget)
That use of 'auto'
On 2010-12-10 19:32:30 -0500, Andrei Alexandrescu
said:
On 12/10/10 4:10 PM, foobar wrote:
Don Wrote:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
I agree
On 12/11/2010 12:12 AM, Nick Sabalausky wrote:
I can definitely see in Ruby how the designer was trying for a "natural
language/thought-process" feel, but it just ends up feeling
sloppily-designed. I never feel completely confident that what I write is
actually going to get parsed as I intended.
On 12/10/2010 10:26 PM, Ary Borenszweig wrote:
http://vimeo.com/17420638
A very interesting talk.
I used to like D. To write code in a high level while at the same
time being very close to the machine, with class invariants, unit
tests and many other features seemed very appealing. But I always
>
> LOL. I'd _love_ to use D at work, but so much of our code is in C++ and
> must
compile with Visual Studio that the fact that C++ doesn't integrate with D
all
that well and the fact that you have to use dmc on Windows for the C or C++
code
if you want to link it with D code make it so that it
On Thu, 09 Dec 2010 20:54:14 -0800, Jonathan M Davis wrote:
> In any case, you've found bugs, please point them out. I can't fix it if
> I don't know that it's broken.
The localtime it retrieves is incorrect, over here. It is always one and
a half hours slow. I am retrieving it using Clock.currTi
Hello,
Just stepped on the const faq page at
http://www.digitalmars.com/d/2.0/const-faq.html. Illuminating :-)
But I really wonder about the following topic:
==
Why aren't function parameters const by default?
Since most (nearly all?) function parameters will not b
On 11/12/2010 00:38, Andrei Alexandrescu wrote:
The std.datetime Phobos submission has been accepted with a landslide
vote that is usually seen only in North Korea.
Many thanks to Jonathan for the hard work, and to everybody who helped
him knocking this into good shape.
Jonathan, please send me
Jonathan M Davis wrote:
I think that it's good to strive to a have a language that is excellent for most
use cases, but ultimately, you always have to pick the best tool for the job. No
language is the best for all scenarios even if it's the best for most scenarios.
If you're an expert on X,
On Sat, 11 Dec 2010 10:29:20 +0100
"Jérôme M. Berger" wrote:
> There is a major syntax issue with Ruby. This line:
>
> foo(a, b)
>
> does not mean the same thing as this line:
>
> foo (a, b)
>
> !!WT?
It is an issue for us, because we are used to non-significant spacing. But non
On Sat, 11 Dec 2010 10:22:19 +0100
Don wrote:
> Andrei Alexandrescu wrote:
> > Agreed. One issue with the talk is non-acceptance of "the right tool for
> > the job" (the speaker literally says he's tired of that phrase). There
> > is one best tool - and that's Ruby. Ahem.
>
> I find this issue
On Sat, 2010-12-11 at 01:12 -0500, Nick Sabalausky wrote:
[ . . . ]
> I can definitely see in Ruby how the designer was trying for a "natural
> language/thought-process" feel, but it just ends up feeling
> sloppily-designed. I never feel completely confident that what I write is
> actually going
Ary Borenszweig wrote:
> http://vimeo.com/17420638
>
> A very interesting talk.
>
> I used to like D. To write code in a high level while at the same
> time being very close to the machine, with class invariants, unit
> tests and many other features seemed very appealing. But I always
> felt ther
On Fri, 10 Dec 2010 20:31:38 -0500
"Adam D. Ruppe" wrote:
> On Sat, Dec 11, 2010 at 01:26:01AM +, Ary Borenszweig wrote:
> > http://vimeo.com/17420638
>
> Is that a full hour of a guy preaching to the choir...
>
> Got a summary?
>
> > with ease) and stop caring about being C-syntax friendl
Andrei Alexandrescu wrote:
On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote:
On 12/10/10 19:26, Ary Borenszweig wrote:
http://vimeo.com/17420638
A very interesting talk.
I used to like D. To write code in a high level while at the same
time being very close to the machine, with class i
Michel Fortin wrote:
On 2010-12-10 17:12:16 -0500, Don said:
Steven Schveighoffer wrote:
To summarize for those looking for the C++ behavior, the equivalent
would be:
void foo(auto ref const Widget)
That use of 'auto' is an abomination.
One problem I'm starting to realize is that we now
On Fri, 10 Dec 2010 18:28:08 -0800
Andrei Alexandrescu wrote:
> It's sort of ironic. Tu viens d'implementing yet another type
> constructor yourself!
The need for yet another one signifie sûrement (probably means) their semantics
(in the human sense) are wrongly defined. D2 needs un regard neu
On Fri, 10 Dec 2010 21:25:49 -0500
Michel Fortin wrote:
> On 2010-12-10 17:12:16 -0500, Don said:
>
> > Steven Schveighoffer wrote:
> >> To summarize for those looking for the C++ behavior, the equivalent would
> >> be:
> >>
> >> void foo(auto ref const Widget)
> >
> > That use of 'auto' is
On Saturday 11 December 2010 00:01:35 Andrei Alexandrescu wrote:
> On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote:
> > On 12/10/10 19:26, Ary Borenszweig wrote:
> >> http://vimeo.com/17420638
> >>
> >> A very interesting talk.
> >>
> >> I used to like D. To write code in a high level whi
On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote:
On 12/10/10 19:26, Ary Borenszweig wrote:
http://vimeo.com/17420638
A very interesting talk.
I used to like D. To write code in a high level while at the same
time being very close to the machine, with class invariants, unit
tests and ma
94 matches
Mail list logo
