- Boost - lists.preview.boost.org

Re: [boost] [test] Automatic registration of tests created with BOOST_PARAM_TEST_CASE
by Jan Stolarek 10 May '09

10 May '09

> Boost.Test do not support this setup out of the box It seems to me that there's no unit testing framework for C++ that would support that (please correct me if I'm wrong). > Which particular part? For example this : "Sub test case names are deduced from the macro argument test_case_name. If you prefer to assign different test case names, you need to use the underlying make_test_case interface instead." More details on that would be nice. It would also be great to add more complex examples. Examples for each section are clear, however problems arise when one tries to combine concepts from many sections. > This is not a good idea. I found it in documentation for Boost 1.34 : http://www.boost.org/doc/libs/1_34_1/libs/test/doc/tests/parameterized_test… > Your best shot probably is to try ot do this in global fixture. Would this be a good solution if I had many tests with lots of data sets? > You can implement your own generator. Could you point me to example on how to do that? >Also you probably should register your test units directly under >framework::master_test_suite() As mentioned in my fisrt mail I have tried that but with no result. It seems that I got something wrong with what I can add to master test suite. Jan

2 1

Re: [boost] [test] Automatic registration of tests created with BOOST_PARAM_TEST_CASE
by Jan Stolarek 10 May '09

10 May '09

Ok, I figured out a solution that seems to be quite elegant, not so verbose and easy to achieve : using namespace boost::unit_test; class DataSet { public : DataSet( /* params */ ) { /* setup single data set */ } ~DataSet( ) { /* teardown single data set */ } /* some fields */ } void testMethod( DataSet* data ) { /* do something with method that's being tested. Use data somehow */ BOOST_CHECK( /* assertion */ ); } BOOST_AUTO_TEST_CASE( TestNameFirstDataSet ) { DataSet dataSet( /* params for first data set */ ); testMethod( dataSet ); } BOOST_AUTO_TEST_CASE( TestNameSecondDataSet ) { DataSet dataSet( /* params for second data set */ ); testMethod( dataSet ); } It's so simple that I wonder why didn't I figure it out right away. It doesn't require extra lines of code (dataSet has to be created somewhere anyway), it even allows to get rid of DataProvider class. Also there is no problem of spliting the tests into many files (I think this could be problematic if I had used global fixture, since all the data sets would have to be defined in one file). Any bad sides of this approach? Jan

1 0

[iostreams] regression - Missing include guard in boost/iostreams/device/mapped_file.hpp
by Bjørn Roald 10 May '09

10 May '09

Hi, Seems like the trunk@46692 commit, 25 june 2008, removed the include guard in boost/iostreams/device/mapped_file.hpp This breaks gcc43 compilation of sources directly including this header. Eg. http://www.mapnik.org/ trunk code. -- Bjørn

2 4

[Review Request] Boost.Convert
by Vladimir Batov 08 May '09

08 May '09

The proposed Boost.Convert has seen some lively discussions and considerable changes. Since then its interface and major implementation details have been unchanged and are being used/tested in an actual development of a system of a moderate size. Therefore, I would like to request a formal review and the component placed into the review queue. The zipped source and documentation are in the Vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… Thanks, Vladimir.

1 0

[utility][foreach][1.39.0] warning C4512
by Michael Mathews 08 May '09

08 May '09

HI folks, Just upgraded to 1.39.0 and everything works well except I started getting these warnings. >C:\Boost\include\boost-1_39\boost/utility/addressof.hpp(30) : warning C4512: 'boost::detail::addr_impl_ref<T>' : assignment operator could not be generated 1> with 1> [ 1> T=std::vector<double> 1> ] 1> C:\Boost\include\boost-1_39\boost/utility/addressof.hpp(56) : see reference to class template instantiation 'boost::detail::addr_impl_ref<T>' being compiled 1> with 1> [ 1> T=std::vector<double> 1> ] 1> C:\Boost\include\boost-1_39\boost/foreach.hpp(627) : see reference to function template instantiation 'T *boost::addressof<T>(T &)' being compiled 1> with 1> [ 1> T=std::vector<double> 1> ] 1> .\main.cpp(102) : see reference to function template instantiation 'boost::foreach_detail_::auto_any<T> boost::foreach_detail_::contain<std::vector<_Ty>>(std::vector<_Ty> &,boost::mpl::false_ *)' being compiled 1> with 1> [ 1> T=std::vector<double> *, 1> _Ty=double 1> ] msvc9 sp1 warning level 4. I didn't get these warnings in 1.38 enjoy michael

2 1

Does Boost has an utility to replace all OLD Keys with NEW one for MultiMap/Map?
by Tushar Chowdhury 08 May '09

08 May '09

Hi Guys, As of now I failed to get such an algo. I've come up with an proposed solution. Please verify: namespace Boost{ template <typename CONTAINER> void replace_key(CONTAINER& container, const typename CONTAINER::key_type& oldKey, const typename CONTAINER::key_type& newKey) { typename CONTAINER::iterator begin(container.find(oldKey)); for(;;){ if(begin != container.end()){ container.insert(typename CONTAINER::value_type(newKey, begin->second)); container.erase(begin++); begin = container.find(oldKey); } else{ return; } } } } make sense?

6 11

[test] Automatic registration of tests created with BOOST_PARAM_TEST_CASE
by JS 08 May '09

08 May '09

Hi, I want to create a test that a) runs the same testing function with different sets of input data AND b) registers automatically Obviously I can use BOOST_PARAM_TEST_CASE macro for a), but how do I achieve b) at the same time? I've been fighting with the problem for many hours and I have no idea how to do it. Unfortunately the documentation is very cryptic. Here's what I came up with so far: boost-main.cpp : #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MAIN #define BOOST_TEST_MODULE My Master Test Suite #include <boost/test/unit_test.hpp> testSomeFunctions.cpp : using namespace boost::unit_test; class DataSet { public : DataSet( /* params */ ) { /* setup single data set */ } ~DataSet( ) { /* teardown single data set */ } /* some fields */ } class DataProvider { public : DataProvider() { dataSet.push_back( new DataSet( /* params */ ) ); /* add more if necessary */ } ~DataProvider() { /* free memory*/ } std::vector<DataSet*> dataSet; } void testMethod( DataSet* data ) { /* do something with method that's being tested. Use data somehow */ BOOST_CHECK( /* assertion */ ); } BOOST_AUTO_TEST_CASE( TestName ) { DataProvider dataProvider; test_suite* test = BOOST_TEST_SUITE( "I don't think the name matters" ); test->add( BOOST_PARAM_TEST_CASE( &testMethod, dataProvider.dataSet.begin(), dataProvider.dataSet.end() ) ); framework::run( test ); } However this is not correct since test cases created with BOOST_PARAM_TEST_CASE are not registered in the master test suite. If one of the tests fails I get the following log : Running 1 test case... ../test/functions/testSomeFunctions.cpp(67): error in "testMethod": check data->a == data->b failed [2 != 3] *** No errors detected I tried replacing "framework::run( test );" with "framework::master_test_suite().add( test );" but that doesn't work at all (log says that no errors were detected, while there should be one test that fails). I also tried something like this : BOOST_AUTO_TEST_CASE( ActivationFunctionTest ) { DataProvider dataProvider; framework::master_test_suite().add( BOOST_PARAM_TEST_CASE( &testMethod, dataProvider.dataSet.begin(), dataProvider.dataSet.end() ) ); } but the result is the same (No errors detected). What should I do? Jan

2 1

[spirit2] conflict with asio header
by Michael Caisse 07 May '09

07 May '09

I'm not certain if this is an asio issue or spirit2 issue (or user error). I checked Spirit out from the trunk and placed it into a 1.37 boost tree. I'm running gcc 4.3.2. Creating file foo.cpp with the following: --------------- #include <boost/asio.hpp> #include <boost/spirit/include/qi.hpp> --------------- Produces a string of errors including this snippet: from ../src/foo.cpp:3: ../../../library/vendor/boost/boost/proto/make_expr.hpp: At global scope: ../../../library/vendor/boost/boost/proto/make_expr.hpp:935: error: expected nested-name-specifier before numeric constant ../../../library/vendor/boost/boost/proto/make_expr.hpp:935: error: expected â>â before numeric constant ../../../library/vendor/boost/boost/proto/make_expr.hpp:940: error: type/value mismatch at argument 3 in template parameter list for âtemplate<class Tag, class DomainOrA0, class A0, class A1, class A2, class A3, class A4, class Void> struct boost::proto::result_of::make_exprâ ../../../library/vendor/boost/boost/proto/make_expr.hpp:940: error: expected a type, got â0â ../../../library/vendor/boost/boost/proto/make_expr.hpp:940: error: expected initializer before âconstâ Swapping the include order resolves the error. Should I enter a ticket? Michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

3 2

Submitting a patch to the bug/ticket list
by Juan Antonio Zaratiegui Vallecillo, a.k.a. Zara 07 May '09

07 May '09

Well, I have submitted a patch for dynamic_bitset.hpp, and I have seen that the ticket is now 'closed' and 'fixed'. I don know if it is an automatic response from the system, or if I have done something wrong (like, for instance, clicking where I should not click), and in such case I should reopen the ticket. Please, tell me which is the case and what should I do, because I am not happy leaving it this way. BTW, the bug owner is listed as gennaro_prota. Should I try to contact him directly? TIA Zara

2 3

gcc-4.4.0 and boost::optional is giving (spurious?) strict-aliasing warnings
by Brad Spencer 07 May '09

07 May '09

Before I get to the details, let me start by saying that I suspect that these warnings are probably spurious. But, before I go and start asking the compiler folks if they are bugs, I'd like to check here first. If you take unmodified boost-1.38.0 and try to use boost::optional with gcc-4.4.0 -Wall -O3, you seem to get warnings about strict-aliasing rules being broken. If boost::optional (and boost::function) are really broken, then we're probably in trouble :) test.cc: #include <boost/optional.hpp> boost::optional<int> x; int func() { return *x; } On x86_64-unknown-linux-gnu: $ /opt/gcc-4.4.0/bin/g++ -Wall -O3 -I. -c -o test.o test.cc test.cc: In function ‘int func()’: test.cc:5: warning: dereferencing pointer ‘<anonymous>’ does break strict-aliasing rules ./boost/optional/optional.hpp:594: note: initialized from here I have seen some similar issues with boost::bind and boost::function, but I haven't isolated them down to something this simple yet. I figured I'd start by asking about this. So, is it safe to presume that boost::optional is not really breaking the strict aliasing rules? (It's not immediately obvious.) If so, then I can ask the gcc folks about this. Thanks! -- ---------------------------------------------------------- Brad Spencer - spencer(a)starscale.com - www.starscale.com

4 3

[thread] on_tls_prepare in win32\tss_pe.cpp incompatible with static linkage to a /clr object
by Matthew Chambers 06 May '09

06 May '09

I'm very interested in being able to have a native C++ executable which makes use of boost's TSS and also be able to wrap .NET modules with C++/CLI (i.e. /clr). And I much prefer it to be statically linked. The C++/CLI wrappers work fine when they are dynamically linked, but they cause a runtime initialization error (0xc000007b) whenever they are connected in only static links. It doesn't matter whether the host executable is compiled with /clr or not - somehow the MSVC linker knows to add some CLR initialization voodoo to the PE header whenever a static link to a /clr-enabled object is made. And that PE header voodoo seems to be incompatible with some of boost::thread's own brand of PE header voodoo which appears to be intended to provide TLS support for Windows. But as far as I can tell, I was able to get TLS working with MSVC9 even after commenting out the on_tls_prepare lines in tss_pe.cpp - commenting out the other lines wasn't necessary: > #if (_MSC_VER >= 1400) > //#pragma section(".CRT$XIU",long,read) > #pragma section(".CRT$XCU",long,read) > #pragma section(".CRT$XTU",long,read) > #pragma section(".CRT$XLC",long,read) > static __declspec(allocate(".CRT$XLC")) _TLSCB > __xl_ca=on_tls_callback; > // static __declspec(allocate(".CRT$XIU"))_PVFV p_tls_prepare = > on_tls_prepare; > static __declspec(allocate(".CRT$XCU"))_PVFV p_process_init = > on_process_init; > static __declspec(allocate(".CRT$XTU"))_PVFV p_process_term = > on_process_term; > #else I put together a test case that I'm pretty sure shows that TLS still works without that function. At the very least, can there be some preprocessor define to manually disable it for CLR compatibility? Or perhaps there is a way to adjust this voodoo to be compatible with the CLR initialization? I'm hosting the test case at: http://fenchurch.mc.vanderbilt.edu/files/TLS_CLR_Test.7z It includes a main function which runs a test of the TSS semantics, and a CLR class which tests console output via C++/CLI. I included binaries and the boost_thread.lib files for both the broken and "fixed" versions of tss_pe.cpp. Thanks, Matt Chambers

2 2

[smart_ptr] boost::auto_ptr?
by Preston A. Elder 06 May '09

06 May '09

I was wondering if the maintainer of the smart pointers could create an analogue to auto_ptr in the boost namespace. Specificlly to allow the addition of a deallocator like that which exists in shared_ptr? Right now, none of std::auto_ptr, shared_ptr or scoped_ptr will quite fit this niche. - std::auto_ptr - always uses delete ptr; There not only no standard way to supply an allocator, but also no way to specify a one-off deleter. - scoped_ptr - is noncopyable (by design), I want to use it like an auto_ptr. - shared_ptr - has more overhead for thread safety and multiple usage concerns than is desired in this circumstance. Not to mention that it doesn't function like auto_ptr ('nullifying' after operator=). Quite simply, I'd love to do: boost::auto_ptr<MyClass> obj(ptr, deleter); Just like I can with boost::shared_ptr, and use it like regular std::auto_ptr. Can someone add this to boost? Pretty please? :) Incidentlly, I have another question, about enable_shared_from_this. Will this play well with a regular shared_ptr? For example - say I have MyClass and MyOtherClass. MyClass is going to invoke a function on MyOtherClass that will cause MyOtherClass to store the shared_ptr. For example: class MyClass { public: void foo(MyOtherClass &moc) const { moc.foo(shared_from_this()); } }; class MyOtherClass { shared_ptr<MyClass> mc; public: void foo(const boost::shared_ptr<MyClass> &in) { mc = in; } }; If I did: shared_ptr<MyClass> mc(new MyClass); MyOtherClass moc; mc->foo(moc); Ignoring the abserdity of the example (obviously real-life situations would be much more complex), would the mc and moc.mc shared ptr's be in sync? would they play nice together? or would there be chaos and destruction? What if I instead did: MyClass *tmp = new MyClass; shared_ptr<MyClass> mc(tmp->shared_from_this()); Would that fix the above if the above is a problem? I am curious, because right now, I have several instances where I am making constructors private, adding a weak_ptr to a class and adding a static create() function that takes the constructor arguments. Then my create() function will construct the object, putting it in a shared_ptr, then initialize the weak_ptr from the newly created shared_ptr, and then return the shared_ptr - all of this is quite cumbersome. Thanks, PreZ :)

1 1

[aligned storage] support for empty storage
by Thorsten Ottosen 06 May '09

06 May '09

Hi all, Currently the following fails: typedef boost::aligned_storage< 0, 4u > storage; storage s; because this will try to create an empty array. Does anybody have anything against adding the following specialization: template< std::size_t alignment_ > struct aligned_storage_imp<0u,alignment_> { /* intentionally empty */ }; Also, I would like to derive from aligned_storage_imp to get the EBO: template < std::size_t size_ , std::size_t alignment_ = std::size_t(-1) > class aligned_storage : private detail::aligned_storage::aligned_storage_imp<size_, alignment_> { ... } The above changes enable the following program typedef boost::aligned_storage< 0, 4u > storage; struct simple : storage { int i; }; #include <iostream> int main() { std::cout << sizeof(storage) << " " << sizeof(simple); } to output "1 4" instead of "1 8" on gcc. In case your are wondering, then I need this functionality in boost::auto_buffer to get rid of the extra word when the stack-buffer is empty (thus making auto_buffer as small as vector). Comments? -Thorsten

2 4

BOOST_ASSERT_IF() [again]
by Thorsten Ottosen 06 May '09

06 May '09

Hi Everyone, Does anyone oppose that I add this macro to supplement BOOST_ASSERT()? It's defined simply as #define BOOST_ASSERT_IF(IF,X) BOOST_ASSERT( (!(IF)) || (X) ) I think it renders assertions somewhat easier to read. -Thorsten

3 3

inline specifier within in class definition
by Mateusz Loskot 05 May '09

05 May '09

Hi, Could anyone explain why some static member functions defined within class definitions are specified with inline keyword? For instance, in boos/serialization/export.hpp template <class Archive, class Serializable> struct export_impl { ... inline static void enable_load(mpl::false_) {} inline static void enable_save(mpl::false_) {} }; AFAIU what the C++ Standard says in chapter "9.3 Member functions", it should be enough to define a member function in its class definition, "in which case it is an inline member function". On the other side, the standard also uses this technique, for instance in example presented in "18.2.1.5 numeric_limits specializations". I'm having problem with catching what's the rationale of using extra inline specifier. I was trying to find answer in the guidelines, but it seems it isn't explained. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

6 10

Reviewer needed for a C++ committee paper candidate
by joaquin＠tid.es 05 May '09

05 May '09

Hello, My excuses is this is slightly OT, but I think it touches with issues definitely of the interest of the Boost community. I'd like to send a paper to the C++ committe, a revision of the already sent http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2009/n2820.pdf and would appreciate if some volunteer with interest in and knowledge on the subject matter can review it. If you're such a volunteer please contact me privately and I'll send you the doc. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Boost.Python def and member function overloads
by Matt Calabrese 05 May '09

05 May '09

I attended Troy Straszheim's Icefishing for Neutrinos Boostcon session today, which was a great talk on Boost.Serialization and Boost.Python in a very interesting context. I have not worked with Boost.Python in practice, having only skimmed the documentation, but was amazed at just how powerful and easy to use it is. However, in his examples, he included exposing classes from C++ that have member functions with multiple overloads and noted that it is somewhat cumbersome due to the fact that you have to explicitly cast your member function pointers when calling .def. For a type "your_type" with a member function "foo" having two overloads, one that takes an int, and another that takes an int and a float, the current syntax comes down to something along the lines of: /*class_ specification here */ .def( "foo", static_cast< void (your_type::*)(int) >(&your_type::foo)) .def( "foo", static_cast< void (your_type::*)(int, float) >(&your_type::foo)) ; Disambiguation is obviously necessary here, but I wonder if it could be handled in a much simpler way such as to avoid explicitly casting or even the explicit use of member function pointer types at all. I propose doing this by allowing users to explicitly pass in a non-member function type as a template argument to def, using a metafunction to translate that type to the appropriate member function type, and having that calculated type be the 2nd parameter type of the function. The suggested syntax would be something along the lines of: /*class_ specification here */ .def< void(int) >( "foo", &your_type::foo ) .def< void(int,float) >( "foo", &your_type::foo ) ; which I feel would be a significant simplification of use and should not be difficult at all to implement (just detect if the first template argument to def is a function type and if so do the appropriate transformation to yield the 2nd function parameter type, otherwise have it work like existing definitions). Would this be a feature that people find useful and be worth pursuing? -- -Matt Calabrese

2 1

[thread] boost::shared_mutex vs. pthread_rwlock_unlock
by Rush Manbert 05 May '09

05 May '09

I am replacing a pthread threading implementation with a boost threads implementation so I can use the code on Windows. There is a ReadWriteMutex class that has the following declaration: class ReadWriteMutex { public: ReadWriteMutex(); virtual ~ReadWriteMutex() {} // these get the lock and block until it is done successfully virtual void acquireRead() const; virtual void acquireWrite() const; // these attempt to get the lock, returning false immediately if they fail virtual bool attemptRead() const; virtual bool attemptWrite() const; // this releases both read and write locks virtual void release() const; private: class impl; boost::shared_ptr<impl> impl_; }; Note the release() method that works for a thread that holds either the read or write lock. My implementation uses boost::shared_mutex. acquireRead calls lock_shared(), acquireWrite calls lock(), attemptRead calls try_lock_shared(), attemptWrite calls try_lock, and release calls ??????? AFAICT there is no equivalent to the pthread_rwlock_unlock() call that the original version of release() called. Am I missing something? Thanks, Rush

2 1

[1.39.0] Confusing directions in bootstrap.sh
by Jeffrey Bosboom 05 May '09

05 May '09

I used the --libdir= and --includedir= options when invoking bootstrap.sh. When bootstrap.sh finishes, it says to run './bjam', but when I did so, it didn't use the libdir and includedir I specified. Only when I ran './bjam install' did it do what I expected. I think bootstrap.sh should be changed to indicate that the 'install' argument is necessary. --Jeffrey Bosboom

2 2

[PATCH] Typo in bootstrap.sh
by Matthew L. Creech 05 May '09

05 May '09

Boost fails to install when LIBDIR isn't specified explicitly and isn't "/lib", due to a typo in bootstrap.sh. Trivial patch below. --- diff -purN orig/bootstrap.sh boost_1_39_0/bootstrap.sh --- orig/bootstrap.sh 2009-05-04 16:09:39.000000000 -0400 +++ boost_1_39_0/bootstrap.sh 2009-05-04 16:10:25.000000000 -0400 @@ -249,7 +249,7 @@ if test "x$EPREFIX" = x; then fi if test "x$LIBDIR" = x; then - LIBDIR="$EXPREFIX/lib" + LIBDIR="$EPREFIX/lib" fi if test "x$INCLUDEDIR" = x; then -- Matthew L. Creech

2 1

[iterator] std::sort on zip_iterator
by Jeremiah Willcock 05 May '09

05 May '09

(Resubmitting to Boost list because I did not receive any answers on boost-users.) I would like to sort two separate vectors of numbers, treating corresponding elements of the two vectors as tuples and sorting the tuples. In particular, I am only comparing the first elements of the tuples; that may or may not be relevant to my problem. An example program is: #include <vector> #include <algorithm> #include <iostream> #include <boost/tuple/tuple.hpp> #include <boost/iterator/zip_iterator.hpp> struct compare_first_elements_in_tuples { template <typename Tuple> bool operator()(const Tuple& a, const Tuple& b) const { return (a.template get<0>()) < (b.template get<0>()); } }; int main(int, char**) { size_t a_data[5] = {0, 2, 1, 2, 4}; size_t b_data[5] = {1, 1, 5, 3, 7}; std::vector<size_t> a(a_data, a_data + 5); std::vector<size_t> b(b_data, b_data + 5); std::cout << "Before:"; for (size_t i = 0; i < a.size(); ++i) { std::cout << " (" << a[i] << ", " << b[i] << ")"; } std::cout << std::endl; typedef std::vector<size_t>::iterator vec_iter; typedef boost::zip_iterator<boost::tuple<vec_iter, vec_iter> > zip_iter; std::sort(zip_iter(boost::make_tuple(a.begin(), b.begin())), zip_iter(boost::make_tuple(a.end(), b.end())), compare_first_elements_in_tuples()); std::cout << "After:"; for (size_t i = 0; i < a.size(); ++i) { std::cout << " (" << a[i] << ", " << b[i] << ")"; } std::cout << std::endl; return 0; } On gcc 4.0.1, the sort operation results in the element (2, 1) (a pair of corresponding elements in a and b) being duplicated, while the element (1, 5) does not appear in the result at all: Before: (0, 1) (2, 1) (1, 5) (2, 3) (4, 7) After: (0, 1) (2, 1) (2, 1) (2, 3) (4, 7) I suspect the problem is related to the fact that zip_iterator does not return a "real" reference when dereferenced. Am I mistaken about this? Is the code above supposed to work? If not, is there an alternative way to sort one sequence while swapping elements in another in a corresponding way? I am not able to join the two input sequences into a single sequence of pairs because of other factors in the use case for this code. Thank you for your help. -- Jeremiah Willcock

2 1

[interprocess][circular_buffer] specialized containers should have container template argument
by Thorsten Ottosen 04 May '09

04 May '09

Hi Ion and Jan, I often use these containers: flat_set, flat_map and circular_buffer. They are great. However, we can make them faster if you allow a new template argument. For example template < class T, class Alloc, class Buffer = /* some default */ > class circular_buffer; template < typename T, typename Pred, typename Alloc class PushBackContainer = /* some default */ > class flat_set; My motivation is that these can perform somewhat better e.g. with an array (for circular_buffer), or auto_buffer (for flat_set/flat_map). I think even some very simply array wrapper would be useable with flat_set. The EA STL implementation has this features. What do you think? -Thorsten

4 5

Re: [boost] The noexcept Specifier & Block
by Anders Dalvander 04 May '09

04 May '09

Posted the following to std.lang.c++, cross-posting here, mostly directed to David Abrahams: After reading N2855 - Rvalue References and Exception Safety (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html) I'm still not confident that a new keyword `noexcept` would be optimal. Especially when the proposal combines this new keyword with a somewhat enhanced version of the already existing exception specification `throw(...)` to explicitly indicate that a move constructor or a destructor may throw exceptions. And at the same time propose to deprecate exception specifications altogether. I think that it would be better to use a simplified exception specification: - `throw()` to indicate that a function does not throw any exception, which is statically checked by the compiler. This would behave as `noexcept` in the N2855 proposal. - `throw(...)` to indicate that a function may throw any exception. Main use for throwing move constructors and throwing destructors. - Any other exception specification would be ill-formed and thus would require a compiler diagnostic. Update the new exception specification to behave as `noexcept` in N2855, where needed. Unfortunately I don't have a really good idea to implement something similar to the `noexcept` block as described in N2855. Perhaps a `try` block without a `catch` handler, perhaps someone else has a better idea? double sqrt(double); // may throw exceptions void f(double &x) throw() { if (x > 0) { x = sqrt(x); // ill-formed: sqrt(x) might throw an exception! } } void g(double &x) throw() { if (x > 0) { try { x = sqrt(x); } // okay: if sqrt(x) throws, invokes undefined behavior } } Rationale: - Exception specification as of C++98/C++03 are considered broken and discouraged. No need to deprecate, remove it entirely. - `throw()` is already used by a lot of libraries, for example boost, to indicate nothrow functions. With this proposal these functions would behave as `noexcept` with no change. - No new keywords are needed. Remove the following: exception-specification: throw ( [type-id-list]opt ) type-id-list: type-id type-id-list , type-id Add the following: no-throw-exception-specification: throw ( ) any-throw-exception-specification: throw ( ... ) What do you think? Regards, Anders Dalvander

1 0

[Review Results] Range.Ex library accepted into boost
by Thorsten Ottosen 04 May '09

04 May '09

Dear all, It is my pleasure that Neil Groves' RangeEx library has been accepted into boost. Congratulations Neil! There are quite a number of minor issues that need to be resolved before the library is release ready, see below for a summary. Review statistics ----------------- Full Reviews: 8. Discussion: extensive. I had the clear impression that everybody that participated in the discussion were in favor of this library, albeit they did not have time to submit a full review. I did not hear a single statement saying that this library should be rejected. Thanks to everybody that participated in the review and its discussions. Issue Summary ------------- Below is given a list of topics that must be adressed before the library can be included into boost. In general, we should try to discuss them one at a time in seperate threads. Many people suggested various extensions, new algorithms (e.g. from adope), etc. **In general we should not require Neil to add all these if he does not have the time currently: the basic infrastructure, the concepts, the naming and organization of the library is much more important. Then we can add all these things later.** 1: documentaion =============== The documentation should clearly reflect if an algorithm delegates to a standard algorithm. If the algorithm is new, then it should state complety and exception-safety. More examples would be welcome. Sometimes the rationale and explanations could be improved, e.g for operator|(). 2: return type specification for find() etc =========================================== There where no major objection to the mechanism, but some found the syntax ugly. I believe the suggested syntax (e.g.) boost::find[_f,_e]( range, x ) boost::find[_f+1,_e]( range, x ) was considered good by most. 3: namespace organization ========================= Currently the library uses the namspaces boost boost::adaptors Some raised concern about putting the algorithms straight in the boost namespace before we have a general agreement on where to put algorithms (e.g. in boost::algorithm or boost::ranges or whatever). I think it will make sense to put each algorithm in its own header, since we might have to include additional standard library headers for calling algorithms that are implemented as member functions (but see 7 below). Feedback is most welcome. 4: naming convention for adaptors ================================= The following have been proposed throughout the review (here examplified with "transform"): | transformed( fun ) | transform( fun ) | transform_view( fun ) | view::transform( fun ) There where no consensus during the review. Other libraries seem to use the _view suffix, which is a strong argument for that candidate (in that case, I suggest to drop the adaptors namespace). 5: naming convention for the adaptor generators =============================================== Many people like to be able to say make_transform_range(r,fun) instead of r | transformed( fun ). There was no concensus on how to name these functions. Here are some candidates: make_transform_range( r, fun ) transformed( r, fun ) transform( r, fun ) (*) transform_view( r, fun ) (*) was dislike by some because it has exactly the same spelling as the algorithm transform. Many felt that the confusion is too big if view generators are not named different from the actual algorithms. 6: reintroducing _if variants of algorithms =========================================== An important problem with the suggested approach was the the iterator returned by an algorithm after applying | filtered( pref ) are now filtered iterators and so one needs to manually unwrap the return iterator. This provided enough justification for reintroducing these algorithms. (One could imagine that this unwrapping was done automatically by a conversion operator such that iterator i = boost::find( r | boost::filtered( pred ), x ); "just worked". However, the syntax is still slightly worse than just using the original algorithm). Generic programming is concerned with the use of orthogonal concepts which put together yields all possible combinations of algorithms. If we reintroduce all _if algorithms, we have to aks ourselves "when does it end?". Should all new algorithms then simply add _if variants? This seems very much against the spirit of generic programming. The problem with the iterators being changed (as in the find example) seems to suggest the following guideline: "If the algorithm returns an iterator, it makes sense to provide an _if overload. Otherwise it does not." Under this guideline, find_if() should be there, but count_if() should not be provided. 7: should algorithms call member function when possible? ======================================================== I heard one strong voice against this. The reason was that the algorithm implemented as member function often has quite different guarantees w.r.t. complexity, reference and iterator stabililty. I think this is a very strong argument. Also, we can add this later if good arguments appear, but it is much harder to take away. We also have to remember Scott Meyers item "Beware of container independent code" which also suggest that this is a bad idea. At the very menimum, the original algorithm and the member function should have similar semantics. This seems to suggest that we can call set::lower_bound() from boost::lower_bound(). In that case, the best way would probably be to add these as overloads in the boost namespace: template< class T, class A > typename std::set<T,A>::iterator lower_bound( std::set<T,A>& s ); template< class T, class A > typename std::set<T,A>::const_iterator lower_bound( const std::set<T,A>& s ); 8: making return values of algorithms consistent/intuitive ========================================================== For example, sort(r) returns the sorted range, but sort_heap(r) does not. Similar issues for partial_sort(). Please go through all algorithms to see if this done correctly. 9: output range concept? ========================= It appears that the only use for an output iterator in the library was for boost::copy(rng,iter), and the only use for that function was for "sinks" like std::ostream_iterator<T>(...). This seems to be the only safety hole left in the library. Here's an idea to how we might remove that: create a new "copy sink" concept: struct array_copy_sink { ... template< class Iterator > copy( Iterator begin, Iterator end ) { ... } }; Then we might imagine boost::copy( rng, boost::ostream_sink(std::cout) ); boost::copy( rng, boost::array_sink(an_array) ); boost::copy( rng, boost::ptr_sink(begin,end) ); boost::copy( rng, boost::front_insert_sink(a_deque) ); ... For optimal performance, we also need a "nonoverlapping copy sink" concept, and an algorithm that expects that sink (or that boost::copy() determines the type of the sink automatically). 10: automatic projection ======================= Adope has algorithms overloaded such that projection is very easy: struct my_type { int member; double another_member; }; //... my_type a[] = { { 1, 2.5 }, ... }; // sort the array by the first member: sort(a, less(), &my_type::member); my_type* i = lower_bound(a, 5, less(), &my_type::member); We should be able to express this well, albeit not as concise, with my_type* i = boost::lower_bound( a | project( &my_type::member ), 5, less() ); where project( ... ) could simply return a transform iterator constructed with boost::bind(). There is another problem, however, because now the return value is a tranform_iterator of some form. Appending .base() would solve it, albeit it is somewhat ugly. Again this might raise the question of an implicit conversion. I just want to say this is not a critical issue as we can always add these overloads. --- End of Issues ---- Again, I would like to thank everybody that participated in the review. best regards Thorsten, review manager

2 1

[signals2] documentation on signals vs signals2
by Ross Levine 04 May '09

04 May '09

Is there documentation on when signals2 should be used over signals? If there is any time that signals is a better choice than signals2? I presume either signals2 is incompatible with code written for signals, or signals2 is inferior to signals in some cases, but this is not documented anywhere.

2 1