On Fri, 19 Jun 2009 03:13:11 +0300, Derek Parnell wrote:
Steve Teale (steve.te...@britseyeview.com) wrote:
Now I admit that these are not method names I would have choosen, as I
would have preferred names more like ... isEmpty(), getFront(),
moveForwards(), getBack(), moveBackwards(), getElement
On Sat, 06 Jun 2009 16:35:15 +0300, Christopher Wright
wrote:
Kristian Kilpi wrote:
I think I shouldn't post this because I could very well start one of
those mega-threads... :D
Of course, only Walter & Co know what D2 will include when it's
finally 'released'
I think I shouldn't post this because I could very well start one of those
mega-threads... :D
Of course, only Walter & Co know what D2 will include when it's finally
'released'. Concurrency stuff has been developed lately. But something
more? Or is that it? What do you think?
I haven't
On Wed, 20 May 2009 21:02:02 +0300, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
Bicycle shed: Well, since output ranges use 'put', how about 'get' for
input ranges?
Nice color :o). In fact, "put" is a poor choice because it doesn't
reflect advancement. Probably putNext and getNext
On Sun, 03 May 2009 15:33:12 +0300, Jérôme M. Berger
wrote:
|
| foreach(c; str)
| {
| ret = (ret << 4) + c;
| }
|
That one is very bad because it only takes into account the last
few characters of the string (how many depends on the size of the
hash). However, several hashing algori
On Sun, 03 May 2009 04:59:26 +0300, BCS wrote:
IIRC something like this is common:
hash_t ret = 0;
foreach(c;str) { ret *= SomePrime; ret += c; }
I think that's the basis for the best general string hashing funcs around.
IIRC from the university, it doesn't matter, in practice, if the
m
On Sun, 12 Apr 2009 22:00:43 +0300, Walter Bright
wrote:
Jarrett Billingsley wrote:
Whether it'll be going away, I'm not sure. I guess Walter is the only
one who knows that.
I see no point to breaking invariant() again.
Will 'invariant' as a type modifier go away? If so, then of course th
On Sun, 22 Mar 2009 14:14:39 +0200, Christopher Wright
wrote:
Kristian Kilpi wrote:
#includes/imports are redundant information: the source code of course
describes what's used in it. So, the compiler could be aware of the
whole project (and the libraries used) instead of one file a
On Sat, 21 Mar 2009 22:19:31 +0200, grauzone wrote:
I don't really understand what you mean. But if you want the compiler to
scan for dependencies, I fully agree.
I claim that we don't even need incremental compilation. It would be
better if the compiler would scan for dependencies, and if
