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 12 Mar '05

12 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

Re: review of proposed fsm library
by Dave Gomboc 12 Mar '05

12 Mar '05

> > Let us consider that we have multiple fsms and we would like to > > apply operations to these fsms, e.g. direct concatenation (the > > terminal state of one automata becomes the start state of another), > > or choice (depending on an action of, or an accept/reject by fsm a, > > proceed to execute fsm b or fsm c). This is apparently > > straightforwared when working at the level of states; however, the > > library draws a distinction between a state_machine and a state. > > This acts as a barrier to the direct composition of state machines > > that we would like to use as components within large state machines. > > A much better way to achieve that is with templated states, > as you seem to > have observed yourself. > > > The distinction made between state and state_machine, which I > > consider to be unfortunate, was not justified in the rationale. > > I didn't justify it because it feels natural to me that a > state machine has > only one event queue, and one place where history is stored (both are > containers inside state_machine). Admittedly, because the > outermost state > knows at compile time that it is the outermost state, the > state_machine class > template could be "abstracted away". You'd then only have > simple_state and > state. However, this seems at best obscure to me. class state_machine: public state, private state_control { ... }; is a possibility. However, leaving the control manager separate from the state data (structure) might be better yet. Why does this separation of concerns seem obscure? Perhaps the control manager can iterate over the state data structure? operator++ advances to the next state; operator() performs the reaction, etc. Okay, I've entered pure brainstorming territory :-), but really, things might be improved by not commingling data and control. > [snip] > > There is a brief note in the tutorial re: submachines that fails to > > do this topic justice. If the template approach recommended there > > is to be the canonical form for a reusable component, that style > > should be propagated through all but the simplest examples in the > > tutorial. Each submachine should clearly be labelled as part of its > > own .hpp file. > > While I might agree with your reasoning in theory, I don't > think that it would > work in practice. Even now I sometimes get complaints that > the examples are > too complex (too many templates) and changing all examples to > work with > templated states would make them even more so. Plus, often > there is no need to > use a state in more than one place, so why bother with > templated states then? I think problems with examples are alleviated partially when people can take the source files comprising the example, compile them, and see them run -- a success was achieved immediately. For instance, Boost.Serialization does this with at least some of its examples (demo_xml.hpp and demo_xml.cpp, if I recall correctly). It is not presumptuous for a coder to assume that their machine will never be needed in another context? If templating improves reusability considerably, while not costing much, then it should be done. However, if there are other obstacles to component reuse, rather than say it's not worth it to template these, instead say these other obstacles must be cleared. One cannot build a library of fsm components that may be connected together to build more complex fsms without this, but I continue to think that this would be very useful. > [snip] > > In the speed vs. scalability trade-off section of the rationale > > page, it is claimed that using an fsm for a parsing task is an > > abuse > > In its generality this remark is of course false and I should > have replaced it > with better reasoning long ago. What I want to say here is > that it is a bad > idea to use this library for parsing, as it is so general > that performance > tradeoffs are inevitable. For parsing, one is much better off > with a parser > framework, which is optimized for the task. The IMO important > observation is > the following: Parsers like Spirit only need to return when > they have finished > processing all "events" (characters). > > An FSM however must > return after > processing each event. Parsers can exploit this fact and > store state with > recursive calls, which is of course much faster (some stuff > can even be > inlined) than any super-clever double-dispatch scheme. > There is often a hard limit for stack space which - I think - > is the reason > why FSMs do make sense in parsers nevertheless. However, all > the FSM-employing > parsers I know are of the dynamic variant (e.g. regex) and > these FSMs are not > directly designed by humans but computed by an algorithm. For reading a identifier character-by-character, sure, one would not want to use an fsm to process each character individually. However, one can design the fsm to proceed to read an entire identifier at once. In situations where a parser might require extensive backtracking (and Spirit-1 doesn't actually backtrack after accepted symbols, which is something I could employ an fsm to work around!) the use of an non-deterministic FA may be well-justified. Also, if one is merely testing for the presence of a regular expression match, I agree that just signalling once when the match is complete is sufficient, however, often one wants substrings within a match that correspond to certain portions of the match, in which case actions at transition points may be a fine solution to the problem, both reasonably efficient and easily understood by the developer. Furthermore, the possibilities for error comprehension and recovery in a parsing process may be improved by the use of an fsm framework. It is certainly true that I have use for dynamically-arranged fsms -- and not only for parsing. It was a disappointment for me that I would not be able to do some tasks with this library. > Last but not least I > think it would be tedious for a human to implement a parser > on the state- > level, which is probably the reason why I dared to make the > admittedly dumb > remark in the first place. > I think Darryl puts this rather nicely: > <quote> > Fast flat fsms to process simple events and having little > additional context > are best implemented using other methods. However such > implementations are not > difficult, and there are plenty of domain specific tools > already (eg various > language recognisers). > </quote> This comment does not address myriad uses that I would have for an fsm library that met my needs. Don't forget that with the addition of storage, it's actaully fully Turing-complete, "fsm" notwithstanding. > > However, finite-state automata are inextricably linked with the > > acceptance of regular languages: see, for instance, section 12.2 of > > Keller (again, > > http://www.cs.hmc.edu/claremont/keller/webBook/ch12/) it is not too > > much to ask that an fsm library to be able to serve as the > > underpinning of a reasonably efficient regex library. > > See above. A regex library needs a dynamic FSM. Indeed, I had been hoping that the fsm library would accommodate such needs. I do, however, understand that one can't implement everything at once! > [snip] > > Other reviewers have also already commented upon the lack of a > > table-lookup dispatch method. From the rationale: > > "To warrant fast table lookup, states and events must be > > represented with an integer. To keep the table as small as > > possible, the numbering should be continuous, e.g. if there are ten > > states, it's best to use the ids 0-9. To ensure continuity of ids, > > all states are best defined in the same header file. The same > > applies to events. Again, this does not scale." > > > > However, I think that for table lookup there is no requirement that > > ids be consecutive -- a compile-time write-once read-many hash table > > could do the trick. > > Unless you use a perfect hashing algorithm (which is > infeasible because you > need to know all the ids beforehand), this would essentially > wreck the ability > to use this library in real-time systems. Hashed containers > are a bad idea for > real-time as there is no upper limit for a search operation. However, one would know the maximum dispatch time guarantee by the end of the compilation process, and it likely would be less time-consuming (where sufficient memory exists) than the linear search currently employed. > > While perhaps each state (compilation module) must know of its > > successor states, no central table of "current state x action x next > > state" encompassing the entire machine need be explicitly created. > > Which is exactly what this library is doing. There is a > lookup "table" within > each state and if that fails lookup considers the states > outer state. However, > this inevitably means that you cannot have constant time > lookup. The larger > your FSM becomes the longer lookup takes. BTW, as I've > written in another post > I don't see why reaction search is so important for people, > because in typical > FSMs I'd expect transition execution to be much more of a > performance hog. Perhaps it is because people would like the freedom to employ fsm in contexts that you did not target your solution for. As I'm sure you know, an fsm can be a very handy thing! > > Under the "Limitations" section, reference is made to "lost events": > > "It is currently not possible to specially handle events that > > have not triggered a recation (and would thus be silently > > discarded). However, a facility allowing this will probably be > > added in the not-too-distant future." > > If the event is irrelevant at that point in the state machine, it is > > most properly ignored. If it is not irrelevant, there ought to be > > a transition (perhaps a self-transition). Therefore, I don't > > understand the comment. > > There are applications of state-machines where an ignored > event consitutes an > error. Since the library currently does not allow to define > transitions that > are triggered by any event there is no easy way to handle > such "ignored" > events. In that case, it seems quite reasonable to add one as you planned. > > I have an uneasy feeling about how differently asynchronous and > > synchronous machines are operated, but did not consider this issue > > in detail. > > Why? They are rather different things aren't they? No, not really. Certainly, I would expect to be able to plug together an asynchronous and synchronous submachines into a larger, single fsm (which would need to be modelled asynchronously). > > Allowing the tracking of history is intruiging; the prohibition > > against deep history of states with orthogonal regions is > > suspicious. > > Why? Why not? > > The explanation given is that it would be more > > complicated (but still possible) to implement. > > It would be much more complicated to be precise. > > > In my experience, > > that sort of reasoning just doesn't fly at Boost. > > Why? Must I really offer all the functionality in the first > version of the > library? Very few people use deep history and orthogonal states in > conjunction. For those that do I describe a work-around. I > have not received a > single request to implement full deep history. Well, you've received at least one, but your response was 'why?'. ;-) > > The discussion of fork and join bars, combined with the event > > dispatch to orthogonal regions discussion immediately below that, > > suggests that the implementation is not truly designed to handle > > concurrent states. > > Why? Otherwise, these items would be addressed, that's why. But see below. > > I think, however, if one is to claim that UML > > statecharts are supported that the semantics of execution ought to > > be the same! I can well imagine that this "would complicate the > > implementation quite a bit", but Boost is also about interface, not > > only implementation, and if the wrong interface is standardized > > (whether de jure or de facto) it's worse for everybody in the end. > > The interface change for this is rather easy: Simply specify > multiple rather > than just one target state. I don't see the problem. > BTW, this is connected to deep history not working for > orthogonal sub-states. I suspected so. I believe it was caused by starting with the fsm having abilities that applied to one state at a time, then later adding orthogonality support but without a full conversion to supporting state-supersets in all places of the code. However, this is sheer speculation on my part and may well be wrong. :-) > > There is no explicit discussion of non-deterministic fsms. Of > > course, every such fsm can be re-expressed deterministically. > > I don't see why I should discuss that. Because people may want the ability to use epsilon-transitions, which NFAs support and make finite automata modelling considerably simpler in many cases. > > Similarly, a given fsm may be non-minimal, but such minimization > > procedures exist. Both of these procedures necessarily require a > > global view of the fsm. As this is contrary to the scalability > > requirement listed in the rationale, I conclude that neither are > > present. > > This has never been a goal and I don't see why I should provide such > functionality. Also I suspect that state-local storage could > prevent such a > minimization. > > > However, I would like to ask if (excepting possible > > compiler limitations) is there anything about the library that > > precludes extending it such that NDFAs could be specified in code, > > and converted into the minimized DFA during compilation? > > Yes, the scalability requirements. As I explain above (and > you seem to have > found that yourself) there is no way to have a global view at an FSM > implemented with this library. I am not suggesting that you provide this functionality yourself. What I am asking is that if another needs this functionality can they add code to your library to do it without too much trouble, or are there implementation considerations that make it impossible? It should be clear that if one intends to perform a NFA->DFA or DFA minimization that it is recognized that they are forfeiting scalability by requiring whole-machine view. > > We had tuple and mpl separately before fusion; it seems reasonable > > for boost to have both compile- and run-time fsm libraries, if > > ultimately they may be similarly fused. > > I don't think that is feasible unless you limit yourself to > FSMs specified in > single TUs so that a global view is possible. Hmm. :-/ > > I like this library, but I'm not satisfied with it. What level of > > library is good enough for boost? The library is not ready for > > standardization, however, this doesn't appear to be the standard > > that most people use when deciding upon their vote. This library is > > certainly good enough for people to make successful use of. > > > The "default" black disc in the diagrams is too large! Maybe make > > the radius about 2/3s of what it is now. > > I think the size is in line with the current UML standard, > but I'll check again. Sorry, I didn't realize that UML had picked a standard size. In Harel's paper, the default black discs were even smaller than what I had suggested. Dave

2 1

Re: Re: Re: FSM Review
by Dave Gomboc 11 Mar '05

11 Mar '05

> However, since each innermost state must know all its outer > states (1), > it is theoretically possible to collapse all the reactions of these > states into a STT that is local for each innermost state. At a rather > hefty price, this would give you constant-time lookup, > *separately* for > each innermost state. In FSMs with orthogonal regions multiple such > innermost states can be active at the same time, which makes lookup > linear again. Hence my previous remark to Dave. 1. And a state-superset transition table is not possible for compiler capability reasons? 2. You know, the NFA -> DFA conversion process is _exactly_ the process that one would use to take the state-supersets and flatten them out. Win: constant-time dispatch. Lose: scalability. Dave

2 1

[optional] new assignmet semantic and references
by Fernando Cacciola 11 Mar '05

11 Mar '05

Hello people, A few days ago, a problem with Boot.Optional's assignment not properly handling aliasing scenarios (like self assignment) was pointed out. We concluded that the solution was to use T's operator=() directly instead of the Destroy+Construct pattern that I was using. I changed the code, tested it, and I was updating the documentation when I recalled the following long-standing issue: Currently, with the Destroy+Construct pattern, references are re-bound in case of assignment: int a = 123 ; int b = 456 ; int& ra = a ; int& rb = rb ; optional<int&> ora(ra); optional<int&> orb(rb); ora = orb ; // now 'ora' contains a reference to 'b' instead of 'a' b = 789 ; cout << *ora ; Prints 789 cout << a ; Prints 123 This is not the way assignment of reference types work in C++: ra = rb ; // The value of 'a' referenced by 'ra' is changed, not the reference itself. cout << a ; Prints 789 This error in the way optional<T&> treated assignment of reference types was pointed out by Joel de Guzman long ago when he started using Optional in Spirit. However, at the time, Joel explicitely asked me not to change this and keep the current rebinding semantics in order to minimize any impact in Spitit itself (which certainly has, o had, a much larger user base). If I change the code now to use T's operator=(), assignment of optional<T&> will have a _radically_ different semantics. A correct one, that's for sure, but end user code might be fundamentally impacted. Note: if you look at Optional documentation you will discover that assignment is only documented for T not being of reference type. This was intentional.. I left this undocumented becasue I knew back then that the current semantics were wrong but I couldn't fix it at the time because Spirit was (or could be) depending on it; yet I didn't want other users to depend on it as well... Of course, users could have "discovered" the (incorrect) semantics themselves and now rely on it, but I hope that the intentionally missing documentation served to keep the amount of users depending on this incorrect semantics very low. [At least it served _me_ to remember about this since I had forgotten] I really want to 'fix' this, i.e, give it correct semantics, so unless Joel or anyone else speaks now I'll move on, finish the documentation updates and commit the new version. Best, Fernando Cacciola

6 26

patches for embedded VC4
by Ulrich Eckhardt 11 Mar '05

11 Mar '05

Hello! I'm currently trying to port Boost to embedded Visual C++ 4. Attached are a patch against this afternoon's CVS and toolset definition for Boost build v1. Some explanations for the patch: --------------------------------- EVC4 comes with several different compilers, all of which are cross compilers for various architectures. Else, those compilers are mostly bug-to-bug compatible to the one that comes with VC6. One problem though is that e.g. the ARM compiler has _MSC_VER=1201 while the MIPS compiler has _MSC_VER=1202 and the one for x86 has _MSC_VER=1200 (like VC6). The C++ standardlibrary is IMHO barely worth talking about, anything but the most primitive types of use require STLport, unfortunately in their yet unreleased version 5 (use 'cvs checkout -r STLPORT_5_0 STLport' in case you want to try). There are a change to boost/config/stdlib/stlport.hpp that is required for STLport 5. If you look at the patch, you will see that most changes are explained by removing '#if _MSC_VER==1200' in favour of '#if _MSC_VER<1300'. At first glance those are not really equivalent, but there are some considerations that will make it sensible: - if (which I doubt will ever happen) there come any updates to those compilers they will still have version numbers < 1300 - if VC6 and similar suffer a defect, chances are good that older compilers also suffer the same problems - there is a line that generates an error anyways should you try to compile boost code with <1200, older compilers are simply not supported. Another set of changes is that sometimes the use of '#pragma once' was made dependant on _MSC_VER>=1200, while other places used _MSC_VER>=1020. MS themselves use _MSC_VER>=1000. I think this pragma was already supported long before VC6, so the second alternative seems to be right. I replaced a few of such cases. I noticed that some places use BOOST_WORKAROUND while others use _MSC_VER directly. For #pragma once that makes still sense, since you don't want to first include the header for the macro, but in other cases I'm not so sure. Is there a tendency to uniformly use BOOST_WORKAROUND? If so, and since I'm touching a lot of those checks already, should I replace those? The change in boost/detail/lwm_win32.hpp is something where I don't claim I really understand what it does. Removing it breaks compilation, I don't know how to test if it really works. The changes in boost/function/function_template.hpp are something that shouldn't break anything, except if the brackets where in fact an undocumented workaround for some other bug.... Working on this, I noticed that some files I checked out of CVS were write protected!? Is that just my setup, intentional or by accident? I didn't investigate further. Some explanations on the toolset file: --------------------------------------- This is far from complete. There are several architectures that aren't yet supported, some aren't even supported by STLport (yet). Lots of debug code are still present. This also requires changes to some other places, in particular the names of libraries need to be changed, for autolinking in the headers, for building in some part (I forgot which) of the build files. Also, I found that MS Windows CE suffers from not being able to load DLLs with names longer than 31 chars, meaning that the normal boost naming conventions can't be used. This is a major bummer, but I don't see a workaround other than that. I'm throwing this work in progress at the list so I can get feedback earlier. So, if there are issues, don't hesitate to bring them forth. cheers Ulrich Eckhardt

4 5

The case for fold_seq
by Larry Evans 11 Mar '05

11 Mar '05

Is there any interest in a proposed mpl sequence, fold_seq, derived from mpl::fold and contained in boost-sandbox.sourceforge.net/vault/ in cppljevans/mpl/fold_seq_test.zip? This zip contains: * a test driver, fold_seq_test.cpp * a header file, fold_seq.hpp * bjam output of driver for intel * bjam output of driver for gcc. A better name for fold_seq might be cummulative_app since each element is a "partial_application" of the ForwardOp "operation" to part of the Seqence, where ForwardOp and Seqence are the arguments to fold, as described here: http://www.boost.org/libs/mpl/doc/refmanual/fold.html The reason for term "partial_application" is that it corresponds to "partial sum" described here: http://mathworld.wolfram.com/PartialSum.html Alternative names include "prefix reduction" or "scan": http://nf.apac.edu.au/training/MPIRefs/MPI_1.1/node84.html#Node84 Anyway, it seems that it's a useful extension to fold, since, as seen by the above references, the corresponding math concept occurs often. In addition, the test driver in the vault contains test_partial_product, where the value's at each element of the fold_seq correspond to elements in a cummulative product: http://mathworld.wolfram.com/CumulativeProduct.html Such a cummulative product could be used to calculate, at compile time, the strides for an instance of mult_array. Also, fold_seq could be used as a replacement for the get_side_type template class mentioned here: http://article.gmane.org/gmane.comp.lib.boost.devel/118867 and used to access the elements in a tuple, as demonstrated by the test_tuple_access function in the test driver. I'd be glad to discuss improvements or reasons why it's unneeded. TIA.

1 1

Need help: for N-arity operators in C++.
by Pavel Chikulaev 11 Mar '05

11 Mar '05

Hi all! Can anyone help me? I've got a problem with my library "Lazy". Here's the code: template<typename T, int N> class B {}; template<typename T> class C : B<T, max_possible_N_of_all_specializations_B<T> > {}; //The question is - How To write //max_possible_N_of_all_specializations_B? So, if I have these template specializations of B: template<> class B<int, 4> { enum { value = 4}; }; template<> class B<int, 920234> { enum { value = 920234 }; }; C<int>::value should be 920234. Does anyone knows how to do it? Thanks in advance. P.S. It's critical for my library to have max_possible_N_of_all_specializations_B. -- Pavel Chikulaev

5 15

Log utility
by Suman Cherukuri 11 Mar '05

11 Mar '05

I wrote a logging library using boost libraries and other standard C++ functions. I'm fairly satisfied with it and using in my own product. I think it'd be a good addition to Boost. What do you all think? --Suman

3 2

Update of the (not yet officially proposed) Function Types library
by Tobias Schwinger 11 Mar '05

11 Mar '05

Dear Boost community, after three complete rewrites and numerous steps of incremental refinement (some of it based on feedback from you) I am proud to hereby present my attempt to provide a "truely boostish" metaprogramming facility to work with function-, function reference - and (member) function pointer types. The functional range includes: - type classification ("is T a * function ?") - type decomposition (e.g. "what is the result of the function T describes ?") - type synthesis ("create a * function with these subtypes !") All of the above work with variadic functions and (configuration dependent) with arbitrary calling conventions. Common applications are: - generating callbacks (the most prominent special case of this is argument binding) - extracting meta infromation from function prototypes - concept checking (e.g. "let's see if this is a setter/getter pair...") - systematic overload selection See the Documentation for further information. [ -> http://tinyurl.com/4fw9n ] A downloadable archive has been put into the vault. [ -> http://tinyurl.com/4oe7q ] Its quality has improved by an order of magnitude since my first naive attempts, last year - and not at least because of those of you who helped. Thank you ! I decided to use the next couple of days for finalizing refinement and to wait for some more feedback to confirm or disprove my suspicion that the submission is "review ready", before sending out a formal request. Regards, Tobias

2 7

[boost::foreach] and bcc32-5.6.4
by Russell Hind 11 Mar '05

11 Mar '05

Has anyone tried BOOST_FOREACH with bcc32-5.6.4? I've just tried the example BOOST_FOREACH(char ch, "Hello") { std::cout << ch; } And get a string of errors of the following: (line 11 of main.cpp is the BOOST_FOREACH line). I'd really like to be able to use this library so if anyone can give any help in getting it to work, it would be really useful. Thanks Russell [C++] main.cpp(1): [C++ Error] main.cpp(11): E2354 Two operands must evaluate to the same type [C++ Warning] main.cpp(11): W8032 Temporary used for parameter 1 in call to 'boost::for_each::boost::for_each::container<char *,boost::mpl::false_> wrap<char *>(char * &)' [C++ Error] main.cpp(11): E2354 Two operands must evaluate to the same type [C++ Error] main.cpp(11): E2285 Could not find a match for 'boost::for_each::contain<T>(undefined,bool,undefined)' [C++ Warning] main.cpp(11): W8032 Temporary used for parameter 1 in call to 'boost::for_each::boost::for_each::container<char *,boost::mpl::false_> wrap<char *>(char * &)'

10 28

[date_time] test failures
by Caleb Epstein 11 Mar '05

11 Mar '05

http://tinyurl.com/5hnvv The date_time regression tests in the gregorian subdir called "testgenerators" and "testgenerators_dll" fail to compile on Solaris due to the use of a variable called "sun". Unfortunately, there is a preprocessor macro sun == 1 which gets defined on this platform that ends up turning the declaration: greg_weekday sat(Saturday), tue(Tuesday), fri(Friday), sun(Sunday); into greg_weekday sat(Saturday), tue(Tuesday), fri(Friday), 1(Sunday); I'd suggest either #undef sun at the top of the file or changing the name of this variable. Also, there are few other failures (testclocks, testlocal_time, testlocal_time_facet) due to a missing declaration of time_ in local_date_time_base. Example: http://tinyurl.com/5xd8h testtz_database is failing because it can't find its input file (probably because of the working directory the tests are run from). Perhaps this file should be found starting from $BOOST_ROOT? -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

[test] [thread] including unit_test_suite_ex.hpp fails to compile
by Caleb Epstein 11 Mar '05

11 Mar '05

One of the Boost.Thread library test programs (test_mutex.cpp) fails to compile due to the inclusion of the header file <boost/test/unit_test_suite_ex.hpp>. This file includes another file which does not exist: http://tinyurl.com/3t83x This test seems to be failing across several platforms. -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Fixed Size Matrix
by Jason Hise 11 Mar '05

11 Mar '05

I saw that boost already has a pretty impressive linear algebra suite, with many specialized types of matrices. Though these are all very useful, I was wondering if there might be room for one more type of matrix: one which makes each size of matrix a unique type (I did not see such a matrix in the docs, but please correct me if I overlooked it and it does already exist). Using such matrices, it would be possible to validate the legality of certain operations at compile time (for instance, only matrices of compatible sizes can be multiplied). A very stripped down version of the class might look like this: template < typename T, unsigned int X, unsigned int Y > class matrix { // maintains Y rows, each containing X Ts internally }; template < typename T, unsigned int X, unsigned int Y, unsigned int Z > matrix < T, Z, Y > operator * ( const Matrix < T, X, Y > & lhs, const Matrix < T, Z, X > & rhs ); // multiplication defined only for compatible matrices Is there any interest in such a class? -Jason

8 10

Logo comments
by Jonathan Turkanis 11 Mar '05

11 Mar '05

Hi All, Here are my remarks about some of the logo candidates. My thoughts were heavily influenced by resizing some of the logos and plugging them into the documentation of the candidate Boost Interfaces library. I found that some logos which I liked isolation didn't do so well when viewed in the context of documentation. I considered preparing a demonstration showing what all the submitted logos would like when used in documentation; I decided this would be unfair, however, since a logo that doesn't look so good with the current Boost documentation might look great if the look and feel were adjusted to match the logo. As a result of the experiment, I have two general observations: A) logos which have some sort of shading, or which employ several closely-related but not identical colors, look far better than logos which don't. The logos with shading make the others look flat and boring. This immediately eliminates many of the logos B) logos with non-white backgrounds don't work well After playing around with many designs myself, I also came to the conclusion (which David Abrahams also recently expressed): C) the letters "C++" and the scope resolution operator "::" simply aren't very visually appealing. Now for particular logos. (For brevity, when I have a negative opinion about some aspect of a logo, I will state it without attempting to be polite; I don't intend to offend any of the logo authors.) 29 - The miniature version does not do it justice. There's a larger version here: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostLogo. At the time Eric posted it, I though it was the best candidate (I liked variant d). However, when I viewed it in the context of documentation, it didn't work in at all, falling victim to B) above. The region where the logo sits tends to be wider than its height, so it looked either too narrow, or too high. Also, the inner detail was lost; it looked like a solid blue square. 38 - This was easily the most appealing at the time I conducted the experiment. I asked a friend, who is a graphic designer, to look at the logos, and he also picked this one. Unfortunately, to me it immediately calls to mind a pair of dice. To others, apparently, it calls to mind children's blocks. I believe this makes it less suitable than some of the other attractive logos. It's okay if a logo doesn't have an immediate association with Boost; if it has an immediate association with something unrelated, however, that's a problem. 67 - This is clearly one of the best logos. Unfortunately, when I reduced it in size and inserted it in documentation, it looked, I'm sorry to say, just terrible. Against a pure white background, the logo's gray background made it look dirty. See B), above. The answer must be to change the background color, but I'm uncertain how to do this without destroying one of the logo's most beautiful features: the tiny white border along the bottom and left edges of the logo's main elements. Without this tiny detail, the logo looks pretty flat; see A), above. I think it's important to get some concrete suggestions on how to deal with this problem before the logo is accepted. 75 - I see that a number of people find this logo attractive, but I have some serious problems with it: Whereas some logos suffer from the problem that you have to look at them too long before you understand them, this one is the opposite: it looks very nice when you just glance at it or view it out of the corner of your eye; unfortunately, it does not stand up to closer scrutiny. When I examine it, my first thought is: "what is it supposed to be?" This is not good for a logo, IMO: when you look at a logo, it should be clear that a it represents something concrete or that it is a purely abstract design. (If a concrete representation is hidden in what first appears to be an abstract design, that's okay too.) The reason I find myself asking what this particular logo is meant to represent, I think, is that it's not sufficiently complex to hold its own as an abstract design. Once I ask myself what the logo represents, I can only conclude that it depicts a stack of paper. This is a big problem: aside from the fact that Boost has little to do with a stack of paper, stacks of paper are simply uninteresting. The second problem is that the 3D effect of the overlapping rectangles make the text look flat. 83 - This is also one of the more attractive logos, but like 38 it calls to my mind associations unrelated to Boost. In particular, I immediately think of looking at paint samples or carpet swatches. 52 - This is nice but suffers from problem B) 60 - Well-designed, but contains too much detail. Also, the crescent shapes look more like cartoon images of the moon then the letter "C". 92 - The captions "Plug it in", "Pieces that fit," etc. make the logos look cluttered; otherwise they look pretty good. However, I don't buy the explanation that the logo "at first appears to be a jigsaw puzzle piece" but can also be seen as people talking around a table: - no one will know that this is the intended interpretation unless they are told. Even if someone notices the alternate interpretation, there's no clue that this is intended - the logo will *always* appear to be a puzzle piece; at best it will *also* appear to be people sitting around a table. The problem with this is that "finding a piece of the puzzle" is one of the most overworked metaphors in English. (I don't know if this is true in other languages.) Best Regards, Jonathan

14 39

[aligned_storage] problems with GCC 4.0.0 20050309
by Joaquín Mª López Muñoz 11 Mar '05

11 Mar '05

The class aligned_storage in boost/aligned_storage.hpp has the following decl: template < std::size_t size_ , std::size_t alignment_ = std::size_t(-1) > class aligned_storage; GCC 4.0 complains about the default value for aligmnent_ saying that: '(size_t)((-1))' is not a valid template argument for type 'unsigned int' because it is a non-constant expression Is GCC right or shall I submit a bug report at gcc.gnu.org/bugzilla? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

YALo: Yet Another Logo
by David B. Held 11 Mar '05

11 Mar '05

This should give some idea as to what I think of as a "scalable logo" or a "scale-free logo". It's rather crude yes, but that's partly the point. Instead of rendering the word "Boost" in a nice font of the same or some appropriate color, I shamelessly stole one from another logo. The colors aren't really important, because they aren't the point (a graphic artist could pick much better colors). I don't know if rounded edges are better or straight lines. And perhaps even this example has more angles than I like in a scale-free logo. Perhaps we could even do without the fins, I'm not sure. The angles could be adjusted to be more pleasing. Now some might say: "Well, Rene made an abstract looking rocket too." And that is true. But Rene's rocket has some very subtle features, like the edges near the flames, which is an area of "high entropy" so to speak. My rocket has no detail frills, and could easily be compressed to an absurdly small vector file. Perhaps something with a nonnegative amount of artistic talent could play with the idea a bit without adding too much information to the logo. I realize that the contest is closed, but I'd like to explore a more simplistic direction just to get an idea of some areas of the design space that I don't think have been hit very heavily. I don't intend the word "Boost" to be a necessary part of the logo. I just think that in large-scale contexts, a caption would be nice, whether it be on the side or the bottom or a word or a phrase. Any takers? Dave

2 1