- Boost - lists.boost.org

[type_traits] Should namespace boost::align be namespace boost::detail::align?
by Glen Fernandes 18 Feb '14

18 Feb '14

I was working on a tiny library, Boost.Align, which would provide (among other things) a boost::align (that would be std::align if BOOST_NO_CXX11_STD_ALIGN is not defined, or a reasonably non-portable implementation otherwise) and found that type_with_alignment.hpp uses the identifier 'align' for a namespace within namespace 'boost'. Was this namespace intended to not be within boost::detail? If it can be, I'll send a pull request; if not, I'll choose a different identifier over 'align'. Glen

2 3

Release script module
by Daniel James 18 Feb '14

18 Feb '14

Now that we have a separate module the release scripts we should remove them from the super project. I'll do that if there are no objections. Do we want to keep it as a submodule, or just completely separate? A lot of the scripts seem to be subversion specific, so can they just be deleted?

4 5

[trac] Resolving tickets
by Ahmed Charles 18 Feb '14

18 Feb '14

https://svn.boost.org/trac/boost/ticket/9415 I've never used trac before and I'm trying to resolve this ticket, but I don't think I can. Do I need a 'trac id' to be able to resolve tickets? Or am I simply missing something?

2 1

Re: [boost] Just another GSoC project idea: Create a Bjam clone based on the Boost libraries
by Brian Wood 17 Feb '14

17 Feb '14

Niall Douglas writes: > (My only request is that if you do do this, please stick a great big > auto-generated warning on the top of every bjam file output. I've got > nobbled by my build script changes getting eaten too many times in my > life!) I'm not sure. I generate both headers and source files. Currently in the headers, I have such a warning. But all of the generated files have a "zz." prefix. I could either put the big warning also in the source files or remove it from the header files. It seems to me that the naming convention might be enough of a warning. Also, I've liked the prefix since it groups the generated code together. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

[Boost] [Config] Macros for the absence of a full C++11 <memory> implementation
by Glen Fernandes 17 Feb '14

17 Feb '14

Macros to determine the availability of C++11 functions in <memory> like std::align would be useful to me. (I know that declaration begs the inquiry "What conforming code would you write if std::align is not present?" but that is separate e-mail...) Would a BOOST_NO_CXX11_HDR_MEMORY be generally useful? Glen

5 13

[graph] named_graph
by Jan Hudec 17 Feb '14

17 Feb '14

Hello, Looking for a way to add index of vertices by some id to adjacency_list graph I notices it derives from maybe_named_graph that should support this. However I didn't find any example nor really usable description of how to use it (I'd need to define boost::graph::internal_vertex_name, but I don't know what the typedef is supposed to be). Is there any code that uses this, anywhere? -- - Jan Hudec <bulb(a)ucw.cz>

1 0

[sync] Included file not found
by Edward Diener 17 Feb '14

17 Feb '14

When I build boost libraries from the top with the latest modular-boost master with MingW/gcc-4.8.1 on Window I get thi error in sync: In file included from libs\sync\src\tss_windows_pe.cpp:9:0: ./boost/sync/detail/config.hpp:32:42: fatal error: boost/detail/winapi/config.hp p: No such file or directory #include <boost/detail/winapi/config.hpp> ^ I do not see this file anywhere. What is the issue and can this be corrected ?

5 8

[thread] Errors when building wave
by Edward Diener 17 Feb '14

17 Feb '14

When building the Wave tool on the 'master' branch with gcc-4.8.1/MingW on Windows I am seeing these errors" ..\..\..\..\libs\thread\src\win32\thread.cpp: In static member function 'static unsigned int boost::thread::physical_concurrency()': ..\..\..\..\libs\thread\src\win32\thread.cpp:425:51: error: 'GetLogicalProcessor Information' was not declared in this scope GetLogicalProcessorInformation(NULL, &size); ^ ..\..\..\..\libs\thread\src\win32\thread.cpp:429:21: error: 'SYSTEM_LOGICAL_PROC ESSOR_INFORMATION' was not declared in this scope std::vector<SYSTEM_LOGICAL_PROCESSOR_INFORMATION> buffer(size); ^ ..\..\..\..\libs\thread\src\win32\thread.cpp:429:57: error: template argument 1 is invalid std::vector<SYSTEM_LOGICAL_PROCESSOR_INFORMATION> buffer(size); ^ ..\..\..\..\libs\thread\src\win32\thread.cpp:429:57: error: template argument 2 is invalid ..\..\..\..\libs\thread\src\win32\thread.cpp:429:65: error: invalid type in decl aration before '(' token std::vector<SYSTEM_LOGICAL_PROCESSOR_INFORMATION> buffer(size); ^ ..\..\..\..\libs\thread\src\win32\thread.cpp:430:52: error: request for member ' front' in 'buffer', which is of non-class type 'int' if (GetLogicalProcessorInformation(&buffer.front(), &size) == FALSE) ^ ..\..\..\..\libs\thread\src\win32\thread.cpp:436:25: error: invalid types 'int[s ize_t {aka unsigned int}]' for array subscript if (buffer[i].Relationship == RelationProcessorCore) ^ ..\..\..\..\libs\thread\src\win32\thread.cpp:436:43: error: 'RelationProcessorCo re' was not declared in this scope if (buffer[i].Relationship == RelationProcessorCore) ^ Does anybody know what I have to do to get this working ?

2 2

Just another GSoC project idea: Create a Bjam clone based on the Boost libraries
by Boris Schäling 17 Feb '14

17 Feb '14

Create a Bjam clone based on the Boost libraries 1. Write a parser for the most important rules (exe, lib and so on) based on Boost.Spirit 2. Use the parser's actions to create a dependency tree based on Boost.Graph 3. Attach Python functions to the nodes in the dependency tree based on Boost.Python 4. Implement Python functions for one toolset (like g++) The project promises a lot of variety as different Boost libraries have to be used. It's also an opportunity to get familiar with various Boost libraries. As it can be broken down into tasks it shouldn't be that difficult to make a realistic plan for a summer project. If there is anyone interested have a look at <https://github.com/boostcon/2011_presentations/raw/master/mon/Boost.Build.p…> and <http://www.highscore.de/cpp/boostbuild/> for more information about the build system. And of course the idea is not to create a fully featured Bjam clone in a few months. If there is a binary at the end of the project which can build a software based on a simple Jamfile the project is a success. It's more important to have all the required components in place even if they are far from complete (but once they are in place it shouldn't be too difficult to extend them later and add support for another rule for example). Boris

12 19

[container] Experimental support for memory expansion in vector and burst allocation in node containers
by Ion Gaztañaga 16 Feb '14

16 Feb '14

Hi to all, Some years later than I expected, I've committed to the master branch (after regression tests in develop were ok) a new feature for Boost.Container: new experimental allocators that support memory expansion and burst allocation in order to improve insertion and erasure times in most containers. The interface of these allocators is a variation of the interface I proposed in N2045. The interface is still experimental and not ready to be used by other containers as it's quite complex to handle and I think it can be further improved. Nevertheless, Boost.Container users can benefit from improved performance just using these allocators. The first experiment using this approach can be found in my old article "Applying classic memory allocation strategies to C++ containers" (http://www.drivehq.com/web/igaztanaga/allocplus/) In that article, Boost.Interprocess containers were modified to support N2045 and DLMalloc was version 2.8.3. In the new version the extended system allocator is based on DLMalloc version 2.8.6 (I've noticed a performance improvement in DLMalloc in the new version) and requires linking a new Boost.Container library. Boost.Container is still header-only if extended allocators are not used. DLMalloc is known to be size and speed efficient for non heavily multithreaded environments, but Boost.Container DLMalloc extension is *not* a replacement for multithreaded allocators (say ptmalloc2, ptmalloc3, nedmalloc, tcmalloc, jemalloc...). Your default system allocator will be more efficient than Boost.Container for highly multithreaded environments. On the other hand, at least in Windows and Linux, the allocator seems to be very efficient in non-multithreaded programs. The following extended allocators are provided: * boost::container::allocator: This extended allocator offers expansion, shrink-in place and burst allocation capabilities implemented as a thin wrapper around the modified DLMalloc. It can be used with all containers and it should be the default choice when the programmer wants to use extended allocator capabilities. * boost::container::node_allocator: It's a Simple Segregated Storage allocator, similar to Boost.Pool that takes advantage of the modified DLMalloc burst interface. It does not return memory to the DLMalloc allocator (and thus, to the system), unless explicitly requested. It does offer a very small memory overhead so it's suitable for node containers that allocate very small value_types and it offers improved node allocation times for single node allocations with respect to boost::container::allocator. * boost::container::adaptive_pool: It's a low-overhead node allocator that can return memory to the system. The overhead can be very low (< 5% for small nodes) and it's nearly as fast as boost::container::node_allocator. It's also suitable for node containers. More details on the implementation of this allocator can be found in http://www.drivehq.com/web/igaztanaga/allocplus/#Chapter3. The goal of these extended allocators in Boost.Container is to start building widespread existing practice in regularly requested features from container users (realloc-like behaviour in vector, amortizing several node allocation in range insertions, etc...). I'm not an allocator expert, nor a HPC guru. These new allocators are just the first step of an experiment that I hope real experts will improve. I will appreciate any comment, bug report or suggestion. Thanks, Ion

1 0