- Boost - lists.preview.boost.org

[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

[config][android] GCC-5 and 6 failures.
by John Maddock 15 Jun '17

15 Jun '17

There are some runtime (segfault) failures running config_test on andoid, see for example: http://www.boost.org/development/tests/develop/developer/CrystaX-apilevel-2… Can anyone with access to this platform (or preferably the test runner) see if defining BOOST_NO_CXX11_THREAD_LOCAL fixes the issue? That would be my hunch for the problem anyway. Many thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 2

[random] Request for Additional Generators
by degski 15 Jun '17

15 Jun '17

I would like to request the addition of 2 generators to Boost.Random. xoroshiro128+ <http://xoroshiro.di.unimi.it/xoroshiro128plus.c> Web page: http://xoroshiro.di.unimi.it/ A very fast PRNG, (quite a lot) faster than the fastest current boost generator, with a period of 2 ^ 128, which could/would be good for f.e. game programming (except for shuffling, see below). It also has a state of only 16 bytes on x64. The author states that the distribution is of higher quality than f.e. MT19937-64 <http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-6…>. It's probably best to just read the web-page, as it goes into quite some detail and is in itself the summary of the research conducted in this area. Other than the normal boost complications, it's very easy to implement and I use my simplistic implementation to great satisfaction with the std and boost distributions. In this <https://www.codeproject.com/Tips/1083372/Random-Number-Generator-Recommenda…> article on CodeProject the issue of shuffling is raised. It's appears that shuffling of large arrays of data requires a generator with extremely long periods in order to be able to generate all the possible permutations. To this extent I would like to see in boost a generator like George Marsaglia's SuperKiss <https://groups.google.com/forum/#!topic/comp.lang.fortran/QiTrbq0XeyM> or/and a templated SFMT generator like this <https://sourceforge.net/p/int64/svn/HEAD/tree/snips/sfmt.hpp> one. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

2 3

[review] Review of PolyCollection starts today (May 3rd)
by Ion Gaztañaga 15 Jun '17

15 Jun '17

Hi everyone, The formal review of Joaquín M. López Muñoz's PolyCollection library starts today. I'd like to encourage your participation as the proposed library is small and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and propose improvements. PolyCollection implements fast containers of polymorphic objects. Typically, polymorphic objects cannot be stored directly in regular containers and need be accessed through an indirection pointer, which introduces performance problems related to CPU caching and branch prediction. Boost.PolyCollection implements a novel data structure that is able to contiguously store polymorphic objects without such indirection, thus providing a value-semantics user interface and better performance. Three polymorphic collections are provided: * boost::base_collection * boost::function_collection * boost::any_collection dealing respectively with classic base/derived or OOP polymorphism, function wrapping in the spirit of std::function and so-called duck typing as implemented by Boost.TypeErasure. The library can be found here: Incubator: http://blincubator.com/bi_library/polycollection/?gform_post_id=1643 Github: https://github.com/joaquintides/poly_collection and the documentation here: http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html Please post your comments and review to the boost mailing list (preferably), the Boost Library Incubator. 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? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Waiting your reviews! Ion

13 51

[review] Review of Nowide (Unicode) continues - summary of the dicussions so far
by Frédéric Bron 15 Jun '17

15 Jun '17

Dear all, The formal review of Artyom Beilis' Nowide library continues until Wed. 21st of June. Here is a summary of the discussions so far: 7 people participate to the review (not counting Artyom and my-self): - Degski - Niall Douglas - Paul Groke - Peter Dimov - Vadim Zeitlin - Yakov Galka - Zach Laine 2 official reviews have been shared, both positive for inclusion in boost (Degski, Peter Dimov). Discussions: Everybody is positive about the usefullness of the library but some major questions arose: 1. how should we handle invalid Unicode sequences (bytes or multi-bytes)? Allow? throws error? 2. there is an unsymmetric way of treatment between Windows and Posix: - on Windows, the conversion from UTF-16 checks for Unicode conformance and returns only valid UTF-8 or fails - on Posix, no check is performed that the input is a valid UTF-8 sequence. 3. in particular, on Windows, the roundtrip conversion UTF-16 -> UTF-8 -> UTF-16 is not guaranted if the initial string is non conformant One main issue is that existing files may have non conformant names and would therefore not been reachable by the nowide API on Windows. On Posix platforms, non conformant paths would work transparently. Different proposals have been made to address this: - convert from UTF-16 to a superset of UTF-8 so that the round-tip conversion is possible, this would mean that the library accepts non conformant strings on Windows as is done on Posix. Question: which enconding should be used (Modified UTF-8, WTF-8, CESU-8)? WTF-8 has the issue of being difficult to handle with string concatenations. - use RtlUTF8ToUnicodeN functions which replace wrong UTF-16 characters by U+FFFD but is this OK for round-trip? - see glib approach - add function to explicitly convert from wide to WTF-8 However, for the Posix case, the issue is that we cannot guarantee that the encoding is always UTF-8 so checking for conformance may be impossible. Hence the choice for not checking on Posix. Minor points: - Missing some documentation on what happens if invalid UTF-8 is provided (getenv, setenv, cout, cerr). - ::setenv on cygwin gives a compile time error (Peter Dimov proposed a fix) - suggestion to add stat and readdir Frédéric

1 0

Packt: Mastering Git - Jakub Narębski
by degski 15 Jun '17

15 Jun '17

To those interested. On Packt, the ebook Mastering Git - Jakub Narębski <https://www.packtpub.com/application-development/mastering-git> is today avaialble for free download, free membership (registration) required. I don't work for Packt. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

1 0