- Boost - lists.preview.boost.org

Resources available for testing on 64-bit MSVC
by pfultz2 01 Jun '15

01 Jun '15

Hello, Recently, I have been working on adding MSVC support for the Fit library, and I have been fairly successful. Using the VMs at modern.ie, I was to able to get all the tests to pass on 32-bit Visual Studio 2015 RC. Unfortunately, a few tests fail on the 64-bit MSVC, and I have been unable to find a VM I can use to debug the problem. All the VMs at modern.ie are 32-bit, it seems. Does anyone know of resources available to test and debug libraries with 64-bit MSVC? Thanks, Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Resources-available-for-testing-on-64-bi… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[next gen future-promise] What to call the monadic return type?
by Niall Douglas 01 Jun '15

01 Jun '15

Dear list, As AFIO looks likely to be finally getting a community review soon, I've made a start on a final non-allocating constexpr-collapsing next generation future-promise such that the AFIO you review is "API final". You may remember my experimentations on those from: http://boost.2283326.n4.nabble.com/Non-allocating-future-promise-td466 8339.html. Essentially the win is that future-promise generates no code at all on recent C++ 11 compilers unless it has to [1], and when it does it generates an optimally minimal set with no memory allocation unless T does so. This should make these future-promises several orders of magnitude faster than the current ones in the C++ standard and solve their scalability problems for use with things like ASIO. They also have major wins for resumable functions which currently always construct a promise every resumable function entry - these next gen future-promises should completely vanish if the resumable function never suspends, saving a few hundred cycles each call. Anyway, my earlier experiments were all very promising, but they all had one big problem: the effect on compile time. My final design is therefore ridiculously simple: a future<T> can return only these options: * A T. * An error_code (i.e. non-type erased error, optimally lightweight) * An exception_ptr (i.e. type erased exception type, allocates memory, you should avoid this if you want performance) In other words, it's a fixed function monad where the expected return is T, and the unexpected return can be either exception_ptr or error_code. The next gen future provides Haskell type monadic operations similar to Boost.Thread + Boost.Expected, and thanks to the constexpr collapse this: future<int> test() { future<int> f(5); return f; } test().get(); ... turns into a "mov $5, %eax", so future<T> is now also a lightweight monadic return transport capable of being directly constructed. In case you might want to know why a monadic return transport might be so useful as to be a whole new design idiom for C++ 11, try reading https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:S tronglyconsiderusingconstexprsemanticwrappertransporttypestoreturnstat esfromfunctions. However, future<T> doesn't seem named very "monadic", so I am inclined to turn future<T> into a subclass of a type better named. Options are: * result<T> * maybe<T> Or anything else you guys can think of? future<T> is then a very simple subclass of the monadic implementation type, and is simply some type sugar for promise<T> to use to construct a future<T>. Let the bike shedding begin! And my thanks in advance. Niall [1]: Compiler optimiser bugs notwithstanding. Currently only very recent GCCs get this pattern right. clang isn't bad and spills a dozen or so completely unnecessary opcodes, and I'll follow up with Chandler with some bug reports to get clang fixed. Poor old MSVC spits out about 3000 lines of assembler, it can't do constexpr folding at all yet. -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

16 122

RFC: Separating Boost.Python from Boost
by Stefan Seefeld 31 May '15

31 May '15

Hello, as I have mentioned here before, I would very much like to continue the modularization effort, by fully separating the Boost.Python project from the rest of Boost. For avoidance of doubt: my intent is not to remove Boost.Python out of the Boost organization. Rather, I would like to separate the build and release processes. For the sake of keeping the discussion focused, I would like to avoid getting into too many (technical) details (there already is a related discussion on the Boost.Build list). Rather, I would like to know whether people here (and Boost.Python users in particular) have any particular thoughts about this proposal. Any strong reasons not to move forward with this ? Things to consider while doing it ? Etc. (My hope is that if the operation succeeds, other Boost libraries may want to do the same, which would help Boost in the long term to become more manageable.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

18 62

Thoughts on Trac wiki page commenting facility
by Niall Douglas 31 May '15

31 May '15

Something Robert raised during the meetings at C++ Now was why can't people comment on Boost's Trac wiki pages? The simple answer is because Trac doesn't allow it and hasn't got to implementing it in many years (http://trac.edgewall.org/ticket/11676) despite it being technically as simple as appending a ticket's comments to a wiki page, so I spent some time researching what options are available: 1. https://trac-hacks.org/wiki/WikiCommentsPlugin This works by inserting the comments directly into the article text. Pros: The comments are the document. This lets the page author fix the problem and delete the comment where that is appropriate. Cons: You need a trac login and editing privs to comment, which until a Trac 1.0 upgrade remains manually awarded by a Boost admin. No preview, so you need to know Trac wiki markup. 2. Disqus https://disqus.com/ This is the grand daddy of free commenting services. This works by you inserting some Javascript into the page where you want the comments to appear. AJAX does the rest. This could very easily patched into Trac for every wiki page by tweaking its template as per the instructions at http://trac.edgewall.org/wiki/TracInterfaceCustomization. Pros: Very well understood by users, in fact by everyone. Built in excellent spam protection. Nice UI. Just works. I also have a ton of ready to go infrastructure from nedprod.com for Disqus, so it's really very little effort for me to integrate this. Cons: They own all your data. They serve adverts in the comment stream, though apparently you can now opt out. They track user visits and sell the information, so AdBlock and Ghostery default block Disqus. Comment load times can be very slow. Comments aren't indexed by Google, and this may decrease the value of the system. 3. Keep looking Niall! Like none of the above? There are open source clones of Disqus you can host on your own infrastructure, but I have no experience with any of the those. If the community really doesn't like either of the two above, I guess I can keep looking. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 5

[locale] Build failure on develop
by Marcel Raad 30 May '15

30 May '15

Hi, since Tuesday, all Boost.Locale tests have been failing on all compilers: http://www.boost.org/development/tests/dev elop/developer/locale.html The MSVC results only mention an expected has_iconv.cpp build failure and it seems all other results only say "Error extracting file: No matching files were found." I tested on my local machine with MSVC 14 RC and the library wouldn't compile because of a missing "#include <map>": https://github.com/boostorg/locale/pull/8

1 0

[bind] Placeholders suggestion, std and boost
by Edward Diener 30 May '15

30 May '15

I realize that changing boost::bind so by default that placeholders of the form _n needing some sort of namespace in front of it will break plenty of code, so I am not suggesting doing that. What I would like to suggest is a Boost.bind macro, which when used before including <boost/bind>, would put the boost::bind placeholders of the form _n in a boost::placeholders namespace. The reason for this suggestion is so that boost::bind and std::bind can be similar syntactically enough so that one could choose one or the other depending on compiler support. Since in the C++ std the placeholders are in the std::placeholders namespace, having a means to have the boost::bind placeholders in the boost::placeholders namespace would be a means to that end.

5 16

[type_traits] Big changes in develop
by John Maddock 30 May '15

30 May '15

A heads up that the "Version2" rewrite of type traits is now in develop. There's still lots to do - more PR's will happen over the coming weeks to remove obsoleted code from other libraries (and quash the warnings that they'd otherwise generate). The docs also need a major update. In the mean time please do shout loudly if there are any regressions caused by this change. Thanks, John.

8 26

[test] Fwd: [Boost-testing] All test runners (windows and linux) crashing
by Rene Rivera 29 May '15

29 May '15

Boost Test developers please fix ASAP. ---------- Forwarded message ---------- From: Tom Kent <lists(a)teeks99.com> Date: Thu, May 28, 2015 at 8:26 PM Subject: Re: [Boost-testing] All test runners (windows and linux) crashing To: Running Boost regression tests <boost-testing(a)lists.boost.org>, Boost Developers List <boost(a)lists.boost.org> On Thu, May 28, 2015 at 6:24 PM, Tom Kent <lists(a)teeks99.com> wrote: > All my test runners are quickly crashing during each run...here's the end > of the output in my results/bjam.log file: > > boost-test(RUN) "test/doc_boost_test_macro1" : > "libs/test/doc/examples/boost_test_macro1.cpp" > boost-test(RUN_FAIL) "test/doc_boost_test_macro2" : > "libs/test/doc/examples/boost_test_macro2.cpp" > boost-test(RUN_FAIL) "test/doc_boost_test_macro3" : > "libs/test/doc/examples/boost_test_macro3.cpp" > error: at D:/t08/c/boost_bb/src/kernel\modules.jam:107 > error: Unable to find file or target named > error: '../doc/examples/test_float_01.cpp' > error: referred to from project at > error: '../libs/test/test' > > Any thoughts? > Tom > I should have specified, that is on the develop branch. Master seems fine. _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

All test runners (windows and linux) crashing
by Tom Kent 29 May '15

29 May '15

All my test runners are quickly crashing during each run...here's the end of the output in my results/bjam.log file: boost-test(RUN) "test/doc_boost_test_macro1" : "libs/test/doc/examples/boost_test_macro1.cpp" boost-test(RUN_FAIL) "test/doc_boost_test_macro2" : "libs/test/doc/examples/boost_test_macro2.cpp" boost-test(RUN_FAIL) "test/doc_boost_test_macro3" : "libs/test/doc/examples/boost_test_macro3.cpp" error: at D:/t08/c/boost_bb/src/kernel\modules.jam:107 error: Unable to find file or target named error: '../doc/examples/test_float_01.cpp' error: referred to from project at error: '../libs/test/test' Any thoughts? Tom

1 1

[type_traits][units] migrating from ice_and
by Jürgen Hunold 28 May '15

28 May '15

Hi! I've noticed that boost/type_traits/detail/ice_or.hpp and boost/type_traits/detail/ice_and.hpp have been deprecated. Both headers are used as an implementation detail in boost/units/scaled_base_unit.hpp, now resulting in lots of warnings: In file included from .../boost/units/scaled_base_unit.hpp:20: .../boost/type_traits/detail/ice_or.hpp:17:10: warning: NOTE: Use of this header (ice_or.hpp) is deprecated [-W#pragma-messages] # pragma message("NOTE: Use of this header (ice_or.hpp) is deprecated") Question: Is there a known migration path from type_traits to what? MPL? Or am I better off copying both files to Boost.Units and be done? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

3 4

[testing][teeks] MSVC-14 errors about MSPDB140.DLL
by Andrey Semashev 27 May '15

27 May '15

Hi, All tests for Boost.Log (and I suspect any other built libraries) on MSVC-14 are failing because of this error: LINK : fatal error LNK1101: incorrect MSPDB140.DLL version; recheck installation of this product See here for example: http://www.boost.org/development/tests/develop/developer/output/teeks99-08f… Could this be fixed?

4 7

[typeof] Weird VC++ compiler bug
by Edward Diener 27 May '15

27 May '15

I discovered a strange VC++ bug using Boost.typeof. I am not posting this to rag VC++ but wondering if there is some known workaround in Boost or in Boost.config. #include <boost/typeof/typeof.hpp> template <class T> struct dereference { typedef BOOST_TYPEOF_TPL(*T()) type; }; int main() { } Compiling this with VC++12 gives: test_vc_type_of_indirection.cpp(6) : error C2100: illegal indirection test_vc_type_of_indirection.cpp(7) : see reference to class template instantiation 'dereference<T>' being compiled Notice that I am not even instantiating 'dereference'. But if I write: #include <boost/typeof/typeof.hpp> template <class T> struct dereference { void afunction() { typedef BOOST_TYPEOF_TPL(*T()) type; } }; int main() { } all is well, for all the good it does me. BOOST_TYPEOF_TPL(*T()) expands to: typename boost::type_of::msvc_typeid_wrapper<sizeof(*boost::type_of::encode_start(*T()))>::type and if I substitute this directly the same results occur. I can report this to the VC++ bug tracker but wanted to see if this is a known problem with VC++ in Boost, some weird error for which maybe Boost has some workaround syntax.

6 13

Fwd: Binary Region Differentials
by Kenneth Adam Miller 27 May '15

27 May '15

Suppose I have a rather huge binary region. Transferring it by any means is an expensive operation. But changes to it will only be some fraction at worst case as large as the binary region itself, but in practice will typically be regional byte blobs, mostly not more than a single kilobyte long.. Is there any data structure that already handles this, where I could say, have every instance start off from the original binary region, and calculate what any other instance of that data structure has by "applicating the deltas"?

3 4

svn.boost.org SSL cert errro
by Olaf van der Spek 26 May '15

26 May '15

Hi, The certificatie of svn.boost.org has expired (two weeks ago).. -- Olaf

10 19

[branch master] add library to regression tests
by Oliver Kowalke 26 May '15

26 May '15

Hello, could you please add boost.coroutine2 to the regression tests of branch master?! best regards, Oliver

1 0

Aho - Corasick String Search (for searching multiple patterns) Interface
by meghana madhyastha 26 May '15

26 May '15

Hi, In some of my previous mails I had suggested that the Rabin Karp and Aho - Corasick string search algorithms be implemented as a part of the Boost algorithm library. This is primarily because these algorithms perform well for searching for multiple patterns. The Aho - Corasick algorithm works by building a trie (a tree with each node corresponding to an ASCII character) of the patterns strings and traversing the trie to search for the pattern in a given text. Additionally, the Aho - Corasick introduced the concept of "failure pointer/failure node" which is the node to be traversed when there is a mismatch. For more information: http://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_string_matching_algorithm The interface I propose is as follows. 1. The input of the patterns should be strings within a *container*. This is because these algorithms are primarily used for multiple pattern searching. The user can input pointers/iterators to the first and last pattern . The final output which is returned is a container with each pattern and a iterator/pointer to their occurrences (There are multiple patterns so just returning an iterator/pointer to where the patterns first occurs in the pattern will not suffice). 2. Just like the previous string searching algorithms that have been implemented in Boost, there can be an object based interface as well as a procedure based interface. In the object based interface, the trie is constructed and the failure nodes are computed in the constructor (while creating the object). The user can then search the text using the operator(). template <typename patIter> class aho_corasick { public: aho_corasick(patIter first, patIter last): pat_first(first), pat_last(last), head(std::shared_ptr<trie_node>(new trie_node)) { //first and last are pointers/iterators to the first and last patterns in the container gotoFn(head); failureFn(head); } ~aho_corasick () {}; template <typename corpusIter> corpusIter operator ()(corpusIter corpus_first, corpusIter corpus_last) //Note: using the same notation as used in the other search algorithms. Corpus- refers to the text to be searched. I've implemented this and would like to get feedback/suggestions on the code as well as the interface. Where should I put up the code for it to be reviewed ? Thanks, Meghana

1 0

boost [vmd]: configuration issue in Jamfile.v2 for Oracle Solaris Studio compiler
by Aparna Kumta 26 May '15

26 May '15

I am looking at my test run for vmd in develop branch. http://www.boost.org/development/tests/develop/developer/vmd.html under SunOS. My tests are run with cxxflags="-compat=5 -library=stlport4" as configured in user-config.jam An example of a test, http://www.boost.org/development/tests/develop/developer/output/oracle-spar… The test fails as follows: "CC" -std=c++0x -std=c++11 -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -c -o "/export/home/sstrunk-tester/boost_regression/boost_sparc-S2_stlport4/results/boost/bin.v2/libs/vmd/test/test_after_identifier_elem.test/sun-stlport4/release/threading-multi/test_after_identifier_elem.o" "../libs/vmd/test/test_after_identifier_elem.cpp" CC: -compat=5 can not be used with -std CC: -library=stlport4 cannot be used with -std=c++11 If I compile the test manually without '-std=c++0x -std=c++11', the test compiles OK. %CC -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -m64 -KPIC -DBOOST_AL0%L_NO_LIB=1 -DNDEBUG -I.. -c -o ./test_after_identifier_elem.o ../libs/vmd/test/test_after_identifier_elem.cpp % It looks like boost_root/libs/vmd/test/Jamfile.v2 needs to be modified for this compiler. Any ideas on how this can be done? Thanks, Aparna

2 3

boost::bind C2664 error with two non-const references
by Nicolas FRANCOIS 25 May '15

25 May '15

Hi, Relatively to this thread http://lists.boost.org/Archives/boost/2015/03/220930.php and this correcting commit 42b5cef177603328ead66bc6a98a3067aebc433d, I still have errors using boost::bind. #include <boost/bind.hpp> #include <boost/function.hpp> struct A { void f(int&, std::vector<int*>&); }; int main(){ A a; auto f = boost::bind(&A:f, &a, _1, _2); } results in error C2664: cannot convert from 'const std::vector<int*> &' to 'std::vector<int*> &' Defining BOOST_NO_CXX11_RVALUE_REFERENCES solves the issue for now. Nicolas FRANCOIS Software Department L-ACOUSTICS Tel : +33 (0) 1 69 63 23 90 Fax : +33 (0) 1 69 63 69 64 www.l-acoustics.com<http://www.l-acoustics.com/> Please consider the environment before printing this email.

2 7

Environment Variables Library?
by Michael Ainsworth 24 May '15

24 May '15

StackOverflow regarding the (non) standardisation of the "setenv" function, does Boost provide a library to interact with environment variables? http://stackoverflow.com/questions/30292642/c-standard-library-stdsetenv-vs… Michael

10 34

[testing][CrystaX.NET] Missing header
by Andrey Semashev 23 May '15

23 May '15

Hi, Many of the CrystaX.NET testers fail to compile tests because of this error: fatal error: crystax/google/sys/select.h: No such file or directory See here for example: http://www.boost.org/development/tests/develop/developer/CrystaX-NET-apilev… Could this be fixed?

2 1

boostdep documentation?
by Robert Ramey 22 May '15

22 May '15

I am interesting in taking a look at boostdep. I see the code in tools/... but I don't see any documentation. Is there any? will there be in the future? Robert Ramey

2 3

Re: [boost] [Better Enums] Interest in/feedback on C++11 enums library
by Anton Bachin 22 May '15

22 May '15

I've been keeping away because I am doing a ton of work on the library, and I don't want to attract too much attention until the work is ready, since there are lots of changes. But, I think I should reply, and I will also give a brief update of the progress at the end of the message. > I suspect this code: > > Depth depth = default_<Depth>(); > > could be made to look like this: > > Depth depth = _default; > > > ie all enums have a constructor that takes a default_t type. The > constructor then calls default_<T>(). > Or something like that. And then change the names to get > > Depth depth = default_; // calls default_impl<T>(); That’s a good idea. I hadn't thought of such a constructor. I will try it out, but I am not sure that it would belong directly in the library, if that's what you mean. It's not clear where one should stop. Should there also be an "invalid" constructor for projects that have such a notion? Are there other special values we can't predict? Perhaps this could be achieved with some kind of extension facility. I will eventually be adding either support for subclassing, or extra macros, or some kind of template-based extensibility. To the other commenters: thanks :) As for progress: there are substantial improvements. - The entire interface is now constexpr, including string functions and iterators. - I ported the interface to C++98, though it still requires __VA_ARGS__. This makes the topic of this message inaccurate. Should I start a new thread for the new version when it's up? - The C++98 conversion means that, in theory, the library should work on MSVC down to VS2005. I will be testing that when I get my new notebook in a few days. If successful, Better Enums will be compatible with the 3 major compiler families. - Eliminated all weak symbols, leaving only standard C++. Some may be brought back later for optimization, but they are no longer required. - When compiling for C++11, there are no more implicit conversions to integers. - The library is now a single header file, containing both the C++11 version and the C++98 port, and all helper macros. - The documentation is getting a major improvement, so please don't look now. The all-constexpr version is unfortunately noticeably slower to compile. The performance test that was previously two times faster than including iostream is now twice as slow, but I can mitigate this with some combination of opt-in and optimization. Anton

1 0

[build][test][gsoc] question about compiling tests with multiple compile params using b2
by Damian Vicino 22 May '15

22 May '15

Hi, I’m working in the safe_float library for the GSOC. For testing I’m using the boost.test library and for building I’m using b2. The implementation have several pieces that are implemented in two flavours, one for compilers supporting FLOAT_ENV and one for those not supporting it. (this is a C++11 feature missed in at least clang and gcc compilers) Right now, the implementation is selected with an #ifdef and I #define them with a -D parameter. My config file for test is: using testing ; lib boost_unit_test_framework ; unit-test test : main-test.cpp [ glob *_test.cpp ] boost_unit_test_framework ; I guess I can generate 2 different executables using 2 targets, duplicating last line and adding something to tell it to pass -DFENV_AVAILABLE, but I couldn’t find how to do that. Having 2 executables for the tests and running them both will provide testing for both compilation paths (when using a compiler supporting FENV). Also, I’m wondering if B2 has the inteligence detect and pass a parameter when using a compiler supporting FENV. Is there any common approach for these situations where conditionally compiling based on a c++ feature support? In the case a Boost.Build needs to define a test for detecting if the compiler supports the feature (autoconf-like) it can be tested compiling a one-liner file: test.fenv.cpp #pragma STDC FENV_ACCESS ON When compiled: clang++ -c test.fenv.cpp test.clang.cpp:1:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESS ON The warning means the feature is not supported. Thanks for any guidance in this area, I’m pretty newbie with the b2 system. Best regards, Damian

2 1

[Better Enums] Interest in/feedback on C++11 enums library
by Anton Bachin 21 May '15

21 May '15

Hello, I’ve just released an enum library that takes advantage of constexpr functions and literal types to provide a nice declaration syntax and decent feature set: https://github.com/aantron/better-enums <https://github.com/aantron/better-enums> I’d like to get feedback on it from the experienced developers here at Boost. Is this approach useful? Are any major features missing? Would this be an interesting candidate for enums in Boost? I am very willing to do further development on this project. The library's basic features are string conversions, value and name listing, some type safety, and a declaration syntax that is based on built-in enums and is easy to learn and use. A much more "advanced” feature is that the generated class is a literal type, and almost everything is constexpr. Here is a simple example, that takes advantage of this, of a compile-time encoding of project policy: https://github.com/aantron/better-enums/blob/master/example/6-traits.cc <https://github.com/aantron/better-enums/blob/master/example/6-traits.cc> . Once I make the iterators constexpr as well, by providing a way to increment them other than mutation (++), it will be easy to write rather involved compile-time algorithms that process Better Enums declarations. Here is an example of a whole bunch of simple compile-time processing already possible: https://github.com/aantron/better-enums/blob/master/example/4-constexpr.cc <https://github.com/aantron/better-enums/blob/master/example/4-constexpr.cc> . Some of that could be useful when C++ declarations are generated by script. The library is all standard C++11 (to the best of my knowledge), except for the usage of weak symbols for some generated constexpr static arrays. I have tested it successfully on clang and g++, but I would need help getting access to more compilers. I believe weak symbols are not a problem for MSVC, but I still don’t believe the library will compile on MSVC since I don’t think MSVC supports enough of C++11 yet. Performance is what I would call excellent. I compared compilation times of these two files to each other: https://github.com/aantron/better-enums/blob/master/test/performance/4-decl… <https://github.com/aantron/better-enums/blob/master/test/performance/4-decl…> https://github.com/aantron/better-enums/blob/master/test/performance/5-iost… <https://github.com/aantron/better-enums/blob/master/test/performance/5-iost…> The first file includes enum.h and declares a bunch of enums, and the second merely includes iostream. On my machine, clang compiled all those enums in about half the time it took to process iostream. g++ was faster on iostream, but only slightly. Using a lot of compile-time expressions would have additional cost, but it has been too small to measure for “realistic” examples from my own usage. I haven’t yet made an example that repeatedly deals with a very large enum at compile time to properly measure that impact. I’ve also explored an alternative interface where the constexpr properties provided by the library are in a traits class parametrized by a normal C++11 enum class, but the interface seemed too verbose. There is also a bitset type that has a very slightly nicer interface than std::bitset for usage with enums, but I didn’t think the improvement was worth the user’s learning effort. I can put these in branches if there is interest, however. Please let me know what you think. Best, Anton

5 4

[BOOST_FOREACH] Problem to iterate on a non-copyable container...
by nico 21 May '15

21 May '15

I'm not sure of the title, because I'm not sure the issue comes from the "copyablility" of my container. I tryied quite everything but I can't get rid of this error. Here is a simplified version of my code (please do not challenge the class design, I really would like to keep the end-used syntax in the BOOST_FOREACH): template <typename T> class MyContainer { public: typedef typename std::vector<T>::iterator iterator; typedef typename std::vector<T>::const_iterator const_iterator; MyContainer(std::vector<T>& vec, boost::mutex& mutex) : m_vector(vec), m_lock(mutex) { } iterator begin() { return m_vector.begin(); } const_iterator begin() const { return m_vector.begin(); } iterator end() { return m_vector.end(); } const_iterator end() const { return m_vector.end(); } private: std::vector<T>& m_vector; boost::lock_guard<boost::mutex> m_lock; }; template <typename T> struct GetContainer { GetContainer(std::vector<T>& vec, boost::mutex& mutex) : m_vector(vec), m_mutex(mutex) { } MyContainer<T> Get() { return MyContainer<T>(m_vector, m_mutex); } std::vector<T>& m_vector; boost::mutex& m_mutex; }; int main() { std::vector<int> v; v.push_back(1); v.push_back(2); boost::mutex m; GetContainer<int> getter(v, m); BOOST_FOREACH(int i, getter.Get()) { std::cout << i << std::endl; } return 0; } The compiler complains about not having a copy constructor for MyContainer<int>::MyContainer(const MyContainer<int>&) I also have : error: no matching function for call to ‘MyContainer<int>::MyContainer(boost::foreach_detail_::rvalue_probe<const MyContainer<int> >::value_type)’ I follow the extensibility tips: http://www.boost.org/doc/libs/1_58_0/doc/html/foreach/extensibility.html#fo… But, making MyContainer<T> : private boost::noncopyable doesn't solve the issue. Nor defining the function boost_foreach_is_noncopyable or specializing the template struct is_noncopyable for MyContainer<int> (in fact, how would I specialize this template for a template type ?) Last "tip": If I remove the mutex and the lock from everywhere (I just pass the vector to GetContainer and to MyContainer<T>, it works. But it doesn't work if I make MyContainer<T> : private boost::noncopyable (I expected it should, so I'm not sure my problem is with BOOST_FOREACH, but maybe because I return a copy of MyContainer with my getter ?) I thank you if you read me until here, and thanks in advance for help.

3 4