- Boost-users - lists.preview.boost.org

[Intrusive] Call custom function after tree rotations
by Lukas Barth 31 May '17

31 May '17

Hi, I'm trying to implement an interval tree based on boost::intrusive::rbtree. For such an interval tree, certain fixup operations must be run after a node rotation. Now, as far as I can see from the code (looking at rotate_* in bstree_algorithms), there is no way of "hooking into"[0] these methods, right? Am I missing something? What I need: After every operation that changes the parent-child-relationship of nodes I need to touch all involved nodes. At this point, I'm considering monkey-patching bstree_algorithms using some preprocessor directives, but that is bound to fail spectacularly. Any better ideas? Kind regards, and thanks for any help, Lukas [0] I know the term "hook" is overloaded differently with intrusive, but I can't think of a better term.

2 1

[Interprocess] uint64 atomic
by dnj0496 31 May '17

31 May '17

Hi, I am new to boost-interprocess. I am trying to store some of my data structures in shared memory using boost::interprocess. Each of my data structure(s) contain a bunch of counters (basically size_t values) updated atomically. In the traditional world, std::atomic supports atomic update for size_t. However, I came to know that boost::interprocess doesn't support atomic update for uint64. I've looked at pairing my counter with a lock for synchronization purposes. I've implemented it and it seems to work. However, the upgradable_mutex is consuming 144bytes while my counter is 8bytes(size_t) making it cost prohibitive. Alternatively, I could use one lock for all the counters of a class to spread the cost but that'd affect the performance and affect parallelism. I'd appreciate it if someone could offer any alternate suggestions. Thanks. Dk. -- View this message in context: http://boost.2283326.n4.nabble.com/Interprocess-uint64-atomic-tp4695000.html Sent from the Boost - Users mailing list archive at Nabble.com.

3 3

[type_erasure] any holding a ref to any
by Joaquin M López Muñoz 31 May '17

31 May '17

Say I have an object a of type any<mpl::vector<Concept1,typeid_<>>,_self&> and an object b of type any<Concept2,T> where Concept1 is a subconcept of Concept2. Is it possible to make a refer to b rather than the object wrapped by b? I mean: any_cast<void*>(&a)==&b typeid_of(a)==typeid(b) A solution involving wrapping/copying b into some auxiliary entity would be acceptable too. This questin is obviously connected to the implementation of boost::any_collection, as Steven will undoubtedly have guessed. Thank you, Joaquín M López Muñoz

2 1

Compiling Boost 1.64.0 with Visual Studio 2017
by Leo Carreon 31 May '17

31 May '17

Hi, Has anyone tried building Boost 1.64.0 with Visual Studio 2017 in “/std:c++latest” mode? I’m asking because I tried and the build generated a lot of errors and some of them are to do with things that have been removed in C++17, e.g. std::auto_ptr, etc. It seems that these need to be resolved soon especially when a lot of the compilers become C++17 compliant. If anyone is curios, I’m attaching a ZIP file containing my complete build log. Kind regards, Leo

1 0

Boost.Python can't link using downloaded pre-compiled binaries
by Heng Zhou 30 May '17

30 May '17

Following are the environment: - Windows 7 Enterprise SP1 64 bit - Python 2.7.13 - Visual Studio 2015 (v14.0) Following are the steps to the problem: (1) I downloaded boost_1_64_0-msvc-14.0-64.exe from https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_projec… . Since it is pre-compiled binary, I think there is no need to build Boost.Python manually. Note that it is for 64 bit build in VS2015 if I understand correctly. (2) Install the pre-compiled binary to C:\local\boost_1_64_0 (3) Follow the Boost.Python's QuickStart here: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.boost.org_doc_libs_… . The source code are the same as shown therein. (4) Set in VS2015 Property Pages->C/C++->Additional Include Directories: C:\local\boost_1_64_0;C:\Python27\include Set in VS2015 Property Pages->Linker->Additional Library Directories: C:\local\boost_1_64_0\lib64-msvc-14.0;C:\Python27\libs Set in VS2015 Property Pages->Linker->Input->Additional Dependencies: boost_python-vc140-mt-1_64.lib;boost_python-vc140-mt-gd-1_64.lib;%(AdditionalDependencies) Set in VS2015 Property Pages->General->Configuration Type: Dynamic Library (.dll) (5) Build under x64 configuration and got errors: 1>Source.obj : error LNK2001: unresolved external symbol __imp_PyString_Type 1>Source.obj : error LNK2001: unresolved external symbol __imp__Py_NoneStruct 1>C:\...\ConsoleApplication1\x64\Release\ConsoleApplication1.dll : fatal error LNK1120: 2 unresolved externals I have no idea what the matter is. I will greatly appreciate it if you can help me out.

3 2

NEWBIE: Undefined references: How do I find the library that resolves an undefined reference
by JENNINGS, LYNN M NH-03 USAF AFMC 517 SMXS/MXDPB 30 May '17

30 May '17

NEWBIE question: Undefined references: How do I find the library that resolves an undefined reference. For example, the output for the gcc linker running in MinGW shows: C:/boost/boost/asio/detail/impl/winsock_init.ipp:39: Undefined reference to `WSAStartup@8' I have googled the documentation a number of ways, but I cannot find the library that will resolve this error. I am sure that this is a common problem. Please point me to the documentation so I can fix this and the undefined references. Thanks!

4 3

boost::process async io and reading stdout line by line
by niXman 29 May '17

29 May '17

Hi, Is it possible to use boost::process async io and reading the stdout line by line? Thanks. -- Regards, niXman ___________________________________________________ Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: https://sf.net/p/mingw-w64/

2 1

[Move] unique_ptr with boost vector container (C++98)
by Gene Kang 29 May '17

29 May '17

I’m using boost::movelib::unique_ptr with a polymorphic container of type boost::container::vector and getting a compiler error that I can’t seem to figure out (see code sample and attached compiler output). Note, this error occurs when compiling without C++11 support w/ x86-64 gcc 4.9.3. When compiling w/ C++11 support (e.g. -std=c++11) the code compiles fine. Any ideas ? Thanks in advance for any help on this. ---------------------------------------------------- #include <boost/move/unique_ptr.hpp> #include <boost/container/vector.hpp> class FooA { public: FooA() {} virtual ~FooA() {} virtual void execute() {} }; class FooB : public FooA { public: FooB() {} virtual void execute() {} }; int main() { typedef boost::movelib::unique_ptr<FooA> FooAPtr; typedef boost::movelib::unique_ptr<FooB> FooBPtr; boost::container::vector<FooAPtr> fooVector; FooBPtr fooBPtr(new FooB); fooVector.push_back(boost::move(fooBPtr)); return 0; }

2 2

Re: [Boost-users] [outcome] Possible extensions/changes to std::experimental::expected
by Vicente J. Botet Escriba 25 May '17

25 May '17

Hi, I believe that this private mail I sent to Niall could concern the Boost community and the Outcome review. While the post concerns the proposed std::experimental::expected, this is applicable as well to Outcome. I've added a more points at the end and some additional information about possible open points for std expected. Le 24/05/2017 à 01:04, Vicente J. Botet Escriba a écrit : > > Hi, > > > After better understanding of the goals of Boost.Outcome I would like > to share two possible extension of std::experimental::expected > > > 1. Implicit conversion when the errors are convertible and the type is > the same. > > I believe this is a missing constructor. > > EXPLICIT expected<T, E>::expected(expected<T, G>); // E is > convertible from G > > I see that the other constructor is also useful > > EXPLICIT expected<T, E>::expected(expected<U, E>); // T is > convertible from U > > and so > > EXPLICIT expected<T, E>::expected(expected<U, G>); // T is > convertible from U and E is convertible from G > > We could as well have an adapt function that transforms expected error explicitly to do error propagation adapt : (E->G) x expected<T,E> -> expected<T,G> (E->G) stands for a function that takes an E and return a G. > 2. variadic expected<Y, E1, ..., En> > > I suggested this already in revision 2 of the Expected standard proposal. > > expected<Y, E1, ..., En> should be something like variant<Y, E1, ..., > En> but with some syntactic sugar. > > > expected<T, E1, ...., En> could be EXPLICIT convertible from > expected<T, G1, ...., Gm> as far as for all Gj we find a unique Ek > that is convertible to. > We can refine the subsumption relation this could take too long to the compiler (as the previous relation has quadratic complexity as Andrzej reported to me). > > I believe this will cover exactly what outcome covers and in addition > it will let open the error types used by the user. > > It acts as a exception specification, which we have abandoned in C++11. > > expected<T, E1, ...., En> f(); > > T f() throw (E1, ...., En); > > > We can consider that this is bad, as we have abandoned it. > > Anyway, I think that expected<T, E1, ...., En> is a good > generalization of the proposed outcome<T> where E1 could be none_t, E2 > could be error_code and E3 is exception_ptr. > > At the end users could use variant<E, E1, ..., En> are return code, so maybe we could to make their life easier. > > In this way we could have > > template <class T> > > using option = expected<T, nullopt_t>; > > Note that this is different to std::optional as the default is T not > nullopt_t :( > I'm not proposing it. Just to say that this could be a possibility for option. > > template <class T> > > using result = expected<T, error_code_extended>; // and possibly none. > > template <class T> > > using outcome = expected<T, none_t, error_code_extended, exception_ptr>; > > > I believe we would need the syntactic sugar as expected<T, > variant<E1,... En>> should have a lot of user code noise. > In addition it will be less efficient than variant<T, E1,... En>. > > E.g. expected<T, variant<E1,... En>> should be convertible from > unexpected_type<G> as soon a one of the Ek is convertible from G. > > I believe variant<E1,... En> is not convertible from variant<G1,... > Gm> under the conditions described above, but maybe this should be the > case. > Andrzej told to me that this is already the case for optional<T>, but I've not found yet on which paper this was added? > > Of course, the never empty warranties could be supported only if the > types Ek allow it and we need to change the standard to ensure it for > exception_ptr. > > > I will not have time to implement a POC for 2, but I believe I could > do it for 1 before Toronto. Anyway I believe it will be worth > discussing these 2 extensions. > > > Best, > > Vicente > > > P.S. EXPLICIT above has the sense given in the standard. > 3. uninitialized default constructed expected<T,E> I know this could be conflictual, but there are a some advantages to doing it. We don't spend time initializing with something we will assign later. This state corresponds to the moved-from state. Initializing it by default to T() is not better initializing to E(). Is expected<Date, error_code> default constructible even if Date is not? Currently it is not the case. There are of course liabilities. We have now the possibility for uninitialized variables, but static analysis tools will help here. 4. About comparisons Outcome doesn't implement comparisons between Outcomes. He pretend that we don't need them. In addition the mix of comparisons and implicit conversion give us some surprising cases as described in Andrzej blog. [1] A gotcha with Optional - https://akrzemi1.wordpress.com/2014/12/02/a-gotcha-with-optional We have that std::future is not comparable (as exception_ptr is not comparable). Instead of comparison we could specialize std::less<> if we want to use them in ordered containers. What others think? 5. About implicit conversion from T The implicit conversion from T to expected<T,E> is a consequence of wanting that expected<T,E> should behave like a T. But this is not right. A expected<T,E> is not a T. We have in some way that expected<T,E> is explicitly constructible from E bu the use of make_unexpected(e). If we had only and explicit constructor from T the code will be much more uniform. Either you build it with a modified make_expected or with make_unexpected. In my opinion the implicit conversion from T to expected<T> is a mistake. 5. About the exception to throw std::experimental::expected throw bad_expected_access<E>. I adopted the design of optional and bad_optional_access We could have as well a bad_expected_access_base class as Outcome has. My question is why don't throw directly E? Some are requesting a way to get a specific exception from E, but either there is one exception that works for all and we can set it using some kind of trait or we need to add a trait parameter to expected to the the mapping :( Do we really want this to be configurable? 6. Implicit conversion from E outcome::expected<T,E> outcome::expected<T,E> is implicitly convertible from E when there is no risk of ambiguity. std::expected<T,E> is implicitly convertible from unexpected<E>. What people thing we should have? In Boost? in the standard? Vicente

1 0

[Regex] Has build location changed between 1.34.1 and 1.64.0 ?
by Kerry, Richard 23 May '17

23 May '17

I've just added Boost Regex to a new project. It is the first time I've done that for quite a long time (several years) and I'm left wondering whether Regex's standard build location has been changed, or whether I've missed a detail in the instructions. The last one I did was Boost version 1.34.1, under Visual Studio 6. The one I have just done is Boost version 1.64.0, under Visual Studio 12, aka Visual Studio 2013. To build 1.34.1 (on VC6) I run "bjam --toolset=msvc --with-regex stage". This creates two folders - "bin.v2" and "stage". Bin.v2 is where all the intermediate files are written. Stage/lib is where the final outputs are written. There are a number of different ones built; for all the various static/dynamic, single/multi-threading, debug/release options. Because of the auto-link stuff I just #include <boost/regex.hpp> in my project, and because of the use of #pragma comments in boost, the Link pass picks up the correct library file-name, provided I have included $(BOOSTDIR)\stage\lib in the linker's list of folders to search. (%BOOSTDIR% being my chosen download/build location) To build 1.64.0 I've followed the current instructions. I ran "b2 regex", which built a dll, which is not what I want. I then ran "b2 regex link=static", which build the static lib I wanted. However, the lib is left in a folder a long way down from the bin.v2 folder, which is where I expected it to be. It's in bin.v2\libs\regex\build\msvc-12\debug\link-static\threading-multi. Hence, I need to know all the build settings to work out the folder name. On the file-name side this is all hidden from my by the auto-link system, which builds the lib file's name from the various option settings. Having the name built automatically but not the path leads me to suspect I've missed something.... So: Is there an instruction I've missed to get all the built products (dlls or libs) put in a common (not too deep) location ? (so the auto-link system will be sufficient to find it given just one linker folder location) Is there an instruction I've missed to get all the combinations (static/dynamic, single/multi-threading, debug/release) built ? (rather than one at a time) Regards, Richard. Richard Kerry BNCS Engineer, SI SOL Telco & Media Vertical Practice T: +44 (0)20 3618 2669 M: +44 (0)7812 325518 4 Triton Square, Regent’s Place, London NW1 3HG richard.kerry(a)atos.net<mailto:richard.kerry@atos.net> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.</ Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983. This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.

3 5