How does D compare to C++?
apm
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! ]
Francis Glassborow
<ap...@student.open.ac.uk> writes
>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
Matthew Wilson
aspects are that it takes a reference-based approach to objects (a la
Java, .NET), but does not have a VM; everything is compiled to machine
code.
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.
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
ap...@student.open.ac.uk (apm) wrote in message news:<d1a33011.03080...@posting.google.com>...
> 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).
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Walter
"Francis Glassborow" <francis.g...@ntlworld.com> wrote in message
news:1WmYxPCOeCN$Ew...@robinton.demon.co.uk...
> In message <d1a33011.03080...@posting.google.com>, apm
> <ap...@student.open.ac.uk> writes
> >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? :-)
www.digitalmars.com/NewsGroup.html
> 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 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.
> 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].
> 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.
To check out D:
The spec: www.digitalmars.com/d/
Quickie comparison chart: www.digitalmars.com/d/comparison.html
Comparison with C: www.digitalmars.com/d/ctod.html
Comparison with C++: www.digitalmars.com/d/cpptod.html
D newsgroups (14,000+ messages!): news.digitalmars.com
-Walter
www.digitalmars.com
Francis Glassborow
<walter...@digitalmars.nospaam.com> writes
> > 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.
>
> > 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.
>
> > 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.
>
> > 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 ]
Walter
> >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.
> >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.
> 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.
> > > 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.
> > > 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
David Bradley
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
Stephen Howe
That is debatable. I don't want to detract from your creation, it is
interesting :-)
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.
I find that D,C#, Java are "different" from C++, not necessarily
"improvements".
Stephen Howe
Francis Glassborow
<walter...@digitalmars.nospaam.com> 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.
--
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 ]
Walter
"Stephen Howe" <NOSPAM...@dial.pipex.com> wrote in message
news:3f356d8a$0$18494$cc9e...@news.dial.pipex.com...
> >It's simply the next evolutionary step.
> That is debatable. I don't want to detract from your creation, it is
> interesting :-)
> 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.
> 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/
apm
> 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.
> 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
Walter
> In message <FXgZa.107972$o%2.47886@sccrnsc02>, Walter
> <walter...@digitalmars.nospaam.com> 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.
That's why I called D evolutionary, rather than revolutionary, although D
does offer some revolutionary better tools such as Design By Contract and
Unit Testing integrated into the language. The evolutionary aspects of D are
the much smoother syntax and expressive power, while eliminating or
mitigating the causes of common sources of nuisance bugs.
DbC and unit testing offer huge productivity improvements. C++, C# and Java
all completely missed the boat on that.
-Walter
www.digitalmars.com/d/
llewelly
> In message <FXgZa.107972$o%2.47886@sccrnsc02>, Walter
> <walter...@digitalmars.nospaam.com> 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 ? :-)
Matthew Wilson
> > 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 ;), 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:mat...@stlsoft.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
-------------------------------------------------------------------------------
llewelly
> It's not a simple question to answer. I would say the most notable
> aspects are that it takes a reference-based approach to objects (a la
> Java, .NET), but does not have a VM; everything is compiled to machine
> code.
>
> 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.
(b) C++'s std::complex supports complex and imaginary.
(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.
(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'.
(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.
(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.)
(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.
(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.
(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.
(k) C++ has std::valarray, which is a slicable array.
> 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.
> 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.
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.
> I think it will be a long time before it
> surplants C++ as my language of choice, however.
[snip]
llewelly
[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?
> 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.
llewelly
> 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.
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 :-) 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++ ).
Matthew Wilson
> > (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
> (b) C++'s std::complex supports complex and imaginary.
Acknowledged
> (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
> (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
> (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.
> (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?
> (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.
> (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.
> (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.
> (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.
> > 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.
> > 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
> 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?
> > I think it will be a long time before it
> > surplants C++ as my language of choice, however.
> [snip]
That speaks for itself, no?
Hyman Rosen
> 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.
Walter
"llewelly" <llewe...@xmission.dot.com> wrote in message
news:868yq0r...@Zorthluthik.local.bar...
> "Walter" <walter...@digitalmars.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.
> > 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.
Walter
"Matthew Wilson" <stl...@hotmail.com> wrote in message
news:5d33192c.03081...@posting.google.com...
> > > 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.
> > 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.
Walter
> 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 :-) 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/
Walter
"llewelly" <llewe...@xmission.dot.com> wrote in message
news:86bruws...@Zorthluthik.local.bar...
> > 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>.
> (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.
> (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
(www.digitalmars.com/ctg/designbycontract.html).
> (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.
> (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.
> 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.
> (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.
> (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.
> (h) Java's anonymous interfaces are a near equivalent to function
> literals.
Perhaps. It's a debatable point.
> (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.
>
> (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.
> (k) C++ has std::valarray, which is a slicable array.
Yes, you're right. But see my comments above about libraries.
> 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.
> 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/
David Bradley
> 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.
It also really depends on the algorithm that the GC is using. Simple
mark and sweep logic isn't sufficient for a system that is going to
handle a million or more objects. That's one of my serious gripes with
Java, you are locked into whatever algorithm the VM implemented liked
that day and provide no way to plugin a new algorithm that might be
better suited for your application domain. And often having objects with
well defined lifetimes is far more convenient than leaving it up to the
GC logic to decide. On top of that, some GC systems use a background
threading technique to collect, so that adds threading issues where none
would have previously been.
David Bradley
llewelly
> llewelly wrote:
>> C++ abstract classes support every feature of Java interfaces
>
> ...except for one. In Java, I may write
I wasn't aware of this example.
>
> 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.
[snip]
There may be a definition of I::f() in another translation unit. So I
think C++'s lack of modules combined with clumsy support for
seperate compilation and the not-always followed rule that C++
object files should be linkable by 'traditional' C linkers stand
in the way (or at least confuse the issue; one could define the
extension to prefer a an ordinary virtual function over a pure
virtual function, ignoring the possiblity of I::f(){}, wether it
is in another TU or not) .
llewelly
[snip]
> 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 turns out D does not have pointers to member functions; delagates
fill that role.
llewelly
> Some great comments! My replies embedded:
>
> "llewelly" <llewe...@xmission.dot.com> wrote in message
> news:86bruws...@Zorthluthik.local.bar...
>> > 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>.
I used to have that opinion - until I tried using namespaces in real
code. They have their uses, but they are not modules, even when
backed up by seperate compilation, #include, etc.
>
>> (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.
I think you should go by the language standard. If a library is part
of the standard, it's in.
>
>> (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.
I didn't find it. It's an old idiom:
class Base
{
public:
void foo(){ pre_foo(); impl_foo(); post_foo();}
protected:
virtual void impl_foo()= 0;
private:
void pre_foo() { /* assert(s) on precondition check(s) */ }
void post_foo() { /* assert(s) on postcondition check(s) */ }
};
class Derived
{
private:
virtual void impl_foo() {/*Derived need only implement this.*/}
};
(1) is (partially :-) addressed by the fact that assert is part of
standard C++; so the user of this idiom needn't use #if.
(2) is addressed by the fact that users cannot call impl_foo()
directly; that's why it is protected. (If derived classes do not
need to call it, it can be private.) Since users of Base only call
Base::foo(), pre_foo() and post_foo() always get called, requiring
no manual work for those deriving from Base.
(3) is addressed as (2) above.
(4) is also addressed as (2) above.
This is what inheriting code is for.
>
>> (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,
[snip]
For someone well-versed in various implementation specific
aspects of C++. For most people, a debugger not tailored to C++ is
useless for C++.
Maybe for D it possible, but I doubt most programmers could take
advantage of 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.
Yes, thank you for mentioning Kahan's work - I had read some of years
ago, but I'm enjoying re-reading it.
>> 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.
I had recalled using a version of MSVC that supported 80 bit long
doubles. I had forgotten how long ago that was (1995 or
so). Current versions no longer support it. I was unware of
this. (one of the aforementioned Kahan articles )
>
>> (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.
I don't know how they implement it. But it does work.
>
>> (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.
For udt types it is easier than &i because that is what you get
whether you like it or not. For built-ins there is are equivalent
library-provided udts like Double.
>
>> (h) Java's anonymous interfaces are a near equivalent to function
>> literals.
>
> Perhaps. It's a debatable point.
>
>> (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.
But most of the code is in fact in the library, and not in the
compiler, in a typical implementation. (Note neither the Java nor
C++ specs require that.)
In any case I think we disagree on where the line around the langauge
should be drawn. I believe standard libraries should be included.
>> (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.
>
>> (k) C++ has std::valarray, which is a slicable array.
>
> Yes, you're right. But see my comments above about libraries.
>
>> 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.
But D has override. Maybe I misunderstand, but it seems to me override
is a superior way to solve your problem. (Which I must say I have
only encountered in other people's code, not mine, and not often -
in particular, I have seldom found myself going back to
make a function 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.
I think we have different views of what virtual is for. For me,
virtual is a decision made at design time, exactly when the design
calls for polymorphism; if I make a function non-virtual it is
because I do not want it overriden.
>
>> 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.
Yes I see this now. I think you should go look at an implementation of
C++'s mem_fun. I believe that if you do not make delegates capable
of refering to non-member functions, (or function pointers capable
of pointing to member functions.) you will someday find yourself
with an equivalent of C++'s mem_fun. If you have understood the
implementation of mem_fun you know you do not want that.
I will believe that delegates are easier to understand, read, write,
and use than C++ pointers to members. However as far as I can see
they do not correct the worse C++ mistake - making member and
non-member functions incompatible. It makes templates and
callback interfaces less flexible.
Walter
"David Bradley" <BradleyJun...@cinci.rr.com> wrote in message
news:fnSZa.53571$hc.2...@fe3.columbus.rr.com...
> Walter wrote:
> > 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.
> It also really depends on the algorithm that the GC is using. Simple
> mark and sweep logic isn't sufficient for a system that is going to
> handle a million or more objects. That's one of my serious gripes with
> Java, you are locked into whatever algorithm the VM implemented liked
> that day and provide no way to plugin a new algorithm that might be
> better suited for your application domain. And often having objects with
> well defined lifetimes is far more convenient than leaving it up to the
> GC logic to decide. On top of that, some GC systems use a background
> threading technique to collect, so that adds threading issues where none
> would have previously been.
The current D compiler uses mark&sweep, but it has a well defined interface
and can be replaced with a better one, such as a copying generational
collector. Also, class-specific custom allocators can be built in a manner
similar to overloading new/delete for C++ classes. I chose m&s for the
initial implementation because it's simple and reliable. There's no
monolithic VM for D so nothing to lock you in. Full source comes with the
RTL.
-Walter
www.digitalmars.com/d/ The D Programming Language
James Dennett
> Some great comments! My replies embedded:
>
> "llewelly" <llewe...@xmission.dot.com> wrote in message
> news:86bruws...@Zorthluthik.local.bar...
[snip]
>>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.
Specifying the contracts of virtual functions is much more
work than specifying the contracts of non-virtual functions:
apart from documenting what the caller of the function can
rely on, it is necessary to document any other constraints
that the base class imposes on implementors of the virtual
function, such as which other member functions can be called
from within overriding functions.
The safer option is not to introduce virtual functions without
careful consideration.
This is not a question of automating something: it's a question
of having a language that encourages the use of good designs.
Making functions virtual by default is a mistake in Java,
repeated elsewhere. C#, IIRC, at least makes a function that
plans to override a base class function declare that, and will
flag an error if there is no suitable virtual base class function
to override. It's been a while since I looked at D; my impression
is that it might be better than Java, but targets a similar
mindset, and I found that its rationales for why things in D
were improvements over C++ often neglected the arguments which
have lead C++ to deliberate choose the opposite design. Maybe
the current FAQs are better; when I have time I'll go back and
look, because I really would like something that really could
be a successor to C++, but I've not yet seen such a thing.
-- James.
Edward Diener
> > In message <d1a33011.03080...@posting.google.com>, apm
> > <ap...@student.open.ac.uk> writes
> > >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? :-)
>
> www.digitalmars.com/NewsGroup.html
You lost my interest as soon as you begin your explanation of D by
explaining that C++ doesn't have resizable strings and arrays. Of course it
does as part of its library and I know you know that. Using that sort of
argument will turn off many intelligent C++ programmers who might be
interested in your ideas, since it insults the intelligence and
understanding of good programmers. Saying that it doesn't have such-and-such
built in to the language as opposed to the standard library is a poor
argument, since it makes very little difference to programmers what is part
of the language and what is part of the standard library as long as the use
is transparent. And in C++ it of course is. If you want to appeal to C++
programmers, you need to accept that their intelligence is greater than what
you think it is when you make such a remark in the beginning of your intro
to D. Don't talk down to your audience, unless you want an audience of
unthinking adherents to your ideas.
Gina Yarmel
> Ok, I'll bite! In what way is C++ better than D?
Multiple inheritance.
Patrick Frankenberger
"llewelly" wrote:
> "Walter" <walter...@digitalmars.nospaam.com> writes:
>
> > "llewelly" <llewe...@xmission.dot.com> wrote in message
> > news:86bruws...@Zorthluthik.local.bar...
You can't weaken preconditions or strengthen postconditions in derived
classes with this scheme. Expanding this scheme to make changes in
conditions possible results in a lot of functions:
void pre_foo() { /*compute a boolean...*/ precondition_satisfied ||
weaker_precondition());
virtual bool weaker_precondition() { return false };
So there are 6 functions in the base class, 3 virtual, 3 non-virtual and for
every condition weakened or strengthened in a derived class 2 more functions
are neccesary. This is clumsy.
Patrick
Walter
"James Dennett" <jden...@acm.org> wrote in message
news:lR_Za.11905$Ye.6666@fed1read02...
> > 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.
> Specifying the contracts of virtual functions is much more
> work than specifying the contracts of non-virtual functions:
> apart from documenting what the caller of the function can
> rely on, it is necessary to document any other constraints
> that the base class imposes on implementors of the virtual
> function, such as which other member functions can be called
> from within overriding functions.
In D, the "documenting" of the allowable inputs and possible outputs of a
virtual function is properly handled using the 'in' and 'out' contracts to
it. Those automatically are enforced even if the virtual function is
overridden by a function with different or no contracts. The 'in' contracts
are all OR'd together in the virtual inheritance tree, and the 'out'
contracts are all AND'd. The idea is to not break users of a virtual
function when it is overridden.
> The safer option is not to introduce virtual functions without
> careful consideration.
I see your point, but the only nasty problem I've had with virtuals is the
one I mentioned above. That problem can't be dealt with by contracts,
either.
> This is not a question of automating something: it's a question
> of having a language that encourages the use of good designs.
> Making functions virtual by default is a mistake in Java,
> repeated elsewhere. C#, IIRC, at least makes a function that
> plans to override a base class function declare that, and will
> flag an error if there is no suitable virtual base class function
> to override. It's been a while since I looked at D; my impression
> is that it might be better than Java, but targets a similar
> mindset, and I found that its rationales for why things in D
> were improvements over C++ often neglected the arguments which
> have lead C++ to deliberate choose the opposite design.
Didn't C++ originally choose the non-virtual-by-default design because of
the philosophy of not adding any overhead unless specifically requested?
> Maybe
> the current FAQs are better; when I have time I'll go back and
> look, because I really would like something that really could
> be a successor to C++, but I've not yet seen such a thing.
I appreciate your comments and would like to hear more. There's a whole lot
more to D than the virtual/not issue.
apm
> > 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.
I believe that eiffel takes a similar approach.
> > This is superior to C++'s manual and error-prone approach.
I tend to agree.
> This is not a question of automating something: it's a question
> of having a language that encourages the use of good designs.
I thought that the reason for the use of 'virtual' was because
of Stroustrup's pay-as-you philosophy, i.e you don't pay
for cost of a virtual dispatch by default but there is a way
to say that you do want virtual dispatch.
-Andrew Marlow
Walter
> I think you should go by the language standard. If a library is part
> of the standard, it's in.
A lot of people have emailed me echoing your rationale.
There's no way to turn on/off the calls to pre_foo and post_foo without the
preprocessor.
> (2) is addressed by the fact that users cannot call impl_foo()
> directly; that's why it is protected. (If derived classes do not
> need to call it, it can be private.) Since users of Base only call
> Base::foo(), pre_foo() and post_foo() always get called, requiring
> no manual work for those deriving from Base.
Yet that incorrectly implements DbC. The pre-conditions need to be OR'd
together, and the post-conditions need to be AND'd.
> (3) is addressed as (2) above.
Yes, it could be added, but the code is clumsy and tedious. Certainly your
example looks cleaner by omitting such <g>.
> (4) is also addressed as (2) above.
Invariant is easier to handle with inheritance. But there are still the
issues of turning it on/off, and inserting it into constructors and
destructors.
> This is what inheriting code is for.
Yes, you can make it work by writing a lot of tedious code like you did
above. But contrast your example with:
class Base
{
public:
void foo()
in { preconditions }
out { postconditions }
body { ... }
}
class Derived : Foo
{
private:
void foo() {/*Derived need only implement this.*/}
}
Isn't that a lot more straightforward? In can be turned on and off with a
simple compiler switch. No funky naming convention. More contracts can be
added to the Derived.foo and the right thing happens. Return values are as
easy as:
int foo()
in { preconditions }
out(result) { postconditions; check result }
body { ... }
Consider that in C one can add virtual functions to structs (I've seen it
done!) and yes, it works, but it really wouldn't be called supporting
virtual functions.
> >> (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,
> For someone well-versed in various implementation specific
> aspects of C++. For most people, a debugger not tailored to C++ is
> useless for C++.
Useless is a pretty strong word. A lot of programmers used C debuggers to
debug C++ before specific C++ debuggers appeared, and they still do on a lot
of platforms where there simply isn't a C++ debugger, or to use specialized
debuggers. C++ would simply never have got off the ground if a C++ specific
debugger was required for it. Remember cfront? <g>
> > 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.
> Yes, thank you for mentioning Kahan's work - I had read some of years
> ago, but I'm enjoying re-reading it.
I admire Prof. Kahan a lot. I think his contributions to computer math have
been very underappreciated.
> >> 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.
> I had recalled using a version of MSVC that supported 80 bit long
> doubles. I had forgotten how long ago that was (1995 or
> so). Current versions no longer support it. I was unware of
> this. (one of the aforementioned Kahan articles )
Correct, Microsoft dropped support for it.
> >> (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.
> I don't know how they implement it. But it does work.
Two ways to do it: either cart along with your executable a bytecode
compiler or a bytecode interpreter. It's still married to the bytecode one
way or another <g>.
> >> (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.
> For udt types it is easier than &i because that is what you get
> whether you like it or not. For built-ins there is are equivalent
> library-provided udts like Double.
I'm going to disagree that these can be called out parameters. It's a
workaround for a lack of out parameters.
> >> (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.
> But most of the code is in fact in the library, and not in the
> compiler, in a typical implementation. (Note neither the Java nor
> C++ specs require that.)
A "string literal" is recognized by the Java compiler as a Java.lang.string.
That makes it built-in. Similarly for complex numbers, in D one can write:
creal r = 5.0 + 6i;
The 'i' postfix makes it imaginary. There's no syntax for that in C++ since
the compiler knows nothing about complex and imaginary types.
> In any case I think we disagree on where the line around the langauge
> should be drawn. I believe standard libraries should be included.
Fair enough. After all, it's only a comparison chart, and it's meant to
stimulate discussion about the various features and misfeatures of the
languages. It's been pretty successful at that <g>.
> > 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.
> Yes I see this now. I think you should go look at an implementation of
> C++'s mem_fun. I believe that if you do not make delegates capable
> of refering to non-member functions, (or function pointers capable
> of pointing to member functions.) you will someday find yourself
> with an equivalent of C++'s mem_fun. If you have understood the
> implementation of mem_fun you know you do not want that.
> I will believe that delegates are easier to understand, read, write,
> and use than C++ pointers to members. However as far as I can see
> they do not correct the worse C++ mistake - making member and
> non-member functions incompatible. It makes templates and
> callback interfaces less flexible.
You're right. I have plans to merge function pointers and delegates into one
construct. That should eliminate those problems.
-Walter
www.digitalmars.com/d/ The D Programming Language
Walter
"Edward Diener" <eldi...@earthlink.net> wrote in message
news:ww3_a.9531$BC2....@newsread2.news.atl.earthlink.net...
> You lost my interest as soon as you begin your explanation of D by
> explaining that C++ doesn't have resizable strings and arrays. Of course
it
> does as part of its library and I know you know that.
The D spec does point this out:
>From www.digitalmars.com/d/overview.html:
"It's frustrating that such a powerful language does not do basic things
like resizing arrays and concatenating strings. Yes, C++ does provide the
meta programming ability to implement resizable arrays and strings like the
vector type in the STL. Such fundamental features, however, ought to be part
of the language."
>From www.digitalmars.com/d/comparison.html:
"Part of the standard library for C++ implements resizeable arrays and
strings, however, they are not part of the actual language. A conforming
freestanding implementation of C++ (C++98 17.4.1.3) does not need to provide
these libraries."
C++ does a brilliant job of making it possible and practical to create
libraries with new types and graft them almost seamlessly into the language
itself. D goes a bit further and integrates the most common and useful
constructs into the syntax and semantics, where I believe they belong.
-Walter
www.digitalmars.com/d/ The D Programming Language
Matthew Wilson
I'm struggling to see how this is an insult to one's intelligence. Are
you telling me that C++ and its libraries represent an absolute
maximum in the space of language design and implementation, and
therefore any criticism of them is invalid?
If you're someone that cannot handle someone else making a bold and -
precisely, though not (as you point out) practically - correct
statement, then I strongly suggest you do not pursue any interest in
D. Though people are by and large polite on the D ng, there are bold
opinions exchanged back and forth, and people with thin skins, or
fragile allegiances to their current language of choice, would
probably be outside their comfort zone. (Having said that, of course,
I cannot imagine any ng where people's opinions were not challenged,
oftentimes in a vigourous way.)
To deal with the issue, you make a reasonable point that strings and
arrays (by which I take it you mean std::vector) are in the standard
library, and therefore can be considered part of the language.
However, it is perfectly valid to distinguish between those components
and the *built-in* ones in D, given the varying, and often
sub-optimal, performance of string and/or vector implementations in
C++ libraries. Until such time as *all* implementations exhibit
optimal (i.e. as good as those in any other language) performance, it
seems perfectly valid and reasonable to comment and compare. C++ is
about performance, is it not? If it isn't, why don't we all just use
C# or Java, and concentrate on enjoying all those lovely colouring
schemes, wizards and other gizmos in their IDDEs?
Matthew Wilson
STLSoft moderator and C++ monomaniac
"I can't sleep nights till I found out who hurled what ball through
what apparatus" -- Dr Niles Crane
-------------------------------------------------------------------------------
Bob Bell
> > "Francis Glassborow" <francis.g...@ntlworld.com> wrote in
> > message news:1WmYxPCOeCN$Ew...@robinton.demon.co.uk...
> > > In message <d1a33011.03080...@posting.google.com>, apm
> > > <ap...@student.open.ac.uk> writes
> > > >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? :-)
> >
> > www.digitalmars.com/NewsGroup.html
>
> You lost my interest as soon as you begin your explanation of D by
> explaining that C++ doesn't have resizable strings and arrays. Of course it
> does as part of its library and I know you know that. Using that sort of
> argument will turn off many intelligent C++ programmers who might be
> interested in your ideas, since it insults the intelligence and
> understanding of good programmers.
Funny you should mention that. I tuned out as well, but in my case
when I read something like "C++ doesn't have resizable strings and
arrays," I don't get insulted, I just think the author doesn't know
what he's talking about. In other words, it destroys the author's
credibility and I go away.
Bob
David Abrahams
> "Edward Diener" <eldi...@earthlink.net> wrote in message
> news:ww3_a.9531$BC2....@newsread2.news.atl.earthlink.net...
>> You lost my interest as soon as you begin your explanation of D by
>> explaining that C++ doesn't have resizable strings and arrays. Of course
> it
>> does as part of its library and I know you know that.
>
> The D spec does point this out:
>
>>From www.digitalmars.com/d/overview.html:
>
> "It's frustrating that such a powerful language does not do basic things
> like resizing arrays and concatenating strings. Yes, C++ does provide the
> meta programming ability to implement resizable arrays and strings like the
> vector type in the STL.
It's a bit of a stretch to refer to the generic programming required
to implement std::vector and std::string as metaprogramming.
> Such fundamental features, however, ought to be part of the
> language."
>
>>From www.digitalmars.com/d/comparison.html:
>
> "Part of the standard library for C++ implements resizeable arrays and
> strings, however, they are not part of the actual language.
This comes from a fundamental misunderstanding of the C++ standard.
The library *is* part of the language. We use the term "the core
language" to demarcate the parts of the language other than the
language support and other libraries.
> A conforming freestanding implementation of C++ (C++98 17.4.1.3)
> does not need to provide these libraries."
How many freestanding implementations of C++ have you encountered?
Freestanding implementations are the C++ standard's one concession to
language subsetting, designed to accomodate embedded systems which
don't even have an operating system. I've never met one.
Regardless, the author of that document ought to justify the assertion
that it's better to put vectors and strings in the core language.
Sophisticated language designers are continually trying to push as
many features as possible *out* of their core languages - it has
enormous benefits for maintenance of an implementation, evolution of
the language itself, and the power available to users. Look for
example at Max Skaller's Felix language (felix.sourceforge.net). In
Felix, even simple things like while loops are not in the core
language.
> C++ does a brilliant job of making it possible and practical to
> create libraries with new types and graft them almost seamlessly
> into the language itself. D goes a bit further and integrates the
> most common and useful constructs into the syntax and semantics,
> where I believe they belong.
Sounds like a step backwards into the dark ages to me. Anyone
remember PL/1?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
David Abrahams
>> >> (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.
>> I don't know how they implement it. But it does work.
>
> Two ways to do it: either cart along with your executable a bytecode
> compiler or a bytecode interpreter. It's still married to the bytecode one
> way or another <g>.
How do you explain http://www.edg.com/jfe.html?
"Use of the JFE as a Compiler
The JFE can be used as part of a compiler for the Java language. One
can write a back end that translates the intermediate language to
object code, or a converter to the intermediate language used by an
existing optimizer/code generator.
There is, however, a more attractive alternative. The JFE includes a
component (called "C IL Generation") that translates the Java
intermediate language (JIL) to the C intermediate language (CIL)
used by EDG's C++/C front end. The CIL can then be fed into a code
generator (this is easier than generating code directly from the
JIL) or, using the C-generating back end provided with the JFE,
output as C source code. This code can then be compiled to object
code using any C compiler."
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Stephen Howe
> like resizing arrays and concatenating strings. Yes, C++ does provide the
> meta programming ability to implement resizable arrays and strings like
the
> vector type in the STL. Such fundamental features, however, ought to be
part
> of the language."
On that I concur. I wish there was both a resize [] expression and operator
resize [] that work with arrays allocated by new [], the former builtin to
the language and calls destructors if the array is shrinking, default
constructors if the array can be expanded insitu, and a mixture of
destructors/copy constructors if the array cannot be expanded insitu; the
latter overrideable which is guaranteed to always satisfy a shrink request,
and do a bad_alloc throw if it cannot expand the memory insitu. Naturally
the resize expression calls operator resize [] and operator new[], operator
delete[] if operator resize [] fails.
vector could be implemented in terms operator resize if allocator interface
was changed slightly. The net effect would be to reduce the number of copy
constructor and destructor calls if resizing insitu works.
Stephen Howe
Walter
"Gina Yarmel" <tainte...@yahoo.com> wrote in message
news:e4241c19.03081...@posting.google.com...
> "Walter" <walter...@digitalmars.nospaam.com> wrote
> > Ok, I'll bite! In what way is C++ better than D?
> Multiple inheritance.
When MI was first proposed for C++, a number of people argued that it was a
step backwards <g>. Single inheritance with interfaces seems to do the job
nicely. General MI is a lot of implementation complexity with marginal, and
eminently debatable, utility over SI with interfaces.
-Walter
www.digitalmars.com/d/
llewelly
> "llewelly" <llewe...@xmission.dot.com> wrote in message
> news:86y8y0p...@Zorthluthik.local.bar...
>> 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 :-) 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.
I also note that at least for C++ the
complexity of implementing the language has IMO been a major
portability barrier; an important reason it was (and to a lesser
extent still is) so hard to take advantage of C++'s power in
portable code is the sheer difficulty of implementing many
of its features causes many implementors to make mistakes. (Or
deliberately choose not to implement features.)
> (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.)
I think < is impossible (not merely problematic) to parse correctly
without knowing wether the preceding identifier is a template
name. In fact in some cases the template keyword must be used to
inform the compiler that a name is a template name. There are also
interesting difficulties with extamples like:
template<int i> struct Foo{};
int const a= 1, b= 2;
Foo<a<b> d;
James Dennett
> James Dennett <jden...@acm.org> wrote in message news:<lR_Za.11905$Ye.6666@fed1read02>...
>
>> > 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.
>
>
> I believe that eiffel takes a similar approach.
That matches my limited knowledge of Eiffel.
>
>> > This is superior to C++'s manual and error-prone approach.
>
>
> I tend to agree.
>
>
>>This is not a question of automating something: it's a question
>>of having a language that encourages the use of good designs.
>
>
> I thought that the reason for the use of 'virtual' was because
> of Stroustrup's pay-as-you philosophy, i.e you don't pay
> for cost of a virtual dispatch by default but there is a way
> to say that you do want virtual dispatch.
That's certainly one reason, and in the case of C++ it
may have been considered sufficient: C++ did a lot to be
fairly compatible with C and to avoid being seen as
inefficient. (And sometimes failed on the latter, even
when the inefficiency is illusory or just a consequence
of a flawed implementation.)
That doesn't, however, mean that the decision would not
have been made the same way even if the C-compatibility
and efficient arguments were neglected. As my previous
post indicated, I believe that non-virtual by default is
the right choice for design reasons, not as a performance
optimization.
-- James.
Walter
"David Abrahams" <da...@boost-consulting.com> wrote in message
news:uadae4...@boost-consulting.com...
> > "Part of the standard library for C++ implements resizeable arrays and
> > strings, however, they are not part of the actual language.
> This comes from a fundamental misunderstanding of the C++ standard.
> The library *is* part of the language. We use the term "the core
> language" to demarcate the parts of the language other than the
> language support and other libraries.
I'd be happy to use the phrase "core language" rather than the "actual
language".
> > A conforming freestanding implementation of C++ (C++98 17.4.1.3)
> > does not need to provide these libraries."
> How many freestanding implementations of C++ have you encountered?
> Freestanding implementations are the C++ standard's one concession to
> language subsetting, designed to accomodate embedded systems which
> don't even have an operating system. I've never met one.
If we're being pedantic, let's be pedantic <g>. BTW, I've developed for
embedded systems with no operating system.
> Regardless, the author of that document ought to justify the assertion
> that it's better to put vectors and strings in the core language.
The reasons to put any feature in the core language as opposed to the
library are (in addition to Stephen Howe's comments):
1) better integration with the syntax of the language
2) better semantic integration
3) better error messages
4) since the compiler knows what the semantics of the feature are, it can
generate better code, do constant folding, etc.
> Sophisticated language designers are continually trying to push as
> many features as possible *out* of their core languages - it has
> enormous benefits for maintenance of an implementation, evolution of
> the language itself, and the power available to users.
Those are very desirable goals, and sometimes they conflict with the other
goals I mentioned. Like any good engineering design, the end result is a
judgement call on the tradeoffs. Would you say that C++ has a minimal
orthogonal set of features? I wouldn't. C++ can be improved given one is
willing to give up on compiling unmodified legacy code, and that's what D
does. D has eliminated a raft of redundant features of C++, making D a much
smaller language but with more capability.
-Walter
www.digitalmars.com/d/ The D Programming Language
llewelly
> "Gina Yarmel" <tainte...@yahoo.com> wrote in message
> news:e4241c19.03081...@posting.google.com...
> > "Walter" <walter...@digitalmars.nospaam.com> wrote
> > > Ok, I'll bite! In what way is C++ better than D?
> > Multiple inheritance.
>
> When MI was first proposed for C++, a number of people argued that it was a
> step backwards <g>. Single inheritance with interfaces seems to do the job
> nicely. General MI is a lot of implementation complexity with marginal, and
> eminently debatable, utility over SI with interfaces.
This is really only defensible because of D's DBC features. Without
those lack of real multiple inheritance would be a significant
problem.
llewelly
[snip]
> > C++ does a brilliant job of making it possible and practical to
> > create libraries with new types and graft them almost seamlessly
> > into the language itself. D goes a bit further and integrates the
> > most common and useful constructs into the syntax and semantics,
> > where I believe they belong.
>
> Sounds like a step backwards into the dark ages to me. Anyone
> remember PL/1?
There is still discussion on comp.lang.pl1 . Where they find
implementations for current popular systems I don't know, but they
do talk about it.
llewelly
> "Edward Diener" <eldi...@earthlink.net> wrote in message
> news:ww3_a.9531$BC2....@newsread2.news.atl.earthlink.net...
>> You lost my interest as soon as you begin your explanation of D by
>> explaining that C++ doesn't have resizable strings and arrays. Of course
> it
>> does as part of its library and I know you know that.
>
> The D spec does point this out:
>
>>From www.digitalmars.com/d/overview.html:
>
> "It's frustrating that such a powerful language does not do basic things
> like resizing arrays and concatenating strings. Yes, C++ does provide the
> meta programming ability to implement resizable arrays and strings like the
> vector type in the STL. Such fundamental features, however, ought to be part
> of the language."
Which too many people will translate to:
'C++ has resizable strings and arrays, but I'd rather pretend it
didn't. '
If that is not what you intended, you need to re-think your paragraph
on the topic.
If you jump at every chance to belittle alternative languages,
prospective users of D will misperceive the D community as
dominated by hate and hostility.
>
>>From www.digitalmars.com/d/comparison.html:
>
> "Part of the standard library for C++ implements resizeable arrays and
> strings, however, they are not part of the actual language. A conforming
> freestanding implementation of C++ (C++98 17.4.1.3) does not need to provide
> these libraries."
>
> C++ does a brilliant job of making it possible and practical to create
> libraries with new types and graft them almost seamlessly into the language
> itself. D goes a bit further and integrates the most common and useful
> constructs into the syntax and semantics, where I believe they belong.
This is perfectly reasonable statement. Note that this is quite
different from the false claim that C++ does not provide
resizeable strings or arrays.
Bo Persson
"Bob Bell" <bel...@pacbell.net> skrev i meddelandet
news:c87c1cfb.03081...@posting.google.com...
The problem here is that we *know* that the author is very well aware
of what C++ does.
Look at the sentence
> >Has anyone here come across the D language
> >by Walter Bright (author of the Zortech compiler)?
and make one guess at what language the famous Zortech compiler was
all about!
>
> Bob
>
Bo Persson
Bo Persson
"Matthew Wilson" <stl...@hotmail.com> skrev i meddelandet
>
> I'm struggling to see how this is an insult to one's intelligence.
Are
> you telling me that C++ and its libraries represent an absolute
> maximum in the space of language design and implementation, and
> therefore any criticism of them is invalid?
No, but saying that a feature that doesn't *require* special compiler
support is not part of the language, is just nonsense. In C++ some
parts, like string and vector, *can* be expressed as a pure library
feature. Is that a weakness?!
>
>
> To deal with the issue, you make a reasonable point that strings and
> arrays (by which I take it you mean std::vector) are in the standard
> library, and therefore can be considered part of the language.
It *is* part of the language. The standard specifies what
> However, it is perfectly valid to distinguish between those
components
> and the *built-in* ones in D, given the varying, and often
> sub-optimal, performance of string and/or vector implementations in
> C++ libraries.
So now we are comparing implementations and not languages?!
Nothing prevents a C++ compiler from using knowledge of std::string,
if that can help it improve performance. The contents of <string> is
specified in the standard document, so the compiler can prefectly well
treat
#include <string>
as way to enable its built-in string class, but it doesn't have to.
Where is the weakness? How is D superior here??
Bo Persson
Walter
> > 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.
> I also note that at least for C++ the
> complexity of implementing the language has IMO been a major
> portability barrier; an important reason it was (and to a lesser
> extent still is) so hard to take advantage of C++'s power in
> portable code is the sheer difficulty of implementing many
> of its features causes many implementors to make mistakes. (Or
> deliberately choose not to implement features.)
You're right, of course. I'd venture that it would take 10 years to write a
C++ compiler from scratch. All the existing ones I know of are well over 10
years old. The standard was approved 5 years ago and just recently have
compilers caught up to it.
One way I try to improve this situation in D is to make the source to the
front end open source.
> > (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.)
> I think < is impossible (not merely problematic) to parse correctly
> without knowing wether the preceding identifier is a template
> name. In fact in some cases the template keyword must be used to
> inform the compiler that a name is a template name. There are also
> interesting difficulties with extamples like:
>
> template<int i> struct Foo{};
> int const a= 1, b= 2;
> Foo<a<b> d;
C++ evolved to where it is today with a steady accretion of new features
grafted into the existing syntax. Isn't it worthwhile to take a fresh look
at it, and refactor it into a much simpler language with equivalent or even
more power?
-Walter
www.digitalmars.com/d/ The D Programming Language
Walter
> "Walter" <walter...@digitalmars.nospaam.com> writes:
>
> >> >> (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.
> >> I don't know how they implement it. But it does work.
> > Two ways to do it: either cart along with your executable a bytecode
> > compiler or a bytecode interpreter. It's still married to the bytecode
one
> > way or another <g>.
> How do you explain http://www.edg.com/jfe.html?
This implies they don't support dynamic class loading: "Because no JVM is
needed in memory, and only those parts of the library that are referenced
need to be linked in, a native executable can potentially run in
environments (e.g., embedded processors) where the Java language might
otherwise be too big."
Walter
"Bo Persson" <bo...@telia.com> wrote in message
news:W0u_a.24008$dP1....@newsc.telia.net...
> The problem here is that we *know* that the author is very well aware
> of what C++ does.
Yup. In fact, I wrote in the D spec that C++ has strings and resizable
arrays in the library:
From www.digitalmars.com/d/overview.html:
"It's frustrating that such a powerful language does not do basic things
like resizing arrays and concatenating strings. Yes, C++ does provide the
meta programming ability to implement resizable arrays and strings like the
vector type in the STL. Such fundamental features, however, ought to be part
of the language."
From www.digitalmars.com/d/comparison.html:
"Part of the standard library for C++ implements resizeable arrays and
strings, however, they are not part of the actual language. A conforming
freestanding implementation of C++ (C++98 17.4.1.3) does not need to provide
these libraries."
Some have pointed out that I should say "core language" rather than "actual
language", and I'm happy to make that change and have updated the web page
accordingly.
Walter
> Where is the weakness? How is D superior here??
That's a fair question. I obviously need to write up a report about it, so
please indulge me for a bit and I'll get back here with it. -Walter
David Abrahams
>> > A conforming freestanding implementation of C++ (C++98 17.4.1.3)
>> > does not need to provide these libraries."
>> How many freestanding implementations of C++ have you encountered?
>> Freestanding implementations are the C++ standard's one concession to
>> language subsetting, designed to accomodate embedded systems which
>> don't even have an operating system. I've never met one.
>
> If we're being pedantic, let's be pedantic <g>. BTW, I've developed for
> embedded systems with no operating system.
Did you use a freestanding implementation of C++?
>> Regardless, the author of that document ought to justify the assertion
>> that it's better to put vectors and strings in the core language.
>
> The reasons to put any feature in the core language as opposed to the
> library are (in addition to Stephen Howe's comments):
> 1) better integration with the syntax of the language
> 2) better semantic integration
> 3) better error messages
> 4) since the compiler knows what the semantics of the feature are, it can
> generate better code, do constant folding, etc.
The real challenge is to write a language which lets a library writer
achieve all those things for her own classes. Some people think hash
tables are as fundamental as vectors. Some people need mutable
strings; others need immutable strings. Your component-specific
integration will only handle a limited range of cases.
>> Sophisticated language designers are continually trying to push as
>> many features as possible *out* of their core languages - it has
>> enormous benefits for maintenance of an implementation, evolution
>> of the language itself, and the power available to users.
>
> Those are very desirable goals, and sometimes they conflict with the
> other goals I mentioned. Like any good engineering design, the end
> result is a judgement call on the tradeoffs. Would you say that C++
> has a minimal orthogonal set of features?
Hardly!
> I wouldn't. C++ can be improved given one is willing to give up on
> compiling unmodified legacy code, and that's what D does.
Oh, definitely. Once you give up on that, though, there is a whole
world of possibility. The fact that D has taken the step of deciding
not to be a superset of C++ doesn't make it a good idea to drive
library components into the core language.
> D has eliminated a raft of redundant features of C++, making D a
> much smaller language but with more capability.
Wonderful!
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
llewelly
Because it makes an obviously false statement. More, it is a falsehood
which is unhelpful to advocating D; one could gain more by arguing
of that integrating strings and resizable arrays into the language
simplifies the syntax. (Should be an easy argument to win. :-)
( Yes, I know there are languages where having a feature in the
library need not impact syntax, but niether C++ nor D is one of
those languages, though both make significant steps in that
direction.)
It amazes me that with the seemingly endless list of valid objections
to C++, advocaters of language X seem to prefer invalid objections
when comparing X to C++. I also observe that a only a tiny
percentage of these languages succeed in replacing C++ in any
significant area. (The nearest examples - Java and C# - seem to be
most important in areas C++ never served well, and were gifted
with enourmous marketing budgets (which C++ never had, and D
likely will never have either).)
It gives the appearance that the advocaters of X know nothing about
which they speak - though of course they often *do* know, but have
been overtaken by their (often justified) enthusiasm for language
X.
(The advocaters of D are by no means the worst offenders in this
area. )
> Are
> you telling me that C++ and its libraries represent an absolute
> maximum in the space of language design and implementation, and
> therefore any criticism of them is invalid?
[snip]
No-one here has said anything of this kind. As professional C++
programmers, we are all aware that C++ has many flaws, some quite
difficult to work around. std::string in particular is often
labeled as 'poorly designed', 'unecessarily complex', etc, in this
ng.
Francis Glassborow
<walter...@digitalmars.nospaam.com> writes
>"Part of the standard library for C++ implements resizeable arrays and
>strings, however, they are not part of the actual language. A conforming
>freestanding implementation of C++ (C++98 17.4.1.3) does not need to provide
>these libraries."
>
>Some have pointed out that I should say "core language" rather than "actual
>language", and I'm happy to make that change and have updated the web page
>accordingly.
OTOH a conforming C++ implementation can provide those things in any way
it wishes. That is one of the special characteristics of a Standard
Library and was at least part of the motivation for placing such things
as valarray in the library.
The current problem is that we lack a separation between those parts of
the Standard Library that must be provided by the implementor of the
core language (they rely on compiler magic) and those parts that should
always be replaceable by a third party implementation.
We also have the problem that a string literal is not a std::string.
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Matthew Wilson
> Are
> > you telling me that C++ and its libraries represent an absolute
> > maximum in the space of language design and implementation, and
> > therefore any criticism of them is invalid?
>
> No, but saying that a feature that doesn't *require* special compiler
> support is not part of the language, is just nonsense. In C++ some
> parts, like string and vector, *can* be expressed as a pure library
> feature. Is that a weakness?!
I don't understand what you're saying, nor how that relates to the
comment I made that you appear to have responded to.
> > To deal with the issue, you make a reasonable point that strings and
> > arrays (by which I take it you mean std::vector) are in the standard
> > library, and therefore can be considered part of the language.
>
> It *is* part of the language. The standard specifies what
Accepted, but std::vector is hardly the same as a built-in array in
the level of what is
fundamental/built-in/intrinsic/choose-your-preferred-adjective. For
example, I could provide my own std::vector implementation with code
(and even make it behave differently) if I chose, which is not
possible with arrays, the double type etc. or fundamental types &
arrays in D.
The fact that doing so would be ill-advised is irrelevant to the fact
that I can do it, and do it easily.
And, yes, I know that there is a grey-area: op-new, new_handler, etc.
But all this is laboured nonsense. If you want to say there is a limit
- the standard (including fundamental/built-in features and the
library) - under which one cannot distinguish, then I can't argue with
it from the perspective of the C++ letter of the law, but it doesn't
mean to say that such a viewpoint is either helpful or appropriate to
the issue under discussion.
> > However, it is perfectly valid to distinguish between those
> components
> > and the *built-in* ones in D, given the varying, and often
> > sub-optimal, performance of string and/or vector implementations in
> > C++ libraries.
>
> So now we are comparing implementations and not languages?!
Sure, why not? I'm a pragmatist (like the vast majority of software
engineers??) so I don't really care whether something is deemed in the
language or in the library. I care whether it engenders and
facilitates good coding practise, is efficient, is robust, is
maintainable and is portable.
> Nothing prevents a C++ compiler from using knowledge of std::string,
> if that can help it improve performance. The contents of <string> is
> specified in the standard document, so the compiler can prefectly well
> treat
>
> #include <string>
>
> as way to enable its built-in string class, but it doesn't have to.
>
> Where is the weakness? How is D superior here??
I haven't said D is superior. The simple reason for that is that I
don't think it's superior; I think C++ is far ahead of any other
language of which I have any significant understanding. What I do not
think is that it is either (i) perfect, or (ii) the answer in all
situations. I regularly use C, D, C#, Java, Perl and Python, and they
each have their virtues and their niches.
What I did say is that D is interesting, and I took issue with the
assertion that C++ programmers will be turned off by someone (perhaps
erroneously) stating that some C++ feature belonged to the language or
to the library.
They couldn't give a fig for the dry precision of the standard. (And
before anyone jumps on that, I am *not* saying the standard is not
very important. Of course it is; I've been digging in it every day for
the last 2 months! It's just that it's not very important to most
jobbing C++ practitioners. I reckon if we could do a poll of Win32
programmers most would be more concerned about the inconsistencies
between 9x/NT family implementations of the Win32 API than they would
about compiler adherence to the standard. Most of them use Visual C++,
or one of the myriad compilers that provide Visual C++-compatiblity.)
People (or at least the practising majority) care about ease of use,
tools, correctness, performance, power, portability. If they didn't
then this newsgroup wouldn't exist, because there are more "perfect"
languages out there than C++. They're just not as good.
Francis Glassborow
Wilson <stl...@hotmail.com> writes
>> It *is* part of the language. The standard specifies what
>
>Accepted, but std::vector is hardly the same as a built-in array in
>the level of what is
>fundamental/built-in/intrinsic/choose-your-preferred-adjective. For
>example, I could provide my own std::vector implementation with code
>(and even make it behave differently) if I chose, which is not
>possible with arrays, the double type etc. or fundamental types &
>arrays in D.
>
>The fact that doing so would be ill-advised is irrelevant to the fact
>that I can do it, and do it easily.
You can do it, but if you do you may not get what you expect. IIUC a C++
implementation is deemed to know about the contents of the Standard
Library and may, in consequence, ignore your implementation or issue a
diagnostic.
It is not entirely clear to me exactly what is or is not allowed. In the
case of C it was always clear that one could declare a Standard Library
function but providing a definition was, at best, non-portable; that was
the implementation's responsibility.
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Walter
"Francis Glassborow" <fra...@robinton.demon.co.uk> wrote in message
news:DRLlgcC1s1O$Ew...@robinton.demon.co.uk...
> OTOH a conforming C++ implementation can provide those things in any way
> it wishes. That is one of the special characteristics of a Standard
> Library and was at least part of the motivation for placing such things
> as valarray in the library.
You're right. In fact, most quality C/C++ compilers recognize a number of
functions, such as sin, cos, fabs, strlen, memcpy, etc., and generate
specialized code for them.
> The current problem is that we lack a separation between those parts of
> the Standard Library that must be provided by the implementor of the
> core language (they rely on compiler magic) and those parts that should
> always be replaceable by a third party implementation.
Java.lang.string is an example of a string library that does rely on
compiler magic, std::string does not.
> We also have the problem that a string literal is not a std::string.
Right. Although a compiler can recognize std::string and generate special
code for it, operator overloading doesn't quite get it all the way into the
syntax/semantics. This has some suboptimal consequences which I'm writing up
for a better treatment of this topic, which I intend to post here shortly.
-Walter
www.digitalmars.com/d/ The D Programming Language
Walter
"Walter" <walter...@digitalmars.nospaam.com> wrote in message
news:RNz_a.95024$cF.29055@rwcrnsc53...
> "Bo Persson" <bo...@telia.com> wrote in message
news:zYt_a.24006$dP1....@newsc.telia.net...
> > Where is the weakness? How is D superior here??
> That's a fair question. I obviously need to write up a report about it, so
> please indulge me for a bit and I'll get back here with it. -Walter
Here it is: www.digitalmars.com/d/cppstrings.html
Walter
> > I wouldn't. C++ can be improved given one is willing to give up on
> > compiling unmodified legacy code, and that's what D does.
> Oh, definitely. Once you give up on that, though, there is a whole
> world of possibility. The fact that D has taken the step of deciding
> not to be a superset of C++ doesn't make it a good idea to drive
> library components into the core language.
I've posted a short paper on the string thing here:
www.digitalmars.com/d/cppstrings.html
> > D has eliminated a raft of redundant features of C++, making D a
> > much smaller language but with more capability.
> Wonderful!
I'd certainly be interested in your comments on other features of D that are
not in C++ such as DbC, unit testing, nested functions, delegates, garbage
collection, the different template design, UTF integration, modules,
versioning, elimination of the preprocessor, etc., as well as the general
cleanup of the syntax.
James Dennett
> "Walter" <walter...@digitalmars.nospaam.com> writes:
>
> >> > A conforming freestanding implementation of C++ (C++98 17.4.1.3)
> >> > does not need to provide these libraries."
> >> How many freestanding implementations of C++ have you encountered?
> >> Freestanding implementations are the C++ standard's one concession to
> >> language subsetting, designed to accomodate embedded systems which
> >> don't even have an operating system. I've never met one.
> >
> > If we're being pedantic, let's be pedantic <g>. BTW, I've developed for
> > embedded systems with no operating system.
>
> Did you use a freestanding implementation of C++?
Within the last 2 years, I've used C++ compilers for
embedded systems which supplied only most of the C library
and some of the essentials of the C++ library. They
weren't really good enough to count as viable
freestanding implementations of C++ though.
The compilers which were good approximations to
freestandling implementations of C++ all came with
fairly complete implementations of the full C++ library.
(Portability concerns meant that we couldn't use it, but...)
-- James.
Matthew Wilson
> "David Abrahams" <da...@boost-consulting.com> wrote in message
> news:uy8xxt...@boost-consulting.com...
> > > I wouldn't. C++ can be improved given one is willing to give up on
> > > compiling unmodified legacy code, and that's what D does.
> > Oh, definitely. Once you give up on that, though, there is a whole
> > world of possibility. The fact that D has taken the step of deciding
> > not to be a superset of C++ doesn't make it a good idea to drive
> > library components into the core language.
>
> I've posted a short paper on the string thing here:
> www.digitalmars.com/d/cppstrings.html
>
Which says:
Copying a String
C++ copies strings with the copy function, but only to the
beginning:
string s1 = "hello world";
string s2 = "goodbye ";
s1.copy(s2, 1, 5); // s2 is "worldye "
D allows copying anywhere in the string:
char[] s1 = "hello world";
char[] s2 = "goodbye ";
s2[8..13] = s1[6..11]; // s2 is "goodbye world"
If you use Shims (http://www.cuj.com/documents/s=8681/cuj0308wilson/),
you get *far* more power in the C++ model. Until D gets all shimmed
up, C++ will have the march in generality wrt strings (any anything
else you can shake a stick at).
Matthew
Matthew Wilson
> In article <5d33192c.03081...@posting.google.com>, Matthew
> Wilson <stl...@hotmail.com> writes
> >> It *is* part of the language. The standard specifies what
> >
> >Accepted, but std::vector is hardly the same as a built-in array in
> >the level of what is
> >fundamental/built-in/intrinsic/choose-your-preferred-adjective. For
> >example, I could provide my own std::vector implementation with code
> >(and even make it behave differently) if I chose, which is not
> >possible with arrays, the double type etc. or fundamental types &
> >arrays in D.
> >
> >The fact that doing so would be ill-advised is irrelevant to the fact
> >that I can do it, and do it easily.
>
> You can do it, but if you do you may not get what you expect. IIUC a C++
> implementation is deemed to know about the contents of the Standard
> Library and may, in consequence, ignore your implementation or issue a
> diagnostic.
>
> It is not entirely clear to me exactly what is or is not allowed. In the
> case of C it was always clear that one could declare a Standard Library
> function but providing a definition was, at best, non-portable; that was
> the implementation's responsibility.
You'll get no argument from me.
I guess my point is that it seems somewhat unhelpful to draw an
iron-curtain/glass-ceiling/struggling-for-analogy on what is
"built-in" to the language and what is legislated in (into the
standard library) in the context of a discussion about a language that
is currently under development.
Drawing a distinction between these things is not only apposite, but
positively necessary, if D is to achieve its aim of being a more
optimal mix of elegance and grunt than is C++.
Of course, I'm backing up my own point of view here, so am probably
being fatuous, at best.
:)
Matthew
Mike
>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!)
Multiple inheritance, or D isn't OO.
-Mike
David Abrahams
> "David Abrahams" <da...@boost-consulting.com> wrote in message
> news:uy8xxt...@boost-consulting.com...
>> > I wouldn't. C++ can be improved given one is willing to give up on
>> > compiling unmodified legacy code, and that's what D does.
>> Oh, definitely. Once you give up on that, though, there is a whole
>> world of possibility. The fact that D has taken the step of deciding
>> not to be a superset of C++ doesn't make it a good idea to drive
>> library components into the core language.
>
> I've posted a short paper on the string thing here:
> www.digitalmars.com/d/cppstrings.html
I find it really amusing that you're touting built-in-ness as a big
advantage because I can write a string class in C++ which has all the
features shown for D strings, almost right down to the syntax (save
the name of the type and using ~ as a concatenation operator, which I
don't neccessarily think is an improvement).
>> > D has eliminated a raft of redundant features of C++, making D a
>> > much smaller language but with more capability.
>> Wonderful!
>
> I'd certainly be interested in your comments on other features of D that are
> not in C++ such as DbC, unit testing, nested functions, delegates, garbage
> collection, the different template design, UTF integration, modules,
> versioning, elimination of the preprocessor, etc., as well as the general
> cleanup of the syntax.
Oh, all those features are wonderful I'm sure; it's their realization
I wonder about. If I get a spare day sometime I'll go through the
manual and look at them all in detail ;->.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
llewelly
> "Walter" <walter...@digitalmars.nospaam.com> wrote in message
> news:RNz_a.95024$cF.29055@rwcrnsc53...
>> "Bo Persson" <bo...@telia.com> wrote in message
> news:zYt_a.24006$dP1....@newsc.telia.net...
>> > Where is the weakness? How is D superior here??
>> That's a fair question. I obviously need to write up a report about it, so
>> please indulge me for a bit and I'll get back here with it. -Walter
>
> Here it is: www.digitalmars.com/d/cppstrings.html
Several of your points I agree with. However, this:
# C++ has two issues, whether a string is initialized and whether it
# is empty or not. This requires some care to get right:
#
# string *str;
# if (str == NULL || str->empty())
# // string is empty
I take issue with. *Every* rebindable indirect type, in most (all?)
languages, requires the additional check for whether the indirect
type is bound to an object.
You accuse string, but your evidence points to
string* - a very different, and seldom useful type.
Falsehood in D advocacy is both unneccessary and undesireable. C++
string has plenty of real flaws.
Uli Kusterer
just dropping in and found this discussion very intriguing. Would any
of you happen to have a URL describing D, for someone interested in
finding out what it is?
Thanks in advance,
-- M. Uli Kusterer
http://www.zathras.de
Bo Persson
> > > I'm struggling to see how this is an insult to one's
intelligence.
> > Are
> > > you telling me that C++ and its libraries represent an absolute
> > > maximum in the space of language design and implementation, and
> > > therefore any criticism of them is invalid?
> >
> > No, but saying that a feature that doesn't *require* special
compiler
> > support is not part of the language, is just nonsense. In C++ some
> > parts, like string and vector, *can* be expressed as a pure
library
> > feature. Is that a weakness?!
>
> I don't understand what you're saying, nor how that relates to the
> comment I made that you appear to have responded to.
The "insult" is in stating that C++ doesn't have a built in string
class. We all know it does.
>
> > > To deal with the issue, you make a reasonable point that strings
and
> > > arrays (by which I take it you mean std::vector) are in the
standard
> > > library, and therefore can be considered part of the language.
> >
> > It *is* part of the language. The standard specifies what
>
> Accepted, but std::vector is hardly the same as a built-in array in
> the level of what is
> fundamental/built-in/intrinsic/choose-your-preferred-adjective.
The preferred adjective (which is not an adjective) is "part of the
language". Stating that the standard library is not an integral part
of C++ is *not* the basis for a fair comparison, it's more like an
attempted blow below the belt:
"Resizeable arrays
Part of the standard library for C++ implements resizeable arrays,
however, they are not part of the core language. A conforming
freestanding implementation of C++ (C++98 17.4.1.3) does not need to
provide these libraries. "
IMNSHO, this is totally irrelevant, but is used to give D a "yes" and
C++ a "no" in the comparison. While technically true that a C++ array
is not resizeable, we all know that a C++ vector is.
So I could write:
"Resizeable vectors
Part of the standard library for C++ implements resizeable vectors.
The D language has a built in array concept, but it requires special
support from the compiler, and does not implement the exact same
features."
Resizeable vector: C++ - yes, D - no.
I think this is *really* unfair.
>
> > > However, it is perfectly valid to distinguish between those
> > components
> > > and the *built-in* ones in D, given the varying, and often
> > > sub-optimal, performance of string and/or vector implementations
in
> > > C++ libraries.
> >
> > So now we are comparing implementations and not languages?!
>
> Sure, why not? I'm a pragmatist (like the vast majority of software
> engineers??) so I don't really care whether something is deemed in
the
> language or in the library. I care whether it engenders and
> facilitates good coding practise, is efficient, is robust, is
> maintainable and is portable.
But you can't really mean that D is a better language because some C++
implementations are bad?
Some of us will be *very* turned off by anyone stating that C++
doesn't support strings. The usual discussion is about the std::string
being to big and complicated, not that some features are missing.
It is also a bit silly of a guy like Walter Bright, who really knows
these things, to publish a comparison saying "While many capabilities
are available with libraries, this table is for features built in to
the language itself. ", when the fact is that some of the features of
C++ is specified in the library part of the standard document because
they happen to be expressable as a library.
The compiler is however *allowed* to know these library elements, but
not *required*, because they can work anyway. Turning this into a "no"
in the table was really a surprise.
Bo Persson
Walter
> I take issue with. *Every* rebindable indirect type, in most (all?)
> languages, requires the additional check for whether the indirect
> type is bound to an object.
>
> You accuse string, but your evidence points to
> string* - a very different, and seldom useful type.
Your criticism is valid if string* and new string(args) are rarely used.
Walter
> "Walter" <walter...@digitalmars.nospaam.com> writes:
> > "David Abrahams" <da...@boost-consulting.com> wrote in message
> > news:uy8xxt...@boost-consulting.com...
> >> > I wouldn't. C++ can be improved given one is willing to give up on
> >> > compiling unmodified legacy code, and that's what D does.
> >> Oh, definitely. Once you give up on that, though, there is a whole
> >> world of possibility. The fact that D has taken the step of deciding
> >> not to be a superset of C++ doesn't make it a good idea to drive
> >> library components into the core language.
> > I've posted a short paper on the string thing here:
> > www.digitalmars.com/d/cppstrings.html
> I find it really amusing that you're touting built-in-ness as a big
> advantage because I can write a string class in C++ which has all the
> features shown for D strings, almost right down to the syntax (save
> the name of the type and using ~ as a concatenation operator, which I
> don't neccessarily think is an improvement).
Of course anything can be represented as appropriately designed function
calls coupled with some conventions. What you can't do is, of course, the
syntax, the integration with string literals and fixed char arrays, etc., as
pointed out in the article. Strings and char[] are different types in C++,
and there's no way to not have to keep that in mind when mixing the two.
(Example is in the article.) Java recognizes this and integrates
java.lang.String into the core language.
I can also do virtual functions and polymorphism in C, too (it's been done
and it works). But it's real nice when integrated into the syntax of C++.
As for ~, it is nice to have a clear, unambiguous distinction between array
concatenation and vector add. Few would want to do a vector add with
strings, but that certainly would be of great interest for arrays of
doubles. Trying to use + for vector add in one case, and concatenation in
another, is inconsistent and arbitrary. Confusion about this comes up in
other languages as well. Consider "123"+"4". Should that mean "1234" or 127?
Any way you slice that, you're left picking an arbitrary rule.
At first, using ~ seemed a bit odd. But it rapidly began to look natural,
and after using it for a while it's clear it was the right decision.
> >> > D has eliminated a raft of redundant features of C++, making D a
> >> > much smaller language but with more capability.
> >> Wonderful!
> > I'd certainly be interested in your comments on other features of D that
are
> > not in C++ such as DbC, unit testing, nested functions, delegates,
garbage
> > collection, the different template design, UTF integration, modules,
> > versioning, elimination of the preprocessor, etc., as well as the
general
> > cleanup of the syntax.
> Oh, all those features are wonderful I'm sure; it's their realization
> I wonder about. If I get a spare day sometime I'll go through the
> manual and look at them all in detail ;->.
I'll look forward to when you get a chance to do it.
-Walter
www.digitalmars.com/d/ The D Programming Language
Walter
"Uli Kusterer" <wit...@t-online.de> wrote in message
news:witness-59F2EE...@news.t-online.com...
> Would any
> of you happen to have a URL describing D, for someone interested in
> finding out what it is?
Here it is:
All are welcome.
Bo Persson
"Walter" <walter...@digitalmars.nospaam.com> skrev i meddelandet
news:iWQ_a.145748$YN5.95999@sccrnsc01...
>
> "Walter" <walter...@digitalmars.nospaam.com> wrote in message
> news:RNz_a.95024$cF.29055@rwcrnsc53...
> > "Bo Persson" <bo...@telia.com> wrote in message
> news:zYt_a.24006$dP1....@newsc.telia.net...
> > > Where is the weakness? How is D superior here??
> > That's a fair question. I obviously need to write up a report
about it, so
> > please indulge me for a bit and I'll get back here with
it. -Walter
>
> Here it is: www.digitalmars.com/d/cppstrings.html
>
Interesting read. Here are my comments for some of the sections:
Concatenation operator
I agree that + and += are not the prefect choice of operators, because
it is not immediately obvious what adding two streams really mean.
Choosing ~ and ~= as replacements dosen't seem much of an improvement
to me either.
I haven't tried concatenating arrays much, so I can't say if
generalizing the operator is a great improvment. Could be.
Interoperability with C strings
I can't say that I have ever missed the concatenation operator for
string literal and string array, so it's nice but not convincing.
Consistency
If you stick with std::string, the inconsistency isn't there. I rarely
count the length of literals.
Checking for empty strings
I have never liked the C style testing of conditions using cute !s in
strange places. I usually write
if (pointer == 0)
for pointers, because that is clearer to me.
Honestly! :-)
Resizing Existing String
:-) Believe me, I am not making this up, but I don't like properties
either. Using resize() makes the operation very readable, IMO.
Slicing a string
std::string can also return a part of a string
string s1 = "hello world";
string s2 = s1.substr(6, 5);
which is pretty close.
I agree that s1[6..11] looks better though.
Copying a string
This example is incorrect, because std::string::copy requires a char*
target, which std::string doesn't provide. It should be more like:
string s1 = "hello world";
string s2 = "goodbye ";
s2.replace(8, 5, s1, 6, 5);
Looks ugly though, and of course I had to look it up to see what index
goes where.
Conversions to C Strings
As you say, the C++ designers intentionally did not provide an
implicit conversion.
Taking a reference
You can of course use the str[2] for std::string as well. Without the
range check, but that was also intentional.
Array bounds checking
You are correct here.
String switch statement
Correct. This is sometimes hard to explain to beginners.
Filling a string
I agree that your syntax is simpler, and look better, but it is not
obviuos to me whether it means insert, or replace, or both.
I find the s[6..11] syntax appealing, but obviously have to read up
more on the D semantics to learn exactly what it means. I now also
understand how you have chosen to generalize the C char array (or
maybe all array types) instead of making it a new type, as in C++.
That is an interesting idea. Still doesn't convince me in the built-in
vs library discussion though.
Bo Persson
bo...@telia.com
Francis Glassborow
<walter...@digitalmars.nospaam.com> writes
>At first, using ~ seemed a bit odd. But it rapidly began to look natural,
>and after using it for a while it's clear it was the right decision.
What to use an operator that is pronounced 'complement' for
concatenation?
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Gabriel Dos Reis
| Concatenation operator
|
| I agree that + and += are not the prefect choice of operators, because
| it is not immediately obvious what adding two streams really mean.
| Choosing ~ and ~= as replacements dosen't seem much of an improvement
| to me either.
In the C/C++ community, "~" reads "complement". Surely concatenating
two strings is not complementing.
--
Gabriel Dos Reis, g...@integrable-solutions.net
llewelly
> "llewelly" <llewe...@xmission.dot.com> wrote in message
> news:86vfsyx...@Zorthluthik.local.bar...
>> I take issue with. *Every* rebindable indirect type, in most (all?)
>> languages, requires the additional check for whether the indirect
>> type is bound to an object.
>>
>> You accuse string, but your evidence points to
>> string* - a very different, and seldom useful type.
>
> Your criticism is valid if string* and new string(args) are rarely used.
So you claim int (in c++) needs to be initialized twice?
llewelly
> "Walter" <walter...@digitalmars.nospaam.com> skrev i meddelandet
> news:iWQ_a.145748$YN5.95999@sccrnsc01...
> >
> > "Walter" <walter...@digitalmars.nospaam.com> wrote in message
> > news:RNz_a.95024$cF.29055@rwcrnsc53...
> > > "Bo Persson" <bo...@telia.com> wrote in message
> > news:zYt_a.24006$dP1....@newsc.telia.net...
> > > > Where is the weakness? How is D superior here??
> > > That's a fair question. I obviously need to write up a report
> about it, so
> > > please indulge me for a bit and I'll get back here with
> it. -Walter
> >
> > Here it is: www.digitalmars.com/d/cppstrings.html
> >
>
> Interesting read. Here are my comments for some of the sections:
>
> Concatenation operator
>
> I agree that + and += are not the prefect choice of operators, because
> it is not immediately obvious what adding two streams really mean.
> Choosing ~ and ~= as replacements dosen't seem much of an improvement
> to me either.
[snip]
Looking at other langauges, I think + and . are the most common string
concatenation operators. I don't know of any langauge other than D
which uses ~. I don't like + because it says the wrong thing. I
dislike ~ for the same reason. Before learning perl, . did not say
anything in particular to me - so I lean toward . I don't think
there is an 'obvious' good operator name for string concatenation.
Gabriel Dos Reis
[...]
| I
| dislike ~ for the same reason. Before learning perl, . did not say
| anything in particular to me - so I lean toward . I don't think
| there is an 'obvious' good operator name for string concatenation.
The programming language of the Maple computer algebra system uses "."
as string concatenation operator; but then, I never have been
impressed by the design of that programming language ;-/
[component selection is denoted by ":-" and C++ name lookup rules are
toy compared to Maple's :-)]
That says nothing about "." itself :-)
--
Gabriel Dos Reis, g...@integrable-solutions.net
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Walter
> In article <qSu%a.159074$YN5.102812@sccrnsc01>, Walter
> <walter...@digitalmars.nospaam.com> writes
> >At first, using ~ seemed a bit odd. But it rapidly began to look natural,
> >and after using it for a while it's clear it was the right decision.
>
> What to use an operator that is pronounced 'complement' for
> concatenation?
It's pronounced 'complement' when used as a unary operatory, and
'concatenate' when used as a binary operator. Just like & is pronounced
'address of' when used as a unary operatory, and 'and' when used as a binary
operator.
If you're up for some whimsy, think of ~ as looking like a bit of rope
holding the two strings together <g>.
Walter
"Bo Persson" <bo...@telia.com> wrote in message
news:a6z%a.24462$dP1....@newsc.telia.net...
> > Here it is: www.digitalmars.com/d/cppstrings.html
> Interesting read. Here are my comments for some of the sections:
>
> Concatenation operator
>
> I agree that + and += are not the prefect choice of operators, because
> it is not immediately obvious what adding two streams really mean.
> Choosing ~ and ~= as replacements dosen't seem much of an improvement
> to me either.
>
> I haven't tried concatenating arrays much, so I can't say if
> generalizing the operator is a great improvment. Could be.
This will turn out to be one of those things where one will need to write
some real code with it, enough to get used to it. Then one will be in the
best position to judge. While many choices I've made in D remain
controversial even among the D community, the strong consensus there is they
like using ~ and ~= for concatenation. It was the right choice.
> Interoperability with C strings
>
> I can't say that I have ever missed the concatenation operator for
> string literal and string array, so it's nice but not convincing.
I can see it being handy in building strings for output. Some pieces will be
const char[], some will be literals, and some will be strings:
extern const char jobtitle[];
void foo(string name)
{ print("The job title is " ~ jobtitle ~ " and the employee name is "
~ name); }
You may not see this as much in C++ because of the way iostreams is
designed. Sometimes certain features are not missed because one gets so used
to using the workaround for it - in this case, the workaround would be
splitting up the concatenations so that each literal or char array is paired
with a string.
> Consistency
>
> If you stick with std::string, the inconsistency isn't there. I rarely
> count the length of literals.
I count them all the time, such as when building a hash lookup for a keyword
table. YMMV, of course.
> Checking for empty strings
>
> I have never liked the C style testing of conditions using cute !s in
> strange places. I usually write
>
> if (pointer == 0)
>
> for pointers, because that is clearer to me.
>
> Honestly! :-)
The ==0 is a perfectly reasonable style.
> Resizing Existing String
>
> :-) Believe me, I am not making this up, but I don't like properties
> either. Using resize() makes the operation very readable, IMO.
I believe you're not making it up! One thing you might want to consider, for
D there's only one name to learn, for reading and writing the size. With C++
strings, there are several related to the size: size(), length(), empty(),
and resize().
> Slicing a string
>
> std::string can also return a part of a string
>
> string s1 = "hello world";
> string s2 = s1.substr(6, 5);
>
> which is pretty close.
>
> I agree that s1[6..11] looks better though.
The slicing syntax turns out to be surprisingly powerful. One can use it,
for example, to transform a C char* into a bounds checked array:
void func(char *p)
{
char[] str = p[0 .. strlen(p)];
}
> Copying a string
>
> This example is incorrect, because std::string::copy requires a char*
> target, which std::string doesn't provide. It should be more like:
>
> string s1 = "hello world";
> string s2 = "goodbye ";
>
> s2.replace(8, 5, s1, 6, 5);
>
> Looks ugly though, and of course I had to look it up to see what index
> goes where.
Thanks for the correction, I'll fix the page.
> Taking a reference
>
> You can of course use the str[2] for std::string as well. Without the
> range check, but that was also intentional.
Can [] produce an lvalue one can take the address of? While it may be
implemented that way, is it guaranteed by the spec? My take on it is the
spec is not clear about that.
> I find the s[6..11] syntax appealing, but obviously have to read up
> more on the D semantics to learn exactly what it means.
It means the array consisting of the elements 6,7,8,9,10 of the s[] array.
> I now also
> understand how you have chosen to generalize the C char array (or
> maybe all array types) instead of making it a new type, as in C++.
> That is an interesting idea. Still doesn't convince me in the built-in
> vs library discussion though.
I think if you write some real code with it, you'll be convinced!
Thanks for posting your excellent comments.
-Walter
www.digitalmars.com/d/ The D Programming Language
llewelly
> In article <qSu%a.159074$YN5.102812@sccrnsc01>, Walter
> <walter...@digitalmars.nospaam.com> writes
>>At first, using ~ seemed a bit odd. But it rapidly began to look natural,
>>and after using it for a while it's clear it was the right decision.
>
> What to use an operator that is pronounced 'complement' for
> concatenation?
Most of the people I have worked with pronounce '~' as 'not'
(confliciting with '!', unfortunately ...). Of course this doesn't
change the argument against ~ as a string concatenation operator.
On the other hand, I wonder how much it really matters; '+' is equally
weird, and yet most people seem to pick up it up ok. I dislike
both '+' and '~', but I don't know of any operators that are
'obviously' string concatenation. Probably 'append' is the most
'obvious' spelling.
Shannon Barber
> Looking at other langauges, I think + and . are the most common string
> concatenation operators. I don't know of any langauge other than D
> which uses ~. I don't like + because it says the wrong thing. I
> dislike ~ for the same reason. Before learning perl, . did not say
> anything in particular to me - so I lean toward . I don't think
> there is an 'obvious' good operator name for string concatenation.
<< ?
or &= ?
Francis Glassborow
Reis <g...@integrable-solutions.net> writes
>llewelly <llewe...@xmission.dot.com> writes:
>
>[...]
>
>> I
>> dislike ~ for the same reason. Before learning perl, . did not say
>> anything in particular to me - so I lean toward . I don't think
>> there is an 'obvious' good operator name for string concatenation.
>
>The programming language of the Maple computer algebra system uses "."
>as string concatenation operator; but then, I never have been
>impressed by the design of that programming language ;-/
>[component selection is denoted by ":-" and C++ name lookup rules are
>toy compared to Maple's :-)]
>
>That says nothing about "." itself :-)
Maybe I do not meet normal people, but I cannot remember the last time
that a student of mine had a problem with the concept of using + for
concatenation. It follows normal English usage: 'add '...' to the end of
that.' Yes we can use append, but we normally do not. And any one who
wrote 'He appended "Have a good day."' instead of 'He added "Have a good
day."' would not be using colloquial English.
+ read as 'add' rather than as 'plus' or 'positive' works quite
naturally. None of the other alternative symbols have even a vague
mnemonic value.
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Francis Glassborow
<walter...@digitalmars.nospaam.com> writes
>This will turn out to be one of those things where one will need to write
>some real code with it, enough to get used to it. Then one will be in the
>best position to judge. While many choices I've made in D remain
>controversial even among the D community, the strong consensus there is they
>like using ~ and ~= for concatenation. It was the right choice.
On what basis do they make that choice. Try it on newcomers even
newcomers who can already program in other languages. Overloading
operator symbols with radically different meanings is probably unwise
design (and yes, I think that applies to C and C++ uses of such
operators as '&')
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Wil Evers
> Multiple inheritance, or D isn't OO.
OK, I'll bite. Why is multiple inheritance (as implemented in C++) not OO?
- Wil
--
Wil Evers, DOOSYS R&D BV, Utrecht, Holland
[Wil underscore Evers at doosys dot com]
Francis Glassborow
<walter...@digitalmars.nospaam.com> writes
>It's pronounced 'complement' when used as a unary operatory, and
>'concatenate' when used as a binary operator. Just like & is pronounced
>'address of' when used as a unary operatory, and 'and' when used as a binary
>operator.
No actually it is pronounced bitand. Because of the way that the
alternative spellings have been defined we have the odd feature that:
int main(){
int i(0);
int * i_ptr(bitand i);
}
Is fine :-) Fortunately I avoid pointers like the plague when writing
high level code so I very rarely use the address-of operator. However
finding this was OK was a bit of a shaker:
int main(){
int i(0);
int bitand i_ref(i);
}
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Randy Maddox
Far be it from me to speak up in defence of std::string, but even
without shims std::string does provide several flavors of insert and
replace that make the above comparison simply untrue. Since the C++
std::string class does indeed support copying anywhere in the string D
has no clear advantage here.
Randy.
Daniel Frey
> Most of the people I have worked with pronounce '~' as 'not'
> (confliciting with '!', unfortunately ...). Of course this doesn't
> change the argument against ~ as a string concatenation operator.
>
> On the other hand, I wonder how much it really matters; '+' is equally
> weird, and yet most people seem to pick up it up ok. I dislike
> both '+' and '~', but I don't know of any operators that are
> 'obviously' string concatenation. Probably 'append' is the most
> 'obvious' spelling.
I actually think that iff a language is going to change operators, it
should use ~ for xor (it's already a bitwise unary operator and using it
as a binary operator for bitwise exclucsive or seems consistant to me)
and than you can give ^ the meaning (and binding) or pow(). THAT would
be really helpful.
Strings can be concatenated with +, which, to me, seems natural. What
probably isn't natural is the conversion of anything-to-string for this
case, so 1 + "hallo" is not an example for or against having + for
string concatenation, it's just a good example why there shouldn't be an
implicit conversion from int to string. The only thing that might be a
useful extension in my eyes would be this:
- Parse an expression.
- If it fails and if it contains a string in source form ("Hello,
world!"), try to convert this to a std::string and parse again.
All other conversions seem too intrusive and dangerous to me, YMMV. And
I'm not even sure I'd like to have the automatic conversion anyway. It
would couple the language to the standard library and that doesn't sound
like a good idea in general. With more time, one might probably find a
better solution, but at least the direction above should be taken IMHO.
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: danie...@aixigo.de, web: http://www.aixigo.de
Sascha Dördelmann
> The "insult" is in stating that C++ doesn't have a built in string
> class. We all know it does.
I believe, some C++ libraries still don't use std::string because
their development started long time ago and therefore they use their
own string classes (wxString in wxWindows, to mention just one).
My conclusion would be, that using the term "built in" isn't *meant*
to be insulting but an attempt to use the most appropriate term to
describe it.
Just another opinion
Sascha
David Bradley
> If you're up for some whimsy, think of ~ as looking like a bit of rope
> holding the two strings together <g>.
Hmm, bitwise xor operator ^ would seem like another candidate for this.
Kind of like pulling two strings together. I guess I like it better
because I tought of it ;-)
Seriously, I guess my concern is that naive users are going to use
newString = aString + bString and not get what they want. And it's not
an unreasonable assumption since nearly every language I've encounter
natively supports this or allows it to be supported. IMO it's not a real
strong argument against it. Even naive users will learn pretty quick.
David Bradley
Bo Persson
"Walter" <walter...@digitalmars.nospaam.com> wrote
> Replies embedded...
>
> "Bo Persson" <bo...@telia.com> wrote in message
> news:a6z%a.24462$dP1....@newsc.telia.net...
>
will be
> const char[], some will be literals, and some will be strings:
>
> extern const char jobtitle[];
> void foo(string name)
> { print("The job title is " ~ jobtitle ~ " and the employee
name is "
> ~ name); }
>
> You may not see this as much in C++ because of the way iostreams is
> designed.
Yes, this solves a problem I don't have. Makes it a hard sell. :-)
>
> > Taking a reference
> >
> > You can of course use the str[2] for std::string as well. Without
the
> > range check, but that was also intentional.
>
> Can [] produce an lvalue one can take the address of? While it may
be
> implemented that way, is it guaranteed by the spec? My take on it is
the
> spec is not clear about that.
But operator[] returns a reference to a single char. You can save the
reference, and use it later.
You *can* take the address of the return value, but that is probably
of no use as the standard is a bit unclear about how long the address
remains valid.
On the other hand, why would you take the address, if you have a
reference? Also, if you actually save the reference, the address it
returns will remain valid as well.
>
> > I find the s[6..11] syntax appealing, but obviously have to read
up
> > more on the D semantics to learn exactly what it means.
>
> It means the array consisting of the elements 6,7,8,9,10 of the s[]
array.
I was a bit confused by your last example:
Filling a String
In C++, this is done with the replace() member function:
string str = "hello";
str.replace(1,2,2,'?'); // str is "h??llo"
In D, use the array slicing syntax in the natural manner:
char[] str = "hello";
str[1..2] = '?'; // str is "h??llo"
where I didn't understand how you got the "h??llo" result with two
question marks replacing the single 'e'. Looking at it again today,
and comparing it to the str.replace(), I now guess that the result
maybe should be "h??lo". Still slightly confused. :-)
Bo Persson
bo...@telia.com
llewelly
> Can [] produce an lvalue one can take the address of? While it may be
> implemented that way, is it guaranteed by the spec? My take on it is the
> spec is not clear about that.
It is so required. 21.3.4 requires the two versions of
string::operator[] return reference and const_reference
respectively. These are typedefs for the corresponding allocator
types. In 20.1.5 table 31 and 32 you can see they are required to
be T& and T const& .
llewelly
> llewelly <llewe...@xmission.dot.com> wrote in message
> [snip]
> > Looking at other langauges, I think + and . are the most common string
> > concatenation operators. I don't know of any langauge other than D
> > which uses ~. I don't like + because it says the wrong thing. I
> > dislike ~ for the same reason. Before learning perl, . did not say
> > anything in particular to me - so I lean toward . I don't think
> > there is an 'obvious' good operator name for string concatenation.
>
> << ?
> or &= ?
hm. With <sstream> << is vaguely akin to concatenation operator in
some sense, but I don't know of any other places these operators
are used for string concatenation.
I don't see how << or &= are any better (or any worse) than + or . .
Walter
> In article <z3P%a.40398$2x....@rwcrnsc52.ops.asp.att.net>, Walter
> <walter...@digitalmars.nospaam.com> writes
> >It's pronounced 'complement' when used as a unary operatory, and
> >'concatenate' when used as a binary operator. Just like & is pronounced
> >'address of' when used as a unary operatory, and 'and' when used as a
binary
> >operator.
>
> No actually it is pronounced bitand. Because of the way that the
> alternative spellings have been defined we have the odd feature that:
>
>
> int main(){
> int i(0);
> int * i_ptr(bitand i);
> }
>
> Is fine :-) Fortunately I avoid pointers like the plague when writing
> high level code so I very rarely use the address-of operator. However
> finding this was OK was a bit of a shaker:
>
> int main(){
> int i(0);
> int bitand i_ref(i);
> }
I'm afraid that syntax isn't going to make it into D!
Walter
"David Bradley" <DavidBrad...@cinci.rr.com> wrote in message
news:Ba60b.70259$hc.6...@fe3.columbus.rr.com...
> Seriously, I guess my concern is that naive users are going to use
> newString = aString + bString and not get what they want. And it's not
> an unreasonable assumption since nearly every language I've encounter
> natively supports this or allows it to be supported. IMO it's not a real
> strong argument against it. Even naive users will learn pretty quick.
The argument against using + for concantenation is the inconsistency of
using + for vector adds. Consider:
char[] s1, s2;
s1 = s1 + s2;
double[] d1, d2;
d1 = d1 + d2;
For the latter, one "naturally" thinks of it as a vector add, not a
concenate. For any sort of consistency with array operations, a different
operator for concatenate is necessary. Use ~ for concatenation a few times,
and you'll be surprised about how quickly it becomes natural. It really is
better and more consistent.
Aside from D's support for string literals, strings are not a unique type at
all. They are simply arrays of type, not different from any other array of
any other type. It's consistency worth fightin' for, worth dyin' for (well,
maybe not that!). Anyhow, arrays of UTF-8 are char[], arrays of UTF-16 are
wchar[], and arrays of UTF-32 are dchar[].
-Walter
www.digitalmars.com/d/
Walter
> [snip]
> > Can [] produce an lvalue one can take the address of? While it may be
> > implemented that way, is it guaranteed by the spec? My take on it is the
> > spec is not clear about that.
>
> It is so required. 21.3.4 requires the two versions of
> string::operator[] return reference and const_reference
> respectively. These are typedefs for the corresponding allocator
> types. In 20.1.5 table 31 and 32 you can see they are required to
> be T& and T const& .
Ok, you're right.
Walter
> In article <LOP%a.139816$It4....@rwcrnsc51.ops.asp.att.net>, Walter
> <walter...@digitalmars.nospaam.com> writes
> >This will turn out to be one of those things where one will need to write
> >some real code with it, enough to get used to it. Then one will be in the
> >best position to judge. While many choices I've made in D remain
> >controversial even among the D community, the strong consensus there is
they
> >like using ~ and ~= for concatenation. It was the right choice.
> On what basis do they make that choice. Try it on newcomers even
> newcomers who can already program in other languages. Overloading
> operator symbols with radically different meanings is probably unwise
> design (and yes, I think that applies to C and C++ uses of such
> operators as '&')
I think you'll find that most D programmers are experienced in a wide
variety of languages. Many have 2 or more decades of professional
programming experience. (D doesn't attract programming newbies because D
doesn't yet have any tutorials or books aimed at newbies.) Probably at least
40 different languages have been brought up to study various features of in
the D newsgroup (with the notable exception of Cobol <g>). Significant
requirements were that the new concatenation operator not step outside of
the C character set, that it look reasonably nice, and that it was visually
distinct. ~ was the standout champion. (! would have worked, but looked too
much like |.)
I'm a bit bemused by this discussion, considering the use of << and >> in
iostreams <g>. Or how about unary * and binary *? The various totally
inconsistent uses of : ? The (unnecessary) distinction between . and ->? The
addition of ::*? // comments? The digraphs? Dare I bring up trigraphs?
The point is, C and C++ have added unconventional use of symbols as needed,
and so these eventually became conventional. And so does D.
-Walter
www.digitalmars.com/d/ The D Programming Language
Walter
> Yes, this solves a problem I don't have. Makes it a hard sell. :-)
Maybe you are so used to the issue you just unconsciously code around it. I
know that happens to me a lot.
> where I didn't understand how you got the "h??llo" result with two
> question marks replacing the single 'e'. Looking at it again today,
> and comparing it to the str.replace(), I now guess that the result
> maybe should be "h??lo". Still slightly confused. :-)
It's a typo. Argh. Thanks for letting me know, I fixed it.
Jean-Marc Bourguet
> + read as 'add' rather than as 'plus' or 'positive' works quite
> naturally. None of the other alternative symbols have even a vague
> mnemonic value.
Ada use "&" (and it is valid for any arrays) which is quite nice, but
I'd never suggest to add yet another overload to this symbol in C++.
I my memory serve, SNOBOL used the famous space operator for
concatenation (so do C and C++ for constant string).
Yours,
--
Jean-Marc