March 2005 - Boost - lists.boost.org

Reporting non-fatal errors in Boost libraries
by Aaron W. LaFramboise 13 Mar '05

13 Mar '05

Most of the time when a library routine encounters an error, that error is fatal, and the proper course of action is fairly obvious: throw an exception, return a singular value, or similar. However, in some cases, we encounter errors that are non-fatal, and simply giving up is not the most appropriate course of action. The error encountered may be inconsequential to successful completion, or we may have gotten notification of the error too late for it to make a difference, or design considerations may prevent us from terminating. A common example is encountering an unrecoverable error in a destructor while closing a file. These errors must be reported. However, without making special provisions for doing so, its unclear exactly how to report them. As we're in code for generic libraries, suggestions such as printing to std::cerr are clearly unacceptable. We also want to avoid encumbering the library interface with error-handling clutter that may never be used. How should Boost libraries be designed so as to allow these errors to be reported? Do existing Boost libraries have problems with these situations, and if so, how have they solved it? Aaron W. LaFramboise

4 5

To whomever modified Boost Web Site index.htm last time, and didn't check it into CVS
by Misha Bergal 13 Mar '05

13 Mar '05

I might have incidently lost your changes :-(. Next time please follow the instructions at http://tinyurl.com/5oyp4. -- Misha Bergal MetaCommunications Engineering

1 0

[type traits] is_convertible issue
by David Abrahams 13 Mar '05

13 Mar '05

Hi, Mike, a Boost.Python user, ran into a problem that amounts to this: #include <boost/type_traits/is_convertible.hpp> struct S { virtual void f()=0; }; boost::is_convertible<S&,S> error; Shouldn't is_convertible handle cases like this by stripping references before testing? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: What I Hate About How We Abstract System Dependence
by Don G 12 Mar '05

12 Mar '05

I agree completely. It's nice to have a common/portable framework, but it is unrealistic to assume that the framework will be sufficient for all use cases. This is true going both directions though. I'll pick on files because they are easy<g>. There are FILE*, iostreams, int fd, etc.. There is a bidirectional relationship between FILE* and int (via fileno/fdopen), but no connection between those int's and whatever native type is used (ex: HANDLE in Windows). Visual C++ has undocumented methods to create a suitable int from a HANDLE, which allows one to pass any native flags or what-not when opening the HANDLE and still use the rest of the standard library. To be truly useful, a portability library must provide some means to connect to the native system and do so bidirectionally where possible. In my own code, I provide get_native() methods to get the native artifact and document the semantics as non-portable. I also provide a way to create classes given already created native "objects" (where appropriate). This kind of support differentiates libraries that have aesthetic appeal from those that work in the real world (IMHO). <digress>This has been a bone of contention I have with the C/C++ standard bodies. Given the computing environment today, there should at least be a Windows and *nix annex that describe non-portable, but yet standard bindings, much like CORBA does with languages. Any other environments that wanted to define their own annex should also do so. But, I've been around long enough to know the chances of this actually happening.. :( </digress> Don --- David Abrahams <dave(a)boost-consulting.com> wrote: > You have to understand, the Boost.Threads specification was > designed to become a standard, and as such it didn't include > anything nonportable. That said, there's no reason we shouldn't > expose the low-level thread IDs and document them in a special > section on platform specifics. __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0

msvc + dinkumware?
by Bronek Kozicki 12 Mar '05

12 Mar '05

I need to build boost (more precisely Boost.Regex) on MSVC6 with Dinkumware (ie. resulting dynamic libraries should link directly with Dinkumware C++ runtime). Any ideas how to do it? TIA B.

5 11

[multi_array][RFC]fixed (or compile-time) ExtentList
by Larry Evans 12 Mar '05

12 Mar '05

In view of recent posts: http://article.gmane.org/gmane.comp.lib.boost.devel/119358 http://article.gmane.org/gmane.comp.lib.boost.devel/119684 suggesting an interest in fixed size matrices (I guess in order to speed execution) would it be desirable to have a variation of multi_array where ExtentList was one of the template arguments instead of an argument to the CTOR, as described here: http://www.boost.org/libs/multi_array/doc/reference.html#multi_array ? Of course the ExtentList would just contain compile time constants, something like mpl::vector_c<mpl::pair<index,index>,....> where: typedef multi_array_types::index index; and the args to pair<index,index> would correspond to the args to extent_range::extent_range(index start, index finish) where, of course, extent_range is the current multi_array class.

1 0

Updating Boost web site
by Misha Bergal 12 Mar '05

12 Mar '05

What is the process for updating the content of main Boost web site? -- Misha Bergal MetaCommunications Engineering

3 4

FSM Review
by Iain K. Hanson 12 Mar '05

12 Mar '05

I have a serrious problems with this library. FSM is a design pattern and they can be spellt in a wide variety of ways. E.g state transition tables Deterministic Finite Automata, Coloured Petri Nets, and Harrel / UML state charts. There are equallly, many ways of implementing FSMs. Calling this library the FSM libray would be like submitting multimap and calling it the collections library. * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? On the whole, the documentation looks fairly good. Some nits are that the exampls use upper case class names and can be confusing when the same name is used for a template parameter. The performance charcteristics should have been formally documented before it came forward for review. * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? This is where I have a problem. I don't have any problem with specifying an FSM using UML notation and certainly there plenty of users that will like this. But any state chart can be collapsed into a state table and there is no good reason that event dispatch performance has to suffer. The documentation suggests that Visitor patter / double dispatch is used. and it looks like ( from the code ) that states are iterated over from outer most to inner most searching for a state willing to consume the event. The performance of event dispatch will decay linnerly with the depth of the states. I can see not good reason why event dispatch could not be achieved with constant time. The reason it is like this is that the author has used state chart concepts for the design. The state_machine class has a total of 5 conatiners ( two std::list and three std::map ) two of the maps are for history and are present even if you don't specify history. This library does not follow the C++ convention of you only pay for what you use. The author has already admitted in discussion on the list that FSMs that generate events at high speed would not be appropiate for this library. Because of the libraries design a seperate async version was needed that requires mutexs. There are many situations where I would prefer to use a re-enterent disign using flyweight singleton states. TTThis tradeoff is not possible with the current design. Because of the above I vote against inclusion of this library into boost. * Are you knowledgeable about the problem domain? I have been building FSMs for the last 20 years as they are the one of the most common patterns I use. I have build them in assembler, C, C++, and Java and none of them have ever required the space and time overhead of this library If this library is accepted into boost I will continue building my FSM by hand, use Alexsey's FSM, or SMC or even boost function. 3. Exception handling support: Several people have rightly pointed out that the rationale for the exception handling support is too thin. The problems here stem from the design. 4. On some compilers (e.g. gcc), the asynchronous part of the library and most of the tests currently cannot be compiled with RTTI turned off. It is an unnecessary overhead that is an artifact of the design. * Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it useable for embedded systems? Is the documentation clear on performance tradeoffs? I've discussed these above. I don't believe real-time system designers would consider using this library. It is to heavey weight in both space and time, they have to jump through extra hoops such as writting a custom alloactor and custom class operator new/delete to overcome the libraries use of heap allocation. And they definately won't like non constant time event dispatch. /ikh

10 42

[type_traits] fully qualified names
by Jody Hagins 12 Mar '05

12 Mar '05

The coding guidelines document (boost/more/int_const_guidelines.htm), states the following... Always use a fully qualified name to refer to an integral constant expression. For example: typedef myclass< ::boost::is_integral<some_type>::value> mytypedef; Rationale: at least one compiler (Borland's), doesn't recognise the name of a constant as an integral constant expression unless the name is fully qualified (which is to say it starts with ::). However, it appears that the same compiler (BCB6) has problems if the '::' is left in. For example... template <class T> struct Foo { typedef typename ::boost::remove_reference< T >::type type; typedef typename ::boost::add_reference< typename ::boost::add_const< type >::type >::type ref_to_const_type; }; fails to compile. Initially I thought it had something to do with typename (e.g., another BOOST_DEDUCED_TYPENAME) because, the first, simpler line compiles if I remove the "typename" keyword. Unfortunately, the following does not compile either template <class T> struct Foo { typedef ::boost::remove_reference< T >::type type; typedef ::boost::add_reference< ::boost::add_const< type >::type >::type ref_to_const_type; }; After seeing a notice on this list a few minutes ago, I decided to remove the '::' and whaddya know... template <class T> struct Foo { typedef typename boost::remove_reference< T >::type type; typedef typename boost::add_reference< typename boost::add_const< type >::type >::type ref_to_const_type; }; this compiles correctly. So, I am left scratching my head, wondering what to do if I want to use TypeTraits in a portbale manner. Thanks!

5 9

Re: [boost] Re: [review] hash functions
by JOAQUIN LOPEZ MU?Z 12 Mar '05

12 Mar '05

----- Mensaje original ----- De: Alberto Barbati <abarbati(a)iaanus.com> Fecha: Viernes, Marzo 11, 2005 9:01 pm Asunto: [boost] Re: [review] hash functions > Hi, > > I have a doubt about the proposed implementation of hash_value() > for > pointers, which is: > > template <class T> inline std::size_t hash_value(T* v) > { > return static_cast<std::size_t>(v - (T*)0); > } > > this code calls for undefined behaviour according to §5.7/6, each > time v > is a non-null pointer. > > IMHO, the only reasonable way to map generic pointer values to > integer > values is through reinterpret_cast<>. The mapping would be > implementation-defined, but it would be no worse than the intent > of the > proposed implementation (if it worked). Agreed. > > To be picky, in order to accomodate with implementations that may > have > sizeof(size_t) < sizeof(T*), we should use two casts: > > template <class T> inline std::size_t hash_value(T* v) > { > return static_cast<std::size_t>( > reinterpret_cast<boost::uintmax_t>(v)); > } > > (the right thing would be to use a C9X-ish uintptr_t type, but > boost/cstdint.hpp does not provide such a type). > > However, as the double cast may result in suboptimal code if > size_t is > large enough, a boost::enable_if trick might be used to provide an > optimized version with just a single use of reinterpret_cast. The > result > would be something similar to: [...] Please, no SFINAE! This would break not-so-conforming compilers. Let's stick to compilerwise macro-based branches. After all, for the vast majority of platforms (AFAIK) sizeof(size_t)==sizeof(T*) > > Unfortunately, there's one more thing... even if p == q, > reinterpret_cast<uintmax_t>(p) is not guaranteed to be equal to > reinterpret_cast<uintmax_t>(q) on implementations that have > multiple > internal representations for the same address. I don't think much > can be > done (in a portable way) for such platforms. > Another reason for resorting to macro-based alternatives, and not to SFINAE. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1