- Boost-users - lists.boost.org

Bug in regex library?
by Andrey Sverdlichenko 30 Mar '03

30 Mar '03

boost::regex do not compile with STLPort-4.5.3 on FreeBSD 4.7-RELEASE-p3, gcc 2.95.4. This is a patch that fixed a problem. Is it just a typo in source? ==== //boost/libs/regex/src/cpp_regex_traits.cpp#1 - //boost/libs/regex/src/cpp_regex_traits.cpp ==== @@ -201,7 +201,7 @@ const std::messages<char>* pm = 0; #ifndef __IBMCPP__ - std::messages<char>::catalog cat = static_cast<std::messages<wchar_t>::catalog>(-1); + std::messages<char>::catalog cat = static_cast<std::messages<char>::catalog>(-1); #else std::messages<char>::catalog cat = reinterpret_cast<std::messages<wchar_t>::catalog>(-1); #endif

2 1

RE: [Boost-Users] Problem with 1.30.0 lexical_cast
by Tom Matelich 28 Mar '03

28 Mar '03

Well, actually, looks like it lies elsewhere. I rolled back to 1.29.0 and its still broken :( > -----Original Message----- > From: Terje Slettebø [mailto:tslettebo@chello.no] > Sent: Wednesday, March 26, 2003 9:15 PM > To: Boost-Users(a)yahoogroups.com > Subject: Re: [Boost-Users] Problem with 1.30.0 lexical_cast > > > >From: "Tom Matelich" <tmatelich(a)zetec.com> > > > Compiler: gcc 3.2 and 3.2.2 > > > > I believe this is actually a bug in gcc, but I'm going to > post it hopes > that > > someone can help me. We have a handy little tool for > generating enums > with > > associated string conversion and stream > insertion/extraction functions. > > When we upgraded to boost 1.30.0, lexical_cast'ing one of > these enums to > > std::string started behaving incorrectly, rather than the > name, it is > giving > > me the integral value. It seems that the lexical_stream is > being used. > > Unfortunately, my test case is working fine. The complete test case > > (including definition of ZAcquisition::PPG) is appended at > the end. The > > code I am seeing failure with looks like: > > > > void foo(ZAcquisition::PPG::Type gt) > > { > > ... > > std::string str; > > str = boost::lexical_cast<std::string>(gt); > > std::cerr << "DEBUG, storing encode for PPG: " << str << > ", aka " << gt > > << std::endl; > > ... > > } > > > > This outputs (for example): > > DEBUG, storing encode for PPG: 0, aka ONE > > > > I tried boost::lexical_cast<std::string, > ZAcquisition::PPG::Type>(gt) as > > well. > > > > Anyone have any ideas? For now I'm going to back out to 1.29.0's > > lexical_cast. > > > It happens on my Windows/Intel 7.0 box as well. > > It's a little difficult when you don't have a failing test > case. If you had > that, I could have looked into it. The above code works > correctly on Intel > C++ 7.0 (Windows), here. > > > Regards, > > Terje > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Get 128 Bit SSL Encryption! > http://us.click.yahoo.com/xaxhjB/hdqFAA/xGHJAA/EbFolB/TM > -------------------------------------------------------------- > -------~-> > > Info: <http://www.boost.org> > Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> > Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

1 0

Why "explicit" in shared_ptr's constructor?
by Maurizio Colucci 28 Mar '03

28 Mar '03

Hello, I am a newbie user of boost. I have a question about boost::shared_ptr. Suppose you have a polimorphic list: class entity{ ...}; class simple_entity : public entity{ public: uint id; simple_entity(uint i) : id(i) {} }; int main(){ list<shared_ptr<entity> > l; ... I noticed the following code doesn't compile l.push_back(new simple_entity(1)); too bad, because it was very easy to read, and very similar to the behavior if standard pointers (not to speak about similarity to Java and C#). So I am forced to do l.push_back(shared_ptr<entity> (new simple_entity(1))); which is less readable and, IMHO, barely tolerable on the long run: too much typing. It seems that the reason is the explicit keyword in the constructor. My question is: why? what was the danger without the explicit? Thank you very much for any info, Maurizio

3 2

RE: [Boost-Users] Why "explicit" in shared_ptr's constructor?
by Tom Matelich 28 Mar '03

28 Mar '03

the danger comes from code like so: void foo(boost::shared_ptr<entity> p) { ... } void bar() { entity* e = new entity; foo(e); delete e; } Allowing a pointer to be converted to a shared_ptr implicitly could cause serious bugs. You could shorten things with this (untested) function: template <typename T> boost::shared_ptr<T> make_sp(T* p) { return boost::shared_ptr<T>(p); } > -----Original Message----- > From: Maurizio Colucci [mailto:seguso@email.it] > Sent: Friday, March 28, 2003 8:36 AM > To: Boost-Users(a)yahoogroups.com > Subject: [Boost-Users] Why "explicit" in shared_ptr's constructor? > > > Hello, > > I am a newbie user of boost. > > I have a question about boost::shared_ptr. Suppose you have a > polimorphic list: > > class entity{ ...}; > > > class simple_entity : public entity{ > public: > uint id; > simple_entity(uint i) : id(i) {} > }; > > int main(){ > list<shared_ptr<entity> > l; > ... > > > I noticed the following code doesn't compile > > l.push_back(new simple_entity(1)); > > too bad, because it was very easy to read, and very similar to the > behavior if standard pointers (not to speak about similarity to Java > and C#). So I am forced to do > > l.push_back(shared_ptr<entity> (new simple_entity(1))); > > which is less readable and, IMHO, barely tolerable on the long > run: too much typing. > > It seems that the reason is the explicit keyword in the > constructor. My question is: why? what was the danger without the > explicit? > > Thank you very much for any info, > > Maurizio > > > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Get 128 Bit SSL Encryption! > http://us.click.yahoo.com/xaxhjB/hdqFAA/xGHJAA/EbFolB/TM > -------------------------------------------------------------- > -------~-> > > Info: <http://www.boost.org> > Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> > Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

2 1

Boost.Thread 1.30 cause lot's of warnings and errors under vc 7.1
by Black Ice 28 Mar '03

28 Mar '03

void foo(string & str) { str = "foo"; } int main(int argc, char * argv[]) { string str1("Hello world"); string str2(str1); thread trd1(bind(&foo, str1)); thread trd2(bind(&foo, str2)); trd1.join(); trd2.join(); return 0; } The following is the compile log: Compiling... testThread.cpp d:\Programming\boost\boost\boost\thread\exceptions.hpp(29) : warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(14) : see declaration of 'std::logic_error' d:\Programming\boost\boost\boost\thread\exceptions.hpp(28) : see declaration of 'boost::lock_error' d:\Programming\boost\boost\boost\thread\exceptions.hpp(35) : warning C4275: non dll-interface class 'std::runtime_error' used as base for dll-interface class 'boost::thread_resource_error' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(136) : see declaration of 'std::runtime_error' d:\Programming\boost\boost\boost\thread\exceptions.hpp(34) : see declaration of 'boost::thread_resource_error' d:\Programming\boost\boost\boost\thread\mutex.hpp(37) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::mutex' d:\Programming\boost\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' d:\Programming\boost\boost\boost\thread\mutex.hpp(36) : see declaration of 'boost::mutex' d:\Programming\boost\boost\boost\thread\mutex.hpp(75) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::try_mutex' d:\Programming\boost\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' d:\Programming\boost\boost\boost\thread\mutex.hpp(74) : see declaration of 'boost::try_mutex' d:\Programming\boost\boost\boost\thread\mutex.hpp(115) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::timed_mutex' d:\Programming\boost\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' d:\Programming\boost\boost\boost\thread\mutex.hpp(114) : see declaration of 'boost::timed_mutex' d:\Programming\boost\boost\boost\thread\thread.hpp(39) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::thread' d:\Programming\boost\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' d:\Programming\boost\boost\boost\thread\thread.hpp(38) : see declaration of 'boost::thread' d:\Programming\boost\boost\boost\thread\thread.hpp(68) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::thread_group' d:\Programming\boost\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' d:\Programming\boost\boost\boost\thread\thread.hpp(67) : see declaration of 'boost::thread_group' d:\Programming\boost\boost\boost\thread\thread.hpp(79) : warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' with [ _Ty=boost::thread * ] d:\Programming\boost\boost\boost\bind.hpp(186) : error C2664: 'void (std::string &)' : cannot convert parameter 1 from 'const std::string' to 'std::string &' Conversion loses qualifiers d:\Programming\boost\boost\boost\bind\bind_template.hpp(21) : see reference to function template instantiation 'R boost::_bi::list1<A1>::operator ()<boost::_bi::bind_t<R,F,L>::result_type,void(__cdecl *)(std::string &),boost::_bi::list0>(boost::_bi::type<T>,F,A &) const' being compiled with [ R=boost::_bi::bind_t<void,void (__cdecl *)(std::string &),boost::_bi::list1<boost::_bi::list_av_1<std::string>::B1>>::result_type, A1=boost::_bi::list_av_1<std::string>::B1, F=void (__cdecl *)(std::string &), L=boost::_bi::list1<boost::_bi::list_av_1<std::string>::B1>, T=boost::_bi::bind_t<void,void (__cdecl *)(std::string &),boost::_bi::list1<boost::_bi::list_av_1<std::string>::B1>>::result_type, A=boost::_bi::list0 ] d:\Programming\boost\boost\boost\bind\bind_template.hpp(19) : while compiling class-template member function 'boost::_bi::bind_t<R,F,L>::result_type boost::_bi::bind_t<R,F,L>::operator ()(void)' with [ R=void, F=void (__cdecl *)(std::string &), L=boost::_bi::list1<boost::_bi::list_av_1<std::string>::B1> ] d:\Programming\project\testBoost\testThread\testThread.cpp(36) : see reference to class template instantiation 'boost::_bi::bind_t<R,F,L>' being compiled with [ R=void, F=void (__cdecl *)(std::string &), L=boost::_bi::list1<boost::_bi::list_av_1<std::string>::B1> ] Build log was saved at "file://d:\Programming\project\testBoost\testThread\Debug\BuildLog.htm" testThread - 1 error(s), 8 warning(s) Any suggestions are appreciated.

2 3

[uBLAS] operations thoughts
by vladimir josef sykora 28 Mar '03

28 Mar '03

Hello, Had a quick look into uBLAS library, and noted the incompatibility between std::vector<> and ublas' binary operations. For example, I have an ublas::matrix<> and wanted to multiply it by a std::vector<>. Since _all_ of ublas data containers provide iterators, I'm wondering why the library doesn't provide algorithms that work on iterators? In this way data structures and operators will be decoupled. For example, to do the product between a matrix and a vector: ********* untested code ********* template <class MatrixRowIterator, class MatrixColIterator, class InputIterator, class OutputIterator> OutputIterator prod(MatrixRowIterator first_row, MatrixRowIterator last_row, MatrixColIterator, InputIterator first_vec, OutputIterator result) { InputIterator cp_first=first_vec; while(first_row!=last_row) { typename MatrixRowIterator::value_type val(0); MatrixColIterator first_col, last_col; first_col=first_row.begin(); last_col=first_row.end(); while(first_col!=last_col) val+= *first_col++ * *first_vec++; *result++ = val; ++first_row; first_vec=cp_first; } return result; } // user side : prod(umatrix.begin1(), umatrix.end1(), umatrix.begin2(), std_vector.begin(), std::back_inserter(std_vector_result)); This of course with the respective preconditions. Also, wouldn't be a good idea to provide copy c'tor and operators accepting std::vector<> for the ublas::vector<> ? Regards, -- vladimir josef sykora morphochem AG gmunder str. 37-37a 81379 muenchen tel. ++49-89-78005-0 fax ++49-89-78005-555 vladimir.sykora(a)morphochem.de http://www.morphochem.de

2 1

BGL properties question
by Jeff Holle 28 Mar '03

28 Mar '03

I would like to write a "generic" routine that prints the named vertex and edges properties. I can see in this code sibit (from graphviz.cpp) that the info that I want is present: > vertex_label(const Vertex& u, const GraphvizDigraph& g) { > boost::property_map<GraphvizDigraph, > boost::vertex_attribute_t>::const_type > va = boost::get(boost::vertex_attribute, g); > return (*(va[u].find("label"))).second; > } It appears that va is a map<Vertex, map<string, "property value"> > How would I write code that prints the names of the properites of a given vertex? (It would involve iterating over the map whose find method is used in the above code segment).

2 1

BGL 1.30.0 upgrade problem
by Jeff Holle 28 Mar '03

28 Mar '03

Having switched from boost_1_29_0 to boost_1_30_0, code that was compiling and running now produces this error message: I'm using Mandrake linux 9.0 with the gcc v3.22 compiler. /home/jholle/boost_1_30_0/boost/graph/connected_components.hpp: In function `boost::property_traits<IndexMap>::value_type boost::connected_components(const Graph&, ComponentMap) [with Graph = boost::subgraph<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::GraphvizVertexProperty, boost::GraphvizEdgeProperty, boost::GraphvizGraphProperty, boost::listS> >, ComponentMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<size_t*, std::vector<size_t, std::allocator<size_t> > >, boost::subgraph_property_map<boost::subgraph<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::GraphvizVertexProperty, boost::GraphvizEdgeProperty, boost::GraphvizGraphProperty, boost::listS> >*, boost::vec_adj_list_vertex_id_map<boost::GraphvizVertexProperty, size_t> >, unsigned int, unsigned int&>]': BGLLayout.cpp:49: instantiated from here /home/jholle/boost_1_30_0/boost/graph/connected_components.hpp:99: `sizeof' applied to incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' The code that produced this error is: void BGLLayout::FindComponents(void) { typedef vector<unsigned int> Ints; Ints c(num_vertices(m_graph)); connected_components(m_graph, make_iterator_property_map(c.begin(), get(vertex_index, m_graph), c[0])); << -- line 49 (error source) m_componentStartVertex.clear(); unsigned int i=0; for (Ints::const_iterator iter=c.begin(); iter != c.end(); ++iter,++i) if (m_componentStartVertex.size() <= *iter) m_componentStartVertex.push_back(i); } Note this code is largely taken from connected_components.cpp. Can anybody tell me what is wrong here?

3 5

'boost::detail' problem
by Alejandro Escalante Medina 27 Mar '03

27 Mar '03

I do also a problem with some code that used to work in 1.29. The following is the output of VC7: d:\development\boost\libs\test\src\unit_test_main.cpp(63) : error C2872: 'detail' : ambiguous symbol could be 'boost::unit_test_framework::detail' or 'boost::detail' I saw someone reported something similar, but I couln't figure out what's wrong... Any ideas? Alex _________________________________________________________ Do You Yahoo!? La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

2 4

Re: bjam issue related to boost::python
by Ben Hutchings 27 Mar '03

27 Mar '03

In article <23681.5566233874$1028263753(a)news.gmane.org>, Srivatsan Raghavan wrote: > hi all , > i created a c++ extension module using python which worked fine.. > > then i wanted to embed a call to PyRun_SimpleFile in another app, > and the script i was calling is attempting to use my extension module > > but i was getting telling me that the interpreter wasn't initialized > after much searching, research, and work with msvc's Dependency Walker > i narrowed it down to the fact that boost_python_debug.dll is trying to > link to the release version of python22.dll , whereas it should be > linking to python22_d.dll (which unfortunately does not come with the > python installer , that has to be compiled manually ) > > at any rate, how can the boost::python Jamfile be modified to try this > check when it comes boost::python ? This is correct. The 'debug' configuration is meant to work with a release version of Python, though I don't know why. However, there is no need to modify the Jamfile; just use the 'debug-python' configuration instead. Also, make sure you include <pyconfig.h> before any of the Boost.Python headers, because not all of them do that and you can end up with incorrect structure definitions in a debug build if you don't. (I should report this bug.)

2 4