- Boost - lists.boost.org

[log] Documentation v2 mini review
by Klaim - Joël Lamotte 19 Jan '13

19 Jan '13

Hi, I took some time to read the new Boost.Log documentation, at leas the beginning and the parts that interest me the most. First, it is very complete and clear, so this is good. I didn't try the code yet but will report about it in coming weeks (I guess it's ok as no mini-review date have been set yet so I'll not be late). Here are some remarks, which are all minor improvements. Design overview: ================ 1. "The library was designed to be very modular and extensible." Maybe starting with "this library" or "Boost.Log" instead of "the library" would be clearer. Next: "The logging library " - remove this repetition. 2. "Both narrow and wide-character loggers provide similar capabilities, so through most of the documentation only the narrow-character interface will be described. The library provides configuration facilities to compile only the version of the library that's needed." So the recent changes you did concerning wide/narrow characters don't affect this part of the documentation? 3. The picture is good. A minor improvement: it would have been better if there was a clear sense that sources and sinks are unrelated. One possibility would be to have crossing arrows in the logging core to express the possibility of having custom source routed to alarms for example. It's a minor improvement anyway, I just fear that visual alignement suggest a direct relationship between sinks and sources. A simpler possibility would be to make the sinks smaller and unaligned from the sources, like this: +-----------+ embedded loggers => | | | | => logs | | | Logging | => (something else) global loggers => | | | core | => alarms | | | | => statistics custom log sources => | | +-----------+ Formatting might be wrong in your email interface so here is the same with right formatting: http://pastebin.com/itPRd66k Which I think would make clear that both concept are not directly linked. 4. " - from parts of your application at the left to the final storage, if any, at the right" It seems that there is a missing coma? Maybe: " - from parts of your application, at the left, to the final storage, (if any) at the right" 5. In this document (and other pages), you are often listing different kind of things. I think it might be even clearer or fast to read if you used bullet points when you are listing possible variants. For example, attribute sets kinds could have each their bullet. To be clear: the current doc is fine as it is now, it's only a potential improvement remark. Trivial logging with filters ============================ 6. "The filter is built as a lambda expression." Maybe a remark related to C++11 lambda might be important here (or before)? To explain the difference with what you're doing in the example. Because it's not obvious here that you're utilizing another library to accept another style of lambda. In general, a note about supporting or not C++11 might be helpful as this library will be new to boost distribution users. Hope it helps. Joel Lamotte

2 3

[Serialization] Bizarre bug - reviewed
by Tobias Loew 17 Jan '13

17 Jan '13

I just came across the following bug http://boost.2283326.n4.nabble.com/Serialization-Bizarre-bug-td2612558.html and noticed that the bizarre behaviour is still reproducible (I used boost-version 1.52). I could figure out that in the buggy build there is an additional static initialization of the singlenton<T>::instance in boost\serialization\singleton.hpp in line 149 at startup > serial_bug.exe!`dynamic initializer for 'boost::serialization::singleton<boost::archive::detail::pointer_oserializer<boost::archive::text_oarchive,std::vector<char,std::allocator<char> > > >::instance''() Zeile 149 C++ which leads to a call of set_bpis in iserializer.hpp line 347. Thus, std::vector<char> will be saved (but NOT loaded) through a pointer. For apps that store and load the same types the problem usually does not arise, but for server/clients this may not be the case (e.g. apps using the RCF-library) Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Serialization-Bizarre-bug-reviewed-tp464… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Changes to VS 2012 config
by Marshall Clow 17 Jan '13

17 Jan '13

Just so people know - I'm updating the Visual Studio configuration to more accurately reflect the capabilities of VS 2012. The first step was in http://svn.boost.org/trac/boost/changeset/81613 ; the next step will be to update the compiler features. If you see any problems, please let me know. -- Marshall

14 26

Interest in breakable labeled scope emulation?
by TONGARI 16 Jan '13

16 Jan '13

Hi all, One of the few things I appreciate in Java is the labeled-break feature. I think C++ would provide it as well in future standard but it seems that there's no even such a proposal. In lack of the language feature, a simple emulation can be used: --------------------------------------------------- #define BOOST_SCOPE(name) \ if (const bool LABELED_SCOPE_##name = false){break(name); name:;} else #define break(name) \ (void)LABELED_SCOPE_##name; goto name; --------------------------------------------------- Now we can write: BOOST_SCOPE(a) { break(a); cout << "123\n"; } The real world usage would reside in nested loop&switch where labeled-break really shines. Thoughts? Sorry if this idea is too simple and somewhat rejected before...

7 22

[thread] Can Boost.Thread use Boost.Atomic without falling on a compatibility issue?
by Vicente J. Botet Escriba 14 Jan '13

14 Jan '13

Hi, in order to fix this issue, https://svn.boost.org/trac/boost/ticket/5752 : "boost::call_once() is unreliable on some platforms", I would like to use Boost.Atomic as suggested on the ticket. As Boost.Atomic is not a header-only library the user would need to link with boost_atomic. Is this an acceptable change? I'm requesting this as recently there were some people reactive to some changes in Boost.Thread. Would this be considered an compatibility issue? If yes should the fix for the call_once issue be included if the user request it using conditional compilation or even go on a separated version of Boost.Thread? Thanks, Vicente

6 44

[serialization] round-trip serialization of float
by Adam Lerer 14 Jan '13

14 Jan '13

The boost serialization of float doesn't appear to use enough digits to guarantee that deserialization of a serialized value will produce the same value. The relevant code is in boost/archive/basic_text_oprimitive.hpp: void save(const float t) { os << std::setprecision(std::numeric_limits<float>::digits10 + 2); ... } std::numeric_limits<float>::digits10+2=8, but float actually requires numeric_limits<float>::max_digits10=9 decimal digits to guarantee unique representation. The code below (with boost/1.52) demonstrates the problem: #include <sstream> #include "boost/archive/text_iarchive.hpp" #include "boost/archive/text_oarchive.hpp" #include <iostream> int main(int argc, char **argv){ float oldf = -1.20786635e-05; std::ostringstream os; boost::archive::text_oarchive oa(os); oa & BOOST_SERIALIZATION_NVP(oldf); float newf; std::istringstream is(os.str()); boost::archive::text_iarchive ia(is); ia & BOOST_SERIALIZATION_NVP(newf); printf("before serialization: %.12g\nafter serialization: %.12g\n", oldf, newf); } // Output: // before serialization: -1.20786635307e-05 // after serialization: -1.20786644402e-05 Note: There's some discussion of this topic in a slightly different context here: http://boost.2283326.n4.nabble.com/serialization-Serialisation-deserialisat…

5 8

[thread] thread::join() + thread::interrupt() not reliable?
by Oliver Kowalke 14 Jan '13

14 Jan '13

Hi, following code does not work reliable - sometimes the output is thread_interrupted thrown by t1 in main(): false thread_interrupted thrown by t1 in fn2(): false done and sometimes I get an exception terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >' what(): boost thread: thread not joinable: Invalid argument I would expect that thread_interrupted will be catched in main() and fn2() as the documentation describes. Oliver #include <iostream> #include <boost/assert.hpp> #include <boost/bind.hpp> #include <boost/thread.hpp> void fn1( boost::barrier * b) { b->wait(); boost::this_thread::interruption_point(); } void fn2( boost::thread * t1, boost::barrier * b, bool * interrupted) { t1->interrupt(); b->wait(); try { t1->join(); } catch ( boost::thread_interrupted const&) { * interrupted = true; } } int main() { bool interrupted1 = false, interrupted2 = false; boost::barrier b( 2); boost::thread t1( boost::bind( fn1, & b) ); boost::thread t2( boost::bind( fn2, & t1, & b, & interrupted2) ); try { t1.join(); } catch ( boost::thread_interrupted const&) { interrupted1 = true; } t2.join(); std::cout << "thread_interrupted thrown by t1 in main(): " << std::boolalpha << interrupted1 << "\n"; std::cout << "thread_interrupted thrown by t1 in fn2(): " << std::boolalpha << interrupted2 << "\n"; std::cout << "done\n"; }

2 3

[1.53.0] Beta1 release available
by Marshall Clow 14 Jan '13

14 Jan '13

Boost release 1.53.0 beta 1 is now available from SourceForge. See https://sourceforge.net/projects/boost/files/boost/1.53.0.beta.1/ This release contains numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://www.boost.org/users/history/version_1_53_0.html. Please download the beta, give it a try, and report any problems you encounter. Thank you, -- The Boost Release Team Beman Dawes, Eric Niebler, Rene Rivera, Daniel James, Vladimir Prus and Marshall Clow.

3 4

Boost.iostreams on Android - Fails on multichar input filters
by Sukender 14 Jan '13

14 Jan '13

Hi, I found iostreams "filtering_stream_test" to fail under Android (32 bits, gcc 4.6, boost 1.52.0) : " Running 18 test cases... read_input_filter_test.hpp(88): error in "read_input_filter_test": failed reading from a filtering_istream in chars with a multichar input filter read_input_filter_test.hpp(101): error in "read_input_filter_test": failed reading from a filtering_istream in chunks with a multichar input filter " Note : I ran some tests by compiling on the host machine (64-bits Linux), then manually copying/running on the (emulator) device (using "adb push" / "adb shell"). I know Android is not actively maintained, but I need multichar filters (gzip_compressor & gzip_decompressor are multichar and thus fail). And I wonder why this test fails. I could not run the regression test on iOS, but my original code (using gzip_decompressor) works as expected under iOS, and Windows, and MacOSX. I have no clue about how to solve the issue. Any idea? Thank you. Cheers, Sukender

1 1

Re: [boost] Flow-based programming library for Boost?
by Marcus Tomlinson 13 Jan '13

13 Jan '13

>> * You use a bus of input/output untyped signals. Why the signals are not >> typed? 1. Flexibility - inputs and outputs can dynamically accept changing signal types. E.g. Varying sample size in an audio stream. 2. Less coding, more expandability - the component designer need not specify the types required at each input / output when configuring IO, only how many. Consider the situation where you would like to update a component to accept int instead of bool for one of its inputs. This would (in your implementation) require you to edit multiple sections of code. With DSPatch, you need only edit / add to the process method. 3. Allow for generic virtual base process method (explained below). >> * Why do you need that the process function be virtual? This is due to the way the circuit works in DSPatch. When a component is required to process, the circuit needs a way of triggering it without having to know anything about the specifics (input / output count, types etc.) of that particular component. A generic inherited virtual method guarantees this kind of catch-all interface. >> // 1. Derive component class from DspComponent >> // =========================================== >> class DspAnd : public DspComponent<DspAnd, InPort<bool>,InPort<bool>, >> OutPort<bool>> >> { >> typedef DspComponent<DspAnd, InPort<bool>,InPort<bool>, OutPort<bool>> >> base_type; >> public: >> // 2. Configure component IO buses >> // =============================== >> DspAnd(DspComponentBase& parent, Signal<bool>& x, Signal<bool>& y, >> Signal<bool>& o) >> : base_type(parent, x, y, o) >> { >> } These requirements for component construction are quite overwhelming. There is a lot to remember (and type) every time you need to create / edit a component. Besides, as mentioned before, flexibility is paramount with DSPatch. This kind of static IO configuration goes against DSPatch's design (more on this later). >> protected: >> // 3. Implement a non-virtual operator() method >> // ====================================== >> bool operator()(bool x, bool y) >> { >> return x && y; >> } >> }; Having to keep track of every component input and output (count, types, etc) in multiple places (constructor, operator(), and in external use) seems overly complex and difficult to expand on / maintain. And again, static IO configuration is quite limiting. >> void main() >> { >> // 1. Create a DspCircuit where we can route our components >> // ======================================================== >> DspCircuit circuit; >> // 2. Create the internal signals >> DspSignal<bool> i1, i2, o; >> // ======================================================== >> // 3. Create instances of the components needed for our circuit and >> connect the signals and the ports >> // ============================================================ >> DspRandBool randBoolGen1(circuit, i1); >> DspRandBool randBoolGen2(circuit, i2); >> DspAnd logicAnd(circuit, i1,i2,o); >> DspPrintBool boolPrinter(circuit, o); Firstly, I like how the signals are referenced externally and are common between all components. This is something I need to improve on in the circuit class. ATM there is a fair amount of data copying going on. I assume that in your idea of this type of implementation, there is still a means of disconnecting and reconnecting signals at a later point? Wiring and rewiring at runtime is a large emphasis of the DSPatch design. I'm not sure wiring at construction is all that important though -I especially don't think it should be mandatory. This looks like the kind of code you'd find in other dataflow libraries. However, this is exactly why I designed DSPatch, and why I designed it the way I did. In my opinion, the code is convoluted (doesn't read well). But alas, I fear that most people actually prefer this kind of syntax over mine. >> Components with several outputs should define a operator() returning the >> tuple of outputs. Much like your implementation of input configuration, tuples have to be defined at compile time and hence can't be adjusted at a later point. By design, DSPatch avoids static IO, in fact it tries to avoid anything that is static. Not only does DSPatch allow you to adjust IO types and runtime, you can add / remove IO dynamically too. E.g. An AI minimax tree where each node dynamically creates a new output, and a feedback input for each possible player move from current position. It may be worth mentioning (again) that DSPatch was originally designed for audio DSP applications (hence the name). Therefore runtime features like branch synchronization, dynamic routing, and adaptive IO signal types are all part of the core design requirements. These features then subsequently cover a very large range of applications, allowing for small, simple static circuits, to large, complex dynamic circuits. I hope this helps you understand why DSPatch is designed the way it is.

3 8