October 2004 - Boost - lists.boost.org

boost::shared_ptr interface
by David M. Jones 18 Oct '04

18 Oct '04

I ran into a situation (see my "smart list" post on the boost users group) where I wanted to create a custom allocator whose pointer typedef is boost::shared_ptr. In other words, the code would look something like: template <typename T> class my_allocator { public: typedef boost::shared_ptr<T> pointer; }; The problem with doing this is that boost::shared_ptr<T> does not have the same "interface" as the equalivalent raw pointer type T*. (I use the term interface in the generic programming/template sense; not in the object oriented sense.) One example is that there is no operator= on boost::shared_ptr that takes a raw pointer; instead reset() must be used. Here are my questions: (1) What advantage does this change of interface serve that makes it worth breaking potential operations such as that above? (2) Does anyone have ideas on how to get around this problem? I toyed with the idea of writing a class that derives from boost::shared_ptr and has the interface that I desire -- anybody have thoughts on this? Thanks, David M. Jones

3 4

explicit shared_ptr(weak_ptr<Y> const & r);
by John Torjo 18 Oct '04

18 Oct '04

Hi Peter, Just a thought: perhaps this constructor: explicit shared_ptr(weak_ptr<Y> const & r); should be private, and the only way to create a shared_ptr from a weak_ptr is: shared_ptr<T> val = weak->lock(); This way, the shared_ptr public constructors will never throw. Users will not make mistakes like this: shared_ptr<T> val = weak; I'm saying this, because I just made this mistake a few hours ago... After a while, the shared_ptr<> constructor started to throw at me ;) Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html

2 4

Re:[boost] Re: Re: Re: RTL status -"help wanted".
by Robert Ramey 18 Oct '04

18 Oct '04

FWIW - I love this idea !!!! I had forgotten about but when back and refreshed my memory. 1) its got nothing to do with being a wrapper to access a traditional database. That might be worthy project but this project isn't it. c) its all compile time. That means the the schemas can't be changed dynamically. This is inherent in the design. So its not a universal replacement for anything. However, I believe the time is now for such a library. Let me explain. Commmon use case. I am a freelance software developer. It often occurs that a customer has a situation which maps directly to a set of database schemas. The easiest way I've found to accomplish ths is (please - don't laugh) is to make a database in MS Access and write a VB program which peeks and pokes at it via ADO or something similar. This approach has the following features. a) Its simple to build and prototype the database. b) Its simple to fixit up when something changes. c) It eliminates a whole bunch of programming required to maintain data d) it eliminates a whole bunch of programming to query data. Just insert and test the query in Access. When it works, invoke the name of the query from VB - very easy. e) It depends on MS implementation of ADO which is very quirky in my opinion. f) It uses VB which will drive a real programmer crazy. g) Its all run time - no compile time optimization. h) Its all run time - no compile time checking. VB delays checking everything to the last possible moment - like when I'm home in bed. i) Its easy to make a nice UI that customer's love j) one doesn't have to worry about the size of things like history logs etc as its all handled by the DB. k) the data is accessible by other tools - basically and SQL query. So there is a class of applications which a) don't require that the schema changes after compilation b) need fast response c) use datasets of bounded size. Examples might be: a) address/contact manager for a palm computer/cell phone b) web database to support sales of tickets to grateful dead concerts as soon as they are announced. c) many small business databases - a years accounting. So I think this is interesting for what it is. I'm concerned that it might get bogged down by concerns that it isn't something else. In my view this sometimes occurs to boost proposals. I just looked over the documentation and I like what I see. Its no clear what's missing - of course I didn't try to use it. I think you might get more response to your request for help if. a) the directory structure and documentation looked more like a boost library so that one could just paste it into his boost tree. b) it was clear what's working and what's not. Maybe this should be reflected in the directory structure. c) If it was divided into working / not working. d) if the working subset was immediately useful. E.g. transactions could be postponed. It looks like you've focused on adding all the features before finishing off the basics ( documentation, examples, tests, etc.) This makes it hard for users to become addicted to your library which is what you need to get more help. The best way to get help is to get people using (part of) your library. When they need some feature, you can pressure them to create it and add a test. Machines and applications are now being made that can really benefit from the RTL library. Robert Ramey

3 2

Re:[boost] Sprit-1.6 and latest boost
by Robert Ramey 18 Oct '04

18 Oct '04

> Because bcc32 can't deal with spirit-1.8, to use spirit and boost 1.31, > I've replaced spirit.hpp and the spirit directory in boost with the 1.6 > distribution. > This doesn't work with the latest boost code, it looks like the errors are > due to the changes mpl that were mentioned. > Are there any plans to update spirit 1.6 to work with latest boost so > those of us with older compilers can use the two together? A very good question that I would also like to know the answer to. For the serialization library, all I had to do was to remove a superfluous "#include <boost/mpl/apply_if.hpp>" from one the spirit 1.6 header. This may or may not address your particular situation. I suspect that the serialization library is the only code in boost that depends on spirit so this may be all you need. More generally, as things stand now, anyone who downloads boost 1.32 and spirit 1.6.x in hopes of using the serialization library with his bcb, gcc 2.95, or msvc 6.x compiler will be disappointed to find that libraries won't build. I would like to see this rectified by an update to the spirit 1.6.x package. Could I encourage someone who has the proper access, authorization and understanding of what's involved to do this? Robert Ramey

1 0

Re: [boost] Sprit-1.6 and latest boost
by JOAQUIN LOPEZ MU?Z 17 Oct '04

17 Oct '04

----- Mensaje original ----- De: Russell Hind <rh_gmane(a)mac.com> Fecha: Domingo, Octubre 17, 2004 5:31 pm Asunto: [boost] Sprit-1.6 and latest boost > Because bcc32 can't deal with spirit-1.8, to use spirit and boost > 1.31, > I've replaced spirit.hpp and the spirit directory in boost with > the 1.6 > distribution. > > This doesn't work with the latest boost code, it looks like the > errors > are due to the changes mpl that were mentioned. > > Are there any plans to update spirit 1.6 to work with latest boost > so > those of us with older compilers can use the two together? > This has been discussed in connection with Boost.Serialization, which relies in Spirit 1.6 for older compilers. Apparently, all it takes to make Spirit 1.6 work under Boost 1.32 is to replace apply_if with eval_if. >From what the mailing list tell us, the fix was on the verge of being applied, but I guess it wasn't after all: http://lists.boost.org/MailArchives/boost/msg71227.php HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Trial history file; CSS problem
by Daryle Walker 17 Oct '04

17 Oct '04

[I sent something like this on Saturday, but no one responded. So I'm resending in case it got rejected.] Instead of a mail attachment, the file is now in the Sandbox. Look under its "BOOST_ROOT/more/version_history.html" and pretend it's at the same relative spot in the main CVS. I'm surprised that a full-blown version history file wasn't added a long time ago. I raided the CVS history of the main "index.htm" file for the details. Any ancient-timers know the history of 1.11.0 and earlier? The header looks funny; I was wondering how to replicate the current look by mutating what's given with CSS. (I was thinking of the headers seen at <http://www.mozilla.org>.) I processed what I wrote through HTML-Tidy, adding indentation and line wrap. I kept getting weird spacing with the function descriptions at the Spirit section of 1.30.1 and the Lambda block-quote at 1.28.0. I worked-around the problem by undoing the line-breaks Tidy added at those points. After being bewildered for a long while about the weird spacing, I saw the problem when looking in the CSS file: CODE { FONT-FAMILY: Courier; white-space: pre; } This last (non-brace) line says that multiple white-space characters are _not_ collapsed into a single space. This lets CODE acts as an in-line variant of PRE, but it violates what CODE usually does! I need the default space-collapsing behavior of CODE. If no one can give me a justification for that attribute, I'm going to erase it. Even if you can justify it, do this instead: CODE.my_special { FONT-FAMILY: Courier; white-space: pre; } Then call it like so: <p>Blah blah, please <code class="my_special">keep all of my spaces</code> blah blah.</p> That way people who need the default space-collapsing attribute of CODE don't get screwed. (Right now it's optimizing the [IMO] <1% wacky case and forcing extra work to get the usual semantics [that should take 99+% of the cases].) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 3

Re: [boost] Re: [tuple] attempt to fix a BCB regression, and a plea for help
by JOAQUIN LOPEZ MU?Z 17 Oct '04

17 Oct '04

----- Mensaje original ----- De: Tobias Schwinger <tschwinger(a)neoscientists.org> Fecha: Domingo, Octubre 17, 2004 1:01 pm Asunto: [boost] Re: [tuple] attempt to fix a BCB regression,and a plea for help > JOAQUIN LOPEZ MU?Z wrote: > > Umm... This got me thinking, maybe the whole BCB-specific > > patch is just overkill, and it only takes to avoid > > the add_const<> construct. > > The attached file does just this, i.e. it relies on > > the default implementation for element<>, using > > plain const-qualifying instead of add_const<> for > > BCB. Would you be so kind to give it a try? Thanks in > > advance. > > > > This new version compiles fine with BCC 5.6.4 but does not compile > with > BCC 5.5.1 (and versions below this, according to Boost.Config). > > The patch is the difference from the file attached to the post I > reply > to (and not the first file you sent) and makes it work again. > > It uses the previous workaround in case > BOOST_NO_CV_SPECIALIZATIONS is set. > Another check for BCB within this block could be made in order to > use > 'add_const' for compilers where it works fine (I omitted it, for now). > > > Here's my (still fuzzy) problem analysis: > > 1. The "BCC <= 5.5.1 - problem" is that for these versions of BCC > cv-specializations don't work. > > 2. The "add_const - problem" could have something todo with the > fact > that for BCC 'type const' and 'const type' can be different types. > [ see the note regarding the '__BORLANDC__' - block in > 'is_const.hpp' ] As I understand it, the comment you refer to has to do with cv-qualifying references --not our problem now, I think. > I am not sure if and how this affects template argument > substitution, > but I changed > > typename T::head_type const > > to > > const typename T::head_type > > , just in case... > My only objection to your patch is that the problem with add_const is attributed to BOOST_BCB_PARTIAL_SPECIALIZATION_BUG Do you have any reason to think so? I'd prefer to have that part guarded by a simple __BORLANDC__ workaround, given our current (lack of) knowledge about what's causing the problem. If no one complains, I'll commit this stuff to the CVS tomorrow. Thanks everyboydy for your help. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

[preliminary submission] Is there any interest in an algebraic vector class?
by Debian User 17 Oct '04

17 Oct '04

Hi @, I've uploaded the initial version of the algebraic vector class as proposed in comp.lang.c++.moderated. It has been renamed to Euclidean vector class as a result of the discussions so far. Is there any interest here? Comments are welcome. The library is not yet in the boost name space and not yet under the boost licence. That's of course going to change if it eventually should be accepted. Andreas

2 1

Re: [boost] Re: [tuple] attempt to fix a BCB regression, and a plea for help
by JOAQUIN LOPEZ MU?Z 17 Oct '04

17 Oct '04

Hi Tobias, ----- Mensaje original ----- De: Tobias Schwinger <tschwinger(a)neoscientists.org> Fecha: Sábado, Octubre 16, 2004 10:24 pm Asunto: [boost] Re: [tuple] attempt to fix a BCB regression,and a plea for help > > Hi, > > the patch makes tupe_test_bench.cpp compile successfully on BCB > 5.5.1 > and 5.6.4. This is great news! Thanks for investigating. > > I have to add the disclaimer that it is an intuitive guess and may > not > be a real solution. I gave it a try, that's all ;+). > The code looked good before I touched it and I have honestly no > idea why > my adjustments make BCB behave again (for both changes)... > Umm... This got me thinking, maybe the whole BCB-specific patch is just overkill, and it only takes to avoid the add_const<> construct. The attached file does just this, i.e. it relies on the default implementation for element<>, using plain const-qualifying instead of add_const<> for BCB. Would you be so kind to give it a try? Thanks in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[boost] [tuple] attempt to fix a BCB regression, and a plea for help
by JOAQUIN LOPEZ MU?Z 17 Oct '04

17 Oct '04

Hello, A couple of days ago I prompted about the status of a supposed regression on tuple_test_bench (http://tinyurl.com/62plc) The attached file (to be replacing boost/tuple/detail/tuple_basic.hpp) is an (unsuccesful) attempt to fix the problem, which is related to the inability of BCB to cope with element<N,T> being specialized for T a const tuple type. AFAICS, the attached file should work (I've checked the workaround with other compilers), but BCB still doesn't like. Lacking the necessary BCB skills and tools, I'd appreciate if someone can take a look at it and, hopefully, turn it into a valid workaround for Borland. The relevant part is guarded by a "#if defined(__BORLANDC__)" directive. There are 14 regressions left in the main trunk, and if we all pull a little together, the long awaited Boost 1.32 release could be make real very soon. Thanks for the help. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4