Board index » cppbuilder » Re: The best C++ compiler (not the IDE)

Re: The best C++ compiler (not the IDE)


2005-04-14 02:31:03 PM
cppbuilder72
"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message
Quote
Sorry if I got you wrong.
No problem. I still need to work on writing clearer. -Walter
 
 

Re:Re: The best C++ compiler (not the IDE)

"Alan Bellingham" < XXXX@XXXXX.COM >wrote in message
Quote
"Andrew Fenton" < XXXX@XXXXX.COM >wrote:
...
And then, Zortech got bought by Symantec, who renumbered the compiler
from somewhere around 3.1 to somewhere around 6.0 (you can tell I'm not
sure of the details, can't you). All the packaging turned bright yellow,
too.
Ah, THAT big yellow company! Not near the top of my list when considering
compilers, probably for reasons you previously stated.
Thanks,
Andrew
 

Re:Re: The best C++ compiler (not the IDE)

"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message
Quote
7) A std conforming compiler does not lock me
in.
Generally, that is true. But if your code is heavilly dependent on standard
behavior X, and only one compiler implements behavior X, then you're locked
in at least until some other compiler implements X too. All compilers will
fall short of the standard in one way or another, especially something as
incredibly complicated as C++.
The most practical approach is to decide what platforms your project needs
to compile on, and program to the subset of the standard that all the
compilers you need to use agree on. When it's time to ship a product, we all
have to work with the tools that are available rather than idealized tools
<g>.
 

{smallsort}

Re:Re: The best C++ compiler (not the IDE)

Walter < XXXX@XXXXX.COM >wrote:
Quote
"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>7) A std conforming compiler does not lock me
>in.

Generally, that is true. But if your code is heavilly dependent on standard
behavior X, and only one compiler implements behavior X, then you're locked
in at least until some other compiler implements X too. All compilers will
fall short of the standard in one way or another, especially something as
incredibly complicated as C++.
If I rely only on std conforming features,
I have the chance that, even if compiler X
currently doesn't implement it and I need
to workaround it, eitehr compiler X might
implement it in a later version or another
compiler might become available on this
platform which does what I need.
If I rely on proprietary features, chances
are less, that other compilers implement
those, too -- especially when I would need
them across platforms.
(And if you insist of making C++ so special,
then I have to say that, if nothing else
helps, Comeau is available on just about
any platform /I/ could imagine needing a
C++ compiler on and then some -- and Comeau
even ports their compiler for me if I am
really desperate. So, if C++ is special in
being exceptional complex, it is at the
same time different by having a very std
compliant compiler available on just about
every platform. -- Whether this is only by
incident remains to be discussed.)
Quote
The most practical approach is to decide what platforms your project needs
to compile on, and program to the subset of the standard that all the
compilers you need to use agree on. When it's time to ship a product, we all
have to work with the tools that are available rather than idealized tools
<g>.
If you can do this -- fine. We have found
ourself in the situation that we got offered
a good deal if we ported some app to some
platform nobody ever thought about when
they designed and implemented the app. When
you have been there a few times, you realize
what standards are good fro and why you don't
like vendors that don't take them seriously.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: The best C++ compiler (not the IDE)

"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message
Quote
Walter < XXXX@XXXXX.COM >wrote:
>"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message
>news: XXXX@XXXXX.COM ...
>>7) A std conforming compiler does not lock me
>>in.
>
>Generally, that is true. But if your code is heavilly dependent on
standard
>behavior X, and only one compiler implements behavior X, then you're
locked
>in at least until some other compiler implements X too. All compilers
will
>fall short of the standard in one way or another, especially something
as
>incredibly complicated as C++.

If I rely only on std conforming features,
I have the chance that, even if compiler X
currently doesn't implement it and I need
to workaround it, eitehr compiler X might
implement it in a later version or another
compiler might become available on this
platform which does what I need.
If I've invested $$$ in a software product, and I need to port it to
platform Y, I need to port it now, and do not want to be in the position of
hoping the Y compiler vendor will upgrade their compiler, nor can I afford
to wait for them to. As a businessman, there's just no way I'm going to
allow the reliance on features that are not widely available and stabley
implemented. The features in the C++ standard that are not widely available
and stabley implemented are easilly avoided. There's no reason to bet your
life savings, your company or your career on them.
Quote
If I rely on proprietary features, chances
are less, that other compilers implement
those, too -- especially when I would need
them across platforms.
(And if you insist of making C++ so special,
then I have to say that, if nothing else
helps, Comeau is available on just about
any platform /I/ could imagine needing a
C++ compiler on and then some -- and Comeau
even ports their compiler for me if I am
really desperate. So, if C++ is special in
being exceptional complex, it is at the
same time different by having a very std
compliant compiler available on just about
every platform. -- Whether this is only by
incident remains to be discussed.)
Isn't that just what you're trying to avoid, vendor lock-in? I have nothing
but admiration and respect for Greg Comeau, but being in a position where "I
am really desperate" and am totally dependent on one vendor is not where I
want to be if I have invested $$$ in a product, no matter how great they
are.
Quote
>The most practical approach is to decide what platforms your project
needs
>to compile on, and program to the subset of the standard that all the
>compilers you need to use agree on. When it's time to ship a product, we
all
>have to work with the tools that are available rather than idealized
tools
><g>.

If you can do this -- fine. We have found
ourself in the situation that we got offered
a good deal if we ported some app to some
platform nobody ever thought about when
they designed and implemented the app. When
you have been there a few times, you realize
what standards are good fro and why you don't
like vendors that don't take them seriously.
I've been there too. And I agree on the importance of standards conformance.
And I understand your dislike of vendors who don't take standard conformance
seriously. But that's all beside the point of the reality that you have to
work with the tools that exist. A few years ago, I was paid to port an app
to a platform that had a C++ compiler that wouldn't do dynamic_cast
correctly. The customer had no interest in porting problems or my feelings,
they wanted the app on that platform, and they wanted it yesterday. The only
thing to do was recode the app so it didn't rely on dynamic_cast. App
ported, the customer was happy.
(Since then, that C++ compiler has been improved and does it correctly now,
but that didn't help me *then*.)
For example, the day the C++ standard was approved back in 1998 did you stop
writing C++ code and wait for someone to implement 100% of it? Of course
not. You avoided using features that were unimplemented, like everyone else.
 

Re:Re: The best C++ compiler (not the IDE)

Walter < XXXX@XXXXX.COM >wrote:
Quote
[...]
>If I rely only on std conforming features,
>I have the chance that, even if compiler X
>currently doesn't implement it and I need
>to workaround it, eitehr compiler X might
>implement it in a later version or another
>compiler might become available on this
>platform which does what I need.

If I've invested $$$ in a software product, and I need to port it to
platform Y, I need to port it now, and do not want to be in the position of
hoping the Y compiler vendor will upgrade their compiler, nor can I afford
to wait for them to. [...]
Did I say anything against that? What I was
replying to was your argument, that writing
std conforming code locks me into the std.
What I wrote was, that the std is where /all/
compilers will get (close) to sooner or later,
so in the long run I won't be locked in.
Quote
[...]
>(And if you insist of making C++ so special,
>then I have to say that, if nothing else
>helps, Comeau is available on just about
>any platform /I/ could imagine needing a
>C++ compiler on and then some -- and Comeau
>even ports their compiler for me if I am
>really desperate. So, if C++ is special in
>being exceptional complex, it is at the
>same time different by having a very std
>compliant compiler available on just about
>every platform. -- Whether this is only by
>incident remains to be discussed.)

Isn't that just what you're trying to avoid, vendor lock-in? [...]
No, not at all. In fact, if we could use the
same compiler/std lib combination on all our
platforms, that would be the best thing that
could happen to us, iff that compiler/std lib
combination was 100% std conform. There's no
vendor lock in, as, if for some reason that
vendor isn't available anymore, you can
always use any other std compliant compiler.
(For exampe, we have Dinkumware on Windows,
MSL on the Mac, and used to have libstd on
Linux platforms. When we switched from libstd
to Dinkumware -- and to the much more std
conforming GCC3.4 -- on Linux, a lot of our
problems porting to Linux just went away, as
Dinkumware is just plain better. Oh, and we
got a whole bunch of new problems since we
switched to the much more std compliant GCC
3.4. <g>It does two-phase lookup and finds
a lot of syntax errors in the code which CW9
did let us get away with.)
Quote
[...]
I've been there too. And I agree on the importance of standards conformance.
And I understand your dislike of vendors who don't take standard conformance
seriously. But that's all beside the point of the reality that you have to
work with the tools that exist. [...]
Of course I have to use what's available. We
have to hack around bugs and quirks in our
compilers daily. However, if usually we stick
to the std, all those workarounds are temporary.
For example, I keep running into the weirdest
hacks surrounded by '#ifdef COMPILER_VC6'. Once
I spent nights to find those workarounds, now
I am happily removing them -- VC /did/ get much
better since then. Also, one old version of CW
couldn't tell one exception type from another
when both were instances of class template.
That was bad for my error handling which heavily
relied on exceptions being templates and we had
to hack around the isue to the point were the
advantages of this scheme got {*word*209}ed to a
nuisance. However, in the next version the
problem was solved (Ron is heaven-sent to MW's
customers), and meanwhile all these hacks are
gone.
I'd have gazillions of such stories to tell.
The main point is, that while we still do not
use a fully std compliant compiler, sticking
to the std did help us in the long run.
Quote
For example, the day the C++ standard was approved back in 1998 did you stop
writing C++ code and wait for someone to implement 100% of it? Of course
not. You avoided using features that were unimplemented, like everyone else.
If possible we used them on those platforms
that had them and hacked around them on all
others. For those features where this doesn't
work, we avoided them until they became widely
available. By the time I came into the position
of having to port a lot of code, most of the
latter category already were widely available.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: The best C++ compiler (not the IDE)

"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message
Quote
If I rely only on std conforming features,
I have the chance that, even if compiler X
currently doesn't implement it and I need
to workaround it, eitehr compiler X might
implement it in a later version or another
compiler might become available on this
platform which does what I need.
If I rely on proprietary features, chances
are less, that other compilers implement
those, too -- especially when I would need
them across platforms.
I see what you mean and mostly agree but the point
is that if you use Comeau for example and make
use of export then you're pretty muched locked into
Comeau aren't you? I think this is what Walter means.
 

Re:Re: The best C++ compiler (not the IDE)

In article <42602d29$ XXXX@XXXXX.COM >,
Duane Hebert < XXXX@XXXXX.COM >wrote:
Quote
"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message
news:425f9868$ XXXX@XXXXX.COM ...
...

I see what you mean and mostly agree but the point
is that if you use Comeau for example and make
use of export then you're pretty muched locked into
Comeau aren't you? I think this is what Walter means.
You guys have been having some good discussions this week!
Anyway, I think Hendrik sees that. But as I wrote last
week: "Some people disagree, and both sides seem right."
Actually, I suspect more than one thing may be being
discussed here, and perhaps more than one word or term
is necessary for qualification of which thing is being
discussed by each party... and when :)
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==>www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
 

Re:Re: The best C++ compiler (not the IDE)

"Greg Comeau" < XXXX@XXXXX.COM >wrote in message news:d3r89l$cjj$ XXXX@XXXXX.COM ...
Quote
In article <42602d29$ XXXX@XXXXX.COM >,
Duane Hebert < XXXX@XXXXX.COM >wrote:
You guys have been having some good discussions this week!
That's probably why we're both still here<g>
Quote
Anyway, I think Hendrik sees that. But as I wrote last
week: "Some people disagree, and both sides seem right."
Actually, I suspect more than one thing may be being
discussed here, and perhaps more than one word or term
is necessary for qualification of which thing is being
discussed by each party... and when :)
Don't misunderstand me. I would love to have export.
It's just that there were comments that a fully compliant
compiler would or would not lock you in. For example,
I do cross platform stuff. I would need compilers in
both Linux and Windows to support export before I
could use it. Short of that though, having a good compliant
compiler on both platforms that I target makes life
much easier.
 

Re:Re: The best C++ compiler (not the IDE)

In article <425f9868$ XXXX@XXXXX.COM >,
Hendrik Schober < XXXX@XXXXX.COM >wrote:
Quote
Walter < XXXX@XXXXX.COM >wrote:
>"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message
>news: XXXX@XXXXX.COM ...
>>7) A std conforming compiler does not lock me
>>in.
>
>Generally, that is true. But if your code is heavilly dependent on standard
>behavior X, and only one compiler implements behavior X, then you're locked
>in at least until some other compiler implements X too. All compilers will
>fall short of the standard in one way or another, especially something as
>incredibly complicated as C++.

If I rely only on std conforming features,
I have the chance that, even if compiler X
currently doesn't implement it and I need
to workaround it, eitehr compiler X might
implement it in a later version or another
compiler might become available on this
platform which does what I need.
True. IOWs, at least there is a light at the end of tunnel
for a path to eventually lead to such. But the problem is
that if you need it today, some people _feel_ they are locked in.
Of course, there is...
Quote
If I rely on proprietary features, chances
are less, that other compilers implement
those, too -- especially when I would need
them across platforms.
(And if you insist of making C++ so special,
then I have to say that, if nothing else
helps, Comeau is available on just about
any platform /I/ could imagine needing a
C++ compiler on and then some -- and Comeau
even ports their compiler for me if I am
really desperate.
... this :)
Quote
So, if C++ is special in
being exceptional complex, it is at the
same time different by having a very std
compliant compiler available on just about
every platform.
I of course agree.
Quote
-- Whether this is only by
incident remains to be discussed.)
It was purposely part of my plan, if that's what you mean.
Quote
>The most practical approach is to decide what platforms your project needs
>to compile on, and program to the subset of the standard that all the
>compilers you need to use agree on. When it's time to ship a product, we all
>have to work with the tools that are available rather than idealized tools
><g>.

If you can do this -- fine. We have found
ourself in the situation that we got offered
a good deal if we ported some app to some
platform nobody ever thought about when
they designed and implemented the app. When
you have been there a few times, you realize
what standards are good fro and why you don't
like vendors that don't take them seriously.
:)
Standards are not make to be stagnant, but I do agree.
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==>www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
 

Re:Re: The best C++ compiler (not the IDE)

In article <4260095a$ XXXX@XXXXX.COM >,
Walter < XXXX@XXXXX.COM >wrote:
.....
Quote
>are less, that other compilers implement
>those, too -- especially when I would need
>them across platforms.
>(And if you insist of making C++ so special,
>then I have to say that, if nothing else
>helps, Comeau is available on just about
>any platform /I/ could imagine needing a
>C++ compiler on and then some -- and Comeau
>even ports their compiler for me if I am
>really desperate. So, if C++ is special in
>being exceptional complex, it is at the
>same time different by having a very std
>compliant compiler available on just about
>every platform. -- Whether this is only by
>incident remains to be discussed.)

Isn't that just what you're trying to avoid, vendor lock-in? I have nothing
but admiration and respect for Greg Comeau, but being in a position where "I
am really desperate" and am totally dependent on one vendor is not where I
want to be if I have invested $$$ in a product, no matter how great they
are.
The odd think I find is that many people think nothing of locking
into one vendor while at the same time purposely avoiding others
because of possible locking in. Of course, reasons may differ.
And often reasons may be good, however, they are often not able
to see the extremes of their choice. :(
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==>www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
 

Re:Re: The best C++ compiler (not the IDE)

In article <42614f28$ XXXX@XXXXX.COM >,
Duane Hebert < XXXX@XXXXX.COM >wrote:
Quote
"Greg Comeau" < XXXX@XXXXX.COM >wrote in message news:d3r89l$cjj$ XXXX@XXXXX.COM ...
>In article <42602d29$ XXXX@XXXXX.COM >,
>Duane Hebert < XXXX@XXXXX.COM >wrote:

>You guys have been having some good discussions this week!

That's probably why we're both still here<g>

>Anyway, I think Hendrik sees that. But as I wrote last
>week: "Some people disagree, and both sides seem right."
>Actually, I suspect more than one thing may be being
>discussed here, and perhaps more than one word or term
>is necessary for qualification of which thing is being
>discussed by each party... and when :)

Don't misunderstand me. I would love to have export.
It's just that there were comments that a fully compliant
compiler would or would not lock you in. For example,
I do cross platform stuff. I would need compilers in
both Linux and Windows to support export before I
could use it.
Which has existed for years now :)
Quote
Short of that though, having a good compliant
compiler on both platforms that I target makes life
much easier.
Not short of it, but as well as it :)
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==>www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
 

Re:Re: The best C++ compiler (not the IDE)

"Greg Comeau" < XXXX@XXXXX.COM >wrote in message
Quote
In article <4260095a$ XXXX@XXXXX.COM >,
Walter < XXXX@XXXXX.COM >wrote:
>Isn't that just what you're trying to avoid, vendor lock-in? I have
nothing
>but admiration and respect for Greg Comeau, but being in a position where
"I
>am really desperate" and am totally dependent on one vendor is not where
I
>want to be if I have invested $$$ in a product, no matter how great they
>are.

The odd think I find is that many people think nothing of locking
into one vendor while at the same time purposely avoiding others
because of possible locking in. Of course, reasons may differ.
And often reasons may be good, however, they are often not able
to see the extremes of their choice. :(
What that usually means is that there are other, unarticulated, reasons for
their choice. I've been in this business a long time (so have you!) and one
thing I've learned is that there can often be a frustrating gap between what
people say they want and what they're willing to pay money for. When I've
built products based on market research, they've been duds. When I built one
based on my gut instinct, they've been successes. Go figure <g>.
 

Re:Re: The best C++ compiler (not the IDE)

Duane Hebert < XXXX@XXXXX.COM >wrote:
Quote
"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message
news:425f9868$ XXXX@XXXXX.COM ...

>If I rely only on std conforming features,
>I have the chance that, even if compiler X
>currently doesn't implement it and I need
>to workaround it, eitehr compiler X might
>implement it in a later version or another
>compiler might become available on this
>platform which does what I need.
>If I rely on proprietary features, chances
>are less, that other compilers implement
>those, too -- especially when I would need
>them across platforms.

I see what you mean and mostly agree but the point
is that if you use Comeau for example and make
use of export then you're pretty muched locked into
Comeau aren't you? I think this is what Walter means.
Of course, there are features that you
simply cannot hack around, if they're
missing. I see two ways to deal with
those: You either don't use them or,
if this isn't possible (say you have a
large code base using them that you
need to port), then you need to look
for tools that have what you need.
Anyway, I don't think 'eport' is one
of those. I haven't used it yet, but I
can imagine that you can invent some
rather trivial macros that let you use
it on those platforms that have it and
let you use includes on the others.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: The best C++ compiler (not the IDE)

Greg Comeau < XXXX@XXXXX.COM >wrote:
Quote
[...]
>If I rely only on std conforming features,
>I have the chance that, even if compiler X
>currently doesn't implement it and I need
>to workaround it, eitehr compiler X might
>implement it in a later version or another
>compiler might become available on this
>platform which does what I need.

True. IOWs, at least there is a light at the end of tunnel
for a path to eventually lead to such. But the problem is
that if you need it today, some people _feel_ they are locked in.
If I need some std C++ feature, the chances
I might find some implementation that makes
it available to me are a lot higher than if
I need something proprietary.
Quote
[...]
>So, if C++ is special in
>being exceptional complex, it is at the
>same time different by having a very std
>compliant compiler available on just about
>every platform.

I of course agree.
You of all involved here!. :)
Quote
>-- Whether this is only by
>incident remains to be discussed.)

It was purposely part of my plan, if that's what you mean.
No. I meant that it might not be
incidentally that C++, while rather
complex and hard to get right for tools
vendors, has some very std compliant
tools (like yours or Dinkumware's).
Quote
>[...] We have found
>ourself in the situation that we got offered
>a good deal if we ported some app to some
>platform nobody ever thought about when
>they designed and implemented the app. When
>you have been there a few times, you realize
>what standards are good fro and why you don't
>like vendors that don't take them seriously.

:)

Standards are not make to be stagnant, but I do agree.
The old How-to-hit-a-running-target
problem. Nevertheless, there's tags and
if I stick to the 1.0 branch instead of
the HEAD, it's rather stable.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett