October 2008 - Boost - lists.preview.boost.org

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

[interprocess] message_queue hangs when another process dies
by Sergei Politov 03 Nov '11

03 Nov '11

Hi, I have found the following problem with message_queue on win32 (MSVC 2008 + Windows Vista). Suppose we have 2 processes, one sends messages to queue, another reads them. When reading process dies (for instance using End process) during message_queue.receive the another process hangs in send. As I found during investigation, it tries to lock interprocess mutex, but it is already locked by dead process. So this message queue instance becomes unusable. I attached the example. Steps to reproduce: 1) Start "mq.exe s" (i.e. with argument s) It outs: sender: $PID 2) Start mq.exe without arguments. It outs: receiver: $PID 0 1 2 3 4 This time sender outs: send done: 3) At this point the message queue is empty and receiver waits for messages. End it with Task Manager. 4) Enter some number in sender console and press Enter. 5) The sender hangs in message_queue.send Best Regards, Sergei

6 13

Re: [boost] [date_time] Time zone improvements
by Rutger ter Borg 25 May '11

25 May '11

Jeff Garland wrote: > Very cool :-) One question -- is there a portable solution where a user > could deploy a files onto a Windows system or is it a Unix only solution? > I'm fine with incorporating a *nix only solution because what your > suggesting will be a nice solution for *nix platforms, but it will need to > be clear that it's not portable. I don't see why it wouldn't be possible to deploy the (big-endian) binary files to any platform. Getting it into this binary form (using zone info compiler zic) may be harder to do cross-platform, but cygwin may help here. [snip] > As the primary maintainer of Boost date-time I can say with certainty that > there is interest in this functionality -- it's long been on my todo list > and I haven't had time to get to it. You can email me privately and we > can discuss all the details of how to get your code incorporated. I'll do! Regards, Rutger

5 9

[serialization] boost/serialization/path.hpp
by Johan Råde 21 Feb '11

21 Feb '11

There is no boost/serialization/path.hpp. I suggest the following: ---------------------------------------------------------------------------------------------------------------- #ifndef BOOST_SERIALIZATION_PATH_HPP #define BOOST_SERIALIZATION_PATH_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) #pragma once #endif #include <boost/config.hpp> #include <boost/filesystem/path.hpp> #include <boost/serialization/level.hpp> BOOST_CLASS_IMPLEMENTATION(boost::filesystem::path, boost::serialization::primitive_type) #ifndef BOOST_NO_STD_WSTRING BOOST_CLASS_IMPLEMENTATION(boost::filesystem::wpath, boost::serialization::primitive_type) #endif namespace boost { namespace serialization { template<class Archive, class String, class Traits> void serialize(Archive& ar, boost::filesystem::basic_path<String, Traits>& p, const unsigned int version) { String s; if(Archive::is_saving::value) s = p.string(); ar & boost::serialization::make_nvp("string", s); if(Archive::is_loading::value) p = s; } }} #endif //-------------------------------------------------------------------------------------------------------------- Comments? Any suggested improvements? --Johan Råde

5 11

[process] How to run test cases
by Boris 23 Jan '11

23 Jan '11

As Boost.Process 0.3 has been released it would be great if the test cases are run on various platforms. So far I've tested Boost.Process on WinXP with MSVC 9.0, Cygwin with g++ 3.4.4 and Solaris with g++ 3.4.6 and Sun C++ 5.9. To make it as easy as possible for others to run the test cases here's a short description of how to proceed. Nearly all test cases depend on a program called "helpers". This program is built first and is started by many test cases as a child process. In order to find the program "helpers" the test cases must know its location. As there is no way to get the location at runtime it is hardcoded in the file libs/process/test/misc.hpp. As the location differs depending on what compiler is used YOU MUST CHECK FIRST THE PATH IN libs/process/test/misc.hpp! Otherwise most of the test cases will fail as they look for a program "helpers" in the wrong directory. As of today only those paths are correct and have been tested which are set for Windows, Cygwin and Solaris. Only after you have checked and maybe updated the path in libs/process/test/misc.hpp you should try to build and run the test cases: WinXP/MSVC 9.0 ************** With MSVC 9.0 you only need to open the Visual Studio 2008 Command Prompt, change to the directory with the test cases and run bjam: C:\boost_1_36_0\libs\process\test> ..\..\..\bjam.exe -q Cygwin/GCC 3.4.4 **************** On Cygwin it's important to know if the Boost libraries have been built for the POSIX or Windows API. By default Boost libraries on Cygwin use the Windows API. With the Windows API the Boost.Process test cases are not passed successfully though (there are compiler errors where I'm not sure currently if they are a Boost.Process problem and how they could be fixed). If you want to run the test cases on Cygwin you must (re-)build the Boost libraries to use the POSIX API: $ cd ~/boost_1_36_0 $ ./bjam cxxflags=-DBOOST_POSIX_API Afterwards you can run the test cases: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam cxxflags=-DBOOST_POSIX_API -q Solaris/GCC 3.4.6 ***************** At first you have to put the following line in ~/user-config.jam: using gcc : : : <linker-type>sun ; Then start building the Boost libraries: $ cd ~/boost_1_36_0 $ ./bjam --toolset=gcc cxxflags=-mcpu=ultrasparc For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. Afterwards the test cases can be run: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=gcc cxxflags=-mcpu=ultrasparc -q Solaris/Sun C++ 5.9 ******************* Build the Boost libraries with the sun toolset: $ cd ~/boost_1_36_0 $ ./bjam --toolset=sun stdlib=sun-stlport For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. If you run the test cases now you'll get this compiler error for one test case: "../../../boost/asio/detail/socket_ops.hpp", line 218: Error: Cannot assign void* to char*. "../../../boost/asio/detail/socket_ops.hpp", line 229: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 66: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 72: Error: Cannot assign void* to char*. The bug has been reported to the Boost.Asio mailing list. If you want to build that one test case, too, you need to fix the two files in Boost.Asio 1.36.0 yourself. All the test cases can be built and run with: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=sun stdlib=sun-stlport -q

4 9

[asio] read_until -- possibly misleading documentation?
by Richard Smith 15 Apr '10

15 Apr '10

The documentation for Boost.ASIO (which is otherwise very comprehensive) says of the boost::asio::read_until set of overloads: | Read data into a streambuf until a delimiter is | encountered. <http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/reference/read_unt…> What the function actually does is to read blocks of data into the streambuf, and stop when the delimiter is found. This means that frequently data beyond the delimiter will be read into the streambuf. (And this is elaborated in more detail on the individual function's pages, if a reader looks there.) I appreciate that this behaviour is compatible with the documentation, but someone less familiar with ASIO could easily assume that the function will read as far as the delimiter and no further. (And I have just spent a fair amount of time debugging a piece of code where the author had made this assumption.) Could we change the summary documentation to read something like: | Read data into a streambuf at least until a delimiter is | encountered. The implementation may read beyond the | delimiter, but will not block when doing so. While I'm on the subject of ASIO documentation, I can't see any documentation on whether the service_name parameters to the basic_resolver_query constructors are allowed to be port numbers (e.g. "80") or whether they have to be symbolic names (e.g. "http"). Port numbers work, at least on Linux, but it's not clear whether this is something that I should be relying on. Similarly for IPv4 and IPv6 addresses in the host_name parameter. Richard Smith

3 2

[TypeTraits] is it possible to add something to boost.type_traits?
by frederic.bron＠alcan.com 17 Dec '09

17 Dec '09

Dear boost implementers, TypeTraits is very useful, thanks you. However, recently, I needed something to know if a type is comparable (with operator<) and that was not in the library. Fortunately, somebody forwarded me an earlier post on the users list where I could find what I wanted. The implementation was inspired from boost/detail/is_incrementable.hpp I have written is_less_comparable, is_less_equal_comparable, is_greater_comparable... inspired from the same source and I wonder if it could be possible to add it to the library as I think it could be helpful for others. I give the source code below (if it is useful) but I am not able to make it fully general as it is in boost/type_traits. In particular, I do not understand all the macros that are used. Regards, F. Bron (See attached file: is_comparable.hpp) Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

11 23

Mark throw_exception as noreturn?
by Andrey Semashev 05 Jul '09

05 Jul '09

Hi, I was wondering why the throw_exception function is not marked as noreturn? This makes it troublesome to use it as a drop-in replacement for throw statements as it starts to flag compiler warnings about missing return statements in non-void functions. I suggest to mark the function as noreturn at least for compilers that support it. GCC has __attribute__((noreturn)), MSVC has __declspec(noreturn).

4 6

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

4 18

[mpl] is there a or_seq like logical metafunction?
by vicente.botet 17 Jun '09

17 Jun '09

Hello, I needs calculate the mlp::or_ of a sequence of nullary logical metafunction. This seams quite simple. I have do the following: <code> template <typename Seq> struct or_seq; template <typename Seq, long N> struct or_seq_aux : mpl::or_< typename mpl::front<Seq>::type, or_seq<typename mpl::pop_front<Seq>::type> > {}; template <typename Seq> struct or_seq_aux<Seq, 1> : mpl::front<Seq>::type {}; template <typename Seq> struct or_seq : or_seq_aux<Seq, mpl::size<Seq>::value> {}; </code> Is there a boost or_seq like logical metafunction? Is there a better way to do it? I would be extremely interested in any suggestions. Best regards --------------------------- Vicente Juan Botet Escriba

5 34

Proposed templated integer_sort
by Steven Ross 25 Apr '09

25 Apr '09

Would there be interest in an integer_sort call that is faster than std::sort? Spreadsort is an in-place hybrid radix-based and comparison-based algorithm with better worst-case and average-case (roughly 20-50%) performance than introsort on random integer data. The worst-case advantage is algorithmic, with Spreadsort taking the better of O(n(square_root(bit_sizeof(data) - log(n)))) and O(nlog(n)) time. For 32-bit integers, that's O(n(square_root(32 - log(n)))), so for a log(n) of 16 (65536 items), it's 4n (plus a small constant times n), vs 16n for introsort. For larger n, the advantage vs. pure comparison-based algorithms increases. In effect, Spreadsort smoothly transitions from pure MSB Radix sort to std::sort with its data cut up by a couple iterations of MSB Radix sort (reducing the size of the log(n) factor), depending upon the distribution and size of the data. I could write a templated version of Spreadsort for the Boost library if there is interest. It would work for anything that supports the << and - operators. It could also handle standard floats sorted as integers. Functors supporting << and - could make it more general. Multi-dimensional sorting is also sped up by Spreadsort. I could also write a similar string_sort, that should also be significantly faster than std::sort. This would look much like postal sort, just using introsort after a certain number of iterations. Is this of interest? http://sourceforge.net/projects/spreadsort

15 118

Boost.Process 0.3 released
by Boris 14 Apr '09

14 Apr '09

I've released Boost.Process 0.3. Here's the documentation and a link to download the zip archive: Docs: http://www.highscore.de/boost/process/ Code: http://www.highscore.de/boost/process.zip It's a header-only library and thus pretty easy to use: Just copy the files to your Boost directory. In this release my main goal was to merge various snapshots: * There was my Boost.Process 0.2 version which was based on Boost.Process 0.1 from 2006. * There was a post-0.1 version of Boost.Process in SVN from 2007. * Chris Fairles had modified a Boost.Process snapshot for Unix platforms. * Ion Gaztañaga had also some ideas and bug fixes he sent to this mailing list recently. I just saw that Ilya Sokolov created another snapshot based on Boost.Process in SVN. That means we have again at least two different versions of Boost.Process. :-/ In my Boost.Process 0.3 version I concentrated on merging and overhauling code. I did not change the design but tried to make the code work: All the code which was written since 2006 should become usable. That's why I also concentrated a lot on test cases. There are quite a lot of test cases, and they all can be built and passed successfully on three platforms with four compilers. As it would be great if others run the test cases, too (ideally on new platforms), I'll send another message in a few minutes with a description how to run the test cases yourself. As the documentation was written in 2006 I also updated it. It's not yet really a good documentation: There are some files coming from 2006 while other files I wrote myself only last week. While the documentation can be improved it's at least up-to-date: The examples all work and can be compiled. As the documentation was not my priority for Boost.Process 0.3 it should be ok for now. Boris

9 14

Final report of GSOC project 'Spatial Indexes'
by Federico J. Fernández 27 Mar '09

27 Mar '09

Hi List! I'm writing this email as a final report of my Google Summer of Code 2008 project for Boost. My project consist in adding some spatial indexing structures to Boost in the context of the Geometry proposal done by Barend Gehrels. Spatial indexes are data structures optimized for spatial oriented queries. The classic index structures (i.e. a binary tree) aren't spatially enabled, they have different ordering criteria but none of them relates to topological properties. The scope of these structures is really wide, from collision detection for games to geometry indexing for GIS software. The original project goals were: - Build a Quadtree. - Build an rTree. - Integrate some previous work from a former GSoC project of a k-d-tree. - Test and document everything. Both indexes are implemented now and everything is tested and documented. The only task that we didn't complete is the k-d-tree integration, because when we analyzed the code it was not ready, and we didn't have the time to finish it. About the results, we made several tests and benchmarks. We tested both indexes with 230.000 objects from GIS data to check the correctness of the implementation, and we made some benchmarks comparing the quadtree vs. rtree and comparing both of them to existing implementation (like GEOS) with very good results. We describe this benchmarks in the documentation offering this as a guide to choose the best index for each use. The code is still beta (or maybe alpha) and not recommended for production use because it is still not tested enough, but if you want to check the actual status you can find it in the following location: https://svn.boost.org/svn/boost/sandbox/SOC/2008/spacial_indexing/ And the docs are at: https://svn.boost.org/svn/boost/sandbox/SOC/2008/spacial_indexing/libs/spat… The future work now is huge. We have some ideas about integrating this in some way to multindexes, and we want to implement also a 'packed' version of the rtree to improve bulk-loading times among another things. Finally, I would like to thank to Boost for allowing me to be part of this year's SOC. And specially to my mentor Hartmut Kaiser for all his help during the program. -- federico j. fernandez

8 13

[endian] superfluous boost::operators<> ?
by Roland Schwarz 26 Mar '09

26 Mar '09

I discovered, that the following will not compile: unsigned u; ulittle32_t u1; ulittle32_t u2; u = 1; u1 = 1; u2 = u1 + u; The compiler complains about not being able to resolve similar conversions. My guess is, that using boost::operators<> _and_ providing type conversion operators at the same time is causing this. I think it should be enough to define the essential operators in cover_operators template, and omit boost::operators<> at all. At least I am not able to find any problems with this, since the compiler adjusts the arguments (using the provided type conversion operators?) and calls the built in operators, thereby resolving ambiguity. Any thoughts? -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

2 1

Profiling template instantiations
by Steven Watanabe 12 Feb '09

12 Feb '09

AMDG Over the last few days, I've been working on a tool that counts the number of class template instantiations in a translation unit. To use it from a jamfile import profile_templates : : directory of the tool ; template-profile result : some_file.cpp : <include>some_directories ; If everything works, this will create a file with the extension .tp which will contain the number of times each class template was instantiated, with the most common templates at the top. I've put a zip of a rough version in the vault. http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Caveats: I've only tested with Visual C++ 9.0 and gcc 3.4.4 on cygwin so far. Other compilers won't work, yet. Other versions of these compilers may or may not work. It may be necessary to add link=static to the bjam command line. In Christ, Steven Watanabe

6 20

Re: [boost] Profiling template instantiations (Steven Watanabe)
by PORKOLAB Zoltan 12 Feb '09

12 Feb '09

Hi Steven, We have created a framework for debugging/profiling template metaprograms in 2006. It might give you a few tips. It works based on the same idea you have. We instrument all template codes, both at the begining and at the end of each template we insert a special piece of code emitting warning messages of a well-defined form. Before instrumentation we create an XML file to remember the template positions in the source file. When we parse the warning, using this information we can reconstruct the instantiation stack knowing the original line numbers, identifiers, etc.. At the end we produce another XML for possible front-ends. The framework uses boost::spirit and boost::wave. We have also implemented and tested a visual studio plug-in. An overview of the whole idea: http://gsd.web.elte.hu/templight/ There is also a GPCE article about the framework, you can find it here: http://portal.acm.org/citation.cfm?id=1173746&coll=portal&dl=ACM&CFID=47731… or here: http://gsd.web.elte.hu/contents/articles/gpce06.pdf You can download both the VS binaries and the source from: http://people.inf.elte.hu/pocok Please feel free to use the code or any of the ideas. For technical question you can find Jozsef: jmihalicza(a)gmail.com or me. Regards, Zoltan

4 3

[thread/interprocess] could we improve recursive_mutex constructor
by vicente.botet 24 Jan '09

24 Jan '09

Hi, the recursive_mutex constructor initialize/set/destroy the pthread_mutexattr_t every time. I'm wondering if we can improve the efficiency storing this on a static variable which will be initialized once. What could be the better way to initialize this static variable? Note: the same applies to interprocess mutexes. recursive_mutex() { // begin code that can be initialized only once pthread_mutexattr_t attr; int const init_attr_res=pthread_mutexattr_init(&attr); if(init_attr_res) { throw thread_resource_error(); } int const set_attr_res=pthread_mutexattr_settype(&attr,PTHREAD_MUTEX_RECURSIVE); if(set_attr_res) { throw thread_resource_error(); } // end code that can be initialized only once int const res=pthread_mutex_init(&m,&attr); if(res) { throw thread_resource_error(); } // begin code that can be removed BOOST_VERIFY(!pthread_mutexattr_destroy(&attr)); // end code that can be removed } Regards, Vicente

2 2

manipulators for filtering_stream s
by Roland Schwarz 22 Jan '09

22 Jan '09

Surprisingly I was not able to find on the net code that would give me a smart way to indent a stream. So I wrote a little filter based on the boost iostreams library. My first attempt was: boost::iostreams::filtering_ostream out; indent_filter ind(4); out.push(ind); out.push(std::cout); However trying to control it via e.g. ind.in() ind.out() turns out to be problematic interface since, 1) out.push() takes a copy of ind 2) the interface ind.in() is suboptimal. With my attached example it is possible to: #include "indent.hpp" ... boost::iostreams::filtering_ostream out; indent_filter::push(out,2); out.push(std::cout); ... And use it like so: out << "Hello Filter!\n" << indent_in << "this is\n" << "indented\n" << indent_out << "until here\n" ; Which will result in output: Hello Filter! this is indented until here The state is stored in the ios base class of the stream, by way of the pword mechanism. Consequently the filter stream even may be downcast to a basic_ostream, and the indenter will still work. E.g. with out defined as above: ... foo(out); ... void foo(std::ostream& out) { out << indent_in << "out is a downcast filter_stream\n" << indent_out << "end of indentation\n" ; } If you want to try it out, you just need to include the header indent.hpp. If someone thinks the snippet is usable either as an example for the iostreams library or the filter streams manipulator idea is worth generalizing to make it usable for other filters too, I would be glad to hear from you. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

5 17

[thread] proposal to manage portable and non portable thread attributes
by vicente.botet 22 Jan '09

22 Jan '09

Hello, Boost.thread has already a non portable interface to get the thread handle class thread { public: ... typedef np_native_handle_type native_handle_type; native_handle_type native_handle(); ... }; Boost.Thread do not allow to pass thread attributes on the thread constructor. I supose that this is due to portable issues. Could we identifiy which attributes are portable and which one not? The portable attributes (as stack size, ...) can be grouped on a thread_attributes class. In order to be able to pass whatever attribute to the thread constructor we can add the setting of non portable attributes to this thread_attributes class, and making the thread constructor take a thread_attributes in addition to the existing parameters. class thread { public: class thread_attributes { // portable attributes public: // set/get of attributes // .. #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) private: pthread_attr_t native_attributes; public: set_np_attributes(const pthread_attr_t* h); // ... other #else #error "Boost threads unavailable on this platform" #endif }; thread(const thread_attributes*p, F f,A1 a1); ... }; The portable application needing some specific configuration can construct portable threads using the following schema thread::thread_attributes attr; // set portable attributes // ... #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) // ... pthread version pthread_attr_t native_attributes; pthread_attr_init(&native_attributes); pthread_attr_setstacksize(&native_attributes, 1000000); attr.set_np_attributes(&native_attributes); #else #error "Boost threads unavailable on this platform" #endif thread th(attr, f,ctx); What do you think? Vicente

3 3

Tests are a mess
by Gennaro Prota 23 Dec '08

23 Dec '08

Few questions: * BGD-Ubuntu is among tested platforms for release, but not for trunk. How is a poor fellow supposed to test on trunk first? * Same as above for BGD-Windows, with the fellow getting poorer and poorer * Are RW_WinXP_VC and RW_WinXP_VCrtl the same? * Can anyone please have a look at the trunk failures for HP-UX_ia64_aCC? For a bunch of libraries I've looked at it gives an Unsatisfied symbol "boost::exception_detail::refcount_ptr<..." What's that? Compiler bug, misconfiguration, phase of the moon? Sorry, but if this is the status quo I'm just going to merge to branches/release and be done with it. -- Genny

11 44

[swap] How to fix ADL barrier for XL, Intel, GCC, Sun and Como?
by Niels Dekker - mail address until 2008-12-31 19 Dec '08

19 Dec '08

The boost::swap utility from Joseph Gauterin has an ADL barrier against infinite recursion or ambiguity, as recommended by Steven Watanabe and David Abrahams, last year at the mailing list: "Re: [boost] Koenig lookup swap." http://lists.boost.org/Archives/boost/2007/08/125938.php Last Friday I added "test_adl_barrier" to test this ADL barrier. Unfortunately it fails on many compilers, including XL (AIX), Intel (version 9 and 10), GCC, Sun and Como: http://www.boost.org/development/tests/trunk/developer/utility-swap_.html While I usually use MSVC, and for that specific compiler, the ADL barrier appears successful! Do you know how to fix the ADL barrier for the other compilers? I'm afraid we'll need to have #if BOOST_WORKAROUND statements in there... FYI, the boost::swap utility is at: http://svn.boost.org/svn/boost/trunk/boost/utility/swap.hpp The ADL barrier test is at: http://svn.boost.org/svn/boost/trunk/libs/utility/swap/test/test_adl_barrie… Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

5 26

Measuring compile time performance
by dan marsden 15 Dec '08

15 Dec '08

Hi We're looking at optimizing some of the compile time performance in Boost.Fusion. I'm looking for any experience in Boost of measuring build times / compile time cost, how to structure tests that cover it etc. Does Boost.Build provide any support for measuring compile time for example? I'm aware there's a Perl script by Steven Watanabe that measures template instantiations if I understand correctly. Are there any other techniques that are being used that I should be aware of? Cheers Dan Send instant messages to your online friends http://uk.messenger.yahoo.com

9 14

[proto][design]why unary_expr,binary_expr; but no nullary_expr?
by Larry Evans 14 Dec '08

14 Dec '08

Although there's unary_expr<Tag,*>, binary_expr<tag.*,*> in traits.hpp there's no nullary_expr<Tag>. I realize this would be a replacement to the current terminal template but with a user specified tag. After all, if a user specified tag for n-ary (where n>0) expressions *is* desirable, why is a user specified tag for 0-ary expressions *not* desirable? On case where this would be useful is for algebraic morphisms where n-ary ops in a source algebra are mapped to n-ary ops in a target algebra. This *includes* 0-ary ops. An op would be the equivalent to proto tags. I think this could be done by another transform similar to the pass_through transform but allowing transformation of the tag. Currently pass_through just uses the source tag in the target expression. It seems like it should be pretty easy to allow transformation on the tag also.

2 3

[MultiIndex] Random Access mental model?
by David Abrahams 29 Nov '08

29 Nov '08

Hi, I'm trying to get a grip on what it means when I have a random access index in a multi_index_container. I have no mental model for what data structure you're actually creating, which makes it difficult to evaluate multi-index vs. hand-rolling my own container. If I was doing this myself, I'd use a combination of these two: hash_map<key, value> deque<hash_map<key, value>::pointer> because I need to maintain an LRU cache of what has been put in the map (i.e. I need O(1) push_back and pop_front). MultiIndex only lets me use sequenced<> which it implies essentially has the properties of list<hash_map<key, value>::iterator>... although I can imagine you could save a lot by using the same nodes for the hash_map and the list. Do you do that? Regardless, I could still save roughly one pointer per node with my deque. I'd think about trying to modify MultiIndex to let it do random access with deques, but I can't make head or tail of the implementation code used for random access. Could someone clarify what's going on in there? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

7 27

[lambda][test] _set_se_translator() requires /EHa
by David Walthall 22 Nov '08

22 Nov '08

I was looking at one of the failures on vc 7.1 and noticed that there was the following warning: ..\boost\test\impl\execution_monitor.ipp(825) : warning C4535: calling _set_se_translator() requires /EHa the command line options /EHc and /GX are insufficient See: http://beta.boost.org/development/tests/release/developer/output/daw-msvc71… or: http://tinyurl.com/5osfqr Is this a spurious warning, or is really an issue? Thanks, David

3 3

[cryptography] concept
by Kasra Nassiri(Math & ComSci) 10 Nov '08

10 Nov '08

Hi all, I mentioned not a while ago that I am planning to write a boost cryptographic library. I am getting there. We have template classes that implement a certain interface (not virtual functions). These classes are: secure_allocator: An allocator which removes the buffers allocated when they are destructed by overwriting them. block_cipher: Any class that could set a key and encrypt/decrypt a constant size of message. (I have included AES, Serpent, Twofish and MARS, however, we could always add more algorithms) stream_cipher: By definition stream_cipher is a cipher that could process messages of any length. hash_function: Is a class that could compute a cryptographically secure hash signature for an arbitrarily long messages. (I have added whirlpool and will be adding more). wipe_algorithm: An algorithm that provides the patterns of wipe for a given pass and fills a given buffer with patterns (It needs to have a prng template to be used on random patterns). By using a mode of operation we could turn the concept of block_cipher into a stream_cipher. For example cryptolib::ctr<cryptolib::aes> is a stream_cipher concept. I have implemented ictr, ctr and will be implementing XTS, LRW soon. classes: cryptolib::entropy_poll<cryptolib::hash_function>: A class that polls random data and mixes the data using a hash function. cryptolib::entropy_thread<cryptolib::entropy_poll>: Calling the polling function of the entropy_poll at "random" but regulated intervals using boost::thread library. cryptolib::crypto_istream<cryptolib::stream_cipher>: cryptolib::crypto_ostream<cryptolib::stream_cipher>: cryptolib::crypto_oistream<cryptolib::stream_cipher>: classes that behave similar to 'std' iostream ,however, they seamlessly encrypt/decrypt the data as they operate. cryptolib::wipe_fstream<cryptolib::wipe_algorithm>: Wipes the file using the patterns by the template wipe algorithm. This class would determine the cluster size and wipe the entire cluster occupied by the file (this is platform specific, so we need to implement the algorithm for different platforms). finally we have the cryptolib::crypto_fstream that could be given a direction (i.e. encryption or decryption) and will operate seamlessly on the data. What do you think? Anything that I am missing on? Best regards Kasra __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

7 6

[flyweight] post-review version available
by JOAQUIN M. LOPEZ MUÑOZ 08 Nov '08

08 Nov '08

Hello, I'm happy to announce the availability of the post-review version of Boost.Flyweight: *Online docs:* http://tinyurl.com/2sstyr http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html *Download as .zip:* http://tinyurl.com/hrdm6 http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… *Check out from SVN:* https://svn.boost.org/svn/boost/sandbox/flyweight *Tested with:* MSVC++ 8.0 and GCC 3.4.4. Compilation reports most welcome. Older compilers like MSVC++ 6.5 are no longer supported. *What's new:* I've tried to address most of the suggestions and comments raised during the review. The two most important changes are: 1. Alberto Barbati's insightful review has led to the introduction of so-called key-value flyweights (http://tinyurl.com/5mnwjp ). This type of flyweights is meant for the situations where constructing the underlying type is expensive and must be avoided except if absolutely necessary. I think the design is robust enough and covers the variants (inner/outer key) that arose during the discussion with Alberto. 2. A comprehensive performance section is provided (http://tinyurl.com/5ap5kt ). *What's pending* 1. Some of the suggestions given at the review, like reducing intermodule_holder to static_holder when permissible (Vicente Botet) or studying read/write locking policies are still pending or have been postponed to later releases of the library. I felt the current state is sufficiently robust for publication. 2. Serialization support is currently broken, pending the resolution of a proposed feature to add to Boost.Serialization (run-time archive helpers). I'd be very grateful if you can take a look at the post- review version of Boost.Flyweight (specially if you were a reviewer), test it and comment on it, with emphasis on the new features like key-value flyweights. If people are happy with this revision my target release for inclusion will be Boost 1.38. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 12

make_shared and allocate_shared for classes with private constructors
by Michael Marcin 06 Nov '08

06 Nov '08

I have some classes that derive from enable_shared_from_this which I've given private constructors and static creation methods which return a shared_ptr. This prevents someone from using the class inappropriately. It seems obvious that at a minimum using make_shared internally here would be an improvement. Unfortunately this requires that make_shared be made a friend for every arity and probably won't work with the variadic template implementation of make_shared. Is it possible to make declaring friendship for make_shared and allocate_shared simpler? I thinking something like serialization does with friend class boost::serialization::access. Thanks, -- Michael Marcin

2 3

[FileSystem] portable Temp, Desktop & Applications directories?
by Jeff Flinn 06 Nov '08

06 Nov '08

Is there any existing facility to get in particular the path to the user's temp directory in FileSystem? I couldn't find one in boost_1_35_0, but I've might have missed it. Any plans for this functionality? On Win and Mac there's getenv TEMP/TmpDir, or is there a better way. Thanks, Jeff

3 3

[MultiIndex] interface comments
by David Abrahams 05 Nov '08

05 Nov '08

Just reading through the docs for this very useful library and I had a few notes: 0. The term /typelist/ (italicized) is used in the tutorial without definition. Do you mean an MPL type sequence, or something else? 1. Seems like the tags functionality could take advantage of Boost.Parameter to provide a nicer interface and save some code. 2. The "shortcuts" save exactly 1 character. Each index of a multi_index_container uses its own iterator types, which are different from those of another indices. As is the rule with STL containers, these iterators are defined as nested types of the index: employee_set::nth_index<1>::type::iterator it= es.get<1>().find("Judy Smith"); <snip> Additionally, multi_index_containers provide shortcut definitions to the iterator types of their constituent indices: employee_set::nth_index_iterator<1>::type it= es.get<1>().find("Judy Smith"); There is a variation of the expression above for use with tags: employee_set::index_iterator<name>::type it= es.get<name>().find("Judy Smith"); // get<1> would also work Notice the column in which "it" appears in both versions. IMO these interfaces should be deprecated (i.e. not documented, and eventually removed) as they provide no readability advantage, hurt learnability, and complicate usage. Regards, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 4

[threadpool] new version v12
by k-oli＠gmx.de 04 Nov '08

04 Nov '08

Hello, the new version of Boost.Threadpool depends on Boost.Fiber. regards, Oliver

10 54

[1.37.0][date-time] Breaking the log jam
by Beman Dawes 04 Nov '08

04 Nov '08

Andrey Semashev has pulled together a number of patches to address backed-up date-time tickets. He has tested them on Linux and Windows. The arrangement was that Jeff Garland would look them over, but Jeff just isn't finding the time to do that. I've taken a look at a few of the proposed fixes. Without knowing anything about date-time, these seem like problems that really should have been fixed some time ago.The proposed patches I looked at seemed fine. So I think it is important we break the log jam. Proposal: * We give Andrey write permission. * He starts moving these fixes into trunk right away. * Anyone who cares about data-time watch the commits carefully, and discuss any issues with Andrey. * Once Andrey is satisfied with trunk test results, he asks permission to merge to release. * Unless there has been undue delay or issues have come up, we will give permission for this release. * I'm willing to hold the release a few days; in aggregate this is an important set of overdue fixes to a major library so I'd like to see them go in this release. Comments? --Beman

7 15

new libaray Boost.Fiber in vault
by k-oli＠gmx.de 03 Nov '08

03 Nov '08

Hello, I've added Boost.Fiber to the boost vault. The library implements lightweight threads of execution (context swapping; fibers on Windows). regards, Oliver

5 14

[MultiIndex] "Compatible Sorting Criterion"
by David Abrahams 02 Nov '08

02 Nov '08

The docs mention that the definition is cumbersome. I think you could probably do much better with a formulation that relies on the concept of being partitioned with respect to a predicate function. See www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1313.html and the wording changes (now in the standard) at: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#270 -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 2

Negative Cycle Detection Code
by Paul De La Musica 02 Nov '08

02 Nov '08

Hi, Is there any negative cycle detection code in the public domain? We would prefer BGL based code but LEDA is fine too. Thanks, Paul

2 1

[type-traits] virtual function type trait check
by Chris 02 Nov '08

02 Nov '08

I was wondering if it were possible to make a is_virtual_function type trait check. Example: class B { public: virtual void complicatedFunction() { } }; class D : public B { public: void complicatedFnction() { static_assert(**check if D::complicatedFnction() is virtual **); // notice the misspelling. } };

2 2

Style Guideline
by Robert Jones 31 Oct '08

31 Oct '08

Writing the kind of code that you see in the Boost libraries is something of a step change from the day-to-day production code that I write, and I suspect most of us write (Joel, Eric, Dave, Peter and others excepted of course! :-) ), and writing it, I find, is a rather different matter from reading it and broadly understanding it! So,....enable_if.... Is enable_if intended only to include or exclude complementary instantiations of different templates from the possible set, or also to control whether a particular instantiation is available at all? Say I have a class which I want to be able to instantiate only for vectors. Is it sensible to create an is_vector<> template and then use enable_if, or should I simply allow instantiation to fail when the code uses some aspect of vectors which is specific to vectors? Does the situation change if it is vectors or lists that are permissible? Or if it's anything with begin() & end() defined? Or am I making a complete hash of this, and ought to be thinking in a different paradigm? Thanks in advance. - Rob.

2 1

[Timer] Inconsistent behaviour
by Jordans, R. 31 Oct '08

31 Oct '08

Hey all, I was looking at Boost.Timer and I noticed that it shows different results when it's used in a threaded program on Windows or Unix machines. A closer inspection revealed that it uses clock() to do it's timings. Digging a bit deeper I found that clock() is specified differently on Windows than it is in my Linux man-page. On windows it counts 'wall clock' time, basically what I'd expect from a class named timer but on Linux it counts CPU time. Thus it will give the result for completely different concepts of time elapsed depending on my system. Two questions; 1) is there a good way to solve this, 2) if not, could it at least be noted in the documentation. Thanks, Roel

6 6

first Visual Studio 2010 CTP is out, c++0x
by Cory Nelson 31 Oct '08

31 Oct '08

In case anyone missed it, a VS10 CTP is out with partial 0x support (lambda, rvalue, static assert, and "auto"), better intellisense, and a modern c++ parallel library. http://www.microsoft.com/downloads/details.aspx?familyid=922b4655-93d0-4476… -- Cory Nelson

10 16

boost::filesystem request
by Jorge Lodos Vigil 31 Oct '08

31 Oct '08

Hi The Traits classes for basic_path provided in the filesystem library (path_traits and wpath_traits) are good enough to be used as default values for basic_path in most cases. However, since they are independent structs, they can not be used to instantiate a basic_path with a single String template parameter. I would like to write: typedef basic_string<char> string_t; typedef fs::basic_path<string_t, fs::basic_path_traits<string_t> > path_t; Currently we are forced to write in our code something as: template <typename String> struct path_traits {}; template <> struct path_traits<std::string> { typedef boost::filesystem::path_traits traits_t; }; template <> struct path_traits<std::wstring> { typedef boost::filesystem::wpath_traits traits_t; }; typedef std::basic_string<CharT> string_t; typedef boost::filesystem::basic_path<string_t, typename path_traits<string_t>::traits_t > path_t; I underestand it is important to emphasize that Traits classes have nothing to do with String classes in path instantiations, so my question is: Is it reasonable to ask that path traits classes provided in the library would be implemented as template specializations instead of separate classes? Thanks in advance. Best regards Jorge

4 9

[range_ex] warning when using index operator on the element of a transformed range of a transformed range of a fusion sequence
by Stjepan Rajko 30 Oct '08

30 Oct '08

Hello, I apologize in advance for the long explanation about a small problem... I tried to trim it down as much as I could right now. If it is still too much info, I can try to trim it down more... I am working in a context where I have Ranges of Ranges of fusion Sequences, and need to access different "slices" of said contraption. By that I mean, if I have a: std::vector<std::vector<fusion::vector<int, double> > > RoRoS, I would like to access a Range of Range of ints (consisting of the first elements of the fusion vector), and a Range of Range of doubles (consisting of the second elements). I wrote a little utility that allows me to do that (using RangeEx `transformed` adaptors) in the context of a for_each iteration (see attached "for_each_element_and_slice.hpp"). The purpose of this one is, given say a fusion::vector<foo,bar> S0; for_each_element_and_slice<1>(S0, RoRoS, some_fn) will call: some_fn (the foo element of S0, the Range of Range of ints) some_fn (the bar element of S0, the Range of Range of doubles) 1 specifies the "depth" - 1 means the second parameter is a Range of Range of Sequence, 0 would mean Range of Sequence, 2 would mean Range of Range of Range of Sequence. Anyway, in doing this I ran into a weird warning. If some_fn is as follows: struct weird_warning { template<typename Element, typename Slice> void operator()(Element &element, const Slice &slice) const { *boost::begin(slice[0]); // no warning slice[0][0]; // warning: operator[](outer) returning reference to temporary } }; ...I get warnings as indicated by the above comments. That is, *boost::begin(slice[0]) works just fine, but slice[0][0] issues a warning about the outer operator[] returning a reference to a temporary. I would be inclined to think that both of these should be legal operations (with no warnings being issued) - is that correct? If so, is there a problem in my use of range_ex, or is there a problem with range_ex? (the test file test_for_each_element_and_slice.hpp attached - the bits relevant to this warning are outlined by: //------------------------------------------------------------ //------------------------------------------------------------ ...relevant bits... //------------------------------------------------------------ //------------------------------------------------------------ ) I am using what I believe is the latest RangeEx from the vault (thanks for this great utility!) against boost trunk. Any help appreciated! Thanks, Stjepan

1 0

Re: [boost] [Boost.Msm] On the necessity of state-boundary-crossingtransitions
by Christophe Henry 30 Oct '08

30 Oct '08

Hi Andreas, I am not sure what is the point of such a challenge considering that I already explained that entry and exit pseudo states are not supported yet but will probably be in the future. Their absence is not by design as you seem to think but simply a decision of when to bring a version 1.0 and what should be inside. Anyway, as you offered me this challenge, I offer a solution which you will find in the vault ( http://www.boostpro.com/vault/index.php?direction=0&order=&directory=Msm&) I think this solution is a good example of what you can do with Msm and will hopefully make it clear how sub machines can make life easier. I want to thank you for the chance you give me to improve Msm (a few bugs were corrected on the way) and for your reaction to my opinion, which made it clear I need to more clearly draw a line between what I personally think and what users are used to and expect to find in Msm. Again, although I think no good of entry and exit pseudo states and consider them more than doubtful practice (please have a look at the doc for an explanation), a future version of Msm will offer them in some form with corresponding warnings. Regards, Christophe

2 1

How to find: best integer type for processor
by Daryle Walker 30 Oct '08

30 Oct '08

Is there a macro and/or typedef that will tell me bit-length used for a processor and/or the best integer type for said processor? The "int" type is supposed to be that type, and it was in the 16- and 32- bit eras. (I learned C programming with the former in the... early 1990s!) However, the powers-that-be decided, for "backwards compatibility," to freeze "int" and "long" at 32 bits and use a new type, "long long," for 64 bits, which should be the optimized integer type for 64-bit processors. (If they kept to the plan, "int" would be 64 bits, "long" either 64 or 128, "short" up to 32, and the new type will be "short short" at 16.) I want to know the best type so, when I build multi-integer arrays for various purposes, I don't pick an element type that causes a slow down, whether to focus on a fraction of a register (if the chosen type is too small) to handle two registers at once (if the chosen type is too large). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

7 9

[parameter] some extensions to Boost.Parameter
by Stjepan Rajko 30 Oct '08

30 Oct '08

Hello, I've played with some extensions to Boost.Parameter and would like to know if there is any interest to have any of them polished / rolled back into the library. I have found these extensions useful when using ArgumentPacks directly rather than using Boost.Parameter macros like BOOST_PARAMETER_FUNCTION, BOOST_PARAMETER_CONSTRUCTOR,... (I am using the library in this particular way because of reduced compile times and (IMO) cleaner library code (although user-side code takes a slight hit)). Here are brief descriptions of the extensions: *1* Keywords/Tags with fixed types These are intended for keywords/tags that are always associated with a certain type of argument. operator= of a fixed-type keyword always return a tagged argument whose value_type is the fixed type. This has the benefit of moving any type conversions to the call site, which allows *3* Implementing this involved splitting the keyword class into typed_keyword and untyped_keyword, with the commonalities extracted into a keyword_base class. It also introduces a corresponding new macro, BOOST_PARAMETER_TYPED_NAME. *2* Default-default arguments When a keyword always has the same default value, I found it useful to put the default value into the Tag definition (in the form of a static member function that returns that default value). The definition is made using a macro - this is an example use case: BOOST_PARAMETER_TYPED_NAME_WDEFAULT(label,const std::string,"") If a ArgumentPack args does not contain an explicit value for _label, args[_label] will return std::string(""). I'm not sure what the right response to e.g., args[label|"something"] should be. *3* Make ArgumentPacks constructible from other ArgumentPacks. I basically added a constructor to arg_list that does allows something like the following: // this will return an appropriate arg_list type, containing four tagged_args // the four tags are all typed (*1*) and with default default values(*2*) typedef argument_pack<tag::label, tag::size, tag::position, tag::background>::type argument_pack_type; window(const argument_pack_type &args); In the above case, e.g., window(( _label="label", _size=size_type(100,100) )) would call window with default-default values for position and background. The benefit here is that the implementation of window doesn't need to be templated (which is helpful in some cases), and you don't need to write any forwarding functions (or use BOOST_PARAMETER_FUN). *4* Overloading operator() for typed keywords Instead of writing, e.g.: window (( _size=size_type(100,100), _position=position_type(0,0) )) , we can write window (( _size(100,100), _position(0,0) )) I accomplished this by adding a delayed_constructor class which holds references to the arguments (e.g., 100, 100) and is convertible to the Tag's value_type (e.g. size_type). The 'conversion' is done constructing an instance of the value_type using the arguments. The delayed_constructor is then stored in a tagged_argument object instead of the usual reference to the value_type. I had to hack tagged_argument and arg_list to work with delayed_constructor, which was in some ways similar to how tagged_argument and arg_list are made to work with the `maybe` class. This leads me to believe that tagged_argument and arg_list would benefit from having a specified extension interface into which things like `maybe` and `delayed_constructor` could hook into, rather than being so tightly coupled. The proof-of-concept implementation for all these things can be found at: http://svn.boost.org/svn/boost/sandbox/guigl/boost/parameter/ To avoid clashing with Boost.Parameter, I made the above extensions in renamed classes (e.g., typed_arg_list and typed_tagged_argument). Please let me know if there is any interest. Kind regards, Stjepan

3 10

Review Request: Polynomial
by Paweł Kieliszczyk 30 Oct '08

30 Oct '08

Hi, I'd like to request a review of my polynomial library which I wrote during Google Summer of Code project this year. The zip file is in Boost Vault (called polynomial.zip). It includes the library, tests and documentation. The same files (not compressed) are also available in sandbox: http://svn.boost.org/svn/boost/sandbox/SOC/2008/polynomial/ Thanks -- Pawel Kieliszczyk

3 5

tie alternative?
by David Abrahams 30 Oct '08

30 Oct '08

OK, BOOST_FOREACH aside, iterating over a range returned as a pair of iterators can be painful and ugly: vertex_iterator pv, ve; tie(pv, ve) = vertices(g); // unpack the pair returned by vertices for (; pv != pe; ++pv) { ... } However, we can make it much nicer, e.g.: for (vertex_iterator pv,ve = xxx(pv,vertices(g)); pv != ve; ++pv) { ... } My only problem is how to spell xxx. The attached proof-of-concept uses operator%, but I don't feel particularly good about that choice either. Ideas? --- -- Dave Abrahams BoostPro Computing http://www.boostpro.com

13 21

[function] support for overloaded function
by Oliver Kowalke 30 Oct '08

30 Oct '08

Hello, how can I support the return type of bind as well as function as function argument in following code. regards, Oliver #include <iostream> #include <cstdlib> #include <stdexcept> #include <boost/bind.hpp> #include <boost/function.hpp> struct X {}; struct Y { template< typename R > void f( boost::function< R() > const& fn) {} template< typename R > void f( boost::function< R( X &) > const& fn) {} }; struct Z { int u( int i) { return i; } int v( X & x, int i) { return i; } }; int main( int argc, char *argv[]) { try { Y y; X x; Z z; // does not compile y.f( boost::bind( & Z::u, z, 1) ); boost::function< int() > fn1( boost::bind( & Z::u, z, 1) ); y.f( fn1); // does not compile y.f( boost::bind( & Z::v, z, _1, 1) ); boost::function< int( X &) > fn2( boost::bind( & Z::v, z, _1, 1) ); y.f( fn2); return EXIT_SUCCESS; } catch ( std::exception const& e) { std::cerr << e.what() << std::endl; } catch ( ... ) { std::cerr << "unhandled" << std::endl; } return EXIT_FAILURE; } -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

2 1

patch to serialize mersenne_twister
by Neal Becker 30 Oct '08

30 Oct '08

Please consider adding this patch to add serialization to mersenne_twister. Since it is only active if BOOST_SERIALIZE_TWISTER is defined, it is completely harmless to those who don't use it.

3 6

[1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92
by Hartmut Kaiser 30 Oct '08

30 Oct '08

Anything I can do about this? What does this assertion mean? My setup: Linux 64Bit, gcc 4.2.4, serialization is used for polymorphic objects loaded from different shared libraries, shared libraries are loaded with dlopen(RTLD_GLOBAL|RTLD_LAZY). Assertion (extended_type_info.cpp:92) occurs during program termination (after main returned), during dlclose(). If anything else isn't possible, would it be appropriate to change the related code (before the release!) from: assert(start != end); // remove entry in map which corresponds to this type do{ if(this == *start) x.erase(start++); else ++start; }while(start != end); To: assert(start != end); // remove entry in map which corresponds to this type while(start != end) { if(this == *start) x.erase(start++); else ++start; } Which wouldn't remove the problem, but at least avoids hanging the program if assertions are off... Regards Hartmut

5 5

[quickbook] probs with docu generation (C++ code)
by Oliver Kowalke 29 Oct '08

29 Oct '08

Hello, I've a porblem with document generation with quickbook. The code in the *.qbk files get some strange extra characters appended (in the example belwo: 'e seco'). Could please so kind to help? regards, Oliver threadpool.qbk boost::tp::pool< boost::tp::unbounded_channel< boost::tp::fifo > > pool( boost::tp::poolsize( 6), boost::posix_time::posix_time::milliseconds( 50), boost::tp::scanns(10) ); generates in the output: boost::tp::pool< boost::tp::unbounded_channel< boost::tp::fifo > > pool( boost::tp::poolsize( 6), boost::posix_time::posix_time::milliseconds( 50), boost::tp::scanns(10) ); e seco ^^^^^^^ why are this chars inserted quickbook xml output: <programlisting> <phrase role="identifier">boost</phrase><phrase role="special">::</phrase><phrase role="identifier">tp</phrase><phrase role="special">::</phrase><phrase role="identifier">pool</phrase><phrase role="special"><</phrase> <phrase role="identifier">boost</phrase><phrase role="special">::</phrase><phrase role="identifier">tp</phrase><phrase role="special">::</phrase><phrase role="identifier">unbounded_channel</phrase><phrase role="special"><</phrase> <phrase role="identifier">boost</phrase><phrase role="special">::</phrase><phrase role="identifier">tp</phrase><phrase role="special">::</phrase><phrase role="identifier">fifo</phrase> <phrase role="special">></phrase> <phrase role="special">></phrase> <phrase role="identifier">pool</phrase><phrase role="special">(</phrase> <phrase role="identifier">boost</phrase><phrase role="special">::</phrase><phrase role="identifier">tp</phrase><phrase role="special">::</phrase><phrase role="identifier">poolsize</phrase><phrase role="special">(</phrase> <phrase role="number">6</phrase><phrase role="special">),</phrase> <phrase role="identifier">boost</phrase><phrase role="special">::</phrase><phrase role="identifier">posix_time</phrase><phrase role="special">::</phrase><phrase role="identifier">posix_time</phrase><phrase role="special">::</phrase><phrase role="identifier">milliseconds</phrase><phrase role="special">(</phrase> <phrase role="number">50</phrase><phrase role="special">),</phrase> <phrase role="identifier">boost</phrase><phrase role="special">::</phrase><phrase role="identifier">tp</phrase><phrase role="special">::</phrase><phrase role="identifier">scanns</phrase><phrase role="special">(</phrase><phrase role="number">10</phrase><phrase role="special">)</phrase> <phrase role="special">);</phrase> <phrase role="identifier">e</phrase> <phrase role="identifier">seco</phrase></programlisting> -- GMX Download-Spiele: Preizsturz! Alle Puzzle-Spiele Deluxe über 60% billiger. http://games.entertainment.gmx.net/de/entertainment/games/download/puzzle/i…

6 10

[1.37.0] beta 1 release candidate QA
by Beman Dawes 29 Oct '08

29 Oct '08

1.37.0 beta 1 release candidates are available at http://boost.cowic.de/rc/ Before pushing these out to SourceForge, we need volunteers to download and install, following the getting started guide. See http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html Please report whether the getting started procedure works, and whether the resulting install looks OK. Thanks, --Beman PS: I've added a "five weeks before release" milestone to http://svn.boost.org/trac/boost/wiki/ReleaseSchedule, so that in the future more of these basic QA tasks get done well before the last minute.

4 10

[BGL] bundled properties and their restrictions (particularly default constructibility).
by Geoff Hilton 29 Oct '08

29 Oct '08

Hi, my graph uses bundled properties for both vertices and edges. Both bundled properties have containers that must be of a certain size when they're actually used. For testing purposes these containers were of fixed size (underlying container is currently a boost::array<..>. However the real world dictates that the size of these containers pretty much must be determined at run-time as opposed to compile-time because the graph is built using an external source such as a file or database for example. I know the documentation requires that bundled properties be all of default constructible, assignable and copy constructible[1][2] because of how the containers (as specified by selectors) store them. I'm unsure as to whether or how this may effect algorithms provided by the BGL, so far the only ones I've used are dijkstra_shortest_path and dag_shortest_path. Given that a custom container selector may be created and push/erase must be overloaded for the given custom container (for my purposes, this would be to specify a custom allocator as in the example)[3], how safe would it be to say that the container selector entirely dictates the restrictions in question? If the answer is "very", presuming we weren't to change these restrictions for existing provided selectors would it be possible for an explicit exception to be made for custom containers and their selectors (created using boost::container_gen<>)? This exception might say that the restrictions in question are then dictated by the custom container. I figure this shouldn't affect existing user code since the current restrictions are already at their most strict. Thanks very much, Geoff [1] http://www.boost.org/doc/libs/1_36_0/libs/graph/doc/using_adjacency_list.ht… [2] Doug Gregor 23/03/2005, this list. [3] http://www.boost.org/doc/libs/1_36_0/libs/graph/doc/using_adjacency_list.ht…

2 4

[threads] missing includes in thread.hpp
by Petr Uzel 29 Oct '08

29 Oct '08

Hi list, is there any reason why boost/thread.hpp #includes everything from boost/thread/*.hpp except condition.hpp and tss.hpp ? Is it a bug ? Thanks, -- Best regards / s pozdravem Petr Uzel, Packages maintainer --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: puzel(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 964 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz

1 0

[ASIO/System] Checking error_code
by Carlo Medas 29 Oct '08

29 Oct '08

Dears, sorry for disturbing with peraphs stupid question, but I'm really hung: I'm not able to check the error code (boost::system::error_code) for a specific 'End of File' type. When I print it, it's 'End of file', with int value = 2. But how to check it? I tried with something like: if (error.default_error_condition() == boost::system::error_condition(boost::system::errc::XXX)) { ... } But I don't know what to put in the XXX. Br and thanks, \Carlo Medas

2 2

[data_time] conversion warnings on 64bit platform
by Christopher Lux 28 Oct '08

28 Oct '08

Hi, when using date_time on a 64bit windows platform i get a warning that a int64 value is converted to a long value in the following section: boost/date_time/time_system_split.hpp 189 typename date_duration_type::duration_rep_type doff = day_offset.add(td.ticks()); I use date_time with the BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG macro set to get nanosec timer abilities (my own timers over the boost interface). Is this warning serious or can it be neglected? Regards -chris -- Christopher Lux | | Bauhaus-Universität Weimar | faculty of media - virtual reality systems group

1 0

[1.37.0 beta] Beta release available on SourceForge
by Beman Dawes 28 Oct '08

28 Oct '08

1.37.0 beta 1 is available on SourceForge. See http://tinyurl.com/674rcl There is one known bug in the beta; the Getting Started Guide release number is still shown as 1.36.0. That will be fixed in the final release. There is one new library (Proto) in the release and numerous bug fixes and updates to existing libraries. The beta period will be approximately ten days. Please post bug reports to either the boost developer or user lists, but also let us hear about success stories too! Many thanks to Eric Niebler, Daniel James, Rene Rivera, Marshall Clow, the testers, and all the others who helped to get this beta release together. --Beman Dawes

9 17

[Asio] Match condition based on asio::streambuf length
by Chet S 27 Oct '08

27 Oct '08

Hello, I'm attempting to write a TCP-based server that can interpret a protocol that has a prepended length followed by variable length data. To do this, I'm using async_read_until along with an asio::streambuf. In order to ensure that there is enough data in the buffer for my next async read handler in the chain, I've written a match condition that will return true if there is enough data already in the streambuf to satisfy the read: class read_until_length { public: explicit read_until_length(size_t len) : m_len(len) { } template<typename Iterator> std::pair<Iterator, bool> operator()(Iterator begin, Iterator end) const { Iterator i = begin; const size_t buffer_len = std::distance(begin,end); if(buffer_len >= m_len) { std::advance(i, m_len); return std::make_pair(i, true); } else return std::make_pair(end, false); } private: size_t m_len; }; And then I use it in chained calls to async_read_until as such: Connection::start() { // Call our next handler when we have received at least 4 bytes (which represents the payload length that will follow) boost::async_read_until(m_socket, // boost::asio::ip::tcp::socket m_data, // boost::asio::streambuf read_until_length(4), boost::bind(&Connection::read_element, this, boost::asio::placeholders::error)); } Connection::read_length(boost::system::error_code& error) { // Read out the 4 byte size header size_t length = 0; memcpy(&length, &*boost::asio::buffers_begin(m_data.data()), sizeof(size_t)); m_data.consume(sizeof(size_t)); // Read out the variable length data next now that we know the size of it boost::asio::async_read_until(m_socket, m_data, read_until_length(length), boost::bind(&Connection::read_data this, length, boost::asio::placeholders::error)); } Connection::read_data(size_t length, boost::system::error_code& error) { // Consume the payload of length bytes... } The problem that I'm having is that async_read_until() performs two checks on the match condition. The first (boost/asio/impl/read_until.ipp:954) is to see if the iterator returned from the match condition is at the end of the buffer. If that is true, it does not post the next handler and assumes that not enough data has been read from the socket. This causes a problem when there is exactly enough data in the streambuf with the match condition as written above. It seems that returning true from the match condition (in the second part of the std::pair<>) should still post a handler since the condition was matched and it shouldn't be overridden by the iterator being at the end of the buffer. Is there a way to use async_read_until and a custom match condition to match the exact size of the streambuf? Thanks in advance. --Chet

1 0

Using allocator rebind on an incomplete type
by Chris Newbold 27 Oct '08

27 Oct '08

In trying to clean up some code in Boost.Pool, I've run afoul of some code in Microsoft's implementation of the STL where they are using allocator::rebind on an incomplete type. Something like this: struct Node; // Incomplete! template<typename T, typename Alloc> struct List { Alloc<T>::rebind<Node>::other::pointer node_p; ... } I believe that attempting to instantiate an allocator with an incomplete type is illegal so, by extension, I would have assumed that attempting to rebind on an incomplete type would also be illegal, no? -Chris

3 6

[threadpool] version 11 - some code cleanup
by k-oli＠gmx.de 27 Oct '08

27 Oct '08

Hello, I've uplaoded v11 to boost vault /concurrent programming. - documentation now in quickbook format, some enhancements - examples with Jam file - test with mJam file - code cleanup - API cleanup regards, Oliver

1 0

[test] linking does not return
by k-oli＠gmx.de 27 Oct '08

27 Oct '08

Hello, I've some test files but the link-step does not return (waits forever). gcc.link ../../../bin.v2/libs/tp/test/test_bounded_queue_fifo.test/gcc-4.3.1/debug/link-static/threading-multi/test_bounded_queue_fifo The Jam file: import testing ; project : requirements <library>../../test/build//boost_unit_test_framework <library>../../thread/build//boost_thread <library>../../system/build//boost_system <link>static <threading>multi ; rule tp-test ( source ) { return [ run $(source).cpp ] ; } test-suite thread_pool : [ tp-test test_bounded_queue_fifo ] [ tp-test test_bounded_queue_lifo ] [ tp-test test_bounded_queue_priority ] [ tp-test test_bounded_queue_smart ] [ tp-test test_unbounded_queue_fifo ] [ tp-test test_unbounded_queue_lifo ] [ tp-test test_unbounded_queue_priority ] [ tp-test test_unbounded_queue_smart ] ; Platform LINUX (Debian/Lenny). regards, Oliver

3 3

Preview 3 of the Geometry Library
by Barend Gehrels 27 Oct '08

27 Oct '08

Dear list, Herewith the URL to the third preview of our Geometry Library, including documentation and examples. The first two previews were sent to this list in January and in March. Since then, Bruno Lalande, already a Boost contributor, joined and we together reworked the library and its concepts. Lines (sequences of points) are now generic, handled using iterator pairs. Concepts have been worked out and integrated everywhere in the code. A Google Summer of Code project, handling Spatial Indexing, is based on the geometries of this library. Many discussions and comments were related to the concepts and, more specific, to the Point concept. This is the most basic thing of a geometry library and has to be as generic as possible. We think we implemented it like that into the library. The library can handle all point types including legacy point types, point types provided by the library, user defined point types, Cartesian points, native arrays, points with spherical coordinates. The library provides point_xy for Cartesian systems and point_ll for lat long systems, but the library user is thus not confined to those types. Using a strategy mechanism, the library should be able to handle every point type, and lines made of those types. The distance / simplify algorithms clearly show this design. The library is not completed, it is still a preview. It is used in real life projects but will still be enhanced and extended. The point type is now generic and lines (sequences of points) are generic. However, boxes, circles and polygons still have to be reviewed and their concepts can be worked out further. Some algorithms will be reprocessed to use strategies and handle any point type. The URL with documentation is here: http://geometrylibrary.geodan.nl. The library is Open Source and uses the Boost License. However, being a preview and not yet a real submission, the SVN is not at boost but still hosted at Geodan. If you are interested you can get SVN access. There were since March two other geometry library references sent to the list. This really shows the need for a Geometry Library into the boost collection. We welcome any discussion, comment or contribution and we are open for any type of cooperation, merge or join. Barend Gehrels

13 49

[zip_iterator] Understanding why.
by Robert Jones 27 Oct '08

27 Oct '08

Zip iterator implements the functionality I need to advance associated iterators through different ranges, but it seems strangly awkward to use, which is odd for Boost. so I'm wondering if I've misunderstood the design paradigms. Given two ranges (say vectors), I'd like to be able to generate an iterable composite, anditerate through that, something like vector<int> v1; vector<int> v2; typedef zip_composite<int, int> Z; Z zip( v1, v2 ); for ( Z::iterator i=zip.begin( ); i !=zip.end( ); ++i ) { // ... blah, blah, blah } Is this impossible or undesirable to implement for reasons I've not realized? Thanks, Rob.

4 3

[1.37.0] Release branch post-beta merges
by Beman Dawes 27 Oct '08

27 Oct '08

The release branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See http://svn.boost.org/trac/boost/wiki/ReleasePractices/PostBetaMerges The final release is currently planned for Sunday, November 2nd. It would be helpful if all merges were complete a couple of days before that to allow plenty of time for tests to cycle and other pre-release preparation. Thanks, --The release managers

1 0

[release management] Draft policy for changes between beta and release
by Beman Dawes 27 Oct '08

27 Oct '08

In another post, John Maddock asked what sort of QA problems should be fixed between the beta and final releases, and what the criteria and procedures are. Here is a quick draft of a possible policy: * Showstoppers. Criteria: Bugs or other problems so serious that the release is seriously compromised if not fixed. Procedure: After discussion on the developers list, release managers will specify how the problem is to be attacked, and what effect it will have on schedule. * Documentation and other minor fixes not affecting code. Criteria: Changes not requiring regression testing and unlikely to impact other libraries. Procedure: Merges to branches/release are OK, after fix applied to trunk, and do not require a release manager's permission. * Minor code fixes. Criteria: Changes believed to have limited risk and that have already been made to trunk and are stable on trunk regression testing. Procedure: Merges to branches/release after fix stable on trunk tests do not require a release manager's permission. * Questionable code fixes. Criteria: Any code changes not meeting the "Minor code fix" criteria, such as a change with a lot of possible ripple effect on other libraries. Procedure: Ask release managers for permission. * Tools changes and fixes. Code changes to bjam, Boost.Build, Boost.Test, the doc build process, and other tools are discouraged late in release cycles in general and between beta and release in particular. Ask release managers for permission if you really think the change is warranted for this release. * New features, breaking changes, major reworks, new libraries. These are not suitable for merging between beta and release. Wait until the next release. Comments? --Beman

5 8

[1.37] status/Jamfile.v2
by Nicola Musatti 27 Oct '08

27 Oct '08

Hallo, I believe the Jamfile.v2 in the status directory should be merged to the release branch. The one that's there looks older than the directory reorganization that was performed a while ago, and it doesn't include the tests for several libraries. Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/

9 17

[mpl] Error in map docs (or bug)
by John Bytheway 26 Oct '08

26 Oct '08

I think I've found an error in the MPL docs (In trunk and 1.35, and presumably everything in between). The documentation for mpl::map state that "count<m,k>::type" yields "The number of elements with the key k in m", where in fact what it returns is the number of elements *equal* to k in m. This is consistent with the documentation of mpl::count. I suspect this is an error in the docs rather than a bug, since there is also mpl::has_key, which serves the purpose count claims to be serving (but isn't). Consider this code: #include <boost/mpl/has_key.hpp> #include <boost/mpl/count.hpp> #include <boost/mpl/assert.hpp> #include <boost/mpl/set.hpp> #include <boost/mpl/map.hpp> #include <boost/mpl/insert.hpp> using namespace boost::mpl; typedef set< int >::type my_set; typedef map< boost::mpl::pair<int, int> >::type my_map; BOOST_MPL_ASSERT((has_key<my_set, int >::type)); BOOST_MPL_ASSERT((count<my_set, int >::type)); BOOST_MPL_ASSERT((has_key<my_map, int >::type)); BOOST_MPL_ASSERT((count<my_map, int >::type)); BOOST_MPL_ASSERT((count<my_map, pair<int,int> >::type)); The fourth assertion fails. If the map docs were accurate then it would be the fifth assertion that failed. The same error is in the Associative Sequence docs, and perhaps other places. John Bytheway

1 0

Directory monitor for Windows (Boost.Asio extension)
by Boris 26 Oct '08

26 Oct '08

I had created a file monitor in March as a reference implementation of how to develop a Boost.Asio extension. While it was pretty incomplete at that time it has become a grown-up and fully tested directory monitor which supports both synchronous and asynchronous I/O. It currently works on Windows only as it is based on Microsoft's I/O Completion Ports (for those who need a directory monitor on Linux see http://article.gmane.org/gmane.comp.lib.boost.asio.user/2699) The directory monitor can be downloaded here: http://www.highscore.de/boost/dir_monitor.zip The zip archive contains various tests which can be used for a quick start. As the directory monitor is pretty small it shouldn't take much longer than 10 minutes to use it in your own projects. Boris

1 0

[test] Patch for gcc warning suppression.
by John Maddock 25 Oct '08

25 Oct '08

I'm getting a bunch of warnings from floating_point_comparison.hpp with gcc, the attached patch fixes these, if these are OK, I can commit from here. That just leaves: c:\data\boost\boost\trunk/boost/test/floating_point_comparison.hpp:246: warning: 'boost::test_tools::<unnamed>::check_is_small' defined but not used Is there any way to get rid of that as well? Thanks, John.

3 3

Welcome to the Boost Developers Archive on Google Groups!
by Eric Niebler 24 Oct '08

24 Oct '08

I've subscribed Google Groups to the boost developers list, so that people who would like to follow the group that way (and get an RSS feed to the list) can do so. http://groups.google.com/group/boost-developers-archive It can't import old messages, but new messages should show up there and be search-able. I hope. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

Class-level instrospection
by Joel Falcou 24 Oct '08

24 Oct '08

Daniel Walker a écrit : > Why don't we both package what we have, upload to vault, and then > work out merging the two and adding the rest in another thread? I've cleaned-up my files and 'boostified' them so to speak. I've uploaded a 'introspection.zip' on the vault so you can grab it and we can start discussing this in a proper topic ;) Basically i've uploaded the following : BOOST_HAVE_MEMBER_FUNCTION BOOST_HAVE_CONST_MEMBER_FUNCTION BOOST_HAVE_NON_CONST_MEMBER_FUNCTION BOOST_HAVE_MEMBER_DATA Basically, the usage is really simple. You want to check if classes provides a bool is_ok(long) method and you want to catch both const and non-const variations : BOOST_HAVE_MEMBER_FUNCTION(is_ok, bool(long) ) then the check itself is done via : has_member_function<T>::type For BOOST_HAVE_DATA_MEMBER, my method can only check for public members. So I added a macoer called BOOST_INSTROSPECTION_SUPPORT(C,V) that have to be used in user-defined class C that want to publish a member named V to our introspection mecanism. struct foo { private : int mValue; }; struct bar { BOOST_INTROSPECTION_SUPPORT(bar,mValue); private : int mValue; }; BOOST_HAVE_MEMBER_DATA(int, mValue) has_member_data_mValue<foo>::value is false has_member_data_mValue<bar>::value is true Other limitations is that currently you can't have various check for a method with a given name but different signature. I'm working on a fix using PP sequence and : BOOST_HAS_MEMBER_FUNCTION_OVERLOADS(func,(void())(void(int))(void(int,int))) In the same way, checking for suff like operator[] yields invalid class name has_member_function_operator[]. So I propose we hand-code the following : BOOST_HAS_SUBSCRIPT_OPERATOR( void(int) ) that builds a has_subscript_operator<T> class. Other similar operator should be handled the same way.

4 7

[General] A standard idiom or technique?
by Robert Jones 24 Oct '08

24 Oct '08

A recent post in this list started me thinking... Given this code snippet, using namespace std; void f( int, int ); vector<int> v1; vector<int> v2; // populate... for ( unsigned i = 0; i <= v1.size( ); ++ i ) { f( v1[ i ], v2[ i ] ); } How would you write this as a for_each() or in some other Boosty, functional way? (The aspect I'm trying to highlight is that two iterators over different ranges must advance in step) One could imagine a tuple-based solution, in which one specifies how an operation applied to the tuple distributes to operations applied to each of the tuple's elements. Does any such thing exist in Boost? Is it ever necessary, or can the functionality be achieved by some C++/STL/Boost idiom that I've not thought of? If there is no obvious technique, is there any interest in a Boost library which address this in a generic way? Thanks. - Rob.

5 7

How to install Boost.Numeric.Bindings
by Peng Yu 24 Oct '08

24 Oct '08

Hi, I've downloaded the whole boost src. svn co https://svn.boost.org/svn/boost boost Right now, I need Boost.Numeric.Bindings which is in the sandbox. I tried bjam, but I got the following error. Can somebody let me know how to compile Boost.Numeric.Bindings? Thanks, Peng $ bjam Unable to load Boost.Build: could not find build system. --------------------------------------------------------- /home/local/eda06/yupeng/test/C++/svn/boost/sandbox/boost-build.jam attempted to load the build system by invoking 'boost-build ;' but we were unable to find "bootstrap.jam" in the specified directory or in BOOST_BUILD_PATH (searching /usr/share/boost-build). Please consult the documentation at 'http://www.boost.org'.

3 8

[Pool]: How to tag pool_allocator
by VoidEx 24 Oct '08

24 Oct '08

Hello pool_allocator based on singleton allocator, but uses it's own tag. But I want use one pool_allocator for some strings/vectors/lists and another for some other data, because I want destroy data separately. Is it possible now? Or may be I do it wrong?

2 2

[pool] Conversion to Boost.Thread for singleton_pool
by Chris Newbold 24 Oct '08

24 Oct '08

Boost.Pool contains a private mutex implementation used as the default mutex type for singleton_pool (which provides a thread-safe API). Now that Boost.Thread is well-established and in line with TR1, I'd like to jettison the private mutex implementation inside Boost.Pool and switch the default mutex type to be boost::mutex. The obvious consequence of this change is that singleton_pool becomes dependent on Boost.Thread. The dependency would exist only for singleton_pool and its clients and would not affect the other Boost.Pool interfaces. Anyone have any objections or reasons why this wouldn't be a good idea? -Chris

3 5

[Generator Iterator] [random]
by Andy Tompkins 24 Oct '08

24 Oct '08

I am trying to use boost::generator_iterator with a random number generator as follows: --- #include <boost/generator_iterator.hpp> #include <boost/random/mersenne_twister.hpp> class my_generator {...}; my_generator gen; boost::generator_iterator<my_generator> first(&gen); boost::generator_iterator<my_generator> last; boost::random::mt19937 rng; rng.seed(first, last); --- Sadly the default constructor of generator_iterator leaves m_gen uninitialized and the seed function is trying to compare first with last. I could pass gen to last, ie. boost::generator_iterator<my_generator> last(&gen), but then if ever begin has the same value as end, it will stop. The documentation for generator_iterator says that it models an input iterator, and I assume that an input iterator is ok to use with the seed function. I'm not sure what can/should be done. Thanks in advance, Andy.

2 3

[filesystem] file monitoring
by Carlos Rafael Giani 24 Oct '08

24 Oct '08

Hi, is a file monitor feature planned for boost.filesystem? I have been looking for a platform independent solution, but there is none (except in toolkits like Qt). Also, so far only inotify (a subsystem in the Linux kernel) can tell me when a file is closed after writing, which is absolutely necessary when watching a plugins/ directory, for example (you don't want to touch the plugins when they're only halfway copied). Several tools watch the plugin directory, but don't care if the plugins are being written or are fully there already. This can lead to instabilities. I think it is only logical to add this to boost.filesystem, something like set_monitor_callback(pathname, function_object); any thoughts?

10 11

[function] function.hpp lacks include guard
by Okko Willeboordse 24 Oct '08

24 Oct '08

Hello, My co-worker Bob Praster found, using PC-Lint 9.0, that function.hpp doesn't have an include guard like; #ifndef BOOST_FUNCTION_HPP #define BOOST_FUNCTION_HPP ... #endif // BOOST_FUNCTION_HPP Kind regards, Okko Willeboordse

12 17

[boost.org] people not updated?
by Thorsten Ottosen 24 Oct '08

24 Oct '08

Hi, It seems like we are missing some of our recent members. -Thorsten

4 3

[asio] HTTPS async_read() question
by Gregory Dai 24 Oct '08

24 Oct '08

I'm playing with the following SSL client example against an https site: http://www.boost.org/doc/libs/1_36_0/doc/html/boost_asio/example/ssl/client… I replaced std::cout << "Enter message: " with the part of the URL corresponding to an HTTP GET request, and changed the handle_read() to void handle_read(const boost::system::error_code& error, size_t bytes_transferred) { if (!error) { std::cout << "Reply: "; std::cout.write(reply_, bytes_transferred); std::cout << "\n"; boost::asio::async_read(socket_, boost::asio::buffer(reply_, bytes_transferred), boost::bind(&client::handle_read, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } else { std::cout << "Read failed: " << error << "\n"; } } so that it goes back to read more data. I'm able to get more than 20k data in response, but unable to reach the end of the data stream as the browser can. What could be a good reason for this behavior? Thanks, Greg

2 2

Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92
by Hartmut Kaiser 24 Oct '08

24 Oct '08

Robert, Would it be possible to get an answer to my initial questions, please? Thanks! Regards Hartmut > Anything I can do about this? > What does this assertion mean? > > My setup: Linux 64Bit, gcc 4.2.4, serialization is used for polymorphic > objects loaded from different shared libraries, shared libraries are > loaded with dlopen(RTLD_GLOBAL|RTLD_LAZY). > > Assertion (extended_type_info.cpp:92) occurs during program termination > (after main returned), during dlclose(). > > If anything else isn't possible, would it be appropriate to change the > related code (before the release!) from: > > assert(start != end); > > // remove entry in map which corresponds to this type > do{ > if(this == *start) > x.erase(start++); > else > ++start; > }while(start != end); > > To: > > assert(start != end); > > // remove entry in map which corresponds to this type > while(start != end) { > if(this == *start) > x.erase(start++); > else > ++start; > } > > Which wouldn't remove the problem, but at least avoids hanging the > program if assertions are off... > > Regards Hartmut

3 6

[release management] Drop .gz and .zip release packaging?
by Beman Dawes 23 Oct '08

23 Oct '08

Boost releases are currently packaged four ways. With CR/NL line endings: boost_1_37_0_beta1.7z 27,340,204 boost_1_37_0_beta1.zip 57,017,457 With NL line endings: boost_1_37_0_beta1.tar.bz2 29,494,538 boost_1_37_0_beta1.tar.gz 36,436,716 I'd like to drop the .zip and .gz packages, starting with release 1.38.0. The primary motivation is a personal one; as release manager I do a lot of FTP transfers and would like to spend less time waiting for the big .zip and .gz packages to upload/download. The problem I see is that CR/NL users still download .zip files twice as often as .7z, and NL users still download about as many .gz packages as bz2. Comments? --Beman

11 11

[1.37] Showstopper? Documentation pdf build broken.
by John Maddock 23 Oct '08

23 Oct '08

Generation of pdf's from the docbook source appears to be terminally broken at present, for example: fop.render.pdf ..\..\..\bin.v2\libs\config\doc\msvc-8.0\debug\threading-multi\config.pdf (document [system-id file:/c:/data/boost/boost/trunk/libs/config/doc/../../../bin.v2/libs/config/doc/msvc-8.0/debug/threading-multi/config.fo] (validate [error] Element 'fo:inline' cannot be a child of 'fo:flow'. Only block-level elements are permitted in this context. [validation total: 1 error] Parse error: Invalid XSL FO source 'file:/c:/data/boost/boost/trunk/libs/config/doc/../../../bin.v2/libs/config/doc/msvc-8.0/debug/threading-multi/config.fo': 1 error found during validation The problem occurs with both FOP and XEP as the FO translator BTW. Anyone know where to look for the problem? John.

1 0

[1.37] Fixing doc typos in the beta.
by John Maddock 23 Oct '08

23 Oct '08

Someone's just emailed me regarding a doc typo in Boost.Regex. Is this the sort of QA issue that should be fixed between the beta and release? If so what criteria and procedure should we be applying? Cheers, John.

2 1

[pool] doubling algorithm
by Boris 23 Oct '08

23 Oct '08

Are there any plans to make the pool's doubling algorithm configurable? It would be great if it was possible for example to set an upper limit or to use constant chunk sizes (thus no algorithm at all). If there are no plans may I propose then some patches? I ask as I need to configure the pool as it eats too much memory sometimes. Boris

3 5

[test] Problems building Boost.Test
by Daniel Walker 23 Oct '08

23 Oct '08

Hello, I'm trying to build Boost.Test from SVN trunk. Linking the dynamic libraries fails with gcc 4.0 on OSX. Apparently, the option -h is passed to the linker. Not sure what that means. The complete bjam output follows. Daniel Walker $ echo $OSTYPE darwin9.0 $ gcc --version i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5488) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ bjam --version Boost.Build V2 (Milestone 12) Boost.Jam 03.1.16 $ svn update At revision 49428. $ bjam --toolset=gcc --with-test ...patience... ...found 659 targets... ...updating 2 targets... gcc.link.dll bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_prg_exec_monitor-gcc40-mt-1_37.dylib ld: unknown option: -h collect2: ld returned 1 exit status "g++" -o "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_prg_exec_monitor-gcc40-mt-1_37.dylib" -Wl,-h -Wl,libboost_prg_exec_monitor-gcc40-mt-1_37.dylib -shared -Wl,--start-group "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/execution_monitor.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/debug.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/cpp_main.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -Wl,--strip-all ...failed gcc.link.dll bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_prg_exec_monitor-gcc40-mt-1_37.dylib... gcc.link.dll bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_unit_test_framework-gcc40-mt-1_37.dylib ld: unknown option: -h collect2: ld returned 1 exit status "g++" -o "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_unit_test_framework-gcc40-mt-1_37.dylib" -Wl,-h -Wl,libboost_unit_test_framework-gcc40-mt-1_37.dylib -shared -Wl,--start-group "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/execution_monitor.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/debug.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/compiler_log_formatter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/framework.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/plain_report_formatter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/progress_monitor.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/results_collector.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/results_reporter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/test_tools.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_log.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_main.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_monitor.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_parameters.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_suite.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/xml_log_formatter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/xml_report_formatter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/exception_safety.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/interaction_based.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/logged_expectations.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -Wl,--strip-all ...failed gcc.link.dll bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_unit_test_framework-gcc40-mt-1_37.dylib... ...failed updating 2 targets... $

3 5

[1.37.0][serialization] unreferenced formal parameter warning
by Jeff Flinn 22 Oct '08

22 Oct '08

Robert, Can this be fixed: \boost_1_37_0\boost/serialization/extended_type_info_typeid.hpp(115) : warning C4100: 'p' : unreferenced formal parameter I'm also having trouble reading portable_binary file generated from boost_1_35_0. I'll try to reproduce with a smaller test case, but if you have any ideas on what to look for I'd appreciated it. Thanks, Jeff

3 4

[1.37.0] The release branch is closed; please do not commit
by Beman Dawes 22 Oct '08

22 Oct '08

The release branch is closed; please do not commit. Creating the beta is in process and it really screws things up if branches/release changes. --Beman

1 0

[1.37.0][serialization] possible loss of data warnings
by Jeff Flinn 22 Oct '08

22 Oct '08

Robert, The following warnings are the result of assigning int values to smaller data types in basic_binary_oarchive::save_overload. Any thoughts on clearing these up. Should these use numeric_cast? boost_1_37_0\boost/archive/basic_binary_oarchive.hpp(72) : warning C4244: 'initializing' : conversion from 'const unsigned int' to 'const unsigned char', possible loss of data boost_1_37_0\boost/archive/basic_binary_oarchive.hpp(77) : warning C4244: 'initializing' : conversion from 'const int' to 'const boost::int_least16_t', possible loss of data \boost_1_37_0\boost/archive/basic_binary_oarchive.hpp(82) : warning C4244: 'initializing' : conversion from 'const int' to 'const boost::int_least16_t', possible loss of data Thanks, Jeff

1 0

Re: [boost] New library in Vault: Msm (Meta State Machine)
by Christophe Henry 22 Oct '08

22 Oct '08

Hi Andreas, > Whether you'd want to work with entry & exit points in the alarm-beeps > case is a matter of taste. I personally wouldn't bother simply because it > seems unlikely that it can be reused anywhere. Do you mean your example is irrelevant or that reuse is not important? > To reach a definite verdict in this particular example we'd need to define > first what coupling in a state machine actually means. To my knowledge, > nobody has done that so far. Do you need more than common sense to know that if you need to see inside of a state machine you have coupling? > Given my first 3 paragraphs above, I hope it has become clear that a > state-boundary-crossing transition combined with an entry/exit-point is > *not* an encapsulation breach. Please forgive me for not agreeing. > Just to make sure we're not talking past each other: With "entry/exit > states" I guess you mean "entry point pseudostate" and "exit point > pseudostate" as defined in UML? Yes, are there other possibilities? > You have read the whole paragraph, right? I quote it here for clarity: > > <quote> > A submachine state is semantically equivalent to a composite state. The > regions of the submachine state machine are the regions of the composite > state. The entry, exit, and behavior actions and internal transitions are > defined as part of the state. Submachine state is a decomposition > mechanism that allows factoring of common behaviors and their reuse. > </quote> > > Note the first sentence. What is unclear here? Well, first why there are 2 terms. They are not equal but equivalent. So what is the difference? And what does it have to do with the subject? The important part is about reuse. Again this is a key point for Msm. > I don't follow. Isn't it a fact that the current version of Msm only > supports a single entry point for a composite state/submachine, namely the > initial state? There is the entry function of the sub state machine and the one of the initial state. > Exactly. However, IIUC, at the moment Msm only supports a single entry > point and a single exit point, which IMO also makes reuse harder than > necessary, see below. Again I have to disagree. When a program runs, it calls functions, which call other functions, etc. Now if you read a book of Model Driven Development, you'll probably find inside that a UML diagram and code are two views of the same model. And now we have it. You don't mind having a single entry point in a function, right? Why is it a problem in a diagram? And there we are again, multiple entry points in a function are labels and goto. > Firstly, let's be clear that any reasonable semantics definition for FSMs > (e.g. Harel, UML) absolutely requires that an entry action of a composite > state/submachine is called when the composite state/submachine is entered > and it doesn't matter at all how the state is entered (ordinary > transition, state-boundary-crossing transition). The same goes for the > exit action when the state is left. Unfortunately I understood it the other way and had to go to great lengths in the example you gave me to avoid the entry of the composite. Maybe I'm not the only unreasonable and this brings confusion? > To cut a long story short: I would encourage you to do either of the > following: > > 1) Allow state-boundary-crossing transitions (without entry/exit points). > Once you have these, entry- and exit-points are a no-brainer: An entry > point is simply a member typedef in the type that defines the submachine. > An exit-point can be supported just as easily by passing the destination > state(s) as template parameters to the submachine. > 2) Introduce entry & exit points as first-class concepts. Implementing a > state-boundary-crossing transition would then become a three step process: > a) define an entry/exit point, b) connect the point with an internal > state, c) connect the point with an external state. > > In my (admittedly biased) view and from a purely conceptual standpoint > (ignoring e.g. performance and other real-world stuff for the moment), > option 1 is clearly superior as it gives the user complete freedom how to > tackle his design problems. Option 2 would be acceptable, when it is clear > that supporting 1) requires too many trade-offs. My goal is not to reimplement Statechart but offer an alternative. It is a key point for Msm to provide an easy-to-use interface and increase reusability. And a list of destination states in the submachine definition does neither. But we already discussed this. I wrote in the documentation of Msm and repeated you that I could implement entry and exit pseudostates if users asked for it. And this only if I'm satisfied of the solution I would offer. Regards, Christophe

2 1

[Boost.Msm] On the necessity of state-boundary-crossing transitions
by Andreas Huber 22 Oct '08

22 Oct '08

Unfortunately, the original thread on this subject has led to so many side arguments that IMO the main point hasn't gotten the attention it deserves. I'll therefore try to summarize the main point here, so that hopefully a more focused discussion results. State machine behavioral standards like e.g. Harel & UML allow that transitions can cross state boundaries. One example for when this is beneficial is given in Fig. 8 of Harel's paper, which can be found here: <http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Statecharts.pdf> In this example, the main reason for the existence of the "alarms-beep" composite state is to avoid duplicating the two transitions triggered by the "any button pressed" and "30 sec in alarms-beep" events. The design of Boost.Msm and the arguments presented in the thread titled "New library in Vault: Msm (Meta State Machine)" seem to amount to the following claim: It is *invariably* bad practice to let transitions cross state boundaries. It follows that a state machine like the one shown in Fig. 8 should *always* be redesigned so that the transitions no longer need to cross state boundaries [1]. For Fig. 8, I claim that any such redesign will lead to information duplication in the diagram and the code implementing it. Moreover, it's probably safe to say that the ultimate bad practice in software engineering is expressing the same piece of information more often in the code than minimally required by the language [2]. Therefore, if following a best practice leads to code duplication then common sense would mandate to choose the lesser of the two evils. So, boundary-crossing transitions cannot always be avoided. Therefore, the challenge is to show that my claim for Fig. 8 is wrong by coming up with an alternative state machine design with the same observable behavior where transitions no longer cross state boundaries without duplicating anything (transitions, events, states) [3]. Note that the leaf-state in which the machine currently resides is part of the observable behavior. So any redesign must have at least the states "alarm 1 beeps", "alarm 2 beeps", "both beep" and "displays". Anything else can be changed to suit. Note that Fig. 8 shows just one widely used pattern that employs boundary-crossing transitions. Other patterns employ them as well. So, even if Fig. 8 can be redesigned without boundary-crossing transitions and without duplicating any information then this is just one data point. Suitable redesigns for the other patterns would have to be shown as well. [1] UML's entry & exit points are "just" encapsulation tools that allow the designer of a composite state to only expose the parts of the inner workings that must be visible from the outside world. So, a transition destined to an entry point does in fact still cross the state boundary. The same goes for a transition originating at an exit point. [2] Of course, all rules come with exceptions: In some cases code duplication can increase performance, which in turn might help to meet system requirements that otherwise couldn't be met. Under such circumstances of course the lesser evil is the code duplication. [3] The obvious solution of moving the "displays" state into the "alarms-beep" state just replaces the crossings of the transitions triggered by the "T hits ..." events with the crossings of the transitions triggered by the "any button pressed" and the "30 sec in alarms-beep" events. Depending on how the latter transitions are drawn, the crossings might not be visible graphically but on the conceptual level they still exist. This is why such transitions are often drawn as the one triggered by y shown in Figure 2 here: <http://www.codeproject.com/KB/cpp/Statechart.aspx> -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

Are there any some utilities that helps to show where a exception is from?
by Peng Yu 22 Oct '08

22 Oct '08

Hi, If there is an error happens, I want to throw an exception, with the error string of the following format (similar to what assert would give). main.cc:12: int main(): some message I'm wondering if boost has such facility. I'm a new boost developer, I want to understand how existing boost libraries take care of runtime errors? Thanks, Peng

5 6

[RangeEx] Using istream_range?
by Robert Jones 22 Oct '08

22 Oct '08

Hi All I'd really appreciate an example of the use of istream_range from the Boost.Range library. I tried this #include <iostream> #include <iterator> #include "boost/range.hpp" #include "boost/range/istream_range.hpp" #include "boost/range/algorithm.hpp" void f( int i ) { std :: cout << i << std :: endl; } int main( ) { typedef std :: istream_iterator< int > in; boost :: for_each( boost :: istream_range< in >( std :: cin ), f ); return 0; } and other variations, but I don't think any of them are right! Do I really have to specify three template type parameters? The signature of the template is namespace boost { template<class Type, class Elem, class Traits> inline range<std::istream_iterator<Type, Elem, Traits> > istream_range(std::basic_istream<Elem, Traits>& in) { return range<std::istream_iterator<Type, Elem, Traits> >( std::istream_iterator<Elem>(in), std::istream_iterator<Elem>()); } } Thanks, Rob.

4 14

Re : Selective Unit Testing.
by dominic ibeme 22 Oct '08

22 Oct '08

Thanks Gennadiy for the immediate & direct response. i can't seem to find a way to specify dependencies for Auto Registered use cases.. cos they are registered during static initialization which would occur before u had a chance to specify dependencies. I'm thinking of the possiblility of tranversing the hierarcy from the master test suite, apparently, this seems non trivial, "i got lost in the plenitude of Macros being used" if there could be a way of manipulating the automated Registration test suites when invoking the initialization function Thanks.

1 0

Boost::statechart: state reaction returned result
by Rajpal Dangi 22 Oct '08

22 Oct '08

Could someone suggest me the recomended way of communicating error from fsm to the fsm user application? Assume state reaction unable to process event due to error and returns with discard_event(). As application calls process_event() to post an event which is of type "void". How do I make sure that my event was processed successfuly and not discarded? Thanks, Rajpal

2 1

Submit a library that compute the roots of a polynomial upto the 4th order
by Peng Yu 22 Oct '08

22 Oct '08

Hi, This is my first time that I wan to submit a library to boost. On http://www.boost.org/development/submissions.html, it mentioned boost vault, without explaining what it is. Can somebody let me know what it is? What is the difference between boost vault and boost sandbox? Do I need to submit my library to vault or sandbox? Where shall I put it? Thanks, Peng

4 4

Re: [boost] Selective Unit Testing
by dominic ibeme 22 Oct '08

22 Oct '08

Thanks Gennadiy . i can't seem to find a way to specify dependencies for test cases that are automatically registered. ----- Original Message ---- From: "boost-request(a)lists.boost.org" <boost-request(a)lists.boost.org> To: boost(a)lists.boost.org Sent: Tuesday, October 21, 2008 5:00:03 PM Subject: Boost Digest, Vol 2343, Issue 3 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/MailArchives/boost/ Today's Topics: 1. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (joaquin(a)tid.es) 2. Selective Unit Testing (dominic ibeme) 3. Re: [mp_int] new release (Paul A Bristow) 4. Re: [1.37.0] beta 1 release candidate QA (Paul A Bristow) 5. Re: [1.37.0] beta 1 release candidate QA (Beman Dawes) 6. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) 7. [function] function.hpp lacks include guard (Okko Willeboordse) 8. Re: [1.37.0] beta 1 release candidate QA (Paul A Bristow) 9. Re: [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 (Peter Dimov) 10. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (joaquin(a)tid.es) 11. Re: Selective Unit Testing (Gennadiy Rozental) 12. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Gennaro Prota) 13. Re: [function] function.hpp lacks include guard (Mathias Gaunard) 14. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) 15. Re: [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) 16. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 Oct 2008 15:39:10 +0200 From: joaquin(a)tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Message-ID: <48FDDB7E.8060600(a)tid.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hartmut Kaiser escribi?: >> assert(start != end); >> >> // remove entry in map which corresponds to this type >> do{ >> if(this == *start) >> x.erase(start++); >> else >> ++start; >> }while(start != end); >> > > After looking at this code again I have the impression that it is broken > anyways. You can't safely increment an iterator after deleting the object it > points to: erase(start++). I think your objection is wrong: erase(start++) is perfectly safe because the incrementing op is executed before erase is invoked. Joaqu?n M L?pez Mu?oz Telef?nica, Investigaci?n y Desarrollo ------------------------------ Message: 2 Date: Tue, 21 Oct 2008 06:20:27 -0700 (PDT) From: dominic ibeme <detroydom(a)yahoo.com> Subject: [boost] Selective Unit Testing To: boost(a)lists.boost.org Message-ID: <96943.77520.qm(a)web53502.mail.re2.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Hi .. I've been using the boost unit testing framework and its quite a wonderful library... thanks to Gennadiy, however the section on advanced usage wasn't made available in release 1.36. i would really like to know how to perform selective testing i.e executing? test with dependencies, i guess this would show up in the future, but i kind of need help on this one. This request list has been?extremely helpful..? ------------------------------ Message: 3 Date: Tue, 21 Oct 2008 15:06:21 +0100 From: "Paul A Bristow" <pbristow(a)hetp.u-net.com> Subject: Re: [boost] [mp_int] new release To: <boost(a)lists.boost.org> Message-ID: <004e01c93386$32d5dac0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Brandon Kohn >Sent: 10 October 2008 16:37 >To: boost(a)lists.boost.org >Subject: Re: [boost] [mp_int] new release >-------------------------------------------------- >From: "Kevin Sopp" <baraclese(a)googlemail.com> >Sent: Friday, October 10, 2008 10:25 AM >To: <boost(a)lists.boost.org> >Subject: Re: [boost] [mp_int] new release I've tried to use your simple "general use" example in your documentation with MS Visual studio 9.0 Sadly it fails to compile with an Internal compiler error :-( 1>Compiling... 1>demo_unbounded_int.cpp 1>i:\trunk\boost\mp_math\mp_int\detail\string_conversion_constants.hpp(44) : fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1411) 1> To work around this problem, try simplifying or changing the program near the locations listed above. 1>Please choose the Technical Support command on the Visual C++ 1> Help menu, or open the Technical Support help file for more information 1> i:\trunk\boost\mp_math\mp_int\detail\string_conversion_constants.hpp(47) : see reference to class template instantiation 'boost::mp_math::detail::max_power<MpInt,Base>' being compiled This is a bit of a showstopper ;-) Or am I doing something silly? Any suggestions about what to try changing? Thanks Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com PS >I'll also need these for sure so it would be nice if they were added to the next release: > >template <> >class numeric_limits< boost::mp_math::mp_int<> > >{ >private: > typedef boost::mp_math::mp_int<> Type; >public: > static const bool is_specialized = true; > static const int digits = 0; > static const int digits10 = 0; > static const bool is_signed = true; > static const bool is_integer = true; > static const bool is_exact = true; > static const int radix = 2; > static const int min_exponent = 0; > static const int min_exponent10 = 0; > static const int max_exponent = 0; > static const int max_exponent10 = 0; > static const bool has_infinity = false; > static const bool has_quiet_NaN = false; > static const bool has_signaling_NaN = false; > static const float_denorm_style has_denorm = denorm_absent; > static const bool has_denorm_loss = false; > static const bool is_iec559 = false; > static const bool is_bounded = false; > static const bool is_modulo = false; > static const bool traps = false; > static const bool tinyness_before = false; > static const float_round_style round_style = round_toward_zero; > static Type min() > { > return static_cast<Type>(0); > } > static Type max() > { > return static_cast<Type>(0); > } > > static Type epsilon() > { > return static_cast<Type>(1); > } > > static Type round_error() > { > return static_cast<Type>(1); > } > > static Type infinity() > { > return static_cast<Type>(0); > } > > static Type quiet_NaN() > { > return static_cast<Type>(0); > } > > static Type denorm_min() > { > return static_cast<Type>(1); > } > }; >} // namespace std > ------------------------------ Message: 4 Date: Tue, 21 Oct 2008 15:16:20 +0100 From: "Paul A Bristow" <pbristow(a)hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost(a)lists.boost.org> Message-ID: <004f01c93387$97fa88f0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes >Sent: 21 October 2008 13:54 >To: Boost Developers list >Subject: [boost] [1.37.0] beta 1 release candidate QA > >1.37.0 beta 1 release candidates are available at >http://boost.cowic.de/rc/ > >Before pushing these out to SourceForge, we need volunteers to >download and install, following the getting started guide. > >See >http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html Is this right - it says 1_36_0 rather than 1_37_0? Thanks Paul PS The http://boost.cowic.de/rc/inspect-snapshot.html Inspection report says "The files checked were from at revision ." rather than including the revision number. I suspect this is not intended? --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com ------------------------------ Message: 5 Date: Tue, 21 Oct 2008 10:40:46 -0400 From: "Beman Dawes" <bdawes(a)acm.org> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: boost(a)lists.boost.org Message-ID: <a61d44020810210740l22606e39w236bea29b0c6222c(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow <pbristow(a)hetp.u-net.com>wrote: > >-----Original Message----- > >From: boost-bounces(a)lists.boost.org > >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes > >Sent: 21 October 2008 13:54 > >To: Boost Developers list > >Subject: [boost] [1.37.0] beta 1 release candidate QA > > > >1.37.0 beta 1 release candidates are available at > >http://boost.cowic.de/rc/ > > > >Before pushing these out to SourceForge, we need volunteers to > >download and install, following the getting started guide. > > > >See > >http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html > > Is this right - it says 1_36_0 rather than 1_37_0? Not really, but we haven't updated beta.boost.org yet. I need to ping Rene; I'm not sure what has to be done. > > Thanks > > Paul > > PS The http://boost.cowic.de/rc/inspect-snapshot.html Inspection report > says > > "The files checked were from at revision ." > > rather than including the revision number. I suspect this is not intended? The inspect program needs to be changed to get the revision number somewhere else if inspect isn't being run on an SVN working copy. I'll put my thinking hat on and see if I can come up with a reliable way to do that. Thanks, --Beman ------------------------------ Message: 6 Date: Tue, 21 Oct 2008 09:41:16 -0500 From: "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdea18.06025a0a.7a9f.6c94(a)mx.google.com> Content-Type: text/plain; charset="iso-8859-1" > Hartmut Kaiser escribi?: > >> assert(start != end); > >> > >> // remove entry in map which corresponds to this type > >> do{ > >> if(this == *start) > >> x.erase(start++); > >> else > >> ++start; > >> }while(start != end); > >> > > > > After looking at this code again I have the impression that it is > broken > > anyways. You can't safely increment an iterator after deleting the > object it > > points to: erase(start++). > > I think your objection is wrong: erase(start++) is perfectly safe > because the incrementing op > is executed before erase is invoked. Actually, to be concise, you're invoking undefined behavior. The Standard doesn't guarantee any execution order of operations in this context. The only thing which is guaranteed is, that the operation executed by erase() uses the initial value and afterwards start has been incremented (well, whatever happens if you increment an iterator after erasing the element it's pointing to). Regards Hartmut ------------------------------ Message: 7 Date: Tue, 21 Oct 2008 16:41:36 +0200 From: Okko Willeboordse <trash(a)willeboordse.demon.nl> Subject: [boost] [function] function.hpp lacks include guard To: boost(a)lists.boost.org Message-ID: <gdkpn1$ajl$1(a)ger.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello, My co-worker Bob Praster found, using PC-Lint 9.0, that function.hpp doesn't have an include guard like; #ifndef BOOST_FUNCTION_HPP #define BOOST_FUNCTION_HPP ... #endif // BOOST_FUNCTION_HPP Kind regards, Okko Willeboordse ------------------------------ Message: 8 Date: Tue, 21 Oct 2008 15:48:27 +0100 From: "Paul A Bristow" <pbristow(a)hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost(a)lists.boost.org> Message-ID: <005001c9338c$141aaba0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes >Sent: 21 October 2008 15:41 >To: boost(a)lists.boost.org >Subject: Re: [boost] [1.37.0] beta 1 release candidate QA > >On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow ><pbristow(a)hetp.u-net.com>wrote: > >> >-----Original Message----- >> >From: boost-bounces(a)lists.boost.org >> >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes >> >Sent: 21 October 2008 13:54 >> >To: Boost Developers list >> >Subject: [boost] [1.37.0] beta 1 release candidate QA >> > >> >1.37.0 beta 1 release candidates are available at >> >http://boost.cowic.de/rc/ >> > >> >Before pushing these out to SourceForge, we need volunteers to >> >download and install, following the getting started guide. >> > >> >See >> >>http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html >> >> Is this right - it says 1_36_0 rather than 1_37_0? > >Not really, but we haven't updated beta.boost.org yet. I need >to ping Rene; >I'm not sure what has to be done. So should I try to follow those instructions anyway? Or wait a while? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com ------------------------------ Message: 9 Date: Tue, 21 Oct 2008 17:55:01 +0300 From: "Peter Dimov" <pdimov(a)pdimov.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <AADF4B12D73849629D295161BAC51971@pdimov2> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Hartmut Kaiser: > Actually, to be concise, you're invoking undefined behavior. The Standard > doesn't guarantee any execution order of operations in this context. It does, there is a sequence point before the call. ------------------------------ Message: 10 Date: Tue, 21 Oct 2008 16:59:20 +0200 From: joaquin(a)tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Message-ID: <48FDEE48.6020003(a)tid.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hartmut Kaiser escribi?: >> Hartmut Kaiser escribi?: >> >>>> assert(start != end); >>>> >>>> // remove entry in map which corresponds to this type >>>> do{ >>>> if(this == *start) >>>> x.erase(start++); >>>> else >>>> ++start; >>>> }while(start != end); >>>> >>>> >>> After looking at this code again I have the impression that it is >>> >> broken >> >>> anyways. You can't safely increment an iterator after deleting the >>> >> object it >> >>> points to: erase(start++). >>> >> I think your objection is wrong: erase(start++) is perfectly safe >> because the incrementing op >> is executed before erase is invoked. >> > > Actually, to be concise, you're invoking undefined behavior. The Standard > doesn't guarantee any execution order of operations in this context. The > only thing which is guaranteed is, that the operation executed by erase() > uses the initial value and afterwards start has been incremented (well, > whatever happens if you increment an iterator after erasing the element it's > pointing to). > I still disagree; start++ produces a side effect (std 1.9.7, emphasis mine): "Accessing an object designated by a volatile lvalue (3.10), *modifying an object* [...] are all side effects, which are changes in the state of the execution environment.[...] At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place." and as such, it must have taken place by the time the function erase is invoked (std 1.9.17): "When calling a function (whether or not the function is inline), there is a sequence point after the evaluation of all function arguments (if any) which takes place before execution of any expressions or statements in the function body .[...]" Am i missing something? Joaqu?n M L?pez Mu?oz Telef?nica, Investigaci?n y Desarrollo ------------------------------ Message: 11 Date: Tue, 21 Oct 2008 15:19:53 +0000 (UTC) From: Gennadiy Rozental <rogeeff(a)gmail.com> Subject: Re: [boost] Selective Unit Testing To: boost(a)lists.boost.org Message-ID: <loom.20081021T151743-746(a)post.gmane.org> Content-Type: text/plain; charset=utf-8 dominic ibeme <detroydom <at> yahoo.com> writes: > > Hi .. > > I've been using the boost unit testing framework and its quite a wonderful library... > thanks to Gennadiy, however the section on advanced usage wasn't made available > in release 1.36. i would really like to know how to perform selective testing i.e executing? > test with dependencies, i guess this would show up in the future, but i kind of need help > on this one. To specify dependencies test_unit has method "depends_on". Also you can run test by name. It should be covered in docs. Gennadiy ------------------------------ Message: 12 Date: Tue, 21 Oct 2008 17:37:03 +0200 From: Gennaro Prota <gennaro.prota(a)yahoo.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: boost(a)lists.boost.org Message-ID: <gdkstr$opo$1(a)ger.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hartmut Kaiser wrote: >> Anything I can do about this? >> What does this assertion mean? >> >> My setup: Linux 64Bit, gcc 4.2.4, serialization is used for polymorphic >> objects loaded from different shared libraries, shared libraries are >> loaded with dlopen(RTLD_GLOBAL|RTLD_LAZY). >> >> Assertion (extended_type_info.cpp:92) occurs during program termination >> (after main returned), during dlclose(). >> >> If anything else isn't possible, would it be appropriate to change the >> related code (before the release!) from: >> >> assert(start != end); >> >> // remove entry in map which corresponds to this type >> do{ >> if(this == *start) >> x.erase(start++); >> else >> ++start; >> }while(start != end); > > After looking at this code again I have the impression that it is broken > anyways. Yes, but IMHO not for the reason you mention. Certainly I wouldn't let the start++/++start "dance" pass a code review. PS: don't use tab characters in posts! :-) -- Genny ------------------------------ Message: 13 Date: Tue, 21 Oct 2008 17:54:35 +0200 From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> Subject: Re: [boost] [function] function.hpp lacks include guard To: boost(a)lists.boost.org Message-ID: <gdktvq$sjg$1(a)ger.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Okko Willeboordse wrote: > My co-worker Bob Praster found, using PC-Lint 9.0, that function.hpp > doesn't have an include guard That's most likely because it doesn't need one, since it's only including other headers. ------------------------------ Message: 14 Date: Tue, 21 Oct 2008 10:55:57 -0500 From: "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfb98.14025a0a.2e02.ffff84e4(a)mx.google.com> Content-Type: text/plain; charset="us-ascii" > Hartmut Kaiser wrote: > >> Anything I can do about this? > >> What does this assertion mean? > >> > >> My setup: Linux 64Bit, gcc 4.2.4, serialization is used for > polymorphic > >> objects loaded from different shared libraries, shared libraries are > >> loaded with dlopen(RTLD_GLOBAL|RTLD_LAZY). > >> > >> Assertion (extended_type_info.cpp:92) occurs during program > termination > >> (after main returned), during dlclose(). > >> > >> If anything else isn't possible, would it be appropriate to change > the > >> related code (before the release!) from: > >> > >> assert(start != end); > >> > >> // remove entry in map which corresponds to this type > >> do{ > >> if(this == *start) > >> x.erase(start++); > >> else > >> ++start; > >> }while(start != end); > > > > After looking at this code again I have the impression that it is > broken > > anyways. > > Yes, but IMHO not for the reason you mention. Certainly I > wouldn't let the start++/++start "dance" pass a code review. Agreed. > PS: don't use tab characters in posts! :-) It's a raw copy of the code, so there have to be tabs in the source files... Regards Hartmut ------------------------------ Message: 15 Date: Tue, 21 Oct 2008 10:57:10 -0500 From: "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfbe0.07045a0a.162b.ffffba69(a)mx.google.com> Content-Type: text/plain; charset="us-ascii" > Hartmut Kaiser: > > Actually, to be concise, you're invoking undefined behavior. The > Standard > > doesn't guarantee any execution order of operations in this context. > > It does, there is a sequence point before the call. Ok, there is always something new to learn out there. Thanks! Regards Hartmut PS: Anyway, that doesn't fix my assertion in the first place either :-P ------------------------------ Message: 16 Date: Tue, 21 Oct 2008 10:59:26 -0500 From: "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfc69.07045a0a.162b.ffffbb50(a)mx.google.com> Content-Type: text/plain; charset="us-ascii" > > Actually, to be concise, you're invoking undefined behavior. The > Standard > > doesn't guarantee any execution order of operations in this context. > The > > only thing which is guaranteed is, that the operation executed by > erase() > > uses the initial value and afterwards start has been incremented > (well, > > whatever happens if you increment an iterator after erasing the > element it's > > pointing to). > > > > I still disagree; start++ produces a side effect (std 1.9.7, emphasis > mine): > > "Accessing an object designated by a volatile lvalue (3.10), > *modifying an object* [...] > are all side effects, which are changes in the state of the execution > environment.[...] > At certain specified points in the execution sequence called sequence > points, all side > effects of previous evaluations shall be complete and no side effects > of subsequent > evaluations shall have taken place." > > and as such, it must have taken place by the time the function erase is > invoked (std 1.9.17): > > "When calling a function (whether or not the function is inline), > there is a sequence point > after the evaluation of all function arguments (if any) which takes > place before execution > of any expressions or statements in the function body .[...]" Ok, I'm wrong. But I remember at least one problem in the past I have had exactly because of this. But that just might have been a non-conforming compiler playing games on me. Thanks for the explanations. Regards Hartmut ------------------------------ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost End of Boost Digest, Vol 2343, Issue 3 **************************************

2 1

Re: [boost] Selective Unit Testing
by dominic ibeme 22 Oct '08

22 Oct '08

Thanks Gennadiy . i can't seem to find a way to specify dependencies for test cases that are automatically registered. ----- Original Message ---- From: "boost-request(a)lists.boost.org" <boost-request(a)lists.boost.org> To: boost(a)lists.boost.org Sent: Tuesday, October 21, 2008 5:00:03 PM Subject: Boost Digest, Vol 2343, Issue 3 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/MailArchives/boost/ Today's Topics: 1. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (joaquin(a)tid.es) 2. Selective Unit Testing (dominic ibeme) 3. Re: [mp_int] new release (Paul A Bristow) 4. Re: [1.37.0] beta 1 release candidate QA (Paul A Bristow) 5. Re: [1.37.0] beta 1 release candidate QA (Beman Dawes) 6. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) 7. [function] function.hpp lacks include guard (Okko Willeboordse) 8. Re: [1.37.0] beta 1 release candidate QA (Paul A Bristow) 9. Re: [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 (Peter Dimov) 10. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (joaquin(a)tid.es) 11. Re: Selective Unit Testing (Gennadiy Rozental) 12. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Gennaro Prota) 13. Re: [function] function.hpp lacks include guard (Mathias Gaunard) 14. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) 15. Re: [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) 16. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 Oct 2008 15:39:10 +0200 From: joaquin(a)tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Message-ID: <48FDDB7E.8060600(a)tid.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hartmut Kaiser escribi?: >> assert(start != end); >> >> // remove entry in map which corresponds to this type >> do{ >> if(this == *start) >> x.erase(start++); >> else >> ++start; >> }while(start != end); >> > > After looking at this code again I have the impression that it is broken > anyways. You can't safely increment an iterator after deleting the object it > points to: erase(start++). I think your objection is wrong: erase(start++) is perfectly safe because the incrementing op is executed before erase is invoked. Joaqu?n M L?pez Mu?oz Telef?nica, Investigaci?n y Desarrollo ------------------------------ Message: 2 Date: Tue, 21 Oct 2008 06:20:27 -0700 (PDT) From: dominic ibeme <detroydom(a)yahoo.com> Subject: [boost] Selective Unit Testing To: boost(a)lists.boost.org Message-ID: <96943.77520.qm(a)web53502.mail.re2.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Hi .. I've been using the boost unit testing framework and its quite a wonderful library... thanks to Gennadiy, however the section on advanced usage wasn't made available in release 1.36. i would really like to know how to perform selective testing i.e executing? test with dependencies, i guess this would show up in the future, but i kind of need help on this one. This request list has been?extremely helpful..? ------------------------------ Message: 3 Date: Tue, 21 Oct 2008 15:06:21 +0100 From: "Paul A Bristow" <pbristow(a)hetp.u-net.com> Subject: Re: [boost] [mp_int] new release To: <boost(a)lists.boost.org> Message-ID: <004e01c93386$32d5dac0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Brandon Kohn >Sent: 10 October 2008 16:37 >To: boost(a)lists.boost.org >Subject: Re: [boost] [mp_int] new release >-------------------------------------------------- >From: "Kevin Sopp" <baraclese(a)googlemail.com> >Sent: Friday, October 10, 2008 10:25 AM >To: <boost(a)lists.boost.org> >Subject: Re: [boost] [mp_int] new release I've tried to use your simple "general use" example in your documentation with MS Visual studio 9.0 Sadly it fails to compile with an Internal compiler error :-( 1>Compiling... 1>demo_unbounded_int.cpp 1>i:\trunk\boost\mp_math\mp_int\detail\string_conversion_constants.hpp(44) : fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1411) 1> To work around this problem, try simplifying or changing the program near the locations listed above. 1>Please choose the Technical Support command on the Visual C++ 1> Help menu, or open the Technical Support help file for more information 1> i:\trunk\boost\mp_math\mp_int\detail\string_conversion_constants.hpp(47) : see reference to class template instantiation 'boost::mp_math::detail::max_power<MpInt,Base>' being compiled This is a bit of a showstopper ;-) Or am I doing something silly? Any suggestions about what to try changing? Thanks Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com PS >I'll also need these for sure so it would be nice if they were added to the next release: > >template <> >class numeric_limits< boost::mp_math::mp_int<> > >{ >private: > typedef boost::mp_math::mp_int<> Type; >public: > static const bool is_specialized = true; > static const int digits = 0; > static const int digits10 = 0; > static const bool is_signed = true; > static const bool is_integer = true; > static const bool is_exact = true; > static const int radix = 2; > static const int min_exponent = 0; > static const int min_exponent10 = 0; > static const int max_exponent = 0; > static const int max_exponent10 = 0; > static const bool has_infinity = false; > static const bool has_quiet_NaN = false; > static const bool has_signaling_NaN = false; > static const float_denorm_style has_denorm = denorm_absent; > static const bool has_denorm_loss = false; > static const bool is_iec559 = false; > static const bool is_bounded = false; > static const bool is_modulo = false; > static const bool traps = false; > static const bool tinyness_before = false; > static const float_round_style round_style = round_toward_zero; > static Type min() > { > return static_cast<Type>(0); > } > static Type max() > { > return static_cast<Type>(0); > } > > static Type epsilon() > { > return static_cast<Type>(1); > } > > static Type round_error() > { > return static_cast<Type>(1); > } > > static Type infinity() > { > return static_cast<Type>(0); > } > > static Type quiet_NaN() > { > return static_cast<Type>(0); > } > > static Type denorm_min() > { > return static_cast<Type>(1); > } > }; >} // namespace std > ------------------------------ Message: 4 Date: Tue, 21 Oct 2008 15:16:20 +0100 From: "Paul A Bristow" <pbristow(a)hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost(a)lists.boost.org> Message-ID: <004f01c93387$97fa88f0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes >Sent: 21 October 2008 13:54 >To: Boost Developers list >Subject: [boost] [1.37.0] beta 1 release candidate QA > >1.37.0 beta 1 release candidates are available at >http://boost.cowic.de/rc/ > >Before pushing these out to SourceForge, we need volunteers to >download and install, following the getting started guide. > >See >http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html Is this right - it says 1_36_0 rather than 1_37_0? Thanks Paul PS The http://boost.cowic.de/rc/inspect-snapshot.html Inspection report says "The files checked were from at revision ." rather than including the revision number. I suspect this is not intended? --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com ------------------------------ Message: 5 Date: Tue, 21 Oct 2008 10:40:46 -0400 From: "Beman Dawes" <bdawes(a)acm.org> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: boost(a)lists.boost.org Message-ID: <a61d44020810210740l22606e39w236bea29b0c6222c(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow <pbristow(a)hetp.u-net.com>wrote: > >-----Original Message----- > >From: boost-bounces(a)lists.boost.org > >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes > >Sent: 21 October 2008 13:54 > >To: Boost Developers list > >Subject: [boost] [1.37.0] beta 1 release candidate QA > > > >1.37.0 beta 1 release candidates are available at > >http://boost.cowic.de/rc/ > > > >Before pushing these out to SourceForge, we need volunteers to > >download and install, following the getting started guide. > > > >See > >http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html > > Is this right - it says 1_36_0 rather than 1_37_0? Not really, but we haven't updated beta.boost.org yet. I need to ping Rene; I'm not sure what has to be done. > > Thanks > > Paul > > PS The http://boost.cowic.de/rc/inspect-snapshot.html Inspection report > says > > "The files checked were from at revision ." > > rather than including the revision number. I suspect this is not intended? The inspect program needs to be changed to get the revision number somewhere else if inspect isn't being run on an SVN working copy. I'll put my thinking hat on and see if I can come up with a reliable way to do that. Thanks, --Beman ------------------------------ Message: 6 Date: Tue, 21 Oct 2008 09:41:16 -0500 From: "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdea18.06025a0a.7a9f.6c94(a)mx.google.com> Content-Type: text/plain; charset="iso-8859-1" > Hartmut Kaiser escribi?: > >> assert(start != end); > >> > >> // remove entry in map which corresponds to this type > >> do{ > >> if(this == *start) > >> x.erase(start++); > >> else > >> ++start; > >> }while(start != end); > >> > > > > After looking at this code again I have the impression that it is > broken > > anyways. You can't safely increment an iterator after deleting the > object it > > points to: erase(start++). > > I think your objection is wrong: erase(start++) is perfectly safe > because the incrementing op > is executed before erase is invoked. Actually, to be concise, you're invoking undefined behavior. The Standard doesn't guarantee any execution order of operations in this context. The only thing which is guaranteed is, that the operation executed by erase() uses the initial value and afterwards start has been incremented (well, whatever happens if you increment an iterator after erasing the element it's pointing to). Regards Hartmut ------------------------------ Message: 7 Date: Tue, 21 Oct 2008 16:41:36 +0200 From: Okko Willeboordse <trash(a)willeboordse.demon.nl> Subject: [boost] [function] function.hpp lacks include guard To: boost(a)lists.boost.org Message-ID: <gdkpn1$ajl$1(a)ger.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello, My co-worker Bob Praster found, using PC-Lint 9.0, that function.hpp doesn't have an include guard like; #ifndef BOOST_FUNCTION_HPP #define BOOST_FUNCTION_HPP ... #endif // BOOST_FUNCTION_HPP Kind regards, Okko Willeboordse ------------------------------ Message: 8 Date: Tue, 21 Oct 2008 15:48:27 +0100 From: "Paul A Bristow" <pbristow(a)hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost(a)lists.boost.org> Message-ID: <005001c9338c$141aaba0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes >Sent: 21 October 2008 15:41 >To: boost(a)lists.boost.org >Subject: Re: [boost] [1.37.0] beta 1 release candidate QA > >On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow ><pbristow(a)hetp.u-net.com>wrote: > >> >-----Original Message----- >> >From: boost-bounces(a)lists.boost.org >> >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes >> >Sent: 21 October 2008 13:54 >> >To: Boost Developers list >> >Subject: [boost] [1.37.0] beta 1 release candidate QA >> > >> >1.37.0 beta 1 release candidates are available at >> >http://boost.cowic.de/rc/ >> > >> >Before pushing these out to SourceForge, we need volunteers to >> >download and install, following the getting started guide. >> > >> >See >> >>http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html >> >> Is this right - it says 1_36_0 rather than 1_37_0? > >Not really, but we haven't updated beta.boost.org yet. I need >to ping Rene; >I'm not sure what has to be done. So should I try to follow those instructions anyway? Or wait a while? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com ------------------------------ Message: 9 Date: Tue, 21 Oct 2008 17:55:01 +0300 From: "Peter Dimov" <pdimov(a)pdimov.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <AADF4B12D73849629D295161BAC51971@pdimov2> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Hartmut Kaiser: > Actually, to be concise, you're invoking undefined behavior. The Standard > doesn't guarantee any execution order of operations in this context. It does, there is a sequence point before the call. ------------------------------ Message: 10 Date: Tue, 21 Oct 2008 16:59:20 +0200 From: joaquin(a)tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Message-ID: <48FDEE48.6020003(a)tid.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hartmut Kaiser escribi?: >> Hartmut Kaiser escribi?: >> >>>> assert(start != end); >>>> >>>> // remove entry in map which corresponds to this type >>>> do{ >>>> if(this == *start) >>>> x.erase(start++); >>>> else >>>> ++start; >>>> }while(start != end); >>>> >>>> >>> After looking at this code again I have the impression that it is >>> >> broken >> >>> anyways. You can't safely increment an iterator after deleting the >>> >> object it >> >>> points to: erase(start++). >>> >> I think your objection is wrong: erase(start++) is perfectly safe >> because the incrementing op >> is executed before erase is invoked. >> > > Actually, to be concise, you're invoking undefined behavior. The Standard > doesn't guarantee any execution order of operations in this context. The > only thing which is guaranteed is, that the operation executed by erase() > uses the initial value and afterwards start has been incremented (well, > whatever happens if you increment an iterator after erasing the element it's > pointing to). > I still disagree; start++ produces a side effect (std 1.9.7, emphasis mine): "Accessing an object designated by a volatile lvalue (3.10), *modifying an object* [...] are all side effects, which are changes in the state of the execution environment.[...] At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place." and as such, it must have taken place by the time the function erase is invoked (std 1.9.17): "When calling a function (whether or not the function is inline), there is a sequence point after the evaluation of all function arguments (if any) which takes place before execution of any expressions or statements in the function body .[...]" Am i missing something? Joaqu?n M L?pez Mu?oz Telef?nica, Investigaci?n y Desarrollo ------------------------------ Message: 11 Date: Tue, 21 Oct 2008 15:19:53 +0000 (UTC) From: Gennadiy Rozental <rogeeff(a)gmail.com> Subject: Re: [boost] Selective Unit Testing To: boost(a)lists.boost.org Message-ID: <loom.20081021T151743-746(a)post.gmane.org> Content-Type: text/plain; charset=utf-8 dominic ibeme <detroydom <at> yahoo.com> writes: > > Hi .. > > I've been using the boost unit testing framework and its quite a wonderful library... > thanks to Gennadiy, however the section on advanced usage wasn't made available > in release 1.36. i would really like to know how to perform selective testing i.e executing? > test with dependencies, i guess this would show up in the future, but i kind of need help > on this one. To specify dependencies test_unit has method "depends_on". Also you can run test by name. It should be covered in docs. Gennadiy ------------------------------ Message: 12 Date: Tue, 21 Oct 2008 17:37:03 +0200 From: Gennaro Prota <gennaro.prota(a)yahoo.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: boost(a)lists.boost.org Message-ID: <gdkstr$opo$1(a)ger.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hartmut Kaiser wrote: >> Anything I can do about this? >> What does this assertion mean? >> >> My setup: Linux 64Bit, gcc 4.2.4, serialization is used for polymorphic >> objects loaded from different shared libraries, shared libraries are >> loaded with dlopen(RTLD_GLOBAL|RTLD_LAZY). >> >> Assertion (extended_type_info.cpp:92) occurs during program termination >> (after main returned), during dlclose(). >> >> If anything else isn't possible, would it be appropriate to change the >> related code (before the release!) from: >> >> assert(start != end); >> >> // remove entry in map which corresponds to this type >> do{ >> if(this == *start) >> x.erase(start++); >> else >> ++start; >> }while(start != end); > > After looking at this code again I have the impression that it is broken > anyways. Yes, but IMHO not for the reason you mention. Certainly I wouldn't let the start++/++start "dance" pass a code review. PS: don't use tab characters in posts! :-) -- Genny ------------------------------ Message: 13 Date: Tue, 21 Oct 2008 17:54:35 +0200 From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> Subject: Re: [boost] [function] function.hpp lacks include guard To: boost(a)lists.boost.org Message-ID: <gdktvq$sjg$1(a)ger.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Okko Willeboordse wrote: > My co-worker Bob Praster found, using PC-Lint 9.0, that function.hpp > doesn't have an include guard That's most likely because it doesn't need one, since it's only including other headers. ------------------------------ Message: 14 Date: Tue, 21 Oct 2008 10:55:57 -0500 From: "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfb98.14025a0a.2e02.ffff84e4(a)mx.google.com> Content-Type: text/plain; charset="us-ascii" > Hartmut Kaiser wrote: > >> Anything I can do about this? > >> What does this assertion mean? > >> > >> My setup: Linux 64Bit, gcc 4.2.4, serialization is used for > polymorphic > >> objects loaded from different shared libraries, shared libraries are > >> loaded with dlopen(RTLD_GLOBAL|RTLD_LAZY). > >> > >> Assertion (extended_type_info.cpp:92) occurs during program > termination > >> (after main returned), during dlclose(). > >> > >> If anything else isn't possible, would it be appropriate to change > the > >> related code (before the release!) from: > >> > >> assert(start != end); > >> > >> // remove entry in map which corresponds to this type > >> do{ > >> if(this == *start) > >> x.erase(start++); > >> else > >> ++start; > >> }while(start != end); > > > > After looking at this code again I have the impression that it is > broken > > anyways. > > Yes, but IMHO not for the reason you mention. Certainly I > wouldn't let the start++/++start "dance" pass a code review. Agreed. > PS: don't use tab characters in posts! :-) It's a raw copy of the code, so there have to be tabs in the source files... Regards Hartmut ------------------------------ Message: 15 Date: Tue, 21 Oct 2008 10:57:10 -0500 From: "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfbe0.07045a0a.162b.ffffba69(a)mx.google.com> Content-Type: text/plain; charset="us-ascii" > Hartmut Kaiser: > > Actually, to be concise, you're invoking undefined behavior. The > Standard > > doesn't guarantee any execution order of operations in this context. > > It does, there is a sequence point before the call. Ok, there is always something new to learn out there. Thanks! Regards Hartmut PS: Anyway, that doesn't fix my assertion in the first place either :-P ------------------------------ Message: 16 Date: Tue, 21 Oct 2008 10:59:26 -0500 From: "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfc69.07045a0a.162b.ffffbb50(a)mx.google.com> Content-Type: text/plain; charset="us-ascii" > > Actually, to be concise, you're invoking undefined behavior. The > Standard > > doesn't guarantee any execution order of operations in this context. > The > > only thing which is guaranteed is, that the operation executed by > erase() > > uses the initial value and afterwards start has been incremented > (well, > > whatever happens if you increment an iterator after erasing the > element it's > > pointing to). > > > > I still disagree; start++ produces a side effect (std 1.9.7, emphasis > mine): > > "Accessing an object designated by a volatile lvalue (3.10), > *modifying an object* [...] > are all side effects, which are changes in the state of the execution > environment.[...] > At certain specified points in the execution sequence called sequence > points, all side > effects of previous evaluations shall be complete and no side effects > of subsequent > evaluations shall have taken place." > > and as such, it must have taken place by the time the function erase is > invoked (std 1.9.17): > > "When calling a function (whether or not the function is inline), > there is a sequence point > after the evaluation of all function arguments (if any) which takes > place before execution > of any expressions or statements in the function body .[...]" Ok, I'm wrong. But I remember at least one problem in the past I have had exactly because of this. But that just might have been a non-conforming compiler playing games on me. Thanks for the explanations. Regards Hartmut ------------------------------ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost End of Boost Digest, Vol 2343, Issue 3 **************************************

1 0

Re: [boost] Selective Unit Testing
by dominic ibeme 22 Oct '08

22 Oct '08

Thanks Gennadiy . i can't seem to find a way to specify dependencies for test cases that are automatically registered. ----- Original Message ---- From: "boost-request(a)lists.boost.org" <boost-request(a)lists.boost.org> To: boost(a)lists.boost.org Sent: Tuesday, October 21, 2008 5:00:03 PM Subject: Boost Digest, Vol 2343, Issue 3 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/MailArchives/boost/ Today's Topics: 1. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (joaquin(a)tid.es) 2. Selective Unit Testing (dominic ibeme) 3. Re: [mp_int] new release (Paul A Bristow) 4. Re: [1.37.0] beta 1 release candidate QA (Paul A Bristow) 5. Re: [1.37.0] beta 1 release candidate QA (Beman Dawes) 6. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) 7. [function] function.hpp lacks include guard (Okko Willeboordse) 8. Re: [1.37.0] beta 1 release candidate QA (Paul A Bristow) 9. Re: [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 (Peter Dimov) 10. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (joaquin(a)tid.es) 11. Re: Selective Unit Testing (Gennadiy Rozental) 12. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Gennaro Prota) 13. Re: [function] function.hpp lacks include guard (Mathias Gaunard) 14. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) 15. Re: [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) 16. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 Oct 2008 15:39:10 +0200 From: joaquin(a)tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Message-ID: <48FDDB7E.8060600(a)tid.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hartmut Kaiser escribi?: >> assert(start != end); >> >> // remove entry in map which corresponds to this type >> do{ >> if(this == *start) >> x.erase(start++); >> else >> ++start; >> }while(start != end); >> > > After looking at this code again I have the impression that it is broken > anyways. You can't safely increment an iterator after deleting the object it > points to: erase(start++). I think your objection is wrong: erase(start++) is perfectly safe because the incrementing op is executed before erase is invoked. Joaqu?n M L?pez Mu?oz Telef?nica, Investigaci?n y Desarrollo ------------------------------ Message: 2 Date: Tue, 21 Oct 2008 06:20:27 -0700 (PDT) From: dominic ibeme <detroydom(a)yahoo.com> Subject: [boost] Selective Unit Testing To: boost(a)lists.boost.org Message-ID: <96943.77520.qm(a)web53502.mail.re2.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Hi .. I've been using the boost unit testing framework and its quite a wonderful library... thanks to Gennadiy, however the section on advanced usage wasn't made available in release 1.36. i would really like to know how to perform selective testing i.e executing? test with dependencies, i guess this would show up in the future, but i kind of need help on this one. This request list has been?extremely helpful..? ------------------------------ Message: 3 Date: Tue, 21 Oct 2008 15:06:21 +0100 From: "Paul A Bristow" <pbristow(a)hetp.u-net.com> Subject: Re: [boost] [mp_int] new release To: <boost(a)lists.boost.org> Message-ID: <004e01c93386$32d5dac0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Brandon Kohn >Sent: 10 October 2008 16:37 >To: boost(a)lists.boost.org >Subject: Re: [boost] [mp_int] new release >-------------------------------------------------- >From: "Kevin Sopp" <baraclese(a)googlemail.com> >Sent: Friday, October 10, 2008 10:25 AM >To: <boost(a)lists.boost.org> >Subject: Re: [boost] [mp_int] new release I've tried to use your simple "general use" example in your documentation with MS Visual studio 9.0 Sadly it fails to compile with an Internal compiler error :-( 1>Compiling... 1>demo_unbounded_int.cpp 1>i:\trunk\boost\mp_math\mp_int\detail\string_conversion_constants.hpp(44) : fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1411) 1> To work around this problem, try simplifying or changing the program near the locations listed above. 1>Please choose the Technical Support command on the Visual C++ 1> Help menu, or open the Technical Support help file for more information 1> i:\trunk\boost\mp_math\mp_int\detail\string_conversion_constants.hpp(47) : see reference to class template instantiation 'boost::mp_math::detail::max_power<MpInt,Base>' being compiled This is a bit of a showstopper ;-) Or am I doing something silly? Any suggestions about what to try changing? Thanks Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com PS >I'll also need these for sure so it would be nice if they were added to the next release: > >template <> >class numeric_limits< boost::mp_math::mp_int<> > >{ >private: > typedef boost::mp_math::mp_int<> Type; >public: > static const bool is_specialized = true; > static const int digits = 0; > static const int digits10 = 0; > static const bool is_signed = true; > static const bool is_integer = true; > static const bool is_exact = true; > static const int radix = 2; > static const int min_exponent = 0; > static const int min_exponent10 = 0; > static const int max_exponent = 0; > static const int max_exponent10 = 0; > static const bool has_infinity = false; > static const bool has_quiet_NaN = false; > static const bool has_signaling_NaN = false; > static const float_denorm_style has_denorm = denorm_absent; > static const bool has_denorm_loss = false; > static const bool is_iec559 = false; > static const bool is_bounded = false; > static const bool is_modulo = false; > static const bool traps = false; > static const bool tinyness_before = false; > static const float_round_style round_style = round_toward_zero; > static Type min() > { > return static_cast<Type>(0); > } > static Type max() > { > return static_cast<Type>(0); > } > > static Type epsilon() > { > return static_cast<Type>(1); > } > > static Type round_error() > { > return static_cast<Type>(1); > } > > static Type infinity() > { > return static_cast<Type>(0); > } > > static Type quiet_NaN() > { > return static_cast<Type>(0); > } > > static Type denorm_min() > { > return static_cast<Type>(1); > } > }; >} // namespace std > ------------------------------ Message: 4 Date: Tue, 21 Oct 2008 15:16:20 +0100 From: "Paul A Bristow" <pbristow(a)hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost(a)lists.boost.org> Message-ID: <004f01c93387$97fa88f0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes >Sent: 21 October 2008 13:54 >To: Boost Developers list >Subject: [boost] [1.37.0] beta 1 release candidate QA > >1.37.0 beta 1 release candidates are available at >http://boost.cowic.de/rc/ > >Before pushing these out to SourceForge, we need volunteers to >download and install, following the getting started guide. > >See >http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html Is this right - it says 1_36_0 rather than 1_37_0? Thanks Paul PS The http://boost.cowic.de/rc/inspect-snapshot.html Inspection report says "The files checked were from at revision ." rather than including the revision number. I suspect this is not intended? --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com ------------------------------ Message: 5 Date: Tue, 21 Oct 2008 10:40:46 -0400 From: "Beman Dawes" <bdawes(a)acm.org> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: boost(a)lists.boost.org Message-ID: <a61d44020810210740l22606e39w236bea29b0c6222c(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow <pbristow(a)hetp.u-net.com>wrote: > >-----Original Message----- > >From: boost-bounces(a)lists.boost.org > >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes > >Sent: 21 October 2008 13:54 > >To: Boost Developers list > >Subject: [boost] [1.37.0] beta 1 release candidate QA > > > >1.37.0 beta 1 release candidates are available at > >http://boost.cowic.de/rc/ > > > >Before pushing these out to SourceForge, we need volunteers to > >download and install, following the getting started guide. > > > >See > >http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html > > Is this right - it says 1_36_0 rather than 1_37_0? Not really, but we haven't updated beta.boost.org yet. I need to ping Rene; I'm not sure what has to be done. > > Thanks > > Paul > > PS The http://boost.cowic.de/rc/inspect-snapshot.html Inspection report > says > > "The files checked were from at revision ." > > rather than including the revision number. I suspect this is not intended? The inspect program needs to be changed to get the revision number somewhere else if inspect isn't being run on an SVN working copy. I'll put my thinking hat on and see if I can come up with a reliable way to do that. Thanks, --Beman ------------------------------ Message: 6 Date: Tue, 21 Oct 2008 09:41:16 -0500 From: "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdea18.06025a0a.7a9f.6c94(a)mx.google.com> Content-Type: text/plain; charset="iso-8859-1" > Hartmut Kaiser escribi?: > >> assert(start != end); > >> > >> // remove entry in map which corresponds to this type > >> do{ > >> if(this == *start) > >> x.erase(start++); > >> else > >> ++start; > >> }while(start != end); > >> > > > > After looking at this code again I have the impression that it is > broken > > anyways. You can't safely increment an iterator after deleting the > object it > > points to: erase(start++). > > I think your objection is wrong: erase(start++) is perfectly safe > because the incrementing op > is executed before erase is invoked. Actually, to be concise, you're invoking undefined behavior. The Standard doesn't guarantee any execution order of operations in this context. The only thing which is guaranteed is, that the operation executed by erase() uses the initial value and afterwards start has been incremented (well, whatever happens if you increment an iterator after erasing the element it's pointing to). Regards Hartmut ------------------------------ Message: 7 Date: Tue, 21 Oct 2008 16:41:36 +0200 From: Okko Willeboordse <trash(a)willeboordse.demon.nl> Subject: [boost] [function] function.hpp lacks include guard To: boost(a)lists.boost.org Message-ID: <gdkpn1$ajl$1(a)ger.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello, My co-worker Bob Praster found, using PC-Lint 9.0, that function.hpp doesn't have an include guard like; #ifndef BOOST_FUNCTION_HPP #define BOOST_FUNCTION_HPP ... #endif // BOOST_FUNCTION_HPP Kind regards, Okko Willeboordse ------------------------------ Message: 8 Date: Tue, 21 Oct 2008 15:48:27 +0100 From: "Paul A Bristow" <pbristow(a)hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost(a)lists.boost.org> Message-ID: <005001c9338c$141aaba0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes >Sent: 21 October 2008 15:41 >To: boost(a)lists.boost.org >Subject: Re: [boost] [1.37.0] beta 1 release candidate QA > >On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow ><pbristow(a)hetp.u-net.com>wrote: > >> >-----Original Message----- >> >From: boost-bounces(a)lists.boost.org >> >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes >> >Sent: 21 October 2008 13:54 >> >To: Boost Developers list >> >Subject: [boost] [1.37.0] beta 1 release candidate QA >> > >> >1.37.0 beta 1 release candidates are available at >> >http://boost.cowic.de/rc/ >> > >> >Before pushing these out to SourceForge, we need volunteers to >> >download and install, following the getting started guide. >> > >> >See >> >>http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html >> >> Is this right - it says 1_36_0 rather than 1_37_0? > >Not really, but we haven't updated beta.boost.org yet. I need >to ping Rene; >I'm not sure what has to be done. So should I try to follow those instructions anyway? Or wait a while? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com ------------------------------ Message: 9 Date: Tue, 21 Oct 2008 17:55:01 +0300 From: "Peter Dimov" <pdimov(a)pdimov.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <AADF4B12D73849629D295161BAC51971@pdimov2> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Hartmut Kaiser: > Actually, to be concise, you're invoking undefined behavior. The Standard > doesn't guarantee any execution order of operations in this context. It does, there is a sequence point before the call. ------------------------------ Message: 10 Date: Tue, 21 Oct 2008 16:59:20 +0200 From: joaquin(a)tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Message-ID: <48FDEE48.6020003(a)tid.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hartmut Kaiser escribi?: >> Hartmut Kaiser escribi?: >> >>>> assert(start != end); >>>> >>>> // remove entry in map which corresponds to this type >>>> do{ >>>> if(this == *start) >>>> x.erase(start++); >>>> else >>>> ++start; >>>> }while(start != end); >>>> >>>> >>> After looking at this code again I have the impression that it is >>> >> broken >> >>> anyways. You can't safely increment an iterator after deleting the >>> >> object it >> >>> points to: erase(start++). >>> >> I think your objection is wrong: erase(start++) is perfectly safe >> because the incrementing op >> is executed before erase is invoked. >> > > Actually, to be concise, you're invoking undefined behavior. The Standard > doesn't guarantee any execution order of operations in this context. The > only thing which is guaranteed is, that the operation executed by erase() > uses the initial value and afterwards start has been incremented (well, > whatever happens if you increment an iterator after erasing the element it's > pointing to). > I still disagree; start++ produces a side effect (std 1.9.7, emphasis mine): "Accessing an object designated by a volatile lvalue (3.10), *modifying an object* [...] are all side effects, which are changes in the state of the execution environment.[...] At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place." and as such, it must have taken place by the time the function erase is invoked (std 1.9.17): "When calling a function (whether or not the function is inline), there is a sequence point after the evaluation of all function arguments (if any) which takes place before execution of any expressions or statements in the function body .[...]" Am i missing something? Joaqu?n M L?pez Mu?oz Telef?nica, Investigaci?n y Desarrollo ------------------------------ Message: 11 Date: Tue, 21 Oct 2008 15:19:53 +0000 (UTC) From: Gennadiy Rozental <rogeeff(a)gmail.com> Subject: Re: [boost] Selective Unit Testing To: boost(a)lists.boost.org Message-ID: <loom.20081021T151743-746(a)post.gmane.org> Content-Type: text/plain; charset=utf-8 dominic ibeme <detroydom <at> yahoo.com> writes: > > Hi .. > > I've been using the boost unit testing framework and its quite a wonderful library... > thanks to Gennadiy, however the section on advanced usage wasn't made available > in release 1.36. i would really like to know how to perform selective testing i.e executing? > test with dependencies, i guess this would show up in the future, but i kind of need help > on this one. To specify dependencies test_unit has method "depends_on". Also you can run test by name. It should be covered in docs. Gennadiy ------------------------------ Message: 12 Date: Tue, 21 Oct 2008 17:37:03 +0200 From: Gennaro Prota <gennaro.prota(a)yahoo.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: boost(a)lists.boost.org Message-ID: <gdkstr$opo$1(a)ger.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hartmut Kaiser wrote: >> Anything I can do about this? >> What does this assertion mean? >> >> My setup: Linux 64Bit, gcc 4.2.4, serialization is used for polymorphic >> objects loaded from different shared libraries, shared libraries are >> loaded with dlopen(RTLD_GLOBAL|RTLD_LAZY). >> >> Assertion (extended_type_info.cpp:92) occurs during program termination >> (after main returned), during dlclose(). >> >> If anything else isn't possible, would it be appropriate to change the >> related code (before the release!) from: >> >> assert(start != end); >> >> // remove entry in map which corresponds to this type >> do{ >> if(this == *start) >> x.erase(start++); >> else >> ++start; >> }while(start != end); > > After looking at this code again I have the impression that it is broken > anyways. Yes, but IMHO not for the reason you mention. Certainly I wouldn't let the start++/++start "dance" pass a code review. PS: don't use tab characters in posts! :-) -- Genny ------------------------------ Message: 13 Date: Tue, 21 Oct 2008 17:54:35 +0200 From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> Subject: Re: [boost] [function] function.hpp lacks include guard To: boost(a)lists.boost.org Message-ID: <gdktvq$sjg$1(a)ger.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Okko Willeboordse wrote: > My co-worker Bob Praster found, using PC-Lint 9.0, that function.hpp > doesn't have an include guard That's most likely because it doesn't need one, since it's only including other headers. ------------------------------ Message: 14 Date: Tue, 21 Oct 2008 10:55:57 -0500 From: "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfb98.14025a0a.2e02.ffff84e4(a)mx.google.com> Content-Type: text/plain; charset="us-ascii" > Hartmut Kaiser wrote: > >> Anything I can do about this? > >> What does this assertion mean? > >> > >> My setup: Linux 64Bit, gcc 4.2.4, serialization is used for > polymorphic > >> objects loaded from different shared libraries, shared libraries are > >> loaded with dlopen(RTLD_GLOBAL|RTLD_LAZY). > >> > >> Assertion (extended_type_info.cpp:92) occurs during program > termination > >> (after main returned), during dlclose(). > >> > >> If anything else isn't possible, would it be appropriate to change > the > >> related code (before the release!) from: > >> > >> assert(start != end); > >> > >> // remove entry in map which corresponds to this type > >> do{ > >> if(this == *start) > >> x.erase(start++); > >> else > >> ++start; > >> }while(start != end); > > > > After looking at this code again I have the impression that it is > broken > > anyways. > > Yes, but IMHO not for the reason you mention. Certainly I > wouldn't let the start++/++start "dance" pass a code review. Agreed. > PS: don't use tab characters in posts! :-) It's a raw copy of the code, so there have to be tabs in the source files... Regards Hartmut ------------------------------ Message: 15 Date: Tue, 21 Oct 2008 10:57:10 -0500 From: "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfbe0.07045a0a.162b.ffffba69(a)mx.google.com> Content-Type: text/plain; charset="us-ascii" > Hartmut Kaiser: > > Actually, to be concise, you're invoking undefined behavior. The > Standard > > doesn't guarantee any execution order of operations in this context. > > It does, there is a sequence point before the call. Ok, there is always something new to learn out there. Thanks! Regards Hartmut PS: Anyway, that doesn't fix my assertion in the first place either :-P ------------------------------ Message: 16 Date: Tue, 21 Oct 2008 10:59:26 -0500 From: "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfc69.07045a0a.162b.ffffbb50(a)mx.google.com> Content-Type: text/plain; charset="us-ascii" > > Actually, to be concise, you're invoking undefined behavior. The > Standard > > doesn't guarantee any execution order of operations in this context. > The > > only thing which is guaranteed is, that the operation executed by > erase() > > uses the initial value and afterwards start has been incremented > (well, > > whatever happens if you increment an iterator after erasing the > element it's > > pointing to). > > > > I still disagree; start++ produces a side effect (std 1.9.7, emphasis > mine): > > "Accessing an object designated by a volatile lvalue (3.10), > *modifying an object* [...] > are all side effects, which are changes in the state of the execution > environment.[...] > At certain specified points in the execution sequence called sequence > points, all side > effects of previous evaluations shall be complete and no side effects > of subsequent > evaluations shall have taken place." > > and as such, it must have taken place by the time the function erase is > invoked (std 1.9.17): > > "When calling a function (whether or not the function is inline), > there is a sequence point > after the evaluation of all function arguments (if any) which takes > place before execution > of any expressions or statements in the function body .[...]" Ok, I'm wrong. But I remember at least one problem in the past I have had exactly because of this. But that just might have been a non-conforming compiler playing games on me. Thanks for the explanations. Regards Hartmut ------------------------------ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost End of Boost Digest, Vol 2343, Issue 3 **************************************

1 0

[MPL] wrapper for if_ selecting integral_c
by Jordans, R. 22 Oct '08

22 Oct '08

Hi, I would like to suggest an addition to Boost MPL. In the project I am working on I often need to select integral values, either using MPL or home-brew template logic. Where MPL is preferred due to consistency. This requires me to do something like: int value = if_<condition, int_<value1>, int_<value2> >::type::value; Which (when adding namespaces to the above) is too much typing in my opinion and reduces readability of my code. Would it be useful to add a new variant of if_ to Boost MPL that would enable the following? (by combining the syntax of if_ and integral_c) type value = if_integral_c<condition, type, value1, value2>::value Best regards, Roel Jordans

4 7