- Boost - lists.preview.boost.org

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 … [View More]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 [View Less]

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 … [View More]

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 … [View More]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 [View Less]

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: … [View More]

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 … [View More]

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 … [View More]

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

RE: [boost] Re: Any interest in adding unicode support to boost?
by Stefan Seefeld 20 Oct '04

20 Oct '04

> From: Peter Dimov [mailto:pdimov@mmltd.net] > Sent: October 20, 2004 15:52 > To paraphrase, unnecessary parameterization is the root of most evil > nowadays. Parameters are a liability, not an asset. I'd sign that any day ! However, the primary goal behind my XML wrapper library (which, by the way, I already discussed here on the boost list to see whether there was enough interest into a general purpose C++ API for dealing with XML...) was to define an API, and to provide a … [View More]

2 1

RE: [boost] Re: Any interest in adding unicode support to boost?
by Stefan Seefeld 20 Oct '04

20 Oct '04

> From: Erik Wien [mailto:wien@start.no] > Sent: October 20, 2004 14:37 > > - Why would the user want to change the encoding? Especially between > > UTF-16 and UTF-32? > > Well... Different people have different needs. If you are > mostly using ASCII > characters, and require small size, UTF-8 would fit your > bill. If you need > the best general performance on most operations, use UTF-16. > If you need > fast iteration over code points and … [View More]

2 1

Re: [boost] http://www.boost.org/libs/utility/iterator_adaptors.htm
by JOAQUIN LOPEZ MU?Z 20 Oct '04

20 Oct '04

This is corrected in RC_1_32 (the link forwards to Boost.Iterator docs, which is (if I'm not wrong) preferred to old iterator adaptors.) ----- Mensaje original ----- De: "Neal D. Becker" <ndbecker2(a)verizon.net> Fecha: Miércoles, Octubre 20, 2004 7:26 pm Asunto: [boost] http://www.boost.org/libs/utility/iterator_adaptors.htm > Bad link on http://www.boost.org/libs/utility -> iterator_adaptors.htm > > _______________________________________________ > Unsubscribe & … [View More]

1 0