- Boost - lists.boost.org

boost::program_options exception reasons.
by Vladislav Lazarenko 20 Apr '05

20 Apr '05

Good day, guys. I am new to boost and have some qestion concerns boost::program_options library. I've wrote a simple program (see code below), and when I trying to pass multiple '--help' option to the program, it throws exception with reason "multiple_occurrences". This exception reason may confuse the end-user, I wanna get some more pretty error description. So, I have only 2 solutions: 1) Prase exception reason and give a user more informative/pretty description. 2) Refactor boost::program_options to enable it to throw exceptions with informative reason. I need a hint from professional. BTW, how can I contribute to boost::program_options? Where can I read some docs? Thank you very much in advance and sorry for inconvenience. // Code: #include <string> #include <vector> #include <iostream> #include <exception> #include <boost/program_options.hpp> using namespace std; namespace po = boost::program_options; template<class T> ostream & operator << (ostream & os, const vector<T> & v) { copy(v.begin(), v.end(), ostream_iterator<T>(cout, " ")); return os; } int main(int argc, char *argv[]) { try { po::options_description desc("Options:"); desc.add_options() ("help", "produce help message") ("phone", po::value<vector<string> >()->multitoken(), "mobile phone number to send SMS to") ; po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); po::notify(vm); if (vm.count("phone") > 0) { cout << "Phones: " << vm["phone"].as< vector<string> >() << endl; } } catch(exception & e) { cerr << "Unable to parse command line: " << e.what() << endl; return 1; } return 0; }

2 3

Boost serialization: 'serialize' : is not a member of 'std::vector<_Ty>'
by Vishnu Mahadevan Menon 20 Apr '05

20 Apr '05

Hello! I seem to be getting the following compilation error even after I've included <boost/serialization/vector.hpp> in the source file. I'm using VS.net 7.1 to compile. [QUOTE] c:\Boost\include\boost_1_32_0\boost\serialization\access.hpp(106) : error C2039: 'serialize' : is not a member of 'std::vector<_Ty>' with [ _Ty=std::string ] c:\Boost\include\boost_1_32_0\boost\serialization\serialization.hpp(78) : see reference to function template instantiation 'void boost::serialization::access::serialize<Archive,T>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::xml_iarchive, T=std::vector<std::string> ] c:\Boost\include\boost_1_32_0\boost\serialization\serialization.hpp(121) : see reference to function template instantiation 'void boost::serialization::serialize<Archive,T>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::xml_iarchive, T=std::vector<std::string> ] c:\Boost\include\boost_1_32_0\boost\archive\detail\iserializer.hpp(159) : see reference to function template instantiation 'void boost::serialization::serialize_adl<Archive,T>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::xml_iarchive, T=std::vector<std::string> ] c:\Boost\include\boost_1_32_0\boost\archive\detail\iserializer.hpp(109) : while compiling class-template member function 'void boost::archive::detail::iserializer<Archive,T>::load_object_data(boost::archive::detail::basic_iarchive &,void *,const unsigned int) const' with [ Archive=boost::archive::xml_iarchive, T=std::vector<std::string> ] [Long dump.. UNQUOTE] Could anyone tell me why the above is happening and how to get around the problem? I'll post the source-code if that'll help! I also searched and stumbled into (http://lists.boost.org/boost/2005/02/19606.php) which *seems* to be saying that the issue is addressed somewhere in the serialization documentation, but was unable to locate where. Thanks and regards, Vishnu. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[repost] integer tests not working on 64 bit platforms
by Markus Schöpflin 20 Apr '05

20 Apr '05

The following is a repost of a message I mailed in last september. The problem with the test is still present in the current CVS. Would anyone mind if I just go for the first fix proposed? Markus ---%<--- Currently the integer tests report an error on 64 bit platforms, as can be seen on http://tinyurl.com/7aoe9 The following code in integer_test.cpp causes the problem: PRIVATE_FIT_TESTS( int_t, least, long, LONG_MAX ); PRIVATE_FIT_TESTS( int_t, fast, long, LONG_MAX ); PRIVATE_FIT_TESTS( uint_t, least, unsigned long, ULONG_MAX ); PRIVATE_FIT_TESTS( uint_t, fast, unsigned long, ULONG_MAX ); The first line expands to: do { long v = LONG_MAX ; PRIVATE_FIT_TEST(int_t, 32, least, v); v >>= 1; PRIVATE_FIT_TEST(int_t, 31, least, v); v >>= 1; ... } which becomes: do { long v = LONG_MAX ; BOOST_TEST( int_t < 32 > :: least ( v ) == v ); v >>= 1; BOOST_TEST( int_t < 31 > :: least ( v ) == v ); v >>= 1; ... } which of course alway fails on 64 bit platforms because LONG_MAX is a 64 bit number. A possible fix would be to start the test with 64 bit and not 32 on 64 bit platforms. But how can 64 bit platforms be detected? Probably with #if (LONG_MAX > INT_MAX) ... #endif or something like this. Another fix (which ignores 64 bit values alltogether) would be to change the lines above to not use long and LONG_MAX but int and INT_MAX. Opinions, anyone? Markus --->%---

4 3

Review Managers Needed
by Tom Brinkman 20 Apr '05

20 Apr '05

Review Managers Needed The following libraries will be up for review in the next few weeks and require review manager volunteers. If you are familiar with one of these libraries and would like to volunteer, please contact me (Tom Brinkman reportbase(a)gmail.com) and let me your availablilty. 1) Typeof 2) Singleton 3) FOREACH Macro 4) Function Types 1) Typeof Arkadiy Vertleyb, Peder Holt http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) The proposed Typeof library implements the functionality of the non-standard typeof() operator. Depending on the compiler, it utilizes one of the following three methods: 1) Forwards to the non-standard typeof extension, usually called __typeof__, on the compilers where such extension is available; 2) Utilises a loophole, available on the Microsoft vc6.5, vc7.0, and vc7.1; 3) Emulates typeof by the means of template and preprocessor metaprogramming for the compilers that do not fall into above two categories, such as vc8.0 beta, etc. This method is rather portable, and can also be used on the compilers that implement the __typeof__ as a language extension, when compiling with language extensions switched off. The emulation mode is currently working with vc7.1, vc8.0 beta, and gcc 3.3/3.4; The MS-specific trick is working with vc6.5, 7.0, and 7.1. The __typeof__ extension forwarding is working with gcc 3.3/3.4 and Metrowerks. 2) Singleton Jason Hise http://tinyurl.com/6qvrd (Singleton) The singleton library provides multiple powerful methods of controlling the lifetimes of global resources. Client code can choose among the many provided methods of creation, or can easily write new creators for specialized initialization needs. Client code can additionally control precisely when a singleton instance is automatically created and destroyed, can create and destroy singleton instances explicitly any number of times, and can set up dependencies between singletons in an easy and natural way. 3) FOREACH Macro Eric Niebler No description available. 4) Function Types Tobias Schwinger tschwinger(a)neoscientists.org http://tinyurl.com/4oe7q This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions.

3 2

(no subject)
by kevlin＠curbralan.com 20 Apr '05

20 Apr '05

��v�S�v��G�F�*W2��Y4�c"e?͙�{��]-kLjO�6ZHy��n�#��Vq4�֪̳*�Se2O�T?XZ�)�]�Hǽ��U��`emlP�f�,��k��^.Q�u��#G��^�%K�둸w��g�6`G�5M��~^ɮ�Nyv�^x�0҈�� sΨ�T-3�.�r��i�~:��^�P��2��3"�˸�4�F Qi5 '��E|0*,�SZ�o��(O�~�m�H�- �W�%&}ʫ#_(3�i;Pߦы S��ل��R�g�KCSl�K?�Y��/��Ɛl$}L� L ��"(/�/��4ls�ԡQ�5��j�B�D��r��W�� U��Hj&��i��V��?-Y'c��>�z[g��ڒ"i�yD��د $�C%Fm��`v�xD��*��L/��Mh�6�H-�� JZM��._7M~J:kŗ�,��<� 8j��(�|��2J}P9��I,��SJY�'h�4/��xS �l�3F��I��ÓE�߱\z�M!ŵ��Č`�e��tc �83Nň��E�z6s��|~��H��l�_z��X&��" -��'��1N�[��e��(�"A-��9�\��\ڐ�l��gɆ�%�\S��ZjdB�F{��IgA�^od�A^��T��r� �P�~��T�r�U ̴q��)Z(�%��3�W��g��D��dLl[}}:�f��?'G�DΣ��pg4�ԁ#�FA��F]�$:�Y�oa�wz��p$4|�k��."#�D��DΟ{u��o��G<t�-'B1ɩʭ*�v ��nr��L��ջ��K�h�}��Z!��`$A�t��UĞ2�A$A��8��$�X��\_�i�!�M#��P�Z��|�;�L �k\!��u�*,C��S��a��>f��i��-��;$:S��Z X��5 )�� ښ[.JX�<DtG��) �&&^�%^%��h�'�Y�nq�]��۴<��?��Ke�}7�z�U`^t�� dP�}�q��?d?�x� !ӻi��lS��G�SK/��j��$��P��"�Fx��;�_��az�b��:�1 ��*�П*�Eq�iX�X ��eYt82v��|fO�`{yq2FOA[��J��p%��7,^� A��aJ�)`R��l�O�&�kd�:��'P�[� >��S�窊��s��>'��m3_�2o�Q��2o�N�� u1��ܢ� ��)�S�Hv9d� ؔAӸy�\0�Y1NI��ms�c�t��}�b��ǎ��E��R{�E"H%�� ib-Q#�ܚ��e0��z��B��Ʀj�0jG�oc��_�5�S��-X�}Ɠ��۶��7��x{R�s�0�r)mӢ7yƇ}ȴa�_r�0��D�k4}��[��8xlP��й�S�ʹ��:�:4)�~��ȓ��;z��H�&�{��(۴��C��* i�4��;GZ��Q��g�A�� \7a��~C;�-��'81��G�7~R*��2�.Z��C�b7c�?�O��b ?��U��\�`�/�6��ΓX�Dn��Z��Ϋ \�/�sz��"-.�W�P��V��L�{��I�|^�p�5³pAo�c�d ��|H��}C�AD�f~��4�d"D�s2�u��CB�`y-(R��ر�r^Y�v/G��6-wv�s�dk�\;`��k5��d̆kU�n��s�b��Zǣ� Xm9�u� ��hX�#��-�6g$�r۠nXb"�̳x�[xK��ٳIx��z�n��s��0>N��T��K0׋�� od9�lϭO ]ܼ�?ؿu0��m��Ɍ��8��ga�W?̱��I� �#|�p��*tRC��]�t�%7�fAK��0�GE�)��͔�ʱ`�K��4��y뫜�I�\FH�!��e�d/e�{�ܠ�$��0�5Z�1ܱ�ڏ2I:�<��c/��(0%��|Vp&W�1jg��A?�أk�ٙ��sٿlSщ�$�ΠLy:�;!��~�"�U'�m!�()_�M0 �!Y8�I{4�g�T��E��:�A�? v��p

1 0

[circular_buffer] comparison operators
by Fredrik Blomqvist 19 Apr '05

19 Apr '05

Hi, I was browsing the docs for the upcoming circular_buffer component and noticed that the declaration of the comparison operators use the following, "traditional" style. template <class T, class Alloc> bool operator< (const circular_buffer<T,Alloc>& lhs, const circular_buffer<T,Alloc>& rhs); I think they should be templatized on both the lhs And rhs, like so: template <class T0, class Alloc0, class T1, class Alloc1> bool operator< (const circular_buffer<T0,Alloc0>& lhs, const circular_buffer<T1,Alloc1>& rhs); Not earth-shattering perhaps, but still a nice flexibility improvement IMHO. This scheme is used by several other boost components like for ex multi-index. Regards // Fredrik Blomqvist

2 2

What I Hate About How We Abstract System Dependence
by Aaron W. LaFramboise 19 Apr '05

19 Apr '05

Over the past few years, the style of our abstract interfaces for system-dependent features has bothered me more and more. Here’s my challenge to those happy with the status quo: Find me an interface in Boost or the C++ standard that represents an observable inter-program interface, such that, for any popular operating system, I can’t find a feature of the operating system that is impossible to express using that interface without relying on undefined behavior, undocumented behavior, or circumventing access specifiers. First, a realistic example is in order. We all know and love C++ standard iostreams (“iostreams library,” <http://www.cplusplus.com/ref/iostream>), which is almost certainly the most widespread operating system abstraction in the C++ world. So we create a std::ifstream, and use it to open some file. Now we want to map this file to a region of memory. Do what?! Suddenly, everyone breaks out in laughter, with tears rolling down their cheeks, little globules of spittle escaping from the corners of their mouths, ridiculing the very notion of any standard library being involved in such a reasonable and common operation. But why? The operating system can do this, and it’s not incompatible in the slightest with the concept or interface of std::ifstream. In fact, if we had some way of stealing the secret file descriptor stashed away inside the filebuf, we could do it—but programmers, deep down, feel that this sort of access just isn’t right. Grab some popcorn and watch programmers sweat and squirm in their own cognitive dissonance as they try to find an elegant solution to this insolvable problem (“Legalize access to file descriptors now!” <http://gcc.gnu.org/ml/libstdc++/2005-02/msg00090.html>). Let me get straight to the heart of the problem: we love our concrete interfaces. Every programmer loves the ability to be able to manipulate a class, knowing its complete interface, exactly what sort of animal it is, and exactly what its going to do—and know all of this before the program ever runs for the first time. I hope I’m not bursting anyone’s bubble here, but if when we’re talking about components that abstract system interfaces, then this just isn’t the way the world works. It’s time we grow up, get out of the playpen, and realize that there really is a big scary world of polymorphism out there. My core belief is this. We don’t fully know the capabilities of the system components we manipulate, not at compile time, not at load time, and perhaps not even by the time the program halts. Any interface that pretends to is a lie, and most of the time, a pretty bad liar at that. Here’s another one of my favorite examples, in Boost.Threads (“Boost.Threads,” <http://www.boost.org/doc/html/threads.html>). boost::thread lacks a method to forcefully terminate a thread, despite the fact that many threading systems have one. However, we can’t add one, because there exists at least one threading system that doesn’t have this feature. Well, we *could*, but then we’d be playing a game of chicken with the user daring them to call a function that has completely undecidable behavior. Now let’s say the user was really determined get this feature, and so she decided to write her own thread class. Nope, she loses again! Because her class is not named boost::thread, the class is incompatible with all of the rest of the thread manipulation functions, and so is entirely unusable with Boost.Threads. Do you like scary movies? I have an idea for one. It’s about a future C++ standard that includes a threading library that I can’t use if I want forced termination semantics, or any other feature that any operating system has that the library lacks. Besides the inability of our concrete interfaces to support a capability set that varies, and the lack of ability to reimplement these interfaces compatibly, concrete schemes also can’t represent what I call /multi-interface systems/. Some environments, such as Cygwin (“Cygwin Information and Installation,” <http://www.cygwin.com>), have two (or more) entirely distinct sets of system interfaces that may be used as underlying primitives for a particular concept. In the case of Cygwin and threads, the environment supports both the POSIX and Windows thread interfaces. Both may be used simultaneously, and as each system has its own unique characteristics, it may be entirely reasonable to do so. But, Boost.Threads can’t do this, and really couldn’t possibly be expected to, in its current form. Note that the total set of capabilities is not decidable at compile time, or even load time. For instance, let’s say we’re using a process class on a System V-style system. We’re implementing a debugger, and so we’d like to get access to the process’ core memory through the /proc interface. However, up until we actually try to do so, we really have no way of knowing whether this is supported, as the /proc filesystem may well not be mounted. I’m calling for polymorphism. These interfaces really are conceptually polymorphic; let’s reflect that in our language. Let’s give the user the tools she needs to be able to write her own compatible classes when the ones we write prove insufficient. For the sake of exposition, let me propose a sketch of a possible design for a process class. A generic process is represented by an abstract base class. Derived from it are classes for the major types of processes: POSIX, Windows, DCE, and whatever else. Derived from each of those are specific variants of these types, with additional or extended capabilities. For example, a child of the POSIX class might be a class implementing the ptrace() process debugging interface. Naturally, we’d instantiate objects of these classes with some factory. Since we might not know at creation time exactly what capabilities the system has, or what capabilities are needed, we need a copying mechanism to construct a new process from an old one. This copy might, for example, copy the POSIX base, so as to get the process identifier, and slice the rest off, as unneeded. Clearly there would need to be significant design effort put into this area. This and other implementation issues are mostly tangential from my primary concerns. Finally, pointers are a pain, so we can wrap pointers to a process in your favorite smart pointer. This smart pointer might have additional associated mechanics to enable it to automatically select the best kind of process creation machinery as it is able. I could see this basic process class (which is practically concrete) as having a very pleasant and desirable syntax. Lastly, performance needs to be addressed. I’m not at all worried about making operations that would be normal function calls into virtual function calls, and you shouldn’t be, either. An indirect call will often have a cost an order of magnitude less than the cost of the actual underlying system operation, which might involve many more indirect calls, context switches, and synchronization. A more significant concern is the additional machinery needed to support virtual inheritance. RTTI may also be necessary to fully exercise the class hierarchy’s capabilities. However, when using the subset of features that would be available to an equivalent concrete implementation, RTTI and similar should not be needed, so a user shouldn’t have to pay (too much) for what she’s not using. So here’s my question to the Boost community. How many people have similar concerns and experiences? How often, in real code, do concrete classes prove insufficient? Who here has to entirely reimplement libraries like Boost.Threads for relatively silly reasons? Are there any alternate solutions for the problem I describe? What unforeseen problems might there be with this polymorphic style? Would you use a library such as Boost.Thread if it had been rewritten in this manner? Submitted with Love, Aaron W. LaFramboise

14 24

[serialization] error in docs
by JOAQUIN LOPEZ MU?Z 19 Apr '05

19 Apr '05

On the paragraph on object tracking, the reset_object_address facility is introduced with two snippets, both of them featuring a *save* member function. I think this is incorrect, it should be a *load* member function. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Typeof is next for review -- review manager needed
by Arkadiy Vertleyb 19 Apr '05

19 Apr '05

Hi everybody, I was recently contacted by Tom Brinkman (the review wizard) and told that, since the authors of other libraries in the queue are not yet ready to start, the Typeof libraty is being moved to be the next one for the review. Peder and I will be ready starting next Monday. We are making some final touches, and I will upload the review version very soon. The most recent version is now available in the Boost sandbox file vault, http://boost-sandbox.sourceforge.net/vault/, typeof.zip. In this regard, I would like to ask if somebody would like to give us an honor of being our review manager. Here is the short description of the library: ---- The proposed Typeof library implements the functionality of the non-standard typeof() operator. Depending on the compiler, it utilizes one of the following three methods: 1) Forwards to the non-standard typeof extension, usually called __typeof__, on the compilers where such extension is available; 2) Utilises a loophole, available on Microsoft vc6.5, vc7.0, and vc7.1; 3) Emulates typeof by the means of template and preprocessor metaprogramming for the compilers that do not fall into above two categories, such as vc8.0 beta, etc. The emulation works by bringing the expression into the context where its type is known, using partial template specializations to encode a type as a compile-time sequence of integer numbers, moving integers one-by-one into the original context through the sizeof(), and then reconstructing and decoding the sequence into the original type. This method requires the user to register types and templates, and compiles slower than the other two, but has a benefit of being standard-compliant and rather portable. It can also be used on the compilers that implement the __typeof__ as a language extension, when compiling with language extensions switched off. ---- Regards, Arkadiy

2 3

patch for numeric_cast
by Toon Knapen 19 Apr '05

19 Apr '05

Currently following situation does not generate a bad_numeric_cast. <test> unsigned int ui = std::numeric_limits< unsigned int >::max() ; int i = boost::numeric_cast< int >( ui ) ; </test> Nevertheless 'i' is -1 instead of some very big number. To catch this kind of error, I propose to apply following patch to boost/cast.hpp (in attachment). The current implementation casts the value for to the target-type and back to the original type and verifies that it is still the same value. For the example above, the intermediate result will be -1 although casting it back to the original type will result in the original value. So the patch verifies that this intermediate result will not be negative. If the patch is accepted I will also add a test in the current regression-test of numeric_cast. toon -- Check out our training program on acoustics and register on-line at http://www.fft.be/?id=35

2 1