- Boost - lists.preview.boost.org

[block_ptr] 20% speed boost
by Phil Bouchard 17 Feb '16

17 Feb '16

> If I try out the latest modifications and I disable the threads then on > Linux I have: > > make: > auto_ptr: 2458626 ns > shared_ptr: 2685224 ns > block_ptr: 28300624 ns > > new: > auto_ptr: 2383605 ns > shared_ptr: 4992185 ns > block_ptr: 7979659 ns So I just added a specialization of the pool for GCC x86 and now block_ptr<> speeds up by 20%: make: auto_ptr: 2511658 ns shared_ptr: 2695469 ns block_ptr: 22547960 ns new: auto_ptr: 2369312 ns shared_ptr: 4991352 ns block_ptr: 6443925 ns Thanks, -Phil

1 2

[Fit] Purpose and Use Cases
by Artyom Beilis 17 Feb '16

17 Feb '16

Hello, Before the formal review begins I would really like to understand the purpose of Boost.FIT It isn't clear to me from the documentation what are the real world use cases? What can't be done today (for example composition) with simple C++11 lambdas? I'd love to see several real world examples and use cases of Boost.FIT - because at least for me I don't really understand why it is useful. Artyom

4 3

Re: [boost] [block_ptr] Request for a review manager
by Bjorn Reese 17 Feb '16

17 Feb '16

On 02/04/2016 03:02 AM, Phil Bouchard wrote: > On the other hand I code completed the deterministic block_ptr in 2011 > and I am wondering if there is anything I am missing to get it through > the review process because this is one of the most important subject in > computer science: > https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.… Do you have any performance measurements comparing block_ptr<T> with shared_ptr<T>? Btw, in the overview section you claim that shared_ptr<T> has to manage counters when it is dereferenced. I am not entirely sure that is correct.

3 7

Boost.Python gsoc project
by Barun Parruck 16 Feb '16

16 Feb '16

Hi! I'm a student looking to get involved with the open source through boost. I was looking through the gsoc projects, and the one involving Boost.python, by Stefan Seefeld piqued my interest! I was wondering what sort of student you'd be looking for for the project, more details about what the project would entail, and what sort of programming competency test I would have to pass.

2 1

stupid github question
by Robert Ramey 16 Feb '16

16 Feb '16

I want to add a contributer to the serialization library - but I can't figure out how to do this on github. I believe this has something to do with the fact that the serialization library is a sub project. It shouldn't be a big deal as I see there are already 31 contributors on the list - many of whom I don't recognise. Robert Ramey

2 3

Alternative remove, erase, and partition algorithms
by Brent Friedman 15 Feb '16

15 Feb '16

Hello, I'd like to propose the following for inclusion in Boost.Algorithm. *semistable_partition* partitions a range into 'good' and 'bad' elements, as partition. 'Good' elements maintain their order, while 'bad' elements are left in unspecified order. stable_partition has either linear additional storage or performs 3NlogN move operations, whereas semistable_partition has constant memory overhead and at most 3N move operations. Requires forward iterators. *unstable_remove ( _if )* removes elements from a range but without maintaining element order. Performs at most N/2 moves as compared to N for remove. Requires bidirectional iterators. *unstable_erase* erases an iterator or range from a container ( as vector::erase ) without maintaining element order. Intuitively, this fills in the hole created by the erase operation by moving elements from the end. Limited to containers with bidirectional iterators (possibly random-access). The following documents describe and explore these algorithms: https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/2uwOmXWqa2E (unstable_erase, unstable_remove) https://iterator.wordpress.com/2016/01/31/algorithms_0/ (unstable_remove, semistable_partition) I have been pursuing standardization, but it seems like there is value in getting community experience with these algorithms first in order to make for easier justification. -Brent Friedman

1 0

[block_ptr] Works on MSVC + Boost.Pool bug
by Phil Bouchard 15 Feb '16

15 Feb '16

It looks like I was able to fix a bug which makes it run correctly under MSVC 2015 Express. Although I do have a crash in the boost::pool: Project2.exe!boost::simple_segregated_storage<unsigned int>::try_malloc_n(void * & start, unsigned int n, unsigned int partition_size) Line 333 C++ Project2.exe!boost::simple_segregated_storage<unsigned int>::malloc_n(unsigned int n, unsigned int partition_size) Line 363 C++ Project2.exe!boost::pool<boost::default_user_allocator_new_delete>::ordered_malloc(unsigned int n) Line 801 C++ Project2.exe!boost::singleton_pool<boost::detail::bp::pool,1,boost::default_user_allocator_new_delete,boost::details::pool::null_mutex,32,0>::ordered_malloc(const unsigned int n) Line 149 C++ Project2.exe!boost::detail::bp::pool::allocate(unsigned int s) Line 148 C++ Project2.exe!boost::detail::bp::block<int>::operator new(unsigned int s) Line 283 C++ Project2.exe!boost::detail::bp::make_block<int,int>(const int & t0) Line 520 C++ > Project2.exe!main() Line 119 C++ When I try this example: https://github.com/philippeb8/block_ptr/blob/master/example/block_ptr_test2… Thanks, -Phil

1 1

Re: [boost] [block_ptr] Request for a review manager
by Peter Dimov 15 Feb '16

15 Feb '16

> Phil Bouchard wrote: > > > I added the new repository with the right folder structure: > > https://github.com/philippeb8/block_ptr > > You should update this to work with the latest Boost, because currently > block_base is abstract as it doesn't implement > > virtual void * get_untyped_deleter() = 0; It also doesn't work with -DBOOST_DISABLE_THREADS, which makes it inconvenient to test as it requires Boost.Thread.

3 7

[dll] dbghelp.hpp in detail/winapi
by Andrey Semashev 14 Feb '16

14 Feb '16

Hi, I've noticed that Boost.Dll provides boost/detail/winapi/dbghelp.hpp header. boost/detail/winapi is the directory of Boost.WinAPI submodule, and I generally don't expect anyone else putting his header in that directory. Could dbghelp.hpp be moved somewhere inside boost/dll?

3 5

Re: [boost] expected/result/etc
by Emil Dotchevski 13 Feb '16

13 Feb '16

On Wed, Jan 27, 2016 at 10:49 PM, Michael Marcin <mike.marcin(a)gmail.com> wrote: > So looking a few of these libraries/proposals I have a few things I'm > interested in. > > - Is it at least as good as a simple hand-rolled solution? > - Can you transport error codes through layers without knowing specifics > of an error? > > For the second Niall's outcome/result handles very well I think. > std::error_code and std::exception_ptr transport is good enough for almost > any reasonable type agnostic error transport. > Have you considered using Boost Exception? It lets you add arbitrary data to exception objects, even after they have been thrown, regardless of their type -- see http://www.boost.org/doc/libs/release/libs/exception/doc/error_info.html. The general idea is to adopt a strategy where the exception objects are augmented with any, even platform-specific relevant data, which then the catch site can analyze to choose the correct handling. Cheers, Emil

9 69

[type_traits] ICE with msvc-12.0
by Steven Watanabe 13 Feb '16

13 Feb '16

AMDG I'm getting boost\type_traits\common_type.hpp(43): fatal error C1001: An internal error has occurred in the compiler. (compiler file 'msc1.cpp', line 1325) To work around this problem, try simplifying or changing the program near the locations listed above. which makes this toolset basically unusable. Oddly enough, I don't see this error in the regression matrix. Does anyone know what's up with this? > cl Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x86 Copyright (C) Microsoft Corporation. All rights reserved. scratch.cpp: #include <boost/type_traits/common_type.hpp> int main() { boost::type_traits::common_type<int, char, long>::type x = 0; } > cd libs/type_traits > git log commit 1f3a3a1553dc316ed002354dce3ba3f081b2e102 Author: jzmaddock Date: Wed Jan 13 10:50:22 2016 +0000 Fixes for older GCC versions, see issue 11904. ... > dir boost ... 02/25/2015 08:26 PM <JUNCTION> type_traits [...\libs\type_traits\include\boost\type_traits] ... In Christ, Steven Watanabe

2 1

[regression] Winapi submodule tests missing
by Andrey Semashev 13 Feb '16

13 Feb '16

Hi, The winapi submodule tests are missing from the test matrix, although the status/Jamfile.v2 lists it. This is both on develop and master. Is there something I should do to make the tests appear?

2 5

Re: [boost] expected/result/etc
by Giovanni Piero Deretta 13 Feb '16

13 Feb '16

On 12 Feb 2016 11:20 a.m., "Niall Douglas" <s_sourceforge(a)nedprod.com> wrote: [...]. > > LLVM, for the record, has implemented a very similar "universal" > exception handling mechanism which allows exception throws to > traverse language boundaries within LLVM, and my great hope is that > once LLVM becomes universal on POSIX platforms someone will go ahead > and replace signals with structured exception handling. As far as I know LLVM simply implements unwinding as mandates by the Itanium ABI, which is already the de facto standard on many unices. Is this what you are referring to? This is completely orthogonal with handling OS/machine exceptions (segfaults, division by zero, etc..). And with right compiler and flag there are ways to convert (synchronous) signals to exceptions. This actually required to support the semantics of languages other than the C family, like Java and Ada. Notably, it doesn't actually work with LLVM, but it does with gcc. -- gpd

2 1

[filesystem] temp_directory_path and Android devices (repost)
by doodad-js Admin 12 Feb '16

12 Feb '16

(sorry for the repost, but someone told me that I should include "filesystem" in the subject) Hi, I have read the specs (http://www.boost.org/doc/libs/1_60_0/libs/filesystem/doc/reference.html#tem p_directory_path) and found the following issues with Android devices: - It should first try to get the application's cache directory from the API level 1 "getCacheDir" so that temporary files created by the application can be easily and automatically removed. - The function fails back to the hard coded value "/data/local/tmp". But I think it should use the environment variable "ANDROID_DATA" when available and append "/local/tmp" to it. - The "/data/local/tmp" folder is denied access on my Android device. I don't have any other suggestion than the application's cache folder like I first mentioned. I'm not a core developer and the information provided on this email maybe erroneous or incomplete. My apologies if I'm entirely wrong. Thanks, Claude Petit

1 0

Contribution to Boost as Developer
by aman kumar singh 11 Feb '16

11 Feb '16

Developers, I am Aman Kumar Singh,Senior Year,NIT Mizoram,India(Computer Science and Engineering).I am new to open source development. I like coding especially in C++.I have 6 years of working experience in C++.I am very much interested in contributing to open source development especially in Boost.I want to apply for Google Summer of Code 2016 in future.Can somebody help me out.I am ready to dedicate my full time to it once I get aware of the system fixing bugs and further contributing to big projects. I am left with very less time for GSoC and this time I want to be part of it.Please help me out. Thanking you, Aman Kumar Singh, NIT Mizoram, India

1 0

problem with ASIO
by Juan Dent 10 Feb '16

10 Feb '16

Thank you so much Bjorn Reese!! you solved my problem with ASIO. My instincts were correct in that the stream was destroying the std::cout. ::dup() solves this. Best regards, Juan

1 0

Re: [boost] Problem with ASIO
by Bjorn Reese 10 Feb '16

10 Feb '16

On 02/10/2016 02:27 AM, Juan Dent wrote: > posix::stream_descriptor stream{ioservice, STDOUT_FILENO}; Here you take over ownership of stdout, so it will be closed by the stream destructor. A quick fix is to pass a copy of the file descriptor with ::dup(STDOUT_FILENO) as shown in the posix_chat_client.cpp example.

1 0

temp_directory_path and Android devices
by doodad-js Admin 10 Feb '16

10 Feb '16

Hi, I have read the specs (http://www.boost.org/doc/libs/1_60_0/libs/filesystem/doc/reference.html#tem p_directory_path) and found the following issues with Android devices: - It should first try to get the application's cache directory from the API level 1 "getCacheDir" so that temporary files created by the application can be easily and automatically removed. - The function fails back to the hard coded value "/data/local/tmp". But I think it should use the environment variable "ANDROID_DATA" when available and append "/local/tmp" to it. - The "/data/local/tmp" folder is denied access on my Android device. I don't have any other suggestion than the application's cache folder like I first mentioned. I'm not a core developer and the information provided on this email maybe erroneous or incomplete. My apologies if I'm entirely wrong. Thanks, Claude Petit

1 0

[ANN] build2 - C++ build toolchain
by Boris Kolpackov 10 Feb '16

10 Feb '16

Hi, build2 is an open source, cross-platform toolchain for building and packaging C++ code. It includes a build system, package manager, and repository web interface. We've also started cppget.org, a public repository of open source C++ packages (where we hope to see Boost one day). This is the first alpha release and currently it is more of a technology preview rather than anything that is ready for production. We have tested this version on various Linux'es, Mac OS, and FreeBSD. There is no Windows support yet (but cross-compilation is supported). The project's page is: https://build2.org For those who need to see examples right away, here is the introduction: https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml Enjoy, Boris

9 19

Problem with ASIO
by Juan Dent 10 Feb '16

10 Feb '16

Hi, I have a problem with the following sample (ASIO 10, part of Boost examples): void f() { { io_service ioservice; posix::stream_descriptor stream{ioservice, STDOUT_FILENO}; auto handler = [](const boost::system::error_code&, std::size_t) { std::cout << ", world!\n"; }; async_write(stream, buffer("Hello"), handler); ioservice.run(); std::cout << "hhh\n"; } // in this line and afterwards, no output will be seen through std::out!! ( it is somehow damaged or destroyed by the destructor of the *stream* object!! std::cout << “This will not print\n"; } As explained in the line comment, when stream is destroyed some permanent damage is done to the std::out object which will not output any more after executing the code in the nested block. I believe the stream should be somehow disconnected from STDOUT_FILENO before its destruction so it does not “harm” std::out. Any ideas? Thanks!! Juan

1 0

[block_ptr] Request for a review manager
by Phil Bouchard 09 Feb '16

09 Feb '16

Greetings, As some of you might know I work full time on WebKit which in turn uses a garbage collector for its Javascript interface and quite honestly a garbage collector is not ready for a commercial release unless you have a lot of CPU juice. So a garbage collector is unacceptable. On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.… Please let me know if you are interested for me to present it and answer questions live. Sincerely, -Phil www.unifiedfieldtheoryfinite.com

6 17

recompile with -fPIC
by Marwa Refaie 09 Feb '16

09 Feb '16

Hi I try to compile "cdec" translation package , I been stuck in this error : ______________________________________________________________________________ /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libboost_system.a(error_code.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libboost_system.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status error: command 'g++' failed with exit status 1______________________________________________________________________________ I red solution like bjam boost without debug or specifiy -fPIC !!! Any help to apply any solution ?? How should I fix plz ?? Marwa N. Refaie

1 0

[smart_ptr] Interest in the missing smart pointer (that can target the stack)
by Noah 09 Feb '16

09 Feb '16

Hi all, I'm new here. Here goes: I propose a new smart pointer called, say "registered_ptr", that behaves just like a native C++ pointer, except that its value is (automatically) set to null_ptr when the target object is destroyed. This kind of smart pointer already exists and is being used in the form of, for example, QPointer and Chromium's WeakPtr (http://doc.qt.io/qt-5/qpointer.html and https://code.google.com/p/chromium/codesearch/#chromium/src/base/memory/wea…) although those implementations only apply to a specific set of object types. There's also std::experimental::observer_ptr (http://en.cppreference.com/w/cpp/experimental/observer_ptr) which seems to be trying to serve a similar purpose, but with none of the functionality. This might be as far as you need to read to decide if you think it's a good idea or not. The rest of this (kind of long) post addresses some of the details and motivation. It's instructive to compare this "registered_ptr" with (std::)shared_ptr. Both have a (modest) performance cost, although registered_ptr's performance cost is significantly lower, as will be discussed later. Both can have a significant "code safety" benefit when used for that purpose - i.e. reduce or eliminate the possibility of invalid access of an object that has already been destroyed. And both have a functional purpose other than safety or convenience (or just being a regular pointer). That functional purpose is to deal with situations when it is not easy to predict in advance (i.e. at compile time) when an object will be referenced (and stop being referenced). shared_ptr deals with these type of situations by ensuring that the object remains "alive" for as long as there are any (owning) references to the object. This assumes that the object has no "curfew". But one can imagine situations where an object needs to be destroyed at or by a certain time or event. If the object is exclusively holding an in demand resource, or security lock for example. In these cases one might prefer that late attempted references to the object fail (safely) rather than have the object's destruction delayed. registered_ptrs might be more suitable for these situations. So from this comparison it's hard to argue for the inclusion of shared_ptr and the omission of registered_ptr in the library. registered_ptr can be thought of as a kind of "non-intrusive" counterpart to shared_ptr. "But wait", you say, "shared_ptr already has a non-intrusive counterpart. Namely weak_ptr." Yes, but the difference between weak_ptr and registered_ptr is that registered_ptr is independent, not just an appendage of shared_ptr. And registered_ptr can point to stack allocated objects (just like native C++ pointers can), but at the cost of "thread safety". Referencing an object on another (asynchronous) thread's stack is inherently not safe, right? Some may be concerned with this lack of thread safety - I am not, I don't think we should be encouraging casual asynchronous object sharing - but the performance dividend of getting to put the target object on the stack rather than the heap more than makes up for it in my opinion. So I've actually already had cause to implement, and use, a version of this "registered_ptr" (I actually called it "TRegisteredPointer"), and in practice it works great. But there are, arguably, a couple of issues. Besides the thread safety (non-)issue, my implementation can only target types that can act as base classes. By default most classes can act as a base class, but native types like int, bool, etc. cannot. In my case, this is not a big issue because TRegisteredPointer is actually part of a small library that includes (safer) substitutes for int, bool and size_t that can act as base classes. The good thing is that it does seem to serve its purpose of not only being safe, but also faster than shared_ptr. Much faster when targeting stack objects as one would expect, but also faster when targeting heap objects according to my simple benchmarks (msvc2013 - Windows 7 - Haswell). My implementation can be found here: https://github.com/duneroadrunner/SaferCPlusPlus. It's in the file called "mseregistered.h". Examples of it in action can be found in the file called "msetl_example.cpp", near the end. No decent documentation yet, but the examples are commented and it should be clear what's going on. So far I've posited that the argument for registered_ptr is at least as good as the argument for shared_ptr. But let me make a further argument for why I think it's particularly important to include registered_ptr. First, let me make an argument for "safe" pointers in general. By safe pointers, I mean pointers that have zero chance of participating in a dereference to invalid memory. This will usually imply that the safe pointer will do a runtime check and throw an exception if an invalid dereference is attempted. Now, I subscribe to the C++ "trust the programmer" philosophy, so I agree that programers should have the option of avoiding these runtime checks. But security (and by extension, language safety) is so important these days that programmers should also have the option of having these runtime checks when desired. So I'm suggesting that all the smart pointers (shared_ptr, unique_ptr, etc.) come in "safe" versions as well. There is already some precedent for safe and unsafe options. For example, std::vector<> provides both the "unsafe" [] operator and the "safe" at() function. And ultimately it needs to be properly measured, but I would think that the performance cost of this kind of runtime check should be quite modest. There is plenty of opportunity for optimizing compilers to strip them out when not needed and of course these sorts of runtime checks are a favorite food of branch predictors in modern cpus right? I haven't put a lot of effort into this, but my simple benchmarks show checked dereferences being only modestly slower than unchecked dereferences. (The "msetl_example.cpp" file includes some simple benchmarks.) So why does this make registered_ptr so important? Because the "safe" version of registered_ptr would be the safe pointer with the lowest performance cost. Perhaps low enough for the safety benefits to be widely considered worth the cost. Of course the ideal would be smart pointers that could distinguish between stack allocated objects and heap allocated objects. Unfortunately, as far as I know, (standard) C++ doesn't seem to give us that facility. If we can't have those, I think we need a smart pointer that can at least accommodate stack allocated objects. Right? Noah

10 45

[Fit] Announcing Fit's formal review (March 2nd)
by paul Fultz 08 Feb '16

08 Feb '16

Dear Boost community, The formal review of the Fit library starts Wednesday, 2nd March and ends on 13th March. Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects. Fit is: - Modern: Fit takes advantages of modern C++11/C++14 features. It support both `constexpr` initialization and `constexpr` evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. - Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. - Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: * Function Adaptors and Decorators: These enhance functions with additional capability. * Functions: These return functions that achieve a specific purpose. * Utilities: These are general utilities that are useful when defining or using functions Fit has been tested on gcc 4.6-4.9, clang 3.4-3.7, and Visual Studio 2015. For more information see: Github: https://github.com/pfultz2/Fit/tree/boost Documentation: http://pfultz2.github.io/Fit/doc/html/ I hope everyone can participate in the review. Thanks, Paul

4 3

How best to implement a bitfield in C++ 14?
by Niall Douglas 07 Feb '16

07 Feb '16

Dear Boost, As part of the AFIO v2 rewrite I've been trying to improve on how AFIO v1 did bitfields by making better use of constexpr and the type system to make usage more natural. I'd appreciate feedback on my efforts. AFIO v1 has an example of usage at https://goo.gl/oVLIjU or https://gist.github.com/ned14/9ef2a9d00da0ffc877b8 and it took the following form: enum class flag : size_t { none=0, delete_on_close=1, disable_safety_fsyncs=2 }; BOOST_AFIO_DECLARE_CLASS_ENUM_AS_BITFIELD(flag) The BOOST_AFIO_DECLARE_CLASS_ENUM_AS_BITFIELD macro declares all the sensible global overloads you'd expect, is type safe and you can use it without surprise except in one single instance: testing for emptiness. The problem is that you cannot declare as a global operator an explicit operator bool nor member functions on enums, so one cannot do if(f) though if(!f) is fine. In AFIO v1, I used if(!!f) and if(!!(f & flag::foo)) everywhere, which is fine if a little abtuse. AFIO v2's current bitfield has an example of usage at https://goo.gl/LsjSGD or https://gist.github.com/ned14/89ee39c6b8eb5254116a and it takes the following form: struct flag : bitwise_flags<flag> { flag() = default; constexpr flag(bitwise_flags<flag> v) noexcept : bitwise_flags<flag>(v) { } static constexpr auto none(){ return bit(0);} static constexpr auto delete_on_close(){ return bit(1); } static constexpr auto disable_safety_fsyncs(){ return bit(2); } }; Here the bitwise_flags<> base class does all the implementation magic, so once again you can use it without surprise except for the obvious clanger - bitfield items are now functions, so instead of the more natural: flag f(flag::disable_safety_fsyncs); flag f2(f&flag::none); f2|=flag::delete_on_close; constexpr flag f3(flag::disable_safety_fsyncs); constexpr flag f4(f3&flag::none); You are stuck with: flag f(flag::disable_safety_fsyncs()); flag f2(f&flag::none()); f2|=flag::delete_on_close(); constexpr flag f3(flag::disable_safety_fsyncs()); constexpr flag f4(f3&flag::none()); I'll admit I started this with the static constexpr flag values being member variables which always works on MSVC and on GCC and clang when the optimiser is running. Unfortunately both GCC and clang appear to be extremely conservative about when a constexpr variable is ODR-used, indeed despite my original design of an unavoidable lvalue-to-rvalue conversion intended to force ODR-used to be off both compilers go ahead and enforce ODR-used anyway which generates undefined reference errors for the storage of the static member variables :( If you'd like to read more about that, and the WG21 DR relating to [basic.def.odr], see https://stackoverflow.com/questions/8016780/undefined-reference-to-sta tic-constexpr-char/28846608#28846608. So, do Boosters think we can actually make a C++ 14 bitfield which: 1. Is typesafe, so not a C bitfield. 2. Is convenient for programmers to declare (i.e. little boilerplate in a specific bitfield declaration). 3. Works as you'd expect a bitfield to work, including bitfield::flag. 4. if(bf) works. 5. Is 100% constexpr and generates zero runtime overhead. My thanks in advance for any advice. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 26