Compile Time String processing
wes
I'm trying to find out if I can use C++ templates to hash a string at
compile time. Here's a first attempt that doesn't do it at compile
time but at run time that simply calculates string length. This is
just a proof of concept that I can iterate over the characters in a
string:
template <class T>
class StringLength
{
public:
static int eval(T* a)
{ return ((*a) == '\0') ? 0 :
(StringLength<T>::eval(a+1) + 1); }
};
template <class T>
inline int stringlength(T* a) { return StringLength<T>::eval(a); }
usage:
stringlength<>("four five six");
Right now I'm trying to figure out is if string processing is even
possible at compile time using templates. So far after much searching
I've only found numeric operations in the metaprogramming examples and
no string examples and I'm wondering if this is for a reason i.e. that
C++ can't process strings in this way. Any ideas?
thanks
wes
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Walter Bright
> Right now I'm trying to figure out is if string processing is even
> possible at compile time using templates. So far after much searching
> I've only found numeric operations in the metaprogramming examples and
> no string examples and I'm wondering if this is for a reason i.e. that
> C++ can't process strings in this way. Any ideas?
C++ can't do it because string literals cannot be passed as template
arguments (see C++98 14.3.2). However, since string literals can be
passed as template arguments in the D programming language, one could
write a string hashing template as:
template hash(char [] s, uint sofar=0)
{
static if (s.length == 0)
const hash = sofar;
else
const hash = hash!(s[1 .. length], sofar * 11 + s[0]);
}
uint foo()
{
return hash!("hello world");
}
Walter Bright
www.digitalmars.com
C, C++, D programming language compilers
James Kanze
> wes wrote:
> > Right now I'm trying to figure out is if string processing is even
> > possible at compile time using templates. So far after much searching
> > I've only found numeric operations in the metaprogramming examples and
> > no string examples and I'm wondering if this is for a reason i.e. that
> > C++ can't process strings in this way. Any ideas?
> C++ can't do it because string literals cannot be passed as template
> arguments (see C++98 14.3.2).
That's not the real problem; it's easily worked around. The
real problem is that you can only instantiate a template with
integral constant expressions, you can't use a pointer in an
integral constant expression, and any attempt to index into an
array will involve an intermediate pointer.
--
James Kanze (GABI Software) email:james...@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
s5n
wrote:
> C++ can't do it because string literals cannot be passed as template
> arguments (see C++98 14.3.2).
Curiously, though, you can pass (char const * &) arguments to
templates. One of my projects uses this trick (introduced by a co-
developer) to bind class names to classes. Here's an example of one of
the types:
template <const char *& Reference>
class StringReference
{
public:
static const char* ref()
{
return Reference;
}
};
But that still doesn't help one iterate over chars at compile-time, as
far as i can see.
Walter Bright
> On Feb 23, 10:37 am, Walter Bright <wal...@digitalmars-nospamm.com>
> wrote:
>> C++ can't do it because string literals cannot be passed as template
>> arguments (see C++98 14.3.2).
>
> Curiously, though, you can pass (char const * &) arguments to
> templates. One of my projects uses this trick (introduced by a co-
> developer) to bind class names to classes. Here's an example of one of
> the types:
>
> template <const char *& Reference>
> class StringReference
> {
> public:
> static const char* ref()
> {
> return Reference;
> }
> };
Yes, because you can bind the addresses of global symbols (not just
const string symbols).
> But that still doesn't help one iterate over chars at compile-time, as
> far as i can see.
Right. Can't use templates to do computations on floating point values,
either (but you can in the D programming language).
Walter Bright
> Walter Bright wrote:
>> wes wrote:
>>> Right now I'm trying to figure out is if string processing is even
>>> possible at compile time using templates. So far after much searching
>>> I've only found numeric operations in the metaprogramming examples and
>>> no string examples and I'm wondering if this is for a reason i.e. that
>>> C++ can't process strings in this way. Any ideas?
>
>> C++ can't do it because string literals cannot be passed as template
>> arguments (see C++98 14.3.2).
>
> That's not the real problem; it's easily worked around. The
> real problem is that you can only instantiate a template with
> integral constant expressions,
Isn't that saying the same thing?
> you can't use a pointer in an
> integral constant expression, and any attempt to index into an
> array will involve an intermediate pointer.
If C++ did allow passing string literals as template arguments, then
it's only a short step to allow constant folding on:
"foo"[1]
It isn't necessary to support pointer arithmetic. The D programming
language constant folder can evaluate expressions of the form:
a[i]
where 'a' is a string literal, array literal, const variable that
resolves to such, or foldable expression, and i is an integer literal,
const variable, or foldable expression. So, we can fold:
static const char Foo[] = "foo";
const int i = 1;
const char c = Foo[i];
without needing any pointers; the hash template example does not involve
pointers.
Trying to do this in C++ would perhaps get into trouble with the problem
that core arrays often lose their array dimension information, and
there's no core array slicing operation. I don't know how easily these
would be worked around; I haven't attempted to do this in a C++ compiler.
James Kanze
> James Kanze wrote:
> > Walter Bright wrote:
> >> wes wrote:
> >>> Right now I'm trying to figure out is if string processing is even
> >>> possible at compile time using templates. So far after much searching
> >>> I've only found numeric operations in the metaprogramming examples and
> >>> no string examples and I'm wondering if this is for a reason i.e. that
> >>> C++ can't process strings in this way. Any ideas?
> >> C++ can't do it because string literals cannot be passed as template
> >> arguments (see C++98 14.3.2).
> > That's not the real problem; it's easily worked around. The
> > real problem is that you can only instantiate a template with
> > integral constant expressions,
> Isn't that saying the same thing?
I wouldn't be if I'd have formulated it correctly. The only
arithmetic type you can use to instantiate a template are
integral types, and their arguments must be integral constant
expressions. There's no problem with instantiating a template
with a string, however:
template< char const* string > class T {} ;
namespace {
char const toto[] = "toto" ;
}
T< toto > instance ;
You can't use string literals, because they don't have
linkage. But the real problem, with regards to what was being
asked, is that you cannot access the elements of the array,
because that involves pointers and pointer arithmetic, which
can't be used in integral constant expressions.
> > you can't use a pointer in an
> > integral constant expression, and any attempt to index into an
> > array will involve an intermediate pointer.
> If C++ did allow passing string literals as template arguments, then
> it's only a short step to allow constant folding on:
> "foo"[1]
> It isn't necessary to support pointer arithmetic.
In C++, the above statement involves pointer arithmetic. And is
not allowed in an integral constant expression.
> The D programming
> language
Is not the subject here. We've already heard how it can do
everything. (Admittedly, in this case, it's pretty easy to do
better than C/C++. C style arrays are broken, and C++ doesn't
have anything at the language level which replaces them.)
> constant folder can evaluate expressions of the form:
> a[i]
> where 'a' is a string literal,
A C++ compiler can presumably do this as well. The problem
isn't what the compiler can or cannot do. Even if the compiler
can know what the results are, it's not an integral constant
expression, and the compiler is required to complain if you try
to use it to instantiate a template.
--
James Kanze (Gabi Software) email: james...@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
Walter Bright
> I wouldn't be if I'd have formulated it correctly. The only
> arithmetic type you can use to instantiate a template are
> integral types, and their arguments must be integral constant
> expressions. There's no problem with instantiating a template
> with a string, however:
>
> template< char const* string > class T {} ;
> namespace {
> char const toto[] = "toto" ;
> }
>
> T< toto > instance ;
That isn't instantiating it with a string, it's instantiating it with a
global symbol.
> You can't use string literals, because they don't have
> linkage.
Linkage isn't the problem, since integral literals don't have linkage,
either, yet they work. The problem is that the C++ standard disallows
string literals (and floating literals) as template arguments. There
might be good reasons for those restrictions, but I don't know what they
are, and none have shown up with the regular use of them in D.
> But the real problem, with regards to what was being
> asked, is that you cannot access the elements of the array,
> because that involves pointers and pointer arithmetic, which
> can't be used in integral constant expressions.
Right, but there's no technical reason why it cannot work, it's just
that the C++ Standard doesn't allow it.
>> If C++ did allow passing string literals as template arguments, then
>> it's only a short step to allow constant folding on:
>
>> "foo"[1]
>
>> It isn't necessary to support pointer arithmetic.
> In C++, the above statement involves pointer arithmetic.
Pedantically, yes, but practically? No. It's trivial for a constant
folder to reduce the above to 'o' without needing any compile time
pointer arithmetic. Note that it cannot be influenced by overloading or
other monkey wrenches. There is no doubt it is as equivalent to 'o' as
2+2 is equivalent to 4.
> And is
> not allowed in an integral constant expression.
>
>> The D programming language
>
> Is not the subject here.
It is when the topic is why can't C++ handle string and floating point
literals as template arguments? A lot of these restrictions are taken
for granted, and D illustrates that perhaps these restrictions are both
unnecessary and constricting. A number of D features seem to have wound
up as proposals for C++0x (such as contract programming, utf strings,
modules, etc.).
> We've already heard how it can do
> everything. (Admittedly, in this case, it's pretty easy to do
> better than C/C++. C style arrays are broken, and C++ doesn't
> have anything at the language level which replaces them.)
>
>> constant folder can evaluate expressions of the form:
>
>> a[i]
>
>> where 'a' is a string literal,
>
> A C++ compiler can presumably do this as well. The problem
> isn't what the compiler can or cannot do.
> Even if the compiler
> can know what the results are, it's not an integral constant
> expression, and the compiler is required to complain if you try
> to use it to instantiate a template.
Yes, it's a definitional problem, not a technical one.
James Kanze
> James Kanze wrote:
> > I wouldn't be if I'd have formulated it correctly. The only
> > arithmetic type you can use to instantiate a template are
> > integral types, and their arguments must be integral constant
> > expressions. There's no problem with instantiating a template
> > with a string, however:
> > template< char const* string > class T {} ;
> > namespace {
> > char const toto[] = "toto" ;
> > }
> > T< toto > instance ;
> That isn't instantiating it with a string, it's instantiating
> it with a global symbol.
A global symbol which refers to a string. It's a simple work
around.
I don't know what definition of string you're using, but the
only one I can see that would apply here is an array of char
which contains a '\0' terminated sequence of characters. toto
is very much a string, even if it isn't a string literal.
> > You can't use string literals, because they don't have
> > linkage.
> Linkage isn't the problem, since integral literals don't have linkage,
> either, yet they work.
Linkage *is* the problem, because the standard says that it is.
Arrays are converted to pointers, and the standard says that
pointers must have external linkage. The standard doesn't
require integral constants to have external linkage.
> The problem is that the C++ standard disallows
> string literals (and floating literals) as template arguments.
Indirectly, in different ways. The C++ standard does not allow
template parameters to have a floating point type, period.
Given that, literals or not doesn't come into question. It does
allow templates to have a type derived from the string type
(char const*); the problem with string literals is that they
don't have linkage, and the standard requires pointer type
constants to have external linkage.
> There
> might be good reasons for those restrictions, but I don't know what they
> are, and none have shown up with the regular use of them in D.
D is a different language. Given that it isn't compatible with
C, I would certainly hope that you didn't break built in arrays
completely, as they are in C. C++ is compatible with C, and is
stuck with the problems C created.
At least, that's part of the problem. I think that there is
some discussion of allowing instantiating templates over
addresses, types, etc. which don't have external linkage. But
it does create some problems with the linkage model. (In the
case of a string literal, it causes a lot of problems. Are
T<"abc"> and T<"abc"> the same type? Those are two different
string literals, and the standard says that it is unspecified
whether they have the same address or not. And of course, the
template is really being instantiated over the address.)
> > But the real problem, with regards to what was being
> > asked, is that you cannot access the elements of the array,
> > because that involves pointers and pointer arithmetic, which
> > can't be used in integral constant expressions.
> Right, but there's no technical reason why it cannot work, it's just
> that the C++ Standard doesn't allow it.
And the C++ standard doesn't allow it, because it would involve
pointer arithmetic in C++, because of the way C defined array
accesses. This would still be true if the standard allowed
instantiation over a string literal.
> >> If C++ did allow passing string literals as template arguments, then
> >> it's only a short step to allow constant folding on:
> >> "foo"[1]
> >> It isn't necessary to support pointer arithmetic.
> > In C++, the above statement involves pointer arithmetic.
> Pedantically, yes, but practically? No. It's trivial for a constant
> folder to reduce the above to 'o' without needing any compile time
> pointer arithmetic. Note that it cannot be influenced by overloading or
> other monkey wrenches. There is no doubt it is as equivalent to 'o' as
> 2+2 is equivalent to 4.
> > And is
> > not allowed in an integral constant expression.
> >> The D programming language
> > Is not the subject here.
> It is when the topic is why can't C++ handle string and floating point
> literals as template arguments?
No it's not. Who cares about D? It isn't even available on
most of the platforms which interest me. No one doubts, I
think, that starting from scratch, you can avoid a number of the
problems which C++ has due to history and C compatibility. (Of
course, starting from scratch has other problems. Like
acceptance, and getting compilers available on a lot of
different platforms.)
> A lot of these restrictions are taken
> for granted,
A lot of these restrictions are accepted as a necessary evil
because C++ derives from C; they're the price we pay for the
advantages of deriving from C. Those advantages may be more
political or commercial than technical.
> and D illustrates that perhaps these restrictions are both
> unnecessary and constricting. A number of D features seem to
> have wound up as proposals for C++0x (such as contract
> programming, utf strings, modules, etc.).
Contract programming was around a long time before D, and I
haven't heard any references to D involving it. (This is the
first I hear that D supports contract programming. The idea, if
I'm not mistaken, goes back to Eiffel). Ditto UTF-8 strings
(for which C already has some support). And the work on modules
goes back to and in based on Modula-2. I don't doubt that D
uses many of the same sources that some of the proposals in
C++0x do, and probably, some of the authors have looked at it as
a proof of concept, or as an example of how to adopt them to a
C-like syntax, but the proposals would doubtlessly be there with
or without D. D isn't the only language around other than C++,
you know.
> > We've already heard how it can do
> > everything. (Admittedly, in this case, it's pretty easy to do
> > better than C/C++. C style arrays are broken, and C++ doesn't
> > have anything at the language level which replaces them.)
> >> constant folder can evaluate expressions of the form:
> >> a[i]
> >> where 'a' is a string literal,
> > A C++ compiler can presumably do this as well. The problem
> > isn't what the compiler can or cannot do.
> > Even if the compiler
> > can know what the results are, it's not an integral constant
> > expression, and the compiler is required to complain if you try
> > to use it to instantiate a template.
> Yes, it's a definitional problem, not a technical one.
The problem is keeping the definitions coherent with other
definitions. A much easier problem if you can change the other
definitions as well.
--
James Kanze (Gabi Software) email: james...@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
Lance Diduck
wrote:
> Linkage isn't the problem, since integral literals don't have linkage,
> either, yet they work. The problem is that the C++ standard disallows
> string literals (and floating literals) as template arguments. There
> might be good reasons for those restrictions, but I don't know what they
> are, and none have shown up with the regular use of them in D.
I'm not sure if a proposal to allow FPN's and string literals is
before the Evolution Committee or not.
What I am not clear on, if FPN's were allows as template non-type
paramters, and by extension in compile time expressions, how would
something like this work:
template <float F> struct foo {enum{val=0}; };
template <>struct foo<3.3333333333333>{enum{val=1}; };
template <>struct foo<3+1.0/3>{enum{val=2};};
typedef foo<10.0/3> bar;
It seems to me that the value of bar::val is indeterminate. Indeed,
since by definition any FP arithmetic is imprecise, it would follow
that any template matching done using FP is also imprecise. This would
make it hard to port a program.
Or is this not correct and I am missing something?
To make a template string hasher that works with current standard C++
technology, the original poster may consider this:
template <char _1,char _2=0,char _3=0,char _4=0,char _5=0,char
_6=0...> //up to about 10 params
struct fold{
static const size_t hval=_1^_2^_3///etc whatever ever you are
going to do
};
Cumbersome, but works fine for small strings.
Lance
Mathias Gaunard
wrote:
> Right. Can't use templates to do computations on floating point values,
> either (but you can in the D programming language).
I think C++ doesn't allow it simply because it is not trivial to do so
portably, given differences in precision of various platforms etc.
For example, GCC will only be able to do evalute floating point
constant expressions from version 4.3.
Walter Bright
> What I am not clear on, if FPN's were allows as template non-type
> paramters, and by extension in compile time expressions, how would
> something like this work:
> template <float F> struct foo {enum{val=0}; };
> template <>struct foo<3.3333333333333>{enum{val=1}; };
> template <>struct foo<3+1.0/3>{enum{val=2};};
> typedef foo<10.0/3> bar;
> It seems to me that the value of bar::val is indeterminate.
It's not any less portable than:
if (x == 3.3333333333) ...
but that's allowed.
> Indeed,
> since by definition any FP arithmetic is imprecise, it would follow
> that any template matching done using FP is also imprecise.
> This would make it hard to port a program.
> Or is this not correct and I am missing something?
I can't see a point to the specializations above. But I can see a point
to having floating point values as arguments - think of a template that
can compute a square root at compile time, for example. Don Clugston has
implemented a whole bestiary of compile time math functions using these
D programming techniques.
> To make a template string hasher that works with current standard C++
> technology, the original poster may consider this:
>
> template <char _1,char _2=0,char _3=0,char _4=0,char _5=0,char
> _6=0...> //up to about 10 params
> struct fold{
> static const size_t hval=_1^_2^_3///etc whatever ever you are
> going to do
> };
>
> Cumbersome, but works fine for small strings.
Sorry, but that's awful!
Walter Bright
> On Feb 24, 2:21 am, Walter Bright <wal...@digitalmars-nospamm.com>
> wrote:
>
>> Right. Can't use templates to do computations on floating point values,
>> either (but you can in the D programming language).
>
> I think C++ doesn't allow it simply because it is not trivial to do so
> portably, given differences in precision of various platforms etc.
> For example, GCC will only be able to do evalute floating point
> constant expressions from version 4.3.
Why should a template binary (or the floating point part of a mangled
name) be portable between platforms?
Walter Bright
> D is a different language. Given that it isn't compatible with
> C,
D is compatible with the C abi. C++ isn't source compatible with C,
either, but of course it is closer than D is. You can write "C" code in
D to the point where one would have to look at it for the 3rd time
before you might notice that it isn't C. I've "translated" much C code
to D by doing little more than rename the file, fix the preprocessor
stuff, and do a few minutes of editing.
> I would certainly hope that you didn't break built in arrays
> completely, as they are in C. C++ is compatible with C, and is
> stuck with the problems C created.
This isn't completely true. One can fix C arrays without breaking them,
and D does so.
> (In the
> case of a string literal, it causes a lot of problems. Are
> T<"abc"> and T<"abc"> the same type?
Yes.
> Those are two different
> string literals, and the standard says that it is unspecified
> whether they have the same address or not. And of course, the
> template is really being instantiated over the address.)
Not if the standard is fixed to say that the instantiation is done based
on the contents of the string literal, not its address. This is how D
does it.
> And the C++ standard doesn't allow it, because it would involve
> pointer arithmetic in C++, because of the way C defined array
> accesses. This would still be true if the standard allowed
> instantiation over a string literal.
I could try again to convince you, but I'll just say that D does just
that, without breaking C arrays, and it works. It doesn't involve hacks
or kludges, either. (It does require that the compiler not be in too big
a hurry to replace string literals with pointers, but that's an
implementation issue. The semantic pass sees "foo"[1] and has everything
it needs to replace it with 'o'.)
Note also that if you wished to do C style arrays, they'll work just
fine, too.
I should add, though, that the implicit conversion of C arrays to
pointers was deliberately severed recently, due to popular request. The
only time this was really necessary was when interfacing with C
functions, and pretty much everyone felt that an explicit cast for that
was better, i.e.:
extern (C) void foo(char*); // C function
static char string[6] = "hello";
foo(string); // error, can't implicitly convert char[6] to char*
foo(cast(char*)string); // ok, using explicit cast
foo(string.ptr); // ok, using "pointer" property of array
>> It is when the topic is why can't C++ handle string and floating point
>> literals as template arguments?
> No it's not. Who cares about D?
Even if you have no intention of ever using D, which is fine, it serves
as an illustration of how these seemingly impossible things (like fixing
C arrays without breaking C arrays) can be done.
>> and D illustrates that perhaps these restrictions are both
>> unnecessary and constricting. A number of D features seem to
>> have wound up as proposals for C++0x (such as contract
>> programming, utf strings, modules, etc.).
>
> Contract programming was around a long time before D, and I
> haven't heard any references to D involving it. (This is the
> first I hear that D supports contract programming. The idea, if
> I'm not mistaken, goes back to Eiffel).
You're right that D's contract programming comes from Eiffel. Thorsten
Ottosen was the one that made the proposal for C++, and his original
draft proposal cites both Eiffel's and D's implementation of it.
> Ditto UTF-8 strings (for which C already has some support).
The C support for it is pretty much useless, hence the C++ proposal
which pretty much starts over with a new basic type. The C proposal to
add utf-8 support is dated 11-2003
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1040.pdf,
and Lawrence Crowl's proposal to add them to C++ goes back to 2005, and
probably further. I've had no discussions with Lawrence about it. But
D's had it since 2001, years before C or C++ proposals.
> And the work on modules goes back to and in based on Modula-2.
Daveed Vandevoorde's proposal for adding modules to C++ came about some
time after I'd had a newsgroup exchange with him over how D modules fix
some difficult problems in Feb, 2004. If he was working on the module
proposal beforehand, then I don't know about it. Search google groups
for "Vandevoorde Walter" for the exchange.
> I don't doubt that D
> uses many of the same sources that some of the proposals in
> C++0x do, and probably, some of the authors have looked at it as
> a proof of concept, or as an example of how to adopt them to a
> C-like syntax,
I don't think it's a coincidence that contracts and modules were
proposed for C++ soon after the authors of those proposals discussed the
ideas with me on how they worked in D. Obviously, they thought that the
D programming language has value in looking at new features for C++,
hence it is on-topic here.
> but the proposals would doubtlessly be there with
> or without D.
I don't think "doubtlessly" can be substantiated for modules and
contracts, given the historical information presented here.
> D isn't the only language around other than C++, you know.
D is far closer to C++ than any other language with those features, so
it is the most valuable when looking for relevant experience with them.
D is the only other language with templates, too. (Java and C# generics
are not true template systems.)
James Kanze
wrote:
> Lance Diduck wrote:
> > What I am not clear on, if FPN's were allows as template non-type
> > paramters, and by extension in compile time expressions, how would
> > something like this work:
> > template <float F> struct foo {enum{val=0}; };
> > template <>struct foo<3.3333333333333>{enum{val=1}; };
> > template <>struct foo<3+1.0/3>{enum{val=2};};
> > typedef foo<10.0/3> bar;
> > It seems to me that the value of bar::val is indeterminate.
> It's not any less portable than:
> if (x == 3.3333333333) ...
> but that's allowed.
The question is whether foo<3.3333333333> and foo<3.3333333332>
are the same type or not. When templates were being adopted
back in the 1990's, the committee didn't have any real answer to
this: is it acceptable to leave it unspecified, or must it be
implementation defined, or even must it be specified by the
standard. In the end, they decided not to allow it, rather than
risk doing the wrong thing. When defining a standard, this is
more or less what you have to do. It's easy to add a feature,
once you know what it should do, but it's almost impossible to
remove one, or even change it, if you make the wrong choice.
(The way floating point is specified in C/C++, something like
the above could even depend on the level of optimization. And
yes, this affects the if as well---I've had examples of code
compiled with g++ where the results of something like the if
changed depending on the optimization level I used.)
--
James Kanze (GABI Software) email:james...@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
James Kanze
wrote:
> Mathias Gaunard wrote:
> > On Feb 24, 2:21 am, Walter Bright <wal...@digitalmars-nospamm.com>
> > wrote:
> >> Right. Can't use templates to do computations on floating point values,
> >> either (but you can in the D programming language).
> > I think C++ doesn't allow it simply because it is not trivial to do so
> > portably, given differences in precision of various platforms etc.
> > For example, GCC will only be able to do evalute floating point
> > constant expressions from version 4.3.
> Why should a template binary (or the floating point part of a mangled
> name) be portable between platforms?
Why should anything be portable?
The problem here has nothing to do with mangled names or
whatever. The question is whether two different instantiations
of a template are the same type or not. The standard requires,
for example, that given "template<int i> struct foo{};",
"foo<1>" and "foo<2-1>" have the same type. Defining when two
such instantiations have the same type is much, much harder for
floating point. Maybe it's acceptable to just say
"unspecified". Maybe not. Maybe we know the answer today. We
certainly didn't back in the 1990's, however, when the standard
was being formulated.
--
James Kanze (GABI Software) email:james...@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
--
Lance Diduck
> Lance Diduck wrote:
> > What I am not clear on, if FPN's were allows as template non-type
> > paramters, and by extension in compile time expressions, how would
> > something like this work:
> > template <float F> struct foo {enum{val=0}; };
> > template <>struct foo<3.3333333333333>{enum{val=1}; };
> > template <>struct foo<3+1.0/3>{enum{val=2};};
> > typedef foo<10.0/3> bar;
> > It seems to me that the value of bar::val is indeterminate.
>
> It's not any less portable than:
> if (x == 3.3333333333) ...
> but that's allowed.
the best way to equality compare FPN's -- that is defined by the
application. But we all can agree on "bit compare of memory " as the
worst way.
I'm glad D allows FPNs for template parameters. Shucks, I'm sure XSLT
allows it for ITS template matching rules too. XLST allows regular
expressions to match template parameters. Now THAT is cool!!!!
But aren't we discussing what C++ could do?
The army of C++ compilers I use do not allow such usages. They can't.
If C++ did eventually allow it, usages in the example will have to be
accounted for, regardless of whether we can imagine how it would be
used at the moment.
> I can't see a point to the specializations above. But I can see a point
> to having floating point values as arguments - think of a template that
> can compute a square root at compile time, for example. Don Clugston has
> implemented a whole bestiary of compile time math functions using these
> D programming techniques.
computes square roots. Anyone who has taken a Numerical Methods class
can implement a method, using only precise numbers, to make imprecise
calculations. Indeed, the FP math unit in your computer does just
that.
Perhaps it is easier in D than in C++ to perform computations before
machine code is generated and linked -- which is really what we mean
by "compile time computation." There are any number of front ends I
can imagine that will perform computations for me, and generate
compilable output, for any language. But the real point is "how do I
do this in C++?" is it not?
What would I use such template specializations for? I don't know off
the top of my head-- I've used template specializations for validating
use of shared memory segments, for making FORTRAN common areas
typesafe, specialized error handling routines, and so forth -- way
beyond what presumably Dr Stroustrup imagined when he first described
templates in the ARM, which reportedly were just a nifty way to make
containers.
>
> > To make a template string hasher that works with current standard C++
> > technology, the original poster may consider this:
>
> > template <char _1,char _2=0,char _3=0,char _4=0,char _5=0,char
> > _6=0...> //up to about 10 params
> > struct fold{
> > static const size_t hval=_1^_2^_3///etc whatever ever you are
> > going to do
> > };
>
> > Cumbersome, but works fine for small strings.
>
> Sorry, but that's awful!
Walter Bright
>> name) be portable between platforms?
> Why should anything be portable?
Binaries aren't portable between platforms, anyway. I don't know any
example of portable C++ binaries between Windows x86 and Linux x86 -
even a trivial one. The C++ standard doesn't specify anything beyond
source portability. So, such is not a valid reason for disallowing
floating point template arguments.
> The problem here has nothing to do with mangled names or
> whatever. The question is whether two different instantiations
> of a template are the same type or not. The standard requires,
> for example, that given "template<int i> struct foo{};",
> "foo<1>" and "foo<2-1>" have the same type. Defining when two
> such instantiations have the same type is much, much harder for
> floating point.
Just specify they must match exactly to the full precision of the type,
like the == operator does for floats (and the standard has no problem
defining ==).
> Maybe it's acceptable to just say
> "unspecified". Maybe not. Maybe we know the answer today. We
> certainly didn't back in the 1990's, however, when the standard
> was being formulated.
As the usage of floating template arguments in the D programming
language illustrates, it simply isn't a problem. Array literals also
work as template arguments, and we plan to add in the future associative
array and struct literals. C++ established a bridgehead on what could be
done with templates, and D is busy pouring the whole army through it <g>.
For a small example of what can be done, Don Clugston wrote a template
metaprogram to execute "99 bottles of beer" entirely at compile time:
http://www.99-bottles-of-beer.net/language-d-1212.html?PHPSESSID=5195781cd0174b11028257941fb775f4
On a more practical note, Don Clugston and Eric Anderton have written
string templates that will compile regular expressions at compile time.
(It's done in C++ using expression templates rather than string templates.)
Walter Bright
> On Feb 26, 9:37 am, Walter Bright <wal...@digitalmars-nospamm.com>
> wrote:
>> Lance Diduck wrote:
>>> What I am not clear on, if FPN's were allows as template non-type
>>> paramters, and by extension in compile time expressions, how would
>>> something like this work:
>>> template <float F> struct foo {enum{val=0}; };
>>> template <>struct foo<3.3333333333333>{enum{val=1}; };
>>> template <>struct foo<3+1.0/3>{enum{val=2};};
>>> typedef foo<10.0/3> bar;
>>> It seems to me that the value of bar::val is indeterminate.
>
>> It's not any less portable than:
>> if (x == 3.3333333333) ...
>> but that's allowed.
>
> The question is whether foo<3.3333333333> and foo<3.3333333332>
> are the same type or not. When templates were being adopted
> back in the 1990's, the committee didn't have any real answer to
> this: is it acceptable to leave it unspecified, or must it be
> implementation defined, or even must it be specified by the
> standard. In the end, they decided not to allow it, rather than
> risk doing the wrong thing.
Now we have implementation experience with floating arguments; they
work, are used, and are useful. None of these problems have
materialized, any more than routine issues with:
if (a == b)
> When defining a standard, this is
> more or less what you have to do. It's easy to add a feature,
> once you know what it should do, but it's almost impossible to
> remove one, or even change it, if you make the wrong choice.
Should have thought of that with exported templates <g>. I think the
lesson is not to avoid new things, but to try implementing them before
welding them in to the standard. This makes the D programming language,
which is very close to C++, on topic and relevant as working examples of
some proposed new features.
> (The way floating point is specified in C/C++, something like
> the above could even depend on the level of optimization. And
> yes, this affects the if as well---I've had examples of code
> compiled with g++ where the results of something like the if
> changed depending on the optimization level I used.)
People who deal with floating point code quickly learn to come to terms
with the a==b problem, and are able to transfer that knowledge to
working with floating point template arguments.
Daveed
wrote:
[...]
> Daveed Vandevoorde's proposal for adding modules to C++ came about some
> time after I'd had a newsgroup exchange with him over how D modules fix
> some difficult problems in Feb, 2004. If he was working on the module
> proposal beforehand, then I don't know about it. Search google groups
> for "Vandevoorde Walter" for the exchange.
If so, the timing was coincidental. My playing with modules came
about
because I was trying to figure out how to package "metacode" (another
proposal of mine) without adding more weight to header files.
At some meeting (Redmond 2004, I think) something came up for which my
Modules ideas at the time were a good fit, and that's when it turned
into a presentation and then later an actual proposal.
James is right that I was at first guided by how Modula-2 works
(besides
Java -- whose model I did't like -- that was what I was most familiar
with). Since then, things have changed and the proposed model is
"somewhere in between" Modula-2 and Java.
That said, I've occasionally argued that the existence and
effectiveness
of modules in D (which is closer to C++ conceptually than Java or
Modula-2) makes it likely that C++ modules could be similarly feasible
and effective.
Daveed
Walter Bright
> Any better suggestion that works in *standard* C++?
When I've been faced with such problems, I've:
1) used a different approach entirely
2) written a separate program that generates C++ source code which is
then #include'd.
3) used a different language
Mathias Gaunard
wrote:
> The C++ standard doesn't specify anything beyond
> source portability. So, such is not a valid reason for disallowing
> floating point template arguments.
The problem I believe is that you cannot do floating point operations
at compile-time without mimicking the whole FPU of the target
platform, that has many liberties in how it can behave.
Walter Bright
> On Feb 26, 3:39 am, Walter Bright <wal...@digitalmars-nospamm.com>
> wrote:
> [...]
>> Daveed Vandevoorde's proposal for adding modules to C++ came about some
>> time after I'd had a newsgroup exchange with him over how D modules fix
>> some difficult problems in Feb, 2004. If he was working on the module
>> proposal beforehand, then I don't know about it. Search google groups
>> for "Vandevoorde Walter" for the exchange.
>
> If so, the timing was coincidental. My playing with modules came
> about
> because I was trying to figure out how to package "metacode" (another
> proposal of mine) without adding more weight to header files.
>
> At some meeting (Redmond 2004, I think) something came up for which my
> Modules ideas at the time were a good fit, and that's when it turned
> into a presentation and then later an actual proposal.
I remember you bringing it up in the September 2004 meeting, and that
was the first I'd heard about it.
> James is right that I was at first guided by how Modula-2 works
> (besides
> Java -- whose model I did't like -- that was what I was most familiar
> with). Since then, things have changed and the proposed model is
> "somewhere in between" Modula-2 and Java.
>
> That said, I've occasionally argued that the existence and
> effectiveness
> of modules in D (which is closer to C++ conceptually than Java or
> Modula-2) makes it likely that C++ modules could be similarly feasible
> and effective.
It's nice to have a motivating example in a closely related language,
especially since exported templates come 'for free' with imports instead
of taking years to implement <g>. Neither Java nor Modula-2 have
templates, so their examples are less compelling. Since C++ utterly
routed and destroyed Modula-2 about 18 years ago, it'd be hard to get
anyone to listen to a spiel about adopting M2 features :-).
BTW, here's a comparison of D and C++ templates:
http://www.digitalmars.com/d/template-comparison.html
Walter Bright
> On Feb 27, 12:21 am, Walter Bright <wal...@digitalmars-nospamm.com>
> wrote:
>
>> The C++ standard doesn't specify anything beyond
>> source portability. So, such is not a valid reason for disallowing
>> floating point template arguments.
>
> The problem I believe is that you cannot do floating point operations
> at compile-time without mimicking the whole FPU of the target
> platform, that has many liberties in how it can behave.
I've written floating point emulators, and there are surely some free
ones floating around on the web. It isn't hard, especially since it
wouldn't have to be fast. I can provide one if some C++ compiler writer
wants to save some time <g>. Implementing C++ templates is probably 3
orders of magnitude more work.
But I find this a strange impediment anyway, as otherwise how is the C++
compiler supposed to do constant folding? Are there any actual C++
compilers that don't?
James Kanze
wrote:
> Daveed wrote:
> > On Feb 26, 3:39 am, Walter Bright <wal...@digitalmars-nospamm.com>
> > wrote:
> > [...]
> It's nice to have a motivating example in a closely related language,
> especially since exported templates come 'for free' with imports instead
> of taking years to implement <g>. Neither Java nor Modula-2 have
> templates, so their examples are less compelling.
> Since C++ utterly routed and destroyed Modula-2 about 18 years
> ago, it'd be hard to get anyone to listen to a spiel about
> adopting M2 features :-).
Well, Java adopted some of Modula-3's features, and you
occasionally hear calls for them to be adopted into C++
(finally, for example). (And of course, anyone who's actually
used Modula-2 still misses its modules in C++. Even after 20
years.)
The concept of modules has been around for a long time; Ada's
packages are very similar (and for many applications, Ada is
C++'s only concurrent). And it has been generally recognized
for a long time, even by people who are otherwise very pro-C++,
that textual inclusion is not really a good solution to the
problem; it can, with a lot of care on the part of the user, be
made to work, but that's about all that can be said for it.
As more of a meta-comment: I believe that one of your goals with
regards to D is that the language should be used. If so, then
it is normal, and IMHO necessary, that D doesn't invent totally
new concepts. Users need something stable, and to define
something stable that works, you need existing practice---that
people have actual experience with the feature. And I don't
think that D is widespread enough that it can be considered as
having "popularized" anything, either. Given these two points,
I don't think that D can be said to have played a large role in
the evolution of C++. It's sometimes nice to know that a
feature has been implemented in a language similar to C++, but
that's about it. And you have to define what is meant by
similar: is the compilation model of D closer to C++ or to Java?
(With regards to the compilation model, Ada is closer to C++
than is Java, and experience in Ada is more significant than
that in Java.)
That doesn't mean that D is necessarily irrelevant. Any
experience with a new feature, in any language, is relevant.
But it's certainly not the only, or even the main source for the
evolution of C++. It is, at most, just one additional data
point.
I, for one, get rather tired of seeing this forum used as a
propaganda medium for D. There are cases where mentionning D is
perfectly relevant---if the question were, how could this
feature be implemented in C++, then a discussion of how you
implemented it in D (including discussion of how D is differs
from C++ in e.g. its definition of string literals) is relevant.
When the question is just: can this be done in C++, insisting on
the fact that it can be done in D, isn't. Note that this has
nothing to do with the qualities of D per se. This forum just
isn't the place for such blatant advocacy.
--
James Kanze (GABI Software) email:james...@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
James Kanze
Now we have some experience with templates in general. Don't
forget that when the standard was being formulated, we didn't
have any real experience in templates at all. In my own work,
I've never needed floating point parameters for templates, so
I'm not going to spearhead any movement to add them, but if
some people find that they might be useful, we certainly have
more experience than we had in 1995 to base the decision on.
> None of these problems have
> materialized,
Normal, since we didn't have the feature:-).
Seriously, I think that there are problems, but I think that
they're probably of the "user beware" type (and if we banned
those, we wouldn't support floating point at all). Some things
that we do with floating point template parameters will have
surprising results, and some won't be portable, but that's the
case of all floating point, already. There will be some
problems specifying what is required, and what isn't, because
C++ supports cross-compilers, and currently doesn't require full
emulation of the target platform's floating point in the
compiler; this means that something like "0.3333333 == 1.0/3.0"
might evaluate true at runtime, but false when evaluated by the
compiler (and thus, true in an if statement, but with
"0.3333333" and "1.0/3.0" resulting in different types when
instantiating a template).
I don't think that any of these are necessarily insurmountable
problems, but they do have to be addressed. Note that this is
place D could be of help. What does D do in the case of cross
compilation, for example: does it just accept that equality of
types doesn't correspond to the equality of run-time values (and
what are the consequences in user code), or does it require full
emulation of the target floating point (and what is the
implementation effort which this implies)? Or simply, for that
matter, how useful is it really? Are there (real) problems
which it solves, or does it just give a feeling of completeness
(and orthogonality), without really being used?
> > When defining a standard, this is
> > more or less what you have to do. It's easy to add a feature,
> > once you know what it should do, but it's almost impossible to
> > remove one, or even change it, if you make the wrong choice.
> Should have thought of that with exported templates <g>.
And a lot of library issues:-). I think there's a saying about
once burned, twice wary, that's applicable here. Just because
we made a mistake in the past is no reason to make the same
mistake in the future. (The problem is, of course, that without
something like export, you can't use templates at the
application level in large projects.)
> I think the
> lesson is not to avoid new things, but to try implementing them before
> welding them in to the standard.
In general, the rule is experiment first, then standardize what
works. In practice, there is a fine line: if the experiment
works, it will be emulated (in incompatible ways) in other
implementations, and once incompatible implementations are
widespread, standardization becomes difficult as well. Still,
it's easier for an experimental implementation to correct a flaw
than when it is fixed in the stone of the standard.
> This makes the D programming language, which is very close to
> C++, on topic and relevant as working examples of some
> proposed new features.
My question, in part, is just how close is it. Many of the
things you say about it suggest to me that it is closer to Java
than to C++. And for some things, Java is a radically different
language, with only the look and feel of C++.
> > (The way floating point is specified in C/C++, something like
> > the above could even depend on the level of optimization. And
> > yes, this affects the if as well---I've had examples of code
> > compiled with g++ where the results of something like the if
> > changed depending on the optimization level I used.)
> People who deal with floating point code quickly learn to come to terms
> with the a==b problem,
I don't know about that. It seems to be a perpetual source of
problems (probably because it doesn't have a simple solution
which can be explained in a few words).
> and are able to transfer that knowledge to
> working with floating point template arguments.
Do you have any actual statistics, or just a gut feeling?
--
James Kanze (GABI Software) email:james...@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
--
James Kanze
wrote:
> Mathias Gaunard wrote:
> > On Feb 27, 12:21 am, Walter Bright <wal...@digitalmars-nospamm.com>
> > wrote:
> >> The C++ standard doesn't specify anything beyond
> >> source portability. So, such is not a valid reason for disallowing
> >> floating point template arguments.
> > The problem I believe is that you cannot do floating point operations
> > at compile-time without mimicking the whole FPU of the target
> > platform, that has many liberties in how it can behave.
> I've written floating point emulators, and there are surely some free
> ones floating around on the web. It isn't hard, especially since it
> wouldn't have to be fast. I can provide one if some C++ compiler writer
> wants to save some time <g>. Implementing C++ templates is probably 3
> orders of magnitude more work.
> But I find this a strange impediment anyway, as otherwise how is the C++
> compiler supposed to do constant folding? Are there any actual C++
> compilers that don't?
For whatever reasons, historically, at least, have not required
it, and I wouldn't be surprised if there weren't some cross
compilers, even today, which don't fold floating point
constants. And of course, the emulators I know emulate IEEE
floating point, which is typically the one you don't need, since
it is what is native on the machine the compiler runs on. You
need to emulate the floating point of the target.
Note too that C++ allows extended precision to be used for
intermediate results. This means that the results of some
complicated expression may (and do, at least with g++ on an
Intel) depend on register presure from other expressions. When
evalutating a template parameter, is the compiler allowed to do
this, or not?
--
James Kanze (GABI Software) email:james...@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
--
James Kanze
wrote:
> James Kanze wrote:
> > On Feb 26, 9:37 am, Walter Bright <wal...@digitalmars-nospamm.com>
> >> Why should a template binary (or the floating point part of a mangled
> >> name) be portable between platforms?
> > Why should anything be portable?
> Binaries aren't portable between platforms, anyway. I don't know any
> example of portable C++ binaries between Windows x86 and Linux x86 -
> even a trivial one. The C++ standard doesn't specify anything beyond
> source portability. So, such is not a valid reason for disallowing
> floating point template arguments.
You're the one who mentionned binaries. The problem is
semantics. C++ normally gives a limited set of legal semantics
to a legal program.
Traditionally, C (and C++) have underspecified floating point
arithmetic, leaving it largely a quality of implementation
issue. With a few precautions, however, programmers could write
code which gave roughly the same results on different platforms,
in practice, anyway. (Note the "roughly", however.) In many
contexts, in order to do this, one avoided testing for equality.
By allowing floating point arguments to templates, you have an
implicit equality test, executed on the host (compiling)
machine, not on the target. The results are binary: either two
instantiations of a template are the same type, or they're not.
Note that whether the results of two floating point expressions
compares equal with g++, on an Intel, sometimes depends on the
level of optimization. In cases where this causes a problem in
non-template code, I write my tests differently, taking a delta
into account, using < instead of ==, etc. If this occurs in a
template argument, however, I don't have any choice.
I'm not saying that it can't be done. Just that there are some
non trivial problems which have to be addressed.
> > The problem here has nothing to do with mangled names or
> > whatever. The question is whether two different instantiations
> > of a template are the same type or not. The standard requires,
> > for example, that given "template<int i> struct foo{};",
> > "foo<1>" and "foo<2-1>" have the same type. Defining when two
> > such instantiations have the same type is much, much harder for
> > floating point.
> Just specify they must match exactly to the full precision of the type,
Which varies depending on the implementation, and in some cases
(g++ on Intel, for example), the optimization or the context of
the expression.
> like the == operator does for floats (and the standard has no problem
> defining ==).
Except that I have no problems avoiding that operator in cases
where it causes problems. And the standard doesn't really
definite that well, either, since something like f() == g()
(where f() and g() return double) may give different results
depending on the optimization, or even in some cases,
surrounding context. (There was a case in this forum recently
where some one was having problems with std::set because he'd
defined the ordering function along the lines of f(a) < f(b),
and it was returning true when a and b were equal, even if the
order of the arguments was swapped.)
And of course, the standard does expect == to be evaluated in
the run-time environment. Which isn't necessarily available (at
present, at least) in the compiler.
> > Maybe it's acceptable to just say
> > "unspecified". Maybe not. Maybe we know the answer today. We
> > certainly didn't back in the 1990's, however, when the standard
> > was being formulated.
> As the usage of floating template arguments in the D programming
> language illustrates, it simply isn't a problem.
Or you haven't recognized it as a problem. Or nobody is
actually using it, so the problems haven't been seen.
The fact that it does exist in D is a good starting point
(provided that D's templates work something like those in C++,
or course). It doesn't prove anything per se, but it allows us
to at least start collecting some concrete data---a necessary
first step. (To tell the truth, I'm rather surprised that some
C++ compiler implementator hasn't offered it as an extension.
It's an obvious extension, and except in the case of cross
compilers, an experimental, first-draft implementation shouldn't
be that difficult.)
For starters, the two places where I see the most likelyhood of
difficulty is in cases of extended precision, and with
cross-compilers. Do you have any experience with
cross-compiling in D? And you certainly have experience with
extended precision, since I know you support Intel. What steps
do you take there: always ensure that the parameter is written
to memory (with the correct type) before comparing it, or
something else?
> Array literals also work as template arguments, and we plan to
> add in the future associative array and struct literals. C++
> established a bridgehead on what could be done with templates,
> and D is busy pouring the whole army through it <g>.
> For a small example of what can be done, Don Clugston wrote a template
> metaprogram to execute "99 bottles of beer" entirely at compile time:
> http://www.99-bottles-of-beer.net/language-d-1212.html?PHPSESSID=5195...
> On a more practical note, Don Clugston and Eric Anderton have
> written string templates that will compile regular expressions
> at compile time.
Finally, an example which interests me:-).
> (It's done in C++ using expression templates rather than
> string templates.)
Does this mean that we don't need string templates in C++ to do
it? (Sounds funny: how do you specify the regular expression,
if not with a string?)
--
James Kanze (GABI Software) email:james...@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
--
Walter Bright
>> Since C++ utterly routed and destroyed Modula-2 about 18 years
>> ago, it'd be hard to get anyone to listen to a spiel about
>> adopting M2 features :-).
>
> Well, Java adopted some of Modula-3's features, and you
> occasionally hear calls for them to be adopted into C++
> (finally, for example).
I would hypothesize that the calls for finally are based on experience
with Java, not M3, as Java is a current (not dead) language, and there
are an enormous number of Java programmers used to finally.
I just don't believe you're going to get many people to listen to a
presentation entitled "Features from Modula-3 that should be put in to C++."
> (And of course, anyone who's actually
> used Modula-2 still misses its modules in C++. Even after 20
> years.)
Which again emphasizes my point that M2 is not a compelling example - it
failed for 20 years to even inspire a proposal for C++ modules.
> The concept of modules has been around for a long time; Ada's
> packages are very similar (and for many applications, Ada is
> C++'s only concurrent). And it has been generally recognized
> for a long time, even by people who are otherwise very pro-C++,
> that textual inclusion is not really a good solution to the
> problem; it can, with a lot of care on the part of the user, be
> made to work, but that's about all that can be said for it.
I'm not going to suggest that D invented modules, and I'm sorry if I
gave the impression that I thought it did. What I *am* suggesting is
that D features are providing motivation for C++ proposals. In this
case, 20 years go by and modules don't get put in C++, then a few months
after discussing D modules with Daveed, he proposes them for C++. While
Daveed says that D modules didn't inspire him, he did use D modules as
an example to try to motivate others to support C++ modules.
> As more of a meta-comment: I believe that one of your goals with
> regards to D is that the language should be used. If so, then
> it is normal, and IMHO necessary, that D doesn't invent totally
> new concepts.
There's not much in D that could be called a new concept in programming.
D draws heavily on existing practice in other languages - primarily C++
- but Ruby, Python, Lisp and others are also influential.
> Users need something stable, and to define
> something stable that works, you need existing practice---that
> people have actual experience with the feature.
How many people have experience with template concepts? Has anyone even
attempted an implementation of it? But concepts are a sure thing for C++0x.
> And I don't
> think that D is widespread enough that it can be considered as
> having "popularized" anything, either.
I didn't say "popularized", so please do not use quotes to put words in
my mouth.
> Given these two points,
> I don't think that D can be said to have played a large role in
> the evolution of C++.
I didn't say that, either. I said: "A number of D features seem to have
wound up as proposals for C++0x (such as contract programming, utf
strings, modules, etc.)". The advocates of C++ modules and C++ contracts
have used the corresponding D features as motivating examples.
> It's sometimes nice to know that a
> feature has been implemented in a language similar to C++, but
> that's about it.
There's a lot more to it than that, because you can see the feature in
actual use - how it helps, how it interacts with other features, any
problems, etc. The closer the language is to C++, the more *relevant*
this is. There's a world of difference between standardizing something
that's never been done at all, and having actual experience. It's like
saying it would be merely "nice to know" that airplanes fly before
placing an order for 1000 airliners at $50,000,000 each.
> And you have to define what is meant by
> similar: is the compilation model of D closer to C++ or to Java?
The compilation model is pretty much identical to C++. After all, both D
implementations use an existing C++ optimizer and back end.
Walter Bright
> And of course, the emulators I know emulate IEEE
> floating point, which is typically the one you don't need, since
> it is what is native on the machine the compiler runs on. You
> need to emulate the floating point of the target.
These aren't hard to write, especially since non-IEEE fp hardware tends
to be simple. The real problem in writing an fp emulator is making it
fast, but that wouldn't be an issue for compiler constant folding
implementations.
> Note too that C++ allows extended precision to be used for
> intermediate results. This means that the results of some
> complicated expression may (and do, at least with g++ on an
> Intel) depend on register presure from other expressions. When
> evalutating a template parameter, is the compiler allowed to do
> this, or not?
Yes, it is explicitly allowed to use arbitrarily higher precision than
would be available on the target, but not less.
Walter Bright
>> As the usage of floating template arguments in the D programming
>> language illustrates, it simply isn't a problem.
> Or you haven't recognized it as a problem. Or nobody is
> actually using it, so the problems haven't been seen.
Since people are using it, and they haven't been shy about complaining
about problems, that's a moot argument.
> (To tell the truth, I'm rather surprised that some
> C++ compiler implementator hasn't offered it as an extension.
> It's an obvious extension, and except in the case of cross
> compilers, an experimental, first-draft implementation shouldn't
> be that difficult.)
As a C++ compiler implementor, I'll give the reasons why:
1) Just trying to implement the Standard consumes all the resources - no
time left over for speculative extensions. Remember those 3 man-years to
do exported templates?
2) Despite (1), I've implemented various C++ extensions over the years.
Nobody uses them, because they are non-standard. It's a waste of my time
to do them.
> For starters, the two places where I see the most likelyhood of
> difficulty is in cases of extended precision, and with
> cross-compilers. Do you have any experience with
> cross-compiling in D?
No - but also, D floating point arithmetic is defined to be IEEE 754.
> And you certainly have experience with
> extended precision, since I know you support Intel. What steps
> do you take there: always ensure that the parameter is written
> to memory (with the correct type) before comparing it, or
> something else?
Explicitly allow the D implementation to constant fold at arbitrarily
higher precision than the target has - just not less precision.
>> On a more practical note, Don Clugston and Eric Anderton have
>> written string templates that will compile regular expressions
>> at compile time.
> Finally, an example which interests me:-).
It's hard to find interesting examples that are just a few lines of code.
>> (It's done in C++ using expression templates rather than
>> string templates.)
>
> Does this mean that we don't need string templates in C++ to do
> it? (Sounds funny: how do you specify the regular expression,
> if not with a string?)
That's like saying if you can get from Boston to Miami by car therefore
one doesn't need airplanes.
1) Expression templates are an order of magnitude harder to program than
string templates.
2) Expression templates restrict the DSL (Domain Specific Language) to
C++ operators, binding and precedence. String templates have no such
restriction.
Walter Bright
> Now we have some experience with templates in general. Don't
> forget that when the standard was being formulated, we didn't
> have any real experience in templates at all.
And that shows. C++ template metaprogramming is all about doing things
that were, rather obviously, never thought of when the template facility
was designed. C++ template metaprogramming was discovered, rather than
designed. It's like using a belt buckle as a screwdriver.
I'm not being critical of C++'s designers for this - it's unreasonable
to expect anyone to be so prescient. But now that we know about template
metaprogramming, we can purposely design a system to support it.
> What does D do in the case of cross
> compilation, for example: does it just accept that equality of
> types doesn't correspond to the equality of run-time values (and
> what are the consequences in user code), or does it require full
> emulation of the target floating point (and what is the
> implementation effort which this implies)?
D implementation floating point requirements are:
1) It be IEEE 754 compliant
2) It must be done at at least the minimum precision specified by the type
3) It optionally can be done at arbitrarily higher precision than is
available at runtime
4) Runtime precision can be increased for intermediate values
In other words, the programmer should write floating point code in such
a manner that if the precision were to be increased, the algorithm would
not malfunction. It's analogous to designing digital electronics
circuits assuming maximum propagation delays, and that substitution of
faster parts wouldn't break the circuit. (Because parts get faster over
time, not slower.)
This also means that trying to specialize templates on values subject to
roundoff should raise an eyebrow just as:
if (x == 10.7/3.6)
should.
> Or simply, for that
> matter, how useful is it really? Are there (real) problems
> which it solves,
Yes. D programming is used by physicists for numerical work, and they
use it (and asked for it). In the past I've had to write programs that
generated static array tables of floating point values to be #include'd
as C++ source code, so yes, that could have been done at compile time
instead.
> or does it just give a feeling of completeness
> (and orthogonality), without really being used?
Orthogonality shouldn't be underrated. It gives the language the feeling
of solidarity and consistency, rather than being a bag of hacks and
kludges. It reduces the effort to learn a language. Perl is a language
without orthogonality, and look at all the trouble that has caused (and
how it created an opportunity for Ruby).
C++ has a lot of problems with orthogonality, and the C++ templates are
a big part of that.
I ain't smart enough to anticipate all the uses a feature can be put to.
I'm consistently surprised at the creative uses put to things that were
just put in for consistency and orthogonality. That certainly happened
with template string literals - it never occurred to me one could use
that to build a compile-time regex compiler!
> My question, in part, is just how close is it. Many of the
> things you say about it suggest to me that it is closer to Java
> than to C++. And for some things, Java is a radically different
> language, with only the look and feel of C++.
A language's philosophy ultimately affects what it is. These are the
philosophies of the 3 languages as I interpret them:
C++:
1) A better C
2) Only pay for what you use (runtime efficiency trumps)
3) The programmer is King and in charge
4) Legacy code must not be broken
5) If there's any way something could be done in a library, that is the
preferred solution
6) Implementation difficulties are irrelevant
What makes Java a radically different language is its radically
different underlying philosophy:
1) Provide an abstract machine that completely hides the real machine
2) Byte code interpreter semantics must not change
3) The machine must be protected from the programmer
4) The JVM is King and in charge
5) OOP hammers all nails
6) Get rid of the hard features of C++
D's philosophy is much closer to C++'s, hence it is far closer to C++
than to Java:
1) It should take its design cues from C++
2) The programmer is King and in charge
3) The natural way to do something should also be the safe and correct way
4) Maintain C ABI compatibility
5) It's ok to be source incompatible with C++ if the reason is sound
6) Programmer efficiency is as important as runtime efficiency
7) Fix the hard features of C++
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).
>> People who deal with floating point code quickly learn to come to terms
>> with the a==b problem,
>
> I don't know about that. It seems to be a perpetual source of
> problems (probably because it doesn't have a simple solution
> which can be explained in a few words).
>
>> and are able to transfer that knowledge to
>> working with floating point template arguments.
> Do you have any actual statistics, or just a gut feeling?
My knowledge comes from working with people who use floating point
templates. None of them have ever wondered about the issue with
templates, after they understood the issues with plain old operator ==.
Andrei Alexandrescu (See Website For Email)
> Walter Bright wrote:
>> James Kanze wrote:
>>> I wouldn't be if I'd have formulated it correctly. The only
>>> arithmetic type you can use to instantiate a template are
>>> integral types, and their arguments must be integral constant
>>> expressions. There's no problem with instantiating a template
>>> with a string, however:
>
>>> template< char const* string > class T {} ;
>>> namespace {
>>> char const toto[] = "toto" ;
>>> }
>
>>> T< toto > instance ;
>
>> That isn't instantiating it with a string, it's instantiating
>> it with a global symbol.
>
> A global symbol which refers to a string. It's a simple work
> around.
>
> I don't know what definition of string you're using, but the
> only one I can see that would apply here is an array of char
> which contains a '\0' terminated sequence of characters. toto
> is very much a string, even if it isn't a string literal.
Sorry, this is incorrect. You can't gloss over the little "detail" that
you must go at namespace scope and define a symbol for each string you
want to use. That makes the feature pretty much useless, as is shown by
the little attention it receives in C++.
Andrei
Tony Delroy
> Note that whether the results of two floating point expressions
> compares equal with g++, on an Intel, sometimes depends on the
> level of optimization. In cases where this causes a problem in
> non-template code, I write my tests differently, taking a delta
> into account, using < instead of ==, etc. If this occurs in a
> template argument, however, I don't have any choice.
Programmers shouldn't have to write their compile-time algorithms
differently from their run-time algorithms. They should be able to
include the same C++ headers, link to the same libraries, run
arbitrary code specified inline in their C++ programs, and have the
resultant text reinserted for compilation. This is the way my
introspective preprocessor works. Templates have their place for
_restricting_ code generation, but all the workarounds and extentions
in C++ vs D that you're both contrasting are sorry hacks. It's like
learning a second, more cryptic, more ad hoc and limited language.
Issues like the one above should be address the same way for compile-
time code generation as run-time: however the programmers think best
in the context of their environment. Let them call the same libraries
to do it, and use the full language feature set. Walter: can you do
what my preprocessor can't do, and let D programs call functions from
the current compilation unit?
Walter Bright
> Programmers shouldn't have to write their compile-time algorithms
> differently from their run-time algorithms. They should be able to
> include the same C++ headers, link to the same libraries, run
> arbitrary code specified inline in their C++ programs, and have the
> resultant text reinserted for compilation.
I agree.
> Templates have their place for
> _restricting_ code generation, but all the workarounds and extentions
> in C++ vs D that you're both contrasting are sorry hacks. It's like
> learning a second, more cryptic, more ad hoc and limited language.
You're quite right.
> Walter: can you do
> what my preprocessor can't do, and let D programs call functions from
> the current compilation unit?
Yes. As of version 1.005, regular D functions can be executed at compile
time, provided that they are 'pure' functions. By this I mean that they
only depend on their arguments, do not read/set anything but locals and
parameters, and have only literals or constants as arguments.
For example, here's a Brain**** DSL that reads bf source at compile
time, and compiles it at compile time into D source code:
http://www.digitalmars.com/d/archives/digitalmars/D/Compile-time_madness_Compile-time_compiler_49164.html
James Kanze
wrote:
> James Kanze wrote:
[...]
> > As more of a meta-comment: I believe that one of your goals with
> > regards to D is that the language should be used. If so, then
> > it is normal, and IMHO necessary, that D doesn't invent totally
> > new concepts.
> There's not much in D that could be called a new concept in programming.
> D draws heavily on existing practice in other languages - primarily C++
> - but Ruby, Python, Lisp and others are also influential.
I think that's where we agree. If D can lay claim to any
originality, it's in the particular mixture of concepts that it
offers, not in any new concepts. And IMHO, that's a feature, at
least if I want to use the language in production. I want
features which have proven their usefulness elsewhere.
> > Users need something stable, and to define
> > something stable that works, you need existing practice---that
> > people have actual experience with the feature.
> How many people have experience with template concepts? Has
> anyone even attempted an implementation of it? But concepts
> are a sure thing for C++0x.
I think that much of the work on concepts got started because of
weaknesses in a purely library solution, as was tried in Boost.
But I'll admit that I'm not really too up to date on them. And
that I'll a little bit sceptical, precisely because we don't
have real experience.
> > And I don't
> > think that D is widespread enough that it can be considered as
> > having "popularized" anything, either.
>
> I didn't say "popularized", so please do not use quotes to put words in
> my mouth.
Sorry. It is more of a meta-comment. I'm trying to put D in
its context. What role does it (or should it) play with regards
to C++.
> > Given these two points,
> > I don't think that D can be said to have played a large role in
> > the evolution of C++.
> I didn't say that, either. I said: "A number of D features seem to have
> wound up as proposals for C++0x (such as contract programming, utf
> strings, modules, etc.)". The advocates of C++ modules and C++ contracts
> have used the corresponding D features as motivating examples.
That's not what they say. But as I said elsewhere, it's a data
point.
> > It's sometimes nice to know that a
> > feature has been implemented in a language similar to C++, but
> > that's about it.
> There's a lot more to it than that, because you can see the feature in
> actual use - how it helps, how it interacts with other features, any
> problems, etc.
That's exactly what I mean. I'm not too worried about the
implementability in itself---there are enough implementors on
the committee to take care of that. I am worried about getting
it into the standard in the right form, so that it really is
usable.
> The closer the language is to C++, the more *relevant*
> this is. There's a world of difference between standardizing something
> that's never been done at all, and having actual experience. It's like
> saying it would be merely "nice to know" that airplanes fly before
> placing an order for 1000 airliners at $50,000,000 each.
> > And you have to define what is meant by
> > similar: is the compilation model of D closer to C++ or to Java?
> The compilation model is pretty much identical to C++. After all, both D
> implementations use an existing C++ optimizer and back end.
That's not what I meant (but I don't really know the right
word). What I was talking about was the fact that you define a
class separately from its member functions; that in most cases,
the member functions aren't even in the same file. When I think
modules, I do still think of Modula-2, and its interface and
implementation sections; if I think of a modern language, I
think Ada, with its package specification and package body.
Somewhere I got the idea that D was like Java; that you defined
the member functions in the class definition. If that's the
case, I'm not sure that its concept of modules would be
applicable to C++.
--
James Kanze (GABI Software) email:james...@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
--
James Kanze
wrote:
> James Kanze 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. I can understand the
motivation for such a decision, but it is not the decision of
C++, and I don't forsee it being the decision of C++ anytime in
the immediate future.
[...]
> This also means that trying to specialize templates on values subject to
> roundoff should raise an eyebrow just as:
> if (x == 10.7/3.6)
> should.
OK. Now you have made a statement concerning concrete
statement about use cases, based (I hope) on real experience.
As I think I mentionned, the problem (potential problem, at
least) is that in the case of if, I have alternatives, operators
like < or <=, or I can modify it to check for proximity, or
whatever my algorithm entails. Template types are based on
strict equality, so I don't have these alternatives.
Does that make floating point arguments for templates unusable?
I don't know. I do think that there is, or at least was, enough
doubt to consider that the committee did the right thing, in the
mid 1990's, in not supporting them.
> > Or simply, for that
> > matter, how useful is it really? Are there (real) problems
> > which it solves,
> Yes. D programming is used by physicists for numerical work, and they
> use it (and asked for it). In the past I've had to write programs that
> generated static array tables of floating point values to be #include'd
> as C++ source code, so yes, that could have been done at compile time
> instead.
> > or does it just give a feeling of completeness
> > (and orthogonality), without really being used?
> Orthogonality shouldn't be underrated.
I'm not trying to underrate it; I think it's important as well.
I'm just pointing out that it's not the only thing which has to
be considered. (There's also the problem that the behavior of
integral types and floating point types isn't orthogonal to
begin with.)
> It gives the language the feeling
> of solidarity and consistency, rather than being a bag of hacks and
> kludges. It reduces the effort to learn a language. Perl is a language
> without orthogonality, and look at all the trouble that has caused (and
> how it created an opportunity for Ruby).
Now there's something we can agree on:-).
> C++ has a lot of problems with orthogonality, and the C++ templates are
> a big part of that.
I'd say that the biggest problem is arrays, which don't behave
like any of the other types.
> > My question, in part, is just how close is it. Many of the
> > things you say about it suggest to me that it is closer to Java
> > than to C++. And for some things, Java is a radically different
> > language, with only the look and feel of C++.
> A language's philosophy ultimately affects what it is. These are the
> philosophies of the 3 languages as I interpret them:
> C++:
> 1) A better C
> 2) Only pay for what you use (runtime efficiency trumps)
> 3) The programmer is King and in charge
> 4) Legacy code must not be broken
> 5) If there's any way something could be done in a library, that is the
> preferred solution
> 6) Implementation difficulties are irrelevant
Not totally for the last. But above all, I'd add a
meta-philosophy: pragmatism. C++ has always been about
something that works, rather than elegance.
> What makes Java a radically different language is its radically
> different underlying philosophy:
> 1) Provide an abstract machine that completely hides the real machine
> 2) Byte code interpreter semantics must not change
> 3) The machine must be protected from the programmer
> 4) The JVM is King and in charge
> 5) OOP hammers all nails
> 6) Get rid of the hard features of C++
> D's philosophy is much closer to C++'s, hence it is far closer to C++
> than to Java:
> 1) It should take its design cues from C++
> 2) The programmer is King and in charge
> 3) The natural way to do something should also be the safe and correct way
> 4) Maintain C ABI compatibility
> 5) It's ok to be source incompatible with C++ if the reason is sound
> 6) Programmer efficiency is as important as runtime efficiency
> 7) Fix the hard features of C++
> 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. And as for
the inheritance model, I find it easier to do OO type
inheritance in C++ than in Java; I find Java's distinction into
two types of inheritance very artificial and limiting. (When I
did do a large application in Java, we made very little use of
interface---our "interfaces" were what Java calls abstract
classes, with all of the public functions declared final. Very
much like I do in C++.)
> >> People who deal with floating point code quickly learn to come to terms
> >> with the a==b problem,
> > I don't know about that. It seems to be a perpetual source of
> > problems (probably because it doesn't have a simple solution
> > which can be explained in a few words).
> >> and are able to transfer that knowledge to
> >> working with floating point template arguments.
> > Do you have any actual statistics, or just a gut feeling?
> My knowledge comes from working with people who use floating point
> templates. None of them have ever wondered about the issue with
> templates, after they understood the issues with plain old operator ==.
OK. I can accept that.
--
James Kanze (GABI Software) email:james...@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
--
Mathias Gaunard
wrote:
> 2) Despite (1), I've implemented various C++ extensions over the years.
> Nobody uses them, because they are non-standard. It's a waste of my time
> to do them.
Depends whether those extensions are really good or not.
If template virtuals were available as an extension on a compiler,
maybe I would consider making some code relying on that extension,
because they would be a very great addition to the language.
If the extension only brings little additional feature, I would rather
keep my code portable.
Dave Harris
> Binaries aren't portable between platforms, anyway. I don't know any
> example of portable C++ binaries between Windows x86 and Linux x86 -
> even a trivial one. The C++ standard doesn't specify anything beyond
> source portability. So, such is not a valid reason for disallowing
> floating point template arguments.
My understanding is that floating point arguments for templates would
break source compatibility. Eg:
template <double d> struct Demo {};
typedef Demo<0.3333333> Demo1;
typedef Demo<1.0/3.0> Demo2;
bool func( Demo1 &d ) { return false; }
bool func( Demo2 &d ) { return true; }
If Demo1 and Demo2 are different types, then we have two overloads of
"func". The signatures are different so the code is legal. If Demo1 and
Demo2 are the same type, then we have two (incompatible) definitions of
the same function, which violates the One Definition rule. Probably it
will not even compile.
There may be more compelling examples, but you get the idea. We don't want
something as basic as static type checking to vary from one implementation
to another.
-- Dave Harris, Nottingham, UK.
Walter Bright
> 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.
>> This also means that trying to specialize templates on values subject to
>> roundoff should raise an eyebrow just as:
>> if (x == 10.7/3.6)
>> should.
>
> OK. Now you have made a statement concerning concrete
> statement about use cases, based (I hope) on real experience.
> As I think I mentionned, the problem (potential problem, at
> least) is that in the case of if, I have alternatives, operators
> like < or <=, or I can modify it to check for proximity, or
> whatever my algorithm entails. Template types are based on
> strict equality, so I don't have these alternatives.
>
> Does that make floating point arguments for templates unusable?
Far from it - consider a template to compute the square root:
template sqrt(real x, real root = x/2, int ntries = 0)
{
static if (ntries == 5)
// precision doubles with each iteration,
// 5 should be enough
const sqrt = root;
else static if (root * root - x == 0)
const sqrt = root; // exact match
else
// iterate again
const sqrt = sqrt!(x, (root+x/root)/2, ntries+1);
}
void main()
{
real x = sqrt!(2);
writefln("%.20g", x); // 1.4142135623730950487
}
Not only does it use exact matching of floating point values, it
*relies* on it in a portable manner.
>> 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.
> But above all, I'd add a
> meta-philosophy: pragmatism. C++ has always been about
> something that works, rather than elegance.
I tend to agree with that. C++ seems absent the religion that infects
other languages, like "everything must be an object".
>> 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.
Mathias Gaunard
Look at boost xpressive.
Daveed
wrote:
[...]
> Which again emphasizes my point that M2 is not a compelling example - it
> failed for 20 years to even inspire a proposal for C++ modules.
Not that many additions to C++ are motivated by their presence in
other languages. In fact, if you exclude C89 and C99 I'm not sure any
C++ additions were motivated by other languages. The additions are
motivated by real problems that come to the committee's attention.
Then, experience in other languages may guide some design choices.
(In fact, my sense is that proposals whose primary motivation is
"Language X has this therefore C++ should have it too" tend not to do
well before the committee.)
> I'm not going to suggest that D invented modules, and I'm sorry if I
> gave the impression that I thought it did. What I *am* suggesting is
> that D features are providing motivation for C++ proposals.
I'm not aware of any such proposals, and I'm pretty sure none has made
it through to having a C++0x chance.
In fact, I think D has been mentioned at most a few times in committee
discussions and not in any amount of detail. The two mentions I can
think of are "D is another language with support for contract
programming" and "D seems to have modules working with a language
model similar to C++". (That's not "motivation"; just argumentation.)
> In this case, 20 years go by and modules don't get put in C++, then a few months after discussing D modules
> with Daveed, he proposes them for C++. While Daveed says that D modules didn't inspire him, he did use D
> modules as an example to try to motivate others to support C++ modules.
As I said, the timing is purely coincidental. Modules (unlike D) were
frequently being brought up in committee meetings (although for a long
time no real formal work took place). I may have discussed them with
you (most likely in the context of export), but then again, throughout
the export implementation we brought them up also (and that wasn't the
motivation either). In fact, modules were on the original "broadest
wish list" for C++0x extensions.
Daveed
Walter Bright
> There may be more compelling examples, but you get the idea. We don't want
> something as basic as static type checking to vary from one implementation
> to another.
You have it anyway if you're using ints, since the size of ints can
change from one implementation to another.
--
kwikius
> wal...@digitalmars-nospamm.com (Walter Bright) wrote (abridged):
>
> > Binaries aren't portable between platforms, anyway. I don't know any
> > example of portable C++ binaries between Windows x86 and Linux x86 -
> > even a trivial one. The C++ standard doesn't specify anything beyond
> > source portability. So, such is not a valid reason for disallowing
> > floating point template arguments.
>
> My understanding is that floating point arguments for templates would
> break source compatibility. Eg:
>
> template <double d> struct Demo {};
> typedef Demo<0.3333333> Demo1;
> typedef Demo<1.0/3.0> Demo2;
>
> bool func( Demo1 &d ) { return false; }
> bool func( Demo2 &d ) { return true; }
Simple to solve. Don't provide floating point params, but do allow
compile time math on floats. The values can be defined /accessed
inside the body. Whether two floats are the same is irrelevant as we
are dealing in types, which we know all about already
The following fails currently because these arent integral_constants
which is convenient. Just provide another spec for float_constants in
class as per integral_constants.
typedef double some_ct_constant_type ;
struct float_constant1{
// defined inside struct
static const some_ct_constant_type value = .3333;
};
struct float_constant2{
static const some_ct_constant_type value = 1./3;
};
template <typename Float1 ,typename Float2>
struct fun{
static const some_ct_constant_type value = Float1::value *
Float2::value;
};
template <typename T>
struct other{
static const some_ct_constant_type value = T::value;
};
int main()
{
some_ct_constant_type x = other<fun<float_constant1,float_constant2>
>::value;
}
regards
Andy Little
James Kanze
> Dave Harris wrote:
> > There may be more compelling examples, but you get the idea. We don't want
> > something as basic as static type checking to vary from one implementation
> > to another.
> You have it anyway if you're using ints, since the size of ints can
> change from one implementation to another.
The problem that Dave presented is the equivalent of:
template< int i >
struct S {} ;
int const x = ... ;
int const y = ... ;
whether S<x> is the same type as S<y> or not does not depend on
anything in the implementation. Replace int by double, and you
don't know.
(On the other hand, of course, it is true that something like
the type of 100000 depends on the implementation. Worse, the
type of 0xFFFF will be signed on some implementations, and
unsigned on others, and we all know the problems of mixing
signed and unsigned in the same expression. But just because a
problem exists in some contexts isn't an argument for adding it
in others.)
--
James Kanze (GABI Software) email:james...@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
--
Andrei Alexandrescu (See Website For Email)
> On Feb 27, 5:23 pm, Walter Bright <wal...@digitalmars-nospamm.com>
> wrote:
> [...]
>> Which again emphasizes my point that M2 is not a compelling example - it
>> failed for 20 years to even inspire a proposal for C++ modules.
>
> other languages. In fact, if you exclude C89 and C99 I'm not sure any
> C++ additions were motivated by other languages. The additions are
> motivated by real problems that come to the committee's attention.
> Then, experience in other languages may guide some design choices.
I don't know about others, but this doesn't sound very effective to me.
With a few exceptions, all languages do address real problems too, and
with various levels of success and various resulting positions in the
design space. My opinion is that many aspects of C++ would have been
designed vastly better if a harder look at how other languages solve the
same problems would have been taken.
> (In fact, my sense is that proposals whose primary motivation is
> "Language X has this therefore C++ should have it too" tend not to do
> well before the committee.)
While avoiding mindless imitation is very nice, such a concept risks of
becoming a dogma a la "NIH". In particular, for a member of the
committee who doesn't know, say, Python, Ruby, C#, or Perl, such a
surrounding attitude provides a powerful disincentive to study them (I
believe such study is extremely worthwhile).
Andrei
James Kanze
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...@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
--
Geert-Jan Giezeman
> Far from it - consider a template to compute the square root:
>
> template sqrt(real x, real root = x/2, int ntries = 0)
> {
> static if (ntries == 5)
> // precision doubles with each iteration,
> // 5 should be enough
> const sqrt = root;
> else static if (root * root - x == 0)
> const sqrt = root; // exact match
> else
> // iterate again
> const sqrt = sqrt!(x, (root+x/root)/2, ntries+1);
> }
> void main()
> {
> real x = sqrt!(2);
> writefln("%.20g", x); // 1.4142135623730950487
> }
>
> Not only does it use exact matching of floating point values, it
> *relies* on it in a portable manner.
>
>>> A language's philosophy ultimately affects what it is. These are the
>>> philosophies of the 3 languages as I interpret them:
>>
It looks to me that this kind of use is catered for in the Generalized
Constant Expressions proposal (N1972). The implementation below gives a
compile time constant (if I understand the proposal correctly).
Because the proposal does not allow recursive calls, I had to write
copies of the function. The proposal says: "However, until we see a
convincing use case for recursion, we don't propose to allow it". I
don't know if this counts as a convincing use case.
constexpr double sqrt_stage5(double x, double root)
{
return (root*root - x == 0.0)
? root
: (root+x/root)/2;
}
constexpr double sqrt_stage4(double x, double root)
{
return (root*root - x == 0.0)
? root
: sqrt_stage5(x, (root+x/root)/2);
}
constexpr double sqrt_stage3(double x, double root)
{
return (root*root - x == 0.0)
? root
: sqrt_stage4(x, (root+x/root)/2);
}
constexpr double sqrt_stage2(double x, double root)
{
return (root*root - x == 0.0)
? root
: sqrt_stage3(x, (root+x/root)/2);
}
constexpr double sqrt_stage1(double x, double root)
{
return (root*root - x == 0.0)
? root
: sqrt_stage2(x, (root+x/root)/2);
}
constexpr double sqrt(double x)
{
return sqrt_stage1(x, x/2);
}
Geert-Jan Giezeman
Mathias Gaunard
> Right now I'm trying to figure out is if string processing is even
> possible at compile time using templates.
There is no real need for templates.
A good optimizer could manage to evaluate regular code before runtime.
However, no optimizer seems to be able to do it perfectly.
Walter Bright
> On Feb 27, 5:23 pm, Walter Bright <wal...@digitalmars-nospamm.com>
> wrote:
> [...]
>> Which again emphasizes my point that M2 is not a compelling example - it
>> failed for 20 years to even inspire a proposal for C++ modules.
>
> Not that many additions to C++ are motivated by their presence in
> other languages.
C++ itself was motivated by another language - Simula67. Fortran often
is envied in regards to its handling of numerics arrays, and there have
been many attempts to bring C/C++ into parity (noalias, restrict, blitz,
etc.).
> In fact, if you exclude C89 and C99 I'm not sure any
> C++ additions were motivated by other languages.
The contracts proposal specifically mentions D (and Eiffel). Your
proposal mentions Modula. The concept proposal compares with several
other languages.
> The additions are
> motivated by real problems that come to the committee's attention.
> Then, experience in other languages may guide some design choices.
> (In fact, my sense is that proposals whose primary motivation is
> "Language X has this therefore C++ should have it too" tend not to do
> well before the committee.)
If you're right, that C++ improvements are not motivated by other
languages, but only by "problems", that's not a good sign. There are an
awful lot of great ideas in other languages. If C++ is to be successful
in the future, it'll have to look outward rather than just inward.
>> In this case, 20 years go by and modules don't get put in C++, then a few months after discussing D modules
>> with Daveed, he proposes them for C++. While Daveed says that D modules didn't inspire him, he did use D
>> modules as an example to try to motivate others to support C++ modules.
> As I said, the timing is purely coincidental. Modules (unlike D) were
> frequently being brought up in committee meetings (although for a long
> time no real formal work took place). I may have discussed them with
> you (most likely in the context of export), but then again, throughout
> the export implementation we brought them up also (and that wasn't the
> motivation either). In fact, modules were on the original "broadest
> wish list" for C++0x extensions.
A wish list is one thing, it takes a second to type in "modules." Making
the effort to put together a well engineered proposal is quite another.
Walter Bright
> 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.
I've implemented floating point emulators. I'll repeat myself in saying
that it is NOT a problem for a cross compiler to have an emulator for
the target's floating point implementation. There's no magic mojo going
on for non-IEEE arithmetic.
Walter Bright
> What I was talking about was the fact that you define a
> class separately from its member functions; that in most cases,
> the member functions aren't even in the same file. When I think
> modules, I do still think of Modula-2, and its interface and
> implementation sections; if I think of a modern language, I
> think Ada, with its package specification and package body.
> Somewhere I got the idea that D was like Java; that you defined
> the member functions in the class definition. If that's the
> case, I'm not sure that its concept of modules would be
> applicable to C++.
In D, you'd normally define the member functions in the class
declaration in the same file. If this is not what you wish to do, using
an abstract class or interfaces, or using import 'header's, or any of a
number of other techniques, is a more appropriate solution.
Walter Bright
> Walter Bright wrote:
>> change from one implementation to another.
>
> The problem that Dave presented is the equivalent of:
>
> template< int i >
> struct S {} ;
> int const x = ... ;
> int const y = ... ;
>
> whether S<x> is the same type as S<y> or not does not depend on
> anything in the implementation.
It sure does. What if it's S<(0xFFFFFFFF + 1) >> 1> ?
> But just because a
> problem exists in some contexts isn't an argument for adding it
> in others.)
Nobody argued it was. The converse was argued: "We don't want something
as basic as static type checking
to vary from one implementation to another."
All I was doing was showing that it already did, yet nobody is
suggesting that makes the feature unusable or should be removed.
Andrei Alexandrescu (See Website For Email)
> As more of a meta-comment: I believe that one of your goals with
> regards to D is that the language should be used. If so, then
> it is normal, and IMHO necessary, that D doesn't invent totally
> new concepts.
Au contraire, I'd say that if a language designer wants to convince
people to use a new language, it must bring something innovative to the
table.
> I, for one, get rather tired of seeing this forum used as a
> propaganda medium for D. There are cases where mentionning D is
> perfectly relevant---if the question were, how could this
> feature be implemented in C++, then a discussion of how you
> implemented it in D (including discussion of how D is differs
> from C++ in e.g. its definition of string literals) is relevant.
> When the question is just: can this be done in C++, insisting on
> the fact that it can be done in D, isn't. Note that this has
> nothing to do with the qualities of D per se. This forum just
> isn't the place for such blatant advocacy.
Probably the best retort is to simply ignore such threads. Without
further arguments (which often ask for rebuttals, qualifications, and
qualifications of the qualifications), this particular thread would have
simply ceased.
Second, I think it's very refreshing to see that things we've
internalized as a community for so many years, to the extent they became
dogma, questioned. Evidence from outside the language can only help. I
think we should be more tired of "you can't use floating-point numbers
with templates" and "you can't use strings with templates" than of this
forum being used as a propaganda medium for D. If I were the OP asking
the question, I'd be more gained by an analysis of what's possible,
what's not, and why, than by simply being served a regurgitation of a
canned concept formed a long time ago. Revisiting such things can be
only helpful.
Andrei
galathaea
> Hi,
> I'm trying to find out if I can use C++ templates to hash a string at
> compile time. Here's a first attempt that doesn't do it at compile
> time but at run time that simply calculates string length. This is
> just a proof of concept that I can iterate over the characters in a
> string:
>
> template <class T>
> class StringLength
> {
> public:
> static int eval(T* a)
> { return ((*a) == '\0') ? 0 :
> (StringLength<T>::eval(a+1) + 1); }
>
> };
>
> template <class T>
> inline int stringlength(T* a) { return StringLength<T>::eval(a); }
>
> usage:
> stringlength<>("four five six");
>
> Right now I'm trying to figure out is if string processing is even
> I've only found numeric operations in the metaprogramming examples and
> no string examples and I'm wondering if this is for a reason i.e. that
> C++ can't process strings in this way. Any ideas?
i am surprised they haven't really been mentioned much
but there are a couple of work arounds here
all strings are also integer containers
so you can encode compile time strings
in any of the mechanisms of compile time integer containers
one i have used in actual code
is to encode the string in arrays of arrays
SomeType['h']['e']['l']['l']['o'][' ']['w']['o']['r']['l']['d']
would be a type to manipulate the corresponding string
"hello world"
you can iterate and build a bunch of tools for parsing
and even printing
but some compilers have difficulty with complex array types
additionally
any of the boost::mpl routines for integer containers
also work
if this is a real design issue
there are methods to get around your needs
though it would be nice if c++ provided more natural syntax
i'd prefer a full metacode system
though
to some of the template extensions being suggested
something like OCaml's Camlp4
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
galathaea: prankster, fablist, magician, liar
James Kanze
<SeeWebsiteForEm...@erdani.org> wrote:
> James Kanze wrote:
> > As more of a meta-comment: I believe that one of your goals with
> > regards to D is that the language should be used. If so, then
> > it is normal, and IMHO necessary, that D doesn't invent totally
> > new concepts.
> Au contraire, I'd say that if a language designer wants to convince
> people to use a new language, it must bring something innovative to the
> table.
History doesn't agree with you, at least not since Fortran and
Cobol. The pre-standard C++ which conquered the world contained
only tried and proven ideas. The "innovation" was making them
available in a practical langage. And what "innovation" do you
see in Java or C#? Whatever else you may think of them, some
people have been convinced to use them. You might want to
compare the success of truly innovative languages, like Simula,
Smalltalk or Eiffel, with that of "synthese"
languages---languages which thrive by adopting the good ideas
originally developped elsewhere---like C++ or Java.
(The innovation of C++ is, of course, it's particular mix of
features, but above all, its emphasis on practical usability
over theoretical considerations.)
There's a reason for this, of course. The largest number of
users are involved in writing production code, not in
experimental research in computer science. And production code
can't afford anything but tried and true solutions. (There are
exceptions, of course, when the increase in productivity is so
great that it overwhelms the risk. The last time that happened
with a language, however, was Fortran.)
> > I, for one, get rather tired of seeing this forum used as a
> > propaganda medium for D. There are cases where mentionning D is
> > perfectly relevant---if the question were, how could this
> > feature be implemented in C++, then a discussion of how you
> > implemented it in D (including discussion of how D is differs
> > from C++ in e.g. its definition of string literals) is relevant.
> > When the question is just: can this be done in C++, insisting on
> > the fact that it can be done in D, isn't. Note that this has
> > nothing to do with the qualities of D per se. This forum just
> > isn't the place for such blatant advocacy.
> Probably the best retort is to simply ignore such threads. Without
> further arguments (which often ask for rebuttals, qualifications, and
> qualifications of the qualifications), this particular thread would have
> simply ceased.
Perhaps. On the other hand, the charter of this group doesn't
mention advocacy of other languages as one of it's approved
subject matters. And of course, D isn't the only language which
provides good examples of things we could do in C++.
> Second, I think it's very refreshing to see that things we've
> internalized as a community for so many years, to the extent
> they became dogma, questioned.
Such as?
> Evidence from outside the language can only help.
> I think we should be more tired of "you can't use
> floating-point numbers with templates" and "you can't use
> strings with templates" than of this forum being used as a
> propaganda medium for D.
Strange, but I haven't seen many postings along those lines.
Where as it seems that D is getting mentioned in every third
thread (always by the same person).
> If I were the OP asking the question, I'd be more gained by an
> analysis of what's possible, what's not, and why, than by
> simply being served a regurgitation of a canned concept formed
> a long time ago. Revisiting such things can be only helpful.
Certainly. But the OP's question definitly concerned how to do
something in C++. Saying that it is possible in another
language, with a different model of how arrays work and what a
string literal is, doesn't help anyone very much. It may be a
problem in C++ (I definitly think it would be useful to be able
to instantiate templates on string literals, although I'm not
convinced of the utility of all this fancy string manipulation),
in which case, we should look for ways to solve it. Just saying
that it's possible in another language doesn't advance anything.
--
James Kanze (GABI Software) email:james...@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
--
Daveed
wrote:
> Daveedwrote:
> > On Feb 27, 5:23 pm, Walter Bright <wal...@digitalmars-nospamm.com>
> > wrote:
> > [...]
> >> Which again emphasizes my point that M2 is not a compelling example - it
> >> failed for 20 years to even inspire a proposal for C++ modules.
>
> > Not that many additions to C++ are motivated by their presence in
> > other languages.
>
> C++ itself was motivated by another language - Simula67.
No it wasn't: It served as a design example, but the motivation was
solving a certain system's programming problem (I forgot which one).
> Fortran often
> is envied in regards to its handling of numerics arrays, and there have
> been many attempts to bring C/C++ into parity (noalias, restrict, blitz,
> etc.).
I'm not sure how this connects to your argument, but I'm guessing the
argument is that C/C++ have been motivated by Fortran. Again, that is
not the case: A certain community wanted to do numerics in C (and
different one wanted the same for C++), and they worked out various
ways to make that a better experience. Fortran mostly served as a
proof that better performance was possible in part with stronger
aliasing guarantees (although valarray is a derivative of trying to
give BLAS-like functionality to the C++ standard library).
> > In fact, if you exclude C89 and C99 I'm not sure any
> > C++ additions were motivated by other languages.
>
> The contracts proposal specifically mentions D (and Eiffel). Your
> proposal mentions Modula.
Modula-2 isn't mentioned as a motivator; only as an example of a
similar mechanism. If I remember correctly, Thorsten argued similarly
using Eiffel and D.
> The concept proposal compares with several
> other languages.
>From my local dictionary:
motivate:
verb [trans.]
provide (someone) with a motive for doing something : "he was
primarily motivated by the desire for profit."
Mentioning another language having a feature does no equate to saying
that that fact was the motive to consider it for C++. It can be as
little as an acknowledgment of awareness or as much as proposal to
take over the existing design whosesale, without it being a motive.
> > The additions are
> > motivated by real problems that come to the committee's attention.
> > Then, experience in other languages may guide some design choices.
> > (In fact, my sense is that proposals whose primary motivation is
> > "Language X has this therefore C++ should have it too" tend not to do
> > well before the committee.)
>
> If you're right, that C++ improvements are not motivated by other
> languages, but only by "problems", that's not a good sign. There are an
> awful lot of great ideas in other languages. If C++ is to be successful
> in the future, it'll have to look outward rather than just inward.
The first and second half of that paragraph are not really logically
connected. I happen to disagree with the first part: I think solving
real-world problems is the best way to evolve a production language
like C++. In fact, the greatest challenge for the committee is to
prioritize those problems. OTOH, deciding that a certain feature is
needed in C++ because it was a great idea in another language seems
like a recipe for disaster.
I do agree that there are very many good ideas in other languages. I
also happen to think that the C++ committee has collectively rather
broad insights in other languages (meaning, there are some committee
who have written significant code in those languages). Languages that
I remember in that group include Ada, Basic, C#, ECMAscript, Eiffel,
Fortran, Haskell, Java, Lisp, Lua, ML, Modula-2, Objective-C/C++,
Ocaml, Occam, Parlog, Perl, PL/1, Python, Scheme, Simula, and SQL.
The are no doubt others, but I think it shows that there is plenty of
knowledge to draw from (and in fact, it is indeed being drawn from).
> >> In this case, 20 years go by and modules don't get put in C++, then a few months after discussing D modules
> >> withDaveed, he proposes them for C++. WhileDaveedsays that D modules didn't inspire him, he did use D
> >> modules as an example to try to motivate others to support C++ modules.
> > As I said, the timing is purely coincidental. Modules (unlike D) were
> > frequently being brought up in committee meetings (although for a long
> > time no real formal work took place). I may have discussed them with
> > you (most likely in the context of export), but then again, throughout
> > the export implementation we brought them up also (and that wasn't the
> > motivation either). In fact, modules were on the original "broadest
> > wish list" for C++0x extensions.
>
> A wish list is one thing, it takes a second to type in "modules." Making
> the effort to put together a well engineered proposal is quite another.
Sure. It just shows that there was some motivation for modules early
on. In fact, that motivation existed long before the list was set
up. I was already lively debated at the very first committee meeting
I attended (Santa Cruz 1996; the one where "extern templates" were
removed -- they were replaced the next meeting by "export templates").
Incidentally, your point is also an argument showing that D had little
influence on the C++ proposal: It takes no longer to mention that
another language has a feature than to put that feature on a wish list
(and the latter may take more creativity).
Daveed
Daveed
<SeeWebsiteForEm...@erdani.org> wrote:
> Daveedwrote:
> > On Feb 27, 5:23 pm, Walter Bright <wal...@digitalmars-nospamm.com>
> > wrote:
> > [...]
> >> Which again emphasizes my point that M2 is not a compelling example - it
> >> failed for 20 years to even inspire a proposal for C++ modules.
>
> > Not that many additions to C++ are motivated by their presence in
> > other languages. In fact, if you exclude C89 and C99 I'm not sure any
> > C++ additions were motivated by other languages. The additions are
> > motivated by real problems that come to the committee's attention.
> > Then, experience in other languages may guide some design choices.
>
> I don't know about others, but this doesn't sound very effective to me.
> With a few exceptions, all languages do address real problems too, and
> with various levels of success and various resulting positions in the
> design space.
But those problems may be of lesser importance or even irrelevant to C+
+. See also my response to Walter Bright: I contend that the best way
to evolve a production language is to carefully identify and
prioritize the problems it must address. I also contend that it
should not be motivated by other languages doing this or that. (I'm
_not_ contending that C++ is doing a stellar job prioritizing those
problems, but it's not doing an awful job either IMO. Nor am I
claiming that other languages shouldn't influence how C++ designs the
solutions to problems it has decided to address. OTOH, I do know that
D did not motivate or influence the design of C++ modules, but D was
used as an argument by example that modules are likely feasible and
beneficial in that sort of language.)
> My opinion is that many aspects of C++ would have been
> designed vastly better if a harder look at how other languages solve the
> same problems would have been taken.
You're now talking about design: I was talking about motivation (and
compulsion).
I don't disagree that there is (and was) plenty of space for better
design in various areas. I don't think that the issue is "looking
harder" tough. It's more one of convincing the deciding parties to a
better compromise. All in all, I think standard C++ is doing a rather
nice job considering the very open and accessible process in which it
evolves.
> > (In fact, my sense is that proposals whose primary motivation is
> > "Language X has this therefore C++ should have it too" tend not to do
> > well before the committee.)
>
> While avoiding mindless imitation is very nice, such a concept risks of
> becoming a dogma a la "NIH". In particular, for a member of the
> committee who doesn't know, say, Python, Ruby, C#, or Perl, such a
> surrounding attitude provides a powerful disincentive to study them (I
> believe such study is extremely worthwhile).
Fortunately, there is in fact a culture within the committee of
looking at other languages. Except for Ruby, I happen to know that
all the languages you mention have active practitioners within the
committee and those languages have been looked at while designing
specific features in C++ (there may be active Ruby practitioners too,
but I couldn't tell).
Daveed
Daveed
wrote:
> James Kanze wrote:
> > 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.
>
> I've implemented floating point emulators. I'll repeat myself in saying
> that it is NOT a problem for a cross compiler to have an emulator for
> the target's floating point implementation. There's no magic mojo going
> on for non-IEEE arithmetic.
I'll second that. (They could alternatively also be specified so that
they can use a different representation than the target; they would
still be useful.)
Incidentally, floating-point template parameters were originally
allowed in the C++ working paper. The EDG front end can be configured
to allow them, and I believe Borland compilers allowed them (at least
in the early nineties). I have a note here saying that they were made
ill-formed in March 1994.
Daveed
Dave Harris
>> want something as basic as static type checking to vary from one
>> implementation to another.
>
> You have it anyway if you're using ints, since the size of ints can
> change from one implementation to another.
True, and implementation limits also vary between machines. However,
these
are much less of a problem in practice, partly because the language
specification has minimum requirements. Ints have to be at least 16
bits,
for example, so you can avoid problems with overflowing them in template
calculations. Usually it is not even an issue.
With floating point, it's harder to avoid the problem cases. Doing any
arithmetic at all is likely to be problematic. For example, it's
possible
for (a+b)+c to be unequal to a+(b+c).
-- Dave Harris, Nottingham, UK.
--
Walter Bright
> On Mar 1, 10:31 pm, Walter Bright <wal...@digitalmars-nospamm.com>
> wrote:
>> Daveedwrote:
>>> other languages.
>> C++ itself was motivated by another language - Simula67.
> No it wasn't:
>From Bjarne Stroustrup's "The C++ Programming Language", first edition,
pg. 4: "The other main source of inspiration was Simula67, ..."
It's pretty plain.
>> Fortran often
>> is envied in regards to its handling of numerics arrays, and there have
>> been many attempts to bring C/C++ into parity (noalias, restrict, blitz,
>> etc.).
> I'm not sure how this connects to your argument, but I'm guessing the
> argument is that C/C++ have been motivated by Fortran. Again, that is
> not the case:
I think you just don't like the word "motivate". C/C++ quite clearly
tried to move the language into parity with Fortran's ability to do
loops over arrays, because people were sticking with Fortran because it
was better at that. I remember reading the NCEG (Numerical C Extensions
Group) proposals in the late 80's early 90's, that repeatedly state
this. If that isn't what a "motivation" is, then I do not understand the
word at all. Even now, C++'s floating point performance is still
routinely compared against Fortran's, with the clear implication that
doing as well as Fortran is the goal.
>>From my local dictionary:
>
> motivate:
> verb [trans.]
> provide (someone) with a motive for doing something : "he was
> primarily motivated by the desire for profit."
>
> Mentioning another language having a feature does no equate to saying
> that that fact was the motive to consider it for C++. It can be as
> little as an acknowledgment of awareness or as much as proposal to
> take over the existing design whosesale, without it being a motive.
I think you just don't like the word "motivate" <g>. Let me put it
another way: any language (that isn't dead) wants to expand its appeal.
If another language has a feature that is so good it is attracting
programmers, then other languages tend to adopt those features, too.
Feature proposals may recast it as a "problem" that must be solved, but
there is little doubt, when one steps back a bit, that there is
competition among languages that drives the adoption of new features.
C++ is no exception. After all, C++ was born from trying to adapt
classes from Simula67 to C. It forthrightly says so in Bjarne's book:
"Most important, working with C enabled "C with Classes" to be a useful
(if awkward) tool within months of the first thought of adding
Simula-like classes to C."
> OTOH, deciding that a certain feature is
> needed in C++ because it was a great idea in another language seems
> like a recipe for disaster.
Of course one must supplement such an argument with reasoned arguments
about how such a feature would fit in with and help C++.
> Sure. It just shows that there was some motivation for modules early
> on. In fact, that motivation existed long before the list was set
> up. I was already lively debated at the very first committee meeting
> I attended (Santa Cruz 1996; the one where "extern templates" were
> removed -- they were replaced the next meeting by "export templates").
There didn't seem to be enough motivation to produce a design proposal.
> Incidentally, your point is also an argument showing that D had little
> influence on the C++ proposal: It takes no longer to mention that
> another language has a feature than to put that feature on a wish list
> (and the latter may take more creativity).
I don't agree at all - D's module system solves several severe and
pernicious problems with C++ templates. No other language that does
imports also has a template system remotely like C++'s. Modula-2 is a
relatively simple language by comparison, and is no demonstration that
complex features like templates can work with modules. D's does prove it
not only works, but solves the problems, as I explained in the Feb 2004
discussion. Knowing something works is a big sales point when lining up
support for a proposal. I can't agree with dismissing this influence,
but I've said my piece and am willing to agree to disagree.
Andrei Alexandrescu (See Website For Email)
> On Mar 1, 8:01 am, "Andrei Alexandrescu (See Website For Email)"
> <SeeWebsiteForEm...@erdani.org> wrote:
>> Daveedwrote:
>>> wrote:
>>> [...]
>>>> Which again emphasizes my point that M2 is not a compelling example - it
>>>> failed for 20 years to even inspire a proposal for C++ modules.
>>> Not that many additions to C++ are motivated by their presence in
>>> other languages. In fact, if you exclude C89 and C99 I'm not sure any
>>> C++ additions were motivated by other languages. The additions are
>>> motivated by real problems that come to the committee's attention.
>>> Then, experience in other languages may guide some design choices.
>> I don't know about others, but this doesn't sound very effective to me.
>> With a few exceptions, all languages do address real problems too, and
>> with various levels of success and various resulting positions in the
>> design space.
>
> +. See also my response to Walter Bright: I contend that the best way
> to evolve a production language is to carefully identify and
> prioritize the problems it must address. I also contend that it
> should not be motivated by other languages doing this or that.
Consider:
"We're not going to add X to just enter a silly bidding war with
language Y, which has X. Features must address problems that C++ users
have, not cater to language comparison checklists and mindless advocacy."
That's an attitude that I entirely agree with. Unfortunately, for, say,
a newcomer to the committee, it is too easy to slip into:
"If we need a feature we can invent our own. Please stop referring me to
how Y does it, I don't know Y nor I care to look into it."
Also focusing on the problems a language must address has the drawback
of fighting effects vs. fighting causes. In contrast, just understanding
how another language addresses the cause, and how that affects the
quality of the language, can be illuminating.
>>> (In fact, my sense is that proposals whose primary motivation is
>>> "Language X has this therefore C++ should have it too" tend not to do
>>> well before the committee.)
>> While avoiding mindless imitation is very nice, such a concept risks of
>> becoming a dogma a la "NIH". In particular, for a member of the
>> committee who doesn't know, say, Python, Ruby, C#, or Perl, such a
>> surrounding attitude provides a powerful disincentive to study them (I
>> believe such study is extremely worthwhile).
>
> Fortunately, there is in fact a culture within the committee of
> looking at other languages. Except for Ruby, I happen to know that
> all the languages you mention have active practitioners within the
> committee and those languages have been looked at while designing
> specific features in C++ (there may be active Ruby practitioners too,
> but I couldn't tell).
Well that's all good and can only foster a good attitude. To conclude, I
stay with my opinion that your earlier statement:
------------------------------------------
> Not that many additions to C++ are motivated by their presence in
> other languages. In fact, if you exclude C89 and C99 I'm not sure any
> C++ additions were motivated by other languages. The additions are
> motivated by real problems that come to the committee's attention.
> Then, experience in other languages may guide some design choices.
>
> (In fact, my sense is that proposals whose primary motivation is
> "Language X has this therefore C++ should have it too" tend not to do
> well before the committee.)
------------------------------------------
needs to be amended quite a bit to convey the intended meaning in full.
kwikius
wrote:
> James Kanze wrote:
> >> The D programming language
>
> > Is not the subject here.
>
> It is when the topic is why can't C++ handle string and floating point
> literals as template arguments?
FWIW the ability to manipulate floating point values at compile-time
does start to make D look an attractive option compared to C++ for me,
especially since AFAICS There is no great willingness to change things
in C++.
regards
Andy Little
James Kanze
wrote:
> Daveed wrote:
> > On Feb 27, 5:23 pm, Walter Bright <wal...@digitalmars-nospamm.com>
> > wrote:
> > [...]
> >> Which again emphasizes my point that M2 is not a compelling
> >> example - it failed for 20 years to even inspire a proposal
> >> for C++ modules.
> > Not that many additions to C++ are motivated by their
> > presence in other languages.
I think I understand what Daveed is saying---that the features
weren't added to C++ simply because they were present in another
language. Ideas from other languages have certainly contributed
to C++, however (as I'm sure Daveed knows).
> C++ itself was motivated by another language - Simula67. Fortran often
> is envied in regards to its handling of numerics arrays, and there have
> been many attempts to bring C/C++ into parity (noalias, restrict, blitz,
> etc.).
> > In fact, if you exclude C89 and C99 I'm not sure any
> > C++ additions were motivated by other languages.
> The contracts proposal specifically mentions D (and Eiffel). Your
> proposal mentions Modula. The concept proposal compares with several
> other languages.
C++ (like D, I believe) does not try to innovate. When a
problem is perceived, the committee (and before that Stroustrup
and his collegues) look around, to see how it has been solved in
other languages. They build (usually, at least) on known
technology.
In some cases, specific concepts are very strongly associated
with one particular language: C++'s classes definitly came from
Simula67, originally (although I suspect that Smalltalk
influenced them somewhat in time as well), and Eiffel cannot be
neglected by anyone considering programming by contract, anymore
than someone doing numerics can ignore Fortran.
In the case of modules, Daveed is the author of the proposal
(and for a long time the only person working on it), and I say
no reason to disbelieve him when he says that the motivation was
problems he had doing something else, and the model he took was
Modula-2.
> > The additions are
> > motivated by real problems that come to the committee's attention.
> > Then, experience in other languages may guide some design choices.
> > (In fact, my sense is that proposals whose primary motivation is
> > "Language X has this therefore C++ should have it too" tend not to do
> > well before the committee.)
> If you're right, that C++ improvements are not motivated by other
> languages, but only by "problems", that's not a good sign. There are an
> awful lot of great ideas in other languages. If C++ is to be successful
> in the future, it'll have to look outward rather than just inward.
There's a old saying: if it ain't broke, don't fix it. If there
are (or were) no problems in C++, there'd be no point in
changing the language. The motivation for the change should be
to solve a problem, not to get on a bandwagon.
Once a problem is perceived, of course, C++ should look to how
it has been solved elsewhere, rather than try to invent a new
and untried solution of its own. I use C++ in production code,
and the last thing I need is untried, experimental solutions.
> >> In this case, 20 years go by and modules don't get put in
> >> C++, then a few months after discussing D modules with
> >> Daveed, he proposes them for C++.
If it was only a few months, then that discussion obviously
couldn't have played much of a role in motivating him. If you
look at the modules proposal, you'll know that there is a lot
more than just a few months work involved in it. (Remember too
that Daveed is doing this on the side, in addition to his
regular work. It takes a lot of time to write up a good
proposal for a complicated feature.)
> >> While Daveed says that D
> >> modules didn't inspire him, he did use D modules as an
> >> example to try to motivate others to support C++ modules.
> > As I said, the timing is purely coincidental. Modules (unlike D) were
> > frequently being brought up in committee meetings (although for a long
> > time no real formal work took place). I may have discussed them with
> > you (most likely in the context of export), but then again, throughout
> > the export implementation we brought them up also (and that wasn't the
> > motivation either). In fact, modules were on the original "broadest
> > wish list" for C++0x extensions.
> A wish list is one thing, it takes a second to type in "modules." Making
> the effort to put together a well engineered proposal is quite another.
The author of the proposal has explained his motivations. Are
you putting them into doubt.
Look. D is not the center of everyone's universe. The committee
members put an extremely large amount of work into their
proposals. They don't just look at D, and say, well D has it,
so we need it. The original motivation is always (or almost
always---but I don't know of any exceptions) a real problem,
which shows up in actual use of the language. A responsible
committee member will then look at all existings solutions, in
all other languages, to see what might be applicable to C++;
just inventing something off the top of one's head is not very
reponsible, and I'm not aware of any committee member doing
such. The result is, obviously, that regardless of the
motivation, or even the solution finally adopted, a serious
proposal will mention D if D implements some solution to the
given problem---I think even the proposal for garbage collection
has been updated to mention D, and you certainly can't claim D
is a motivation for Hans Boehm there. If David's proposal, or
the proposal for programming by contract, didn't mention D, they
would be lax. But just because they mention D certainly can't
be taken to mean that D provided the motivation.
IMHO, it's not particularly surprising that many of the problems
the standard committee finds in C++, and is addressing, are
problems you also found in C++, and addressed in D. The
contrary, in fact, would surprise me. This doesn't mean that D
is influencing C++; it means that intelligent people, given the
same circumstances (i.e. the current state of C++) find the same
problems, and to some degree, the same solutions. Even if D had
never existed, garbage collection would be part of the next
version of C++, Daveed would have made his proposal for modules,
and I'm pretty sure that there would have been a proposal for
programming by contract as well. (I was doing programming by
contract in C++ long before I'd ever heard of D, for example,
and the author's of the proposal were aware of what I was doing.
Who knows: maybe I was the motivation for the proposal:-). Far
more likely, of course, is that they had read some of Meyers
seminal work on the subject, and thought that it might be
applicable to C++.) D's a nice additional data point, showing
that other intelligent people are thinking along the same lines,
but it's not really a motivation, nor even necessarily a model
per se.
--
James Kanze (GABI Software) email:james...@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
--
James Kanze
wrote:
> James Kanze wrote:
> > 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.
> I've implemented floating point emulators. I'll repeat myself in saying
> that it is NOT a problem for a cross compiler to have an emulator for
> the target's floating point implementation. There's no magic mojo going
> on for non-IEEE arithmetic.
It's certainly possible. I've even done parts of one myself, in
the past. (It might be a problem if the target floating point
was non-deterministic, but I don't think we really have to
consider such cases.) It is, however, a fair bit of work, and
for whatever reasons, the C committee made the decision, many,
many years back, to not require it.
Maybe, however, that decision should be reconsidered. I suspect
that space considerations, at a time when compilers had to run
on machines with only 64 Kb, or less, might have been an
important consideration. Which probably isn't relevant today.
To return to the initial point: I'm not against allowing
templates to have floating point parameters. I just don't think
that it should be automatic; there are problems which have to be
addressed. And while I also think that there are acceptable
solutions to those problems, to my knowledge, to date no one has
done the work, and written a proposal addressing them. And if
there is one thing which will guarantee that a feature doesn't
make it into the next version of C++, it is not having a
proposal to add it. The fact that it is implemented in D does
not suffice. If no one thinks it's important enought to write a
proposal, it won't get added.
--
James Kanze (Gabi Software) email: james...@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
--
Andrei Alexandrescu (See Website For Email)
> I think I understand what Daveed is saying---that the features
> weren't added to C++ simply because they were present in another
> language. Ideas from other languages have certainly contributed
> to C++, however (as I'm sure Daveed knows).
That's my understanding too.
> C++ (like D, I believe) does not try to innovate.
We must be seeing C++ in radically different ways... templates were as
far as I understand very innovative, as was (to a lesser extent, Ada
marking a weaker precedent) marrying full-fledged exceptions with a
statically-typed language.
Andrei
Walter Bright
> Maybe, however, that decision should be reconsidered. I suspect
> that space considerations, at a time when compilers had to run
> on machines with only 64 Kb, or less, might have been an
> important consideration. Which probably isn't relevant today.
It wasn't relevant then, either. Nobody ever got a C++ compiler to run
in 64K <g>. 640K, yes, but that ceased to be a consideration around 1990
or so.
I remember being on a C compiler panel discussion at SDWest sometime in
the 80's. I was representing Zortech, and there were representatives
from Microsoft, Borland, etc. The first question posed was "do you have
a version of your compiler that works on floppy disk only systems?" The
first representative said yes, here's how to do it, you load this file,
that file, fiddle here, fiddle there, etc. The second said yes, we have
a special build for that, etc. Finally it gets to me. I said yes, we
have a floppy only edition for an extra $200, and it comes with a hard
disk drive.
That was literally the end of that issue. It never, ever came up again.
> To return to the initial point: I'm not against allowing
> templates to have floating point parameters. I just don't think
> that it should be automatic; there are problems which have to be
> addressed. And while I also think that there are acceptable
> solutions to those problems, to my knowledge, to date no one has
> done the work, and written a proposal addressing them. And if
> there is one thing which will guarantee that a feature doesn't
> make it into the next version of C++, it is not having a
> proposal to add it. The fact that it is implemented in D does
> not suffice. If no one thinks it's important enought to write a
> proposal, it won't get added.
And that's as it should be. All I'm doing is pointing out that its
experience in the D programming language shows that it is useful and
implementable. The rest is up to whoever might be motivated to put it in
C++.
Mathias Gaunard
> Right now I'm trying to figure out is if string processing is even
> possible at compile time using templates. So far after much searching
> I've only found numeric operations in the metaprogramming examples and
> no string examples and I'm wondering if this is for a reason i.e. that
> C++ can't process strings in this way. Any ideas?
Seems it hasn't been mentioned, you could just use the metaprogramming
library of Boost, MPL.
You can represent strings that way for example:
typedef boost::mpl::vector_c<char, 't', 'h', 'i', 's', ' ', 'i', 's',
' ', 'a', 'n', ' ', 'e', 'x', 'a', 'm', 'p', 'l', 'e'> mystring;
MPL provides containers, iterators and algorithms similar to the STL
but which work at compile-time.
They're mainly used to hold types but they can hold integers too.
Note, however, that writing algorithms with that kind of thing is not
as easy as with normal C++.
As you can see, your string isn't a variable here: it's a type. It's a
whole different mechanism.
Walter Bright
> There's a old saying: if it ain't broke, don't fix it.
That's what Douglas thought about designing jetliners - turboprops work
great, and are proven technology. Boeing blew right by them when the
airliners discovered that jetliners had half the operating costs, and
Douglas was reduced to a shadow.
James Kanze
wrote:
> James Kanze wrote:
> > Maybe, however, that decision should be reconsidered. I suspect
> > that space considerations, at a time when compilers had to run
> > on machines with only 64 Kb, or less, might have been an
> > important consideration. Which probably isn't relevant today.
> It wasn't relevant then, either. Nobody ever got a C++ compiler to run
> in 64K <g>.
The attitide predates C++; from what I've heard, the earliest C
compiler ran on a machine with only 12Ko (but I suspect that
that's just urban folklore). The position of C++ on this is
simply based on C compatibility.
> 640K, yes, but that ceased to be a consideration around 1990
> or so.
Maybe a little later, but I agree that it really shouldn't be a
consideration today.
Just curious: does it (or could it) affect other things than
template arguments. Could we extend the notion of "integral
constant expression" to one of "arithmetic constant expression",
and allow things like:
char array[ size_t( 3.5 * 2 ) ] ;
?
--
James Kanze (Gabi Software) email: james...@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
--
James Kanze
somewhat off-topic in clc++m: regardless of the possibly incomplete
state of that discussion, stronger topicality judgement will be applied
to follow-ups (this article accepted as direct response). ;-) -mod/aps }
On Mar 4, 8:30 am, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
> James Kanze wrote:
> > There's a old saying: if it ain't broke, don't fix it.
> That's what Douglas thought about designing jetliners - turboprops work
> great, and are proven technology. Boeing blew right by them when the
> airliners discovered that jetliners had half the operating costs, and
> Douglas was reduced to a shadow.
What does this have to do with anything we're discussing (or
with C++)? (Aside from being false---I think you're thinking of
Lockheed, not Douglas, who was for a long time the second
biggest constructor of jetliners.)
Also, of course, turboprops were actually more experimental than
jet engines at the time; jets were widely used in military
aircraft. Boeing didn't innovate in producing the 707. There
were earlier, experimental, jetliners, such as the Sud Aviation
Caravelle or the de Havilland Comet which didn't catch on. The
de Havilland Comet is, in fact, a good example as to why you
don't want to much state of the art in production tools: it
generated a lot of excitement when it first appeared (as the
first jet airliner); regretfully, it turned out to have one
small defect---it tended to loose its wings in flight. It was
Boeing's experience with large jet aircraft like the B-52 which
put it in the driver's seat with regards to commercial
jetliners.
To get back to C++ (sort of): no one is saying that there should
be no research into new technologies, nor that what isn't broken
today might be considered so in the future, as a result of new
technologies. (When I look at the C++ I wrote 15 years ago, I
would consider it broken by my standards today. But back then,
I was proud of it.) The rôle of C++ amongst the many languages
available isn't to invent new features; it's to leverage off
inventions that have proved themselves in other languages. And
when it does play an innovative rôle, as is the case with
template meta-programming, it's more or less serendipity;
templates weren't designed with meta-programming in mind, and it
was only after the fact that one or two geniuses realized all
that could be done with them. (And of course, even today, most
serious companies don't allow programmers to define templates at
the application level---templates are restricted to standard
components which don't change, because of the source code
coupling issues.)
--
James Kanze (Gabi Software) email: james...@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
--
James Kanze
<SeeWebsiteForEm...@erdani.org> wrote:
> James Kanze wrote:
> > I think I understand what Daveed is saying---that the features
> > weren't added to C++ simply because they were present in another
> > language. Ideas from other languages have certainly contributed
> > to C++, however (as I'm sure Daveed knows).
> That's my understanding too.
> > C++ (like D, I believe) does not try to innovate.
> We must be seeing C++ in radically different ways... templates were as
> far as I understand very innovative, as was (to a lesser extent, Ada
> marking a weaker precedent) marrying full-fledged exceptions with a
> statically-typed language.
Both were state of the art existing practice when they were
adopted into C++. The only "innovation" was in making them less
restrictive in C++, and that innovation was fully in keeping
with the philosophy of C/C++: that the programmer knows best.
As it happens, C++'s templates are extremely innovative, but
back arround 1990, when they were being proposed, no one
realized all of the innovative things that could be done with
them. It was a question of adopting existing practice which had
proven benefits in other languages.
--
James Kanze (Gabi Software) email: james...@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
--
kwikius
wrote:
<...>
> template sqrt(real x, real root = x/2, int ntries = 0)
> {
> static if (ntries == 5)
> // precision doubles with each iteration,
> // 5 should be enough
> const sqrt = root;
> else static if (root * root - x == 0)
> const sqrt = root; // exact match
> else
> // iterate again
> const sqrt = sqrt!(x, (root+x/root)/2, ntries+1);}
>
> void main()
> {
> real x = sqrt!(2);
> writefln("%.20g", x); // 1.4142135623730950487
>
> }
I Finally got around to trying out D and I do think that studying The
D metaprogramming scheme would be very instructive for C++. e.g in
relation to:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1471.pdf.
Of course D has had the benefit of hindsight, which is always a
wonderful thing and much of the way D does templates is probably not
directly transferrrable to C++
Nevertheless, though I have only been playing with D for half a day,
IMO there is certainly a lot to be gained from examining the D way of
doing things.
metaprogramming is certainly a powerful tool, but in C++ it is seen as
something to be done by experts only, and there has been much truth in
that. After all metaprogramming was basically discovered by accident.
In fact it is getting easier in C++. Earlier attempts at
metaprogramming have been frustrated by compiler non-conformity
problems, but compilers are improving. Nevertheless it still requires
quite a deep knowledge of the way templates works and their foibles.
One of the regular questions on comp.lang.c++ is "Why doesnt such and
such template code compile? I have spent hours trying to find the
problem." Before even looking at the code, it is possible to guess
that a large percentage of the time the answer is 'typename'. It is
these sort of large number of minor details that you just have to know
that are problematic. Thanks to a recent poster on clc++ for this
insight ;-)
In D a template is more of a template namespace (Its AFAIK not bound
to a particular class or function, and might be worth examining from
the viewpoint of template namespaces) and you also have the static if
construct. This immediately helps because conditionals are familiar
ground from runtime experience and "static if" also helps because it
uses lazy evaluation, which you can emulate in C++ but can bite you in
C++ both through unwanted SFINAE and through getting errors trying to
instantiate impossible types in complex metaprogramming expressions,
with accompanying Huge error messages.
These are just some of the sorts of solutions that should lower the
barrier to metaprogramming dramatically.
The other useful practical isue with templates in D seems to be that
for a given construct compilation is a lot faster. I havent verified
this yet for anything complicated, but from the small experience I
have gained so far this seems to be the case. Again this is
unsurprising due to hindsight, but, if so, this is another factor in
lowering the entry barrier to metaprogramming, and incidentally
increasing productivity and reducing development time and also
learning time. You can simply do more compiles in the same time.
So far the things I don't like about D are the use of modules/
packages, as I am use to #includes and directories. I generally start
off with namespaces in my source file then cut em out into a header.
In D you are it seems kind of tied to your package system
and I sure miss:
std::cout << x <<'\n';
regards
Andy Little
Francis Glassborow
Kanze <james...@gmail.com> writes
>The attitide predates C++; from what I've heard, the earliest C
>compiler ran on a machine with only 12Ko (but I suspect that
>that's just urban folklore). The position of C++ on this is
>simply based on C compatibility.
I see no reason to think that. The machine I learnt my programming on
was an IBM 1130 mini with a massive 8K of 16-bit words (and apart from
addresses 0-7 which were ttl and doubled up as registers, the memory was
magnetic core) with a single Winchester (sorry I do not recall the
capacity of that but it would certainly have been small compared with
modern backing storage. Nonetheless it supported a full Fortran IV
compiler.
I also had a full C compiler running on a Sinclair Spectrum (with 48K of
RAM and a cassette drive)
C++ is more demanding but the Zortech compiler was not that demanding
of resources.
While I would not advocate going back to such resource constrained
systems, it is important to realise that skilled implementors managed to
get quarts into what we might now consider to be teacups.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions:
http://www.spellen.org/youcandoit/projects
kwikius
The rôle of C++ amongst the many languages
> available isn't to invent new features; it's to leverage off
> inventions that have proved themselves in other languages.
I've heard that a couple of times in this thread, but in the upcoming C
+ standard the revolution AFAICS will be Concepts. (It may be just an
academic revolution. It is unclear how long it will take for indutry
to catch up and whether other technologies wil intervene and supercede
in the meantime) I'm not too clear on whether Concepts exist in other
(used) languages, but they are a big shift and also relatively
unproven in C++. They are also a big and complex feature to implement.
If Concepts take off then I reckon there will be a big shift.
Ultimately I can see that you will be programming solely in terms of
Concepts with the Concepts themselves selecting the best types to use
for a given situation. I have used this approach in a limited way
where floats or integers are used for the result of a calculation
dependent on whether the result can be held in an integer without loss
of precision, however another example that came up a while ago was
using Concept criteria to select a color model depending on certain
criteria.
So in case of Concepts they do seem to be bound for the standard but
they are certainly not proven. They just seem at the moment to be an
awfully good idea ;-)
regards
Andy Little
Andrei Alexandrescu (See Website For Email)
> On Mar 3, 6:55 pm, "Andrei Alexandrescu (See Website For Email)"
> <SeeWebsiteForEm...@erdani.org> wrote:
>>> I think I understand what Daveed is saying---that the features
>>> weren't added to C++ simply because they were present in another
>>> language. Ideas from other languages have certainly contributed
>>> to C++, however (as I'm sure Daveed knows).
>
>> That's my understanding too.
>
>>> C++ (like D, I believe) does not try to innovate.
>
>> We must be seeing C++ in radically different ways... templates were as
>> far as I understand very innovative, as was (to a lesser extent, Ada
>> marking a weaker precedent) marrying full-fledged exceptions with a
>> statically-typed language.
>
> adopted into C++.
In what languages?
> The only "innovation" was in making them less
> restrictive in C++, and that innovation was fully in keeping
> with the philosophy of C/C++: that the programmer knows best.
>
> As it happens, C++'s templates are extremely innovative, but
> back arround 1990, when they were being proposed, no one
> realized all of the innovative things that could be done with
> them. It was a question of adopting existing practice which had
> proven benefits in other languages.
Well if people who pioneered and promoted templates in C++ (of whom
Stroustrup deserves the most credit) would have had the conservative
bias that C++ is not out there to innovate, you can be sure that we'd be
all much worse off. I can't believe I'm even having this conversation. :o)
Walter Bright
> Just curious: does it (or could it) affect other things than
> template arguments. Could we extend the notion of "integral
> constant expression" to one of "arithmetic constant expression",
> and allow things like:
>
> char array[ size_t( 3.5 * 2 ) ] ;
>
> ?
I don't see why not. It works in the D programming language.
{ It also works with some C++ compilers, e.g. MSVC 7.1 and g++ 3.4.4,
although not accepted by Comeau Online. Which is probably more relevant
to what C++ can or should support, thus on-topic. Hint, hint. -mod }
Walter Bright
> C++ is more demanding but the Zortech compiler was not that demanding
> of resources.
C++ was also a much simpler language back in 1988 <g>, and of course the
size of C++ programs was much smaller.
--
Tony Delroy
> that could be done with them. (And of course, even today, most
> serious companies don't allow programmers to define templates at
> the application level---templates are restricted to standard
> components which don't change, because of the source code
> coupling issues.)
The problem is when the templates are used for volatile (as in, often
changed) library code. Within the application level, a recompile
isn't a serious issue.
Daveed
> On 4 Mar, 12:22, "James Kanze" <james.ka...@gmail.com> wrote:
> The rôle of C++ amongst the many languages
>
> > available isn't to invent new features; it's to leverage off
> > inventions that have proved themselves in other languages.
>
> I've heard that a couple of times in this thread, but in the upcoming C
> + standard the revolution AFAICS will be Concepts.
We'll see whether it'll be a revolution (hopefully it will be a good
one), but it's indeed the largest core language extension planned for C
++0x (in terms of specification and implementation).
> (It may be just an
> academic revolution. It is unclear how long it will take for indutry
> to catch up and whether other technologies wil intervene and supercede
> in the meantime) I'm not too clear on whether Concepts exist in other
> (used) languages, but they are a big shift and also relatively
> unproven in C++. They are also a big and complex feature to implement.
Agreed.
> If Concepts take off then I reckon there will be a big shift.
> Ultimately I can see that you will be programming solely in terms of
> Concepts with the Concepts themselves selecting the best types to use
> for a given situation. I have used this approach in a limited way
> where floats or integers are used for the result of a calculation
> dependent on whether the result can be held in an integer without loss
> of precision, however another example that came up a while ago was
> using Concept criteria to select a color model depending on certain
> criteria.
I'm not sure I fully see that part, but certainly the proposal on the
table is a very powerful one. In addition to addressing the issue of
diagnostics in instantiations (rarely pretty in C++03
implementations), it does introduce concept-based overloading (which I
think is what you allude to), and also "concept mapping" which allows
a component that wasn't aware of the requirements of a certain generic
library to be relatively painlessly adapted for that library if the
concepts (as opposed to the interfaces) it embodies are sufficiently
compatible with the library. A typical example of the latter are the
hosts of "iterator-like" things out there that don't actually follow
the standard library conventions for iterators: Concept maps will
often allow for efficient adaptation in such cases.
> So in case of Concepts they do seem to be bound for the standard but
> they are certainly not proven. They just seem at the moment to be an
> awfully good idea ;-)
You're right that there is a fair bit of invention going on here, and
that's a very real risk. OTOH, I think that it's WG21's willingness
to take such risks (and invent) that makes C++ stand out as one of the
very few true "committee languages" to be still very much alive and
evolving.
That said, the Concepts proposal has some very credible foundations
both by drawing on sound theoretical experience (e.g., from the
SuchThat generic programming language) and by actually coming with a
complete implementation (including a complete adaptation of the
standard library).
Daveed
Walter Bright
> Well if people who pioneered and promoted templates in C++ (of whom
> Stroustrup deserves the most credit) would have had the conservative
> bias that C++ is not out there to innovate, you can be sure that we'd be
> all much worse off. I can't believe I'm even having this conversation. :o)
I should add that at the time (1990 or so), I was against templates and
didn't see much of any value in them. Stroustrup deserves a lot of
credit for championing them - he was right, and I was wrong. Ditto for
exception handling.
Exception specifications were, well, nobody bats 1000!
James Kanze
> On Mar 4, 9:22 pm, "James Kanze" <james.ka...@gmail.com> wrote:
> > that could be done with them. (And of course, even today, most
> > serious companies don't allow programmers to define templates at
> > the application level---templates are restricted to standard
> > components which don't change, because of the source code
> > coupling issues.)
> The problem is when the templates are used for volatile (as in, often
> changed) library code. Within the application level, a recompile
> isn't a serious issue.
The problem is that when templates are used, there is extensive
source level coupling, which management rejects per se. (In
every actual case I've encountered, it has been manageable.)
--
James Kanze (GABI Software) email:james...@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
--
James Kanze
> Andrei Alexandrescu (See Website For Email) wrote:
> > Well if people who pioneered and promoted templates in C++ (of whom
> > Stroustrup deserves the most credit) would have had the conservative
> > bias that C++ is not out there to innovate, you can be sure that we'd be
> > all much worse off. I can't believe I'm even having this conversation. :o)
> I should add that at the time (1990 or so), I was against templates and
> didn't see much of any value in them.
That's interesting, because where I was working in 1990, they
almost rejected C++ because it lacked generics, whereas the
other languages under consideration (Ada, Eiffel) both supported
them. (I'm pretty sure that they both had exceptions as well,
but that wasn't considered critical in our evaluation at the
time.)
C++, of course, had <generic.h>, which is about the strongest
argument for templates I can think of:-). The point being, of
course, that C++ didn't just run in to implement something
because it could. The technique had already been proven in
other languages, and there was a proven need for it in C++.
> Stroustrup deserves a lot of
> credit for championing them - he was right, and I was wrong. Ditto for
> exception handling.
Certainly. He also deserves a lot of credit for making them
even more flexible than they were in the predecessors. But they
can hardly be considered radical innovations when they were
introduced in C++.
--
James Kanze (GABI Software) email:james...@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
--
James Kanze
> James Kanze wrote:
> > On Mar 3, 6:55 pm, "Andrei Alexandrescu (See Website For Email)"
> > <SeeWebsiteForEm...@erdani.org> wrote:
> >> James Kanze wrote:
> >>> I think I understand what Daveed is saying---that the features
> >>> weren't added to C++ simply because they were present in another
> >>> language. Ideas from other languages have certainly contributed
> >>> to C++, however (as I'm sure Daveed knows).
> >> That's my understanding too.
> >>> C++ (like D, I believe) does not try to innovate.
> >> We must be seeing C++ in radically different ways... templates were as
> >> far as I understand very innovative, as was (to a lesser extent, Ada
> >> marking a weaker precedent) marrying full-fledged exceptions with a
> >> statically-typed language.
> > Both were state of the art existing practice when they were
> > adopted into C++.
> In what languages?
Ada has had generics since 1985. Modula-3 certainly had
exceptions before C++ as well (and Modula-3 is more strictly
statically typed than C++). From what I understand, they were
introduced into those two languages as "existing practice", so
presumably, they go back even further.
--
James Kanze (GABI Software) email:james...@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
--
James Kanze
> In article <1173005017.4...@64g2000cwx.googlegroups.com>, James
> Kanze <james...@gmail.com> writes
> >The attitide predates C++; from what I've heard, the earliest C
> >compiler ran on a machine with only 12Ko (but I suspect that
> >that's just urban folklore). The position of C++ on this is
> >simply based on C compatibility.
> I see no reason to think that. The machine I learnt my programming on
> was an IBM 1130 mini with a massive 8K of 16-bit words (and apart from
> addresses 0-7 which were ttl and doubled up as registers, the memory was
> magnetic core) with a single Winchester (sorry I do not recall the
> capacity of that but it would certainly have been small compared with
> modern backing storage. Nonetheless it supported a full Fortran IV
> compiler.
You're almost as old as I am: my first "evolved" language was
PL-1, on a machine with 16 Kb, and removable hard disks. It
worked thanks to lots of overlays, and compile times which were
measured in hours.
But just because we had to struggle with such beasts doesn't
mean that Bell labs was that cheap. Bigger machines did exist,
and the PDP-11 supported up to 62 Kb from the start. And while
it's fully possible that Richie did only have 12 Kb on his
machine, all of the sources I know for this correspond to the
sort of sources which typically do return urban legends. So
while I find that it makes a nice story, I'll take it with a
grain of salt.
> C++ is more demanding but the Zortech compiler was not that demanding
> of resources.
I almost mentioned the Zortech compiler myself, since I'm sure
that Walter is very familiar with it:-). But I only used it
under MS-DOS, on a machine which had 256 Kb memory, so I'm not
sure what it really required. (It was a .exe, and not a .com,
if I recall correctly. So it wasn't subject to any 64Kb limit.)
And I don't think that even Walter would like to try to
implement modern C++ under such conditions.
> While I would not advocate going back to such resource constrained
> systems, it is important to realise that skilled implementors managed to
> get quarts into what we might now consider to be teacups.
Certainly. The question is whether language restrictions to
make it easier for them to do so are still relevant today.
--
James Kanze (GABI Software) email:james...@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
--
kwikius
> That said, the Concepts proposal has some very credible foundations
> both by drawing on sound theoretical experience (e.g., from the
> SuchThat generic programming language) and by actually coming with a
> complete implementation (including a complete adaptation of the
> standard library).
Power to Douglas Gregor and everyone working on ConceptGCC, but AFAIK
the implementation is a long way from complete. In particular concept
definitions with member templates are as far as I know not yet
implemented. If I'm wrong I apologise, but as I understand it that is
the current status of ConceptGCC.
I would like to say thanks to Douglas Gregor for the huge amount he
has done on the project.
I'm just trying to get the facts straight here :-)
regards
Andy Little
Daveed
> On 5 Mar, 06:55, "Daveed" <vandevoo...@gmail.com> wrote:
>
> > That said, the Concepts proposal has some very credible foundations
> > both by drawing on sound theoretical experience (e.g., from the
> > SuchThat generic programming language) and by actually coming with a
> > complete implementation (including a complete adaptation of the
> > standard library).
>
> Power to Douglas Gregor and everyone working on ConceptGCC, but AFAIK
> the implementation is a long way from complete. In particular concept
> definitions with member templates are as far as I know not yet
> implemented. If I'm wrong I apologise, but as I understand it that is
> the current status of ConceptGCC.
>
> I would like to say thanks to Douglas Gregor for the huge amount he
> has done on the project.
>
> I'm just trying to get the facts straight here :-)
I was a little loose with my use of "complete" (I probably
misremembered a verbal report), but looking at
http://www.generic-programming.org/software/ConceptGCC/
I think your info may be out of date as well. It looks like it's
relatively complete feature-wise (though it's not quite an industrial-
strength implementation at this point).
Daveed
Jerry Coffin
james...@gmail.com says...
[ ... ]
> Ada has had generics since 1985.
FWIW, that as actually 1983. It also had exceptions in 1983.
> Modula-3 certainly had
> exceptions before C++ as well (and Modula-3 is more strictly
> statically typed than C++). From what I understand, they were
> introduced into those two languages as "existing practice", so
> presumably, they go back even further.
My nominees for the origins:
AFAIK, the first real language defined to include exception handling was
PL/I. The idea may have been floated in the Algol committee before PL/I
adopted it, but PL/I was defined before that work matured into a
standard (i.e. PL/I was defined by 1964, and there wasn't a finished
version of the next Algol standard until 1968).
Depending on your viewpoint, you could pretty easily trace generics back
to Lisp -- unless you take steps to prevent it, a Lisp function to do
something like add two things together can be applied to any two things
for which that operator is defined.
Among languages with strong typing, CLU was probably the first to
support generics. It wasn't really a lot like C++ or Ada generics, but
it included "generators" that allowed you to instantiate a cluster (more
or less like a class) over various other types to produce (for example)
a set[int] or set[char]. CLU used an explicit declaration of the
operations needed for instantiation, so the 'set' type above would be
declared something like:
set = cluster [t: type] is create, includes, size, insert, delete
where t has equal: proctype(t, t) returns(bool)
The compiler then checks that your implementations of create, includes,
size, insert and delete only use the specified members of 't' (only
equal, in this case).
Even though Ada was explicitly stated to be based (to at least some
extent) on Pascal, it seems (to me) to resemble CLU at least as closely.
--
Later,
Jerry.
The universe is a figment of its own imagination.
kwikius
> On Mar 5, 9:52 am, "kwikius" <a...@servocomm.freeserve.co.uk> wrote:
> > I'm just trying to get the facts straight here :-)
>
> I was a little loose with my use of "complete" (I probably
> misremembered a verbal report), but looking at
> http://www.generic-programming.org/software/ConceptGCC/
> I think your info may be out of date as well.
Maybe. So, To check my facts I downloaded the latest version of
conceptGCC this morning. The error message at the end seems clear
enough:
#include <concepts>
concept SomeValueType<typename T>{
template <typename Rhs>
where std::Addable<T,Rhs>
// is this allowed?
&& SomeValueType<Rhs>
std::Addable<T,Rhs>::result_type
operator +(T, Rhs);
// OTOH Maybe this should work?
// Here Rhs is a model of SomeValueType but not necessarily the
same as in the parameter
/*
template <SomeValueType Rhs>
where std::Addable<T,Rhs>
std::Addable<T,Rhs>::result_type
operator +(T, Rhs);
*/
};
/* output:
test.cpp:16: error: pseudo-signature template<class T> template<class
Rhs> stati
c std::Addable<T, Rhs>::result_type SomeValueType::operator+(const T&,
const Rhs
&) is not permitted in a concept
test.cpp:16: note: this feature is currently unsupported, but will be
in a futur
e version
make: *** [test.o] Error 1
// conceptg++ version:
conceptg++ (GCC) 4.1.1 (Indiana University ConceptGCC alpha 5)
*/
Tony Delroy
> Tony Delroy wrote:
> > On Mar 4, 9:22 pm, "James Kanze" <james.ka...@gmail.com> wrote:
> > > that could be done with them. (And of course, even today, most
> > > serious companies don't allow programmers to define templates at
> > > the application level
> per se. (In every actual case I've encountered, it has been manageable.)
Sounds like an issue with your particular management. You yourself
are saying it's not technically justified, so I can only assume you've
non-technicals micromanaging or technical-incompetents mismanaging
your coding guidelines. My sympathies. I've never worked in a
company where I couldn't use templates at my own discretion.
kwikius
Further, I suspect you cant actually define e.g std::Integral<T>
correctly without this, and that the current version in conceptGCC
4.1.1-alpha 5 is incorrect. E.g.
char + char is AFAIK an int not a char:
concept Integral<typename T> {
...
T operator+(T, T); // doesnt work for char among others
}
// also
// some function with std::Integral constraint
int x;
long y;
x + y; // error no operator+.
etcetera.
In fact I think that defining Addable etc for inbuilt types will
require some scheme such as I played around with to get Concepts
working for my Quan library. (There is a kind of cheicken egg
situation I think)
#include <concepts>
// type deduction
// with default testable invalid op case
#include <quan/meta/binary_operation.hpp>
// set up basic op concepts
namespace quan{ namespace concepts{
auto concept Multiplicable<typename TL, typename TR> {
typename result_type = quan::meta::binary_operation<
TL,
quan::meta::times,
TR
>::type;
where !std::SameType<result_type,boost::mpl::void_>;
result_type operator *(TL,TR);
};
auto concept Addable<typename TL, typename TR> {
typename result_type = quan::meta::binary_operation<
TL,
quan::meta::plus,
TR
>::type;
where !std::SameType<result_type,boost::mpl::void_>;
result_type operator +(TL,TR);
};
auto concept Subtractable<typename TL, typename TR> {
typename result_type = quan::meta::binary_operation<
TL,
quan::meta::minus,
TR
>::type;
where !std::SameType<result_type,boost::mpl::void_>;
result_type operator -(TL,TR);
};
auto concept Divisible<typename TL, typename TR> {
typename result_type = quan::meta::binary_operation<
TL,
quan::meta::divides,
TR
>::type;
where !std::SameType<result_type,boost::mpl::void_>;
result_type operator /(TL,TR);
};
}}
#include <quan/length.hpp>
#include <quan/time.hpp>
#include <quan/velocity.hpp>
#include <quan/area.hpp>
template <typename TL, typename TR>
where quan::concepts::Addable<TL,TR>
quan::concepts::Addable<TL,TR>::result_type
add (TL const & lhs,TR const & rhs)
{
return lhs + rhs;
}
template <typename TL, typename TR>
where quan::concepts::Multiplicable<TL,TR>
quan::concepts::Multiplicable<TL,TR>::result_type
mul (TL const & lhs,TR const & rhs)
{
return lhs * rhs;
}
int main()
{
quan::length::mm x(2);
quan::time::s t(1);
quan::length::mm r1 = add(x,x);
quan::area::mm2 r2 = mul(x,x);
//add(x,t); error
}
With the default invalid case defined its possible for the concept
system to have something to chew on. OTOH some version of maybe
decltype and SFINAE will fill the bill depending on how decltype
works...
Anyway most stuff I use seems to build on these so called fundamental
things:
Integral<T>
Integral<T> || Float<T> -- > Arithmetic<T>
etc etc
IOW there is an awful long way to go....
regards
Andy Little
James Kanze
> On Mar 5, 9:07 pm, "James Kanze" <james.ka...@gmail.com> wrote:
> > Tony Delroy wrote:
> > > On Mar 4, 9:22 pm, "James Kanze" <james.ka...@gmail.com> wrote:
> James Kanze wrote:
> > > > that could be done with them. (And of course, even today, most
> > > > serious companies don't allow programmers to define templates at
> > > > the application level
> > > Within the application level, a recompile isn't a serious issue.
> > there is extensive source level coupling, which management rejects
> > per se. (In every actual case I've encountered, it has been manageable.)
> Sounds like an issue with your particular management. You yourself
> are saying it's not technically justified, so I can only assume you've
> non-technicals micromanaging or technical-incompetents mismanaging
> your coding guidelines. My sympathies. I've never worked in a
> company where I couldn't use templates at my own discretion.
Yes and no. I've encountered the situation in just about every
well managed place I've worked in. The concerns are valid. I
believe that they can be addressed, but management is being
conservative, and not taking any risk. Since the typical (and
by far the most important) use of templates is low level
containers and such, they feel that the advantages of allowing
them at higher levels aren't worth the risk.
To date, I'll admit that I've not felt it to be a serious
restriction, either. Partially, of course, because I do a lot
of work at the lower levels where they are allowed:-). But also
because as you move up into the application levels, templates
are less important; my experience is that in the lowest levels,
I have lots of templates, and very little inheritance, where as
at the application level, it's the reverse.
Such things definitly are, and should be, management decisions.
And as I say, I've encountered the problem in well run
organizations, not in poorly managed ones. Also, management
listens. If something came up where they would be important,
and I could justify significant gains by using them, and show
how they could be managed, management would doubtlessly adapt
its policy---either for that one case, or generally.
--
James Kanze (GABI Software) email:james...@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
--
Yuriy Koblents-Mishke
[snip]
> (And of course, anyone who's actually
> used Modula-2 still misses its modules in C++. Even after 20
> years.)
>
There was something something very similar to modules in Borland Turbo
Pascal in late 1980s or early 1990s. It was named "unit". The units
appeared in version 4 of Turbo Pascal, and were supported also in
"object Pascal" (ver. 5.5 and 6). Units had a separate interface and
the code itself was local to them. The separation was much clearer
than #include in Turbo C and Turbo C++, and it also compiled much
faster (precompiled headers somewhat mitigated the speed problem, but
only somewhat).
The units was one of few things that I missed when migrated to C++.
(Local functions was another).
A quick search shows that units survived in Delphi. Delphi is not used
widely, but it is not a dead language like Modula. I did not code in
Delphi, though.
Sincerely
Yura.
Alf P. Steinbach
> On Feb 27, 8:58 am, "James Kanze" <james.ka...@gmail.com> wrote:
> [snip]
>> (And of course, anyone who's actually
>> used Modula-2 still misses its modules in C++. Even after 20
>> years.)
>>
>
> There was something something very similar to modules in Borland Turbo
> Pascal in late 1980s or early 1990s. It was named "unit".
As I recall that concept was from UCSD p-Pascal, which I used as student
(along with a great many other Pascals, Z80 and x86 and PDP-11 assembly,
PL/M-86, a little Fortran, etc.) in the very early 1980s. It's all very
connected: the guy who gave us Turbo Pascal subsequently gave us C#.
And both are languages with features that point the way for future C++:
simple modules from (originally UCSD, but) Turbo Pascal, and the
concepts of language-supported functors, called delegates, and
checked/unchecked statements and operators (do arithmetic operations
throw or not) from C#.
I'm not sure how much of that will end up in C++.
I wish for it all.
Now, if only Microsoft and the GNU guys (those are the C++ compilers I
use, or used to use) could take the hint from Anders Hejlsberg and
produce a C++ compiler that is blindingly, instantly /fast/, if
necessary by stopping at the first error and attempting no recovery
(those error avalanches are ungood anyway).
Extra connection: there's doubt about whether Anders was born in 1960 or
1961; likewise, there's doubt about whether Gabriel García Márquez was
born in 1927 or 1928, even though he celebrated his 80 year birthday two
days ago. Darned if I know what the connection between Gabriel and C++
is, because it seems all those Google hits of articles mentioning both
are in Spanish, but there are 14400 of them on the net, so, something...
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Walter Bright
off-topicality (stronger topicality judgement on airplane industry
history sub-thread), suggesting a move to other forum instead. After
discussion with other moderators I now think tangential discussions
should be accepted as long as there is on-topic C++ content, and I
apologize for the inconvenience; also, consequently, please disregard
earlier mod-comment regarding the tangential discussion. -mod/aps }
James Kanze wrote:
> On Mar 4, 8:30 am, Walter Bright <wal...@digitalmars-nospamm.com>
> wrote:
>> James Kanze wrote:
>>> There's a old saying: if it ain't broke, don't fix it.
>
>> That's what Douglas thought about designing jetliners - turboprops work
>> great, and are proven technology. Boeing blew right by them when the
>> airliners discovered that jetliners had half the operating costs, and
>> Douglas was reduced to a shadow.
>
> What does this have to do with anything we're discussing (or
> with C++)?
It's the disruptive innovation thing. By focusing on step-wise
refinement of existing technology, you can fail to recognize fundamental
problems as even being problems. Another way to look at it is you'll
never evolve a CLI into a GUI by fixing problems with the CLI.
So, with C++, by focusing merely on fixing "broken" things, a big risk
is run by missing the boat in recognizing seismic shifts in programming
technology.
> (Aside from being false---I think you're thinking of
> Lockheed, not Douglas, who was for a long time the second
> biggest constructor of jetliners.)
No, I have it right. Douglas was the big cheese of airliner builders
before jets, closely followed by Lockheed, with Boeing way, way behind.
Lockheed bet on the Electra, a turboprop, and missed the boat, not
producing a jetliner until the L1011 in 1970. Douglas failed as a
company in 1966.
> Also, of course, turboprops were actually more experimental than
> jet engines at the time; jets were widely used in military
> aircraft.
Turboprop engines were (mistakenly) seen as less risky by Douglas,
Lockheed, Convair, because they seemed a natural evolutionary step. I
suspect exported templates were added to C++ rather than modules because
export was seen as a less risky evolutionary step.
> Boeing didn't innovate in producing the 707.
That's dead, dead wrong.
> There
> were earlier, experimental, jetliners, such as the Sud Aviation
> Caravelle
Which rolled out (1955) one year AFTER the 707 (1954).
> or the de Havilland Comet which didn't catch on.
For two very good reasons:
1) it cost more to operate than a prop airliner, whereas the 707 cost
ONE HALF
2) it had a fundamentally unsound design, killing lots of people
> The
> de Havilland Comet is, in fact, a good example as to why you
> don't want to much state of the art in production tools:
The Comet didn't go far enough, it was too timid.
> it
> generated a lot of excitement when it first appeared (as the
> first jet airliner); regretfully, it turned out to have one
> small defect---it tended to loose its wings in flight.
No, that was the Electra. The Comet's problem was fatigue failure of the
fuselage, not the wings.
> It was
> Boeing's experience with large jet aircraft like the B-52 which
> put it in the driver's seat with regards to commercial
> jetliners.
No, it was Boeing's willingness to go whole hog with jetliners and do it
right with a long range, high capacity machine that had half the
operating costs of props. The Comet's timid, short range, small capacity
design doomed it to a costly, irrelevant niche. Airliners bought 707's
by the bucketful because it:
1) worked
2) made big fat wads of cash for the airliners
For C++, the magic is productivity. More productive use of programmer
time == better. Improvements to C++ should not exclusively focus on
problems, but on increasing productivity.
> To get back to C++ (sort of): no one is saying that there should
> be no research into new technologies, nor that what isn't broken
> today might be considered so in the future, as a result of new
> technologies.
"If it ain't broke, don't fix it" sure sounds like that.
> (When I look at the C++ I wrote 15 years ago, I
> would consider it broken by my standards today. But back then,
> I was proud of it.) The rôle of C++ amongst the many languages
> available isn't to invent new features; it's to leverage off
> inventions that have proved themselves in other languages.
Probably C++'s biggest productivity improvement, templates with STL, was
new, not proven in another language. C++ took a big risk with it, and it
paid off handsomely.
> And
> when it does play an innovative rôle, as is the case with
> template meta-programming, it's more or less serendipity;
> templates weren't designed with meta-programming in mind, and it
> was only after the fact that one or two geniuses realized all
> that could be done with them. (And of course, even today, most
> serious companies don't allow programmers to define templates at
> the application level---templates are restricted to standard
> components which don't change, because of the source code
> coupling issues.)
Template STL was designed, not discovered, and for a truly innovative
feature it does it tolerably well. Template metaprogramming, I agree,
was discovered. As a consequence, C++ templates are rather bad at
metaprogramming simply because they aren't designed for it. It's like
discovering a belt buckle can drive screws. Now that we know that
driving screws is a useful activity, we can purposefully design a
screwdriver, and go back to using the belt buckle to hold up our pants,
which it does a fine job of <g>.
To Mr. Moderator: Yes, I like to bring up aviation analogies <g>. I know
a lot about the aviation industry, having worked in it for years, and
having read many books about it. I've learned a lot from it, which has
influenced a lot of my work on compilers and language design. There are
a lot of parallels. Although it may not seem relevant, I think it is,
and I'll try to make the connections more clear in the future.
Francis Glassborow
<wal...@digitalmars-nospamm.com> writes
>{ This article was submitted Sun, 04 Mar 2007. I rejected it for
>off-topicality (stronger topicality judgement on airplane industry
>history sub-thread), suggesting a move to other forum instead. After
>discussion with other moderators I now think tangential discussions
>should be accepted as long as there is on-topic C++ content, and I
>apologize for the inconvenience; also, consequently, please disregard
>earlier mod-comment regarding the tangential discussion. -mod/aps }
>
topic content are undesirable and exercise self-discipline to limit it
and to resist an ongoing discussion of what is entirely tangential. Yes
we all know that we can get away with such by including some genuinely
new C++ as an after-thought but that is not really in the spirit of the
unwritten contract that posters have with each other and the vastly
larger number of readers.
This is not an attack on the post that the above introduced nor on the
poster but it is an appeal that we should all avoid interminable
discussion of the details of analogies. Very few analogies can stand up
under intense scrutiny. For me an analogy is just a way to try to help
other people understand my thoughts and is not a valid form of argument.
As such the finer details are relatively meaningless.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions:
http://www.spellen.org/youcandoit/projects
James Kanze
wrote:
> James Kanze wrote:
> > On Mar 4, 8:30 am, Walter Bright <wal...@digitalmars-nospamm.com>
> > wrote:
> >> James Kanze wrote:
> >>> There's a old saying: if it ain't broke, don't fix it.
> >> That's what Douglas thought about designing jetliners - turboprops work
> >> great, and are proven technology. Boeing blew right by them when the
> >> airliners discovered that jetliners had half the operating costs, and
> >> Douglas was reduced to a shadow.
> > What does this have to do with anything we're discussing (or
> > with C++)?
> It's the disruptive innovation thing. By focusing on step-wise
> refinement of existing technology, you can fail to recognize fundamental
> problems as even being problems.
That can be a risk. You do have to take a large view when
considering problems. On the other hand, if you're a commercial
organization whose main product is not data processing, you
pretty much want to avoid untried technology. Let you're
competitors suffer the problems of version 1.0:-).
> So, with C++, by focusing merely on fixing "broken" things, a big risk
> is run by missing the boat in recognizing seismic shifts in programming
> technology.
In the case of C++, I'm not too worried about that. Given the
wide range of users, I rather suspect that a lack of support for
a seismic shift in programming technology will be felt to be a
problem too soon, rather than too late. (I'm also a little bit
sceptical of seismic shifts. I find today that programming is a
fairly mature discipline.)
> > (Aside from being false---I think you're thinking of
> > Lockheed, not Douglas, who was for a long time the second
> > biggest constructor of jetliners.)
> No, I have it right. Douglas was the big cheese of airliner builders
> before jets, closely followed by Lockheed, with Boeing way, way behind.
> Lockheed bet on the Electra, a turboprop, and missed the boat, not
> producing a jetliner until the L1011 in 1970. Douglas failed as a
> company in 1966.
Well, I'm not going to argue about it (this isn't the place).
The information is readily available on the network, for those
interested.
> > Also, of course, turboprops were actually more experimental than
> > jet engines at the time; jets were widely used in military
> > aircraft.
> Turboprop engines were (mistakenly) seen as less risky by
> Douglas, Lockheed, Convair, because they seemed a natural
> evolutionary step. I suspect exported templates were added to
> C++ rather than modules because export was seen as a less
> risky evolutionary step.
> > Boeing didn't innovate in producing the 707.
> That's dead, dead wrong.
That's relevant to my point, and I'm right. The de Havilland
Comet was the innovation; the first jetliner. Boeing wasn't
first, by a long shot. (And Boeing had extensive experience in
large jet aircraft already, e.g. the B-52.)
Which is exactly my point: the de Havilland Comet was a typical
"first version", and it's users came to regret it.
But we don't have to go so far afield. Who had the first
implementation of templates for C++? And where are they now?
Whereas the two most widely used implementations of C++ (VC++
and g++) were probably the last two to implement templates.
There's an old saying about learning from your mistakes, but
it's even better to learn from the mistakes of others.
(If you want to make money, of course. Obviously, some one has
to innovate. I just prefer that it be the other fellow, so that
I can learn from his mistakes, rather than from mine.)
> > There
> > were earlier, experimental, jetliners, such as the Sud Aviation
> > Caravelle
> Which rolled out (1955) one year AFTER the 707 (1954).
> > or the de Havilland Comet which didn't catch on.
> For two very good reasons:
> 1) it cost more to operate than a prop airliner, whereas the 707 cost
> ONE HALF
> 2) it had a fundamentally unsound design, killing lots of people
Typical of a technological innovation, no. That's exactly my
point.
> > The
> > de Havilland Comet is, in fact, a good example as to why you
> > don't want to much state of the art in production tools:
> The Comet didn't go far enough,
Taken literally, one can't argue the point. (On a flight from
London to Johannesburg, it only got to the Mediteranean. Which
definitly wasn't far enough. And sorry for the bad joke.)
> it was too timid.
Whatever. It was the first jetliner (and the first jet aircraft
at all of that size?), and Boeing didn't appear until
considerably later.
Of course, in both this example and mine with C++, there are a
lot of other factors: Boeing had a lot of Defense Department
moneys for development, which de Havilland didn't, and I don't
think that VC++ won it's position just because it was in some
way stabler than CFront (although instabilities with CFront
definitly hurt arguments for its template instantiation
technology).
> > it
> > generated a lot of excitement when it first appeared (as the
> > first jet airliner); regretfully, it turned out to have one
> > small defect---it tended to loose its wings in flight.
> No, that was the Electra. The Comet's problem was fatigue failure of the
> fuselage, not the wings.
> > It was
> > Boeing's experience with large jet aircraft like the B-52 which
> > put it in the driver's seat with regards to commercial
> > jetliners.
> No, it was Boeing's willingness to go whole hog with jetliners and do it
> right with a long range, high capacity machine that had half the
> operating costs of props. The Comet's timid, short range, small capacity
> design doomed it to a costly, irrelevant niche. Airliners bought 707's
> by the bucketful because it:
> 1) worked
> 2) made big fat wads of cash for the airliners
And the reason it worked: because Boeing had learned from de
Havilland's mistakes.
> For C++, the magic is productivity. More productive use of
> programmer time == better. Improvements to C++ should not
> exclusively focus on problems, but on increasing productivity.
Where I work, we consider the amount of time it takes to produce
reliable, working code a real problem.
My point is simply that without concrete experience, you'll
probably get it wrong first time around. (Where was it that I
read: "Plan to throw one out. You'll have to anyway.") And
that we can't afford to get it wrong in the standard, so we
can't afford to standardize untested technology.
> > To get back to C++ (sort of): no one is saying that there should
> > be no research into new technologies, nor that what isn't broken
> > today might be considered so in the future, as a result of new
> > technologies.
> "If it ain't broke, don't fix it" sure sounds like that.
It's a saying. It doesn't really mean much, except as a
starting point to further explinations.
> > (When I look at the C++ I wrote 15 years ago, I
> > would consider it broken by my standards today. But back then,
> > I was proud of it.) The rôle of C++ amongst the many languages
> > available isn't to invent new features; it's to leverage off
> > inventions that have proved themselves in other languages.
> Probably C++'s biggest productivity improvement, templates with STL, was
> new, not proven in another language. C++ took a big risk with it, and it
> paid off handsomely.
Templates were already in wide use in Ada, Eiffel and possibly
other languages. Even before that, much generic programming was
being done by the Lisp community. The addition of templates to
C++ was a catch-up move, if you like. It was, at any rate,
fully in keeping with the philosophy of adopting existing good
ideas, rather than inventing things from scratch. It was also a
response to something that anyone who'd used it felt broken, and
needing fixing, mainly <generic.h>.
As for the STL, I'd agree that it was adopted too quickly, and
now we're stuck with its mistakes.
> > And
> > when it does play an innovative rôle, as is the case with
> > template meta-programming, it's more or less serendipity;
> > templates weren't designed with meta-programming in mind, and it
> > was only after the fact that one or two geniuses realized all
> > that could be done with them. (And of course, even today, most
> > serious companies don't allow programmers to define templates at
> > the application level---templates are restricted to standard
> > components which don't change, because of the source code
> > coupling issues.)
> Template STL was designed, not discovered, and for a truly innovative
> feature it does it tolerably well.
Templates were originally introduced into C++ before STL (which
if I'm not mistaken, was originally started in Ada). The needs
of the STL did influence the early evolution of templates, but
again, we're talking about features that were added to solve a
particular problem in the library.
> Template metaprogramming, I agree, was discovered.
A bit serendiptiy, even, I believe.
> As a consequence, C++ templates are rather bad at
> metaprogramming simply because they aren't designed for it. It's like
> discovering a belt buckle can drive screws. Now that we know that
> driving screws is a useful activity, we can purposefully design a
> screwdriver, and go back to using the belt buckle to hold up our pants,
> which it does a fine job of <g>.
I think we agree there.
--
James Kanze (GABI Software) email:james...@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
--
Andrei Alexandrescu (See Website For Email)
> In article <O7ydnb7-XoYPMXbY...@comcast.com>, Walter Bright
> <wal...@digitalmars-nospamm.com> writes
>> off-topicality (stronger topicality judgement on airplane industry
>> history sub-thread), suggesting a move to other forum instead. After
>> discussion with other moderators I now think tangential discussions
>> should be accepted as long as there is on-topic C++ content, and I
>> apologize for the inconvenience; also, consequently, please disregard
>> earlier mod-comment regarding the tangential discussion. -mod/aps }
>>
> topic content are undesirable and exercise self-discipline to limit it
> and to resist an ongoing discussion of what is entirely tangential. Yes
> we all know that we can get away with such by including some genuinely
> new C++ as an after-thought but that is not really in the spirit of the
> unwritten contract that posters have with each other and the vastly
> larger number of readers.
The worst thing in these long discussions containing a ton of fluff is
that they tend to continue between two people alone, because everybody
else is too tired and too bored to cut through the chaff. I've been
there, and at the time I thought I was making great points and that
there was no way the interlocutor could come back with something
sensible. Yet somehow there was always something new to say, partly
because in such long meandering discussions, trying to make sense is
actually a handicap :o).
> This is not an attack on the post that the above introduced nor on the
> poster but it is an appeal that we should all avoid interminable
> discussion of the details of analogies. Very few analogies can stand up
> under intense scrutiny. For me an analogy is just a way to try to help
> other people understand my thoughts and is not a valid form of argument.
> As such the finer details are relatively meaningless.
Definitely. However, the issue is when the other side of the analogy
contains a mistake that elicits an emotional response.
To try bringing this back on track: I understand that some people have a
conservative view and some others a view that fosters innovation when it
comes about the design of programming languages.
My opinion is that C++ innovated a good amount, and that it also
"conserved" a lot, both of which contributed to its success. I also
believe that the uber-conservative approach aired in this thread would
have definitely run it into the ground, as would have an uber-innovative
approach. And I fully realize I cannot prove any of the above :o). One
man's innovation is another man's feature that LISP had a long time ago,
and one man's recipe for success is another man's recipe for disaster.
To conclude: whacha gonna do? :o)
Andrei
hast...@hotmail.com
wrote:
> In article <O7ydnb7-XoYPMXbYnZ2dnUVZ_uygn...@comcast.com>, Walter Bright
> <wal...@digitalmars-nospamm.com> writes>{ This article was submitted Sun, 04 Mar 2007. I rejected it for
> >off-topicality (stronger topicality judgement on airplane industry
> >history sub-thread), suggesting a move to other forum instead. After
> >discussion with other moderators I now think tangential discussions
> >should be accepted as long as there is on-topic C++ content, and I
> >apologize for the inconvenience; also, consequently, please disregard
> >earlier mod-comment regarding the tangential discussion. -mod/aps }
>
> However I think that posters should recognise that large amounts of off
> topic content are undesirable and exercise self-discipline to limit it
> and to resist an ongoing discussion of what is entirely tangential.
> Very few analogies can stand up under intense scrutiny. For me an analogy
> is just a way to try to help other people understand my thoughts and is not
> a valid form of argument. As such the finer details are relatively meaningless.
An analogy can be a very powerful tool. It is not uncommon
for mathematicians or physicians to solve old problems by
applying techniques from completely unrelated fields, once
analogies are shown to actually be isomorphisms.
With regard to the C++ evolution, Walter words made me
realize how similar it seems to be to natural evolution :
1. Stepwise refinement, solving known problems is akin to evolution
by small mutations. A good, useful feature is selected and develops
further. A bad feature becomes deprecated. I'm sure you will
recognize many instances of this process in C++.
2. Cross-fertilization from (and to) other languages is akin to
sexual reproduction - which is known to lead to faster adaptation.
Of course, it happens only between similar languages (beings).
Both processes are useful, and I dont think that any of them
should be neglected.
But both processes are also known to reach only a local optimum.
Living beings most often do not adapt to a sudden, catastrophic
change in the environment, where survival requires a massive,
rapid evolution.
We have probably seen such a change with the internet, to which
C++ did not adapt, with the consequence of a reduced territory.
As with most living beings, I cannot remember any language
having been able to quickly adapt to a completely new environment.
This may be achievable, since language evolution is human
driven. However, doing so may be fighting a very strong rule,
and I'm far from sure that C++ should ever try to go this way.
Herb and others may be trying to go this way with C++/CLI.
It will be interesting to see whether these very smart guys
succeed in getting C++ selected in dotnet.
--- Raoul
--
James Kanze
> > <wal...@digitalmars-nospamm.com> writes
> >> { This article was submitted Sun, 04 Mar 2007. I rejected it for
> >> off-topicality (stronger topicality judgement on airplane industry
> >> history sub-thread), suggesting a move to other forum instead. After
> >> discussion with other moderators I now think tangential discussions
> >> should be accepted as long as there is on-topic C++ content, and I
> >> apologize for the inconvenience; also, consequently, please disregard
> >> earlier mod-comment regarding the tangential discussion. -mod/aps }
> > However I think that posters should recognise that large amounts of off
> > topic content are undesirable and exercise self-discipline to limit it
> > and to resist an ongoing discussion of what is entirely tangential. Yes
> > we all know that we can get away with such by including some genuinely
> > new C++ as an after-thought but that is not really in the spirit of the
> > unwritten contract that posters have with each other and the vastly
> > larger number of readers.
> The worst thing in these long discussions containing a ton of fluff is
> that they tend to continue between two people alone, because everybody
> else is too tired and too bored to cut through the chaff. I've been
> there, and at the time I thought I was making great points and that
> there was no way the interlocutor could come back with something
> sensible. Yet somehow there was always something new to say, partly
> because in such long meandering discussions, trying to make sense is
> actually a handicap :o).
Yeh. Several times, I've sworn to myself that I would limit my
responses, to avoid falling into the trap. But as you can see,
I never do. I just get carried away.
[...]
> To try bringing this back on track: I understand that some people have a
> conservative view and some others a view that fosters innovation when it
> comes about the design of programming languages.
> My opinion is that C++ innovated a good amount, and that it also
> "conserved" a lot, both of which contributed to its success.
Now that sounds like a reasonable statement. Some innovation is
necessary: introducing templates into C++ is an innovation for
C++, even if similar features were fairly widespread before C++
introduced them. And of course, C++'s templates aren't exactly
like those in Ada, or in any other language. (They can't be,
without C++ being Ada, or some other language.)
The important points, IMHO, are that 1) the feature solves a
definite problem (i.e. if it ain't broken, don't fix it), and 2)
that there is some concrete experience somewhere using it, so
that we know what it implies, what the risks are, etc. This
second point will never eliminate the risk 100%, but it does
mean that we at least have some idea what we are doing.
I think that C++ has, on the whole, followed this approach, and
that's what makes it a language that I'm willing to use. I
think, too, that there are some notable exceptions, particularly
in the library (<locale>, anyone?); as it happens, they
correspond to the parts of C++ that I consider more or less
"failures".
> I also
> believe that the uber-conservative approach aired in this thread would
> have definitely run it into the ground, as would have an uber-innovative
> approach. And I fully realize I cannot prove any of the above :o).
Given the looseness, it's a self evident truth. With everyone,
of course, defining uber-conservative and uber-innovative
according to his personal preferences:-).
--
James Kanze (GABI Software) email:james...@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
--