- Boost - lists.boost.org

RE: [boost] Re: [Threads] Simple active object wrapper, take 2
by Hurd, Matthew 24 Feb '04

24 Feb '04

> On Behalf Of Matthew Vogt > Subject: [boost] Re: [Threads] Simple active object wrapper, take 2 > > > scott <scottw <at> qbik.com> writes: > Had a little thought that might be relevant. Please spank me if this is OT given the rather specific implementation I'm dropping in on... As mentioned previously, future values could give you a lazy way of evaluating the result, even when you aren't multithreaded. In the truly "active" object, that is, it has at least one thread, you could call the methods with a future instead of a normal value so that when the result arrives it percolates through the implied queue. Now for a new thought. What about using an expression template mechanism so that when you combine futures they are glommed at compile time to remain lazy? boost::future<double> sum = some_thing_maybe_active.total(); boost::future<double> count = some_thing_maybe_active.count(); boost::future<double> average = sum / count; sum / count forms a lazy expression if a method groks a future and then this becomes interesting... boost::future<double> result = some_thing_maybe_active.do_stuff(average); You can end up with the active object percolating all the way through to "result" without any blocking until the result of "result" is used. If you get rid of the thread(s) in the active object idea, you end up with a mechanism for lazy evaluation. Perhaps there is a more general mechanism / pattern and bike shop name lurking in this pattern... Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

RE: [boost] Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 24 Feb '04

24 Feb '04

> From: David Abrahams [mailto:dave@boost-consulting.com] > Hey! These implementations using "advance" don't work for > non-iterators (e.g. int) the way regular next() and prior() do. I > consider this a bug! Are there really use cases where implementations should work seamlessly for both non-iterators and iterators? Or are there (common) non-iterator types that share the iterators' "operator++() but not operator+()" issue? I understand the problem that next/prior solves for iterators, but when dealing with numeric types, I'm thinking there's always binary +/- operators available. Bjorn

2 1

[format]: c_str() function
by Pavel Vozenilek 23 Feb '04

23 Feb '04

Would it be possible to add function c_str() into format interface? It would return const char/wchar_t* to internal string buffer. Use cases for such function: 1. void foo(const char*) { ...} format f("...") f % ... foo(f.c_str()); This is shorter and faster than foo(f.str().c_str()); No temporary gets created. 2. // class used to accept any string type struct parm_string { parm_string(const char* s) : str_(s) {} parm_string(const std::string& s) : str_(s.c_str()) {} const char* str_; }; void foo(parm_string) { ... } format f("...") f % ... // ERROR - pointer to deleted temporary gets used inside foo() foo(f.str()); foo(f.c_str()); // would be OK /Pavel

2 2

[indexed_set] Release 9.1
by Joaquín Mª López Muñoz 23 Feb '04

23 Feb '04

Release 9.1 available at: http://groups.yahoo.com/group/boost/files/indexed_set.zip The sandbox version is also updated, but the ViewCVS tool has some delay and changes are not visible yet. Minor changes in the code and a big overhaul of the docs. I've rewritten a major portion of the documentation, and now the reference reflects the existence of sequenced indices as well as prior, regular indices. I'd very much appreciate if proofreaders can indicate on the understandability of the reference (things are a little more abstract now.) The tutorial, which is the only part left to rewrite to accommodate new sequenced index types, remains untouched as of now. Again, if some kind soul with skills at writing English volunteers to help rewrite the tutorial, my eternal gratitude would go to her/him (I'm suspicious I don't have perspective enough to write some good introductoy material on the library.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Moving Boost.Thread barrier from thread_dev to HEAD
by Michael Glassford 23 Feb '04

23 Feb '04

The thread_dev branch in CVS contains a barrier class that I would like to move to the main branch, as has recently been requested by more than one Booster. Is anyone aware of any problems that should be addressed before this happens? For reference, see thread.hpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/boost/thread/A… and thread.cpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/thread/sr… One potential problem that I am aware of is that it is possible for the m_generation counter (see barrier.cpp) to overflow on systems that detect overflow of integer addition instead of wrapping (I assume there are such systems though I've never used one). Is it worthwhile checking for this and forcing wrapping in code? Mike

5 14

Re:[boost] (For me a) showstopper [was: boost thread static library]
by Robert Ramey 23 Feb '04

23 Feb '04

Stefan Slapeta wrote: >There's one more big "surprise": the need for the shared runtime >libraries! I'm very frustrated at the moment because I don't know which >strategy to choose for boost.thread at all: >Sorry for this critisism. I know about all your efforts and appreciate >them very much. This time it seems that the need for new functionality >broke too much of existing code for my taste! I'm not sure I'm following all this. Given that you are understand what the consequences of building and using a static library in this context, and you decide that they are not a problem for you, what prevents you from building your own statically linked library and using it in your own projects? Wouldn't that solve your whole issue Robert Ramey

4 8

Re: [boost] Re: algorithms namespace
by Dave Gomboc 23 Feb '04

23 Feb '04

> Well. It's actually the opposite. Because English is > (presumably) your first language, you prefer the > non-abbreviated "filesystem" over "fs". From the perspective > of someone who doesn't "think in English", the two have > pretty much the same inherent value, i.e. they are arbitrary > identifiers. >From the perspective of this English-speaking software developer, I recognize filesystem, and I also know what fs means. Furthermore, the first time I hear "fs", I imagine that I was able to guess from the context it was used in that fs means filesystem. >From the perspective of a developer who knows English but whose native tongue is not English, filesystem is understandable, because the component words, file and system, either are known or are looked up in a translation dictionary. "fs", on the other hand, is incomprehensible without supporting documentation. > A mental mapping translates these identifiers > into the entities they represent. Since the extra letters in > the longer identifier do not add any semantic value to > non-English speakers, they are merely clutter and do not > contribute to readability. You're missing the point -- the extra letters *do* add semantic value to those who speak English, but not as a first language. > Your observation that "stdio" is a _word_ in non-English > programmer cultures, and not an abbreviation of "standard > input/output", is very much in line with the above. Stdio was *not* a word to them, it was just a jumble of random characters. The whole concept of "standard" had been lost! Dave

2 1

Re: [boost] Re: mpl::for_each and polymorphic function object
by Aleksey Gurtovoy 23 Feb '04

23 Feb '04

Gennadiy Rozental wrote: > > mpl::for_each<mpl::transform<s, wrap<_1> >::type>(foo()); > > I saw this in mpl::for_each test. Actually, if you do it as in the test, it's even simpler: mpl::for_each< types,wrap<_1> >(foo()); > It may probably solve my problem. But is tyhe more generic solution? Sorry, cannot parse this one. > Or why doesn't for each pach mpl::identity in a first place? Sometimes the value semantics is exactly what you want: typedef mpl::range_c<int,0,10> numbers; std::vector<int> v; mpl::for_each<numbers,mpl::_>( boost::bind(push_back, &v, _1) ); > Or could we eliminate parameter at all and make for_each to > work with explicit type specialization, like this: > > aux::unwrap(f, 0)::operator()<arg>(); Like the previous suggestion, it would rule out ordinary function objects; besides, it's not portable. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 23 Feb '04

23 Feb '04

> From: Daniel Frey [mailto:daniel.frey@aixigo.de] > > // A strange way to retrieve my_container.begin(): > boost::prior( my_container.end(), my_container.size() ); > > Is that legal? The second template parameter of boost::prior > is deduced > to an unsigned(!) type, which IMHO means that -n is > undefined, right? Do > we need to fix this? It's both legal and well defined, but perhaps not very intuitive... For unary minus, the negative of an unsigned is computed as 2^n-v (where n is the number of bits in the type yielded by performing integral promotion on the operand and v is the value of the operand [5.3.1/7]). The resulting type is the promoted operand; this means that unsigned char and unsigned short will typically work as expected with boost::prior (those types can be promoted to int on most [all?] platforms), whereas unsigned int and unsigned long will always return a positive value (because here, the resulting type of integral promotion is the type of the operand, and the result of the unary - operator is therefore 2^n-v). So, the effect of this is that the example above is valid, but the resulting iterator is past-the-end, typically way too far to ever be seen again...and the name 'prior' thus becomes misleading for certain types. > or shall we document that it's illegal/undefined to call > boost::prior() > with an unsigned second parameter? I think Dave's suggestion of using reverse_iterator would be cool; that also adds a good reason for using boost::prior rather than std::advance for decrementing. Something like this should work: template <class T, class Distance> inline T prior(T x, Distance n) { return next(std::reverse_iterator<T>(x),n).base(); } (Daniel, good work spotting this issue!) Bjorn Karlsson

2 1

Re: [boost] Re: [mpl] BOOST_MPL_METAFUNCTION_MAX_ARITY
by Aleksey Gurtovoy 23 Feb '04

23 Feb '04

Jonathan Turkanis wrote: > > Defining BOOST_MPL_METAFUNCTION_MAX_ARITY together with > > BOOST_MPL_NO_PREPROCESSED_HEADERS the should do it. If not, it's a > > bug. I'll check if that's the case with the current CVS state. > > Thanks. FYI I got the errors with VC7.1. These were caused by a hard-coded 'bind' specialization in the "if.hpp" header. The code fails only if you disable the preprocessed headers _and_ reconfigure the arity, while the usual testing procedure was to test only with BOOST_MPL_NO_PREPROCESSED_HEADERS, and that's why the regression hasn't been caught earlier. Fixed in the main trunk. Thanks for reporting it, -- Aleksey Gurtovoy MetaCommunications Engineering

2 1