- Boost - lists.boost.org

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 17 Oct '04

17 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

[Graph] New algorithms on graph_devel_1_33_0 branch
by Doug Gregor 16 Oct '04

16 Oct '04

I've just checked in some new graph algorithms that have been contributed to the BGL. They're on the branch graph_devel_1_33_0 until we've branched off the 1.32.0 release, at which point they will go into the trunk. The interesting algorithms are: - A* search, from Kristopher Beevers and Jufeng Peng - Floyd-Warshall all-pairs shortest paths, from Lauren Foutz and Scott Hill - Fruchterman-Reingold force-directed layout, from Doug Gregor The first two algorithms came out of David Musser's Generic Programming class at RPI. Consider that a challenge for any one else teaching courses in Generic Programming now or in the future: you know who you are :) I'll also be moving (sequential) code from the Parallel BGL project into CVS as soon as it becomes ready, and will batch up messages to list announcing the additions. All of the code has been written or reviewed by me, so you know where to direct comments and complaints :) Doug

2 2

Re: [boost] StringAlgo - (was: boost::tokenizer )
by Dirk Gregorius 16 Oct '04

16 Oct '04

Hi there, > I'm not very good at explaining the things in short, but I'll try. thanks for the explanation. I think I got it and it was not as bad as you maybe think. To come back to the initial problem of string tokenizing. I am trying to implement the finder in terms of ForwardIteratorT. Here is what I think I am expecting to do - also actually I am not very sure about it. I justed started to read M. Austern's book and I am quite new to concepts, requirements and so on. So here is what I did so far: struct comment_finder { template<typename ForwardIteratorT> boost::iterator_range<ForwardIteratorT> operator()( ForwardIteratorT Begin, ForwardIteratorT End ) { ForwardIteratorT first, last; while ( Begin != End ) { first = Begin; if ( *Begin++ == '/' && *Begin == '/' ) { last = first; while ( *last++ != '\n' ) { // FAILURE: Return an empty range if ( last == End ) return boost::make_range( ??, ?? ); // return an empty range - HOW? } // SUCCESS: Return the range return boost::make_range( first, last + 1 ); } } return boost::make_range( ??, ?? ); // return an empty range - HOW? } }; Is this the way I have to implement the finder or can it be implemented using some facilities in your library? This implementation is quite low-level, so I am wondering if this is correct. Secondly, for the case this is correct, how should I return an empty range or what shall I return if didn't find a matching range? What are the following steps? Do I have to split two time times or how do I erase the comments out of the string? Will the final token iterator be only of ForwardIteratorT or will be of the type of the conatiner that is holding the tokens. ( e.g. for a vector it would be a randow access iterator? ) Sorry for the inconvinience and thanks for the help so far. -Dirk

2 1