Board index » cppbuilder » Boost and bcc v5.8.2.0

2006-12-30 09:08:28 AM
cppbuilder6
I'm copying this post from delphi non-tech, as there are probably several
people here who can point out to David their favorite boost failures with
bcc v.5.8.2.0 compiler.
"David Dean [CodeGear]" wrote
CVS RC_1_34_0 candidate, which hopefully will be released very very soon.
engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/
They have entries for the 5.8.2 compiler (which is the latest released
AFAIK) for several of the libraries.
Check out the multi-array library:
engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/multi_array.html
or, the lambda library:
engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/lambda.html
I could go on-and-on.
Note that Boost has regression testing software they use to check to see if
all bugs/regressions are removed before they make a release, and they report
those daily on the Boost devel list. It currently only shows about 3 or 4
Borland regressions/bugs, but that is simply because they have marked the
rest of them as expected failures for that compiler. At least that is my
understanding of the situation. I'm sure Alisdair can clarify the exact
state of failures.
 

In article < XXXX@XXXXX.COM >,
"geikelite" < XXXX@XXXXX.COM >wrote:
question. I wanted to know which libraries that are failing are ones
which you need for your work.
his work and are in touch with him.
--
-David Dean
CodeGear C++ QA Engineer
 

"David Dean [CodeGear]"
of them. But then again, if someone *needed* one that bcc does not support,
they probably wouldn't be reading or responding to the post, because they
would not be using Builder for their project in that case anyway.
In particular I was wanting to try both multi-array and boost::ublas.
However, I decided against using both. I would think Lambda would be a
rather high priority lib.
Anyway, it probably would be best if bcc could handle the tr1 subset of libs
that are listed on that page ( tr1 ).
A question: Do you guys internally have the bcc compiler working with the
boost tr1, or the Dinkumware tr1 lib?
 

{smallsort}

David Dean [CodeGear] wrote:
portability between WIndows and Linux. When I'm back in the office on Tuesday I'll
check to see which others we use.
Currently we use gcc 3.3.4 and MS VS 2003 (soon to go to later versions of both). I
want to try a port to the next Borland release if the boost support looks good for
what we use.
Maybe you should start a thread with a really obvious title "Which boost libraries do
you use and want to use?"
 

In article <4595dd96$ XXXX@XXXXX.COM >,
"geikelite" < XXXX@XXXXX.COM >wrote:
regression harness that runs every night. We have licensed Dinkumware.
They're all works in progress, but each one is very important, IMO.
--
-David Dean
CodeGear C++ QA Engineer
 

In article <4596aff4$ XXXX@XXXXX.COM >,
Randall Parker < XXXX@XXXXX.COM >wrote:
might also be a good question for a future survey.
--
-David Dean
CodeGear C++ QA Engineer
 

David Dean [CodeGear] wrote:
1) With Borland-specific patches.
2) With no compiler-specific patches.
Progress on the latter score is a better measure of how the compiler is progressing
overall.
 

In article <4596dcba$ XXXX@XXXXX.COM >,
Randall Parker < XXXX@XXXXX.COM >wrote:
more complicated than just turning them on/off. I am thinking about
creating a variety of new benchmarks, and the impact of various boost
workarounds are excellent candidates.
--
-David Dean
CodeGear C++ QA Engineer
 

"David Dean [CodeGear]" < XXXX@XXXXX.COM >wrote in
it's hugely useful.
The question of "need" is pretty broad; there are always workarounds, but
why do it yourself if you don't have to? Further, it's a good idea for
C++ programmers to get used to BOOST because much if not most of that
stuff is probably going to end up in the standard library at some point.
If CodeGear is serious about playing in the C++ space, robust support for
building and using BOOST is a must.
Regards,
mr_organic
 

David Dean [CodeGear] wrote:
few surveys I've seen were for Delphi to the exclusion of the C++
language. I realize that Delphi is the most important language for
CodeGear but to not even have an option that you upgraded from BCB6 to
BDS2006 in the last Delphi survey was a real mistake (I believe).
I'm very hopeful about CodeGear and a lot of that hope comes from your
posts here and Nick's posts ... everywhere :-) Keep up the good work. It
will be great to see better Boost support. For the record, I'd like to
be able to use the Spirit stuff from Boost some day.
Regards,
Jim Dodd
Onset Computer Corp.
 

In article <459a897b$ XXXX@XXXXX.COM >,
Jim Dodd < XXXX@XXXXX.COM >wrote:
--
-David Dean
CodeGear C++ QA Engineer
 

In article <459a5ef7$ XXXX@XXXXX.COM >,
"mr_organic" < XXXX@XXXXX.COM >wrote:
--
-David Dean
CodeGear C++ QA Engineer
 

mr_organic wrote:
But it would be easy to get carried away being too focussed on Boost
regression scores (the common measure of support)
For instance, I am not aware of any Boost failures due to the bad code
generation for exception handling prior to BCB2006. I think that was
probably a more useful fix than a problem with open array types as
template arguments - although the latter is the corner case responsible
for a lot of type-traits failures, I doubt it will affect the majority
of users. And that is far from the most obscure bug in the tests.
The trick will be to find the bugs with the broadest application that
might hurt users outside building the boost libs themselves. e.g.
SFINAE support, a solution to some of the type deduction problems
(premature pointer decay, const references!), overload resolution
issues, ... Clearly attention here will improve Boost scores, but
will also serve the community more broadly than patching up the tests
that check corner cases (although I will be happy to take those patches
too!)
--
AlisdairM(TeamB)
 

"Alisdair Meredith[TeamB]" <alisdair.meredith@no-spam-
XXXX@XXXXX.COM >wrote in news:459aaeab$1
@newsgroups.borland.com:
yeoman work on the compiler itself, and why I think it's going to be a
lot of hard work. The compiler desperately needs love in many areas --
not just in compliance to the standard, but in terms of optimizations,
multi-core support, etc. As I've written before, most of the low-hanging
fruit is gone. I don't know that the current compiler can be "fixed", but
trying to deploy a new one is equally fraught with danger. New compilers,
IME, take about three or four years to really settle down and be
trustworthy for production work.
If I had to pick I guess I'd go with compliance over raw performance, but
it irks me that I should even *have* to make such a choice in this day
and age.
Regards,
mr_organic
 

with Turbo Explorer showed that standard things like parsing an fstream
object
and using getline() was EXTREMELY slow. This is likely due to Dinkumware
relying heavily on optimizations that Borland may not be doing. (search the
cpp group
for threads)
If this is the case then it may not make sense to concentrate only on
compiance
when the resulting code is not usable. I think that if Borland is serious
they'll need
to deal with a lot of different areas but this is mostly due to letting it
slide for
so long.