So, here's my code, as it stands currently:
import std.stdio;
static enum Type {
request,
response
};
class Parser(Type t) {
static if (t == Type.request) {
string name = "request";
} else {
string name = "response";
}
string message;
this(string message) {
this.message = message;
}
}
voi
The immutable is not necessary, use:
auto h = new Parser!(Type.request)("Hello world");
Otherwise, if you really want to declare the type instead of infering
it you can write:
Parser!(Type.request) h = new Parser!(Type.request)("Hello world");
You can also do:
Parser!(Type.request) h;
h = new typ
> Also, 'static' on the enum declaration doesn't really do anything. :)
but what if the immutable data changes?! :P
But yeah, D's type inference is reasonably good (not as good as
Haskell's, but nothing is as good as Haskell's), so doing what seems
like the best way is normally the right way arou
On 02/27/2012 08:29 AM, Tyler Jameson Little wrote:
> I didn't want to do subclassing, because my parser is a state-machine
style
> parser, so it's in a big switch. Pretty gross, but I would like it to
be as
> fast as possible. That's why I thought this model would be so cool,
because
> I coul
On Monday, February 27, 2012 10:55:12 Ali Çehreli wrote:
> On 02/27/2012 08:29 AM, Tyler Jameson Little wrote:
> > I didn't want to do subclassing, because my parser is a state-machine
>
> style
>
> > parser, so it's in a big switch. Pretty gross, but I would like it to
>
> be as
>
> > fast as
On 27.02.2012 23:18, Jonathan M Davis wrote:
On Monday, February 27, 2012 10:55:12 Ali Çehreli wrote:
On 02/27/2012 08:29 AM, Tyler Jameson Little wrote:
I didn't want to do subclassing, because my parser is a state-machine
style
parser, so it's in a big switch. Pretty gross, but I would li
On Monday, February 27, 2012 23:55:39 Dmitry Olshansky wrote:
> On 27.02.2012 23:18, Jonathan M Davis wrote:
> > On Monday, February 27, 2012 10:55:12 Ali Çehreli wrote:
> >> On 02/27/2012 08:29 AM, Tyler Jameson Little wrote:
> >>> I didn't want to do subclassing, because my parser is a state-mach
On 02/27/2012 02:06 PM, Jonathan M Davis wrote:
> I'm not saying that dmd doesn't ever optimize switch statements. I'm just
> saying that as I understand it, it doesn't always do so (its
performance with
> ranged case statements isn't great for instance). Odds are that it _does_
> optimize stra
On 28.02.2012 2:17, Ali Çehreli wrote:
On 02/27/2012 02:06 PM, Jonathan M Davis wrote:
> I'm not saying that dmd doesn't ever optimize switch statements. I'm
just
> saying that as I understand it, it doesn't always do so (its
performance with
> ranged case statements isn't great for instance)
On 02/28/2012 02:12 AM, Dmitry Olshansky wrote:
> On 28.02.2012 2:17, Ali Çehreli wrote:
>> I have played with this optimization recently. (Could be dmd 2.057.) No,
>> dmd did not optimize a straightforward switch statement over a ubyte
>> expression with about two hundred ubyte cases.
>>
> Hate
> Parser!(Type.request) h = new Parser!(Type.request)("Hello world")
Wow, I was so close! I had tried this:
Parser!Type.request h = new Parser!Type.request("Hello world");
but that didn't work. I didn't think about enclosing it in parens!
I didn't want to do subclassing, because my parser is a
On Mon, Feb 27, 2012 at 09:29:25AM -0700, Tyler Jameson Little wrote:
> > Parser!(Type.request) h = new Parser!(Type.request)("Hello world")
Even better:
auto h = new Parser!(Type.request)("Hello world");
T
--
First Rule of History: History doesn't repeat itself -- historians
merely r
On 2/27/12, Tyler Jameson Little wrote:
> That's why I thought this model would be so cool, because
> I could remove conditions from the generated code, and get rid of a lot of
> the conditionals.
I think Nick Sabalausky talks about this concept (removing
conditionals via compile-time features) i
13 matches
Mail list logo
