D sucks, C++ is still better. And the new C++ will have parallelism included, D will be obsolete lol
Name:
Anonymous2007-02-12 16:26
>>6
A lot of what's slated for C++0x (due in 2009, hah) has been in D for years, including proper thread support. D's author also writes a C++ compiler, so he rips of good ideas soon after they appear, including the C++0x proposals.
>>1
That depends where you're coming from. If languages like Python/Ruby/Lisp/Perl are your thing, you won't get much out of D. Despite the claims, D isn't as productive as them. Also, while D's templates are a lot more powerful than C++'s, they're still ugly as hell.
However, if you're coming from C or C++, then D is a very big breath of fresh air. If performance code is your thing, D is a good choice, although it's still a bleeding-edge language with all the associated problems.
Name:
Anonymous2007-02-12 16:48
>>7
oooohhhh, so where are the atomic and parallel support in D?
Name:
Anonymous2007-02-12 16:49
don't forget the lack of programming with contract and good (and open-source!) tools for D, D sucks.
looooooo: "No, D does not have a general reference type". Even Java has references :D This D language is funnier every minute :p
Name:
Anonymous2007-02-12 17:04
The problem with D is that the main web site is a mess, I can't find a good reference without stumbling upon an animated gif advertisment for a hemoroid product or something (right now it's "XP Style Icons" maybe with spyware included). And for the name of the site, what is this Digital Mars? Yes I know, it's the company name, but it should be the name of the language itself, not this (look at python.org, ruby-lang.org, perl.com...) The first time I went to this web site I thought it was a mistake and I had to look for the good links. D will fail without really good marketing (and a good dose of CSS on the site)
Name:
Anonymous2007-02-12 17:09
Look at pure FUD in the morning: class Foo
{
int foo(Bar *c) { return c->bar(); }
};
class Bar
{
public:
int bar() { return 3; }
};
He can't write correct C++ code and he criticizes? I don't get it.
Name:
Anonymous2007-02-12 17:47
>>9
D has had contracts for a long time. Have you looked at the language?
The tools, however, is a valid complaint.
>>10
I'm referring to non-trivial template metaprogramming. It's still morbidly evil in D.
I'm genuinely curious: what's wrong with that C++ code?
Name:
Anonymous2007-02-13 18:11
>>21
The foo method makes the bar method private. If you wanted that then there is nothing wrong with using a get method. But separating that into another class is probably unnecessary in the first place.
Not to mention that examples like this demonstrate nothing. This is a blown up constant integer:
class quz {
public:
quz (int n) : m_number(n) { }
~quz() { }
int bar() { return m_number; }
private:
const int m_number;
};
If you try to win an argument for a language with mocked up code then you suck.
It just goes to show that you can prove anything with a contrived example.
Name:
Anonymous2007-02-13 18:28
>>22
How is bar() different from a get method? And what if foo() is non-trivial and does something with bar() first?
Name:
Anonymous2007-02-13 18:44
How is bar() different from a get method?
It's not and I never claimed differently.
And what if foo() is non-trivial and does something with bar() first?
Like what? And wtf are you doing with bar() that would break C++ and not be the programmer's fault? The example is contrived. The fact that it was contrived poorly so that you had to ask that doesn't prove that C++ sucks or D is even okay.
Name:
Anonymous2007-02-13 19:36
I'm afraid I still don't get it.
Let's say you have a screen and bezier object, and want to render the bezier. screen.draw(bez) doesn't seem that strange. The screen needs to extract all the x, y, and color coords somehow. Not exactly efficient, but not that strange either.
In any case, >>14 says the code is incorrect. What's stopping it from compiling?
or whatever you're saying might be more efficient. Not only is the abstraction more coherent (drawing a curve vs drawing three points and three color components), you're also only copying a pointer versus putting all that jazz on the stack.
Of course, the question of "efficiency" in such a context is very likely moot anyhow. The overhead of the function call is likely to be dwarfed by the time spent computing the curve.
Name:
Anonymous2007-02-14 11:35
>>27
Not to mention the cache misses incurred fetching parameters from some well-aged part of the memory, rather than sticking them on the stack where they'll stay nice and warm in the L1 cache. (Or, as happens for the first 4 or so parameters on x86-64, the registers.)
Name:
Anonymous2007-02-14 14:57
>>27
Yes, that's all true. I am not interested in that however; it was only an off-cuff example that demonstrates that the code in >>14 isn't unusual.
Can someone please tell me what is wrong with >>14 already?
Name:
Anonymous2007-02-14 19:37
D looks alright but I'm not touching it until there's a nice reference book I can buy and put in my bookshelf, and have at my side when typing. Fuck having to ask other people on a pseudo-usenet forum or IRC channel every time you want to get anything done.
WRITE SOME FUCKING D LITERATURE. O'REILLY OR APRESS WILL PUBLISH IT. JUST WRITE IT.
Name:
Anonymous2007-02-14 20:18
More like bez.drawto(screen).
And D is overengineered shit.
Name:
Anonymous2007-02-14 22:38
And C++ is underengineered shit.
yay im hav smerts lol
Name:
Anonymous2007-02-14 23:16
fuck garbage collection. only idiots can't malloc and free.