- Boost - lists.boost.org

Re: [boost] [gsoc] Request Feedback for Boost.Ustr Unicode String
by Joe Mucchiello 16 Aug '11

16 Aug '11

>> text t6(pq_some_func(), textenc::libpq()); >> > You don't need it. You're proposing a design that tries to solve a > non-existing problem. There is no such diversity of encodings in the > interfaces. I don't know what is libpq, but it either uses UTF-8 in which > case you write: > > string t6 = pq_some_func(); > I think the point here that you don't need to know the encoding of libpq. If the policy is that you use this text class and that to use it you convert it using the standard text constructor that takes the listed tag. For libraries that use UTF-8 the conversion is a no-op. Adapting a new library to the "boost way" just involves adding a new tag to the textenc namespace and, if necessary, writing a new pair conversion routines.

2 1

[1.44][serialization] Link error with polymorphic archives and BOOST_CLASS_EXPORT
by Ralph Tandetzky 15 Aug '11

15 Aug '11

Hi, I discovered a problem, that has been previously discussed in a post from 2011-01-21 which has the same title. No concluding answer was given there, so I post the problem again. Essentially, the following code compiles but doesn't link: -------------------------- #include <sstream> #include <boost/serialization/export.hpp> #include <boost/archive/polymorphic_binary_oarchive.hpp> class A { public: template<class Archive> void serialize(Archive & ar, const unsigned version) { } }; BOOST_CLASS_EXPORT(A) int main() { A a; std::ostringstream os; boost::archive::polymorphic_binary_oarchive oa(os); oa & a; } -------------------------- Removing the line with "BOOST_CLASS_EXPORT(A)" or turning the "polymorphic_binary_oarchive" into a "binary_oarchive" removes the linker error. With Visual Studio 10 the following error message occurs: main.obj : error LNK2001: unresolved external symbol "public: static void __cdecl boost::archive::detail::archive_serializer_map<class boost::archive::detail::polymorphic_oarchive_route<class boost::archive::binary_oarchive_impl<class boost::archive::binary_oarchive,char,struct std::char_traits<char> > > >::erase(class boost::archive::detail::basic_serializer const *)" (?erase@?$archive_serializer_map@V?$polymorphic_oarchive_route@V?$binary_oarchive_impl@Vbinary_oarchive@archive@boost@@DU?$char_traits@D@std@@@archive@boost@@@detail@archive@boost@@@detail@archive@boost@@SAXPBVbasic_serializer@234@@Z) 1>main.obj : error LNK2001: unresolved external symbol "public: static bool __cdecl boost::archive::detail::archive_serializer_map<class boost::archive::detail::polymorphic_oarchive_route<class boost::archive::binary_oarchive_impl<class boost::archive::binary_oarchive,char,struct std::char_traits<char> > > >::insert(class boost::archive::detail::basic_serializer const *)" (?insert@?$archive_serializer_map@V?$polymorphic_oarchive_route@V?$binary_oarchive_impl@Vbinary_oarchive@archive@boost@@DU?$char_traits@D@std@@@archive@boost@@@detail@archive@boost@@@detail@archive@boost@@SA_NPBVbasic_serializer@234@@Z) Is there something wrong with the serialization library? Regards, Ralph Tandetzky.

2 2

Review Request: Singularity
by Ben Robinson 15 Aug '11

15 Aug '11

Hello, I would like to thank the Boost community for their invaluable feedback regarding the features and implementation details of Singularity. Singularity has been greatly refined and I am now requesting a formal review. I have compiled and run Singularity on 4 different compilers: GCC 4.5, MSVC++ 2010, the CL2000 TI compiler targeting the 2803x processor, and the Green Hills compiler targeting the Cortex-A8 ARM processor. The documentation, implementation and Boost unittests are available on GitHub at https://github.com/icaretaker/Singularity. Please note, that I have also implemented Singularity in C++11 using perfect function forwarding in the /cpp11 subdirectory, but that is not part of the submission, unless Boost is accepting C++11 libraries at this time. I will now include an excerpt of the documentation file "singularity.htm" which is part of the GitHub download: Introduction<file:///C:/home/ben/workspace_boost/boost/source/common/libs/singularity/singularity.htm#singularity.introduction> The Singularity Design Pattern allows you to restrict any class to a single instance. Singularity gives you direct control over the lifetime of the object, and does not require you to grant global access to the object, nor limit you to a single constructor for that object. Motivation<file:///C:/home/ben/workspace_boost/boost/source/common/libs/singularity/singularity.htm#singularity.motivation> The ability to restrict a class to a single instance is an important technique. While the commonly used Singleton Design Pattern achieves the desired goal, it introduces three undesirable limitations, namely: 1. Lifetime: Singleton introduces lifetime management complexities. The undefined destruction order of multiple singletons is just one example. 2. Scope: Singletons are always globally accessible. Accessibility should be orthogonal to restrictions on the number of instances. 3. Initialization: Singletons typically restricts the class to the default constructor. This makes Singleton difficult for classes which require non-default constructors. Like Singleton, Singularity restricts a class to a single instance. However Singularity does not suffer from lifetime, scoping and initialization problems. The following are the advantages of Singularity over Singleton: 1. The lifetime of the single object is bounded by calls to create() and destroy(). This lifetime is managed similiarly to objects bounded by calls to new() and delete(). 2. Singularity does not force global access to the instance. If global access is required, then a globally accessible get_global() function can be enabled upon creation of the instance. 3. Singularities of objects can be created using any available constructor for that object. Thank you, Ben Robinson, Ph.D.

2 1

Re: [boost] [containers review] A reminder that the containers review ends tomorrow
by John Maddock 14 Aug '11

14 Aug '11

> Just a quick reminder that the containers lib review ends tomorrow - there > have been lots of good comments, but not so many reviews - so now's your > chance ;-) If there are any reviews pending that are likely to be late > please let me know so we can extend the review period. This review was sent to me privately, posted here for comment: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Review of Boost.Contianer by Zoltán Tóth I am not an expert of C++ containers topic, but use them daily in my algorithm programming job. C++ 1998 STL containers have serious deficiencies, I would say especially node-based STL containers are not usable at all for performance-critical algorithms due to their memory allocator treatment/requirements. I have written own implementations for STL vector, set, list, ., because I was not satisfied with STL containers. Therefore a replacement of those in Boost could be a terribly useful library. I did not try to use the library. I just quickly read the documentation, and found that it is very poor. Here are the deficiencies I have found in the documentation: 1. One of the most important reason to replace the STL containers is the treatment of custom memory allocators. However the documentation tells only a single sentence about it: "Containers support stateful allocators and are compatible with Boost.Interprocess (they can be safely placed in shared memory). " 1. It does not specify how the containers are swapped: are the allocators swapped with the container? 2. Most STL implementations have been supporting stateful allocators for years now. So it is not big news. However I am not satisfied with the way they might do it. For example Visual Studio's STL implementation require the allocator type to have a template copy constructor. Such allocator types are difficult to be implemented in efficient, threads-friendly way. (This is the reason I have implemented my own set implementation instead of STL::set) The documentation does not tell whether this library have a similar requirement. If no, that would be big news. 2. The documentation says: "All containers offered by Boost.Container can be used in recursive data structures, something that is not guaranteed by the standard". To understand the value of this feature better I as a user would like to know more about this topic. Please insert links or own text here that explain why does the standard not guarantee this. Is there any danger or difficulty in it? If yes: how does this library overcome them. IMHO Boost.Containers should not (yet) be accepted (because of the lack of a detailed documentation).

3 2

[locale] Slides for the lecture on Boost.Locale
by Artyom Beilis 14 Aug '11

14 Aug '11

Hello, I had given a lecture about the Boost.Locale library at the annual Israeli FOSS conference "August Penguin". The slides can be found there: - http://art-blog.no-ip.info/files/August-Pinguin-Boost-Locale.pdf - http://art-blog.no-ip.info/files/August-Pinguin-Boost-Locale.odp I hope the video would be available soon. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

2 2

Introduction
by Andrew Hundt 14 Aug '11

14 Aug '11

Hi everyone, I'm Andrew Hundt and I've been doing C++ development for about 3 years. I've also been following the boost mailing lists for about the last two years. I've occasionally asked questions on this list during that time, but I've never introduced myself. I'm at Carnegie Mellon University in a staff position, and I have some possible contributions based on my work there that I've been hoping to at least gauge interest on. However, I wanted to introduce myself first, so greetings! Cheers! Andrew Hundt

2 1

[uuid][release] Changelog for 1.47.0 does not properly warn about critical bug
by Eric Niebler 13 Aug '11

13 Aug '11

Cross-posting to the developers list, fixing the title. This sounds like a serious bug, possibly worthy of a point release. Can anybody confirm and chime in? On 8/5/2011 4:20 AM, Paul Harris wrote: > Hello, I discovered this bug by accident > https://svn.boost.org/trac/boost/changeset/68866 > which was only linked via the ticket mentioned below, > > The code below demonstrates that ANY wide-character string of the same > length resolves to the same UUID ! > > Thats pretty darn serious, I expected to see a much more serious mention > in the Changelog in boost 1.47.0... for UUID, there was only a mention > of a few tickets > including this one: > https://svn.boost.org/trac/boost/ticket/5145 > which only mentioned a WARNING in the description ! > "Fixed warning: use of logical && with constant operand; switch to > bitwise & or remove constant [-Wconstant-logical-operand]" > > Surely it should say something like "UUIDs for wide character strings > are totally wrong" > > Note also that the Changelog link for UUID goes to Utility, not UUID. > > > The code: > > > #include <boost/uuid/name_generator.hpp> > #include <boost/uuid/nil_generator.hpp> > #include <boost/uuid/uuid_io.hpp> > #include <iostream> > > using namespace boost::uuids; > using namespace std; > > int main() > { > { > cout << "WIDE" << endl; > const wchar_t* a = L"one long string that is something like this > and that blahh"; > const wchar_t* b = L"hello there you long long string that looks > nothing like t"; > > nil_generator nil; > name_generator na(nil()); > name_generator nb(nil()); > > uuid ua = na(a); > uuid ub = nb(b); > > cout << to_string(ua) << endl; > cout << to_string(ub) << endl; > } > > { > cout << "NARROW" << endl; > const char* a = "one long string that is something like this and > that blahh"; > const char* b = "hello there you long long string that looks > nothing like t"; > > nil_generator nil; > name_generator na(nil()); > name_generator nb(nil()); > > uuid ua = na(a); > uuid ub = nb(b); > > cout << to_string(ua) << endl; > cout << to_string(ub) << endl; > } > > return 0; > } > > > > the result: > > $ g++ main.cpp && ./a.out > WIDE > 4ffa48af-9685-5089-97ac-fe6627ead94c > 4ffa48af-9685-5089-97ac-fe6627ead94c > NARROW > 73030b72-a864-5c7b-9963-c0bedff1283e > da8943a6-26c9-5641-bd37-427b1b70d619 > $ > > > The two different wchar_t strings resolve to the same uuid !!! > > What am I doing wrong? > > thanks > Paul -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[serialization] overloading load_construct_data: no accessible constructor at all
by Griffin Howlett 13 Aug '11

13 Aug '11

Hey, so I'm using the boost::serialization library, and I'm trying to override how a class is constructed, since it has no default constructor. This is demonstrated here<http://www.boost.org/doc/libs/1_47_0/libs/serialization/doc/serialization.h…>. To me it appears the function ONLY takes the `class* t` and then sets it to point to a newly constructed object. If I'm wrong, this is definitely the source of my error. However, the only way to construct my class is by using another classes `create()` function, meaning I need to stray from the code in the example (this is stated in the boost::serialization namespace): `::new(t)my_class(attribute);` I tried simply calling the create function and setting `t` equal to the returned pointer, but this doesn't seem to work because right after the `load_construct_data function`, and in the `serialization function`, the given `myClass&` is not the same as what I set 't' to. *How do I do whatever ::new(t) is doing so the object created using the create function follows through into the serialize/other functions?* [1]: http://www.boost.org/doc/libs/1_47_0/libs/serialization/doc/serialization.h…

2 1

[thread] basic mutex problem
by Greg Rubino 13 Aug '11

13 Aug '11

Hi Boost.Thread maintainer(s)/expert(s)/user(s) like me, I'm having an issue with boost::mutex. I'm not really an expert in concurrency, and there's something wrong with my thread_db library, so I'm having some trouble debugging (for now). I tend to think it's something in my code, but I thought maybe someone on the list would take a look at it. The code is pretty minimal, but let me know if I should reduce it further. I'm leaving out the #includes, because I'm pretty sure those are ok: using namespace std; using namespace boost::phoenix; namespace phoenix_args = boost::phoenix::arg_names; namespace posix_time = boost::posix_time; boost::mutex g_mutex; struct random_activity_planner { random_activity_planner(vector<activity>& a, posix_time::ptime o) : activities(a) , origin(o) {} void operator()() { g_mutex.lock(); posix_time::ptime start(origin + posix_time::seconds(rand() % 1000)); posix_time::ptime end(start + posix_time::seconds(rand() % 1000)); activities.push_back(activity(start, end)); g_mutex.unlock(); } vector<activity>& activities; const posix_time::ptime& origin; }; int main(int argc, char** argv) { if(argc != 2) return 1; size_t activity_count = boost::lexical_cast<size_t>(argv[1]); vector<activity> activities; boost::thread_group random_activity_planners; posix_time::ptime origin(posix_time::second_clock::universal_time()); srand(time(NULL)); for(size_t i = 0; i < activity_count; ++i) { random_activity_planners.create_thread(random_activity_planner(activities, origin)); } random_activity_planners.join_all(); cout << "all activities: " << endl; for_each(activities.begin() , activities.end() , cout << phoenix_args::_1 << endl); vector<activity> schedule; greedy_activity_selector(activities.begin() , activities.end() , back_inserter(schedule)); cout << "scheduled activities: " << endl; for_each(schedule.begin() , schedule.end() , cout << phoenix_args::_1 << endl); return 0; } [END] The problem is that the last "activity" is not being pushed onto the shared vector in the . I'm sure there are some stylistic problems with the code, but its purpose is just to demonstrate an algorithm. At the following for_each() call: for_each(activities.begin() , activities.end() , cout << phoenix_args::_1 << endl); I find out, via a gregorian::bad_year exception, that the final activity has not been initialized. I have omitted the definition for activity, but it's pretty simple. It has only one member (a posix_time::duration that defaults to neg_infin => pos_infin ), which is why I suspect that the final call to random_activity_selector::operator() is not completing before the for_each() call that succeeds it in the source. I thought that join_all() would prevent this from happening. Is there something wrong with my code? I left some stuff out, because I didn't want to inundate the reader with irrelevant details, so please let me know if I left out anything crucial. Also, I am aware that I don't need to be using threads here, but I am, and I don't understand why it's not working. Thanks! Greg

4 6

enable_if and non-template member functions?
by John Maddock 13 Aug '11

13 Aug '11

Folks, I have a problem with enable_if: it works just dandy for template member functions in my class, but I have some *non-template* member functions and constructors that I want to enable only if the template is instantiated with template args that meet certain criteria. Seems like I can't do this with enable_if as it then generates an invalid class definition. I guess I could use base classes, and/or partial specialization, but both involve a lot of code duplication I'd rather not have. Anyone any ideas? Thanks, John.

11 21