- Boost - lists.preview.boost.org

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

16 Mar '05

In-Reply-To: <012301c5299e$0e2b2f90$6501a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > This is because you ignored the "use_a" member when computing the hash > value. I didn't ignore it; hash_value uses it, albeit not in the best way. > We can't prevent these mistakes in general; if you omit a member > (that affects the equivalence relation) when computing the hash value, > the computation is just wrong. In this case the computation was correct, and indeed carefully chosen, but produced needlessly many collisions. > A hash_value that encodes the type will just hide the error from you if > a and b have different types The point is that even the corrected version is needlessly throwing away some valuable entropy. It's not about hiding the error, it's about having the best possible hash function. -- Dave Harris, Nottingham, UK

3 3

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

16 Mar '05

In-Reply-To: <01b201c52987$e0bbb950$6801a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > If you _know_ how the default hash function will perform on your key > set, you can make the decision of whether to use it or not, and if the > hash function is standard, you do not have to re-evaluate your decision > each time you change platforms. I do appreciate the benefits of stability. What isn't clear is whether it trumps hash quality. This is a judgement call, in that it partly depends on which issue is more important to you. Ultimately if you want stability you can get it by using your own hasher. If you want the best quality the platform can deliver, then that's intrinsically non-portable; it should be provided by the vendor but in a standard way. We could both be made happy if boost provided 2 hashers as standard, one for stability and one for quality. However, I don't think we want to go that route at this stage, and anyway there can only be one default. This is /not/ a deal-breaker for me. I won't reject the proposal because it favours stability over hash quality. -- Dave Harris, Nottingham, UK

2 1

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

16 Mar '05

In-Reply-To: <01c301c52989$d50a2f40$6801a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > I think that it is better to fix the zero trap in hash_combine, because > this does not depend on users remembering to initialize the seed to > default_seed, instead of zero. Did you see my suggestion of changing the primitive hash_value functions instead? That also does not depend on users remembering to initialise the seed. size_t hash_value( int v ) { return size_t(v) + default_seed; } And similarly for long, etc. Is there a reason to reject this? > 2. Add a hash_range overload that takes a seed. > > 2a. void hash_range( size_t & seed, It first, It last ); > 2b. size_t hash_range( size_t seed, It first, It last ); > 2c. size_t hash_range( It first, It last, size_t seed ); > > which are listed in order of my preference. So we're talking about a family of 3 functions: 2a: void hash_combine( size_t &seed, T value ); void hash_range( size_t &seed, It first, It last ); size_t hash_range( It first, It last ); 2b: void hash_combine( size_t &seed, T value ); size_t hash_range( size_t seed, It first, It last ); size_t hash_range( It first, It last ); 2c: void hash_combine( size_t &seed, T value ); size_t hash_range( It first, It last, size_t seed=0 ); I think 2b is very error-prone, because of the lack of consistency between how hash_combine and the seeded version of hash_range return their results. 2a is less error-prone, but it seems needlessly confusing to have the two versions of hash_range return their results in different ways. In general there's a lot of similarity between hash_combine and hash_range which those versions fail to bring out. I'd rather be more consistent, eg: (a) size_t hash_combine( size_t seed, T value ); size_t hash_range( size_t seed, It first, It last ); or: (b) void hash_combine( size_t &seed, T value ); void hash_range( size_t &seed, It first, It last ); (Perhaps with overloads to catch passing a non-size_t first argument.) I don't see much value in adding a hash_range which doesn't take a seed. Especially with (a), because we can easily pass 0 explicitly. -- Dave Harris, Nottingham, UK

2 1

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

16 Mar '05

In-Reply-To: <019d01c52985$a04f54f0$6801a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > You also need equal_ptr<MyType>. Indeed. > Also, it is easy to break the above unordered_set my modifying some > of the MyTypes. Yes, that's something to be aware of. I use the approach on types which are immutable, so it doesn't arise. > size_t Derived::hash_value() const > { > size_t seed = my_unique_value; > > hash_combine( seed, Base::hash_value() ); > hash_combine( seed, m_value ); > > return seed; > } That leaves the problem of assigning a different my_unique_value to each subclass, bearing in mind that different subclasses may be written by different people, teams or organisations. Without some kind of system people may just copy and paste code from one class to another and not change the value. -- Dave Harris, Nottingham, UK

2 1

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

16 Mar '05

In-Reply-To: <989aceac05031508512fb3bd43(a)mail.gmail.com> (reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfe r-encoding:references; b=R/dgT5RcmFTM4l6wo1FsmJV0WmZRxxS4UwfDvrZfxiBXu3i07NjqdqXmY0k93EfeA2rzuv0U dyun6iZo4Mn86mrySznULAY97Xn/zgqN3tU49cmIB/EtvwNWQzyHhnrH/iKu8pfDQoo6swyqX4 AJ8ih0MJXLu4umRrhBw7YSD2E=) wrote (abridged): > > However, it yields hash values for int * different to the values for > > char *, so with the current design aims we can't use it. > > It also has the undesirable side-effect of making the hash value > depend on the machine endianness. The same set of integers would hash > to different values on (say) Sparc and Intel machines. True - another variant of the stability issue. -- Dave Harris, Nottingham, UK

1 0

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

16 Mar '05

In-Reply-To: <d17nlh$8o3$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > I'm glad that I'm not the only person who's worried about alignment. > But this is a problems for a cross-platform library. Either I'll have > to introduce a load of macros to tweak it on various platforms (I'll > need help there) or just accept it. We can probably find something which gives reasonable results across a wide range of platforms. Shuffling the bits in a hash_combine-like manner would help. Eg something like: template <typename T> size_t hash_value( const T *p ) { size_t value = reinterpret_cast<size_t>(p); return value + value / sizeof(T); } If there's an easy way to turn sizeof(T) into a power of 2, use it. In many cases it will already be a power of 2, and I suspect the performance difference isn't crucial anyway. Alternatively we could just use: return value + (value >> 3); which ought to be reasonable for most small objects. It may also be reasonable for large objects that are heap-allocated, depending on how the heap is implemented. Anyway, I think it is better to do something like this than to just return value. -- Dave Harris, Nottingham, UK

1 0

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

16 Mar '05

In-Reply-To: <d174ak$vp3$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > are you saying we don't want to hash a Base* as a void*, but use > object properties instead? Sometimes. It's a reasonable thing to do. It's what my own app actually does. It shouldn't be the default, of course. Mainly I'm saying that equality tests sometimes need to be polymorphic, and when they are the corresponding hash_value needs to be as well. So sometimes we will be comparing hash values from different types. (Other people here have claimed that never happens.) -- Dave Harris, Nottingham, UK

1 0

No tests on como?
by Peter Dimov 16 Mar '05

16 Mar '05

We don't seem to be running any tests on Comeau C++, why? Not using the "reference compiler" for our testing doesn't make much sense. Has the "reference compiler" changed without me noticing? -- Peter Dimov http://www.pdimov.com

8 23

How to add examples ot the regression testing?
by Gennadiy Rozental 16 Mar '05

16 Mar '05

I want to make sure that all examples are successfully compilable. What is the best way to do this? Gennadiy

3 3

Re: Sockets: proposal for a library design
by Don G 16 Mar '05

16 Mar '05

Hi Scott, > Networking is inherently asynchronous. Initiation and acceptance > of connections and I/O may be disguised as synchronous but other > activity (e.g. "network down") cannot. Network APIs will often > defer such errors until the next reporting opportunity (e.g. next > I/O request) but this is a band-aid that is sometimes enough and > at other times downright misleading. I assume that something > going by the name of Boost.Net would be targeting a higher > sophistication. Amen. It took me some time to get used to the work around that one should always try to have a pending read in order to detect problems. In some cases that works, but it depends on the protocol whether or not you can read at the right time. > Proposing that all network communication is asynchronous does > not preclude any synchronous coding. As discussed in other > threads (i.e. RPC) a "low-level", asynchronous library may be > the "core" of a Boost.net while synchronous services may be > built on top. While this will work, in my experience there are efficiencies to be had if the synchronous methods aren't forced to create/store callbacks that simply signal condition variables. Of course, the gains will depend on the cost of the async mechanism in question. > I think an asynchronous, core Boost.Net should expose fundamental > network services. In the case of TCP, that would be the reliable, > async 2-way transfer of data blocks. Achieving a clean and > portable library at this level would be achievement enough. What, no UDP? :) > Dragging I/O streams into the "network discussion" at this > point is almost premature; it moves the focus up the network > stack. Again this doesn't preclude those who need to from > integrating with I/O streams at a later point. I agree. > $0.01 Hey! That was at least $0.03! Best, Don __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0

Re: Sockets: proposal for a library design
by Don G 16 Mar '05

16 Mar '05

Hi Boris, My responses are below... >> I would suggest that a proposed Boost.Net library should focus >> on networking in a more abstract manner, and not be merely a >> socket encapsulation. IMHO, sockets are a terrible API and >> should be hidden as fast as possible. A socket wrapper class >> is appropriate, but I would not go to any trouble to change >> the socket API. Simply wrap the resources and provide portable >> access to the underlying system. The real end-user part of the >> Net library should not talk about sockets (unless one provides >> a method like get_native to return the socket handle, and that >> method is defined as non-portable). > > This reminds me of the layers requirement from > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl? > BoostSocket/SocketRequirements. > I agree that it would be nice to have some easy-to-use high-level > classes for concepts that are used in network applications again > and again. Yes; sockets are just a means to that end and not the end in themselves. As such, they need not receive much special design consideration because that is not where you want users to interact with the library. A robust socket layer may only encourage undesirable use. The socket layer that has involved in my own code consists of a single Socket class with: a destructor for cleanup, methods that handle the mapping of non-portable EFOOBAR codes to portable exception types or return values, const-correctness, default arguments in a few places, etc.. The network layer simply uses sockets to implement the abstraction, and is the only direct user of sockets. > I agree again. There shouldn't be any of the four I/O models > omitted. We will see as we proceed if supporting various I/O > models is easy to implement and to use at runtime (especially > switching between I/O models). The I/O model that troubles me is the select/poll model. That is the mechanism I have used to implement the other three and it is not readily apparent how to expose it to the user as well. I may be surprised, but I think most folks would not mind seeing that model go away. The async I/O model with callbacks (essentially made from inside the select/poll/whatever loop) would provide a robust replacement for that tedious body of code. >> As others have also suggested, I would agree that the net >> facilities not be tied up into I/O streams. It would be >> better to provide the network facilities and then layer >> on I/O streams for those that want it. > > Several people dislike the idea of a network library built > on I/O streams. What are the reasons for this? I can only speak for myself, but I just don't like I/O streams. They seem to have a lot of clunk and little value, IMHO. They may work for text protocols, but in my use of network communications, they don't feel right. For example, the output would probably need consistent flushing do get data out of the buffer and on to the wire. > Is this a request for a more low-level access to socket > functions like read(), write(), send() and recv()? Again, I don't view socket access as the goal, but essentially yes: access to the "primitives" is what I would want. For example, I would want to be able to differentiate EOF from ECONNRESET(?) from ETIMEOUT, etc.. > The only reason I see why I/O streams should not be used is > the lack of support for an asynchronous I/O model. The > network library would have to add functions for asynchronous > support Yes, the network layer has to define what asynchronous I/O looks like. Again, I think a function<> with an appropriate signature is the answer. If the users needs those calls to be queued/marshalled, that is not the problem of the network layer. > until one day I/O streams support an asynchronous > I/O model by default (btw, anyone working on this?). I don't see how I/O streams could be asynchronous because async file I/O is not portable. For example Windows 95/98/Me don't have it. I suspect that many other systems are similar. Even though Windows NT (and 2000, XP, 2K Server) have async file I/O, it is not something that select() can handle as it can on *nix. >> Usage examples: > > Thanks again! When the socket class hierarchy is more > stable I hope to move upwards to high-level classes > representing concepts from the network world you used > in your examples. Most welcome. If I recall, the actual number of calls to socket API's made in my entire code base was so few (probably around 10-20) that even the little time I had spent on the socket layer was probably overkill. >> One thing I think is essential when using a blocking model >> is cancellation. For example, I have a reset() method on >> Acceptor, Address, Datagram and Stream that can be called >> at any time to cause blocking methods to terminate with a >> cancel exception (obviously this must be from another >> thread). Ironically, these reset() methods meant I could >> not use blocking socket calls to implement my blocking >> methods - recv() cannot be canceled once it blocks (at >> least not portably)! > > I added this to the Wiki but I am not sure if a network > library should support it. If you have two threads in your > application and one thread is halted because of a blocking > call it might have been better to use a > nonblocking/asynchronous I/O model? Perhaps, but some produces are just best designed as synchronous. They can go along merrily producing data and waiting for it to be consumed before producing more. Eventually they will block, and if they cannot be canceled (forced to unblock), you have a problem. IMO, any mechanism that can block indefinitely really needs some way to cancel. This should not be confused with thread cancellation. In this situation, once a stream is canceled/reset, it is almost completely unusable (most methods will throw the cancel exception). Best, Don __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0

boost::bind now with limited operator support
by Peter Dimov 15 Mar '05

15 Mar '05

boost::bind now supports operator! and the relational operators ==, !=, <, <=, >, >=. For the latter, the left operand must be a bind expression, the right operand can be a value, a placeholder, or another bind expression. Not exactly a Lambda, but good enough for many common tasks. -- Peter Dimov http://www.pdimov.com

1 0

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

15 Mar '05

In-Reply-To: <d11prg$uvt$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > > Firstly, I think we have some agreement that the signature: > > > > size_t hash_range( It first, It last ); > > > > is wrong > > I didn't get the impression of any agreement about that. > > > and there should be some way to provide an initial seed. > > Although, I agree with this. That's all I meant. I knew there wasn't much agreement over whether side effects are bad :-) My review was a lot more conservative than my comments in discussion. > > We have some agreement that using reinterpret_cast would be better. > > Yes, and this will be fixed. When I wrote it seemed there were still unresolved issues. In fact, I don't believe anyone has yet posted an acceptable hash_value for pointers. Presumably we want to shift out bits which are always 0 for alignment reasons. > It is proposed that the standard explicitly specifies the hash > functions (and I've been criticized for not doing that) but part > of the purpose of this library is to get real world experience > on what the specification should be. And change it, if necessary. OK. > I do intend to spend more time looking into alternatives in the future > (and will look into adding a constant to hash_combine very soon). OK. Although I suggested it, I'm not sure it's the best fix, as compared with using non-zero initial seeds. const size_t default_seed = 0x9e3779b9; // Or whatever. size_t hash_range( It first, It last, seed=default_seed ); A signature like that provides a hook to introduce variation between similar types if the author desires, and also allows ranges to be hashed as subranges with the output of one subrange feeding into the next. The default value allows the issue to be safely ignored by naive users. So it's a good idea anyway, and since it also fixes the problem with zeros maybe we don't need to fix that twice. This does leave the issue of other places where hash_combine is called. It would be sufficient if we could be sure that all used a non-zero initial seed, eg: size_t hash_value( std::pair<int,int> p ) { size_t hash = default_seed; combine_hash( hash, p.first ); combine_hash( hash, p.second ); return hash; } and the documentation would encourage that, but we can't really be sure of it. Another approach is to change all the primitive functions. For example: size_t hash_value( int i ) { return static_cast<unsigned int>(i) + default_seed; } Introducing the non-zero constant here is surely as efficient as in combine_hash, if not more so. Admittedly it doesn't eliminate the zero, it just moves it around, but it should massively reduce its dynamic frequency. (Actually it will eliminate the zero where it matters most, ie for types like bool, char and short which are smaller than size_t.) > Did you see Peter's original proposal? Yes, I had followed most of the links. > > For example, the proposal has no specialisation for chars at all. I > > can't tell if that is an oversight, or whether it is a design > > aim [...] > I don't think it's either. Peter? Peter has now said it is a design aim. That even you weren't sure illustrates my point :-) > When hash_range is called with a seed argument, it would be equivalent > to calling hash_combine for pair<int, int>. If I understand the principles being advocated here, pair< pair<int,int>, pair<int,int> > should have the same hash_value as int[4]. How do you achieve that without giving hash_value( pair ) an initial seed? ----- I find myself increasingly drawn to the idea of a hasher object. The main signature should be like: template <typename T> Hasher &hash( Hasher &hasher, const T &t ); with implementations looking like, eg: template <typename First, typename Second> Hasher &hash( Hasher &hasher, const pair<First,Second> &p ) { hash( hasher, first ); hash( hasher, second ); return hash; } Then hash_value, if we still need it, would be like: template <typename T> size_t hash_value( T &t ) { Hasher hasher; hash( hasher, t ); hasher.finalise(); return hasher.value(); } but would rarely be called directly. This solves the problem of the default value, allows us to store intermediate results bigger than size_t (which may be important for cryptographic-strength hashing), and the finalise() step provides a hook for the final mixing/avalanching which some algorithms use (eg Paul Hsieh's). > Perhaps it would be better spelt as: > > template <class It> > void hash_combine(std::size_t& seed, It begin, It end); Yes, I considered that. I wasn't sure whether overloading the name would help or hinder - hash_range and hash_combine are not substitutable for each other. > Well, we did discus the type of review before it started, and nobody > raised any objections. I don't object to quick reviews in principle (although if someone can only contribute, eg, on Sunday mornings, a 5-day period is going to leave them out completely). > > I am not an expert on hashing, but I have implemented my own hashing > > library. I have encountered practical problems due to different > > objects having the same hash values. > > Is this in C++? Yes. The main problem was zeros. My hash primitives produced zeros and my hash_combine turned zeros into more zeros. Just as with the initial boost proposal. > I would have thought that type safety would have helped avoid > such problems. This was specifically an issue with optional or alternate types. For example, I had something similar to: size_t MyType::hash_value() const { return use_a ? hash_value(a) : hash_value(b); } where a and b could be different types. We can avoid that mistake in library classes like boost:variant, but that doesn't prevent it recurring in user code. When I am dealing with types without much intrinsic variation, eg bools, I found it important to exploit such variation as I did have as much as possible. Hashing false and 0 to different values helped. > Thank you for reviewing the library and bringing up several good points. My pleasure. -- Dave Harris, Nottingham, UK

3 3

boost::filesystem in Windows 95
by Jorge Lodos 15 Mar '05

15 Mar '05

Hi We have a code base for Windows that compiles with common settings for all Windows platforms. When using boost::filesystem, this is no longer possible, due to the fact that Windows implementation in operations_posix_windows.cpp uses the API function GetFileAttributesExA, not available in Windows 95. GetFileAttributesExA could be replaced by FindFirstFile, which gives the same information and is available in all Windows platforms. This API is used in two different places, BOOST_FILESYSTEM_DECL bool _is_empty( const path & ph ) implementation and BOOST_FILESYSTEM_DECL boost::intmax_t file_size( const path & ph ) implementation. Using FindFirstFile instead of GetFileAttributesExA we would get: BOOST_FILESYSTEM_DECL bool _is_empty( const path & ph ) { # ifdef BOOST_POSIX ........ # else WIN32_FIND_DATA ; HANDLE hf = ::FindFirstFileA(ph.string().c_str(), &ffd); if (hf == INVALID_HANDLE_VALUE) boost::throw_exception( filesystem_error( "boost::filesystem::is_empty", ph, fs::detail::system_error_code() ) ); CloseHandle(hf); return ( ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY ) ? is_empty_directory( ph ) :( !ffd.nFileSizeHigh && !ffd.nFileSizeLow ); # endif } BOOST_FILESYSTEM_DECL boost::intmax_t file_size( const path & ph ) { # ifdef BOOST_POSIX ....... # else // by now, intmax_t is 64-bits on all Windows compilers WIN32_FIND_DATA ; HANDLE hf = ::FindFirstFileA(ph.string().c_str(), &ffd); if (hf == INVALID_HANDLE_VALUE) boost::throw_exception( filesystem_error( "boost::filesystem::file_size", ph, fs::detail::system_error_code() ) ); CloseHandle(hf); if ( (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) !=0 ) boost::throw_exception( filesystem_error( "boost::filesystem::file_size", ph, "invalid: is a directory", is_directory_error ) ); return (static_cast<boost::intmax_t>(ffd.nFileSizeHigh) << (sizeof(ffd.nFileSizeLow)*8)) + ffd.nFileSizeLow; # endif } Is there any chance this could be solved in boost::filesystem? Thank you for boost :-) Best regards Jorge

2 1

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

15 Mar '05

In-Reply-To: <001201c527e4$7405efa0$6501a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > > In my experience, if you want two different things to hash the same, > > you need to write their hash functions with that in mind. It is a > > special case which justifies not using the default hash function. > > Maybe, but this is not an argument for making the hash values different. True. Arguments for that have been given elsewhere. One argument is to maximise variation (and for types like bool it is desperately needed). Another is to allow treating of 32-bit values as bytes. For example, size_t hash_range( const int *first, const int *last ) { return hash_range( static_cast<const unsigned char *>(first), static_cast<const unsigned char *>(last) ); } may be a good implementation on some platforms. It does 4 times as many mixing steps (assuming sizeof(int) == 4) as the proposed algorithm. It is, I think, how the designer of the proposed hash_combine algorithm expected it to be used. However, it yields hash values for int * different to the values for char *, so with the current design aims we can't use it. > > But doesn't this mean that hash_value( pair<int,int> ) also needs a > > seed argument, if you want it to match hash_range( int[2] ) ? > > No. The seed version of hash_range is used when you want to compute the > hash function of a sequence, but you don't have access to the whole > sequence at once. It's goal is not to provide a way to change the > initial seed, but to make it possible to continue from an intermediate > seed. But suppose I have pair< pair<int,int>, pair<int,int> > ? Shouldn't that yield the same hash value as int[4] ? -- Dave Harris, Nottingham, UK

5 5

ANN: review of FSM library starts
by Pavel Vozenilek 15 Mar '05

15 Mar '05

Review of Finite State Machine library written by Andreas Huber starts today, February 21, and lasts 10 days. The library can be found at: http://boost-sandbox.sf.net/fsm.zip (781 kB). FSM is feature rich library to design finite state machines without need for external generator. It is accompanied by extensive documentation. Here are some questions you might want to answer in your review: * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? * 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? * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every reviewer should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Pavel Vozenilek FSM review manager

7 19

FSM Review
by Jody Hagins 15 Mar '05

15 Mar '05

I am sorry this is late. I made the mistake of introducing my kids to snow skiing. Now they can not get enough of it. Thus, we were gone again until Wednesday (yes, I let them skip a few days of school to go skiing). * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? I think the documentation is relatively complete. However, I am not exactly thrilled by the requirement on the reader to understand UML diagrams. On the other hand, this library is intended to represent UML in C++ (at least to my understanding), so I'm not sure what else can be done. A link to a basic tutorial on UML state machine diagrams would be appropriate in the "UML to boost::fsm Mapping Summary." I know you link to the 730 page OMG document on UML, but I'd also like to see something that describes the basic UML for state charts. * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? I think the requirements dictate the design. Specifically, the desire to mimic UML statecharts in C++. As stated before, the design brings with it some performance tradeoffs that will make this library unusable to some. * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? I think it is obvious that the library should be separated, though I do not think this issue itself should be a stumbling block for acceptance. Exception handling is very important, and I do not buy the rationale that allowing destructors to throw is not a problem in practice. I also do not think I really understand "two stage exit." * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? I did not look too much at the implementation, so I can not comment much here. * 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 think we have to define real-time. Traditionally, real-time systems have hard completion time requirements (e.g., the XYZ event must be processed in under 50ms). Even though I have performance issues with this library, I think it can still be utilized in many real-time situations. Andreas has stated several times that the dispatch time will be small compared to the handling time. However, I find this argument a bit lacking, especially for hard real-time requirements, where each cycle taken for dispatch is stolen from the reaction handler. My current application requirements do not fit the traditional definition of real-time. However, my SMs need to be as fast as possible, because in a real sense, my code is competing with other code. Without going into too much detail, when an "opportunity" is available, it is only available to the first one to see it, respond, and take that opportunity. Thus, my real-time requirement is that I have to be faster than anyone else playing my game. I think using this library would put me at a disadvantage in that particular space. However, I do have some applications in which this library could be used successfully (if I were inclined to learn enough UML to make sense of all the details). The documentation is clear enough about the performance issues. In fact, it may be too clear, as some people seem to see problems that may not exist in most applications. One last thing on performance, since it has been a hot topic in relation to this library. I do not think it has sufficient performance to warrant use in all my applications, and I assume the same for many others. However, it does have sufficient performance to be used in a large number of applications. If the docuemntation is clear (which it is), then users can decide when/how it can be used. I could make similar performance claims agains almost every boost library (and I have made them on this list about shared_ptr and signals). However, that does not mean we should eliminate those libraries from boost, nor does it mean that they should never have been accepted (but I would like to see a larger commitment to address performance issues in all currently accepted libraries). I would, however, like to see a separate submission which has a focus on performance, and I would really like to see the performance issue of this library revisited, especially with input from some of the folks here who claim expertise in that area. * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? I have used sevaral versions of SMC, solutions from Samek's "Practical Statecharts in C/C++," and my own hand-crafted stuff. I think SMC is the easiest to use, though it also offers the least flexibility. With moderate use, I think this library could become the standard tool for implementing state machines, with the caveat of every tool: it may need to be replaced if it is too slow. However, I also think that this tool requires a more structured design of your state machine than ad-hoc methods. Thus, if speed were an issue, translating this code to something else would not be too difficult. One thing I have not seen in other reviews is a comparison to GUI state machine tools. I know this is a library, with very different requirements. However, having virtually no experience with GUI tools that build FSMs, I'd be interested to see how this code stacks up with code generated by such tools. Specifically, I have avoided them because I want more control than they allow (or at least allowed when I first looked at them). Does anyone have experiences to offer in this regard? * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability problems? I used it on linux, with gcc. I am probably the last person in this community to offer porting advice to older compilers. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read all the documentation, and played with a few examples. Specifically, I tried to implement a subset of a current state machine to compare ease of use and performance. This library seemed more difficult to use, but I attribute most of that to inexperience. I am convinced that with some moderate level of experience, I could write state machines more easily with this tool. * Are you knowledgeable about the problem domain? I would not consider myself an expert, by any stretch of imagination. However, I have done my fair share of work coding state machines. I have used a small number of tools, and I have crafted my own, so I am at least comfortable with the problems represented by such a library. And finally, every reviewer should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes, with two conditions. 1. The name should definitely be changed. I am not sure, however, what a new name should be. I tend to favor one of Andreas' alternatives: umlfsm. 2. I also think there should be some commitment to revisit the performance issues. I am not sure how this works, but I'd be satisfied with a commitment from Andreas, possibly accompanied by a request to the Boost community for assitance. I am not certain that an acceptable solution can be found, but I think the issue at least needs to be addressed again, specifically with input from the Boost community.

12 37

[Boost-bugs] [ boost-Feature Requests-1163952 ] handle double '/' in the boost::filesystem
by SourceForge.net 15 Mar '05

15 Mar '05

Feature Requests item #1163952, was opened at 2005-03-15 22:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1163952&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Serg Repalov (rsrus) Assigned to: Nobody/Anonymous (nobody) Summary: handle double '/' in the boost::filesystem Initial Comment: Hi. Sometimes I make some path by hand. For example std::string str = "./"; //... some code .... std::string str2 = str + "/path/to/file"; The result is ".//path/to/file". If I try to make path from it: boost::filesystem::path fs_path2(str2, fs::native); I got exception. Is it possible to correct function path::m_path_append to handle this situation (double/triple/... separator in the middle of string)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1163952&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

Re: [boost] [FSM library] review result: accepted with fewconditions
by Iain Hanson 15 Mar '05

15 Mar '05

On Tue, 2005-03-15 at 19:10 +0100, Pavel Vozenilek wrote: > FSM library written by Andreas Huber has been > accepted into Boost, with few conditions > and few recomendations. > > > Thanks, Andreas, for your work and stamina > to get thus far! > Yes and congratulations to Andreas. > > The documentation is now very dense, splitting > it into smaller parts may help. More hyperlinking > would also help a lot. > Then could there also be a version suitable for printing structured pretty much as it is now please. /ikh

2 1

Re: Re: FSM review
by Dave Gomboc 15 Mar '05

15 Mar '05

> Rejection is not permanent. If a library has flaws and they > are substantial enough then it should be rejected so that > when changed, it can be reviewed again. > > I would like to see a state chart lib in boost but not as it > currently stands. I would not mind if it was accepted as > *beta* which would tell users that it has caveats. Given that the author has already had almost an entire year's notice on this issue, I think giving the current library some sort of "beta" status would be a mistake. This issue won't be resolved one way or the other until a) the review manager ignores the entirely reasonable expectation of constant-time state dispatch, and accepts the library into Boost anyway, or b) the existing code is changed to support constant-time dispatch, perhaps under certain constraints (e.g. when one doesn't use certain features), or c) code is added to the library that converts the specified machine during compilation into something that dispatches in O(1) (e.g. by an algorithm that converts M: S* x T -> S* into M': S' x T' -> S). If c) is the route chosen, whether to invoke this procedure could be made selectable by the user so that one can choose between a) minimizing compile-time (and minimizing risk of encountering compiler limitations, if such a risk exists), and b) maxmizing the performance (and optionally, minimizing the memory footprint) of the state machine at runtime. Dave

1 0

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

15 Mar '05

In-Reply-To: <d11prg$uvt$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > Well, we did discus the type of review before it started, and nobody > raised any objections. That's partly because it sounded like the interface was fixed and known good. Where-as we are now agreed that hash_range is going to take at least one additional parameter and possibly be renamed (to hash_combine) and the return type maybe changed to void; so the interface is not fixed. Had I known that I might have objected to the fast-track, but the only way to know it would be to actually review the proposal. Maybe if we are in a hurry we should delete hash_range and hash_combine from the initial official interface, while still using them for the implementation. That would enable the containers to move forward. > On a related note, I am going to be requesting a review for the > unordered associative containers soon. It has been suggested that since > they are based on TR1 they should have a shorter than normal review > (but longer than this one). So I guess you think it should have a full > length review? I have no idea. I am less interested in the containers than in the hashing. I don't think I've ever implemented a hashing container in C++. I don't currently plan to contribute to the containers review. -- Dave Harris, Nottingham, UK

2 1

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

15 Mar '05

In-Reply-To: <002901c527e7$9f9fb620$6501a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > The problem is that hash functions vary wildly in quality. Leaving the > default function unspecified (or implementation defined) is good if you > are lucky and the implementation you happen to use is good. It's a > tradeoff. I think if we provide a good quality default implementation, and also a good rational (and the rational is important here), then vendors are unlikely to change it to something worse. Vendors avoid unnecessary work. The eventual standard could recommend a specific implementation in a non-normative Note. > A fixed and predictable default means that you don't have to measure > the quality of the hash function for every implementation to which you > port your program. Your original tests are still valid. In general, performance varies between platforms. If one implementation has the fixed string optimisation and the other doesn't, my benchmarks for one will not apply to the other. I am not yet convinced that hashing deserves to be a special case. On the other hand, it does seem to be an area which can benefit from innovation. Eg a platform may have a super-fast near-cryptographic-strength algorithm implemented in hardware, and we're saying they can't use it? > The other side of predictability - that the hash function is not > affected by types or the particular representation of a sequence of > values - means that you don't necessarily have to re-run the > performance benchmark of your unordered_maps when you refactor the key > to use int[3] instead of struct { short, short, short }, or a wstring > instead of a string. I think you need to repeat your benchmarks anyway. You may find that values which used to fit in cache no longer do so. Or vice versa. If you are hashing pointer values then the collisions will vary from one run of the program to the next. Even if you can get stability for some set of program edits, there will always be other edits which don't get it. Reordering the hash_combines, or refactoring an object's state, for example. -- Dave Harris, Nottingham, UK

2 1

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

15 Mar '05

In-Reply-To: <d1409a$kc1$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > Think about how such a class would be stored in the proposed unordered > associative containers. If you use unordered_set<base*> then the hash > function will be called for the pointer, not the class. I imagine you would use a hasher which dereferenced the pointer. template<typename T> struct hash_ptr { size_t operator()(const T *p) const { return hash_value( *p ); } }; And perhaps this should be included in boost too? Eg this: unordered_set< shared_ptr<MyType>, hash_ptr<MyType> > looks reasonable to me. > If Thorsten writes ptr_unordered_set<base> then there might be a > problem with boost::hash<base>. Although it will equally apply to > std::equal_to<base>. Absolutely. In general when writing hash_value() you need to look at the corresponding equality operator. For example: bool Derived::operator==( const Base &base ) const { if (Base::operator==( base )) if (const Derived *p = dynamic_cast( const Derived * >(&base)) if (m_value == p->m_value) return true; return false; } Ideally we look at this and we decide there ought to be something in the hash_value which corresponds to the dynamic_cast. But what? We can try using hash_value( typeid(*this) ). However, that will be relatively slow and may not give good results, depending on how it is implemented. We could use our own type IDs, but allocating them is tricky. So it is tempting not to bother, and instead use: size_t Derived::hash_value() const { // return combine_hash( Base::hash_value(), m_value ); size_t hash = Base::hash_value(); combine_hash( hash, m_value ); return hash; } which is correct, but will produce more collisions than if we'd used the typeid. If hash_value( m_value ) yielded different results for different types of value, then the number of collisions would be reduced. The stability requirement compromises the quality of hashing. -- Dave Harris, Nottingham, UK

3 2

Re: [Boost-testing] Re: [test] numerous tests broken
by Caleb Epstein 15 Mar '05

15 Mar '05

On Tue, 15 Mar 2005 11:44:51 -0500, Gennadiy Rozental <gennadiy.rozental(a)thomson.com> wrote: > > errors_handling_test > > ifstream_line_iterator_test > > test_fp_comparisons > > test_tools_test > > Most of this test/compiler combination should pass. Failures caused by some > mix-up between test, Boost.Build and configuration file. I did not have a > time to localize the issue. I don't understand this answer. Are you saying the problem is fixed or you haven't yet had time to investigate it? -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Logo: version for candidate libs
by rasmus ekman 15 Mar '05

15 Mar '05

When the winning logo is selected, ask the designer to please create a version with the word "Candidate" stamped over or just below. It could also be somewhat greyed-out or whatever. This logo may be used in docs for libraries at all steps until acceptance; the Boost logo should be reserved for acccepted libs. (sorry if already suggested - haven't read all posts) re

2 2

Re: FSM Review
by Johannes Brunen 15 Mar '05

15 Mar '05

David B. Held and Paul A Bristow wrote: >> It will be a sad day when Boost rejects a good library because >> another library in a different part of the design space is >> theoretically faster. > IMO this hits the nail on the head. > As with too many reviews, there have been very interesting, > but essentially speculative, alternative ideas, > produced not during the 'proposed library' development phase, > but somewhat destructively and at the 'last minute'. > > These should not be a reason for rejection, > but should spur development of different > (and hopefully in some ways better) ideas to submit in future. I would like to second that. With best regards Johannes Johannes Brunen DataSolid GmbH Nobelstr. 3-5 41189 Mönchengladbach Tel.: 02166 / 955 789 Email: JBrunen(a)DataSolid.com Internet: www.DataSolid.com ____________ Virus checked by G DATA AntiVirusKit Version: AVK 15.0.3667 from 15.03.2005 Virus news: www.antiviruslab.com

1 0

Re: [boost] Re: Sockets: proposal for a library design
by Willam Lee 15 Mar '05

15 Mar '05

A C++ framework for network is very useful and long for. I have seen the ACE, but felt it too weight. The proposed library seems a lightweight one and the socket wrapper is appropriate. I think if user manage the sockets one by one, the proposed library will work perfectly. But in common network applications, a server usually serves on several sockets or ports with a select() style function. In this condition, how to process multiple socket class for different connection the proposal ? In the pseudo code, select() function is a member function of socket, maybe it can only process the 'this' socket. Finally I don't like build socket lib based on iostream, but the net lib can provide some operator like "<<" , ">>" to simulate the iosteam-style calling. Thanks Boris's work. best regards William Lee _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

3 2

boost::begin/end disappeared?
by Caleb Epstein 15 Mar '05

15 Mar '05

A number of regression tests failed today on gcc-3.4.3+ (both mine and Martin Wille's runs) for failure to find boost::begin and boost::end. I'd suspect something changing in the Range library, but nothing looks obivous. Anyone? -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

[test] numerous tests broken
by Caleb Epstein 15 Mar '05

15 Mar '05

This has been happening for several days. A number of the Boost.Test regression tests are failing across most/all platforms: http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/te… errors_handling_test ifstream_line_iterator_test test_fp_comparisons test_tools_test Gennadiy? -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

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

15 Mar '05

In-Reply-To: <018201c52567$1b710ca0$6601a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > But as I said, benchmarking hash functions is pointless. Real programs > do not compute the hash value of a random 256 byte buffer five million > times. They usually need to do something with the hash value. This > something typically involves a division on a prime to obtain a modulus, > several pointer chasings, and at least one equality comparison (which > on a 256 byte buffer will have considerable impact). I'd add that my own application caches the results of the hash at highish level, so it doesn't actually matter that much if it is slow. The equality comparison is only needed if the hashes are equal. If you are doing something like adding values to a set, and all the values are in fact different, then hopefully the hashes will be different and the equality tests never needed. In my own code I use a mixture of hashing and interning. This means that if objects are equal they probably have the same address. If they are different they probably have different (cached) hashes. Full byte-by-byte compares of all the data are rarely needed. -- Dave Harris, Nottingham, UK

1 0

template_assert
by Johan Paulsson 15 Mar '05

15 Mar '05

(If this is off topic, has already been discussed, or is stupid, I'm sorry) I wanted a static assert without #define, I ended up with this: template<bool MustBeTrue, int TemplateAssertError = 1 / static_cast<int>(MustBeTrue)> class template_assert {}; so template_assert<true> means TemplateAssertError = 1 / 1, no error template_assert<false> means TemplateAssertError = 1 / 0, error The only compiler I have is MSVC++ 2003. I have no idea how other compilers like it, but to me this seems like a better alternative to BOOST_STATIC_ASSERT. Is it? An example, with the code that will trigger template_assert commented out: // template<class Type> struct test { typedef template_assert<sizeof(Type) == sizeof(int)> assert_type; void do_nothing() {} }; template<bool Boo> void function() { template_assert<Boo>(); test<int> works; works.do_nothing(); //test<char> fails; //fails.do_nothing(); } void start() { function<true>(); //works //function<false>(); //fails } // In MSVC++ 2003 i can also use: template<bool Boo> void function() { template_assert<Boo>; //<-- no parenthesis ... but i suppose this is not portable (I don't have a copy of the C++ standard). Thank you all for making boost! /Johan Paulsson

2 1

RE: [boost] Re: FSM Review
by Iain Hanson 15 Mar '05

15 Mar '05

On Tue, 2005-03-15 at 12:06 +0000, Paul A Bristow wrote: > > | -----Original Message----- > | From: boost-bounces(a)lists.boost.org > | [mailto:boost-bounces@lists.boost.org] On Behalf Of David B. Held > | Sent: 15 March 2005 00:13 > | To: boost(a)lists.boost.org > | Subject: [boost] Re: FSM Review > > | It will be a sad day when Boost rejects a good library because > | another library in a different part of the design space is > | theoretically faster. > > IMO this hits the nail on the head. > > As with too many reviews, there have been very interesting, > but essentially speculative, alternative ideas, > produced not during the 'proposed library' development phase, > but somewhat destructively and at the 'last minute'. > Sorry, but check the archives before "speculating" on when comments have been made. I argued for state charts to be implemented in terms of STT at the pre-review in May 2004. > These should not be a reason for rejection, > but should spur development of different > (and hopefully in some ways better) ideas to submit in future. > Rejection is not permanent. If a library has flaws and they are substantial enough then it should be rejected so that when changed, it can be reviewed again. I would like to see a state chart lib in boost but not as it currently stands. I would not mind if it was accepted as *beta* which would tell users that it has caveats. /ikh

1 0

Boost.Thread docs and more (1.32)
by Johan Nilsson 15 Mar '05

15 Mar '05

Hi, I was browsing the website for Boost.Thread 1.32 updates and became somewhat confused. This is just the few items I noticed during a quick browse. 1. The library isn't mentioned along with other updated libraries on the start page. 2. Quote from 'Design/The Next Phase': "The next phase will address more advanced synchronization concepts, such as read/write mutexes and barriers.". I guess this is just one of the mentioned "remaining inconsistencies" from the release notes. 3. In the release notes it is also stated that recursive_mutex is now implemented using a critical section under Win32. AFAIK this was already the case with 1.31 (or perhaps even earlier?). I also glanced a bit at the recursive_mutex implementation under Win32 and it looks a bit weird to me (this is just an extract): --- recursive_mutex.cpp --- ... recursive_mutex::recursive_mutex() : m_mutex(0) , m_critical_section(false) , m_count(0) { m_critical_section = true; if (m_critical_section) m_mutex = new_critical_section(); else m_mutex = new_mutex(0); } recursive_mutex::~recursive_mutex() { if (m_critical_section) delete_critical_section(m_mutex); else delete_mutex(m_mutex); } ... The if/else clause exists in virtually all methods even though there is no way to affect it from client code. Is this some kind of preparation for future improvements, just some cut and paste from recursive_try_mutex, or ...? 5. Last (but not least): Why aren't the more recent contributors mentioned a bit more up-front in the documentation - I think they deserve a lot more credit than this? // Johan

1 0

Re: [boost] No tests on como?
by Bronek Kozicki 15 Mar '05

15 Mar '05

Bronek Kozicki <brok(a)rubikon.pl> wrote: > 2 como does not support dynamic libraries at all; this is going to be > improved with next version (hopefully to be released soon) my poor memory does not serve me well. Apparently there is some support for consuming DLLs (like system libraries), however support for building them is still lacking. B.

1 0

Re: [boost] Re: FSM Review
by Iain Hanson 15 Mar '05

15 Mar '05

Hi Dave, I've taken the liberty of correcting my poor spelling in the quoted parts of my message of last night. My only excuse is that it was late :-(. ( And I am a native English speaker :-( ). On Mon, 2005-03-14 at 22:34 -0600, David B. Held wrote: > Iain K. Hanson wrote: > > [...] > > There is no doubt ( in my mind ) that Andreas has done some very > > good work. The issue is whether this library is suitable for > > acceptance into boost. IIUC boost is predominately about best of > > breed libs. > > Yes. And sometimes there is more than one best in the breed. Agreed. We have a collection of containers to deal with genuine trade- offs. > > > The primary philosophy in C++ is you don't pay for what you don't use. > > ...And yet, we have iostreams. I don't know the history of iostreams or std::string but I'd be surprised and a little disappointed if there flaws were known and yet they were still admitted to the std. I know iostreams pre-dates the std so perhaps its historical. > > Andreas has deliberately taken a different approach. He has chosen > > to go for the all singing, all dancing heavy weight approach. > > ...Much like shared_ptr<>, which got into TR1. And I dare say that > shared_ptr<> is used in far more performance sensitive contexts than > the FSM. If we declared that shared_ptr<> is the end-all, be-all > smart pointer for C++, I would be as unhappy as you are. For very different reasons. shared_ptr deals with safety. The current FSM proposal takes a feature like state specific storage and every user has to pay for it whether they need it or not even if there is another cheaper way to provide it. ( there always is ). > > > He has explained his approach on this list. You pay for State > > Specific Storage whether you want it or not. You currently get > > non-linear event dispatch ( without orthaganal regions ) if you > > use outer states. And you get horrible performance on transitions > > ( with loss of state specific storage when you transition out of > > a state ). > > And if that were a deal-breaker, people wouldn't be using the > library, would they? Apparently, there are applications where > these are not the critical metrics, and people have already found > use for it. I'm sure its useful. Just as iostreams and std::string are useful. But I don't think that std::string would get through a boost review if presented for the first time today. And nor would it deserve to. Associative containers have O ( log N ) performance for a number of operations because of the underlying algorithm. The current FSM ( State Chart ) proposal has its performance characteristics because of the choices made by the author not for any fundamental underlying reason. All state charts can be collapsed to a STT. > > > I know that if I hand write a GOF state pattern I can get close > > to the scalability of the FSM lib but with constant time event > > dispatch through a single indirection and can change state through > > a single assignment. > > But can you provide all the other features of the FSM proposal? If > not, then you're comparing apples to oranges, right? Of course. At the end of the day, the most an FSM lib can give us is the elimination of some boiler plate code. The doing away with cut and paste. I think few will be willing to pay the performance price to do away with boiler plate and cut & paste. > > FSM is the domain but whether it is spelt STT or StateChart is > > irrelevant one can be mechanically collapsed to the other. But > > the fsm proposal does not do this. > > > > If we have a StateChart lib in boost it should scale as well as any > > other library in boost > > I'm not quite sure what you're saying here, but clearly there is > precedent for solutions at different granularities/complexities > /performance tradeoffs in Boost. Consider tokenizer/regex/spirit. > Consider compose/bind/lambda. If you think that Boost needs a > low-level FSM that concentrates on performance over abstraction, > you may be right. But if you think that it does not need an FSM > library that focuses on abstraction and ease of use, it would > appear that some users might disagree with you. > I think that you are mistaking me. I strongly believe in solutions at different granularities and the trade-offs that they require. If this proposal was an just an std::map and presented as the containers library then it would just need docs to be corrected to say that it is part of a containers lib. ( Just as Andreas has agreed his proposal should be spelt StateChart ). My issue is that this is a std::vector with the performance and weight of std::map. When we know this up front then *I believe* it is a good reason to vote for rejection. /ikh

1 0

[addressof] patch for Borland
by Eric Niebler 15 Mar '05

15 Mar '05

Borland doesn't like boost::addressof when used with arrays. It won't let you reinterpret_cast from an array reference to a char &. Russell Hind was good enough to test the following patch for me and confirmed that it works around the problem. (This is needed to get BOOST_FOREACH to work with Borland.) If no one objects, I'll apply the patch myself. -- Eric Niebler Boost Consulting www.boost-consulting.com Index: addressof.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/utility/addressof.hpp,v retrieving revision 1.7 diff -b -d -u -r1.7 addressof.hpp --- addressof.hpp 27 Jul 2004 03:43:33 -0000 1.7 +++ addressof.hpp 14 Mar 2005 18:15:31 -0000 @@ -33,6 +33,22 @@ &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); } +// Borland doesn't like casting an array reference to a char reference +// but thes overloads work around the problem. +# if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) +template<typename T,std::size_t N> +T (*addressof(T (&t)[N]))[N] +{ + return reinterpret_cast<T(*)[N]>(&t); +} + +template<typename T,std::size_t N> +const T (*addressof(const T (&t)[N]))[N] +{ + return reinterpret_cast<const T(*)[N]>(&t); +} +# endif + } #endif // BOOST_UTILITY_ADDRESSOF_HPP

4 8

Re: [boost] Re: boost/pending/mutable_queue missing clear() function
by JOAQUIN LOPEZ MU?Z 14 Mar '05

14 Mar '05

----- Mensaje original ----- De: Douglas Gregor <doug.gregor(a)gmail.com> Fecha: Lunes, Marzo 14, 2005 9:29 pm Asunto: Re: [boost] Re: boost/pending/mutable_queue missing clear() function > > On Mar 14, 2005, at 12:55 PM, David Abrahams wrote: > > > Douglas Gregor <doug.gregor(a)gmail.com> writes: > > > >> On Feb 11, 2005, at 5:39 PM, Lloyd J Lewins wrote: > >> > >>> I notice that mutable_queue is missing a clear() function, > i.e. a low > >>> overhead way of emptying the entire queue (without resorting to > >>> repeated > >>> pops). However, I think clear() can be implemented as follows: > >>> > >>> void clear() { clear(); } > >>> > >>> Which is efficient and (often) fast. > > > > Surely that one only runs until you blow the stack. Am I missing > > something? > > No, but neither did I :) The correct code (in CVS of course) is: > > void clear() { c.clear(); } > A silly and totally OT std-riddle: would an optimizer be allowed to rewrite void clear() { clear(); } as if: void clear() {} ? If not, why not? (with observable behavior in mind) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[iostreams] Major interace changes planned -- comments requested
by Jonathan Turkanis 14 Mar '05

14 Mar '05

Hi All, Several important extensions of the Iostreams library have been on hold for over a month while I have tried to resolve the issue described in this message. Unfortunately it didn't get much attention during the review, so I'm hoping I can generate some discussion now. I'm sorry about the length of this message; I've been stuck on this for a long time and would really appreciate some help. I. The Problem --------------------------- Standard iostreams do not work well with non-blocking or asynchronous i/o. I would eventually like to extend the library to provide support for non-blocking and async i/o, and when I do so I expect I will have to introduce some new Device concepts. However, I would like to modify the *current* filter concepts so that they will work unchanged when non-blocking and asynchronous devices are introduced. There are several reasons for this: 1. Proper isolation of concepts. A filter represents a rule for transforming character sequences; ideally, how the sequence is accessed should not be relevant. For example, it would be silly to require separate versions of a toupper_filter for blocking and non-blocking i/o, since they would both represent the same simple rule. 2. Maximal code reuse. While it would just be silly to require several versions of a toupper_filter, it would be extremely wasteful to require several versions of more complex components like compression or encryption filters. 3. Reduced complexity of the library. The library already has a large number of concepts; I don't want to double or triple the number of filter concepts when non-blocking and async i/o is introduced. II. The Solution (the easy part) --------------------------- I believe it will suffice to: - provide the functions put() and write() (both filter member functions and the free functions with the same names) with a way to indicate that fewer than the requested number of characters have been written to the underlying data sink even though no error has occurred. - Provide the functions get() and read() (both filter member functions and the free functions with the same names) with a way to indicate that fewer than the requested number of characters have been read from the underlying data source, even though no error has occurred and EOF has not been reached. This is easily achieved for put() and write(), and almost as easily for read(): - Instead of returning void, put() can return a bool indicating whether the given character was successfully written. - Instead of returning void, write() can return an integer indicating the number of characters written. - Currently, when read returns fewer characters than the requested amount it is treated as an EOF indication. Instead, we can allow read to return the actual number of characters read, and reserve -1 to indicate EOF, since it is not needed as an error indication. III. The Solution (the ugly part) --------------------------- The function get presents more of a challenge. Currently it looks like this (for char_type == char): struct my_input_filter : input_filter { template<typename Source> int get(Source& src); }; The return type already serves a dual purpose: it can store a character or an EOF indication. Unfortunately, with non-blocking or async i/o there are now three possible results of a call to get: 1. A character is successfully retrieved. 2. The end of the stream has been reached. 3. No characters are currently available, but more may be available later. My preferred solution is to have get() return an instance of a specialization of a class template basic_character which can hold a character, an EOF indication or a temporary failure indication: template<typename Ch> class basic_character { public: basic_character(Ch c); operator Ch () const; bool good() const; bool eof() const; bool fail() const; }; typedef basic_character<char> character; typedef basic_character<wchar_t> wcharacter; character eof(); // returns an EOF indication character fail(); // returns a temporary failure indication. wcharater weof(); wcharater wfail(); [Omitted: templated versions of eof and fail] Alternatively, the member functions good, eof and fail could be made non-member functions taking a basic_character. IV. Examples (feel free to skip) --------------------------- With these changes, the uncommenting_input_filter (http://tinyurl.com/3ue9r) could be rewritten as follows: class uncommenting_input_filter : public input_filter { public: explicit uncommenting_input_filter(char comment_char = '#') : comment_char_(comment_char) { } template<typename Source> character get(Source& src) { character c = boost::io::get(src); if (c.good() && c == comment_char_) while (c.good() && c != '\n') c = boost::io::get(src); return c; } private: char comment_char_; }; Similarly, usenet_filter::get (http://tinyurl.com/6xqvk) could be rewritten: template<typename Source> int get(Source& src) { // Handle unfinished business. if (eof_) return EOF; if (off_ < current_word_.size()) return current_word_[off_++]; // Compute curent word. current_word_.clear(); while (true) { character c; if (!(c = boost::io::get(src)).good()) { if (c.eof()) eof_ = true; if (current_word_.empty()) return c; else break; } else if (isalpha((unsigned char) c)) { current_word_.push_back(c); } else { // Look up current word in dictionary. map_type::iterator it = dictionary_.find(current_word_); if (it != dictionary_.end()) current_word_ = it->second; current_word_.push_back(c); off_ = 0; break; } } return this->get(src); // Note: current_word_ is not empty. } V. Problems ---------------------------- 1. Harder to learn. Currently the function get and the concept InputFilter are very easy to explain. I'm afraid having to understand the basic_character template before learning these functions will discourage people from using the library. 2. Harder to use. Having to check for eof and fail make writing simple filters, like the above, slightly harder. I'm worried that the effect on more complex filters may be even worse. This applies not just to get, but to the other functions as well, since their returns values will require more careful examination. 3. Performance. It's possible that the change will have a negative effect on performance. I was planning to implement it and then perform careful measurements, but I have run out of time for this. I think the effect will be slight. VI. Benefits ------------------------ A positive side-effect of this change would be that I can rename the filter concepts InputFilter --> PullFilter OutputFilter --> PushFilter and allow both types of filter to be added either to input or to output streams. Filter writers could then choose the filter concept which best expressed the filtering algorithm without worrying whether it will be used for input or output. VII. Alternatives. 1. Adopt the convention that read() always blocks until at least one character is available, and that get() always blocks. This would give up much of the advantage of non-blocking and async i/o. 2. Add new non-blocking filter concepts, but hide them in the "advanced" section of the library. All the library-provided filters would be non-blocking, and users would be encouraged, but not required, to write non-blocking filters. If you've made it this far THANK YOU!!! Please let me know your opinion. Jonathan

6 49

[range] rationale for transform_range() algorithm?
by Eric Niebler 14 Mar '05

14 Mar '05

Background: I have been working on range-based algorithms and adaptors. The algorithms are variants of the std::algorithms that accept ranges instead of a [begin,end) iterator pair. The adaptors are like the iterator adaptors, except they adapt ranges. Following the principal of least surprise, I want to call my range adaptors filter_range, indirect_range, reverse_range and transform_range (to parallel filter_iterator, indirect_iterator, etc). But I can't do this, because there already is a transform_range, and it's a function! Problem: At the bottom of iterator_range.hpp is this: template< typename SeqT, typename Range, typename FuncT > inline SeqT transform_range( const Range& r, FuncT Func ) { SeqT Seq; std::transform( begin( r ), end( r ), std::back_inserter(Seq), Func ); return Seq; } I'm not sure why. It looks like a range-based algorithm, but ... why provide only one? (Two actually -- copy_range is there also.) And why call it transform_range() instead of just calling it "transform" and making it part of a complete range-based algorithm library? Solution: I suggest the functions copy_range() and transform_range() should be removed or moved into a "deprecated" namespace, freeing up the identifier "boost::transform_range" to be a type, analagous to boost::transform_iterator. Development should proceed on a range-based algorithms library to fill the need that the existing "transform_range()" function is meeting. Thoughts? -- Eric Niebler Boost Consulting www.boost-consulting.com

4 10

boost/pending/mutable_queue missing clear() function
by Lloyd J Lewins 14 Mar '05

14 Mar '05

I notice that mutable_queue is missing a clear() function, i.e. a low overhead way of emptying the entire queue (without resorting to repeated pops). However, I think clear() can be implemented as follows: void clear() { clear(); } Which is efficient and (often) fast. I don't think there is any need to "clear" the index_array (since the constructor for mutable_queue doesn't initialize its contents) Lloyd J. Lewins Fellow, Raytheon Co., llewins(a)raytheon.com +1 (310) 647-8832

3 3

bug fixes for boost::filesystem::exists on Win32
by Robert Mathews 14 Mar '05

14 Mar '05

Hi: I was trying to do something simple with the boost::filesystem library on Win32 && I noticed that it has trouble with UNC paths. I think I noticed 2 bugs with boost::filesystem::exists (possible patch attached). Finally, I also had a question about what consistutes a "part" of a path. Here's the context: I was trying to get all of the parts of a path, starting at the front and moving to the end in order to find out at which point a path was invalid. So, I wrote a path-checker that went something like this: using namespace std; namespace fs = boost::filesystem; void check_path(const string iPath) { fs::path::default_name_check(fs::native); fs::path aCurrentPath; for(fs::path::iterator aItr1=iPath.begin(); aItr1!=iPath.end(); aItr1++) { aCurrentPath /= *aItr1; bool aExists(fs::exists(aCurrentPath)); if(!aExists) { cout << "Hey, this was invalid path and it failed at aCurrentPath" << endl; return false; } } return true; } The function works fine if you give it paths like "D:/foo/bar", but a UNC path like \\computername\share\foo\bar doesn't work. The reason is that the path::iterator returns the following results for the beginning of the UNC path: "//computername" "/" "share" "/" "foo" ... etc and "//computername" is not a valid path. I've got a couple of questions about this: 1) Why is the separator "/" a separate part of the path? Shouldn't there be a way to only get the directory parts of the path w/o the separators? Just curious .. I couldn't find a reference to that in the discussion list. 2) boost::filesystem::exists("//computername") will return false, always. That seems like the wrong answer, given that the path::iterator has returned it as a part of the path. I notice that the filesystem code does otherwise understand UNC paths otherwise. 3) boost::filesystem::exists("//computername/nofreelunch") will return true, if even "nofreelunch" doesn't exist. Looking at the implementation of filesystem::exists in boost libs/filesystems/src/operations_posix_windows.cpp line 324, I'd like to propose the following changes to fix cases 2 & 3. To fix case 3 above, the error code return for an invalid share is not PATH_NOT_FOUND, but ERROR_BAD_NETPATH. That's a simple addition to the list of error codes to check. That should be uncontroversial. To fix case 2 above, one must notice that you have a UNC path with 1 element - ie, a computer name. At the point you can either follow the hint in the code and simply return true, or you can call a different WIN32 function to see if the server exists. Attached is a proposed patch for both issues. Thanks. begin 666 operations_posix_windows.cpp.patch M26YD97@Z(&]P97)A=&EO;G-?<&]S:7A?=VEN9&]W<RYC<' -"CT]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T-"BTM+2!O<&5R871I;VYS7W!O<VEX7W=I;F1O=W,N M8W!P"2AR979I<VEO;B R-3(W,2D-"BLK*R!O<&5R871I;VYS7W!O<VEX7W=I M;F1O=W,N8W!P"2AW;W)K:6YG(&-O<'DI#0I 0" M,S(Q+#$P("LS,C$L,S@@ M0$ -"B @(" @("!]#0H@(" @(" @<F5T=7)N('1R=64[#0H@(R @(&5L<V4- M"BT@(" @("!I9B(a)Z.D=E=$9I;&5!='1R:6)U=&5S02@@<&@N<W1R:6YG*"DN M8U]S='(H*2 I(#T](#!X1D9&1D9&1D8I#0HK"2 @<W1R:6YG(&%0871H*'!H M+G-T<FEN9R@I*3L-"BL)("!B;V]L(&ES54Y#4&%T:"AA4&%T:"YS:7IE*"D@ M/B S("8F(&%0871H+G-U8G-T<B@P+#(I(#T]("(O+R(I.R O+R T/4QA<F=E M(&5N;W5G:"!P871H('1O(&AA=F4@82!L96%D:6YG("\O(&%N9"!A="!L96%S M=" Q(&UO<F4@8VAA<F%C=&5R#0HK"2 @<W1R:6YG.CIS:7IE7W1Y<&4@84YE M>'13;&%S:"AA4&%T:"YF:6YD7V9I<G-T7V]F*"(O(BPR*2D[#0HK"2 @8F]O M;"!I<T]N;'E#;VUP=71E<DYA;64H:7-53D-0871H("8F"0D)"0D)+R\@;6%K M92!S=7)E('1H:7,@82!53D,@<&%T:"!O9B!S;VUE('1Y<&4N#0HK"0D)"0D) M"2 @*&%.97AT4VQA<V@@/3T@<W1R:6YG.CIN<&]S('Q\"2\O(&QO;VL@9F]R M("\O8V]M<'5T97)N86UE#0HK"0D)"0D)"2 @("AA3F5X=%-L87-H(#T]("AA M4&%T:"YS:7IE*"D@+2 Q*2 F)B!A4&%T:"YS:7IE*"D@/B S("\O(&%L;&]W M("\O8V]M<'5T97)N86UE+R!A;F0@9F5N8V4@;V9F("<O+R\G(&EN<'5T( T* M*PD)"0D)"0D@(" I*2D[#0HK"2 @:68H:7-/;FQY0V]M<'5T97).86UE*0T* M*R-I9F1E9B!F86YC>5]C:&5C:VEN9PT**PD)(" O+R!)(&1O;B=T(&MN;W<@ M:68@>6]U('=A;G0@=&\@9V\@=&AI<R!F87(@;W(@;F]T/PT**PD)(" O+R!9 M;W4G;&P@:&%V92!T;R C:6YC;'5D92 \;&TN:#X@86YD(&QI;FL@86=A:6YS M="!.971A<&DS,BYL:6(@)B8@=&AE;B!W;W)R>2!A8F]U="!A;&P@=F%R:6]U M<R!V97)S:6]N<R!O9B!W:6YD;W=S("XN( T**PD@('L-"BL)"2 @3%!315)6 M15)?24Y&3U\Q,# @85-E<G9E<DEN9F\H3E5,3"D[#0HK"0D@($Y%5%]!4$E? M4U1!5%53(&%3=&%T=7,H3F5T4V5R=F5R1V5T26YF;T$H#0HK"0D)"0D)"0D) M"2 @<&@N<W1R:6YG*"DL#0HK"0D)"0D)"0D)"2 @,3 P+ T**PD)"0D)"0D) M"0D@("A,4$)95$4J*2 F85-E<G9E<DEN9F\-"BL)"0D)"0D)"0D)("D[#0HK M"0D@(&EF*&%397)V97));F9O*0T**PD)"2 @3F5T07!I0G5F9F5R1G)E92AA M4V5R=F5R26YF;RD[#0HK"0D@(')E='5R;B!A4W1A='5S(#T]($Y%4E)?4W5C M8V5S<SL-"BL)("!]#0HK(V5L<V4-"BL)(" O+R!!="!L96%S="P@:68@>6]U M(')E8V]G;FEZ92!T:&%T('1H:7,@82!C;VUP=71E<B!N86UE+"!Y;W4@8V]U M;&0@9&\@=V]R<V4@=&AA;B!T;R!A<W-U;64@:70@;6EG:'0@97AI<W0N#0HK M"2 @<F5T=7)N('1R=64["0D)#0HK(V5N9&EF"2 @#0HK"2 @96QS92!I9B@Z M.D=E=$9I;&5!='1R:6)U=&5S02@@<&@N<W1R:6YG*"DN8U]S='(H*2 I(#T] M(#!X1D9&1D9&1D8I#0H@(" @(" @>PT*(" @(" @(" @(%5)3E0@97)R(#T@ M.CI'971,87-T17)R;W(H*3L-"BT@(" @(" @("!I9B@H97)R(#T]($524D]2 M7T9)3$5?3D]47T9/54Y$*2!\?" H97)R(#T]($524D]27TE.5D%,241?4$%2 M04U%5$52*2!\?" H97)R(#T]($524D]27U!!5$A?3D]47T9/54Y$*2!\?" H M97)R(#T]($524D]27TE.5D%,241?3D%-12DI#0HK(" @(" @(" @:68H*&5R M<B ]/2!%4E)/4E]&24Q%7TY/5%]&3U5.1"D@?'P@*&5R<B ]/2!%4E)/4E]) M3E9!3$E$7U!!4D%-151%4BD@?'P@*&5R<B ]/2!%4E)/4E]0051(7TY/5%]& M3U5.1"D@?'P@*&5R<B ]/2!%4E)/4E])3E9!3$E$7TY!344I#0HK"0D)*&5R M<B ]/2!%4E)/4E]"041?3D544$%42"D-"BL)"2 @("D-"B @(" @(" @(" @ M("!R971U<FX@9F%L<V4[("\O($=E=$9I;&5!='1R:6)U=&5S(&9A:6QE9"!B M96-A=7-E('1H92!P871H(&1O97,@;F]T(&5X:7-T#0H@(" @(" @(" @+R\@ M9F]R(&%N>2!O=&AE<B!E<G)O<B!W92!A<W-U;64@=&AE(&9I;&4@9&]E<R!E M>&ES="!A;F0@9F%L;"!T:')O=6=H+ T*(" @(" @(" @("\O('1H:7,@;6%Y M(&YO="!B92!T:&4@8F5S="!P;VQI8WD@=&AO=6=H+BXN(" H2DT@,C P-# S %,S I#0H` ` end

1 0

[serialization] BOOST_CLASS_EXPORT regression?
by Vladimir Prus 14 Mar '05

14 Mar '05

Hello, I've have a header file like this: namespace lvk { namespace nm_model { namespace runtime { class IntTraceItem {}; }}} BOOST_CLASS_EXPORT(lvk::nm_model::runtime::IntTraceItem); The header is included in two files. It used to work before, but I've just updated to CVS state of the serialization lib, and get: src/runtime/bin/gcc/debug/threading-multi/TraceArbiter.o(.bss+0x0):src/runtime/TraceArbiter.cpp:16: multiple definition of `boost::archive::detail::guid_initializer<lvk::nm_model::runtime::IntTraceItem>::instance' src/runtime/bin/gcc/debug/threading-multi/Trace.o(.bss+0x0):src/runtime/Trace.cpp:21: first defined here I attach the testcase. When I run g++ -I ~/Work/boost-rc s1.cpp s2.cpp the first error is about duplicate symbols. Am I doing something wrong or is this a regression? - Volodya

3 5

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

14 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 see I have missed the deadline. Oh, well. Several queries have been raised during the review, some of which have merit. Firstly, I think we have some agreement that the signature: size_t hash_range( It first, It last ); is wrong and there should be some way to provide an initial seed. I am not yet decided on what the best signature should be; I am tempted towards a 3rd argument with a default value, but I can also see some merit in mimicking hash_combine() by making the seed the first argument. Secondly, the proposed implementation for hashing pointers produces undefined behaviour because it subtracts pointers not in the same array. We have some agreement that using reinterpret_cast would be better. Thirdly, I think there is also a legitimate query over whether the default hash_range should provide better quality hashes for arrays of bytes, eg along the lines discussed in: http://www.azillionmonkeys.com/qed/hash.html With boost interface is more important than implementation, but apparently implementations of the hash library will not be allowed to vary. My impression is that the proposed implementation of hash_combine: seed ^= hash_value(v) + (seed << 6) + (seed >> 2); was designed to combine 8-bit character values; do we have any evidence it also performs well to combine 32-bit values? Perhaps hash_value(v) would be better treated as an array of 4 bytes? Fourthly, there seems to be a design philosophy behind the current proposal which is not stated explicitly in the documentation. It apparently favours some notion of safety over speed and hash quality, where "safety" means that different objects should have the same hash values if they look at all alike to someone possibly. For example, the proposal has no specialisation for chars at all. I can't tell if that is an oversight, or whether it is a design aim that: char chars[] = { 1, 2, 3, 4 }; int ints[] = { 1, 2, 3, 4 }; assert( hash_range( chars, chars+4 ) == hash_range( ints, ints+4 ) ); I gather it is a design aim that hash_value( pair<int,int> ) match hash_range( int[2] ). Presumably if hash_range takes a seed argument, this means hash_value must too, else how can it match it? I am not sure about all this philosophy. I had kinda hoped that a boost hashing library would offer good quality industrial-strength hashing; that it would save me having to do my own research. Regardless, I think the aims and guarantees of the proposed library should be documented more explicitly. In conclusion, I feel that if we given only 5 days to review a proposal, that proposal needs to be spot on, uncontroversial, with all issues nailed accurately in advance. I don't think that is the case here. Although I think all the problems could be resolved, I don't think we have enough time to do that in the given review period. If I have to decide now, I'd say: This should not be accepted as a Boost library. Stock questions: I have not tried to compile the code. I have looked at the documentation, the source, and followed some of the references. I have raised design questions here and followed the discussion. Total time is a few hours. I am not an expert on hashing, but I have implemented my own hashing library. I have encountered practical problems due to different objects having the same hash values. -- Dave Harris, Nottingham, UK

6 14

[aligned_storage][repost] problems with GCC 4.0.0 20050309
by JOAQUIN LOPEZ MU?Z 14 Mar '05

14 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 which is ruining some of the regression tests. 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

5 4

Boost Graph - internal datastructures of graph
by Peter Billen 14 Mar '05

14 Mar '05

Hello all, I was wondering what internal datastructures are used in the different graph concepts (Graph, IncidenceGraph, etc.), to achieve efficient implementations of these different concepts. Is this documented somewhere? I couldn't find anything about the implementations on the website. Is this discussed in the book? I am aware I can browse through the code, but I thought it might be a good idea to ask it first here. Thanks for your replies, -- Peter

2 1

[Boost-bugs] [ boost-Bugs-1163091 ] push_relabel_max_flow may be broken
by SourceForge.net 14 Mar '05

14 Mar '05

Bugs item #1163091, was opened at 2005-03-14 11:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1163091&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: push_relabel_max_flow may be broken Initial Comment: The push_relabel_max_flow algorithm seems to be dereferencing past-the-end iterators. The initial bug report is here: http://lists.boost.org/MailArchives/boost-users/msg10032.php Doug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1163091&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

[Boost-bugs] [ boost-Bugs-1163077 ] EdgeListS = setS for adjacency_list does not work
by SourceForge.net 14 Mar '05

14 Mar '05

Bugs item #1163077, was opened at 2005-03-14 10:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1163077&group_… Category: graph Group: None Status: Open Resolution: None Priority: 4 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: EdgeListS = setS for adjacency_list does not work Initial Comment: The adjacency_list class template requires the EdgeListS selector to indicate a Sequence container (and may very well require the default listS). setS, for instance, does not work. See http://lists.boost.org/MailArchives/boost-users/msg09557.php ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1163077&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

[wiki] New content filtering to reduce spam
by Jeff Garland 14 Mar '05

14 Mar '05

All - I've instituted a new content filter on the Wiki to try and cut off the spamming without going to a login or other user intrusive mechanism. The timing of this feature turned out to be important as a sophisticated spambot that evades the ip banning strategy by using many different ip addresses (presumably using zombie machines) has been attempting to SPAM the wiki all day today. The new content filter has sucessfully stopped this bot. Note that if a spammer is successful I am now reverting all spam content from the Wiki history so that there is no change of googlebot finding it. For the moment, I'm not going to publish the regular expressions I'm using to filter, but suffice to say, normal boost content should be unaffected. If you get an error indicating content has been blocked due to spam, send me and email. Thanks, Jeff

2 1

Hash function review
by John Maddock 14 Mar '05

14 Mar '05

A little late in day, here we go: >What is your evaluation of the design? The design is basically fixed by the TR, so there's not much to review here. The extensions to the TR proposed by Peter Dimov, and implemented here look fine to me as well. >What is your evaluation of the implementation? Modulo the suggestions to the pointer hashing, it looks very good: I spent some time examining the floating point implementation, along with the associated test cases, and everything that could be tested looks like it is. I agree with those opinions expressed here that it's better to have a reliable implementation, that produces good hash values, than an artificially fast version that produces bad hash values. I have one query regarding hashing of integer types, regarding hashing of long long, Daniel says: "Also, it will need a different hash function to the other integer type as the current one won't take account of the higher bits. I want to take my time over things like this and get it right." But I think this is a (mostly theoretical) issue already: type long may have more bits than size_t does. I don't think this is a big issue though, it should effect very few platforms, and shouldn't hold up acceptance of the library. >What is your evaluation of the documentation? Also looks very good, I would like to see some more description of how the implementation differs from the TR (all the bits are there in the docs, it's just not clear which are part of the TR, and which are the extensions). >What is your evaluation of the potential usefulness of the library? Can't believe we haven't had this in Boost already. It's about time. >Did you try to use the library? With what compiler? Did you have any >problems? I've spent some time examining and running the test cases, everything that should pass does so with: gcc-3.3.2 Intel 7, 8.1 and 9Beta VC++ 6, 7, 7.1 and 8Beta. The tests are failing with Borland, due to a problem with Boost.Test. >How much effort did you put into your evaluation? A glance? A quick >reading? In-depth study? A couple of hours reading the code and the docs. >Are you knowledgeable about the problem domain? I don't claim to be any kind of expert in hashing. >Do you think the library should be accepted as a Boost library? Yes, please ;-) John.

1 0

[test] still regressions with IsDebuggerPresent()
by Stefan Slapeta 14 Mar '05

14 Mar '05

There are still regressions caused by a missing definition of IsDebuggerPresent(). These failures have been introduced by the recent changes in boost.test. What is to do here? see http://tinyurl.com/6vdo9 Cheers, Stefan

2 1

Sockets: proposal for a library design
by Boris 14 Mar '05

14 Mar '05

I updated the Wiki pages for a net library at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet. After collecting all the information I found at the Wiki pages for the socket and multiplexing library I try to explain how a net library should basically look like. The proposal includes various I/O models and is based on I/O streams. As usual any comments are appreciated, Boris

6 10

[serialization] current CVS not working for CW
by Joaquín Mª López Muñoz 14 Mar '05

14 Mar '05

Hello, None of the CW compilers being tested seems able to build the serialization lib against the current CVS. I seem to recall there were no problems of this kind a month ago or so. I know the author's probably aware of this, just wanted to know about the status of this problem. Thank you, Joaquín M López Muñoz Telefónica, Investigacion y Desarrollo

4 4

RE : FSM Review : Performance Issues
by jdspalding＠comcast.net 14 Mar '05

14 Mar '05

******************************************************************************* BOOST Re: FSM Review : Performance Issues. I'd like to add some overall comments about the FSM's perceived performance issues. To clarify my bias, previous comments, I have already submitted a positive review, focusing on usage issues. Context: On Sat, 12 Mar 2005 , Dave Garland wrote >On Sat, 12 Mar 2005 15:57:10 -0500, David Abrahams wrote >> >> Haven't a few people been reporting that they won't even begin to >> apply this one because of particular limitations? Anyone who needs >> higher performance won't even get started. >Sure, and on the other hand we've had at least one testimonial that this was >the best fsm library they found -- served them well in a project. I've heard >the same sort of argument from people comparing std::string to a char*. >std::string: Discussion : I believe the discussion of performance in the proposed boost FSM library is going in an unrewarding direction. Undefined design possibilities are being weighed against a working system. (notice : I am going to be sympathetic to the "working system".) On the "design possibilties" side there seem to be a number of major issues. - double dispatch is O(n), we'd like O(1). - overall performance is slow, state transitions in XXX nSec are too slow for a proposed application. - some people have the idea that the techniques used to allow FSM to extend over multiple translation units could be improved. Again and again someone writes in and says the design does not feel right, if we did XXX, FSM is likely to be able to fix YYY. However, the concrete solution is not yet conceived, and for now, a general plausability argument will have to do... Proposal: I think we could adopt a structured approach to evaluate these competing claims. A) One viewpoint of the FSM library is through the filter of application performance tradeoffs. IMHO we have exhausted the qualitative approach, and need the definiteness of the quantitative. I would think the FSM critics have the obligation here to provide support to their view, that FSM performace is inadequate. A.1) It is said that performance considerations will keep FSM from being considered for some applications. => Then could we specifically, and quantitatively define a class of applications for which FSM, as it exists today, would be inadequate? (model app) - in the timed performance area, what are the model app's FSM performace metrics, such as number of states, use of orthogonal states, depth of state nesting, number of events fired per second, number of events handled per second? - what are the model app's non FSM performance metrics, perhaps normalized to FSM metrics, such as lines of code or execution time, per state change, or per event fired? - please also include some details about the context for the app's execution, usage area, etc., to assist the readers from other experience domains. A.2) It is said that O(n) double dispatch is inadequate, that better design is required for acceptance. => To really assert this we really have to have a complete model of FSM's runtime behavior. Since this is different in different usage scenarios, what we really need are several usage scenarios, and an analysis/measurement of where FSM spends its time. I think Andreas has mentioned that he thinks other areas than double dispatch are more important. IMHO this is a quantitative issue, per usage scenario. B) A second viewpoint of the FSM library is that of usage requirements in the application's code. Here there are at least two areas of contention - B.1) The implications of the requirement for compilation in multiple translation units. - B.2) The overal ease of use of the FSM library's API. Finally, here is my submission of data for a model usage of FSM, in the above framework. ****************************************************** Quantitative data : example : from J. Spalding's use of FSM area : industrial control. A.1) Performance metric Number of states : 15-20. maximum state nesting depth : 5. use of orthogonal states : no. maximum number of events per second (burst) : 10. events handled per second (burst) : 10. context : Use of FSM in a machine control application. FSM controls application's execution "mode", and the hardware error monitoring state. remarks : model app not stressing FSM performance. A.2) Runtime behavior profile not carried out. FSM performance trivial component of model application. B.1) Multiple translation units. model application code was broken across multiple translation units, no particular problems occurred. B.2) API Ease of Use. API was expressive, easy to configure to solve the problem. The only difficulties encountered were found in tracing compile time initial useage mistakes. This is also a strength of the approach, incorrectly configured FSM machines will not compile. *********************************************************** My Opinion : per FSM acceptance into Boost: - I like the FSM API, think performance today is adequate for many/most applications, think UML connection is a plus, voted for FSM acceptance. - Seeing statements such as 100 nSec cost per event handled prevents serious use of FSM, does offend me, without a supporting application performance model/context. IMHO Andreas has requsted such info many times, and has not been rewarded with any quantitative data. - IMHO, If we were evaluating FSM for an engineering use today, it would be accepted, due to good API, good documentation. The only way FSM could fail is if FSM code grabbed > (XX) % of the app's compute cycles, or made an unacceptable latency hit. The alternatives, at least in the boost discussion of it, are all proposed concepts requiring evaluation & development. - Further it would be quick work to use FSM to prototype a proposed use, and numerically evalute its time/space/latency cost. Just write the proposed FSM on the target machine, install it with a test harness that puts out events at the required rate, and you have a use/not use decision with hard data. If FSM were included in Boost, then this evaluation might be accomplished a number of times in the future, and the fsm interest group may acquire data justifying a performace oriented new implementation/library. ***********************************************************

1 0

Re: Sockets: proposal for a library design
by Don G 13 Mar '05

13 Mar '05

Hi Boris, Thanks for all the effort and getting something posted! On first blush, my thoughts are as follows: I would suggest that a proposed Boost.Net library should focus on networking in a more abstract manner, and not be merely a socket encapsulation. IMHO, sockets are a terrible API and should be hidden as fast as possible. A socket wrapper class is appropriate, but I would not go to any trouble to change the socket API. Simply wrap the resources and provide portable access to the underlying system. The real end-user part of the Net library should not talk about sockets (unless one provides a method like get_native to return the socket handle, and that method is defined as non-portable). I think all desired I/O models should be available at run-time (see below). In my own work in this area I have seen that this approach does not greatly effect the implementation. In other words, there is virtually nothing to be gained by making async I/O optional at compile-time. As others have also suggested, I would agree that the net facilities not be tied up into I/O streams. It would be better to provide the network facilities and then layer on I/O streams for those that want it. There are really only a few abstract entities to worry about: Url, Address, Stream, Datagram, Acceptor. In my work (not related to Boost), I've also created a Network class to serve as the abstract factory and contain a thread pool for doing the async I/O. I believe your diagrams use "Client" and "Server". I think these terms are a bit too generic. I prefer the term "Acceptor". Usage examples: shared_ptr<Network> net (new SomeSpecificNetwork(some_arguments)); Url some_url = "http://www.boost.org"; shared_ptr<Address> addr = net->new_address(some_url); shared_ptr<Stream> str = addr->new_stream(); str->connect(); // now it's connected (blocking) shared_ptr<Address> localhost = net->new_local_address("ntp://"); shared_ptr<Datagram> dg = localhost->new_datagram(); // on the ntp port localhost = net->new_local_address("ftp://"); shared_ptr<Acceptor> ac = localhost->new_acceptor(); // "ftp" port str = ac->accept(); // blocking accept I've omitted any nonblocking/async methods for brevity. IMHO, blocking, nonblocking and free-threaded-async-w/callback are the only models worth providing. These models can be ported anywhere and can be implemented via whatever mechanism is best for the given platform. A select() based version can be made to work just about anywhere with minimal #ifdef logic, but may be less than ideal when the system supports poll() or NT I/O completion ports. One thing I think is essential when using a blocking model is cancellation. For example, I have a reset() method on Acceptor, Address, Datagram and Stream that can be called at any time to cause blocking methods to terminate with a cancel exception (obviously this must be from another thread). Ironically, these reset() methods meant I could not use blocking socket calls to implement my blocking methods - recv() cannot be canceled once it blocks (at least not portably)! The big issue in nonblocking I/O is how to notify the application that things have changed and now would be a good time to try more I/O. I like the free-threaded callback for this as it fits closely with async I/O and that way the nature of the I/O mechanism can still be encapsulated. Throughout the above I use the term "free threaded callback". By that I mean that the user supplied callback will be invoked directly by a worker thread. The reason for this is that it is the only way to approach the efficiency of a hand-rolled select/poll loop. When select() returns, the fd_set would be examined and steps taken to prepare for the next call to select(). Since multiple operations could complete, whatever state machines exist are pumped inside a processing loop between select() calls. When the abstraction comes in and hides the loop behind callbacks, if the callbacks are made directly, we add only the overhead of making the callbacks. If, on the other hand, all callbacks where marshalled out, the loop would not have the information needed to formulate the next call to select() and would likely have to be interrupted repeatedly to get to the proper state. The dangers of this approach should be obvious (deadlock to say the least). The user code is now forced to understand the execution model in order to properly code a callback. What I found is that a short list of allowed operations is sufficient. Any async I/O methods are OK, as are nonblocking methods, etc.. After that (long winded) explanation, what I have also seen is that very few applications need the performance that free-threaded callbacks provide and would opt out of the complexity if they could. My solution to this was an auto-marshalling callback. I'm not sure what facilities Boost provides for queued function<> calls, but the idea is to provide a callback that queues a callback. The pseudo code for me was something like this: str->async_read(buf, n, channel.bind_async_call(this, &This::foo)); The "channel" was my entity that could enqueue calls. The "(this, &This::foo)" would actually be a function<> object or something. The return from bind_async_call() is a function<> object that performs the actual call to channel.async_call() passing the user callback. Whew! Slightly more than $0.02, I know. :) Best, Don --- Boris <boris(a)gtemail.net> wrote: > I updated the Wiki pages for a net library at > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet. > > After collecting all the information I found at the Wiki pages for > the socket and multiplexing library I try to explain how a net > library should basically look like. The proposal includes various > I/O models and is based on I/O streams. > > As usual any comments are appreciated, > Boris __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

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

13 Mar '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Marzo 13, 2005 0:52 am Asunto: [boost] Re: [review] hash functions > Alberto Barbati <abarbati(a)iaanus.com> writes: > > > Ah! And there's one more case in which we are helpless, although > I'm > > curious to see an implementation that exploits such latitude: > the > > wording used in the standard does not guarantee that the mapping > from > > pointers to integers always produce the same value over time. In > other > > words: > > > > char* p = new char; > > size_t i1 = reinterpret_cast<size_t>(p); > > size_t i2 = reinterpret_cast<size_t>(p); > > assert(i1 == i2); // ??? > > char* q1 = reinterpret_cast<char*>(i1); > > char* q2 = reinterpret_cast<char*>(i2); > > assert(p == q1 && q1 == q2); > > > > The standard guarantees that the second assert passes, but says > nothing > > about the first assert. > > There are other cases too. reinterpret_cast could map all > pointers to > the same integer. If you allow me to be a little pedantic, this is not the case. reinterpret_cast<> guarantees back conversion, so it can't possibly map every pointer into the same integer. As for the rest of your argument, I agree 100%. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

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

13 Mar '05

In-Reply-To: <007e01c52597$b62c1980$6601a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > pair<int, int>, int[2], struct { int a; int b; } are different > representations of the same thing; it is not strictly necessary for > them to use the same algorithm, but it's desirable and will eliminate a > source of confusion and mistakes. Really? What kind of mistakes? In my experience, if you want two different things to hash the same, you need to write their hash functions with that in mind. It is a special case which justifies not using the default hash function. > void hash_range( size_t & seed, It first, It last ); > > should this function be added. You are welcome to spell the above as > > size_t hash_range( size_t seed, It first, It last ); I am also tempted by: size_t hash_range( It first, It last, size_t seed=0 ); perhaps replacing the 0 with some other default value. So people can ignore it if they don't need it. But doesn't this mean that hash_value( pair<int,int> ) also needs a seed argument, if you want it to match hash_range( int[2] ) ? -- Dave Harris, Nottingham, UK

2 2

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

13 Mar '05

In-Reply-To: <d0vsa6$bkm$1(a)sea.gmane.org> abarbati(a)iaanus.com (Alberto Barbati) wrote (abridged): > 2) provide the hash function (with reintepret_cast<>) only for those > platforms that we are able to check in advance that will satisfy those > requirements and make any use of such function produce a static assert > for all other platforms In the case of (2), the platform may provide another implementation which can be used. For example, perhaps the pointers are segment+offset and the offset part is suitable. In my view, boost should be allowed to vary the implementation of the hash functions to suit the local platform. One interesting case is compacting garbage collectors. These already have problems with std::less() and I'd rather not make things worse by over-specifying hashing. -- Dave Harris, Nottingham, UK

1 0

Re: [boost] [aligned_storage][repost] problems with GCC 4.0.0 20050309
by JOAQUIN LOPEZ MU?Z 13 Mar '05

13 Mar '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Domingo, Marzo 13, 2005 2:18 pm Asunto: Re: [boost] [aligned_storage][repost] problems with GCC 4.0.0 20050309 > JOAQUIN LOPEZ MU?Z wrote: > > 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 > > > > which is ruining some of the regression tests. > > Is GCC right or shall I submit a bug report at gcc.gnu.org/bugzilla? > > I don't see anything in the standard or in the issue lists that > prohibits > size_t(-1) as an integral constant expression. Bug report. > Alas, I tried to isolate this into a simple snippet #include <cstddef> template < std::size_t size_ , std::size_t alignment_ = std::size_t(-1)> class aligned_storage { }; int main() { aligned_storage<1> as; } but then the problem goes away. Would some kind soul with access to GCC 4.0.0 care to take a look at this? The actual problem is shown at: http://tinyurl.com/4hxy5 Thank you very much, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

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

13 Mar '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Marzo 13, 2005 4:52 am Asunto: [boost] Re: [review] hash functions > JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> writes: > > > ----- Mensaje original ----- > > De: David Abrahams <dave(a)boost-consulting.com> > > Fecha: Domingo, Marzo 13, 2005 0:52 am > > Asunto: [boost] Re: [review] hash functions > > > >> Alberto Barbati <abarbati(a)iaanus.com> writes: > >> > >> > Ah! And there's one more case in which we are helpless, > although > >> I'm > >> > curious to see an implementation that exploits such latitude: > >> the > >> > wording used in the standard does not guarantee that the > mapping > >> from > >> > pointers to integers always produce the same value over time. > In > >> other > >> > words: > >> > > >> > char* p = new char; > >> > size_t i1 = reinterpret_cast<size_t>(p); > >> > size_t i2 = reinterpret_cast<size_t>(p); > >> > assert(i1 == i2); // ??? > >> > char* q1 = reinterpret_cast<char*>(i1); > >> > char* q2 = reinterpret_cast<char*>(i2); > >> > assert(p == q1 && q1 == q2); > >> > > >> > The standard guarantees that the second assert passes, but > says > >> nothing > >> > about the first assert. > >> > >> There are other cases too. reinterpret_cast could map all > >> pointers to > >> the same integer. > > > > If you allow me to be a little pedantic, this is not the > > case. reinterpret_cast<> guarantees back conversion, so it can't > > possibly map every pointer into the same integer. > > 4 A pointer can be explicitly converted to any integral type large > enough to hold it. The mapping function is implementation-defined > [Note: it is intended to be unsurprising to those who know the > addressing structure of the underlying machine. ] > > 5 A value of integral type or enumeration type can be explicitly > converted to a pointer. 64) A pointer converted to an integer of > sufficient size (if any such exists on the implementation) and back > to the same pointer type will have its original value; mappings > between pointers and integers are otherwise implementation-defined. > > There's no guarantee that the integer type will have sufficient size. OK, with that provision in mind I buy your thesis now. > > > As for the rest of your argument, I agree 100%. > > Now you agree with all of it ;-) > (I hope) > Definitely! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[review] hash functions
by Thorsten Ottosen 13 Mar '05

13 Mar '05

Dear All, 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. The library is fairly small and can be seen as an extension to boost.functional. Therefore the review is a fast-track review. >From the introduction of the library: "boost::hash is an implementation of the hash function object specified by the C++ Standard Library Technical Report. It is being proposed as an addition to Boost.Functional" "The hash functions have several possible uses, but the main intention of boost::hash is for indexing a hash table such as the unordered associate containers in the Technical Report, or the hash index for the Boost Multi-Index Containers Library. A hash table stores its values in buckets which are numbered by their keys' hash values. Given a key, the bucket the object lies in can be quickly found be calculating its hash value and looking in the corresponding bucket. This requires the hash function to be fast - since the point is to find the object quickly. Collisions need to be minimised, to reduce the number o objects in each bucket, and thus the number of comparisons required to find objects in a bucket." . If you decide to do a review, please follow the guidelines described in http://www.boost.org/more/formal_review_process.htm#Comments The library can be downloaded from http://boost-sandbox.sourceforge.net/vault/index.php?directory=Hash best regards Thorsten, review manager -- Thorsten Ottosen ---------------------------- www.dezide.com www.cs.aau.dk/index2.php?content=Research/bss www.boost.org www.open-std.org/JTC1/SC22/WG21/

12 48

Re: [boost] Re: FSM Review
by 辉李 13 Mar '05

13 Mar '05

Hi all, I'm a new guy in boost list. --- Alexander Nasonov <alnsn(a)yandex.ru> wrote: > Because classical approach to implement POAManager > and the like > is not overly complex and because no special skills > are needed, > new library should have several advantages (to give > answers to problems > 1-3, at least) and it should have very clear and > easily understandable > model. > Tutorial of this library should describe how to > solve typical problems > of classical approach. > Support Alexander's opinion., I have seen the tutorial of FSM library, I think the tutorial is too UML-style. As I know FSM has been used widely before UML become popular. Some classical usage of FSM have simple state transfer and action style, but has many states. The tutorial should give some examples in the classical style, or we should call this library boost::FSM::UML-style. The performance of FSM is very important for some application with simple usage of FSM. When using a FSM lib, the user of this kind of FSM should not pay the loss in performance for the functions they don't need. If the trade between performance and functionality can not satisfy some FSM users in this design, maybe the boost can accept this library but should provide an opportunity for accept other design of FSM with high performance but some simple functionality. regards William Lee _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

1 0

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

offline code generator for BIL
by christopher diggins 09 Mar '05

09 Mar '05

I just wanted to put forth that I really could use an offline code generator for my work on the OOTL. I only want a handful of interfaces for the library which won't change often. The benefits for me are: a) I won't have extra boost dependencies for meta-programming b) have the fastest possible compile times for my library Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

3 5

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

09 Mar '05

In-Reply-To: <422EFC7F.9D48D181(a)tid.es> joaquin(a)tid.es (=?iso-8859-1?Q?Joaqu=EDn=20M=AA=20L=F3pez=20Mu=F1oz?=) wrote (abridged): > Oh, sorry, I misread it. I agree with you hashing a bool makes little > sense, and agree that it probably shouldn't be made part of the public > interface (for the same reasons, for instance, that there's no overload > for char.) Is that because bools and chars will be promoted to ints? I can imagine wanting bools and chars to hash differently, to take advantage of their special properties. Then hash_value('\0') could be different to hash_value(0), which wouldn't bother me because they are different types. However I can understand if this is felt too risky for general use. -- Dave Harris, Nottingham, UK

1 0

Re: [review] hash functions
by Jaap Suter 09 Mar '05

09 Mar '05

I would like to second the following: "1. The overloads of hash_value for STL containers forces the implementation to include <vector>, <list>, etc., which makes the header a little heavier than desired." I'd say it's not a 'little' heavier but a lot heavier. Can we not put the extensions in their own header files; vector_hash.hpp or something? Not everybody has all these containers in a precompiled header already. Thanks, Jaap Suter

3 2

Logo Contest Current Tally
by Joel de Guzman 09 Mar '05

09 Mar '05

Hi, You can see the latest logo contest tally here: http://boost.org/more/logo_contest_tally.htm As of March 7, 2005: Votes Entry 6 38, Simeon Nasilowski 5 67, Simeon Nasilowski 4 39, Simeon Nasilowski 4 75, Zoltan "cad" Juhasz 3 83, Emil Kirichev 3 85, Ben Hetland 3 92, Aleksey Gurtovoy 2 18, Boost 2 Jonathan Turkanis 2 52, Zoltan "cad" Juhasz 2 60, Banu Alexandru 2 68, Aleksey Gurtovoy 1 1, Boost 1 13, René Rivera 1 20, Jonathan Turkanis 1 23, Jonathan Turkanis 1 29, Erik Wien 1 3, Joaquín M López Muñoz 1 30, Erik Wien 1 62, Mike H 1 97, Jonathan Turkanis 1 18, Jonathan Turkanis Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

15 39

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

09 Mar '05

On Thu, 2005-03-03 at 22:28 +0000, Jarl Lindrud wrote: > Iain Hanson <Iain.Hanson <at> videonetworks.com> writes: > > [snip] > You're making my point for me. For something quick and dirty, who is going to > want to type all that out? And before I do, I have to learn about IDL, _var > types, safe downcasts, factories, CORBA::string's, etc, while in the back of my > mind there's the nagging suspicion that I've missed some subtle detail > somewhere. I hardly find 5 lines of code onerous. And it is easy to wrap up part of it in a template. Quick and dirty may be something you do to learn how to do something. But AFAIK, not something we create boost libraries for. IDL is what gives you type safety, something we usually appreciate in C++. > And whoever will be looking at my code needs to learn these things as > well. This is something that never fails to amaze me. Building distributed systems is hard to do correctly. It is very similar to the difficulty with threaded systems but the issues are subtly different and I think harder in distributed systems. If you can't learn a few conventions in half a day, then you probably have no business trying to build such systems. I probably spend half of my working life fixing systems that have been quickly hacked and then put into production. CORBA /EJB both have marketed themselves as the easy and safe way to write distributed systems and they are not. They are easy to write bad systems in. What you are proposing is an easier way to write even worse systems. > I also have to modify the build process to handle the IDL files, and then > find an ORB to build and link to. None of this is difficult, but I personally > find it rather cumbersome, and above all, for my situation it's just plain > unnecessary. All I wanted to do was to make a couple of remote calls between two > C++ programs! Something along these lines seems to me much more proportional to > the task at hand: You already have to link to the serialization library that you have had to build. I don't understand the difference. And your user needs to understand the trade-offs with each archive format. > > // server > > RCF_BEGIN(I_Echo, "I_Echo") > RCF_METHOD_R1(std::string, echo, std::string); > RCF_END(I_X); > > struct Echo > { > void std::string echo(std::string s) { return s; } > }; > > int main() > { > RCF::RcfServer server(50001); > server.bind<I_Echo,Echo>(); > server.start(); > return 0; > } > > // client > > RCF_BEGIN(I_Echo, "I_Echo") > RCF_METHOD_R1(std::string, echo, std::string); > RCF_END(I_Echo); > > int main() > { > std::cout << RcfClient<I_Echo>("localhost", 50001).echo("ho hum"); > return 0; > } > Your client has 4 lines of code to my 5 and you have macros in your interface. Not normally considered a good thing. And you have hard coded the server location. Always considered a bad thing in anything but toy code. [snip] > I guess the argument boils down to this: does anyone write network applications > for which CORBA-style scaleability is not a requirement? I would think so, but > maybe I'm wrong. > There are low level systems that need to work with sockets. The IETF has made a pretty good job of making the internet protocols scale. And there are hard and soft real time projects that need to use sockets. There are probably a lot of applications that have been built using sockets that should have used CORBA. Cost has historically been a big issue with CORBA because commercial implementations have typically ( in the U.K. ) cost of the order of £3,500 per developer a year and £2,500 per user a year run time. > RPC's don't scale too well, we both agree on that. But why do you think all > applications need to scale? If I'm prototyping something, then the last thing in > the world I need is scaleability, and I certainly wouldn't want the development > cluttered and slowed because someone has decreed that we must all use CORBA > because it scales so well. > If you are just playing around then I don't have a problem. But I don't think boost is in the habit of adopting toys. The problem with over simplified solutions is that a prototype is built, the boss asks for a few extra features, and before you know it, its rolled out to production and know one will pay for it to be re-written properly :-(. > Your position seems to be that programmers should not be afforded the option of > choosing; they should just bite the bullet and always use CORBA. If they don't > like that, then they should just avoid networking altogether. Personally I tend to prefer not letting programmers shoot themselves in the foot, if I can avoid it. Unfortunately, they ( and I sometimes ) are incredibly inventive at finding new ways to do so ;-). /ikh

7 11

N-arity operators in C++, also reducing temporaries. [Repost]
by Pavel Chikulaev 09 Mar '05

09 Mar '05

This text not as silly as my "Herb Sutter's operator = can be optimized", so please read it. I'm currently working on library "Lazy" which eases creation of classes which needs lazy evalution and n-arity operators to improve speed. The library's sample usage placed below. Please let me know what do you think about it. I'll appreciate any feedback on my library. Library description: Library eases creation of classes which needs lazy evalution and n-arity operators. Library features are: * n-arity operators support; * operator aliasing, such as a + -b will be computed as a - b; * custom operators; * no unnecessary temporaries during evalution and assigning. Library's sample usage: //Matrix.h #include "lazy.hpp" class transpose_tag {}; //Tag class class Matrix { LAZY_CLASS(Matrix) static lazy::type<Matrix> Matrix_; //Similar to Andrei Alexandrescu's Type2Type template public: Matrix(); Matrix(const Matrix &); Matrix & operator = (const Matrix &); void swap(void Matrix &); //Libray won't work without swap function. //If name of your swap function isn't swap then use //LAZY_CLASS_EX(Matrix, YourSwapFunctionName) //lazy constuctors which enables lazy operators Matrix(LAZY_OP(Matix_ + Matrix_)); //Matrix operator +(Matrix, Matrix) Matrix(LAZY_OP(Matrix_ * Matrix_)); //... Matrix(LAZY_OP(-Matrix_); Matrix(LAZY_OP(Matrix_ + Matrix_ * Matrix_)); //ternary operator //Now enable operators LAZY_ENABLE_OP(Matrix_ = Matrix_ + Matrix_); LAZY_ENABLE_OP(Matrix_ = Matrix_ * Matrix_); LAZY_ENABLE_OP(Matrix_ = -Matrix_); LAZY_ENABLE_OP(Matrix_ = Matrix_ + Matrix_ * Matrix_); //operator aliasing LAZY_ALIAS(Matrix + -Matrix_ = Matrix_ - Matrix_); //Custom operation Matrix(LAZY_CUSTOM_OP(transpose_tag, (Matrix_))); LAZY_ENABLE_CUSTOM_OP(transpose, Matrix_ = lazy::custom_op<transpose_tag>(Matrix_)); //same as Matrix transpose (const Matrix &) but there //won't be any temporary objects at all }; //Matrix.cpp Matrix::Matrix(LAZY_OP(Matix_ + Matrix_) op) { //Construct matrix object //lhs matrix = op._1 //rhs matrix = op._2 } Matrix::Matrix(LAZY_CUSTOM_OP(transpose_tag, (Matrix_) op) { //Construct matrix object tranposed to op._1 } //etc //Now the use of Matrix class Matrix a, b, c, d; //... a = b + c; //No tempories at all //Using normal practice it will take two temporary objects (no NRVO or RVO ) a = b + -c; //Will be evaluates as a = b - c; No temporaries again //Using normal practice it will take three temporary objects (no NRVO or RVO) a = b + c * d; //Will use ternary operator. No temporaries again a = transpose(b); //Custom lazy operation. No tempories again Maybe the library is very similar to uBLAS's matrix_expression and vector_expression. But with my approach there is no need to code matrix_expression and vector_expression at all and it is easy to create new classes which needs lazy evaluation and n-arity operators. I believe that my library should be very useful with big_int. So what do you think? Is there any similar approaches available? Is there any need of such library? Thanks in advance. -- Pavel Chikulaev

7 47

Herb Sutter's Assignment operator can be optimized + Proposal for very small boost utility library
by Pavel Chikulaev 09 Mar '05

09 Mar '05

Hi, Do you know that well-known Herb Sutter's assignment operator in most cases does unnecessary copying? No? Then read it to learn how to elminate it. class Matrix { //.... Matrix& operator = (const Matrix& that) { Matrixtemp(that); swap(temp); return *this; } //... }; Consider first example: Matrixa, b; //.... a = b; Here Herb Sutter's operator = works just fine. But consider second example: Matrix func (); Matrix a; //... Matrix = func(); Result of func() is copied to temporary objectand then operator = copies it again. So assigning to result of function creates one useless object. Elminating of temporary int object will cost nothing, but elminating of temporary std::vector of 10000 elements will cost a lot. But how can we define that copying is necessary? - Every function returns object not of type T but temporary object of type T. So let's code something: template<typename T> struct temporary : T { temporary() {} temporary(const T & t) : T(t) {} //some operators and constructors to create base object in-place not listed here }; Now let's change function consider operator +: Matrix operator + (const Matrix & a, const Matrix & b) { Matrix temp(a); temp += b; return temp; } To optimize it we do the following: temporary<Matrix> operator + (const Matrix & a, const Matrix & b) { Matrix temp(a); temp += b; return temp; } Maybe it can be hardly optimized using NRVO, so let's help the complier rewriting as following: temporary<Matrix> operator + (const Matrix & a, const Matrix & b) { temporary<Matrix> temp(a); temp += b; return temp; } By now, even returning temporary<Matrix> instead of Matrix, no optimization is done. To enable the optimization we need to change the class Matrix by adding one more assignment operator : Matrix & operator = (const temporary<Matrix> & that) { swap (const_cast<Matrix &>(static_cast<const Matrix &>(that))); return *this; } or using "deprecated" casts Matrix & operator = (const temporary<Matrix> & that) { swap ((Matrix &) that); return *this; } By now we've elminated unnecassary copying. Is this worth being called Pavel Chikulaev's temporary assignment operator? Is this worth being included in Boost? By including temporary.hpp, adding one operator in class, and replacing each function result to explicitly marked temporary you get really a lot. My temporary assignment operator as safe as Herb Sutter's. Maybe returing temporary<T> will make some obstacles to templated programming, so i'm going to add temporary_traits: is_temporary, add_temporary, remove_temporary. Some changes of BOOST_TYPEOF will be also needed. So, what do you think? Copyright 2005 Pavel Chikulaev. Use, modification, and distribution are subject to the Boost Software License, Version 1.0

12 29

Sockets
by Boris 09 Mar '05

09 Mar '05

There hasn't been much talk about a socket library recently. The Wiki stuff about sockets is quite old so I don't know if Hugo is still working on it? It's some time ago I added some proposals for a multiplexing library to the Wiki. So I went through most of the Wiki pages of Boost.Socket and Multiplexing and tried to gather and sort the ideas a bit. As I don't want to go even more into details by adding more C++ code I tried a top-down-approach using UML diagrams. Without sorting the ideas and getting a big picture we are stuck in the details and don't proceed. The network API isn't small, there are many different goals to reach and the network library might overlap with other libraries - quite a lot to do. :-) So here is the next small step: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet As usual any comments are appreciated, Boris

7 13

Boost 1.32.0 and VS.NET 2005 under AMD64
by p.klotz＠icoserve.com 09 Mar '05

09 Mar '05

Hi I have sent a mail about this topic to boost-users a few weeks ago but got no response. There exist a few problems when trying to compile Boost 1.32.0 under AMD64 with VS.NET 2005: * No toolset exists to compile Boost 1.32.0 native on the AMD64 platform (no cross compile). The attached file vc-8_0-amd64-tools.jam fixes that. * InterlockedExchange() in line 44 of lwm_win32.hpp collides with a macro of the same name in WinBase.h One finds in WinBase.h: #elif defined(_M_AMD64) && !defined(RC_INVOKED) ... #define InterlockedExchange _InterlockedExchange I changed the name of Boost's function to InterlockedExchangeBoost() to avoid this problem. * No type long_type exists when compiling with the Microsoft Compiler. The 64Bit part in lwm_win32.hpp seems to have been written for the Intel Compiler. An additional #ifdef now checks if the 64Bit compiler is from Intel or Microsoft. The InterlockedExchange() and long_type issues are fixed by boost_1_32_0-AMD64.patch. Maybe these changes can be integrated in some form in the next version of Boost. Best regards, Peter.

2 2

Re: [boost] [1.33.0]: Some Moderation Please.
by Dave Gomboc 09 Mar '05

09 Mar '05

> Date: Tue, 08 Mar 2005 13:50:54 -0700 > From: "Victor A. Wagner Jr." <vawjr(a)rudbek.com> > > And I _hope_ what I put in the <hostile>...</hostile> was offensive, > it was intended to be. I'd hate to think that I'm accidently offensive > but can't be when I want to. Victor, please, quit while you're behind. Dave

1 0

[testing] Possible changes to testing..
by Rene Rivera 09 Mar '05

09 Mar '05

All, I've been reading all the testing related post and not having time to respond to them. So I decided to talk about what might be done to improve things in one big posting. For along time now one of my objectives has been to use BuildBot (http://buildbot.sf.net/) to improve the management of running the regression tests. For those who don't feel like reading about that software here's a quick summary: It is a client-server based configuration where the test server controls the test clients telling them what to do for test. In this arrangement the client do not directly control what they are testing, nor how. All the clients provide is an execution environment for the testing. The server is configured to control the various clients as to what they test, including how to get the source, and when they test. The testing is change driven instead of time driven as we currently have. This means that each time a change occurs on the source (CVS in our case) the server decides to tell the clients to run tests. Because of this direct communication to the clients the server is able to give direct feedback as to what the testing is doing. This includes a live display of test progress, down to a dynamic view of the test log. Some of the issues and how this step might help. And other changes I've thought about might help.. *Reproducibility* BuildBot controls what the checkouts are and what triggered the build. You can see this by selecting one of the yellow "Build #" links on the BuildBot display. If there's ever a question about what code produced an error one can get the specific version of the tree to attempt reproduction. The history of what tests have run is kept. Which means that we can finally answer the dreaded "When did that start breaking?" question. *Scalability* One big change I'd like to see is the breakup of running tests to make it possible for testers to run tests on subsets of libraries, or even individual libraries. For example there might be some testers which have a special interest in a particular library, Boost.Python comes to mind. It would be ideal to make it possible for them to only run those tests, and to go through the extra steps of doing the Python setup. Also for some popular platforms, it becomes possible to get much faster response rates from testing if, for example, we partition the library testing space throughout those platforms and they would test the libraries in parallel. For this to happen some significant organizational changes need to happen to the tests. As it currently stands such a division is not possible because of the way tests are defined and organized. We have a single test point, status/Jamfile, which a) points to the rest of the test points, libs/*/test/Jamfile, and b) defines it's own tests. The problem is that there is a conflict, for some libraries, between the tests defined in status/Jamfile, and the tests defined in libs/*/test/Jamfile. For example Boost.Config has a reduced set of test in status/Jamfile. This situation is likely a reaction to reduce test times to something manageable. And I understand that library authors would need to have a place to run their own set of comprehensive tests. My proposal is to create a set of canonical tests that comprise the regression testing suite independent of the library author's tests. This set of tests would be structured so that it's possible to run each libraries tests independent of others. It would be adding this type of structure: boost-root/tests/<library>/Jamfile boost-root/tests/<library>/<sub-library>/Jamfile boost-root/tests/<library>/<some-other-grouping>/Jamfile So for example a tester could say she only wants to test python/*, or numeric/ublas/*, etc. *Fragility* Simply put because BuildBot exposes the complete testing procedure it becomes much easier to see where problems occur in the testing. Also, because there is a central server managing the procedures it's more likely that problems can be solved at that one location instead of opaquely trying to fix the clients. With the, hopefully, additional distributed testers it becomes harder for testing to break down completely. Another aspect we need to address is fragility of the server. Ideally we would have multiple BuildBot servers to add redundancy. To make such a multi-server, multi-client setup resource efficient we would need to manage the distribution of testing between them. *Resources* The only predictable way to address the resource usage, is to distribute the testing so we can create more capacity. Breaking up the tests is the only way I can see to move there. It was already suggested that only slicing the testing to single toolsets would help. But that doesn't really address the problems. For example it would still be prohibitive for me to run tests on my G3 Mac for CW-8.3 because it's a slow machine and it would take days to run just one cycle of tests making the results useless. But it would be possible for me to run a minimal set of tests, for example Boost.Config and other basic tests. Restructuring also brings up the possibility of moderating the set of tests that make it into the regression suite. Right now we are in a position of asking library authors to define what the tests for the library. We can't moderate what gets into testing, or what needs go out. We need some procedure for reviewing tests, and some form of approval to get tests into the regression system. I'm not saying that authors would not be able to do additional testing, just that we need to define what the standard set of tests are so that we can concentrate our testing efforts. It would still be possible to set up additional resources to run "experimental" tests. *Response* The gain from segmentation and distribution of testing is hopefully obvious ;-) But another advantage of using BuildBot is that we are not tied to waiting for the XSLT processing to see results. Sure the results are not going to be as incredibly well organized as the Meta-Comm results but they are immediately available. So if there is a significant delay in the processing, because of load or breakage, we can still continue working. *Releases* Managing the testing for a release was brought up a many times. And it's clear that requiring testers to do manual changes is just not working. For BuildBot having the control of what is tested on the server means that at any point one, or some small number, person(s) can make the switch to have testing resources devoted to release testing. One possibility that the finner grain testing allows for is to limit the testing for a release to the required set of toolsets and platforms. OK, that's enough rambling... I know I haven't mentioned many other items raised, particularly about bjam and Boost.Build. I'll leave that for another post. I just need to get back to setting up the BuildBot server now ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

RE: [boost] thread safety in boost date time
by Yitzhak Sapir 09 Mar '05

09 Mar '05

> From: Jeff Garland > > On Tue, 8 Mar 2005 11:34:15 +0200, Yitzhak Sapir wrote > > Boost date_time apparently has a thread safety problem in linux in > > that it calls localtime() in boost/date_time/time_clock.hpp and > > related functions rather than localtime_r() and related functions. > > This is even though BOOST_HAS_PTHREADS is defined by configure in > > user.hpp. > > That's true -- date_time doesn't do anything to ensure thread > safety. I'm a little reluctant to protect these functions since the > user can determine better if they need to take the associated > performance hit. Of course this needs to be documented, which > it isn't now. Thoughts? Ok, having investigated the problem a little more, I get the following.. The problem comes down to the fact that localtime/gmtime call tzset(), which in turn calls getenv("TZ"). This call isn't done in the _r versions which use pretty much the same code. getenv() appears to be not thread safe, but I'm not sure why. This does indicate, however, that probably the _r versions are a little quicker (because they don't call getenv()). Running localtime (no _r) in loops in four threads on a multi cpu machine resulted in no segmentation fault. Maybe something else is interfering with getenv() in unforseeable ways? boost is not the only one making these calls. log4cxx is another third party we use and it also makes these calls. It also calls wcsftime, a version of strftime, which appears to always call tzset()/getenv(). So, wcsftime/strftime appear to be not threadsafe either. For the record, we use libgcc 3.3.3 and glibc 3.2.3. The libgcc is a by product of compiling an equivalent gcc on all machines for distcc purposes, while the glibc is the version that was installed with the operating system. I am wondering if this version mismatch could be the cause of the problems, but it seems the getenv.c hasn't changed in glibc for 2 years. A link to an example posting about a problem that seems very similar: http://lists.gnu.org/archive/html/bug-glibc/2002-11/msg00092.html If it is to be documented and not fixed, it should probably be documented in a central place for all boost. (This is a good idea regardless). I think it should be fixed, given that the main difference is using a static buffer vs a stack allocated buffer and that the current version does more work (damage?) than the reentrant version. Yitzhak Sapir

2 1

copy_if, composition, and proper predicate
by Michael Goldshteyn 08 Mar '05

08 Mar '05

Given: // Definitions class Element { public: const std::string &GetTag() const; }; typedef std::vector<Element> ElementContainer; // Now here is what is required ElementContainer elements; ... ElementContainer matchingElements; std::string matchingTag("abc"); copy_if(elements.begin(),elements.end(),back_inserter(matchingElements)),pred); -- What is pred? Assuming that iElements represents the iterator inside copy_if, pred should be something like: iElements->GetTag()==matchingTag I could go about this by creating a new function object class/struct, which takes matchingTag as its sole constructor argument and does the comparison inside operator(). But, I want to use in place composition using binders, etc... to create the pred, so as not to have to create a function object class/struct. The question is, "What piece of code should pred be?" // Almost does the right thing, but it's only *iElements==matchingTag, I need iElements->GetTag()==matchingTag bind_2nd(equal_to,matchingTag) This seems like a very common operation. How can I compose the predicate, in place to do this? If there are multiple solutions, I would like to hear them as well! Thanks, Michael

2 1

Archive stuck
by Gennadiy Rozental 08 Mar '05

08 Mar '05

Sorry I know I was given direct address. But I couldn't locate it for some reason. Gennadiy

1 1

Re: [boost] Re: What I Hate About How We Abstract System Dependence
by brangdon＠cix.compulink.co.uk 08 Mar '05

08 Mar '05

In-Reply-To: <422D79A6.4050502(a)aaronwl.com> aaronrabiddog51(a)aaronwl.com (Aaron W. LaFramboise) wrote (abridged): > > I have always thought that concrete implementations of portable > > libraries should supply users a way to get at the OS-specific data so > > they can use platform-specific facilities on them if neccessary. > [...] > It seems to me that, by doing this, we are throwing away so many > correctness guarantees. To me, this seems sort of like taking > shared_ptr, and making it implicitly convertable to a pointer. Surely it's more like taking shared_ptr and giving it an explicit get() function? You can break invariants by doing stuff like: delete p.get(); but people are unlikely to do that by accident. Access to the underlying raw pointer is essential for inter-operating with software which isn't smart-pointer aware. So it is with OS handles. -- Dave Harris, Nottingham, UK

1 0

Re: [boost] Re: What I Hate About How We Abstract System Dependence
by brangdon＠cix.compulink.co.uk 08 Mar '05

08 Mar '05

In-Reply-To: <loom.20050308T013051-569(a)post.gmane.org> belvis(a)pacbell.net (Bob Bell) wrote (abridged): > Another possibility is to provide another level of indirection. For > example, boost::thread can have an accessor which returns a > boost::platform_thread, which has the OS thread ID, plus member > functions which mimic OS operations not reflected in the portable > (boost::thread) API. The advantage of this approach is that > boost::platform_thread member functions may be able to preserve > invariants that otherwise might be broken if the user was allowed > to manipulate the underlying OS thread ID itself, and if the coverage > of the boost::platform_thread member functions is large enough, it > might not even be necessary to expose the OS thread ID at all. I don't think the coverage could never be large enough. We should always allow for 3rd parties which are not boost-aware, and which need to be passed low-level OS handles. -- Dave Harris, Nottingham, UK

1 0

[iostreams] names for non-blocking character properties
by Jonathan Turkanis 08 Mar '05

08 Mar '05

Hi All, Everybody likes naming questions, right? The thread "[iostreams] Major interface changes planned" discussed having the get() function return a type (basic_character, character or wcharacter) which can hold either a character, an EOF indication or an EAGAIN indication. My question is what I should call the functions which query the state of a basic_character. My first idea was to use bool good(character c) - returns true if c represents a character rather than EOF or EAGAIN bool eof(chacrater c) - returns true if c represent EOF bool fail(character c) - returns true if c represents EAGAIN. These functions have the same names as member functions of basic_ios. However, since fail() above doesn't mean exactly the same thing as basic_ios::fail(), I now think this is a bad idea. Here are the names I've thought of: good: good, is_good eof: eof, is_eof fail: fail, eagain, is_eagain, would_block, should_retry I also need names for the two functions called by implementations of get() to return characters representing EOF and EAGAIN. E.g., template<typename Source> character get(Source& src) { ... if ( ... ) return eof(); else return eagain(); } (They will actually return instances of types convertible to basic_character.) What do you think? Jonathan

3 7

[shmem] New Shmem snapshot ready in Boost Files section
by Ion Gaztañaga 08 Mar '05

08 Mar '05

Hello to all, I've just uploaded a new version of Shmem library (removed Boost from name because of the new naming policy) to Boost Files (http://groups.yahoo.com/group/boost/files/) which includes built html help files. Snapshot file: Shmem.2005-03-06.tar.bz2. Changes and features from last version: -> Name changes. -> Improved compatibility with unordered_map/set family. Soon we will be able to place unordered containers in shared memory. Thanks, Daniel. -> Templatized index types for named shared memory object allocator -> New private segregated storage STL allocator for shared memory. -> Bug fixes -> Improved documentation and code comments. For the next version I plan to improve code comments, documentation and tests. Please, if there is any comment or suggestion, let me know. Regards, /Ion

2 1

Is (void) still means ()? Is that syntax deprecated?
by Pavel Chikulaev 08 Mar '05

08 Mar '05

ISO/IEC 14882:1998(E) 8.3.5 (2) says: The parameter list (void) is equivalent to the empty parameter list. Is there any paper that shows that syntax (void) deprecated? I am asking about it because I'm trying to remove (void) syntax in Visual Studio's 2005 IDE Class View and Add Member Wizard. Is there any ideas how to remove it? P.S. As for me, It is really annoying.

1 0

[Boost.Regex] Not compiling without exceptions.
by larsbj＠gullik.net 08 Mar '05

08 Mar '05

In cpp_regex_traits.cpp line 76 there is a re-throw. This does not work when compiling without exceptions. I see that gcc have a #ifndef __EXCEPTIONS # define __throw_exception_again #else # define __throw_exception_again throw #endif for this case. Something similar should work for boost as well. To allow compiling I did this: --- ../../boost/boost/throw_exception.hpp 2004-08-05 17:24:43.000000000 +0200 +++ boost/throw_exception.hpp 2005-03-08 03:04:27.066704153 +0100 @@ -32,6 +32,8 @@ void throw_exception(std::exception const & e); // user defined +#define BOOST_THROW_EXCEPTION_AGAIN + #else template<class E> inline void throw_exception(E const & e) @@ -39,6 +41,8 @@ throw e; } +#define BOOST_THROW_EXCEPTION_AGAIN throw + #endif } // namespace boost -- Lgb

3 3

Incredible Logos
by John Maddock 08 Mar '05

08 Mar '05

As someone who hasn't paid that much attention to the logos during their development, I have to say going to vote was a revelation - there were so many exceptionally high quality logos to choose from - all I can say is there's some really talented people on this list and whatever the result I think we're going to end up with an excellent new logo. Well done everyone! John.

1 0

Re: What I Hate About How We Abstract System Dependence
by Chris Just 08 Mar '05

08 Mar '05

Rob Stewart wrote: > Another possibility is to provide another level of indirection. For > example, boost::thread can have an accessor which returns a > boost::platform_thread, which has the OS thread ID, plus member functions > which mimic OS operations not reflected in the portable (boost::thread) API. > The advantage of this approach is that boost::platform_thread member > functions may be able to preserve invariants that otherwise might be broken > if the user was allowed to manipulate the underlying OS thread ID itself, and > if the coverage of the boost::platform_thread member functions is large > enough, it might not even be necessary to expose the OS thread ID at all. This is exactly what I would like to see. Boost::thread and other classes should be platform neutral, but provide a method to get at the private handles so that people can extend the class for specific platforms on their own. Another thing I would REALLY like to see is better documentation. I'd love to use more Boost classes, but I don't have time to reverse engineer them to figure out how they work. Chris. __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

2 1

My Thoughts on the Best Logos
by Rob Stewart 08 Mar '05

08 Mar '05

I decided to jump in with my ideas for the best logos and my comments on them. 1. 67 Simeon Nasilowski I liked this one because the checkerboard is abstract for several things: building blocks (Boost provides software building blocks), fitting the missing piece (Boost often provides just what you're missing), blended parts of C++ syntax (you can infer :: and }{, for example). I also liked that the checkerboard itself could be used as an icon, including in the address/location bar of the browser. What I don't like is the color scheme. I think a bluer scheme would be better. "C++ Libraries" could also be replaced with other tag lines like: - Setting the Standard - C++: The Next Generation (might be a copyright problem) - Your C++ 2. 83 Emil Kirichev I liked the color wheel, since it could be extracted as an icon and it suggests a never ending stream of libraries from Boost. I don't like the multiple colors; a simpler scheme would be better, I think. "C++ Library" should be plural, at the least, and could be replaced with numerous tag lines. 3. 49 Cristian Peraferrer Mayn? This logo looks really sharp and might have been my first choice, except for a couple of issues. I liked the coloring and the lettering. Since there is no accompanying graphic, it would be difficult to form an iconic version of this logo. The shading in the letters and the border requires a high number of colors; will it look as attactive with less color depth? 4. 21 Jonathan Turkanis I like the grayscale variant best, but the black works OK for lower color depths. There's too much gap between the "C" and "boost." It doesn't render well at low resolution, including as an icon. 5. 38 Simeon Nasilowski I like the "b" variant best. (I'm partial to the blue color palette, it seems.) The blocks can be used separately as an icon and there's always room to add a tag line (push "boost" up and put the tag line below as with #83). The foreground block could be adorned with a "C" yielding "C++," though that leaves the other, exposed surfaces with nothing. I don't know if that will look right or not. Adding a tag line would improve this one quite a bit. -- Rob Stewart stewart(a)sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

1 0

Re: [boost] thread safety in boost date time
by Iain Hanson 08 Mar '05

08 Mar '05

On Tue, 2005-03-08 at 06:20 -0700, Jeff Garland wrote: > On Tue, 8 Mar 2005 14:48:00 +0200, Peter Dimov wrote > > Well I don't think just calling the _r function is enough to ensure the thread > safety of this code. I believe I would have to insert a lock in the date-time > code to make this assurance. > Yes it is. the _r versions require a user supplied buffer. So each caller supplying there own buffer is what makes them re-entrant. /ikh

1 0

Re: [boost] Re: FSM Review
by Iain Hanson 08 Mar '05

08 Mar '05

On Mon, 2005-03-07 at 21:24 -0500, David Abrahams wrote: > "Iain K. Hanson" <ikh(a)hansons.demon.co.uk> writes: > > > On Mon, Mar 07, 2005 at 06:03:15PM -0500, David Abrahams wrote: > >> "Andreas Huber" <ahd6974-spamgroupstrap(a)yahoo.com> writes: > >> > > > > [snip] > > > >> > > >> > That depends on the functionality. I don't think it is possible if you > >> > want to provide support for orthogonal regions. > >> > >> Sorry, I don't really understand the concept. How are they different > >> from separate state machines? > > > > AFAICT nothing. State charts are always collapseable to state transition > > tables. > > This has something to do with STTs and State Charts? I'm lost. > Nothing else you say here helps clarify the concept of orthogonal > regions for me. No. Sorry, I should not have run the two together. orthogonal regions are also know as concurrent states. They are separate state machines running on separate threads. The other stuff was to give you an idea of what would be needed to support a state chart DSL and generator. /ikh

1 0

boost/operators.hpp remarks
by Sylvain Pion 08 Mar '05

08 Mar '05

Hi, I have been using boost/operators.hpp recently, and found it quite good at removing lines of code from my maintainance area :) I have some remarks about it : 1/ The mixed operators are only provided if you know the type in advance and it is fixed. For example, it is not possible for example to mix with a template family of types. E.g. let's say that My_type has to provide mixed operators with all types X<U>. This is not possible to do with the current library. Another related thing is how to express "I want My_type to mix with all integral types". Maybe there could be a version of the operators that uses enable_if and tr1::is_integral somehow, for this purpose ? Just a thought. 2/ I think it is "Euclidean Ring", not "Euclidian Ring" ("e" instead of "i"), hence the names for euclidian_ring_operators<T> and similar, are unfortunate. -- Sylvain

3 3

thread safety in boost date time
by Yitzhak Sapir 08 Mar '05

08 Mar '05

Boost date_time apparently has a thread safety problem in linux in that it calls localtime() in boost/date_time/time_clock.hpp and related functions rather than localtime_r() and related functions. This is even though BOOST_HAS_PTHREADS is defined by configure in user.hpp. Yitzhak Sapir

3 3

casp.hpp workaround and more
by Gennadiy Rozental 07 Mar '05

07 Mar '05

1. Shouldn't this header use workaround from config/suffix.hpp instead of BOOST_EXPLICIT_DEFAULT_TARGET? 2. Shouldn't this header be split by ..._cast? 3. Doesn't numeric_cast facility shouldn't be deprecated? Genandiy

4 23

RPC library
by Jarl Lindrud 07 Mar '05

07 Mar '05

Hi all, I've searched this list a bit and found a few mentions of rpc's (Remote Procedure Call), but nothing concrete. I've written a library for doing portable C++ RPC's, which can be downloaded at http://www.codeproject.com/threads/RMI_For_Cpp.asp Is there any interest in Boost for something like this, and if so in what directions do you all think it should be developed? Thanks! Jarl.

7 20

Re: [boost] Re: Logo Contest Current Tally
by JOAQUIN LOPEZ MU?Z 07 Mar '05

07 Mar '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> [...] > Well, now Joel and Jeff Garland have both told me by private mail that > there doesn't seem to be anything wrong with having a discussion about > what's worth voting for, and I am basically convinced. I think > certainaspects of the logo are more important than others and > should be > considered. But before I start blurting out any specifics, let's hear > from the group. Is there any reason we shouldn't talk about how to > choose? We do almost everything at boost by public consensus. Why > not this time? Well, I don't have any strong opinion about whether this poll should be kept in privacy or not, but certainly there is a difference between the contest and other activities: the former is a voting process, unlike all other decisions taken here (including reviews.) Joaquín M López Muñoz Telefónica, Investigacion y Desarrollo

1 0

Re: [boost] Re: Logo Contest Current Tally
by Iain Hanson 07 Mar '05

07 Mar '05

On Mon, 2005-03-07 at 12:48 -0500, David Abrahams wrote: > christopher diggins <cdiggins(a)videotron.ca> writes: > [snip] > Well, now Joel and Jeff Garland have both told me by private mail that > there doesn't seem to be anything wrong with having a discussion about > what's worth voting for, and I am basically convinced. I think certain > aspects of the logo are more important than others and should be > considered. But before I start blurting out any specifics, let's hear > from the group. Is there any reason we shouldn't talk about how to > choose? We do almost everything at boost by public consensus. Why > not this time? > I think it would be a good thing. If people are influenced by it will be no different than the review process. I also have no problem with the running tally. /ikh

1 0

FSM Review
by Peter Petrov 07 Mar '05

07 Mar '05

I have used and watched closely this library for more than a year, since its early versions. Initially, we needed a good modern state machine framework for a project at the company I work for. After evaluating the possibilities, we decided to take the risk and go with Andreas' FSM, despite its early-alpha state at the time. Now, one year later, that choice has proved to be correct. We have used FSM in one more project and are planning to use it in future projects too. * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? The documentation is very adequate. I was able to quickly understand how to use the basic features of the library, and then proceed to the advanced ones. At that time I had experience with different kinds of state machines, but primarily SDL-specified. FSM's documentation was my first introduction to UML state charts, and did the job well. The tutorial is excellent. The FAQ and Rationale sections give important answers to questions which are likely to arise. There is also an extensive Reference section, which I needed very rarely. * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? To me, the design is good and follows naturally from the objectives of the library. It imposes some restrictions, although they can be overcome if necessary (for me it has not been necessary). For example, machines don't recognize polymorphic events, therefore they cannot "forward" unknown events to another machine. This can be circumvented by using a "wrapper" event around such events, which works, but only with asynchronous machines. Another example is the way that state machines are inherited - it's not very flexible and only allows altering how a state machine reacts to an already recognized event. One cannot add support for new events, except using again the "wrapper event" trick. * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? The name (boost::fsm, Boost.FSM) is fine for me. Regarding separating the library into two parts, I prefer it being separated, since the Worker part is useful by itself. * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? It's as obscure as its complexity requires. At the same time it is stable and bug-free, which is proved by extensive bulk-testing in our labs. * Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it usable for embedded systems? Is the documentation clear on performance tradeoffs? The documentation is definitely clear on performance tradeoffs, and it's up to the potential user to take an informed decision. One tradeoff is that dispatch time is linear to the number of nested states. In my experience this is not a problem, since there are rarely more than two nested states, and I have never seen more than three. A possible problem is that states are constructed using operator new(). The documentation clearly states that, and the library allows overcoming the issue by specifying a custom allocator for the state machine, as well as writing custom operator new()'s for all state classes. I personally am against the second requirement and think that it complicates things too much. Specifying a custom allocator for the state machine should be enough. (this is mentioned in the documentation, in the Rationale section under "Memory management customization") * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? The greatest distinction of code written using the FSM library is its manageability. It's very easy to write and subsequently evolve state machines and most common mistakes are caught at compilation time. When state machines are involved, using FSM is definitely a great improvement over using a primitive framework, or not using a framework at all (the notorious switch/case idiom). Especially if the library's advanced features are used. * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability problems? Used with MSVC++ 7.1 and GCC 3.x. Currently without problems. In the early versions there were some minor issues which Andreas has addressed quickly. Regarding older compilers, I don't think they should be supported by this library. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In-depth study, as well as real-world usage. * Are you knowledgeable about the problem domain? To a good extent. I have developed two different state machine frameworks, although both of them were significantly lower level than FSM. I have also worked extensively with various kinds of state machines, mainly protocol-related and in telecom applications. * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes. Definitely.

2 1

[interfaces] Hand written interfaces
by Jonathan Turkanis 07 Mar '05

07 Mar '05

Hi All, I'm working on ways to make the Boost Interfaces library easier to use. This involves making interface definitions compile faster and making them easier to read. Unfortunately, these are somewhat conflicting goals: really messy-looking interface definitions may compile much faster than simple ones. I'm working on four approaches to interface definitions; I plan to implement them all and then compare them. Right now I'm looking for feedback on number 4: 1. The current IDL, possibly slightly modified, in which an interface definition consists of a sequence of macro invocation 2. A modified IDL in which an interface definition consists of a single invocation; this increases the amount of preprocessor metaprogramming but decreases the amount of template metaprogramming 3. The pseudocode IDL, together with an IDL compiler which translates pseudocode definitions into C++ class definitions requiring virtually no metaprogramming. 4. Hand written interfaces, requiring virtually no metaprogramming. The point of allowing hand-written interfaces is to decrease compile times. There's no question that writing interfaces by handle will be the most difficult of the above four options. Still, writing interfaces by hand has to be reasonably straightforward or no one will ever do it. So here's my question. Consider the interface: interface IBar { void foo(const char*); int foo(int, int); }; Is the following definition of IBar so complex that it would be pointless to offer it as an alternative? template< typename Derived, typename Base, typename Flags > struct ibar_impl { struct type : Base { struct interface_metadata : metadata_base<Derived, Base, Flags> { const char* names = { "foo", "foo" }; typedef mpl::vector< void(const char*), int(int, int) > signatures; }; void foo(const char* name) { return invoker<interface_metadata, 1>::execute(this, name); } int foo(int n, int m) { return invoker<interface_metadata, 2>::execute(this, int, int); } }; }; typedef interface< ibar_impl<_, _, _> > IBar; Best Regards, Jonathan

4 8

RE: [boost] Re: review of proposed fsm library
by Dave Gomboc 07 Mar '05

07 Mar '05

> > Otherwise you would be able to mix both synchronous and > asynchronous > > states in one machine, which doesn't make sense. > > While tangential to my original point about naturally > recursive structures, I'll take time out to disagree here > too. It _can_ make sense to combine async and sync behaviour > in different parts of a state machine when one is modeling > electrical circuits, e.g. in certain regions of the circuit > one may know that the behaviour is sync and not want to spend > extra CPU by going through all the async motions. I will quickly add that this issue (combining async and sync fsms) will occur whenever one has prior components that one wishes to assemble together, where some are async and some are sync. Dave

1 0

Re: [boost] Re: review of proposed fsm library
by Dave Gomboc 07 Mar '05

07 Mar '05

> > The distinction made between state and state_machine, > which I > consider to be unfortunate, was not justified in > the rationale... > > There is at least one good reason - the library supports both > synchronous and asynchronous state machines, which are > essentially different beasts and are operated quite > differently. No such distinction exists for states, therefore > they shouldn't be treated the same way as state machines. However, asynchronous_state_machine is separated from both state_machine and state. Ergo, the reason must lie elsewhere. I didn't delve deeply into the library's support for asynchronicity, but I did consider it odd and amusing that at the level of hardware circuitry, asynchronous behaviour is the default, and work is done to get synchronous behaviour by adding latches and a clock, but that for fsm (and many, many other software components rather higher-level than a J-K flip-flop) the opposite was true. I do understand it, but I am not convinced that in this case it was the correct decision. Unforunately, I have to leave for work now. :-) > Otherwise you would be able to mix both synchronous and > asynchronous states in one machine, which doesn't make sense. While tangential to my original point about naturally recursive structures, I'll take time out to disagree here too. It _can_ make sense to combine async and sync behaviour in different parts of a state machine when one is modeling electrical circuits, e.g. in certain regions of the circuit one may know that the behaviour is sync and not want to spend extra CPU by going through all the async motions. Dave

1 0

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

07 Mar '05

On Sun, 2005-03-06 at 22:59 +0000, Jarl Lindrud wrote: > Iain Hanson <Iain.Hanson <at> videonetworks.com> writes: > To sum up then, your position is that: > > 1) CORBA is the be-all and end-all of distributed programming. > No. Its just the best that we have available. > 2) Anything not projected to need CORBA-style scaleability is just a "toy" and > not worthy of library support. > Probably. But the problem is that people build quick and dirty apps that grow like Topsy. Its the danger of this that make me against non scalable solutions. > > I guess you don't find much need for networking at all in Boost? At least not > beyond lowlevel socket API wrappers and assorted utilites that might be useful > for something like realtime socket apps. Anything beyond that can, and should, > be done with CORBA, regardless of scale and scope. > Doug Schmidt certainly tends to argue in this direction. However, given that CORBA is not ubiquitous and is not ever likely to be then there is always going to be a need for sockets. /ikh

1 0

Help need reed related to libboost_filesystem.lib
by Thota, Vimal 07 Mar '05

07 Mar '05

Dear friends, I am using the boost libraries for my project. When I am compiling the (libboost_filesystem.lib) with my project files libraries which is available in the ibs\filesystem\build\bin\libboost_filesystem.lib\vc7.1\release\runtime-l ink-dynamic , I am facing with the Linking issues which I have listed down. Are you people able to guess where I have gone wrong. Thanks, Vimal Thota Disk Manager error LNK2001: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::~dir_it(void)" (??1dir_it@filesystem@boost@@QAE@XZ) Disk Manager error LNK2001: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::dir_it(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0dir_it@filesystem@boost@@QAE@ABV?$basic_string@DU?$char_traits@D@std @@V?$allocator@D@2@@std@@@Z) Disk Manager error LNK2001: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::dir_it(void)" (??0dir_it@filesystem@boost@@QAE@XZ) Disk Manager error LNK2001: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::is_directory>::operator bool(void)const " (??B?$get@Uis_directory@filesystem@boost@@@filesystem@boost@@QBE_NXZ) Disk Manager error LNK2001: unresolved external symbol "public: class boost::filesystem::dir_it & __thiscall boost::filesystem::dir_it::operator++(void)" (??Edir_it@filesystem@boost@@QAEAAV012@XZ) Disk Manager error LNK2001: unresolved external symbol "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall boost::filesystem::dir_it::operator*(void)const " (??Ddir_it@filesystem@boost@@QBE?AV?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@XZ) Disk Manager error LNK2001: unresolved external symbol ___argc Disk Manager error LNK2001: unresolved external symbol ___argv Disk Manager error LNK2001: unresolved external symbol __mbctype Disk Manager error LNK2001: unresolved external symbol __mbctype Disk Manager error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in msvcprtd.lib(newop_s.obj) Disk Manager error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in msvcprtd.lib(newaop_s.obj) Disk Manager error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in MSVCRTD.lib(MSVCR71D.dll) Disk Manager error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) already defined in MSVCRTD.lib(MSVCR71D.dll) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::~dir_it(void)" (??1dir_it@filesystem@boost@@QAE@XZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::dir_it(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0dir_it@filesystem@boost@@QAE@ABV?$basic_string@DU?$char_traits@D@std @@V?$allocator@D@2@@std@@@Z) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::dir_it(void)" (??0dir_it@filesystem@boost@@QAE@XZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::ctime>::operator long const *(void)const " (??B?$get@Uctime@filesystem@boost@@@filesystem@boost@@QBEPBJXZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::is_archive>::operator bool(void)const " (??B?$get@Uis_archive@filesystem@boost@@@filesystem@boost@@QBE_NXZ) referenced in function "public: bool __thiscall DirectoryWatcher::next_archived(void)const " (?next_archived@DirectoryWatcher@@QBE_NXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::is_directory>::operator bool(void)const " (??B?$get@Uis_directory@filesystem@boost@@@filesystem@boost@@QBE_NXZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::mtime>::operator long const *(void)const " (??B?$get@Umtime@filesystem@boost@@@filesystem@boost@@QBEPBJXZ) referenced in function "public: long __thiscall DirectoryWatcher::next_age(void)const " (?next_age@DirectoryWatcher@@QBEJXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall DMWorkflowInterface::~DMWorkflowInterface(void)" (??1DMWorkflowInterface@@QAE@XZ) referenced in function "public: void * __thiscall DMWorkflowInterface::`scalar deleting destructor'(unsigned int)" (??_GDMWorkflowInterface@@QAEPAXI@Z) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall DMWorkflowInterface::DMWorkflowInterface(void)" (??0DMWorkflowInterface@@QAE@XZ) referenced in function "public: virtual void __thiscall DiskManagerService::MainThread(void)" (?MainThread@DiskManagerService@@UAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: bool __thiscall boost::filesystem::dir_it::operator!=(class boost::filesystem::dir_it const &)const " (??9dir_it@filesystem@boost@@QBE_NABV012@@Z) referenced in function "private: void __thiscall DiskManagerService::check_watchers(class std::map<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class DirectoryWatcher *,struct std::less<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,class DirectoryWatcher *> > > &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?check_watchers@DiskManagerService@@AAEXAAV?$map@V?$basic_string@DU?$ch ar_traits@D@std@@V?$allocator@D@2@@std@@PAVDirectoryWatcher@@U?$less@V?$ basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@V?$allocat or@U?$pair@$$CBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@ std@@PAVDirectoryWatcher@@@std@@@2@@std@@ABV?$basic_string@DU?$char_trai ts@D@std@@V?$allocator@D@2@@3@@Z) Disk Manager error LNK2019: unresolved external symbol "public: bool __thiscall boost::filesystem::dir_it::operator==(class boost::filesystem::dir_it const &)const " (??8dir_it@filesystem@boost@@QBE_NABV012@@Z) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: class boost::filesystem::dir_it & __thiscall boost::filesystem::dir_it::operator++(void)" (??Edir_it@filesystem@boost@@QAEAAV012@XZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: class boost::filesystem::dir_it & __thiscall boost::filesystem::dir_it::operator=(class boost::filesystem::dir_it const &)" (??4dir_it@filesystem@boost@@QAEAAV012@ABV012@@Z) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall boost::filesystem::dir_it::operator*(void)const " (??Ddir_it@filesystem@boost@@QBE?AV?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@XZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol __mbctype referenced in function "protected: long __thiscall CEditView::OnFindReplaceCmd(unsigned int,long)" (?OnFindReplaceCmd@CEditView@@IAEJIJ@Z) Disk Manager fatal error LNK1120: 17 unresolved externals Disk Manager warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library This email may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

[optional]output
by Gennadiy Rozental 07 Mar '05

07 Mar '05

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; } Gennadiy

1 0

Boost Logo Contest Request for independent tally
by Joel de Guzman 07 Mar '05

07 Mar '05

Hi, Jonathan noted a minor error in the recent (initial) tally where his entry got listed twice. In the interest of fairness... I would like to request for help. If anyone is interested in doing an independent tally, I'd gladly provide him/her with access to the submitted votes. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

2 2

[congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by Jonathan Turkanis 07 Mar '05

07 Mar '05

Hi, <boost/shared_ptr.hpp> contains the following in the public section of the class definition (reformatted): // Tasteless as this may seem, making all members public // allows member templates to work in the absence of member // template friends. (Matthew Langston) #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #endif T * px; // contained pointer detail::shared_count pn; // reference counter This has become a pretty common technique, I believe. I certainly use it a lot, at any rate. I'd like to suggest two macros which would allow code like the above to be simplified as follows: BOOST_PRIVATE: BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) T * px; // contained pointer detail::shared_count pn; // reference counter Here BOOST_PRIVATE would expand to "private" for compilers that support template friends and to "public" otherwise; BOOST_BEFRIEND_TEMPLATE would expand to a template friend declaration where supported, and to nothing otherwise. It might be desirable to have two macros BOOST_BEFRIEND_TEMPLATE_CLASS and BOOST_BEFRIEND_TEMPLATE_STRUCT to avoid compiler warnings. Jonathan

3 9

Logo Contest: Send In Your votes!
by Joel de Guzman 07 Mar '05

07 Mar '05

Hi Y'all, Acceptance of logo entries is officially over. I waited more than 24 hours after the March 1 deadline to account for the time zones. For my convenience, I find it best to simply collect the votes by email. For this purpose, I setup a mail account at address: boost.logo.contest(a)gmail.com where you can send your votes to. For transparency, I shared the password with the Boost Moderators, so they can check the status anytime. Please be reminded that voting shall be based on Instant Runoff Voting (http://www.fairvote.org/irv/whatis2.htm) meaning that each individual voter shall choose 5 favorites, in order of preference. Please send in your votes in this format: 1. 1st choice: Entry number (variant), Submitter 2. 2nd choice: Entry number (variant), Submitter 3. 3rd choice: Entry number (variant), Submitter 4. 4th choice: Entry number (variant), Submitter 5. 5th choice: Entry number (variant), Submitter ***where variant, designated by a letter, is optional. Example: 1. 225, John Doe 2. 336a, Jane Doe 3. 751, Apple Pie 4. 101b, Dorothy Rainbow 5. 855, Kim Possible I shall be collecting votes and progressively posting the results in the boost web site. The competition will close on March 15, 2005 and the winning entry will be announced soon thereafter. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

5 12

RE: [boost] high_resolution_timer \ timer feature requests forBoost.Timer
by Brian Braatz 07 Mar '05

07 Mar '05

(sorry - mail client weirdness on the last post- I have fixed the doublespacing)(here is the mail again) ********************************************* First off- note that Timer can take a start time on the ctor: class timer { public: timer() { _start_time = std::clock(); } // postcondition: elapsed()==0 (snip) high_resolution_timer does not however: class high_resolution_timer { public: // ctor high_resolution_timer() { start_time.QuadPart = 0; frequency.QuadPart = 0; if (!QueryPerformanceFrequency(&frequency)) throw std::runtime_error("Couldn't acquire frequency"); restart(); } (snip) MY PROBLEM: I need to feed the timer the START time (or get FROM it the start time would be preferred) The reason I need this is because for logging purposes (working with the Profiler from Christopher Diggins) I need to log the start and stop times, and I need it to (for internal cross reference) be the same number for multiple purposes. MY REQUESTS: Easy request: high_resolution_timer is changed to have the same type of ctor as timer does May Start a discussion request: That something like a starttime() method is provided for both classes Medium request- That both classes do a typedef for the type returned by the starttime method i.e. instead of class high_resolution_timer { public: (snip) private: timer t; // backup in case of QueryPerformanceCounter() bug LARGE_INTEGER start_time; LARGE_INTEGER frequency; }; You have instead: class high_resolution_timer { public: (snip) typedef LARGE_INTEGER TIME_TYPE; private: timer t; // backup in case of QueryPerformanceCounter() bug TIME_TYPE start_time; TIME_TYPE frequency; }; (for both high_resolution_timer and timer) There you go, those are my requests. Now I will sit here quietly and hope there is a Santa Claus.... (grin)

3 2

RE: [boost] Re: high_resolution_timer \ timer feature requestsforBoost.Timer
by Brian Braatz 06 Mar '05

06 Mar '05

The code I am using was originally developed by Christopher Diggins. His code allows for use of boost.timer or the high_resolution_timer. I am currently using the high_resolution timer. THANK YOU for the suggestion of using the microsec_time_clock.hpp. I did not know that existed, do you know how does this compare to the high_resolution timer? I need to stick to a base release version of boost for production reasons, do you think this other timer will work inside 1.32? Thank you very much for your thoughts, I would not have noticed the microsec if you had not pointed it out to me. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Caleb Epstein > Sent: Friday, March 04, 2005 8:32 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: high_resolution_timer \ timer feature > requestsforBoost.Timer > > On Fri, 4 Mar 2005 10:42:16 -0700, Brian Braatz <brianb(a)rmtg.com> wrote: > > > But the Profile LOG (like a trace of what happened) looks like this > > DEPTH NAME TIME > > 0 FuncA 2 Seconds > > 1 FuncB 1 Second > > > > Does that answer your question, or am I missing something? > > Just a subtle point, but the boost::timer class returns CPU time used > not elapsed wall-clock time and would return results of ~0.0 for a > function that just sleep'd for a second or two. > > If what you're looking for is a high-resolution clock, try > <boost/date_time/microsec_time_clock.hpp> (at least in the latest > CVS). If you want performance or profiling information, use > boost::timer. > > > -- > Caleb Epstein > caleb dot epstein at gmail dot com > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Integrating Boost Documentation with Visual Studio IDE.
by Pavel Chikulaev 06 Mar '05

06 Mar '05

Hi all, I don't know how many of boosters use VC, but I think intergrating boost documentation with visual studio IDE will help VC developers a lot. Key feature is context help, for example pressing F1 when cursor is on "BOOST_PP_REPEAT" token will instantly open help on BOOST_PP_REPEAT instead of opening boost.org(or saved page), then documentation, then preprocessor, the reference, then scrolling a lot in left frame for PP_REPEAT. Right know I don't know how to do it, but I'll try to find the easiest way to do it. P.S. I almost have no exprerience with other IDEs, but I think it is also possible to integrate boost documentation with them too.

2 1

Wanted : Modified Boost Jamfiles for Mac OS X
by Tommy Nordgren 06 Mar '05

06 Mar '05

Could someone please mail me an archive with modified Jamfiles, that allows the Boost 1.32 libraries to be built with Mac OS X 10.3.8, on a 512 MB machine. Currently the build stalls when compiling a file called xml_parser.cpp, exhausting virtual memory. As an alternative, can someone tell me how to exclude builds that uses the Spirit Framework. "Home is not where you are born, but where your heart finds peace" - Tommy Nordgren, "The dying old crone"

4 3

FSM review
by Jeff Garland 06 Mar '05

06 Mar '05

I'll start my review with the conclusion: I recommend fsm be accepted into Boost -- thanks to Andreas for his excellent contribution. FSMs apply to a broad range of software products and the proposed library would simplify the implementation of many of them. * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? Overall I think the documentation is good, although I think the tutorial code be improved slightly by carefully illustrating the 'boilerplate' part from where the user would add code either to a machine or to a state and the design tradeoffs that would drive one to this approach (we had some discussion of this earlier and it might be better in the FAQ then in the tutorial). * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? Overall the library is well thought out and supports a wide range of essential features for building fsms. * What is your evaluation of the implementation? I spent a few minutes browsing the implementation. In general the code is written clearly and understandably -- even though I couldn't possibly understand the full context of the code or truly evaulate the implementation. There is also a large number of tests already written which should help with porting / regression testing. Overall the implementation appears to be up to usual boost standards. * 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? No opinion on this except that there is good documentation of the performance implications of using the library. * What is your evaluation of the potential usefulness of the library? *Can you compare this FSM to other implementations? Most other FSM implementations are code generators of one sort or another. For example: <http://smc.sourceforge.net>. Being a pure library (and a header library as well) makes the current proposal very attractive. No new tools to required to take advantage of the capabilities. * Did you try to use the library? With what compiler? Did you have any problems? Yes - gcc 3.3.1 under dev-c++. No problems. I modified the tutorial examples to try and understand what a user would need to learn to use the library. *Do you have tips for better support of older compilers? What are possible portability problems? I think Andreas should ignore older compilers. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours. I also looked at the library about a year ago and followed list discussions over the last couple years. * Are you knowledgeable about the problem domain? I'm quite famaliar with FSM for software design having first studied them in college over 20 years ago. I've also worked on projects that use state machine compilers. *The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? 1. Library name -- Obviously boost::fsm is not for everyone.... I think the library name is fine. 2. Two libraries in one: The library consists of two parts that could easily be separated... I'd leave the library alone for now. More experience will show whether it makes sense to split it. 3. Exception handling support: Several people have rightly pointed out that the rationale for the exception handling support is too thin. The rationale seems good enough to me for now. A more advanced paper would be nice, but doesn't seem essential to using the library. 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. This isn't a problem in my view as RTTI is a feature of C++. While I acknowledge that there are a group of folks that want to turn it off for embedded work, I think if they are that concerned about performance they probably won't use fsm anyway. So the bottom line is I don't see that this is a problem. Jeff

2 1

[serialization] flush ?
by troy d. straszheim 06 Mar '05

06 Mar '05

Here's a use case that has been discussed before, but to which I couldn't seem to find any solid resolution the list archives: class A; some_oarchive oa; void mutate(shared_ptr<A>& aptr_) { aptr_ = shared_ptr<A>(new A); }; shared_ptr<A> aptr; for (int i=0; i<LARGE_NUMBER; i++) { mutate(aptr); oa << aptr; } The problem is that your oarchive ends up with somewhere between two and LARGE_NUMBER distinct A's in it. Usually two. Presumably the "two" is because in this simple example only A's are getting allocated and deallocated, and therefore there are often free A-sized blocks conveniently laying around for reuse. aptr gets assigned A's at two different alternating addresses. If it was just a plain A, you could turn off tracking by not serializing through a pointer. You'd then get the right number of A's in your archive. But if elsewhere you want to serialize A through a pointer you can't do that just for this call to operator<<(). Also you don't have a good way to see if A actually is serialized via pointer elsewhere or not. (My use case is one where lots of inexperienced programmers are modifying the data structures contained in A, and they will surely screw up if the rules are more complicated than "use BOOST_CLASS_EXPORT in your header file, and never use bald pointers, always use shared_ptr".) I looked through the archives a bunch and didn't come across anything conclusive. It seemed that some thought this kind of use case was pathological, but I'm not sure why. Of course, I'm not all that experienced with serialization. What I'd like to be able to do is to tell the archive, "The previous calls to operator<<() represent a 'snapshot' of the state of some group of objects, and now I want you to forget about existent objects because I am going to rearrange them all. Continue to track object types, but forget about the addresses." I realize that this creates the possiblity for memory leaks, but if the serialization is done through one toplevel call to operator<< on a shared_ptr whose pointee contains pointers to a whole universe of home-cooked pointer spaghetti, I don't see a better way to do this, and I don't see how to clearly express what I intend via the export and tracking macro mechanisms. You can't close and reopen the archive in the top loop, you get duplicate headers. The list archives mention the use case of serializing the state of some memory pool that is very likely to get reused: I think the little example above is probably the simplest case of this. So without asking for a sanity-check, I implemented basic_oarchive::flush(), and some tests. The changes to basic_oarchive and basic_oarchive_impl are very small. basic_oarchive has an internal object_set, which tracks object_ids and addresses. I add a num_flushed_objects member, and flush() clears out the set and adds the number of objects flushed to this counter. New tracked objects are assigned object_ids starting at num_flushed_objects + object_set.size(). In this way the class_id's are reused post-flush, but object id's are not. The interface is simply this: class A; some_oarchive oa; void mutate(shared_ptr<A>& aptr_) { aptr_ = shared_ptr<A>(new A); }; shared_ptr<A> aptr; for (int i=0; i<LARGE_NUMBER; i++) { mutate(aptr); oa << aptr; oa.flush(); } No modifications are required to the iarchive, but the user code of course has to be written in such a way that objects aren't leaked. though "oa << archive::endl;" would be a cute way to flush, too. Dunno. Is this unnecessary because I'm missing something obvious? At any rate the modified files and two tests are attached. All tests pass with this change... troy d. straszheim /////////1/////////2/////////3/////////4/////////5/////////6/////////7/////////8 // test_flush_simple.cpp // // copyright (c) 2005 // troy d. straszheim <troy(a)resophonic.com> // http://www.resophonic.com // // Use, modification and distribution is subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // should pass compilation and execution // test verifies that basic_oarchive::flush() "resets" all pointers to objects #include <iostream> #include <fstream> #include <cstdio> // remove #include <boost/config.hpp> #if defined(BOOST_NO_STDC_NAMESPACE) namespace std{ using ::remove; } #endif #include <boost/archive/archive_exception.hpp> #include "test_tools.hpp" #include <boost/preprocessor/stringize.hpp> #include BOOST_PP_STRINGIZE(BOOST_ARCHIVE_TEST) #include <boost/serialization/base_object.hpp> #include <boost/serialization/export.hpp> struct A { unsigned i; template <class Archive> void serialize(Archive &ar, unsigned) { ar & BOOST_SERIALIZATION_NVP(i); } static std::size_t num_objects_; public: virtual ~A(){ num_objects_--; } A() { num_objects_++; } static std::size_t num_objects() { return num_objects_; } }; std::size_t A::num_objects_ = 0; const unsigned NUMOBJS = 4; void do_save(const char *testfile) { test_ostream os(testfile, TEST_STREAM_FLAGS); test_oarchive oa(os); oa.flush(); // be sure you can flush an empty archive A a; for (unsigned int i=0; i<NUMOBJS; i++) { a.i = i; oa << BOOST_SERIALIZATION_NVP(a); oa.flush(); BOOST_CHECK(A::num_objects() == 1); } // do some more flushes for the sake of thoroughness; oa.flush(); oa.flush(); oa.flush(); A* ap = &a; for (unsigned int i=0; i<NUMOBJS; i++) { ap->i = i; oa << BOOST_SERIALIZATION_NVP(ap); oa.flush(); BOOST_CHECK(A::num_objects() == 1); } oa.flush(); oa.flush(); oa.flush(); } // save exported polymorphic class void do_load(const char *testfile) { test_istream is(testfile, TEST_STREAM_FLAGS); test_iarchive ia(is); { A a; for (unsigned int i=0; i<NUMOBJS; i++) { ia >> BOOST_SERIALIZATION_NVP(a); BOOST_CHECK(a.i == i); BOOST_CHECK(A::num_objects() == 1); } } // a goes out of scope: no objects BOOST_CHECK(A::num_objects() == 0); A* ap; for (unsigned int i=0; i<NUMOBJS; i++) { ia >> BOOST_SERIALIZATION_NVP(ap); std::cout << "numobjs=" << A::num_objects() << std::endl; BOOST_CHECK(ap->i == i); BOOST_CHECK(A::num_objects() == (i+1)); // we leak 'em on purpose, we need to count em. } } int test_main( int /* argc */, char* /* argv */[] ) { const char * testfile = boost::archive::tmpnam(NULL); BOOST_REQUIRE(NULL != testfile); do_save(testfile); do_load(testfile); std::remove(testfile); return EXIT_SUCCESS; } // EOF /////////1/////////2/////////3/////////4/////////5/////////6/////////7/////////8 // test_flush.cpp // // copyright (c) 2005 // troy d. straszheim <troy(a)resophonic.com> // http://www.resophonic.com // // Use, modification and distribution is subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // should pass compilation and execution // test verifies that basic_oarchive::flush() "resets" all pointers to objects #include <iostream> #include <fstream> #include <cstdio> // remove #include <boost/config.hpp> #if defined(BOOST_NO_STDC_NAMESPACE) namespace std{ using ::remove; } #endif #include <boost/archive/archive_exception.hpp> #include "test_tools.hpp" #include <boost/preprocessor/stringize.hpp> #include BOOST_PP_STRINGIZE(BOOST_ARCHIVE_TEST) #include <boost/serialization/base_object.hpp> #include <boost/serialization/export.hpp> class polymorphic_base { friend class boost::serialization::access; template<class Archive> void serialize(Archive & /* ar */, const unsigned int /* file_version */){ } static std::size_t num_objects_; public: virtual ~polymorphic_base(){ num_objects_--; } polymorphic_base() { num_objects_++; } static std::size_t num_objects() { return num_objects_; } }; std::size_t polymorphic_base::num_objects_ = 0; //BOOST_IS_ABSTRACT(polymorphic_base) class polymorphic_derived1 : public polymorphic_base { friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int /* file_version */){ ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(polymorphic_base); } public: virtual ~polymorphic_derived1(){} }; BOOST_CLASS_EXPORT(polymorphic_derived1) class polymorphic_derived2 : public polymorphic_base { friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int /* file_version */){ ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(polymorphic_base); } public: virtual ~polymorphic_derived2(){} }; BOOST_CLASS_EXPORT(polymorphic_derived2) // save exported polymorphic class void save_exported(const char *testfile) { test_ostream os(testfile, TEST_STREAM_FLAGS); test_oarchive oa(os); polymorphic_base *rb1 = new polymorphic_derived1; polymorphic_base *rb2a = new polymorphic_derived2; polymorphic_base *rb2b = new polymorphic_derived2; oa << BOOST_SERIALIZATION_NVP(rb1); oa << BOOST_SERIALIZATION_NVP(rb1); oa << BOOST_SERIALIZATION_NVP(rb2a); oa << BOOST_SERIALIZATION_NVP(rb2b); BOOST_CHECK(polymorphic_base::num_objects()==3); oa.flush(); oa << BOOST_SERIALIZATION_NVP(rb2b); oa << BOOST_SERIALIZATION_NVP(rb2a); oa << BOOST_SERIALIZATION_NVP(rb1); oa << BOOST_SERIALIZATION_NVP(rb1); BOOST_CHECK(polymorphic_base::num_objects()==3); oa.flush(); oa << BOOST_SERIALIZATION_NVP(rb1); oa << BOOST_SERIALIZATION_NVP(rb1); oa << BOOST_SERIALIZATION_NVP(rb2a); oa << BOOST_SERIALIZATION_NVP(rb2b); BOOST_CHECK(polymorphic_base::num_objects()==3); oa.flush(); delete rb1; delete rb2a; delete rb2b; BOOST_CHECK(polymorphic_base::num_objects()==0); } #define RETRIEVE_AND_CHECK(ARCHIVE, PTR, TYPE, N) \ ARCHIVE >> BOOST_SERIALIZATION_NVP(PTR); \ BOOST_CHECK_MESSAGE( \ boost::serialization::type_info_implementation<TYPE> \ ::type::get_instance() \ == boost::serialization::type_info_implementation<polymorphic_base> \ ::type::get_derived_extended_type_info(*PTR), \ "restored pointer " BOOST_PP_STRINGIZE(PTR) " not of correct type" ); \ BOOST_CHECK(polymorphic_base::num_objects()==N); // save exported polymorphic class void load_exported(const char *testfile) { test_istream is(testfile, TEST_STREAM_FLAGS); test_iarchive ia(is); polymorphic_base *rb1a = NULL, *rb1b = NULL; polymorphic_base *rb2a = NULL, *rb2b = NULL; RETRIEVE_AND_CHECK(ia, rb1a, polymorphic_derived1, 1); RETRIEVE_AND_CHECK(ia, rb1b, polymorphic_derived1, 1); RETRIEVE_AND_CHECK(ia, rb2a, polymorphic_derived2, 2); RETRIEVE_AND_CHECK(ia, rb2b, polymorphic_derived2, 3); RETRIEVE_AND_CHECK(ia, rb2b, polymorphic_derived2, 4); RETRIEVE_AND_CHECK(ia, rb2a, polymorphic_derived2, 5); RETRIEVE_AND_CHECK(ia, rb1a, polymorphic_derived1, 6); RETRIEVE_AND_CHECK(ia, rb1b, polymorphic_derived1, 6); RETRIEVE_AND_CHECK(ia, rb1a, polymorphic_derived1, 7); RETRIEVE_AND_CHECK(ia, rb1b, polymorphic_derived1, 7); RETRIEVE_AND_CHECK(ia, rb2a, polymorphic_derived2, 8); RETRIEVE_AND_CHECK(ia, rb2b, polymorphic_derived2, 9); } int test_main( int /* argc */, char* /* argv */[] ) { const char * testfile = boost::archive::tmpnam(NULL); BOOST_REQUIRE(NULL != testfile); save_exported(testfile); load_exported(testfile); std::remove(testfile); return EXIT_SUCCESS; } // EOF /////////1/////////2/////////3/////////4/////////5/////////6/////////7/////////8 // basic_oarchive.cpp: // (C) Copyright 2002 Robert Ramey - http://www.rrsd.com . // Use, modification and distribution is subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // See http://www.boost.org for updates, documentation, and revision history. #include <boost/config.hpp> // msvc 6.0 needs this for warning suppression #include <cassert> #include <set> #include <boost/limits.hpp> #include <boost/state_saver.hpp> #include <boost/throw_exception.hpp> // including this here to work around an ICC in intel 7.0 // normally this would be part of basic_oarchive.hpp below. #define BOOST_ARCHIVE #include <boost/archive/basic_archive.hpp> #include <boost/archive/detail/basic_oserializer.hpp> #include <boost/archive/detail/basic_pointer_oserializer.hpp> #include <boost/archive/detail/basic_oarchive.hpp> #include <boost/archive/archive_exception.hpp> #ifdef BOOST_MSVC # pragma warning(push) # pragma warning(disable : 4251 4231 4660 4275) #endif using namespace boost::serialization; namespace boost { namespace serialization { class extended_type_info; } namespace archive { namespace detail { class basic_oserializer; class basic_pointer_oserializer; class basic_oarchive_impl { friend class basic_oarchive; ////////////////////////////////////////////////////////////////////// // information about each serialized object saved // keyed on address, class_id struct aobject { const void * address; class_id_type class_id; object_id_type object_id; bool operator<(const aobject &rhs) const { assert(NULL != address); assert(NULL != rhs.address); if( address < rhs.address ) return true; if( address > rhs.address ) return false; return class_id < rhs.class_id; } aobject & operator=(const aobject & rhs) { address = rhs.address; class_id = rhs.class_id; object_id = rhs.object_id; return *this; } aobject( const void *a, class_id_type class_id_, object_id_type object_id_ ) : address(a), class_id(class_id_), object_id(object_id_) {} aobject() : address(NULL){} }; // keyed on class_id, address typedef std::set<aobject> object_set_type; object_set_type object_set; std::size_t num_flushed_objects; ////////////////////////////////////////////////////////////////////// // information about each serialized class saved // keyed on type_info struct cobject_type { const basic_oserializer * bos_ptr; const class_id_type class_id; bool initialized; cobject_type( std::size_t class_id_, const basic_oserializer & bos_ ) : bos_ptr(& bos_), class_id(class_id_), initialized(false) {} cobject_type(const basic_oserializer & bos_) : bos_ptr(& bos_) {} cobject_type( const cobject_type & rhs ) : bos_ptr(rhs.bos_ptr), class_id(rhs.class_id), initialized(rhs.initialized) {} // the following cannot be defined because of the const // member. This will generate a link error if an attempt // is made to assign. This should never be necessary // use this only for lookup argument cobject_type & operator=(const cobject_type &rhs); bool operator<(const cobject_type &rhs) const { return *bos_ptr < *(rhs.bos_ptr); } }; // keyed on type_info typedef std::set<cobject_type> cobject_info_set_type; cobject_info_set_type cobject_info_set; // list of objects initially stored as pointers - used to detect errors // keyed on object id std::set<object_id_type> stored_pointers; // address of the most recent object serialized as a poiner // whose data itself is now pending serialization const void * pending_object; const basic_oserializer * pending_bos; basic_oarchive_impl() : num_flushed_objects(0), pending_object(NULL), pending_bos(NULL) {} const cobject_type & find(const basic_oserializer & bos); const basic_oserializer * find(const serialization::extended_type_info &ti) const; public: const cobject_type & register_type(const basic_oserializer & bos); void save_object( basic_oarchive & ar, const void *t, const basic_oserializer & bos ); void save_pointer( basic_oarchive & ar, const void * t, const basic_pointer_oserializer * bpos ); void flush(); }; ////////////////////////////////////////////////////////////////////// // implementation of basic_oarchive implementation functions // given a type_info - find its bos // return NULL if not found inline const basic_oserializer * basic_oarchive_impl::find(const serialization::extended_type_info & ti) const { class bosarg : public basic_oserializer { bool class_info() const { assert(false); return false; } // returns true if objects should be tracked bool tracking() const { assert(false); return false; } // returns class version unsigned int version() const { assert(false); return 0; } // returns true if this class is polymorphic bool is_polymorphic() const{ assert(false); return false; } void save_object_data( basic_oarchive & ar, const void * x ) const { assert(false); } public: bosarg(const serialization::extended_type_info & type_) : boost::archive::detail::basic_oserializer(type_) {} }; bosarg bos(ti); cobject_info_set_type::const_iterator cit = cobject_info_set.find(cobject_type(bos)); // it should already have been "registered" - see below if(cit == cobject_info_set.end()){ // if an entry is not found in the table it is because a pointer // of a derived class has been serialized through its base class // but the derived class hasn't been "registered" return NULL; } // return pointer to the real class return cit->bos_ptr; } inline const basic_oarchive_impl::cobject_type & basic_oarchive_impl::find(const basic_oserializer & bos) { std::pair<cobject_info_set_type::iterator, bool> cresult = cobject_info_set.insert(cobject_type(cobject_info_set.size(), bos)); return *(cresult.first); } inline const basic_oarchive_impl::cobject_type & basic_oarchive_impl::register_type( const basic_oserializer & bos ){ cobject_type co(cobject_info_set.size(), bos); std::pair<cobject_info_set_type::const_iterator, bool> result = cobject_info_set.insert(co); return *(result.first); } inline void basic_oarchive_impl::save_object( basic_oarchive & ar, const void *t, const basic_oserializer & bos ){ // if its been serialized through a pointer and the preamble's been done if(t == pending_object && pending_bos == & bos){ // just save the object data ar.end_preamble(); (bos.save_object_data)(ar, t); return; } // get class information for this object const cobject_type & co = register_type(bos); if(bos.class_info()){ if( ! co.initialized){ ar.vsave(class_id_optional_type(co.class_id)); ar.vsave(tracking_type(bos.tracking())); ar.vsave(version_type(bos.version())); (const_cast<cobject_type &>(co)).initialized = true; } } // we're not tracking this type of object if(! bos.tracking()){ // just windup the preamble - no object id to write ar.end_preamble(); // and save the data (bos.save_object_data)(ar, t); return; } // look for an existing object id object_id_type oid(object_set.size() + num_flushed_objects); // lookup to see if this object has already been written to the archive basic_oarchive_impl::aobject ao(t, co.class_id, oid); std::pair<basic_oarchive_impl::object_set_type::const_iterator, bool> aresult = object_set.insert(ao); oid = aresult.first->object_id; // if its a new object if(aresult.second){ // write out the object id ar.vsave(oid); ar.end_preamble(); // and data (bos.save_object_data)(ar, t); return; } // check that it wasn't originally stored through a pointer if(stored_pointers.end() != stored_pointers.find(oid)){ // this has to be a user error. loading such an archive // would create duplicate objects boost::throw_exception( archive_exception(archive_exception::pointer_conflict) ); } // just save the object id ar.vsave(object_reference_type(oid)); ar.end_preamble(); return; } // save a pointer to an object instance inline void basic_oarchive_impl::save_pointer( basic_oarchive & ar, const void * t, const basic_pointer_oserializer * bpos_ptr ){ const basic_oserializer & bos = bpos_ptr->get_basic_serializer(); std::size_t original_count = cobject_info_set.size(); const cobject_type & co = register_type(bos); if(! co.initialized){ ar.vsave(co.class_id); // if its a previously unregistered class if((cobject_info_set.size() > original_count)){ if(bos.is_polymorphic()){ const serialization::extended_type_info *eti = & bos.type; const char * key = NULL; if(NULL != eti) key = eti->key; if(NULL != key){ // the following is required by IBM C++ compiler which // makes a copy when passing a non-const to a const. This // is permitted by the standard but rarely seen in practice const class_name_type cn(key); // write out the external class identifier ar.vsave(cn); } else // without an external class name // we won't be able to de-serialize it so bail now boost::throw_exception( archive_exception(archive_exception::unregistered_class) ); } } if(bos.class_info()){ ar.vsave(tracking_type(bos.tracking())); ar.vsave(version_type(bos.version())); } (const_cast<cobject_type &>(co)).initialized = true; } else{ ar.vsave(class_id_reference_type(co.class_id)); } // if we're not tracking if(! bos.tracking()){ // just save the data itself ar.end_preamble(); state_saver<const void *> x(pending_object); state_saver<const basic_oserializer *> y(pending_bos); pending_object = t; pending_bos = & bpos_ptr->get_basic_serializer(); bpos_ptr->save_object_ptr(ar, t); return; } object_id_type oid(object_set.size() + num_flushed_objects); // lookup to see if this object has already been written to the archive basic_oarchive_impl::aobject ao(t, co.class_id, oid); std::pair<basic_oarchive_impl::object_set_type::const_iterator, bool> aresult = object_set.insert(ao); oid = aresult.first->object_id; // if the saved object already exists if(! aresult.second){ // append the object id to he preamble ar.vsave(object_reference_type(oid)); // and windup. ar.end_preamble(); return; } // append id of this object to preamble ar.vsave(oid); ar.end_preamble(); // and save the object itself state_saver<const void *> x(pending_object); state_saver<const basic_oserializer *> y(pending_bos); pending_object = t; pending_bos = & bpos_ptr->get_basic_serializer(); bpos_ptr->save_object_ptr(ar, t); // add to the set of object initially stored through pointers stored_pointers.insert(oid); } // replaces addresses of objects in the object_set with NULL so that // future objects will be duplicated, but object_id's will be // preserved. inline void basic_oarchive_impl::flush() { num_flushed_objects += object_set.size(); object_set.clear(); } ////////////////////////////////////////////////////////////////////// // implementation of basic_oarchive functions BOOST_DECL_ARCHIVE basic_oarchive::basic_oarchive() : pimpl(new basic_oarchive_impl) {} BOOST_DECL_ARCHIVE basic_oarchive::~basic_oarchive() { delete pimpl; } void BOOST_DECL_ARCHIVE basic_oarchive::save_object( const void *x, const basic_oserializer & bos ){ pimpl->save_object(*this, x, bos); } void BOOST_DECL_ARCHIVE basic_oarchive::save_pointer( const void * t, const basic_pointer_oserializer * bpos_ptr ){ pimpl->save_pointer(*this, t, bpos_ptr); } void BOOST_DECL_ARCHIVE basic_oarchive::register_basic_serializer(const basic_oserializer & bos){ pimpl->register_type(bos); } unsigned int BOOST_DECL_ARCHIVE basic_oarchive::library_version() const{ return ARCHIVE_VERSION(); } void BOOST_DECL_ARCHIVE basic_oarchive::end_preamble(){ } void BOOST_DECL_ARCHIVE basic_oarchive::flush(){ pimpl->flush(); } } // namespace detail } // namespace archive } // namespace boost #ifdef BOOST_MSVC #pragma warning(pop) #endif #ifndef BOOST_ARCHIVE_BASIC_OARCHIVE_HPP #define BOOST_ARCHIVE_BASIC_OARCHIVE_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif /////////1/////////2/////////3/////////4/////////5/////////6/////////7/////////8 // basic_oarchive.hpp: // (C) Copyright 2002 Robert Ramey - http://www.rrsd.com . // Use, modification and distribution is subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // See http://www.boost.org for updates, documentation, and revision history. #include <boost/config.hpp> #include <boost/detail/workaround.hpp> // can't use this - much as I'd like to as borland doesn't support it // #include <boost/scoped_ptr.hpp> #include <boost/archive/basic_archive.hpp> #include <boost/serialization/tracking.hpp> #include <boost/archive/detail/abi_prefix.hpp> // must be the last header namespace boost { namespace archive { namespace detail { class BOOST_DECL_ARCHIVE basic_oarchive_impl; class BOOST_DECL_ARCHIVE basic_oserializer; class BOOST_DECL_ARCHIVE basic_pointer_oserializer; ////////////////////////////////////////////////////////////////////// // class basic_oarchive - write serialized objects to an output stream class BOOST_DECL_ARCHIVE basic_oarchive { friend class basic_oarchive_impl; // hide implementation of this class to minimize header conclusion // in client code. note: borland can't use scoped_ptr //boost::scoped_ptr<basic_oarchive_impl> pimpl; basic_oarchive_impl * pimpl; // overload these to bracket object attributes. Used to implement // xml archives virtual void vsave(const version_type t) = 0; virtual void vsave(const object_id_type t) = 0; virtual void vsave(const object_reference_type t) = 0; virtual void vsave(const class_id_type t) = 0; virtual void vsave(const class_id_optional_type t) = 0; virtual void vsave(const class_id_reference_type t) = 0; virtual void vsave(const class_name_type & t) = 0; virtual void vsave(const tracking_type t) = 0; protected: basic_oarchive(); virtual ~basic_oarchive(); public: unsigned int library_version() const; void save_object( const void *x, const basic_oserializer & bos ); void save_pointer( const void * t, const basic_pointer_oserializer * bpos_ptr ); void register_basic_serializer(const basic_oserializer & bos); void save_null_pointer(){ vsave(NULL_POINTER_TAG); } void end_preamble(); // default implementation does nothing void flush(); }; } // namespace detail } // namespace archive } // namespace boost // required by smart_cast for compilers not implementing // partial template specialization BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION( boost::archive::detail::basic_oarchive ) #include <boost/archive/detail/abi_suffix.hpp> // pops abi_suffix.hpp pragmas #endif //BOOST_ARCHIVE_BASIC_OARCHIVE_HPP

2 1

[Boost-bugs] [ boost-Bugs-1157766 ] build process still hangs on xml_grammar.cpp
by SourceForge.net 06 Mar '05

06 Mar '05

Bugs item #1157766, was opened at 2005-03-06 15:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1157766&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sebastian (pinguin751) Assigned to: Nobody/Anonymous (nobody) Summary: build process still hangs on xml_grammar.cpp Initial Comment: as suggested in this thread: http://lists.boost.org/MailArchives/boost/msg76792.php the build process still hangs on MacOSX when building xml_grammar.cpp (boost v1.32). the system has very high load, gcc fetches more and more memory til the system is constantly swapping ... with this fix: <darwin><release><inlining>off added to build of "serialisation" and "wserialisation" the problem could be solved (as already suggested in the mail listed above) also interesting could be this: http://lists.boost.org/MailArchives/boost/msg77573.php pls include a/the fix it into the src base thx regards, seb ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1157766&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

[somewhat OT] BGL-based graph library
by Maxim Khesin 06 Mar '05

06 Mar '05

Hello Folks, I recently started working on a graph-algorithms library in Python. What makes this one different from the other couple of libs that are available is a heavy influence from the C++ Boost Graph Library. This is a sort of an exploration in Concept in Python without loosing the Pythonness :). There is no official code release so far, but I have been blogging ideas and code snippets here: http://pythonzweb.blogspot.com/. I already invited Jeremy Siek of BGL fame to comment, and any other comments from boost/BGL community would be most welcome (you can leave them right on the blog). thanks, max.

4 5

Unhackable Wiki
by David Abrahams 06 Mar '05

06 Mar '05

I don't see any reason our Wiki should be so vulnerable, and before we make it official I would insist that we fix that. The Boost list never gets spammed, and moderators don't even seem to have to reject any spammers. All we need to do is use the same approval and posting process for the Wiki. Is something wrong with that? -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 6

Re: uBLAS mailing list
by Ian McCulloch 05 Mar '05

05 Mar '05

Nikos Platis wrote: > Hi, > > Being new to uBLAS I wanted to post a message to its mailing list. > Unfortunatly, the documentation still mentions the Yahoo Group, which, > as I now find out, is not the current mailing list of the project. I > read at > http://lists.boost.org/MailArchives/ublas/msg00095.php > that the problem will be corrected with the next release, We really have to wait until the next boost release to get an important correction made to the boost web page? That sounds nuts! > but, until > then, I believe that the easiest thing to do is add a large message at > the homepage of the Yahoo Group with information pointing to the new > mailing list (I have seen such messages in other Yahoo Groups). IIRC, the problem is none of the yahoo groups administrators are active on boost anymore, in which case that is not possible. Cheers, Ian

3 5

high_resolution_timer \ timer feature requests for Boost.Timer
by Brian Braatz 05 Mar '05

05 Mar '05

First off- note that Timer can take a start time on the ctor: class timer { public: timer() { _start_time = std::clock(); } // postcondition: elapsed()==0 (snip) high_resolution_timer does not however: class high_resolution_timer { public: // ctor high_resolution_timer() { start_time.QuadPart = 0; frequency.QuadPart = 0; if (!QueryPerformanceFrequency(&frequency)) throw std::runtime_error("Couldn't acquire frequency"); restart(); } (snip) MY PROBLEM: I need to feed the timer the START time (or get FROM it the start time would be preferred) The reason I need this is because for logging purposes (working with the Profiler from Christopher Diggins) I need to log the start and stop times, and I need it to (for internal cross reference) be the same number for multiple purposes. MY REQUESTS: Easy request: high_resolution_timer is changed to have the same type of ctor as timer does May Start a discussion request: That something like a starttime() method is provided for both classes Medium request- That both classes do a typedef for the type returned by the starttime method i.e. instead of class high_resolution_timer { public: (snip) private: timer t; // backup in case of QueryPerformanceCounter() bug LARGE_INTEGER start_time; LARGE_INTEGER frequency; }; You have instead: class high_resolution_timer { public: (snip) typedef LARGE_INTEGER TIME_TYPE; private: timer t; // backup in case of QueryPerformanceCounter() bug TIME_TYPE start_time; TIME_TYPE frequency; }; (for both high_resolution_timer and timer) There you go, those are my requests. Now I will sit here quietly and hope there is a Santa Claus.... (grin)

3 2

FSM - Late Review
by jdspalding＠comcast.net 05 Mar '05

05 Mar '05

FSM Review - John Spalding - 2005/MAR/04 Contents - Overall impression. - my use case. - review manager's questions. ******************************* Overall Impression ******************************* I have been completly impressed by the FSM library, and recommend that it be immediately accepted into the Boost Libraries. I had been looking for a system that implemented hierarchical state machines, and never before found anything satisfactory. The ideas behind the Harel state chart had always seemed to me to have a place in standard software development. Prior to using FSM, I had read through another effort on C++ state machine development "Practical State Charts in C++", by Miro Samek, CMP Books, 2002, and found its methods unsatisfactory. I was impressed by Samek's advocacy of the utility of hierarchical state machines in software design. I am now using FSM for a modest practical project at my work, involving about 10 events and 10 states. FSM will replace a home brew non-hierarchical state machine. I like the ability to model hierarchical states and I also like the way FSM allows state networks to be constructed and modified quickly. => improvements - new user documentation <= I would add to the documentation a small section on trouble shooting the compile. When I started out, the fact that state machine connectivity was specified in templates caused me a bit of head scratching. My typical new-user mistakes resulted in lots of error messages. I would explicitly address this area, describing how connectivity errors cause compile time errors, for common state machine hook up errors. For example, if I change the "context" for just one state from the correct value to an incorrect value, I get over 90 lines of output. I think if you explicitly described a simple strategy for tracking down these connectivity problems, it would help the new user. ********************************************** Usability Evaluation - my modest use case. ********************************************** A distinguishing characteristic of this FSM library is its use of C++ templates to specify event/state connectivity. - we specify which events are handled or ignored when we are in a specified state. - we specify the sub-state network for the state machine. These are two separate connection operations. Both are specified by the class declaration for the state. A typical class template I used follows, in the example code. - the event handing connectivity is specified by the 3-rd argument to the fsm::simple_state<> template, an mpl::list of events. Simpler forms exist for the case that an event does not require special processing, however this general case is not complex. - the sub-state network is handled by the first two arguments to the fsm::simple_state<> template. The second argument simply names the "outer state", or containing state of this state. The outermost states of the finite state machine also have to instead name the controlling class, derived from fsm::state_machine. - In addition, I have provided an IFsmState<> template that implements a "GetState()" function that can be called by the state machine. I have used FSM to implement a modest sized state machine with about 10 events and 10 states. This particular state machine implements the high level application state of a data taking machine control application. In this application there are about 4 varieties of data taking. Using a common outer state Acquisition, containing the data taking states, allows me to write once the common code that causes data taking to stop. This application also monitors a significant number of conditions that require the system to take action when an abnormal condition (or hazard) occurs. This led me to have two outermost states, Hazard and NoHazard. When an abnormal condition is signalled, the hierarchy allows me to write once the code that stops data taking, and causes the system to enter the Hazard state. Bottom line, I found hierarchical state modeling to be very useful. I also found that FSM had answers for all the problems I encountered reducing the hiersrchical state machine to working code, in this relatively small example. The only "advanced" functions of FSM I utilized were state_cast<> and context<>. struct StIdle : IFsmState<StIdle>, fsm::simple_state< StIdle, StNoHazard, mpl::list< fsm::custom_reaction< EvSortEnter>, fsm::custom_reaction< EvCalEnter>, fsm::custom_reaction< EvTestEnter>, fsm::custom_reaction< EvTemplGenEnter> > > { StIdle(); ~StIdle(); fsm::result react(const EvSortEnter &); fsm::result react(const EvCalEnter &); fsm::result react(const EvTestEnter &); fsm::result react(const EvTemplGenEnter &); }; // Used for all states... struct IFsmStateQuerry { virtual const type_info & GetState() const = 0; }; // Used for all states... template<typename T> struct IFsmState : public IFsmStateQuerry { const type_info & GetState() const { return typeid(T); } }; class SystemFsm : public IFsmStateQuerry, public fsm::state_machine< SystemFsm, StNoHazard > { public: SystemFsm() { } // ... // Get state information. const type_info & GetState() const { // state_cast produces object in active state. // GetState returns type_info for that state. return state_cast< const IFsmStateQuerry & >().GetState(); } }; ***************************** Review manager's questions ***************************** What is your evaluation of the documentation? - I proposed adding a new user section, to help with compile time problems caused by state machine connect errors. - I also think the central role of the "context" parameter in simple_state<>, when specifying how to connect up all the states, could be stressed more, esp. for new users. What is your evaluation of the design? - I did not review the design implementation. - The FSM API is novel, due to template use, but I grew to like it. Are there parts of the implementation that duplicate parts of BOOST? - no, the entire FSM is novel. I did not evaluate performance bottlenecks, nor real-time aspects of usage. I did try to use the library for a practical library, and had lots of fun. (see my use case section) How much work did you put into the evaluation. - I have spent several days reviewing FSM, and have tracked it since I read about it on the boost list in 2004. - I have spent 2-3 days on the modest practical project. Domain Knowledge... - I am an "interested" user, but not an expert. I strongly believe FSM should be accepted into Boost.

2 1

[Boost-bugs] [ boost-Patches-1157160 ] patch for boost::filesystem
by SourceForge.net 05 Mar '05

05 Mar '05

Patches item #1157160, was opened at 2005-03-05 07:23 Message generated for change (Comment added) made by fotzor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1157160&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Weiss (fotzor) Assigned to: Nobody/Anonymous (nobody) Summary: patch for boost::filesystem Initial Comment: hi, when you try to get the branch path of this "c:\some_dir\some_file.txt" under windows the branch path should be "c:\some_dir". what is returned instead is "c:" which isn't correct. so here's the fix: in path_posix_windows.cpp: std::string::size_type leaf_pos( const std::string & str, std::string::size_type end_pos ) // end_pos is past-the-end position // return 0 if str itself is leaf (or empty) { if ( end_pos && str[end_pos-1] == '/' ) return end_pos-1; std::string::size_type pos( str.find_last_of( '/', end_pos-1 ) ); # ifdef BOOST_WINDOWS if ( pos == std::string::npos ) pos = str.find_last_of( '\', end_pos-1 ); // ADDED if ( pos == std::string::npos ) pos = str.find_last_of( ':', end_pos-2 ); # endif return ( pos == std::string::npos // path itself must be a leaf (or empty) # ifdef BOOST_WINDOWS || (pos == 1 && (str[0] == '/' || str[0] == '\')) // or share // ADDED # endif ) ? 0 // so leaf is entire string : pos + 1; // or starts after delimiter } mfg steven ---------------------------------------------------------------------- >Comment By: Steven Weiss (fotzor) Date: 2005-03-05 08:24 Message: Logged In: YES user_id=1124235 i forgot something... in branch_path() you must also change the condition of the if to: if ( end_pos && (m_path[end_pos-1] == '/' || m_path[end_pos-1] == '\') && !detail::is_absolute_root( m_path, end_pos ) ) --end_pos; else it doesn't work proper. perhaps there are other functions depending on leaf_pos() that must be adjusted as well ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1157160&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

[Boost-bugs] [ boost-Patches-1157160 ] patch for boost::filesystem
by SourceForge.net 05 Mar '05

05 Mar '05

Patches item #1157160, was opened at 2005-03-05 07:23 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=1157160&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Weiss (fotzor) Assigned to: Nobody/Anonymous (nobody) Summary: patch for boost::filesystem Initial Comment: hi, when you try to get the branch path of this "c:\some_dir\some_file.txt" under windows the branch path should be "c:\some_dir". what is returned instead is "c:" which isn't correct. so here's the fix: in path_posix_windows.cpp: std::string::size_type leaf_pos( const std::string & str, std::string::size_type end_pos ) // end_pos is past-the-end position // return 0 if str itself is leaf (or empty) { if ( end_pos && str[end_pos-1] == '/' ) return end_pos-1; std::string::size_type pos( str.find_last_of( '/', end_pos-1 ) ); # ifdef BOOST_WINDOWS if ( pos == std::string::npos ) pos = str.find_last_of( '\', end_pos-1 ); // ADDED if ( pos == std::string::npos ) pos = str.find_last_of( ':', end_pos-2 ); # endif return ( pos == std::string::npos // path itself must be a leaf (or empty) # ifdef BOOST_WINDOWS || (pos == 1 && (str[0] == '/' || str[0] == '\')) // or share // ADDED # endif ) ? 0 // so leaf is entire string : pos + 1; // or starts after delimiter } mfg steven ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1157160&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

RE: [boost] high_resolution_timer \ timer featurerequests forBoost.Timerr
by Brian Braatz 05 Mar '05

05 Mar '05

> -----Original Message----- > On Behalf Of James Fowler > Sent: Friday, March 04, 2005 1:10 PM > Brian Braatz wrote: > > >First off- note that Timer can take a start time on the ctor: ... > > > >high_resolution_timer does not however: ... > > > > high_resolution_timer() { ... > > if (!QueryPerformanceFrequency(&frequency)) > > throw std::runtime_error("Couldn't acquire frequency"); > >... > > > >MY PROBLEM: > > I need to feed the timer the START time (or get FROM it the start > >time would be preferred) > > > >The reason I need this is because for logging purposes (working with the > >Profiler from Christopher Diggins) I need to log the start and stop > >times, and I need it to (for internal cross reference) be the same > >number for multiple purposes. > > [Brian Braatz Writes:] My most basic problem is high_resolution_timer and boost.timer have different interfaces, one takes a time to start with the other does not. I realize the high_resolution_timer is windows only and I realize that the struct it uses to store the time is windows specific. At the simplest level I am asking for this: Have both high_resolution_timer and timer support: * Typedef's for the internal TYPE * Same construction interface using that type * Accessor method to GET to the internal data Then I could accomplish what I am trying to do- I am not just measuring things, but putting a layer on top. I can live with the issues with timers. What I am after is being able to do this- Record profile LOGS in different threads (not reports, but logs of every call that happened), spit out the approximate TIME each one of those events occurred, this gives the human reader a conceptual way to connect the different logs in time- Right now I am using hours, mins, seconds for this, getting to the internal time is one way , the other is to make a redundant call to QueryPerformanceCounter() or what have you. This probably gets into the deeper question of "are these classes supposed to have roles that extend a bit beyond just holding time duration?" If nothing else, I ask that making the interface amongst the timers be the same (same ctor style and the typedef so I can write code against either) > > > IMHO, based on the example you gave, you're mixing two separate > problems: how to capture a representation of current time, and how to > present an interface to capture durations of time. I haven't really > examined the Profiler mentioned lately in detail, so maybe you've > actually already dealt with this in the real code. If so, I'd like to > take a look, as I'm working through similar issues myself. If not, I'm > working on something that be useful to you. [Brian Braatz Writes:] Yes, I am mixing many problems. I am building something on top of Profiler (by Chris Diggings) to also do log tracing, and do it multi-threaded- So now I can see the normal profile report, AND I can also turn on DEEP TRACING which will tell me all the calls that occurred and how long they took. (the sample below doesn't show it, but I have need of getting the internal time data and using it to get a sense of "roughly" when 2 threads of execution are near-about each other- it can be a little off and that is fine) Here is some samples of what I have working: (EVENT_BEGIN and EVEN_END define the profiler objects which use RAII to engage and disengage the profile point) (sample code to test the profiler \ logger) class Fname { public: void SetText() { EVENT_BEGIN(Fname,SetText); Sleep(300); EVENT_END(Fname,SetText); } }; class EntryScreen { Fname m_FName; public: void DoSomethingElse() { EVENT_BEGIN(EntryScreen,DoSomethingElse); PROFILE_CHECKPOINT(DataBaseOperation); Sleep(1234); EVENT_END(EntryScreen,DoSomethingElse); } void DoOtherStuff() { EVENT_BEGIN(EntryScreen,DoOtherStuff); Sleep(1432); m_FName.SetText(); EVENT_END(EntryScreen,DoOtherStuff); } }; class MainWindow { EntryScreen r; public: void DoSomething() { EVENT_BEGIN(MainWindow,DoSomething); { r.DoSomethingElse(); r.DoOtherStuff(); } EVENT_END(MainWindow,DoSomething); } }; Test() { MainWindow in; In.DoSomething(); } Here is the profile REPORT: (this is what the Profiler that Mr Diggins started produces) profile total count mean percent CP-DataBaseOperation 1.230334 1 1.230334 16.392611 Fname#SetText 0.312570 1 0.312570 4.164595 MainWindow#DoSomething 2.981596 1 2.981596 39.725903 EntryScreen#DoOtherStuff 1.750382 1 1.750382 23.321574 EntryScreen#DoSomethingElse 1.230537 1 1.230537 16.395316 total entries 5 total time elapsed 7.505420 overall average 1.501084 NOW- here is the LOG DEPTH DATE TIME NAME ELAPSED 1 3/4/2005 17:06:02 MainWindow#DoSomething 2.98135 2 3/4/2005 17:06:02 EntryScreen#DoSomethingElse 1.23054 2 3/4/2005 17:06:03 EntryScreen#DoOtherStuff 1.75038 3 3/4/2005 17:06:05 Fname#SetText 0.312562 NOTE THE DEPTH COL- by reading this I can tell that: MainWindow#DoSomething ran for about 3 seconds total it called doSomethingElse- which ran for 1.2 seconds then DoSomething called DoOtherStuff() which then called SetText (the depth col makes it a tree) LONG TERM GOALS FOR ME: 1- Get this finished in my production app and working to solve some real problems 2- Merge the logging stuff with the profiler library 3- finish the process of getting this ready for boost EXTREMELY LONG TERM GOALS for the profiling library: * Use wave to parse the boost source code- and make a copy of all the code and insert the profling code INTO the boost libraries Then run the unit tests on the mangled code- spitting out performance info * integrate this with unit testing so that boost libraries can now be tested with integrated profiling Would like to see how the different libraries perform on different platforms with different compilers Would like boost to have yet something else the other libraries of the world do not (I love boost and want to help move it along in any way I can figure out) > > Here's some food for thought: > > * interface issues for capturing durations > o consistent, portable representation > o normalized conversion(s) for use in external expressions > (i.e., as double representing seconds) > o support for internal expressions (add, subtract, compare) > o variety of use cases for establishing boundary moments [Brian Braatz Writes:] (snip) I have read this mail several times and have saved it for reference, I am not a timer expert and VERY MUCH appreciate the information THANK YOU. (and yes it sounds like this work would make what I am working on better) > > Hopefully this gives a taste of the complexities surrounding the > seemingly simple task of getting a precise representation of "now". It > can be a very dangerous area to explore for anyone with perfectionistic > tendencies ;) . IMHO this is a classic "can't see the forest for the [Brian Braatz Writes:] Yes, I will be running into more of these as I move forward, I am in the basic stages right now. Fundamentally, I have an app that has some weird performance issues, and I am working on "baking in" logging and performance analysis to help debug these production issues. So my needs are *very much* from the front lines :) > trees" issue (and I've gotten lost in that forest a few times over the > years...). With the myriad possibilities for differing results driven > by the matrix of potential variation, trying to predict just how a > given combination will behave becomes an exasperating challenge. How > can we get past that? Stop trying to predict the results. Go produce > the results instead. Line up all the possible combinations that can > work on a given platform, turn them loose and take notes. Pinning exact > timing on individual moments may always involve a little uncertainty, > but analyzing average trends can lead to deeper insights and justifiable > confidence in the system overall. Some of the issues with > QueryPerformanceCounter(...) may certainly be "real", yet their impact > on the real world of your applications may prove irrelevant with a > little testing. > [Brian Braatz Writes:] I agree :) For the most part- I am LOOKING for things like this- (example) today the application took 30 seconds to perform an operation that should take 10 seconds. So the issues with realtime ARE important for me from a boost sense, but are livable for the production problem I am working on. > > > >MY REQUESTS:... > > > >There you go, those are my requests. Now I will sit here quietly and > >hope there is a Santa Claus.... > > > >(grin) > > > > > So was this less, or more, than you asked for? Although I suppose you'd > rather have it done than have it described. :) Alas, for that you'll > have to be patient, but perhaps not for long. Since I'm in the process > of writing documentation which needed to address high resolution timing > anyway, organizing my thoughts in this response probably helped me more > than it will help you! At least, until the whole package is ready to go > under the tree... > > - james [Brian Braatz Writes:] It was WAY more than I asked for, and thank you for the brain dump and stimulating discussion. :)

1 0

RE: [boost] Re: high_resolution_timer \ timer feature requestsfor Boost.Timer
by Brian Braatz 05 Mar '05

05 Mar '05

I am generally doing the following- Solving my specific problem for my specific application. After I am through with that issue, I will look more at the general issues (as I ended up inheriting the profiler). For my APP- I am logging in hierarchical form the timings-(in addition to the report the profiler already does) so if you have (code is high level and pseudo) FuncB() { PROFILE POINT FUNCTION B { Sleep(1000); // 1 second } } FuncA() { PROFILE POINT FUNCTION B { Sleep(1000); // 1 second FuncB(); } } Then you will have in the profile Report (overall): FuncA took 2 seconds FuncB took 1 second But the Profile LOG (like a trace of what happened) looks like this DEPTH NAME TIME 0 FuncA 2 Seconds 1 FuncB 1 Second Does that answer your question, or am I missing something? > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Goran Mitrovic > Sent: Friday, March 04, 2005 12:21 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: high_resolution_timer \ timer feature requestsfor > Boost.Timer > > How do you intent to deal with nested timers (outer ones might become very > inaccurate because of the inner ones)? > > Also, how do you plan to represent results of such profiling? > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: Adobe Open Source Library
by Sean Parent 05 Mar '05

05 Mar '05

> > Adobe has apparently open sourced some libraries- I (very brief) quick > look shows me: If you read my foreword <http://opensource.adobe.com/asl_foreword.html> you will see I give a great deal of credit to Boost and the libraries do depend on Boost. Although I'm not active on this list (too much traffic for me to track) - I do know many people here and have folks like Mat forward me information of interest. As for the question about the relationship of this work to Mat - ASL is the work of Adobe's Software Technology Lab - the team Mat is on, although Mat isn't working directly on these libraries at the moment - he and Alex Stepanov (another STLab member) are working hard on another project. Certainly they influence mine and Foster's work a great deal. I'd be happy to answer technical questions - either directly or though the ASL forum on SourceForge. Sean

2 1

[Boost-bugs] [ boost-Support Requests-1156957 ] Regex
by SourceForge.net 04 Mar '05

04 Mar '05

Support Requests item #1156957, was opened at 2005-03-04 13:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1156957&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Regex Initial Comment: PROBLEM: ======== If I use the following code: lv_rcode = regcomp(&lr_re, ms_RegExp, REG_EXTENDED); lv_rcode = regexec(&lr_re, &lv_string[0], 1, &pm, 0); to find the following text: cm582172 Using the following regular expression [A-Z]{2}[[:space:]]*[0-9]{6}[[:space:]]* The text if found. However if I use instead the following code boost::regex regx(config.vRegx.at(iCnt).c_str()); flags = boost::match_default; boost::regex_search(start, end, what, regx, flags) With the same regular expression it does not find the string unless I use the following regular expression: [a-z]{2}[[:space:]]*[0-9]{6}[[:space:]]* The difference is the lower case of the alpha range [a-z] My question: Is there a way I can use regexec to be case sensitive for the alpha range like it is with regex_search function? Thanks, Matias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1156957&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

Re: [boost] Re: [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by Iain Hanson 04 Mar '05

04 Mar '05

On Fri, 2005-03-04 at 10:56 -0700, Jonathan Turkanis wrote: > Iain Hanson wrote: > On Thu, 2005-03-03 at 23:21 +0100, JOAQUIN LOPEZ MU?Z wrote: > > > > > personally, I don't like obfuscated code. > > And you think I do? Obviously I wouldn't suggest the macros if I though it made > code harder to understand. > Sorry, I could have phrased that better. I'm afraid I let my strong dislike of macros shoow a little to much. /ikh

1 0

Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by Iain Hanson 04 Mar '05

04 Mar '05

On Thu, 2005-03-03 at 23:21 +0100, JOAQUIN LOPEZ MU?Z wrote: > > ----- Mensaje original ----- > De: Jonathan Turkanis <technews(a)kangaroologic.com> > Fecha: Jueves, Marzo 3, 2005 9:49 pm > Asunto: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > > > > > #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS > > > > private: > > > > template<class Y> friend class shared_ptr; > > template<class Y> friend class weak_ptr; These 4 line of code I can read and understand. > > > > > > BOOST_PRIVATE: > > BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) > > BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) > > And these 2 lines don't mean anything I can grok. personally, I don't like obfuscated code. /ikh

2 1

RE: [boost] Re: Re: Boost.org Site Suggeswtion was [RE: Re:AdobeOpenSourceLibrary]
by Brian Braatz 04 Mar '05

04 Mar '05

Please keep going with this. I think such a page would help a lot with people "selling" the idea of using boost in their enterprise. For the ACE sample for example, it really provides people the ammunition to use ACE in their company. I use boost in my company and sometimes get weird looks from people when you say "open source" - they think in the back of their heads this is some weird hacky thing dreamed up by a 14 year old and does not have commercial value. (though it helps being the Chief Software Architect- I still get weirdness from non-developers) A list of projects which successfully uses boost would help considerably in dealing with the "pencil heads" of the world :) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jeff Garland > Sent: Friday, March 04, 2005 3:41 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: Boost.org Site Suggeswtion was [RE: > Re:AdobeOpenSourceLibrary] > > On Thu, 3 Mar 2005 12:25:30 -0800, Robert Ramey wrote > > There are a couple of reasons a wiki page might not be the best choice. > > > > a) too easily hackable > > b) I very much like the idea of getting some rough statistics. e.g. > > how many people use library x. This presume data with some sort of > simple > > structure. > > Here's a couple thoughts. First off, the need for this was brought up at > OOPSLA. People really like to see a list of users when evaluating if they > are > going to use a new open source tool. This is a very common feature of > open > source projects. So I think we really need to find a way to do this. As an > example: > > http://www.cs.wustl.edu/~schmidt/ACE-users.html > > As for how to gather the information, I think there needs to be 2 phases. > Phase 1 would be a 'logo like' campaign to gather up current users. We > can > use the wiki/mail list and whatever tools we have available to gather the > information. Publish a request on comp.lang.c++, etc. From this, I'll > volunteer to collate the list and create a fixed web page we can > incorporate > into the main Boost web site. > > Phase 2 would be to come up with a way to maintain this. We could use a > wiki > page or perhaps a small web form to gather up information. This might be > a > simple php script that takes the information and updates the wiki or sends > me > email to add the information to the site. Periodically we would gather > these > up and add them in. > > Actually now that I've written it, it seems like designing the form should > be > the first step... > > Jeff > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

best way to make {reverse_}fold a sequence
by Larry Evans 04 Mar '05

04 Mar '05

After creating: typedef range_c<int,0,3> types; typedef fold < types , empty_base , inherit< arg<2>, arg<1> > >::type tuple_type; I'd like to use for_each on tuple_type. For example: struct print_integral_c { template<int i, typename Right> void operator()(inherit<integral_c<int,i>, Right>)const { std::cout<<i<<"\n"; } }; for_each<tuple_type>(print_integral_c); However, tuple_type is not a sequence; hence, for_each won't work. I could define the necessary specializations for mpl::begin, etc., to make it a sequence, but I was wondering if there's any way or any plans to somehow automagically make fold or reverse_fold into a sequence so I could use for_each on it.

2 14

RE: [boost] Re: Boost.org Site Suggeswtion was [RE: Re: Adobe OpenSourceLibrary]
by Brian Braatz 04 Mar '05

04 Mar '05

> -----Original Message----- > On Behalf Of Thomas Matelich > OpenSourceLibrary] > > Sounds like a wiki page to me. > > > On Thu, 3 Mar 2005 08:29:17 -0800, Robert Ramey <ramey(a)rrsd.com> wrote: > > I would like to see this idea taken a little bit further. > > > > I would like a place where users of boost can add a line describing: > > > > name > > organization > > application > > which libraries they use > > general comments. > > > > This would be very helpful feedback as to what is getting used by whom > for > > what purpose. It would be useful to library authors to get a sense of > what > > is being used. It would be very useful to people who are considering > > downloading boost and want to know what parts have been found useful to > > other people. > > > > Think of it as "boost" marketing. > > > > Robert Ramey > > [Brian Braatz Writes:] I propose if it becomes a wiki- that there is a LINK to it on the MAIN page

7 7

[Threads] error notification (joining an already exited thread in Windows debug builds)
by Kevin Wheatley 04 Mar '05

04 Mar '05

Hi, using a thread_group, I have an application that runs something like this: thread_group myThreads; for each thread we need myThreads.create_thread(reference to thread function) for each work item { add work item to queue // threads just created start doing the work... } add 'finish' task to queue myThreads.join_all() delete threads... etc etc When running under windows debug build I noticed that the join on the individual threads in the group can fail the assertion: assert(res == WAIT_OBJECT_0); But rather unhelpfully it doesn't include the error code returned by the call or GetLastError() as to why ! In my case I belive this is because the thread has already exited before joining or something similar. now the question would be of course what to do if an error occurs during a non-debug build as the assert will not be there most likely and I'd never notice any problems as the reult is discarded. Thread join could return something rather then being void, that the thread group could then pass back, but then what if the failure occurs half way through the thread group? Should it return a list of error indicators? e.g. thread is not joinable, thread id is invalid, deadlock detected (POSIX optional), or should this be a 'checked_join_all()' (join_all_checked() ?) Is there any work going on that might addrss these concerns? (I checked the CVS branches but didn't find anything obvious) Thanks Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |

1 0

[Boost-bugs] [ boost-Support Requests-1156682 ] problem building on linux
by SourceForge.net 04 Mar '05

04 Mar '05

Support Requests item #1156682, was opened at 2005-03-04 06:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1156682&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: problem building on linux Initial Comment: I tried to build boost under my own user and in a tree that I own. I used : bjam "sTOOLS=gcc" -prefix=/nfs/us13/sverker/c++/boost/install/ install First it said #skipping phyton..." which is ok with me. Then I get : --------------------------------------------------------------------- don't know how to make sTOOLS=gcc don't know how to make -prefix=/nfs/us13/sverker/c++/boost/install/ ...patience... ...found 10593 targets... ...updating 3329 targets... ...can't find 2 targets... Then I get many complaints that it cannot write in /usr/local.. And finaly : ...failed updating 111 targets... ...skipped 3218 targets... ...updated 851 targets... /nfs/us13/sverker/c++/boost/install/ is empty. Do I always have ro run under root? Why do I get these two "dont know how to ..."? Yours Sverker Almehed Lund Sweden ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1156682&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

Joint view and make_variant_over
by Richard Peters 04 Mar '05

04 Mar '05

Hello, I encountered a problem using a sequence obtained by mpl::joint_view with make_variant_over. While I can make a variant over a sequence of types, I can't make the variant over two typesequences joined together with joint_view. I am really new with mpl, so I might just have done something really wrong. The program is below, the line commented out produces lots of errors when uncommented. Is this a problem in either the variant or the mpl library, or did I just do something wrong? thanks, Richard Peters #include <boost/mpl/vector.hpp> #include <boost/mpl/joint_view.hpp> #include <boost/variant.hpp> namespace mpl { using namespace boost::mpl; } struct a {}; struct b {}; int main() { typedef mpl::vector<a> list1; typedef mpl::vector<b> list2; typedef mpl::joint_view<list1, list2>::type joint_list; typedef boost::make_variant_over<list1>::type variant_type1; typedef boost::make_variant_over<joint_list>::type variant_type2; a x; variant_type1 y(x); //variant_type2 z(x); // doesn't compile }

1 0

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

04 Mar '05

On Fri, 2005-03-04 at 10:27 +0100, Johan Nilsson wrote: > "Pavel Vozenilek" <pavel_vozenilek(a)hotmail.com> wrote in message > news:d07hih$veg$1@sea.gmane.org... > > > > H. S. Lahman list available options and argues that passing > > anything else than values is dangerous and causes high coupling: > > http://groups.google.ca/groups?selm=3B86C364.AB1A6066%40worldnet.att.net > > (the paragraphs starting with "pure message"). > > > [snip] > If you use well-defined interfaces I can't see how that would cause any > higher coupling than during normal circumstances (remoting aside). A pretty > common usage would be implementing the Observer pattern cross-process. > Technically it does cause higher coupling. Both sides now know something about each other. But it is really a rather academic point. /ikh

1 0

Re: [boost] Re: Running regression tests
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

----- Mensaje original ----- De: Jody Hagins <jody-boost-011304(a)atdesk.com> Fecha: Jueves, Marzo 3, 2005 7:04 pm Asunto: Re: [boost] Re: Running regression tests > > Boy, do I feel stupid. I missed errors in the bjam.log file. It > lookslike there was a problem generating bjam.log (but since > stderr was > redirected to the file, it was not obvious). Anyway, I think that is > the problem, but I have no clue as to how it should be fixed. It > lookslike a problem with some Jamfile... > > > Anyone got an idea? > > > > boost-test(RUN) "multi_index/test_range" : Jody, are you trying to run the tests for multi_index in BCB6? This lib is not supposed to work for BCB... Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

More reviewers wanted: FSM review extended until Mar 6th
by Pavel Vozenilek 04 Mar '05

04 Mar '05

Review of Boost.FSM library was extended by one week, until March 6th. Reviews, even short opinions on this library are much welcomed. I'll encourage public by quoting Darryl Green: ------ quote ----------- I have seen substantial reductions in code complexity arise out of using the fsm libary in a refactoring of some existing code. The result is also much easier to modify/maintain. This last point is particularly important if the fsm is not well specified to start with and/or may need to be modified in reaction to changes in requirements. Using boost fsm an iterative/exploratory design approach works fine. In many ways this is less painful than if there were a code generator. ------- end quote ------ So now is your chance to recommend this tool into Boost (or pin-point problems or suggest alternatives). /Pavel ========================================== Original review announcement: Review of Finite State Machine library written by Andreas Huber starts today, February 21. The library can be found at: http://boost-sandbox.sf.net/fsm.zip (781 kB). FSM is feature rich library to design finite state machines without need for external generator. It is accompanied by extensive documentation. Here are some questions you might want to answer in your review: * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? * 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? * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every reviewer should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Pavel Vozenilek FSM review manager

5 5

Singleton is documented!
by Jason Hise 04 Mar '05

04 Mar '05

The singleton library is finally documented! A complete tutorial in using the library along with an extensive reference section are provided. A tutorial on extending the library is forth-coming. The new zip is available in the <a href="http://boost-sandbox.sourceforge.net/vault/">sandbox</a> under the singleton folder, and should be extracted into the boost root directory. As always, suggestions are welcome. -Jason

6 17

Looking for some WINDOWS help
by Jody Hagins 04 Mar '05

04 Mar '05

Whenever I get a spare moment, I try to get my typeid/type_info tests working on windows (I am convinced that if I had started programming under that environment, I would have chosen a different line of work). Right now I am struggling a bit with the DLL library that is part of testing type_info. Everything works fine, except when it doesn't ;-> The documentation of LoadLibrary() says it returns NULL on failure. However, I can feed it some files (like a valid .LIB that is not a DLL) and before LoadLibrary() returns, it displays a dialog box saying "Bad Image." I guess this could be an exception that BCB is intercepting and turning into a dialog box, but the docs say nothing about an exception. Also, I look on google, and find that people have similar problems from within Java (though I could not find any solutions). How do I prevent that from happening? Thanks in advance!

2 1

Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Viernes, Marzo 4, 2005 0:32 am Asunto: Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > Jonathan Turkanis wrote: > > Hi, > > > > <boost/shared_ptr.hpp> contains the following in the public section > > of the class definition (reformatted): > > > > // Tasteless as this may seem, making all members public > > // allows member templates to work in the absence of member > > // template friends. (Matthew Langston) > > > > #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS > > > > private: > > > > template<class Y> friend class shared_ptr; > > template<class Y> friend class weak_ptr; > > > > > > #endif > > > > T * px; // contained pointer > > detail::shared_count pn; // reference counter > > > > This has become a pretty common technique, I believe. I > certainly use > > it a lot, at any rate. > > > > I'd like to suggest two macros which would allow code like the above > > to be simplified as follows: > > > > BOOST_PRIVATE: > > BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) > > BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) > > > > T * px; // contained pointer > > detail::shared_count pn; // reference counter > > This doesn't look any better to me than the original, sorry. ;-) Well, I think there are situations were it'd improve readability: Example 1: previous section was not public #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #else public: #endif Example 2: derivation class Derived: #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private else public #endif Base { ... }; Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[mpl-docs] portability trap
by Tobias Schwinger 04 Mar '05

04 Mar '05

Hi, This code: #include <boost/mpl/vector.hpp> #include <boost/mpl/pop_front.hpp> #include <boost/mpl/assert.hpp> #include <boost/mpl/equal.hpp> using namespace boost; // Doc says: pop_front returns a vector typedef mpl::pop_front< mpl::vector<bool,char,int> >::type v; // Doc says: vectors have a type member equal to itself BOOST_MPL_ASSERT(( mpl::equal< v, v::type > )); fails to compile with GCC ( v::type is mpl::vector3<bool,char,int> ) and compiles fine with other compilers. Examples for false conclusions that could be easily drawn from the current documentation: "Oh great - I do not need mpl::identity when using v with mpl::eval_if" "Let's inherit from 'v::type' so I can save the '::type' later" "::type always gives the numbered form of my current sequence so I can use it with partial specialization" I got trapped by this in two different places (and I still hope not to be surpassingly stupid ;-). Shouldn't this behaviour be documented in some way ? Regards, Tobias

2 2

Re: [boost] Looking for some WINDOWS help
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

----- Mensaje original ----- De: Jody Hagins <jody-boost-011304(a)atdesk.com> Fecha: Viernes, Marzo 4, 2005 0:37 am Asunto: [boost] Looking for some WINDOWS help > > Whenever I get a spare moment, I try to get my typeid/type_info tests > working on windows (I am convinced that if I had started programming > under that environment, I would have chosen a different line of > work). > Right now I am struggling a bit with the DLL library that is part of > testing type_info. Everything works fine, except when it doesn't > ;-> > > The documentation of LoadLibrary() says it returns NULL on > failure. > However, I can feed it some files (like a valid .LIB that is not a > DLL)and before LoadLibrary() returns, it displays a dialog box > saying "Bad > Image." I guess this could be an exception that BCB is > intercepting and > turning into a dialog box, but the docs say nothing about an > exception. > Also, I look on google, and find that people have similar problems > fromwithin Java (though I could not find any solutions). > > How do I prevent that from happening? > With SetErrorMode, I think. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Re: [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

Hi Jonathan! ----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Viernes, Marzo 4, 2005 0:08 am Asunto: [boost] Re: [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > JOAQUIN LOPEZ MU?Z wrote: [...] > > The macros I'm using are: > > > BOOST_PRIVATE_IF_MEMBER_TEMPLATE_FRIENDS > > BOOST_PROTECTED_IF_MEMBER_TEMPLATE_FRIENDS > > These would be okay with me. But sometimes I use a macro for > specifying the type > of derivation, and > > struct derived_class > : BOOST_PRIVATE_IF_MEMBER_TEMPLATE_FRIENDS base_class > { }; > > seems a bit long. Yep it is long, but BOOST_PRIVATE covers too much semantic scape: what if in the future a similar workaround is needed to make up for another, unrelated defficiency? This is not hypothetical, in fact I'm already using BOOST_MULTI_INDEX_PRIVATE_IF_USING_DECL_FOR_TEMPL_FUNCTIONS that does the same thing (turning private into public) in some compilers that do not support in-class using declarations for template functions. Admittedly, it'd be nicer if we can come up with a shorter, yet descriptive name. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: OT: Jonathan, weren't you going to promote a scopeguard impl to boost/detail? I'm waiting for that so that I can reduce my own codebase :)

2 1

[congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE [repost]
by Jonathan Turkanis 03 Mar '05

03 Mar '05

[I'm reposting this because I misspelled 'config' in the subject line] Hi, <boost/shared_ptr.hpp> contains the following in the public section of the class definition (reformatted): // Tasteless as this may seem, making all members public // allows member templates to work in the absence of member // template friends. (Matthew Langston) #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #endif T * px; // contained pointer detail::shared_count pn; // reference counter This has become a pretty common technique, I believe. I certainly use it a lot, at any rate. I'd like to suggest two macros which would allow code like the above to be simplified as follows: BOOST_PRIVATE: BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) T * px; // contained pointer detail::shared_count pn; // reference counter Here BOOST_PRIVATE would expand to "private" for compilers that support template friends and to "public" otherwise; BOOST_BEFRIEND_TEMPLATE would expand to a template friend declaration where supported, and to nothing otherwise. It might be desirable to have two macros BOOST_BEFRIEND_TEMPLATE_CLASS and BOOST_BEFRIEND_TEMPLATE_STRUCT to avoid compiler warnings. Jonathan

1 1

[config] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE [repost][repost]
by Jonathan Turkanis 03 Mar '05

03 Mar '05

Hi, <boost/shared_ptr.hpp> contains the following in the public section of the class definition (reformatted): // Tasteless as this may seem, making all members public // allows member templates to work in the absence of member // template friends. (Matthew Langston) #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #endif T * px; // contained pointer detail::shared_count pn; // reference counter This has become a pretty common technique, I believe. I certainly use it a lot, at any rate. I'd like to suggest two macros which would allow code like the above to be simplified as follows: BOOST_PRIVATE: BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) T * px; // contained pointer detail::shared_count pn; // reference counter Here BOOST_PRIVATE would expand to "private" for compilers that support template friends and to "public" otherwise; BOOST_BEFRIEND_TEMPLATE would expand to a template friend declaration where supported, and to nothing otherwise. It might be desirable to have two macros BOOST_BEFRIEND_TEMPLATE_CLASS and BOOST_BEFRIEND_TEMPLATE_STRUCT to avoid compiler warnings. Jonathan

1 0

Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by JOAQUIN LOPEZ MU?Z 03 Mar '05

03 Mar '05

----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Jueves, Marzo 3, 2005 9:49 pm Asunto: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > Hi, > > <boost/shared_ptr.hpp> contains the following in the public > section of the class > definition (reformatted): > > // Tasteless as this may seem, making all members public > // allows member templates to work in the absence of member > // template friends. (Matthew Langston) > > #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS > > private: > > template<class Y> friend class shared_ptr; > template<class Y> friend class weak_ptr; > > > #endif > > T * px; // contained pointer > detail::shared_count pn; // reference counter > > This has become a pretty common technique, I believe. I certainly > use it a lot, > at any rate. FWIW, I've also been forced to use a similar workaround. > > I'd like to suggest two macros which would allow code like the > above to be > simplified as follows: > > BOOST_PRIVATE: > BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) > BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) > > T * px; // contained pointer > detail::shared_count pn; // reference counter > BOOST_PRIVATE seems a little to uninformative a name to me. The macros I'm using are: BOOST_PRIVATE_IF_MEMBER_TEMPLATE_FRIENDS BOOST_PROTECTED_IF_MEMBER_TEMPLATE_FRIENDS (well, I'm using lib-specific variations of these names, but you get the idea.) As for your proposal, I like it: there are at least three libraries that would benefit from it. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

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

03 Mar '05

On Thu, 2005-03-03 at 13:54 +0000, Jarl Lindrud wrote: > Iain Hanson <Iain.Hanson <at> videonetworks.com> writes: > > > > > So anything less than CORBA should not be considered? For RPC, Yes. > > My experience with CORBA is that you _do_ pay for things you don't need. Try > building a simple server/client app with my RPC library, and then build it with > ACE TAO, and I wonder which method you'll find to be simpler/easier/faster... Here is an example CORBA client. And it doen not matter which ORB you use. #include <iostream> #include "echoC.hpp" // generated from the idl file int main ( int ArgV , char * ArgV ) { try { // _var types are smart ptrs to ref counted objects. CORBA::ORB_var Orb = CORBA::ORB_init ( ArgC , ArgV , "TAO"); // get IOR from a file so we can talk to server CORBA::Object_var Factory_Object = Orb->string_to_object ( ArgV [ 1 ] ); // This is a CORBA safe downcast My::Echo_Factory_var Factory = My::Echo_Factory::_narrow ( Factory_Object.in( ) ); My::Echo_Server_var EchoServer = Factory->get_server ( ArgV [ 2 ] ); CORBA::String_var Echoed = EchoServer-> ( "Hello World" ); } catch ( CORBA::Exception & E ) { std::cerr << "CORBA exception raised!" << std::endl; } } I don't think 5 lines of code is exactly heavyweight. I could of done it in 3 lines if I did not use a factory, but that would have been unrealistic. I won't show the server but it 2 classes the factory publicly inherits from Echo_Factory and implements a single function get_server. Likewise like for EchoServer. > Which code is less invasive, more intuitive, and more proportional to the task? > And oh I forgot, don't forget to first build all of ACE and TAO, and then link > the whole shebang to your own 5 lines of code. To me it feels like I'm getting > far, far more than I asked for. But that's just me :-) ACE is nothing to do with CORBA. It just happens to be what TAO uses internally. Building Open source or installing per build libs has nothing to do with how easy it is to use. Your comparing apples and carrots. >If you need scaleability, then obviously CORBA is one of the few >options you have. But if you don't need scaleability, or naming >services, or whatever, what's wrong with using something much simpler? Because when you app grows you will have to re-write it. More likely, is that won't happen and people will re-invent the again. Take a look at the development of SOAP :-(. /ikh

2 1

regexes matching empty strings
by Michael Goldshteyn 03 Mar '05

03 Mar '05

Why can I not construct a regex of the form: "|abc" (throws exception based on REG_EMPTY) for use with regex_match, if I want to match either "abc" or the empty string "". I understand thatn in a regex_search the empty string would always match (per Perl like semantics), and abc would never be considered. But, I want to use this with regex_match, where the empty string would have to match the entire string being searched. Work arounds such as "(?:)|abc" and "^$|abc" seem to get around this deficiency, but I am wondering why it is there in the first place. Thanks, Michael Goldshteyn

2 3

One more test message. Please delete it
by Pavel Chikulaev 03 Mar '05

03 Mar '05

Ok?

1 0

Running regression tests
by Jody Hagins 03 Mar '05

03 Mar '05

Trying to run the regression tests for BCB6/Windows, using current CVS head... set BOOST_ROOT=C:\boost set TOOLS=borland I can run bjam stage and everything that is supposed to build, builds (serialization, and wave do not build). However, when I follow the directions, I have problems. Can someone please help?!? I tried cd up into boost root, and it seemed to work better, but links in the html files wanted to access directories ".." so that failed too. What am I doing wrong? Thanks! C:\boost>cd status C:\boost\status>bjam --dump-tests test >bjam.log 2>&1 C:\boost\status>echo %BOOST_ROOT% C:\boost C:\boost\status>echo %TOOLS% borland C:\boost\status>process_jam_log < bjam.log Usage: bjam [bjam-args] | process_jam_log [--echo] [--create-directories] [locat e-root] locate-root - the same as the bjam ALL_LOCATE_TARGET parameter, if any. Default is boost-root. create-directories - if the directory for xml file doesn't exists - creates it. usually used for processing logfile on different machine boost_root: C:/boost/status/.. locate_root: C:/boost/status/.. no errors detected C:\boost\status>compiler_status %BOOST_ROOT% cs-win32.html **** exception(205): std::exception: boost::filesystem::directory_iterator const ructor: "C:\boost\status\bin": The system cannot find the path specified. ******** errors detected; see standard output for details ******** C:\boost\status>compiler_status Usage: compiler_status [options...] boost-root status-file [links-file] boost-root is the path to the boost tree root directory. status-file and links-file are paths to the output files. Must be run from directory containing Jamfile options: --compiler name Run for named compiler only --ignore-pass Do not report tests which pass all compilers --no-warn Warnings not reported if test passes --locate-root path Path to ALL_LOCATE_TARGET for bjam; default boost-root. --comment path Path to file containing HTML to be copied into status-file. --notes path Path to file containing HTML to be copied into status-file. --notes-map path Path to file of toolset/test,n lines, where n is number of note bookmark in --notes file. --jamfile path Path to Jamfile. By default "Jamfile". Example: compiler_status --compiler gcc /boost-root cs.html cs-links.html Note: Only the leaf of the links-file path and --notes file string are used in status-file HTML links. Thus for browsing, status-file, links-file, and --notes file must all be in the same directory. **** error return code: 1 ******** errors detected; see standard output for details ******** C:\boost\status>

3 10

Test. Please delete this thread
by Pavel Chikulaev 03 Mar '05

03 Mar '05

I just couldn't have get access to developers list

1 0

Preview of the Function Types library (function_traits replacement)
by Tobias Schwinger 03 Mar '05

03 Mar '05

Dear Boosters, a preview of the Function Types library is available, now. [ Online documentation: http://tinyurl.com/4fw9n ] [ Downloadable archive: http://tinyurl.com/6u77y ] It is the third (nearly) complete rewrite and the design finally feels right for me. However, I am very curious to hear any of your opinions about it ! So, if you have been hoping for the retirement of function_traits, please take a few minutes to find out if this would suit your needs. Regards, Tobias

3 19

patch against boost threads library
by Ulrich Eckhardt 03 Mar '05

03 Mar '05

Short notes: * thread_exception::message() is broken beyond repair, as it returns a pointer to local storage (via std::string::c_str()) * any program using it is broken, too. * it is unused by boost itself(!) which is why it can be removed * it is the only reason why a helper-function 'system_message()' is needed, which can then be removed, too. * system_message() is the only reason several headers and a hack for strerror() were needed, which can then also be removed. * system_message() requires a char-based API on win32, which is not available under MS Windows CE, strerror() is also not available there, making two more reasons to remove it. cheers Uli

3 4

[range] BOOST_RANGE_DEDUCED_TYPENAME
by Jody Hagins 03 Mar '05

03 Mar '05

In range/config.hpp, I see this code... #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) #define BOOST_RANGE_DEDUCED_TYPENAME #else #define BOOST_RANGE_DEDUCED_TYPENAME BOOST_DEDUCED_TYPENAME #endif Why is there a special version of this? It is only defined to empty, or BOOST_DEDUCED_TYPENAME. What is wrong with simply using BOOST_DEDUCED_TYPENAME? If there is a problem with the "stock" one? If so, shouldn't that be changed instead?

3 2

Preprocessor warning from BOOST_PP_SEQ_ELEM
by Edward Bishop 03 Mar '05

03 Mar '05

Hi All, When I run the following code through the preprocessor, it emits the correct output: alpha is simple; beta is simple; gamma is complex and color is red; delta is simple; epsilon is complex ; but it also emits the folowing warning (several times): macro "BOOST_PP_SEQ_ELEM_III" requires 2 arguments, but only 1 given My question is, how can I eliminate the warning. Thanks in advance for any comments/advice. # include <boost/preprocessor/library.hpp> #define IS_SIMPLE(t) BOOST_PP_NOT_EQUAL(3, BOOST_PP_SEQ_SIZE(t)) #define PROPERTIES(t) BOOST_PP_SEQ_ELEM(2,t) #define HAS_COLOR(t) BOOST_PP_EQUAL(2, BOOST_PP_SEQ_ELEM(0, \ PROPERTIES(t))) #define COLOR(t) BOOST_PP_SEQ_ELEM(1, PROPERTIES(t)) #define FSIMPLE(a, s, i, t) \ BOOST_PP_SEQ_ELEM(0,t) is simple; #define FCOMPLEX(a, s, i, t) \ BOOST_PP_SEQ_ELEM(0,t) is complex \ BOOST_PP_IF(HAS_COLOR(t), and color is COLOR(t) , ); #define FCHOICE(a, s, i, t) \ BOOST_PP_IF(IS_SIMPLE(t), \ FSIMPLE(a, s, i, t), \ FCOMPLEX(a, s, i, t)) #define T(s)\ BOOST_PP_SEQ_FOR_EACH_I(FCHOICE, s, s) \ T ( // ID Frequency Properties ( (alpha) (16) ) ( (beta) (3) ) ( (gamma) (13) ((2) (red)) ) ( (delta) (5) ) ( (epsilon) (13) ((4) (heavy)) ) )

3 7

Re: [boost] Re: ANN: review of FSM library starts
by Augustus Saunders 03 Mar '05

03 Mar '05

First, I appologize for messing up the threading, but I get the digest and so can't respond directly. >Have you ever had a look at other FSM libraries? I think boost::fsm >is less messy than any other library I've seen. Unfortunately, no. My response is based on the fact that 1) I generally think I know what fsm are about, 2) I'm comfortable seeing complex template stuff, yet 3) sample code for simple state machines just didn't click for me. I feel like I'm in the target audience of the library, so I'm looking deeper to see if I can figure out why. >> // I guess there's no way to avoid declaring >> // these ahead of time?? >> class Machine, State1, State2, Event1, Event2; >Actually there is, but I found out about this only recently (Peter > Dimov mentioned this in an unrelated post) and haven't changed the > docs because I feared that this does not work on all compilers: > >Instead of > >struct Greeting; >struct Machine : fsm::state_machine< Machine, Greeting > {}; > >you can write: > >struct Machine : fsm::state_machine< Machine, struct Greeting > {}; Ok, good to know. I'd like to hash out what the "ideal world" would look like and compromise from there, if you know what I mean. >> struct S1Data >> { >> int i; >> S1Data() : i(0) {} >> }; >> >> typedef simple_state< Machine, S1Data, >> BOOST_TYPEOF( cout << constant("Entering State1.") ), >> BOOST_TYPEOF( cout << constant("Exiting State1.") ), >> on_event<Event1, BOOST_TYPEOF( _1->i++ ) >, >> transition<Event1, State2> > >> State1; >> // the "data" member of State1 has type S1Data, and is >> // passed into event handlers >You consider this more readable? Sorry, I have to disagree. For entry > and exit actions and extended state variables I consider my approach > superior, for reaction definition, your approach seems about > equivalent. I think this is how my example would look using the current library, right? struct State1 : simple_state< State1, Machine, custom_reaction< Event1 >, transition< Event1, struct State2 > > { int i; State1() : i(0) { cout << "Entering State1."; } ~State1() { cout << "Exiting State1."; } result react( const Event1 & ) { i++; } }; That's actually not so bad. I've defined both a reaction and a transition on the same event; not sure if you're supposed to do that. Now I'm wondering if there's a way with mpl to determine if a class has a function with a certain signature. Can you eliminate the need for "custom_reaction< Event1 >" and just test whether or not the class implements "result react( const Event1 & )" ? If you could somehow hide the CRT mechanism, and specify children instead of parents, maybe you could boil down to something like so: DEFINE_STATE(State1, transition< Event1, struct State2 >) { int i; State1() : i(0) { cout << "Entering State1."; } ~State1() { cout << "Exiting State1."; } result react( const Event1 & ) { i++; } }; And I think that's about as obvious as you can make it. But that may just be wishful thinking. >I don't understand, you do define states top-down in boost::fsm. Maybe I'm confused, but as best as I can tell, you specify parents instead of specifying children. So, if StateX has StateY and StateZ as inner states, instead of saying StateX : StateY + StateZ, you say StateY -> StateX; StateZ -> StateX. >> it's my impression that with mpl one can iterate >> through the template arguments and figure out if they are events or >> transitions or whatever. So I smushed together the different >One sure can but that would duplicate mpl::list<> functionality to a > certain degree. For "real-world" uses, this seems unimportant. However, for the tutorial and basic examples, I think it would be a good idea if you can silently ignore mpl. Of course those examples should compile and work... I don't have a feel for whether I'm asking for a mountain or a molehill here, so I'll let it be. >Given that the approach you outlined above really works, I think you > can use lambda for transitions without changing a single line of > boost::fsm, you simply define your own reaction that accepts > typeofed lambda expressions instead of function pointers for > transition actions. I'm not so sure whether the same is possible > with entry/exit actions but I'm inclined to think that it > is (that would require deriving your own state class template from > simple_state). I think it would be nice to have a mechanism that accepts lambdas, though I'll concede it is better to avoid it for "average joe" programmer. But since fsm is compile time, an advanced user might use another library/technique to programmatically generate the code she wants as a lambda type. It's always seemed that lambda had great potential as a compile time code generator, and fsm is a place where one might concievably stick it. >Most people get used to the syntax >of boost::fsm quite quickly. Also, I've received feedback that people > really like the fact that they can easily put the bodies of complex > actions in cpp files, I *guess* that would be a little more > difficult with your approach. Now I'm thinking that maybe a macro or two added to what you've got, just to hide some of the machinery, is all that it would take to get what I'm looking for. I'll grant you that I'm struggling to come up with what I think is "ideal." My main goal is boost::fsm using code should be reasonably "guessable" by an educated reader in short order. Basically, my coworkers should be able to look at my code and mostly be able to guess what was going on. [snip] > I'd say it takes one day tops of playing around with boost::fsm to > learn this. My concern is intimidating potential new users more than necessary. Like I said initially, I might have missed a ton of discussion about this from before. If you can point me to a thread where interface issues were hashed out in great detail already, I'll take a look. > I did consider using named template parameters, but > rejected it because it would add to the amount of text you have to > write and would offer a benefit only for beginners. Me, I would probably cater a little more to the beginners, since I think getting more people to use FSM than previously would have to be a good thing. >> tutorial just made my head spin, especially trying to figure out >> how states and machines get tied together (this is still unclear to >> me). > I guess you mean how the implementation ties them toghether? As a > user, why do you need to know that? When I first looked at the sample code, I was hunting high and low, thinking to myself, "Where on earth does it specify which states belong to which?" >As I already mentioned in another post: Targetting every C++ > developer would require an *additional* document at least as thick > as the current tutorial. I think it is reasonable to expect previous > exposure to FSMs. Yes, I do not suggest writing your own guide to FSMs. >> In general, I would drop all mention of UML except for some >> appendix somewhere (and the reference manual too). > >Why? I think it's a distraction. Sure, it's great that you've got this nice correspondance with UML, but that's unimportant *in the tutorial*. Mention it on the about page, have an appendix all about it, go into detail in the references, etc. >> "Getting Started" and >> "Target Audience" should be in a differenct document, and > >Please make a suggestion. Probably just in index.html. >> "How to read this tutorial" should be removed. > >Why? To me, is unnecessary verbiage. It doesn't say anything important. Perhaps you need better headings in the TOC. The ToC is currently broken up by the name of the example; perhaps rather than "StopWatch," say "Simple Finite State Machines - A StopWatch example." >> In general, all of your "remarks" and "comments" need to be in the >> code! > >You're the second person to request that. I personally think it is > better to not clutter code with too many comments. If people think > it is better to have all comments in the code, I'll sure change it. Having it in the code, both in the tutorial and in the example files, would help a lot, IMO. Especially the example files. If you could give me a better overview of the process and hold my hand better about which template parameters are which, I think I would have been much less confused. >> I think the example state machines are basically OK, but I >> think that it is absolutely essential that you include a simple >> example that is alphabet-based. In fact, some helper functions for >> alphabet-based languages are probably a good idea, just to make the >> tutorial easier. > >Why? Well, maybe this isn't the norm, but I was taught FSMs using alphabets-as-events. One of the first things *I* would do with the library is try and implement some examples out of my old college text. I figured most people were taught this way, and so having an example with that would help connect with something familiar. >You mean the mapping between the pressed key and the generated event? > Why? I think it's probably a common thing to want to test your state machine by triggering events from the keyboard in a console app. >> I'm confused about why entering/exiting states causes construction/ >> destruction. It's taken as a given, > >It is not: http://tinyurl.com/5mjra (State-local storage) That's explaining why you offer state-local storage, which I have no qualms with. It doesn't explain why you use the constructor/destructor mechanism, it's just stated that's the way it is. >> but I would tend to assume that >> state-local-storage is maintained throughout unless I explicitly >> reset it. > >Why? Ok, I think I figured something out since I wrote this. You're relying on nesting states to maint data. I think this needs to be explained in big neon signs. I don't think of exiting a state as destroying it, just that it's no longer "active" or whatever. Your model is like a window manager that closes a window every time a different window gets the focus and reopens the first window upon return. Of course, having lost all data imbetween. Maybe hoisting your data up to an enclosing space is a good idea, but I'm not used to working with nested states, so I don't really think that way. I'm willing to be convinced, although I'm suspicious. >> I'm also surprised by the lack of "accept" states. Maybe >> it's not universal, but my theory certainly had them, and it's just >> disconcerting for them not to be there. > >I don't know what accept states are. UML doesn't have them. Now, I'm in no way an academic, so I'm relying on Wikipedia to tell me what's "normal." Since it's in line with my old textbook, I guess it's reasonably standard. Wikipedia tells me that there "acceptor" and "transducer" finite state machines. I've not worked with the "transducer" variety before; my text deals with them only in the exercises. At any rate, with an "acceptor" FSM, if after processing all input you are in an "accept" state, the input was legal, the operation was successful, whatever. Otherwise there was an error. Not that everybody will use them, but it would be nice to be able to mark states as accept-states and ask the machine if the current state is an accept-state. I would certainly recommend adding http://en.wikipedia.org/wiki/Finite_state_machine to your list of links about FSMs. Cheers- Augustus __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

3 3