August 2005 - Boost-users - lists.boost.org

Regex Lib: Feature Set: Newbie ?
by Jordanna Chord 26 Aug '05

26 Aug '05

Newbie question; I'm porting a project from PCRE 3.9 to the most recent version of Boost Regex++. Has anyone compiled a list of differences between the regex supported by Boost and other libraries such as PCRE which supports Perl 5? Thanks, Lacey

2 1

Boost.Random: Suspicious code in uniform_smallint_integer
by Daniel Krügler 26 Aug '05

26 Aug '05

Although uniform_smallint_integer currently is no official code (its in the details section and seems nowhere used), I would like to mention, that the current implementation contains a subtle bug: The member _factor is never initialized, thus calling operator()() would cause U.B. The reason is, that the initializer member function set defines a **local** variable _factor, which is never assigned to this->_factor, such that uniform_smallint_integer::_factor will never be assigned. Just one question: Is detail::uniform_smallint_integer a leftover of some experiments by the library responsible or does it exist for interested boost users to test it? Greetings from Bremen, Daniel

1 0

Re: [Boost-users] Boost serialization
by Li Lirong 26 Aug '05

26 Aug '05

You may try to serialize the data to a std::vector. See here for how to write a ostream with std::vector: http://www.boost.org/libs/iostreams/doc/tutorial/container_sink.html Regards, Lirong --- Srikanth Rao <srirao_us(a)yahoo.com> wrote: > Hi, > > I saw a mail from you to the group. I have a similar > issue but I need to send the serialized data on the > network. > > After serializing to a stream, can I get the buffer? > > How? > TIA, > Sri. > > > > __________________________________ > Yahoo! Mail for Mobile > Take Yahoo! Mail with you! Check email on your > mobile phone. > http://mobile.yahoo.com/learn/mail > __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

1 0

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

25 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Elisha Berns > Sent: Wednesday, August 24, 2005 8:48 PM > To: Boost > Subject: [Boost-users] Boost.Thread memory leak reported > > > > Detected memory leaks! > Dumping objects -> > {146} normal block at 0x00227008, 24 bytes long. > Data: < | > 08 7C 04 00 FF FF FF FF 00 00 00 00 00 00 00 > 00 > {145} normal block at 0x00223928, 8 bytes long. > Data: < p" > 08 70 22 00 01 CD CD CD > Object dump complete. Hi Elisha, Could you come up with a small test case that demonstrates the problem?

4 7

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

25 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Christian Henning > Sent: Thursday, August 25, 2005 4:03 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Boost.Thread memory leak reported > > > I'm just wondering why Purify doesn't show anything. (it sucks) Disclaimer: I only used it enough to make the above statement

1 0

[Test] redirecting unit test report
by Kim Barrett 25 Aug '05

25 Aug '05

I'm using the unit test framework provided by Boost.Test, mostly using the auto unit test facility. I wrote a parser for the XML formatted report output, as part of a regression package. Unfortunately, changes between 1.32 and 1.33 are causing a problem. The format of the XML output changed quite a bit between 1.32 and 1.33. Ok, I can deal with that; in fact, the new format is quite a bit easier to deal with, and I've already finished with the changes. It would be nice if this format were documented though. Unfortunately, there is one change that I haven't been able to figure out a good way to deal with. If a test case aborts, due to an exception uncaught by the test itself, the exception is caught by the unit test framework. The occurrence of the abort is recorded in the test results. In 1.32, this would be reported by including an <aborted ...> subentry for the test case data, including some descriptive text. In 1.33, the descriptive text is printed to std::cerr and the report indicates that the test case was aborted via the "result" value for the test case. The generated report no longer contains the descriptive text. (I don't care all that much about this last change.) The problem is the printing of the descriptive text for the exception to std::cerr. That is also the stream to which the test report is written, and I'm capturing the report information by redirecting stderr to a file when invoking a test program. The exception text ends up appearing at the beginning of the report file, and isn't valid XML, which causes my report parser to die. (If necessary, I may end up prefixing the parser with a step to skip over anything that doesn't look like XML, but that's pretty ugly.) Now, I never really liked redirecting stderr to a file in order to capture the report. What if something in the test program were to write to stderr? (Which is exactly what is happening now.) I see that there is now (in 1.33) a mechanism for setting the stream used by the report generator (boost:unit_test::results_reporter::set_stream()). But after spending the last couple of days pouring over the documentation and sources for Boost.Test, I have no idea where I would put a call to that function that doesn't involve patching the Boost.Test sources. There doesn't seem to be a place to insert such user code, at least not that I can find. Have I overlooked something, or is this really a hole in the present design / implementation?

3 13

Intermittent problem(s) building boost 1.33 with VC7.1
by Elisha Berns 25 Aug '05

25 Aug '05

The message "failed to write command file" comes up intermittently and seemingly at random when I build some or all of the 1.33 libraries. Once that message appears the build is killed and that's it. So far I have only been able to build the thread and iostreams libraries. What's the deal? Is it some problem with my machine, or with the build itself? Thanks, Elisha Berns e.berns(a)computer.org tel. (310) 556 - 8332 fax (310) 556 - 2839

2 1

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

25 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Christian Henning > Sent: Thursday, August 25, 2005 10:53 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Boost.Thread memory leak reported > > > On 8/25/05, Sohail Somani <s.somani(a)fincad.com> wrote: > > Valgrind doesn't find it either. I have yet to try it with stack > > walker (was about to but xp blue screened so I took it as a sign) > > > > Isn't valgrind for linux? I think the problem might be on > Windows machines, only. > > The functions new_critical_section() and > delete_critical_section() should be called only on Windows > machines, since they are calling Win32 functions. I didn't know it was a Windows only problem until you posted the location of the leaked allocation.

2 1

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

25 Aug '05

Valgrind doesn't find it either. I have yet to try it with stack walker (was about to but xp blue screened so I took it as a sign) > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Elisha Berns > Sent: Thursday, August 25, 2005 9:45 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Boost.Thread memory leak reported > > > Right, > > Those are the same project settings I'm using. The only > difference is that my code is in a non-MFC class. I tested > it with the VLD memory leak detector found on CodeProject and > it also reports zero leaks. > > Elisha > > > I got exactly the same error. Here is how I did it: > > > > I created a project of a MFC Application inside VC7.1 . The wizards > > creates the usual document/view classes. Inside the > document class I > > placed, like Elisha, a mutex. Inside the OnNewDocument() function I > > put the code from Elisha: > > > > BOOL CMFCTestDoc::OnNewDocument() > > { > > if (!CDocument::OnNewDocument()) > > return FALSE; > > > > // TODO: add reinitialization code here > > // (SDI documents will reuse this document) > > > > boost::thread indexer( > > boost::bind(&CMFCTestDoc::run, this)); > > > > boost::mutex::scoped_lock lock(m_orphan_annotation_mutex); > > > > indexer.join(); > > > > > > return TRUE; > > } > > > > I'm using MFC in a Shared DLL and Multithreaded Debug DLL runtime > libs. > > > > I can send the project files to anyone that is interessted. > > > > By the way, if I use Purify to track down the leaks, it cannot find > them. > > > > Regards, > > Christian > > > > > > > > > > On 8/25/05, Sohail Somani <s.somani(a)fincad.com> wrote: > > > > -----Original Message----- > > > > From: boost-users-bounces(a)lists.boost.org > > > > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Elisha > Berns > > > > Sent: Wednesday, August 24, 2005 8:48 PM > > > > To: Boost > > > > Subject: [Boost-users] Boost.Thread memory leak reported > > > > > > > > > > > > > > > > Detected memory leaks! > > > > Dumping objects -> > > > > {146} normal block at 0x00227008, 24 bytes long. > > > > Data: < | > 08 7C 04 00 FF FF FF FF 00 00 00 00 00 > 00 00 > > > > 00 > > > > {145} normal block at 0x00223928, 8 bytes long. > > > > Data: < p" > 08 70 22 00 01 CD CD CD > > > > Object dump complete. > > > > > > Hi Elisha, > > > > > > Could you come up with a small test case that demonstrates the > problem? > > > > > > > > > _______________________________________________ > > > Boost-users mailing list > > > Boost-users(a)lists.boost.org > > > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > > > > > > _______________________________________________ > > Boost-users mailing list > > Boost-users(a)lists.boost.org > > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

2 1

[filesystem] Mingw DLL problems
by Paul 25 Aug '05

25 Aug '05

Hi all, It seems that theres a lot of traffic in regards to using filesystem as a DLL with mingw (or other) compilers. I'd like to lay out what I know and try and figure out a solution for it. Or at least ask for a work-around to be added to the CVS, or to the documentation! Often I see complaints that it will fail to work as expected! This is because the 'native' "flag" passed to path will be virtually IGNORED when you link to it as a DLL. Why? Because native is not a flag, its a free function pointer. Inside the filesystem DLL, it compares the address of the passed checker against its version of 'native', however: the address of 'native' is DIFFERENT in the DLL compared with any other DLL or your executable! So native(you) != native(DLL), so paths will be checked the POSIX way, not the native way. I've heard suggestions that you should define BOOST_ALL_DYN_LINK, however that doesn't seem to do anything in my case. I've tested it. I am betting that most people 'solve' it by statically linking to it, but thats not an option for me. The only solution I have come up with is to add a function to get the DLL's native function address. Instead of passing 'native', I now pass get_native(). This just does return native; but it does it inside the DLL, so you get the "right" function address. Beman said that it should be fixed in the next version of filesystem, however it appears to be Not Hear Yet. So can we please please get an interim fix? Attached was my attempt from back in January, it worked for me, and I'll be applying it to my shiny new 1.33 version. Thanks Paul

1 0