- Boost - lists.preview.boost.org

[proto][variant] variant crashes proto expression
by Igor R 13 May '16

13 May '16

The following code is a slightly modified Proto calc2 example. Instead of doubles I use variant<int, double>, and the expression is just _1 = _2. This code triggers assertion in variant/detail/forced_return.hpp, so it looks like some variant instance gets messed up. It happens when the value returned from proto::eval(*this, ctx) is being copied. It can be reproduced both with MSVC and gcc, with Boost 1.60. Is there any workaround for this issue? Thanks. ////////////// #include <iostream> #include <boost/proto/proto_typeof.hpp> #include <boost/proto/core.hpp> #include <boost/proto/context.hpp> #include <boost/variant.hpp> namespace proto = boost::proto; using proto::_; typedef boost::variant<int, double> var_t; template<typename Expr> struct calculator_expression; // Tell proto how to generate expressions in the calculator_domain struct calculator_domain : proto::domain<proto::generator<calculator_expression> > {}; // Will be used to define the placeholders _1 and _2 template<int I> struct placeholder {}; // Define a calculator context, for evaluating arithmetic expressions // (This is as before, in calc1.cpp) struct calculator_context : proto::callable_context< calculator_context const > { // The values bound to the placeholders var_t d[2]; // The result of evaluating arithmetic expressions typedef var_t result_type; explicit calculator_context(const var_t &d1 = var_t(), const var_t &d2 = var_t()) { d[0] = d1; d[1] = d2; } // Handle the evaluation of the placeholder terminals template<int I> result_type operator ()(proto::tag::terminal, placeholder<I>) const { return d[ I - 1 ]; } }; // Wrap all calculator expressions in this type, which defines // operator () to evaluate the expression. template<typename Expr> struct calculator_expression : proto::extends<Expr, calculator_expression<Expr>, calculator_domain> { explicit calculator_expression(Expr const &expr = Expr()) : calculator_expression::proto_extends(expr) {} BOOST_PROTO_EXTENDS_USING_ASSIGN(calculator_expression<Expr>) // Override operator () to evaluate the expression var_t operator ()() const { calculator_context const ctx; return proto::eval(*this, ctx); } var_t operator ()(const var_t &d1) const { calculator_context const ctx(d1); return proto::eval(*this, ctx); } var_t operator ()(const var_t &d1, const var_t &d2) const { calculator_context const ctx(d1, d2); return proto::eval(*this, ctx); } }; // Define some placeholders (notice they're wrapped in calculator_expression<>) calculator_expression<proto::terminal< placeholder< 1 > >::type> const _1; calculator_expression<proto::terminal< placeholder< 2 > >::type> const _2; // Now, our arithmetic expressions are immediately executable function objects: int main() { BOOST_PROTO_AUTO(expr, _1 = _2); var_t a1(1), a2(2.5); expr(a1, a2); return 0; }

3 2

[intrusive] crash with slist push_back
by Arpan Sen 12 May '16

12 May '16

Hi Boost Dev, Please consider the following code, this crashes with slist but works just fine if I replace slist with list. Also flat_map crashes but std::map works fine. Am I doing something gross or is there a bug here? #include <iostream> #include <boost/container/flat_map.hpp> #include <map> //#include <boost/intrusive/list.hpp> #include <boost/intrusive/slist.hpp> using namespace boost::intrusive; struct m : public slist_base_hook<> { int n; public: m(int k) : n(k) { } }; int main() { boost::container::flat_map<int, slist<m, cache_last<true> > > c1; std::map<int, slist<m, cache_last<true> > > c2; m* m1 = new m(22); c1[1].push_back(*m1); m* tt = new m(99); c2[1].push_back(*tt); } Regards Arpan

2 1

Using thread_local with Boost.Thread
by Ruediger Berlich 11 May '16

11 May '16

Hi there, I am curious whether it would be possible to use C++11 thread_local instead of Boost's own TLS, while continuing to use Boost.Thread ? I assume that there will be problems if Boost falls back to native pthread ? Kind Regards, Beet

1 0

Boost 1.61.0 Release Candidate 2
by Vladimir Prus 11 May '16

11 May '16

The second release candidates for the 1.61.0 release are now available at: http://boost.cowic.de/rc/boost_1_61_0_rc2.zip http://boost.cowic.de/rc/boost_1_61_0_rc2.7z http://boost.cowic.de/rc/boost_1_61_0_rc2.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_rc2.tar.gz The SHA256 checksums are as follows: fa1c34862b7ba8674ed6e064a14667a11830c6252f702d9458451834b74f7815 boost_1_61_0_rc2.7z a547bd06c2fd9a71ba1d169d9cf0339da7ebf4753849a8f7d6fdb8feee99b640 boost_1_61_0_rc2.tar.bz2 a77c7cc660ec02704c6884fbb20c552d52d60a18f26573c9cee0788bf00ed7e6 boost_1_61_0_rc2.tar.gz 02d420e6908016d4ac74dfc712eec7d9616a7fc0da78b0a1b5b937536b2e01e8 boost_1_61_0_rc2.zip The changes relative to RC1 are MSVC fixes for signals2 and graph libraries. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. The signed list of checksums is also attached, signed with the following key: https://pgp.mit.edu/pks/lookup?op=get&search=0xDA472E8659753BA4 Key fingerprint C5F0 F367 AA66 616F B839 806E DA47 2E86 5975 3BA4 Thanks! -- The release managers

9 14

[lockfree] _ENABLE_ATOMIC_ALIGNMENT_FIX for VS 2015 Update 2
by Stephan T. Lavavej 11 May '16

11 May '16

Hi, While running Boost.Lockfree's tests, one of our compiler devs encountered the following failure: freelist_test.cpp c:\wcfb01\binaries\x86chk\inc\atomic(659): error C2338: You've instantiated std::atomic<T> with sizeof(T) equal to 2/4/8 and alignof(T) < sizeof(T). Before VS 2015 Update 2, this would have misbehaved at runtime. VS 2015 Update 2 was fixed to handle this correctly, but the fix inherently changes layout and breaks binary compatibility. Please define _ENABLE_ATOMIC_ALIGNMENT_FIX to acknowledge that you understand this, and that everything you're linking has been compiled with VS 2015 Update 2 (or later). c:\wcfb01\binaries\x86chk\inc\atomic(669): note: see reference to class template instantiation 'std::_Atomic_base<_Ty,4>' being compiled with [ _Ty=boost::lockfree::detail::tagged_index ] e:\boost\boost\boost\lockfree\detail\freelist.hpp(608): note: see reference to class template instantiation 'std::atomic<boost::lockfree::detail::tagged_index>' being compiled e:\boost\boost\boost\lockfree\detail\freelist.hpp(609): note: see reference to class template instantiation 'boost::lockfree::detail::fixed_size_freelist<T,NodeStorage>' being compiled call "C:\WCFB01\binaries\x86chk\bin\i386\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"..\bin.v2\libs\lockfree\test\freelist_test.test\msvc-latest\debug\threading-multi\freelist_test.obj.rsp" ...failed compile-c-c++ ..\bin.v2\libs\lockfree\test\freelist_test.test\msvc-latest\debug\threading-multi\freelist_test.obj... with the following type: class tagged_index { public: typedef boost::uint16_t tag_t; typedef boost::uint16_t index_t; protected: index_t index; tag_t tag; }; This is by design - your tagged_index has align 2, size 4, triggering the need for my atomic alignment fix. As the static_assert advises, your code needs to define _ENABLE_ATOMIC_ALIGNMENT_FIX in order to pass. If this has already been fixed in 1.61.0, then that's great (I haven't checked). Thanks, STL

5 14

Getting started with boost in Codeblocks
by Karan Kapoor 11 May '16

11 May '16

Hi, This is Karan Kapoor,a 3rd year UG student at NSIT. Can somebody guide me how to get started with boost libraries while i am using codeblocks. Karan Kapoor

2 1

Boost.Random subtract_with_carry doesn't like m == numeric_limits<result_type>::digits
by Billy O'Neal (VC LIBS) 10 May '16

10 May '16

Hello, Boost folks. I found a bug in subtract_with_carry_engine while fixing a bug in MSVC++'s implementation of the same, where m == numeric_limits<result_type>::digits. Consider the following: #include <stdlib.h> #include <stdio.h> #ifdef USE_BOOST #include <boost/random/subtract_with_carry.hpp> using namespace boost::random; #else #include <random> using namespace std; #endif template <typename Engine> typename Engine::result_type run_10k(Engine engine) { for (int i = 0; i < 9999; ++i) { engine(); } return engine(); } int main() { subtract_with_carry_engine<unsigned long long, 64, 10, 24> ull_swc; ull_swc.seed(0x12341234'00000000); printf("0x%016llX\n", run_10k(ull_swc)); } MSVC++ said: 0xFCF0A4776BA0A6A8 Libstdc++ says: 0x01316AEA3646F686 Libc++ says: 0x01316AEA3646F686 Boost 1.60.0/libc++ + Clang says: 0x69E18848FE1BD36D Boost 1.60.0/libstdc++ + g++ says: 0x1DD6C263C41EEED0 MSVC++'s bug was that we did the underflow check incorrectly resulting in the carry bit always being set if m == numeric_limits<result_type>::digits. I fixed that and MSVC++ will agree with libstdc++ and libc++ in the next update; but boost's behavior here is still strange. Hope that helps, Billy Robert O'Neal III SDE II - Visual C++ Libraries bion(a)microsoft.com

2 1

[thread] API for getting/setting thread name in Boost?
by Bob Summerwill 10 May '16

10 May '16

I've also been working with an external developer which is getting Ethereum C++ working on Alpine Linux, as a statically linked executable using musl, rather than glibc. One rather confusing element was related to setting and getting thread names, which is the process of working through this issue, I find appears not to have made its way into either Boost or the C++11 standard library, though it must be a very common cross-platform use-case. https://github.com/ethereum/libweb3core/pull/73 https://github.com/ethereum/libweb3core/pull/73/files I've just added this comment-block, while fixing the issue: /// Set the current thread's log name. /// /// It appears that there is not currently any cross-platform way of setting /// thread names either in Boost or in the C++11 runtime libraries. What is /// more, the API for 'pthread_setname_np' is not even consistent across /// platforms which implement it. /// /// A proposal to add such functionality on the Boost mailing list, which /// I assume never happened, but which I should follow-up and ask about. /// http://boost.2283326.n4.nabble.com/Adding-an-option-to-set-the-name-of-a-bo… /// /// man page for 'pthread_setname_np', including this crucial snippet of /// information ... "These functions are nonstandard GNU extensions." /// http://man7.org/linux/man-pages/man3/pthread_setname_np.3.html /// /// Stack Overflow "Can I set the name of a thread in pthreads / linux?" /// which includes useful information on the minor API differences between /// Linux, BSD and OS X. /// http://stackoverflow.com/questions/2369738/can-i-set-the-name-of-a-thread-i… /// /// musl mailng list posting "pthread set name on MIPs" which includes the /// information that musl doesn't currently implement 'pthread_setname_np' /// https://marc.info/?l=musl&m=146171729013062&w=1 void setThreadName(std::string const& _n); Would I be right in assuming that this never happened? http://boost.2283326.n4.nabble.com/Adding-an-option-to-set-the-name-of-a-bo… If not, where can I log an issue to request that we revisit that? From what I can see, everybody is likely just cut-and-pasting much the same code for this functionality. http://stackoverflow.com/questions/10121560/stdthread-naming-your-thread Cheers, Bob Summerwill -- bob(a)summerwill.net

2 7

[config] Boost and the Intel (Linux) compiler
by Bob Summerwill 10 May '16

10 May '16

I am a developer on the Ethereum C++ client ( https://github.com/ethereum/webthree-umbrella) and have been working with an external developer on adding support to the codebase for building with the Intel Compiler on Ubuntu. Here is the full log of pain :-) https://github.com/ethereum/webthree-umbrella/issues/396 We've already merged various changes, and we appear to be getting down to the real hard ones, which are now mainly clustered around build issues with boost::multiprecision and seeming limitations with the Intel compiler and Like so: /home/libweb3core/libdevcore/Base64.h(48): error: no suitable conversion function from "boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<160U, 160U, boost::multiprecision::unsigned_magnitude, boost::multiprecision::unchecked, void>, boost::multiprecision::et_off>" to "unsigned int" exists unsigned r = (unsigned)(a - a / 36 * 36); // boost's % is broken ^ detected during instantiation of "std::string dev::toBase36(const dev::FixedHash<N> &) [with N=20UL]" at line 114 of "/home/libethereum/libethcore/ICAP.cpp" This appears to be the key observation: https://github.com/ethereum/webthree-umbrella/issues/396#issuecomment-20659… "In summary, the intel platform supports this "convert_to" member function, but does not support implicit conversion of boost multiprecision types" Has anybody worked with Boost and the Intel compiler who might have some further insight into whether there is some way in which the Intel compiler "warts" can be handed within Boost? Or are we stuck with these nasty diffs/workarounds? https://github.com/ethereum/libethereum/pull/224/files https://github.com/ethereum/libweb3core/pull/68/files Cheers, Bob Summerwill Developer, Ethereum Foundation -- bob(a)summerwill.net

3 4

github issues tracking listing
by Vicente J. Botet Escriba 09 May '16

09 May '16

Hi, I would like to have the possibility to have github issues in my boost modules (thread/chrono/ratio). I see that Boost.Hana has its own issue list. What I need to do to add the possibility to add issues? Best, Vicente

3 3

Boost 1.61.0 Release Candidate 1
by Vladimir Prus 09 May '16

09 May '16

The release candidates for the 1.61.0 release are now available at: http://boost.cowic.de/rc/boost_1_61_0_rc1.zip http://boost.cowic.de/rc/boost_1_61_0_rc1.7z http://boost.cowic.de/rc/boost_1_61_0_rc1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_rc1.tar.gz The SHA256 checksums are as follows: dcd11a91a412b2e8a78678b38cb2a74857e61f9bfe2577de9fd70be770100d54 boost_1_61_0_rc1.7z 476937369c7a82103b734ccae85d35a523cdb7f8462c5f2fe1217ff0c8e2a7df boost_1_61_0_rc1.tar.bz2 e60dee39ebb29d24bf8a4ef9aec34dbb8c1b9b219d4737ea4b358f38b1aab2b7 boost_1_61_0_rc1.tar.gz e5f662f44a65c5c19450b8a1c07f75c7d5f16e58667871e856ba3984ec082006 boost_1_61_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. The signed list of checksums is also attached, signed with the following key: https://pgp.mit.edu/pks/lookup?op=get&search=0xDA472E8659753BA4 Key fingerprint C5F0 F367 AA66 616F B839 806E DA47 2E86 5975 3BA4 Thanks! -- The release managers

14 38

[Style] Import a C function with wrong signature on purpose
by Klemens Morgenstern 08 May '16

08 May '16

Hi, for the boost.process library I need WinAPI functions which take an enumerator. Problem is: the forward-declaration doesn't work here, even with C++11. I.e. this code is still illegal, because X has a non-fixed type: enum X {}; enum X : typename std::underlying_type<X>::type ; I do however know which values the enum has take, thus I can redeclare it and have the reasonable expectation, that it will use the same underlying type. So theoretically, I could import the function into a seperate namespace (using extern "C") and use it, while having it declared with another enum type. I.e. you have in some C code the declaration: enum X { a,b,c}; void f(X); And I'll write in my code without including the other header: namespace import_thingy { extern "C" { enum X { a,b,c}; void f(X); } To be absolutely sure, I'd add an test, which asserts that the underlying types are equal. Now of course, that would never be accepted into the boost/winapi module, but I could just add this in my library. Would this be a dealbreaker for a library attempting to become a boost-library? If so, I'd need to put it into a source file and include windows.h there, but I'd really like the library to be header-only and under no circumstances include windows.h there. Thanks, Klemens

2 6

What to do about std::binary_function and std::unary_function?
by Nick Matteo 07 May '16

07 May '16

std::binary_function and std::unary_function are deprecated, and scheduled to be removed from the standard in C++17. That means it's possible that code using these might soon fail to compile when targeting this standard. These are still used throughout Boost, including by the libraries Accumulators, Algorithm, Bimap, Function, Functional, GIL, Graph, ICL, MPI, Polygon, and Xpressive. You can see all the uses I found in the 1.61 beta boost/ directory at http://kundor.github.io/ubinary_function_list.html . All that these classes do are provide the typedefs result_type, and argument_type (for unary_function) or first_argument_type and second_argument_type (for binary_function). In particular, they do not include a virtual operator(), so that one cannot accept a function object polymorphically as a std::binary_function&, for example. So, although it is conceivable that C++98-era user code might check for inheritance from std::binary_function, it seems rather unlikely: practically all uses should just depend on the typedefs being present (which is what the standard library has always done). With modern C++ standards, the availability of std::result_of, decltype, and std::function make these typedefs redundant, and references to them are being phased out of the standard library (starting with deprecation.) It seems to me that there are four main possibilities for removing these classes from Boost. (I'll talk about binary_function in the following, but it all applies equally to unary_function.) 1) Add some sort of compatibility macro to Boost.Config, to enable classes to inherit from std::binary_function if it is available, or add the appropriate typedefs if it is not. I don't think this is necessary. 2) Remove the inheritance from std::binary_function, and add the typedefs. This seems to be the default approach: it is used by the C++11 standard itself, and has also already been done by some Boost libraries, e.g. in container/string.hpp and in intrusive/priority_compare.hpp. The drawback here is increased verbosity. Instead of writing template <class T> struct functor : std::binary_function<T, T, bool> {...}; We must write template <class T> struct functor { typedef T first_argument_type; typedef T second_argument_type; typedef bool result_type; ... }; 3) A modification of approach 2: instead of manually adding the typedefs everywhere, make a base class to provide the typedefs somewhere in Boost. Then replace inheritance from std::binary_function<Arg1, Arg2, Result> with inheritance from boost::binary_function<Arg1, Arg2, Result>. 4) Just remove inheritance from std::binary_function (and don't provide typedefs.) This is the bold approach. The typedefs are redundant now: I think the only use in the standard library is by the deprecated std::not1/std:not2 and the deprecated binders std::bind1st/std::bind2nd (which are to be removed in C++17). This is the direction that the standard library is starting to head, with all uses of the typedefs deprecated and probably eventually removed, and even the provision of the typedefs optional in C++17 standard library function objects. This has already been done at least by Boost Interprocess in detail/mpl.hpp. Probably the best options are either (2) or (4). Should there be a default policy on what authors should do? Nick Matteo

5 6

Regression testing Clang/LLVM with VC14.
by degski 07 May '16

07 May '16

I have started a new thread as the other one "Testing of clang emualting the VC++ preprocessor on Windows" has become rather long and interlaced with less relevant musings. Here I would like to concentrate on the subject in the title. Sergey suggested I'd run regression tests, in the "other thread". I was hesitant at first, mostly due to the luke warm reception. Thanks to Google's simple coding of their spam filter, I actually missed the post by Niall Douglas of 4th of April. When it was referenced later and after I dug it from the archives, I became encouraged by the fact that maybe I wasn't all wrong and somebody within the community was actually thinking along similar lines as me. Following this I'd decided to take on regression testing. I chose to first simply test boost-develop against VC14, just to see how it goes. Some good, some bad. Was easy to set up (git already included with VC14, all what I needed to do was install python, which I normally have, but I'm having a new laptop). The bad, space required 44GB (advertised as 5GB). Possibly .pdb files (debugger symbols) are filling up disk-space uselessly. Next bad, the process finished with the following lines: # Done writing "C:\boost_develop\results\degski.xml". # Compressing "C:\boost_develop\results\degski.xml"... # Done writing "C:\boost_develop\results\degski.zip". # Uploading log archive "C:\boost_develop\results\degski.zip" to develop # <lambda> failed with message "[Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions" # Retrying (5 more attempts). # Uploading log archive "C:\boost_develop\results\degski.zip" to develop # <lambda> failed with message "[Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions" # Retrying (4 more attempts). # Uploading log archive "C:\boost_develop\results\degski.zip" to develop # <lambda> failed with message "[Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions" # Retrying (3 more attempts). # Uploading log archive "C:\boost_develop\results\degski.zip" to develop # <lambda> failed with message "[Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions" # Retrying (2 more attempts). # Uploading log archive "C:\boost_develop\results\degski.zip" to develop # <lambda> failed with message "[Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions" # Retrying (1 more attempts). # Uploading log archive "C:\boost_develop\results\degski.zip" to develop # <lambda> failed with message "[Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions" # Giving up. Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "C:\boost_develop\boost_regression_src\regression.py", line 287, in __init__ self.main() File "C:\boost_develop\boost_regression_src\regression.py", line 624, in main getattr(self,action_m)() File "C:\boost_develop\boost_regression_src\regression.py", line 591, in command_regression self.command_upload_logs() File "C:\boost_develop\boost_regression_src\regression.py", line 538, in command_upload_logs lambda: File "C:\boost_develop\boost_regression_src\regression.py", line 663, in retry return f() File "C:\boost_develop\boost_regression_src\regression.py", line 546, in <lambda> self.dart_server ) File "C:\boost_develop\boost_regression_src\collect_and_upload_logs.py", line 430, in upload_logs upload_to_ftp( tag, logs_archive, ftp_proxy, debug_level, ftp_url ) File "C:\boost_develop\boost_regression_src\collect_and_upload_logs.py", line 256, in upload_to_ftp ftp = ftplib.FTP( ftp_site ) File "C:\Python27\lib\ftplib.py", line 120, in __init__ self.connect(host) File "C:\Python27\lib\ftplib.py", line 135, in connect self.sock = socket.create_connection((self.host, self.port), self.timeout) File "C:\Python27\lib\socket.py", line 575, in create_connection raise err socket.error: [Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions I've re-checked this page <http://www.boost.org/development/running_regression_tests.html>again, there's no mention of "registering" or something similar. Some tests must have failed, got prompted for starting the debugger twice (is the latter normal). This was a test-run (testing the testing), with VC14U2. Assuming the above can get sorted, I would in reality like to test Clang/LLVM (with VC14U2). I would like to ask (Niall Douglas in particular, I guess) what the suggested parameters to run.py should be for this combo. Should I target clang.exe or clang-cl.exe, develop or master. What about Clang/C2? How to reduce disk-space usage? degski

5 7

proposed new library "histogram"
by Hans Dembinski 06 May '16

06 May '16

Hi everybody, I recently added a new library called "histogram" to the Boost Incubator. I would like to advertise it a little here in the hope to find a person interested in reviewing it. I hope that shameless self-advertisement is not going against some rule of this list, but I am sure you will let me know. My background is in analysis of big data in the fields of particle physics and astroparticle physics. Boost is very popular among my peers, since it is a free, high-quality, rich, and very well maintained collection of libraries. There is a growing number of tools to do statistical analysis in Boost and I think this project would fit in nicely, and fill a gap. We work with histograms a lot, so that's why my interest came from. I am a senior programmer in C++ and Python with 10 years of experience. Guiding development through code reviews and tickets, as well as taking on responsibility for continuous maintenance, are natural for me. Naturally, I am willing to commit free time to maintain the project should it be accepted, and do my share of the work in this community. I put a lot of thought and effort into this project, the rationale and my design choices are explained in the documentation, which I wrote according to the advice given at the Boost Incubator website. The project is feature complete from my side. What it needs now is the input from the Boost community to round off possible edges and to make the interface rich enough for everybody. I am good at considering the user perspective, but I cannot anticipate everyone's needs. In case you got interested, here are the links: Incubator link: http://rrsd.com/blincubator.com/bi_library/histogram-2/?gform_post_id=1582 github link: https://github.com/HDembinski/histogram Best regards, Hans

6 15

1.61 release notes
by John Maddock 06 May '16

06 May '16

Is it too late to add release notes? Forgetfully yours, John.

2 1

Boost.Proto: specializing context::eval classes
by Brook Milligan 06 May '16

06 May '16

I am trying to use Boost.Proto with some user-defined function terminals. Following the documentation, this requires specialization of context::eval classes to handle new terminals. (Using the callable_context<> mechanism is too simplistic because that seems to require a uniform result_type.) However, doing as suggested (see the "Defining an Evaluation Context" section) does not compile when function terminals are involved. My solution is a new traits class that deduces the type of a terminal. This does allow successful specialization of context::eval on the type of terminal, even with functions. To illustrate this, I have attached a set of three files, one implementing an example proto function, one implementing the relevant metafunction, and one demonstrating both use cases: the one corresponding to the Boost.Proto documentation and the one corresponding to my alternative. I would appreciate comments on the following: - Is this a valid problem and a valid solution or have I missed a standard method using Boost.Proto that works to solve this pattern? - Is this the standard way of creating function terminals in Boost.Proto or have I done something there to trigger the problem? - If the answer to these questions indicates a missing feature within Boost.Proto, what is the process for fixing that? Thanks for any help you can offer. Cheers, Brook

1 0

[random] Using random_device needs to link to built library
by Edward Diener 06 May '16

06 May '16

Evidently if I use boost::random::random_device class in code I need to link to the built random library. Otherwise the random library is header only. Shouldn't this be mentioned somewhere in the Boost random documentation ?

1 0

[generic programming] header file for general "default" operations for C++ classes
by Walt Karas 05 May '16

05 May '16

In C++, a default assignment operator is generated for a class if all of its components (data members and base classes) have an assignment operator. There are plans in C++17 to do something similar for comparison operators. This header, in https://github.com/wkaras/C-plus-plus-library-default-operators , facilitates that, more generally, if there is an operation on all the components of a class, a single macro invocation can provide this operation on the class as well. A big drawback is that it's very intrusive into the class definition. Each class component must be defined using a macro, COMPOSITE_OP_MBR_T(int) i; for examle. The class will in truth be a template, with the template parameter being defaulted for normal usage. I don't know which, if any, existing Boot library this header would belong in.

3 4

[Promotional] ghournal - a commandline based blog engine for gh-pages
by Ganesh Prasad 05 May '16

05 May '16

***DISCLAIMER*** *This is a self promotional message and quite unrelated to Boost and C++. But I believe, it's something that makes lives of developers easier, in fact I built it to make my life easier. Now, as an OpenSource activity it needs some promotion to attract users and contributors alike. * *Also, I am not good at writing promotional messages, so this mail might look really messy. Hence, apologies in advance.* *********************************************************************************************** git is the lifeline of most of the OpenSource activities around the globe. We all write code, create projects on github and push our changes to the repo and blah blah blah... That's what we all do, git add | commit | merge | push are probably the most used commands on a developer's console, the command pattern is muscle memory. Now with the introduction of github-pages it has been possible to host static websites for your projects on github, most of the serious projects on github already have their static websites there. Sometimes we want to maintain blogs for our projects on the project website. But github-pages being a static platform does not provide backend scripting or database capabilities. So, conventional blogging (like on blogger/wordpress) is not natively possible on github-pages. Sometimes we wish that blogging was possible and conveniently easy to use on github-pages. Also, some of us (like me for instance) sometimes think like, "life would have been easier if blogging was as simple as git init..git commit...git push, maybe something like blog init... blog new... blog publish". *ghournal <https://www.npmjs.com/package/ghournal>* as a tool designed for users of git, makes these above wishes come true. It is a command line based blog management tool for static web hosts, targeted primarily towards the github-pages platform. *ghournal <https://www.npmjs.com/package/ghournal> *exposes a git like command structure for blogging from the terminal. Creating a blog is as easy as 'ghournal init', adding a new post is as simple as 'ghournal new <postID>' etc. The complete command structure is documented in the project README. *ghournal <https://www.npmjs.com/package/ghournal>* is written in javascript and is available on npm. Hence installing and using it can not me easier. In short, it is designed to make the lives of developers who want to blog about their projects easier. So, if this sounds cool, please have a look at https://www.npmjs.com/package/ghournal and thanks :) sincerely Ganesh Prasad

1 0

[config] Checking if put_time is in iomanip
by Edward Diener 04 May '16

04 May '16

Does anybody know of a way to check if the std::put_time functionality is part of iomanip ? It is supposed to be a part of C++11, but Boost.Config does not have any general way to check for C++11 that I know about. Nor do I find anything in SD-6 which would tell me if std::put_time is supported.

1 0

[chrono] Header only library build and boost::system dependency
by Edward Diener 04 May '16

04 May '16

The documentation for chrono says: "How to Build Boost.Chrono as a Header Only Library? When BOOST_CHRONO_HEADER_ONLY is defined the lib is header-only. If in addition BOOST_USE_WINDOWS_H is defined <windows.h> is included, otherwise files in boost/detail/win are used to reduce the impact of including <windows.h>. However, you will either need to define BOOST_CHRONO_DONT_PROVIDE_HYBRID_ERROR_HANDLING or link with Boost.System. " So I have: #define BOOST_CHRONO_HEADER_ONLY #define BOOST_CHRONO_DONT_PROVIDE_HYBRID_ERROR_HANDLING #include <boost/chrono.hpp> followed by some code using chrono, and I still get when linking my exe: gcc.link C:\Programming\VersionControl\modular-boost\build\boost\bin.v2\libs\cxx_dual\test\test_chrono.test\gcc-mingw-5.3\debug\test_chrono.exe C:\Programming\VersionControl\modular-boost\build\boost\bin.v2\libs\cxx_dual\test\test_chrono.test\gcc-mingw-5.3\debug\test_chrono.o: In function `_static_initialization_and_destruction_0': E:\Programming\VersionControl\modular-boost\libs\cxx_dual\test/../../../boost/system/error_code.hpp:221: undefined reference to `boost::system::generic_category()' E:\Programming\VersionControl\modular-boost\libs\cxx_dual\test/../../../boost/system/error_code.hpp:222: undefined reference to `boost::system::generic_category()' E:\Programming\VersionControl\modular-boost\libs\cxx_dual\test/../../../boost/system/error_code.hpp:223: undefined reference to `boost::system::system_category()' collect2.exe: error: ld returned 1 exit status Is there a way to use chrono without having to link boost::system ?

3 5

Naming convention of iterated binary operation
by Jeremy Murphy 03 May '16

03 May '16

Dear list entities, is there such a convention or precedent for naming an iterated binary operation? For example, Boost.Functional/Hash has an iterated hash() called hash_range(). I don't mind the "_range" suffix but I prefer the "iterated_" prefix based on the mathematical definition: https://en.wikipedia.org/wiki/Iterated_binary_operation The case in point is gcd() in Boost.Math: we want to provide an iterated gcd but we can't quite decide how to name it. I like the "iterated_" prefix but I would rather go with whatever might be the convention. Thanks, cheers. Jeremy

3 6

[predef] check and require logical operators and multiple expression questions
by Edward Diener 01 May '16

01 May '16

Is there any difference in the result when you use the 'and' logical operator or simplty specify more than one expression: lib my_special_lib : source.cpp : [ predef-require "BOOST_OS_WINDOWS" and "BOOST_COMP_CLANG"] ; lib my_special_lib : source.cpp : [ predef-require "BOOST_OS_WINDOWS" "BOOST_COMP_CLANG"] ; Are both the above equivalent ? Can I use both 'and' and 'or' in an expression ? If so does 'and' bind before 'or' does, so that 'expression1 and expression2 or expression3' is conceptually '(expression1 and expression2) or expression3' ? Can I use parentheses to bind an expression with 'and' and 'or' ?

1 0

boost chrono bad_cast (gcc > 4.9 on Mac)
by Min Yang Jung 01 May '16

01 May '16

Hi All, I was wondering if Boost.Chrono works with gcc > 4.9 on Mac. When system_clock::now() is called, it throws an std::bad_cast exception. The binary from the same code doesn’t have the issue if compiled with clang on Mac and gcc > 4.9 on Linux. The gcc compilers that I use are macport-installed gcc 4.9 and 5.0 (g++-mp-4.9 and g++-mp-5.0) on Mac. Any help would be appreciated. Thanks. Regards, Min Yang Jung

3 2