- Boost-users - lists.boost.org

BOOST_PP_SEQ_ENUM troubles
by Cherotek Music 08 Jul '16

08 Jul '16

Hi, I'm trying to make a macro chain that expands something like this *A, B, C* into something like this *{"A", create<AFile>}, {"B", create<BFile>}, {"C", create<CFile>}* This is what I have come up with *#define FORMATS A, B, C // Add new formats here* *#define SEQ_FORMATS BOOST_PP_VARIADIC_TO_SEQ(FORMATS)* *#define ARG_PAIR(s, data, x) {#x, create<x##File>}* *#define SEQ_ARG_PAIRS BOOST_PP_SEQ_TRANSFORM(ARG_PAIR, ~, SEQ_FORMATS)* *#define ARG_PAIRS BOOST_PP_SEQ_ENUM(SEQ_ARG_PAIRS)* The SEQ_ARG_PAIRS macro does expand into *({"A", create<AFile>}) ({"B", create<BFile>}) ({"C", create<CFile>})* but ARG_PAIRS fails with the following error: test.cpp:20:1: error: macro "BOOST_PP_SEQ_SIZE_0" passed 2 arguments, but takes just 1 ARG_PAIRS ^ BOOST_PP_SEQ_ENUM_0 ({"B", create<BFile>}) ({"C", create<CFile>}) ({"A", create<AFile>}) ({"B", create<BFile>}) ({"C", create<CFile>}) Any ideas? thanks a lot

3 7

boost::any with const value types
by Robert Dailey 07 Jul '16

07 Jul '16

I'm finding that if I store a `char*` versus `char const*` in a boost::any object, that this impacts the behavior of boost::any_cast. I do not find this documented anywhere. For example, if I store a const qualified character pointer in a boost::any object, then I do `boost::any_cast<char*>(......)`, it will throw. Changing the type to `char const*` fixes it. Is this by design? I find this makes things more difficult to deal with since I don't always know if the type I'm getting is const or not. Also my implementation does not change depending on constness.

4 3

State of context and coroutine
by Michael Steinberg 06 Jul '16

06 Jul '16

Hello, I find myself working on a project which makes use of boost::context functionality which got moved to the detail namespace somewhen before booost 1.61 . Now this project is mimicing something along the lines of boost::coroutine on top of context. I could try to adapt to the new intended usage of context or change the setup to use coroutine. Hence my question is whether the public coroutine interface, specifically the asymmetric parts, is stable yet? Im seeing 1's and 2's there side by side, so I could imagine there's still deciding on a good interface going on. Kind Regards, Michael

4 12

Re: [Boost-users] Acquiring and rebuilding C++ libraries on Windows
by LeMay.Steve 06 Jul '16

06 Jul '16

Probably a great topic for CPPCON. Sent from my iPad From: Ernest Zaslavsky Sent: 7/5/16, 8:44 PM To: , Boost Subject: Re: [Boost-users] Acquiring and rebuilding C++ libraries on Windows Hi, And what happened to the native NuGet packages idea? It is quite convenient way to get, use and update third parties. From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Eric Mittelette Sent: Wednesday, July 06, 2016 2:49 AM To: boost-users(a)lists.boost.org Subject: [Boost-users] Acquiring and rebuilding C++ libraries on Windows Hello I’m Program Manager at Microsoft, working on VC++ Libraries team (VC runtime, STL…) We are working on the spec of a tool to acquire 3rd party libraries on Windows. We are targeting mainly OSS libraries, our tool will help dev to rebuild locally from the source code on Windows. Today we have a proto, based on a port tree approach. (having a repo with the build script and the associated patch file) I wanted to have a discussion with the Boost community about this project, and how dev could acquire Boost this way. Feel free to contact me to initiate this discussion, we’ll be happy to share our idea and prototype with you and collect feedback and suggestions. Best, Eric Mittelette Senior Program Manager – Visual C++ (VCLib) Microsoft Corp. CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information. This message is intended solely for the use of the addressee. If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited.

1 0

filesystem path{}.string() interface brittle when developing cross platform
by Werner Erasmus 05 Jul '16

05 Jul '16

Firstly, I would like to than the author/s of filesystem for their great work and their time. I've recently written some code on Linux where I had to adapt a filesystem::path object to string. I noticed that the return value was of type [const std::string&], and used the same return value in my getter that exposed the underlying string. Moving over to windows, I had strange crashes (undefined behaviour) as result of the type under windows being converted to [std::string]. The reason for the "undefined behaviour" took me a while to figure out. While understanding why the author returned by value (Windows API underlying type not a std::string...), I think that for a specific type, the contract concerning return value "semantics" should no be broken. There is a significant difference between returning by const reference as opposed to returning by value. If the contract cannot be held, the decision should be made to (in the interest of consistency/clarity) to return the same type for all OS's/platforms if the code is to be considered platform independent. This might mean to compromise by returning by value, or to, in the case of Windows (where the underlying string has a different type), cache the string, or at the very least document a *BOLD* note that caution must be taken. I can comprehend that if conversion is required, return by value is the only option. I expect type consistency per type, as this to me is part of the contract of a function. I don't consider this a bug, but would appreciate some response. Kind Regards

3 2

[coroutine2] - exceptions from constructor fail
by Tamas.Ruszkai＠leica-geosystems.com 01 Jul '16

01 Jul '16

2 1

Re: [Boost-users] Multiprecison: converting a complex class to a number<> backend (John Maddock)
by Daniel Brake 30 Jun '16

30 Jun '16

Hi Boost, particularly John Maddock and Christopher Kormanyos *first my response to John:* > From: John Maddock <jz.maddock(a)googlemail.com> > Date: Wed, 29 Jun 2016 19:28:19 +0100 Subject: Re: [Boost-users] Multiprecison: converting a complex class to a > number<> backend I suggest you take a look at rational_adaptor which does more or less > exactly this but for rational types - if you basically just gut the > function implementations from that file, search and replace the class > names, and then fill in the blanks you should be 95% there. > this is exactly the kind of advice i was looking for, thanks very much!!! i think i can get started almost right away. > This is actually something that's been on our TODO list for far too long, > ideally this should be part of the library - fancy helping out - or at > least being a testing guinea pig? > absolutely, i would love to help with this. the major challenge I see for getting everything fully functional in my active codebase using the new backend is Eigen. I continue to push the boundaries of Eigen with respect to expression templated numeric types, ha. i absolutely love that library! by the time I am done with my code, it will be expressions and templates the whole way down. i am guessing that personal emails or the dev list are the best place to continue discussion of helping work on this part of the library? > I quickly mocked up an example (attached) of how I think this should look > if we were to add it to the library, basically: > thanks for the mock-up! > As noted in the attached example, we really need another number category > for complex types, and while mixed arithmetic with (real) scalars will just > work, if you wanted an imaginary type as well, that would involve a whole > lot more work, as class number does not currently support return a type > different from either argument type in the binary operators (for real + > imaginary for example). > mixed real-complex is enough for me for now, adding imag-real specializations won't affect much of my codebase, so not currently a high priority for me. sometime over the rainbow, it might become important, but not right now. > And finally... there is this: > https://code.google.com/archive/p/cpp-imaginary-numbers/ which takes a > different view of things (but loses multiprecision's expression templates). > I really need the expression templates, but this is a good resource. thanks for the link. > PS, one final note: ideally this would be handled by std::complex, but > sadly that class can not be instantiated on any type other than > float/double/long double with invoking undefined behaviour. > agreed. the STL's most disappointing template to me: the std::complex. i was disheartened to feed in higher precision types, and get only double precision out of atan. then i found out about the invocation of UB resulting from what i had done... thanks for the response, John. you are always most helpful, and I really appreciate your time. ---------- *second, my response to Christopher and John* On 29/06/2016 22:17, Christopher Kormanyos wrote: > >> >> In my opinion, trying to adapt a complex number class to the backend >> requirements of number might not be the best way to go. >> >> I would recommend writing an extended complex template class >> that is intended to be instantiated for both user-defined types as well as >> float, double and long double. >> > should be a relatively easy conversion, to add template parameters to my class, and replace the hard-code of real_ and imag_ type. this is definitely a desirable modification, though not a pressing need in my context. It would be nice to be able to use any type. John, I think we should talk about the final needs of a complex_backend for inclusion in the multiprecision library. Thanks for the response Christopher. Thanks for reading and responding! Daniel

2 1

Re: [Boost-users] boost::serialize 1.61 ticket #12141 not quite fixed for VS2015? (Robert Ramey)
by Colin Humphries 30 Jun '16

30 Jun '16

Hello Robert, Thank you for your quick reply. Today I down-loaded and rebuilt boost 1.61.0, for both .zip and .7z versions from boost.org but I still see that final expanded line. Regards Colin Humphries On 6/26/16 3:33 PM, Colin Humphries wrote: > After converting to boost 1.61 and Visual Studio 15 we now see a > problem closely related to one reported in ticket #12141. Our XML > archives now end with the following 2 lines: > > </boost_serialization> > </boost_serialization> > > Could someone suggest a quick fix please? I think the problem must be > in archive/impl/xml_woarchive_impl.ipp but I cannot grasp how > the archive destructor emits the last line. When this was reported we took emergency action to make sure it was addressed before the final release. Are you sure you have the actual 1.61 final release? Robert Ramey >

1 0

boost unit test framework exports std::basic_ostringstream
by Sascha Kremers 30 Jun '16

30 Jun '16

The boost unit test framework exports std::basic_ostringstream to the dll. This causes linker errors on visual studio 2012 (LNK 2005), if the tested code contains std::basic_ostringstream. You can confirm the symbol std::basic_ostringstream is in boost_unit_test_framework-vc110-mt-1_61.dll by using dependency walker. I have the same problem with my self-built dlls as well as the ones downloaded from https://sourceforge.net/projects/boost/files/boost-binaries/. Is this a problem with boost or did I configure the build wrong? Thank you. I posted the issue on Stack Overflow a week ago [1]. Please excuse, if this still counts as cross posting. Regards Sascha [1] http://stackoverflow.com/questions/37922117/stdbasic-ostringstream-exported…

2 2

Re: [Boost-users] Multiprecison: converting a complex class to a number<> backend
by John Maddock 30 Jun '16

30 Jun '16

On 29/06/2016 22:17, Christopher Kormanyos wrote: > > In my opinion, trying to adapt a complex number class to the backend > requirements of number might not be the best way to go. > > I would recommend writing an extended complex template class > that is intended to be instantiated for both user-defined types as well as > float, double and long double. > > The real and imag parts are template parameter types. They could be > of type mpfr_float because the template parameter type is > determined at compile-time when the class is instantiated. > > In the winter, I wrote an extended complex class and tested it extensively > with multiprecision and fixed point. There was also another candidate > implementation of extended complex a few years ago from another > developer, but it never got to review. > > I have not yet made my extended complex code available. > > I am not subscribed to the user's list. If the post gets to the > developer's > list, there is a good chance I will see it. I'm curious as to what you see as the stumbling block to providing a complex number backend to class number<> ? The main advantages are that the expression-template code and all operator overloads are "just there" already, what do you see as the drawbacks? Best, John.

1 0