Re: [Boost-users] boost::crc32 - visual studio crt - bug?!

I do not like the idea of changing my compile flags (I really do like that option for my debug builds!) just because of boost crc32. What about changing the header the request way, marking all casts using &0xFF? I do not see any reason for those safe marks not being introduces into boost crc.

You could also try wrapping the calls to crc_32_type and process_bytes in a #pragma runtime_check: #ifdef _DEBUG #pragma runtime_checks("c", off) #endif [ call to crc_32_type or process_bytes] #ifdef _DEBUG #pragma runtime_checks("c", restore) #endif It's ugly, but it might solve the problem, at least temporarily. Hope this helps, Demian

Hi dear members, I'm currently working on some template based DSL using MPL and proto and i came across some really strange problem.I'll try to give as much details as possible, but I mus confess I'm really los so some important things may have slipped. So, i have a class called matrix which is a simple end-user class for handling multidimensionnal array of data. It's declared as follow : template<class T, class S = settings<> > class matrix : public process_settings<T,S>::type; In this declaration, T is the type of the element stored in the matrix ans S is a setting list. A seting list is a static vector of types that defines various aspects of the matrix : nbr of dimensions, 'shape' (aka dense, upper triangular etc), other optimisations settings like unroll factor etc. As i didn't want my user to be forced to register those options in a linear fashion (and thus forcing them to remember a cumbersome list of predefined options), I did the folowing : - each options type defines a type that tag them and discriminate them. For example, all shape related type are done likewise : struct dense { typedef shape_tag type; }; struct upper_triangular { typedef shape_tag type; }; - The vector is turned into a mpl::map in which the key of each element of the vector is used as a key. This allow me to store any number of options in any order - this map is then passed to process_settings which retrieves the shape tag options and returns another type called shape as the public base of matrix. Now, this shape class is overloaded for each shape type by using tempalte argument. For ex., the dense shape overload is given by shape<T,dense,options>, where T is the element of the matrix and options the processed map of options. This class does all the grutn work of allocating, freeing and accessing elements. I also have a method called size() that returns the size of the shape in nbr of elment. matrix::size then just call back this size() method. Now I had the need to have a free function called size that take a matrix and call .size() on it. Alas, the compiler don't let me do it right :/ Using gcc 4.1 (on linux or using mingw) i got the following error : C:/Boost/include/boost-1_34_1/boost/mpl/size_fwd.hpp: In function 'int main()': C:/Boost/include/boost-1_34_1/boost/mpl/size_fwd.hpp:20: error: 'template<class Sequence> struct boost::mpl::size' is not a function, ../../ophelia/nt2/container/matrix/matrix.hpp:499: error: conflict with 'template<class T,class S> const typename matrix<T,S>::size_type& nt2::size(const matrix<T,S>&)' I:\dev\nt2\ophelia\nt2\main.cpp:17: error: in call to 'size' Basically, instead of using my size() function, the compiler fetches boost::mpl::size ... I checked and triple checked that i have NO using namespace boost anywhere and that, if I rename size into let's say gimme_size, it works. It just fail at finding size cause he find the mpl structure instead. Same for any function name like at or stuff like this (ie names that are also a mpl class name). Now, if matrix ends up with only ONE tempalte arguments (ie T), it works fine ... I'm completely lost. Even if i know that i can just rename this, i don't want to just let it go. Either I did something stupid, either there is some bug (I think the former alas) and i don't want such errors resufraces later in some unrelated code. If details on the class actual definition is needed, I'll post them. Joel FALCOU Research Engineer @ Institu d'Electronique Fondamentale Université PARIS SUD XI France

AMDG Joel FALCOU wrote:
Hi dear members,
I'm currently working on some template based DSL using MPL and proto and i came across some really strange problem.I'll try to give as much details as possible, but I mus confess I'm really los so some important things may have slipped.
So, i have a class called matrix which is a simple end-user class for handling multidimensionnal array of data. It's declared as follow :
template<class T, class S = settings<> > class matrix : public process_settings<T,S>::type;
<snip>
Now, this shape class is overloaded for each shape type by using tempalte argument. For ex., the dense shape overload is given by shape<T,dense,options>, where T is the element of the matrix and options the processed map of options. This class does all the grutn work of allocating, freeing and accessing elements. I also have a method called size() that returns the size of the shape in nbr of elment. matrix::size then just call back this size() method.
Now I had the need to have a free function called size that take a matrix and call .size() on it. Alas, the compiler don't let me do it right :/ Using gcc 4.1 (on linux or using mingw) i got the following error :
<snip>
Basically, instead of using my size() function, the compiler fetches boost::mpl::size ... I checked and triple checked that i have NO using namespace boost anywhere and that, if I rename size into let's say gimme_size, it works. It just fail at finding size cause he find the mpl structure instead. Same for any function name like at or stuff like this (ie names that are also a mpl class name). Now, if matrix ends up with only ONE tempalte arguments (ie T), it works fine ...
I'm completely lost. Even if i know that i can just rename this, i don't want to just let it go. Either I did something stupid, either there is some bug (I think the former alas) and i don't want such errors resufraces later in some unrelated code. If details on the class actual definition is needed, I'll post them.
I would be helpful to see the definition of settings<>. Are any of it's template parameters or base classes in namespace mpl? Ok, yes. I suspect that the compiler is finding mpl::size by ADL. I don't think it ought to, but I'll look it up. I'd also like to know what happens with another compiler. In Christ, Steven Watanabe

Steven Watanabe a écrit :
I would be helpful to see the definition of settings<>. Are any of it's template parameters or base classes in namespace mpl? Ok, yes. I suspect that the compiler is finding mpl::size by ADL. I don't think it ought to, but I'll look it up. I'd also like to know what happens with another compiler.
You got it right. settings was defined as : template< class S1 = bm::na,class S2 = bm::na,class S3 = bm::na, class S4 = bm::na,class S5 = bm::na,class S6 = bm::na, class S7 = bm::na,class S8 = bm::na,class S9 = bm::na > struct settings : bm::vector<S1,S2,S3,S4,S5,S6,S7,S8,S9> type; {}; I changed it to : template< class S1 = bm::na,class S2 = bm::na,class S3 = bm::na, class S4 = bm::na,class S5 = bm::na,class S6 = bm::na, class S7 = bm::na,class S8 = bm::na,class S9 = bm::na > struct settings { typedef bm::vector<S1,S2,S3,S4,S5,S6,S7,S8,S9> type; }; and modified the appropriate typedef in process_settings. Another such problems was raised in another of my matrix related case. When both where fixed, it worked flawlessy. I also made the test on VC++ 2008 with same results. The fact the compiler use ADL at this point is rather fishy as the whole matrix type should be enough. Thanks for the highlight, I was so deep in this matter for so long I didn't tought of the obvious. Joel FALCOU Research Engineer @ Institu d'Electronique Fondamentale Université PARIS SUD XI France
participants (4)
-
Demian Nave
-
gfsdgadas@Safe-mail.net
-
Joel FALCOU
-
Steven Watanabe