- Boost - lists.boost.org

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

[release] merging doc changes?
by joaquin＠tid.es 08 Jul '08

08 Jul '08

Is it OK to merge documentation changes to the release branch? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[fusion] fusion sequence of non-copy-constructible types
by Oliver Mueller 08 Jul '08

08 Jul '08

hello, at the last boostcon i had the chance to be introduced to fusion by dan and joel. i appreciate the idea of fusion a lot and the library amazingly detailed. since we have already had great exposure to the mpl the fusion concepts present ample opportunity for new ideas. still, some little things sometimes make it hard for me to keep rolling with fusion: i need to have a vector/list of non-copy-constructible types. using e.g. a standard fusion::vector that does not seem to be possible since objects are constructed first, then copied. of course, i could provide a public copy-constructor but that would in other places remove the compiler enforced contract that those objects are not copied under any circumstances. i also cannot think of a good reason why it is nesseccary to copy in that case. so is there a way of having a fusion sequence that does work on non-copy-constructible types? thanks for any suggestions, oliver

6 13

Re: [boost] [1.36.0] Libraries with unmerged changes?
by Jan Gaspar 08 Jul '08

08 Jul '08

Hi Thorsten, I've just found your emails in the spam folder. ?? Will merge the changes into the release branch. Jan ----- Original Message ---- From: Thorsten Ottosen <thorsten.ottosen(a)dezide.com> To: boost(a)lists.boost.org; Jan Gaspar <jano_gaspar(a)yahoo.com> Sent: Tuesday, 8 July, 2008 10:45:01 AM Subject: Re: [1.36.0] Libraries with unmerged changes? Beman Dawes skrev: > Below is a list of libraries whose header files appear to differ between > the trunk and branches/release. > circular_buffer I have had diffuculties reaching Jan regarding this library. There are some quite imortant changes here, especially for the default constructor. If we can't reach Jan soon, I wonder if I could just patch the constructor in the release branch for him? -Thorsten __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

1 0

Fusion Question
by Tom Brinkman 08 Jul '08

08 Jul '08

Joel de Guzman, I'd like to enhance my future boost::layout library proposal to use your boost::fusion. Here is a simple example of the boost::layout framework, that uses boost::gill as the view parameter. A boost::layout functor takes the following form: struct layer { template <typename view_t> void operator()(view_t& view) {} }; Examples of layers could be: fill_layer<> fill; border_layer<> border; text_layer<> text; Lets say I want to combine three layers into a single drawing operation. Currently, I do it like this: typedef boost::function<void (view_t&) > layer_t; layer_t layers[] = { fill_layer<>, border_layer<>, text_layer<> } draw_layers draw(layers,sizeof(layers)/sizeof(layer_t)); boost::gil::rgb8view_t view; draw(view); This works fine, but I would like to improve it by using boost fusion. Any suggestions or hints to get me started?

2 1