Re: [Boost-users] [shmem] New bugfix version in Boost Vault and sandbox cvs

From: bwood (brass_at_[hidden])
Date: 2006-05-06 13:47:46

This is a MIME encoded message.

--=_90d886084a49ed2f6c047ae2bdc39726
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Ion Gaztañaga wrote: 
>Jan Stetka(e)k dio: 
>> Yes I understand that I can't use shmem::map and std::map if they are

>> both on the global namespace. I've looked at the implementation of
the 
>> std::map header from the STL implementation that is included in vc++
7.2 
>> and that doesn't forward declare std::list in <map>. This is a design

>> issue rather than a bug. Why forward declare shmem::list by including
it 
>> in map.hpp when it isn't used? 
>
>
>All classes in Shmem include shmem_fwd.hpp or container_fwd.hpp where
>Shmem defines default arguments (for example default Less, or
Allocator
>template parameter). That's why you get the predeclaration of list
>including map. Another alternative would be to declare a *_fwd.hpp for
>each class defined in Shmem, but you would get a lot of extra headers,
>and I would have a lot of work to maintain.
>
>
>Even if I don't include list predeclaration with map, I'm free to use
>any Shmem container in any Shmem class (for example, I can implement a
>pooled allocator using a list container), so it's likely that a Shmem
>class include will include more Shmem classes (predeclarations, or
full
>declarations). I don't consider it a design error, but a design
choice.
>What I see dangerous is pushing two namespaces, std, and shmem to the
>same context because they have similar classes. An alternative would
be
>to rename shmem classes like "vector" to "shmem_vector", .... But
>weren't namespaces born to allow that?

I think this is their intended purpose, but I don't like using them 
that way.  It gets confusing and brevity isn't attained as you have
to qualify things.  Namespaces support a "let's just agree to 
disagree" approach that isn't a resolution, but is the best that 
can be done at times.  Do you think this shmem functionality should 
be integrated with the std containers?  In the meantime, I think 
shmem_vector is better.

Does shmem support multi_index_containers?  Or, depending on 
how shmem fits into the picture, should B.MI take the lead in 
supporting shmem functionality internally?  Y'all have more 
flexibility in the B.MI case as it isn't part of the standard.

Brian
www.webEbenezer.net

--=_90d886084a49ed2f6c047ae2bdc39726--