Where can I download Comeau compiler as a trial version?
Thanks in advice.
41  18001 
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
On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
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.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@r34g2000hsd.googlegr oups.com...
On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
>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!
:^)
"Chris Thomasson" <cr*****@comcast.netwrote in message
news:yv******************************@comcast.com. ..
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@r34g2000hsd.googlegr oups.com...
On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
>>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??
John
JohnQ wrote:
>
"Chris Thomasson" <cr*****@comcast.netwrote in message
news:yv******************************@comcast.com. ..
>"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@r34g2000hsd.googleg roups.com...
On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
>>>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!
Or more likely, you are using one of the many embedded platforms that
don't have a C++ compiler.
--
Ian Collins.
"Ian Collins" <ia******@hotmail.comwrote in message
news:5h**************@mid.individual.net...
JohnQ wrote:
>>
"Chris Thomasson" <cr*****@comcast.netwrote in message
news:yv******************************@comcast.com ...
>>"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@r34g2000hsd.google groups.com...
On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
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.
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
On Aug 8, 3:01 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Ian Collins" <ian-n...@hotmail.comwrote in message
news:5h**************@mid.individual.net...
JohnQ wrote:
"Chris Thomasson" <cris...@comcast.netwrote in message
news:yv******************************@comcast.com ...
"James Kanze" <james.ka...@gmail.comwrote in message
news:11**********************@r34g2000hsd.google groups.com...
On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
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.
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.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@22g2000hsm.googlegro ups.com...
On Aug 8, 3:01 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Ian Collins" <ian-n...@hotmail.comwrote in message
news:5h**************@mid.individual.net...
JohnQ wrote:
"Chris Thomasson" <cris...@comcast.netwrote in message
news:yv******************************@comcast.com ...
"James Kanze" <james.ka...@gmail.comwrote in message
news:11**********************@r34g2000hsd.google groups.com...
On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
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?
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
JohnQ wrote:
>
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@22g2000hsm.googlegro ups.com...
On Aug 8, 3:01 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
>"Ian Collins" <ian-n...@hotmail.comwrote in message
news:5h**************@mid.individual.net...
JohnQ wrote:
>"Chris Thomasson" <cris...@comcast.netwrote in message
news:yv******************************@comcast.co m...
"James Kanze" <james.ka...@gmail.comwrote in message
news:11**********************@r34g2000hsd.googl egroups.com...
On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
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?
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.
>
>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.
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_BI T_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
"LR" <lr***@superlink.netwrote in message
news:46***********************@news.uslec.net...
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
In article <NI*******************@newssvr12.news.prodigy.net> ,
JohnQ <jo***********************@yahoo.comwrote:
>"Chris Thomasson" <cr*****@comcast.netwrote in message
news:yv******************************@comcast.com ...
>"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@r34g2000hsd.googleg roups.com...
On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
>>>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?
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 / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
In article <CB*****************@newssvr29.news.prodigy.net> ,
JohnQ <jo***********************@yahoo.comwrote:
>"Ian Collins" <ia******@hotmail.comwrote in message
news:5h**************@mid.individual.net...
>JohnQ wrote:
>>"Chris Thomasson" <cr*****@comcast.netwrote in message
news:yv******************************@comcast.co m...
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@r34g2000hsd.googl egroups.com...
On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
>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.
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.
>Or more likely, you are using one of the many embedded platforms that
don't have a C++ compiler.
That niche I can understand.
OK :)
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
In article <11**********************@22g2000hsm.googlegroups. com>,
James Kanze <ja*********@gmail.comwrote:
>On Aug 8, 3:01 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
...
>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.
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 / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
In article <gs*****************@newssvr21.news.prodigy.net> ,
JohnQ <jo***********************@yahoo.comwrote:
>"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@22g2000hsm.googlegr oups.com...
On Aug 8, 3:01 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
>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?
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.
>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?
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.
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
JohnQ wrote:
>
"LR" <lr***@superlink.netwrote in message
news:46***********************@news.uslec.net...
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
"LR" <lr***@superlink.netwrote in message
news:46***********************@news.uslec.net...
JohnQ wrote:
>>
"LR" <lr***@superlink.netwrote in message
news:46***********************@news.uslec.net.. .
>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?
Hehe, anyone who "knows" me is saying, "shhh! don't get him started!".
>when it's not painful to do so.
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.
For me, I need only a fraction of the features C++ offers
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.
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.
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
"Greg Comeau" <co****@panix.comwrote in message
news:f9**********@panix2.panix.com...
In article <CB*****************@newssvr29.news.prodigy.net> ,
JohnQ <jo***********************@yahoo.comwrote:
>>"Ian Collins" <ia******@hotmail.comwrote in message
news:5h**************@mid.individual.net...
>>JohnQ wrote:
"Chris Thomasson" <cr*****@comcast.netwrote in message
news:yv******************************@comcast.c om...
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@r34g2000hsd.goog legroups.com...
On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
>>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.
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?
>
>>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.
>>Or more likely, you are using one of the many embedded platforms that
don't have a C++ compiler.
That niche I can understand.
OK :)
John
"Alf P. Steinbach" <al***@start.nowrote in message
news:13*************@corp.supernews.com...
>* 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.
I don't need it, I'm not building compilers.
>Example: A platform compiler that goes from C++ source to intermediate
form to assembly. Is that "compiling"?
Yes.
That was a rhetorical question. The context it was in suggests a more
abstract question.
John
"Alf P. Steinbach" <al***@start.nowrote in message
news:13*************@corp.supernews.com...
>* 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.
I don't need it. I'm not building a compiler.
John
On Aug 8, 11:57 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"James Kanze" <james.ka...@gmail.comwrote in message
news:11**********************@22g2000hsm.googlegro ups.com...
On Aug 8, 3:01 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Ian Collins" <ian-n...@hotmail.comwrote in message
>news:5h**************@mid.individual.net...
JohnQ wrote:
"Chris Thomasson" <cris...@comcast.netwrote in message
>news:yv******************************@comcast.com ...
>"James Kanze" <james.ka...@gmail.comwrote in message
>>news:11**********************@r34g2000hsd.google groups.com...
>On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
>>>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.
(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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
JohnQ wrote:
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?
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."
--
Thomas http://www.netmeister.org/news/learn2quote.html
In article <xg*****************@newssvr13.news.prodigy.net> ,
JohnQ <jo***********************@yahoo.comwrote:
>"Greg Comeau" <co****@panix.comwrote in message
news:f9**********@panix2.panix.com...
>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?
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.
>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.
One way to look at it is as a special compiler. Just like a compiler
is a special translator. And so on.
>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"?
Maybe front-end compiler would work for what I believe you're seeking.
>Now that I think about it more though, maybe going from source code to
intermediate form is "compiling", as in "compile to intermediate form" (!).
Aha! :)
>I know that the C++ defines the phases of translation, so maybe I'm just not
boned up on those definitions.
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 "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?
If I understand your question, yes, I would say they are different
forms and different stages of compiling.
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
In article <l2*****************@newssvr11.news.prodigy.net> ,
JohnQ <jo***********************@yahoo.comwrote:
>"Alf P. Steinbach" <al***@start.nowrote in message
news:13*************@corp.supernews.com...
...
>>You're saying that it's "compiling" rather than just "translating"..
Yes. If you don't have the Dragon book, get it.
I don't need it. I'm not building a compiler.
Ok, but you asked about some of this stuff, and the "Dragon Book"
is normally considered a solid reference on some of this stuff.
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
"Greg Comeau" <co****@panix.comwrote in message
news:f9**********@panix2.panix.com...
In article <l2*****************@newssvr11.news.prodigy.net> ,
JohnQ <jo***********************@yahoo.comwrote:
>>"Alf P. Steinbach" <al***@start.nowrote in message
news:13*************@corp.supernews.com...
...
>>>You're saying that it's "compiling" rather than just "translating"..
Yes. If you don't have the Dragon book, get it.
I don't need it. I'm not building a compiler.
Ok, but you asked about some of this stuff, and the "Dragon Book"
is normally considered a solid reference on some of this stuff.
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
"Greg Comeau" <co****@panix.comwrote in message
news:f9**********@panix2.panix.com...
In article <xg*****************@newssvr13.news.prodigy.net> ,
JohnQ <jo***********************@yahoo.comwrote:
>>"Greg Comeau" <co****@panix.comwrote in message
news:f9**********@panix2.panix.com...
>>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?
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.
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?
>
>>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.
One way to look at it is as a special compiler. Just like a compiler
is a special translator. And so on.
>>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"?
Maybe front-end compiler would work for what I believe you're seeking.''
Or how about, "precompiler"?
>
>>Now that I think about it more though, maybe going from source code to
intermediate form is "compiling", as in "compile to intermediate form"
(!).
Aha! :)
>>I know that the C++ defines the phases of translation, so maybe I'm just
not
boned up on those definitions.
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! :) ).
>
>>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?
If I understand your question, yes, I would say they are different
forms and different stages of compiling.
Or different contextual uses of the term 'compiling' more likely.
John
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@b79g2000hse.googlegr oups.com...
On Aug 8, 11:57 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"James Kanze" <james.ka...@gmail.comwrote in message
news:11**********************@22g2000hsm.googlegro ups.com...
On Aug 8, 3:01 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Ian Collins" <ian-n...@hotmail.comwrote in message
>news:5h**************@mid.individual.net...
JohnQ wrote:
"Chris Thomasson" <cris...@comcast.netwrote in message
>news:yv******************************@comcast.com ...
>"James Kanze" <james.ka...@gmail.comwrote in message
>>news:11**********************@r34g2000hsd.google groups.com...
>On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
>>>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.
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).
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++..."
I thought it was very compiler-specific 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.)"
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.
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?
"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.
3. <something about C++'s complexity leading to it's obsolescence>
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."
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!
(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."
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".
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."
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?
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."
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.
"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."
But within the same tool. Apples/oranges.
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.
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++. (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
JohnQ wrote:
"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.)"
Excuse me but I never got g++ to work under AIX.
It is completely full of bugs.
We used xLc
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46**********************@news.orange.fr...
JohnQ wrote:
"JohnQ quoted JK" you mean.
>
>"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.)"
Excuse me but I never got g++ to work under AIX.
It is completely full of bugs.
We used xLc
JohnQ wrote:
>
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46**********************@news.orange.fr...
>JohnQ wrote:
"JohnQ quoted JK" you mean.
Yes. Excuse me.
>
>>
>>"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.)"
Excuse me but I never got g++ to work under AIX.
It is completely full of bugs.
We used xLc
On Aug 10, 9:32 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Greg Comeau" <com...@panix.comwrote in message
news:f9**********@panix2.panix.com...
In article <l2wui.27099$RX.3...@newssvr11.news.prodigy.net> ,
JohnQ <johnqREMOVETHISprogram...@yahoo.comwrote:
>"Alf P. Steinbach" <al...@start.nowrote in message
news:13*************@corp.supernews.com...
...
You're saying that it's "compiling" rather than just "translating"..
Yes. If you don't have the Dragon book, get it.
I don't need it. I'm not building a compiler.
Ok, but you asked about some of this stuff, and the "Dragon Book"
is normally considered a solid reference on some of this stuff.
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
On Aug 10, 9:32 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Greg Comeau" <com...@panix.comwrote in message
news:f9**********@panix2.panix.com...
In article <l2wui.27099$RX.3...@newssvr11.news.prodigy.net> ,
JohnQ <johnqREMOVETHISprogram...@yahoo.comwrote:
>"Alf P. Steinbach" <al...@start.nowrote in message
news:13*************@corp.supernews.com...
...
You're saying that it's "compiling" rather than just "translating"..
Yes. If you don't have the Dragon book, get it.
I don't need it. I'm not building a compiler.
Ok, but you asked about some of this stuff, and the "Dragon Book"
is normally considered a solid reference on some of this stuff.
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.
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).
--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
In article <Tv**************@newssvr25.news.prodigy.net>,
JohnQ <jo***********************@yahoo.comwrote:
>
"Greg Comeau" <co****@panix.comwrote in message
news:f9**********@panix2.panix.com...
>In article <l2*****************@newssvr11.news.prodigy.net> ,
JohnQ <jo***********************@yahoo.comwrote:
>>>"Alf P. Steinbach" <al***@start.nowrote in message
news:13*************@corp.supernews.com...
...
You're saying that it's "compiling" rather than just "translating"..
Yes. If you don't have the Dragon book, get it.
I don't need it. I'm not building a compiler.
Ok, but you asked about some of this stuff, and the "Dragon Book"
is normally considered a solid reference on some of this stuff.
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.
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".
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
In article <TG***************@newssvr25.news.prodigy.net>,
JohnQ <jo***********************@yahoo.comwrote:
>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?
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.
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
On Aug 10, 9:32 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Greg Comeau" <com...@panix.comwrote in message
news:f9**********@panix2.panix.com...
In article <l2wui.27099$RX.3...@newssvr11.news.prodigy.net> ,
JohnQ <johnqREMOVETHISprogram...@yahoo.comwrote:
>"Alf P. Steinbach" <al...@start.nowrote in message
news:13*************@corp.supernews.com...
...
You're saying that it's "compiling" rather than just "translating"..
Yes. If you don't have the Dragon book, get it.
I don't need it. I'm not building a compiler.
Ok, but you asked about some of this stuff, and the "Dragon Book"
is normally considered a solid reference on some of this stuff.
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.
"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
In article <q6***************@newssvr25.news.prodigy.net>,
JohnQ <jo***********************@yahoo.comwrote:
>"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@b79g2000hse.googleg roups.com...
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.
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.
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).
>Me: Using 2 compilers in a chain is for very specialized, very
non-mainstream development scenarios.
You: No it's not.
It happens. Although I'm not sure that was that JK was saying,
although perhaps it was.
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++..."
I thought it was very compiler-specific C.
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.
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.
Partially, sure.
>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.
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).
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?
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?
>"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).
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.
>"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.
JK is not saying to make one implementation "THE C++".
>"(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.
I don't hear anybody disagreeing with this.
>2. I understand why people "close to" a language would think that way or try
to make it that way.
I still don't hear anybody disagreeing.
>3. <something about C++'s complexity leading to it's obsolescence>
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.
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."
I don't think so. That's why I said 'platform-specific' C.
It's both. As above, let's leave it at that.
>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!
Now, *that's* silly :)
>"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."
I think a better approach is to know what the issues are and then code
around them.
Maybe I'm tired, but coding around something that can be automatic
seems contrary to what we're usually using computers for.
>To wait for the next version of the platform-specific compiler
or the next C++ standard when "things are ready for prime time".
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.
>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."
Comeau is a very specialized tool, not in the same category as mainstream
compilers, IMO.
There is a bit of both.
>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?
I'd love to see a new and better language than C++.
It's a BIG drawing board. Do you have it ready yet? :)
>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."
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.
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.
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
"Greg Comeau" <co****@panix.comwrote in message
news:f9**********@panix1.panix.com...
In article <TG***************@newssvr25.news.prodigy.net>,
JohnQ <jo***********************@yahoo.comwrote:
>>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?
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.
I made another post that more firmly describes how I'm thinking of the
process. So pick it up there if you want to and let this tangential
subthread end. (I actually refer to the stuff in this subthread there).
John
In article <T%*****************@nlpi061.nbdc.sbc.com>,
JohnQ <jo***********************@yahoo.comwrote:
>
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@k79g2000hse.googleg roups.com...
On Aug 10, 9:32 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
>"Greg Comeau" <com...@panix.comwrote in message
>news:f9**********@panix2.panix.com...
In article <l2wui.27099$RX.3...@newssvr11.news.prodigy.net> ,
JohnQ <johnqREMOVETHISprogram...@yahoo.comwrote:
"Alf P. Steinbach" <al...@start.nowrote in message
news:13*************@corp.supernews.com...
...
You're saying that it's "compiling" rather than just "translating"..
Yes. If you don't have the Dragon book, get it.
I don't need it. I'm not building a compiler.
Ok, but you asked about some of this stuff, and the "Dragon Book"
is normally considered a solid reference on some of this stuff.
>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.
"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.
I'm surprised about this whole thread then! :)
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).
I prefer to think of things as a "compiler system" with a
"compiler proper" as one part.
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
"Greg Comeau" <co****@panix.comwrote in message
news:f9**********@panix1.panix.com...
In article <T%*****************@nlpi061.nbdc.sbc.com>,
JohnQ <jo***********************@yahoo.comwrote:
>>
"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@k79g2000hse.google groups.com...
On Aug 10, 9:32 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
>>"Greg Comeau" <com...@panix.comwrote in message
>>news:f9**********@panix2.panix.com...
>In article <l2wui.27099$RX.3...@newssvr11.news.prodigy.net> ,
JohnQ <johnqREMOVETHISprogram...@yahoo.comwrote:
"Alf P. Steinbach" <al...@start.nowrote in message
news:13*************@corp.supernews.com...
...
You're saying that it's "compiling" rather than just
"translating"..
Yes. If you don't have the Dragon book, get it.
I don't need it. I'm not building a compiler.
>Ok, but you asked about some of this stuff, and the "Dragon Book"
is normally considered a solid reference on some of this stuff.
>>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.
"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.
I'm surprised about this whole thread then! :)
It's probably because I'm learning stuff along the way. I _use_ C++, I don't
_implement_ it.
>
>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).
I prefer to think of things as a "compiler system" with a
"compiler proper" as one part.
I think I was asking JK, but OK. What you said though, probably in this day
needs more definition and can have it. (I mean, it's clear in my mind :) ).
John
JohnQ wrote:
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).
I'm not sure I understand that.
"(The intermediate form being symbol tables and such)."
What makes you think that the intermediate form would include symbol
tables? For what reason? And what does "and such" include?
I always thought that the intermediate form would be code of some kind.
In the case of Comeau's compiler, C code. But no reason it couldn't be
something else. For example I understand that more recent versions of
Visual C++ compile to MSIL or CIL and from there to various native
machine codes. You may find this of interest: http://en.wikipedia.org/wiki/MSIL
Not to say that a symbol table wouldn't be useful for, say, a cross
reference tool or something, but I don't see why it would be included in
the intermediate form.
But perhaps I'm wrong. What do you think the intermediate form is?
LR
On Aug 10, 10:13 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"James Kanze" <james.ka...@gmail.comwrote in message
news:11**********************@b79g2000hse.googlegr oups.com...
On Aug 8, 11:57 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"James Kanze" <james.ka...@gmail.comwrote in message
news:11**********************@22g2000hsm.googlegro ups.com...
On Aug 8, 3:01 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Ian Collins" <ian-n...@hotmail.comwrote in message
>news:5h**************@mid.individual.net...
JohnQ wrote:
"Chris Thomasson" <cris...@comcast.netwrote in message
>news:yv******************************@comcast.com ...
>"James Kanze" <james.ka...@gmail.comwrote in message
>>news:11**********************@r34g2000hsd.google groups.com...
>On Aug 1, 12:26 pm, "Bo Persson" <b...@gmb.dkwrote:
>>>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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"LR" <lr***@superlink.netwrote in message
news:46***********************@news.uslec.net...
JohnQ wrote:
>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).
I'm not sure I understand that.
"(The intermediate form being symbol tables and such)."
What makes you think that the intermediate form would include symbol
tables? For what reason? And what does "and such" include?
Well I was trying to narrow down what I meant. Whatever kind of constructs
the source code is parsed into, that's what I was considering "intermediate
form". "The place from which anything can be generated". "Symbol tables" was
just a traditional construct I tried to use to give an idea of what I
consider as "intermediate form".
>
I always thought that the intermediate form would be code of some kind.
Not me. No way. That's code generation. That comes after syntax checking and
semantic analysis and "putting into proprietary constructs". When source
code turns into those traditional programming constructs (say STL containers
and algos), THAT is intermediate form. (Or PRIMARY intermediate form).
In the case of Comeau's compiler, C code.
Nope. That comes after. That's "code generation". Sure, it's "intermediate",
but auxiliary.
Not to say that a symbol table wouldn't be useful for, say, a cross
reference tool or something, but I don't see why it would be included in
the intermediate form.
I think it pretty much IS the intermediate form.
>
But perhaps I'm wrong. What do you think the intermediate form is?
I tried to explain more above.
John This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Theodore Huxibolde |
last post by:
The Comeau C++ web site does not appear to have been updated in nearly
a year, but I do notice that Mr. Comeau does post here quite freqently.
Is this compiler still being actively developed and...
|
by: Rohit Upadhyay HCST |
last post by:
Hi !!!
I wanted to migrate to c++, But Im in no hurry
so I actually want to see how the C++ calls get
translated into C, using Cfront(the original thing
that Bjourne developed).
But I cant...
|
by: Miroslaw Makowiecki |
last post by:
Where do I download Comeau compiler as a trial version?
Thanks in advice.
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
