- Boost - lists.boost.org

Re: [boost] Bugs in regression/library_status.cpp on Windows
by Robert Kawulak 22 Sep '11

22 Sep '11

Hi, Since there was no response to my emails with patches for two months now and the code is still broken as it was, should the tool be considered abandoned? If so, would it be acceptable if I apply the patches by myself? Best regards, Robert > -----Original Message----- > From: Robert Kawulak [mailto:Robert.Kawulak@gmail.com] > Sent: Monday, July 25, 2011 12:18 AM > To: 'boost(a)lists.boost.org' > Subject: RE: Bugs in regression/library_status.cpp on Windows > > Hi, > > Could anybody please apply that patch or suggest what can I do (or whom > to contact directly) to get this fixed? BTW, I wonder how it's possible > that most of the bugs were introduced in one commit half a year ago and > nobody even noticed - it would suffice to run this app on any platform > to get obvious errors while on Windows it wouldn't even compile. Am I > really the only person using this tool? :P > > I've also found another minor problems: > - when building it, "$(BOOST_ROOT)\tools\regression\build\bin" > directory is created but it's not marked with "ignore" in SVN; > - char_xlate functor only translates '/' character in URLs while on > Windows the character used is '\' (and it also causes problems in some > browsers). The solution is very simple - add "|| c = '\\'" in line 75. > > I'm attaching a patch file combining the previous fixes and the '\' > translation. > > Best regards, > Robert > > > > > -----Original Message----- > > From: Robert Kawulak [mailto:Robert.Kawulak@gmail.com] > > Sent: Saturday, July 09, 2011 11:35 PM > > To: 'boost(a)lists.boost.org' > > Cc: 'bdawes(a)acm.org'; 'blelbach(a)cct.lsu.edu' > > Subject: Bugs in regression/library_status.cpp on Windows > > > > Hello, > > > > I've stumbled upon several bugs in > > tools/regression/src/library_status.cpp when compiling on Windows > with > > gcc 4.5 and msvc 10.0. I'm attaching a patch file with all necessary > > fixes. The bugs are: > > > > - using path::native() instead of path::string() - the former is > > wstring on Windows, > > - calling path::string() twice to obtain begin() and end() iterators > - > > on Windows path::string() returns a temporary, so the iterators point > > to different objects, > > - using whole path for each node in build_node_tree() instead of only > > the directory name, > > - using whole path instead of only the test name in do_table_body(), > > - the link to links file is relative to test directory, not to the > > results output directory, > > - generation of closing "</a>" without opening "<a>". > > > > Best regards, > > Robert

1 0

More tests running with Boost.Test than registered
by Jon Black 22 Sep '11

22 Sep '11

I have a large solution in Visual Studio (100+) projects, of which most are dll's. The test code is in the DLL's and the tests are run using the provided console_test_runner. At the moment, each DLL has a single passing test. However, when I run the console_test_runner on a single dll, the output indicates that there are more tests. For example: D:\Projects\MyProject\console_test_runner.exe --test MyDll1.dll Running 5 test cases... *** No errors detected So I put a print statement in the test in each DLL and ran it again, and here's what happened: D:\Projects\MyProject\console_test_runner.exe --test MyDll1.dll Running 5 test cases... TestMyDll5 TestMyDll4 TestMyDll3 TestMyDll2 TestMyDll1 *** No errors detected The project for MyDll1 depends on the other projects. That can't be a coincidence! I'm confused though, why is the console_test_runner executing tests in other DLL's when I've only specified MyDll1 on the command line? Each DLL has its own unit_test_init() function declared in the pre-compiled header, so I'm really lost on what is happening here. Is it possible that the other dll tests are getting registered as well?

2 1

preprocessor programming challenge
by Eric Niebler 22 Sep '11

22 Sep '11

I have a PP interface such as the following: #define MACRO(x) \ typedef x type; \ typedef x::nested nested; struct D { struct nested {}; }; It is intended to be used as follows: struct foo { MACRO(D) }; Now the problem comes when x is a dependent type, because "typedef x::nested" needs a "typename" in there. I would like to additionally support the following syntax (or something like it): template<class DD> struct bar { MACRO(typename DD) }; The above doesn't work as is because "typedef typename DD type;" is ill-formed (although msvc eats it). Constraints are i/ the interface must be backwards compatible to avoid breaking existing clients, ii/ it should be done with PP only. No templates should be instantiated here, and iii/ it should be standard C++03. No PP variadics. Is this possible? I think not, but my PP-foo is weak. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

Name and Namespace for Potential Boost Extended Floating-Point
by Christopher Kormanyos 22 Sep '11

22 Sep '11

Hello, We are seeking a good name for a potential boost extended precision floating-point library. This is a multiple precision floating-point type which *behaves* well in C++. The original thread announcing this potential library is here: http://lists.boost.org/Archives/boost/2011/06/182334.php Some very helpful boosters are assisting me with the preparation of this potential library. We've still got a lot to do, but are making good progress. In order to continue, we need a good name for a potential boost multiple-precision floating-point type. For the multiple-precision real type we have names like: * multiprecision_real * mp_real * extended_float_tOur current favorite is the second:mp_real. For namespaces, we have: 1. boost::mp::mp_real 2. boost::multiprecision::mp_real 3. boost::multiple_precision::mp_realOur current favorite namespace is number 2: boost::multiprecision. This new data type behaves like a drop-in replacement for a POD. It also has a collection of transcendental functions and a complex data type. So we are proposing: namespace boost { namespace multiprecision { class mp_real { ... }; // The real data type. class mp_complex { ... }; // The complex data type. mp_real sin(const mp_real&); // The sin function for the real data type. class mp_uint { }; // A potential future multiple-precision unsigned integer type. class mp_int { }; // A potential future multiple-precision signed integer type. } } We would appreciate comments (negative or positive) and/or alternative suggestions for names. Thank you. Sincerely, Chris.

15 56

[type_traits] has_member_function_callable_with
by Ion Gaztañaga 21 Sep '11

21 Sep '11

Hi to all, Trying to port C++11 code (allocator_traits) to C++03 (without decltype support), I needed to check at compile time if a member function can be called with some given parameters. Typical solutions I found on the net were based on specific signatures, say: const bool value = HAS_MEMBER_FUNCTION_FUNCNAME_WITH_SIGNATURE(MyClass, (int, char*)); However, it is not feasible to know the exact signature as I want to deal with conversions, const references, etc. Luckily, I found a very interesting explanation in Proto documentation: http://www.boost.org/doc/libs/1_47_0/doc/html/proto/appendices.html#boost_p… Based on this, I've tried to write my solution and I'd like to share it here with type traits experts, in case someone knows a better solution (see attached example). I know I don't take into account many issues for a truly generic utility (const member functions, etc.) but please let me know if you find this example interesting. Best, Ion

4 6

[BGL] container_gen
by Cromwell Enage 21 Sep '11

21 Sep '11

Hi, all. After a bit of a programming hiatus, I've managed to follow up on our container_gen discussion we had last May, archived here: <http://article.gmane.org/gmane.comp.lib.boost.devel/219238> I've created a branch in the sandbox called utility-container_gen that places the metafunction in Boost.Utility, changes detail::is_random_access to is_random_access_selector, provides an is_unique_associative_selector metafunction, and changes adjacency_list and parallel_edge_traits to use said utilities. Plus, there's Quickbook documentation. I've tested a few example programs in the BGL to make sure they still work, but I feel that's far from being thorough. No selectors for Boost.Intrusive have been implemented, yet. Feedback welcome! Cromwell D. Enage

2 2

Re: [boost] [contract] syntax redesign
by Andrzej Krzemienski 21 Sep '11

21 Sep '11

> Comments are always welcome :) Hi Lorenzo, The number of examples is impressive. It is a pleasure to observe your library growing at this pace. I would like to suggest two things. I could not see from the examples, if the library is capable of supporting "function try blocks" in constructor and destructor definitions. This is what I mean. http://msdn.microsoft.com/en-us/library/e9etx778%28v=vs.71%29.aspx http://www.gotw.ca/gotw/066.htm Second, I have seen #ifndef pragmas in some of the examples, e.g., in the body of function myadvance_dispatch you have: { #ifndef CONTRACT_CONFIG_NO_LOOP_VARIANTS Distance n_max = n; #endif CONTRACT_LOOP( while(n++) ) { CONTRACT_LOOP_VARIANT( const( n_max, n ) n_max - n ) --i; } } I am not sure if the necessity to use this conditional code would occur often, but if so, perhaps the code would be slightly more clear if instead the conditional code would be wrapped in an additional macro, like MFC did with DEBUG_ONLY macro: { CONTRACT_CONFIG_LOOP_VARIANT_ONLY( Distance n_max = n ); CONTRACT_LOOP( while(n++) ) { CONTRACT_LOOP_VARIANT( const( n_max, n ) n_max - n ) --i; } } That is, macro CONTRACT_CONFIG_LOOP_VARIANT_ONLY is defined as: #ifndef CONTRACT_CONFIG_NO_LOOP_VARIANTS #define CONTRACT_CONFIG_LOOP_VARIANT_ONLY(ARG) ARG #else #define CONTRACT_CONFIG_LOOP_VARIANT_ONLY(ARG) #endif Although I am not sure if a similar trick would be possible with the definition like: CONTRACT_FUNCTION( template( typename T ) requires( Addable<T> #ifndef CONTRACT_CONFIG_NO_POSTCONDITIONS // Equality only for postconditions. , boost::EqualityComparable<T> #endif ) (T) (add) ( (T) x, (T) y ) postcondition( auto result = return, result == x + y ) ) { return x + y; } Regards, &rzej

3 2

[exception] get_error_info with dynamic libraries
by Pavel Lebedev 19 Sep '11

19 Sep '11

Hi, I believe there is a problem with boost::get_error_info when used to retrieve error info objects added to exceptions in a module (exe/dll) different from the one making the call to this function under MSVC++ 2010 SP1. The problem appears to be introduced in SVN revision 68792 with a fix for ticket #5178 that changed struct boost::exception_detail::type_info_ from storing a reference to type info to a pointer in member type_. There's an assertion in function boost::exception_detail::error_info_impl_container::get that checks these members for equality which now does pointer comparison instead of calling std::type_info::operator== (for the case of enabled RTTI). This fails when used on error info added in the different module from the one trying to access it because each module gets its own copy of std::type_info object for the same type with different addresses, even though std::type_info::operator= does string comparison of class names and would have returned true, as it did before this change. Other compilers/platforms that don't provide process-unique type info objects are most likely affected too. The following patch appears to fix this problem for me by reverting to compiler-provided way of comparing type info objects. Index: info.hpp =================================================================== --- info.hpp (revision 74465) +++ info.hpp (working copy) @@ -97,7 +97,7 @@ { shared_ptr<error_info_base> const & p = i->second; #ifndef BOOST_NO_RTTI - BOOST_ASSERT( BOOST_EXCEPTION_DYNAMIC_TYPEID(*p).type_==ti.type_ ); + BOOST_ASSERT( *BOOST_EXCEPTION_DYNAMIC_TYPEID(*p).type_==*ti.type_ ); #endif return p; } Is this fix correct? Thanks in advance. Pavel Lebedev

2 2

[utility] rvalue support in value_initialized
by "Claas H. Köhler" 19 Sep '11

19 Sep '11

Hi everybody! Recently I encountered a problem using the std:::unique_ptr within boost::spirit. The reason is apparently that value_initialized does not support rvalue assignment. Are there any plans to implement move semantics into value_initialized? Mainly I would be interested in making something like this work: std::unique_ptr<T> a= boost::get( boost::value_initialized< std::unique_ptr<T> >() ); Currently this fails due to the fact, that unique_ptr can be moved but not copied. Regards Claas

8 9

[move] [optional] Move constructors support
by Antony Polukhin 19 Sep '11

19 Sep '11

There is a feature request https://svn.boost.org/trac/boost/ticket/1841 with some patch. I'm just curious, when will be it applied? Shall this patch be applied, or some integration with Boost.Move must be done instead? Best regards, Antony Polukhin

1 0