- Boost - lists.boost.org

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

[review] More reviews of Nowide are welcome
by Frédéric Bron 16 Jun '17

16 Jun '17

Hi all, More official reviews are welcome for the boost nowide library. It's a small and very useful library, please consider taking some time to give us your feedback. Please answer the questions at the bottom of this message. Cheers, Frédéric (review manager) ---------- Forwarded message ---------- Date: 2017-06-12 6:20 GMT+02:00 Subject: [boost][review] Review of Nowide (Unicode) starts today Hi Everyone, The formal review of Artyom Beilis' Nowide library starts today and will last until Wed. 21st of June. Your participation is encouraged, as the proposed library is uncoupled, focused and rather small. Nowadays, everyone needs to handle Unicode but this is very difficult using only the standard library in a platform independant way. Nowide offers a very simple way to handle Unicode the same way on Windows/MacOS/Linux. Key features: * work with UTF-8 in your code, Nowide converts to OS encoding * Easy to use functions for converting UTF-8 to/from UTF-16 * A class to fixing argc, argc and env main parameters to use UTF-8 * UTF-8 aware functions: - stdio.h functions (fopen, freopen, remove, rename) - stdlib.h functions (system, getenv, setenv, unsetenv, putenv) - fstream (filebuf, fstream/ofstream/ifstream) - iostream (cout, cerr, clog, cin) Documentation: http://cppcms.com/files/nowide/html GitHub: https://github.com/artyom-beilis/nowide git clone https://github.com/artyom-beilis/nowide.git Latest tarballs: - to be unzipped in boost source: https://github.com/artyom-beilis/nowide/archive/master.zip - as a standalone library: http://cppcms.com/files/nowide/nowide_standalone.zip Nowide has standard boost layout. So, just put it into the boost source tree under libs/nowide directory for building and running tests. Or alternatively - for header only part of the library add the nowide/include path to the include path of your projects. Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. Frédéric

1 0

Re: [boost] [review] Review of Nowide (Unicode) starts today
by Artyom Beilis 16 Jun '17

16 Jun '17

How would you therefore do this simple task: 1. get a directory from nowide::getenv -> base_dir (UTF-8 on Windows, unknown narrow on Posix) 2. create a file in base_dir which name is file_name encoded in UTF-8 (because it is created by the application). If I understand well, I should NOT do this: auto f = nowide::ofstream((boost::filesystem::path(base_dir) / file_name).string()); because this is guaranteed to work only on Windows where I have the guarantee that base_dir is UTF-8, right? Actually it is what exactly you should do. Once you turn on **nowide integration** with boost filesystem path::string does not perform any conversions on POSIX platforms. And you can safely concatenate two different strings and valid file will be created. Even if dir is in ISO 8859-1 and file in UTF-8. The file will be valid even if not representable in any encoding. Under windows you'll get the correct conversions from narrow to wide using the utf8/16 facet installed by boost.nowide/Filesystem integration as on Windows boost filesystem uses wide strings Artyom

4 4

[interprocess] how to use lock_file with Unicode file name?
by Frédéric Bron 16 Jun '17

16 Jun '17

Hi, I have been using lock_file with ASCII file names without any trouble. Now I would like to be able to use non ASCII file names. How does it work? Currently, lock_file uses as input const char *. What about the encoding? Cheers, Frédéric http://www.boost.org/doc/libs/1_64_0/doc/html/boost/interprocess/file_lock.… http://www.boost.org/doc/libs/1_64_0/doc/html/interprocess/synchronization_…

1 0

Re: [boost] [review] Review of Nowide (Unicode) starts today
by Frédéric Bron 15 Jun '17

15 Jun '17

> at Linux nowide fstream is > an alias to std::fstream If course! Frédéric

1 0