On 07/18/2012 01:37 AM, Jonathan M Davis wrote:
On Tuesday, July 17, 2012 23:11:43 Timon Gehr wrote:
This issue is unrelated to CRTP. (also, you probably want to negate
that static if condition, otherwise the code is valid and poses no
challenge to a compiler.)
It's not that it makes the compi
On 07/18/2012 11:08 PM, monarch_dodra wrote:
On Tuesday, 17 July 2012 at 23:38:04 UTC, Jonathan M Davis wrote:
It's not that it makes the compiler's life hard. It's the fact that
conditional compilation relies on state that doesn't exist yet. It's
messed up
to be checking whether an object defin
On Tuesday, 17 July 2012 at 23:38:04 UTC, Jonathan M Davis wrote:
It's not that it makes the compiler's life hard. It's the fact
that
conditional compilation relies on state that doesn't exist yet.
It's messed up
to be checking whether an object defines something when you're
in the middle of
d
> That being said, I have never used CRTP in D so far, since template
mixins seem to be the better choice in almost all situations.
FWIW, CRTP is the main reason I used classes in Pegged, to allow grammar
rules to refer to themselves. My earlier attempts with structs did not work.
So, given a gra
On Tuesday, July 17, 2012 23:11:43 Timon Gehr wrote:
> This issue is unrelated to CRTP. (also, you probably want to negate
> that static if condition, otherwise the code is valid and poses no
> challenge to a compiler.)
It's not that it makes the compiler's life hard. It's the fact that
condition
On Tuesday, 17 July 2012 at 20:50:41 UTC, Jonathan M Davis wrote:
The problem is that if you have static ifs and the like in the
base class
which depends on compile time reflection of the derived class,
you effectively
have a recursive template definition. e.g.
class MyBase(T)
{
static if(is(
On 07/17/2012 10:50 PM, Jonathan M Davis wrote:
On Tuesday, July 17, 2012 22:36:10 Timon Gehr wrote:
On 07/17/2012 07:23 PM, Jonathan M Davis wrote:
On Tuesday, July 17, 2012 14:48:32 David Nadlinger wrote:
On Tuesday, 17 July 2012 at 05:24:26 UTC, Jonathan M Davis wrote:
This code strikes me
On Tuesday, July 17, 2012 22:36:10 Timon Gehr wrote:
> On 07/17/2012 07:23 PM, Jonathan M Davis wrote:
> > On Tuesday, July 17, 2012 14:48:32 David Nadlinger wrote:
> >> On Tuesday, 17 July 2012 at 05:24:26 UTC, Jonathan M Davis wrote:
> >>> This code strikes me as being a bug:
> >>>
> >>> ---
On 07/17/2012 07:23 PM, Jonathan M Davis wrote:
On Tuesday, July 17, 2012 14:48:32 David Nadlinger wrote:
On Tuesday, 17 July 2012 at 05:24:26 UTC, Jonathan M Davis wrote:
This code strikes me as being a bug:
class MyBase(T)
{}
class MySubA : MyBase!MySubA
{}
class MySubB : MyBase!M
On 7/17/2012 12:23 PM, Jonathan M Davis wrote:
On Tuesday, July 17, 2012 14:48:32 David Nadlinger wrote:
On Tuesday, 17 July 2012 at 05:24:26 UTC, Jonathan M Davis wrote:
This code strikes me as being a bug:
class MyBase(T)
{}
class MySubA : MyBase!MySubA
{}
class MySubB : MyBase!My
On Tuesday, July 17, 2012 14:48:32 David Nadlinger wrote:
> On Tuesday, 17 July 2012 at 05:24:26 UTC, Jonathan M Davis wrote:
> > This code strikes me as being a bug:
> >
> >
> > class MyBase(T)
> > {}
> >
> > class MySubA : MyBase!MySubA
> > {}
> >
> > class MySubB : MyBase!MySubB
> >
On Tuesday, 17 July 2012 at 05:24:26 UTC, Jonathan M Davis wrote:
This code strikes me as being a bug:
class MyBase(T)
{}
class MySubA : MyBase!MySubA
{}
class MySubB : MyBase!MySubB
{}
void main()
{}
This pattern is actually quite common in C++ code, and referred
to as C
There's a thorough explanation of how "incomplete types" work in
C++:
http://www.drdobbs.com/the-standard-librarian-containers-of-inc/184403814
And there's some more C++ related stuff:
http://www.boost.org/doc/libs/1_50_0/doc/html/container/containers_of_incomplete_types.html
I wouldn't know ab
It is indeed supposed to work, and was actually touted as a
common and lauded example way back in the day. However, with the
advent of this-params for templates it seems less useful now
(once they've been through the ringer a little more at least).
I did use this-params to great effect in Zea
On Tuesday, July 17, 2012 07:37:38 Alex Rønne Petersen wrote:
> (Not sure if MySubB was meant to demonstrate anything; it's effectively
> semantically equal to MySubA.)
It's a simplification of an example in this question:
http://stackoverflow.com/questions/11516066/d-inheriting-static-variables-
On 17-07-2012 07:24, Jonathan M Davis wrote:
This code strikes me as being a bug:
class MyBase(T)
{}
class MySubA : MyBase!MySubA
{}
class MySubB : MyBase!MySubB
{}
void main()
{}
but it compiles just fine. However, given the fact that MySubA isn't even
properly defined unt
http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern
On 7/16/2012 10:24 PM, Jonathan M Davis wrote:
> This code strikes me as being a bug:
>
>
> class MyBase(T)
> {}
>
> class MySubA : MyBase!MySubA
> {}
>
> class MySubB : MyBase!MySubB
> {}
>
> void main()
> {}
> ---
This code strikes me as being a bug:
class MyBase(T)
{}
class MySubA : MyBase!MySubA
{}
class MySubB : MyBase!MySubB
{}
void main()
{}
but it compiles just fine. However, given the fact that MySubA isn't even
properly defined until its base class has been defined, I don't se
18 matches
Mail list logo
