Board index » cppbuilder » Re: Borland Bashing- is it productive at this point?

Re: Borland Bashing- is it productive at this point?


2005-05-15 09:50:00 AM
cppbuilder2
"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news:428673e8$ XXXX@XXXXX.COM ...
Quote
I remember at the time wanting a far more elaborate assertion mechanism.
Check this out <g>:
www.digitalmars.com/d/dbc.html
 
 

Re:Re: Borland Bashing- is it productive at this point?

Walter wrote:
Quote
"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news:428673e8$ XXXX@XXXXX.COM ...

>I remember at the time wanting a far more elaborate assertion mechanism.

Check this out <g>:

www.digitalmars.com/d/dbc.html
Neato!
I don't get this sentence:
"If a function in a derived class overrides a function in its super class, then only
one of the in contracts of the base functions must be satisified Overriding functions
then becomes a process of loosening the in contracts."
This part in particular: "only one of the in contracts of the base function"? A base
function can have multiple contracts and somehow one but one get ignored once you
override that function in a derived class?
One issue: one could write a lot of assertions/contracts and want to do something
other than "turn them all on" or "turn them all off". Turning them all on might
introduce so much performance degradation that it wouldn't be worth doing. A first
cut way to deal with this woud be to turn them on for some classes and not for other
classes. But a finer way would be to be able to turn them on for some methods only.
Suppose a function manipulates a few different data structures. Your interest might
be in the integrity of just one of those data structures. So you might want to turn
on assertion checking only on calls that manipulate that data structure.
 

Re:Re: Borland Bashing- is it productive at this point?

"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote:
Quote
>... One interesting side effect of fixing bugs for 20
>years is I've wound up with a rather formidable test
>suite consisting of everything that has failed before.

I think few vendors would keep a record of the bugs they have fixed
over the years.
It's pretty standard practice, actually. I'm not sure about the
GNU compiler team. But I'm pretty sure all the commercially
active C++ front end implementors keep a comprehensive
record of bugs fixed (and improvements made) and an
associated regression suite.
Daveed
 

{smallsort}

Re:Re: Borland Bashing- is it productive at this point?

"Walter" < XXXX@XXXXX.COM >wrote:
Quote

"Daveed Vandevoorde" < XXXX@XXXXX.COM >wrote in message
news:42856e50$ XXXX@XXXXX.COM ...
>I mostly
>Google for "Vandevoorde", "Vandervoorde" (duh!), and "Daveed"
>to decide where I should spend some cycles trying to clarify
>things.

LOL. I have some friends who are expecting a baby, and we were talking about
baby names. I suggested that they should consider the google effect. Is it
better to have a relatively unique name so it is googlable, or a relatively
common name so that one can be anonymous on the net? From their reaction it
was obvious they'd never thought of that!
We're also expecting (our second one). Right now we're agonizing
because they couldn't tell us whether it'll be a boy or a girl: So we're
trying to come up with names for both possibilities. They won't be
super-common (and the last name is fairly common in Benelux, but
that's a limited population).
Unfortunately, they don't acccept square brackets in names.
I thought "Kid[0]" and "Kid[1]" would have been most convenient.
Daveed
 

Re:Re: Borland Bashing- is it productive at this point?

In article <427e8db2$ XXXX@XXXXX.COM >,
Walter < XXXX@XXXXX.COM >wrote:
Quote
The only reason to care about minimizing the need for recompilation
is concern about compile speed.
Although I'm responding to Walter's words, I'd rather
make my response more to the thread than to Walter.
That is, I think this thread has boxed itself into a corner,
as it's focusing too much on the low level.
So to back off that, I don't think there is a sole reason
to minimize recompilation. For instance, there is
source code organization, design relationships, etc.
and when possible, those should take the lead.
I agree that often speed related considerations are issues,
and I agree we often even do source code things to
achieve that goal, but not always.
There is always something to be said about high level concepts
and techniques that follow thereof. I am not saying
we should go to the other extreme, or that we should
stay theoretical (although I don't think this is theoretical
in this case) just that there is room for both,
and many respective midpoints issues.
I just reread some of the messages quickly and pulled
out what may be the key gridlocks in addition to the above:
In article <427ff984$ XXXX@XXXXX.COM >,
Walter < XXXX@XXXXX.COM >wrote:
Quote
I disagree with the assumption that one approach "solves" the
speed problem and another does not. I'd rephrase it as:
If [compiler x] is significantly faster without export than
Compiler X is with export, which is addressing the customer's
needs better?
and
In article < XXXX@XXXXX.COM >,
Hendrik Schober < XXXX@XXXXX.COM >wrote:
Quote
whatever the compilation speed ... is, it will
certainly take longer to compile a certain number
of LOC than to not to compile it.
This is probably the classic case where you're both right and
it seems to me that situation lies between the two points.
--
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: Borland Bashing- is it productive at this point?

In article < XXXX@XXXXX.COM >,
Hendrik Schober < XXXX@XXXXX.COM >wrote:
Quote
Walter < XXXX@XXXXX.COM >wrote:
>I cannot understand why build speed is a serious problem but compile/link
>speed isn't. The flaw in your argument is the assumption that export
>technology, no matter how long it takes to implement, is the only way to
>address build speed. What should matter is the time it takes to do a build,
>the underlying technology to get that done should be irrelevant.

It might not be the only way, but it's the one
that I expect (and was asserted to gain) the
most dramatic improvements from. It could well
cut the number of files that need to get
recompiled by three orders of magnitude. In a
code base with around 1MLOC, that's many hours
to be gained each week.
Even if your compile was five times faster than
the second fastest on the market, it would gain
me only a few minutes per week -- not enough to
go through the hassle of porting, adapting the
tool chain, and loosing support for some very
important 3rd-party APIs.
As in my other email, I suspect you are both correct
under the right conditions, and I also suspect legitimate
examples can be made to illustrate both aspects.
And perhaps more importantly, in combination.
--
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: Borland Bashing- is it productive at this point?

"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news: XXXX@XXXXX.COM ...
Quote
"If a function in a derived class overrides a function in its super class,
then only
one of the in contracts of the base functions must be satisified
Overriding functions
then becomes a process of loosening the in contracts."

This part in particular: "only one of the in contracts of the base
function"? A base
function can have multiple contracts and somehow one but one get ignored
once you
override that function in a derived class?
That could have been written better. It should say only one of the base
functions needs to have its in clause satisifed.
Quote
One issue: one could write a lot of assertions/contracts and want to do
something
other than "turn them all on" or "turn them all off". Turning them all on
might
introduce so much performance degradation that it wouldn't be worth doing.
A first
cut way to deal with this woud be to turn them on for some classes and not
for other
classes. But a finer way would be to be able to turn them on for some
methods only.
True, but I want to see how far this goes first.
Quote
Suppose a function manipulates a few different data structures. Your
interest might
be in the integrity of just one of those data structures. So you might
want to turn
on assertion checking only on calls that manipulate that data structure.
You can turn it on and off on a per-module basis.
 

Re:Re: Borland Bashing- is it productive at this point?

In article <42813653$ XXXX@XXXXX.COM >,
Randall Parker < XXXX@XXXXX.COM >wrote:
Quote
Hendrik Schober wrote:
>Walter < XXXX@XXXXX.COM >wrote:
>>So, are you, in actuallity, saving hours using Comeau C++?
>
>I already told you that the platform where
>we have a compiler available that supports
>'export' is not used for writing software.
>Software is only ported to it. That's a mere
>minor task, not involving many builds. It's
>not worth the effort to enable 'export' in
>our codebase and obfuscate the code through
>the workarounds necessary for the other
>platforms. We are herding about half a dozen
>platforms. Features requiring workarounds on
>at half of them or even more won't get used.
>Otherwise the code would consist of more
>workarounds than actual code.

...
I'm curious to know when it comes to developing fairly portable C++
whether Comeau or DMC or other compilers have advantages over MS in
terms of debuggability.
Not sure how you mean debugability. But if you mean with a de{*word*81},
Comeau does not come with a de{*word*81}, but can often use aspects of
the back end C compiler's de{*word*81}.
Quote
Or do they have advantages over MS in terms of better compiler error
messages?
VC++ diagnostics have improved recently IMO, but quality diagnostics
from Comeau are well known IMO.
Quote
In other words, for someone who is trying to be platform independent
can a compelling case be made for some toolset other than MS and for
what strengths would one want to use one of the other toolsets?
Not sure what you mean, as MS is not platform independent.
Quote
Is DMC better at pre-compiled headers than Borland or MS?
Or is Comeau? Or some other C++ compiler?
It would need to be put to a test I would think, in addition
to defining "better", etc.
Quote
Also, is Comeau the only compiler offering export?
At least the only one publicizing 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: Borland Bashing- is it productive at this point?

In article <428185ae$ XXXX@XXXXX.COM >,
Walter < XXXX@XXXXX.COM >wrote:
Quote
Reality can and often does give surprising results to conventional wisdom
gedanken experiments.
I very much agree.
Quote
That's why I, over and over, suggest you actually try
it. You have the means at your disposal, right now, to do it.
As with any such test, just doing it is insufficient.
There are too many variables which need to be understood,
or at least spelling out as the limits. I know you know this,
but it's not coming out that way.
Quote
You have Comeau C++ which implements export. If export will save you hours,
you don't even need to download DMC++ to test that theory. Just benchmark
Comeau against whatever else you are currently using.
If you still won't use Comeau C++, then I believe you've answered the
question as to why other compiler vendors haven't implemented export.
I very much disagree, at least to the extent again that you're
expressing this. He has reasons to not use Comeau C++ that may
have nothing to do with export, and he may have reasons to not
use Comeau C++ that may have everything to do with export.
Or something in the middle. It's far from "must be" and does
not always need to be an either or 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: Borland Bashing- is it productive at this point?

In article < XXXX@XXXXX.COM >,
Hendrik Schober < XXXX@XXXXX.COM >wrote:
Quote
Randall Parker < XXXX@XXXXX.COM >wrote:
>In other words, for someone who is trying to be platform independent
>can a compelling case be made for some toolset other than MS and
>for what strengths would one want to use one of the other toolsets?

I think it was Robert C. Martin who once wrote
that no piece of software is re-usable before
it hasm't actually been re-used. (The point of
which is that what's been needed for that can
only be discovered on the way.)
One can do better than just the element of surprise, but...
Quote
IME the same
applies to being platform/tool-independent. In
order to be independent of a certain tool, you
have to user other tools all the time. Otherwise
you will use tool-specific stuff without even
realizing it.
... it's damn hard.
Quote
The more compilers you actually
compile, test, and run your code on, the more
independent you are. But if you don't do this
constantly, you will actually port software
written with only one platform in mind to some
other platform -- which is a PITA.
Yup.
Quote
OTOH, you can get rid of many problems by using
the same tool on every platform you need to
support. If you, e.g., use Comeau+Dinkumware on
all your platforms, that solves many problems.
Yup again.
Quote
However, it doesn't solve all. UIs, threads,
and many other stuff will still be platform-
dependent. And it brings in other problems
(like the one we have), which might weigh more
or less -- depending on your needs.
Indeed. From a quick skim I see later on in this thread
some mentions of regressions, etc. We are often asked
"If EDG already wrote the C++ front end, then you don't
do anything right, and so why should we buy it from you."
But it's more than just compiling it, and there is a whole
set of non-C++ specific problems which must be addressed.
Not only X times for X platforms, but X+Y too. For instance,
to release a fix can mean not only retesting on the
immediate platform in question, but for all of them.
--
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: Borland Bashing- is it productive at this point?

Randall Parker wrote:
Quote
Back in the first version it didn't have as many of those. I forget
whether it didn't have preconditions or if it didn't have
postconditions. But I remember way back in 1987 or 1988 or
thereabouts something obvious was missing.
You mean something like the following:
www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1800.pdf
[link to design-by-contract proposal presented to C++ committee for
next C++ standard]
AlisdairM(TeamB)
 

Re:Re: Borland Bashing- is it productive at this point?

In article <42823e9b$ XXXX@XXXXX.COM >,
Walter < XXXX@XXXXX.COM >wrote:
Quote

"Daniel James" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>In article <427fac90$ XXXX@XXXXX.COM >, Walter wrote:
>>The point is that there are many ways to improve build speed. Since
>>build speed is one of the 4 main arguments in favor of export, it
>>makes sense to compare it with other methods of improving build
>>speed when doing a cost/benefit analysis of the value of export.
>
>It also makes sense to consider the benefit that might be gained by
>combining the techniques.
>
>Given that export and PCH give compilation speed-ups for different reasons
>I would expect the two together to give a greater overall increase than
>either on its own.
>
>That doesn't sound like a good reason to eschew one in favour of the
other.

One must look at the costs as well as the benefits. It isn't just a cost to
the compiler vendors - the compiler users pay for such expensive features
too. They pay in terms of years of waiting, and they must necessarilly give
up other desirable features that the compiler vendor won't be working on
instead.

What are you willing to give up for export in the meantime? Better code
optimization? Better libraries? Better de{*word*81}s? X86-64 support?

I've noticed in these various threads that many proponents of export are not
willing to switch compilers to get it. That means that they are NOT willing
to give up other things for export. This speaks volumes to compiler vendors
about what's important. Putting everything else on hold while the compiler
is razed and rebuilt over a year or two is an enormous risk for losing your
existing customer base.
Any feature being worked on is clearly a compromise that needs to be
made over one that is not.
IMO, the politics of export have overinfluences that technical
aspects of export.
IMO, such discussions of compiler razing as a blanket statement
are similar to comments earlier in this thread about early
implemntor's not being pragmatic, and partaking of imptuousity:
they are false.
--
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: Borland Bashing- is it productive at this point?

In article <42826079$ XXXX@XXXXX.COM >,
Randall Parker < XXXX@XXXXX.COM >wrote:
Quote
Walter wrote:
>One must look at the costs as well as the benefits. It isn't just a cost to
>the compiler vendors - the compiler users pay for such expensive features
>too. They pay in terms of years of waiting, and they must necessarilly give
>up other desirable features that the compiler vendor won't be working on
>instead.

Walter, I totally agree on this point. Every time someone shows up asking
that we all join in and advocate for x86-64 support I respond with a list
of other things I would like to see improved /before/ Borland takes on
x86-64 support.
Indeed. An issue that a vendor has is to also juggle the often
opposing additions, deletion and change suggestions, and some
parts involve forward-thinking guesses. As with all of us,
sometimes it's gotten right and gotten wrong, sometimes a toss up.
Re export, I personally think the cost has been sensationalized,
though this is by no means to suggest that it's trivial, far from 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: Borland Bashing- is it productive at this point?

"Daveed Vandevoorde" < XXXX@XXXXX.COM >wrote in message
Quote
We're also expecting (our second one).
Congrats!
Quote
Right now we're agonizing
because they couldn't tell us whether it'll be a boy or a girl: So we're
trying to come up with names for both possibilities. They won't be
super-common (and the last name is fairly common in Benelux, but
that's a limited population).

Unfortunately, they don't acccept square brackets in names.
I thought "Kid[0]" and "Kid[1]" would have been most convenient.
How about "Beta" and "Release"? <g>
 

Re:Re: Borland Bashing- is it productive at this point?

"Greg Comeau" < XXXX@XXXXX.COM >wrote in message
Quote
>That's why I, over and over, suggest you actually try
>it. You have the means at your disposal, right now, to do it.
As with any such test, just doing it is insufficient.
There are too many variables which need to be understood,
or at least spelling out as the limits. I know you know this,
but it's not coming out that way.
It's sufficient to try out for his project on his terms. After all, to him
(or anyone else), that's what matters most.
Quote
>You have Comeau C++ which implements export. If export will save you
hours,
>you don't even need to download DMC++ to test that theory. Just benchmark
>Comeau against whatever else you are currently using.
>If you still won't use Comeau C++, then I believe you've answered the
>question as to why other compiler vendors haven't implemented export.
I very much disagree, at least to the extent again that you're
expressing this. He has reasons to not use Comeau C++ that may
have nothing to do with export, and he may have reasons to not
use Comeau C++ that may have everything to do with export.
Or something in the middle. It's far from "must be" and does
not always need to be an either or choice.
But he can use it to prove if export will save him hours or not for his
project. He doesn't have to use Comeau C++ for anything more than doing a
build speed test. And if it does save him hours, he'll have a very
compelling argument to use, worth a lot more than all the arguing and
gedanken experiments.