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

newbie build problems with msvc-stlport toolset
by uncle_buck_598 10 Jul '03

10 Jul '03

I am attempting to build the complete boost library set with the command line: bjam -sTOOLS=msvc-stlport "-BUILD=debug release <stlport-iostream>on" Unfortunately, 5 of the release DLLs fail to link with the following error: unresolved external symbol "public: static void __cdecl _STL::_STLP_mutex_spin<0>::_M_do_lock(long volatible *)" ("_M_do_lock@?$_S_STLP_mutex_spin@$0A@@_STL@@SAXPCJ@Z) What is confusing is that the debug DLLs all build with out a hitch! I am using MSVC 6.0 SP5, STLport-4.5.3, and Windows Platform SDK - Nov2002. Any help would be greatly appreciated!! --Jamie

1 0

configuring MSVC 7.1 to use boost build
by Dave Gomboc 10 Jul '03

10 Jul '03

I'm trying to use boost::signals and boost::regex with MSVC 7.1 I retrieved the current CVS state with WinCVS, downloaded a binary of bjam (3.1.4), used the Visual Studio .NET 2003 Command Prompt, invoked bjam with the argument "-sTOOLS=vc7.1", and have added the boost path to Tools|Options|Projects|VC++ Directories (Include Files). When I compile programs I get link errors, e.g. signals_test.obj : error LNK2019: unresolved external symbol "public: void __thiscall boost::signals::connection::disconnect(void)const " (?disconnect@connection@signals@boost@@QBEXXZ) referenced in function "public: __thiscall boost::signals::connection::~connection(void)" (??1connection@signals@boost@@QAE@XZ) signals_test.obj : error LNK2019: unresolved external symbol "public: __thiscall boost::signals::detail::signal_base::~signal_base(void)" (??1signal_base@detail@signals@boost@@QAE@XZ) referenced in function "public: __thiscall boost::signal0<void,struct boost::last_value<void>,int,struct std::less<int>,class boost::function0<void,class std::allocator<class boost::function_base> > >::~signal0<void,struct boost::last_value<void>,int,struct std::less<int>,class boost::function0<void,class std::allocator<class boost::function_base> > >(void)"(??1?$signal0@XU?$last_value@X@boost@@HU?$less@H@std@@V?$functio n0@XV?$allocator@Vfunction_base@boost@@@std@@@2@@boost@@QAE@XZ) I have tried to add library paths in the IDE in a similar fashion to how I added the include path, but I had no success when building a test project. What do I need to do to successfully link? Thanks, Dave P.S. It might be a good idea to add the "vc7.1" target to http://www.boost.org/tools/build/index.html#Configuring.

2 1

Re: CRC problem with 8 bit truncated polynomial
by Daryle Walker 10 Jul '03

10 Jul '03

On Wednesday, July 9, 2003, at 11:02 AM, Victoria Ames wrote: [SNIP] > However, when I have tried examples using 8 bit truncated > polynomials I fail to get a meaningful checksum. > > Example that doesn't work : > std::cout << "Expected CRC-8 : EA" << std::endl; > boost::crc_optimal<8, 0x9B, 0, 0, false, false> crc_8; > crc_8 = std::for_each( data, data + data_len, crc_8 ); > std::cout << "Optimal CRC-8 : " << std::hex << crc_8() << std::endl; > > The results I get are : [SNIP] > Expected CRC-8 : EA > Optimal CRC-8 : Û > > Does anyone know why the 8 bit example does not seem to work? I can't tell at this point. The problem could be that the results of the "crc_8" object is an "unsigned char". The built-in character types can take the same numeric operations as the bigger built-in integral types (i.e. "int"). However, the character types differ from the other integral types since the character types act as C++ text system types. So when an object of a built-in character type is printed, its text value is printed instead of its numeric value. The solution is to convert the result to a numeric-only integral type. Try std::cout << std::hex << static_cast<unsigned>( crc_8() ) << std::endl; to check the numeric value of the result. Then you can tell if the result is correct. If it's not, send us another message. With my hypothesis, the problem is only in the printing. You would have no problem in using the result for further mathematical analyses. Daryle

1 0

RE: [Boost-Users] RE: Re: CRC problem with 8 bit truncated polyno mial
by Jim.Hyslop 09 Jul '03

09 Jul '03

Vladimir Prus wrote: > Sorry, I don't understand what you're saying... > > std::cout << "Optimal CRC-8 : " << std::hex << (unsigned)crc_8() > << std::endl; > > is the same as > > std::cout << "Optimal CRC-8 : " << std::hex << (unsigned int)crc_8() > << std::endl; Sorry, I wasn't very clear in my last message. The results can be unexpected, depending on whether the result of crc_8() (or more precisely, operator() ) is signed or unsigned. If operator() returns an unsigned value, there will be no problems, and the output will be ea. On the other hand, if operator() returns a signed value, then it will first be promoted to a signed int, then converted to an unsigned int. Using the original example values posted by Victoria, the output would be ffffffea. In this scenario, the return value must be first cast to an unsigned char, then to an unsigned int: ... << static_cast<unsigned>( static_cast<unsigned char>( crc_8() ) ) I just had a quick look at the crc.hpp file, and operator() returns an unsigned value, thus banishing my caveat to the dusty corners where all academic footnotes end up ;-) -- Jim

2 1

RE: [Boost-Users] Re: CRC problem with 8 bit truncated polynomial
by Jim.Hyslop 09 Jul '03

09 Jul '03

Vladimir Prus wrote: > I'm guessing this should be > > std::cout << "Optimal CRC-8 : " << std::hex << (unsigned)crc_8() > << std::endl; > > The way iostreams format chars is most likely not what you wanted. True enough - and that includes signed vs. unsigned chars (both are handled the same, at least with my compiler). The result needs to be put into an unsigned *int* for cout to display the numeric value. -- Jim

3 2

RE: [Boost-Users] CRC problem with 8 bit truncated polynomial
by Jim.Hyslop 09 Jul '03

09 Jul '03

victoriaames wrote: > Example that doesn't work : > std::cout << "Expected CRC-8 : EA" << std::endl; > boost::crc_optimal<8, 0x9B, 0, 0, false, false> crc_8; > crc_8 = std::for_each( data, data + data_len, crc_8 ); > std::cout << "Optimal CRC-8 : " << std::hex << crc_8() << std::endl; > > The results I get are : > > Expected CRC-CCITT : 29B1 > Optimal CRC-CCITT : 29b1 > > Expected CRC-8 : EA > Optimal CRC-8 : Û > > Does anyone know why the 8 bit example does not seem to work? I haven't used this library, but judging from the output it looks to me like it's working just fine. The result is an 8-bit value, i.e. a (possibly unsigned) char, with the value 0xEA. Think about what cout does with 'char'. -- Jim

1 0

CRC problem with 8 bit truncated polynomial
by victoriaames 09 Jul '03

09 Jul '03

When I have tried examples using 16 or 32 bit truncated polynomials this library works perfectly. Example that works : unsigned char const data[] = { 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39 }; std::size_t const data_len = sizeof( data ) / sizeof( data[0] ); std::cout << "Expected CRC-CCITT : 29B1" << std::endl; // Simulate CRC-CCITT with the optimal version boost::crc_optimal<16, 0x1021, 0xFFFF, 0, false, false> crc_ccitt2; crc_ccitt2 = std::for_each( data, data + data_len, crc_ccitt2 ); std::cout << "Optimal CRC-CCITT : " << std::hex << crc_ccitt2() << std::endl; However, when I have tried examples using 8 bit truncated polynomials I fail to get a meaningful checksum. Example that doesn't work : std::cout << "Expected CRC-8 : EA" << std::endl; boost::crc_optimal<8, 0x9B, 0, 0, false, false> crc_8; crc_8 = std::for_each( data, data + data_len, crc_8 ); std::cout << "Optimal CRC-8 : " << std::hex << crc_8() << std::endl; The results I get are : Expected CRC-CCITT : 29B1 Optimal CRC-CCITT : 29b1 Expected CRC-8 : EA Optimal CRC-8 : Û Does anyone know why the 8 bit example does not seem to work? Victoria

2 1

[help] thread on intel solaris 8
by meg_r123 09 Jul '03

09 Jul '03

Hi all, I've succesfully compiled the boost library 1.30.0, and the tests for the libthread runs fine, but I get an "abort" when I try to execute a simple test written by me. I suppose it is a link problem, this is the command in the Makefile: (I'm using GCC) CC = g++ OBJS = test_thread.o TARGET = test_thread $(TARGET): $(OBJS) $(CC) -o $(TARGET) $(OBJS) -L$(HOME)/local/lib/ -lboost_thread Any idea to suggest me? Thank you, meg

3 4

[boost::date_time] posix_time::to_simple_string and posix_time::time_from_string
by Russell Hind 08 Jul '03

08 Jul '03

These 2 functions don't seem to work together. to_simple_string will produce a string such as 2003-Jul-08 11:55:47 But time_from_string expects 2003-07-08 11:55:47 This means you can't convert to a string (to store in a text file) then read back in and convert it back to a ptime. Is this a bug, or have I missed a conversion function that can handle this? Thanks Russell

2 3

Const strangeness and indirect_iterator generators.
by Tim Robertson 08 Jul '03

08 Jul '03

Hi, I've been trying to get indirect_iterator working in what seems (to me) to be a straightforward context -- I have a std::vector of boost::shared_ptr objects, and I need both const and non-const iterators into the vector (I'm using the vector as the sole data member of a container class, and I need the iterators to properly handle const and non-const container types). This looks something like this: class MyClass { // ... }; class MyContainer { public: typedef MyClass value_type; typedef value_type & reference; typedef value_type * pointer; // and so on, for const_reference, const_pointer, etc... // ... private: std::vector<boost::shared_ptr<MyClass> > _data; }; Now, the trouble comes when I attempt to define the iterators for MyContainer using the indirect_iterator generators. If I do the obvious: Approach #1: ------------ typedef indirect_iterator_pair_generator< vector<shared_ptr<MyClass> >::iterator, value_type, reference, const_reference, std::random_access_iterator_tag, pointer, const_pointer>::itgen; typedef typename itgen::iterator my_iterator; typedef typename itgen::const_iterator my_const_iterator; I find that the const_iterator generated is inadequate for use in a container context. Particularly, it produces a my_const_iterator that has the following constructor signature: my_const_iterator(shared_ptr<MyClass> *) Whereas, a const std::vector<shared_ptr<MyClass> > will produce const_iterators that look like this: const shared_ptr<MyClass> * const This causes compilation problems, because inevitably, in this context, you'll want to construct a my_const_iterator from a vector::const_iterator. The problem seems obvious: the indirect_iterator_pair_generator class is considering only non-const base iterators. This led me to try the following: Approach #2: ----------- typedef typename indirect_iterator_generator <typename vector<shared_ptr<MyClass> >::iterator, value_type, reference, pointer, std::random_access_iterator_tag>::type my_iterator; typedef typename indirect_iterator_generator <typename vector<shared_ptr<MyClass> >::const_iterator, value_type, const_reference, const_pointer, std::random_access_iterator_tag>::type my_const_iterator; It seemed that this would solve the problem by independently generating the two types of iterators that are needed (note how I've made the base iterator type ::iterator in one, and ::const_iterator in the other). However, with this method I always obtain compilation errors -- whereever there is a use of the operator->(), the following error is produced (g++ 3.0.3 and 3.2 do the same thing, Linux and Mac OSX): "result of `operator->()' yields non-pointer result" I have yet to figure out what is causing this error. This led me to attempt the following "solution" to the problem: Approach #3: ----------- typedef indirect_iterator_pair_generator <typename vector<shared_ptr<MyClass> >::iterator, value_type,reference,const_reference, std::random_access_iterator_tag, pointer,const_pointer> itgen; typedef typename itgen::iterator my_iterator; typedef indirect_iterator_pair_generator <typename vector<shared_ptr<MyClass> >::const_iterator, value_type,reference,const_reference, std::random_access_iterator_tag, pointer,const_pointer> itgen2; typedef typename itgen2::const_iterator my_const_iterator; This actually works! I can't explain why -- it seems like indirect_iterator_pair_generator and indirect_iterator_generator should behave identically when their template parameters are identical.... The way I see it, there's a bug in at least one of the indirect_iterator generator objects. At the very least, indirect_iterator_pair_generator and indirect_iterator_generator are behaving differently when their parameter types are the same (compare approaches #2 and #3). But there's also the issue of why approach #1 didn't work to begin with -- it *seems* like indirect_iterator_pair_generator should produce a const_iterator type that can be initialized with an iterator from a const vector. This isn't the case. If anyone can explain this to me, and convince me that I'm not going insane, I'd appreciate it greatly ;-) (Standard bug-report disclaimers: Current boost distribution, g++ 3.0.x/3.2.x, both Mac OSX and Linux exhibit identical behaviour.) -Tim

2 1