- Boost - lists.boost.org

Re: [boost] How do you make MPL-compatible template meta-functions?
by joaquin＠tid.es 09 Jul '08

09 Jul '08

Daryle Walker escribió: > On Jul 9, 2008, at 3:02 AM, joaquin(a)tid.es wrote: > [...] >> You can use boost::mpl::equal to test this: >> >> BOOST_STATIC_ASSERT >> ( (boost::mpl::equal<distinct_integral_bit_counts, >> boost::mpl::list_c<int, 8, 16, 32> >::value) ); >> } >> >> Other than that, your type_to_digit_count is perfectly lambda- >> cabable AFAICS. HTH, >> > > Thanks. I switched to mpl::equal and it compiled. I later switched > to BOOST_MPL_ASSERT. (Remember to take _out_ the "::value" part!) I > originally had the "integral_c" part of "type_to_digit_count" as a > member called "type," instead of as a base class, then I switched > back and forth. Both ways work. Why is that? Because integral_c (and all other integral constant types in Boost.MPL) evaluates to itself, that is, it has the form: template<typename T, T N>struct integral_c { typedef integral_c<T,N> type; ... }; > And which way is best > (if they're not equally good, and without a better third alternative)? > I don't think it makes any difference in compile times or otherwise, but deriving from integral_c is terser and more MPL-idiomatic. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

How do you make MPL-compatible template meta-functions?
by Daryle Walker 09 Jul '08

09 Jul '08

Here's what I'm trying (to redo integer_test.cpp): //============================== #include <boost/config.hpp> #include <boost/limits.hpp> #include <boost/integral_c.hpp> #include <boost/mpl/list.hpp> #include <boost/mpl/transform.hpp> #include <boost/static_assert.hpp> #include <boost/type_traits.hpp> #include <climits> namespace { // List all the conventional integral types, without the ones that are like // a strong-typedef of a lower type typedef boost::mpl::list<unsigned char #if USHRT_MAX > UCHAR_MAX , unsigned short #endif #if UINT_MAX > USHRT_MAX , unsigned int #endif #if ULONG_MAX > UINT_MAX , unsigned long #endif #if defined(BOOST_HAS_LONG_LONG) && ((ULLONG_MAX > ULONG_MAX) || (ULONGLONG_MAX > ULONG_MAX)) , boost::ulong_long_type #elif defined(BOOST_HAS_MS_INT64) && (0xFFFFFFFFFFFFFFFFui64 > ULONG_MAX) , unsigned __int64 #endif > distinct_unsigned_types; typedef boost::mpl::transform<distinct_unsigned_types, boost::make_signed<boost::mpl::_1> >::type distinct_signed_types; // New type list: integral type -> (wrapped) number of bits template < typename T > struct type_to_digit_count : boost::mpl::integral_c<int, std::numeric_limits<T>::digits> { }; typedef boost::mpl::transform<distinct_unsigned_types, type_to_digit_count<boost::mpl::_1> >::type distinct_integral_bit_counts; BOOST_STATIC_ASSERT ( (boost::is_same<distinct_integral_bit_counts, boost::mpl::list_c<int, 8, 16, 32, 64> >) ); } //============================== I originally did not have that last line there with the "BOOST_STATIC_ASSERT," but I put it in after some errors when doing a compiler-sanity check while coding. I cleaned up the other errors, but the compiler complains that the first argument of "is_same," i.e. "distinct_integral_bit_counts," is an invalid template argument. I don't think my definition of "type_to_digit_count" is lambda-safe, like "make_signed" is. How do I get it that way? (Or is the problem in the definition of "distinct_integral_bit_counts"?) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[test][gcc] return value support broken with "-pedantic"
by Juergen Hunold 09 Jul '08

09 Jul '08

Hi ! The latest changes to Boost.Test broke compilation with gcc in "pedantic" mode. This seems to be: http://svn.boost.org/trac/boost/changeset/47153 Just add "<toolset>gcc:<cxxflags>-pedantic" to libs/test/test/Jamfile.v2 and recompile. This will bail out with: gcc.compile.c++ /build/bjam/boost_1.36.0/libs/test/test/output_test_stream_test.test/gcc-4.2/debug/output_test_stream_test.o output_test_stream_test.cpp: In member function 'void test_constructor::test_method()': output_test_stream_test.cpp:30: error: ISO C++ forbids braced-groups within expressions I've disabled "return value support" locally (by commenting out test_tools.hpp line 86) but would like to have a conformant solution. Should we rise the warning level by _always_ activating "-pedantic" at least for the test suite ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

4 6

[test] Serious breakage - please fix or revert immediately
by Beman Dawes 09 Jul '08

09 Jul '08

Yesterday's changes to Boost.Tests appear to be breaking many libraries on gcc compiles. Please fix or revert immediately. --Beman Examples: ../boost/test/impl/test_main.ipp(40): error: destructible entities are not allowed inside of a statement expression BOOST_CHECK( test_main_result == 0 || test_main_result == boost::exit_success ); In file included from ../boost/test/minimal.hpp:37, from ../libs/crc/test/crc_test.cpp:23: ../boost/test/impl/execution_monitor.ipp:60:1: error: unterminated #if ../boost/test/impl/execution_monitor.ipp:24:1: error: unterminated #ifndef

2 2

Fusion Question
by Tom Brinkman 09 Jul '08

09 Jul '08

>> Have you looked into Adobe's Eve library, described in >> http://lambda-the-ultimate.org/node/563 Oh, yes. definately; and if its as good as Adobe's GIL library, I'm sure it would be a most welcome addition to boost. An Adobe sponsered layout engine would be very welcome, I'm sure. As you know, I use GIL extensively in my own graphics layout library. I think that it represents many of the best-practices that can be found on boost. As far as my own boost::layout library, I'd be happy to merge it with adobe's or just add extensions to it. I'll let you and others guide me on that.

3 3

[extension] Concatenating factory_map objects
by Robert Dailey 09 Jul '08

09 Jul '08

Hi, I'm developing a plugin system and I will be loading several DLLs. Basically, as far as I know, this means having one factory_map per DLL (on Windows). I need to concatenate either the factory_map objects or their maps so that I can do lookups in one map instead of several maps. Is there a recommended way of doing this? Right now this requires keeping all of the factory_map objects around (for cleanup purposes only) and having my additional global std::map, that contains the concatenated std::map's from the factory_map objects (it's essentially one large copy).

2 7

[extension] factory::create() constness
by Robert Dailey 09 Jul '08

09 Jul '08

Hi, Would it be possible to make boost::extension::factory::create() a const member function? I haven't taken the time to look at the implementation of create() myself, but if there's a possibility of that function becoming const I can make my wrapper interfaces const as well. I just have a feeling that a create method should not mutate the factory object at all, but I could be mistaken.

2 1

[gil] new opencv extension
by Christian Henning 08 Jul '08

08 Jul '08

Hi there, over the past few weeks I have rewritten the current opencv extension. Now there is a lot more functionality available as it was before. The following topics are covered: * converting colorspaces ( gray, rgb, rgba, xyz, hsv, hls, and lab ) * drawing primitives ( line, rectangles, circle, polyline, and text ) * edge detection ( sobel, laplace, canny, ... ) * resizing images( nearest neighbor, linear, area, and cubic ) * smoothing ( blur, gaussian, median, and bilateral ) As usual this extension is header only, but a user would need to make the opencv headers and libs available for compiling and linking. You can download the extension here using subversion: http://gil-contributions.googlecode.com/svn/trunk/gil_2 The folder structure is the same as with all boost libraries. There are some tests that can be used for testing and for learning the rather simple interface. Only the vc8 compiler has been used so far and though I would like ask for some assistance for making the extension compilable with gcc, for instance. Please give me some insight of what you think and about what functionality you might miss. I started to toy around with Tom Brinkman's idea of stacking up operations to batch process them which you can see in the drawing_test.cpp. Regards, Christian BTW: OpenCV is distributed with the BSD license and if I understand wikipedia correctly there isn't any objection using it in commercial applications. "The BSD License allows proprietary commercial use, and for the software released under the license to be incorporated into proprietary commercial products. Works based on the material may even be released under a proprietary license (but still must maintain the license requirements)."[wikipedia]

1 0

[date_time] Constructor copy-paste bug?
by Chris Newbold 08 Jul '08

08 Jul '08

While cleaning up GCC -Wshadow warnings in the date_time library, we've found what appears to be a copy-paste error in a date_generator_formatter constructor. The following constructor... //! Constructor that allows for a custom set of phrase elements date_generator_formatter(const string_type& first, const string_type& second, const string_type& third, const string_type& fourth, const string_type& fifth, const string_type& last, const string_type& before, const string_type& after, const string_type& of) { phrase_strings.push_back(string_type(first_string)); phrase_strings.push_back(string_type(second_string)); phrase_strings.push_back(string_type(third_string)); phrase_strings.push_back(string_type(fourth_string)); phrase_strings.push_back(string_type(fifth_string)); phrase_strings.push_back(string_type(last_string)); phrase_strings.push_back(string_type(before_string)); phrase_strings.push_back(string_type(after_string)); phrase_strings.push_back(string_type(of_string)); } ...takes a whole series of arguments, which it summarily ignores as the constructor body is an exact duplicate of that for the default constructor. Presumably the right fix is to push all of the given arguments into phrase_strings. -Chris

1 0

Newbie Trying to Build Boost Libraries on 64-bit MS Windows Vista
by Beverly Pope 08 Jul '08

08 Jul '08

Hi, I am a complete newbie at boost, who must compile several Boost 1.33.1 Libraries on 64-bit MS Windows Vista, using MS VS2005. I downloaded the 64-bit version of Python (python-2.5.2.amd64.msi) as well as bjam (boost-jam-3.1.16-1-ntx86.zip) and Boost 1.33.1 (boost_1_33_1.zip); I then installed Python and extracted the other two files, placing bjam in the PATH. I tried various things to build the libraries. I finally got some (not all) of them to build by setting MSVCDir, which makes the builds bypass running msvcvars32.bat. I am currently using the following to do the build (I've also tried --toolset=msvc, but that does not do any better): bjam ^ -sTools=8_0-amd64 ^ --prefix=%myBoostDir%\newboost ^ --builddir=%myBoostDir%\newboost ^ --debug-configuration ^ --with-python-root=%myPythonDir% ^ --with-python-version=2.5 ^ --with-pydebug ^ stage ^ > %myBoostDir%\logfile.txt 2>&1 1) I see numerous (21360) warnings like the following -- I don't know whether that is something that can be ignored? D:\work\intersect\boost_1_33_1\boost/config/abi_prefix.hpp(19) : warning C4103: 'd:\work\intersect\boost_1_33_1\boost\config\abi_prefix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) 2) When building the libraries, I get the following errors when it tries to build object_protocol.cpp (three times) : vc-C++ d:\work\intersect\boost_1_33_1\newboost\bin\boost\libs\python\build\boost_python.dll\vc-7_1\debug\threading-multi\object_protocol.obj cl : Command line warning D9002 : ignoring unknown option '/Op' object_protocol.cpp D:\work\intersect\boost_1_33_1\libs\python\build\../src/object_protocol.cpp(110) : error C2664: '_PyEval_SliceIndex' : cannot convert parame ter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast D:\work\intersect\boost_1_33_1\libs\python\build\../src/object_protocol.cpp(112) : error C2664: '_PyEval_SliceIndex' : cannot convert parame ter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast D:\work\intersect\boost_1_33_1\libs\python\build\../src/object_protocol.cpp(137) : error C2664: '_PyEval_SliceIndex' : cannot convert parame ter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast D:\work\intersect\boost_1_33_1\libs\python\build\../src/object_protocol.cpp(139) : error C2664: '_PyEval_SliceIndex' : cannot convert parame ter 2 from 'int *' to 'Py_ssize_t *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast Do I just need to change the cast or is something else going on? Thanks for your time. Bev

2 1