On Aug 10, 10:13 am, "JohnQ" <johnqREMOVETHI Sprogram...@yah oo.com>
wrote:
"James Kanze" <james.ka...@gm ail.comwrote in message
news:11******** **************@ b79g2000hse.goo glegroups.com.. .
On Aug 8, 11:57 am, "JohnQ" <johnqREMOVETHI Sprogram...@yah oo.com>
wrote:
"James Kanze" <james.ka...@gm ail.comwrote in message
news:11******** **************@ 22g2000hsm.goog legroups.com...
On Aug 8, 3:01 am, "JohnQ" <johnqREMOVETHI Sprogram...@yah oo.com>
wrote:
"Ian Collins" <ian-n...@hotmail.co mwrote in message
>news:5h******* *******@mid.ind ividual.net...
JohnQ wrote:
"Chris Thomasson" <cris...@comcas t.netwrote in message
>news:yv******* *************** ********@comcas t.com...
>"James Kanze" <james.ka...@gm ail.comwrote in message
>>news:11****** *************** *@r34g2000hsd.g ooglegroups.com ...
>On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwro te:
>>>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
platform
compiler (VC++ on Windows, for example) in the first place? I don't
understand how adding translation steps and requiring more
compilers is
good. I could see how many years ago when there weren't C++
compilers
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."
That's a facetious argument. The window is that of compiling source code.
Not really. The window is building an executable from the
sources I wrote. In practice, of course, those sources are
almost never pure C++; who writes out complex table
initializations , when AWK can do it from a simple text file more
easily? Can you really say that you've created a serious C++
program in which none of the sources are automatically
generated? Can you really say that you don't use some sort of
source code control, and that your sources aren't necessarily
directly accessible from the compiler? That you don't use a
data base, or a third party windowing library, or any third
party connectivity software?
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
Me: Using 2 compilers in a chain is for very specialized, very
non-mainstream development scenarios.
You: No it's not.
You're missing the point. If you use Comeau, that's the only
"compiler" you have in your chain. Comeau, of course, may use
other tools, but then, so does g++ on my Solaris machine.
That's Comeau's problem, not mine. And of course, a "compiler"
is simply not the only tool I have in my tool chain. I use lex,
yacc, awk, etc. for code generation. I use third party
libraries for data base accesses. I do depend on multiple
suppliers. I can't imagine any serious application which
didn't; you don't work in a vacuum, and you certainly aren't
going to redevelop everything yourself.
(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).
I'm not sure I follow you. You seem to have created an
artificial category: compilers. The tools I use to "compile"
code are drivers which invoke multiple sub-tools. In some
cases, all of the sub-tools come from the same supplier, but not
always: g++ under Solaris uses the Sun linker, for example.
[...]
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.)
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.
That's a more or less accurate way of describing it. Just as by
using a high level language, I'm jobbing out the differences in
machine architecture, and by using a commercial database, I'm
jobbing out the incredible amount of work which would be
necessary to write one myself. Anytime I can job work out, I
win.
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.
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?
The real question is: why should they? They have something
which works. They make it available at a very reasonable cost.
If Greg had to write (or pay someone to write) a machine code
back-end for each platform, the compiler would cost more. Just
as I use a commercial database, rather than write my own,
because I get a lot better product a lot cheaper that way, Greg
lets the specialists in each machine architecture provide the
back-end for that architecture.
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.
It is. EDG has done so, and it certainly has a lot less
resources that companies like MS or Sun.
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.
Something is very, very wrong. Some suppliers have chosen to
ignore the standard, for whatever reasons, and just implement
the parts of it which interest them. Often with in house
extensions added to it.
(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.
That's probably because you've never had to develop professional
level code. What do you base your language understanding on, if
not the standard? You have a choice: standard conformance, or
vendor lock in and unportability.
[...]
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.
In theory, you're right. In practice, you have no means of
really knowing in advance what all of the issues are going to
be. Compiler vendors don't advertise up front that they don't
actually do some things correctly.
[...]
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.
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.
You, maybe. You've already mentionned that you don't like or
use templates. If you don't like or use templates, then many of
the issues do disappear. As it happens, I'd like to use
templates, but most companies still forbid them at the
application level, because of portability problems. There are
things in Boost I'd like to use, but some companies still forbid
even the standard library, because of portability concerns (and
in fact, we've had problems recently when porting code from Sun
CC to g++, and vice versa).
Use Comeau and the Dinkumware libraries everywhere, and this set
of problems disappear. (Use C90, and they disappear as well.
Interestingly enough, use C99, and you run into exactly the same
sort of problems. Which sort of proves that the problem isn't
with the complexity of the language per se, but with the
decision of compiler vendors to more or less ignore the
standard, at least in part, and with compiler users to accept
this without complaint.)
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.
Again, that's a (THE) problem with C++.
And C. And Fortran. In the past, it was always a serious
problem with Cobol---today, the only people using Cobol are on
IBM mainframes, so the problem has disappeared.
(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).
In at least one case (and no, I'm not thinking of Microsoft
here), it's very clear that the vendor would prefer that all
developments use his own language, rather than C++. More
generally, it is a question of allocation of resources, and it
would seem that most vendors, today, are more concerned with
somehow "locking you in", or at least supplying special platform
specific features, than being standard conformant. So that's
where they put their resources.
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.
A problem shared by most languages today, it would seem. (Ask
about support for C99 in comp.lang.c, for example.)
--
James Kanze (GABI Software) email:james.ka. ..@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
