CPAN for C++ ?
Andrew Hicox
I've been a perl programmer for about 5 years, and I'm just now
learning C++.
In the world of perl, usually the very first thing you do when you
have a new problem to solve is head straight over to your local CPAN
mirror and see if someone has already been down the road you are about
to travel. Among many things, this prevents you from re-inventing the
wheel, as well as providing a tremendous free and open base of example
code. My question is this:
is there anything similar to CPAN for C++ (or just plain C for that
matter) ?
If I shouldn't be asking this question here, where is the FAQ that I
should be reading? I have looked ...
thank you everyone:
-Andrew ;-)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Beman Dawes
> is there anything similar to CPAN for C++ (or just plain C for that
> matter) ?
See www.boost.org
--Beman
James Kanze
> I've been a perl programmer for about 5 years, and I'm just now
> learning C++. In the world of perl, usually the very first thing you
> do when you have a new problem to solve is head straight over to your
> local CPAN mirror and see if someone has already been down the road
> you are about to travel. Among many things, this prevents you from
> re-inventing the wheel, as well as providing a tremendous free and
> open base of example code. My question is this:
> is there anything similar to CPAN for C++ (or just plain C for that
> matter) ?
Boost (www.boost.org) is probably about as close as you can get. There
are a lot of other sites which have odds and ends floating about as
well; there are also sites which collect links to various librarys of a
certain type (GUI, etc.). But as far as I know, no central repository.
Note that even with a central repository, the issue wouldn't be as clear
as with Perl. In the case of C++, there are many different
implementations, and they are far from compatible. The simple fact that
a library exists doesn't mean that you will be able to use it with your
compiler. Even in the case of Boost, where there has been an enormous
effort in this direction (and also in validating the code made
available), I was unable to generate the regular expression library for
one of my compilers (Sun CC 5.1).
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Early Ehlinger
C++ in it... ("void" also helps to reduce the clutter down to actual C++
code :)
Recently (within the last few years) there has been a push to provide
standardized libraries for a number of things not in the official Standard.
This can be found at www.boost.org. It is not as large as CPAN, but it does
offer quite a bit of functionality and generic programming support.
--
-- Early Ehlinger CEO, ResPower Inc - Toll-Free : 866-737-7697 --
- RenderFarm - Lightwave , 3dSMax , Bryce , Maya , AfterEffects -
--- www.respower.com -- 400+ GHz Starting At USD$0.50/GHz*Hour --
----------------- SuperComputing For the Masses! ----------------
"I'm so busy programming my computer to let me be lazy, I never
get any rest!" - John Kaster
"Andrew Hicox" <and...@hicox.com> wrote in message
news:e796c4eb.03022...@posting.google.com...
> Hello Everyone:
>
> I've been a perl programmer for about 5 years, and I'm just now
> learning C++.
> In the world of perl, usually the very first thing you do when you
> have a new problem to solve is head straight over to your local CPAN
> mirror and see if someone has already been down the road you are about
> to travel. Among many things, this prevents you from re-inventing the
> wheel, as well as providing a tremendous free and open base of example
> code. My question is this:
>
> is there anything similar to CPAN for C++ (or just plain C for that
> matter) ?
>
> If I shouldn't be asking this question here, where is the FAQ that I
> should be reading? I have looked ...
>
> thank you everyone:
>
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Sam Holden
> and...@hicox.com (Andrew Hicox) wrote
>
>> is there anything similar to CPAN for C++ (or just plain C for that
>> matter) ?
>
> See www.boost.org
Boost is really very different from CPAN. CPAN has much lower entry
requirements, and has a *lot* more modules/libraries that are very
low-level and specific. Want to interface to some strange device, CPAN
probably has a module for it. Want to extract names from free form text,
CPAN probably has a module for it.
C++ isn't suitable for a CPAN type repository anyway, since perl has the
advantage that it provides install tools and such things. C++ doesn't,
and shouldn't.
I guess you could create a similar thing based on something like GNU
configure, but that wouldn't be C++. That would be C++ and some
other things.
freshmeat.net can be searched for Software libraries and Language::C++,
which is more similar to CPAN (especially in the variable quality of the
software :).
--
Sam Holden
George van den Driessche
>
> I've been a perl programmer for about 5 years, and I'm just now
> learning C++.
> In the world of perl, usually the very first thing you do when you
> have a new problem to solve is head straight over to your local CPAN
> mirror and see if someone has already been down the road you are about
> to travel. Among many things, this prevents you from re-inventing the
> wheel, as well as providing a tremendous free and open base of example
> code. My question is this:
>
> is there anything similar to CPAN for C++ (or just plain C for that
> matter) ?
>
> If I shouldn't be asking this question here, where is the FAQ that I
> should be reading? I have looked ...
>
> thank you everyone:
The things I use most are Boost at http://www.boost.org for code and C/C++
Users Journal at http://www.cuj.com for ideas.
George
Roland Pibinger
>and...@hicox.com (Andrew Hicox) wrote in message
>news:<e796c4eb.03022...@posting.google.com>...
>
>> I've been a perl programmer for about 5 years, and I'm just now
>> learning C++. In the world of perl, usually the very first thing you
>> do when you have a new problem to solve is head straight over to your
>> local CPAN mirror and see if someone has already been down the road
>> you are about to travel. Among many things, this prevents you from
>> re-inventing the wheel, as well as providing a tremendous free and
>> open base of example code. My question is this:
>
>> is there anything similar to CPAN for C++ (or just plain C for that
>> matter) ?
>
>Boost (www.boost.org) is probably about as close as you can get.
Do you really recommend Boost to somebody who is "just now learning
C++"? You must be joking!
Best regards,
Roland Pibinger
LLeweLLyn
> Hello Everyone:
>
> I've been a perl programmer for about 5 years, and I'm just now
> learning C++.
> In the world of perl, usually the very first thing you do when you
> have a new problem to solve is head straight over to your local CPAN
> mirror and see if someone has already been down the road you are about
> to travel. Among many things, this prevents you from re-inventing the
> wheel, as well as providing a tremendous free and open base of example
> code. My question is this:
>
> is there anything similar to CPAN for C++ (or just plain C for that
> matter) ?
is a collection of useful libraries targeting addition to the next
C++ standard.
> If I shouldn't be asking this question here, where is the FAQ that I
> should be reading? I have looked ...
Marshall Cline's C++ faq lite:
http://www.parashift.com/c++-faq-lite/
James Kanze
news:<3e5e97f...@news.utanet.at>...
> On 26 Feb 2003 18:02:38 -0500, ka...@gabi-soft.de (James Kanze) wrote:
> >and...@hicox.com (Andrew Hicox) wrote in message
> >news:<e796c4eb.03022...@posting.google.com>...
> >> I've been a perl programmer for about 5 years, and I'm just now
> >> learning C++. In the world of perl, usually the very first thing
> >> you do when you have a new problem to solve is head straight over
> >> to your local CPAN mirror and see if someone has already been down
> >> the road you are about to travel. Among many things, this prevents
> >> you from re-inventing the wheel, as well as providing a tremendous
> >> free and open base of example code. My question is this:
> >> is there anything similar to CPAN for C++ (or just plain C for that
> >> matter) ?
> >Boost (www.boost.org) is probably about as close as you can get.
> Do you really recommend Boost to somebody who is "just now learning
> C++"? You must be joking!
Not at all.
I wouldn't recommend his looking at the Boost code for inspiration.
Some of it is extremely complicated, and all of it uses some complicated
tools to get it to compile on a large number of platforms. But if he
can install it correctly and get the necessary libraries to compile on
his platform, some of the actual tools are extremely simple to use, and
almost all of them are easier than the alternatives that I've seen. If
he is used to Perl, for example, he will find boost::regex a godsend.
(I just wish I could get it to compile with Sun CC.)
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
LLeweLLyn
> On 26 Feb 2003 18:02:38 -0500, ka...@gabi-soft.de (James Kanze) wrote:
>
> >and...@hicox.com (Andrew Hicox) wrote in message
> >news:<e796c4eb.03022...@posting.google.com>...
> >
> >> I've been a perl programmer for about 5 years, and I'm just now
> >> learning C++. In the world of perl, usually the very first thing you
> >> do when you have a new problem to solve is head straight over to your
> >> local CPAN mirror and see if someone has already been down the road
> >> you are about to travel. Among many things, this prevents you from
> >> re-inventing the wheel, as well as providing a tremendous free and
> >> open base of example code. My question is this:
> >
> >> is there anything similar to CPAN for C++ (or just plain C for that
> >> matter) ?
> >
> >Boost (www.boost.org) is probably about as close as you can get.
>
> Do you really recommend Boost to somebody who is "just now learning
> C++"? You must be joking!
Well now. Let us have some fun.
(a) my_widget* my= new my_widget;
(b) boost::shared_ptr<my_widget> my(new my_widget);
Which is easier for a beginner to learn to use safely and correctly?,
and why? I would appreciate it if people would share their
opinions, and more importantly their experiences and
justifications for thier opinions.
I lean toward (b), with the following caveats:
(0) Doesn't handle circular referencing. (Though in some cases one
one can conviently break circularities in appropriate
destructors. )
(1) Sometimes one must use get() and pass the raw pointer to a 3rd
party api.
(2) May be percieved as perfect, providing a false sense of
security.
(Note: I realize there's plenty of esoteric stuff at boost, and that the
documentation is not aimed at beginners. I thought I could
come up with some boost stuff that was potentially easier to learn
than constructs beginners are typically taught. This was the first
that popped into my head, but I feel there are sublte issues
involved. So now I'm asking for a general discussion.)
E. Mark Ping
James Kanze <ka...@gabi-soft.de> wrote:
>If he is used to Perl, for example, he will find boost::regex a
>godsend. (I just wish I could get it to compile with Sun CC.)
Except that boost::regex does not use perl regular expressions. But
yes, it is _very_ useful that's my only complaint.
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
David A. Ferguson
news:e796c4eb.03022...@posting.google.com...
> Hello Everyone:
>
> matter) ?
The 'Available C++ Libraries FAQ' by Nikki Locke, Trumphurst Ltd.
seems to list a lot of libraries.
http://www.trumphurst.com/cpplibs/cpplibs.phtml
Kevin Cline
> rpb...@yahoo.com (Roland Pibinger) writes:
>
{unnecessary quote snipped -mod/fwg}
>
> Well now. Let us have some fun.
>
> (a) my_widget* my= new my_widget;
>
> (b) boost::shared_ptr<my_widget> my(new my_widget);
>
> Which is easier for a beginner to learn to use safely and correctly?,
> and why? I would appreciate it if people would share their
> opinions, and more importantly their experiences and
> justifications for thier opinions.
>
> I lean toward (b), with the following caveats:
>
> (0) Doesn't handle circular referencing. (Though in some cases one
> one can conviently break circularities in appropriate
> destructors. )
>
> (1) Sometimes one must use get() and pass the raw pointer to a 3rd
> party api.
IMO such API's are poor. Most functions should accept references
instead of pointers. Unfortunately, Microsoft does not seem to share my opinion.
Roland Pibinger
wrote:
>rpb...@yahoo.com (Roland Pibinger) writes:
>
> > On 26 Feb 2003 18:02:38 -0500, ka...@gabi-soft.de (James Kanze) wrote:
> >
> > >and...@hicox.com (Andrew Hicox) wrote in message
> > >news:<e796c4eb.03022...@posting.google.com>...
> > >
> > >> I've been a perl programmer for about 5 years, and I'm just now
> > >> learning C++. In the world of perl, usually the very first thing you
> > >> do when you have a new problem to solve is head straight over to your
> > >> local CPAN mirror and see if someone has already been down the road
> > >> you are about to travel. Among many things, this prevents you from
> > >> re-inventing the wheel, as well as providing a tremendous free and
> > >> open base of example code. My question is this:
> > >
> > >> is there anything similar to CPAN for C++ (or just plain C for that
> > >> matter) ?
> > >
> > >Boost (www.boost.org) is probably about as close as you can get.
> >
> > Do you really recommend Boost to somebody who is "just now learning
> > C++"? You must be joking!
>
>Well now. Let us have some fun.
>
> (a) my_widget* my= new my_widget;
>
> (b) boost::shared_ptr<my_widget> my(new my_widget);
>
>Which is easier for a beginner to learn to use safely and correctly?,
> and why? I would appreciate it if people would share their
> opinions, and more importantly their experiences and
> justifications for thier opinions.
I don't know how your example is related to Boost other than because
it uses a boost::shared_ptr. Boost produces high sophisticated
(b)leading edge libraries with an emphasis on template and template
meta programming. Boost libraries are usually difficult to understand
and difficult to compile. Therefore, IMO, they are inappropriate for
somebody who is "just now learning C++". Because of its complexity I
also question whether Boost (and the Boost style of programming) will
spread to "real world" C++. (Of course, this question will only be
answered by the "real world" programmers who use Boost or not.)
Best regards,
Roland Pibinger
David B. Held
news:3e61ed00...@news.utanet.at...
> [...]
> Boost libraries are usually difficult to understand and difficult to
> compile.
I disagree. Their *implementations* may be difficult to understand,
but only the most advanced libraries are difficult to compile. The
most commonly used libraries compile on just about all desired
platforms.
> Therefore, IMO, they are inappropriate for somebody who is
> "just now learning C++".
Considering that some of them get considered for inclusion in the
standard library (and that two of them already have), I must
conclude that you also think that the standard library is
"inappropriate for somebody who is 'just now learning C++'".
> Because of its complexity I also question whether Boost (and the
> Boost style of programming) will spread to "real world" C++.
Insofar as Boost is a collection of *libraries*, I wouldn't expect its
style to "spread to the 'real world' [of] C++" except where libraries
are written. And judging by the backlog of libraries to be reviewed,
I think it's safe to say that such a spread has already occurred.
> (Of course, this question will only be answered by the "real
> world" programmers who use Boost or not.)
Of which Boost-using programmers number in the thousands, if not
more.
Dave
John Potter
<dh...@codelogicconsulting.com> wrote:
> > Because of its complexity I also question whether Boost (and the
> > Boost style of programming) will spread to "real world" C++.
> Insofar as Boost is a collection of *libraries*, I wouldn't expect its
> style to "spread to the 'real world' [of] C++" except where libraries
> are written.
Yep, only library writers need it. Real programmers write code.
> And judging by the backlog of libraries to be reviewed,
> I think it's safe to say that such a spread has already occurred.
Sounds like a language in which a search for an existing library is
the appropriate way to code. Isn't that perl or smalltalk? Oops,
I missed the fact that it was only libraries being reviewed not
used.
> > (Of course, this question will only be answered by the "real
> > world" programmers who use Boost or not.)
> Of which Boost-using programmers number in the thousands, if not
> more.
Considering that the number of C++ programmers numbers in the
millions, 0% of them use boost.
Not intended to knock boost, just getting things in perspective.
When the number of libraries becomes incomprensible, the language
becomes unusable for the average mortal. I know programmers who
use C and find the K&R C library unmanageable. How do you spell
string::find_first_of in C? It is there.
John
Bronek Kozicki
> IMO such API's are poor. Most functions should accept references
> instead of pointers. Unfortunately, Microsoft does not seem to share
passing reference would require C++ function linkage, thus it's not
possible with any API or library written in C (and usable from any other
language).
B.
witoldk
That would likely be strpbrk :)
Just to add my 25 cents: the very fact that boost is a "proprietary"
library disqualifies it for the code I deal with. No matter how usefull
how advanced and how widely regarded. I think there are many places
where people just do not want the headache (or rather they already have
enough). Shall parts of boost become parts of standard library, then
these parts will be "accepted". But these parts wouldn't be boost
anymore:)
So: raw new vs. shared_ptr?
raw new
James Kanze
news:<v64cus8...@corp.supernews.com>...
> "Roland Pibinger" <rpb...@yahoo.com> wrote in message
> news:3e61ed00...@news.utanet.at...
> > [...]
> > Boost libraries are usually difficult to understand and difficult to
> > compile.
> I disagree. Their *implementations* may be difficult to understand,
> but only the most advanced libraries are difficult to compile. The
> most commonly used libraries compile on just about all desired
> platforms.
That hasn't been my experience, and I've been unable to get regex to
compiler for Sun CC.
The reason is doubtlessly linked to the attempts to support all possible
exotic platforms. (The errors stem from the preprocessor, and all of
the nested #if render the code completely unreadable.)
And most of the libraries ARE difficult to understand, if the goal is to
understand the internal workings.
The question was, however, concerning their use by a beginning
programmer. While I would agree that the example given was misleadingly
simplified (no mention of the necessity of deriving from counted_base,
etc.), the real question is: what are the alternatives? While
shared_ptr may not be the simplest thing in the world, it is still a lot
simpler than managing memory without it. About the only real criticism
I could give is that it might give the misleading impression that it
solves more than it actually does. But that is probably true for just
about any technology which simplifies your programming, and is hardly an
argument against the tool.
> > Therefore, IMO, they are inappropriate for somebody who is "just now
> > learning C++".
> Considering that some of them get considered for inclusion in the
> standard library (and that two of them already have), I must conclude
> that you also think that the standard library is "inappropriate for
> somebody who is 'just now learning C++'".
Which two have been incorporated into the standard library? From what I
understood, Boost was started after the standard library was fixed.
> > Because of its complexity I also question whether Boost (and the
> > Boost style of programming) will spread to "real world" C++.
> Insofar as Boost is a collection of *libraries*, I wouldn't expect its
> style to "spread to the 'real world' [of] C++" except where libraries
> are written.
And even then, only when the libraries have to be portable to many
different implementations, while still using all of the available
features of the most advanced implementations.
> And judging by the backlog of libraries to be reviewed, I think it's
> safe to say that such a spread has already occurred.
> > (Of course, this question will only be answered by the "real world"
> > programmers who use Boost or not.)
> Of which Boost-using programmers number in the thousands, if not more.
In general, I would consider that a programmer who developed a tool in
house when there was an easily available alternative already available
has shown bad judgement. There are reasons why one can't always use
everything available in an existing project. But if starting a new
project, I would certainly use anything I could get from Boost that
would do the job.
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Andrew Hicox
helpful.
Boost dosen't look like the sort of thing that's going to be helpful
until I understand a bit more of the language. This is true of CPAN as
well, at least for the first year that I was doing perl I avoided CPAN
like the plague, because there were just too many things I didn't
understand, and for me at that time, it was often less of an effort to
make my own wheel than to learn to use someone else's.
I have to take issue to the "real programers don't write libraries"
sentiment. At the risk of being the newbie who spouts whereof he does
not know, I have to say that is complete BS. On the contrary, real
programmers write as many libraries as possible, this is, after all
the main VALUE of using OO techniques: code re-use. Having a boat-load
of libraries available, does NOT make a language less usable. The
problem is ORGANIZATION of what you have available, not the fact that
it is available at all.
Sounds to me like Boost is a big step in the right direction, however,
I would really love to see something more like CPAN evolve for C++, or
perhaps if Boost is the current favored movement of the community, it
should consider emulating CPAN in these ways:
1) Distributed Architechture
Boost should emulate the mirror/rsync method used by perl. A good
reason for this? the boost site is slow as monkey nutz today.
2) There is nothing at all wrong with makefiles.
Makefiles work good! someone earlier in the thread commented that a
major problem with having a CPAN-like thing for C++ is that there's no
standard installation method, and that while something like GNU make
could be used, that it would no longer be C++, it would be C++ plus
some other stuff. My response to that is "so what?". Why is it bad to
distribute libraries using makefiles? Perl does it, and does it well I
might add. So what if you need a bit of additional infrastructure to
handle installations? As long as it's standard, free, open, and easily
available, who cares?
3) online documentation.
Good, LORD, it's hard to find documentation on STANDARD c++ libs, much
less anything non-stnadard. Want proof? I'm a newbie, I had a homework
project over the weekend in which I needed to use the mathematical
constant PI. Do you know how long it took me to find documentation for
the cmath library? holy CRAP! In the end I ended up wading trough
google results, half of which wanted to a) sell me a book b) sell me
some pre-compiled libs, or c) pop me up with some dam banner ad's.
Anyhow, just my thoughts,
feel free to comment or get into an argument, it is, after all what
the internet was built for (apart from star trek and porn).
-Andrew ;-)
jpo...@falcon.lhup.edu (John Potter) wrote in message news:<3e62da8c...@news.earthlink.net>...
Maciej Sobczak
"Bronek Kozicki" <br...@rubikon.pl> wrote in message
news:6e677$3e631c5a$c299d863$26...@nf1.news-service.com...
> Kevin Cline <kcli...@hotmail.com> wrote:
> > IMO such API's are poor. Most functions should accept references
> > instead of pointers. Unfortunately, Microsoft does not seem to share
>
> passing reference would require C++ function linkage, thus it's not
> possible with any API or library written in C (and usable from any other
> language).
That's hardly an argument.
The API or libraries written in C cannot portably (independently of the
compiler used) interoperate with non-static C++ members.
Instead, the common practice is to write static members or even free
functions to have a point of interface with the C APIs.
Writing API or C library that would work with (in other words: call)
non-static class member would rely on the assumption that the "this" pointer
has some specific place in the member's signature -- for example, that
"this" is the first implicit argument of the member -- so that the C code
can form a valid function frame for the call. The problem is that this
assumption is not reliable since there is no requirement that it is so -- it
is only a common realization of the object model, probably rooted in the
fact that most compilers eat both C and C++ code.
The "this" pointer is an non-lvalue expression denoting the address of the
"current" object and that's all that is required. There is even no
requirement that it gets into the member function as one of its parameters.
In other words, from the point of view of the third APIs or C libraries,
there is no difference whether "this" is a pointer or a reference.
--
Maciej Sobczak
http://www.maciejsobczak.com/
Distributed programming lib for C, C++, Python & Tcl:
http://www.maciejsobczak.com/prog/yami/
Roland Pibinger
<dh...@codelogicconsulting.com> wrote:
>"Roland Pibinger" <rpb...@yahoo.com> wrote in message
>news:3e61ed00...@news.utanet.at...
>> [...]
>> Boost libraries are usually difficult to understand and difficult to
>> compile.
>
>I disagree. Their *implementations* may be difficult to understand,
>but only the most advanced libraries are difficult to compile. The
>most commonly used libraries compile on just about all desired
>platforms.
Maybe you suffer from a guru bias?
>> Therefore, IMO, they are inappropriate for somebody who is
>> "just now learning C++".
>
>Considering that some of them get considered for inclusion in the
>standard library (and that two of them already have), I must
>conclude that you also think that the standard library is
>"inappropriate for somebody who is 'just now learning C++'".
Yes, a minor error in using std::string can result in an error message
of 5 lines by popular compilers. Even the correct usage of std::string
will sometimes produce unintelligible warnings for beginners ('symbol
truncated').
>> Because of its complexity I also question whether Boost (and the
>> Boost style of programming) will spread to "real world" C++.
>
>Insofar as Boost is a collection of *libraries*, I wouldn't expect its
>style to "spread to the 'real world' [of] C++" except where libraries
>are written. And judging by the backlog of libraries to be reviewed,
>I think it's safe to say that such a spread has already occurred.
Libraries always boost a (their) way of programming. Often programmers
adopt the style of the library they use, see e.g. the impact of STL on
the 'modern' C++ programming style.
By Boost style I mean the focus on genericity (heavy templatezation),
functional programming, value semantics etc. This style is powerful
for some applications but IMO many programmes look for something
handier (as always: less is more!).
Best regards,
Roland Pibinger
David B. Held
news:3e62da8c...@news.earthlink.net...
> [...]
> Yep, only library writers need it. Real programmers write code.
Do you mean code that isn't write-only?
> [...]
> Sounds like a language in which a search for an existing library is
> the appropriate way to code. Isn't that perl or smalltalk? Oops,
> I missed the fact that it was only libraries being reviewed not
> used.
I don't understand your point here. C++ has a very large user
base, and so naturally, there will be many different libraries available.
I don't think the fact that the language doesn't simply have a small
number of commonly known libraries is a detriment. Rather, it's
a strength, as it offers choice. Too much choice can be a bad
thing, but natural selection works on code as well as biology.
> [...]
> Considering that the number of C++ programmers numbers in
> the millions, 0% of them use boost.
Only if you're using integer math. ;) A more appropriate statistic
would probably be the popularity of Boost relative to other
libraries, since most third-party libraries probably have less than a
million users. In which case, "percent" is an inappropriate scale. ;)
> Not intended to knock boost, just getting things in perspective.
> When the number of libraries becomes incomprensible, the
> language becomes unusable for the average mortal. I know
> programmers who use C and find the K&R C library
> unmanageable. How do you spell string::find_first_of in C? It
> is there.
Programmers are being expected to write more and more
complex software. How do you expect to achieve this goal
without more and more complex tools? I think we'd all love to
be coding assembly on a Z80, and have that be leading-edge
technology. But those days are long gone. Now we have to
rely on the machine to help us program it, which means electronic
reference manuals with powerful search capabilities. By
"unmanageable", you simply mean that one person cannot
possibly be a domain expert in every area of programming, like
was once possible. But that is not a failure of technology. It is
a sign of its success.
Dave
James Kanze
news:<9bed99bb.03030...@posting.google.com>...
[...]
> Just to add my 25 cents: the very fact that boost is a "proprietary"
> library disqualifies it for the code I deal with. No matter how
> usefull how advanced and how widely regarded. I think there are many
> places where people just do not want the headache (or rather they
> already have enough).
Very understandable. Often, however, you don't have the choice of not
having the headache. The only choice is which headache -- that of
developping equivalent tools of your own, or that of using Boost or
another third party library. Even admitting that installing Boost,
getting it working in your production chain, and validating it takes two
or three man-days (a very large estimate for most platforms), how much
effort would it take you to develop the equivalent code.
Obviously, if you don't need the functionality of a third party library,
you shouldn't use it.
> Shall parts of boost become parts of standard library, then these
> parts will be "accepted". But these parts wouldn't be boost anymore:)
> So: raw new vs. shared_ptr?
> raw new
That isn't the question. It is almost impossible to write correct C++
without some sort of smart pointer (unless you are using the Boehm
collector). So the question is rather: home-built shared pointer, or
boost::shared_ptr? Given that it would take more time to develop the
simplest smart pointer in house than it will take to install Boost, and
the simplest in house smart pointer will have neither all of the
features of boost::shared_ptr nor be as robust, the answer should be
obvious. About the only valid reason for not using boost::shared_ptr is
that you already have a smart pointer which is widely used in your code.
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> >> Therefore, IMO, they are inappropriate for somebody who is "just
> >> now learning C++".
> >Considering that some of them get considered for inclusion in the
> >standard library (and that two of them already have), I must conclude
> >that you also think that the standard library is "inappropriate for
> >somebody who is 'just now learning C++'".
> Yes, a minor error in using std::string can result in an error message
> of 5 lines by popular compilers. Even the correct usage of std::string
> will sometimes produce unintelligible warnings for beginners ('symbol
> truncated').
Are you suggesting that beginners should not be exposed to std::string
either? Which is preferrable: 5 lines of somewhat obscure error
messages, or a subtle run-time bug due to mismanagement of memory? When
discussing advantages and disadvantages, it is important to keep in mind
the alternatives.
> >> Because of its complexity I also question whether Boost (and the
> >> Boost style of programming) will spread to "real world" C++.
> >Insofar as Boost is a collection of *libraries*, I wouldn't expect
> >its style to "spread to the 'real world' [of] C++" except where
> >libraries are written. And judging by the backlog of libraries to be
> >reviewed, I think it's safe to say that such a spread has already
> >occurred.
> Libraries always boost a (their) way of programming.
If this is true (and at least partially it is), then there is a
fundamental problem. The constraints on libraries are radically
different than the constraints on application programs.
> Often programmers adopt the style of the library they use, see
> e.g. the impact of STL on the 'modern' C++ programming style.
Don't judge modern C++ programming style by the postings you see here.
Most of the people I work with seem to be able to know to avoid
genericity when it isn't necessary, etc.
> By Boost style I mean the focus on genericity (heavy templatezation),
> functional programming, value semantics etc. This style is powerful
> for some applications but IMO many programmes look for something
> handier (as always: less is more!).
I've never written an application which didn't need some objects with
value semantics. I've never written one which didn't also need objects
with reference semantics. I've needed a template exactly once in
application code; I've never developped a library which didn't need
them.
In the end, it is up to the teacher to make the difference. IMHO, one
of the essential reasons for using Boost is that in any application, you
DO need things like boost::shared_ptr. (Especially if you have a lot of
objects with reference semantics and polymorphism.) Making the student
write his own puts too much emphesis on generics, templates, etc., too
early. Using something ready-made allows more attention to be paid to
the larger design issues.
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
witoldk
> OK, first, thanks to everyone for provinding links. They were quite
> helpful.
> Boost dosen't look like the sort of thing that's going to be helpful
> until I understand a bit more of the language. This is true of CPAN as
> well, at least for the first year that I was doing perl I avoided CPAN
> like the plague, because there were just too many things I didn't
> understand, and for me at that time, it was often less of an effort to
> make my own wheel than to learn to use someone else's.
>
> I have to take issue to the "real programers don't write libraries"
> sentiment. At the risk of being the newbie who spouts whereof he does
> not know, I have to say that is complete BS. On the contrary, real
> programmers write as many libraries as possible, this is, after all
> the main VALUE of using OO techniques: code re-use. Having a boat-load
> of libraries available, does NOT make a language less usable. The
> problem is ORGANIZATION of what you have available, not the fact that
> it is available at all.
>From what you write I'd think you do not mean "library" the way it
is commonly understood. Real programmers likely want to re-use their
code. They likely even package the code into an "archive" and then
just link their "new" code with it. But this does not mean the
programmers have put together a library. I've called a collection of
objects (*.o files) an archive even though technically it is a library.
You give it to the linker to link other code with it. That is to
underscore a difference between a collection of usefull/re-usable
pieces of code and a library. I understand the library to be a little:)
more than that. I think many might as well. Library can be thought of
something that you are ready to "publish" not only for use in your
"department", but for _everybody_ to use. This is _quite_ an effort.
Not really for most real programmers to undertake :)
>
> Sounds to me like Boost is a big step in the right direction, however,
> I would really love to see something more like CPAN evolve for C++, or
I'm sure C++ is ripe for that.
> perhaps if Boost is the current favored movement of the community, it
> should consider emulating CPAN in these ways:
I think you are absolutely right. Emulating CPAN should be really
beneficial for boost.
>
> 1) Distributed Architechture
> Boost should emulate the mirror/rsync method used by perl. A good
> reason for this? the boost site is slow as monkey nutz today.
Consider it done:)
>
> 2) There is nothing at all wrong with makefiles.
> Makefiles work good! someone earlier in the thread commented that a
> major problem with having a CPAN-like thing for C++ is that there's no
> standard installation method, and that while something like GNU make
> could be used, that it would no longer be C++, it would be C++ plus
> some other stuff. My response to that is "so what?". Why is it bad to
> distribute libraries using makefiles? Perl does it, and does it well I
> might add. So what if you need a bit of additional infrastructure to
> handle installations? As long as it's standard, free, open, and easily
> available, who cares?
You've got it:)
>
> 3) online documentation.
> Good, LORD, it's hard to find documentation on STANDARD c++ libs, much
> less anything non-stnadard. Want proof? I'm a newbie, I had a homework
> project over the weekend in which I needed to use the mathematical
> constant PI. Do you know how long it took me to find documentation for
> the cmath library? holy CRAP! In the end I ended up wading trough
> google results, half of which wanted to a) sell me a book b) sell me
> some pre-compiled libs, or c) pop me up with some dam banner ad's.
If you could not find what you were looking for thru google, maybe you
would consider borrowing a book from a library?
Hmmm... in case of PI, maybe I could help ?
3.1415927300133056603139961890252155185995816071
Please let me know if you need it with higher precision.
>
> Anyhow, just my thoughts,
> feel free to comment or get into an argument, it is, after all what
> the internet was built for (apart from star trek and porn).
What is star trek ?
David B. Held
> >I disagree. Their *implementations* may be difficult to understand,
> >but only the most advanced libraries are difficult to compile. The
> >most commonly used libraries compile on just about all desired
> >platforms.
>
> Maybe you suffer from a guru bias?
No, that's not the case. ;) I don't have any problems using shared_ptr,
scoped_ptr, function, and type traits. Boost.Bind can be tricky some
times, but that's to be expected. And compared to the alternatives, I
think Spirit makes parsing a piece of cake.
> [...]
> Yes, a minor error in using std::string can result in an error message
> of 5 lines by popular compilers.
That's not a problem with the standard library. That's a problem with
compilers generating long messages for templates. Which means
it's a C++ problem. If you don't like long template messages, use C.
Or wait until compiler vendors realize what a pain it is to parse a ten
page error message, and offer alternative diagnostic output.
> Even the correct usage of std::string will sometimes produce
> unintelligible warnings for beginners ('symbol truncated').
C++ is full of areas where correct usage will produce bizarre
warnings, or slightly incorrect usage produces misleading or
confusing messages. Still, I don't see that being unique to std::string.
> [...]
> Libraries always boost a (their) way of programming. Often
> programmers adopt the style of the library they use, see e.g. the
> impact of STL on the 'modern' C++ programming style.
Well, it changes the modern style in that the STL is *used* more, but
not necessarily that *application* code looks more and more like
STL *implementation* code. In fact, I don't think I've ever seen a
generic algorithm written for an application. That type of thing
belongs in a *library*.
> By Boost style I mean the focus on genericity (heavy
> templatezation), functional programming, value semantics etc. This
> style is powerful for some applications but IMO many programmes
> look for something handier (as always: less is more!).
While I do use templates where appropriate in application code, it
is far less than what would (or should) appear in library code. That
is the fundamental difference. Users should not look at Boost
implementations to learn how to write application code. They should
look at it to learn more about the language and discover new
techniques. But the whole point of Boost is that they *don't* have to
write that type of code themselves!! I don't think Boost promotes
FP any more than the STL does. I think it makes it easier, but
my impression is that most programmers still use common sense
in deciding how much FP to use in their application code. I don't
know anyone who spent a week forcing Boost.Lambda to do
something that could be done in a for loop in ten minutes. And, if
by "value semantics", you mean heavy use of RAII, well, I think that
is such a fundamental feature of C++ that everyone should be
taking advantage of that as appropriate anyway. If you think that
Boost doesn't use raw pointers enough, perhaps it's because you
use raw pointers too much. Boost is a tool. It's not a textbook.
It helps you solve common problems. It doesn't tell you how to
write your domain-specific code. For what it does, I think it works
fairly well. My application code looks nothing at all like any Boost
library, and that doesn't bother me one bit. I would be more
disturbed if there were a similarity. If other *libraries* try to emulate
some of the principles that Boost promotes (like appropriate
genericity), then I think that is only good for everybody.
Dave
James Dennett
> Hmmm... in case of PI, maybe I could help ?
> 3.1415927300133056603139961890252155185995816071
> Please let me know if you need it with higher precision.
Like, accurate beyond 3.141592 ? This is just a reply to
try to ensure that nobody uses the inaccurate value above
for anything where they want remotely accurate answers.
Pi is closer to 3.141592653589793238, but don't trust that
either because it's come from my head.
{Perhaps we should ask Herb Sutter to do his party piece, which IIRC, is
to recite pi to more than 1000 places. -mod/fwg}
-- James.
Roland Pibinger
>rpb...@yahoo.com (Roland Pibinger) wrote in message
>news:<3e63b5e...@news.utanet.at>...
>
>> >> Therefore, IMO, they are inappropriate for somebody who is "just
>> >> now learning C++".
>
>> >Considering that some of them get considered for inclusion in the
>> >standard library (and that two of them already have), I must conclude
>> >that you also think that the standard library is "inappropriate for
>> >somebody who is 'just now learning C++'".
>
>> Yes, a minor error in using std::string can result in an error message
>> of 5 lines by popular compilers. Even the correct usage of std::string
>> will sometimes produce unintelligible warnings for beginners ('symbol
>> truncated').
>
>Are you suggesting that beginners should not be exposed to std::string
>either? Which is preferrable: 5 lines of somewhat obscure error
>messages, or a subtle run-time bug due to mismanagement of memory? When
>discussing advantages and disadvantages, it is important to keep in mind
>the alternatives.
If I were a C++ teacher I would first introduce my own minimal
non-template(!) string class (of course 'upward' compatible with
std::string) and later explain that class when introducing operator
overloading. I also would begin with an non-template string container
instead of std::vector<std::string>. Otherwise I would empty my class
too soon.
Agreed, this is an important distinction. Application code essentially
is non-template code. But if you take a look at e.g.
boost::iterator_adaptor or boost::functional you can hardly use them
in your application without programming in Boost-C++.
>In the end, it is up to the teacher to make the difference. IMHO, one
>of the essential reasons for using Boost is that in any application, you
>DO need things like boost::shared_ptr. (Especially if you have a lot of
>objects with reference semantics and polymorphism.)
I don't use ref-count pointers and I would not recommend them.
Dynamically created objects almost never need single treatment, they
are usually stored in containers. One owner object can take care of
thousands of (polymorphic) objects in a container. IMO ref-count
pointers indicate that an application was not designed with resource
management in mind.
>Making the student
>write his own puts too much emphesis on generics, templates, etc., too
>early. Using something ready-made allows more attention to be paid to
>the larger design issues.
I don't see the reason why the library logic (not implementation)
should be entirely different form the application logic.
Best regards,
Roland Pibinger
David B. Held
news:d6651fb6.03030...@posting.google.com...
> "David B. Held" <dh...@codelogicconsulting.com> wrote in message
> news:<v64cus8...@corp.supernews.com>...
> > Considering that some of them get considered for inclusion in the
> > standard library (and that two of them already have), I must conclude
> > that you also think that the standard library is "inappropriate for
> > somebody who is 'just now learning C++'".
>
> Which two have been incorporated into the standard library? From
> what I understood, Boost was started after the standard library was
> fixed.
Boost.Function and Boost.Tuples, if memory serves correctly. They
were added to TC1.
Dave
witoldk
> wit...@optonline.net (witoldk) wrote in message
> news:<9bed99bb.03030...@posting.google.com>...
>
> [...]
> > Just to add my 25 cents: the very fact that boost is a "proprietary"
> > library disqualifies it for the code I deal with. No matter how
> > usefull how advanced and how widely regarded. I think there are many
> > places where people just do not want the headache (or rather they
> > already have enough).
>
> Very understandable. Often, however, you don't have the choice of not
> having the headache. The only choice is which headache -- that of
> developping equivalent tools of your own, or that of using Boost or
> another third party library. Even admitting that installing Boost,
> getting it working in your production chain, and validating it takes two
> or three man-days (a very large estimate for most platforms), how much
> effort would it take you to develop the equivalent code.
Please note that estimates like that are often based on one's personal
experience. It might take more or less for people with different skill
set than yours.
Furthermore, the paperwork alone for installing something into the
"production chain" might take many times your etimate of few days
(yes, the "production chain" includes the mainframe :).
Sometimes I'm under the impression that many here work where everybody
dances to their tune. Please understand that there are places where
testing the new and cool stuff is left for the others. In places like
that it is hard to imagine that installing something into a production
chain is going to happen because there is a cool library out there that
the developers would love to have. Places like that usually run two
releases behind, so to speak :)
I'm curious if you had a chance to install boost on HP-UX 11
where the standard library is on the release level 1.x.x?
The 1.x.x is the release before the std namespace was enabled
in standard library 2.x.x on this platform. I do not even see the
toolset for HP-UX aCC (yes I know, I could write one, or maybe I need
to look better :)
>
> Obviously, if you don't need the functionality of a third party library,
> you shouldn't use it.
>
> > Shall parts of boost become parts of standard library, then these
> > parts will be "accepted". But these parts wouldn't be boost anymore:)
>
> > So: raw new vs. shared_ptr?
> > raw new
>
> That isn't the question. It is almost impossible to write correct C++
> without some sort of smart pointer (unless you are using the Boehm
> collector). So the question is rather: home-built shared pointer, or
> boost::shared_ptr? Given that it would take more time to develop the
> simplest smart pointer in house than it will take to install Boost, and
> the simplest in house smart pointer will have neither all of the
> features of boost::shared_ptr nor be as robust, the answer should be
> obvious. About the only valid reason for not using boost::shared_ptr is
> that you already have a smart pointer which is widely used in your code.
Right. Please note that most shops had to deal with this issue long before
boost came around (or became widely known). So there is either no need for
one, or it is there already. It is not to say that boost shared_ptr and
other "parts" of boost in general are not excelent "training" tools.
Let me re-iterate: raw new.
(as no more options were given :)
Bronek Kozicki
> I don't use ref-count pointers and I would not recommend them.
> Dynamically created objects almost never need single treatment, they
> are usually stored in containers.
What about "std::list<boost::shared_ptr<MyClass> > " ? Do you see any
reason not to recommend this ?
Kind regards
B.
James Kanze
> On 4 Mar 2003 15:32:19 -0500, ka...@gabi-soft.de (James Kanze) wrote:
> >rpb...@yahoo.com (Roland Pibinger) wrote in message
> >news:<3e63b5e...@news.utanet.at>...
> >> >> Therefore, IMO, they are inappropriate for somebody who is
> >> >> "just now learning C++".
> >> >Considering that some of them get considered for inclusion in the
> >> >standard library (and that two of them already have), I must
> >> >conclude that you also think that the standard library is
> >> >"inappropriate for somebody who is 'just now learning C++'".
> >> Yes, a minor error in using std::string can result in an error
> >> message of 5 lines by popular compilers. Even the correct usage of
> >> std::string will sometimes produce unintelligible warnings for
> >> beginners ('symbol truncated').
> >Are you suggesting that beginners should not be exposed to
> >std::string either? Which is preferrable: 5 lines of somewhat
> >obscure error messages, or a subtle run-time bug due to
> >mismanagement of memory? When discussing advantages and
> >disadvantages, it is important to keep in mind the alternatives.
> If I were a C++ teacher I would first introduce my own minimal
> non-template(!) string class (of course 'upward' compatible with
> std::string) and later explain that class when introducing operator
> overloading.
And what is the advantage compared to std::string? Most of my code is
blissfully unaware that std::string is a template. All of my production
code is, and I don't expect that to change anytime soon -- instantiating
std::basic_string over anything but char or wchar_t is not for the faint
of heart.
> I also would begin with an non-template string container instead of
> std::vector<std::string>. Otherwise I would empty my class too soon.
Why? You need to define a syntax to declare an array. Of varying
types. What is the problem with that syntax being std::vector<char>,
rather than char[]? What is the problem with allowing the dimension to
be a variable, rather than imposing a compile-time constant?
So don't use them when beginning with C++. Some of Boost is immediately
applicable. Other parts are really tools for making other low-level
components, and would probably not be appropriate at the application
level. Still other parts are specialized for particular applications --
I really doubt that I'll find a use for boost::crc in my present
application (managing orders in various European stock markets).
Nobody says you have to use every single class in Boost right away. But
classes like shared_ptr, date_time and timer offer functionality which
isn't easily available otherwise, in a way that hopefully will one day
become standard. (I'd mention regex and thread as well, but they
address issues that a beginning programmer probably won't encounter.)
> >In the end, it is up to the teacher to make the difference. IMHO,
> >one of the essential reasons for using Boost is that in any
> >application, you DO need things like boost::shared_ptr. (Especially
> >if you have a lot of objects with reference semantics and
> >polymorphism.)
> I don't use ref-count pointers and I would not recommend them.
You use the Boehm collector, then.
> Dynamically created objects almost never need single treatment, they
> are usually stored in containers. One owner object can take care of
> thousands of (polymorphic) objects in a container. IMO ref-count
> pointers indicate that an application was not designed with resource
> management in mind.
Or simply that the designer didn't want to make things harder than
necessary for himself.
> >Making the student write his own puts too much emphesis on generics,
> >templates, etc., too early. Using something ready-made allows more
> >attention to be paid to the larger design issues.
> I don't see the reason why the library logic (not implementation)
> should be entirely different form the application logic.
The library provides tools. In the case of C++, you don't have a
choice; the language has no built-in IO, for example. And what is the
difference between using the iostream interface for IO, and using
boost::date_time for dates and times, from a user point of view?
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
news:<9bed99bb.03030...@posting.google.com>...
> ka...@gabi-soft.de (James Kanze) wrote in message
> news:<d6651fb6.0303...@posting.google.com>...
> > wit...@optonline.net (witoldk) wrote in message
> > news:<9bed99bb.03030...@posting.google.com>...
> > [...]
> > > Just to add my 25 cents: the very fact that boost is a
> > > "proprietary" library disqualifies it for the code I deal with. No
> > > matter how usefull how advanced and how widely regarded. I think
> > > there are many places where people just do not want the headache
> > > (or rather they already have enough).
> > Very understandable. Often, however, you don't have the choice of
> > not having the headache. The only choice is which headache -- that
> > of developping equivalent tools of your own, or that of using Boost
> > or another third party library. Even admitting that installing
> > Boost, getting it working in your production chain, and validating
> > it takes two or three man-days (a very large estimate for most
> > platforms), how much effort would it take you to develop the
> > equivalent code.
> Please note that estimates like that are often based on one's personal
> experience. It might take more or less for people with different skill
> set than yours.
Certainly. Generally speaking, I'm notoriously incompetent when it
comes to installing third party software, and probably significantly
better than average when it comes to developping low level support
classes. I can probably write a good reference counted pointer in less
time than it takes to install Boost. I can't document it fully in the
same time scale, however, and of course, if any of the collegues has
questions about it, they won't get much help asking them here.
There's a lot to be said for using a pseudo-standard.
> Furthermore, the paperwork alone for installing something into the
> "production chain" might take many times your etimate of few days
> (yes, the "production chain" includes the mainframe :).
That is a problem in many cases, at least in large projects. (For small
projects, you can just install it locally, and be done with it.) The
paperwork may involve licensing issues. (Many shops are very leary of
open source because they incorrectly equate it with the GNU license --
one of the most restrictive in the business. This isn't the case with
Boost -- they insist very strongly on a liberal license that shouldn't
cause problems. But companies being what they are, you may need
authority from the legal department.) And it almost certainly will
involve installing the library where it can be globally seen; many shops
will take time here as well, in order to ascertain that they aren't
accidentally installing a virus.
Still, it can usually be done, and the total amount of work necessary
will still usually be less than what it would take to develop the same
tools in house, although because that work may involve other
departments, it may be spread out over a longer period of time.
> Sometimes I'm under the impression that many here work where everybody
> dances to their tune.
Not my case, and I understand your problem.
> Please understand that there are places where testing the new and cool
> stuff is left for the others. In places like that it is hard to
> imagine that installing something into a production chain is going to
> happen because there is a cool library out there that the developers
> would love to have. Places like that usually run two releases behind,
> so to speak :)
Tell me about it. We're still compiling with compat 4.2 mode of the Sun
compiler, because some of the libraries don't work right with more
recent releases.
> I'm curious if you had a chance to install boost on HP-UX 11 where the
> standard library is on the release level 1.x.x?
My last two contracts have been in purely Solaris. Before that, AIX for
well over three years. My experience with HP/UX goes back to before
Boost -- in fact, it goes back to a time when their compiler was still
CFront.
Agreed. With regards to smart pointers, Boost is rather late. Still,
I'd go for it for all new developments, rather than reusing an existing
smart pointer. Simply because there is some chance that newer personnel
have already seen it; the chances of anyone having used our in-house
smart pointers before is as close to 0 as you can get.
> Let me re-iterate: raw new.
> (as no more options were given :)
IMHO, raw pointers are NOT an option, unless you are using the Boehm
collector. (Raw new is used with both the Boost pointers and my own
smart pointers.) This doesn't deny your arguments for using in-house
developed smart pointers, of course. The arguments may be largely
political, but that doesn't make them less real. And in the case of
smart pointers, the strictly technical arguments are also against Boost:
they all favor using the Boehm collector. But I'll bet you'll have even
more problems getting that accepted:-).
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Beman Dawes
> Just to add my 25 cents: the very fact that boost is a "proprietary"
> library ...
Where did you get that idea? Boost is free open-source code with
licenses aimed at promoting wide use, including commercial use. It
isn't GPL'ed, or anything like that.
--Beman
Beman Dawes
> "James Kanze" <ka...@gabi-soft.de> wrote in message
> news:d6651fb6.03030...@posting.google.com...
> > "David B. Held" <dh...@codelogicconsulting.com> wrote in message
> > news:<v64cus8...@corp.supernews.com>...
> > [...]
> > > Considering that some of them get considered for inclusion in the
> > > standard library (and that two of them already have), I must conclude
> > > that you also think that the standard library is "inappropriate for
> > > somebody who is 'just now learning C++'".
> >
> > Which two have been incorporated into the standard library? From
> > what I understood, Boost was started after the standard library was
> > fixed.
> > [...]
>
> Boost.Function and Boost.Tuples, if memory serves correctly. They
> were added to TC1.
Boost.Function and Boost.Tuples were the first two libraries added to
the Library TR, not the TC.
ISO-speak:
TC = Technical Corrections to an existing standard.
TR = Technical Report of stuff destined for the next revision of the
standard.
The cut-off for Library Technical Report proposals is the C++
committee meeting next month in Oxford, UK. Several of the major
proposals (hash tables, regex, type traits, etc.) on now on their
second or third revisions, so the final form of the TR should become
much more obvious as votes are taken in Oxford.
--Beman
James Kanze
> On 4 Mar 2003 15:32:19 -0500, ka...@gabi-soft.de (James Kanze) wrote:
> >rpb...@yahoo.com (Roland Pibinger) wrote in message
> >news:<3e63b5e...@news.utanet.at>...
> >> >> Therefore, IMO, they are inappropriate for somebody who is
> >> >> "just now learning C++".
> >> >Considering that some of them get considered for inclusion in the
> >> >standard library (and that two of them already have), I must
> >> >conclude that you also think that the standard library is
> >> >"inappropriate for somebody who is 'just now learning C++'".
> >> Yes, a minor error in using std::string can result in an error
> >> message of 5 lines by popular compilers. Even the correct usage of
> >> std::string will sometimes produce unintelligible warnings for
> >> beginners ('symbol truncated').
> >Are you suggesting that beginners should not be exposed to
> >std::string either? Which is preferrable: 5 lines of somewhat
> >obscure error messages, or a subtle run-time bug due to
> >mismanagement of memory? When discussing advantages and
> >disadvantages, it is important to keep in mind the alternatives.
> If I were a C++ teacher I would first introduce my own minimal
> non-template(!) string class (of course 'upward' compatible with
> std::string) and later explain that class when introducing operator
> overloading.
And what is the advantage compared to std::string? Most of my code is
blissfully unaware that std::string is a template. All of my production
code is, and I don't expect that to change anytime soon -- instantiating
std::basic_string over anything but char or wchar_t is not for the faint
of heart.
> I also would begin with an non-template string container instead of
> std::vector<std::string>. Otherwise I would empty my class too soon.
Why? You need to define a syntax to declare an array. Of varying
types. What is the problem with that syntax being std::vector<char>,
rather than char[]? What is the problem with allowing the dimension to
be a variable, rather than imposing a compile-time constant?
> >> >> Because of its complexity I also question whether Boost (and
So don't use them when beginning with C++. Some of Boost is immediately
applicable. Other parts are really tools for making other low-level
components, and would probably not be appropriate at the application
level. Still other parts are specialized for particular applications --
I really doubt that I'll find a use for boost::crc in my present
application (managing orders in various European stock markets).
Nobody says you have to use every single class in Boost right away. But
classes like shared_ptr, date_time and timer offer functionality which
isn't easily available otherwise, in a way that hopefully will one day
become standard. (I'd mention regex and thread as well, but they
address issues that a beginning programmer probably won't encounter.)
> >In the end, it is up to the teacher to make the difference. IMHO,
> >one of the essential reasons for using Boost is that in any
> >application, you DO need things like boost::shared_ptr. (Especially
> >if you have a lot of objects with reference semantics and
> >polymorphism.)
> I don't use ref-count pointers and I would not recommend them.
You use the Boehm collector, then.
> Dynamically created objects almost never need single treatment, they
> are usually stored in containers. One owner object can take care of
> thousands of (polymorphic) objects in a container. IMO ref-count
> pointers indicate that an application was not designed with resource
> management in mind.
Or simply that the designer didn't want to make things harder than
necessary for himself.
> >Making the student write his own puts too much emphesis on generics,
> >templates, etc., too early. Using something ready-made allows more
> >attention to be paid to the larger design issues.
> I don't see the reason why the library logic (not implementation)
> should be entirely different form the application logic.
The library provides tools. In the case of C++, you don't have a
choice; the language has no built-in IO, for example. And what is the
difference between using the iostream interface for IO, and using
boost::date_time for dates and times, from a user point of view?
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Roland Pibinger
wrote:
>Roland Pibinger <rpb...@yahoo.com> wrote:
> > I don't use ref-count pointers and I would not recommend them.
> > Dynamically created objects almost never need single treatment, they
> > are usually stored in containers.
>
>What about "std::list<boost::shared_ptr<MyClass> > " ? Do you see any
>reason not to recommend this ?
What about:
std::list <MyClass*> list;
list_owner <MyClass*> owner(list);
owner deletes all objects in list when it goes out of scope - one
owner object instead of list.size() ref-counting objects (all of them
having set their counter to 1).
Best wishes,
Roland Pibinger
Roland Pibinger
>rpb...@yahoo.com (Roland Pibinger) wrote in message
>news:<3e651ed8...@news.utanet.at>...
>> On 4 Mar 2003 15:32:19 -0500, ka...@gabi-soft.de (James Kanze) wrote:
>
>> >rpb...@yahoo.com (Roland Pibinger) wrote in message
>> >news:<3e63b5e...@news.utanet.at>...
>
>> >> Yes, a minor error in using std::string can result in an error
>> >> message of 5 lines by popular compilers. Even the correct usage of
>> >> std::string will sometimes produce unintelligible warnings for
>> >> beginners ('symbol truncated').
>
>> >Are you suggesting that beginners should not be exposed to
>> >std::string either? Which is preferrable: 5 lines of somewhat
>> >obscure error messages, or a subtle run-time bug due to
>> >mismanagement of memory? When discussing advantages and
>> >disadvantages, it is important to keep in mind the alternatives.
>
>> If I were a C++ teacher I would first introduce my own minimal
>> non-template(!) string class (of course 'upward' compatible with
>> std::string) and later explain that class when introducing operator
>> overloading.
>
>And what is the advantage compared to std::string? Most of my code is
>blissfully unaware that std::string is a template. All of my production
>code is, and I don't expect that to change anytime soon -- instantiating
>std::basic_string over anything but char or wchar_t is not for the faint
>of heart.
Your code is unaware that std::string is a template, your compiler is
not. In case of a minor (= beginner) mistake it emitts error messages
that are hard to decipher for a beginner.
>> I also would begin with an non-template string container instead of
>> std::vector<std::string>. Otherwise I would empty my class too soon.
>
>Why? You need to define a syntax to declare an array. Of varying
>types. What is the problem with that syntax being std::vector<char>,
>rather than char[]? What is the problem with allowing the dimension to
>be a variable, rather than imposing a compile-time constant?
By non-template string container I mean a string_vector rather than
a char[]. Templates simply add(ed) one level of complexity to the C++
language. Apply some namespace obfuscation to identifiers and you
don't need more to frustrate beginners.
>Some of Boost is immediately
>applicable. Other parts are really tools for making other low-level
>components, and would probably not be appropriate at the application
>level. Still other parts are specialized for particular applications --
>I really doubt that I'll find a use for boost::crc in my present
>application (managing orders in various European stock markets).
>
>Nobody says you have to use every single class in Boost right away. But
>classes like shared_ptr, date_time and timer offer functionality which
>isn't easily available otherwise, in a way that hopefully will one day
>become standard. (I'd mention regex and thread as well, but they
>address issues that a beginning programmer probably won't encounter.)
Boost libraries in general demand a generic, functional programming
style from their users (not implementers): e.g. update objects in a
list the Boost way (copied from Boost::functional)
class Person
{
public:
void set_name(const std::string &name);
// ...
};
std::for_each(c.begin(), c.end(),
boost::bind2nd(boost::mem_fun_ref(&Person::set_name), "Fred"));
>> >In the end, it is up to the teacher to make the difference. IMHO,
>> >one of the essential reasons for using Boost is that in any
>> >application, you DO need things like boost::shared_ptr. (Especially
>> >if you have a lot of objects with reference semantics and
>> >polymorphism.)
>
>> I don't use ref-count pointers and I would not recommend them.
>
>You use the Boehm collector, then.
No, C++ is not Java!
>> Dynamically created objects almost never need single treatment, they
>> are usually stored in containers. One owner object can take care of
>> thousands of (polymorphic) objects in a container. IMO ref-count
>> pointers indicate that an application was not designed with resource
>> management in mind.
>
>Or simply that the designer didn't want to make things harder than
>necessary for himself.
Or he uses a pattern that Cargill once called 'Creator as Owner'.
Best regards,
Roland Pibinger
Francis Glassborow
<rpb...@yahoo.com> writes
>Your code is unaware that std::string is a template, your compiler is
>not. In case of a minor (= beginner) mistake it emitts error messages
>that are hard to decipher for a beginner.
If we are talking about real beginners, effectively all error messages
are hard to decipher and translate to 'something went wrong around about
line ...' As the errors they are making are almost always very simple,
just looking at the indicated area eliminates more than 95%. Those
learning should have access to some form of help (via the Internet
newsgroups, ACCU Mentored Developers etc.) so the remaining cases are
dealt with by such means, or by a physical instructor.
The only justification for introducing non-template substitutes is to
reduce compile time. As this is small for beginner type programs that is
hardly a serious factor. Actually I would argue that having compilation
take appreciable time (5-15 seconds) is an advantage when teaching
because it encourages the student to think rather than just throw code
at the compiler.
--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU
Peter Dimov
> On 4 Mar 2003 15:32:19 -0500, ka...@gabi-soft.de (James Kanze) wrote:
>
> >In the end, it is up to the teacher to make the difference. IMHO, one
> >of the essential reasons for using Boost is that in any application, you
> >DO need things like boost::shared_ptr. (Especially if you have a lot of
> >objects with reference semantics and polymorphism.)
>
> I don't use ref-count pointers and I would not recommend them.
> Dynamically created objects almost never need single treatment, they
> are usually stored in containers. One owner object can take care of
> thousands of (polymorphic) objects in a container. IMO ref-count
> pointers indicate that an application was not designed with resource
> management in mind.
To put things in code:
vector<X*> v;
unique(v.begin(), v.end()); // Bad Things(tm)
Possible fix #1:
vector< shared_ptr<X> > v;
unique(v.begin(), v.end()); // OK
Possible fix #2:
class my_pointer_vector
{
vector<X*> v_;
public:
void unique();
};
#2 is a valid approach but so is #1.
LLeweLLyn
[snip]
> If I were a C++ teacher I would first introduce my own minimal
> non-template(!) string class (of course 'upward' compatible with
> std::string)
An apparently simple task which is in fact fraught with error. It is
also largely pointless, as James points out; everyone uses the
typedefs std::string and std::wstring, and (almost) no-one
instantiates the template on anything other than char or wchar_t.
> and later explain that class when introducing operator
> overloading. I also would begin with an non-template string container
> instead of std::vector<std::string>. Otherwise I would empty my class
> too soon.
If you don't make up fables about bogeymen hiding inside of
templates, your students will have nothing to fear from
std::string or std::vector, assuming a modern implementation.
[snip]
> I don't use ref-count pointers and I would not recommend them.
> Dynamically created objects almost never need single treatment, they
> are usually stored in containers. One owner object can take care of
> thousands of (polymorphic) objects in a container.
If this is the case I suspect said objects should have been designed
to have value semantics instead of reference semantics. An
exception to this would be certain GUI paradigms that think
windows are containers. (Another case of bad design, IMO, but so
pervasive it can't be dismissed.)
> IMO ref-count
> pointers indicate that an application was not designed with resource
> management in mind.
Alternatively, design energies were freed up to be applied to more
important aspects of design.
Possilby the objects should have had value or container semantics in the
first place. :-)
> >Making the student
> >write his own puts too much emphesis on generics, templates, etc., too
> >early. Using something ready-made allows more attention to be paid to
> >the larger design issues.
>
> I don't see the reason why the library logic (not implementation)
> should be entirely different form the application logic.
I think library logic should in general be simpler, lower-level, and
more common-denominator oriented than application logic. I don't
think this often results in 'entirely different' logic, but if
your library logic and your application logic are frequently
identical, you are missing out on some bug-preventing code reuse.
Peter Dimov
>
> Boost libraries in general demand a generic, functional programming
> style from their users (not implementers): e.g. update objects in a
> list the Boost way (copied from Boost::functional)
>
> class Person
> {
> public:
> void set_name(const std::string &name);
> // ...
> };
>
> std::for_each(c.begin(), c.end(),
> boost::bind2nd(boost::mem_fun_ref(&Person::set_name), "Fred"));
Sorry, no. You can always find an example in Boost that supports
whatever point you are trying to make, but there is no single "Boost
way" to do things.
The above is actually the STL way to do things, as boost::bind2nd and
boost::mem_fun_ref are merely less limited versions of their std::
counterparts. One possible Boost way would be:
std::for_each(c.begin(), c.end(),
boost::bind(&Person::set_name, _1, "Fred")
);
but you aren't forced to use it if you don't like it.
David Abrahams
> I'm curious if you had a chance to install boost on HP-UX 11
> where the standard library is on the release level 1.x.x?
> The 1.x.x is the release before the std namespace was enabled
> in standard library 2.x.x on this platform. I do not even see the
> toolset for HP-UX aCC (yes I know, I could write one, or maybe I need
> to look better :)
The latter; we've had an acc-tools.jam in the CVS since 2002/12/20.
Boost is not designed to work on compilers without an std:: namespace,
and even the most recent aCC is so horribly broken that it routinely
asserted and/or crashed when I tested it against Boost a few months
ago. However, for some of the simpler libraries (like shared_ptr) you
can probably get it to work if you add -Dstd to your command-lines.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
David Abrahams
> That hasn't been my experience, and I've been unable to get regex to
> compiler for Sun CC.
>
> The reason is doubtlessly linked to the attempts to support all possible
> exotic platforms. (The errors stem from the preprocessor, and all of
> the nested #if render the code completely unreadable.)
Actually the reason is linked to Sun CC's fragility and inability to
deal with even relatively straightforward standard C++. The last time
I tried to run the Boost regression tests (which exercise a fairly
broad sampling of C++ language constructs) against Sun CC, the number
of internal compiler errors was truly amazing. I made some progress,
though; you might try the Boost CVS state. IIRC I found some
workarounds for Sun preprocessor bugs.
David Abrahams
> Just to add my 25 cents: the very fact that boost is a "proprietary"
> library
Huh? Where on *earth* did you get that idea?
Boost is a _collection_ of totally free for unrestricted use
libraries.
David Abrahams
> 2) There is nothing at all wrong with makefiles. Makefiles work
> good!
Can you write me a makefile that will reliably build and test static
and shared libraries (not to mention Python extensions) on a wide
variety of compilers and platforms including Linux, Windows, AIX, SGI,
OSF, and MacOSX? Can you make it possible for developers to write
makefiles that will be highly likely to work on platforms and
compilers they can't even test on?
There are a lot of problems with Makefiles, many of which are
addressed by Boost's build system. Some of our design goals are here:
http://www.boost.org/tools/build/build_system.htm#design_criteria
> someone earlier in the thread commented that a major problem with
> having a CPAN-like thing for C++ is that there's no standard
> installation method
Yes, that is a major and nontrivial problem, a completely different
one from the build problem. How and where you install libraries
(i.e. headers and built products) on various platforms is another
issue altogether.
> and that while something like GNU make could be used, that it would
> no longer be C++, it would be C++ plus some other stuff. My response
> to that is "so what?"
You're right; there's no problem with a distribution system that
involves other tools, especially if you can build those tools with a
C++ compiler.
> Why is it bad to distribute libraries using makefiles? Perl does it,
> and does it well I might add.
Perl has a single command-line interface and perl components fit
together in the same way on all platforms -- one of the benefits of an
interpreted language is that program components don't need to be
configured differently just to hook into platform-specific facilities
such as dynamic loaders, etc. And don't be fooled by the number of
'C' language packages that can be portably built with simple-minded
build systems. C++ is a whole other bag of enchiladas.
> So what if you need a bit of additional infrastructure to handle
> installations? As long as it's standard, free, open, and easily
> available, who cares?
I agree with that part, but please don't trivialize the problem until
you've succeeded in solving it.
> 3) online documentation. Good, LORD, it's hard to find
> documentation on STANDARD c++ libs, much less anything non-stnadard.
Are you _really_ having trouble finding the Boost documentation?
> Want proof? I'm a newbie, I had a homework project over the weekend
> in which I needed to use the mathematical constant PI. Do you know
> how long it took me to find documentation for the cmath library?
Well, that's really a holdover from 'C', but anyway, did you try
googling for cmath? I saw at least two complete references on the
first results page. Or better yet, did you look in your C/C++
standard documents?
David Abrahams
> 1) Distributed Architechture
> Boost should emulate the mirror/rsync method used by perl.
Are you volunteering to set it up for us?
> A good reason for this? the boost site is slow as monkey nutz today.
Really? How fast is your connection? I never notice any appreciable
delay.
ssmith901
Roland Pibinger wrote:
> On 6 Mar 2003 06:35:50 -0500, "Bronek Kozicki" <br...@rubikon.pl>
> wrote:
>
> >Roland Pibinger <rpb...@yahoo.com> wrote:
> > > I don't use ref-count pointers and I would not recommend them.
> > > Dynamically created objects almost never need single treatment, they
> > > are usually stored in containers.
> >
> >What about "std::list<boost::shared_ptr<MyClass> > " ? Do you see any
> >reason not to recommend this ?
>
> What about:
> std::list <MyClass*> list;
> list_owner <MyClass*> owner(list);
>
This seems a gross simplification. What about..
class producer
{
}
class consumer1
{
std::list<boost::shared_ptr <ProducerData> d;
};
class consumer2
{
std::list <boost::shared_ptr<ProducerData> d;
};
with a connectivity of
_____consumer2
producer |
|_____consumer1
I realize this is a rather pathetic illustration of the example, but I'm
currently working on system that has a fan out servant capabilty with no
guarantee that consumers work data off at the same rate The producer
doesn't know who's listening and the consumers don't know who else is
listening. Adding a "controller" or "owner" to manage the data
flow/destruction would just be cumbersome and not really provide any added
benefit. The boost::shared_ptr's provided an elegant "fire and forget"
solution to the problem (and it's free!! ; ) )
As much as possible the problem domain should identify the proper technology
solution, not pick a technology solution and now coerce your design to
comply.
I currently have a lot of new college graduates working for me and they've
all been able to adapt and apply aspects of boost with relative ease.
Just my two cents (commence flaming now....)
Dave Harris
> If we are talking about real beginners, effectively all error messages
> are hard to decipher and translate to 'something went wrong around
> about line ...' As the errors they are making are almost always very
> simple, just looking at the indicated area eliminates more than 95%.
Part of the problem with templates is that the line referenced is
sometimes not the line I wrote. Instead it will be in some template body.
My local compiler will usually also give the point of call/instantiation,
which helps, but sometimes that is just another template. Without knowing
what line of my code produced the error, it's hard to begin to fix it.
Successful compilation of a template body is not enough to ensure that the
body won't give compiler errors when used. In that sense, C++ does not
have separate compilation of templates. I don't think "export" will change
this, either. It's an issue for experienced programmers as well as real
beginners.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Roland Pibinger
"fire and forget" hits the mark. This style of programming really
needs a kind of poor man's garbage collector like shared_ptr. Many
C/C++ programs today produce memory leaks because their programmers
wrote a "fire and forget" solution without shared_ptr. OTOH you also
could employ a symmetric resource management strategy: Always delete
dynamically created objects by (an) automatic object(s) in the same
scope they were allocated, a.k.a. "localized ownership". This seems
constraining at first sight but makes memory management easy and safe.
Which way you chose is more a matter of style than of rightness.
>As much as possible the problem domain should identify the proper technology
>solution, not pick a technology solution and now coerce your design to
>comply.
>
>I currently have a lot of new college graduates working for me and they've
>all been able to adapt and apply aspects of boost with relative ease.
They like shared_ptr? Well, they learnd Java at college ...
Best regards,
LLeweLLyn
> and...@hicox.com (Andrew Hicox) writes:
>
> > 2) There is nothing at all wrong with makefiles. Makefiles work
> > good!
>
> Can you write me a makefile that will reliably build and test static
> and shared libraries (not to mention Python extensions) on a wide
> variety of compilers and platforms including Linux, Windows, AIX, SGI,
> OSF, and MacOSX? Can you make it possible for developers to write
> makefiles that will be highly likely to work on platforms and
> compilers they can't even test on?
Autoconf, etc, can (nearly) do that for all of the above except
windows, plus lots more platforms like cygwin, hpux, solaris,
etc.
In practice I have less trouble getting an autoconf using C++ package to
build than I do getting boost to build (in unusual environments),
despite the brain-damage of those tools with respect to C++
needs. The notable exception to that is, as I said before, windows.
Though I must say that when it comes to ugly, autoconf and its friends
take the cake, platter, and table.
> There are a lot of problems with Makefiles, many of which are
> addressed by Boost's build system. Some of our design goals are here:
> http://www.boost.org/tools/build/build_system.htm#design_criteria
While I think autoconf is so far effectively more portable than boost
Jam, I don't think it does a good job of filling those
design criteria. Several of those criteria are about ease of use
by people who are not build-tool experts - IMO, make and autoconf
fall down hard there.
> > someone earlier in the thread commented that a major problem with
> > having a CPAN-like thing for C++ is that there's no standard
> > installation method
>
> Yes, that is a major and nontrivial problem, a completely different
> one from the build problem. How and where you install libraries
> (i.e. headers and built products) on various platforms is another
> issue altogether.
Perl is a system. C++ is a language. Sometimes I wonder if C++ should
pursue systemhood. Look at Java, C#, and Perl. The problem I see
platforms where a system as extensive as perl is not a viable
option. Finally, I feel that if C++ were to pursue systemhood, it
would need to be friendly to cross-compilation and
remote-execution environmnets. Not an easy task, and not something
any of Java, C#, or Perl attempt to address.
I've also thought a C++ build system should be built on top of a
pre-existing portable system, like perl. That's more or less what
autoconf does, but it uses a subset of sh and common unix command
line tools.
> > and that while something like GNU make could be used, that it would
> > no longer be C++, it would be C++ plus some other stuff. My response
> > to that is "so what?"
>
> You're right; there's no problem with a distribution system that
> involves other tools, especially if you can build those tools with a
> C++ compiler.
Most such distribution systems fail badly in cross-compilation
environments. autoconf and friends are intended to work in
cross-compilation enviroments, but I would say less than half of
the autoconf-using packages I've tried actually build and
configure correctly in the cross-compilation enviroments I've
used. (And those are mostly C packages. autoconf-using C++
packages tend to be less portable.) I've never gotten boost to
configure correctly in a cross-compilation enviroment. (only tried
twice, though) Fortunately, boost is mostly header files. If its
build system doesn't work one can still use most of it. :-)
Sometimes I feel that should tell us something about the form
portable C++ libraries should come in. Then I curse about long
build times. :-) (Of course, distributing the library in the form
of header files really only works for templated libraries - which
seem to have stronger need for test programs which figure out
which work-arounds a platform needs.)
> > Why is it bad to distribute libraries using makefiles? Perl does it,
> > and does it well I might add.
Perl libraries don't just use makefiles. First you run a perl program
to configure the makefile. Amoung other things, the perl program
runs other perl programs which test your system for bugs and
features, in order to determine configuration parameters.
It's easy to dismiss that difference with 'so what, I already have
perl, and would be the point of installing a perl library if I
didn't?' But we are talking about C++. Most C++ libraries will
need to run small C++ test progarams in order to determine the
bugset of your implementation and the corresponding configuration
platforms. These things generally don't work in a
cross-compilation environment, though I believe they could be made
to (with an expensive work investment), in most cases. Perl isn't
used in any form analogous to cross-compilation, but C++ often is.
Now, I am *not* saying these sorts of techniques shouldn't be used by
C++ libs; on the contrary I feel they are the most effective so
far. I'm saying there is a significant fraction of C++ users which
they will serve poorly until the techniques improve. (Which I
expect to happen; I know of no reason that makes it impossible to
properly configure a c++ library in a cross-compilation
environment; just factors that make it more difficult than a non
cross-compilation environment.)
> Perl has a single command-line interface and perl components fit
> together in the same way on all platforms -- one of the benefits of an
> interpreted language is that program components don't need to be
> configured differently just to hook into platform-specific facilities
> such as dynamic loaders, etc. And don't be fooled by the number of
> 'C' language packages that can be portably built with simple-minded
> build systems. C++ is a whole other bag of enchiladas.
>
> > So what if you need a bit of additional infrastructure to handle
> > installations? As long as it's standard, free, open, and easily
> > available, who cares?
>
> I agree with that part, but please don't trivialize the problem until
> you've succeeded in solving it.
>
> > 3) online documentation. Good, LORD, it's hard to find
> > documentation on STANDARD c++ libs, much less anything non-stnadard.
>
> Are you _really_ having trouble finding the Boost documentation?
>
> > Want proof? I'm a newbie, I had a homework project over the weekend
> > in which I needed to use the mathematical constant PI. Do you know
> > how long it took me to find documentation for the cmath library?
>
> Well, that's really a holdover from 'C', but anyway, did you try
> googling for cmath? I saw at least two complete references on the
> first results page. Or better yet, did you look in your C/C++
> standard documents?
If you know what to google for, C++ documentation is usually easy to
find. If you don't, it isn't. Does a newbie know that M_PI and
friends are #defined in <cmath> ? I don't think so. Will he know
what to google for if sees 'boost::bind' in some code he's working
on? More likely than connecting M_PI or <cmath> with pi. If he
needs boost::bind, but hasn't seen it, will he know what to look
for? Not likely.
I'm guessing Dave is aware of most of what I've said (though not
necessarily in agreement :-), but I don't think everyone is.
Roland Pibinger
>rpb...@yahoo.com (Roland Pibinger) wrote in message news:<3e651ed8...@news.utanet.at>...
>> On 4 Mar 2003 15:32:19 -0500, ka...@gabi-soft.de (James Kanze) wrote:
>>
>> >In the end, it is up to the teacher to make the difference. IMHO, one
>> >of the essential reasons for using Boost is that in any application, you
>> >DO need things like boost::shared_ptr. (Especially if you have a lot of
>> >objects with reference semantics and polymorphism.)
>>
>> I don't use ref-count pointers and I would not recommend them.
>> Dynamically created objects almost never need single treatment, they
>> are usually stored in containers. One owner object can take care of
>> thousands of (polymorphic) objects in a container. IMO ref-count
>> pointers indicate that an application was not designed with resource
>> management in mind.
>
>To put things in code:
>
>vector<X*> v;
>unique(v.begin(), v.end()); // Bad Things(tm)
Do you mean duplicate entries in v (pointers pointing to the same
object) or the effects of std::unique on a sequence of pointers?
>Possible fix #1:
>
>vector< shared_ptr<X> > v;
>unique(v.begin(), v.end()); // OK
>
>Possible fix #2:
>
>class my_pointer_vector
>{
> vector<X*> v_;
>
>public:
>
> void unique();
>};
>
>#2 is a valid approach but so is #1.
I can hardly think of reasons why one would call unique for a
container of pointers, maybe in an assert (assuming v is sorted):
assert (v.end() == unique(v.begin(), v.end());
Mutating algorithms and pointers just don't match.
Best regards,
Roland Pibinger
witoldk
> wit...@optonline.net (witoldk) writes:
>
> > I'm curious if you had a chance to install boost on HP-UX 11
> > where the standard library is on the release level 1.x.x?
> > The 1.x.x is the release before the std namespace was enabled
> > in standard library 2.x.x on this platform. I do not even see the
> > toolset for HP-UX aCC (yes I know, I could write one, or maybe I need
> > to look better :)
>
> The latter; we've had an acc-tools.jam in the CVS since 2002/12/20.
Maybe the last time I checked was more than three months ago...
>
> Boost is not designed to work on compilers without an std:: namespace,
Please note that HP's aCC is fully namespace-capable. I meant the
standard library, not aCC.
> and even the most recent aCC is so horribly broken that it routinely
> asserted and/or crashed when I tested it against Boost a few months
> ago.
Yeah, crap they make these HP people. They have had fully 64bit platform
for quite some time, their OS runs 32bit binaries and is rock-solid-stable.
And HP means absolutely nothing in C++/STL world.
Yeah, HP-UX aCC is crap. The experience must have been really horrible.
And of course would never make you think how far ahead of reality boost
is.
Before someone jumps on the word reality above, please let me clarify
that the "reality" is meant to mean "boring, totally un-cool non-PC,
light years behind the cutting edge C++ development".
witoldk
> wit...@optonline.net (witoldk) wrote in message news:<9bed99bb.03030...@posting.google.com>...
>
> > Just to add my 25 cents: the very fact that boost is a "proprietary"
> > library ...
>
> Where did you get that idea? Boost is free open-source code with
> licenses aimed at promoting wide use, including commercial use. It
> isn't GPL'ed, or anything like that.
>
> --Beman
Sorry, did not mean aything contradicting your statement.
See double quotes around proprietary?
Probably should have said _third party_.
My appologies.
witoldk
> wit...@optonline.net (witoldk) writes:
>
> > Just to add my 25 cents: the very fact that boost is a "proprietary"
> > library
>
> Huh? Where on *earth* did you get that idea?
>
> Boost is a _collection_ of totally free for unrestricted use
> libraries.
I did not mean it was not free. Sorry if anybody took it to mean that.
But see the double quotes around proprietary?
What do you want me to call it? I've already called it cool.
Would you prefer it be called YALibrary, or non-standard C++ library
(as opposed to standrad C++ library:) sounds better ?
David Abrahams
> David Abrahams <da...@boost-consulting.com> writes:
>
>> and...@hicox.com (Andrew Hicox) writes:
>>
>> > 2) There is nothing at all wrong with makefiles. Makefiles work
>> > good!
>>
>> Can you write me a makefile that will reliably build and test static
>> and shared libraries (not to mention Python extensions) on a wide
>> variety of compilers and platforms including Linux, Windows, AIX, SGI,
>> OSF, and MacOSX? Can you make it possible for developers to write
>> makefiles that will be highly likely to work on platforms and
>> compilers they can't even test on?
>
> Autoconf, etc, can (nearly) do that for all of the above except
> windows, plus lots more platforms like cygwin, hpux, solaris,
> etc.
All covered by Boost.Build, BTW.
> In practice I have less trouble getting an autoconf using C++ package to
> build than I do getting boost to build (in unusual
> environments),
Sure, I agree. The question is, is that due to broken compilers which
can't handle standard C++, or because configuring the build system is
difficult? In my experience the former is the greater obstacle. If
that's the main problem, no amount of autoconf will help.
> despite the brain-damage of those tools with respect to C++
> needs. The notable exception to that is, as I said before, windows.
...which is an important target for us. BTW, Boost has an autoconf
configuration script, but in general the hand-tweaked configuration we
supply works better than what you'll get out of autoconf.
> Though I must say that when it comes to ugly, autoconf and its friends
> take the cake, platter, and table.
Aesthetics weren't as much of a concern for us as:
1. How many different subsystems/languages one has to learn in order
to use it
2. How much a developer may be required to install in order to use it
(yes, some Windows developers/companies balk at installing Cygwin).
3. Whether it fulfills our needs as a multi-compiler build/test system
> Perl is a system. C++ is a language. Sometimes I wonder if C++ should
> pursue systemhood. Look at Java, C#, and Perl. The problem I see
> platforms where a system as extensive as perl is not a viable
> option. Finally, I feel that if C++ were to pursue systemhood, it
> would need to be friendly to cross-compilation and
> remote-execution environmnets. Not an easy task, and not something
> any of Java, C#, or Perl attempt to address.
Part of the problem is that it still isn't easy enough to *build*
systems in C++, for the lack of things like a standard filesystem
library. However, even solving that problem that doesn't make those
latter goals easy.
> I've also thought a C++ build system should be built on top of a
> pre-existing portable system, like perl. That's more or less what
> autoconf does, but it uses a subset of sh and common unix command
> line tools.
We wanted to build it on top of Python, like SCons
(http://scons.sf.net) does, but unfortunately that fell afoul of #2
above for too many people. If you really like to read Perl (<wink>)
you might consider cons
(http://www.foo.be/docs/tpj/issues/vol3_1/tpj0301-0012.html)
> Most such distribution systems fail badly in cross-compilation
> environments. autoconf and friends are intended to work in
> cross-compilation enviroments, but I would say less than half of
> the autoconf-using packages I've tried actually build and
> configure correctly in the cross-compilation enviroments I've
> used. (And those are mostly C packages. autoconf-using C++
> packages tend to be less portable.) I've never gotten boost to
> configure correctly in a cross-compilation enviroment. (only tried
> twice, though)
Boost.Build v1 isn't designed to do that. We plan to support it in
v2 at some point.
> Fortunately, boost is mostly header files. If its build system
> doesn't work one can still use most of it. :-) Sometimes I feel
> that should tell us something about the form portable C++
> libraries should come in. Then I curse about long build
> times. :-) (Of course, distributing the library in the form of
> header files really only works for templated libraries
There's always "inline" <wink>.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David Abrahams
> OTOH you also could employ a symmetric resource management strategy:
> Always delete dynamically created objects by (an) automatic
> object(s) in the same scope they were allocated, a.k.a. "localized
> ownership". This seems constraining at first sight
And second sight, and third sight. You can hardly do anything with
this strategy that can't also be done with automatic objects. There's
almost no point in using dynamic allocation at all in that case.
> but makes memory management easy and safe.
Not by itself. Your guideline fails to deal with leaks due to
exceptions thrown between sequence points, for example.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
witoldk
is essential to give adequate context to your responses. Then resubmit.
-mod}
ka...@gabi-soft.de (James Kanze) wrote in message news:<d6651fb6.03030...@posting.google.com>...
And that means _maintaining_ _two_ installations.
> will take time here as well, in order to ascertain that they aren't
> accidentally installing a virus.
>
> Still, it can usually be done, and the total amount of work necessary
> will still usually be less than what it would take to develop the same
> tools in house, although because that work may involve other
> departments, it may be spread out over a longer period of time.
>
> > Sometimes I'm under the impression that many here work where everybody
> > dances to their tune.
>
> Not my case, and I understand your problem.
>
> > Please understand that there are places where testing the new and cool
> > stuff is left for the others. In places like that it is hard to
> > imagine that installing something into a production chain is going to
> > happen because there is a cool library out there that the developers
> > would love to have. Places like that usually run two releases behind,
> > so to speak :)
>
> Tell me about it. We're still compiling with compat 4.2 mode of the Sun
> compiler, because some of the libraries don't work right with more
> recent releases.
The last time I worked on Solaris we were doing some networking code and
Sun was patching the OS and compiler twice a week (well, maybe once in
two weeks, really :).
Others here do not really think high of HP's aCC, I'm not really thrilled
with it either. But the subset of standard it claims it supports it does
well (in my experience, at least - I've completely dropped the habbit of
thinking about compiler bugs first - I know all the bugs are mine :).
That saves me time in the long run.
(It also might be I'm not pushing it hard enough:)
>
> > I'm curious if you had a chance to install boost on HP-UX 11 where the
> > standard library is on the release level 1.x.x?
>
> My last two contracts have been in purely Solaris. Before that, AIX for
> well over three years. My experience with HP/UX goes back to before
> Boost -- in fact, it goes back to a time when their compiler was still
> CFront.
It is still being shipped :)
The reason might be that there is tons of "old" :-) C++ that no new
compiler would swallow. I've seen some. I guess it is cheaper not to touch
it. That would make CC needed for diseaster recovery'n stuff, and so it
is still part of standard distribution.
Agreed.
>
> > Let me re-iterate: raw new.
> > (as no more options were given :)
>
> IMHO, raw pointers are NOT an option, unless you are using the Boehm
> collector. (Raw new is used with both the Boost pointers and my own
> smart pointers.) This doesn't deny your arguments for using in-house
> developed smart pointers, of course. The arguments may be largely
> political, but that doesn't make them less real. And in the case of
> smart pointers, the strictly technical arguments are also against Boost:
> they all favor using the Boehm collector. But I'll bet you'll have even
> more problems getting that accepted:-).
I'm not _really_ advocating using raw pointers :)
Roland Pibinger
<da...@boost-consulting.com> wrote:
>rpb...@yahoo.com (Roland Pibinger) writes:
>
>> OTOH you also could employ a symmetric resource management strategy:
>> Always delete dynamically created objects by (an) automatic
>> object(s) in the same scope they were allocated, a.k.a. "localized
>> ownership". This seems constraining at first sight
>
>And second sight, and third sight. You can hardly do anything with
>this strategy that can't also be done with automatic objects. There's
>almost no point in using dynamic allocation at all in that case.
Maybe I did not express myself clearly, so here is an example.
template <class T>
class list_owner
{
public:
list_owner (std::list<T>& l) : list (l) {}
~list_owner()
{
typename std::list<T>::iterator iter;
for (iter = list.begin(); iter != list.end(); ++iter)
delete *iter;
list.clear();
}
private:
std::list<T>& list;
list_owner (const list_owner& );
list_owner& operator= (list_owner& );
};
using namespace std;
void foo1 (const list<string*> l) {/*...*/}
void foo2 (const string& s) {/*...*/}
int main()
{
list<string*> list;
list_owner<string*> o(list);
srand (time (NULL));
int k = rand() % 9999;
for (int i = 0; i < k; ++i)
list.push_back (new string ("Hello!"));
foo1 (list);
if (list.size() > 0)
foo2 (**list.begin());
// ...
} // no memory leak here
>> but makes memory management easy and safe.
Tom Cargill developed a "pattern langugage" WRT the "management of
dynamic-object lifetimes in C++" called "Localized Ownership" (printed
in Vlissides et al "Pattern Languages of Program Design 2").
Unfortunately these patterns (it is more a categorization of idioms)
have not been discussed widely.
The patterns are ordered by decreasing localization:
1. Creator as Owner (creator becomes owner, ownership is not
transferred)
1.1 Function as Owner (see above)
1.2 Object as Owner
1.3 Class as Owner
2. Sequence of Owners (e.g. auto_ptr)
3. Shared Ownership (e.g. shared_ptr)
Cargill: "Localized responsibility generally simplifies design and
implementation. Therefore, use the lowest-numbered pattern that
suffices". IMO, "Creator as Owner" is sufficent for most cases if you
design your application with it in mind from the beginning.
Best regards,
Roland Pibinger
David Abrahams
>> Boost is not designed to work on compilers without an std:: namespace,
>
> Please note that HP's aCC is fully namespace-capable. I meant the
> standard library, not aCC.
The library is part of the C++ implementation. Of course, aCC +
STLPort has potential with Boost.
>> and even the most recent aCC is so horribly broken that it routinely
>> asserted and/or crashed when I tested it against Boost a few months
>> ago.
>
> Yeah, crap they make these HP people. They have had fully 64bit platform
> for quite some time, their OS runs 32bit binaries and is rock-solid-stable.
> And HP means absolutely nothing in C++/STL world.
> Yeah, HP-UX aCC is crap.
I didn't say that.
> The experience must have been really horrible.
Yes it was. It's one thing to get error messages due to unsupported
or badly-implemented features -- at least with those you stand a good
chance of finding a workaround -- but when the compiler just quits
and gives no clue as to how or why, it does become extremely frustrating.
> And of course would never make you think how far ahead of reality
> boost is.
"Reality" is that most Boost libraries work on most C++ compilers in
common use (http://boost.sourceforge.net/regression-logs/). There are
two major compilers I can think of with which we're currently having
serious trouble, HP aCC and Sun CC, both of which exhibit extremely
hard-to-understand bugs when you try to run the tests. Usually,
though, supporting a given broken compiler is just a matter of
investing time. If we had more committed people working with these
compilers (even someone to run the regression tests would help) I'm
sure they'd be faring better.
> Before someone jumps on the word reality above, please let me clarify
> that the "reality" is meant to mean "boring, totally un-cool non-PC,
> light years behind the cutting edge C++ development".
I have to agree with your assesment of Boost then. We do not aspire
to be "light years behind the cutting edge" :-)
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David Abrahams
> David Abrahams <da...@boost-consulting.com> wrote in message news:<un0k6q...@boost-consulting.com>...
>> wit...@optonline.net (witoldk) writes:
>>
>> > Just to add my 25 cents: the very fact that boost is a "proprietary"
>> > library
>>
>> Huh? Where on *earth* did you get that idea?
>>
>> Boost is a _collection_ of totally free for unrestricted use
>> libraries.
>
> I did not mean it was not free. Sorry if anybody took it to mean
> that. But see the double quotes around proprietary?
I see them, but when you add quotes around a word it doesn't usually
indicate, "I really mean something completely different, try to guess
what that is." It usually indicates, "I mean something almost like
this". Whatever else Boost may be, it isn't anything like
proprietary.
> What do you want me to call it? I've already called it cool.
I like that ;-)
> Would you prefer it be called YALibrary, or non-standard C++ library
> (as opposed to standrad C++ library:) sounds better ?
It depends what you mean to say, but "non-standard" is certainly an
accurate description. However, Boost is not just one library, so
"non-standard C++ libraries" would be more apt.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
WitoldK
> wit...@optonline.net (witoldk) writes:
>
> > David Abrahams <da...@boost-consulting.com> wrote in message
news:<un0k6q...@boost-consulting.com>...
> >> wit...@optonline.net (witoldk) writes:
> >>
> >> > Just to add my 25 cents: the very fact that boost is a "proprietary"
> >> > library
> >>
> >> Huh? Where on *earth* did you get that idea?
> >>
> >> Boost is a _collection_ of totally free for unrestricted use
> >> libraries.
> >
> > I did not mean it was not free. Sorry if anybody took it to mean
> > that. But see the double quotes around proprietary?
>
> I see them, but when you add quotes around a word it doesn't usually
> indicate, "I really mean something completely different, try to guess
> what that is." It usually indicates, "I mean something almost like
> this". Whatever else Boost may be, it isn't anything like
> proprietary.
Point well taken. I am admitting it was a mistake. I am taking it back.
Boost is not proprietary.
James Kanze
|> wit...@optonline.net (witoldk) writes:
|> > David Abrahams <da...@boost-consulting.com> wrote in message
|> > news:<un0k6q...@boost-consulting.com>...
|> >> wit...@optonline.net (witoldk) writes:
|> >> > Just to add my 25 cents: the very fact that boost is a
|> >> > "proprietary" library
|> >> Huh? Where on *earth* did you get that idea?
|> >> Boost is a _collection_ of totally free for unrestricted use
|> >> libraries.
|> > I did not mean it was not free. Sorry if anybody took it to mean
|> > that. But see the double quotes around proprietary?
|> I see them, but when you add quotes around a word it doesn't
|> usually indicate, "I really mean something completely different,
|> try to guess what that is." It usually indicates, "I mean
|> something almost like this". Whatever else Boost may be, it isn't
|> anything like proprietary.
I think that quotes can often mean something along the lines of "is
considered as, although it isn't". Whatever else Boost is, it isn't
standard, and in some shops, that means that it is "proprietary", and
can't be used. I'm not defending this attitude -- independantly of
Boost, it seems stupid to me to not use an existing solution which
works, rather than to reinvent the wheel. But while I've been lucky
in my recent contracts, I've seen places in the past where it was just
politically impossible to use anything external that didn't come with
the compiler.
--
James Kanze mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France Tel. +33 1 41 89 80 93
WitoldK
> wit...@optonline.net (witoldk) writes:
>
> >> and even the most recent aCC is so horribly broken that it routinely
> >> asserted and/or crashed when I tested it against Boost a few months
> >> ago.
> >
> > Yeah, crap they make these HP people. They have had fully 64bit platform
> > for quite some time, their OS runs 32bit binaries and is
rock-solid-stable.
> > And HP means absolutely nothing in C++/STL world.
> > Yeah, HP-UX aCC is crap.
>
> I didn't say that.
Of course you didn't. I did.
>
> > The experience must have been really horrible.
>
> Yes it was. It's one thing to get error messages due to unsupported
> or badly-implemented features -- at least with those you stand a good
> chance of finding a workaround -- but when the compiler just quits
> and gives no clue as to how or why, it does become extremely frustrating.
Agreed. It is easy to get aCC to quit, and you do not even need anything
fancy to do that. Yet, this compiler is used by many companies and many
developers. Often with quite satisfactory results :)
>
> > And of course would never make you think how far ahead of reality
> > boost is.
>
> "Reality" is that most Boost libraries work on most C++ compilers in
> common use (http://boost.sourceforge.net/regression-logs/). There are
> two major compilers I can think of with which we're currently having
> serious trouble, HP aCC and Sun CC, both of which exhibit extremely
> hard-to-understand bugs when you try to run the tests
> > Before someone jumps on the word reality above, please let me clarify
> > that the "reality" is meant to mean "boring, totally un-cool non-PC,
> > light years behind the cutting edge C++ development".
>
> I have to agree with your assesment of Boost then. We do not aspire
> to be "light years behind the cutting edge" :-)
>
Of course you do not. Boost is the cutting edge. My clarification was meant
to be sarcastic. I clearly failed at that :)
My point was really more that your two major broken compilers carry a lot
of weight among them. Some might say that if the library can not be
compiled on Solaris nor on HP-UX then _it_ must be broken. And that, no
matter how much these platforms' native compilers are broken. And no
matter how cutting edge the library is otherwise.
That would not be me though :)
But, that is what I meant by reality.
David Abrahams
> On 8 Mar 2003 19:54:04 -0500, David Abrahams
> <da...@boost-consulting.com> wrote:
>
>>rpb...@yahoo.com (Roland Pibinger) writes:
>>
>>> OTOH you also could employ a symmetric resource management strategy:
>>> Always delete dynamically created objects by (an) automatic
>>> object(s) in the same scope they were allocated, a.k.a. "localized
>>> ownership". This seems constraining at first sight
>>
>>And second sight, and third sight. You can hardly do anything with
>>this strategy that can't also be done with automatic objects. There's
>>almost no point in using dynamic allocation at all in that case.
>
> Maybe I did not express myself clearly, so here is an example.
I think you did.
That proves my point. What you have above is no different
semantically from the much simpler:
void foo1 (list<string> const& l) {/*...*/}
void foo2 (string const& s) {/*...*/}
int main()
{
list<string> l;
srand (time (NULL));
int k = rand() % 9999;
for (int i = 0; i < k; ++i)
l.push_back(string("Hello!"));
foo1(l);
if (l.size() > 0)
foo2 (l.front());
// ...
} // no memory leak here
On the other hand, shared_ptr allows you to express networks of
objects such as the collaboration scheme mentioned by another poster,
that can't be managed with your kind of strategy.
> Tom Cargill developed a "pattern langugage" WRT the "management of
> dynamic-object lifetimes in C++" called "Localized Ownership" (printed
> in Vlissides et al "Pattern Languages of Program Design 2").
> Unfortunately these patterns (it is more a categorization of idioms)
> have not been discussed widely.
>
> The patterns are ordered by decreasing localization:
> 1. Creator as Owner (creator becomes owner, ownership is not
> transferred)
> 1.1 Function as Owner (see above)
> 1.2 Object as Owner
> 1.3 Class as Owner
> 2. Sequence of Owners (e.g. auto_ptr)
> 3. Shared Ownership (e.g. shared_ptr)
>
> Cargill: "Localized responsibility generally simplifies design and
> implementation. Therefore, use the lowest-numbered pattern that
> suffices". IMO, "Creator as Owner" is sufficent for most cases if you
> design your application with it in mind from the beginning.
Another rule is: "use a small number of general purpose design
patterns that together cover nearly all cases, and you won't have to
worry about these sort of details". IMO by-value containment and
boost::shared_ptr cover almost everything very well.
BTW, I notice that your *_owner ("proxy ownership") pattern isn't in
Cargill's list.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David Abrahams
> I think that quotes can often mean something along the lines of "is
> considered as, although it isn't". Whatever else Boost is, it isn't
> standard, and in some shops, that means that it is "proprietary",
Not unless you're using some special definition of that word which I
don't have access to. (see
http://dictionary.reference.com/search?q=proprietary).
> and can't be used. I'm not defending this attitude
And I'm not arguing with the attitude. Some shops can't use anything
from a third party, too bad. I'm just saying that nobody can
reasonably claim that Boost is proprietary, or even that it's
something resembling proprietary.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> and...@hicox.com (Andrew Hicox) writes:
> > 2) There is nothing at all wrong with makefiles. Makefiles work
> > good!
> Can you write me a makefile that will reliably build and test static
> and shared libraries (not to mention Python extensions) on a wide
> variety of compilers and platforms including Linux, Windows, AIX, SGI,
> OSF, and MacOSX? Can you make it possible for developers to write
> makefiles that will be highly likely to work on platforms and
> compilers they can't even test on?
I've done so in the past. I'll admit that I cheated a bit, however; I
require the installation of GNU make first:-).
Whatever its defects, make is a pseudo-standard. Using something else
is just another hurdle that has to be overcome when installing the
software. (In a lot of places, sysadmins are hesitant to install things
that they don't understand.)
> There are a lot of problems with Makefiles, many of which are
> addressed by Boost's build system. Some of our design goals are here:
> http://www.boost.org/tools/build/build_system.htm#design_criteria
Saying that there are problems with makefiles is putting it mildly. On
the other hand, there is a lot of experience out their in overcoming
those problems.
The documentation on the web site isn't up to date, at least with
regards to shared_ptr.
> > Want proof? I'm a newbie, I had a homework project over the weekend
> > in which I needed to use the mathematical constant PI. Do you know
> > how long it took me to find documentation for the cmath library?
> Well, that's really a holdover from 'C', but anyway, did you try
> googling for cmath? I saw at least two complete references on the
> first results page. Or better yet, did you look in your C/C++
> standard documents?
Part of the problem is probably that googling for "pi" (or even "pi and
c++") will probably not be very useful. It's a special case, I think;
most of the time, the search terms can be much tighter. A search for
"smart pointer c++" turned up an article by Herb Sutter citing the Boost
pointers as the second entry (and the link in the first entry was dead,
so it was the first you could actually use).
--
James Kanze GABI Software mailto:ka...@gabi-soft.fr
Conseils en informatique oriente objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tl. : +33 (0)1 30 23 45 16
Roland Pibinger
<da...@boost-consulting.com> wrote:
>rpb...@yahoo.com (Roland Pibinger) writes:
>
>> On 8 Mar 2003 19:54:04 -0500, David Abrahams
>> <da...@boost-consulting.com> wrote:
>>
>>>rpb...@yahoo.com (Roland Pibinger) writes:
>>>
[...]
>> int main()
>> {
>> list<string*> list;
>> list_owner<string*> o(list);
[...]
>> }
>
>
>That proves my point. What you have above is no different
>semantically from the much simpler:
[...]
>int main()
>{
> list<string> l;
[...]
>}
In my example string is just a placeholder. Replace it with any
non-copyable entity-class and the semantic equivalence is gone. Your
solution is only applicable for objects with value semantics.
>On the other hand, shared_ptr allows you to express networks of
>objects such as the collaboration scheme mentioned by another poster,
>that can't be managed with your kind of strategy.
A network of objects is probably charactericed by high coupling
between objects. In this case localizerd ownership might even simplify
memory/resource issues.
>> Tom Cargill developed a "pattern langugage" WRT the "management of
>> dynamic-object lifetimes in C++" called "Localized Ownership" (printed
>> in Vlissides et al "Pattern Languages of Program Design 2").
>> Unfortunately these patterns (it is more a categorization of idioms)
>> have not been discussed widely.
>>
>> The patterns are ordered by decreasing localization:
>> 1. Creator as Owner (creator becomes owner, ownership is not
>> transferred)
>> 1.1 Function as Owner (see above)
>> 1.2 Object as Owner
>> 1.3 Class as Owner
>> 2. Sequence of Owners (e.g. auto_ptr)
>> 3. Shared Ownership (e.g. shared_ptr)
>>
>> Cargill: "Localized responsibility generally simplifies design and
>> implementation. Therefore, use the lowest-numbered pattern that
>> suffices". IMO, "Creator as Owner" is sufficent for most cases if you
>> design your application with it in mind from the beginning.
>
>Another rule is: "use a small number of general purpose design
>patterns that together cover nearly all cases, and you won't have to
>worry about these sort of details".
Which details? Just put the owner in the right scope, that's all!
Owner's class can be implemented in a generic way for all
std::containers except maps. Effectively you need 3 classes:
scoped_ptr for one dynamic object, 'container_owner' for 0-N dynamic
objects, and 'map_owner' for keyed dynamic objects.
>IMO by-value containment and
>boost::shared_ptr cover almost everything very well.
... but they are not the only design alternatives, especially if you
want symmetric and deterministic resource management (that you can
have in C++ but not in gc languages).
>BTW, I notice that your *_owner ("proxy ownership") pattern isn't in
>Cargill's list.
It is, it's 'Function as Owner'. *_owner is just a helper-object. The
pattern describes the scope where objects are created and destroyed.
Best regards,
Roland Pibinger
David Abrahams
> David Abrahams <da...@boost-consulting.com> wrote in message
> news:<uu1eeq...@boost-consulting.com>...
> > and...@hicox.com (Andrew Hicox) writes:
>
> > > 2) There is nothing at all wrong with makefiles. Makefiles work
> > > good!
>
> > Can you write me a makefile that will reliably build and test static
> > and shared libraries (not to mention Python extensions) on a wide
> > variety of compilers and platforms including Linux, Windows, AIX, SGI,
> > OSF, and MacOSX? Can you make it possible for developers to write
> > makefiles that will be highly likely to work on platforms and
> > compilers they can't even test on?
>
> I've done so in the past. I'll admit that I cheated a bit, however; I
> require the installation of GNU make first:-).
How did you deal with all the differences between platforms?
> Whatever its defects, make is a pseudo-standard. Using something
> else is just another hurdle that has to be overcome when installing
> the software. (In a lot of places, sysadmins are hesitant to
> install things that they don't understand.)
It's true, and I can't argue with the value of standards. However, a
few of us (see also Scons - scons.sf.net, A-A-P -
http://www.a-a-p.org/, and others) think that some standards need to
be overturned eventually.
> > There are a lot of problems with Makefiles, many of which are
> > addressed by Boost's build system. Some of our design goals are
> > here:
> > http://www.boost.org/tools/build/build_system.htm#design_criteria
>
> Saying that there are problems with makefiles is putting it
> mildly.
:-)
> On the other hand, there is a lot of experience out their in
> overcoming those problems.
Yes, and some programmer is always repeating the experience of
learning how to do that.
> > Are you _really_ having trouble finding the Boost documentation?
>
> The documentation on the web site isn't up to date, at least with
> regards to shared_ptr.
I didn't say it was always perfect, just that it was easy to find.
BTW, what specifically is out-of-date? We are about to do another
release and I'd like to make sure it's fixed.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
ssmith901
Roland Pibinger wrote:
I don't understand this statement. I used boost::shared_ptr<> because I
wanted
no coupling between objects. The data creator has no concept (nor does it
need to know) who its consumers are. Additionally, consumers don't know (and
don't care) what other consumers may be acquiring the same data. I was
specifically avoiding the concept of a data "owner" because I thought that
introduced a very strong coupling.
LLeweLLyn
> LLeweLLyn <llewe...@xmission.dot.com> writes:
[snip]
> > In practice I have less trouble getting an autoconf using C++ package to
> > build than I do getting boost to build (in unusual
> > environments),
>
> Sure, I agree. The question is, is that due to broken compilers which
> can't handle standard C++, or because configuring the build system is
> difficult? In my experience the former is the greater obstacle. If
> that's the main problem, no amount of autoconf will help.
On the most difficult platforms (that weren't cross-compilation
environments, that is) I've dealt with, the biggest
problem with boost was getting was getting a working boost jam,
actually. Once I got a working boost jam, boost configured itself
well enough that I could use the parts I cared about, despite the
brokeness of the compilers. Mind, I didn't use boost extensively
in these projects - only for a few, relatively simple
things. IOWs, the brokeness of some C++ compilers with respect to
boost is a problem you and the other boost developers have largely
already solved (and go on solving), in as much as is feasible. (By
the way, thank you, and congratulations on the quality of your work.)
As for broken compilers, autoconf can help in two ways:
(a) It can run tests to determine which workarounds
are needed. (With the caveats about running such tests in
cross-compilation environments, which I've already covered.) That,
however, is in the hands of the maintainers of a project, not its
users. I'm aware such workarounds can only go so far, but I think
most of the time that is far enough. I'm also aware that such
tests are deceptively easy to get almost right, so that they only
go wrong on hard to obtain platforms. :-)
(b) It can select a hand-tweaked configuration for a pre-tested
platform.
I've only got an occasional user's perspective of boost.build, but I
believe it relies primarily on (b), but is capable of (a) as
well.
Autoconf is primarily aimed towards (a), but it seems to me most
autoconf-using projects (including
most autoconf-using C++ projects) which need unusual tests
(that is, tests that don't come with autoconf ) tend to assume
certain features go together and do something between (a) and
(b).
Mind, I'm not saying boost should switch to autoconf (that is, switch
to using autoconf primarily), or that a new project should
necessarily prefer autoconf techniques to those used by boost; I'm
just pointing it out as an alternative, which some projects have
used successfuly.
> > despite the brain-damage of those tools with respect to C++
> > needs. The notable exception to that is, as I said before, windows.
>
> ...which is an important target for us. BTW, Boost has an autoconf
> configuration script, but in general the hand-tweaked configuration we
> supply works better than what you'll get out of autoconf.
Since I've always used the hand-tweaked configuration, I can only say
I trust you. :-) (I did try the autoconf configuration script in
two cases, for which there weren't hand-tweaked configurations,
but it didn't work; those were odd cross-compilation
environments.)
> > Though I must say that when it comes to ugly, autoconf and its friends
> > take the cake, platter, and table.
>
> Aesthetics weren't as much of a concern for us as:
>
> 1. How many different subsystems/languages one has to learn in order
> to use it
This issue reminds me of your comment about C++ being a 'whole other
bag of enchiladas' . Using autoconf with C is often quite easy -
you use the macros it comes with in more or less the way described
in the manual, and presto, your C project builds and runs on an
amazing variety of unices, including some you've never heard
of. On the other hand, an autoconf-using C++ project needs its own
tests (some tests can be obtained from other autoconf-using C++
projects, such as libsigc++, etc, but in general if you aren't
prepared to write your own tests, you aren't prepared), which
means learning gnu m4 and sh (If you thought the combo of
CPP and c++ was fun, you ain't seen nothin' yet, baby.). Then
there are linker issues... :-). IOWs, using autoconf for C++
requires learning more subsystems/languages than using it for
C. Another reason C isn't going away anytime soon. (Autoconf is
hardly the only tool with this property.)
> 2. How much a developer may be required to install in order to use it
> (yes, some Windows developers/companies balk at installing Cygwin).
I would say nearly all, and cygwin isn't the only set of unix tools
such people balk at installing. Thus my classification of windows
as a platform autoconf doesn't handle. (And while I won't live
without a unix-style command line if I can help it, I won't
pretend such balkiness is without reason.)
[snip]
> > I've also thought a C++ build system should be built on top of a
> > pre-existing portable system, like perl. That's more or less what
> > autoconf does, but it uses a subset of sh and common unix command
> > line tools.
>
> We wanted to build it on top of Python, like SCons
> (http://scons.sf.net) does, but unfortunately that fell afoul of #2
> above for too many people. If you really like to read Perl (<wink>)
> you might consider cons
> (http://www.foo.be/docs/tpj/issues/vol3_1/tpj0301-0012.html)
Thank you. I do like perl. I imagine you'll keep an eye on the Python
possiblity; if Python spreads enough, it may become a good option.
> > Most such distribution systems fail badly in cross-compilation
> > environments.
[snip]
> > I've never gotten boost to
> > configure correctly in a cross-compilation enviroment. (only tried
> > twice, though)
>
> Boost.Build v1 isn't designed to do that. We plan to support it in
> v2 at some point.
Glad to hear that, thank you.
[snip]
> > (Of course, distributing the library in the form of
> > header files really only works for templated libraries
>
> There's always "inline" <wink>.
Yes. Now that one can expect most compilers to ignore its optimization
hint, inline can freely be used a source-code organization trick
... :-)
David Abrahams
> David Abrahams <da...@boost-consulting.com> writes:
>
> > LLeweLLyn <llewe...@xmission.dot.com> writes:
> [snip]
> > > In practice I have less trouble getting an autoconf using C++ package to
> > > build than I do getting boost to build (in unusual
> > > environments),
> >
> > Sure, I agree. The question is, is that due to broken compilers which
> > can't handle standard C++, or because configuring the build system is
> > difficult? In my experience the former is the greater obstacle. If
> > that's the main problem, no amount of autoconf will help.
>
> On the most difficult platforms (that weren't cross-compilation
> environments, that is) I've dealt with, the biggest
> problem with boost was getting was getting a working boost jam,
> actually.
That should've gotten much easier in the last few months. Rene Rivera
wrote some build scripts for bjam which make the process really
simple. You can look in the CVS or check out the release that's
coming out in the next few days.
> Once I got a working boost jam, boost configured itself well
> enough that I could use the parts I cared about, despite the
> brokeness of the compilers.
It sounds like in fact there was no configuration going on; you were
just using the pre-packaged config headers.
> Mind, I didn't use boost extensively in these projects - only
> for a few, relatively simple things. IOWs, the brokeness of
> some C++ compilers with respect to boost is a problem you and
> the other boost developers have largely already solved (and go
> on solving), in as much as is feasible. (By the way, thank you,
> and congratulations on the quality of your work.)
Thanks! It mostly comes our peer-review process; in other words,
credit goes to all the boost participants for laying their eyes on the
design and code, and being ready to speak up when something's amiss.
> As for broken compilers, autoconf can help in two ways:
>
> (a) It can run tests to determine which workarounds
> are needed. (With the caveats about running such tests in
> cross-compilation environments, which I've already covered.) That,
> however, is in the hands of the maintainers of a project, not its
> users. I'm aware such workarounds can only go so far, but I think
> most of the time that is far enough. I'm also aware that such
> tests are deceptively easy to get almost right, so that they only
> go wrong on hard to obtain platforms. :-)
It works out well if you know which tests to run, and if every bit of
code checks the resulting macros and applies appropriate workarounds.
OTOH, C++ compilers can be broken in _so many_ ways that it's pretty
hard to know which are the right tests ahead of time.
> (b) It can select a hand-tweaked configuration for a pre-tested
> platform.
That's easy enough to do with header files (like we do in Boost),
isn't it?
> I've only got an occasional user's perspective of boost.build, but I
> believe it relies primarily on (b), but is capable of (a) as
> well.
No, we haven't integrated any (a)-like capabilities into Boost.Build
yet. I mean, we do use it for regression testing, but haven't tried
to generate configuration headers from test results.
> Autoconf is primarily aimed towards (a), but it seems to me most
> autoconf-using projects (including
> most autoconf-using C++ projects) which need unusual tests
> (that is, tests that don't come with autoconf ) tend to assume
> certain features go together and do something between (a) and
> (b).
>
> Mind, I'm not saying boost should switch to autoconf (that is, switch
> to using autoconf primarily), or that a new project should
> necessarily prefer autoconf techniques to those used by boost; I'm
> just pointing it out as an alternative, which some projects have
> used successfuly.
No doubt. And as I've said, I'm sure it's a great solution for some
projects.
> > > despite the brain-damage of those tools with respect to C++
> > > needs. The notable exception to that is, as I said before, windows.
> >
> > ...which is an important target for us. BTW, Boost has an autoconf
> > configuration script, but in general the hand-tweaked configuration we
> > supply works better than what you'll get out of autoconf.
>
> Since I've always used the hand-tweaked configuration, I can only say
> I trust you. :-) (I did try the autoconf configuration script in
> two cases, for which there weren't hand-tweaked configurations,
> but it didn't work; those were odd cross-compilation
> environments.)
The problem there is likely that you need to know what to test for in
order to write an autoconf script that will handle any given problem.
> > > Though I must say that when it comes to ugly, autoconf and its friends
> > > take the cake, platter, and table.
BTW: :-)
> > Aesthetics weren't as much of a concern for us as:
> >
> > 1. How many different subsystems/languages one has to learn in order
> > to use it
>
> This issue reminds me of your comment about C++ being a 'whole other
> bag of enchiladas' . Using autoconf with C is often quite easy -
> you use the macros it comes with in more or less the way described
> in the manual, and presto, your C project builds and runs on an
> amazing variety of unices, including some you've never heard
> of. On the other hand, an autoconf-using C++ project needs its own
> tests (some tests can be obtained from other autoconf-using C++
> projects, such as libsigc++, etc, but in general if you aren't
> prepared to write your own tests, you aren't prepared), which
> means learning gnu m4 and sh (If you thought the combo of
> CPP and c++ was fun, you ain't seen nothin' yet, baby.). Then
> there are linker issues... :-). IOWs, using autoconf for C++
> requires learning more subsystems/languages than using it for
> C. Another reason C isn't going away anytime soon. (Autoconf is
> hardly the only tool with this property.)
Hah! I never thought of it that way: autoconf keeps 'C' entrenched as
a portable development tool!
> > 2. How much a developer may be required to install in order to use it
> > (yes, some Windows developers/companies balk at installing Cygwin).
>
> I would say nearly all, and cygwin isn't the only set of unix tools
> such people balk at installing. Thus my classification of windows
> as a platform autoconf doesn't handle. (And while I won't live
> without a unix-style command line if I can help it, I won't
> pretend such balkiness is without reason.)
I never understood it, personally. I get way too much benefit out of
Cygwin to live without it.
> [snip]
> > > I've also thought a C++ build system should be built on top of a
> > > pre-existing portable system, like perl. That's more or less what
> > > autoconf does, but it uses a subset of sh and common unix command
> > > line tools.
> >
> > We wanted to build it on top of Python, like SCons
> > (http://scons.sf.net) does, but unfortunately that fell afoul of #2
> > above for too many people. If you really like to read Perl (<wink>)
> > you might consider cons
> > (http://www.foo.be/docs/tpj/issues/vol3_1/tpj0301-0012.html)
>
> Thank you. I do like perl. I imagine you'll keep an eye on the Python
> possiblity; if Python spreads enough, it may become a good option.
It's already a good option; they're already doing considerably more
than the Perl version does IIUC. Where do you want to build software
that Python hasn't reached yet? You can flame me (off NG) for this,
but Python is a far better platform than Perl for any system of this
scope.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
LLeweLLyn
> LLeweLLyn <llewe...@xmission.dot.com> writes:
[snip]
> > I imagine you'll keep an eye on the Python
> > possiblity; if Python spreads enough, it may become a good option.
>
> It's already a good option; they're already doing considerably more
> than the Perl version does IIUC. Where do you want to build software
> that Python hasn't reached yet?
Then why don't you switch to the python system? I meant, a good option
for re-implementing the boost build system. I assumed it was
already a good option for new projects.
Since you asked, I've never worked on a host platform python hadn't
been ported to, but I've always been in an environment were it was
hard to convince people to install and use a thing they weren't
familar with.
> You can flame me (off NG) for this,
> but Python is a far better platform than Perl for any system of this
> scope.
[snip]
I might not believe you (I tend to be skeptical of any claim that
language A is better than language B, even though I someties spout
such opinions myself), but I won't flame you. I'll wait till I
have some experience with these two (the perl cons and python
scons) tools before comparing them.
David Abrahams
> David Abrahams <da...@boost-consulting.com> writes:
>
> > LLeweLLyn <llewe...@xmission.dot.com> writes:
> [snip]
> > > I imagine you'll keep an eye on the Python
> > > possiblity; if Python spreads enough, it may become a good option.
> >
> > It's already a good option; they're already doing considerably more
> > than the Perl version does IIUC. Where do you want to build software
> > that Python hasn't reached yet?
>
> Then why don't you switch to the python system? I meant, a good option
> for re-implementing the boost build system. I assumed it was
> already a good option for new projects.
Two reasons:
1. I already said this one: having to install Python violated one of
the minimum criteria set forth by the Boost membership.
2. It doesn't satisfy some of our design goals. As good as it is,
it's still a much lower-level system. That said, if #1 weren't an
issue I'd have jumped at the chance to enhance Scons to do the
high-level things we are doing with bjam.
> Since you asked, I've never worked on a host platform python hadn't
> been ported to, but I've always been in an environment were it was
> hard to convince people to install and use a thing they weren't
> familar with.
But every programmer already knows python! It's true, sort of.
> > You can flame me (off NG) for this,
> > but Python is a far better platform than Perl for any system of this
> > scope.
> [snip]
>
> I might not believe you (I tend to be skeptical of any claim that
> language A is better than language B
I'm not saying Python is absolutely better, just that it's better for
reasonably large projects. There are real objective criteria you can
point to.
> even though I someties spout such opinions myself), but I won't
> flame you. I'll wait till I have some experience with these two
> (the perl cons and python scons) tools before comparing them.
Well, the tools are distinct from the languages...
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
|> ka...@gabi-soft.de (James Kanze) writes:
|> > David Abrahams <da...@boost-consulting.com> wrote in message
|> > news:<uu1eeq...@boost-consulting.com>...
|> > > and...@hicox.com (Andrew Hicox) writes:
|> > > > 2) There is nothing at all wrong with makefiles.
|> > > > Makefiles work good!
|> > > Can you write me a makefile that will reliably build and
|> > > test static and shared libraries (not to mention Python
|> > > extensions) on a wide variety of compilers and platforms
|> > > including Linux, Windows, AIX, SGI, OSF, and MacOSX? Can you
|> > > make it possible for developers to write makefiles that will
|> > > be highly likely to work on platforms and compilers they
|> > > can't even test on?
|> > I've done so in the past. I'll admit that I cheated a bit,
|> > however; I require the installation of GNU make first:-).
|> How did you deal with all the differences between platforms?
In the code, or in make? In the code, I have separate directories for
each platform, which contain the platform dependant stuff. In the
makefile, I've not detected any great difference between GNU makes on
different platforms.
In practice, my porting has been restricted to Windows and various
Unix platforms (and I've not had access to Windows recently), so there
is a lot I haven't seen.
|> > Whatever its defects, make is a pseudo-standard. Using
|> > something else is just another hurdle that has to be overcome
|> > when installing the software. (In a lot of places, sysadmins
|> > are hesitant to install things that they don't understand.)
|> It's true, and I can't argue with the value of standards.
|> However, a few of us (see also Scons - scons.sf.net, A-A-P -
|> http://www.a-a-p.org/, and others) think that some standards need to
|> be overturned eventually.
I agree, and I would welcome a (pseudo-)standard replacement for make.
On the other hand, if your goal is widespread use, breaking with the
conventions isn't going to help you get there.
|> > > There are a lot of problems with Makefiles, many of which
|> > > are addressed by Boost's build system. Some of our design
|> > > goals are here:
|> > > http://www.boost.org/tools/build/build_system.htm#design_criteria
|> > Saying that there are problems with makefiles is putting it
|> > mildly.
|> :-)
|> > On the other hand, there is a lot of experience out their in
|> > overcoming those problems.
|> Yes, and some programmer is always repeating the experience of
|> learning how to do that.
|> > > Are you _really_ having trouble finding the Boost documentation?
|> > The documentation on the web site isn't up to date, at least with
|> > regards to shared_ptr.
|> I didn't say it was always perfect, just that it was easy to find.
|> BTW, what specifically is out-of-date? We are about to do another
|> release and I'd like to make sure it's fixed.
Please don't understand that as a criticism. Compared to most
freeware (and an awful lot of commercial software), Boost is way
ahead. Still, I've been unable to build regex for Solaris. (The
problem wasn't with the build system, but I got compiler errors from
the preprocessor.) And above all, I wasn't able to figure out how to
build and install it for several versions (g++ 2.95.2 and 3.2.2, Sun
CC 5.1 32 bit and 64 bit) on a single machine. Had it been based on
makefiles, I might have been able to figure out what was needed, since
I am familiar with the technology. (Had I had more time, I'm sure I
could have figured it out.)
--
James Kanze mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France Tel. +33 1 41 89 80 93
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David Abrahams
> |> How did you deal with all the differences between platforms?
>
> In the code, or in make? In the code, I have separate directories for
> each platform, which contain the platform dependant stuff. In the
> makefile, I've not detected any great difference between GNU makes on
> different platforms.
Not differences in the build tools, but in how compilers are invoked,
what flags control what options, what file extensions to use, whether
you need import libraries for dynamic linking, where you install the
debug build of Python, ...
Those things need to be accounted for by any cross-platform build
system.
> |> It's true, and I can't argue with the value of standards.
> |> However, a few of us (see also Scons - scons.sf.net, A-A-P -
> |> http://www.a-a-p.org/, and others) think that some standards need to
> |> be overturned eventually.
>
> I agree, and I would welcome a (pseudo-)standard replacement for make.
> On the other hand, if your goal is widespread use, breaking with the
> conventions isn't going to help you get there.
That's not our goal, but it doesn't seem to be hurting very much
anyway.
> |> > > Are you _really_ having trouble finding the Boost documentation?
>
> |> > The documentation on the web site isn't up to date, at least with
> |> > regards to shared_ptr.
>
> |> I didn't say it was always perfect, just that it was easy to find.
> |> BTW, what specifically is out-of-date? We are about to do another
> |> release and I'd like to make sure it's fixed.
>
> Please don't understand that as a criticism. Compared to most
> freeware (and an awful lot of commercial software), Boost is way
> ahead. Still, I've been unable to build regex for Solaris. (The
> problem wasn't with the build system, but I got compiler errors from
> the preprocessor.)
Yes, that has nothing to do with documentation or the quality of
Boost code. Nobody ported it to solaris (read: worked around the
Sun compiler bugs).
> And above all, I wasn't able to figure out how to
> build and install it for several versions (g++ 2.95.2 and 3.2.2
You never posted a question to the Boost list. What was the problem?
> Sun CC 5.1 32 bit and 64 bit) on a single machine.
I would be surprised if anyone can compile it with Sun CC 5.1.
> Had it been based on makefiles, I might have been able to figure out
> what was needed, since I am familiar with the technology.
It has nothing to do with the build system; it's about the compiler.
> (Had I had more time, I'm sure I could have figured it out.)
And, in sum, that's a very elaborate way of not answering the
question. What documentation specifically is out-of-date?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> James Kanze <ka...@alex.gabi-soft.fr> writes:
> > |> How did you deal with all the differences between platforms?
> > In the code, or in make? In the code, I have separate directories
> > for each platform, which contain the platform dependant stuff. In
> > the makefile, I've not detected any great difference between GNU
> > makes on different platforms.
> Not differences in the build tools, but in how compilers are invoked,
> what flags control what options, what file extensions to use, whether
> you need import libraries for dynamic linking, where you install the
> debug build of Python, ...
The same way I do for my C++ code. The makefile's include another
makefile, in the <arch>/<syst>/<comp> sub-directory, with the necessary
definitions.
I am still struggling to get a web site here. Once I get one, it will
have some sample code. It is much easier to understand how I solved the
problems by looking at that than by my explaining it.
And of course, it is only one solution, not the only one, nor
necessarily the best. But it works for me.
> Those things need to be accounted for by any cross-platform build
> system.
I know.
> > |> It's true, and I can't argue with the value of standards.
> > |> However, a few of us (see also Scons - scons.sf.net, A-A-P -
> > |> http://www.a-a-p.org/, and others) think that some standards
> > |> need to be overturned eventually.
> > I agree, and I would welcome a (pseudo-)standard replacement for
> > make. On the other hand, if your goal is widespread use, breaking
> > with the conventions isn't going to help you get there.
> That's not our goal, but it doesn't seem to be hurting very much
> anyway.
Well, it means that I can't shift to boost::regex for the moment.
Because I'm unable to get it to build for all of my environments, and
I'm unable to figure out what I'm doing wrong, because I'm unfamiliar
with the tools used. For that matter, I'm not sure how to go about
maintaining several environments from the same source tree, although I'm
sure it can be done.
> > |> > > Are you _really_ having trouble finding the Boost
> > |> > > documentation?
> > |> > The documentation on the web site isn't up to date, at least
> > |> > with regards to shared_ptr.
> > |> I didn't say it was always perfect, just that it was easy to
> > |> find. BTW, what specifically is out-of-date? We are about to
> > |> do another release and I'd like to make sure it's fixed.
> > Please don't understand that as a criticism. Compared to most
> > freeware (and an awful lot of commercial software), Boost is way
> > ahead. Still, I've been unable to build regex for Solaris. (The
> > problem wasn't with the build system, but I got compiler errors
> > from the preprocessor.)
> Yes, that has nothing to do with documentation or the quality of Boost
> code. Nobody ported it to solaris (read: worked around the Sun
> compiler bugs).
That has nothing to do with the documentation or the quality of the
code. However, if only tools I was familiar with were used, it would be
easier for me to find the problem. I'm pretty sure it isn't with the
build system, but rather with the various #ifdef's.
> > And above all, I wasn't able to figure out how to build and install
> > it for several versions (g++ 2.95.2 and 3.2.2
> You never posted a question to the Boost list. What was the problem?
I can't get to the Boost list at present. I can't get to much of
anything at present -- my connectivity is at a minimum. The problem,
however, is that I don't have the slightest idea of where to start. (To
be honest, I've not had much time to address the problem. I suspect
that this is documented somewhere, and that I simply haven't had the
time to find it.)
> > Sun CC 5.1 32 bit and 64 bit) on a single machine.
> I would be surprised if anyone can compile it with Sun CC 5.1.
Well, it is one of the platforms I have to support. Along with g++
2.95.2 and VC++ 6.0.
As far as I can tell, these are widespread platforms, even if they
aren't the latest version (for any of them). For the moment, I'm stuck
with my own non-templated regular expressions. And this is one case
where the Boost code is definitly superior to what I have written.
> > Had it been based on makefiles, I might have been able to figure
> > out what was needed, since I am familiar with the technology.
> It has nothing to do with the build system; it's about the compiler.
I know what the compiler needs. I don't know where, in the build
system, to specify it.
> > (Had I had more time, I'm sure I could have figured it out.)
> And, in sum, that's a very elaborate way of not answering the
> question. What documentation specifically is out-of-date?
I think we're confusing at least three separate issues:
- The documentation for boost::shared_ptr is definitly out of date.
It doesn't mention counted_base, for example, or the problems of
exporting a this pointer to something that wants a shared_ptr.
- I'm totally unfamiliar with the build system used. I don't really
know where to find adequate documentation about it, and I don't have
enough time to learn a new tool just to install Boost. I need to
maintain several versions based on the same source tree.
- I could not get regex to compile with Sun CC 5.1, even using the
makefile. The compilation didn't get past the pre-processor stage,
and I was immediately lost in the wealth of #ifdef. If Boost
doesn't support Sun CC 5.1, it is worthless to me, since this is a
compiler I have to support.
--
James Kanze GABI Software mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16
Hillel Y. Sims
news:d6651fb6.03031...@posting.google.com...
>
> Well, it means that I can't shift to boost::regex for the
moment.
> Because I'm unable to get it to build for all of my
environments, and
> I'm unable to figure out what I'm doing wrong, because I'm
unfamiliar
> with the tools used. For that matter, I'm not sure how to go
about
> maintaining several environments from the same source tree,
although I'm
> sure it can be done.
That's too bad, because it's really *awesome*. I got it to build
on our crazy environment (VMS + proprietary inhouse make system)
and it was fairly little trouble to port. Due to our custom
environment, I didn't even attempt to use any of the boost build
stuff, I just built a custom local build script based on the cpp
files provided. Fortunately, our compiler is fairly compliant
(EDG based), except that we don't have any of the <cname>
headers. The biggest issues for me really were that, because we
do not use automatic template instantiation in our environment,
I had to figure out and add all the various manual
instantiations that were needed, and then I also had to manually
export all the various functions for successful shared library
functionality. It took about 2 days total to get everything
working, but it was totally worth the effort, imo. (Well I
already had the basic boost_config stuff working before porting
this one, but that's pretty easy to set up too.) If nothing
else, the posix compatibility functions have proved to be
something like 20% faster than this old gnu regex library we
had; and the native C++ boost::regex stuff is just much better
still. I'm really hard-pressed to need to turn to perl anymore
for text parsing stuff..
(Another big issue for me in porting boost libs is having to
rename all the headers and #includes because we have a flat
directory structure in our development environment.. don't
ask -- this isn't even inherent to VMS, just our custom
environment.. anyhow I've since used boost::regex to write a
'perl script' in C++ which automates much of this grunt work for
porting other boost toolkits to our environment.. :-)
(I almost got the spirit library working recently, except I ran
into one compile error which I couldn't figure out at all for
the life of me -- I got lost after about 5 nested levels of
typedefs, though it does seem to disappear under a newer version
of the compiler, but that has problems of its own.. -- and then
I realized that there is a large deal of implicit reliance on
automatic template instantiation in there (all the .ipp files),
it might be rather painful to try to use with manual
instantiation only..)
hys
--
(c) 2003 Hillel Y. Sims
hsims AT factset.com
David Abrahams
> David Abrahams <da...@boost-consulting.com> wrote in message
> news:<uu1e1a...@boost-consulting.com>...
>> James Kanze <ka...@alex.gabi-soft.fr> writes:
>
>> > |> How did you deal with all the differences between platforms?
>
>> > In the code, or in make? In the code, I have separate directories
>> > for each platform, which contain the platform dependant stuff. In
>> > the makefile, I've not detected any great difference between GNU
>> > makes on different platforms.
>
>> Not differences in the build tools, but in how compilers are invoked,
>> what flags control what options, what file extensions to use, whether
>> you need import libraries for dynamic linking, where you install the
>> debug build of Python, ...
>
> The same way I do for my C++ code. The makefile's include another
> makefile, in the <arch>/<syst>/<comp> sub-directory, with the necessary
> definitions.
>
> I am still struggling to get a web site here. Once I get one, it will
> have some sample code. It is much easier to understand how I solved the
> problems by looking at that than by my explaining it.
>
> And of course, it is only one solution, not the only one, nor
> necessarily the best. But it works for me.
Sure. The problems with that are:
1. It works for you (but not for everybody else). If I want the same
effect, I have to repeat the work you did.
2. (related) your system is only going to be as general as _you_ need
it to be. A comprehensive build system is a nontrivial effort, so
even if you give me your system, I may need to substantially
redesign it to handle build situations you didn't envision.
3. Extensibility and generality are hampered by the limitations of
the make language
4. "Recursive make considered harmful" (don't get me started)
>> > I agree, and I would welcome a (pseudo-)standard replacement for
>> > make. On the other hand, if your goal is widespread use, breaking
>> > with the conventions isn't going to help you get there.
>
>> That's not our goal, but it doesn't seem to be hurting very much
>> anyway.
>
> Well, it means that I can't shift to boost::regex for the moment.
> Because I'm unable to get it to build for all of my environments,
> and I'm unable to figure out what I'm doing wrong, because I'm
> unfamiliar with the tools used.
This is silly. It's easy enough to get bjam to dump the build
commands it's using (just add -d+2 as the first option). You could
just copy them into a shell script or makefile or whatever you're
comfortable with and tweak them until you think you have all the
build configuration issues covered.
> For that matter, I'm not sure how to go about maintaining several
> environments from the same source tree, although I'm sure it can be
> done.
I don't know what you mean by "environments". If you mean, "building
for several compilers", you don't need to do anything special; the
build system segregates the products of each one. If you mean,
"building on several platforms", you can control where the tree of
built products goes by setting ALL_LOCATE_TARGET. It's all in the
docs.
BTW, AFAIK there's no standard way to do this with make either.
Wouldn't you need to read some docs about whatever makefiles you were
using to figure it out?
>> > |> > > Are you _really_ having trouble finding the Boost
>> > |> > > documentation?
>
>> > |> > The documentation on the web site isn't up to date, at least
>> > |> > with regards to shared_ptr.
>
>> > |> I didn't say it was always perfect, just that it was easy to
>> > |> find. BTW, what specifically is out-of-date? We are about to
>> > |> do another release and I'd like to make sure it's fixed.
>
>> > Please don't understand that as a criticism. Compared to most
>> > freeware (and an awful lot of commercial software), Boost is way
>> > ahead. Still, I've been unable to build regex for Solaris. (The
>> > problem wasn't with the build system, but I got compiler errors
>> > from the preprocessor.)
>
>> Yes, that has nothing to do with documentation or the quality of Boost
>> code. Nobody ported it to solaris (read: worked around the Sun
>> compiler bugs).
>
> That has nothing to do with the documentation or the quality of the
> code. However, if only tools I was familiar with were used, it would be
> easier for me to find the problem. I'm pretty sure it isn't with the
> build system, but rather with the various #ifdef's.
Perhaps.
>> > And above all, I wasn't able to figure out how to build and install
>> > it for several versions (g++ 2.95.2 and 3.2.2
>
>> You never posted a question to the Boost list. What was the problem?
>
> I can't get to the Boost list at present. I can't get to much of
> anything at present -- my connectivity is at a minimum. The problem,
> however, is that I don't have the slightest idea of where to start. (To
> be honest, I've not had much time to address the problem. I suspect
> that this is documented somewhere, and that I simply haven't had the
> time to find it.)
Building is easy. Installation is up to you. We haven't got a
standard install location for our libraries or headers. It's just a
problem that we haven't had time to address across all platforms.
>> > Sun CC 5.1 32 bit and 64 bit) on a single machine.
>
>> I would be surprised if anyone can compile it with Sun CC 5.1.
>
> Well, it is one of the platforms I have to support. Along with g++
> 2.95.2 and VC++ 6.0.
Those other two work with most of Boost.
> As far as I can tell, these are widespread platforms, even if they
> aren't the latest version (for any of them).
Yes they are.
> For the moment, I'm stuck with my own non-templated regular
> expressions. And this is one case where the Boost code is definitly
> superior to what I have written.
It's a shame.
>> > Had it been based on makefiles, I might have been able to figure
>> > out what was needed, since I am familiar with the technology.
>
>> It has nothing to do with the build system; it's about the compiler.
>
> I know what the compiler needs.
Really? We'd love to know; it would be great to support Sun CC.
> I don't know where, in the build system, to specify it.
I don't think there is a place in the build system to specify it,
whatever it is. You generally need to patch the compiler config file
and/or the regex sources to work around compiler bugs.
>> > (Had I had more time, I'm sure I could have figured it out.)
>
>> And, in sum, that's a very elaborate way of not answering the
>> question. What documentation specifically is out-of-date?
>
> I think we're confusing at least three separate issues:
(the reason being that I asked a direct question about outdated
documentation and you answered about other things)
> - The documentation for boost::shared_ptr is definitly out of date.
> It doesn't mention counted_base, for example
That's because it's an implementation detail. It was available on an
experimental basis during the last release cycle but a better solution
was found and it's back in the boost::detail namespace.
> or the problems of exporting a this pointer to something that
> wants a shared_ptr.
I don't know what that means exactly, but I think we have that problem
covered in this document:
(1.30.0 will be out within a day or so; this is in the release).
> - I'm totally unfamiliar with the build system used. I don't really
> know where to find adequate documentation about it
Starts at http://www.boost.org/tools/build. The instructions for
basic usage work pretty well.
But we know that the documentation for this version of the build
system is really not up-to-snuff. The problem is that we're nearly
finished with the next version (a complete rewrite) and we don't
really want to invest a lot in documenting something that will soon be
obsolete.
> and I don't have enough time to learn a new tool just to install
> Boost.
Understandable. In the temporary absence of really easy instructions
to deal with the deeper issues the best we can offer is handholding
and personal attention (which is often more work for us but better for
users anyway).
> I need to maintain several versions based on the same source
> tree.
Versions of what?
> - I could not get regex to compile with Sun CC 5.1, even using the
> makefile. The compilation didn't get past the pre-processor stage,
> and I was immediately lost in the wealth of #ifdef.
I'll ask again: was this with 1.29.0, the 1.30.0 beta, or some CVS
version? We have accounted for some Sun CC preprocessor bugs since
1.29.0 (by treating it the same way we deal with Borland's bugs).
> If Boost doesn't support Sun CC 5.1, it is worthless to me,
> since this is a compiler I have to support.
It probably depends on what you're willing to invest. A rich gold
mine is worthless unless you're willing to do a little shoveling. On
the other hand, if you started running our tests against Sun CC,
uploading regression results, and notifying us of new failures, I bet
it would start to look like Boost supported your compiler pretty
quickly... especially if, as you say, you "know what the compiler
needs". We don't - the compiler bugs are often too impenetrable -
which is why my last attempt to get most of Boost working on Sun was a
failure.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David Abrahams
> ... It took about 2 days total to get everything
> working, but it was totally worth the effort, imo. (Well I
> already had the basic boost_config stuff working before porting
> this one, but that's pretty easy to set up too.)
Cool! Care to post a WIKI page about your experience?
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BOOST_WIKI
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]