Re: [config] seems like VC 8.0 needs BOOST_NO_MEMBER_TEMPLATE_FRIENDS
On Tuesday 27 July 2004 00:42, JOAQUIN LOPEZ MU?Z <joaquin@tid.es> wrote:
error C2888: 'void boost::multi_index::safe_mode::detach_equivalent_iterators(Iterator &)' : symbol cannot be defined within namespace 'detail'
The error seems to indicate a namespace problem rather then something specific to member template friends?
I've searched through the VC 2005 beta docs and, allegedly, member template friends are supported, so this particular problem could be a bug rather than complete lack of support for this feature. Maybe someone with local access to VC 8.0 can test the above code and see what happens (I currently don't have the time and resources to try myself.)
Maybe the problem is related to namespace handling in VC 8.0 Boost.numeric.interval library fails when included in uBLAS due to a curious namespace problem. http://www.meta-comm.com/engineering/boost-regression/developer/output/Rudbe... The same problem effect VC 7.1 as well. Why the compilers think the 'lower' 'upper' symbols are ambiguous I have no idea! -- Michael ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________
At Tuesday 2004-07-27 01:09, you wrote:
On Tuesday 27 July 2004 00:42, JOAQUIN LOPEZ MU?Z <joaquin@tid.es> wrote:
error C2888: 'void boost::multi_index::safe_mode::detach_equivalent_iterators(Iterator &)' : symbol cannot be defined within namespace 'detail'
The error seems to indicate a namespace problem rather then something specific to member template friends?
I've searched through the VC 2005 beta docs and, allegedly, member template friends are supported, so this particular problem could be a bug rather than complete lack of support for this feature. Maybe someone with local access to VC 8.0 can test the above code and see what happens (I currently don't have the time and resources to try myself.)
Maybe the problem is related to namespace handling in VC 8.0
Boost.numeric.interval library fails when included in uBLAS due to a curious namespace problem. http://www.meta-comm.com/engineering/boost-regression/developer/output/Rudbe...
The same problem effect VC 7.1 as well. Why the compilers think the 'lower' 'upper' symbols are ambiguous I have no idea!
because there are two different ones to choose from
-- Michael
___________________________________ Michael Stevens Systems Engineering
Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Le mar 27/07/2004 à 11:02, Victor A. Wagner Jr. a écrit :
Boost.numeric.interval library fails when included in uBLAS due to a curious namespace problem. http://www.meta-comm.com/engineering/boost-regression/developer/output/Rudbe...
The same problem effect VC 7.1 as well. Why the compilers think the 'lower' 'upper' symbols are ambiguous I have no idea!
because there are two different ones to choose from
Could you please explain why there are two different ones to choose from in the first place? I don't understand why the compiler looks for boost::numeric::ublas::lower. If VC is right, please tell me so that I submit bug-reports to GCC and ICC (since they don't see it). Regards, Guillaume
At Tuesday 2004-07-27 02:38, you wrote:
Le mar 27/07/2004 à 11:02, Victor A. Wagner Jr. a écrit :
Boost.numeric.interval library fails when included in uBLAS due to a curious namespace problem. http://www.meta-comm.com/engineering/boost-regression/developer/output/ RudbekAssociates-bin-boost-libs-numeric-ublas-test7-test-vc8-0-debug.html
The same problem effect VC 7.1 as well. Why the compilers think the 'lower' 'upper' symbols are ambiguous I have no idea!
because there are two different ones to choose from
Could you please explain why there are two different ones to choose from in the first place? I don't understand why the compiler looks for boost::numeric::ublas::lower. If VC is right, please tell me so that I submit bug-reports to GCC and ICC (since they don't see it).
from my quick test (I tried to FORCE the "local" lower) it had better see it because the local one caused an error. I'll have to run that test again tho (I believe I commented on it several days ago when I originally tried to fix it)
Regards,
Guillaume
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Michael Stevens wrote:
The error seems to indicate a namespace problem rather then something specific to member template friends?
Yes. Both 7.1 and 8 show exactly the same behaviour. AFAIK there is no support for member template friends where the template is defined in another namespace. However, I've no idea whether they planed to improved this in VC 8. From what I've heard and seen so far, one should not expect any major changes concerning std C++ for this compiler version except bugfixes. My impression is that they invested all their resources for the managed extensions. Stefan
Michael Stevens ha escrito:
On Tuesday 27 July 2004 00:42, JOAQUIN LOPEZ MU?Z <joaquin@tid.es> wrote:
error C2888: 'void boost::multi_index::safe_mode::detach_equivalent_iterators(Iterator &)' : symbol cannot be defined within namespace 'detail'
The error seems to indicate a namespace problem rather then something specific to member template friends?
I don't think so. My hunch is that the problem is template-specific. The following test snippet works OK with MSVC 6.5 and Comeau 4.3.3. I guess MSVC 8.0 will handle it right too since MSVC 6.5 does, but I cannot verify this hypothesis: ****************TEST 0**************** namespace A{ namespace C{ class foo; } namespace B{ void f(C::foo& x); } namespace C{ class foo { int m; friend void B::f(foo&); }; } namespace B{ void f(C::foo& x) { x.m=0; } } } // A int main() { A::C::foo x; A::B::f(x); return 0; } ****************END TEST 0**************** When we introduce templates, Comeau still has it right, but MSVC 6.5 chokes on it (error C2888, the same that RudbekAssociates tests show for multi_index in VC 8.0): ****************TEST 1**************** namespace A{ namespace B{ template<typename X>void f(X& x) { x.m=0; } } namespace C{ class foo { int m; template<typename X> friend void B::f(X&); }; } } // A int main() { A::C::foo x; A::B::f(x); return 0; } ****************END TEST 1**************** Could some kind soul with access to MSVC 8.0 try TEST 0 and TEST 1 for this compiler and report the results? If TEST 0 passes and TEST 1 fails, IMHO BOOST_NO_MEMBER_TEMPLATE_FRIENDS should be set on for this compiler, or at least a weak variant, something like BOOST_NO_MEMBER_TEMPLATES_ACROSS_NAMESPACES Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
[...] IMHO BOOST_NO_MEMBER_TEMPLATE_FRIENDS should be set on for this compiler
That wouldn't be very friendly. NO_MEMBER_TEMPLATE_FRIENDS means "disable all templated friends, including class templates".
Peter Dimov ha escrito:
Joaquín Mª López Muñoz wrote:
[...] IMHO BOOST_NO_MEMBER_TEMPLATE_FRIENDS should be set on for this compiler
That wouldn't be very friendly. NO_MEMBER_TEMPLATE_FRIENDS means "disable all templated friends, including class templates".
Oh, sure, I don't really know the extent of this bug candidate. Actually, for my needs I don't have to use any Boost.Config macro: if the bug is confirmed I can fix things myself internally. But Boost.Config is meant to accumulate the experience in dealing with compiler defects, so some sort of macro for this would be nice. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
Could some kind soul with access to MSVC 8.0 try TEST 0 and TEST 1 for this compiler and report the results? If TEST 0 passes and TEST 1 fails, IMHO BOOST_NO_MEMBER_TEMPLATE_FRIENDS should be set on for this compiler, or at least a weak variant, something like BOOST_NO_MEMBER_TEMPLATES_ACROSS_NAMESPACES
Once again: VC 8.0 behaves _exactly_ like VC 7.1! (therefore, test 0 succeeds and test 1 fails) Thus, as BOOST_NO_MEMBER_TEMPLATE_FRIENDS is defined in visualc.hpp for this compiler... #if _MSC_VER <= 1310 # define BOOST_NO_MEMBER_TEMPLATE_FRIENDS #endif ...there should be the same define for VC 8. Whether this is too strict or not and whether there should be a "weaker" macro (just for friends in other namespaces) is a completely different discussion and the outcome is equally valid for both VC 7.1 and VC 8! Stefan
Stefan Slapeta ha escrito:
Joaquín Mª López Muñoz wrote:
Could some kind soul with access to MSVC 8.0 try TEST 0 and TEST 1 for this compiler and report the results? If TEST 0 passes and TEST 1 fails, IMHO BOOST_NO_MEMBER_TEMPLATE_FRIENDS should be set on for this compiler, or at least a weak variant, something like BOOST_NO_MEMBER_TEMPLATES_ACROSS_NAMESPACES
Once again: VC 8.0 behaves _exactly_ like VC 7.1! (therefore, test 0 succeeds and test 1 fails)
Oh, excuse my misunderstanding. I took this previous statement of yours: [Michael Stevens] The error seems to indicate a namespace problem rather then something specific to member template friends? [Stefan Slapeta] Yes. Both 7.1 and 8 show exactly the same behaviour [...] as meaning that you endorsed the pov that the problem was not template-related. (Later on on the paragraph, your position is made clearer, though.) Anyway, thank you for the further explanation and for trying the tests. I'll update my lib accordingly to this info.
Thus, as BOOST_NO_MEMBER_TEMPLATE_FRIENDS is defined in visualc.hpp for this compiler...
#if _MSC_VER <= 1310 # define BOOST_NO_MEMBER_TEMPLATE_FRIENDS #endif
...there should be the same define for VC 8.
Whether this is too strict or not and whether there should be a "weaker" macro (just for friends in other namespaces) is a completely different discussion and the outcome is equally valid for both VC 7.1 and VC 8!
I guess we'd need more direct exposure to the compiler to determine this. Peter seems to point out that MSVC 8.0 has made some actual progress in supporting member *class* template friends, but I don't really know. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (3)
-
Guillaume Melquiond -
Joaquín Mª López Muñoz -
Michael Stevens -
Peter Dimov -
Stefan Slapeta -
Victor A. Wagner Jr.