Quote:Original post by Anthony Serrano

Quote:Original post by DeadXorAlive
How about a regular expressions compiler? At the end of the following article you can find the source code:
templates revisited

Quote:Original post by h3r3tic
How about you take a look at the examples I posted ?

Congratulations for completely failing to understand my point. I'm not looking for examples of D being better/simpler/more whatever than C++, and if I was, I know where to find them. I'm pointing out to Drakex that his attempt at showing D's alleged superiority failed miserably, and offered a suggestion for future attempts.

Quote:

Quote:
So are you saying you can finally(after 10-15 years) do the following in C++?
string a = "Hello " + " World";

No, I'm saying that strings are conceptually different from arrays, and therefore any language that insists that a string is just an array of char/wchar/dchar is not markedly better than C++ in that regard. ( And if you don't believe me about string!=array, then tell me this: should {1, 2, 3} + {4, 5, 6} equal {1, 2, 3, 4, 5, 6} or {5, 7, 9}? )

Quote:
In terms of syntactical aesthetics they're both ugly and about as ugly as each other.

struct A{	int operator <  (int i);	int operator <= (int i);	int operator >  (int i);	int operator >= (int i);};int operator <  (int i, A &a) { return a >  i; }int operator <= (int i, A &a) { return a >= i; }int operator >  (int i, A &a) { return a <  i; }int operator >= (int i, A &a) { return a <= i; } 

struct A{	int opCmp(int i); }

Quote:
Preprocessor macros aren't necessarily ugly

Quote:Original post by ibisbasenji
In all fairness, in order to more fully implement the C++ example, the above D example really should be:
*** Source Snippet Removed ***

Otherwise you miss the cases of (i < a) which C++'s global overload handled. But the essential point stands firm.

import std.stdio;struct A {    int n;    int opCmp(int m) { return n - m; }}void main() {    static A a = { 10 };    writefln("a > 5: %s", a > 5);    writefln("5 > a: %s", 5 > a);}

Quote:Original post by Aldacron
One of the motivating factors behind D's operator naming scheme is clear intent. The problem with the C++ style syntax is that the symbols themselves do not give any indication of what the operator does. Is the + operator addition or concatenation? Is the vector * vector operator a component-wise scalar multiplication or a dot product (I have seen code doing both)?

opAdd always means add, and never means concatanate. opMul always means multiply, and never means dot product. Of course, it's still possible for people to make the methods do something different, but in that case they are breaking a contract. When operator overlaods are named with a symbol, the implementor can define that symbol to mean anything he wants it to. Your array example below is exactly the problem D's operator overload syntax is meant to solve.

Quote:No, I'm saying that strings are conceptually different from arrays, and therefore any language that insists that a string is just an array of char/wchar/dchar is not markedly better than C++ in that regard. ( And if you don't believe me about string!=array, then tell me this: should {1, 2, 3} + {4, 5, 6} equal {1, 2, 3, 4, 5, 6} or {5, 7, 9}? )

I don't see that strings are conceptually different. They are sequences of characters. What is an array if not a sequence of items? In D, your example is not a problem, since D has a specific concatenation operator that cannot be confused with addition:

*** Source Snippet Removed ***

So if I wanted to create a sequence container or some such in D that had array semantics, allowed the addition of a value to all items in the sequence and allowed concatenation of arrays or other sequence containers, I can do so without any confusion. Here's a contrived example, an array of 3D Vectors:

*** Source Snippet Removed ***

No confusion here. In C++, one person might use operator+ to add and operator+= to concatenate, while another might use operator+= to add-assign and have a separate concatenation method. You would have no way to know which is which just by the interface.

Quote:Original post by h3r3tic
D currently supports implicit function template instantiation for non-member functions and will be getting full support soon. The comparison sheet just hadn't been upated when Walter added IFTI to D.
http://www.digitalmars.com/d/template.html

The changelog for DMD.149 states "Added limited support for implicit function template instantiation.". /Limited/ - only for non-members.

Quote:Original post by h3r3tic
Even without IFTI, D's templates are more powerful than these in C++. If you don't buy it, just try them. Looking at the specs will not tell you much if you dismiss D outright.

Quote:Original post by h3r3tic
What's so special about boost::fusion ? A library with functionality similar to boost::python is underway, I've got a lib that accomplishes what boost::bind does. So you say that boost::fusion is the next logical step ? Thanks, I'll make sure D makes it as well.

Quote:Original post by clayasaurus
Cpp requires ~20% more code and twice as many files for the same D equivilent. Most of Cpp's problem is it keeps all its cruft from C to be source compatible. Translate any large C++ project to D to see what I mean.

Quote:Original post by clayasaurus
Show me a beatiful Macro then, as all the ones I have seen are ugly.

Quote:
They are a language within a language and are very bug prone.

Quote:Original post by Nitage
This is what I've come across so far in my (brief) usage of D:

Problems with D:
Operator overloading is problematic:
- IMO the rational for NaN being part of the language instead of the library is covering for the fact that D's comparsion operator can't express the NaN relationship ( ie NaN > NaN, NaN == NaN and NaN < NaN are all false). The language also doesn't account for the fact that many object have a sensible equality relationship, but no sensible greater than or less than relationship

Quote:
- The lack of an overloadable assignment operator prevents correctly managing resources - the rational being that reference counting etc. isn't required in a language with garbage collection - this rational fails to account for the fact that programs may wish to manage resources other than memory
- The lack of an overloadable . or -> operator makes it impossible to create any kind of smart pointer or handle object. Again, the language has forgotten to account for managing non-memory resources.

Quote:
No CV-qualifiers:
- I don't use volatile in C++, so I can't really comment on that.
- I find the lack of const to be very weird - D is designed to be better than C++ at expressing constraints and to avoid long winded workarounds, yet due to the lack of const, C++ wins hands down over D in this area.

Quote:
Core Language overload:
- Too many constructs get special treatment because they are in the core language. This prevents libraries from integrating cleanly into the language, as they don't get the same perks

Quote:
Lack of 3rd party libraries:
- can't compete with C++ on the amount of libraires/utilities available