[shmem] New bugfix version in Boost Vault and sandbox cvs
Hi to all,
I've just uploaded to Boost Vault a new version of Shmem (0.92). You
can download it here:
http://boost-consulting.com/vault/index.php?direction=&order=&directory=Memory
Online documentation here:
http://ice.prohosting.com/newfunk/boost/libs/shmem/
Changes in 0.92:
-----------------
* Solved bugs in flat_xxx insert functions.
* Solved ambiguous windows native function calls with some header orderings.
* Changed named_mutex to support scoped_lock.
* Added missing
Glad to see a new version has been produced. Is it intentional that named_mutex.hpp requires lock.hpp to be included before it? I'm getting alot of error C2039: 'lock_ops' : is not a member of 'boost::shmem' when i compile. Jan
Hi,
When I intend to use a std::list with
using namespace boost::shmem; //and
using namespace std;
I get this error:
\src\ph\projects\PHQuery\running.cpp(78) : error C2872:
'list
Hello, The compiler knows about shmem::list as it is declared in shmem_fwd.hpp which is included in containers\map.hpp. shmem::list is NOT used in map.hpp. It would be possible to just forward declare those classes that are needed. Such a fine grained approach would make it easier to use shmem and stl side by side. Thanks.
Jan Stetka(e)k dio:
Hello,
The compiler knows about shmem::list as it is declared in shmem_fwd.hpp which is included in containers\map.hpp. shmem::list is NOT used in map.hpp. It would be possible to just forward declare those classes that are needed. Such a fine grained approach would make it easier to use shmem and stl side by side.
That won't solve the problem if you use "using namespace boost::shmem" and "using namespace std" because although you don't include containers directly, the library might use some containers internally (for example, map) and you can get ambiguous symbols. I suggest using a namespace alias if you find "boost::shmem::container" too long, but if you try to push all std names and boost::shmem names to the global namespace you will surely have problems. This is likely to happen also with other boost libraries that mimic STL algorithms. Regards, Ion
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? Jan
Ho Jan, 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? Regards, Ion
Hi, Ion Gaztañaga wrote:
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.
That is what I was getting at. And it is a small point in another wise extremely useful library. Being able to use containers across processes, and shared process mutexs with shmem is powerful, straightforward and reliable. I like that greatly!! Thanks for your work.
Evening, There is still an ambiguous windows native function call. My file has using namespace boost::shmem and wtl is included in one of the other headers. C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\include\atlbase.h(4438) : error C2668: 'GetCurrentThreadId' : ambiguous call to overloaded function C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinBase.h(2502): could be 'DWORD GetCurrentThreadId(void)' C:\boost_1_33_1\boost\shmem\sync\win32\win32_sync_primitives.hpp(359): or 'unsigned long boost::shmem::GetCurrentThreadId(void)'
Jan Stetka(e)k dio:
Evening,
There is still an ambiguous windows native function call. My file has using namespace boost::shmem and wtl is included in one of the other headers.
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\include\atlbase.h(4438) : error C2668: 'GetCurrentThreadId' : ambiguous call to overloaded function C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinBase.h(2502): could be 'DWORD GetCurrentThreadId(void)'
C:\boost_1_33_1\boost\shmem\sync\win32\win32_sync_primitives.hpp(359): or 'unsigned long boost::shmem::GetCurrentThreadId(void)'
Hi Jan, I will try to fix these issues as soon as possible. Thanks for bug testing, Ion
participants (2)
-
Ion Gaztañaga -
Jan Stetka