- Boost - lists.boost.org

Serialize a an image with Boost & GIL
by Visual Designer - Digital Team 13 Apr '16

13 Apr '16

Hi, I'm currently using boost serialization in order to save/load my data structure. The problem is that it contains some images and even with the ZIP compression the files are really big (4x bigger than the jpeg). So, I'm looking for a way to compress a RGB/A image (HDR or not) (without file operation) in memory. If possible without using any image compression library, we already use OpenImageIO but it is not possible for now ! Any idea ? I have found the GIL library, but can't find how to: 1) convert raw to GIL image 2) serialize the GIL image 1) deserialize the GIL image 2) convert the GIL to raw image Of course, the goal is to have a good compression without writing temporary file ! Thanks --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 3

[endian] Some suggestions
by Tatsuyuki Ishi 13 Apr '16

13 Apr '16

Mr. Beman, Here are some suggestions for the endian library. 1. Bring back float: make a proper reason for abandon You told about NaN: but it shouldn't apply since you store it in char buffer. Provide a proper reason: float is still needed since this is the only library that wraps details (platform endianness detection+compiler builtin optimizations). Float points are indispensable in data formats. I have to do a reinterpret_cast now as a workaround. 2. Remove n_bits(endian buffers): completely useless This just look like an alternative to sizeof, and always /8'd when used. What's the meaning of that? 3. Minor API suggestions Move operator type to endian_buffer: it's not related to arithmetic but just used because it can act like an integer. Non-const data(): I'm tired to do reinterpret_cast. Look at C++11 vector for a reference. Move stream operators to endian_arithmetic: I first thought that was for reading binary. That's basically unused.

9 19

Re: [boost] [endian] Some suggestions
by Tatsuyuki Ishi 13 Apr '16

13 Apr '16

> > 1. Bring back float: make a proper reason for abandon > > You told about NaN: but it shouldn't apply since you store it in char > > buffer. > > > > The problem isn't when storing into the char buffer, but later on a > different machine or compiler when the char buffer has to be converted to a > float type. I know nothing other than float format differences, and my target platforms are using iec559. I think reinterpret_cast should work: char data shouldn't be changed as long as stored as char. > > In testing, I even ran into a case were on the same machine and compiler > the float data failed to round-trip correctly if the program that created > the file was compiled with a different set of optimization options that the > program the read the file. > I will be happy if you provide some example. > > > > > 2. Remove n_bits(endian buffers): completely useless > > This just look like an alternative to sizeof, and always /8'd when used. > > What's the meaning of that? > > > > Please give a specific code example from the docs of what you think should > be changed. Or submit a pull request. > Since this is breaking API, I'd like you to make the decision to change it or not. For detail, this is the endian_buffer definition: template <order Order, class T, std::size_t n_bits, align A = align::no> class endian_buffer; n_bits looks quite useless here. It's basically sizeof*8. > > > > > 3. Minor API suggestions > > Move operator type to endian_buffer: it's not related to arithmetic but > > just used because it can act like an integer. > > > > Again, what code is it you think should be changed? Operator value_type()? > Please submit a pull request. > Exactly: operator value_type(). This will provide much more convenience. An example: when you specify the size for the array: endian_buffer size; dynarray d(size.value()); vs dynarray d(size); > > > Non-const data(): I'm tired to do reinterpret_cast. Look at C++11 vector > > for a reference. > > > > What is the motivation? What are the safety implications? What are the > alternatives? The C++11 (and also C++17) addition of non-cost data() > members to some standard library containers was supported by motivation and > safety analysis. > Seems endian_buffer is targeted for using in structs. Then is there any problem to provide a wrap of reinterpret_cast? At least, it should be safe by design. > > > Move stream operators to endian_arithmetic: I first thought that was for > > reading binary. That's basically unused. > > > > I must be missing something. Why wouldn't stream operators apply to endian > buffers? A code example might help. > Quite confusing. I first thought that was binary r/w operators that reads/writes the stream and store the value. The problem is that, there's no method provided for reading from binary, so this is also a reason for the previous data() suggestion.

2 1

[iostreams] Maintainer not working
by Tatsuyuki Ishi 13 Apr '16

13 Apr '16

Seems nobody is doing code review for iostreams since February. Basically I want a PR being merged: https://github.com/boostorg/iostreams/pull/25 This patch and some others looks good to me. It fixes a quite annoying warning. Can anybody with permission merge it?

1 0

[Coroutine] What happened to WINFIBERS?
by Tobias Loew 12 Apr '16

12 Apr '16

When testing 1.61 beta I couldn't find any reference to BOOST_USE_WINFIBERS in the sources and also the WinFibers implementation-file "execution_context_winfib.ipp" was missing. Has support for windos-fibers been removed? Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Coroutine-What-happened-to-WINFIBERS-tp4… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

Compiling boost_thread on CentOS 7 32 bit system
by Kristian 11 Apr '16

11 Apr '16

Hi, I am trying to build boost 1.60 on a CentOS 7 32 bit system. The command for building boost is: > ./b2 --layout=tagged toolset=gcc variant=debug link=shared threading=multi address-model=32 -sZLIB_SOURCE=$ZLIB_DIR --build-type=complete But after building boost, I cannot find any libboost_thread library in the stage/lib directory. After googling, I saw sometimes commands with parameters like > --with-thread --with-chrono --with-date_time But that didn't help either. After the second try, I only saw these files: > libboost_chrono-mt-d.so > libboost_chrono-mt-d.so.1.60.0 > libboost_chrono-mt.so > libboost_chrono-mt.so.1.60.0 > libboost_system-mt-d.so > libboost_system-mt-d.so.1.60.0 > libboost_system-mt.so > libboost_system-mt.so.1.60.0 Can someone tell me, what I am missing here?

2 1

[Nowide] Review Manager Needed
by Artyom Beilis 11 Apr '16

11 Apr '16

Boost.Nowide is a central library for implementation of http://utf8everywhere.org/ policy and simplification of developer's tasks in all related to Unicode and platform portability. http://cppcms.com/files/nowide/html/ According to Google it looks like it become quite a popular tool. It still looks for a review manager. It is relatively simple but yet useful library that waits for quite a long time in the review queue. Volunteer for review manager is needed. Artyom Beilis

2 2

[iostreams] basic_array_source: improper constructor argument
by Tatsuyuki Ishi 08 Apr '16

08 Apr '16

Since this is a 1-minute fix, I won't open any tickets: template<int N> basic_array_source(char_type (&)[N]); -> template<int N> basic_array_source(const char_type (&)[N]); Since iostream sources are read-only, this should be const.

1 0

[Root Pointer] Seeking a Review Manager
by Phil Bouchard 08 Apr '16

08 Apr '16

Greetings, - "Root Pointer" is an alternative to the long unsolved problem of garbage collectors which lasted for more than 70 years! - Thanks to Paul A. Bristow for his help on the generation of the documentation which is now available at the following link: http://philippeb8.github.io/root_ptr/ (I apologize for the misplaced images in the rationale) - The library itself can be found here: https://github.com/philippeb8/root_ptr/ All examples and tests compile fine with BJAM with GCC and MSVC. - Also here is a quick overview on the benchmarks: Single threaded: unique_ptr (new): 43.2705 unique_ptr (make_unique): 42.4111 shared_ptr (new): 68.9101 shared_ptr (make_shared): 46.6575 shared_ptr (allocate_shared_noinit): 31.2334 root_ptr (new): 30.3701 Multi threaded: unique_ptr (new): 42.1397 unique_ptr (make_unique): 43.4631 shared_ptr (new): 76.4543 shared_ptr (make_shared): 76.6611 shared_ptr (allocate_shared_noinit): 81.9926 root_ptr (new): 66.3417 - An example of its usage can be seen here: https://github.com/philippeb8/root_ptr/blob/master/example/t100_test1.cpp We can see in the aforementioned link that outputting part of a complex graph, cyclic or not, can be done in the following simple way: cout << "Mind dump:" << endl; cout << * t100 << endl; cout << "Searching for: \"einstein\"" << endl; if (node_ptr<neuron_base> p = t100->search("einstein")) cout << p->sort().unique() << endl; cout << "Searching for: \"graviton\"" << endl; if (node_ptr<neuron_base> p = t100->search("graviton")) cout << p->sort().unique() << endl; Sincerely yours, -Phil

6 26

[clang][preprocessor] Testing of clang emualting the VC++ preprocessor on Windows
by Edward Diener 07 Apr '16

07 Apr '16

I have made local changes in the Boost preprocessor config.hpp on the 'develop' branch to have clang's emulation of the non-standard VC++ preprocessor act like the VC++ preprocessor as far as Boost PP is concerned. Boost PP has a large number of workarounds for VC++ without which Boost PP preprocessor code would not work when compiling using any version of VC++. I have tested the usual compilers extensively to make sure they are unaffected by these changes as well as the normal clang-linux implementation. Everything remains the same for these compilers with my changes so I am assured the changes will not affect any other compiler implementation. I was able to test both clang-3.8 and the latest build of clang, which is clang-3.9, by invoking clang-cl. My user-config.jam file for these entries looks like: using clang-win : 3.8 : SomePath/clang-cl : <compatibility>vc12 using clang-win : 3.9 : SomePath/clang-cl : <compatibility>vc14 By passing toolset=clang-win-3.8 or toolset=clang-win-3.9 I was able to successfully test these implementations against the Boost PP test code. There are quite a few failures in this clang emulation of the VC++ preprocessor when tested against the preprocessor test code. In fact testing clang emulation of VC++ preprocessor when I don't treat clang as VC++ in Boost PP, but as its normal C++ standard conforming preprocessor, still fails a few cases but far less than when clang is treated as VC++ in Boost PP. Needless to say when invoking clang-linux, which tests the normal clang implementation whether on Windows or Linux, there are no failures in the Boost PP tests. I am perfectly willing to push my changes to 'develop' for the preprocessor. The changes are essentially just in the Boost PP config.hpp file, which sets macros which control the compiler workarounds in Boost PP. As I have previously stated I am not personally willing to try to figure out or report to clang why their VC++ preprocessor emulation in Boost PP is failing, but others who are interested can do so if they wish. My personal reasons for this is that I think it is a very bad thing to attempt to replicate an already flawed C++ preprocessor in another compiler in general code. I also have spent enough time working with the VC++ preprocessor trying to find workarounds for its non-standard behavior that I do not want to do so for another preprocessor which attempts to be non-standard. I posted this to alert others to my plans to update Boost PP on 'develop' with this change, in case anybody is greatly opposed to it or wants to discuss it further. The change will not affect any other compiler but clang in VC++ preprocessor emulation mode. Unless I hear objections etc. I plan to push my update within the next day although I will wait awhile for any replies to this post.

8 31