J
JohnQ
Alf P. Steinbach said:
I don't need it. I'm not building a compiler.
John
I don't need it. I'm not building a compiler.
John
J
James Kanze
By not counting the number of tools? I must have about twenty
or thirty different tools installed on my Windows machine; if I
were to use it for actual development, I'd need quite a few
more. If I count each package as a "tool" on my Linux box, I'm
in the hundreds. One more or less doesn't mean that much.
(But you're right in a way. Having an additional tool in the
build chain is a disadvantage. Not a big one, of course, but
something which should be taken into consideration with the
rest. There's a definite advantage of having the entire build
chain and the underlying system and libraries all from the same
source. In general, however, it's not possible: Sun doesn't
sell a data base, I need third party libraries to connect to
Reuters as well, and so on.)
It feeds C into VC++ or g++. Very old-fashioned C. C's been
around for a long time, is very stable and relatively simple.
I'd be very surprised if there were any serious bugs in the C
compiler of gcc or VC++. Where as with C++...
That too, but what I was really thinking of is the idea of using
Comeau for all of the platforms. That way, you have the same
C++ everywhere. (In the Unix world, a number of places use g++
systematically just for this very reason. There are a number of
subtle differences between xlC and Sun CC, but g++ is the same
on both AIX and Solaris.)
It's definitly not a "from source to executable" product.
Neither is g++, for that matter, at least not under Solaris
(where it uses the Sun linker). And that's certainly a
consideration. But as I said above, you typically need other
tools anyway, like a data base. And you probably won't find the
same "from source to executable" product available on all of
your target platforms. Using the same compiler front-end on all
of your platforms frees you from having to worry about
variations in the language the compiler understands, or in its
interpretation of the standard.
And IMHO, that is the main argument for using Comeau,
professionally. If you're only concerned about one system, and
portability is not a concern, then the obvious solution is the
"native" compiler: VC++ under Windows, g++ under Linux, Sun CC
under Solaris, etc.
(That's professionally, of course. I know more than a few
people who use Comeau on the side, because they want to
experiment with standard C++, and be sure that what they are
learning corresponds to the standard---with the hope, of course,
that as time goes on, more compilers will conform.)
That's true. But it's still a basic "format" that can be used
on just about every platform.
I think you can choose, at least to some degree. (Under Linux,
it's gcc. And I don't think you have a choice there.)
If you use Comeau, you get the potential issues of Comeau C++,
plus the potential issues of the native C compiler. If you use
the native C++ compiler, you get its potential issues.
Generally speaking, the first set is smaller than the second, at
least with regards to bugs and language issues.
They're not just abstracting away one set of issues. You're
replacing the issues of your native C++ compiler with those of
Comeau plus the native C compiler. Typically, the native C
compiler has almost no problems, so it's Comeau C++ vs. the
native C++. And the people behind the Comeau compiler (which is
a port of the EDG front-end) are better than those behind just
about any other C++ compiler. Much better, usually.
If they all had a compatible C++ compiler, yes. I certainly
don't look for such a tool for C. But they don't. C++
compilers still vary greatly in how much of the standard they
implement, and how they interpret it.
You've doubtlessly got more than that already.
The more vendors more pain is a real argument. Although Comeau
is very good about not passing the buck. I've had a lot of
problems in the past with vendors just saying "it's the other
guys fault". Of course, today, even with one vendor, you'll
sometimes get the answer: "that's the way it is; live with it".
But only if the vendor is significantly bigger than you, and
knows that he can get away with it. The fact that Comeau is
small can be a definite advantage when it comes to dealing with
the company.
I don't know. Given two platforms, I'd certainly consider it.
It's certainly a more reliable compiler than either VC++ or g++.
It's also the same compiler for both platforms---my experience
with g++ under Windows is that it isn't well integrated, and
VC++ and g++ are definitely different compilers, each with its
own set of bugs and its own set of problems. On the other hand,
maintaining the two tool chains is more work. And there's also
the fact that the people who maintain wxWindows certainly use
g++ and VC++, and test with it before shipping, where as its
very unlikely that their code has ever been compiled with
Comeau. (Note that when dealing with third party software, like
wxWindows, stricter standards conformity is not necessarily an
advantage.)
Given the price of Comeau, I'd certainly recommend at least
using it on the side, to experiment with, and to ensure that any
of the fancier code you write is standards conform, and will
(probably) compile with later versions of the compilers you
actually use in production.
T
Thomas J. Gritzan
JohnQ said:
A compiler goes from a source language to a target language, that can be
assembly, machine code, C or whatever.
<http://en.wikipedia.org/wiki/Compiler>:
"A compiler is a computer program (or set of programs) that translates text
written in a computer language (the source language) into another computer
language (the target language). The original sequence is usually called the
source code and the output called object code. Commonly the output has a
form suitable for processing by other programs (e.g., a linker), but it may
be a human-readable text file."
G
Greg Comeau
Most things have some subjective level to them. But most definitions
usually come to similar conclusion. Anyway, I'm not just saying it's
compiling because it is going to an intermediate form. I think it's
worth point out that error checking, syntax checking, semantic analysis,
etc are all done. The difference is that the code generation phase
emits a different object code.
One way to look at it is as a special compiler. Just like a compiler
is a special translator. And so on.
Maybe front-end compiler would work for what I believe you're seeking.
Aha!
Right, actually many of the standards (certainly C and C++) punt on
terms like compiling, linking, etc. and stick instead to issues
such as phases, and semantics.
If I understand your question, yes, I would say they are different
forms and different stages of compiling.
G
Greg Comeau
Ok, but you asked about some of this stuff, and the "Dragon Book"
is normally considered a solid reference on some of this stuff.
J
JohnQ
Greg Comeau said:
I knew someone was going to say that. And I already knew what I was going to
say in return: I'd rather know what the C++ standard has to say about those
things. I've heard "translation phases" in here before, but I don't remember
or know if they actually put names on all of them. As in: translation phase
1, preprocessing.
John
J
JohnQ
Thomas J. Gritzan said:
It would seem then that just saying "compiling" is indeed ambiguous if one
wants to know what's really going on behind the scenes and that something
like "compiling to proprietary intermediate form" is in order.
John
J
JohnQ
Greg Comeau said:
So, you're telling me that "compiling" = error checking + syntax checking +
semantic analysis + etc? I'd accept that. Then everything that happens after
that is translation. Translate to assembly or C or machine code or whatever.
Yes?
Or how about, "precompiler"?
Aha!
Right, actually many of the standards (certainly C and C++) punt on
terms like compiling, linking, etc. and stick instead to issues
such as phases, and semantics.
OK, I need to look up those phases out of curiosity now. (Or someone can
post them!
).Or different contextual uses of the term 'compiling' more likely.
John
J
JohnQ
"By not counting the number of tools? I must have about twenty
or thirty different tools installed on my Windows machine; if I
were to use it for actual development, I'd need quite a few
more. If I count each package as a "tool" on my Linux box, I'm
in the hundreds. One more or less doesn't mean that much."
That's a facetious argument. The window is that of compiling source code.
Pretend it's the last compile before packaging and deployment and not
everything from concept to purchasing shrink-wrapped sofware in a retail
store. But it's not worth talking about. If you think that exotic means of
compiling should be considered everywhere, all the time, so be it.
Me: Using 2 compilers in a chain is for very specialized, very
non-mainstream development scenarios.
You: No it's not.
(But you're right in a way. Having an additional tool in the
build chain is a disadvantage. Not a big one, of course, but
something which should be taken into consideration with the
rest. There's a definite advantage of having the entire build
chain and the underlying system and libraries all from the same
source. In general, however, it's not possible: Sun doesn't
sell a data base, I need third party libraries to connect to
Reuters as well, and so on.)
If you like to lump everything into one category, so be it. Class hierarchy:
development tools. Not much of a hierarchy huh. (We were talking about
compilers. USUALLY there is only one).
"It feeds C into VC++ or g++. Very old-fashioned C. C's been
around for a long time, is very stable and relatively simple.
I'd be very surprised if there were any serious bugs in the C
compiler of gcc or VC++. Where as with C++..."
I thought it was very compiler-specific C.
"That too, but what I was really thinking of is the idea of using
Comeau for all of the platforms. That way, you have the same
C++ everywhere. (In the Unix world, a number of places use g++
systematically just for this very reason. There are a number of
subtle differences between xlC and Sun CC, but g++ is the same
on both AIX and Solaris.)"
It just means that you are jobbing out the difference resolution to Comeau
instead of doing it yourself. Instead of dealing with differences in C++
implementations, you're letting Comeau deal with differences in C
implementations. Of course, doing it in C is an alternative also.
"It's definitly not a "from source to executable" product.
Neither is g++, for that matter, at least not under Solaris
(where it uses the Sun linker). And that's certainly a
consideration."
Comeau will get the code to something platform-specific but not
hardware-specific. That's why I consider it a "front end". Which begs the
question: "Why doesn't Comeau put a back end on it for each platform and
sell a "real" compiler?
"But as I said above, you typically need other
tools anyway, like a data base. And you probably won't find the
same "from source to executable" product available on all of
your target platforms. Using the same compiler front-end on all
of your platforms frees you from having to worry about
variations in the language the compiler understands, or in its
interpretation of the standard."
Again, you're just trading C++ difference management for someone else doing
C difference management. Increasingly, that makes less and less sense
because compilers have evolved and will continue to do so. (Of course, what
I'd prefer is a "devolved" C++ to solve the problem instead of
masking/bandaiding it).
"And IMHO, that is the main argument for using Comeau,
professionally. If you're only concerned about one system, and
portability is not a concern, then the obvious solution is the
"native" compiler: VC++ under Windows, g++ under Linux, Sun CC
under Solaris, etc."
Nah, it's bad all around (note JohnQ jumping out of the hot oil): C++ should
be implementable. If it is so bad that one cannot trust that code can be
written to be compiled on any compiler, something else is VERY VERY wrong.
So no, making one C++ implementation "THE C++" is not a good answer. You may
want to note that I frequently suggest here that C++ is too complex,
over-kill etc., that a simpler language to implement is compelling, and that
your "stand" in this thread supports the basis for my quest quite well.
"(That's professionally, of course. I know more than a few
people who use Comeau on the side, because they want to
experiment with standard C++, and be sure that what they are
learning corresponds to the standard---with the hope, of course,
that as time goes on, more compilers will conform.)"
1. I think the importance of standard conformance is over-blown relative to
all development issues.
2. I understand why people "close to" a language would think that way or try
to make it that way.
"That's true. But it's still a basic "format" that can be used
on just about every platform."
I don't think so. That's why I said 'platform-specific' C. It just all seems
really silly: translate to another HLL in a form that won't compile
everywhere without massaging it. Well, that was the same thing at the get go
with the C++ code!
"I think you can choose, at least to some degree. (Under Linux,
it's gcc. And I don't think you have a choice there.)"
"If you use Comeau, you get the potential issues of Comeau C++,
plus the potential issues of the native C compiler. If you use
the native C++ compiler, you get its potential issues.
Generally speaking, the first set is smaller than the second, at
least with regards to bugs and language issues."
I think a better approach is to know what the issues are and then code
around them. To wait for the next version of the platform-specific compiler
or the next C++ standard when "things are ready for prime time".
"They're not just abstracting away one set of issues. You're
replacing the issues of your native C++ compiler with those of
Comeau plus the native C compiler. Typically, the native C
compiler has almost no problems, so it's Comeau C++ vs. the
native C++. And the people behind the Comeau compiler (which is
a port of the EDG front-end) are better than those behind just
about any other C++ compiler. Much better, usually."
Comeau is a very specialized tool, not in the same category as mainstream
compilers, IMO. The applicability of the Comeau product is directly related
to the problem with the C++ language. I'd rather see the language fixed,
replaced or a new language. "Design for producibility" is a good engineering
concept for language designers also. Back to the drawing board?
"If they all had a compatible C++ compiler, yes. I certainly
don't look for such a tool for C. But they don't. C++
compilers still vary greatly in how much of the standard they
implement, and how they interpret it."
Like I said, I can see where you would be more apt to worry about that than
most. In the short term, I think the appropriate action is to talk to the
compiler vendors when something is lacking. A language that can only be
implemented by very few companies, or just by companies for that matter, is
"not ready for prime time" or lacks "goodness"/quality.
"You've doubtlessly got more than that already."
But within the same tool. Apples/oranges.
"The more vendors more pain is a real argument. Although Comeau
is very good about not passing the buck. I've had a lot of
problems in the past with vendors just saying "it's the other
guys fault". Of course, today, even with one vendor, you'll
sometimes get the answer: "that's the way it is; live with it".
But only if the vendor is significantly bigger than you, and
knows that he can get away with it. The fact that Comeau is
small can be a definite advantage when it comes to dealing with
the company."
Aside: Now may be a good opportunity to list the things (conformance
issues?) that may be of enormous concern to developers that Comeau solves
and the other guys don't. What would be interesting also is a comparison of
where compilers are at today to where they were yesterday, against the Dr.
Dobb's article someone refernced earlier perhaps. I have a feeling that I'll
find the issues mostly remote/non-important.
"I don't know. Given two platforms, I'd certainly consider it.
It's certainly a more reliable compiler than either VC++ or g++.
It's also the same compiler for both platforms---my experience
with g++ under Windows is that it isn't well integrated, and
VC++ and g++ are definitely different compilers, each with its
own set of bugs and its own set of problems."
Again, that's a (THE) problem with C++. (Unless of course there are inclings
that the platforms are competing with languages with their own APIs and
therefor purposely avoid implementing certain language elements).
"On the other hand,
maintaining the two tool chains is more work. And there's also
the fact that the people who maintain wxWindows certainly use
g++ and VC++, and test with it before shipping, where as its
very unlikely that their code has ever been compiled with
Comeau. (Note that when dealing with third party software, like
wxWindows, stricter standards conformity is not necessarily an
advantage.)"
"Given the price of Comeau, I'd certainly recommend at least
using it on the side, to experiment with, and to ensure that any
of the fancier code you write is standards conform, and will
(probably) compile with later versions of the compilers you
actually use in production."
Now that IS a valid potential use, if one decides that "the more compilers
we run the code through the better". But again, it's a fundamental language
problem IMO.
John
J
jacob navia
JohnQ said:
Excuse me but I never got g++ to work under AIX.
It is completely full of bugs.
We used xLc
J
JohnQ
jacob navia said:
"JohnQ quoted JK" you mean.
J
jacob navia
JohnQ said:
Yes. Excuse me.
J
James Kanze
J
James Kanze
The standard doesn't really speak of "compiling" formally. It
specifies how a C++ is translated to an executable file, then
executed. The translation has a certain number of steps;
classically, some of those have been considered "compiling",
where as the last has been considered "linking". But modern
systems tend to blur the distinction, and most systems today
also use a single command line for the works. Thus, for
example, g++ is not what would have been called a compiler when
I was learning computer science; it's a driver program which
invokes different phases of the compiler and/or the linker,
depending on command line options, etc.
Depending on the context today, "compiling" can mean what you do
to go from one or more .cc files to an executable binary, or
what you do to go from a single .cc file to a single .o/.obj
file, with linking being a separate step (and I can't think of a
good, simple verb for "building a library"). Note that with
g++, I use the commands g++ and cl (under Windows) for both
compiling and linking, and with Sun CC, I use the command CC for
building a library as well (although I use ar with g++, and lib
with cl).
G
Greg Comeau
The closest it really comes to is mentioning preprocessing. The rest is
really dealing with the semantics of things, revolving names not
linking per se, syntax analysis but not how to scan or lex per se
(I'm not saying that right, but hopefully the point comes though),
and so on. This way, it leaves translation open to other options beyond
traditional "compiling".
G
Greg Comeau
If one really wants to know what's really going on behind the scenes,
there is probably no term, because at that point exactly what
is going on is up to the particular implementation. So, sure,
then we're left with the terms we have.
G
Greg Comeau
You're starting to loose me, but I'll try: compiling does include those
things, but compiling (in the case of compiling) is the translation act.
And yes, I guess it's valid to say that there are subtranslations
occuring within that sometimes.
J
JohnQ
"The standard doesn't really speak of "compiling" formally. It
specifies how a C++ is translated to an executable file, then
executed. The translation has a certain number of steps;
classically, some of those have been considered "compiling",
where as the last has been considered "linking". But modern
systems tend to blur the distinction, and most systems today
also use a single command line for the works. Thus, for
example, g++ is not what would have been called a compiler when
I was learning computer science; it's a driver program which
invokes different phases of the compiler and/or the linker,
depending on command line options, etc."
"Depending on the context today, "compiling" can mean what you do
to go from one or more .cc files to an executable binary, or
what you do to go from a single .cc file to a single .o/.obj
file, with linking being a separate step (and I can't think of a
good, simple verb for "building a library"). Note that with
g++, I use the commands g++ and cl (under Windows) for both
compiling and linking, and with Sun CC, I use the command CC for
building a library as well (although I use ar with g++, and lib
with cl)."
See, now that's what I think of as "compiling" also: the traditional use of
the term. So, would you consider going from source code to an intermediate
form, doing semantic analysis and such along the way, compiling? (The
intermediate form being symbol tables and such).
John
J
JohnQ
Greg Comeau said:
So there is no list of translation phases then (right?). I have the draft
standard, is the high level view of the phases discussed somewhere that you
know of and can point me to? If it's scattered all over the document without
overview though, that disuades me from diving into it. (I think you are
saying that it is scattered).
If I feel "ambitious" I'll open the pdf and skim through it looking for
relevant passages.
Tell me this though, if you know: are the phases purposely not defined to
give implementations more leeway? As in, "anything can happen between
ingesting the source code and putting out the resulting obj file".
It's all good info, but I'm just curious. Knowing the things that happen
"behind the scenes" somehow help me, but I don't know how. Well tool
selection maybe, but that's a stretch.
John
G
Greg Comeau
If it's an all encompassing carte blanche statement it probably is
pushing things, although there is still a point there.
However, chances are reasonable that even if you have a focused
look at things, you're using a multi-vendor solution, for instance,
a sub process which is invokes, or a library that is used, etc
(and yeah, I'm talking strickly about compiling).
It happens. Although I'm not sure that was that JK was saying,
although perhaps it was.
Actually it can be "old fashion" and is compiler-specific
while at the same time striving for some commonality.
Let's leave it at that.
Partially, sure.
So is doing it in assembler then
Anyway, no, as JK would then be saying using the same C compiler
which is not the same thing as what you just said (at least as
I'm reading it).
Because we can leverage off "C being available everywhere"
and use it as a portable assembler so to speak. And since C
vendors have tailored to specific CPUs etc, in their "back ends"
and that is hard, well, why should we?
I don't believe that is what JK is saying. Let's say Comeau was
a native compiler. JK's comments still remain in full force.
Delegating to C may be what we're doing as an implementation detail
but it's a moot aspect to JK's point, at least as I'm currently seeking it.
JK is not saying to make one implementation "THE C++".
I don't hear anybody disagreeing with this.
I still don't hear anybody disagreeing.
If C++ ceased to exist from today onward, it would be among one of
the most amazing successes in software/languages/etc. Saying otherwise
is just plain wrong.
Also, the demise of C++ has been hailed since its inception.
It has not happened. And the contrary happened, despite
poor initial marketing and many other obstacles. And yes,
it had many problems.
It's both. As above, let's leave it at that.
Now, *that's* silly
Maybe I'm tired, but coding around something that can be automatic
seems contrary to what we're usually using computers for.
Neither of these seems related to the discussion at hand,
or in any case, are true across the board, and so should shake
out no matter what the compiler or language.
There is a bit of both.
I'd love to see a new and better language than C++.
It's a BIG drawing board. Do you have it ready yet?
But something of the opposite of that has always been the case with C++.
So I'm going to say that what you just said it categorically false,
at least as I'm understanding it.