- Boost-users - lists.boost.org

using boost::format with STLPort
by Alexey Bakhvalov 23 Feb '05

23 Feb '05

Hello, I have a problem when I try to include "boost/format.hpp" from Boost 1.32 in a project that uses STLPort library. I am using MSVC 7.1 and the compiler prints the following error: \boost\format\format_implementation.hpp(216) : error C2244: 'boost::basic_format<Ch,Tr,Alloc>::size' : unable to match function definition to an existing declaration \boost\format\format_class.hpp(58) : see declaration of 'boost::basic_format<Ch,Tr,Alloc>::size' definition 'basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' existing declarations 'boost::basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' If I switch back to Boost 1.31 or don't use STLPort then the problem goes away. I just wonder what can be the cause of such strange error because I can't see any difference between function's definition and declaration. Also I use many other Boost libraries and don't have this problem with either of them.

3 2

lapack bindings compiled fail with Visual C++ 7.1
by HHSU 23 Feb '05

23 Feb '05

Hi, I used VC7.1 and Boost_1.32_0 to compiled the SVD test file ( ublas_gesvd.cc) which download from http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/nume… I get the following error and warring messages: d:\upload\test\ublas_gesvd.cpp(61) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned int', possible loss of data c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\numeric\ublas\traits.hpp(941) : warning C4267: 'argument' : conversion from 'size_t' to 'const unsigned int', possible loss of data c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\numeric\ublas\matrix_expression.hpp(4462) : see reference to class template instantiation 'boost::numeric::ublas::promote_traits<X,Y>' being compiled with [ X=boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>::size_type, Y=boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>::size_type ] d:\upload\test\ublas_gesvd.cpp(84) : see reference to class template instantiation 'boost::numeric::ublas::matrix_matrix_binary<E1,E2,F>' being compiled with [ E1=boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>, E2=boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>, F=boost::numeric::ublas::matrix_matrix_prod<real_t,real_t,boost::numeric::ublas::matrix_matrix_binary_traits<real_t,boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>,real_t,boost::numeric::ublas::matrix<real_t,boost::numeric::ublas::column_major>>::promote_type> ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\numeric\bindings\lapack\gesvd.hpp(281) : error C3861: 'assert': identifier not found, even with argument-dependent lookup d:\upload\test\ublas_gesvd.cpp(69) : see reference to function template instantiation 'int boost::numeric::bindings::lapack::gesvd<m_t,v_t,m_t,m_t,std::vector<_Ty>>(const char,const char,MatrA &,VecS &,MatrU &,MatrV &,VecW &)' being compiled with [ _Ty=real_t, MatrA=m_t, VecS=v_t, MatrU=m_t, MatrV=m_t, VecW=std::vector<real_t> ] What I am missing or doing wrong ? Bert.

1 1

boost::format bug?
by Orhun Birsoy 23 Feb '05

23 Feb '05

Hi, I am getting boost::io::too_many_args exceptions for the following line. cout << format(" %1% %3% \n") % 1 % 2 % 3 % 4 % 5; but not for this one cout << format(" %1% %5% \n") % 1 % 2 % 3 % 4 % 5; If the last argument is used in the format, I do not get the exception. Is this a bug? Thanks. Orhun Birsoy -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

2 1

[lexical_cast]: Converting a formatted string
by maha.ramanan＠philips.com 23 Feb '05

23 Feb '05

Hi, I am quite new to the iostreams and lexical cast and hence bear with me of any lack of knowledge. I am using the lexical cast in the following manner: unsigned int data_value = boost::lexical_cast<unsigned int>("0xFF"); The above comes out with a runtime bad_lexical_cast error. I understood, by default, the streams (stringstream used by lexical cast) should be able to automatically identify the radix of the input and convert it automatically. Is my above undestanding correct? Is lexical_cast meant to be used in this situation? Thanks for your help? Ram ======================================================================================= Mahadevan Ramanan Design Technology Centre DTG - Philips Semiconductors Milbrook Industrial Estate Tel: +44 (0) 23 8031 2540 Southampton, Hants SO15 0DJ Fax: +44 (0) 23 8031 2642 UK ====================================================================================== The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

1 0

lexical_cast specializations
by Cory Nelson 22 Feb '05

22 Feb '05

How about adding some specializations to use wstringstring when given a wstring? -- Cory Nelson http://www.int64.org

1 0

RE: regex/string algorithm problem
by The Grumpiest Man You Know 22 Feb '05

22 Feb '05

Boy! You guys are SPOOKY good. I wrestle with something 'til I give up and then I go to write a report and while I formulate the words you start feeding back answers! The reason the code I sent "hangs" is because it's iterating over a zero length match. which consumes 0 characters of input per loop. I must do that once a year in any language I use, you think I'd learn huh? If I can reproduce the segfault and I can't see why it's my fault, can I post that too? Or can we skip that and have y'all start channeling me the clues now. :) Thanks again for your time. -- Blue Skies

3 3

shared_ptr: proper removal from STL Containers?
by Jeremy Hill 21 Feb '05

21 Feb '05

Greetings, I have only recently begun exploring boost, and I must say that I have found it very interesting. In particular I've been focusing on boost::shared_ptr. However, I'm not quite sure how to 'deallocate' shared_ptrs that are in a Container, such as a vector. I'd like to issue some pseudocode to help put things in perspective: class Descriptor { public: bool valid; Descriptor() : valid(true) {} } struct InvalidDesc { bool operator()(Desc_ptr &d) { return (*d).valid; } }; class Desc_broker { private: vector< boost::shared_ptr< Descriptor > > desc_list; public: //These functions are, in this order, called elsewhere: void fun_1() { <conditionally invalidate Descriptors> }; void fun_2() { <iterate through desc_list and do stuff> }; void cleanup() { desc_list.erase( remove_if(desc_list.begin(), desc_list.end(), InvalidDesc()), desc_list.end() ); } }; There is the class 'Descriptor' that is contained within a shared_ptr, which is wrapped in the 'Desc_broker' class. Once a Descriptor is invalidated, such as in fun_1() above, it is no longer needed. I'll need to get rid of invalid Descriptors before the vector is iterated through in fun_2(). However, since the shared_ptr for the invalid Descriptor will not go out of scope, to the best of my knowledge I'll need to help it along by using something along the lines of 'cleanup', which will remove all desc_ptrs whose Descriptors are invalid (via std::remove_if and the InvalidDesc predicate). However, this feels wrong to me because it seems like it is against what shared_ptrs are trying to accomplish. And, in fact, Boost agrees--I receive this on cleanup(): assertion "px != 0" failed: file "/usr/local/include/boost/shared_ptr.hpp", line 253 Aborted (core dumped) What is the correct way to remove the invalid Descriptors? Also, I apologize if this is considered the unacceptable topic "Requests for help interpreting the C++ standard." If that is the case, please tell me so that I may not offend in future posts. Thank you, Jeremy Hill

2 2

Re: problem with lambda and function<>
by Arturo_Cuebas＠bpmicro.com 21 Feb '05

21 Feb '05

In my previous post the sample code was a lot more than what what necessary to ask the question. I could have given this simpler example: #include <boost/function.hpp> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> using namespace boost; using namespace boost::lambda; int f(void) { return 5; } int main(void) { int test = 0; (_1 = bind(&f))(test); // No compile error function<int (void)> functorized_f(&f); (_1 = functorized_f)(test); // Compile error return 0; } This is what my question really boils down to: just like naming delayed variables, is it possible to predefine and name the result of a call to bind() outside a lambda expression? /*what goes here?*/ bound_f = bind(&f); (_1 = bound_f)(test);

1 0

boost::filesystem -- handling dead symlinks
by Matthias Kaeppler 21 Feb '05

21 Feb '05

Hello, I wonder if there is any means of telling boost::filesystem::directory_iterator to skip broken symlinks. It's sort of an annoyance working with them, since operations like is_directory will throw when invoked on a broken symlink. I am keeping a vector of boost::filesystem::pathS, and as soon as I operate on a broken symlink, an exception will be thrown. I do catch it, but that doesn't really help since the program will return from the method where the exception was thrown. I would find it much more convenient to simply skip these broken files, instead of jumping out of the procedure (IMO it's not even exceptional behavior, dead symlinks are pretty common). Any idea what I can do about this? -- Matthias Kaeppler

3 4

MPL iterator category
by Philippe Mori 21 Feb '05

21 Feb '05

In C++ Template Metaprogramming book, there is the expression i::category in tables 5.1, 5.2 and 5.3 that says that the result is convertible to mpl::forward_iterator_tag, mpl::bidirectional_iterator_tag and mpl::random_access_iterator_tag respectively. Since a random access iterator is bidirectional iterator which is in turn a forward iterator, I was expecting that i::category for a bidirectional iterator would also be convertible to mpl::forward_tag which is not the case. So if an algorithm has to works differently for random-access iterator but it the same for forward and bidirectional iterator, it seems to me that I would need some extra logic to uses forward iterator algorithm if I have a bidirectional iterator as theree are no implicit conversion. In fact, in the implementation we derives from int_<n> where n is 0, 1 or 2 depending on the iterator type. Philippe

3 2