June 2017 - Boost - lists.boost.org

Re: [boost] [cmake] Minimum viable cmakeification for Boost
by Thomas Heller 20 Jun '17

20 Jun '17

Am 20.06.2017 4:21 nachm. schrieb "Peter Dimov via Boost" < boost(a)lists.boost.org>: Thomas Heller wrote: > As a general observation, I see a lot of statements along the lines of "I > state that XYZ is preferable over UVW", it would be nice to have to have > background information (pros and cons anyone? what do the cmake > authors/docs have to say about this?) on those statements so that everyone > can form their own opinion instead of having to choose whom to trust about > what's "standard" cmake. > That's the problem with CMake, there's no way for someone like me who does not follow it to get a definitive answer to what idiomatic CMake 3.5+ is. There are several articles about it, they all say more or less the same thing - use target_*. I get that. But that's not enough. I see a general (and very predictable) trend of moving from imperative to declarative. Programmers like imperative, but a proper build system really prefers declarative, so CMake is trying to evolve towards declarative. Take for example find_package. It's a command, find me this package, now. But it's much better if a library does not issue "find me this package" commands, but rather declares which packages it needs. So we get "best practice" hacks like redefining find_package. I'm sorry, this doesn't feel right. I hear what you're saying. We'll end up innovating cmake, which for me isn't a bad thing. I'm favoring CMake due to its great support for generating for all kinds of different environments (including proper visual studio solutions). To be fair, I haven't invested as much time in boost.build as I did for cmake. For all platforms I work on, both work equally nice with different quircks on different ends. I'm not using an ide though. For the sake of ide support, I'd lean towards cmake. Regarding the discussion of what's right and wrong when writing your CMakeLists.txt files, it's almost bike shedding. If you want to depend on a library, you'll make it work, no matter what, that's what we do. Nevertheless, in terms of cmakeisms, I really like what Paul put together and what Daniel Pfeifer said in his talk makes a lot of sense in a cmake world. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

1 0

proposal - modularize Boost build system
by Stefan Seefeld 20 Jun '17

20 Jun '17

One of Boost's bottlenecks is its monolithic build infrastructure. It would be beneficial for many different use cases (testing, packaging, etc.) to decouple the building of Boost libraries (well, those that require building, see the listing in http://www.boost.org/doc/libs/1_64_0/more/getting_started/unix-variants.htm…) such that they may optionally be built stand-alone. At present, building a Boost library requires the entire (super-)repository to be checked out, and the build logic itself involves traversing the entire source tree, looking for a "Jamroot". What would be beneficial to many would be a workflow like this: 1) Have a development environment with (some version of) Boost pre-installed (or at least the parts that the library being built depends on). 2) Check out a single Boost repository (e.g., https://github.com/boostorg/python) 3) Invoke a command to build it (if there is anything to build) 4) Invoke a command to test it 5) Invoke a command to install it 6) Invoke a command to package it (optional) While it's of course already possible to do all the above by adding support for another build infrastructure (point in case: Boost.Python right now uses SCons for this very reason), this means duplication of effort, as Boost as a whole is still built, tested (and even packaged for binary packages) using Boost.Build, meaning I need to maintain two sets of build infrastructure. This proposal thus has two parts: 1) Make the nested build logic independent of the outer bits, so individual libraries can be built stand-alone (for example, using b2 by adding a `--with-boost` set of options to point to the location of the prerequisite parts of Boost). 2) Define a clear interface the outer build logic will use to invoke the nested build commands. Note that for my own case above (Boost.Python), providing 2) would be enough, i.e. by having a way for me to "plug in" my SCons commands to build and test Boost.Python could obsolete the existing Boost.Build logic as defined in Boost.Python (as well as the prerequisite parts in Boost.Build's "python" module). However, as my proposal is *not* actually advocating to move away from Boost.Build, but rather to modularize it, I think 1) is essential to let everyone else (who may not be inclined to use anything other than Boost.Build) to also take advantage of modularization. While I'd rather avoid delving into the technical details of how this could possibly be implemented (if you really must, *please* do so in a new thread !), let me outline a few use-cases that would be made possible by the above: * individual projects would be free to switch to their preferred infrastructure, including CMake, SCons, etc., if they so wish * individual projects could be much more easily developed and contributed to * individual projects could be much more easily tested, notably in CI environments * individual projects could be much more easily packaged All of the above advantages are *huge*, and reflect real-world needs, and the technical issues to solve these are all minor. The question really is whether there is enough will to move into that direction. I'd be very happy to participate in the work needed to implement this. But first we need to agree that this is where we want to go. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

14 46

Review of Nowide
by Chris Glover 20 Jun '17

20 Jun '17

Hi, The following is my review of the proposed Boost.Nowide library. This is my first official review of a boost library, so please forgive me if I've missed anything. - What is your evaluation of the design? At first I was surprised by lack of a platform agnostic encoding. However, through reading the docs and the discussion in the list, I believe this to be the correct choice. If a user has a need for a common encoding, I believe that would be best served by a different library that would ultimately have different issues and performance characteristics. One thing I'm not sure about is if the overlap between the fstream implementations in filesystem and nowide is necessary. It seems to me that if I set filesystem to be nowide aware (via boost::nowide::nowide_filesystem) then there's little reason for the nowide versions of the stream objects to exist, other than possibly eliminating one string copy on non-windows platforms and avoiding the filesystem dependency (and maybe those are good enough reasons). - What is your evaluation of the implementation? I only gave the implementation a glance. It looks good; clean, organized; with a full test suite and nothing weird stands out. It seems to be of the typical quality I expect from a boost library. - What is your evaluation of the documentation? The documentation is clear and complete, but I think it needs to explain at the top that the library does not present a uniform encoding for strings. This is discussed in the documentation near the end, under "Q & A", but I think it should be near the top. A suggestion is to add a section called "What Boost.Nowide is *not*" directly under the section titled "What is Boost.Nowide", otherwise I expect some users to be surprised. - What is your evaluation of the potential usefulness of the library? It is very useful. I am already using it. - Did you try to use the library? With what compiler? Did you have any problems? I converted one application that was using boost::filesystem::path to transport filenames around to use nowide instead. I had no issues, everything just worked. Some code was also simplified as a result -- not dramatically, but enough that it felt better. I tested the application on windows only using Visual Studio 2017. I also ran the tests under MSYS2 on Windows using gcc-6.3, on Windows using MSVC 2017 and on Ubuntu using gcc-7. Under MSYS, one test failed (Fail: Error boost::nowide::cin.putback(c) in test_iostream.cpp:17 main), but I haven't had a chance to look into why yet. All of the tests passed on the other platforms. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I followed the discussion, read the docs, integrated the library, used the API and tested the resulting program. All in, I think that took me about 4 hours. This seems quick, but to me that is a testament to a solid design and clear documentation because the conversion process was very simple. - Are you knowledgeable about the problem domain? I am aware of the problem and have worked around it in the past by using filesystem::path as a string. However, most of the environments I work in professionally are controlled in a way that allows us to avoid this problem most of the time, so I have not had extensive experience with it. - Do you think the library should be accepted as a Boost library? Yes. I am already using it and expect I will be using it a lot more going forward. -- chris

2 2

[nowide] review
by Andrzej Krzemienski 20 Jun '17

20 Jun '17

Hi All. This is a review of Boost.Nowide library. I am not really familiar with the problem. I used to do trivial tasks with files on Windows, but they were always ASCII, so the problems solved by Boost.Nowide never affected me. I am also not fa,iliar with the problems of converting from Windows encoding (*WTF* seems like the right choice of name) to UTF-8. I have read the documentation, and got some additional information from the author. I have downloaded the library and have run a toy program that plays with names that cannot be encoded in a single code-page. I am testing on Windows 7, MinGW, GCC 6.3, with -std=c++03. Compilation and linking works fine. Tests work fine too. Then, I tried the same example with normal `std::ifstream` and it did not work on Unicode file names and strings, which conforms that Boost.Nowide solves an existing problem. DESIGN: clear, logical, intuitive. IMPLEMENTATION: I did not look at. DOCUMENTATION: clear. POTENTIAL USEFULNESS: as specified in the docs, if you want to do things with multilingual strings in a platform independent way, you need a library like this. I vote to *ACCEPT* the library. I may not be qualified enough (the manager will weigh my vote), but the desctiption of the library, as well as the replies from Artyom convince me that the library addresses the problem in the right way and is reliable. Artyom, thanks for sharing this library, and submitting it for review. One minor thing. In th be docs (http://cppcms.com/files/nowide/html/) we read: boost::nowide::widen <http://cppcms.com/files/nowide/html/namespaceboost_1_1nowide.html#a6baacc1b…> returns std::string. I thing is thsould be std::wstring? Regards, &rzej;

2 5

Atomic Shared Ptr
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi, Does Boost have anything like concurrency TS' atomic_shared_ptr? Gr, -- Olaf

3 7

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

Sanitizer bug or undefined behavior in format?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi, I think it's about rdbuf() which doesn't appear to be virtual. Is this a bug in the sanitizer or is this call not allowed? alt_sstream.hpp: basic_oaltstringstream(stringbuf_t * buf) : pbase_type(buf, No_Op() ), stream_t(rdbuf()) { } $ g++ a.cpp -fsanitize=undefined && ./a.out /usr/include/boost/format/alt_sstream.hpp:146:60: runtime error: member call on address 0x7fffdb4f36a0 which does not point to an object of type 'basic_oaltstringstream' 0x7fffdb4f36a0: note: object has invalid vptr 00 00 00 00 00 00 00 00 00 00 00 00 18 3a 4f db ff 7f 00 00 b0 4c 37 fa 66 55 00 00 28 5b 0d 80 ^~~~~~~~~~~~~~~~~~~~~~~ invalid vptr a.cpp: #include <iostream> int main() { std::cout << boost::format("%d") % 1 << std::endl; // std::cout << boost::format("%04d-%02d-%02d") % (date->tm_year + 1900) % (date->tm_mon + 1) % date->tm_mday << std::endl; return 0; } -- Olaf

2 2

Re: [boost] proposal - introduce API & ABI compatibility guidelines
by Brian Wood 19 Jun '17

19 Jun '17

Artyom Beilis writes: > The problem is that it isn't going to change in near future because > it is almost impossible to reach a consensus of some strategic > direction because any major change will find enough developers > who will not want one. > > So today I use boost only in applications and never in libraries. I'm only comfortable using Boost in private/closed source applications. I think on line code generation will help with some of the packaging problems discussed in this thread. Brian Ebenezer Enterprises - Enjoying programming again. http://webEbenezer.net

1 0

proposal - introduce API & ABI compatibility guidelines
by Stefan Seefeld 18 Jun '17

18 Jun '17

Following up on this point made by Peter Dimov in another discussion: > This is part of the price you pay for being accepted as part of Boost > - the duty to act as an integration test for your Boost dependencies. > This is beneficial for you in the long term, because you can detect > breaking changes in your dependencies before they get shipped. If you > only test against 1.56, and 1.64 breaks your library, you won't hear > about it before 1.72. This does you no good, and it does your users no > good. You WANT to know if changes in 1.65's SmartPtr would break you > BEFORE 1.65 gets released. The real problem that you are touching here is Boost's lack of any sort of ABI or even API stability. So Boost 1.X and Boost 1.(X+1) are two distinct packages, as there is no metric that enables even to measure the amount of incompatibility between the two. Any normal library that's used in-production would have strong requirements for backward compatibility, to enable users to reason about the risk of upgrading etc. Thus, to follow up (and not pollute the original discussion about modularization), I'll propose the following: I'd like to see guidelines to be established for: * what API and ABI changes may be applied in a given release * have a clear definition of version numbers (major, minor, bug fix) with associated semantics * impose testing requirements to enforce the above. Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 1

[nowide] request for clarification
by Andrzej Krzemienski 17 Jun '17

17 Jun '17

Hi Everyone, I admit I am not quite familiar with the problem, but I understand that as one of the features, nowide offers a replacement for std::fstream that can be constructed with its string types. At the same time we have boost::filesystem that offers its own replacement for std::fstream that can be constructed with filesystem::path. Now, if I want to use `filesystem::path`s in my program (to be able to tell just any string from a filesystem path), can I still use the benefits of `nowide` library? Also, in the docs for nowide::ifstream, we read, "Same as std::basic_ifstream<char> but accepts UTF-8 strings under Windows." What about other systems? What does it accept on Linux? ascii? In documentation for `nowide::args`, we read, "args is a class that fixes standard main() function arguments and changes them to UTF-8 under Microsoft Windows." Does it write to the input strings in-place? is it even legal in C++? It "fixes", which implies that otherwise the args are "broken". How are args in function main() broken? (other than not being UTF-8)? Regards, &rzej;

5 9