The reason IE8 is the only browser that can crack the clues is because they're using server-side user agent sniffing. A quick fiddle with the User Agent Switcher addon in Firefox fixes that.

But you know the most pathetic part? The site doesn't work properly with IE8, requiring the user to explicitly disable compatibility mode first.

This is somewhat alleviated in D2 via a shared core runtime. The problem is more or less that which library you use is based on the task at hand, and personal choice. There have been numerous attempts to merge them, or kill one off, and they've never succeeded because people don't want to give up the library they (legitimately, for their circumstances) see as better.

For D1, your best bet is probably to give Tango + Tangobos (which is Phobos implemented on top of Tango) a shot. For D2, there are efforts to fix the situation.

Yeah; I think LDC is the future of D. We'll just have to be patient. :)

That's because it's not finished. You can't complain that an experimental version that changes on a regular basis doesn't have library support.

As for when D2 will be finished, I deeply suspect it will be like it was with D1: Walter and the community will get fed up with it as a moving target, draw a line in the sand and *boom* finished; let's start on D3.

In fact, you can force a class to be scope allocated by putting "scope" at the front of the class declaration. This doesn't remove the requirement for 'scope' at the allocating statement; merely makes it mandatory.

Note that you cannot use this to give a class value semantics; if you could, you would open the door to the slicing problem. By making it a property of the allocating context, you avoid that.

I guess that means the differences between C++ and assembler are superficial, only in syntax. After all, anything you can compute in C++ you can compute in assembler.

Ease of use is definitely overrated.

As you already say, if you are very concerned about performance in a situation with lots of small objects you can use structs. Simply ignoring structs because you are too lazy to use them does not make D slow. With a bit of experience and a few rules of thumb it's not hard to choose.

But structs do not have the same treatment as classes.

Your point is... what, exactly? They're for completely different purposes; of course they're treated differently. Otherwise, we'd only have classes or structs, not both.

I think maybe you're talking about what is called "scope" now. It allocates the memory for the class on the stack. Yeh, it doesn't cover every possible use case of by-value classes, but it can be a nice optimization.

And a heck of lot difficult to spot. At least, in C++, it's obvious what is a pointer and what it is not.

This is a valid concern, but I can't see what this has to do with the particular quoted part of the gp's post. He's pointing out that scope is useful, and you're complaining about not being able to tell if an arbitrary identifier has value or reference semantics. Huh?

That said, just because something doesn't have a star out the front in C++ doesn't mean it's a value type; I've seen some truly terrifying abuses of operator overloading. At least in D, it's trivial to find out: stick in a pragma(msg, whatIs!(x)) and bob's your uncle (note: whatIs is not in the standard library, but I've written similar templates before without much trouble.)

Yes you use structs when you want an efficient aggregate value type. Classes and structs have different semantics in D. It's pretty easy to choose once you get the hang of it. If you are likely to want to put virtual functions on the thing, make it a class. If you want to pass lots of them around by value, make it a struct. If you can count on your fingers how many instances you will have, make it a class -- the hit from allocation won't matter. There is some gray area in-between, granted, but in practice it's usually pretty clear, and the benefit is that you do completely eliminate the slicing problem by going this route. If you really can't decide you can also write the guts as a mixin and them mix them into both a class and a struct wrapper. Or just write it primarily as a struct, and aggregate that struct inside a class. The use cases that are left after all that are pretty insignificant.

Why do all that? no thanks. C++ is much better in this regard.

Yeah, why bother designing your program before you write it? After all, maybe you want to make your 16-byte vectors into classes, or turn GUI widgets into value structs!

Honestly, I'm amazed every time I see this argument. Let's try it from the other direction: Java seems to do pretty well without "plain old data" structs; clearly, you don't need structs to write a program. If you really don't want to have to engage your brain, just pretend structs don't exist.

D's template system has gone far beyond C++'s.

Nope. It hasn't.

It's even far beyond what C++0x is going to be.

Nope, it isn't.

Alias template parameters

C++ has typedef.

Yeah, so this combined with the 'auto' comment before lead me to believe you don't actually know what you're talking about.

Tell me, how do you typedef a function in C++? Or a string value?

template mixins

Mixins are bad from a design standpoint.

I personally think you're wrong, but that's an opinion and not a valid argument. :)

static if

C++ can do it with templates.

template isLowerAlpha(char c)
{
static if( 97 <= c || c <= 122 )
const isLowerAlpha = true;
else
isLowerAlpha = false;
}

And I can get even more complex from there. Maybe you could match D in terms of ability (which I doubt,) but you can't argue that it's anywhere near as intuitive or simple.

a host of compile-time introspection facilities, the ability to run regular functions at compile-time

And introduce big complications in the code.

C++ is just one giant complication. Hell, programming is complicated. First of all, introspection is invaluable; it means you can write templated types and functions that actually know about their type parameters. CTFE (compile time function evaluation) is also brilliant because it means you can move computations into the compile step. Yes, it adds complexity to the code, but the difference is minimal. Especially when the alternative is to either write and manually choose between a shitload of marginally different templates in the first case, and just moving that complexity to runtime in the second.

type tuples

Boost provides them.

Really? So Boost can do this, then?

template dump(Ts...)(Ts values)
{
foreach( i,value ; values )
writefln("values[%d] = %s", i, value);
}

Note that the above code expands at compile-time, and works for an arbitrary number of arguments.

D metaprogramming is to C++ metaprogramming as C++ OOP is to OOP in C. It takes a technique that the previous language begrudgingly permitted and turns it into one that is actually supported by the language.

Nope. The C++ and D template type system are exactly the same.

I wasn't aware there was a special type system for regular code and templates in C++. I know there isn't in D. But saying the type systems in D and C++ are the same is just wrong: transitive const, immutability, sharing (coming soon).

In fact, if you ask Walter, all the template tricks in D are done using the C++'s Turing complete template system.

So I assume you could, with Walter's permission, post both your question and his response somewhere? Unless, of course, you're psychic.

You strike me as one of the C++ programmers who irrationally hates D because it's trying to improve upon and replace your favourite language, but you haven't spent enough time using D to actually be able to make an informed choice. That, or your knowledge of it is so out of date that it's no longer applicable.

You're more than welcome to your choice, of course. Just don't go around spreading FUD about D, please.

If I had to guess, I'd say it's because that would involve introducing another function call between D and C. Currently, a lot of the C library functions exposed in D are just extern(C) declarations, so code is calling them directly. Placing a C wrapper around those calls would slow things down (and Walter doesn't like slow.)

Incidentally, there's a tool Walter wrote called htod which actually runs a C or C++ header through the C++ compiler and then converts the internal AST into a D header. Sadly, it runs it through the DigitalMars compiler, and DMC doesn't run on mac. :P

I'm a network admin for an ISP, and we've been recommending UPSs for the frequent-reboot routers that our customers have. We've found that routers (especially Linksys) have a real problem with power fluctuations that most other systems and devices don't notice. A decent line-conditioning UPS might solve your problems, but a cheap one will suffice.

Also, could be the device is running out of memory, if your ISP is changing the properties of your connection a lot, or you might have a duplex issue causing a lot of retransmissions. . .

Just a couple of thoughts :)