- Boost - lists.boost.org

[filesystem] static object throws
by Vladimir Prus 09 Mar '06

09 Mar '06

Hi, an application of mine just suddenly crashed before entering 'main', with the following stacktrace: #5 0xb7eb7106 in __cxa_throw () from /usr/lib/libstdc++.so.5 #6 0xb7e6ccb0 in std::__throw_runtime_error () from /usr/lib/libstdc++.so.5 #7 0xb7eb5c8e in std::locale::facet::_S_create_c_locale () from /usr/lib/libstdc++.so.5 #8 0xb7e96554 in std::locale::_Impl::_Impl () from /usr/lib/libstdc++.so.5 #9 0xb7e768e9 in std::locale::locale () from /usr/lib/libstdc++.so.5 #10 0xb78f6922 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /space/NM/boost/libs/filesystem/src/path.cpp:29 And the line in question contains just: 29 std::locale loc(""); This is CVS as of today. The problem was that I incorrectly set the LC_MESSAGES environment variable. However, I think that exception from static object is not so good idea. I can't catch it, so the error reporting just reads "Aborted". Maybe, this can be converted into a function with static variable, so that the static variable is only initialized on the first call? TIA, Volodya

2 4

Re: [boost] [multi_index]boost/boost/multi_index/detail/index_base.hpp:49:error
by JOAQUIN LOPEZ MU?Z 09 Mar '06

09 Mar '06

----- Mensaje original ----- De: Felipe Magno de Almeida <felipe.m.almeida(a)gmail.com> Fecha: Martes, Marzo 7, 2006 6:34 pm Asunto: Re: [boost][multi_index] boost/boost/multi_index/detail/index_base.hpp:49:error > On 3/6/06, Joaquín Mª López Muñoz <joaquin(a)tid.es> wrote: > > [snip] > > > > > > > typedef std::pair<iterator, iterator> iterator_pair; > > > > Here. What is this "iterator" type? What index.equal_range(name) > > returns is a > > typedef headers_multi_index_t::nth_index<1>::type::iterator iterator; [...] > Looks like that's not the problem > Yep, looks like this is OK, and, as you say, the thing works on other compilers. The following is a shot in the dark. Can replace your typedef headers_multi_index_t::nth_index<1>::type::iterator iterator; with something like typedef headers_multi_index_t::nth_index<1>::type::iterator my_iterator; // note, name changed adjust the dependent typedefs and try to compile? Older versions of GCC have sometimes clashing symbol problems with symbols that ought not to clash. Additionally, I'd check the using decls and directives in effect. If this does not shed any light, it'd be extremely helpful if you can isolate the problem into a complete testcase you can post or send to me. I've tried myself to reproduce the issue following your general code outline, but didn't get the compiler to choke as you have reported. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

Re: [boost] bug in filesystem::wpath
by Jan Hermelink 09 Mar '06

09 Mar '06

>> As already reported in >> http://article.gmane.org/gmane.comp.lib.boost.devel/128277, >> narrow_path() doesn't work if short filename generation is disabled. As >> a workaround I have fstream.hpp patched for using the non-standard wide >> char fstream constructors in VC8 (Dinkumware library). Indeed this works >> for VC8 only... > Would you like to contribute your patch? That might be faster and easier > than waiting for me to get around to it! Shure. Patch against current CVS attached. >> Ok, I >> have seen the free function what() but what it's the rationale not >> including it in the exception object? > The what() free function provides more elaborate formatting. The member > what() function is minimal, and so doesn't have as many memory allocation > issues. The approach is take to follow the guidelines at > www.boost.org/more/error_handling.html. I see. It's a pity, it would be fine to have m_path1 and m_path2 provided by the what() member... Cheers, Jan

2 1

[bitfield] More portable implementation available in the vault
by Emile Cormier 09 Mar '06

09 Mar '06

Bitfield2.zip in http://boost-consulting.com/vault/index.php?direction=0&order=&directory=bi… For now, I didn't bother to adapt my code to Boost's style. I'm using this stuff at work where we have a different coding style. Check out the html folder for the doxygen page, which shows usage examples. I removed Bitfield::operator(), as its purpose was not self-evident. I think this version will not suffer from memory alignment/padding problems as did the previous version. The test code runs fine with GCC MinGW 3.4. I plan on using it on an ARM platform, so I'll confirm if it runs okay on that platform too. Bitfield now accepts a 4th template parameter, R, which is the reference type used by Bitfield to manipulate the word. The only requirements on this reference type are: - Has a default or copy constructor, depending on how you use it - Can be assigned a value of type T - Can be evaluated as a value of type T By default, R=T&, which is convenient for manipulating regular non-I/O-mapped integers. I demonstrate in PortExample.hpp how Bitfield can be used with special types which can interface to memory-mapped I/O ports. I've just read the n1666 "Technical Report on C++ Performance", and it seems like Bitfield would be ready to support the use of <iohw.h> ports. I need to study the proposed <iohw.h> some more to fully understand it, though. I will inspect mixed source+assembly to confirm that this Bitfield mechanism is as efficient as hand-written bit-manipulations. -- Emile Cormier emilecormier(a)mailcan.com

1 0

[Boost-bugs] [ boost-Bugs-1445983 ] Win32 windows_name() bug
by SourceForge.net 08 Mar '06

08 Mar '06

Bugs item #1445983, was opened at 2006-03-08 14:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1445983&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: filesystem Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Beman Dawes (beman_dawes) Summary: Win32 windows_name() bug Initial Comment: I have tried this with both Borland and MSVC ... trying to instantiate a boost::filesystem::path instance and getting the following error: Invalid name "D:" in path "D:\". One would figure that this should not happen, as that is a valid Win32 path name. My guess is the problem is the ":", since I tried "D\A", "D\A\B", "D\A\B\C", etc. and did not have any problem with them. Initially I thought is was my Borland compiler, but when it did the same thing with MSVC, then I figured that it was a bug somewhere in the library. If someone could point me in the right direction as to which particular file I need to look at I could probably fix the issue myself, but I would prefer a patch from one of the maintainers to keep the codebase the same as everyone else. Thanks. William william.clifford.mit(a)gmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1445983&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

yet another multimethods library
by Korcan Hussein 08 Mar '06

08 Mar '06

Hi, i'm on the verge of completing a first release of a fully featured multimethods component for C++, one in which i believe goes beyond anything currently available and is very suited to become part of boost. I'm fully aware of Jesse Jones's contribution however his library has not become an offical part of boost and i believe my version takes things much further in thew different ways and i have some nice ideas for the next version to make even better. It's inspired by boost/std::tr1::function and CLOS generic functions and thus works like bost::/std::tr1::function preferred syntax ALA function types e.g: typedef boost::shared_ptr<fuzz> fuzz_ptr; generic_function< void (const foo&, int, bar*, float, fuzz_ptr) > foobar; where foo, bar and fuzz are polymorphic types and automatically are considered for multiple dispatch, detection of which arguments are choosen for dispatch is automated (and yes there already is support for smart/proxy pointers/references in place with std::auto_ptr, boost::/std::tr1::shared/intrusive_ptr working out-the-box). The order and placement of arguments is irrelevant and non-polymorphic arguments are totally allowed, covariant return types comes for free and work similar to covariant return types of virtual member functions. I think i'll just stop writing about the library any further (abit more to it than this) i just like to know if you guys are interested in making this an offical part of boost and to be worked on further by myself and with the help of others. P.S By the way this has been built with boost mpl, preprocessor and type traits from the beginning and interlope with other boost components in mind i.e phoenix, lambda, fusion, bind, function etc, etc.

6 11

[Boost-bugs] [ boost-Patches-1438991 ] rational::operator<(rational) fails due to overflow
by SourceForge.net 08 Mar '06

08 Mar '06

Patches item #1438991, was opened at 2006-02-26 04:54 Message generated for change (Settings changed) made by mclow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1438991&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Benbennick (dbenbenn) >Assigned to: Jonathan Turkanis (turkanis) Summary: rational::operator<(rational) fails due to overflow Initial Comment: Consider boost::rational<long>. Pick two objects of that type at random (that's well defined, since there are only finitely many objects of that type), and pick them to both have the same sign. Call them a and b. Then the expression "a < b" returns the wrong value 50% of the time! The problem is that the calculation in rational.hpp can overflow, and that overflow actually happens most of the time. Here's a patch that implements operator< without overflow. It's somewhat less efficient (I haven't benchmarked it) but it gives the right answer. Possibly the new version of operator< has bugs. I've run a few hundred million random tests, with the right answer every time (I've used bc to check the answers), but there might be a subtle problem. In particular, the new code assumes that integer division always truncates towards 0, even when dividing negative integers. Perhaps that is not true on some obscure platforms/compilers? ---------------------------------------------------------------------- Comment By: David Benbennick (dbenbenn) Date: 2006-03-07 13:08 Message: Logged In: YES user_id=95581 Here's a new patch that uses std::numeric_limits to select the more efficient, direct comparison method for unbounded types, and only uses the overflow-avoiding method for types that can overflow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1438991&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] bug in filesystem::wpath
by Jan Hermelink 08 Mar '06

08 Mar '06

> PS: I'd like to hear from programmers using wide character file names. Are > they working OK? Are they meeting your needs? I use the wide character names for about three months with VC8 and after applying a similar patch like Mark I'm very satisfied with the library! Thank you. Three items doesn't meet my needs: As already reported in http://article.gmane.org/gmane.comp.lib.boost.devel/128277, narrow_path() doesn't work if short filename generation is disabled. As a workaround I have fstream.hpp patched for using the non-standard wide char fstream constructors in VC8 (Dinkumware library). Indeed this works for VC8 only... I would like to see a what() method in basic_filesystem_error. Ok, I have seen the free function what() but what it's the rationale not including it in the exception object? The documentation is yet incomplete (for instance the convenience functions are not documented I think). Jan -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Posted At: Thursday, February 23, 2006 10:35 PM Posted To: Boost Developer Conversation: [boost] bug in filesystem::wpath Subject: Re: [boost] bug in filesystem::wpath "Mark Bartosik" <mbartosik(a)yahoo.com> wrote in message news:dtjclm$7dr$1@sea.gmane.org... > bug in filesystem::wpath. > In mirgrating to support wchar_t, a couple of lines were missed. > m_path which has type of std::wstring is assigned a narrow character > string resulting in a compilation error. Fixed in CVS. Test cases were also added to wide_test.cpp. Thanks, --Beman PS: I'd like to hear from programmers using wide character file names. Are they working OK? Are they meeting your needs? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[optional] swapping
by Vaclav Vesely 08 Mar '06

08 Mar '06

Hi, When two optionals are swaped and only one is initialized, then wrapped value in the uninitialized optional is constructed and that in initialized one is destroyed. It's maybe not necessary. It should be sufficient and more effective to swap optional_base's member (m_initialized and m_storage). Is there any reason for this implementation? Regards, Vaclav

1 0

[Boost-bugs] [ boost-Support Requests-1445526 ] Max Flow Algorithm
by SourceForge.net 08 Mar '06

08 Mar '06

Support Requests item #1445526, was opened at 2006-03-08 11:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1445526&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vincenzo Failla (vfailla) Assigned to: Nobody/Anonymous (nobody) Summary: Max Flow Algorithm Initial Comment: Hi, I'm a student in Computer Science and Telecommunications. I'm working for my thesis job on graph algorithms and I'm developping a code for the k-cut and the multiterminal cut problem. To calculate max flow/minimum s-t cut, I used the Goldberg algorithm implemented in the Boost Library. Now I like to have more information (f.e.: the complexity) about Goldberg Algorithm used in Boost Library. I already gave a look to references section of Boost Project but I had some difficult to find the related Goldberg article ("A New Max-Flow Algorithm", 1985). However in a later article ("A New Approach to the Maximum-Flow Problem", Goldberg and Tarjan 1986) a complexity of O(n^3) for the Goldberg algorithm (1985) is given. After simulation tests, I think the algorithm implemented in Boost Library has lower complexity than O(n^3). Is this possible? Is there someone has the Goldberg article (1985)? I will be grateful if someone can help me. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1445526&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0