Re: Compile Time String processing
On Feb 28, 11:38 pm, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
James Kanze wrote:
On Feb 27, 11:30 pm, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
D implementation floating point requirements are:
1) It be IEEE 754 compliant
Which means that it is largely irrelevant with regards to C++
for anything concerning floating point.
IEEE 754 is one way of doing floating point - there is nothing about it
that either aids or retards having floating point template args. Worst
case, you'd have to write an emulator, and as I wrote before, that isn't
a big problem.
My point is just that most of the problems I foresee for this in
C++ stem from the fact that C++ doesn't have a defined floating
point format; that it is implementation defined, and in
practice, does vary between implementations; IBM mainframes
don't even use a base 2 format. It makes defining the semantics
considerably more difficult.
That may or may not be a problem. We've lived for years with a
rather vague definition for even the most basic things, counting
on quality of implementation. But it's an issue that has to be
considered. And the fact that there are no such problems in a
language which imposes one particular floating point format
doesn't really help when the crux of the problem is dealing with
different formats.
[...]
A language's philosophy ultimately affects what it is. These are the
philosophies of the 3 languages as I interpret them:
C++:
[...]
6) Implementation difficulties are irrelevant
Not totally for the last.
I added that because in the early days of the C++ committee, that
philosophy was expressed to me several times by various committee
members. I predicted that trouble would result from it and it did - over
a decade of persistently incompatible, incomplete implementations, as
well as the shrinkage in the number of several C++ vendors.
It's the "irrelevant" that I was disagreeing with. It is
certain that C++ gives the issue less importance that C
traditionally has, and considers it better to add implementation
difficulties than to make life harder for the user. In theory,
however, it does require that the implementation be reasonably
possible; implementation difficulties aren't necessarily very
important, but they aren't totally irrelevant either.
(In practice, of course, it depends on who you talk to. And
when: the mood of the committee shifts in time, and in the last
couple of meetings, "is there an implementation?" has been a
regular question. On the other hand, in some earlier days, it's
likely that not enough attention was paid to the point.)
[...]
You might get the impression that D is like Java because D has garbage
collection and a similar OOP inheritance model, but that's about where
the similarity ends. D is nothing like Java (aside from their common C++
heritage).
The first two points are interesting. I use garbage collection
with C++, at least in new projects. And while I think that D
has had a positive influence in this regard, the movement to add
garbage collection started long before D showed up.
I know. I've found serious proposals to add gc to C++ going back to
1995. I wouldn't (and didn't) say that D inspired gc in C++, but it does
add to the pressure.
A little bit. It would have added to it a lot more if it were
as popular as Java:-). (It actually adds significantly to the
pressure in a negative sense. No modern language fails to
provide garbage collection; had D not had garbage collection, we
couldn't make that claim. So whatever it's influence in terms
of number of users, it definitly contributes to the sentiment of
a consensus.)
--
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! ]