R
Roland Pibinger
Already done weeks ago.
Already done weeks ago.
J
James Kanze
So it doesn't follow the ISO C++ standards. This doesn't, in
itself, make it worse than a number of other compilers, but it
does mean that it's not the answer to the original question (any
more than is g++ or VC++), if the original question is to be
taken literally.
W
Walter Bright
James said:
English isn't a programming language - we don't expect what we say to be
taken *literally* unless someone annotates the description saying so.
One would expect such a question to be worded like:
"Does anyone know of a C++ compiler which is 100% conformant with the
C++ standard?"
instead of:
"I wanted a C++ compiler which would follow the ANSI C++ standards.
If you could tell me an IDE also, it would be more helpful."
which is not even grammatically correct. Do you really think that a
language lawyer would also ask for an IDE? For understanding English,
context is crucial. Pulling sentences out of context and trying to take
them literally is to risk seriously misunderstanding people.
W
Walter Bright
Roland said:
Thank-you. My apologies.
W
Walter Bright
kwikius said:
A case in point: I attended a presentation by Scott Meyers that involved
doing some C++ template metaprogramming. A lot of the focus was on the
mechanics of what was, essentially, an array of types. It was pretty
clear that manipulating an array of types in C++ is hard, time
consuming, and when you make a mistake, how to fix it is often very
difficult to deduce.
But if it was an array of integers, rather than an array of types, the
presentation would have been over in 5 minutes. This seems to happen a
lot with C++ metaprogramming - once you get past the mechanics and
figure out what the programmer was trying to actually do, it's pretty
simple. And the reason it is simple is because it's *too hard* to do
anything else with C++ TMP.
So, a huge goal with D TMP is to be able to do simple things in a
straightforward, simple manner. One should be able to manipulate an
array of types as easily as an array of ints. Writing templates should
not be harder than writing a function.
Right. Case in point: the factorial template which recursively
instantiates itself to compute a factorial at compile time. For every
iteration, the compiler must:
1) instantiate a template
2) encode the entire state of the template and all previous iterations
into the (mangled) name of the template
3) emit symbol table info (and possibly debug info) for each of these
templates, pretty much making an explosion of output
If you think about it, that's a fantastic amount of processing and
memory required to do something as trivial as a factorial. It is why
complex calculations cannot be done with C++ templates, even if they
theoretically can be. It's why C++ TMP compiles very, very slowly.
I'm not familiar with Daveed's work, nor did I know he was working on
such a language.
G
Gennaro Prota
Thank-you for the explanation. Now I hope we don't have to face
another 200-post thread like the one we had on c.l.c++.m a while ago.
The OP has enough material for making his own deductions.
J
James Kanze
English (like all human languages) has many different levels of
precision. A statement refering to ISO standard's is pretty
precise.
That's why I added the "if"---if the original question is to be
taken literally. I don't really know what the original poster
is looking for. As you say, would someone who understood
programming well enough to understand what standards conformance
means want an IDE? On the other hand, grammatical or not (and
the grammar errors could be due to sloppy thinking, or to
English not being his native langauge---we don't know), the
question explicitly mentions the standard. Why, if not that he
wanted standards conformance? As I say, I don't know what he
really wants or needs, but DMC++ is not an answer to his
question, as he stated it, any more than is g++ or VC++.
He also didn't state his platform. Now, it's probably a pretty
good guess that it is Windows, but if by chance it is Solaris,
DMC++ probably isn't a good answer either (and neither is VC++).
In fact, the only correct answer is: what do you really want and
need?
B
BobR
James Kanze said:
The OP did state later that (s)he was intending to use window$.
But it sounds like the OP tried to put a Posix(?) version of GCC on the
windows machine.
K
kwikius
Yep. However I prefer C++ to D mainly because I have spent quite a
long time learning it and it looks to me like D is becoming just as
complex and quirky as it evolves.
Still I did like the metaprogramming in D.
I would prefer to have my cake and eat it I guess.
I'm not sure if he still is but there is some info dated April 2003
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1471.pdf
http://www.vandevoorde.com/Daveed/News/Archives/000015.html.
regards
Andy Little
W
Walter Bright
kwikius said:
That will inevitably happen. However, you can do much more complicated
things with D before the quirkiness sets in. And some day, D will get to
the point where E will become necessary.
The reports are that the same problems take dramatically less code to do
in D than in C++, and go together much faster.
Wouldn't we all <g>. But I hear your issue with having spent a lot of
time learning C++. D is designed so most of what people know about C++
can be transferred to D, making it an easy language to master. I know
you already know this, so this is for the lurkers.
Thank you, I'll have a look.
K
kwikius
The problem I had when I tried D was that there seemed to be no
equivalent to the C++ explicit keyword. Its useful for example value
initialisation of my quan quantity types:
quan::length::mm x(1);
quan::length::mm y = 1; // Error quantity constructor is declared
explicit.
That may seem trivial but its just one of those tools that I am used
to having. However I figured that you have enough feedback and
requests for language features to contend with at the moment, and I
decided I would back off ;-)
I would agree with that from the short time I spent trying D out and
it certainly provides a good talking point for a separate C++
metaprogramming scheme, though my current hunch is that that is
unlikely to happen because the current metaprogramming hacks are
becoming firmly embedded, with time spent on honing the hacks ( e.g
variadic templates should help a lot)
The other thing of course is that none of the problems with C++
metaprogramming(compile time, compiler resources) are that visible in
textbooks or lectures... something about style over substance...
The other point is the 'macho' attitude, something I believe
contributed to the success of Dos/Win over Mac. Simply put,
programmers enjoy conquering ugly crap ;-) ( Maybe Linux is in there
too ;-)
It would be interesting to know what you make of it. I would think you
are probably The ideal person to comment, if anybody is.
regards
Andy Little
W
Walter Bright
kwikius said:
There are plans to improve control over implicit conversions for
classes, and I think that will help with this.
I don't expect C++ TMP to change in any fundamental way. The C++0x
improvements just twiddle around the edges, there are no fundamental
improvements (other than variadic templates).
I think these problems will get harder and harder to overlook and brush
aside, since there are now examples of how it doesn't have to be that way.
As an old DOS programmer, I can attest that part of the attraction to
DOS was the system was 100% understandable, and one could write programs
that had complete control over the machine. Those days are certainly gone.
K
kwikius
The major feature of C++0x for me is in making Concepts programming
entities rather than documentation entities.
There are other useful features such as decltype and auto(aka typeof)
which just should have been there with overloaded operators.
There are so many plus points for Concepts that it is another reason
for sticking with C++ ( I am aware that this isnt what you may want to
hear but I'm just laying it out ). Nor do I find it easy to explain.
An interesting example is a power function.
In case of std:
ow the power is a runtime value. However in aparticular expression on quantities its not possible to make the power
a runtime value as the type of the result is dependent on it so it
must be a compile time value. To a layman this would appear to be a
limitation, but in practise every variable raisd to a power must
conform to some Concept,probably either a numeric or a quantity.
e.g. Calculate an area y from a length x;
///use doubles
double x =1;
double y = std:
ow(x,2);//use quantities
quan::length::m xx(1);
quan::area::m2 yy = quan:
ow<2>(x);In the first case the concepts are there but hidden, whereas in the
second case they are enforced and the whole expression is strongly
typed and further by revealing the concepts underlying the expression
the pow function has been given much clearer hint for optimisation.
( and the power must be a compile time value)
There are many calculations where, once the concepts are revealed then
values can be moved to compile time.
One area that I have explored and where there can be dramatic
optimisations of an order of magnitude is in 3D matrix concatenation,
where many values are multiplied by 1 or 0. Every 3D matrix is in
fact a type e.g a translation matrix, a rotation matrix etc. The
result type of a concatenation of the basic types is also a specific
type. which can be computed by the compiler from these 'primitive'
input types. ( You can also use quantities or numerics or combinations
within a matrix). Special static types are used for certian values
within the matrix which because all their properties are known at
compile time calculations on them with runtime types are very easy to
optimise away.
It works but...interestingly this is one area where C++ does suffer
really badly and is frustrating because in practise for the compiler
computing the result type of a matrix computation at compile time
reveals very much the problems ( long compile times, running out of
compiler resources (in VC7.1)) discussed previously.
However IMO the results of this work if the practical issues were
solved could be very positive for complexity of 3D games etc, so I'm
continuing plugging away.
hmm.. It might be worth trying this stuff in D and I reckon it would
be a good proof for D over C++. But therin lies another problem. Does
D have an equivalent of for example C++'s enable_if(SFINAE) construct
which gives primitive Concept support and is useful to get this stuff
running or indeed is there more comprehensive support for e.g
overloading based on Concepts planned in D?
(As you can see I am stuck between two cakes, neither with a liberal
enough quota of jam ;-) )
regards
Andy Little
W
Walter Bright
kwikius said:
D already has the equivalents of those.
D has a much simpler method of doing the same thing - specializations.
Extending the specializations a little covers what concepts do.
An interesting example is a power function.
In case of std:
particular expression on quantities its not possible to make the power
a runtime value as the type of the result is dependent on it so it
must be a compile time value. To a layman this would appear to be a
limitation, but in practise every variable raisd to a power must
conform to some Concept,probably either a numeric or a quantity.
e.g. Calculate an area y from a length x;
///use doubles
double x =1;
double y = std:
//use quantities
quan::length::m xx(1);
quan::area::m2 yy = quan:
In the first case the concepts are there but hidden, whereas in the
second case they are enforced and the whole expression is strongly
typed and further by revealing the concepts underlying the expression
the pow function has been given much clearer hint for optimisation.
( and the power must be a compile time value)
There are many calculations where, once the concepts are revealed then
values can be moved to compile time.
I don't see anything here that can't be done with D. Or maybe I just
don't get it, which is possible.
You might find these interesting:
http://www.digitalmars.com/pnews/re....com&group=digitalmars.D.announce&artnum=4591
http://www.csc.kth.se/~ol/physical.d
Yes, static if-statements and is-expressions.
?
=?ISO-8859-1?Q?Erik_Wikstr=F6m?=
So you can do concept mapping too? Nice.
K
kwikius
Sure. Its *possible* to do all this stuff in C++ now ( I would need to
look in more detail at the D equivalents). Its possible to do in C, in
Java probably somehow. However what is often not appreciated is the
simple power of being able to express something precisely and
elegantly.
The most important feature of my quan library is that it gives you a
vocabulary to express physical quantities elegantly in code. Its not
easy to describe the usefulness of this here but it brings out the
intent of code and this in turn helps you to think at a higher level
rather than trying to remmember what quantity double x is representing
and so on and so forth.
I think the generic term is "raising the level of abstraction". You
can then see the broad picture and overall design more clearly And
the design is enforced by the compiler.
Already Concepts do similar in documentation in C++, so rather than
saying type x needs functions Y and Z and members A, B, and C, else
you will get a (compile or runtime) failure you simply say type x is
or must be a model of Concept X. Doing this in documentation is
useful, but crucially the rules arent enforced. This has consequences.
The first one is there is no way to test a Concept . This means that
Concepts are academic entities and types can slip through the net.
Like anything that is designed, Concepts themselves need to be
designed,redesigned and honed to get them right. They won't be correct
first time. It is very hard to test and use Concepts without being
able to enforce them. Basically template metaprogramming in C++ is
very similar to assembly language programming in this respect. It is
very hard to understand the code and very hard to track down errors.
A Concept is a concise and elegant way to express and ideally
enforce ... well a Concept ;-)
C++ Concepts are potentially a very powerful mechanism ...allegedly...
as yet ConceptGCC doesnt implement some of the more useful stuff :-(
Yep. I have already seen that. You might want to compare this :
( d code in above url)
void main() {
Area a = 25 * meter * meter;
Length l = 0.1 * meter;
Volume vol = a * l;
Mass m = 100 * kilogram;
assert(!is(typeof(vol / m) == Density));
//Density density = vol / m; // dimension error -> syntax error
Density density = m / vol;
writefln("The volume is %s",vol.toString);
writefln("The mass is %s",m.toString);
writefln("The density is %s",density.toString);
writef("\nElectrical example:\n\n");
Voltage v = 5 * volt;
Resistance r = 1 * 1e3 * ohm;
Current i = v/r;
Time ti = 1 * second;
Power w = v*v/r;
Energy e = w * ti;
// One wishes the .toString was unnecessary...
writefln("A current of ",i.toString);
writefln("through a voltage of ",v.toString);
writefln("requires a resistance of ",r.toString);
writefln("and produces ",w.toString," of heat.");
writefln("Total energy used in ",ti.toString," is ",e.toString);
writef("\nCapacitor time curve:\n\n");
Capacitance C = 0.47 * 1e-6 * farad; // Capacitance
Voltage V0 = 5 * volt; // Starting voltage
Resistance R = 4.7 * 1e3 * ohm; // Resistance
for (Time t; t < 51 * 1e-3 * second; t += 1e-3 * second) {
Voltage Vt = V0 * exp((-t / (R*C)).value);
writefln("at %5s the voltage is %s",t.toString,Vt.toString);
}
//----
With this source at:
http://tinyurl.com/2k7ugv
authored by my very self ;-)
:
#include <quan/capacitance.hpp>
#include <quan/resistance.hpp>
#include <quan/time.hpp>
#include <quan/out/voltage.hpp>
int main()
{
using quan::capacitance;
using quan::voltage;
using quan::resistance;
using quan::time_; // for non default time with int value_type
std::cout.setf(std::ios_base::fixed,std::ios_base::floatfield);
std::cout.precision(3);
capacitance::uF const C(0.47); // capacitor
voltage::V const V0(5); // starting voltage across
capacitor
resistance::kR const R(4.7); // resistance between terminals
// one possible useage of integer value_type
for ( time_<int>::ms t ; t <= time_<int>::ms(50); ++t ){
voltage::V Vt = V0 * std::exp(-t / (R * C));
std::cout << "at " << t << " voltage is " ;
//format
if (Vt >= voltage::V(1.0)) std::cout << Vt ;
else if(Vt >= voltage::mV(1)) std::cout <<
voltage::mV(Vt);
else if(Vt >= voltage::uV(1)) std::cout <<
voltage::uV(Vt);
else if(Vt >= voltage::nV(1)) std::cout <<
voltage::nV(Vt);
else std::cout <<
voltage:
V(Vt);std::cout << "\n";
}
}
Ahhh imitation is the best form of flattery ...That's the power of
Quan ....
BTW for those interested, though quan on sourceforge has been sleeping
for some time, I hope that soon she will be back in modified form,
hopefully on her own site, with a similar interface but with a much
more elegant implementation and a lot more comprehensive features,
she's too pretty to die so young ;-)
regards
Andy Little
W
Walter Bright
kwikius said:
It's roughly equivalent to an 'interface' in D. If you inherit from an
interface, you must provide an implementation of all of the interface's
members. A template type parameter can be constrained to be derived from
a particular interface. This is enforced by the compiler.
K
kwikius
Actually this brings me to a feature of D's operator overloading
design that I wasnt too keen on, which is that operators must be
expressed as members of a particular class (in C++ terminology) IIRC
A binary operation always applies to two types and there are *4*
entities involved, the 2 input types,the operator and the result_type.
IOW a binary operation involves 4 entities and making it a member of
one input_type doesnt express this elegantly (if anything the
operation is a "member" of the operator which is the only constant
feature)
Further as free functions it is possible to add overloads without
modifying classes.
Ideally one would be able to define operator overloads as:
//some construct for computing result_type of A * B, overloadable on
types or Concepts
result_of operator *(Concept A, Concept B) {
result_type = "some metaprogramming stuff on A and B "
};
// definition of the body where A and B meet requirements
operator *( Concept A, Concept B)
{
return some_expression of A, B;
}
Note with this approach the result_type can be automatically computed
from the expression
However it is useful as a constraint.
Note that in the above no types have been defined !
In fact there is a definite OOP flavour to D which despite contrary
claims is not so dominant in C++.
regards
Andy Little
W
Walter Bright
kwikius said:
C++ has that weird asymmetry in that one ordering of operands is a
member function, the other is a free function. In D you can do both as
member functions, in either the class of one operand, or the class of
the other operand.
The other problem with C++'s method is it requires ADL (Koenig lookup).
Requiring operator overloads to be class members avoids that whole wacky
kerfluffle.
I suspect it is less of an OOP flavor and more of an orientation towards
modularity. C++ doesn't have modules, which leads to all sorts of
scaling problems (the worst of which are exported templates).
K
kwikius
I usually but not always make my op-assignment operators members and
other binary operations non-members as that seems most logical to me.
Aha ... but for me as class(es) designer... this is where the power of
concepts comes in.
Write your operator function to work on Concepts .
Again no type has been written but if a pair of types fits, they
automatically get the overloaded function. You can also of course
supply ways to 'opt in/out' of the default if you so wish.
Write your various models of the Concepts. ( Quan has 5 or 6 major
types all requiring ops) Bingo! No need to write your operator
function for each type.
BTW I have been associating Concepts and types. In fact a type can be
a model of many Concepts and a Concept can reflect a part of a type(s)
eg Addable<TL,TR>, etc etc. In fact you can probe for a type by
finding out which concepts it models, but ultimately the particular
type doesnt matter. If it fulfills the reuirements things will work as
long as the concepts are correct.
The basic idea of ADL is sound but I think everyone agrees that ADL is
too liberal...
I think its great that D is around because it takes an alternative
approach. I suspect that it has already had a part to play in C++
development and will in future.
If D has been influential and I think it has, and the core std people
arent acknowledging the fact then that is there problem.
Keep Rockin ;-)
regards
Andy Little