Re: Where do I download Comeau compiler.
On Aug 8, 11:57 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:1186564577.100962.268040@22g2000hsm.googlegroups.com...
On Aug 8, 3:01 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Ian Collins" <ian-n...@hotmail.com> wrote in message
news:5hsg1eF3lvf8eU19@mid.individual.net...
JohnQ wrote:
"Chris Thomasson" <cris...@comcast.net> wrote in message
news:yvWdnbR3-7tHByzbnZ2dnUVZ_h-vnZ2d@comcast.com...
"James Kanze" <james.ka...@gmail.com> wrote in message
news:1186041484.420452.160970@r34g2000hsd.googlegroups.com...
On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dk> wrote:
Miroslaw Makowiecki wrote:
:: Where can I download Comeau compiler as a trial version?
:: Thanks in advice.
You cannot. You can test-drive it on their web site though
http://www.comeaucomputing.com/tryitout/
The purchase price is also dirt cheap; something even a student
could afford.
Right. Good price for a high quality product. Nice!
That's in addition to the compiler you must have to turn Comeau's
generated C code to machine code, yes? Why not just use the platfo=
rm
compiler (VC++ on Windows, for example) in the first place? I don't
understand how adding translation steps and requiring more compile=
rs is
good. I could see how many years ago when there weren't C++ compil=
ers
available on most platforms how that would be good. But today??
You might want a better compiler!
1. I wouldn't call something that translates from one high
level language to another a compiler. (Just like I wouldn't
consider cfront one). I'd call the components that do
translation (to intermediate form) that occurs before the C
code generation a compiler front-end.
Formally, you're probably correct, but practically, it comes out
to the same thing.
How can you consider "the same thing" having to have 2 tools
installed rather than just one to get the same result?
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.)
2. If by "better", you mean "better compliance with the
standard", well it would have to be an awfully critical need
for some feature that would cause one to go from a compiler to
a language-to-language translator.
Better can mean many things: less bugs, more optimization,
stricter standards compliance... Off hand, Comeau beats VC++ two
out of three there.
But Comeau feed into VC++ (or g++), yes? It still seems like
you have all the issues with the platform compiler plus any
issues with the front end.
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++...
Better can also mean portability. One of the strongest motives
I know for using g++ is that I have the same compiler on all of
my platforms.
Though using different compilers does help check out your code better.
You'll probably write less portable code and have more bugs within the
safety of one compiler than if you were to build with many.
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.)
Comeau offers the same advantage, with even better quality and better
standard compliance.
But it's still apples and oranges if you ask me because Comeau
is not a "from source to executable" product. It seems like a
special-purpose product to use when you want to code in C++
but one or more of your target platforms doesn't have a C++
compiler. Yes?
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.)
As to "language-to-language translator": Comeau is just using C
as a platform neutral intermediate representation.
I don't think that is correct. I think it translates to
platform-compiler-specific C.
That's true. But it's still a basic "format" that can be used
on just about every platform.
(Which compilers it uses on which platforms, I
don't know. VC++ on Windows?)
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.)
It's not really converting C++ to C, at least not to any C
you'd ever want to see.
I don't see how the effects of using multiple compilers/tools
wouldn't be additive as far as the potential issues go.
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.
It's
just that Comeau abstracts one away from one set of the
issues. But who's to say they're better at it than you are?
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.
It appears to me that you'd have to be targeting a lot of
"weird" hardware where Comeau is and other C++ compilers
aren't, in or to be using the product. If all your platforms
had a C++ compiler or g++, you'd probably use those/that.
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.
"And who cares what intermediate representation is
being used. That's an internal detail of the compiler,
invisible to the user."
Having TWO intermediate representations doesn't seem good.
You've doubtlessly got more than that already.
Also, there's 2 vendor dependencies: Comeau front end and the
platform compiler. Seems painful: more vendors, more pain. Am
I missing some info?
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.
Would you agree that if I was (just) developing GUI programs
with wxWindows on Windows and on FreeBSD/X I would not want to
use Comeau?
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.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34