- Boost - lists.boost.org

shared_ptr<> vast questions
by Dave 22 Jan '05

22 Jan '05

Hello NG, With regard to shared_ptr<>... Let's say I have a heap object of type O that contains one subobject of type SO. At this point, I'm deliberately not saying whether the subobject is brought into the object by public inheritance or by containment. Either way, the memory layout is the same under most implementations. May I upcast shared_ptr<O> to shared_ptr<SO> in any case? Or, does the answer depend on whether the subobject has been brought in by public inheritance or by containment? Same question for a downcast (dynamic cast)... Thanks, Dave

2 1

Re: [boost] Re: [multi_index] interest in a random-access index?
by JOAQUIN LOPEZ MU?Z 21 Jan '05

21 Jan '05

Hi Jeff, ----- Mensaje original ----- De: Jeff Flinn <TriumphSprint2000(a)hotmail.com> Fecha: Viernes, Enero 21, 2005 4:46 pm Asunto: [boost] Re: [multi_index] interest in a random-access index? > Joaquín Mª López Muñoz wrote: > > A. Is there interest in having this in Boost.MultiIndex? I wouldn't > > like to add stuff just for the fun of it. > > Definitely! I've been thinking about replacing the internals of a > displayTable class that is derived from the MFC ListView class. I > need random > access when the user does in place editing, while also needing to > allowordering by multiple indices when the user clicks on a column > header. I've taken a look at CListCtrl and cannot figure out why you need a randon-access index (the additional ordered indices seem obvious enough.) Just to make sure, would you care to explain how a random-access index would be used in your situation? (thanks) In case I finally write this, would you volunteer to test a beta version of it to assess its usefulness? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[multi_index] interest in a random-access index?
by Joaquín Mª López Muñoz 21 Jan '05

21 Jan '05

Hello, I'm considering the possibility of devising a new type of index for Boost.MultiIndex with random-access capabilities, modeled pretty much after the interface of std::vector (with some significant pros and cons.) The basic features of such an index would be: 1. Traversal order is set by the user as with sequenced types. A vector-like insertion interface is provided (push_back/front, positional insert). 2. Iterators are random-access. The index provides an operator[]/at() interace. Advancing/incrementing an iterator involves internally an addition and two pointer dereferences: not as fast as a real vector, but very fast indeed. 3. The memory overhead is two pointers per element. 4. Iterators and references are stable, i.e. they remain valid on the face of insertions/deletions (std::vector does not guarantee this.) 5. Memory storage is *not* contiguous: so, (&begin[0])+n cannot be used to sequentally access all the elements of the index, unlike std::vector. 6. The complexity bounds are much the same as those of a vector: amortized constant insertion/deletion at the end, linear otherwise. My questions are: A. Is there interest in having this in Boost.MultiIndex? I wouldn't like to add stuff just for the fun of it. B. Any suggestion for the name of such an index? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[filesystem] Now uses POSIX readdir_r if available
by Beman Dawes 21 Jan '05

21 Jan '05

CVS has been updated: * For POSIX systems, directory_iterator now uses readdir_r if available, with a fallback to readdir otherwise. The POSIX readdir function uses a static buffer, so is unsafe in multi-threaded apps. Furthermore, there has been a report that readdir on Mac OS X does not meet the POSIX requirement of a different static buffer for each directory stream; readdir_r should solve that problem too. * Tests have been added to operations_test.cpp to detect interference between directory_iterators. The changes have been tested using operations_test.cpp on Red Hat Linux 8.0 and Windows XP. Since gcc on this Linux does supply readdir_r, the code was tweaked by hand to force use of readdir. Both passed. Please let me know right away if you run into any problems! --Beman

1 0

about the Data_time; How I can init a ptime that only have the time no the date;
by "帅哥:->代小飞" 21 Jan '05

21 Jan '05

As I knew : construct a ptime use the ptime("2002-01-20 23:59:59.000"); but now I want to init a ptime look like ptime("23:59:59.000");when I use this funcation,a exception is show! any body can tell me ,,How Can i do?!

2 1

Borland and ADL
by Gennadiy Rozental 21 Jan '05

21 Jan '05

Why Borland config doesn't have BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP defined? In my experience it doesn't ADL at least up to 5.6.4 (when I tried) Gennadiy

3 5

[mpl] RFE: accessing ith tail of [reverse_]fold
by Larry Evans 21 Jan '05

21 Jan '05

I just uploaded to boost vault: inherit_tail_type.zip which contains inherit_tail_type.hpp and a test. It allows easy access to ith tail in fold<types, empty_base, inherit2<_2,_1> >. It has specializations for the tail being on the left or right side of inherit2, and for using reverse_fold also. I'm proposing this as an enhancement to mpl.

1 1

Singleton
by Jason Hise 21 Jan '05

21 Jan '05

Regarding the static creation policy... would it be dangerous to use such a policy if there were static dependencies in use? I am worried that the static storage might be released before the said dependency and then when this last dependency dies it would try to destruct an object living in now inaccessible memory. Is this concern well founded? -Jason

2 2

Singleton
by Jason Hise 21 Jan '05

21 Jan '05

Alrighty, I think I've taken care of a large number of the concerns. I have locking, multiple allocator types, and even a fancy longevity lifetime policy. Everything is in the Singleton directory at "http://boost-sandbox.sourceforge.net/vault/". Please let me know what remains to be added, or if there is anything remaining that needs to be fixed. -Jason

1 0

Re: Singleton
by Dave Handley 20 Jan '05

20 Jan '05

<snip on alignment> Jonathan Wakely wrote: > > memory is alignment with the type being allocated. Malloc and New are > > guaranteed to return memory that is aligned for an object of that size > > Guaranteed to be aligned for _any_ type, isn't it ? Any type that is not bigger than the memory size allocated. I'm pretty sure that the ANSI requirement for malloc and new does not require alignment to 8/16 byte blocks for memory allocations of a single byte (for example). This means that, to be pedantic, a 1 byte allocation is not guaranteed to be aligned for a double (for example). However, since this is a silly example, for all practical purposes you are correct. Also, some implementation may well guarantee alignment for small allocations. Nevertheless, my rather terse comment about being guaranteed to return memory aligned for an object of that size was probably a bit too terse, so thanks for the quotes and clarification. Dave

2 1