- Boost-users - lists.boost.org

Re: pool_allocator problems on VC7.1 (real rele ase)
by scleary＠jerviswebb.com 26 Apr '03

26 Apr '03

> -----Original Message----- > From: John Harris [mailto:john.harris@tradingtechnologies.com] > > I can test this for you tomorrow (I'm about to go drinking now). In > return, could you possibly tell me how to change pool_allocator so > that it uses my own tag? My goal is to have a totally local > allocator for some special parts of the code. Why, BTW, does it have > to use the Singleton pool interface instead of the object pool > interface? The latter, I think is what I'm after. I'm going to start with a brief overview of the Boost.Pool interfaces: pool<> (pool.hpp): "The" pool interface. Provides allocation and deallocation of memory. object_pool<> (object_pool.hpp): Restricts access to the pool<> interface. Provides allocation and deallocation of memory for a single object type; and, when destroyed, will call the destructor for any non-deallocated objects allocated from that object_pool. singleton_pool<> (singleton_pool.hpp): Provides access to the pool<> interface as a singleton, distinguished mainly by size of the memory allocations and a tag. pool_allocator<> (pool_alloc.hpp): Restricts access to the singleton_pool<> interface. Provides a Standard-compliant Allocator interface. To answer the specific questions: 1) The pool_allocator<> (and fast_pool_allocator<>) can be relatively easily extended to use other tags for the singleton_pool<> interface underlying them - pass an additional template parameter (after the UserAllocator parameter), defaulting to the currently-used tag. This is a good idea, and I'll put it in when I can. 2) pool_allocator<> uses the singleton_pool<> interface instead of the object_pool<> interface for the following reasons: A) Standard Allocators only handle the allocation and deallocation of memory, and do not deal with actual object types [+]. The intent of object_pool<> is to cleanly call destructors for objects that were never deallocated. Such an action: 1) is unneeded (since all containers should free whatever memory they allocate, and destroy any objects they construct), and 2) would cause the Allocator to get into construction/destruction semantics, which is contrary to the Standard Allocator concept. B) Standard-compliant Allocators that can be used with STL-provided containers must be stateless. This requires an underlying singleton interface. Encapsulating a non-singleton interface within the Allocator, or even sharing one with the handle/body idiom does not satisfy the stateless requirement. [+] The object-related Allocator requirements (construct()/destroy()) do not have anything to do with allocation/deallocation, and are generally considered to be a useless overspecification. Please let me know if I haven't been clear enough - I've been a little lacking in sleep lately ;) -Steve

2 1

RE: [Boost-Users] NRVO (was Re: "Correct" way to return empty shared_ptr?)
by dick.bridges＠tais.com 25 Apr '03

25 Apr '03

return shared_ptr<int>(); works with VC6.0 but elicits the [AFAICT] uninformative <emsg>parse error before `;'</emsg> from gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110). Drat! "Duane Murphy" <duanemurphy@mac To: "Boost Users" <Boost-Users(a)yahoogroups.com> .com> cc: Subject: RE: [Boost-Users] NRVO (was Re: "Correct" way to return empty shared_ptr?) 04/24/2003 09:40 AM Please respond to Boost-Users --- At Thu, 24 Apr 2003 16:56:40 +0100, Ben Hutchings wrote: <snip> shared_ptr<int> maybe_get_a_pointer() { return shared_ptr<int>(); } is perfectly reasonable and can also be optimized. Is there more recent and complete discussion concerning this optimization? Is naming actually required? ...Duane Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

1 0

RE: [Boost-Users] Re: pool_allocator problems on VC7.1 (real rele ase)
by scleary＠jerviswebb.com 25 Apr '03

25 Apr '03

> -----Original Message----- > From: John Harris [mailto:john.harris@tradingtechnologies.com] > > Since it seems to work on VC7.1, it would be nice if the author had > access to that compiler and could do some testing. In the mean time, > I'll try some stuff with this new toy and report any further problems. Some command-line tools ship with their DDK, so I do have a version of "cl.exe" that reports "13.00.9176" - no idea how this fits in with the VC versions, though. And the DDK doesn't include an STL anyway. There is one "common" failure case with some implementations of STL containers: passing 0 to Allocator::deallocate. When used with std::allocator, the 0 is passed through to operator delete() which of course ignores it. When used with pool_alloc, this generally causes a segfault. IIRC, STLPort's std::vector will do this if you construct & destroy an empty vector. Since I don't have the VC STL, could you do that test case for me? Thanks, -Steve

2 2

MP3 and C++
by steelgig 25 Apr '03

25 Apr '03

Hi, I'm working on a project for the university and I'm looking for some C++ library or application that could help me. My goal is to extract some kind of information related to the spectra of a signal coded in MP3. I'm looking for a spectrum analyzer that localizes peaks in the power spectrum (better if it works on a user-specified band) and allows the detection of the temporal occurence of each peak and its intensity. I also need to retrieve some sample of frequency components (or the MDCT coefficients) near the identified peaks. Every suggestion is welcome (even something that satisfies only partially the requests or that indicates a better place to found an answer to this message). Thanks in advance for the help, Gio PS: even some function that works on the MP3 file without decoding it, for example only partial decoding actions (IMDCT, Huffman decoding) or subband value retrieval function, could be useful.

1 0

Circular Buffer
by Joe Mariadassou 24 Apr '03

24 Apr '03

Does boost or any other open source have an implementation of a bounded circular buffer? My search in boost and google yielded naught. The main purpose of this container is to pipeline messages in a typical producer-consumer scenario. I was surprised not to find any implementation. TIA Joe [Non-text portions of this message have been removed]

2 1

Test for endian using MPL or PP(Wave?)
by Mike Wilson 24 Apr '03

24 Apr '03

Hi, There is an application I use that always produces a little endian binary file. I have written a program to process this file. As my program can port to both little/big endian platforms I have a #define (LITTLE_ENDIAN_TARGET) acting as a flag for the necessary byte swapping that is needed on the big-endian platforms. I was wondering if there is a better way to do this, so I searched the Web & boost archives. I found the following code snippet in the boost archives. bool isLittleEndian() { int temp = 1; return (*(char*)&temp) != 0; } which is of some help (eliminating my #define). However, I was wondering if there is a PP or mpl way of testing for endian-ness at compile time. For example, I'd like to do something like the following: const bool IsLittleEndian = ..to be determined automatically..; I've got a gut feeling that I can't do the above at complile time, but maybe something like Wave may do the job? Thanks for any assistance in this matter. Mike

4 4

RE: [Boost-Users] Re: "Correct" way to return empty shared_ptr?
by Ben Hutchings 24 Apr '03

24 Apr '03

dick.bridges(a)tais.com wrote: > This is one of the places where I get *REALLY* confused - the 'real' code > has multiple returns. Apologies: I should have included this psuedo code > in the original example. It looks like this. > > <snippet> > // v is populated somewhere else > typedef vector<shared_ptr<int> > V; > V v; > > shared_ptr<int> maybe_get_a_pointer() > { > shared_ptr<int>::iterator itr; > itr = find_if(v.begin(), v.end(), some_op); > > if(itr != v.end) > return(*itr); > > shared_ptr<int> p; > return(p); > } > </snippet> > > Are compilers supposed to be able to match *itr to p in order to apply the > NRVO? I don't know what you mean by "match *itr to p". The NRVO should be possible for the second return statement, because if p is constructed then it's always returned. However, optimisations are by definition optional so the implementation isn't "supposed to" perform them.

1 0

RE: [Boost-Users] NRVO (was Re: "Correct" way to return emptyshared_ptr?)
by Ben Hutchings 24 Apr '03

24 Apr '03

Duane Murphy <duanemurphy(a)mac.com> wrote: > --- At Thu, 24 Apr 2003 16:56:40 +0100, Ben Hutchings wrote: > >dick.bridges(a)tais.com wrote: > >> I don't understand C++ well enough to grok a compiler's interpretation of > >> the code, but I seems like I'm creating an extra copy for the return. > ><snip> > > > >Logically the local variable is copied to the the caller, but since the type > >of the returned expression matches the return type the compiler is allowed > >to optimise away that copy, even though the return type has a user-defined > >copy constructor. In this case you always return a certain named variable, > >so the compiler can arrange to construct it in the memory location where the > >caller expects the returned value. This is called the named-return-value > >optimisation, or NRVO. > > I dont want to start any kind of war, and this is a bit off topic, but I > was investigating NVRO and found a few discussions with Scott Meyers that > indicated that naming is not relevant to the optimization. That this: > > shared_ptr<int> maybe_get_a_pointer() > { > return shared_ptr<int>(); > } > > is perfectly reasonable and can also be optimized. > > Is there more recent and complete discussion concerning this > optimization? Is naming actually required? I realise that the implementation is allowed to optimise out the copy whether the return value is named or not. Actually doing so requires quite different treatment of the two cases, so it's worth considering them as separate optimisations. For NRVO to be possible at some return statement, there must not be any return statements reachable after the construction of the returned object that return any other object. The optimisation involves changing the code generated for the definition of the object, rather than the code for the return statement. So the implementation has to consider the whole function when doing this. Anonymous RVO is a very local optimisation, so it should require less work to apply.

1 0

RE: [Boost-Users] Re: "Correct" way to return empty shared_ptr?
by dick.bridges＠tais.com 24 Apr '03

24 Apr '03

This is one of the places where I get *REALLY* confused - the 'real' code has multiple returns. Apologies: I should have included this psuedo code in the original example. It looks like this. <snippet> // v is populated somewhere else typedef vector<shared_ptr<int> > V; V v; shared_ptr<int> maybe_get_a_pointer() { shared_ptr<int>::iterator itr; itr = find_if(v.begin(), v.end(), some_op); if(itr != v.end) return(*itr); shared_ptr<int> p; return(p); } </snippet> Are compilers supposed to be able to match *itr to p in order to apply the NRVO? "Ben Hutchings" <ben.hutchings@businesswebso To: <Boost-Users(a)yahoogroups.com> ftware.com> cc: Subject: RE: [Boost-Users] Re: "Correct" way to return empty shared_ptr? 04/24/2003 08:56 AM Please respond to Boost-Users dick.bridges(a)tais.com wrote: > I don't understand C++ well enough to grok a compiler's interpretation of > the code, but I seems like I'm creating an extra copy for the return. <snip> Logically the local variable is copied to the the caller, but since the type of the returned expression matches the return type the compiler is allowed to optimise away that copy, even though the return type has a user-defined copy constructor. In this case you always return a certain named variable, so the compiler can arrange to construct it in the memory location where the caller expects the returned value. This is called the named-return-value optimisation, or NRVO. Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

1 0

RE: [Boost-Users] Re: "Correct" way to return empty shared_ptr?
by Ben Hutchings 24 Apr '03

24 Apr '03

dick.bridges(a)tais.com wrote: > I don't understand C++ well enough to grok a compiler's interpretation of > the code, but I seems like I'm creating an extra copy for the return. <snip> Logically the local variable is copied to the the caller, but since the type of the returned expression matches the return type the compiler is allowed to optimise away that copy, even though the return type has a user-defined copy constructor. In this case you always return a certain named variable, so the compiler can arrange to construct it in the memory location where the caller expects the returned value. This is called the named-return-value optimisation, or NRVO.

2 1