- Boost - lists.boost.org

[variant] regressions in gcc-2.95.3-linux and gcc-2.95.3-stlport-4.5.3-linux
by JOAQUIN LOPEZ MU?Z 23 Oct '04

23 Oct '04

Hi all, Just wanted to record the following, in case it can be helpful for someone to solve the current regressions of variant for the mentioned toolsets: Latest regression runs before branching also failed for GCC 2.95.3, but *only* in the second toolset. That is, gcc-2.95.3-linux was working fine. Given that I'm pretty sure none of the relevant code (MPL or variant code itself) has changed since, I'd say this could have to do with some local change on Martin Wille's environment during the branching. Maybe the toolset rules? HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

RE: [boost] Re: SOCI db lib [Was: RTL status -"help wanted"]
by Brian Braatz 22 Oct '04

22 Oct '04

> -----Original Message----- > Subject: Re: [boost] Re: SOCI db lib [Was: RTL status -"help wanted"] > > On Wed, 20 Oct 2004 00:15:52 -0500, David B. Held wrote > > Steve Hutton wrote: > > > [...] > > > So the relevance of ODBC is open to debate - the key IMHO is uniform > > > support for all the major databases. ODBC may be a quick means to > > > that end. Native drivers can always be added later, or vise-versa. > > Agree. > > > In my experience, ODBC can be unbelievably slow, also. It is definitely > > not a cure-all. It should probably be supported, but creating an > > interface that will elegantly support native drivers should be a > > priority. > Jeff Garland: > Sure having good support for native drivers is fine, but I think it is > much, > much, harder to achieve. So my push for ODBC binding is primarily to meet > the > 'all major databases' supported quickly. > > Jeff [Brian Braatz] >From a practical point of view, I believe Jeff to be 100% right here. I have been searching for a good solution for this, and the odbc \ unixodbc path gets a framework up and running quickly. I would add that it would be nice to have that framework support "unplugging" the odbc aspect and placing in native or other drivers later. I view this perspective as the scaffolding that supports the statue, while the statue is being carved :)

1 0

[serialization] and arrays with bcc32
by Russell Hind 22 Oct '04

22 Oct '04

I'm trying to serialise arrays (boost::array, actually). There aren't any specific headers for it as there are for STL types. Could one be added at some point? But I've run in to a more basic compilation problem under bcc32: This won't compile #include <boost/archive/text_oarchive.hpp> double d[3]; d[0] = 0.0; d[1] = 1.0; d[2] = 2.0; std::ofstream ofs("c:\\test.txt"); archive::text_oarchive toa(ofs); toa & d; The error I get is [C++ Error] interface_oarchive.hpp(105): E2031 Cannot cast from 'double *' to 'double ( &) const[3]' Is this a problem with Borland or is my syntax for serialising arrays? Thanks Russell

3 3

RE: RE: [boost] Library Proposal: database (boost::db)
by Brian Braatz 22 Oct '04

22 Oct '04

Sorry to anyone who was interested in the doc I said I was going to write up (had a few work things that delayed be for a few days). I got up very early this morning and finished it off. I did a write up on the issues I have run into trying to use multi_index dynamically and issues in general for supporting DB frameworks in boost. I have placed it in the boost files section http://groups.yahoo.com/group/boost/files/BoostTable/ BTW- IT BARELY fit- it would appear there is not any more room on that area for files. I also was not able to re-download it - (or anything else for that matter from that area)- it looks like the yahoo file servers may be temporatily at lunch. If you have difficulty getting to this or would like me to mail it to you, please send me private mail and I will send to you directly. Thanks Brian Braatz brianb(a)rmtg.com > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Brian Braatz > Sent: Tuesday, October 19, 2004 6:30 AM > To: boost(a)lists.boost.org > Subject: RE: RE: [boost] Library Proposal: database (boost::db) > > > (sorry been away from mail over the last 3 days)- I wanted to respond > that > > JOAQUIN LOPEZ MU?Z Writes: > > "> If you'd care to sketch what kind of dynamic multi_index > > you have in mind (from the user point of view) maybe we > > can come out with some solid design to implement > > in future releases of the lib. My intention is to stay > > away from relational stuff, but I'll go for a dynamic > > container if it can be made general purpose." > > I *very* much want to take you up on this- tonight (about 12 hours from > now) I will write something up and show you what I did. > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org [mailto:boost- > bounces(a)lists.boost.org] > > On Behalf Of JOAQUIN LOPEZ MU?Z > > Sent: Friday, October 15, 2004 12:06 PM > > To: boost(a)lists.boost.org > > Subject: Re: RE: [boost] Library Proposal: database (boost::db) > > > > Hi Brian, > > > > ----- Mensaje original ----- > > De: Brian Braatz <brianb(a)rmtg.com> > > Fecha: Viernes, Octubre 15, 2004 6:56 pm > > Asunto: RE: [boost] Library Proposal: database (boost::db) > > > > [...] > > > > > > I am currently going down this exact path and wanted to share what > > > I ran > > > into: > > > > > > 1- Boost does not have a 2dim "Table<>" - i.e. a Recordset > > > 2- Boost.multi_index only works with concrete structures > > > I would love it if I could use that to make a dynamic Table\ > > > recordset > > > > What do you mean by concrete structures? > > > > > 3- I have had to build my own Table<> by internally using > > > boost.multiindex > > > > Do you mean, you have actually built a Table<> class > > using Boost.MultiIndex? > > > > > > [...] > > > > > I believe boost is missing a "recordset" analolgy and I would hope > > > thatwhatever is created is not "struct only" like > > > boost.multi_index. (don't > > > get me wrong I LOVE the multi_index - it just doesn't work > > > dynamically) > > > > Well, in the past I thought about what a > > dynamic_multi_index_container (with run-time specification > > of indices) could look like: the implementation internals > > are not hard to solve with the same framework as > > Boost.MultiIndex, it is the interface that I don't have a > > clear idea about. Also, I don't envision a clear usage > > scenario for this, and there are RTTI-like issues > > involved as well (what should get<N>() return?) > > > > If you'd care to sketch what kind of dynamic multi_index > > you have in mind (from the user point of view) maybe we > > can come out with some solid design to implement > > in future releases of the lib. My intention is to stay > > away from relational stuff, but I'll go for a dynamic > > container if it can be made general purpose. > > > > On another topic, have you considered Arkadiy's > > RTL as another source of ideas/synergies? Seems like > > Arkady sort of diverted to his BOOST_TYPEOF facility, > > so I don't know what the current status of the lib is. > > > > Joaquín M López Muñoz > > Telefónica, Investigación y Desarrollo

1 0

[serialization] BOOST_CLASS_IMPLEMENTATION and partial template specalization
by Vyacheslav E. Andrejev 22 Oct '04

22 Oct '04

Hello, Using BOOST_CLASS_IMPLEMENTATION there is no way to assign specific serialization implementation to any specialization of some template class. Suppose we have template class template <class Params> class LaserPointSerializationExpression { ... }; And we want that any specialization of this class should be object_serializable. Simple use of BOOST_CLASS_IMPLEMENTATION(LaserPointSerializationExpression, boost::serialization::object_serializable); will give us the following code namespace boost { namespace serialization { template <> struct implementation_level<LaserPointSerializationExpression > { typedef mpl::integral_c_tag tag; typedef mpl::int_< boost::serialization::object_serializable > type; static const int value = implementation_level::type::value; }; } } which obviously will fail to compile. The correct code is namespace boost { namespace serialization { template <class Params> struct implementation_level<asda::lpfio::LaserPointSerializationExpression<Params> > { typedef mpl::integral_c_tag tag; typedef mpl::int_< boost::serialization::object_serializable > type; static const int value = implementation_level::type::value; }; } } But there's no macro such as BOOST_CLASS_IMPLEMENTATION to generate it. So I think there should be special version of BOOST_CLASS_IMPLEMENTATION that allows to generate implementation_level for any specialization of some template. -- ______________________________ Vyacheslav E. Andrejev System Architect, Excelsior, LLC E-mail: vandrejev(a)excelsior-usa.com ICQ: 7152604

2 1

Math functions for Stastistics- feedback from TR2 proposal
by Paul A Bristow 22 Oct '04

22 Oct '04

Sadly I was not able to attend The Redmond meeting to present proposals myself, but Alisdair Meredith gave the following feedback: "I mentioned I would like feedback for stats functions, at least as a rough indicator on how to proceed. Unfortunately feedback was overwhelmingly negative. It is seen as a lot of work for a small audience with minimal commercial incentive. Bill Plauger went so far as to say given the chance again, he would not have taken on the current math functions and once bitten, twice shy. If this is to stand any chance of consideration, we need a cast iron case proving: i/ market demand ii/ reasonable implementability It is too early to be drawing the exhaustive list of functions. One approach suggested was that if we got an implementation into Boost, and there is feedback of widespread adoption, then there would be incentive to revisit the issue." I find this response rather baffling considering the importance of these functions for even the most basic statistics. I can only conclude that they are under the common delusion that computer systems are only responsible for reproducing the data input and does not extend to deriving information to justify action. As a very simple example, if you make several measurements on two things, whether racing driver lap times, pipe diameters, share prices, accident rate, ore yield, or pollutant levels, you need some of these statistics functions to be able to judge the probability that one is different from the other. So I am now asking for your views on if it is worth producing a Boost library version based on the existing Cephes implementation by Steven Moshier who has kindly agreed to make it available under the Boost licence terms. It would be a modest effort to rename the existing Cephes C double functions, and provide the C++ templates to use them. This would be a 'proof-of-concept' implementation, with some minimal testing (the original code has been quite well tested). But there would be a lot more tedious work to produce a full implementation including all three builtin floating-point formats, and perhaps the existing high precision UDT Floating point as well. I am sure you will understand I would not want to put a lot of effort into this, only to have it rejected by Boosters. Please let me have your views on if and how to progress this topic. Paul Slightly updated versions of my TR2 proposal are at http://www.hetp.u-net.com/public/math_stats_functions_tr2_v2.doc http://www.hetp.u-net.com/public/math_stats_functions_tr2_v2.pdf Powerpoint presentation of short bullet points used in my presentation to the UK C++ panel. http://www.hetp.u-net.com/public/Math%20functions%20for%20C%20and%20C++%20St andard.ppt and a text version http://www.hetp.u-net.com/public/Math%20functions%20for%20C%20and%20C++%20St andard.txt Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

5 4

Possible bug in thread/tss.cpp
by Baptiste Lepilleur 22 Oct '04

22 Oct '04

I think there is a bug related to the fact that global static variable initialization order is undefined. tls_data is a global variable which is initialized indirectly by tss::init(). thread_specific_ptr<> instance usually also global static variable and call tss::init() in their constructor. Both being global static variable, their initialization order is unspecified, and error may occurs if thread_specific_ptr<> is initialized before tls_data. Questions: wouldn't it be possible to get ride of the tls_data memory leak, by using a by value tls_data static data instead of a pointer, and calling pthread_key_delete() to ensure callback are no longer called ? Baptiste.

1 0

get original argv string(s) for program option?
by Jonathan Graehl 22 Oct '04

22 Oct '04

Is it possible to index from option name to the original argv string(s) supplied by the user? It doesn't seem possible to do this with vm["option"].as<string>() since: 1. *template*<*typename* T> *const* T & as() *const*; If stored value if of type T, returns that value. Otherwise, throws boost::bad_any_cast exception. Now that I think of it, because options can come from environment vars and config files as well, the original string won't necessarily be lying around in memory, but would have to be copied somewhere. What would be nice is if variable_value could (yes, at some cost to those who don't use it) store the original string(s) automatically? The vector<option> from command_line_parser isn't convenient to use (since it can't be indexed by option name, but would have to be searched.

2 1

RE: [boost] Re: Any interest in adding unicode support to boost?
by Glen Knowles 22 Oct '04

22 Oct '04

> From: Eric Niebler > Erik Wien wrote: > > "Miro Jurisic" <macdev(a)meeroh.org> wrote in message news:macdev- > > > >>I am not sure I buy this. I think that if you want to have > unchecked > >>Unicode data, you should use a vector<char*_t>. Unicode > strings have > >>well-defined invariants with respect to canonicalization and > >>well-formedness, and I think that the a Unicode string abstraction > >>should enforce those invariants. > >> > >>Having intermediate states that are invalid and a final > state that is > >>valid is not a feature, it's a bug. It's a silent failure > that I want > >>to know about. > > > > > > Amen. ;) > > > > No fair bringing religion into this. ;-) I'll repeat what I > said before > -- this would be an unfortunate design, and you'll hear about it from > your users. If you force people to do their bit twiddling in > vector<char*_t>, then you impose an extra allocation and a > copy to get > it into a unicode::string, and most people won't bother. If it imposes a copy I certainly won't use it. What I'm interested in are functions to compare utf* encoded arrays and create sort keys from those same arrays. In truth, all I need are unicode aware versions of strcoll, strxfrm, and strlwr that don't require locking a mutex around the global locale in my multithreaded code. But other things such as substring and regex matching would also be welcome. I'm sure its already been discussed adnausem, but the fact that atof, ostringstream ctor/dtor, printf, tolower, etc all may mutex around access of a global locale has forced me to strip them out of quite a bit of code. In my tests this was fine on a uniprocessor, marginal on a dual, but on a quad or better it was the single biggest bottleneck. I almost always want to treat strings as char arrays. Most operations are simply copying/moving or checking to see if the string is in a set or hash. If I need to do a lot of locale aware comparisons I'm going to generate sort keys first. Glen

1 0

[graph] adjacency_list::operator=()
by David M. Jones 21 Oct '04

21 Oct '04

Hello all, If I have an adjacency_list g and I call g = g; all of the vertices and edges of g are removed. This is not what I would expect; I would expect that this operation would not change g. 1. Is this the desired behavior? (It seems different than what other types do.) 2. Is this issue old news? (I couldn't find it on the mailing list archives but it may well be there.) Thanks, David

4 4