- Boost - lists.preview.boost.org

Library proposal: binconst, constant of the binary form.
by TaeKyeong Wang 16 Jan '09

16 Jan '09

C++ programmers want to input a constant of the binary form, like following. But, this is illegal in C++ world. unsigned char value = 0b10001010; There are some solutions of this lack. But, I can't find the gratifying answer. This proposal has following features. - whether digits is binary form - whether digits is octal or decimal of binary form - range of input octal or decimal number detection - output value is absolutely constant, no charge of resource (code, memory) at a run-time Usage: unsigned int td = BD_( 10101010, 00101100, 11110000, 00001111 ); // OK unsigned short tw = BW_( 00011000, 12345678 ); // Compile Error - invalid binary digit unsigned char tb1 = BB_( 0101 ); // OK. from octal unsigned char tb2 = BB_( 1010 ); // OK. from decimal unsigned char tb3 = BB_( 0111100001 ); // Compile Error - out of octal range unsigned char tb4 = BB_( 111100001 ); // Compile Error - out of decimal range Thanks. ---------- binconst.h template<int> struct CompileTimeCheck; template<> struct CompileTimeCheck<true> { }; /** Determines whether N is octal digits of the binary form. ex 1) octal_test< 0101 > == octal_test< 65 >, 65 % 8 == 1 octal_test< 0010 > == octal_test< 8 >, 8 % 8 == 1 octal_test< 0001 > == octal_test< 1 >, 1 % 8 == 1 octal_test< 0000 > == octal_test< 0 >, 0 % 8 == 0 ex 2) octal_test< 0120 > == octal_test< 80 >, 80 % 8 == 0 octal_test< 0012 > == octal_test< 10 >, 10 % 8 == 2 <--- invalid digit detected!!! octal_test< 0001 > == octal_test< 1 >, 1 % 8 == 1 octal_test< 0000 > == octal_test< 0 >, 0 % 8 == 0 */ template< unsigned int N > struct octal_test { enum { is_octal = (N % 8 <= 1) & octal_test< N / 8 >::is_octal }; }; /** end recursive */ template<> struct octal_test< 0 > { enum { is_octal = 1 }; }; /** Determines whether N is decimal digits of the binary form. */ template< unsigned int N > struct decimal_test { enum { is_decimal = (N % 10 <= 1) & decimal_test< N / 10 >::is_decimal, }; }; /** end recursive */ template<> struct decimal_test< 0 > { enum { is_decimal = 1 }; }; /** Convert octal digits of the binary form to a binary number. */ template< unsigned int N > struct binary_octal { enum { value = N % 8 + 2 * binary_octal< N / 8 >::value }; }; /** end recursive */ template<> struct binary_octal< 0 > { enum { value = 0 }; }; /** Convert decimal digits of the binary form to a binary number. */ template< unsigned int N > struct binary_decimal { enum { value = N % 10 + 2 * binary_decimal< N / 10 >::value }; }; /** end recursive */ template<> struct binary_decimal< 0 > { enum { value = 0 }; }; /** one byte */ template< unsigned int B0 > struct binary_byte { enum { is_octal = octal_test< B0 >::is_octal, is_decimal = decimal_test< B0 >::is_decimal }; static const unsigned int value = is_decimal ? binary_decimal< B0 >::value : binary_octal< B0 >::value; CompileTimeCheck< is_octal * B0 <= 011111111 > Out_Of_Range_Octal; CompileTimeCheck< is_decimal * B0 <= 11111111 > Out_Of_Range_Decimal; CompileTimeCheck< is_octal | is_decimal > Invalid_Binary_Digit; }; /** two bytes */ template< unsigned int B1, unsigned int B0 > struct binary_word { static const unsigned int value = (binary_byte< B1 >::value << 8) + (binary_byte< B0 >::value); }; /** four bytes */ template< unsigned int B3, unsigned int B2, unsigned int B1, unsigned int B0 > struct binary_dword { static const unsigned int value = (binary_word< B3, B2>::value << 16) + binary_word< B1, B0 >::value; }; #define BB_( b0 ) \ binary_byte< b0 >::value #define BW_( b1, b0 ) \ binary_word< b1, b0 >::value #define BD_( b3, b2, b1, b0 ) \ binary_dword< b3, b2, b1, b0 >::value ---------- binconst_test.cpp #include "binconst.h" const unsigned int testd = BD_( 11111111, 00000000, 00000000, 00000101 ); #define CHECK( c ) \ { \ CompileTimeCheck< (c) > error; \ (void)error; \ } int main() { /* Generated assembly code Visual C++ 2008 Express Edition mov DWORD PTR _bd$[ebp], -16777211 ; ff000005H g++ (GCC) 4.2.1 20070719 [FreeBSD] movl $-16777211, -4(%ebp) */ dword bd = BD_( 11111111, 00000000, 00000000, 00000101 ); CHECK( BD_( 11111111, 00000000, 00000000, 00000101 ) == 0XFF000005 ); CHECK( BB_( 0 ) == 0x0 ); CHECK( BB_( 1 ) == 0x1 ); CHECK( BB_( 00 ) == 0x0 ); CHECK( BB_( 01 ) == 0x1 ); CHECK( BB_( 10 ) == 0x2 ); CHECK( BB_( 11 ) == 0x3 ); CHECK( BB_( 000 ) == 0x0 ); CHECK( BB_( 001 ) == 0x1 ); CHECK( BB_( 010 ) == 0x2 ); CHECK( BB_( 011 ) == 0x3 ); CHECK( BB_( 100 ) == 0x4 ); CHECK( BB_( 101 ) == 0x5 ); CHECK( BB_( 110 ) == 0x6 ); CHECK( BB_( 111 ) == 0x7 ); CHECK( BB_( 0000 ) == 0x0 ); CHECK( BB_( 0001 ) == 0x1 ); CHECK( BB_( 0010 ) == 0x2 ); CHECK( BB_( 0011 ) == 0x3 ); CHECK( BB_( 0100 ) == 0x4 ); CHECK( BB_( 0101 ) == 0x5 ); CHECK( BB_( 0110 ) == 0x6 ); CHECK( BB_( 0111 ) == 0x7 ); CHECK( BB_( 1000 ) == 0x8 ); CHECK( BB_( 1001 ) == 0x9 ); CHECK( BB_( 1010 ) == 0xA ); CHECK( BB_( 1011 ) == 0xB ); CHECK( BB_( 1100 ) == 0xC ); CHECK( BB_( 1101 ) == 0xD ); CHECK( BB_( 1110 ) == 0xE ); CHECK( BB_( 1111 ) == 0xF ); CHECK( BB_( 00000000 ) == 0x00 ); CHECK( BB_( 00000001 ) == 0x01 ); CHECK( BB_( 00000010 ) == 0x02 ); CHECK( BB_( 00000011 ) == 0x03 ); CHECK( BB_( 00000100 ) == 0x04 ); CHECK( BB_( 00000101 ) == 0x05 ); CHECK( BB_( 00000110 ) == 0x06 ); CHECK( BB_( 00000111 ) == 0x07 ); CHECK( BB_( 00001000 ) == 0x08 ); CHECK( BB_( 00001001 ) == 0x09 ); CHECK( BB_( 00001010 ) == 0x0A ); CHECK( BB_( 00001011 ) == 0x0B ); CHECK( BB_( 00001100 ) == 0x0C ); CHECK( BB_( 00001101 ) == 0x0D ); CHECK( BB_( 00001110 ) == 0x0E ); CHECK( BB_( 00001111 ) == 0x0F ); CHECK( BB_( 00010000 ) == 0x10 ); CHECK( BB_( 00010001 ) == 0x11 ); CHECK( BB_( 00010010 ) == 0x12 ); CHECK( BB_( 00010011 ) == 0x13 ); CHECK( BB_( 00010100 ) == 0x14 ); CHECK( BB_( 00010101 ) == 0x15 ); CHECK( BB_( 00010110 ) == 0x16 ); CHECK( BB_( 00010111 ) == 0x17 ); CHECK( BB_( 00011000 ) == 0x18 ); CHECK( BB_( 00011001 ) == 0x19 ); CHECK( BB_( 00011010 ) == 0x1A ); CHECK( BB_( 00011011 ) == 0x1B ); CHECK( BB_( 00011100 ) == 0x1C ); CHECK( BB_( 00011101 ) == 0x1D ); CHECK( BB_( 00011110 ) == 0x1E ); CHECK( BB_( 00011111 ) == 0x1F ); CHECK( BB_( 00100000 ) == 0x20 ); CHECK( BB_( 00100001 ) == 0x21 ); CHECK( BB_( 00100010 ) == 0x22 ); CHECK( BB_( 00100011 ) == 0x23 ); CHECK( BB_( 00100100 ) == 0x24 ); CHECK( BB_( 00100101 ) == 0x25 ); CHECK( BB_( 00100110 ) == 0x26 ); CHECK( BB_( 00100111 ) == 0x27 ); CHECK( BB_( 00101000 ) == 0x28 ); CHECK( BB_( 00101001 ) == 0x29 ); CHECK( BB_( 00101010 ) == 0x2A ); CHECK( BB_( 00101011 ) == 0x2B ); CHECK( BB_( 00101100 ) == 0x2C ); CHECK( BB_( 00101101 ) == 0x2D ); CHECK( BB_( 00101110 ) == 0x2E ); CHECK( BB_( 00101111 ) == 0x2F ); CHECK( BB_( 00110000 ) == 0x30 ); CHECK( BB_( 00110001 ) == 0x31 ); CHECK( BB_( 00110010 ) == 0x32 ); CHECK( BB_( 00110011 ) == 0x33 ); CHECK( BB_( 00110100 ) == 0x34 ); CHECK( BB_( 00110101 ) == 0x35 ); CHECK( BB_( 00110110 ) == 0x36 ); CHECK( BB_( 00110111 ) == 0x37 ); CHECK( BB_( 00111000 ) == 0x38 ); CHECK( BB_( 00111001 ) == 0x39 ); CHECK( BB_( 00111010 ) == 0x3A ); CHECK( BB_( 00111011 ) == 0x3B ); CHECK( BB_( 00111100 ) == 0x3C ); CHECK( BB_( 00111101 ) == 0x3D ); CHECK( BB_( 00111110 ) == 0x3E ); CHECK( BB_( 00111111 ) == 0x3F ); CHECK( BB_( 01000000 ) == 0x40 ); CHECK( BB_( 01000001 ) == 0x41 ); CHECK( BB_( 01000010 ) == 0x42 ); CHECK( BB_( 01000011 ) == 0x43 ); CHECK( BB_( 01000100 ) == 0x44 ); CHECK( BB_( 01000101 ) == 0x45 ); CHECK( BB_( 01000110 ) == 0x46 ); CHECK( BB_( 01000111 ) == 0x47 ); CHECK( BB_( 01001000 ) == 0x48 ); CHECK( BB_( 01001001 ) == 0x49 ); CHECK( BB_( 01001010 ) == 0x4A ); CHECK( BB_( 01001011 ) == 0x4B ); CHECK( BB_( 01001100 ) == 0x4C ); CHECK( BB_( 01001101 ) == 0x4D ); CHECK( BB_( 01001110 ) == 0x4E ); CHECK( BB_( 01001111 ) == 0x4F ); CHECK( BB_( 01010000 ) == 0x50 ); CHECK( BB_( 01010001 ) == 0x51 ); CHECK( BB_( 01010010 ) == 0x52 ); CHECK( BB_( 01010011 ) == 0x53 ); CHECK( BB_( 01010100 ) == 0x54 ); CHECK( BB_( 01010101 ) == 0x55 ); CHECK( BB_( 01010110 ) == 0x56 ); CHECK( BB_( 01010111 ) == 0x57 ); CHECK( BB_( 01011000 ) == 0x58 ); CHECK( BB_( 01011001 ) == 0x59 ); CHECK( BB_( 01011010 ) == 0x5A ); CHECK( BB_( 01011011 ) == 0x5B ); CHECK( BB_( 01011100 ) == 0x5C ); CHECK( BB_( 01011101 ) == 0x5D ); CHECK( BB_( 01011110 ) == 0x5E ); CHECK( BB_( 01011111 ) == 0x5F ); CHECK( BB_( 01100000 ) == 0x60 ); CHECK( BB_( 01100001 ) == 0x61 ); CHECK( BB_( 01100010 ) == 0x62 ); CHECK( BB_( 01100011 ) == 0x63 ); CHECK( BB_( 01100100 ) == 0x64 ); CHECK( BB_( 01100101 ) == 0x65 ); CHECK( BB_( 01100110 ) == 0x66 ); CHECK( BB_( 01100111 ) == 0x67 ); CHECK( BB_( 01101000 ) == 0x68 ); CHECK( BB_( 01101001 ) == 0x69 ); CHECK( BB_( 01101010 ) == 0x6A ); CHECK( BB_( 01101011 ) == 0x6B ); CHECK( BB_( 01101100 ) == 0x6C ); CHECK( BB_( 01101101 ) == 0x6D ); CHECK( BB_( 01101110 ) == 0x6E ); CHECK( BB_( 01101111 ) == 0x6F ); CHECK( BB_( 01110000 ) == 0x70 ); CHECK( BB_( 01110001 ) == 0x71 ); CHECK( BB_( 01110010 ) == 0x72 ); CHECK( BB_( 01110011 ) == 0x73 ); CHECK( BB_( 01110100 ) == 0x74 ); CHECK( BB_( 01110101 ) == 0x75 ); CHECK( BB_( 01110110 ) == 0x76 ); CHECK( BB_( 01110111 ) == 0x77 ); CHECK( BB_( 01111000 ) == 0x78 ); CHECK( BB_( 01111001 ) == 0x79 ); CHECK( BB_( 01111010 ) == 0x7A ); CHECK( BB_( 01111011 ) == 0x7B ); CHECK( BB_( 01111100 ) == 0x7C ); CHECK( BB_( 01111101 ) == 0x7D ); CHECK( BB_( 01111110 ) == 0x7E ); CHECK( BB_( 01111111 ) == 0x7F ); CHECK( BB_( 10000000 ) == 0x80 ); CHECK( BB_( 10000001 ) == 0x81 ); CHECK( BB_( 10000010 ) == 0x82 ); CHECK( BB_( 10000011 ) == 0x83 ); CHECK( BB_( 10000100 ) == 0x84 ); CHECK( BB_( 10000101 ) == 0x85 ); CHECK( BB_( 10000110 ) == 0x86 ); CHECK( BB_( 10000111 ) == 0x87 ); CHECK( BB_( 10001000 ) == 0x88 ); CHECK( BB_( 10001001 ) == 0x89 ); CHECK( BB_( 10001010 ) == 0x8A ); CHECK( BB_( 10001011 ) == 0x8B ); CHECK( BB_( 10001100 ) == 0x8C ); CHECK( BB_( 10001101 ) == 0x8D ); CHECK( BB_( 10001110 ) == 0x8E ); CHECK( BB_( 10001111 ) == 0x8F ); CHECK( BB_( 10010000 ) == 0x90 ); CHECK( BB_( 10010001 ) == 0x91 ); CHECK( BB_( 10010010 ) == 0x92 ); CHECK( BB_( 10010011 ) == 0x93 ); CHECK( BB_( 10010100 ) == 0x94 ); CHECK( BB_( 10010101 ) == 0x95 ); CHECK( BB_( 10010110 ) == 0x96 ); CHECK( BB_( 10010111 ) == 0x97 ); CHECK( BB_( 10011000 ) == 0x98 ); CHECK( BB_( 10011001 ) == 0x99 ); CHECK( BB_( 10011010 ) == 0x9A ); CHECK( BB_( 10011011 ) == 0x9B ); CHECK( BB_( 10011100 ) == 0x9C ); CHECK( BB_( 10011101 ) == 0x9D ); CHECK( BB_( 10011110 ) == 0x9E ); CHECK( BB_( 10011111 ) == 0x9F ); CHECK( BB_( 10100000 ) == 0xA0 ); CHECK( BB_( 10100001 ) == 0xA1 ); CHECK( BB_( 10100010 ) == 0xA2 ); CHECK( BB_( 10100011 ) == 0xA3 ); CHECK( BB_( 10100100 ) == 0xA4 ); CHECK( BB_( 10100101 ) == 0xA5 ); CHECK( BB_( 10100110 ) == 0xA6 ); CHECK( BB_( 10100111 ) == 0xA7 ); CHECK( BB_( 10101000 ) == 0xA8 ); CHECK( BB_( 10101001 ) == 0xA9 ); CHECK( BB_( 10101010 ) == 0xAA ); CHECK( BB_( 10101011 ) == 0xAB ); CHECK( BB_( 10101100 ) == 0xAC ); CHECK( BB_( 10101101 ) == 0xAD ); CHECK( BB_( 10101110 ) == 0xAE ); CHECK( BB_( 10101111 ) == 0xAF ); CHECK( BB_( 10110000 ) == 0xB0 ); CHECK( BB_( 10110001 ) == 0xB1 ); CHECK( BB_( 10110010 ) == 0xB2 ); CHECK( BB_( 10110011 ) == 0xB3 ); CHECK( BB_( 10110100 ) == 0xB4 ); CHECK( BB_( 10110101 ) == 0xB5 ); CHECK( BB_( 10110110 ) == 0xB6 ); CHECK( BB_( 10110111 ) == 0xB7 ); CHECK( BB_( 10111000 ) == 0xB8 ); CHECK( BB_( 10111001 ) == 0xB9 ); CHECK( BB_( 10111010 ) == 0xBA ); CHECK( BB_( 10111011 ) == 0xBB ); CHECK( BB_( 10111100 ) == 0xBC ); CHECK( BB_( 10111101 ) == 0xBD ); CHECK( BB_( 10111110 ) == 0xBE ); CHECK( BB_( 10111111 ) == 0xBF ); CHECK( BB_( 11000000 ) == 0xC0 ); CHECK( BB_( 11000001 ) == 0xC1 ); CHECK( BB_( 11000010 ) == 0xC2 ); CHECK( BB_( 11000011 ) == 0xC3 ); CHECK( BB_( 11000100 ) == 0xC4 ); CHECK( BB_( 11000101 ) == 0xC5 ); CHECK( BB_( 11000110 ) == 0xC6 ); CHECK( BB_( 11000111 ) == 0xC7 ); CHECK( BB_( 11001000 ) == 0xC8 ); CHECK( BB_( 11001001 ) == 0xC9 ); CHECK( BB_( 11001010 ) == 0xCA ); CHECK( BB_( 11001011 ) == 0xCB ); CHECK( BB_( 11001100 ) == 0xCC ); CHECK( BB_( 11001101 ) == 0xCD ); CHECK( BB_( 11001110 ) == 0xCE ); CHECK( BB_( 11001111 ) == 0xCF ); CHECK( BB_( 11010000 ) == 0xD0 ); CHECK( BB_( 11010001 ) == 0xD1 ); CHECK( BB_( 11010010 ) == 0xD2 ); CHECK( BB_( 11010011 ) == 0xD3 ); CHECK( BB_( 11010100 ) == 0xD4 ); CHECK( BB_( 11010101 ) == 0xD5 ); CHECK( BB_( 11010110 ) == 0xD6 ); CHECK( BB_( 11010111 ) == 0xD7 ); CHECK( BB_( 11011000 ) == 0xD8 ); CHECK( BB_( 11011001 ) == 0xD9 ); CHECK( BB_( 11011010 ) == 0xDA ); CHECK( BB_( 11011011 ) == 0xDB ); CHECK( BB_( 11011100 ) == 0xDC ); CHECK( BB_( 11011101 ) == 0xDD ); CHECK( BB_( 11011110 ) == 0xDE ); CHECK( BB_( 11011111 ) == 0xDF ); CHECK( BB_( 11100000 ) == 0xE0 ); CHECK( BB_( 11100001 ) == 0xE1 ); CHECK( BB_( 11100010 ) == 0xE2 ); CHECK( BB_( 11100011 ) == 0xE3 ); CHECK( BB_( 11100100 ) == 0xE4 ); CHECK( BB_( 11100101 ) == 0xE5 ); CHECK( BB_( 11100110 ) == 0xE6 ); CHECK( BB_( 11100111 ) == 0xE7 ); CHECK( BB_( 11101000 ) == 0xE8 ); CHECK( BB_( 11101001 ) == 0xE9 ); CHECK( BB_( 11101010 ) == 0xEA ); CHECK( BB_( 11101011 ) == 0xEB ); CHECK( BB_( 11101100 ) == 0xEC ); CHECK( BB_( 11101101 ) == 0xED ); CHECK( BB_( 11101110 ) == 0xEE ); CHECK( BB_( 11101111 ) == 0xEF ); CHECK( BB_( 11110000 ) == 0xF0 ); CHECK( BB_( 11110001 ) == 0xF1 ); CHECK( BB_( 11110010 ) == 0xF2 ); CHECK( BB_( 11110011 ) == 0xF3 ); CHECK( BB_( 11110100 ) == 0xF4 ); CHECK( BB_( 11110101 ) == 0xF5 ); CHECK( BB_( 11110110 ) == 0xF6 ); CHECK( BB_( 11110111 ) == 0xF7 ); CHECK( BB_( 11111000 ) == 0xF8 ); CHECK( BB_( 11111001 ) == 0xF9 ); CHECK( BB_( 11111010 ) == 0xFA ); CHECK( BB_( 11111011 ) == 0xFB ); CHECK( BB_( 11111100 ) == 0xFC ); CHECK( BB_( 11111101 ) == 0xFD ); CHECK( BB_( 11111110 ) == 0xFE ); CHECK( BB_( 11111111 ) == 0xFF ); return 0; }

4 5

[mp_math] Wrong sign for mp_int<> after addition.
by Jeroen N. Witmond 16 Jan '09

16 Jan '09

Greetings, I posted this in the Boost Users list last Sunday, but on second throught perhaps I'd beter post it here. I've stumbled across a problem in mp_math in the sandbox, revision 50541. The code below (a Boost.Test test case) demonstrates that the problem is present only for mp_int<> and not for int. The message I get is wrong-value.cpp(16): error in "Mixed_integers<N5boost7mp_math6mp_intISaIvENS0_13mp_int_traitsIjyEEEE>": check j == 4 failed [-4 != 4] Regards, Jeroen. #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MODULE Wrong_sign #include <boost/test/unit_test.hpp> #include <boost/mp_math/mp_int.hpp> #include <boost/mpl/list.hpp> typedef boost::mpl::list< int, boost::mp_math::mp_int<> > test_types; BOOST_AUTO_TEST_CASE_TEMPLATE( Mixed_integers, Type, test_types ) { Type i(-1); BOOST_CHECK_EQUAL(i, -1); Type j = i + 5; BOOST_CHECK_EQUAL(j, 4); // Line 16. }

2 2

Serialization Link Error
by Venkata (Ravi) Adusumilli 16 Jan '09

16 Jan '09

Hi, BOOST: 1.37 Linux version 2.6.9-efsm (root@vizzini) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)) #3 SMP Mon Dec 4 13:14:15 CST 2006 I recieve the following link error: *undefined reference to `void CommandRequest::serialize<boost::archive::xml_iarchive>(boost::archive::xml_iarchive&, unsigned int)'* while compiling the following class: ======H====== #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/shared_ptr.hpp> class CommandRequest { public: CommandRequest(); CommandRequest(int requestID, int commandType); ~CommandRequest(); int requestID() const; int commandType() const; protected: int requestIDM; int commandTypeM; friend class boost::serialization::access; template<class A> void serialize(A& archive, const unsigned int); }; BOOST_SERIALIZATION_SHARED_PTR(CommunicationObjects::CommandRequest) ======CPP====== CommandRequest::CommandRequest() : requestIDM(0), commandTypeM(0) { } CommandRequest::CommandRequest(int requestID, int commandType) : requestIDM(requestID), commandTypeM(commandType) { } CommandRequest::~CommandRequest() { } int CommandRequest::requestID() const { return requestIDM; } int CommandRequest::commandType() const { return commandTypeM; } template<class A> void CommandRequest::serialize(A & archive, const unsigned int /* version */) { archive & requestIDM; archive & commandTypeM; } template void CommandRequest::serialize<boost::archive::text_oarchive>(boost::archive::text_oarchive& archive, const unsigned int version); template void CommandRequest::serialize<boost::archive::text_iarchive>(boost::archive::text_iarchive& archive, const unsigned int version); Please let me know if you can help me out. -- Thank You, Venkata (Ravi) Adusumilli ------------------------------------------------- "A happy New Year! Grant that I May bring no tear to any eye When this New Year in time shall end Let it be said I've played the friend, Have lived and loved and labored here, And made of it a happy year." ~ Edgar Guest -------------------------------------------------

3 4

Extra functions for filesystem
by Walter Landry 16 Jan '09

16 Jan '09

Greetings, A long, long time ago, I proposed adding a few more convenience functions to filesystem. http://lists.boost.org/Archives/boost/2006/08/109740.php Despite a positive response and a followup patch, those functions never got incorporated. Did it just fall through the cracks, or was there a more substantive reason those functions never got added? Otherwise, it does not seem possible to implement "cp -a". Thanks, Walter Landry wlandry(a)caltech.edu

3 3

[proto] subscript_wrapper and templated operator[]
by David Deakins 15 Jan '09

15 Jan '09

While using proto with some classes that have a templated operator[] on VC8 and VC9, I have run into a '2 overloads have similar conversions' ambiguity error (C2666). The problem seems to be with subscript_wrapper in detail/decltype.hpp, where neither the templated operator[] from the original class nor the fallback 'any operator[](any)' function in subscript_wrapper have priority. Any thoughts on how to tweak subscript_wrapper so that the 'any operator[](any)' function looks like a worse match than the templated operator[] and thus prevents the ambiguity? I attached a small test case that reproduces the problem. Also, for reference, I am using the proto code from the release branch as of a couple days ago (~12 Jan 2009). Thanks, -Dave #include <boost/proto/proto.hpp> using namespace boost; struct Abc { template <typename T> void operator[](T const & t) { } }; template< typename Expr > void evaluate( Expr const & expr ) { proto::default_context ctx; proto::eval(expr, ctx); } int main() { Abc a; evaluate( proto::lit(a) [ 0 ] ); return 0; }

2 3

Futures - Reviews Needed (January 5, 2009)
by Tom Brinkman 15 Jan '09

15 Jan '09

>> Is the expected result of the review to choose a library (or none) or to >> create a third library that is a mixture of the two? I have no expectations about the results. I'm interested to hear your views and those of the authors about how to proceed.

3 2

[1.38.0] Regression test failures
by Beman Dawes 15 Jan '09

15 Jan '09

The reporting has been fixed and tests are starting to cycle. See http://beta.boost.org/development/tests/release/developer/summary.html There are failures on build, config, integer, ptr_container, serialization, and spirit. Please take a look if any of these are your library. Thanks, --Beman

3 3

Are you a C++ guru - prove it here !
by Robert Ramey 15 Jan '09

15 Jan '09

I'm having problems with the following code below from boost/serialization/export.hpp compiling BOOST_CLASS_EXPORT_GUID(final, "final") results in the following error message on the gcc compilers. error: too few template-parameter-lists VC compilers don't complain about this. I've tried replacing ::boost::archive::detail::init_guid< T >::guid_initializer = \ with ::boost::archive::detail::init_guid< T >::guid_initializer< T> =\ But this doesn't help. Happy to get help from any C++ guru Robert Ramey template<typename T> class init_guid { static ::boost::archive::detail::guid_initializer<T> const & guid_initializer; }; } // namespace detail } // namespace archive } // namespace boost #define BOOST_CLASS_EXPORT_GUID(T, K) \ ::boost::archive::detail::guid_initializer< T > const & \ ::boost::archive::detail::init_guid< T >::guid_initializer = \ ::boost::serialization::singleton< \ ::boost::archive::detail::guid_initializer< T > \ >::get_mutable_instance().export_guid(K); \

3 3

[LibrariesUnderConstruction] new gil io extension
by Christian Henning 14 Jan '09

14 Jan '09

Hi there, I just found out about the LibrariesUnderConstruction wiki. Is it possible to add an entry for the upcoming new boost::gil io extension. The current version is stable and can be used without any problems. In fact, I'm and other people are using the code in several projects. Right now, I'm working on the documentation. If possible please add the following entry. == Boost.GIL.IO == * '''Author(s): Christian Henning [mailto:chhenning-AT-gmail.com>''' * '''Version:''' * '''State:''' Stable * '''Last upload:''' 2009 Jan 14 * '''Links:''' [http://gil-contributions.googlecode.com/svn/trunk/gil_2] ( svn repository ) * '''Description:'''IO extension for boost::gil which allows reading and writing of/in image formats ( tiff, jpeg, ... ). Thanks, Christian

2 1

Re: [boost] [LibrariesUnderConstruction] update of LibrariesUnderConstruction wiki page
by vicente.botet 14 Jan '09

14 Jan '09

Hi, The wiki page Libraries Under Construction contains now much more entries. Good trip, Vicente ----- Original Message ----- From: "vicente.botet" <vicente.botet(a)wanadoo.fr> To: <boost(a)lists.boost.org>; <boost-announce(a)lists.boost.org>; <boost-users(a)lists.boost.org> Sent: Sunday, December 07, 2008 5:50 PM Subject: [LibrariesUnderConstruction] new LibrariesUnderConstruction wiki page Hi, I have created a new wiki page containing some of the libraries under construction for Boost. You can access this page from the Boost Trac wiki https://svn.boost.org/trac/boost/wiki > Projects > Libraries Under Construction or directly https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction The contents of this page is by nature incomplete and outdated. Please help to maintain this page updated by modifying it directly (if you have the rights) or posting on the Boost mailing lists boost(a)lists.boost.org or boost-users(a)lists.boost.org with the prefix [LibrariesUnderConstruction]. If you're the author of one of these libraries and desire that all or part of the information related to your library be removed or modified, please send a mail or you can do it directly if you prefer. If you're a library author and plan on submitting a library but don't know when it will be ready for review, and you want to include your library in this list, please add it directly (if you have the rights) or send a mail. If you're a library author and plan on submitting a library for review in the next 3-6 months, email Ron Garcia or John Phillips ("garcia at osl dot iu dot edu" and "phillips at mps dot ohio-state dot edu" respectively) a short description of your library and they will add it to the Review Wizard Report Libraries Under Construction section. HTH, Vicente

1 0

[interthreads] Library under development v0.2
by vicente.botet 14 Jan '09

14 Jan '09

Hi, I have added the threader/joiner classes following the design of Kevlin Henney N1833 - Preliminary Threading Library Proposal for TR2 (http:/www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1883.pdf). I use the Boost.Futures library from Anthony (review ongoing) In addition and as a generalization of these classes I have started a framework working with asynchronous executors -AE (threader) and asynchronous completion tokens -ACT (joiner). The library include also an launcher (AE) associated to the unique_future (ACT) which is the equivalent of the thread_pool in N2276 - Thread Pools and Futures (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2276.html) With some minor changes in the ThreadPool library (review scheduled), the tp:pool can be seen as a AE and the tp::task as a ACT. The library allows also to fork several functions at the same time. The result of the fork_all operation is a fusion tuple of asynchronous completion token handles. The user can apply any fusion algorithm on this tuple as for example. To make common tasks easier the library provide some functors and some functions that are the result of applying these functors to the tuple using a fusion algorithm. Last the library provides also some functions like wait_for_all that forks all the functions and wait for the result of all of them and wait_for_any which works with functions that return the same type, and forks all the functions and wait for the first one. For the moment the AE/ACT framework is included it in Bosst.InterThreads library, but this is independent and can be included in an independent library (any suggestion for a name and a namespace?) The library is available at Boost Sandbox: https://svn.boost.org/svn/boost/sandbox/interthreads and Boost Vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=intert… Includes every thing on the Sandbox + Html documentation + Boost.Futures + Boost.ThreadPool adaptations I'd appreciate it if people could take a look, test it on their compiler and give me some feedback. It's not quite ready for formal review yet. Best regrads, Vicente _____________________ Vicente Juan Botet Escribá

1 0

[mpl] sequence_tag
by Eric Niebler 14 Jan '09

14 Jan '09

A type is an mpl sequence if mpl::sequence_tag<T>::type is something other than mpl::non_sequence_tag. There are a few ways of hooking mpl::sequence_tag, but the easiest is for T to have a nested typedef named "tag". I find this unfortunate. Consider proto expression types, which, in addition to being nodes in expression trees, are also both fusion sequences and mpl sequences. A proto expression type has three tag types associated with it: 1) The Proto tag (e.g., proto::tag::plus), a nested typedef named "proto_tag" 2) The Fusion tag, a nested typedef named "fusion_tag" 3) The MPL tag I can't in good conscience use a nested typedef named "tag" for the MPL tag because that would lead to confusion. It would be nice if MPL had instead chosen the name "mpl_tag" for its tag type. It's not too late to make the change ... MPL could first look for "mpl_tag" before falling back on "tag". For now, I have chosen to specialize mpl::sequence_tag for the proto::expr type. This is an incomplete solution because types that extend proto::expr are not themselves automatically MPL sequences. Another solution might be to allow SFINAE on sequence_tag, like ... template<typename T, typename EnableIf = void> struct sequence_tag; That way I could partially specialize for proto expression types, like: template<typename T, typename enable_if<proto::is_expr<T> >::type> struct sequence_tag { ... Thoughts? FWIW, I'd prefer MPL to rename the nested tag typedef to "mpl_tag". -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 5

[linux drivers] Is it possible to use boost in a Linux driver?
by Sid Sacek 14 Jan '09

14 Jan '09

Does anybody know if it's possible to use boost within a Linux driver?

8 13

[tr1] Help needed with Darwin port
by John Maddock 14 Jan '09

14 Jan '09

Can someone with access to various flavours of gcc-4.x on Darwin let me know what directory the glibc++ std lib headers are in? Currently Boost.TR1 is using #include <../c++/header_name> which is taken from STLPort's configuration, but is apparently causing regressions in the boost code, Thanks, John.

4 10

[scope_exit] Doesn't included in Boost yet?
by Dmitriy Maksimov 14 Jan '09

14 Jan '09

Hi, I didn't found boost::scope_exit library in Boost 1.37 althougth the library approved in May 2008. Why? Kind regards, Dmitriy

6 15

Re: [boost] [lexical_cast] A suggestion
by Andrew Troschinetz 14 Jan '09

14 Jan '09

Alexander Nasonov <alnsn <at> yandex.ru> writes: > This looks interesting but boost::optional<T> is already > InputStreamable: > #include <boost/optional/optional_io.hpp> This sounded really cool to me so I attempted a cursory hack to get this working. The only way I could figure out how to provide an override for optional<T> that never throws was to change detail::lexical_cast from a function to a struct to get partial template specialization. Maybe there is a better way, I'm new at this. It seems like there must be because I wound up with lots of almost- duplicated code. Here's the old familiar detail::lexical_cast, structified: And here's the optional<T> specialization: Initially this didn't work however. I traced it to what might be a bug in optional_io.hpp's insertion operator: if ( in.good() ) { int d = in.get(); if ( d == ' ' ) /* assuming a space in stream, what if there's not? */ { T x ; in >> x; v = x ; } else v = optional<T>() ; } return in; With the above insertion operator code, this would fail: istringstream si ("test"); optional<string> o; si >> o; assert (o); /* fails, would work if si were constructed with " test" instead */ That seems wrong to my thinking, but maybe there's a reason for the if (d == ' ') test? If the intent was to simply eat up spare white space, how about this instead: if (in) { T x; if (in >> std::ws >> x) v = x; else v = optional<T>(); } return in; Using that code in optional_io.hpp, and with the above changes, things work out just fine: int invalid_as_uint = -1; int valid_as_uint = 5; unsigned default_uint = 6; // Normal form, throws. try { unsigned i = lexical_cast<unsigned> (invalid_as_uint); cout << i << endl; } catch (const bad_lexical_cast&) { cout << "bad lexical cast error" << endl; } // Overload for lexical_cast<optional<T>>, does not throw. optional<unsigned> i = lexical_cast<optional<unsigned> > (invalid_as_uint); if (i) cout << *i << endl; else cout << "invalid return value" << endl; i = lexical_cast<optional<unsigned> > (valid_as_uint); if (i) cout << *i << endl; else cout << "invalid return value" << endl; Also, I would love to see a fallback style lexical_cast for the same reasons Neil already mentioned. -- Andrew Troschinetz

1 0

MSVC9 SFINAE quirks?
by Simonson, Lucanus J 14 Jan '09

14 Jan '09

Is there some gotcha about metaprogramming with MSVC9? I recently finished my geometry library rewrite and found that I couldn't port it to windows because the SFINAE overloading of generic functions is viewed as ambiguous in the more complex cases, but was readily accepted by gcc and icc in linux. The following code compiles in recent versions of gcc, but fails in MSVC9 //simple SFINAE overload of foo works in both template <typename T> typename gtl_if<typename is_mutable_polygon_90_type<T>::type>::type foo(const T& t) { return gtl_yes(); } template <typename T> typename gtl_if<typename is_mutable_polygon_45_type<T>::type>::type foo(const T& t) { return gtl_yes(); } //metafunction wrapper around SFINAE to supply return type works in both template <typename T> typename requires_1<typename gtl_if<typename is_mutable_polygon_90_type<T>::type>::type, void>::type foo2(const T& t) { } template <typename T> typename requires_1<typename gtl_if<typename is_mutable_polygon_45_type<T>::type>::type, void>::type foo2(const T& t) { } //meta function wrapper around two checks works in gcc but not msvc9 // error C2668: 'gtl::foo4' : ambiguous call to overloaded function template <typename polygon_type, typename polygon_type_2> typename requires_1< typename gtl_if< typename gtl_and< typename is_mutable_polygon_90_type<polygon_type>::type, typename is_mutable_polygon_90_type<polygon_type_2>::type >::type>::type, polygon_type>::type foo4(polygon_type& polygon, const polygon_type_2& point) {return point;} template <typename polygon_type, typename polygon_type_2> typename requires_1< typename gtl_if< typename gtl_and< typename is_mutable_polygon_45_type<polygon_type>::type, typename is_mutable_polygon_45_type<polygon_type_2>::type >::type>::type, polygon_type>::type foo4(polygon_type& polygon, const polygon_type_2& point) {return point;} int main() { using namespace gtl; polygon_45_data<int> p45; foo(p45); foo2(p45); foo4(p45, p45); //error here //this works as expected and has no syntax error in msvc9 gtl_if<gtl_and< is_mutable_polygon_45_type<polygon_45_data<int> >::type, is_mutable_polygon_45_type<polygon_45_data<int> >::type >::type>::type a; //this works as expected, generating syntax error in msvc9 // error C2039: 'type' : is not a member of 'gtl::gtl_if<gtl::gtl_no> gtl_if<gtl_and< is_mutable_polygon_90_type<polygon_45_data<int> >::type, is_mutable_polygon_90_type<polygon_45_data<int> >::type >::type>::type b; Does someone like Steve Wanatabe with more experience with MS compilers know what I have inadvertently run afoul of and how to get myself out of this jam? Thanks, Luke

2 11

[mp_int] Incorrect comparison with native types
by Nathan Kitchen 13 Jan '09

13 Jan '09

When I create an negative mp_int outside the range of a native type and compare it to a number of that type, I get incorrect results. Here is an example to reproduce the behavior: #include <iostream> #include <limits> #include <boost/cstdint.hpp> #include <boost/mp_math/mp_int.hpp> using namespace boost::mp_math; using namespace std; int main() { int32_t MIN = numeric_limits<int32_t>::min(); mp_int<> a = MIN; cout << a << endl; a -= 1; // Should print "-2147483649 1" but prints "-2147483649 0" instead cout << a << ' ' << (a < MIN) << endl; return 0; }

2 7

1.38 release schedule
by John Maddock 13 Jan '09

13 Jan '09

Since there haven't been any announcements, do I correctly assume that the 1.38 schedule is likely to slip by a couple of weeks? Cheers, John.

2 1

Pondering Futures
by Tom Brinkman 13 Jan '09

13 Jan '09

Ponderings on the Futures Library: What is the status of Anthony Williams' submission of the futures library to the c++ standards committee? Is it more prudent to wait to find out what the c++ standards committe is going to do first, before adding a possibly incompatible version of the futures library to boost? One could ask, if Anthony's submission is approved by the c++ standards committe, what is the point of adding a "futures" library to boost as well? Is a seperate library needed? What is the advantage of having a root level library called boost::futures? Why would it not be perferable to just extend boost::thread with the additional capabiltity to handle "futures"? Futures are a very useful concept, and I have used them personally. The c++ commitee is correctly considering adding them to the standard. I would be interested in hearing the authors views on their "grand" vision for parallel programming in general and how their "futures" library submissions fit into this vision. tom brinkman

8 12

[fusion] mpl::is_sequence<fusion::vector<> >::type::value should work right?
by Dean Michael Berris 13 Jan '09

13 Jan '09

Hi Guys, I've tried the following minimal test with the latest in trunk and I get an error with GCC 4.2. #include <boost/fusion/container/vector.hpp> #include <boost/static_assert.hpp> int main(int argc, char *argv[]) { BOOST_STATIC_ASSERT((boost::mpl::is_sequence<boost::fusion::vector<> >::type::value)); return EXIT_SUCCESS; } The error is pasted below: /home/dean/boost_trunk/boost/mpl/begin_end.hpp: In instantiation of 'boost::mpl::begin<boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> >': /home/dean/boost_trunk/boost/mpl/is_sequence.hpp:95: instantiated from 'boost::mpl::is_sequence<boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> >' fusion_is_sequence_test.cpp:5: instantiated from here /home/dean/boost_trunk/boost/mpl/begin_end.hpp:35: error: invalid use of incomplete type 'struct boost::mpl::begin_impl<boost::fusion::fusion_sequence_tag>' /home/dean/boost_trunk/boost/mpl/begin_end_fwd.hpp:19: error: declaration of 'struct boost::mpl::begin_impl<boost::fusion::fusion_sequence_tag>' fusion_is_sequence_test.cpp: In function 'int main(int, char**)': fusion_is_sequence_test.cpp:5: error: 'type' is not a member of 'boost::mpl::is_sequence<boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> >' fusion_is_sequence_test.cpp:5: error: template argument 1 is invalid fusion_is_sequence_test.cpp:5: error: template argument 1 is invalid Is this a bug? HTH -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

2 2

[Signals] Early exit on call
by Kisso Bajslovski 12 Jan '09

12 Jan '09

Hi, I wonder if there's any way to end a call early. For example, if we have 4 connections to a signal, and when the first 2nd is called it wants to abort and avoid the calls to the last 2 connections.

3 2

[PhD] todo: use sum() consistently all places ... make it easy to switch to kahanSum() or to optomize
by Thorsten Ottosen 12 Jan '09

12 Jan '09

-Thorsten

1 1

[Review] UUID review results
by Hartmut Kaiser 12 Jan '09

12 Jan '09

Hi all, Some while ago we have had a lively discussion during the review of Andy Thompkin's UUID library. I counted 11 votes, 10 'yes' votes and one 'no' vote. IMHO the 'no' vote has been superseded by the followup discussion and all issues have been resolved. Almost all reviewers stated the UUID library to be very useful. Given the overwhelming number of 'yes' votes the UUID library is accepted for inclusion into Boost. Before inclusion into the Boost SVN Andy will need to fix a couple of minor issues as discussed during the review, some of which are: - POD-ness - lexical_cast - default construction Congratulations to Andy for his effort related to pushing the UUID library forward. I hope to see active development and maintenance of this library in the future. Regards Hartmut Review Manager

1 0

[iostreams]howto replace ostream buffer?
by Larry Evans 11 Jan '09

11 Jan '09

How can one use iostreams::filtering_streambuf to replace the std::basic_streambuf used by cout. I've tried the code in 1st attachment; however, that code produces the output in 2nd attachment. The desired output is shown in 3ird attachment. How should the code be modified to get the desired output? TIA. -regards, Larry Hello World! is_complete=1 3ird Hello! Hello World! is_complete=1 2ND HELLO! 3ird Hello!

2 3