Re: newbie question: Can D do this?

2011-12-21 Thread mta`chrono
In PHP frameworks often use $option arrays which are some kind of key value pairs. they are merged with the default valuzes inside the function. pro: - you can pass an argument by name - you only need to pass those who needed. cons: - hash arrays it should be possible to create a similar

Re: How to mixin each element of tuple

2011-12-21 Thread Michal Minich
On 20. 12. 2011 16:20, Timon Gehr wrote: struct Item1(T){} struct Item2(T){} mixin template getItems(Items ...){ static if(Items.length) { private alias Items[0] _item; mixin _item!int; mixin getItems!(Items[1..$]); } } struct Group(Items...) { mixin getItems!Items; } void main(){ alias

Re: newbie question: Can D do this?

2011-12-21 Thread Christophe
Timon Gehr , dans le message (digitalmars.D.learn:31142), a écrit : On 12/20/2011 03:18 PM, clk wrote: Thank you for your quick replies. I'm impressed by the helpfulness and dedication of the D community! Here's another one. Is there a way to pass arguments to functions by keyword as in the

writing iterators without code duplication. inout?

2011-12-21 Thread pompei2
Hello. I want to add the option to iterate objects of my class using foreach. I need them to be iterable as view-only const and as mutable too. I would prefer to iterate using the return a delegate but if that's not possible, ranges are fine too. Also, I'd prefer a template-less solution

Re: writing iterators without code duplication. inout?

2011-12-21 Thread Trass3r
Can't really answer your original question, but 1. Why don't you use opApply? 2. Why do you use ref int even in the const version? 3. You could also use alias this to allow iteration, don't know if that's what you want in general though.

Re: writing iterators without code duplication. inout?

2011-12-21 Thread Timon Gehr
On 12/21/2011 04:54 PM, pompei2 wrote: Hello. I want to add the option to iterate objects of my class using foreach. I need them to be iterable as view-only const and as mutable too. I would prefer to iterate using the return a delegate but if that's not possible, ranges are fine too. Also, I'd

Re: writing iterators without code duplication. inout?

2011-12-21 Thread Jakob Ovrum
On Wednesday, 21 December 2011 at 16:31:01 UTC, Jakob Ovrum wrote: On Wednesday, 21 December 2011 at 16:07:55 UTC, Timon Gehr wrote: Just remove the non-const overload. const member functions work with mutable, immutable and const receivers. The const version does not allow using 'ref' when

Re: writing iterators without code duplication. inout?

2011-12-21 Thread pompei2
On Wednesday, 21 December 2011 at 16:05:24 UTC, Trass3r wrote: Can't really answer your original question, but 1. Why don't you use opApply? 2. Why do you use ref int even in the const version? 3. You could also use alias this to allow iteration, don't know if that's what you want in general

Re: writing iterators without code duplication. inout?

2011-12-21 Thread Jakob Ovrum
On Wednesday, 21 December 2011 at 16:07:55 UTC, Timon Gehr wrote: Just remove the non-const overload. const member functions work with mutable, immutable and const receivers. The const version does not allow using 'ref' when iterating.

Re: writing iterators without code duplication. inout?

2011-12-21 Thread Christophe
pompei2 , dans le message (digitalmars.D.learn:31164), a écrit : This is what I have, which works but has severe code duplication. I hoped inout would help me here, but I just can't figure it out. I also gave a try to ranges, but same thing again: I can only get it to work if I define my

test if object is instance of class at compile time

2011-12-21 Thread Elvis Maehren
This works fine at runtime, but explodes in CTFE: --- bool isInstanceOf(T, O)(O o) { return (cast(T) o) !is null; } --- CTFE doesn't like !is null (cannot compare [...] at compile time). Moreover, in CTFE a failed cast terminates the interpretation (cannot reinterpret class from [...]

Are D classes always garbage collected?

2011-12-21 Thread Froglegs
From what I understand D classes are reference types, which would imply to me that they are either always garbage collected or rather less likely, reference counting. Which is fine and all, but since structs don't support virtual functions, doesn't this pretty much force you to use classes

Re: Are D classes always garbage collected?

2011-12-21 Thread Vladimir Panteleev
On Thursday, 22 December 2011 at 02:29:10 UTC, Froglegs wrote: From what I understand D classes are reference types, which would imply to me that they are either always garbage collected or rather less likely, reference counting. They are garbage-collected. Which is fine and all, but since

Re: test if object is instance of class at compile time

2011-12-21 Thread Vladimir Panteleev
On Wednesday, 21 December 2011 at 20:15:36 UTC, Elvis Maehren wrote: Is this somehow catchable? I believe that's what __traits(compiles, ...) is for: http://dlang.org/traits.html#compiles

Re: Are D classes always garbage collected?

2011-12-21 Thread Froglegs
You can allocate classes anywhere, if you're OK with forfeiting safety guarantees. For example, see emplace in std.conv: http://dlang.org/phobos/std_conv.html#emplace Ah thanks Value type polymorphism has shown to be problematic. One notable problem is object slicing:

Re: Are D classes always garbage collected?

2011-12-21 Thread Froglegs
You can allocate classes anywhere, if you're OK with forfeiting safety guarantees. For example, see emplace in std.conv: http://dlang.org/phobos/std_conv.html#emplace Hum calling emplace ending up calling this bit of code.. T* emplace(T)(T* chunk) if (is(T == class)) { *chunk =

Re: Are D classes always garbage collected?

2011-12-21 Thread Froglegs
Which returned me a nice fat null pointer.. wth? Perhaps that should be a compile time error if you aren't supposed to use classes.. Strange... I'm not sure what the deal is with that overload. I meant the last one on the page (that takes a void[]). Hum I've tried the array version but I

Re: Are D classes always garbage collected?

2011-12-21 Thread Froglegs
T emplace(T, Args...)(void[] chunk, Args args) if (is(T == class)) { enforce(chunk.length = __traits(classInstanceSize, T), new ConvException(emplace: chunk size too small)); ... This fails whenever the size is greater or equal to the amount of memory required :( Hum nevermind

Re: Are D classes always garbage collected?

2011-12-21 Thread Vladimir Panteleev
On Thursday, 22 December 2011 at 06:43:33 UTC, Froglegs wrote: T emplace(T, Args...)(void[] chunk, Args args) if (is(T == class)) { enforce(chunk.length = __traits(classInstanceSize, T), new ConvException(emplace: chunk size too small)); ... This fails whenever the size is greater or

Re: Are D classes always garbage collected?

2011-12-21 Thread Andrew Wiley
On Wed, Dec 21, 2011 at 10:20 PM, Froglegs lug...@gmail.com wrote: Which returned me a nice fat null pointer.. wth? Perhaps that should be a compile time error if you aren't supposed to use classes.. Strange... I'm not sure what the deal is with that overload. I meant the last one on the

Re: test if object is instance of class at compile time

2011-12-21 Thread Jacob Carlborg
On 2011-12-21 21:15, Elvis Maehren wrote: This works fine at runtime, but explodes in CTFE: --- bool isInstanceOf(T, O)(O o) { return (cast(T) o) !is null; } --- CTFE doesn't like !is null (cannot compare [...] at compile time). Moreover, in CTFE a failed cast terminates the

ctfe bug?

2011-12-21 Thread Johannes Pfau
Hi, the following code is reduced from a parser generated with Ragel (http://www.complang.org/ragel/). That's also the reason why it's using pointers instead of array access, but Ragel guarantees that there won't be any out-of-bound reads. AFAIK pointers are supported in CTFE now as long as