- Boost - lists.boost.org

[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

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 sample implementation as a proof-of-concept. The fact that this particular implementation I'v been using is based on utf-8 should be transparent (though accessible). Regards, Stefan

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 size doesn't matter, use UTF-32. another argument is legacy / compatibility. I'v written an XML library in C++ that essentially wraps a C library (libxml2 for the insiders), and so I'd like to avoid unnecessary string copies when passing data around. While the inside uses utf-8, I want to make the wrapper API adaptive to user-side unicode APIs. Thus the unicode type has become a template parameter, and conversion is being done by a trait class. Regards, Stefan

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 & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

http://www.boost.org/libs/utility/iterator_adaptors.htm
by Neal D. Becker 20 Oct '04

20 Oct '04

Bad link on http://www.boost.org/libs/utility -> iterator_adaptors.htm

1 0