- Boost-users - lists.preview.boost.org

Fw: boost::enable_if : usage clarification
by Suresh T 08 Aug '05

08 Aug '05

hi There is a correction in my snippet that i attached for enable_if. The correct snippet is //primary class template <std::size_t size , template<std::size_t size,typename E = void > class USER_TYPE = select_type > class my_class { public: //Primary class //Note that the select_type is default for USER_TYPE }; //Specialized class template <std::size_t size , template<std::size_t size,typename E = void > class USER_TYPE > class my_class< size,SER_TYPE> { public: //The commented code line below does not work for VC7.1 // typedef typename USER_TYPE<size>::type data_type; //THIS DOES NOT WORK with vc7.1 typedef typename USER_TYPE<size,void>::type data_type; //THIS WORKS }; --------------------------------------------------------------------------------------------------------- Rgds ----- Forwarded by Suresh T/BTC/SC/PHILIPS on 08/08/2005 02:03 PM ----- hi I am using the boost::enable_if for selection of types. Something similar to below template<std::size_t Size,class Enable = void> struct type_select{ }; template<std::size_t Size> struct type_select< Size, typename boost::enable_if < bool_ < (size <= 8) > > >::type >{ typedef typename char type; }; template<std::size_t Size> struct type_select< Size, typename boost::enable_if < bool_ < (size > 8) > > >::type >{ typedef typename int type; }; The conditions are based on the first parameter size. The normal usage would be something like type_select<10>::type; My question is : If i explicitly use the second parameter ( by passing void) will the correct specialization be still used i.e, if i use say type_select<6,void>::type, will it resolve to "char" in the above case. Please note: I was using the normal way (without the void) for my code on linux+gcc without any problems My problem came up when i tried to move my code to windows + vc7.1. The vc7.1 compiler needs the second argument (in my usage shown below ) else it gives an error. The results are as desired, but i would like to know whether this usage is correct. Below is a snippet where the vc7.1 compiler gives a problem with the usage. Note type_select is not directly used but is used as a default type for USER_TYPE parameter template <std::size_t size , template<std::size_t size,typename E = void > class USER_TYPE > class my_class < size, USER_TYPE = select_type //select_type is a default parameter > { public: //The commented code line below does not work for VC7.1 // typedef typename USER_TYPE<size>::type data_type; //THIS DOES NOT WORK with vc7.1 typedef typename USER_TYPE<size,void>::type data_type; //THIS WORKS }; Thanks for clarification in advance.. --------------------------------------------------------------------------------------------------------- Rgds, Suresh

1 0

boost::enable_if : usage clarification
by Suresh T 08 Aug '05

08 Aug '05

hi I am using the boost::enable_if for selection of types. Something similar to below template<std::size_t Size,class Enable = void> struct type_select{ }; template<std::size_t Size> struct type_select< Size, typename boost::enable_if < bool_ < (size <= 8) > > >::type >{ typedef typename char type; }; template<std::size_t Size> struct type_select< Size, typename boost::enable_if < bool_ < (size > 8) > > >::type >{ typedef typename int type; }; The conditions are based on the first parameter size. The normal usage would be something like type_select<10>::type; My question is : If i explicitly use the second parameter ( by passing void) will the correct specialization be still used i.e, if i use say type_select<6,void>::type, will it resolve to "char" in the above case. Please note: I was using the normal way (without the void) for my code on linux+gcc without any problems My problem came up when i tried to move my code to windows + vc7.1. The vc7.1 compiler needs the second argument (in my usage shown below ) else it gives an error. The results are as desired, but i would like to know whether this usage is correct. Below is a snippet where the vc7.1 compiler gives a problem with the usage. Note type_select is not directly used but is used as a default type for USER_TYPE parameter template <std::size_t size , template<std::size_t size,typename E = void > class USER_TYPE > class my_class < size, USER_TYPE = select_type //select_type is a default parameter > { public: //The commented code line below does not work for VC7.1 // typedef typename USER_TYPE<size>::type data_type; //THIS DOES NOT WORK with vc7.1 typedef typename USER_TYPE<size,void>::type data_type; //THIS WORKS }; Thanks for clarification in advance.. --------------------------------------------------------------------------------------------------------- Rgds, Suresh

1 0

Re: [Boost-users] question: boost::array does not have compile time checked access
by Merrill Cornish 07 Aug '05

07 Aug '05

>>> the places where you would use fixed arrays, >>> you probably also know at what indexes certain data resides. If you use fixed arrays in that way, then you are using them much like structs where, say, [0] mean THIS and [1] means THAT and [2] means something else etc. If that were the case, then individually named variables would likely work better. The more common reason for fixed arrays is that the array is matching something in the real world: I'm doing a 256 element Fast Forier Transform, I'm processing census data for 50 US states, I'm tallying sales for the 12 months. Even if you can attach a specific meaning for individual elements, most of the processing is still done either by iterating over the array or by accessing an element based on an index number extracted from incoming data. In general rogramming the occassions where you would be accessing the array by a constant index is still very rare compared to accessing the elements by a variable index. Even if you did have an application where almost all of the array accesses were with constant indexes, then you would also certainly create a set of constants so that you would, say, extract the state name from an array of address strings by saying [WYOMING] rather than [49]. You set the constants up once and you're done. No more array bounds access errors. Even if the initial set of constant definitions had an error, once fixed, it's fixed forever. Again, the number of places where checking array bounds on fixed length arrays is too small to justify work involved. Merrill

2 1

Boost.Iostreams
by Steven T. Hatton 07 Aug '05

07 Aug '05

I just happened to open Konqueror to the root of a recent boost CVS, and discovered an HTML file with some information I've never seen before. Among that information was a link to the Boost.Iostreams library. I don't see any reference to it on the Boost homepage, and when I searched the site I didn't find much there. But I've found it elsewhere on the Internet. I'm confused as to the status of the library. Is it a continuing project? I sure hope so. -- Regards, Steven

2 3

[1.33.0] Release candidate #2 is available
by Douglas Gregor 07 Aug '05

07 Aug '05

Boost 1.33.0 release candidate #2 is now available at the usual place: http://www.osl.iu.edu/~dgregor/boost-1.33.0/ Please build it, test it, and report back to the mailing list. If no major problems are found before August 9th, this release candidate will become Boost 1.33.0. Doug Gregor 1.33.0 Release Manager

1 0

(no subject)
by Mikhail Kupchik 07 Aug '05

07 Aug '05

Hello All, I have a question regarding integration of Boost library into a project which uses SCons build system. We'd like to build Boost as static-linkable library under MSVC7.1 for Win32, and make it dependable on compiler options which are set from root of the project in SCons configuration file - like /GL (link-time code generation), /Og (global optimization) etc. What is the most simple way to do this? If we simple link all libs/src/*.cpp files into single static library, will it work? Are there any #defines, project-specific include dirs, project-specific compiler options etc? Maybe anyone already have similar experience and have SConscript files for Boost? -- Best regards, Mikhail mailto:Mikhail.Kupchik@prime-expert.com

2 1

concept_check question.
by sr kumar 07 Aug '05

07 Aug '05

Hi, I am having trouble understanding why the following concept_check, which checks an inheritance relationship, doesn't work but the BOOST_STATIC_ASSERT does. Just to make sure that the concept does actually work, the LessThanComparableConcept was implemented and then commented out. Would appreciate getting the missing link in my understanding. thanks in advance for all help, -sr ------------------------------------------ #include <boost/static_assert.hpp> #include <boost/concept_check.hpp> #include <boost/type_traits.hpp> using namespace boost; template <typename T> struct MyConcept { void constraints() { (bool)(boost::is_base_and_derived<int,T>::value == true); // (bool)(a<b); } // T a,b; }; class X { public: X() { function_requires<MyConcept<X> > (); BOOST_STATIC_ASSERT( (is_base_and_derived<int,X>::value == true)); } ~X(){} // bool operator<(X& rhs) { return (x < rhs.x); } int x; }; int main() { return 0;}

2 1

Re: [Boost-users] question: boost::array does not have compile time checked access
by Merrill Cornish 07 Aug '05

07 Aug '05

>>> My point is only that one can add a compile time safe accessor to >>> this array. True. It could be added. But how often would it (could it) ever be used? Look through your source code. How often do you see an expression like arrayName[i] versus and expression like arrayName[257]? The compiler could check 257 against the declared array length, but not i. And yet, in most code you very seldom have any constant array indexes that could be checked at compile time. So, yes, it could be done. But if you had it, you would almost never find anyplace to use it. Merrill

2 1

1.33 pointer to object serialization
by Chris Coleman 07 Aug '05

07 Aug '05

Hi, I'm having trouble with serializing an object through a pointer to it. The code below works in 1.32, but in 1.33 it gives the errors below. I am using Mac OS X 10.4.2, gcc 4.0. I've had a look at the headers, but my template programming isn't good enough to make too much sense of them. It seems that there is a check to ensure T is not a pointer on line 549 of oserializer.hpp, which is the reason the static assert is failing? Is it correct that objects shouldn't be serializable by pointers to them, or not? Cheers Chris gps_position* p_g = new gps_position(35, 59, 24.567f); oa << p_g; // causes the error's below g++ -o test test.cpp -lboost_serialization-d-1_33 /usr/local/include/boost/archive/detail/oserializer.hpp: In function 'void boost::archive::save(Archive&, T&) [with Archive = boost::archive::text_oarchive, T = gps_position*]': /usr/local/include/boost/archive/basic_text_oarchive.hpp:78: instantiated from 'void boost::archive::basic_text_oarchive<Archive>::save_override(T&, int) [with T = gps_position*, Archive = boost::archive::text_oarchive]' /usr/local/include/boost/archive/detail/interface_oarchive.hpp:85: instantiated from 'Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = gps_position*, Archive = boost::archive::text_oarchive]' hash_test.cpp:130: instantiated from here /usr/local/include/boost/archive/detail/oserializer.hpp:560: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>' This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

4 14

Problem compiling regex lib.
by Thaddeus Olczyk 07 Aug '05

07 Aug '05

kept it simple: ------------------------ #include <boost/regex.hpp> int main(int argc,char argv[]) { return 1; } --------- So all it does is try to compile the headers for the regex lib. Here is the output. ------------------------------ g++ -I/cy/f/Programs/development/boost_1_32_0/nocygwin/include/boost-1_32 -ansi -pedantic -Wall -O2 -c main.cpp -o main.o In file included from /cy/f/Programs/development/boost_1_32_0/nocygwin/include/boost-1_32/boost/regex/regex_traits.hpp:32, from /cy/f/Programs/development/boost_1_32_0/nocygwin/include/boost-1_32/boost/regex/v4/regex.hpp:57, from /cy/f/Programs/development/boost_1_32_0/nocygwin/include/boost-1_32/boost/regex.hpp:34, from main.cpp:1: /cy/f/Programs/development/boost_1_32_0/nocygwin/include/boost-1_32/boost/regex/v4/regex_traits.hpp:827: error: overflow in constant expression /cy/f/Programs/development/boost_1_32_0/nocygwin/include/boost-1_32/boost/regex/v4/regex_traits.hpp:840: error: overflow in constant expression -- Thad

2 1