Where do I download Comeau compiler.

[Miroslaw Makowiecki]

Where can I download Comeau compiler as a trial version?
Thanks in advice.

 

[Bo Persson]

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/



Bo Persson

 

[James Kanze]

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.

 

[Chris Thomasson]

The purchase price is also dirt cheap; something even a student
could afford.

Right. Good price for a high quality product. Nice!

:^)

 

[JohnQ]

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??

John

 

[Ian Collins]

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!

Or more likely, you are using one of the many embedded platforms that
don't have a C++ compiler.

 

[JohnQ]

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.
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.

Or more likely, you are using one of the many embedded platforms that
don't have a C++ compiler.

That niche I can understand.

John

 

[James Kanze]

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.

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.

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. Comeau offers the same advantage, with even
better quality and better standard compliance.

As to "language-to-language translator": Comeau is just using C
as a platform neutral intermediate representation. It's not
really converting C++ to C, at least not to any C you'd ever
want to see. And who cares what intermediate representation is
being used. That's an internal detail of the compiler,
invisible to the user.

 

[JohnQ]

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?

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.

"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.

"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?

"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. (Which compilers it uses on which platforms, I
don't know. VC++ on Windows?)

"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. 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?

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.

"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.

Also, there's 2 vendor dependencies: Comeau front end and the platform
compiler. Seems painful: more vendors, more pain. Am I missing some info?
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?

John

 

[LR]

"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?

Because the end result is the same?

I once used a program that compiled and linked in one program. No need
to compile and link in two steps. But the end result was the same.
Although, there are plenty of situations where two programs, a compiler
and a linker would be better.

"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.

Not all the issue with the platform compiler. Because the compilation
process probably creates code that is more likely to compile and run
correctly, probably, in part, by using a subset of the language. I
haven't used this product in particular, but other front ends I've used
have worked that way.

"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.

I suppose that might depend on the conformance of the particular
compilers you are using.

I've seen plenty of code that has things like:

#ifdef GIANT_COMPUTER_CORP_VERSION_5_00
// do something strange
#endif
#ifdef GIANT_COMPUTER_CORP_VERSION_5_01A
// do something even stranger
#endif
#ifdef WOW_COMPUTER_MODEL_NINE_HAS_36_BIT_WORDS_AND_12_BIT_BYTES
// and you thought the other two were weird
#endif

"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?

Or when a particular target doesn't have a a C++ compiler that is
conforms enough to compile your code.

[snip]

I don't see how the effects of using multiple compilers/tools wouldn't
be additive as far as the potential issues go. 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?

No code is ever perfect. All code has bugs. But Comeau has a pretty
good reputation. If your question stands, then you ought to write in
assembler (ie write something that produces the code you want to run) on
every platform, because who's to say any compiler writer is going to be
better at it than you are.

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.

I suppose that in general compiler compliance is getting better, but
some are more compliant than others.

[snip]

Also, there's 2 vendor dependencies: Comeau front end and the platform
compiler. Seems painful: more vendors, more pain.

Everything is painful. I suppose it depends on what guarantees you get
from each vendor and how much you're paying.

> Am I missing some
info? 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?

That seems like it's going to be a somewhat subjective choice to me.
But I suppose a better choice could be made if you'll test the compiler
you are using for compliance and Comeau's and tell us which is more
compliant, (I understand that there are commercial packages available
that will help you with this) and also if those are features of the
language that are important to you, now and in the future.

This is pretty old, from November 2003, but may still be interesting to
you. It's been a long time since I read the article. I wish someone
would repeat this today. Maybe someone has. Does anyone know?
C++ Compilers & ISO Conformance
http://www.ddj.com/cpp/184405483

LR

 

[JohnQ]

This is pretty old, from November 2003, but may still be interesting to
you. It's been a long time since I read the article. I wish someone would
repeat this today. Maybe someone has. Does anyone know?
C++ Compilers & ISO Conformance
http://www.ddj.com/cpp/184405483

I'm sure I read it back then, but if I wasn't particularly concerned with
conformance issues then (I wasn't), I'm surely not today since I make an
effort to use as few features of the language as possible when it's not
painful to do so. For me, I need only a fraction of the features C++ offers
and would be happier with a stipped-down, non-conforming compiler with just
the features I use than a conforming compiler. But I know that's a "way out
there" point of view.

John

 

[Greg Comeau]

That's in addition to the compiler you must have to turn Comeau's generated
C code to machine code, yes?
Yes.

Why not just use the platform compiler (VC++ on
Windows, for example) in the first place?

There's many reasons for using a native compiler and an OS specific one.
There's also many reasons for not. IOWs, there a bag of pros and cons
that we each need to go through: vendor lock in, platform goodies,
portability, compliance, bring code to new platforms, etc, etc.

I don't understand how adding
translation steps and requiring more compilers is good.

You get that anyway. So it's just a question of how, not whether,
and at, the how can wash out too.

I could see how many
years ago when there weren't C++ compilers available on most platforms how
that would be good. But today??

That's still true. It's still one reason why C is very popular.

 

[Greg Comeau]

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.

There is some wiggle room for what we can call things, and I agree we
can explore that, but when push comes to shove, there is little else to
call the process except "compiling C++ to C," given all that needs to
be considered, and hence, calling the tools that does that, a compiler.
Personally I prefer to think Comeau offers a compiler system, since
some other stuff is going 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.

Mmm, no, if I understand you, that's not the choice. Probably we should
leave this until the above is explored further.

That niche I can understand.

OK

 

[Greg Comeau]

On Aug 8, 3:01 am, "JohnQ" <[email protected]>
wrote:
...

Better can mean many things: less bugs, more optimization,
stricter standards compliance... Off hand, Comeau beats VC++ two
out of three there.

And often can leverage the third by virtue of using what the
C compiler in question already uses/does.

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. Comeau offers the same advantage, with even
better quality and better standard compliance.

Indeed. I think that's a VERY strong argument for g++
("it's everywhere") and for Comeau, obviously for those who
need such.

 

[Greg Comeau]

"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?

James is talking about the logic flowchart of the thing.
You're talking about an actual implementation.
But each implementation is different, and each implementation
goes through it's own internal "X tools installed" issue,
so it's happening one way or the other.

"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?

In some cases, yes.

It still seems like you have all
the issues with the platform compiler plus any issues with the front end.

Intuition is often wrong. What usually happens is some of those
issues go away and new ones pop up. So in effect, it's "the same"
problem as any other compiler/vendor/etc just with it's own
specific issues.

"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.

There ya go

"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.

But the intent is for it to be used as such. Since VC++ was one
example in the thread thus far, you just wanna do 'cl ..options.. files..'
and get your executable, knowing it is doing many things behind the scenes.
With como, same thing: 'como ..options.. files..", and it'll be doing many
things behind the scenes too.

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?

That too.

"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. (Which compilers it uses on which platforms, I
don't know. VC++ on Windows?)

It's not incorrect. There's a few levels of "intermediate code",
symbol tables, etc. being tossed about, but once again, this is
usually the case anyway.

"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.

That X issues to deal with, from all the vendor, where X may not
be the same number for each vendor. Either they are dealt with,
or they are not.

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?

You lost me here, as James is not a compiler vendor.

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,

Sure, partially.

in or to be using the
product. If all your platforms had a C++ compiler or g++, you'd probably use
those/that.

This implies that it is optimal for each platform to have only
one compiler available. I know you did not mean that, but I'm
not sure what you do mean then. Perhaps I misread.

"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.

For the most part, there already is X representations, so this is just
par for the course.

Also, there's 2 vendor dependencies: Comeau front end and the platform
compiler. Seems painful: more vendors, more pain. Am I missing some info?

If we screw up, then we screwed it up, but if it works, it works.
This is so for Comeau, non-Comeau, dependency, or no-dependency.

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'll answer this more generally: It would depend upon a number of factors,
just as any compiler choice does.

 

[LR]

I'm sure I read it back then, but if I wasn't particularly concerned
with conformance issues then (I wasn't), I'm surely not today since I
make an effort to use as few features of the language as possible

Why?

when it's not painful to do so.

There's the rub.

> For me, I need only a fraction of the features C++ offers

Maybe you'd be happier with another language then? But of course, C++
does allow that wonderful flexibility. Use what you want, if not, then
don't, and the stuff you don't want today will be available when you
*need* it. A good reason to be concerned about conformance, even if you
don't need it Right Now.

> and would be happier with a stipped-down,
non-conforming compiler with just the features I use than a conforming
compiler. But I know that's a "way out there" point of view.

Well. You're not alone there. I hesitate to mention the name since it
seems to provoke flame wars, but there has been at least one effort
along those lines. I tend to agree with those who think that effort was
sadly misguided and mine is The Objective Point of View (tm), of course.

But seriously, if you really feel this way, then why C++? Why not some
other language? Does C++ have some particular feature that is
unavailable in other languages that you want? Which?

LR

 

[JohnQ]

Why?

Hehe, anyone who "knows" me is saying, "shhh! don't get him started!".

There's the rub.

I'll let that go, as I'm not trying to convince anyone to use a subset of
the language like I do.

Maybe you'd be happier with another language then?

And I may actually develop one someday or someone may do so and I'll switch.
But while I can say that "C++ is overkill" for my purposes, it doesn't
really matter if the features are there that I don't use. Especially since
compilers are for the most part free. Now if I had to pay for all the
features I don't use, that would bug me.

But of course, C++ does allow that wonderful flexibility. Use what you
want, if not, then don't, and the stuff you don't want today will be
available when you *need* it. A good reason to be concerned about
conformance, even if you don't need it Right Now.

Well, like I said above. But I don't foresee a time where I'll move back to
using what I used to use and abandoned.

Well. You're not alone there. I hesitate to mention the name since it
seems to provoke flame wars, but there has been at least one effort along
those lines. I tend to agree with those who think that effort was sadly
misguided and mine is The Objective Point of View (tm), of course.

You mean the effort from a looong time ago (early 90's)?

But seriously, if you really feel this way, then why C++? Why not some
other language? Does C++ have some particular feature that is unavailable
in other languages that you want? Which?

There isn't any other that meets my criteria. I like most of the C++ syntax
for instance. I'd like to have, and maybe I will develop, a preprocessor to
replace the standard one so I can "clean up" the syntax a bit and create
some new constructs to experiment with in the short term.

John

 

[JohnQ]

There is some wiggle room for what we can call things, and I agree we
can explore that, but when push comes to shove, there is little else to
call the process except "compiling C++ to C," given all that needs to
be considered, and hence, calling the tools that does that, a compiler.
Personally I prefer to think Comeau offers a compiler system, since
some other stuff is going on.

You're saying that it's "compiling" rather than just "translating" because
you are going to an intermediate form in between the C++ source and the
generated C source. I think Bjarne S. called cfront a compiler for that
reason too, noting that it had symbol tables etc. so that made it more than
a preprocessor. It really shouldn't be subjective, there should be industry
definitions that are unambigous. Are there?

Example: A platform compiler that goes from C++ source to intermediate form
to assembly. Is that "compiling"? Maybe it is because the resulting form is
native (x86 assembly, for example) to the hardware. Maybe it's not though.
Maybe it's just "translation to assembly". Maybe the assembler is the real
"compiler" because it produces a target in machine code.

I dunno. Certainly in the common usage, I think of going from source code to
machine code as "compiling". If a product gets me half way there, then to
me, it's a "front end" of some sort. So, more than a preprocessor, but less
than a compiler. A "translator"?

Now that I think about it more though, maybe going from source code to
intermediate form is "compiling", as in "compile to intermediate form" (!).
I know that the C++ defines the phases of translation, so maybe I'm just not
boned up on those definitions.

If "compiling" means going to intermediate form though, what is "going from
source to executable" then? Just a different form of compiling, as in
"compile to exe", "compile to assembly"? Is the terminology really ambiguous
or are there definitions?

Mmm, no, if I understand you, that's not the choice. Probably we should
leave this until the above is explored further.


OK

John

 

[Alf P. Steinbach]

* JohnQ -> Greg Comeau:

You're saying that it's "compiling" rather than just "translating"
because you are going to an intermediate form in between the C++ source
and the generated C source. I think Bjarne S. called cfront a compiler
for that reason too, noting that it had symbol tables etc. so that made
it more than a preprocessor. It really shouldn't be subjective, there
should be industry definitions that are unambigous. Are there?

Yes. If you don't have the Dragon book, get it.

Example: A platform compiler that goes from C++ source to intermediate
form to assembly. Is that "compiling"?

Yes.

 

[JohnQ]

* JohnQ -> Greg Comeau:

Yes. If you don't have the Dragon book, get it.

I don't need it, I'm not building compilers.

Yes.

That was a rhetorical question. The context it was in suggests a more
abstract question.

John