Which libraries in Boost are mature enough to be used in real applications?

[Guch Wu]

Boost has many terrific libraries.
But I want to know whether they are ready for using in real projects.
Which of them are mature enough, or just only in progress?

[Ivan Vecerina]

"Guch Wu" <gu****@gmail.com> wrote in message
news:11*********************@i40g2000cwc.googlegro ups.com...
: Boost has many terrific libraries.
: But I want to know whether they are ready for using in real projects.
: Which of them are mature enough, or just only in progress?

Well, the most mature ones have already been adopted for inclusion
into tr1/tr2 or the next C++ standard ;)

To make it into boost, most libraries will have attained a reasonable
level of maturity. All of them have undergone a peer review.
All of them should be at least as good as in-house libraries
of most companies...
But of course, some have a more generally useful scope than others.
Some are undergoing revisions, etc. But the same would happen with
the standard C++ library if it were not an ISO standard (I'm pretty
sure that the design of std::string would have been revised by now).

I think that you are approaching the problem from the wrong end:
you shouldn't analyze the solution before identifying the problem.

First look at the collection of available libraries, and identify
those that could be useful to you. For those libraries, see if
they appear to fit your problem domain and can save you time.

If you want to study boost only to see what's ahead, start with
the libraries that have been included in tr1, or proposed for tr2:
http://www.open-std.org/jtc1/sc22/wg...2005/n1745.pdf
http://www.open-std.org/jtc1/sc22/wg...005/n1810.html
hth -Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[Guch Wu]

Thanks!
I want to use lambda and uBLAS. But I don't know how to use them till
now.
I think there needs more samples in Boost documents.

[Ivan Vecerina]

"Guch Wu" <gu****@gmail.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...
: Thanks!
: I want to use lambda and uBLAS. But I don't know how to use them till
: now.
: I think there needs more samples in Boost documents.

Please consider joining the boost mailing lists:
http://www.boost.org/more/mailing_lists.htm

bu yong kerh chee -Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[Tom Widmer]

Ivan Vecerina wrote:

"Guch Wu" <gu****@gmail.com> wrote in message
news:11*********************@i40g2000cwc.googlegro ups.com...
: Boost has many terrific libraries.
: But I want to know whether they are ready for using in real projects.
: Which of them are mature enough, or just only in progress? First look at the collection of available libraries, and identify
those that could be useful to you. For those libraries, see if
they appear to fit your problem domain and can save you time.

The majority of boost libraries aren't domain specific, but rather
extensions to the standard library that are of general utility to pretty
much any C++ program. Do you use analyse your problem domain before
deciding which parts of the standard library to use?

Tom

[Ivan Vecerina]

"Tom Widmer" <to********@hotmail.com> wrote in message
news:e3**********@emma.aioe.org...
: Ivan Vecerina wrote:
: > "Guch Wu" <gu****@gmail.com> wrote in message
: > news:11*********************@i40g2000cwc.googlegro ups.com...
: > : Boost has many terrific libraries.
: > : But I want to know whether they are ready for using in real
projects.
: > : Which of them are mature enough, or just only in progress?
:
: > First look at the collection of available libraries, and identify
: > those that could be useful to you. For those libraries, see if
: > they appear to fit your problem domain and can save you time.
:
: The majority of boost libraries aren't domain specific, but rather
: extensions to the standard library that are of general utility to pretty
: much any C++ program.

I would rather think that a majority is domain-specific,
but let's save ourselves the effort of making a count.

: Do you use analyse your problem domain before
: deciding which parts of the standard library to use?

Yes. Of course.

Most of my programs have not needed to use <bitset>, <valarray>,
<locale>, <complex>, <queue>, <strstream>, <cassert>, <csignal>,
<csetjmp>, <clocale>, <ctime>, <numeric>.....
Most of my implementation files include only a subset of the rest.

And the broader the scope of the libraries,
the pickier one needs to be.

Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[Roland Pibinger]

On 5 May 2006 00:10:47 -0700, "Guch Wu" <gu****@gmail.com> wrote:

Boost has many terrific libraries.
But I want to know whether they are ready for using in real projects.
Which of them are mature enough, or just only in progress?

I wouldn't use Boost libraries (actually Boost is one monolitic
library) in real-world projects because they clearly don't pass
McConnell's software Litmus Test:
"When programming is seen predominately as an attempt to manage
complexity, the litmus test for any design or implementation approach
becomes clear: Does the approach increase or decrease overall system
complexity? If a design seems simple and yet accounts for all the
possible cases, it is a good design. If an implementation results in
code that is easy to read and is more simple than clever, it is a good
implementation."
http://www.stevemcconnell.com/ieeesoftware/bp06.htm

Best wishes,
Roland Pibinger

[Joe Van Dyk]

Roland Pibinger wrote:

On 5 May 2006 00:10:47 -0700, "Guch Wu" <gu****@gmail.com> wrote:

Boost has many terrific libraries.
But I want to know whether they are ready for using in real projects.
Which of them are mature enough, or just only in progress?

I wouldn't use Boost libraries (actually Boost is one monolitic
library) in real-world projects because they clearly don't pass
McConnell's software Litmus Test:
"When programming is seen predominately as an attempt to manage
complexity, the litmus test for any design or implementation approach
becomes clear: Does the approach increase or decrease overall system
complexity? If a design seems simple and yet accounts for all the
possible cases, it is a good design. If an implementation results in
code that is easy to read and is more simple than clever, it is a good
implementation."
http://www.stevemcconnell.com/ieeesoftware/bp06.htm

Best wishes,
Roland Pibinger

Hm. Using boost's smart pointers, lexical casts, and unit testing
programs seem to substancially reduce the complexity of my C++ programs.

Joe

[Mirek Fidler]

Roland Pibinger wrote:

On 5 May 2006 00:10:47 -0700, "Guch Wu" <gu****@gmail.com> wrote:

Boost has many terrific libraries.
But I want to know whether they are ready for using in real projects.
Which of them are mature enough, or just only in progress?

I wouldn't use Boost libraries (actually Boost is one monolitic
library) in real-world projects because they clearly don't pass
McConnell's software Litmus Test:
"When programming is seen predominately as an attempt to manage
complexity, the litmus test for any design or implementation approach
becomes clear: Does the approach increase or decrease overall system
complexity? If a design seems simple and yet accounts for all the
possible cases, it is a good design. If an implementation results in
code that is easy to read and is more simple than clever, it is a good
implementation."
http://www.stevemcconnell.com/ieeesoftware/bp06.htm

Best wishes,
Roland Pibinger

I am not sure you can win this debate this way... :)

The only way how to do this is to _demonstrate_ superior approach. Bring
some facts.... (and even then it will be very hard, believe me ;)

Mirek

[Roland Pibinger]

On Fri, 05 May 2006 22:42:58 +0200, Mirek Fidler <cx*@volny.cz> wrote:

I am not sure you can win this debate this way... :)

The only way how to do this is to _demonstrate_ superior approach. Bring
some facts.... (and even then it will be very hard, believe me ;)

A superior approach in what respect and for which purpose? Superior in
usability, simplicity and convenience for real-world users? Superior
in exploiting the most complex template meta-programming techniques?
There is nothing wrong with Boost when it is considered what it is: an
experiment in template programming. The (implicit) Boost motto is
"Look what we can do with templates!". The criteria for real-world
libraries and applications point in the opposite direction. For the
latter the goal is to provide large functionality with small,
convenient and safe interfaces. Anyone who claims that Boost is made
for real-world users either doesn't know Boost or the real world.
Probably both.

Best regards,
Roland Pibinger

----------------------
"From early on, we wanted a product that would seem so natural and so
inevitable and so simple, you almost wouldn't think of it as having
been designed"
Jonathan Ive, designer of the iPod

[werasm]

Roland Pibinger wrote:

On Fri, 05 May 2006 22:42:58 +0200, Mirek Fidler <cx*@volny.cz> wrote:

I am not sure you can win this debate this way... :)

The only way how to do this is to _demonstrate_ superior approach. Bring
some facts.... (and even then it will be very hard, believe me ;)
A superior approach in what respect and for which purpose? Superior in
usability, simplicity and convenience for real-world users? Superior
in exploiting the most complex template meta-programming techniques?
There is nothing wrong with Boost when it is considered what it is: an
experiment in template programming. The (implicit) Boost motto is
"Look what we can do with templates!". The criteria for real-world
libraries and applications point in the opposite direction. For the
latter the goal is to provide large functionality with small,
convenient and safe interfaces. Anyone who claims that Boost is made
for real-world users either doesn't know Boost or the real world.
Probably both.

I live in the real-world, developing software for real people. Up to
date I've found boosts interface ("if you use documentation") very
clean. If you need to write software to meet all needs, complexity is
often necessary. As long as it is not complex to use, and most often it
is not.

I've been able to use the following classes in the boost lib
successfully without any trouble whatsoever.

All the smart pointers (shared, weak, scoped and their array variants).
I find the array variants necessary and superior to vector in some
situations. The reason for this is that is slotted in with certain code
with less change. vector required interface changes whilst I could
manage resources at scope level without interface changes.

Amongst others I've seen handy uses for optional, type_traits, ref,
utils - especially base-from-member, array and others. The only reason
why I haven't used it even more often, is that I've only started using
it recently. Also, having implemented libs that others used, I come to
realise that having the convenience of templates, and especially
specialisation some things would be far more difficult to implement
(generically) without templates - even impossible. The combination of
run-time and compile-time polymorphism is very powerful. This said, as
long as the code is well tested and reviewed (which I'm currently
assuming is the case with boost). I, BTW, have made mistakes in the
past - like uninitialised vars, that boost has help me find with their
defensive style of programming.

Sad that following how they implement their magic is quite hard due to
yes, complexity. But complexity in implementation is orthogonal to
complexity in interface. The former being necessary in some
circumstances, the latter preferably as simple as possible - that said,
the latter should only be simple enough of domain users to understand.
If I write a lib for use by mathematicians, I can't expect chemists to
know how to use it, as they are not necessarily familiar with the
domain concepts.

Regards,

Werner

Best regards,
Roland Pibinger

----------------------
"From early on, we wanted a product that would seem so natural and so
inevitable and so simple, you almost wouldn't think of it as having
been designed"
Jonathan Ive, designer of the iPod

[andy]

Roland Pibinger wrote:

A superior approach in what respect and for which purpose? Superior in
usability, simplicity and convenience for real-world users?
Yes!
Superior
in exploiting the most complex template meta-programming techniques?
and yes!
There is nothing wrong with Boost when it is considered what it is: an
experiment in template programming. The (implicit) Boost motto is
"Look what we can do with templates!". The criteria for real-world
libraries and applications point in the opposite direction. For the
latter the goal is to provide large functionality with small,
convenient and safe interfaces. Anyone who claims that Boost is made
for real-world users either doesn't know Boost or the real world.
Probably both.

It seems to me that you havent taken a very deep look into what goes on
at boost. There is a huge variety of all kinds of libraries there.
Some make very advanced use of templates. Other dont. Some other areas
of work include concurrent programming, common means of accessing file
systems, common mechanism for serialisation, interprocess
communication, networking, etc, etc etc. That is only a small selection
from many libarries. There is also a wide range of discussion about the
C++ language and where it is heading.

For instance check this out:

http://www.osl.iu.edu/~dgregor/ConceptGCC/

Some of the ground work for conceptgcc had roots in boost ConceptCheck
lib AFAIK. Boost is AFAICS really good for C++. Its a R & D center. In
fact recent discussion on comp.lang.c is asking why they can have an
equivalent R & D center for that language.

Sorry to say this but you just do sound like you are being a miserable
old git!

regards
Andy Little

[andy]

BTW

Check it out yourself:

http://www.boost.org

regards
Andy Little

[andy]

Guch Wu wrote:

Boost has many terrific libraries.
But I want to know whether they are ready for using in real projects.
Which of them are mature enough, or just only in progress?

You might want to check out the following links regarding boost

http://www.boost.org/more/background.html
http://www.boost.org/doc/html/who_s_using_boost_.html

regards
Andy Little

[Roland Pibinger]

On 6 May 2006 00:36:39 -0700, "werasm" <w_*****@telkomsa.net> wrote:

Sad that following how they implement their magic is quite hard due to
yes, complexity. But complexity in implementation is orthogonal to
complexity in interface. The former being necessary in some
circumstances, the latter preferably as simple as possible - that said,
the latter should only be simple enough of domain users to understand.

Templates provide no separation between interface and implementation.
The template interface is the template implementation (and vice
versa). A template-only (almost) library cannot hide the "complexity
in implementation". This is an insurmountable problem for all template
libraries, not only Boost.

Best regards,
Roland Pibinger

[loufoque]

Roland Pibinger wrote :

I wouldn't use Boost libraries (actually Boost is one monolitic
library) in real-world projects because they clearly don't pass
McConnell's software Litmus Test:
"When programming is seen predominately as an attempt to manage
complexity, the litmus test for any design or implementation approach
becomes clear: Does the approach increase or decrease overall system
complexity? If a design seems simple and yet accounts for all the
possible cases, it is a good design. If an implementation results in
code that is easy to read and is more simple than clever, it is a good
implementation."

Maybe you should stop using the C++ standard library then.
Because most of the C++ standard library proposals come from boost.

Boost takes what already exists in the standard library and extends it
or improve it.
Boost is like the development center of the C++ standard library. It's
also where innovation in C++ take place.

And C++ without the standard library is just C with classes, unless you
write your own stdlib clone.

[Roland Pibinger]

On Sat, 06 May 2006 13:36:59 +0200, loufoque
<lo******@remove.gmail.com> wrote:

Maybe you should stop using the C++ standard library then.
The Standard library has its own share of problems but that's another
question.
Because most of the C++ standard library proposals come from boost.
Well, some Boosters are members of the Standard committee ... ;-)
Boost takes what already exists in the standard library and extends it
or improve it.
That was the original goal years ago. Today Boost certainly is not an
extension of the C++ Standard library.
Boost is like the development center of the C++ standard library. It's
also where innovation in C++ take place.
Innovation in what respect? Innovation in template programming?
Certainly. But I'm talking about usability. Again, Boost is not
targeted at real-world programmers. The libraries would look different
if it were.
And C++ without the standard library is just C with classes, unless you
write your own stdlib clone.

C++ is a 'Multiparadigm Language'. The design space for libraries is
much larger than what is currently covered by Boost and the Standard
library.

Best wishes,
Roland Pibinger

[Phlip]

Roland Pibinger wrote:

Innovation in what respect? Innovation in template programming?
Certainly. But I'm talking about usability. Again, Boost is not
targeted at real-world programmers. The libraries would look different
if it were.

Is Boost a meritocracy?

If I were a bum with no credentials, and I write a better library than a
current Boost library, could I submit it? Would it replace the current
version?

(Note that several Boost libraries have been replaced, and several have
alternate implementations...)

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[wij]

an**@servocomm.freeserve.co.uk 寫�：

...
It seems to me that you havent taken a very deep look into what goes on
at boost. There is a huge variety of all kinds of libraries there.
Some make very advanced use of templates. Other dont. Some other areas
of work include concurrent programming, common means of accessing file
systems, common mechanism for serialisation, interprocess
communication, networking, etc, etc etc. That is only a small selection
from many libarries. There is also a wide range of discussion about the
C++ language and where it is heading.
...

I have noticed boost library for two years. But strange to say, I
still don't make up my mind looking into it deeper for fear that my
effort won't be paid back. There are many programming technics to
learn from, though.

IJ. Wang

[Jerry Coffin]

In article <44*************@news.utanet.at>, rpbg123
@yahoo.com says...

[ ... ]

C++ is a 'Multiparadigm Language'. The design space for libraries is
much larger than what is currently covered by Boost and the Standard
library.

This is more or less inevitable. Boost has much the same
problem as almost any similar effort: virtually
everything is contributed by volunteers, and demand for
good code always exceeds supply.

Since it is (at least primarily) a volunteer effort, it's
no surprise that the code is aimed primarily at the
things that interest those volunteers the most. Whether
that's "real world" or not is mostly a question of how
closely what you work with coincides with what interests
them. Apparently, for you right now, there's little
intersection -- but I think it's safe to say that what
you work with isn't the universal measure of the whole of
the "real world"...

--
Later,
Jerry.

The universe is a figment of its own imagination.

[werasm]

Roland Pibinger wrote:

On 6 May 2006 00:36:39 -0700, "werasm" <w_*****@telkomsa.net> wrote:

Sad that following how they implement their magic is quite hard due to
yes, complexity. But complexity in implementation is orthogonal to
complexity in interface. The former being necessary in some
circumstances, the latter preferably as simple as possible - that said,
the latter should only be simple enough of domain users to understand.

Templates provide no separation between interface and implementation.
The template interface is the template implementation (and vice
versa). A template-only (almost) library cannot hide the "complexity
in implementation". This is an insurmountable problem for all template
libraries, not only Boost.

I don't entirely agree with this. Whilst templates don't promote
compilation dependency, interface is not determined by compilation
dependency, but by what is publicly usable. True that there is no
physical seperation between interface and implementation (but interface
still exists and is concise). Apart from that, seperation can often be
established by using combination of dynamic and static polymorpishm.
The command pattern and Alexandrescu's functors are example of this.

Furthemore, most of the idioms implemented in boost are so well
established, with narrow concise interfaces that never change (e.g.
they promote single responsibility), therefore the strong dependency is
irrelevant, this being the case for the STL as well. If an interface is
cast in concrete, it no longer requires to be seperated from
implementation. Many idioms in boost are so narrow that they are cast
in concrete.

Kind regards,

Werner

[werasm]

Phlip wrote:

Roland Pibinger wrote:

Innovation in what respect? Innovation in template programming?
Certainly. But I'm talking about usability. Again, Boost is not
targeted at real-world programmers. The libraries would look different
if it were.
Is Boost a meritocracy?

If I were a bum with no credentials, and I write a better library than a
current Boost library, could I submit it? Would it replace the current
version?

If it would pass the peer reviews, I think you might stand a chance.

Some bums become that because the current world they live in are too
shortcited to perceive their intelligence. Their work are sometimes
acknowledged by following generations. Other bums are simply lazy, and
others are depressed.

If you are the first kind, then some boosters may just acknowledge
that. I don't think all boosters have credentials. I may be wrong but
that is the impression I get (POP).
(Note that several Boost libraries have been replaced, and several have
alternate implementations...)

Yes, inhouse libs too, STD too, MS libs too. Java libs and C# libs too
(deprecated). Sadly, less C libs - or maybe I'm lacking experience
their, because their are alternatives for me.

Retrospect is a wonderful thing. Why did they not just start out with
the ideal lib/language :-). Why was assembler ever required, and C, and
C++, and all those languages that have not yet been borne from
retrospect.

BTW. I hope the boosters are less short cited than to consider
credentials. Original creativity and genius does not necessarily sprout
from credentials, but I gather you know this already.

Kind regards,

W

[Mirek Fidler]

Roland Pibinger wrote:

On Fri, 05 May 2006 22:42:58 +0200, Mirek Fidler <cx*@volny.cz> wrote:

I am not sure you can win this debate this way... :)

The only way how to do this is to _demonstrate_ superior approach. Bring
some facts.... (and even then it will be very hard, believe me ;)

A superior approach in what respect and for which purpose? Superior in
usability, simplicity and convenience for real-world users? Superior
in exploiting the most complex template meta-programming techniques?
There is nothing wrong with Boost when it is considered what it is: an
experiment in template programming.

Well, I think you have not understood my post. Your posts in this area
seem to "disagree", but not to show any alternative...

The (implicit) Boost motto is
"Look what we can do with templates!".
Well, I would rather say "Look how we can enhance STL" :)
convenient and safe interfaces. Anyone who claims that Boost is made
for real-world users either doesn't know Boost or the real world.
Probably both.

This will just bring a dozens of posts about usability of Boost in real
world applications (and how smart pointers allow you to store stuff in
containers ;)

Mirek

[Mirek Fidler]

>> possible cases, it is a good design. If an implementation results in

code that is easy to read and is more simple than clever, it is a good
implementation."

Maybe you should stop using the C++ standard library then.

Actually, a very good idea ;)
Boost takes what already exists in the standard library and extends it
or improve it.

Yes, that is the problem....

Mirek

[Roland Pibinger]

On Sun, 07 May 2006 21:25:45 +0200, Mirek Fidler <cx*@volny.cz> wrote:

Well, I think you have not understood my post. Your posts in this area
seem to "disagree", but not to show any alternative...

Probably I still don't understand your question. You mean heavy
templatezation and template meta-programming combined with creative
operator overloading is the only way to design C++ libraries? I beg to
differ. If you want names of C++ libraries targeted at the real world
programmers then you must first take a look at commercial offerings.
I've worked with libraries from Rogue Wave in the late nineties (then
known as Tools.h and DbTools.h) and found them convenient and well
designed. Probably also the libraries from Qt fall into the same
category (albeit I havn't used them). If you search the internet (or
eg. www.koders.com) you find many (parts of) fundation libraries,
mostly as part of some project or as one-man show.

Best regards,
Roland Pibinger

[Mirek Fidler]

Roland Pibinger wrote:

On Sun, 07 May 2006 21:25:45 +0200, Mirek Fidler <cx*@volny.cz> wrote:

Well, I think you have not understood my post. Your posts in this area
seem to "disagree", but not to show any alternative...

Probably I still don't understand your question

That was not question, but a hint...
differ. If you want names of C++ libraries targeted at the real world
programmers then you must first take a look at commercial offerings.
I've worked with libraries from Rogue Wave in the late nineties (then
known as Tools.h and DbTools.h) and found them convenient and well
designed.
Actually, this is what I was suggesting... To show some alternative...
Or at least to point to unnecessary problems associated with STL which
most C++ gurus seems to silently ignore (like the copying obsession ;)
Probably also the libraries from Qt fall into the same
category (albeit I havn't used them).
Yes, actually, it is quite funny that in 4.x version they completely
abandoned STL iterator syntax ;)
If you search the internet (or
eg. www.koders.com) you find many (parts of) fundation libraries,
mostly as part of some project or as one-man show.

A good hint. We have not posted to www.koders.com yet ;)

Mirek

[loufoque]

Mirek Fidler wrote :

This will just bring a dozens of posts about usability of Boost in real
world applications (and how smart pointers allow you to store stuff in
containers ;)

It seems from what I've read that the most used library of boost is the
smart pointers library.
Yet, I rarely saw cases where it's actually needed.

The biggest use of pointers is for polymorphism, and for that you have
auto_ptr.
Unfortunetely, you can't have a container of auto_ptrs as the STL uses
copying to move stuff (that will be fixed in C++0x hopefully), and while
it would be trivial to move an auto_ptr it can't be copied.
For that you can indeed use a container of shared_ptr, but there are
better alternatives, like the pointer containers in boost.

shared_ptr is actually meant to be used when the object can be owned by
multiple objects at the same time.
If you just need to store pointers in a container, using shared_ptr
doesn't seem to be a good idea to me.

[Alex Buell]

On Sun, 07 May 2006 20:15:25 GMT rp*****@yahoo.com (Roland Pibinger)
waved a wand and this message magically appeared:

Probably also the libraries from Qt fall into the same
category (albeit I havn't used them).

I wouldn't bother using QT C++ libs, they abuse the C++ language to
get what they want. They have this preprocessor, called moc, FFS.

Gtkmm is /much/ better and is very much like STL i.e. uses things like
iterators etc.

--
http://www.munted.org.uk

Take a nap, it saves lives.

[werasm]

loufoque wrote:

Mirek Fidler wrote :

This will just bring a dozens of posts about usability of Boost in real
world applications (and how smart pointers allow you to store stuff in
containers ;)
It seems from what I've read that the most used library of boost is the
smart pointers library.
Yet, I rarely saw cases where it's actually needed.

I've seen examples where things without the use of smart pointers get
very difficult. Smart pointers are especially handy when binding
clients to servers polymorphically, when the clients lifetime has the
potential to surpass that of the server by small periods of time. Often
this sort of thing takes tedious programming to prevent. Making use of
smart pointers this becomes trivial.

Another almost impossible example that I can make mention of, is the
passing of pointers over queues for execution of RPC's in another
thread/task/context. When the RPC/aka. command is executed in the
context of arrival, the server of the command (of course a pointer) may
not be available anymore (no possibility of removing it from the queue
- FIFO), using a weak_ptr in this case is ideal, as it becomes invalid
when it's source is destroyed. Using a raw pointer on the other hand,
well... impossible. Using a reference, also not possible because who's
the say the sender context stack is still around.

Your rarely may sprout from lack of experience. :-)

Regards,

W
The biggest use of pointers is for polymorphism, and for that you have
auto_ptr.
Unfortunetely, you can't have a container of auto_ptrs as the STL uses
copying to move stuff (that will be fixed in C++0x hopefully), and while
it would be trivial to move an auto_ptr it can't be copied.
For that you can indeed use a container of shared_ptr, but there are
better alternatives, like the pointer containers in boost.

shared_ptr is actually meant to be used when the object can be owned by
multiple objects at the same time.
If you just need to store pointers in a container, using shared_ptr
doesn't seem to be a good idea to me.

[Mirek Fidler]

loufoque wrote:

Mirek Fidler wrote :

This will just bring a dozens of posts about usability of Boost in
real world applications (and how smart pointers allow you to store
stuff in containers ;)

It seems from what I've read that the most used library of boost is the
smart pointers library.
Yet, I rarely saw cases where it's actually needed.

The biggest use of pointers is for polymorphism, and for that you have
auto_ptr.
Unfortunetely, you can't have a container of auto_ptrs as the STL uses
copying to move stuff (that will be fixed in C++0x hopefully), and while

Yes, exactly. Right to the spot!

See:

http://upp.sourceforge.net/srcdoc$Core$NTL$en-us.html

BTW, fix in C++ 0x will not solve that completely, it will just
suplement copying with moving, but there will still be a lot to be desired.
shared_ptr is actually meant to be used when the object can be owned by
multiple objects at the same time.
Which is quite stupid idea anyway. Shared ownership always leads to hard
to maintain code and is quite easily avoidable (in C++, I mean).
If you just need to store pointers in a container, using shared_ptr
doesn't seem to be a good idea to me.

Agree.

Mirek

[Earl Purple]

Roland Pibinger wrote:

A superior approach in what respect and for which purpose? Superior in
usability, simplicity and convenience for real-world users? Superior
in exploiting the most complex template meta-programming techniques?
There is nothing wrong with Boost when it is considered what it is: an
experiment in template programming. The (implicit) Boost motto is
"Look what we can do with templates!". The criteria for real-world
libraries and applications point in the opposite direction. For the
latter the goal is to provide large functionality with small,
convenient and safe interfaces. Anyone who claims that Boost is made
for real-world users either doesn't know Boost or the real world.
Probably both.

I disagree with you on the whole but agree with you in part,
particularly with regard to bind and lambdas .I think this was an
attempt to improve on the STL binders, but then I generally don't use
those either. Why? Because they make the code unreadable. And with
boost it introduces these funny _1 and _2 symbols, which I'm not even
sure are thread-safe (they are globals aren't they?). Wouldn't be easy
to debug into and if you dare to get the syntax slightly wrong, you'll
have your work cut-out interpreting the error messages.

Plus there is are two simple alternatives. One is to write a simple
functor - that's all the bind templates are anyway, but at least with
your own it will be comprehensible if you debug into it. The other is
(shock horror) to use a loop. But sometimes, when the algorithms don't
quite do what you want them to do, it's easier to implement a loop than
to start working out how to make them fit anyway. (At one point I was
writing my own algorithms and ended up with an enormous number of these
- later I decided loops were often a simpler solution).

[Noah Roberts]

Roland Pibinger wrote:

On 6 May 2006 00:36:39 -0700, "werasm" <w_*****@telkomsa.net> wrote:

Sad that following how they implement their magic is quite hard due to
yes, complexity. But complexity in implementation is orthogonal to
complexity in interface. The former being necessary in some
circumstances, the latter preferably as simple as possible - that said,
the latter should only be simple enough of domain users to understand.

Templates provide no separation between interface and implementation.
The template interface is the template implementation (and vice
versa). A template-only (almost) library cannot hide the "complexity
in implementation". This is an insurmountable problem for all template
libraries, not only Boost.

You appear to be confusing visibility to the programmer with visibility
to the code. There is nothing about templates that break
encapsulation. The only qualm I have is compile time
dependencies...that's annoying but still doesn't break encapsulation
and there are ways to minimize it.

[Earl Purple]

Noah Roberts wrote:

You appear to be confusing visibility to the programmer with visibility
to the code. There is nothing about templates that break
encapsulation. The only qualm I have is compile time
dependencies...that's annoying but still doesn't break encapsulation
and there are ways to minimize it.

Actually there are encapsulation issues with templates. Even with
std::string. Let's see some issues:

- I cannot safely pass a std::string across libraries.
- Including string will usually pull in some stream functions even
though I don't intend to use them.
- Because string is a template class, I can't forwardly declare it. I
can't put in my header any of these:

class std::string;
namespace std { class string; }

typename doesn't work either, of course. It's not standard here. Whilst
you can forwardly declare it, doing so is complex. Even if my header
only uses const std::string & I can't forwardly declare it. Ok so you
get away wtih "but string is so standard that everything should know it
anyway" but it still breaks encapsulation.

You get a similar problem with shared_ptr, although here it obviously
does need to be a template. But you have to include its header, plus
all the other headers it uses in its implementation.

If you ever want to change from boost::shared_ptr to tr1::shared_ptr
(and eventually to std::shared_ptr?), how many changes will that
entail? How much will need to be recompiled (even if there's just one
code change)? All your source, I would imagine.

I, by the way, have 2 separate abstract interfaces and one that
multiply inherits from them that are implemented with std::map. One is
for writing, one for lookup. So I have been able to abstract away
(encapsulate) map from my client code.

[Noah Roberts]

Earl Purple wrote:

Noah Roberts wrote:

You appear to be confusing visibility to the programmer with visibility
to the code. There is nothing about templates that break
encapsulation. The only qualm I have is compile time
dependencies...that's annoying but still doesn't break encapsulation
and there are ways to minimize it.
Actually there are encapsulation issues with templates. Even with
std::string. Let's see some issues:

- I cannot safely pass a std::string across libraries.

Huh?
- Including string will usually pull in some stream functions even
though I don't intend to use them.
Yes, including the definition of a class often includes things you
don't intend to use.
- Because string is a template class, I can't forwardly declare it. I
can't put in my header any of these:
None of these issues has anything to do with encapsulation.

If you ever want to change from boost::shared_ptr to tr1::shared_ptr
(and eventually to std::shared_ptr?), how many changes will that
entail? How much will need to be recompiled (even if there's just one
code change)? All your source, I would imagine.

Yes, I mentioned the problem of compile time dependencies. This still
doesn't break encapsulation. You can make very similar arguments you
have about regular classes:

class X { Y private_y; }; // Now you also have to include the
definition of Y even though Y is only used privately by X.

I'll grant you that compile time depenencies to internal data between
classes that don't know about each other's insides is a language
weakness, and that weakness is worse in templates by their nature of
having everything they do in a header file that is included where it is
used. But again, as with classes this does not break encapsulation and
there are ways to minimize both.

Encapsulation, or information hiding more accurately, is about hiding
design decisions from the rest of your code. Altering the internals of
one class should not cause another to need to change. This doesn't
mean you won't have to recompile as the clients now have to access
something that is different (that is a language weakness) but you won't
have to edit them to account for changes. Only when the interface is
altered do you have to do this. You guys are confusing compile time
dependencies and programmer visibility with information hiding.

[Earl Purple]

Noah Roberts wrote:

class X { Y private_y; }; // Now you also have to include the
definition of Y even though Y is only used privately by X.

And that does break "encapsulation" if that is defined as hiding the
implementation from the user. Using a pointer to Y (scoped_ptr if you
prefer) you can forwardly declare the Y and that hides the
implementation detail better. Particularly if there is only one such
pointer (a pointer to the implementation).

You can always say "this is a black box, don't look inside" and
generally we do adopt that approach when using, for example,
std::string and std::vector. That is fine on the whole.

But as I mentioned, std::string is not portable across libraries. And I
will explain what I mean.

I have, say, a library that I have written and compiled using GCC
compiler 3.2.1 that sits on the system and has an interface that takes,
for example, a const std::string & or even worse, a function that
returns a std::string.

Your application is being compiled with Solaris Forte 8 compiler with
Roguewave STL and tries to interact with my library. Although we are
both using a standard string class with the same interface, they are
possibly implemented differently and when you pass yours by reference
to mine, it may compile fine but may seg-fault when run.