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

Signals library safety
by Eugene Talagrand 11 Jul '03

11 Jul '03

Hello to all, I'm looking into using the Boost.Signals. The library claims not to be thread safe. What does this mean exactly? When using Boost.Threads, can I make concurrent calls to connect as long as I wrap each call in a Mutex? If this is possible, do tackable objects also still work (if two trackable objects get destroyed in two different threads there might be a problem from what I understand) On an different note, I am trying to use Boost.Signals for network event handling. I'd like to set it up so that it uses something similar to he JavaScript event model, where every slot returns a boolean value. If that value is false, the remaining slots are not called. Would anyone have any recommendations on how to do this? Should I wrap each slot in a function that takes the return value and sets a global flag, then every subsequent slot checks the flag? It looks like combiners would not be appropriate, as it appears they are used after each slot is called (unless the InputIterator' opeator* actually calls the slot??) Thanks for any help -Eugene

2 1

stream operators and random number generators
by Witz 10 Jul '03

10 Jul '03

hi, in my code i need to be able to save the state of my program including that of he random number generators but under MSVC 7.1.3088 the following code: int main() { boost::mt19937 rng; std::cout << rng; return 0; } won't compile and gives the error: "error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'boost::mt19937' (or there is no acceptable conversion)" there a workaround for this (beyond my hacky solution of adding load and save functions to the mersenne_twister class)? thanks in advance, ian whittley

1 0

BOOST_MPL_DEPENDENT_TEMPLATE_TYPEDEF
by Joaquín Mª López Muñoz 10 Jul '03

10 Jul '03

I've read on some archived post in the boost mailing list about BOOST_MPL_DEPENDENT_TEMPLATE_TYPEDEF, but seems like it is not in the 1.30 distribution anymore. Anyone knows what happened to it? I'm in need of this sort or workaround. Aleksey, are you there? :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

deadlock in filesystem?
by Ken Alverson 10 Jul '03

10 Jul '03

I'm running into an odd deadlock situation, and I was wondering if it's a known issue, or if there's likely something wrong with my code, or if I've misconfigured something? First off, a stack trace: ntdll.dll!77f5b7f4() kernel32.dll!77e61bf5() scanner.exe!boost::detail::sp_counted_base::release() Line 132 + 0xf C++ scanner.exe!boost::detail::shared_count::~shared_count() Line 380 C++ scanner.exe!boost::shared_ptr<boost::filesystem::directory_iterator::dir_itr_i mp>::~shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>() + 0x2e C++ scanner.exe!boost::shared_ptr<boost::filesystem::directory_iterator::dir_itr_i mp>::reset() Line 217 C++ scanner.exe!boost::filesystem::directory_iterator::m_inc() Line 256 C++ scanner.exe!boost::filesystem::directory_iterator::operator++() Line 88 + 0x2b C++ scanner.exe!std::for_each(boost::filesystem::directory_iterator _First={...}, boost::filesystem::directory_iterator _Last={...}, scan_file _Func={...}) Line 20 + 0xa C++ I'm using boost 1.30.0 running a staticly linked debug build of the filesystem lib, on vc7. The for_each is actually the most recursed level of a recursive directory search - I'm pretty sure that code is fine; I'm very familiar with STL iteration and I'm not doing anything strange, just: std::for_each( fs::directory_iterator(dir), fs::directory_iterator(), scan_files(fileset)); where scan_files will recurse on directories and process on files. I don't touch the iterators directly other than to pass them to for_each. Now, the strange part is this program works completely fine when I simply run it from the command line. However, I am building it into a windows service, and when it runs as a service under the SYSTEM account (I haven't tried running it as a service under a different account, yet), I get deadlock. I suspected the problem might be related to funny permissions on the directory in question, but SYSTEM has full rights to the directory, so that shouldn't be the problem. Oddly, when I use the release filesystem lib it deadlocks in a different location in the search, but in the same sp_counted_base::release() function - this time in an attempt to unwind after a filesystem exception. I tried to search the mailing list for similar problems, but the search seems to be broken at the moment. I'm hoping this is an easy fix, known issue, because I'm at a loss as to how I could be causing it, especially since I'm not getting anywhere near the internals of the directory iterators. I am a fairly new user to boost, but up until now I've had no problems. Sorry if this is a jumble...I've been banging my head against this for the past few hours and my coffee is wearing off. Ken

3 11

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