On Wednesday, February 05, 2003 10:55 AM [GMT+1=CET], Daniel Frey <[EMAIL PROTECTED]> wrote:
> Dave Abrahams wrote: > > > > On Wednesday, February 05, 2003 9:32 AM [GMT+1=CET], > > Daniel Frey <[EMAIL PROTECTED]> wrote: > > > > > "Premature flexibility is the root of all evil" > > > > > > Stone me, Andrei :o) > > > > I don't think it's premature. There's certainly plenty of evidence by now > > that people want a variety of different smart pointers > > I know. And I agree. Sentences like the above are provoking by their > nature, but still hold some truth. I don't dispute that, but particularly given the rocky history of Andrei's relationship with Boost, it'd probably be better to avoid statements that are provoking by their nature in this conversation. I'd like to make sure Andrei feels welcome here and hope one day he'll make some library submissions. > In the end, it's all a trade-off Truism of the week ;o) > and > I am not sure how far we can extend flexibility. It has some cost (might > be smaller if template-typedefs are available) Not much. Smart pointers are easy enough to simplify via inheritance. > and I think it would be a > horror to create and even more to maintain a boostified version of > Andrei's PBSP. Boost is becoming a blackbox with lot's of magic inside, I think that's also provoking by its very nature (it's subjective impression stated as fact). > PBSP might suffer the same problem. People (including me) seem to prefer > things that not only just work, but which can also be fixed if they > don't work. This is why I like open-source so much, but boost is giving > me some headaches like is_class. I was also a bit shocked when I found > out that boost's smart-pointer add ~36 bytes to my objects if I use > intrusive-counting - which is not acceptable for me. Which compiler? How were you using intrusive counting? > This was a > motivation to start my own little library where I can understand the > code. It helped me to understand the things I wasn't able to understand > from looking at the boost code. I haven't published it yet for several > reasons including missing documentation, missing tests for at least some > important platforms/compilers, and last but not least I'm not sure if it > would be fair to boost. Why not? > OTOH, it might help others to learn more about > C++ (I learned a lot from boost, but it's getting harder with every new > release). > > To sum it up: I believe boost is becoming a blackbox and that worries > me. Please define "blackbox." Are you saying we need more implementation-level documentation? Most projects concentrate on that at the expense of user-level docs, and it hurts usability. Boost's focus goes the other way, which probably hurts transparency. As you say "it's a trade-off." What you could do that would make a big contribution would be to take what you learned from analyzing smart_ptr, and write some implementation docs that could be incorporated in boost. > > I still have some questions which haven't been satisfied about how to get > > there, of course... > > Andrei has done a lot of good things not just by creating them, but also > by writing a book about it. Agreed, of course. What I mean is that I'm not completely satisfied with the implications that his MI design has for smart pointer size on real-world compilers. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost