March 2014 - Boost - lists.preview.boost.org

Re: [boost] testing potential GSOC students
by Ganesh Prasad 08 Mar '14

08 Mar '14

( (c) TM (R) Will Smith) --> (The man in BLACK ) ... The actor one ??? I love that guy. Not sure if I would go competitive against him. :D

1 0

Re: [boost] testing potential GSOC students
by Ganesh Prasad 07 Mar '14

07 Mar '14

As this year the main focus of UBLAS will be compile time optimizations, and I wish to submit a proposal for this project, I would like to show the compile time library Gns::META_LISCPP , written by me. In reference to *Boost Digest, Vol 4288, Issue 3, Message :3 ,* I am sending this library by me for evaluation. Though I have not implemented a minimal Vector library over it yet , still it demonstrates, I optimally guess, my understandings of the generic meta programming paradigm. And I guess, I might come up with some vector processing features for it soon. Here is the github url to the repository : *https://github.com/GnsP/GNS--META_LISCPP/ <https://github.com/GnsP/GNS--META_LISCPP/>* Looking forward to your responses. Best Wishes Ganesh Prasad

3 2

Re: [boost] [Re] [Re] JSON Parsing Library for GSoC 14
by Sebastian Theophil 07 Mar '14

07 Mar '14

There are many libraries that parse JSON to maps and vectors. IIRC Microsoft’s REST SDK includes a JSON library as well (http://casablanca.codeplex.com) There are at least 15 other C++ libraries like that and we don’t need to write another one. But there are only two libraries AFAIK that parse JSON to C++ structs using serialization adaptors: - https://github.com/Loki-Astari/ThorsSerializer - http://fossil.wanderinghorse.net/repos/nosjob/index.cgi/index I consider the ability to read and write C++ structs essential for any library admitted to boost. Shouldn't such a library be an extension to boost.serialization? Boost.Serialization already defines a way for each data structure to define which data should be written/read. The Boost.Serialization docs say that the library even offers methods & macros to output a class member together with its member variable name as a name value pair. Exactly what a JSON library would need. There has been a discussion about last year’s GSoC mentioning further desirable properties of a JSON library: http://boost.2283326.n4.nabble.com/JSON-Parser-GSoC-2013-td4645117.html Regards Sebastian -- Dr. Sebastian Theophil | stheophil(a)think-cell.com Senior Software Engineer We are looking for C++ Developers: http://www.think-cell.com/career think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schödl

3 4

[GSoC] pipelines questions
by Thaler Benedek 06 Mar '14

06 Mar '14

Hi, I'm interested in the Boost.Pipelines proposal of GSoC 2014. [0] I'd like to ask the stakeholder (Vicente J. Botet Escriba ?) the following: * Is this supposed to be built from scratch or rather to be some kind of improvement over the already existing google implementation? [1] * If the former is true, should be n3534 [2] considered as a strict requirement or as a vague suggestion? * If the later is true, which features should be the main distinctive ones? I think about things like using Boost libraries (e.g: Boost.Atomic) instead of custom solutions, cross platform support, comply to Boost coding standard, etc. Are there any areas of improvement identified in the reference implementation? * I understand it might take quite a long time for a proposal to make it to Boost, therefore it's not a requirement. Is there any objective milestone that a successful project should reach anyway? Thanks, Benedek [0]: https://svn.boost.org/trac/boost/wiki/SoC2014#Boost.Pipelines [1]: https://code.google.com/p/google-concurrency-library/source/browse/include/… [2]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3534.html#Proposal

3 4

[uuid] sequential_generator / comb_generator / utc_generator / timestamp_generator
by Adam Walling 06 Mar '14

06 Mar '14

For personal use, I've created a few generators that create sequential and time-based uuids. However there does not seem to be a single standard for these kinds of algorithms. While tidying up this code, I've run into some obstacles with generalization of the logic. Although some applications like SQL Server will use GUIDs and lexicographically compare based on the least significant bytes of Data4 for boost::uuids' purposes we can simply assume a block of 16 bytes. The generic approach is to combine (basic_comb_generator) a number of bytes from a sequential source, filling the rest of the bytes with random data. What concerns me is the choice of source and the number of bytes to use. And additionally the value which specifies the variant / version. The usual choices seem to be 8 or 6 bytes. The source is also usually UTC Unix time. However the original uuid version used nanosecond intervals and the MAC address. Am I worrying too much about extensibility? As it is now my basic_comb_generator has a template param for a source, a number of bytes of the source to use, and a UniformRandomNumberGenerator to fill the rest. Since resolution may be a second if using Unix time they may not be consistently sequential but generally so, hence my hesitation to name the generator typedef as sequential. Of course it is possible to use even higher resolution. I suppose I am gauging interest in this feature, as well as asking if there are any thoughts or suggestions on how others would likely use this, and alternative or standard algorithms defined. Once I have some feedback I intend to complete the code and bounce it back on here for any further comments before lobbying to include anything within the library. It seems like commonly needed functionality at least! Nilsson article here for SQL Server: http://www.informit.com/articles/article.aspx?p=25862&seqNum=7 CouchDB's uuid generation algorithms: https://wiki.apache.org/couchdb/HttpGetUuids

2 1

[signals2] Test failure in C++11 (trivial fix for incorrect usage of boost::optional)
by Ben Pope 06 Mar '14

06 Mar '14

I have the following errors: "clang++-3.4" -c -x c++ -std=c++11 -stdlib=libc++ -O0 -g -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -I".." -o "/home/ben/development/boost/test/build/results/boost/bin.v2/libs/signals2/test/signal_test.test/clang-linux-3.4~c11_libc++/debug/link-static/signal_test.o" "../libs/signals2/test/signal_test.cpp" ../libs/signals2/test/signal_test.cpp:32:16: error: invalid operands to binary expression ('boost::optional<int>' and 'int') if(max == false) max = *first; ~~~ ^ ~~~~~ "clang++-3.4" -c -x c++ -std=c++11 -stdlib=libc++ -O0 -g -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -I".." -o "/home/ben/development/boost/test/build/results/boost/bin.v2/libs/signals2/test/track_test.test/clang-linux-3.4~c11_libc++/debug/link-static/track_test.o" "../libs/signals2/test/track_test.cpp" ../libs/signals2/test/track_test.cpp:36:14: error: invalid operands to binary expression ('boost::optional<int>' and 'int') if(max == false) Richard smith explains the problem here: http://llvm.org/bugs/show_bug.cgi?id=18180#4 "OK, I see what's happening -- in Clang 3.3 and GCC 4.8, 'false' is being treated as a null pointer constant. boost::optional implicitly converts to an "unspecified-bool-type" that happens to be a pointer-to-member type, and thus can be compared against a null pointer constant via the built-in operator!=(pointer-to-member, pointer-to-member) overload. In C++11 onwards, 'false' isn't a null pointer constant any more, so this comparison is no longer valid. Clang 3.3 and GCC 4.8 don't implement that rule; Clang 3.4 does." The trivial fix is to change the if statements at: ../libs/signals2/test/signal_test.cpp:32:16: ../libs/signals2/test/track_test.cpp:36:14: to if(!max) rather than if(max == false). Ben

7 19

[range][documentation] - best practice for generating documentation?
by Neil Groves 05 Mar '14

05 Mar '14

Hi, I'm currently the suitably ashamed owner of numerous documentation trac issues for Boost.Range. I would like to address these issues but I'm unclear about what our strategy is for generating documentation since our move to modular Boost. I anticipate that if I continue to commit the generated html as I had done previously that I will be in for a "world of pain" when it comes to merge to master. I've searched and found several pages about document best-practice but the pages contain references to the subversion repository which leads me to believe that this must be out-of-date. I'd like some advice to ensure that my commits are aligned with what is wanted. If there is a temporary workflow I can use that will not end in a merge disaster then I'd like to put small documentation fixes in quickly before major re-factoring of the documentation generation process. I apologise in advance if my search skills have been deficient. Sending a link accompanied with abuse is entirely acceptable! Thanks, Neil Groves

2 3

[offtopic] Wonders of C++ syntax
by Andrey Semashev 05 Mar '14

05 Mar '14

Maybe this experience will be interesting to someone... I'm currently trying to write a simple parser for function signatures for Boost.Log and collecting different curious use cases. The parser is supposed to extract the function name from the compiler-generated string with the signature (i.e. BOOST_CURRENT_FUNCTION). Now the interesting case I've stumbled upon is a conversion operator to a function pointer: namespace namespc { struct my_class2 { typedef char (*pfunc_t)(double); operator pfunc_t () const { std::cout << BOOST_CURRENT_FUNCTION << std::endl; return 0; } }; } I first tried to imagine how this could be written without the typedef, but my brain broke soon enough. Then I decided to ask the compiler, and naturally different compilers gave different answers. GCC nicely sidestepped the problem altogether: namespc::my_class2::operator pfunc_t() const MSVC was more creative: __cdecl namespc::my_class2::operator char (__cdecl *)(double)(__cdecl *(void) const)(double) Frankly, my brain can't parse this one either and it looks incorrect to me since the function pointer type is duplicated. So it seems, there's no syntax for expressing the operator without a typedef, is that right? In that case, I wonder what to do with MSVC output...

2 2

changelog for 1.56
by Oliver Kowalke 05 Mar '14

05 Mar '14

I tried to add comments to the change log of 1.56 - but I've no permission to push the commit. is feed/history/boost_1_56_0.qbk the correct place and can I get permission to push commits?

2 1

libcpp.hpp always defines BOOST_NO_CXX11_HDR_ATOMIC
by Peter Dimov 05 Mar '14

05 Mar '14

The libc++ config header, libcpp.hpp, always defines BOOST_NO_CXX11_HDR_ATOMIC, but the libc++ that - I presume - ships with "Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)" appears to have a functional <atomic>.

6 22