Re: The D Programming Language
AJ wrote:
Seungbeom Kim wrote:
<snip>
But considering only the core language features would be a serious
mistake; it would be an unfair disadvantage to a language which has
preferred library solutions to core language solutions. For example,
under that criterion, you would say "C99 can handle variable-length
arrays but C++ can't; C99 can handle complex numbers but C++ can't."
It would also be unfair to consider library support as good as core
language support for (at least) two reasons:
1) Syntax.
2) Convenience.
That depends. Library support isn't as good as core support
when it isn't as good. The fact that it is library and not core
isn't a disadvantage per se---I'd say that almost the opposite
is true. But you do have to compare the level of support; there
are some things that simply cannot be supported in a library
alone.
Here's one example: Multi-threading and thread safety.
And this is one of them: you definitly have to specify at the
language level when it is safe to access objects, and when not.
For 1: In D, this is achieved in a super-clean and succinct manner:
Adding a synchronized keyword.
That, on the other hand, is a serious defect, at least if it is
done as in Java. It forces locking to obey scope rules.
In C++, one must add error-prone boilerplate for critical
sections (or mutexes, or locks) and in general the syntax is
verbose and a hassle.
I've never noticed this. My experience in Java is that the
synchronized keyword is a major problem; it's much easier to
write effective, correct code in C++ (using e.g. boost::mutex).
For 2: In D, synchronized is built-in. No need to download or
install anything else. No need to check additional
documentation on library usage.
I'm not sure I understand this point: if the functionality is
part of the standard library, there's also no need to download
or install anything else, and what's the difference between
having to check library documentation, and having to check
language documentation? The standard library IS part of the
language.
In C++, one must install and add a dependency to boost
(non-trivial) or pthreads (still non-trivial), or sacrifice
platform-independence and go Win32.
Pthreads is delivered pre-installed on all of my platformes:-).
But that's not the point. At present, there is no support for
threading in (official) C++. Library or language. That is a
weakness. A weakness currently being addressed by the
committee. The final solution will doubtlessly contain both
library elements and language elements---the library cannot
possibly define what sequence points mean in a multi-threaded
environment, and it would be completely silly to not use
functions and classes to create new threads, mutexes, etc.
(Note that Java uses the synchronized keyword principally
because it doesn't have destructors, and has no other way of
ensuring that a lock is released in case of an exception. One
weakness leads to another.)
On the other hand, D isn't available by default almost anywhere, whereas
C++ is, so that's one disadvantage.
A pretty serious one. For me, the absence of a compiler for
Sparc under Solaris means that it's not even worth my time to
find out more.
However, wasn't this the case with
C++ vs. C too, at some point?
I'm not sure. The earliest C++ compiler used C as an
intermediate language, so could easily be ported to any machine
on which C ran.
One other serious legacy flaw in D (inherited from C/C++) is that it
doesn't do away with undefined behavior. It's close, I think, but it's
unfortunate that the holes aren't closed entirely.
No language manages to completely do away with undefined
behavior. Although C++ could surely do better in this regard;
there's a lot of unnecessary undefined behavior.
However, what is important is whether a programmer can do his/her task
efficiently with the language and the associated tools, not whether it
is done by the core language or by the standard library or by a
third-party library. Whether a language facilitates good libraries or it
hinders good development tools, much of the credit/blame is to the language.
'Efficiently' is the key. Adding certain things to the core language can
improve efficiency by an order of magnitude. "Can be done at all" isn't
the same as "can be done simply and easily." :)
Formally, if it is part of the standard library, the compiler
can know about it, and do whatever is necessary. This is often
the case for standard library functions (like memcpy) in C. To
date, it's not become the case for anything in C++, at least to
my knowledge, although the standard certainly allows it. I
think, however, that part of the goal is to design things so
that the compiler can do the job well, not just for standard
components, but for any user defined class.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]