Adam D. Ruppe wrote:
> On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote:
>> I disagree, I find the function calls without the () to be really
>> prettifying.
>>
>> But maybe that's just me.
>>
>> I don't think that it causes serious bugs, you would see that it's an
>> integer the mom
Nick Sabalausky wrote:
> - Does nothing to change my opinion that Google has done nothing noteworthy
> outside of search engines and maybe their ad service.
>
>
Google Maps (not sure if you counted that under search); but their real
strength is context-aware integration of different services.
%u wrote:
> In the end this brings me to a sad thing: I nearly never get dsource projects
> to compile. And most of the
> time (I guess) its about build system problems. So why dont you all write
> these very simple makefiles
> and throw everything at the compiler? Such makefiles would be very ea
Justin Johansson wrote:
> Happy New Year 2010 Everybody.
>
> Having resumed C++ nationality for the last few months, I kind of miss D's
> auto keyword.
>
If you're on gcc or a compiler that allows the typeof extension:
#define DECL(A, B) typeof(B) A = B
:)
Ashok wrote:
> "Don" wrote in message
> news:hh6v0a$1bc...@digitalmars.com...
>> Ashok wrote:
>>> Don wrote:
Ashok wrote:
> Sean Kelly wrote:
>> Ashok Wrote:
>>
>>> Actually, I have another question before the one in the subject
>>> line: How many types of arrays are ther
Eldar Insafutdinov wrote:
> Currently we have ParameterTypeTuple for extracting type list of function
> arguments. This is not enough. There should be a clean way to extract storage
> classes and default arguments if there are any. Any thoughts?
Parsing stringof is not required.
There's a trick
Hi,
recently I ran into a situation where I wanted to keep a freelist of freed
textures for every OpenGL context (there can be multiple).
I started with static { int[] freelist; } then realized this wouldn't work
because there'd be no way to map texture IDs to contexts.
To simplify situations
Daniel wrote:
> I'm writing some gui code, and am currently trying to make something
> equivalent to this:
>
> int delegate()[] funcs;
> funcs.length = 3;
>
> foreach(i, ref f; funcs)
> {
> f = int() { return i; }
> }
>
> foreach(f; funcs)
> {
> writeln(f());
> }
>
> Prints:
> 3
> 3
> 3
>
Lutger wrote:
> downs wrote:
>
>> Or are there any bugs/optimization opportunities I'm missing?
>>
>> void qsort(T)(T[] array) {
>> if (array.length < 2) return;
>> static int i;
>> auto pivot = array[i++%$];
>> // from is ba
according to
http://www.mail-archive.com/haskell-cafe%40haskell.org/msg63381.html
I'll let this speak for itself.
import Data.Array.Base (unsafeRead, unsafeWrite)
import Data.Array.ST
import Control.Monad.ST
myqsort :: STUArray s Int Int -> Int -> Int -> ST s ()
myqsort a lo hi
| lo < hi
Or are there any bugs/optimization opportunities I'm missing?
void qsort(T)(T[] array) {
if (array.length < 2) return;
static int i;
auto pivot = array[i++%$];
// from is base-0, to is base-1.
int from = 0, to = array.length;
while (from != to) {
if (array[from] >= pivot && array[t
retard wrote:
> Sat, 19 Dec 2009 14:04:32 -0600, Andrei Alexandrescu wrote:
>
>> Walter Bright wrote:
>>> The Haskell folks really need to find a better canonical example.
>> Add to that the Erlang folk, too. I'm reading the book on Erlang by
>> Armstrong. Here's the Quicksort section and example
Tim Matthews wrote:
> downs wrote:
>> I've just committed a module to tools that should enable linking and
>> using any C++ library with D programs without creating a C wrapper for
>> it.
>>
>
>
> Does 'any' c++ library even include the ones i
retard wrote:
> Thu, 10 Dec 2009 01:01:34 +0100, downs wrote:
>
>> including such gems as incorrect
>> tuple lengths, incorrect tuple slices, endless errors without line
>> numbers, spurious template instantiation errors with nonsensical
>> parameters, and at least
dsimcha wrote:
> == Quote from downs (default_357-l...@yahoo.de)'s article
>> I've just committed a module to tools (tools.cpp,
> http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should
> enable
> linking and using any C++ library with D programs wit
BCS wrote:
> please tell me the subject is a freudian slip (or just a typo).
>
>
Considering the amount of abuse me and the compiler put each other through in
the course of writing this, including such gems as incorrect tuple lengths,
incorrect tuple slices, endless errors without line numbers,
g wrote:
> downs Wrote:
>
>> I've just committed a module to tools (tools.cpp,
>> http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should
>> enable linking and using any C++ library with D programs without creating a
>> C wrapper for it.
&g
ot;&"~`~mname~`~") {
return
"~`~mname~`~"("~refToValueList(isRef!(typeof(mixin("&"~`~mname~`~");
}
"); `;
--downs
Nick Sabalausky wrote:
> I just noticed in D1 that the values for the cases in a switch must be known
> at compile-time (btw, the docs don't seem somewhat vague on that). Is this
> also true in D2? If so, I don't suppose we could get that changed before the
> book? It's a real PITA for dynamic c
omg wrote:
> AJ Wrote:
>
>> You didn't do bad. You may be on the crossroad of doing bad. No one is going
>> to say you are or were bad. Today. Tomorrow is another time, and another
>> choice maybe for you. Everyone is going to be just fine, unless you don't do
>> the right thing. The right thin
Robert Jacques wrote:
> On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun
> wrote:
>
>> Robert Jacques wrote:
>>> On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
>>> wrote:
>>>
dsimcha wrote:
> Axe. Looks like the only things it's good for are making code
> undreadable and
Bill Baxter wrote:
> On Sat, Nov 14, 2009 at 10:16 AM, downs wrote:
>> Slightly modified from what you so amusingly called "my CoolTools.ctfe":
>>
>> ctSlice (not to be confused with the [] array slicing functionality)
>> "slices" a string in two at
Slightly modified from what you so amusingly called "my CoolTools.ctfe":
ctSlice (not to be confused with the [] array slicing functionality) "slices" a
string in two at a marker, returning the text before the marker and removing it
(and the marker) from the input text.
The ct prefix is handy f
Justin Johansson wrote:
> downs Wrote:
>
>> auto var = hairilyAllocatedObject();
>> scope(exit) cleanupObject(var);
>>
>> sock.send("");
>> scope(exit) sock.send("");
>>
>> logln("Digraph D {");
>> scope(exit)
auto var = hairilyAllocatedObject();
scope(exit) cleanupObject(var);
sock.send("");
scope(exit) sock.send("");
logln("Digraph D {");
scope(exit) logln("}");
SDL_LockSurface(display.surface);
scope(exit) SDL_UnlockSurface(display.surface);
auto dg = { performComplexExitCleanupDuty; };
scope(exit
dsimcha wrote:
> == Quote from downs (default_357-l...@yahoo.de)'s article
>> dsimcha wrote:
>>> == Quote from downs (default_357-l...@yahoo.de)'s article
>>>> I submitted a patch a while back for constant-time removeRange. Can we
>>>> dredg
dsimcha wrote:
> == Quote from downs (default_357-l...@yahoo.de)'s article
>> I submitted a patch a while back for constant-time removeRange. Can we dredge
> that one up and/or implement something similar? It's rather useful for things
> like
> stackthreads that ne
I submitted a patch a while back for constant-time removeRange. Can we dredge
that one up and/or implement something similar? It's rather useful for things
like stackthreads that need to add and remove lots of ranges :)
(Search the NG for "Feature req.+Patch: O(1) removeRange")
Walter Bright wrote:
> http://langref.org/
>
> Need some D versions!
http://rosettacode.org/wiki/Category:D is much more complete.
AJ wrote:
> "Nick Sabalausky" wrote in message
> news:hboum3$1bh...@digitalmars.com...
>> "AJ" wrote in message
>> news:hbosh1$17l...@digitalmars.com...
>>> "Nick Sabalausky" wrote in message
>>> news:hbontv$uq...@digitalmars.com...
If you want to manually write a separate redundant file
sprucely wrote:
> To try to be sure I had the correct syntax I tried the -S option of g++ along
> with a switch for intel syntax to output the assembly. However the portion
> corresponding to the inline assembly was still in ATT syntax.
>
> For my resulting D executable I tried using hte, but it
Walter Bright wrote:
> Currently, static arrays are (as in C) half-value types and
> half-reference types. This tends to cause a series of weird problems and
> special cases in the language semantics, such as functions not being
> able to return static arrays, and out parameters not being possible
Walter Bright wrote:
> Ary Borenszweig wrote:
>> I remember seeing a lot of CTFE code that created a dynamic array and
>> then appended stuff to it, like for example to build a list of prime
>> numbers. Would that still work with ArrayBuilder?
>
> Probably not. But you can rewrite:
>
> a ~= stu
dsimcha wrote:
> == Quote from downs (default_357-l...@yahoo.de)'s article
>> Walter Bright wrote:
>>> The purpose of T[new] was to solve the problems T[] had with passing T[]
>>> to a function and then the function resizes the T[]. What happens with
>>> t
Walter Bright wrote:
> The purpose of T[new] was to solve the problems T[] had with passing T[]
> to a function and then the function resizes the T[]. What happens with
> the original?
>
> The solution we came up with was to create a third array type, T[new],
> which was a reference type.
>
> And
Jeremie Pelletier wrote:
> Nick Sabalausky wrote:
>> "downs" wrote in message
>> news:hb83h6$1ht...@digitalmars.com...
>>> Gemaine Frazier wrote:
>>>> completely chilled - a glass or two of wine will do that...
>>> you all! Except you, wei
Gemaine Frazier wrote:
> completely chilled - a glass or two of wine will do that...
you all! Except you, weird spacey goat thing. You freak me out.
But man this is some FINE weed!
On consideration, this wasn't a test of the two methods at all, but a test of
the compiler's ability to inline. Disregard it.
Two discoveries were made from this benchmark.
1) There is no appreciable speed difference between delegates and functors. I
re-ran the benchmark several times; sometimes one was faster, sometimes the
other - no clear advantage was discernible. The visible differences can be
blamed on experimen
Justin Johansson wrote:
> - that the .sizeof a delegate is 8 bytes (on a 32-bit machine).
>
> AFAIK, stack pushes are still more expensive than a pointer dereference in
> contemporary
> CPU architectures.
>
> Justin
- with this weird way of writing posts? The subject should tell us about the
c
Jeremie Pelletier wrote:
> Andrei Alexandrescu wrote:
>> Chris Nicholson-Sauls wrote:
>>> downs wrote:
>>>>
>>>> Here is a funny consequence of this amusing fact:
>>>>
>>>> if you overload opAssign in a stru
downs wrote:
> Did you know the following code compiles?
>
>> module test;
>>
>> import std.stdio;
>>
>> void Assert(bool cond, string delegate()[] dgs...) {
>> debug if (!cond) {
>> string str;
>> foreach (dg; dgs) str ~= dg();
&
Did you know the following code compiles?
> module test;
>
> import std.stdio;
>
> void Assert(bool cond, string delegate()[] dgs...) {
> debug if (!cond) {
> string str;
> foreach (dg; dgs) str ~= dg();
> throw new Exception(str);
> }
> }
>
> void main() {
> Assert(false, "O hai
Jeremie Pelletier wrote:
> downs wrote:
>> Don wrote:
>>> downs wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> downs wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> downs wrote:
>>>>>>>>
Don wrote:
> downs wrote:
>> Andrei Alexandrescu wrote:
>>> downs wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> downs wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> Hello,
>>>>>>>
>>>
Andrei Alexandrescu wrote:
> downs wrote:
>> Andrei Alexandrescu wrote:
>>> downs wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> Hello,
>>>>>
>>>>>
>>>>> D currently allows defining class allocators and dealloc
Andrei Alexandrescu wrote:
> downs wrote:
>> Andrei Alexandrescu wrote:
>>> Hello,
>>>
>>>
>>> D currently allows defining class allocators and deallocators. They have
>>> a number of problems that make them unsuitable for D 2.0. The mo
Andrei Alexandrescu wrote:
> Hello,
>
>
> D currently allows defining class allocators and deallocators. They have
> a number of problems that make them unsuitable for D 2.0. The most
> obvious issue is that D 2.0 will _not_ conflate destruction with
> deallocation anymore: invoking delete agains
bearophile wrote:
> Denis Koroskin:
>
>> I don't see any reason why if (someComplexNumber) { ... } should be a
> valid code, it hardly makes any sense for me.<
>
> In general I think adding a boolean-evaluation standard method to D can be
> positive and handy and not that bug-prone.
> But comp
Denis Koroskin wrote:
> I'm currently writing a program that interfaces with C++.
> C++ code uses a lot of 'unsigned long', which equals to 'unsigned int',
> or just 'unsigned', but is mangled differently.
>
> In particular, C++ mangles unsigned long as 'K', and I can't find a D
> counterpart that
Justin Johansson wrote:
> Walter Bright Wrote:
>
>> http://www.reddit.com/r/programming/comments/9qf8i/i_wrote_some_d_today_and_its_completely_blowing/
>
> Don't know why you bother with Reddit, Walter. Going by a lot of the replies
> there, its a case of
> pearls before swine.
>
> Cheers
> --
language_fan wrote:
> Fri, 02 Oct 2009 19:35:55 -0300, Leandro Lucarella thusly wrote:
>
>> We might have very different taste, but I find that a little...
>> horrible. What do you have against mixins? I think you're trying to use
>> D as C++ :)
>
> So basically the diamond problem is again imple
Jeremie Pelletier wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> Here's an article about the perils of equals in Java (opEquals in D):
>>>
>>> http://www.ddj.com/article/printableArticle.jhtml;jsessionid=GFKUCQH5S4IHNQE1GHOSKHWATMY32JVN?articleID=184405053&dept_url=/java/
>>>
>>>
>>> It
Jeremie Pelletier wrote:
> downs wrote:
>> Jeremie Pelletier wrote:
>>> Christopher Wright wrote:
>>>> Jeremie Pelletier wrote:
>>>>> What if using 'Object obj;' raises a warning "unitialized variable"
>>>>> an
Jeremie Pelletier wrote:
> Andrei Alexandrescu wrote:
>> downs wrote:
>>> Walter Bright wrote:
>>>> Nick Sabalausky wrote:
>>>>
>>>> I agree with you that if the compiler can detect null dereferences at
>>>> compile time, it should
Jeremie Pelletier wrote:
> Christopher Wright wrote:
>> Jeremie Pelletier wrote:
>>> What if using 'Object obj;' raises a warning "unitialized variable"
>>> and makes everyone wanting non-null references happy, and 'Object obj
>>> = null;' raises no warning and makes everyone wanting to keep the
>>
Jeremie Pelletier wrote:
> Jarrett Billingsley wrote:
>> On Sat, Sep 26, 2009 at 11:23 PM, Jeremie Pelletier
>> wrote:
>>
>>> There is no such thing as "not being able to happen" :)
>>>
>>> Object thisCannotPossiblyBeNullInAnyWayWhatsoever = cast(Object)null;
>>>
>>> I seem to be the only one who
Denis Koroskin wrote:
> On Sun, 27 Sep 2009 03:01:48 +0400, Walter Bright
> wrote:
>
>> Denis Koroskin wrote:
>>> One more:
>>> T foo(bool someCondition)
>>> {
>>> T? t;
>>> if (someCondition) t = someInitializer();
>>> // ...
>>> if (t.isNull) { // not initialized yet
>>>
Walter Bright wrote:
> Nick Sabalausky wrote:
>
> I agree with you that if the compiler can detect null dereferences at
> compile time, it should.
>
>
>>> Also, by "safe" I presume you mean "memory safe" which means free of
>>> memory corruption. Null pointer exceptions are memory safe. A null
>
Jeremie Pelletier wrote:
> downs wrote:
>> Jeremie Pelletier wrote:
>>> downs wrote:
>>>> Jeremie Pelletier wrote:
>>>>> grauzone wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> downs wrote:
>>>>>&g
Jeremie Pelletier wrote:
> downs wrote:
>> Jeremie Pelletier wrote:
>>> grauzone wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> downs wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> downs wrote:
>>>>&
language_fan wrote:
> Thu, 24 Sep 2009 13:47:21 -0400, Steven Schveighoffer thusly wrote:
>
>> I actually prefer the compiler to handle the casting versus templates to
>> cut down on template instantiation bloat.
>
> I wonder how D scales to 100 MLOC programs as the template instantiations
> can
Jeremie Pelletier wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> downs wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> downs wrote:
>>>>>> With all the neat template tricks we have in 2.0, and since we're
>&
bearophile wrote:
> Justin Johansson:
>> See subject line
>
> You can't. All questions here will be scrupulously scrubbed, looking for
> subversive ideas or hidden irony, and if something is found they invariably
> spout and blossom into invasive threads of often pointless but interesting
> dis
Andrei Alexandrescu wrote:
> downs wrote:
>> With all the neat template tricks we have in 2.0, and since we're
>> widely redefining the syntax anyway, why not deprecate the current
>> cast syntax and move it into object.d as a library function?
>>
>> So instea
With all the neat template tricks we have in 2.0, and since we're widely
redefining the syntax anyway, why not deprecate the current cast syntax and
move it into object.d as a library function?
So instead of cast(Foo) bar; you would say cast!Foo(bar); .. save on a keyword
and demonstrate langua
language_fan wrote:
> Sun, 20 Sep 2009 18:16:37 -0400, bearophile thusly wrote:
>
>> My benchmarks aren't chosen randomly, I naturally focus on things that
>> are slower in D, so sometimes you can see Java to "win". I usually
>> discard the code where Java results slower :-)
>
> I have seen peopl
Nick Sabalausky wrote:
> "Justin Johansson" wrote in message
> news:h8ruu1$1qp...@digitalmars.com...
>> Being somewhat of a fan of Elliotte Rusty Harold, I drop in for a coffee &
>> read at his cafes from time to time. I think D people will enjoy this
>> December 2008 article with amusement so
Justin Johansson wrote:
>downs Wrote:
>>
>> Justin Johansson wrote:
>>> Can D people please recommend suitable tools for generating a parser (in D)
>>> for an LL(1) grammar. There's bound to be much better parser generator
>>> tools available
Justin Johansson wrote:
> > downs Wrote:
> >
>> >> Justin Johansson wrote:
>>> >>> Can D people please recommend suitable tools for generating a parser
>>> >>> (in D) for an LL(1) grammar. There's bound to be much better parser
Justin Johansson wrote:
> Can D people please recommend suitable tools for generating a parser (in D)
> for an LL(1) grammar. There's bound to be much better parser generator tools
> available nowadays, since my last foray into this area 10+ years ago with
> YACC. I've heard of tools like biso
Robert Fraser wrote:
> downs wrote:
>> foo.betweens("src=\"", "\"") /select/ (string s) { return
>> s.find(criteria) != -1; }
>
> Heh, I love that infix expression syntax. Too abd it ends up with a
> completely useless wrapper struct &
I think a favorite line of D code should have a feature of D that
>> doesn't appear in any other language...
>
> I've heard a d guru known as 'downs' is the master of obfuscated one-
> liners.
Well I wouldn't call myself a 'guru' .. 'mutilator&#
Walter Bright wrote:
> Jeremie Pelletier wrote:
>> Isn't it possible to make 'const ref S' or 'in S' generate the same
>> machine code as 'in S*'? To me it would seem the semantics of the two
>> are the same, with 'const S*' being useful syntax for C compatibility
>> while 'in S' and 'const ref S'
Lars T. Kyllingstad wrote:
> Tim Matthews wrote:
>> Jarrett Billingsley Wrote:
>>
>>> On Mon, Aug 17, 2009 at 7:42 PM, Paul D.
>>> Anderson wrote:
It's awfully quiet on the newsgroup today. Does that mean Walter is
busy getting the new release ready?
Or does it only mean I'm not
BCS wrote:
> Reply to Jarrett,
>
>> On Mon, Aug 17, 2009 at 7:42 PM, Paul D.
>> Anderson wrote:
>>> It's awfully quiet on the newsgroup today. Does that mean Walter is
>>> busy getting the new release ready?
>>>
>>> Or does it only mean I'm not getting new posts :(
>>>
>>> Suspiciously,
>>>
>>> Pa
grauzone wrote:
> Daniel Keep wrote:
>>
>> grauzone wrote:
>>> torhu wrote:
On 03.08.2009 19:47, Andrei Alexandrescu wrote:
> A while ago I mentioned the video of my BoostCon keynote "Iterators
> Must
> Go" will be soon available online. Here it is:
>
> http://boostcon.blip
Leandro Lucarella wrote:
> downs, el 30 de julio a las 22:31 me escribiste:
>> To clarify for a few criticisms that have come up in IRC: this is meant as a
>> rule of thumb to fall back on where no other considerations are present.
>>
>> For instance, const and shared
Sergey Gromov wrote:
> Thu, 30 Jul 2009 21:57:33 +0200, downs wrote:
>
>> 1) If it's a word, put it in the standard library.
>> 2) Otherwise, put it in the compiler.
>>
>> For example:
>>
>> assert() -> library.
>> complex -> library.
&g
Lars T. Kyllingstad wrote:
> downs wrote:
>> To clarify for a few criticisms that have come up in IRC: this is
>> meant as a rule of thumb to fall back on where no other considerations
>> are present.
>>
>> For instance, const and shared are type constructors,
Michiel Helvensteijn wrote:
> downs wrote:
>
>> 1) If it's a word, put it in the standard library.
>> 2) Otherwise, put it in the compiler.
>
> What an interesting theory.
>
>> For example:
>>
>> assert() -> library.
>
> Compile-tim
downs wrote:
> Walter Bright wrote:
>> downs wrote:
>>> As it stands, the claim on the homepage that it's easier to implement
>>> a D compiler than a C++ one is highly dubious.
>> Since I'm the only person to have implemented both, I think I'm in a
To clarify for a few criticisms that have come up in IRC: this is meant as a
rule of thumb to fall back on where no other considerations are present.
For instance, const and shared are type constructors, and as such hard to do in
the standard library.
To my knowledge, assert() for instance has
language_fan wrote:
> Thu, 30 Jul 2009 21:57:33 +0200, downs thusly wrote:
>
>> As it stands, the claim on the homepage that it's easier to implement a
>> D compiler than a C++ one is highly dubious.
>
> Isn't D simpler to implement than C++ because the
Walter Bright wrote:
> downs wrote:
>> As it stands, the claim on the homepage that it's easier to implement
>> a D compiler than a C++ one is highly dubious.
>
> Since I'm the only person to have implemented both, I think I'm in a
> good position to judge
In this post, I present a simple rule of thumb that covers most cases of the
common decision: should a feature go in the compiler, or in the standard
library?
Note: this only applies to features that aren't in C.
1) If it's a word, put it in the standard library.
2) Otherwise, put it in the com
Bill Baxter wrote:
> On Wed, Jul 29, 2009 at 8:11 AM, downs wrote:
>> Bill Baxter wrote:
>>> Just remembered this other real example of a D property that caused me
>>> discomfort:
>>>
>>> .transform
>>>
>>> I wanted it to be an u
Bill Baxter wrote:
> Just remembered this other real example of a D property that caused me
> discomfort:
>
> .transform
>
> I wanted it to be an unambiguous property that returns the transform
> of an object, but it's too easy to misinterpret as an action that
> transforms the object if it can
Ary Borenszweig wrote:
> downs escribió:
>> dsimcha wrote:
>>> I know I've probably mentioned this one here before, but it was
>>> buried in long
>>> threads.
>>>
>>> Could we put a feature in the language that allows private member
>
dsimcha wrote:
> I know I've probably mentioned this one here before, but it was buried in long
> threads.
>
> Could we put a feature in the language that allows private member variables to
> be cast to public? The idea is that, if a class/struct designer makes
> something private, they're saying
Don wrote:
> Steve Teale wrote:
>> To the D Faithful:
>>
>> In recent postings, I have increasingly seen references to the
>> 'Select Few'.
>>
>> This kind of reminds me of Iran, where you have 'The Guardian
> Council', and 'The Supreme Leader'.
>
> The similarities are pretty weak, I'd say.
> Wh
Jerry Quinn wrote:
> Hi, all. I find myself a little confused about how foreach, opApply, and
> delegates interact according to the docs.
>
> Foreach on an aggregate will use the opApply call (assuming ranges aren't
> being used). So if we use a simple example below, what exactly is the
> del
Denis Koroskin wrote:
> I just started using nothrow functions a little bit and came across the
> following issue.
> Some of the functions that I'd like to mark as nothrow have debug
> asserts inside them.
>
> They used to throw an Exception, but I'd like to change their behavior
> and terminate a
Jeremie Pelletier wrote:
> Why is there no !in operator just like there is a !is operator?
> Is it because this expression evaluates to a pointer to the found element?
> Even so, it would make asserts much easier to write.
http://dsource.org/projects/scrapple/browser/trunk/tools/tools/base.d
too
Jarrett Billingsley wrote:
> On Mon, May 18, 2009 at 2:57 PM, Andrei Alexandrescu
> wrote:
>> Andrei Alexandrescu wrote:
>>> I don't think "out" is doable.
>> I take that back. It is doable. The code below prints "void function(out int
>> _param_0)":
>>
>> struct S
>> {
>>void blah(out int) {}
Christopher Wright wrote:
> Brad Roberts wrote:
>> An interesting side effect of these changes is that thread startup
>> cost is going to increase. Yet more reasons to avoid globals and
>> global initialization.
>>
>> -- Brad
>
> It'll further promote use of threadpools. This isn't terribly safe
Consider this type:
struct StringPosition {
size_t pos;
void opImplicitCast(out size_t sz) {
sz = pos;
}
void opImplicitCast(out bool b) {
b = pos != -1;
}
}
Wouldn't that effectively sidestep most problems people have with find
returning -1?
Or am I missing something?
Of cou
So .. how will the threadlocal global variables be initialized?
Obviously, they can't be initialized in the static constructor, since that is
only run once.
But if the static constructors are run on every new thread, what about the
shared variables that only need to be initialized once?
For th
Steve Teale wrote:
> bearophile Wrote:
>
>> So I agree with nearly nothing you have (badly) expressed.
>>
>> Bye,
>> bearophile
>
> Who is this guy?" He must be putting his messages through one of those web
> sites that translate into strange dialects - fry my ass!
>
> I'm with you, reading K&
Joel C. Salomon wrote:
> grauzone wrote:
>> downs wrote:
>>> Daniel Keep wrote:
>>>> Here's an excellent reason to use ranges over opApply: you
>>>> can't define zip with opApply. Because opApply uses inversion of
>>>> contro
1 - 100 of 137 matches
Mail list logo
