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

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

10 Mar '05

Hi Peter, ----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Jueves, Marzo 10, 2005 11:51 pm Asunto: Re: [boost] Re: Re: Re: [review] hash functions > JOAQUIN LOPEZ MU?Z wrote: > > > > The idea is that you can alter only some part of the > > hashing scheme and benefit of the preexisting definitions: [...] > > I think I see your point. You want something like this: [...] > will automatically propagate it downwards if one invokes > hash_value on > vector<vector<vector<int> > >. Sort of, I think. Your formulation is somewhat more generic in that you pass combiners around where I rely on tag dispatching (the *_impl markers.) > Interesting, but overkill, IMO. ;-) Can't say the contrary :) I see it as I way to get everybody happy: regular users don't notice the difference and playful ones can easily plug in their superhashing schemes. Anyway. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

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

10 Mar '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Jueves, Marzo 10, 2005 10:35 pm Asunto: Re: [boost] Re: Re: Re: [review] hash functions > JOAQUIN LOPEZ MU?Z wrote: > > > > Maybe the following approach could be taken to > > allow for alternative implementations to be plugged into > > the framework: [...] > > > unordered_set<my_type,boost::hash<my_type,crypto_impl> > us; > > The proposal is not a framework, it contains two simple tools for > constructing hash_value overloads for compound types and a suite > of > _default_ hash functions. > > Alternative implementations (who may or may not use the supplied > tools) are > supported by unordered_set by simply using > > unordered_set< my_type, my_hash > us; > > There's no need to plug them in. The idea is that you can alter only some part of the hashing scheme and benefit of the preexisting definitions: template<typename It> std::size_t hash_range(It first,It last,crypto_impl) { ... } // third_party_type is an external type with its own // hash_value overload unordered_set< std::vector<third_party_type>, boost::hash<std::vector<third_party_type>, crypto_impl> > us; // here, we automatically get an impl of hashing for // strings using the crypto_impl hash_range unordered_set< std::string, boost::hash<std::string, crypto_impl> > us2; But I won't defend this to death :) I just felt like throwing the idea in. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

stl-like containers of pointers
by Felipe Magno de Almeida 10 Mar '05

10 Mar '05

I heard that boost is going to have all the stl-like containers, but with reference semantics and will treat the indirection in the iterators and etc... I would like to know where I can get this. It is not in the cvs either... Thanks in advance, -- Felipe Magno de Almeida UIN: 2113442 email: felipe.almeida at ic unicamp br, felipe.m.almeida at gmail com, felipe at synergy com I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer from synergy, and Computer Science student from State University of Campinas(UNICAMP). To know more about: Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br current work: http://www.mintercept.com

2 10

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

10 Mar '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Jueves, Marzo 10, 2005 6:01 pm Asunto: Re: [boost] Re: Re: Re: [review] hash functions > Thorsten Ottosen wrote: > > > > so basically you're saying that any collision is much worse than a > > slower hash function because we must use == to go through the > bucket ? > > Something like that, yes; of course it depends on the level of > slowness. > Cryptographic hash functions are typically overkill. Increasing > the number > of collisions slightly is tolerable (but can easily negate the > effect of the > faster hash function). Hitting a pathological case where a > significant > percentage of the key set maps to the same bucket is a serious > problem. > Maybe the following approach could be taken to allow for alternative implementations to be plugged into the framework: struct std_impl{}; template<typename T,typename Impl=std_impl> struct hash { std::size_t operator()(const T& x)const { return hash_value(x,Impl()); } }; template<typename T,typename Impl> std::size_t hash_value(const T& x,Impl impl) { return hash_value(x); } // standard hash_value overloads for integral types and pointers ... // template<typename T,typename Impl> void hash_combine(size_t& seed,const T& x,Impl impl) { seed^=hash_value(x,impl)+(seed<<6)+(seed>>2); } template<typename A,typename B,typename Impl> std::size_t hash_value(const std::pair<A,B>& x,Impl impl) { std::size_t seed=0; hash_combine(seed,x.first,impl); hash_combine(seed,x.second,impl); return seed; } template<typename It,typename Impl> std::size_t hash_range(It first,It last,Impl impl) { std::size_t=0; for(;first!=last;++first){ hash_combine(seed,*first,impl); } return seed; } template<typename E,typename T,typename A,typename Impl> std::size_t hash_value(const std::basic_string<E,T,A>& x,Impl impl) { return hash_range(x.begin(),x.end(),impl); } // same as previous for the rest of STL containers This framework is transparent to the regular user, who never specifies an alternative implementation and can define hashing for her own types as before: std::size_t hash_value(const my_type& x) { //... } unordered_set<my_type,/* boost::hash<my_type> */> us; But the "advanced" user can tweak one or more parts of the hashing framework ad libitum: struct crypto_impl{}; std::size_t hash_value(int x,crypto_impl) { // smart hash for ints } // we modify also range hashing template<typename It> std::size_t hash_range(It first,It last,crypto_impl) { std::size_t seed=0; std::size_t n=1; for(;first!=last;++first){ hash_combine(seed,*first,crypto_impl); seed*=n; // for instance n*=2; } return seed; } unordered_set<my_type,boost::hash<my_type,crypto_impl> > us; What do you think? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 10 Mar '05

10 Mar '05

In-Reply-To: <d0pe8q$tdi$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > But it will be easy to make mistakes for more complicated (possibly > recursive) types. Especially since hash_combine is not associative or > transitive. I could see that leading to mistakes. I can see that it's possible to call the function with the wrong arguments, but that kind of problem can be addressed with documentation and/or by careful naming. I don't think that's worth distorting the interface and introducing side effects and spurious variables and inefficiency to fix it. > And it would be quite easy to forget to call hash_value (because > many types are implicitly convertible to std::size_t) Since that conversion is all hash_value does, why does it matter? That said, I agree the second argument should not be hash value. If we care about the first argument, perhaps the problem could be identified with an overload or specialisation. template < typename T, typename S> size_t hash_combine( S seed, const T &v ) { BOOST_STATIC_ASSERT( false ); } template <typename T, typename S> size_t hash_combine<>( size_t seed, const T &v ) { const size_t c = 0x12345678; // Or some other value. return seed ^ (hash_value(v) + c + (seed<<6) + (seed>>2)); } (I'm not so hot on templates so the above may be wrong, but I hope it conveys the idea.) > size_t my_hash_function(int x[4]) { > using namespace boost; > > return hash_combine( > hash_combine(hash_value(x[0]), hash_value(x[1])), > hash_combine(hash_value(x[2]), hash_value(x[3]))); > } I agree this is wrong. I think: return hash_combine( hash_combine( hash_combine( hash_value( x[0] ), x[1] ), x[2] ), x[3] ); is reasonable and ideally would be supported. > An alternative would be to implement hash_combine as an object. > Something like: > > struct hash_seed { > hash_seed(); > template <class T> void combine(T const&); > std::size_t value() const; > }; > > Then it could initialise itself to whatever it wants. Do you mean the seed should be an object? I can see advantages to that, although it seems like overkill. Adding an optional seed argument to hash_range and/or hash_combine sounds like a good idea, though. -- Dave Harris, Nottingham, UK

3 2

[foreach] and reverse iteration
by Russell Hind 10 Mar '05

10 Mar '05

Is there a way to reverse iterator using BOOST_FOREACH? From a quick browse of the docs, it isn't mentioned. I guess it could be done using a std::pair of reverse iterators, but would it be easy to build a BOOST_REVERSE_FOREACH construct or BOOST_RFOREACH that just runs from rbegin to rend? Cheers Russell

2 1

Re: [boost] [review] hash functions
by brangdon＠cix.compulink.co.uk 10 Mar '05

10 Mar '05

In-Reply-To: <018901c52569$ea842610$6601a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > That would be bad because the hash value of the pair (x, y) would no > longer match the hash value of the sequence (x, y). Why is it necessary for pairs and sequences to have the same hash value? They are different things. If it is necessary, we can avoid the problem by fixing hash_range: template <typename It> size_t hash_range( It first, It last ) { if (first == last) return 0x87654321; // Or some other value; size_t seed = hash_value(*first); for (++first; first != last; ++first) seed = hash_combine( seed, *first ); return seed; } This also gives hash_range( &a, &a+1 ) the same result as hash_value(a), which your approach does not. > Do you have a different hash_combine in mind that doesn't suffer from > this problem and is better than the proposed implementation? ;-) > (Keeping in mind that even the current hash_combine is perceived as > slower than necessary, of course.) I had in mind something like: template <typename T> size_t hash_combine( size_t seed, const T &v ) { const size_t c = 0x12345678; // Or some other value. return seed ^ (hash_value(v) + c + (seed<<6) + (seed>>2)); } This costs one extra addition, which can probably be scheduled in parallel with other operations anyway. -- Dave Harris, Nottingham, UK

2 1

[test] missing test file
by Vladimir Prus 10 Mar '05

10 Mar '05

When running "bjam -n" in the libs/test/test directory, I get: don't know how to make <@boost!libs!test!test>foreach_test.cpp Gennadiy, seems like you either forgot to commit that file, or forgot to commit some changes to Jamfile. Can you fix this? - Volodya

2 1

review of proposed fsm library
by Dave Gomboc 10 Mar '05

10 Mar '05

Reviewer info: ============== I have an M.Sc. in computing science. Much of my experience is with state-space search, which has certain similarities to the topic at hand. Also, lately I have been working daily with code that ought to have been written using an FSM library, but wasn't! :-( I have been following the FSM discussion on the list, and have focussed on the library for one day, reading through the docs and rationale, plus Harel's initial statechart paper. The rationale document did not convince me of the correctness of some design choices, so I did not attempt to write code with the library. Reviewer comments: ================== 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. The distinction made between state and state_machine, which I consider to be unfortunate, was not justified in the rationale. For naturally recursive structures, distinguishing between the structure's frontier and its interior by type is best avoided. (Analogously, the head of a (singly-linked) list and the root of a tree would not be distinguished by type from their successors and children, respectively.) Composition is critical! See, for instance, section 12.4 of Keller (http://www.cs.hmc.edu/claremont/keller/webBook/ch12/) An example of multiple-machine composition into a large machine should also exist in the tutorial. The simplest useful such case would likely be connecting two half-adders to make a full-adder machine. 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. I was pleased that the tutorial and rationale collectively contain considerable discussion of exception handling. 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, excusing the relatively low performance of the library. 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. The lack of support for dynamically-configurable automata is also unfortunate, though not unexpected given the requirements list. 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. But even that may be an aside. I am unconvinced by: "To satisfy requirement 6 [to support the development of arbitrarily large and complex state machines], it should be possible that to spread a single state machine over several translation units. This however means that the dispatch table must be filled at runtime and the different trnaslation units must somehow make themselves 'known' so that their part of the state machine can be added to the table. There simply is no way to do this automatically and portably." 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. 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. I have an uneasy feeling about how differently asynchronous and synchronous machines are operated, but did not consider this issue in detail. Allowing the tracking of history is intruiging; the prohibition against deep history of states with orthogonal regions is suspicious. The explanation given is that it would be more complicated (but still possible) to implement. In my experience, that sort of reasoning just doesn't fly at Boost. 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. 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. There is no explicit discussion of non-deterministic fsms. Of course, every such fsm can be re-expressed deterministically. 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. :-) 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? (http://www2.toki.or.id/book/AlgDesignManual/BOOK/BOOK5/NODE207.HTM# SECTION03177000000000000000 gives a toy example of FSM minimization). 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. Reviewer conclusion: ==================== 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. Ultimately, I think there are issues of design and rationale that must be sorted through, appropriate modifications made, followed by re-review. Less weighty issues: ==================== struct Greeting; struct Machine: fsm::state_machine<Machine, Greeting> {}; (and all similar) should be changed to struct Machine: fsm::state_machine<Machine, struct Greeting> {}; If necessary, the old way can be metioned as a workaround for older compilers in a footnote. The "default" black disc in the diagrams is too large! Maybe make the radius about 2/3s of what it is now. Change "Such transitions are currently flagged" to "Transitions across orthogonal regions are currently flagged". It's the first sentence in the last paragraph of the rationale.

4 4

Hash review: hash_float_test broken?
by John Maddock 10 Mar '05

10 Mar '05

Sorry if this has come up before, but all the compilers I tested with refuced to compile hash_float_test: hash_float_test.cpp ..\..\..\..\libs\functional\hash\test\hash_float_test.cpp(99) : error C2501: 'BOOST_META_FUNC_TEST_CASE' : missing storage-class or type specifiers ..\..\..\..\libs\functional\hash\test\hash_float_test.cpp(99) : error C2440: 'initializing' : cannot convert from 'void (__cdecl *)(T1 *)' to 'int' Context does not allow for disambiguation of overloaded function ..\..\..\..\libs\functional\hash\test\hash_float_test.cpp(105) : error C2275: 'float_types' : illegal use of this type as an expression ..\..\..\..\libs\functional\hash\test\hash_float_test.cpp(104) : see declaration of 'float_types' ..\..\..\..\libs\functional\hash\test\hash_float_test.cpp(105) : error C3861: 'BOOST_FUNC_TEMPLATE_TEST_CASE': identifier not found, even with argument-dependent lookup "cl" /Zm800 -nologo /EHsc -c /Z7 /Od /Ob0 /EHsc /GR /MDd /Op /Zc:forScope Zc:wchar_t -I"..\..\..\..\bin\boost\libs\functional\hash\test" -I"C:\Program Files\Microsoft Visual Studio .NET 003\VC7\include" -I"c:\data\boost\develop\boost" -Fo"..\..\..\..\bin\boost\libs\functional\hash\test\hash_float_test.test\vc-7_1\debug\threading-multi\hash_float_test.obj" -Tp"..\..\..\..\libs\functional\hash\test\hash_float_test.cpp" Thanks, John.

3 3

RE: [boost] [optional]output
by Martin Bonner 10 Mar '05

10 Mar '05

----Original Message---- From: Gennadiy Rozental [mailto:gennadiy.rozental@thomson.com] Sent: 07 March 2005 07:18 To: boost(a)lists.boost.org Subject: [boost] [optional]output > Hi, > > Maybe it's something that I missed, but why optional doesn't define > output operator something like this: > > template<typename T> > inline std::ostream& > operator<<( std::ostream& ostr, optional<T> const& v ) > { > if( v ) > ostr << *v; > return ostr; > } I don't think optional should define an output operator at all. There are too many possibly useful definitions. For example: template<typename T> inline std::ostream& operator<<( std::ostream& ostr, optional<T> const& v ) { if( v ) { ostr << true << ' ' << *v; } else { ostr << false; } return ostr; } -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

8 22

boost/python: how to: call memberfunctions of an existing c++ object from python?
by Marco Borm 10 Mar '05

10 Mar '05

Hi Boost/Python developers, at first I have to say that I am no boost nor a python expert. I've searched for hours now on the web for my problem but was unable to find some solution for my problem: Currently I am working on the possibility that an python-script is called by an existing c++ object. This was "easy" to do with and without the boost python-classes. To make this more complicate, the script must be able to call some member functions of this object. So to make this possible I created an BOOST_PYTHON_MODULE() containing the class and the to be called member function-definitions. Now it is possible to create new instances of the class and call them from python. It is also possible to do the following in my c++ object-code: "ret = boost::python::call<int>(PyFunction.ptr(), this );" But now my problem: boost copies the object and passes only that copy to the function. Is it and how is it possible to make the object accessible to the function within the python-script? I have found some hints in the boost-source for using smartptr but I was unable to use them as an parameter for call(): "TypeError: No to_python (by-value) converter found for C++ type: class boost::shared_ptr<TYPE>". I am also don't known if this is the right way to do. Thanks for help! Marco Borm

2 3

Re: [boost] [review] hash functions
by brangdon＠cix.compulink.co.uk 10 Mar '05

10 Mar '05

In-Reply-To: <00cd01c524e3$bf3cb4d0$6501a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > A pure function would entice you to define hash_value for (x, y) > as hash_combine(x, y). And that would be bad because...? template <typename T1, typename T2> size_t hash_value( const std::pair<T1,T2> &pair ) { return hash_combine( hash_value(pair.first), hash_value(pair.second) ); } looks good to me. 1 line of code instead of 4, no spurious variable, no side effects, half as many calls to hash_combine(), easier to exploit instruction-level parallelism. > We can fix this by initializing the seed in hash_range with something > other than zero. It isn't a problem for strings, where \0 is rare, but > may be a problem for arbitrary sequences. That would help. How about fixing it in hash_combine instead? At the moment hash_combine(0,0) == 0. If you fix it in hash_range, you also need to fix it in every other place a seed is used, eg for pairs. -- Dave Harris, Nottingham, UK

3 2

indirecter_unary, indirecter_binary
by Matthias Kaeppler 10 Mar '05

10 Mar '05

Hello, because of the lack of a generic adaptor which indirects operations on pointers to the pointees, i.e. sorting a collection of pointers with predicates applying to the pointees, I have come up with two classes, indirecter_unary and indirecter_binary which do exactly that (thanks again to the people from boost users and comp.lang.c++ for assisting me). Both adaptors accept adaptable function objects as well as plain functions. Ex.: inline int plus( int a, int b ) { return a + b; } // ... std::vector<int> vec; // ... std::sort(vec.begin(),vec.end(),indirect_binary(std::less<int>())); // ... std::transform(vec.begin(),vec.end(),vec.begin(),std::ostream_iterator<int>(std::cout,"\n"),indirect_binary(plus)); I have attached the source file. Your feedback would be greatly appreciated. -- Matthias Kaeppler

8 31

Re: [boost] [shmem] Uploaded to Vault+documentation questions...
by ION_G_M 10 Mar '05

10 Mar '05

Hi James, I missed your message in the big diggest! QuickBook seems to offer all that I need, so I will definitely look at it. >I've attached a larger sample based on your "Quick Guide" (which might >be out of date...). Take a look, and if your interested check out the >Boost Documentation list at >https://lists.sourceforge.net/lists/listinfo/boost-docs. There's quite >a bit happening with QuickBook. Ok, thank you for all. Regards, Ion

1 0

Visual Studio 2005 IDE: Improving Class View(() instead of (void)) [Repost]
by Pavel Chikulaev 10 Mar '05

10 Mar '05

Visual Studio 2005 Beta2 CTP December 2004 still uses (void) as empty parameter list in Class View, Add Member Wizard and other IDE windows. I am asking you: Is there any official paper that shows that syntax (void) deprecated? It's possible to retire current (void) syntax in VS's IDE in case of showing Microsoft Visual Studio developers some official paper that shows it. I am posting it here because I believe there are some of us who also dislike it VS and knows/reads some C++ official papers. P.S. As for me, It is really annoying.

2 2

RE: [boost] Logo Contest
by Mark Blewett 10 Mar '05

10 Mar '05

At 22:38 09/03/2005, you wrote: I really want to respond to a comment at the end of Reid's post.. but there are a few interesting comments on the way... so I've added my thoughts "Spot on. I'd further add that most of the best commercial logos are pretty simple--not all, but it's a lot harder to make a complex one appealing." I agree, and add a further comment. Yes there have been some well drawn/rendered logos, however many seem (IMHO to me) like taking a average idea, but adding as many effects to make it look good. What I think (and hope) we should be looking at is the concept, not the frills. "Without singling any of the entries out, I think that most of the currently-posted entries are too complex. As a side note, and not a very relevant one (maybe), it's pretty clear the list is populated by a mostly left-brained crowd; look at how many of the entries depend on word play, acrostics, and the like. " Again I agree.. there are a few graphical people here, but most are "left-brained crowd".. but what's Boosts target audience? It's actually a serious question.. first line would be developers.. so a "left-brained crowd" logo would be ok, second line are companies.. which probably don't look at the logo, more the legal use of boost. What I'm trying to say is most logo's are for the general population.. in the case of boost (unfortunately) we don't have world domination.. so we should be producing a logo for the selected target audience. "Not saying that's bad, but again, the logos people tend to remember are more likely to be graphic than semiotic. Yeah, I guess that one deserves a smiley, on the grounds of self-referential irony. So here: <g>. Now, if there were just a way to make emoticons tail-recursive...come to think of it, I'm surprised no one used recursion as a means of indicating "boostness." If it weren't too late, I'd maybe have a go at that. Although most of my ideas were based around shapes, color use, and shading." I agree with "graphic than semiotic" for the general population.. does it apply to potential Boost users? I'm not so sure... but believe its probably true. "Incidentally, I'm also surprised no one has tried to define a coherent color scheme, especially given that there *are* graphic designers present. Is it just that everyone unconsciously accepted the existing "cool" scheme? Only a couple of the entries even try to do much with color, and I can't find any consistency in the usage (possibly my fault; it's just a hobby with me). Okay, <\kibitz>" I started writing an email awhile back (which I didn't posted), commenting on various designs.. however writing it I felt as it I was actually questioning the process rather than the produced logos (I'm not knocking the designers or anyone else.. just questioning) Why I'm responding to your email is a similar thought... Before we have a boost logo, do we need to define the boost "colours", the boost "font".. the foundations of a "corporate" logo? Or another example, capitalization.. should should Boost be "boost", "Boost" or "BOOST".. my thought is "Boost" in documentation, and "boost" (because coding standards apply) in code. Buts what about in a logo? Going back to colours.. I'm not sure what you mean about the "existing cool scheme".. I presume variants of blue.. there's are good reasons... 1) (unfortunately) most of us are male (and our target audience).. and we have a preference for the colour. 2) Industry Conventions.. I posted a link awhile back (http://lists.boost.org/MailArchives/boost/msg75724.php) which gives another reason; <quote> I'm no expert either but http://graphicdesign.about.com/od/logotips/a/8logoelements_2.htm has a interesting point about colour which I haven't seen mentioned here; Works Within Industry Conventions Often there are consistencies among logos in certain industries, and following these conventions can help customers more easily identify what you do or what you sell. This doesn't mean you should sacrifice originality, but it does mean you (or the firm creating your logo design) should be aware of patterns among logos in your industry and somehow incorporate these consistencies into your design. For example, did you realize that the main color for the logos for Microsoft, IBM, Dell, Hewlett Packard and Intel is blue? The color blue is associated with stability and progress and has long been a standard color among high-tech companies. So if you were a technology company, you would probably want to incorporate blue into your logo design to take advantage of these positive built-in associations. </quote> I guess choosing a logo is very personal and emotive (compared to accepting, or not, a new library).. but personally I trust the judgement of the people here and the process.. discussion is the key I feel. Regards Mark

4 4

RE: [boost] Logo Contest
by Mark Blewett 10 Mar '05

10 Mar '05

At 01:57 10/03/2005, you wrote: Firstly there are a lot of things I agree with you in your previous post... and was responding to it because it was (I feel) it is good starting point (because it summarized a lot of my concerns) to make the comments to the list as a whole that I felt needed making, not against your own post... perhaps I should of been clearer about that. Unfortunately with a brief scan of your response.. your interpretation of my post maybe different, I guess I have a lot to learn about posting "correctly" here. >My personal take is that it says "safety" to an industry that's anything but >predictable. Which isn't to denigrate it. I like blue. Got blue color >schemes on all my machines (or teal, which is close). It just seemed that >no one had given it any thought, That's what I'm trying to say.. (ok doing it badly)... about getting the basics (things like colour / font / capitalization) sorted.. however perhaps these will come out in post selection changes. >and I was trying to, well, *goose* people a >bit, maybe get someone to try something else. If you noticed it as it >breezed past and sank, my one early attempt was blue, and I thought at that >time (seem to recall some posts that made me think that) we were supposed to >keep the old color, to minimize collateral changes to color in the page >content. I guess most of use like stability.. which is strange given the innovative libraries in boost. >As for "targeting the audience," I harbor a deep suspicion that just because >coders work with text doesn't mean they'll necessarily *respond* positively >to it. Sadly, I have a wee bit of experience to tell me that (don't ask, >don't tell <g>). For one thing, yeah, we're working in a text medium, but I >don't really think the bulk of us are really all that language-oriented. That's actually a very good observation! I'd been thinking of the day to day textual side.. not thinking of what goes on inside the mind. >I'd wager that better than 95% of the people who track this list are male >(which I do *not* say to belittle women, or even to suggest that the logo >should just target males--I'm just talking numbers), Unfortunately its the world we live in :o( >which dictates a pretty >strong statistical leaning towards problem-solving techniques based on some >form of physical visualization. (About to commit the sin of generalizing >from a single particular, but...) I'm about as language-oriented as it goes, >with an advanced degree in writing and Lit, but when I code, I *picture* >things. Abstract patterns of colored blocks, actually. It's subtle, but >there. Now, after all that disquisition, I'll observe that a text logo can >work. Good ones are pretty hard to do, but you can think of some if you >try. However, apart from IBM, can you really think of many others? Look >closely at HP's logo, or Motorola's, any of that ilk, and you'll see there's >a graphic component even to them. Hell, there's one to IBM's. Check out >what their trademark actually is. Block serif lettering in a particular >shade of blue, broken by horizontal drop-outs. Hmmmn. I'm looking at the >Dell logo on my monitor; not sure what it means to do. Looks like it's got >"lazy E syndrome." <g> It may be that a large percentage of the submissions >are text-based simply because that's the first idea anyone will have, on >average. I think you are right about the submissions, and right that perhaps (if I understand you correctly) an abstract logo is a better way to go. >I would say that, yes you *do* need to be thinking about all those >foundations, if you expect to get it trademarked, because anything not >explicitly specified in the description will *not* be considered part of the >trademark. You also have to be careful not to over-constrain the >definition, or you can arrive at situations where you can't claim copyright >protection for certain usages. For instance, a logo I once did (still think >it's my best) for a rock band was largely defined by a geometric pattern >that surrounded and dominated the opening capital of the band's name. There >was also a backdrop done in a flame scheme by airbrush, and I'd designed a >custom font for the name that echoed patterns in the geometric figure. The >description finally filed mentioned only the figure and the name. Including >the font would have forced the band to always use only that font. Likewise >the backdrop; that logo had to appear on a number of things, and lots of >them wouldn't have been conducive to having a lot of deep saturated reds, >oranges, and yellows on them. I'm speaking of US trademark law, of course. >I don't know the conventions in other countries. But yeah, I do think of >this process as "establishing a brand," in the full commercial sense. That's one of the thinks I was questioning in my head.. what's a logo.. why is a new one needed.. what I personally came back to each time was actually we are trying to establish a brand.. and that the logo is just part of it. Maybe my interpretation as a causal observer is wrong. >Were >I at liberty to drop names, I could tell you a tale of a company that >neglected to trademark a very important part of what had come to be a >long-established and well-known brand, and their main competitor simply >appropriated it for their own advertising, undoubtedly luring customers who >associated that very key thing with the wrong company. But I ain't. And I >ain'ta gonna. <g> Okay, Boost isn't a "company" in the traditional sense. >But it's got to work with laws designed for corporate protection, and that >means really working with them. That's an interesting comment, one which I'd never of thought of... has anyone? >Yeah, it's personal. Since Boost isn't a company I "own" or do branding for >though, I'm not emotional about it. If it's seemed that way, I apologize >for the impression I managed to import into my messages. Sorry what I meant was the choice of logo is personal and emotive to everyone here.. everyone has their own reasons, its not (as) logical like voting for a library submission. >And yep, >discussion is the key. Which is what we're doing, I thought. <g> Yeah.. and you have made me think of a few areas, problems, and ideas which I hadn't even considered before. Thanks! Regards Mark

1 0

Logo Contest
by Zoltan 'cad' Juhasz 10 Mar '05

10 Mar '05

Greetings! I suppose the "Boost Logo Contest Conversation" becames forming something philosophical :) I'm not a professional graphic artist any more, but have been worked as a graphic artist for some years. Although logo gives the face of the project, company, team etc., it does not determine the area of operation of the represented! I mean a logo doesn't need to reflect to all of the services a company provides and it's very hard to find a logo that looks great and tells everything about the company. Conclusion: sometimes that's good enough to have an impressive logo the emotional effect depends on the represented. However, I'm absolutely sure about the thing that the "user" will not spend any valuable minute on racking his brains about the very meaning of an abstract logo :). > Pepsi, Nike, Sun, Microsoft Windows, BMW, Toyota, Apple... The logos of these companies are really impressive and stylish, aren't they? In my point of view Nike, Sun and perhaps Pepsi have those logos that are great just by being a logo the others mentioned need to have the background meaning to catch the attention. Iconify: I share the opinion of those who think about the recognizability of a logo as a basic feature, especially by extremely tiny size... but I don`t think that we would need a sparated icon logo as well. Sometimes the logo itself can work as an icon: http://people.inf.elte.hu/cad/etc/boost/famous-logos.png Although the logo of the Infiniti company is completely abstract, it`s incredible: http://people.inf.elte.hu/cad/etc/boost/infiniti.png As I attended the competition I don`t judge anyone`s work, since I`m affraid I couldn`t stay objective.:) > Then 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. I would like to protect my 75th application by some words: a logo doesn't need to illustrate anything tangible, since everyone will think and feel by seeing the logo the way he concieves of the represented. Jonathan saws papers, I saws component layers. that is subjectivity. Zoltan 'cad' Juhasz

5 7

RE: [boost] Logo Contest
by Mark Blewett 10 Mar '05

10 Mar '05

[A repost with (hopefully) proper quoting.. thanks Jonathan, and apologies to everyone else for the previous post] At 22:38 09/03/2005, Reid Sweatman wrote: I really want to respond to a comment at the end of Reid's post.. but there are a few interesting comments on the way... so I've added my thoughts >Spot on. I'd further add that most of the best commercial logos are pretty >simple--not all, but it's a lot harder to make a complex one appealing. I agree, and add a further comment. Yes there have been some well drawn/rendered logos, however many seem (IMHO to me) like taking a average idea, but adding as many effects to make it look good. What I think (and hope) we should be looking at is the concept, not the frills. >Without singling any of the entries out, I think that most of the >currently-posted entries are too complex. As a side note, and not a very >relevant one (maybe), it's pretty clear the list is populated by a mostly >left-brained crowd; look at how many of the entries depend on word play, >acrostics, and the like. Again I agree.. there are a few graphical people here, but most are "left-brained crowd".. but what's Boosts target audience? It's actually a serious question.. first line would be developers.. so a "left-brained crowd" logo would be ok, second line are companies.. which probably don't look at the logo, more the legal use of boost. What I'm trying to say is most logo's are for the general population.. in the case of boost (unfortunately) we don't have world domination.. so we should be producing a logo for the selected target audience. >Not saying that's bad, but again, the logos people >tend to remember are more likely to be graphic than semiotic. Yeah, I guess >that one deserves a smiley, on the grounds of self-referential irony. So >here: <g>. Now, if there were just a way to make emoticons >tail-recursive...come to think of it, I'm surprised no one used recursion as >a means of indicating "boostness." If it weren't too late, I'd maybe have a >go at that. Although most of my ideas were based around shapes, color use, >and shading. I agree with "graphic than semiotic" for the general population.. does it apply to potential Boost users? I'm not so sure... but believe its probably true. >Incidentally, I'm also surprised no one has tried to define a coherent color >scheme, especially given that there *are* graphic designers present. Is it >just that everyone unconsciously accepted the existing "cool" scheme? Only >a couple of the entries even try to do much with color, and I can't find any >consistency in the usage (possibly my fault; it's just a hobby with me). >Okay, <\kibitz> I started writing an email awhile back (which I didn't posted), commenting on various designs.. however writing it I felt as it I was actually questioning the process rather than the produced logos (I'm not knocking the designers or anyone else.. just questioning) Why I'm responding to your email is a similar thought... Before we have a boost logo, do we need to define the boost "colours", the boost "font".. the foundations of a "corporate" logo? Or another example, capitalization.. should should Boost be "boost", "Boost" or "BOOST".. my thought is "Boost" in documentation, and "boost" (because coding standards apply) in code. Buts what about in a logo? Going back to colours.. I'm not sure what you mean about the "existing cool scheme".. I presume variants of blue.. there's are good reasons... 1) (unfortunately) most of us are male (and our target audience).. and we have a preference for the colour. 2) Industry Conventions.. I posted a link awhile back (http://lists.boost.org/MailArchives/boost/msg75724.php) which gives another reason; <quote> I'm no expert either but http://graphicdesign.about.com/od/logotips/a/8logoelements_2.htm has a interesting point about colour which I haven't seen mentioned here; Works Within Industry Conventions Often there are consistencies among logos in certain industries, and following these conventions can help customers more easily identify what you do or what you sell. This doesn't mean you should sacrifice originality, but it does mean you (or the firm creating your logo design) should be aware of patterns among logos in your industry and somehow incorporate these consistencies into your design. For example, did you realize that the main color for the logos for Microsoft, IBM, Dell, Hewlett Packard and Intel is blue? The color blue is associated with stability and progress and has long been a standard color among high-tech companies. So if you were a technology company, you would probably want to incorporate blue into your logo design to take advantage of these positive built-in associations. </quote> I guess choosing a logo is very personal and emotive (compared to accepting, or not, a new library).. but personally I trust the judgement of the people here and the process.. discussion is the key I feel. Regards Mark

1 0

Re: [boost] Re: RPC library
by Iain Hanson 10 Mar '05

10 Mar '05

On Wed, 2005-03-09 at 10:22 -0500, Caleb Epstein wrote: > On Wed, 9 Mar 2005 08:45:52 +0000 (UTC), Jarl Lindrud > <jlindrud(a)hotmail.com> wrote: > > > > As for messaging vs RPC, I think the same thing applies; it is easier to > > > build an RPC layer on top of messaging than the other way around. > > > > If you have oneway RPC's, why would it be difficult to build messaging on top of > > that? The two seem to me to be almost the same thing. > > Messaging is often built on top of a broadcast or multicast transport, > so one does not need to locate or connect to a remote endpoint in > order to publish messages. In most, if not all messaging systems you do have connect to an end point. The remote server provides various QoS and you need to register your subject or channel and whether you are a push or a pull publisher. Oh 8-) I think I'm re-inventing the CORBA Notification service. What a surprise. > I don't think one-way RPCs are an adequate > replacement for publish-subscribe semantics like these if you have a > large fanout. Simple one-way RPCs don't have a return value and can't throw exceptions an so there not a good way for messaging if you want QoS other than best efforts. The fan out is irrelevant using multi-cast. /ikh

4 3

looking for Dietmar's thesis
by Max Khesin 09 Mar '05

09 Mar '05

Does anyone have a copy of Dietmar Kuehl's Master's thesis stashed somewhere? The ftp link is dead, and I cannot find mine. thanks, max This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

[shmem] Uploaded to Vault+documentation questions+misc
by ION_G_M 09 Mar '05

09 Mar '05

Hi James and all shmem users, Sorry for uploading to boost files but I had some problems with file size, so I uploaded to boost files instead. In boost vault you will fine a new folder (Shmem) with 3 new files: Shmem.2005-03-06.tar.bz2 //library Shmem.2005-03-06-doc-1.tar.bz2 //doc1 Shmem.2005-03-06-doc-2.tar.bz2 //doc2 Write now I am writing documentation with a text editor and it's just a pain. For this version, I've discovered the CDATA usage so I don't have to manually escape XML characters (<, >, &). I will have a look at Quickbook. Is there any way to "insert" a cpp file directly on the code using BoostBook/QuickBook? That would help me a lot to mantain example code without errors. I've also seen in unordered associative containers documentation that colored code is used and I'm very interested in that, but I don't know if that is provided by BoostBook or was created with an external tool. Regarding new version, there are some name changes, so please, forgive me. I don't plan any further name changes except after a boost review. I've tested it in Windows XP using visual 7.1 mainly and Linux 2.6 kernel (Suse 9.2) using gcc 3.4.1. But it's possible to be errors in some linux tests. For this version I don't have any atomic swap/inc/test function and I don't plan to have it, because library has grown so much that I prefer to polish a bit this. I agree that those functions would be very useful to implement lock-free allocators and structures. If win32 shared_mutex/shared_condition seem very rudimentary test/yield functions but I've not found any pthread-like process shared mutex/condition implementation in any place (the latest time I checked, cygwin, pthread-win32, Windows Unix Services, didn't support that) so I had to make this hack to go on. When I propose a review process, surely synchronization objects should be included/adapted to boost threads, but currently boost::thread's elements don't allow single threaded builds, so I can't use boost::xtime and scoped_locks in shmem when synchronizing two single threaded processes. That's why I've copied those classes in my library changing their name. One last thing: shared memory creation/destruction is not very portable, because I can't find a common implementation that suits win32/posix shared memory model (I mean shm_unlink behaviour). I've not found any valid implementation except using System V shared memory to emulate Win32 shared memory, but I want to use posix functions if available. Has anyone solved this before? Well, thank you for your comments and feel free to write if any problem is found. Regards, Ion

5 5

Re: [boost] [review] hash functions
by brangdon＠cix.compulink.co.uk 09 Mar '05

09 Mar '05

In-Reply-To: <d0kr8r$gl6$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > It's a pleasure to announce that the review of Daniel James' hash > functions library starts today (8th of March) and ends the 12th > of March. I have some questions about the design. First, why does hash_combine have a void result, and have side-effects on its arguments? Wouldn't a pure, side-effect free function be better? Second, why doesn't hash_range depend on the length of the sequence? For example, the hash_range of { 12 } and { 0, 0, 0, 12 } are the same. I'd rather they gave different results. Thirdly, the hash values love producing 0. For example, hash_value( (char *) NULL ) and hash_value( false ) are both 0. hash_combine on a range of 0s will produce another 0. Am I the only person who sees this as a problem? -- Dave Harris, Nottingham, UK

2 1

[Boost-bugs] [ boost-Patches-1160158 ] Perl style foreach iterating
by SourceForge.net 09 Mar '05

09 Mar '05

Patches item #1160158, was opened at 2005-03-09 20:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1160158&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amir Taaki (genjix) Assigned to: Nobody/Anonymous (nobody) Summary: Perl style foreach iterating Initial Comment: somewhere in boost, there should be a perl style foreach iterator, like so #define ITERATOR(obj) typeof(obj.begin()) #define foreach(v,i) for(ITERATOR(v) i = v.begin() ; i != v.end() ; i++) genjix at gmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1160158&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0