Re: Getting overloads of free functions

2009-10-12 Thread Christopher Wright
Lutger wrote: Probably has been discussed before but I couldn't figure it out: Is it possible to retrieve the signatures of overloaded functions (not virtuals) at compile time? No. You can't even get all the overloads of class methods at compile time (only non-private non-static methods, as

Re: Forward references and more

2009-10-12 Thread Steven Schveighoffer
On Mon, 12 Oct 2009 15:38:07 -0400, bearophile wrote: Steven Schveighoffer: It looks strange what you are doing. A Foo can have a memory pool of a lot of Foo's? Do you mean to make the memory pool static? Right and yes. I think that might work.< It works if I use a global variable.

Re: Forward references and more

2009-10-12 Thread bearophile
Ary Borenszweig: > I can see MemoryPool!(Foo) sizeof doesn't depend at all of T.sizeof > because it just has a pointer. Well, a dynamic array of pointers, but the situation is the same. >But how do you suggest to fix the compiler to understand that?< I don't know. I don't know enough about co

Getting overloads of free functions

2009-10-12 Thread Lutger
Probably has been discussed before but I couldn't figure it out: Is it possible to retrieve the signatures of overloaded functions (not virtuals) at compile time?

Re: Forward references and more

2009-10-12 Thread Ary Borenszweig
Steven Schveighoffer wrote: On Mon, 12 Oct 2009 05:26:58 -0400, bearophile wrote: What's wrong with this code? struct MemoryPool(T) { alias T[100_000 / T.sizeof] Chunk; Chunk*[] chunks; } struct Foo { int x; MemoryPool!(Foo) pool; } void main() {} It prints "Error: struct pr

Re: Forward references and more

2009-10-12 Thread bearophile
Steven Schveighoffer: > It looks strange what you are doing. A Foo can have a memory pool of a > lot of Foo's? Do you mean to make the memory pool static? Right and yes. >I think that might work.< It works if I use a global variable. But I'd like to not used global variables when possible

Re: Embedding a DSL into D source

2009-10-12 Thread Bill Baxter
On Mon, Oct 12, 2009 at 8:24 AM, Justin Johansson wrote: > I'm working on a mini domain specific language (called say, MyDSL) which > compiles to > (generates) D code and am thinking that it might be nice to be able to embed > MyDSL statements > directly in a D source file in manner similar to s

Embedding a DSL into D source

2009-10-12 Thread Justin Johansson
I'm working on a mini domain specific language (called say, MyDSL) which compiles to (generates) D code and am thinking that it might be nice to be able to embed MyDSL statements directly in a D source file in manner similar to string mixins. It's use might look something like this: void foo()

Re: Forward references and more

2009-10-12 Thread Steven Schveighoffer
On Mon, 12 Oct 2009 05:26:58 -0400, bearophile wrote: What's wrong with this code? struct MemoryPool(T) { alias T[100_000 / T.sizeof] Chunk; Chunk*[] chunks; } struct Foo { int x; MemoryPool!(Foo) pool; } void main() {} It prints "Error: struct problem.Foo no size yet for fo

Re: Forward references and more

2009-10-12 Thread bearophile
> T.sizeof must be 8 in all cases. Ignore this line, please :-)

Forward references and more

2009-10-12 Thread bearophile
What's wrong with this code? struct MemoryPool(T) { alias T[100_000 / T.sizeof] Chunk; Chunk*[] chunks; } struct Foo { int x; MemoryPool!(Foo) pool; } void main() {} It prints "Error: struct problem.Foo no size yet for forward reference". T.sizeof must be 8 in all cases. So I ha

Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]

2009-10-12 Thread Don
Yigal Chripun wrote: On 10/10/2009 10:50, Don wrote: Yigal Chripun wrote: On 10/10/2009 00:36, Christopher Wright wrote: Yigal Chripun wrote: On 09/10/2009 00:38, Christopher Wright wrote: It makes macros highly compiler-specific, or requires the compiler's AST to be part of the language. N

interface assignement implies implicit const cast

2009-10-12 Thread gzp
Assigning a const instance to an interface implies an implicit cast. Is it acceptable for the const-correctness ?? interface I { void foo(); } class C : I { void foo() { writeln("a"); } } ... C c = new C; I i = c; // ok c.foo();// ok i.foo();// ok const C cc = c; I ci = cc;