- Boost - lists.boost.org

Re: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION
by Brian Wood 26 Jun '12

26 Jun '12

Pete Bartlett: < snip > > Cons for 1) and 2): > - Always paying for the cost of #including <boost/throw_exception.hpp> > - All libraries are dependent on - and therefore become vulnerable to any > future breakages (if any) in - Boost.Exception. Is there a penalty for single threaded applications here? There's been discussion of the support for transferring exceptions between threads; are there aspects of that support that are unneeded in a single threaded context? Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Re: [boost] Interest in a "breadth first" algorithm?
by Brian Wood 26 Jun '12

26 Jun '12

Gary Powell: > > A while ago I needed to serialize and de-serialize a std::map and I > realized that the only interface was begin(), end() which of course meant > that re-creating this same map was the least efficient way possible, as all > the elements were added in sorted order. Because I wrote them out using > begin() -> end() So I wrote a breadth first template which takes a > container, a template to use as the core of a queue, a template for the > allocator, the container and a function to apply to the elements. > It doesn't quite do a true breadth first traversal because I don't look at > the inner data structure of the map, (works with sets as well) but instead > does a middle, then right, left push until it's hit all of the nodes. And > it doesn't copy the elements, it pushes the iterators, and calls the > function on that iterator when the length is 1. > It ended up speeding up my map recreation by about 20% (because I start > with a center enough node that it should never have to be rebalanced) at a > cost of about 5% to write it this way (It's more expensive to create the > queue, and traverse the map from center on out), for a roughly 15% gain in > speed. > Is there any interest this for boost? I've got working code but not any > documentation. And rather than spend a huge amount of time on that I'm > looking to see if anyone else has an interest in this. I'm interested. If you like I'll give you an investment in Ebenezer Enterprises [1]. If you post it here or send it to me, I'll probably use it in the archive available here -- http://webEbenezer.net/build_integration.html<http://webebenezer.net/build_integration.html> . [1] Past performance is not a guarantee of future results. > > "Come gather 'round people wherever you roam. And admit that the waters > around you have grown. And accept it that soon you'll be drenched to the > bone. If your time to you is worth savin'. Ahh you better start swimmin' or > you'll sink like a stone. For the times they are a-changin'" Bob Dylan Huh. Bob Dylan is from the Hibbing/Duluth part of Minnesota. In the days after you posted, that area received a summer's worth of rain in 36 hours. An 8 year old boy nearly died in the flooding when he was swept down a culvert. Thankfully he popped up a mile down the system and has been giving interviews since. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 1

Re: [boost] Boost and exceptions
by Stewart, Robert 26 Jun '12

26 Jun '12

Robert Ramey wrote: > Dave Abrahams wrote: > >> I mean, if there is a problem with boost::throw_exception or > >> any other part of Boost Exception, I'd like to know about > >> it. > > > > It seems clear to me from his posts that Robert wants to > > talk about the process and has forgotten any specifics about > > actual problems. > > > The problem was the gratuitious inclusion of a new dependency. Emil has described repeatedly why the change was not gratuitous. That you fail to recognize the value in the change does not make it gratuitous. I looked at a recent boost/throw_exception.hpp. It includes boost/exception/detail/attribute_noreturn.hpp. That creates a dependency inversion that is unfortunate. That is, a top-level header file depends upon a header file of a library's files. That header is very short and has nothing Boost.Exception specific, so the code could be moved into boost/throw_exception.hpp or boost/detail/attribute_noreturn.hpp, for example. The header also conditionally includes the non-trivial boost/exception/exception.hpp, another dependency inversion, which defines many types and functions, and includes some inline function definitions: boost::exception_detail::refcount_ptr boost:: error_info boost::exception boost::exception_detail::error_info_base boost::exception_detail::type_info_ boost::exception_detail::error_info_container boost::exception_detail::get_info boost::exception_detail::get_diagnostic_information() boost::exception_detail::copy_boost_exception() boost::exception_detail::set_info() boost::exception_detail::error_info_injector boost::enable_error_info() boost::exception_detail::clone_base boost::exception_detail::clone_impl boost::enable_current_exception() If BOOST_EXCEPTION_DISABLE is not defined, then boost::throw_exception() tacks on Boost.Exception features to the exception being thrown. This is a non-trivial set of changes to make to the top-level header. I didn't follow the discussion at the time, but I'll presume there was a lot of discussion about the type and extent of these changes and that it was considered a good idea. In hindsight, I agree with Robert's assertion that there should have been a replacement function, boost::exception::throw_exception() or similar, to introduce the new functionality. Whether the existing function needed to be deprecated is a separate issue. The result is that libraries could knowingly choose the new version, and a dependency on Boost.Exception, or, if warranted, stick with the old. As things now stand, if there is good reason to avoid the new version, it can only be done by defining BOOST_EXCEPTION_DISABLE, which affects an entire build. > The extent/nature of any problem it created or didn't create is > not relevant here. Just the injection of a new body of code > which replaced two lines and added no functionality used/needed > by the serialization library makes the any library which used > boost::throw_exception "bigger" for no reason. The issue you're raising, as I understand it, is dependency inversion: the top-level header brings a dependency on Boost.Exception. > It makes the library more "fragil". It means I have I a new > place to look if something needs looking into. etc.etc. As Nevin pointed out, your code will always be subject to the changes in those libraries on which it depends. The more dependencies you introduce, the more fragile your code becomes, but there's a great deal of benefit to reuse, too. The only issue in this case is that one can reasonably expect a top-level header to avoid dependencies on libraries. > So we'll just move on as Vicente suggested. That will be > satisfactory from my standpoint. That is the only way forward, if there is good reason to avoid the now longstanding changes to boost::throw_exception(). However, you should work with Emil to be sure you correctly and fully understand the issues before deciding that you cannot accept boost::throw_exception() as is. (I don't pretend to know what your concerns are. I just don't want to see a new throw_exception() variant if there isn't a compelling reason, and I don't consider your fragility argument compelling in this case.) _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

20 91

[contract] relaxing preconditions in subcontracting
by Andrzej Krzemienski 26 Jun '12

26 Jun '12

Hi Lorenzo, I am trying to understand how the feature of relaxing preconditions in overridden functions work or should work. Given the situation, where I call an overridden function via base class reference: *struct Base { virtual void fun(bool b) = 0 precondition{ b == true }; }; struct Deriv : Base { void fun(bool b) override precondition{ true }; }; void test( Base & b ) { b.fun(false); **// broken contract or not?** }* Should this be treated as a broken contract or not? My reading of the documentation says that contract is not broken (because the "logic-or<http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp…>" logic applies), but I feel that whoever implemented function *test *made a mistake: he cannot assume what type will be implementing "interface" *Base*, so he cannot rely on the precondition being relaxed (even if he gets away with it this time). Regards, &rzej

2 7

boost with cxxflags=-Zc:wchar_t-
by Renato Tegon Forti 25 Jun '12

25 Jun '12

Hi All, I'm mixing QT and boost and noticed problems with wchar_t! I need to compile boost: cxxflags =-Zc: wchar_t- Would like to know what problems I can find! anyone ever had to use 'wchar_t-"? Libs that I am using: boost_mpi boost_serialization boost_system boost_filesystem boost_thread boost_iostreams Thanks

3 2

library dependencies and boost modularization [ was Boost and Exceptions]
by Robert Ramey 25 Jun '12

25 Jun '12

Boost has now close to 100 libraries. In addition there are hundreds of smaller but necessary facilities which aren't technically libraries but they add a lot to the "surface area" that one's brain has to be familiar with to take best advantage of boost facilities. There is also a lot of interconnectedness which makes it an even larger task. This wasn't a big deal when boost was 15 libraries - but now it's different. I would like to propose a classification of boost libraries and guidelines for future libraries. a) Layering of libraries =============== 0) C++ standard library 1) "boost core" libaries 2) "boost utility" libraries 3) "boost user" libraries b) Guidelines ========= 1) a library in a given layer shall include code from libraries in a higher layer 2) boost core libraries are in namespace "boost" 3) boost user libraries are in the name space boost::<name of user library> 4) there is a special user library named "utility" for small libraries which are widely used. 5) boost header directory structures should match namespace structure. example, a library named boost.range should have all it's code in namespace boost::range and in the directory boost/range. 6) exception to 5) above, a user library might have a "convenience header" in directory "boost" which includes all the header directories of that user library. c) Rationale ======== 1) it diminishes the possibility of namespace conflicts as boost/C++ grows 2) it diminishes the possibility of importing a lot more code and depencies than one expected. 3) a library can control its depencies. Often a library will rely only on "boost core". This means that users of the library can know that code is dependent only on that library. 4) It more easily supports the concept of "boost modularization" where by deployment of a subset of boost libraries is can be supported. It's often mentioned how other languages like java, C#, perl have HUGE number of libraries in comparison to C++. I believe these languages have reached their peak and are in fact in decline somwhat. It is possible that this huge number of libraries make them less attractive rather than more? Perhaps a little more formal structure applied to our work might be agood thing. Robert Ramey

1 0

[serialization] Reading newer archives - was throwing unsupported_class_version, now crashes
by Nikolay Mladenov 25 Jun '12

25 Jun '12

Hi Robert, I remember that in the past the serialization library was throwing unsupported_class_version exception when reading of archives with future class versions. This no longer seems to be the case. We had older version of software crash when reading newer archive. The only place that I found to mention unsupported_class_version is commented out and I do not understand the attached note: BOOST_DLLEXPORT void iserializer<Archive, T>::load_object_data( basic_iarchive & ar, void *x, const unsigned int file_version ) const { // note: we now comment this out. Before we permited archive // version # to be very large. Now we don't. To permit // readers of these old archives, we have to suppress this // code. Perhaps in the future we might re-enable it but // permit its suppression with a runtime switch. #if 0 // trap case where the program cannot handle the current version if(file_version > static_cast<const unsigned int>(version())) boost::serialization::throw_exception( archive::archive_exception( boost::archive::archive_exception::unsupported_class_version, get_debug_info() ) ); #endif // make sure call is routed through the higest interface that might // be specialized by the user. boost::serialization::serialize_adl( boost::serialization::smart_cast_reference<Archive &>(ar), * static_cast<T *>(x), file_version ); } To allow class to read serialized objects of newer version by default seems very dangerous. I generally requires extra work from the class author and without it will most likely crash. So isn't it better to have an additional trait that a class author needs to define, if a class should be allowed read future versions? something like namespace boost{ namespace serialization { template<class T> struct allow_future_versions : mpl::false_ {}; }} #define BOOST_SERIALIZATION_ALLOW_FUTURE_VERSIONS(T) \ namespace boost{ namespace serialization \ { \ template<> struct allow_future_versions<T> : mpl::true_ {}; \ }} and change the code above to: BOOST_DLLEXPORT void iserializer<Archive, T>::load_object_data( basic_iarchive & ar, void *x, const unsigned int file_version ) const { // trap case where the program cannot handle the current version if( ! boost::serialization::allow_future_versions<T>::value && file_version > static_cast<const unsigned int>(version())) boost::serialization::throw_exception( archive::archive_exception( boost::archive::archive_exception::unsupported_class_version, get_debug_info() ) ); ...... Thanks in advance, Nikolay Mladenov Sitius Automation Inc.

3 10

[move] GCC bug and aliasing questions
by Tr3wory 25 Jun '12

25 Jun '12

Hi, Yesterday I started using Boost.Move in my project. On gcc I had the same problem like the guys here: http://lists.boost.org/Archives/boost/2011/07/184263.php Namely, I can't define the move constructor nor the assignment operators outside my class... After some time I managed to create a minimal example (19 lines) and sent a bug report to the gcc guys: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53725 So far, so good. In the minimizing process I found something interesting: the problem vanishes if I remove the __may_alias__ attribute from the rv<> class. This got me thinking. Do we need this attribute at all? The problematic expression is this: (It's in macros normally placed inside a class, TYPE is the name of this class.) operator ::boost::rv<TYPE>&() { return *static_cast< ::boost::rv<TYPE>*> (this); } But rv<TYPE> is derived from TYPE so to me it looks like the two type is compatible, therefore the code didn't violate the strict aliasing rules, so the attribute is not necessary. (BTW can we violate the strict aliasing rules trough static_cast if we don't do any chained conversion trough void*?) On the other hand, if it's really breaks the rules then we solved the problem for gcc, but we still have undefined behavior on every other compiler. Can we fix this somehow? Cheers, tr3w

3 5

An alternative approach to TypeErasure
by Pyry Jahkola 25 Jun '12

25 Jun '12

Hi all, I was quite impressed by Sean Parent's Friday talk in C++Now! 2012 (see slides in [1], code in [2]) and was left wondering whether the generation of his polymorphic object wrapper could be made simple somehow in C++11. [1]: https://github.com/boostcon/cppnow_presentations_2012/raw/master/fri/value_… [2]: https://github.com/boostcon/cppnow_presentations_2012/blob/master/fri/value… What I ended up with is tricking ADL into allowing the overloading of arbitrary (specifically crafted) function objects that I call _callables_, and then letting the user define interfaces by specifying sets of ("member") function signatures with a callable. You can find the code, and my rambling introductory README file, in GitHub: https://github.com/pyrtsa/poly Comments are welcome! * * * Here's a somewhat shorter intro: 1) Create a callable F by simply deriving it from poly::callable<F>: struct draw_ : poly::callable<draw_> {}; constexpr draw_ draw = {}; 2) Or use the convenience macro POLY_CALLABLE(name) to do the same: POLY_CALLABLE(to_string); // type `to_string_` and object `to_string` 3) Overload your callables by overloading the function named `call`, with the callable as first argument: template <typename T> void call(draw_, T const & x, std::ostream & out, std::size_t position) { out << std::string(position, ' ') << x << std::endl; } std::string call(to_string_, int i) { return std::to_string(i); } template <typename T> std::string call(to_string_, std::vector<T> const & xs) { std::ostringstream s; s << '['; auto i = begin(xs), e = end(xs); if (i != e) s << *i++; while (i != e) s << ", " << *i++; s << ']'; return s.str(); } Now you can call ::draw(x, o, p) and ::to_string(x) for several different types of x: ::draw(123, std::cout, 2); // prints " 123" to stdout ::to_string(std::vector<int>(1, 2, 3)); // "[1, 2, 3]" But you can likewise extend ::draw and ::to_string further by overloading them for your own types too. 4) Define an interface by specifying the set of function signatures as template arguments to poly::interface: using drawable = poly::interface< void(draw_, poly::self const &, std::ostream &, std::size_t, std::string(to_string_, poly::self const &)>; Now, the following calls got automatically defined, and forwarded to whatever type you successfully construct a `drawable` from: void call(draw_, drawable const &, std::ostream &, std::size_t); std::string call(to_string_, drawable const &); * * * I am aware that Steven Watanabe has put some astonishing work on his proposed Boost.TypeErasure. I'm open for discussion whether and how his or mine is a better approach, or if we could combine these into an eventual Boost.Interface library or such! * * * PS. Like I mention in my GitHub page, this kind of type erasure is common in functional languages like Haskell or Clojure. The problem they are solving there is known as the Expression Problem. IMO it makes very much sense to have the corresponding construct in C++ too, as we're moving towards a more and more functional style with parallelism and such. Best Regards, -- Pyry Jahkola pyry.jahkola(a)iki.fi https://twitter.com/pyrtsa

7 16

Multiprecision Review
by Phil Endecott 25 Jun '12

25 Jun '12

Dear All, Here is my review of the proposed Multiprecision review. First a rant: why have so few people contributed to the discussion or written reviews? I have waited until now before writing this in the hope that others would say something useful, but there has been very little to read. Boost will suffer as a result of this. It has been depressing to see that at the same time the mailing list has been full of other discussions, so the problem is not that people don't have the time to contribute. In particular, the long thread about Boost.Exception makes me want to shout "Why Didn't You Say All This When It Was Reviewed?". My view of the proposed library can be summarised as follows: it doesn't do what I want, but maybe it does enough things that other users would like to justify its acceptance anyway. Except probably it doesn't, because if it did those other users would have said so, which they haven't. In particular, I'd like to be able to implement integers of perhaps 128 or 256 bits that behave like the built-in integers. I can quickly throw together something myself that works OK but: - It's difficult to get the last bit of performance because you need to write asm to use the CPU's carry flag; the work-around probably results in a 2X slowdown. - Writing all the operator overloading etc. is tedious. - It's also error prone, as a mistake in e.g. carry propagation might be detected once in very 2^32 operations. It would have been great if this library could have helped with this. Instead, it has produced something worse than my "quick throw-together". It's worse because it has tried to unify this smallish fixed-size type with very large variable-size types, and the compromises necessary to achieve this have sabotaged the performance. It's also worse because it had a subtle bug - which has since been corrected, but I would still not be confident of getting correct answers without verifying against another implementation. Ideally, there would still be some parts of the library that could be useful to me. If the library had been decomposed into data structures vs. algorithms then perhaps I could have applied the algorithms to my simpler data structures. Unfortunately the library has not been organised in this way, and even if it had done the use of sign-magnitude representation might have scuppered any re-use. As far as I can see, the only part of the library that I could re-use would be the expression template front-end, which doesn't seem to improve performance for types of this size anyway. Here are my answers to the standard review questions: What is your evaluation of the design? Not great for my purposes; see above. What is your evaluation of the implementation? I spent half a day chasing down a bug. My observations are that (a) there are subtle bugs, and (b) the code lacks comments or other clues for people like me to quickly pick up what it's all doing. What is your evaluation of the documentation? Satisfactory. What is your evaluation of the potential usefulness of the library? Not useful for me; see above. Did you try to use the library? With what compiler? Did you have any problems? I spent perhaps a day working on a small but real benchmark which was discussed on the mailing list. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About a day-and-a-half in all. I've not looked beyond the areas that I've discussed and I'm aware that there is a lot more to the library i.e. non-integer types. Are you knowledgeable about the problem domain? Not especially. Do you think the library should be accepted as a Boost library? No, because (a) I'm not convinced from this discussion that lots of people are waiting for this functionality (see above). (b) Based on previous experience, I'm sceptical about the possibility of the performance of Boost libraries being improved after acceptance. Despite that, I thank John and Chris for their work which is a considerable leap forward from the last "big number" submission, "xint". Regards, Phil.

5 5