Kevin Bealer wrote:
> I'm kind of glad its not going away completely, because I've always found the links on column #0 provide a neat resource for finding things like "static if" when you don't remember the syntax (or keyword!) that makes it tick.
> > I'm wondering if a larger version like this would be useful:
> > |String support:
> | D C C++ Java
> | UTF8,16,32 types char*, null string and Special class with
> | used with D's terminated wstring are language support;
> | static + dynamic arrays with ASCII and is an immutable
> | arrays. libc's string.h UTF16 array array of UTF16
> | support functions. classes. codepoints.
> > It could be a mixture of "what exists" plus "how to do it".
It would be good to get a C++ person to check it over,
so that it doesn't say that wstring is tied to UTF-16,
for example (particularly as C++09 is very likely to
bring support for Unicode strings to C++, and wstring
is intended for fixed-width encodings which excludes
UTF-16, though on many or most platforms it is quite
reasonable to store UCS4 in std::wstrings).
-- James

== Quote from James Dennett (jdennett@acm.org)'s article
> Kevin Bealer wrote:
> > I'm kind of glad its not going away completely, because I've always found the links on column #0 provide a neat resource for finding things like "static if" when you don't remember the syntax (or keyword!) that makes it tick.
> >> > I'm wondering if a larger version like this would be useful:
> >> > |String support:
> > | D C C++ Java
> > | UTF8,16,32 types char*, null string and Special class with
> > | used with D's terminated wstring are language support;
> > | static + dynamic arrays with ASCII and is an immutable
> > | arrays. libc's string.h UTF16 array array of UTF16
> > | support functions. classes. codepoints.
> >> > It could be a mixture of "what exists" plus "how to do it".
> It would be good to get a C++ person to check it over,
> so that it doesn't say that wstring is tied to UTF-16,
> for example (particularly as C++09 is very likely to
> bring support for Unicode strings to C++, and wstring
> is intended for fixed-width encodings which excludes
> UTF-16, though on many or most platforms it is quite
> reasonable to store UCS4 in std::wstrings).
> -- James
I meant this just as an example, but the kind of complexity you are describing makes me think that an actual description of how or what is supported would be too problematic after all.
When I wrote the above 'chart line' I was thinking that most of the keyword or key-phrase items like wstring and "Java String" would be links to more useful resources. Maybe it would be better to *just* have a link.
|String support:
| D C C++ Java
| <char[]> <link to C howto> <cppreference link> <class String>
Each could link to an online resource that does a more thorough job of describing the technique -- this would allow Sun to make the case for Java's design. So if D's 'String' link points at a "why use char[]" page, it wouldn't seem biased, since all the links go to advocates, owners, or resources specific to the respective languages.
Kevin

Kevin Bealer wrote:
> Each could link to an online resource that does a more thorough job of
> describing the technique -- this would allow Sun to make the case for
> Java's design. So if D's 'String' link points at a "why use char[]"
> page, it wouldn't seem biased, since all the links go to advocates,
> owners, or resources specific to the respective languages.
I've been accused multiple times of "sabotaging" C++ by referencing what I believed was an authoritative source for a C++ technique, and being told that technique was ignorant, wrong, obsolete, whatever <g>.
What is the "right" way to do things in C++ depends an awful lot on which guru you talk to.

Kevin Bealer wrote:
> I'm kind of glad its not going away completely, because I've always found the
> links on column #0 provide a neat resource for finding things like "static if"
> when you don't remember the syntax (or keyword!) that makes it tick.
> > I'm wondering if a larger version like this would be useful:
> > |String support:
> | D C C++ Java
> | UTF8,16,32 types char*, null string and Special class with
> | used with D's terminated wstring are language support;
> | static + dynamic arrays with ASCII and is an immutable
> | arrays. libc's string.h UTF16 array array of UTF16
> | support functions. classes. codepoints.
> > It could be a mixture of "what exists" plus "how to do it".
> > But maybe this is beyond the scope of this site for now -- it would take a lot of
> typing and maybe some research to fill in such a table and that might be better
> done via wiki.
> > Kevin
Another possibility would be to add a single-line comment beside some of the entries, to directly avoid misconceptions.
eg:
Garbage collection --- Optional, Manual memory management also available.
Object oriented --- Optional, free functions also available
Template value parameters --- integral, floating point, or string.
I'm also baffled as to why 'alias' is in the Arrays section.

Jari-Matti Mäkelä wrote:
> There's still this text on the front page
> > "For a quick feature comparison, see [link]this[/link] comparison of D
> with C, C++, C# and Java."
also, if you go to
http://digitalmars.com/d/pretod.html
the left hand side incorrectly links to "D Features"
I think I said this before though...

Georg Wrede Wrote:
> Quoting from http://www.gamedev.net/community/forums/topic.asp?topic_id=431909> > > I'm sorry, but some of your "comparisons" to C# are just WRONG. Period, flat out, wrong. No dynamic arrays? Try System.Collections.Generic.List<T>. No associative arrays? Try System.Collections.Generic.Dictionary<T>. No aliases? Try using <class> = Alias;. There are many more on that page, so much so, I am half tempted to write a page debunking over half your comparisons.
> > > > Your comparison sheet is EXTREMELY misleading, as you completely ignore the .NET framework, which extends C# far beyond anything D can currently do. Ignoring the presence of many of these facilities in the .NET framework is a really shady tactic to make D seem like it has several important features that C# supposedly lacks. Several other features you claim are "important" are really not (like multiple inheritance, which is dangerous to begin with).
> > > > D is a neat language, but you need to be more honest in your comparisons.
> > Not directly commenting on this quote (since I'm not that familiar with C#), I think we should check if the comparison really is up to date.
> > Other languages may have got new versions out, and some of the table entries are, ehh, not that obvious to the casual reader.
> > While some of the more surprising answers (the yes/no stuff) are explained in footnotes or on other pages, we must understand that all this slashdotting etc. brings readers who don't bother reading "the fine print". They may then dismiss the table (and thus D itself) as biased, hyped, and regular marketing lies altogether.
> > I don't think we can afford it.
>
It's 2009Q2 now.
The comparison is still not a comparison at all by just showing the D features.
If you want to attract more programmers to D you need to show HIGH QUALITY code (snippets) in, say,
D, C++, Java ... you choose.
You need to show the value.

Vincenzo Romano wrote:
...
> It's 2009Q2 now.
> The comparison is still not a comparison at all by just showing the D
features.
> If you want to attract more programmers to D you need to show HIGH QUALITY
code (snippets) in, say,
> D, C++, Java ... you choose.
> You need to show the value.
Did you not find them? Throughout the articles on digitalmars.com/d, in the spec and phobos library documentation you find lot's of examples and illustrations.