- Boost - lists.boost.org

Re: [boost] Re: Customization via Overloading in Namespace
by Peter Dimov 24 Feb '04

24 Feb '04

Peter Dimov wrote: > David Abrahams wrote: >> >> Simple: specializations that follow the point of instantiation aren't >> considered. This program exits with an error: >> >> template <class T> >> int f(T) { return 1; } >> >> int main() { return ::f(0); } >> >> template <> int f(int) { return 0; } > > It's ill-formed, actually. On reflection, I think I see what you are trying to illustrate, and I also think that you are wrong. #include <iostream> // f.hpp template<class T> void f(T) { std::cout << "General\n"; } // g.hpp template<class T> void g(T t) { ::f(t); } // X.hpp struct X {}; /*template<>*/ void f(X) { std::cout << "X-specific\n"; } // main.cpp int main() { f( X() ); g( X() ); } Uncomment the /*template<>*/ to see what I mean. No order dependency.

2 1

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

24 Feb '04

> From: Daniel Frey [mailto:daniel.frey@aixigo.de] > Should we propose std::regress (the counter-part for > std::advance) for > standardization (via a DR)? The current definition of > std::advance seems > to limit the number of elements that can be skipped backwards > to signed > types, but the container can be larger (OK, in theory, never tried it > myself :). This would also nicely solve the implementation > issue for us. I don't think it's really a defect; there's a slight inconsistency with regards to the max/min values on most platforms, but nothing inherently wrong AFAICS. Note that the reverse_iterator trick can be used by client code too, so the "signed type limit" is easily defeated. [snip] > right? Although I wonder what happens if T is already a reverse > iterator. Is it legal to reverse a reverse_iterator? Or do we need a > trait and implement both cases separately? Yes, reversing a reverse_iterator this way is fine (because a reverse_iterator satisfies the iterator requirements). Bjorn

4 4

allocator_facade
by Alberto Barbati 24 Feb '04

24 Feb '04

Hi Boosters, I had a very good time writing iterators with the new iterator_facade template. Very good job! It makes writing iterators so much simpler! What about having a similar template for allocators? Given that a large class of useful allocators are de facto built over a couple of typeless malloc-like/free-like functions, I imagine something that could be used like this: struct malloc_impl { static void* allocate(size_t n) { return malloc(n); } static void deallocate(void* p) { free(p); } }; std::vector<int, boost::allocator_facade<int, malloc_impl> > v; where boost::allocator_facade<T, malloc_impl> satisfies all requirements that std::allocator<T> does. An implementation for a conforming compiler and library is straightforward and allocator_facade could also include workarounds for specific platforms where possible (for example it can easily and automatically provide the __stl_alloc_rebind hack in STLport). Is there any interest for such a thing? Alberto

3 2

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 > > >Hurd, Matthew <hurdm <at> sig.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... > > > > Not at all. If this proves useful, I would certainly want to support it. > > > 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. > > > > Yes, certainly. I'm not au fait with expression templates, but you could > alternatively implement arithmetic operations in future<T> which > maintained > shared pointers to operands, and stored a function pointer to std::plus, > etc. Expression templates are just a way of doing the kind of thing you have just described at compile time. Here is a famous intro http://www.adtmag.com/joop/crarticle.asp?ID=627 that I like anyway. > > If you get rid of the thread(s) in the active object idea, you end up > > with a mechanism for lazy evaluation. > > > > This I don't really follow. If you take away the thread from the active > object > then the calling thread must perform the evaluation itself, eventually. > What > you have left is equivalent to a sequence of boost::binds to a standard > function, haven't you? No, it doesn't have to perform the operation, the future could simply contain a boost::optional<value> with a boost::function callback, for one example implementation, so the calc might not be done until it is really needed... I was thinking about this situation in terms of what it would take to move this successfully to a single threaded (or passive object?) case and the problem of messy dependencies that automagically resolve themselves in the threaded active object sense might not have a solution, or might have a less efficient solution, if laziness was not the default behaviour. That is you could end up waiting on things that haven't been kicked off and thus you deadlock without laziness. > > Perhaps there is a more general mechanism / pattern and bike shop name > > lurking in this pattern... > > > > Regards, > > > > Matt Hurd > > Are you suggesting that the 'future' template is a convenient syntactic > sugar > for lazy evaluation, as a separate concern to the threading involved? If > so, > I can't disagree... > > Matt Yup, laziness and possibly a neat way of keeping things architectural neutral with appropriate policies. 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.

1 0

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