November 2011 - Boost-users

[Graph] compilation error under Windows but not under Linux
by Gaël de Chalendar 29 Aug '12

29 Aug '12

Hello, I have a compilation error under Windows (Visual C++ 2008) with a code that works well under Linux (gcc 4.6.1 and before). The compilation error is: =========== /FsaAccess16.tcc(833) : error C2784: 'std::pair<graph_traits<G>::in_edge_iterator,graph_traits<G>::in_edge_iterator> boost::in_edges(graph_traits<G>::vertex_descriptor,const boost::subgraph<Graph> &)'ÿ: impossible de d‚duire l'argument modŠle pour 'const boost::subgraph<Graph> &' … partir de 'FrCeaLic2m::Common::FsaAccess::selected_graph_types16::spareGraphType' C:\PROGRA~1\boost\BOOST_~1\boost/graph/subgraph.hpp(432)ÿ: voir la d‚claration de 'boost::in_edges' Z: \Projets\MoteurMultimedia\mm_common\src\common/FsaAccess/FsaAccess16.tcc(778)ÿ: lors de la compilation de la fonction membre '<Inconnu>' de la classe <Inconnu> z: \projets\moteurmultimedia\mm_common\src\common\fsaaccess\FsaAccessReader16.h(118)ÿ: voir la r‚f‚rence … l'instanciation de la classe modŠle 'FrCeaLic2m::Common::FsaAccess::FsaAccess16<graphType>' en cours de compilation with [ graphType=FrCeaLic2m::Common::FsaAccess::selected_graph_types16::spareGraphType ] z: \projets\moteurmultimedia\mm_common\src\common\fsaaccess\FsaAccessSpare16.h(35)ÿ: voir la r‚f‚rence … l'instanciation de la classe modŠle 'FrCeaLic2m::Common::FsaAccess::FsaAccessReader16<graphType>' en cours de compilation with [ graphType=FrCeaLic2m::Common::FsaAccess::selected_graph_types16::spareGraphType ] =========== The line that does not compile is boost::tie(iei,ie_end) = boost::in_edges(commonTarget,m_graph); The function being compiled is declared like that: template <typename graphType > std::pair< const typename boost::graph_traits<graphType>::vertex_descriptor, bool > FsaAccess16<graphType>::findEquivalentInRegister( dicoVertexType tempState ){ ... And here graphType, the type of m_graph is spareGraphType defined by: struct selected_graph_types16 { ... typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, dicoVertexCountProperty> spareGraphType; ... This is a cmake based project that I compile using qtcreator. I'm a Linux developer and I'm a little bit lost with VC outputs and tools under Windows... Regards, Gaêl -- Gael de Chalendar CEA LIST Centre de Fontenay-aux-Roses Laboratoire Vision et Ingénierie des Contenus (Vision and Content Engineering Laboratory) Bat. 38-2 ; 18, rue du Panorama ; BP 6 92265 Fontenay aux Roses Cedex ; France Tél.:01.46.54.80.18 ; Fax.:01.46.54.75.80 Email : Gael.D.O.T.de-Chalendar.A(a)T.cea.D.O.T.fr

2 2

Re: [Boost-users] asio HTTP Server 3 example memory leak
by admin＠thefireflyproject.us 25 Aug '12

25 Aug '12

2 1

accumulator operations
by Olaf Peter 04 Jun '12

04 Jun '12

Hi, I like to collects some stats. There are several data slices where I can partially/separated collect them (each of them). Finaly I like to combine these stats to a single one to get summarized informations. How to? May this work: accumulator_set<..> acc1; accumulator_set<..> acc2; ... accumulator_set<..> acc_all; ... acc1(42); ... acc_all += acc1; ... acc_all += acc2; Because did not found informations about. The same problem woulde be probably for a threaded implementation too. Thanks, Olaf

4 4

[multi_array] operator= requires resize - why?
by Markus Werle 04 Jun '12

04 Jun '12

Hi! IMHO the behaviour of operator= for multi_array is a little bit broken. A lot of preconditions required: template <typename ConstMultiArray> multi_array_ref& operator=(const ConstMultiArray& other) { [...] // make sure the dimensions agree assert(other.num_dimensions() == this->num_dimensions()); assert(std::equal(other.shape(),other.shape()+this->num_dimensions(), this->shape())); Besides the fact that I get mad about asserts instead of exceptions (please change this to a way users may choose) why do we have such an odd behaviour here? >From page 1, line 3 of the docs I cite: "The interface design is in line with the precedent set by the C++ Standard Library containers" - this is not true for operator=, since std::<container>::operator= works fine for me all the time _without_ any resize. Could we please change the behaviour of multi_array::operator= to take care of resize where in need to? IMHO operator= should result in a true copy ignoring previous state. Markus

6 18

offlist - Re: [iterator] Problems with iterator_facade and const-qualification
by Neil Groves 24 May '12

24 May '12

On Sat, May 7, 2011 at 5:52 PM, Dave Abrahams <dave(a)boostpro.com> wrote: > On Fri, May 6, 2011 at 1:51 PM, Evan Driscoll <driscoll(a)cs.wisc.edu> > wrote: > > On 05/06/2011 11:59 AM, Jeff Flinn wrote: > >> > >> You might google any_iterator, and see how other authors have addressed > >> similar problems. > > > > Great! I tried to find someone who had done something similar, figuring I > > couldn't have been the first, but all the search terms I tried were too > > generic. > > > > Thanks, > > Evan > > You can find one in the ASL that's built on iterator_facade. > http://stlab.adobe.com/classadobe_1_1any__iterator.html > > The underlying Boost.Range implementation implements an any_iterator that I believe to be similar to the one in ASL in terms of functionality. I believe that the small-buffer optimization implementation is superior to forcing the definition of a closed-set of possible type as suggested in a TODO within the ASL documentation. During my performance testing I had considerably superior performance than the ASL implementation. I wondered if you disliked my implementation, or had any feedback. Additionally I wondered what you thought about moving the Boost.Range internal any_iterator implementation into Boost.Iterator. I can't honestly imagine a good use-case for using any_iterator in preference to any_range, hence I haven't suggested this previously. This could easily be due to my lack of imagination! Can you think of a time when using an any_iterator on any interface would be superior to using an any_range? Your opinions and guidance would be much appreciated. HTH, > > -- > Dave Abrahams > BoostPro Computing > http://www.boostpro.com Regards, Neil Groves

4 5

Recommended mock framework to use with Boost?
by doug livesey 15 Mar '12

15 Mar '12

Hi -- I'm trying to learn to develop properly with C++ and Boost, and to that end am learning along with Boost.Test, as I'm a BDD coder in another language (Ruby) in my day job. I'm at the point, now, where my tests could really benefit from a mocking framework. There doesn't appear to be one in Boost (not documented, at least), so I wondered if anyone on the list could recommend a mocking framework that they use that works well with Boost.Test? Any and all advice gratefully received, Doug.

9 16

Boost.Generic sources?
by Nathan Ridge 05 Mar '12

05 Mar '12

I just read about the Boost.Generic library at https://github.com/boostcon/2011_presentations/raw/master/thu/Boost.Generic…. It looks amazing! I understand it's not fully complete, but are the sources available somewhere? Thanks, Nate.

2 5

[smart_ptr] Inclusion of unique_ptr
by Szymon Gatner 27 Dec '11

27 Dec '11

Hi, as suggested by Dave Abrahams I am now turning here with proposition of including unique_ptr<> to smart_ptr library. Newly accepted boost.move enables portable implementation and move-aware containers in boost.container allow to take full advantage of this now standard pointer type. Attaching proposed implementation. -- Szymon Gatner The Lordz Games Studio www.thelordzgamesstudio.com

3 2

Ambiguous boost::move
by Kelvin Chung 13 Dec '11

13 Dec '11

I'm having this compiler issue while trying to use boost::packaged_task (gcc, C++03, move emulation). When I try to compile, I get the following: src/KMBuilder.cpp:54: error: call of overloaded ‘move(boost::unique_future<long unsigned int>&)’ is ambiguous boost/include/boost/thread/detail/move.hpp:44: note: candidates are: typename boost::enable_if<boost::is_convertible<T&, boost::detail::thread_move_t<T> >, boost::detail::thread_move_t<T> >::type boost::move(T&) [with T = boost::unique_future<long unsigned int>] boost/include/boost/move/move.hpp:294: note: typename boost::move_detail::disable_if<boost::has_move_emulation_enabled<T>, T&>::type boost::move(T&) [with T = boost::unique_future<long unsigned int>] The offending line of code: futures.push_back(boost::move(taskResult)); // futures is a boost::container::deque Is there a way to force one version of boost::move over the other? If so, which one should I use?

3 2

[Format] boost 1.48.0, vs2010 runtime check triggered by cast to smaller type in feed_args.hpp
by david x callaway 09 Dec '11

09 Dec '11

running the code below triggers a runtime crash due to casting to a smaller type in feed_args.hpp if -RTCc is given. we turn on this runtime check for debug builds as shown in the sample code. so far the only remedy I've found is to turn off runtime checks for the entire module, not a nice solution. microsoft's suggestion, to use a pragma to turn off the check, doesn't work (not your problem I know). the same issue exists in boost 1.47.0. thx dxc // ----- cut ---- // boost 1.48.0 // visual studio 10.0, service pack 1, windows 7/64 // using this pragma, per microsoft, does not solve the problem // #pragma runtime_checks( "", off ) #include <string> #include <boost/format.hpp> // compile: cl -EHsc -W4 -I /path/to/boost -MDd check.cp // runs fine with no runtime check, output as expected // if you include -RTCc, runtime size checks, it goes into the debugger // compile: cl -EHsc -W4 -RTCc -I /path/to/boost check.cpp // static_cast triggers runtime error at feed_args.hpp:168 int main() { std::string documenttype("1"); std::string key(boost::str(boost::format("name[documenttype:%1%]")%documenttype)); std::cout << key << "\n"; // expected output: name[documenttype:1] return 0; } // #pragma runtime_checks( "", restore )

2 2