[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 <exceptions.hpp> include in named_mutex. * Added get_instance_type, get_instance_length and get_instance_name functions to front-ends. Warning: -------- Peter Johson has detected a problems with Vc8 and global optimization (/Og). Some tests have shown a possible compiler bug. vc7.1 has no problems with /Og. I'm investigating this but meanwhile I recommend disabling /Og (which is deprecated in vc8) when using Shmem. Special thanks to Peter Johnson, Harold Pirtle and Jan Stetka for their help on this version. Regards, Ion
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<PHProcess,std::allocator<PHProcess> >' : ambiguous symbol could be 'boost::shmem::list<T>' with [ T=PHProcess ] or 'std::list<_Ty>' with [ _Ty=PHProcess ] Although I haven't included boost/shmem/containers/list.hpp. How does the compiler know about shmem::list? Does the compiler know about all types defined in the namespace? Thanks in advance
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