- Boost-users - lists.boost.org

Problem solved: LNK2019 with boost::thread_group [!]
by Joseph A. Marks 11 Dec '08

11 Dec '08

Problem solved: In case anyone ever needs to know, here are the steps taken to solve the problem: {NOTE: A colleague helped me with this}. Re-loaded Boost, upgrading to v. 1.37 {this upgrade may be a red herring, but it didn't hurt). This version is very friendly to compiling in MS VS 2008 (version 9). Then, added the following, at the top of any relevant file: #include <boost/test/floating_point_comparison.hpp> #define BOOST_TEST_MAIN "Test put_your_town_string_here" #include <boost/test/unit_test.hpp> #include <boost/test/auto_unit_test.hpp> I am not sure if the first of these includes is required, but this always seems to work. Hopefully, someone will be helped by this e-mail at some point or other. Thanks, Sincerely, Joseph A. Marks e-mail: josephamarks(a)yahoo.com --- On Mon, 12/8/08, Joseph A. Marks <josephamarks(a)yahoo.com> wrote: > From: Joseph A. Marks <josephamarks(a)yahoo.com> > Subject: LNK2019 with boost::thread_group [!] > To: boost-devel(a)lists.boost.org > Date: Monday, December 8, 2008, 10:53 AM > I get the following linker error using Boost, I am trying to > get it to compile using VS 2008, with a makefile system: > > error LNK2019: unresolved external symbol "class > boost::unit_test::test_suite * __cdecl > init_unit_test_suite(int,char * * const)" > (?init_unit_test_suite@@YAPAVtest_suite@unit_test@boost@@HQAPAD@Z) > referenced in function _main > > Does anyone have any insight? > > Thanks in advance, > > Joseph A. Marks > e-mail: josephamarks @ yahoo.com Joseph A. Marks e-mail: josephamarks(a)yahoo.com

2 1

Boost + __stdcall calling convention
by cdongieux.ext＠orange-ftgroup.com 11 Dec '08

11 Dec '08

Hello, I am currently programming a dll in COM format with Visual Studio 2005. For it to be in COM format, the calling convention has to be __stdcall. In my project, I need somme Boost code, just to get my life easier :) My problem is that the compiler complains in linking process : I have unresolved Boost symbols whereas I included the good .lib. I tried many workarounds, and I saw that when I change the calling convention to __cdecl, the project compiles fine. Unfortunatly I can't register the DLL with regsvr32 since the format is not correct. Is it possible to use Boost libraries with the __stdcall convention ? Do you have an idea/solution ? Thanks in advance.

3 2

[spirit] real_p fails on negative exponent
by Jan Boehme 11 Dec '08

11 Dec '08

Hi, on my system (RHEL3, libc 2.3.2, gcc 3.2.3, Intel 10.1 which is used to compile and link) real_p fails to parse real numbers like 1.0E-001 and it is most likely the negative exponent as 1.0E001 works as expected. Our investigations brought us to numerics.hpp line 162 where the int parser which is used by real_p is declared as 'int_parser<T, 10, 1, -1>' with T=double. I don't see the reason for this yet and the 'out of the box' int parser 'int_p' itself is declared using 'int_parser<int>'. Here my questions: Do I have to expect any problems using int instead double for the real_p exp_n parser? Is this a kind of a mistake as even int_p is declared using 'int'? Thank you very much for your support, Jan. p.s.: Yes, I know gcc 3.2.3 isn't officially supported by boost but please consider helping me even so, thanks.

4 9

Re: [Boost-users] [boost] [review][constrained_value] Review of ConstrainedValueLibrary begins today
by Jesse Perla 11 Dec '08

11 Dec '08

Robert: >Yes, this might be added in the future to the library itself. But first I want >to become confident this is what actually users need and that this solution is >general enough. Therefore, I'd be grateful if you (and other possible users) >could test the provided code and say how well is it fulfilling the requirements. Absolutely. I will test around the beginning of the year. >I think the best solution for dynamic constraints union (or intersection) is to >use boost::signal, and this is how I would implement this. Again, this is a >possible addition to the library in the future if it proves generally needed. Yes, the signals approach would solve multiple constraint bounds-checking through a predicate. But it doesn't solve my main use case: Querying the sub-type information associated with a type for numeric algorithms, which may not be connected intervals. For my code (and I would guess most people's) numeric applications, I will turn off bounds-checking when running in release, and manually trigger inclusion testing as I see necessary. But the type information will be perfectly efficient at runtime for generating grids, checking convergence of optimizers, etc. The reason that I think you need to think through the unions sooner rather than later is that there is a chance it could change your design to have the library return statically available type data as lists/iterators. And it is worth thinking if you want to generalize the interval concept sooner rather than later. If it is possible and there is no future-proofing necessary, then that is fine. >On numerics: >I have no experience with such computations and no code like you describe to >test. However, I'll be grateful for any reports from users after trying to use >the library in such applications. Yup. I write code some test cases when I get started. >On numeric_limits: >Then you may specialise those functions for constrained -- I think it's a better >solution than providing numeric_limits for constrained in the library. I hear what you are saying. Yu can't write your own numeric_limits classes/functions... they are very platform specific and are part of the standard. Though there may be ways to subclass from your super-type. If it is possible to automatically subclass the numeric limits from the underlying type it would really make writing generic code for numerics much easier. If not automatically, then perhaps we could just have a usage pattern where you declare the constrained type, then the numeric_limits through inheritance? This is also related to the testing of this library with existing numerics libraries. Some of these (mine for example) are relying on numeric_limits existing for whatever type is passed in to the function. So there is a good chance that some numeric libraries would fail without this, and it would be a major disincentive for people to using this library. Thanks Robert, I will get back in contact early January to see how I can help after the review has died down. -Jesse

2 1

Re: [Boost-users] [boost] [review][constrained_value] Review ofConstrainedValueLibrary begins today
by Jesse Perla 10 Dec '08

10 Dec '08

>This too is already solved if any predicate is acceptable: just use a >predicate functor that forwards via a pointer or reference to another >global predicate. Or (somewhat less efficient but easier) use the >dynamic boost::function predicate that is already included and >boost::bind/lambda/phoenix to a method on this global object. Gordon: I absolutely agree that if this library was purely for bounds testing, managing invariants, etc, that predicates are sufficient. But for high performance numerics, that is not what would happen. First of all, you would turn off automatic testing at runtime. But one of the key value of this library, in both release/debug, for those examples is to get information about the bounds and intervals from the type itself for generic algorithms. A predicate as a function can test assignment, but it can't give back structured data for these algorithms. If you can show me how the testing predicate can be easily queried within this framework for the type metadata itself(e.g. a list of intervals), then I will shut up. I really think people need to think through this alternative use case of this powerful library. And Robert: There are a lot of discussions on the boost mailing list (which I can't post on) about NaN and others for numeric_limits. In virtually every case with high performance computing, you would turn off predicate testing on assignment for release builds because it is too expensive. Then you would, judiciously, test inclusion of the value. So the model here is that if bounded_float is a subset of float, a value in this class it is always in the float superset, but I can test inclusion within the other subset that I have defined. Here, predicates work fine as long as there is a manual way to test set inclusion. And numeric libraries frequently use NaN, infinity, etc. as signals for algorithms. So these values should be associated with the superset in the model as a default approach. So what I am saying is that people should be given the option (as a preprocessor instruction is sufficient) to have the value as always within the bounds vs. considering this as a "set" which they can then test inclusion at their own liesure. This is a pragmatic approach to ensure consistency of this library with existing generic numerical algorithms, which is just as important for the numerics as solving the floating point problem. Also, I am not aware of the structure of the numeric_limits, but I doubt these are written to be virtual/subclassed due to efficiency. What this means is that you would probably have to write your own traits class if we don't make this automatic, and you can't pick or choose to override existing tratis. And these numeric traits are impossible for normal developers to write since they are platform specific. Last, and this is not something I know enough about because I am not a numeric analyst, but the epsilon method discussed in the mailing list may have a flaw for numeric work. What we effectively are doing here is creating an epsilon neighborhood for testing equality. As we know from set theory/topology, this does not create a weak ordering because it fails transitivity. Now, one might say that this is irrelevant because it is a reasonable approximation for pragmatic reasons, but you run into a problem in numerics. The reason is that many numerical algorithms are already testing within an epsilon neighborhood for convergence of algorithms, derivatives, etc. So we need to be REALLY careful that this epsilon ball is well within those balls, or we may seriously mess up algorithms depending on a comparison operator.... This may or may not be a problem, but I would pose it on the boost list to ensure that people are thinking about it. One solution may be to rely on the numeric_limits::epsilon trait that would always be available, would be platform specific, and I believe is the small possible neighborhood of a point. Whether this is the maximum amount of truncation possible, I do not know. -Jesse

3 2

signals/slots and boost::functions
by david.weber＠l-3com.com 10 Dec '08

10 Dec '08

I have a class, where I want callers to be able to register/deregister signals/slots. They will pass in a function pointer, and we'll hook it up to the signal, and manage the connection object. Part of the management, is I need to map the function pointer to the actual connection object. This is where the trouble comes in. Since a boost::function doesn't have an operator <, the simplest way is to just map it to an unsigned long long, and store the raw address of the underlying function. So, my connect function: typedef VSSP (*TargetType) ( std::string, EncodingEnum); typedef boost::function < VSSP ( std::string, EncodingEnum) > CreateTypeFunc; bool ElementBase::connectCreateTypeSignal(const CreateTypeFunc& slot) { LOG4CXX_DEBUG(logger_, "connectCreateTypeSignal in"); bool retValue = false; unsigned long long slotAddr = (unsigned long long)slot.target< TargetType >(); LOG4CXX_DEBUG(logger_, "*** slotAddr = " + (boost::format("%08X") % slotAddr).str()); <snip> } One of my checks, is to ensure that you don't connect the same thing multiple times. So, I have a test case that does this, and expects it to bomb out: VSSP getTypeSlot(std::string fqn, EncodingEnum encoding) { <snip> return VSSP; } BOOST_FIXTURE_TEST_CASE(ElementBase_connectCreateType, ElementBaseTestFixture) { BOOST_CHECK(true == ebp->connectCreateTypeSignal(getTypeSlot)); BOOST_CHECK(false == ebp->connectCreateTypeSignal(getTypeSlot)); } My debug printouts, are shoing unexpected behavior. The address that I am getting from target is different every time it is called, even though I'm calling with the same function (getTypeSlot). I would expect this if I was getting the address of the function object, because I'm creating one implicitly through the call, but not dereferencing via target(), unless I'm misunderstanding what target() does. I just need the stupid address of the function passed in. Help!! TIA --dw

3 5

Eigenvalues
by r89 10 Dec '08

10 Dec '08

Hi, It seems like Boost doesn't support eigen-analysis, is that true? I've been using VXL/VNL for eigenanalysis, but my project must get rid of dependencies on VXL/VNL, so I'm wondering what would be the easiest transition? By the way, the matrices I'm dealing with are of size 2x2 and 3x3. Thanks! -- View this message in context: http://www.nabble.com/Eigenvalues-tp20941764p20941764.html Sent from the Boost - Users mailing list archive at Nabble.com.

4 3

[BGL] passing a graph from one function to another
by r89 10 Dec '08

10 Dec '08

Hi all, I have a graph defined as follows (the same as in the Dijkstra shortest path example code): typedef adjacency_list < listS, vecS, directedS, no_property, property < edge_weight_t, float > > graph_t; The following works fine: graph_t myGraph(array, edge_array + num_arcs, weights, num_nodes); However, now I want to do the above line inside a function (say, fun_A), and I want another function (say, fun_B) to have access to "myGraph". How should I do that? I wish I could do something like this: graph_t myGraph; fun_A(graph_t &myGraph) { myGraph(array, edge_array + num_arcs, weights, num_nodes); } fun_B(graph_t &myGraph) { // using myGraph to run some graph algorithm... } but it doesn't work. Any suggestions? Thanks! -- View this message in context: http://www.nabble.com/-BGL--passing-a-graph-from-one-function-to-another-tp… Sent from the Boost - Users mailing list archive at Nabble.com.

5 12

[bind/lambda] Matching signature constness?
by Robert Jones 10 Dec '08

10 Dec '08

Here's a bit of code (and my apologies for it's length, but I'm unsure which bit is the failure point) #include <cstddef> #include "boost/lambda/lambda.hpp" #include "boost/lambda/bind.hpp" #include "boost/function.hpp" #include "boost/type_traits.hpp" namespace { template < bool > struct cmp_detail { template < typename T > static bool cmp( const T & lhs, const T & rhs ) { return lhs != rhs; } }; template < > struct cmp_detail< true > { template < typename T, std :: size_t sz > static bool cmp( const T ( & lhs )[ sz ], const T ( & rhs )[ sz ] ) { using boost :: lambda :: _1; using boost :: lambda :: bind; using boost :: lambda :: var; boost :: function< bool( unsigned ) > cmp_element = bind( cmp_detail< boost :: is_array< T > :: value > :: cmp, var( lhs )[ _1 ], var( rhs )[ _1 ] ); for ( unsigned i = 0; i != sz; ++ i ) if ( cmp_element( i ) ) // if ( cmp_detail< boost :: is_array< T > :: value > :: cmp( lhs[ i ], rhs[ i ] ) ) return true; return false; } }; template < typename T > bool cmp( const T & lhs, const T & rhs ) { return cmp_detail< boost :: is_array< T > :: value > :: cmp( lhs, rhs ); } template < typename T, std :: size_t sz > struct Block { typedef T type[ sz ][ sz ]; }; } int main( ) { Block< int, 16 > :: type a; Block< int, 16 > :: type b; cmp( a, b ); } The problem is the bind call in cmp_detail<true>::cmp(...). Error is this block.cpp: In static member function `static bool <unnamed>::cmp_detail< true>::cmp(const T (&)[sz], const T (&)[sz]) [w ith T = int[16], unsigned int sz = 16u]': block.cpp:45: instantiated from `bool <unnamed>::cmp(const T&, const T&) [with T = int[16][16]]' block.cpp:61: instantiated from here block.cpp:32: error: no matching function for call to `bind(<unknown type>, const boost::lambda::lambda_functor<boost::l ambda::lambda_functor_base<boost::lambda::other_action<boost::lambda::subscript_action>, boost::tuples::tuple<boost::lam bda::lambda_functor<boost::lambda::identity<const int (&)[16][16]> >, boost::lambda::lambda_functor<boost::lambda::place holder<1> >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boo st::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, const boost::l ambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::other_action<boost::lambda::subscript_action>, b oost::tuples::tuple<boost::lambda::lambda_functor<boost::lambda::identity<const int (&)[16][16]> >, boost::lambda::lambd a_functor<boost::lambda::placeholder<1> >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples:: null_type> > >)' I think perhaps the var() calls are not preserving constness quite right? Any help would be welcome. Thanks. - Rob.

2 3

[Review] UUID library (mini-)review starts today, November 23rd
by Hartmut Kaiser 10 Dec '08

10 Dec '08

Hi all, The mini-review of Andy Tompkins UUID library starts today, November 23rd 2008, and will end on November 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! The library can be downloaded from the vault here (it's the file uuid_v13.zip in the topmost directory): http://tinyurl.com/6xx28b The initial review of the UUID library ended with a provisional acceptance (read here: http://article.gmane.org/gmane.comp.lib.boost.user/27774/) This mini review is meant to allow for a final decision after looking at the changed parts of the library. Here is a list of things fixed and changed: - fixed the licensing issues revealed by the initial review - fixed the security vulnerability revealed by the initial review - renamed to uuid, moved all classes, functions, etc. to namespace boost::uuids - implemented sha1 hash function (thus no license problem) - new class basic_uuid_generator to create random-based uuids. The random number generator is no longer hard coded. It can use any random number generator, default is boost::mt19937 - implemented a good seed function for random number generators - all functions are now reentrant, all classes are as thread safe as an int and the library is no longer dependent on Boost.Thread --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

14 39