C++Talk.NET Forum Index C++Talk.NET
C++ language newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

How does D compare to C++?
Goto page 1, 2, 3 ... 27, 28, 29  Next
 
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ Language (Moderated)
View previous topic :: View next topic  
Author Message
apm
Guest





PostPosted: Fri Aug 08, 2003 10:08 pm    Post subject: How does D compare to C++? Reply with quote



Has anyone here come across the D language
by Walter Bright (author of the Zortech compiler)?
The spec makes it seem quite good to me.
Surely some other C++ers have taken a look?
I realise that this is slightly OT. If there
is a more apropriate NG for this then I would
like to know what it is (please).

-Andrew Marlow

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Back to top
Francis Glassborow
Guest





PostPosted: Fri Aug 08, 2003 11:24 pm    Post subject: Re: How does D compare to C++? Reply with quote



In message <d1a33011.0308080013.6df518ac (AT) posting (DOT) google.com>, apm
<apm35 (AT) student (DOT) open.ac.uk> writes
Quote:
Has anyone here come across the D language
by Walter Bright (author of the Zortech compiler)?
The spec makes it seem quite good to me.
Surely some other C++ers have taken a look?
I realise that this is slightly OT. If there
is a more apropriate NG for this then I would
like to know what it is (please).

You mean like the forum provided for it by Digital Mars? :-)

I think the very last thing that the World needs is another languages
that is syntactically hard to distinguish from C++ whilst having
different semantics. It looks awfully like a language in which the
designers have thrown in everything but the kitchen sink.

It isn't C++ and cannot compile C++ code. However I wonder if it
plagiarises too much, not just the ideas but the expression of those
ideas.



--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Francis Glassborow
Guest





PostPosted: Sat Aug 09, 2003 11:26 pm    Post subject: Re: How does D compare to C++? Reply with quote



In message <jZ%Ya.69294$Vt6.23969 (AT) rwcrnsc52 (DOT) ops.asp.att.net>, Walter
<walternospamm (AT) digitalmars (DOT) nospaam.com> writes
Quote:
I think the very last thing that the World needs is another languages

There's been enormous interest in D and momentum behind it is building
rapidly. Witness to that are the 14,000+ messages in the D newsgroup.

That actually seems very small to me particularly as almost all
discussion will go through that forum.

Quote:

that is syntactically hard to distinguish from C++ whilst having
different semantics.

The stuff in D that looks like C++ behaves very closely to C++, the
different syntax is where the differences are. The idea is to not subvert
the assumptions longtime C/C++ coders make about how expressions evaluate.
For example, it follows the same operator precedence and integral promotion
rules.

Very closely is the problem. Exactly the same or seriously different is
easy to handle, subtle differences are the ones that cause traps. In
addition one of the major tar-pits for C & C++ is the integral promotion
rules.

Quote:

It looks awfully like a language in which the
designers have thrown in everything but the kitchen sink.

But the spec is less than half the size of C++ <g>. It's a lot less code to
implement, too. A major design goal was to have more power, but be a far
less complex language. It's ironic that you compare it to the kitchen sink,
given that I spend a great deal of time explaining why I'm not going to add
in [insert favorite must have feature here].

The spec of C++ wasn't that large in the days of C with classes:-) The
trouble starts when we try to tie down corner cases.

Quote:

It isn't C++ and cannot compile C++ code. However I wonder if it
plagiarises too much, not just the ideas but the expression of those
ideas.

C and C++ are brilliant and innovative languages. D rests on the shoulders
of such giants. It's simply the next evolutionary step.

So what special support does it provide for metaprogramming so that that
technique does not involve contorted use of template technology?


--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Walter
Guest





PostPosted: Sun Aug 10, 2003 10:30 am    Post subject: Re: How does D compare to C++? Reply with quote


"Francis Glassborow" <francis.glassborow (AT) ntlworld (DOT) com> wrote

Quote:
In message <jZ%Ya.69294$Vt6.23969 (AT) rwcrnsc52 (DOT) ops.asp.att.net>, Walter
There's been enormous interest in D and momentum behind it is building
rapidly. Witness to that are the 14,000+ messages in the D newsgroup.
That actually seems very small to me particularly as almost all
discussion will go through that forum.

Compared to C++, it's still small. For a new language, though, it's huge.


Quote:
The stuff in D that looks like C++ behaves very closely to C++, the
different syntax is where the differences are. The idea is to not subvert
the assumptions longtime C/C++ coders make about how expressions
evaluate.
For example, it follows the same operator precedence and integral
promotion
rules.
Very closely is the problem. Exactly the same or seriously different is
easy to handle, subtle differences are the ones that cause traps.

I agree with you. That's why D tries to avoid subtle differences.


Quote:
In addition one of the major tar-pits for C & C++ is the integral
promotion
rules.

Once you get used to them, changing them is even worse.

Quote:
It looks awfully like a language in which the
designers have thrown in everything but the kitchen sink.
But the spec is less than half the size of C++ <g>. It's a lot less code
to
implement, too. A major design goal was to have more power, but be a far
less complex language. It's ironic that you compare it to the kitchen
sink,
given that I spend a great deal of time explaining why I'm not going to
add
in [insert favorite must have feature here].
The spec of C++ wasn't that large in the days of C with classes:-) The
trouble starts when we try to tie down corner cases.

One of the things I tried to do was figure out why the spec is so large.
Some reasons for that do not add to the power of the language, they only
make it excessively complex. One, for example, is how symbols are resolved -
look at the rules for how symbol lookups are done for symbols inside
template instantiations.

Quote:
It isn't C++ and cannot compile C++ code. However I wonder if it
plagiarises too much, not just the ideas but the expression of those
ideas.
C and C++ are brilliant and innovative languages. D rests on the
shoulders
of such giants. It's simply the next evolutionary step.
So what special support does it provide for metaprogramming so that that
technique does not involve contorted use of template technology?

D has full template support, including things like partial specialization,
explicit specialization, partial ordering, argument deduction, etc. One way
it makes things easier is the ambiguous syntax of C++ is chucked, in favor
of an easy-to-parse and sematically analyze syntax. The whole type
independent and dependent lookup thing is tossed in favor of the natural and
simpler method of resolving all names in the context of the template
declaration, except for the arguments which are resolved in the context of
the instantiation. I could go on, and I will, in the form of a magazine
article I'm writing about it.

-Walter
www.digitalmars.com/d/ The D Programming Language


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
David Bradley
Guest





PostPosted: Sun Aug 10, 2003 10:31 am    Post subject: Re: How does D compare to C++? Reply with quote

I'd rather have a better development environment than yet another
language. We can't manage what we have today with C++ on large scale
projects easily. We have to fumble around with tools that reverse
engineer our code or try and feebly attempt to bridge the gap between
the flat file based world the compilers live in and a more dynamic world.

We need to move away from 60's style management of code and something
that is able to allow us to manage the large scale complex projects many
of us have to deal with on our jobs.

Until that occurs we can have the most expressive natural language
imaginable and it really won't do much to make our lives better.

David Bradley

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Back to top
Walter
Guest





PostPosted: Mon Aug 11, 2003 12:11 am    Post subject: Re: How does D compare to C++? Reply with quote


"Stephen Howe" <NOSPAMsjhowe (AT) dial (DOT) pipex.com> wrote

Quote:
It's simply the next evolutionary step.
That is debatable. I don't want to detract from your creation, it is
interesting Smile
Not everybody here would say that garbage collection is a "must have
addition" to C++; for some problems, programmers do not want automatic
garbage collection.

You're right that there are some problems where gc is the wrong solution. D
does offer a way for manual allocation/freeing for those cases, in a similar
manner that overloading new/delete works in C++. GC, however, is the right
solution for the large majority of routine programming tasks.

Quote:
I find that D,C#, Java are "different" from C++, not necessarily
"improvements".

Ok, I'll bite! In what way is C++ better than D? (And I mean from a
technical standpoint, I don't think it's quite fair to say that at the
moment C++ has more books out on it than D!) As for how D is an improvement
over C/C++:

www.digitalmars.com/d/pretod.html
www.digitalmars.com/d/ctod.html
www.digitalmars.com/d/cpptod.html

-Walter
www.digitalmars.com/d/


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
apm
Guest





PostPosted: Mon Aug 11, 2003 12:21 am    Post subject: Re: How does D compare to C++? Reply with quote

[email]stlsoft (AT) hotmail (DOT) com[/email] (Matthew Wilson) wrote in message news:<5d33192c.0308081751.5ab38e31 (AT) posting (DOT) google.com>...
Quote:
It's got lots of other interesting features as well, in addition to
(currently) some flaws. There's lots of heated, but polite, debate on
the subject at news://news.digitalmars.com/d, and I'm sure you'd be
very welcome.

I'll drop in.

Quote:
For me, it's certainly an interesting language to learn, and already
preferable to Java/.NET. I think it will be a long time before it
surplants C++ as my language of choice, however.

Matthew

What are your reasons please?
Obviously there is much more code available for C++ but I presume
there is some other reason.

-Andrew Marlow

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
llewelly
Guest





PostPosted: Mon Aug 11, 2003 9:25 am    Post subject: Re: How does D compare to C++? Reply with quote

Francis Glassborow <francis.glassborow (AT) ntlworld (DOT) com> writes:

Quote:
In message <FXgZa.107972$o%2.47886@sccrnsc02>, Walter
[email]walternospamm (AT) digitalmars (DOT) nospaam.com[/email]> writes
So what special support does it provide for metaprogramming so that that
technique does not involve contorted use of template technology?

D has full template support, including things like partial specialization,
explicit specialization, partial ordering, argument deduction, etc. One way
it makes things easier is the ambiguous syntax of C++ is chucked, in favor
of an easy-to-parse and sematically analyze syntax. The whole type
independent and dependent lookup thing is tossed in favor of the natural and
simpler method of resolving all names in the context of the template
declaration, except for the arguments which are resolved in the context of
the instantiation. I could go on, and I will, in the form of a magazine
article I'm writing about it.

I think you missed my point. A next generation statically typed language
should supply much better tools for metaprogramming. Just as C++ added
tools for object orientation and then generic programming. For me that
means that D (along with Java, C# etc.) are not the next evolutionary
step.

So maybe lisp is the next evolutionary step ? :-)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Matthew Wilson
Guest





PostPosted: Mon Aug 11, 2003 9:28 am    Post subject: Re: How does D compare to C++? Reply with quote

Quote:
For me, it's certainly an interesting language to learn, and already
preferable to Java/.NET. I think it will be a long time before it
surplants C++ as my language of choice, however.

Matthew

What are your reasons please?
Obviously there is much more code available for C++ but I presume
there is some other reason.

Ok, but please bear in mind that I'm as daft as a brush most of the
time. ;)

1. Efficiency. I like efficiency, both in terms of size and speed, and
am conceptually turned off by VMs.

2. Templates. For all that the template support is pretty raw at the
current stage of D, it does have them. Life without templates could
only be more unbearable if it was without RAII (which many of us
successfully lobbied for.)

3. RAII. How can anyone seriously work with any resources (and not
just memory) without RAII. C#'s half-hearted attempt, with the
IDisposable thingy, is about 10% better than nothing, but it's still
pretty hopeless. (fyi, it relies on the class _user_, not the class
_author_, to determine whether a particular type (or rather a
particular instance of said type) needs to experience RAII.)

4. Influence. D is still being developed, and by a one man at that.
For all that there are disadvantages with this approach - the
libraries and tools are not the best - interested parties have a
day-to-day influence on the development of the language. That's not to
say, of course, that there is a non-settling volatility, merely that
everyone gets to argue things through, and common-sense mostly wins.

Although he hates me telling this, I rate Walter highly as a compiler
vendor not just because DMC++ bundles the STLSoft libraries Wink, but
because he is open to suggestions, and acts rapidly when he agrees
with them. DMC++ has a flag -wc, which warns about the use of C-style
casts in C++ compilation units. I suggested this to Walter last year,
and it was in the next release of the compiler (8.29 if memory
serves). You may compare that response with some larger compiler
vendors and draw your own conclusions. (Before everyone flames me, I
understand that there are good reasons to have very stable - even
stability in the bugs - but you cannot deny the advantages of the
responsive vendor.)

5. Spirit. I like the D newsgroup, which is just a very friendly place
to be. Perhaps because the language is new, and there are no experts,
everyone's ego is left at the door.

6. Possibilities. I'm far from a language expert, but I think that
there is as good a chance of D getting off the ground as any other
language that is not supported by large companies. If it does, and can
live up to even a part of its potential, it will be a better (though
perhaps not as popular) as those other languages we mentioned.

7. Diversity. I just like learning new languages, especially if
they've got curly braces and semi-colons. D is *very* easy to learn
(apart from the templates), and enjoyable to use.


Anyway, that's a fair list, I grant you, but please don't take me for
a blinkered D die-hard. I have a lot of criticisms to make of it in
the ng, and I still cannot see it taking my heart from C++. (Well,
maybe if we can make the DTL as powerful and efficient as STL, but 10
times easier ...)

Cheers

Matthew

--
Matthew Wilson

STLSoft moderator and C++ monomaniac

mailto:matthew (AT) stlsoft (DOT) org
http://www.stlsoft.org
news://news.digitalmars.com/c++.stlsoft

"If i'm curt with you it's because time is a factor. I think fast, I
talk fast, and I need you guys to act fast" -- Mr Wolf

-------------------------------------------------------------------------------

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Matthew Wilson
Guest





PostPosted: Mon Aug 11, 2003 5:57 pm    Post subject: Re: How does D compare to C++? Reply with quote

Quote:
It's got lots of other interesting features as well, in addition to
(currently) some flaws. There's lots of heated, but polite, debate on
the subject at news://news.digitalmars.com/d, and I'm sure you'd be
very welcome.

Also, check out http://digitalmars.com/d/comparison.html.

I have several issues with this table.

(a) It claims C++ has modules. To me modules implies (amoung other
things) the ability to import the interface of a module by
refering to its name, with semantics independent of where the
importation occurs - something #include cannot do. So I do not
accept the claim that C++ supports modules.

Agreed

Quote:
(b) C++'s std::complex supports complex and imaginary.

Acknowledged

Quote:
(c) It claims C++ does not support DBC. protected virtual
functions implement this simply and powerfully, and are
niether 'clumsy' nor 'inconsistent'. Why the author accepts
fragile hackery for modules and turns down simple and sound
use of a safe feature for DBC is beyond me.

Agreed

Quote:
(d) The 'use existing debuggers' entry is nonsense; as far as I
can see each of the 5 languages requires tailored debuggers,
which can be found for all 5 languages; e.g. all Java and C#
implementations known to me have 'existing debuggers'.

Acknowledged

Quote:
(e) It asserts that 'most' C++ compilers do not implement 80 bit
long doubles. What does this mean? Most platforms do not
support 80 bit long doubles. Most x86 C++ compilers *do*
implement 80 bit long doubles.

This one is reasonable. AFAIK, Borland, Digital Mars and GCC do; Intel
does given a non-default compiler option; CodeWarrior, Visual C++ and
Watcom do not. Kind of 50-50, really.

Quote:
(f) It claims Java does not support direct native code gen. Yet
the gnu java implementation bundled with gcc does exactly
that. (C# AFAIK does not prevent direct native code gen
either, but I don't know of any implementation.)

Correct in an absolute sense, but practically false, since how many
people can/do use it is this fashion?

Quote:
(g) Java is labled as not supporting out function parameters,
while C is labled as supporting out function parameters. IMO,
this is inconsistent; Java references implement out function
parameters as easily as C pointers.

Are you saying that the out-param-as-single-array-member is equivalent
to C's pointers? That doesn't really stand up.

Quote:
(h) Java's anonymous interfaces are a near equivalent to function
literals.

(i) It is never explained why java.lang.string is viewed as
built-in but std::string is not, when both are part of the
respective langauges libraries, and both are delivered with
most (all?) modern implementations.

I tend to agree with you.

Quote:
(j) It claims C++ support for 'interfaces' is 'weak'. However C++
abstract classes support every feature of Java interfaces, and
more. Therefor C++ support for 'interfaces' is stronger than
at least Java's.

Agreed.

Quote:
(k) C++ has std::valarray, which is a slicable array.

Not in any way as fundamental as D's array slices, so this one is a
valid point, IMO.

Quote:
For me, it's certainly an interesting language to learn,

At first glance I agree, but the errors in the comparison table do not
do it justice.

Not my table, and I don't agree with a significant part of it.
However, it does the job that the reply addresses, which gives a
largely accurate comparison.

Quote:
and already
preferable to Java/.NET.

I note that about 2/3 of my Java methods are non-polymorphic. A
similar portion of member functions of OO C++ class are also
non-polymorphic. Yet D for some reason repeats the Java mistake of
making member functions polymorphic by default.

Agreed. There are more problematic parts also, but that gets me

Quote:
While the D definition is currently small, it does not approach the
rigor and precision achieved by the other langauge definitions I
am familiar with, and leaves many unanswered questions. For
example I was unable to determine if a D function pointer could
point to a D member function.

It's still being worked out. Isn't that kind of the point?

Quote:
I think it will be a long time before it
surplants C++ as my language of choice, however.
[snip]

That speaks for itself, no?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Hyman Rosen
Guest





PostPosted: Mon Aug 11, 2003 6:01 pm    Post subject: Re: How does D compare to C++? Reply with quote

llewelly wrote:
Quote:
C++ abstract classes support every feature of Java interfaces

....except for one. In Java, I may write

interface I { void f(); }
class C { public void f() { } }
class IC extends C implements I { }

and I am done. In C++ I must write

struct I { virtual void f() = 0; };
struct C { void f() { } };
struct IC : I, C { void f() { C::f(); } };

I must write the forwarding function in IC in C++,
but not in Java. I have several times requested this
as an extension for C++, that when you inherit one
non-abstract method and several abstract ones of the
same name and argument types, the non-abstract one
should become the final overrider of the others.
Naturally, this meets with the usual indifference
meted out to extension requests.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Walter
Guest





PostPosted: Mon Aug 11, 2003 6:01 pm    Post subject: Re: How does D compare to C++? Reply with quote


"llewelly" <llewelly.at (AT) xmission (DOT) dot.com> wrote

Quote:
"Walter" <walternospamm (AT) digitalmars (DOT) nospaam.com> writes:
[snip]
Ok, I'll bite! In what way is C++ better than D? (And I mean from a
technical standpoint, I don't think it's quite fair to say that at the
moment C++ has more books out on it than D!)
Fair or not reasons like this are why C++ has succeeded where a long
list of technicaly superior langauges have failed. Of course you
must understand this at some level; else why support linking to C
libraries? And why else use C-like syntax and semantics?

Of course, but when one is debating the technical merits, it's rather
pointless to simply dismiss anything new because it doesn't have the biggest
market share yet.


Quote:
As for how D is an improvement
over C/C++:

www.digitalmars.com/d/pretod.html
www.digitalmars.com/d/ctod.html
www.digitalmars.com/d/cpptod.html
[snip]

I note the C++ in the 3rd link contains horrible design errors - e.g
virtual overloaded relational operators. No competent C++
programmer would make these virtual for any typical usage, and
even the fact they are member operators is IMO a mistake. This of
course has nothing to do with the qualities of the D language
itself, but much to do with link's value as a migration guide or a
comparison.

LOL! The reason that it would be a design error is inherent in the example -
the assymmetry. There's also still the point of 8 overloads vs 1.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Walter
Guest





PostPosted: Mon Aug 11, 2003 6:03 pm    Post subject: Re: How does D compare to C++? Reply with quote


"Matthew Wilson" <stlsoft (AT) hotmail (DOT) com> wrote

Quote:
For me, it's certainly an interesting language to learn, and already
preferable to Java/.NET. I think it will be a long time before it
surplants C++ as my language of choice, however.
What are your reasons please?
Obviously there is much more code available for C++ but I presume
there is some other reason.
Ok, but please bear in mind that I'm as daft as a brush most of the
time. ;)

1. Efficiency. I like efficiency, both in terms of size and speed, and
am conceptually turned off by VMs.

2. Templates. For all that the template support is pretty raw at the
current stage of D, it does have them. Life without templates could
only be more unbearable if it was without RAII (which many of us
successfully lobbied for.)

3. RAII. How can anyone seriously work with any resources (and not
just memory) without RAII. C#'s half-hearted attempt, with the
IDisposable thingy, is about 10% better than nothing, but it's still
pretty hopeless. (fyi, it relies on the class _user_, not the class
_author_, to determine whether a particular type (or rather a
particular instance of said type) needs to experience RAII.)

Some people might read this and assume that you mean D has a VM. Just to
clarify, D does not have a VM, it compiles straight to machine code in the
usual manner. D also has templates and RAII, which Java does not and C# has
only partial.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Walter
Guest





PostPosted: Tue Aug 12, 2003 12:39 am    Post subject: Re: How does D compare to C++? Reply with quote


"llewelly" <llewelly.at (AT) xmission (DOT) dot.com> wrote

Quote:
I don't think I agree with much of your post, but IMO a primary limitiing
factor on the quality of C++ tools is the incredible complexity of
the language in general the syntax in particular. As far as I can
see, D does not (yet Smile approach the complexity of C++, so
advanced tools should be easier to implement for D than for C++
(as we are seeing with Java vs C++ ).

You're right. One feature of D that I've been pretty adamant about is the
total separation of the lexical, parsing, and semantic phases of
compilation. This makes it far, far easier to write code analysis tools for
D. (It's pretty easy to break things like syntax directed C++ editors by
doing things like using line spicing, trigraphs, etc. The macro processor
makes it impossible to preparse things. Things like > are pretty problematic
in trying to parse C++ without semantic info.)

-Walter
www.digitalmars.com/d/


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Walter
Guest





PostPosted: Tue Aug 12, 2003 12:42 am    Post subject: Re: How does D compare to C++? Reply with quote

Some great comments! My replies embedded:

"llewelly" <llewelly.at (AT) xmission (DOT) dot.com> wrote

Quote:
Also, check out http://digitalmars.com/d/comparison.html.
I have several issues with this table.
(a) It claims C++ has modules. To me modules implies (amoung other
things) the ability to import the interface of a module by
refering to its name, with semantics independent of where the
importation occurs - something #include cannot do. So I do not
accept the claim that C++ supports modules.

It's certainly a debatable point. Namespaces perform most of the function of
modules. If I said C++ didn't support modules, the other half of the C++
community would argue that it did because of namespaces <g>.

Quote:
(b) C++'s std::complex supports complex and imaginary.

Any language can support complex and imaginary with an appropriate library.
I do garbage collection with C++ all the time, too. The reverse is true,
too: C++ doesn't need a 'long' native type, either, it could be done with a
library like std::complex. That's why I explicitly left off library features
as part of a language. Some have suggested the table include a different
color for library features, this is probably a good idea.

Quote:
(c) It claims C++ does not support DBC. protected virtual
functions implement this simply and powerfully, and are
niether 'clumsy' nor 'inconsistent'. Why the author accepts
fragile hackery for modules and turns down simple and sound
use of a safe feature for DBC is beyond me.

There's no way to do DbC in C++ without fragile hackery. First, it hast to
be wrapped in #if's so it can be turned on/off. Second, the 'in' and 'out'
contracts for a member function have to call the base classes' 'in' and
'out' functions. This will have to be done manually in C++. Third, the 'out'
contract has to be attached to all the return statements, again needing to
be done manually. Fourth, the 'invariant' have similar issues on entry and
exit. If you can find a way to make this work in C++ in a smooth, reliable,
and visually appealing way, my hat will be off to you. Note that I have
actually extended the Digital Mars C++ compiler to support these features
([url]www.digitalmars.com/ctg/designbycontract.html)[/url].

Quote:
(d) The 'use existing debuggers' entry is nonsense; as far as I
can see each of the 5 languages requires tailored debuggers,
which can be found for all 5 languages; e.g. all Java and C#
implementations known to me have 'existing debuggers'.

Although people have written custom C++ debuggers, it isn't necessary to use
one for C++. Most any debugger will do, in fact, I regularly use multiple
debuggers from different vendors, some are very old (!), because each
happens to be good at different things. There (used to be, anyway) a
thriving business in 3rd party debuggers. Any native machine debugger will
work with C++ (or C or D). That's not so with Java or C#, which require a
debugger tailored to their particular respective VM's. It's particularly
important for D, because when porting it to a new platform, or perhaps an
embedded system, one can use the various machine debuggers for that platform
right off the bat, and don't need to build a custom debugger to bootstrap D
onto it.


Quote:
(e) It asserts that 'most' C++ compilers do not implement 80 bit
long doubles. What does this mean? Most platforms do not
support 80 bit long doubles.

It's too bad many platforms don't do 80 bit float in hardware, though the
compiler could still support it with some software. Up until the Intel 486,
compilers for the x86 could not rely on the existence of the FPU and
provided a software emulator for it. 80 bit floats are really, really nice
to have when you need them (see Prof. William Kahan's nice articles on it),
and writing emulators isn't really that hard.

Quote:
Most x86 C++ compilers *do*
implement 80 bit long doubles.

Try sizeof(long double) with your compiler and see what it gives. DMC++
gives 10. VC gives 8.

Quote:
(f) It claims Java does not support direct native code gen. Yet
the gnu java implementation bundled with gcc does exactly
that. (C# AFAIK does not prevent direct native code gen
either, but I don't know of any implementation.)

I implemented a native code generating Java compiler for Symantec years
back. It suffered from not handling dynamic class loading, however, and so
could not be considered a true Java compiler. I don't know how gnu java
addresses this issue.

Quote:
(g) Java is labled as not supporting out function parameters,
while C is labled as supporting out function parameters. IMO,
this is inconsistent; Java references implement out function
parameters as easily as C pointers.

AFAIK, the only way to emulate an out parameter in Java is to 'box' the
parameter in a class. I don't see this as being as easy as &i.

Quote:
(h) Java's anonymous interfaces are a near equivalent to function
literals.

Perhaps. It's a debatable point.

Quote:
(i) It is never explained why java.lang.string is viewed as
built-in but std::string is not, when both are part of the
respective langauges libraries, and both are delivered with
most (all?) modern implementations.

There's custom built-in support for Java strings in the Java compiler.

Quote:

(j) It claims C++ support for 'interfaces' is 'weak'. However C++
abstract classes support every feature of Java interfaces, and
more. Therefor C++ support for 'interfaces' is stronger than
at least Java's.

I think you're right. I'll revisit this.

Quote:
(k) C++ has std::valarray, which is a slicable array.

Yes, you're right. But see my comments above about libraries.

Quote:
I note that about 2/3 of my Java methods are non-polymorphic. A
similar portion of member functions of OO C++ class are also
non-polymorphic. Yet D for some reason repeats the Java mistake of
making member functions polymorphic by default.

This is the reaction of mine to having many very-hard-to-find bugs in C++
code where I would override a function in a derived class and forget to go
back and make its ancestor virtual. The D compiler, given access to the
entire program, can determine which virtual functions can be de-virtualized.
This is superior to C++'s manual and error-prone approach.

Quote:
While the D definition is currently small, it does not approach the
rigor and precision achieved by the other langauge definitions I
am familiar with, and leaves many unanswered questions. For
example I was unable to determine if a D function pointer could
point to a D member function.

Function pointers cannot. However, delegates can point to member functions.
I find delegates to be easier to understand and more useful than
pointers-to-members.

-Walter
www.digitalmars.com/d/


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Display posts from previous:   
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT
Goto page 1, 2, 3 ... 27, 28, 29  Next
Page 1 of 29

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.