Boost logo

Boost :

From: Burc Arpat (burch_at_[hidden])
Date: 2004-02-06 14:13:09


patrick,

thanx for the suggestion. i am actually a fan of ace myself and i have
happily used it before

the problem is: nowadays it is becoming more and more common for non-cs
depts. to try and write reusable, near-commercial quality code. this is
true at least for some major private universities that i know of. that
typically happens because companies who supply research funds expect to see
software that is immediately useful, not just proof of concept coding. in
other words, we are supposed to deliver quality scientific c++ libraries and
software that implements all the research that's going on in the dept.

given that, sticking with a single 3rd party library for such fundamental
tools makes sense for several reasons:

(1) when a new student arrives, you tell him/her to go to boost.org and
start reading and that's the only burden. you don't also say, "oh, also
read about ace, etc.". these people do not need to be very fluent in c++ (
remember, we are talking about non-cs engineering students ) so it's only
confusing to force them to use different interface styles. boost interfaces
sometimes vary to but at least the overall 'feel' of them is unified and in
sync with the standard library

(2) when a company wants to use the code, they only need to download and
compile boost and our code and nothing else. the less 3rd party dependency,
the better

(3) and, finally, it is much easier to justify the use of boost than any
other library out there. i can simply say "some of their sub-libraries are
gonna make it to the next standard" and "they have c++ standards committee
members on board" and will persuade even the biggest anti-open-source zealot

for the above reasons, we prefer to use a boost sub-library whenever we can
rather than using some other 3rd party library regardless of how high
quality it might be. 'hope this explains the situation

...

everyone,

thanks for the responses. i guess, this means, i can start using the lib
and then incorporating the changes is not gonna be a big problem. great!

one question, though: i understand thread cancellation is gonna be one of
the topics to work on. to be honest, it is gonna be quite important for us
in the future. do you think it will be safe to say at least an alpha level
work on this issue will be available within the next 6 months? although i
don't consider myself a threading guru, as i mentioned before, i'll help out
as much as i can towards such a goal

burch

Bennett, Patrick <Patrick.Bennett <at> inin.com> writes:

>
> Honestly, I'd suggest you just use ACE for threading/synchronization
> primitives. It's available for a large number of platforms and is
> heavily used and frequently updated.
> I like Boost a lot, but I think some people are trying to make Boost
> more than (IMO) it should be. People discussing efficient io dispatch
> techniques for example would be better served to just use ACE, which
> already does many of these things extremely well.
> (http://www.cs.wustl.edu/~schmidt/ACE.html)
>
> Just my (possibly unwanted) $.02.
>
> Patrick


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk