- Boost-users - lists.boost.org

Boost.Algorithm: Functors must be CopyConstructible
by Daniel Krügler 29 Aug '05

29 Aug '05

Several functors in Boost.Algorithm do not fulfill CopyConstructable requirements, e.g. case_conv.hpp: to_lowerF, to_upperF formatter_regex.hpp: regex_formatF I propose to replace their reference members by either corresponding pointers or by boost::reference<>'s. Greetings from Bremen, Daniel Krügler

2 2

strange filesystem dll behaviour
by Paul 28 Aug '05

28 Aug '05

Hi, I'm having killer problems with the filesystem library. I'm compiling it with bjam "-sTOOLS=mingw", which seems to work just fine. All the tests pass etc. Then I wrote this simple program: #include <boost/filesystem/path.hpp> #include <iostream> using namespace std; using namespace boost::filesystem; int main() { try { path p("c:",native); } catch (exception & e) { cerr << "Error: " << e.what() << endl; return 1; } cerr << "Ok" << endl; return 0; } and compiled it with the Makefile: test: test.cpp Makefile g++ -g -I../boost/boost-compiled -I. -Wall -c test.cpp g++ -g -Wl,-enable-stdcall-fixup -Wl,-subsystem,console -Wall -o test.exe test.o libboost_filesystem-mgw-d-1_32.lib g++ -g -Wl,-enable-stdcall-fixup -Wl,-subsystem,console -Wall -o test-dll.exe test.o -L. -lboost_filesystem-mgw-d-1_3 (adjust for your paths, I copied the dlls and libs into the local dir Just To Be Sure). The output of running the two programs is as follows: paul@xyz ~/test $ ./test Ok paul@xyz ~/test $ ./test-dll.exe Error: boost::filesystem::path: invalid name "c:" in path: "c:" Why does it behave differently depending on the linkage? If I must use a .lib, what if it needs to be used in multiple .dlls of mine? Help? Thanks Paul

3 10

[Test] typo in auto_unit_test.hpp
by Takeshi Mouri 28 Aug '05

28 Aug '05

Hello, line 198: BOOST_AUTO_TC_REGISTRAR( test_nase )( This may cause the redefinition of test_nase_registrar(). I think that it is not "test_nase" but "test_name". Regards, Takeshi Mouri

2 1

Rationale for explicit ctors in boost smart pointers
by Matthias Kaeppler 28 Aug '05

28 Aug '05

Hi, I was wondering why e.g. boost:shared_ptr has an explicit constructor. This makes automatic conversion from T* to shared_ptr<T> impossible. The lack of the opposite conversion is covered by the FAQ and reasonable; however, I couldn't think of a good reason why I shouldn't be able to do something like this: std::set< boost::shared_ptr<Foo> > coll; coll.insert(new Foo); // error: No implicit conversion from Foo* to shared_ptr<Foo> Best regards, Matthias

2 4

Problem of using Boost::regex
by Aaron 28 Aug '05

28 Aug '05

I want to make a program to grep all symbols in header file,like: #define CMD_BASE 0x10000000 #define CMD_GETFile (CMD_BASE + 0X00000001) /* Get a file from srv*/ A singl symbole definition line will be extract to three parts: 1. symbol itself 2. the value of a symbol, it's a signed 32-bit value 3. comments about the symbol I use the following pattern: std::string ptn = "\\s*#define\\s+([^\\s]+)\\s+([^/]*)([^\r\n]*)"; I hope this pattern could do what I want, but when I use grep to do the parsing, I got from above two lines: what[1]: CMD_BASE what[2]: 0x00001000#define CMD_GET_ALL_DOMAINNAME (CMD_IS_BASE+0x1) you see, the match extend to the new line! I noticed that when I use the same text, same pattern, doing the same thing in a vbscript program, if I set "Global match" option, this wouldn't happen. So, what's the counterpoint at boost::regex? My code here: bool OnGrepSingleLineSymbols(const boost::match_results<std::string::const_iterator>& what) { Symbol* sym = new Symbol; strcpy(sym->szSymbolName, what[1].str().c_str()); strcpy(sym->szSymbolInfo, what[3].str().c_str()); MakePretty(sym->szSymbolName); MakePretty(sym->szSymbolInfo); sym->nSymbolValue = ResolveMsgValue(sym->szSymbolName, what[2].str()); GetMsgSrv().AddSymbols(sym); return true; } void GrepSingleLineSymbols(CString& strSymContainer) { //#define ARN_SUCCESS 0l //ARRON!'HAHA //#define Arn_error1 ARN_SUCCESS + 0X0F //AARON ERROR1 static std::string ptn = "\\s*#define\\s+([^\\s]+)\\s+([^/]*)([^\r\n]*)"; static boost::regex re(ptn); std::string::const_iterator start, end; std::string text = strSymContainer; start = text.begin(); end = text.end(); boost::regex_grep(OnGrepSingleLineSymbols, start, end, re); }

2 3

[Serialization] Class versioning & upward compatibilty
by Flavio Antonioli 27 Aug '05

27 Aug '05

Hello, is serialization class versioning supposed to allow old versions of a program that serializes an old version of a class to load files saved with a newer version that saves some extra data? It doesn't seem to be able to do it, but it would be a very useful feature. The docs mention the fact that new versions can read old version classes, they don't mention if old versions can load newer versions files. Unless I'm missing something, which is not unlikely, it should be relatively easy to implement, the xml readed should simply skip fields that it doesn't recognize. I'm using XML serialization, boost_1_33_0 dated 28-4-05, Visual C++ 7.1 & 8.0 beta 2. Thanks, Flavio Antonioli.

2 1

[thread] RFE 1274707: Remove try/catch(...) in thread.cpp:thread_proxy()
by Matt Gruenke 27 Aug '05

27 Aug '05

I've submitted an RFE on this rather troubling behavior. I won't restate my case, as you can just view it here: http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7… Anyhow, it occurred to me that perhaps users with threads experience on other platforms (especially Windows) could comment on whether there's any similarly useful debugging behavior when exceptions are allowed to propagate outside of a thread (i.e. what the 'catch(...)' in libs/thread/src/thread.cpp:thread_proxy() specifically inhibits). If so, please update the RFE, rather than posting to the list. Matt Gruenke Software Engineer IntelliVid Corp.

1 0

Re: [Boost-users] Boost.Thread memory leak reported
by Sohail Somani 26 Aug '05

26 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peter Dimov > Sent: Friday, August 26, 2005 1:45 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Boost.Thread memory leak reported > > > Sohail Somani wrote: > > >>> Any dynamically allocated memory that isn't freed is a Bad > >> Thing imho. > >> > >> Because? > > > > Was it forgotten? Was it intentional? If the assumption is it will > > always be freed, then there is no ambiguity. > > Seems clearly intentional to me - the allocation is invoked > by call_once and > is a textbook implementation of a thread safe singleton. A > "this is not a > leak" comment may help. I understand its not a leak. There should atleast be a comment there saying we are not going to deallocate this memory that is allocated once. Its great you know, but part of this thread would have been avoided had there been that comment.

1 0

Re: [Boost-users] Boost.Thread memory leak reported
by Sohail Somani 26 Aug '05

26 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peter Dimov > Sent: Friday, August 26, 2005 1:07 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Boost.Thread memory leak reported > > > Christian Henning wrote: > > > But Peter, we do agree that there is problem and it should > be fixed, > > dont't we? > > I see no problems in the code. Any dynamically allocated memory that isn't freed is a Bad Thing imho.

2 1

Re: [Boost-users] Boost.Thread memory leak reported
by Foster Gareth 26 Aug '05

26 Aug '05

> Because Purify is smart and doesn't report false leaks. > "False leaks"??

3 3