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

Clang, -pedantic, and variadic macro warnings
by Edward Diener 06 Aug '14

06 Aug '14

My test show that if you compile with clang, pass the '-pedantic' option, and also pass 'std=c++0x' or 'std=c++11', that the many warnings about variadic macro use do not show in the output. I know there was a discussion and an assertion that the warnings do show in the output oonce '-pedantic' is passed as a compiler option even though a 'std=xxx' is passed that covers variadic macros, but I am not seeing that in my tests. If anybody else can tell me of a Boost library build where clang is the compiler, 'pedantic' is passed, and the appropriate 'std=xxx' to cover variadic macro use is passed, and the clang compiler warnings about using variadic macros show up, it would be appreciated.

1 0

[python] Building and Testing needs to be updated for modular-boost
by Edward Diener 05 Aug '14

05 Aug '14

Attempting to follow the building and testing explanation for Boost.Python in modular-boost, it appears it no longer works with the new structure of modular-boost and Boost Build. Staring with the 3.1 Basic Procedure section I invoke in the libs/python/example/quickstart/ directory the command: > b2 toolset=gcc-4.8.1 --verbose-test test only to receive: > Unable to load Boost.Build: could not find build system. > --------------------------------------------------------- > C:\Programming\VersionControl\modular-boost\libs\python\example\quickstart\boost-build.jam attempted to load the build system by invoking > > 'boost-build ../../../../tools/build/v2 ;' > > but we were unable to find "bootstrap.jam" in the specified directory > or in BOOST_BUILD_PATH (searching C:\Programming\VersionControl\modular-boost\libs\python\example\quickstart\../../../../tools/build/v2). > > Please consult the documentation at 'http://www.boost.org'. I do not know who is taking care of Boost Python now but it appears that it needs to be updated for modular-boost.

2 8

Files in Github
by Axel Ismirlian 05 Aug '14

05 Aug '14

Which subrepository do the files under /home/boost/boost belong to? More specifically, I made a change to /home/boost/boost/date_time/time_resolution_traits.hpp and I am looking to push it upstream, but I cannot find who this file belongs to. Sincerely, -Axel

4 3

[filesystem] develop broken after current merge
by Jürgen Hunold 05 Aug '14

05 Aug '14

Hi Beman, the last merge broke Boost.FileSystem on Linux using gcc(-4.8) and clang(-3.6) in c++11 mode. Diagnosic: include/boost/filesystem/path_traits.hpp contains #ifndef BOOST_NO_CXX11_CHAR16_T inline void convert(const char16* from, const char16* from_end, This should most probably be "char16_t" for C++11. The same for "char32" which should be "char32_t". This affects several other files. This one I could patch myself. But then I encountered: BOOST_ROOT/boost/filesystem/path_traits.hpp:131:13: error: ‘interop’ does not name a type typedef interop::conversion_iterator<interop::narrow, interop::utf16, const char16*> I can't find a definition of "interop" anywhere in the current repository... If you need more diagnostics, please ping me. 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

2 1

Is there any interest in a dependency injection library?
by Krzysztof Jusiak 05 Aug '14

05 Aug '14

Hi, Is there any interest in a C++03/C++11/C++14 header only, type safe, library providing compile time, macro free *constructor dependency injection <http://en.wikipedia.org/wiki/Dependency_injection>*? *Key features:* * *Compile time *- no exceptions - if application compiles all dependencies will be be created accurately * *Macro free* - by default no need to specify constructor traits or register anything (less intrusive) * *Scopes deduction* - scopes are deduced based on type semantic * *Automatic conversion* between std/boost smart pointers * *Compile time policies* - example to detect circular dependencies or limit supported types only to specified *Hello World* ----------------------------------------------------------------------------------------------------------> #include <memory> #include <boost/shared_ptr.hpp> *#include <boost/di.hpp>* *namespace di = boost::di;* struct interface { virtual ~interface() { } }; struct implementation : interface { }; class hello_world { public: hello_world(std::unique_ptr<interface> up , const std::shared_ptr<interface>& sp1 , boost::shared_ptr<interface> sp2 , int i) : i(i) { assert(dynamic_cast<implementation*>(up.get())); assert(dynamic_cast<implementation*>(sp1.get())); assert(dynamic_cast<implementation*>(sp2.get())); assert(sp1.get() == sp2.get()); assert(i == 0); } int run() { return i; } private: int i = 0; }; int main() { // create injector and configure bindings auto injector = *di::make_injector*( *di::bind*<interface, implementation>() // scope will be deduced ); // create and run hello_world return injector.*create*<hello_world>().run(); } <---------------------------------------------------------------------------------------------------------- *Overview*: * boost library incubator: http://rrsd.com/blincubator.com/bi_library/di-dependency-injection-2 * repository: https://github.com/krzysztof-jusiak/di * documentation: http://krzysztof-jusiak.github.io/di/boost/libs/di/doc/html * issues: https://github.com/krzysztof-jusiak/di/issues * download: https://github.com/krzysztof-jusiak/di/archive/master.zip *Supported Compilers* - 100% test coverage: * Linux (x86/x86-64) * Clang 3.2/3.3/3.4/3.4.2+ (clean with Clang Static Analyzer and Valgrind) * GCC 4.7.3/4.8.2/4.9.0+ (clean with Valgrind) * Intel C++ 14.0.3+ (clean with Valgrind) * Windows (x86/x86-64) * MinGW 4.7.3/4.8.2+ * Visual Studio 2013+ (clean with DrMemory) * Darwin/Mac OS (x86-64) * Clang 503.0.40+ (Apple LLVM version 5.1) *Continuous integration*: * Linux, Darwin/Mac OS: https://travis-ci.org/krzysztof-jusiak/di * Windows: https://ci.appveyor.com/project/krzysztof-jusiak/di * Coverage: https://coveralls.io/r/krzysztof-jusiak/di *Similar libraries*: * https://bitbucket.org/cheez/dicpp * https://code.google.com/p/infectorpp * https://github.com/phs/sauce * https://code.google.com/p/wallaroo * https://code.google.com/p/hypodermic * https://github.com/admiyo/CppInject * http://qtioccontainer.sourceforge.net * https://code.google.com/p/autumnframework * http://sourceforge.net/projects/cpp-resolver (proposal for boost library in 2009: http://lists.boost.org/Archives/boost/2009/10/157477.php) * https://code.google.com/p/pococapsule * https://code.google.com/p/spring-cpp * http://www.cs.utah.edu/~arichard/inject.html * http://bobah.net/d4d/source-code/misc/cpp-dependency-injection * https://code.google.com/p/ffead-cpp * http://codebros.github.io/DiLite * https://code.google.com/p/kindi Java: https://github.com/google/guice C#: http://www.ninject.org/ Source code was internally reviewed. DI was successfully used in a commercial project as well. Looking forward to hear from you. Any feedback is more than welcome. Best regards, Kris

3 13

[1.56.0] Release Candidate 2 available
by Eric Niebler 05 Aug '14

05 Aug '14

We've created a second release candidate to fix a few issues. The three fixes since RC1 are listed at the end of this mail. The files for 1.56.0 RC2 are available at: http://boost.cowic.de/rc/ 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 files (and associated md5s) are: MD5 (boost_1_56_0_rc2.7z) = 2e1688886aede1c3348e131a0e73a031 MD5 (boost_1_56_0_rc2.tar.bz2) = 2079fabbfb9fb046e6e12e381eff20fa MD5 (boost_1_56_0_rc2.tar.gz) = 96fe9c5f70759399217dc7ee113ecdd3 MD5 (boost_1_56_0_rc2.zip) = df42b60e120841fc3893de7c2529fc4a Thanks! -- The release managers === Changes Since RC1 === Boost.Thread bug is causing coroutine build to fail on gcc 4.6 in C++11 mode. https://github.com/boostorg/thread/pull/21 Boost.Graph broken on MSVC-12 and gcc-4.4. https://github.com/boostorg/graph/pull/14 Boost.System broken on cygwin, local_free_on_destruction not defined. https://github.com/boostorg/system/pull/4

9 12

Re: [boost] [1.56.0] Release Candidate 2 available
by Glen Fernandes 04 Aug '14

04 Aug '14

> We've created a second release candidate to fix a few issues. The three > fixes since RC1 are listed at the end of this mail. > > The files for 1.56.0 RC2 are available at: > http://boost.cowic.de/rc/ Builds successfully on: 1. OSX 10.9.4, x64, clang 3.4 (C++03, C++11) 2. Ubuntu 14.04, x64, gcc 4.8.2, (C++03, C++11) Glen

1 0

Re: [boost] How to establish boost configurations for cross-compilers not currently covered?
by Dave Gomboc 04 Aug '14

04 Aug '14

> > The boost config manual > > does not explicitly address the case where one is attempting to > > determine the relative lack of C++98 compliance of a cross-compiler > > (e.g., for an embedded system) that is not already within Boost's > > supported set of compilers. > > [Christopher Kormanyos] > Dave, may I ask what cross compilers you are considering for > your investigations? I am not sure that I can say precisely which, but I feel safe enough saying that none of them are intended to run under Unix or Linux. Unfortunately, this means I can't directly use "configure" as per John Maddock's suggestion. Though, it is true that some of the compilers run under Windows, so perhaps I could install Cygwin to obtain ./configure capability... or, perhaps I could try running under Wine. For the others, who knows... > Although I can not answer your question directly, I am also > very interested in finding ways to adapt or extend Boost support > to embedded systems compilers --- even for small micros. I am > particularly interested in extending the range of Boost and C++ to > compilers from suppliers such as IAR systems, Green Hills, > and also selected GCC crosses. > > I am also sensing increased interest in the Boost and C++ > communities regarding compilers not running *nix, Win32. > There is, in my opinion, lots of work to do here --- especially > when plain "int" is 16-bits in width or if an STL is lacking, or etc. Int is 32 bits on most, if not all, of the platforms that I was considering when I wrote my email. That said, there appears to be a surprising amount of (hobbyist) retrocomputing activitly over the past few years. So, I don't doubt at all that there might be interest even where plain "int" is even just 8 bits! Dave P.S. I ordered your book recently, Chris, and am looking forward to reading it when it arrives.

2 1

[random] Contributing Well equidistributed long-period linear (WELL) implementation
by Sergiu Dotenco 04 Aug '14

04 Aug '14

Some time ago, I implemented the WELL family of PRNGs introduced in: Francois Panneton, Pierre L'Ecuyer and Makoto Matsumoto. "Improved Long-Period Generators Based on Linear Recurrences Modulo 2". ACM Transactions on Mathematical Software, 32 (1, March) 2006, pp. 1-16. WELL is supposed to provide better equidistribution and bit-mixing properties for equivalent period lengths compared to Mersenne twister. The WELL family of generators provide period lengths ranging from 2^512-1 to 2^44497-1. The implementation can be found at https://bitbucket.org/sergiu/random/src/tip/well.hpp?at=default. The code has to be boostified, which I'm willing to do if there's any interest.

2 4

Hana Typeclass
by Robert Ramey 04 Aug '14

04 Aug '14

I can't review the whole library. So I'm confining my observations to just a couple of aspects. My method is to review some section of the documentation. it looks like a critique of the documentation, but it's really observations on the underlying design of the library. In this post I'm addressing Typeclass. Typeclass "Conceptually, type classes are an artifice allowing humans to manipulate objects of heterogeneous types with well-defined semantics. OK They serve a purpose very similar to C++ concepts (which are not in yet) and to Haskell type classes, except they do not have language support" OK - But I would argue that C++ concepts do have library support. It may not be perfect, but it's good enough for government work. template <class T> struct Printable { private: T t; std::ostream os; public: BOOST_CONCEPT_USAGE(Printable) { os << t; } }; "Type classes in Boost.Hana are a library-level implementation of such type constraints allowing us to organize our generic programming." When I read this it seems to be identical to the definition of what Boost Concept Checking is. "Getting concrete" Here is where we start to have problems. Rather than the simple BCC example above, we've got something a lot more complex and hard to understand. the example struct Printable { BOOST_HANA_TYPECLASS(Printable); // This is valid, but it's probably not a good idea unless those are // strongly related to the type class. int foo; void bar() const { }; struct baz { }; }; Describes what not to do - but doesn't describe what one is supposed to do. "As you will see later with minimal complete definitions, it is often useful to put other related members in a type class; don't hesitate to do it when it makes sense." Upon reading this - we don't know enough to know that "related members" means and what it means to "make sense". "When I introduced type classes, I said they allowed us to bundle together related operations called methods. This is because type classes can be seen as defining some kind of public interface consisting of the operations that are valid with any object satisfying some constraints" which is the C++ concept - or my own "type constraint" "I also said that they made it possible to explicitly state that a type satisfies those constraints, and how it does so" I would phrase this differently: explicitly state what operations must be valid when applied to a given type in order to deem it as fulfilling the "type constraints" "From now on, I will refer to the set of all types satisfying the constraints of a type class T as the instances of T" A big problem as far as I'm concerned. In C++ we use the phrase "instance of type T" for an entirely different thing. I would use the phrase: a "Printable" type - in the case of the example above. When referring to a set of type constraints I would pick something like "modeling the type constraints T or modeling the Printable type". This is familiar language to us. "To associate methods to a type class, we create a layer of indirection through the instance member of the type class. For example, let's say we want to have a method named print in the Printable type class: …" The whole rest of this section goes into how to create a set of types modeling "Printable". OK - But why is this necessary at all? If one tries something like: template<class T> void f(T & x) { BOOST_CONCEPT_ASSERT((Printable<T>)); std::cout << x; } class x { }; f(x); // compile time error here the program will trap at compile time with an error inside of Printable indicating that f doesn't model Printable because the operation ostream << x isn't supported by x; That's what I need. With type class it looks like that is expected that there be a default implementation for f if x isn't printable. It's not at all clear what this default definition is supposed to do. Print default error message at runtime? or what? The documentation notes that the usage of a default would be rare. But if it were to be used - it conflicts with the original purpose if type constraints (or concepts or type classes, etc). It's still not clear to me what happens if I use your type class system and invoke f(x). Do I get a compile time error? - what kind? where does it point to? How does it help the user find his error? To me the "type class" of the Hana library is a muddled re-implemenation of the boost concept check library. Its much more complicated and subtle and not as well documented and doesn't add anything to BCC. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Typeclass-tp4665978.html Sent from the Boost - Dev mailing list archive at Nabble.com.

5 7