- Boost - lists.boost.org

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

Re: [boost] [bitfield] Initial bitfield proposal available inthevault
by Martin Bonner 08 Mar '06

08 Mar '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little Sent: 08 March 2006 03:42 To: boost(a)lists.boost.org Subject: Re: [boost] [bitfield] Initial bitfield proposal available inthevault > "Emile Cormier" wrote > >> Martin is on to something about using pointers. I'm not sure I am. I was trying to explain (and failing) why structs may be larger than their embedded data. (By making the struct larger, the pointer can be smaller). > Surely any pointer must be capable of being converted to a void* > which means void* has to know about the extra bits? How does that work? sizeof(struct*) <= sizeof(void*) sizeof(char*)==sizeof(void*) Note that if you cast an unsigned char* to an arbitrary struct* and back, you are **NOT** guaranteed to get your original pointer back. On the other hand you are guaranteed that casting an arbitrary pointer to struct to another pointer to struct and back will return you the original value. > I would have thought it would be possible to reinterpret_cast (or > somehow > convert) the struct to the inbuilt type in these situations isnt it > thus fooling > the compiler into storing that type? > The problem I see is that there seems to be two types of pointers > here which doesnt seem to be standard C++ behaviour? It is, oh it is! -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

1 0

Re: [boost] [bitfield] Initial bitfield proposal availableinthevault
by Martin Bonner 08 Mar '06

08 Mar '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little Sent: 07 March 2006 17:43 To: boost(a)lists.boost.org Subject: Re: [boost] [bitfield] Initial bitfield proposal availableinthevault > "Martin Bonner" wrote >> Andy Little wrote >>> "Martin Bonner" <martin.bonner(a)pitechnology.com> wrote in message >>> news:D997BF79D1E92C4793B7FCC04B4F90A51D79B6@pigeon.pi.local... >>>> ----Original Message---- >>>> From: Emile Cormier >>>> >>>>> The bitfield mechanism relies on this assumption: Unions of >>>>> non-polymorphic, non-derived objects, having the exact same >>>>> underlying data member type, will have the same size as this >>>>> underlying data member type. I'm no language lawyer, so please let >>>>> me know if this is a safe and portable assumption. >>>> >>>> I'm not quite sure what you mean, but given: >>>> struct a { unsigned char ch; }; >>>> struct b { unsigned char ch; }; >>>> union u { a theA; b theB }; >>>> then you are not guaranteed that sizeof(u) == sizeof(unsigned >>>> char). >>> >>> Though in practise you can use: >>> >>> BOOST_STATIC_ASSERT(sizeof(u) == sizeof(unsigned char)) >> >> My point was exactly that you CANNOT use that. (On a certain class >> of machine). > > Why not?. Will it a) compile but be incorrect or b) not compile but > be incorrect > or c) not compile but be correct? The assert will fire. > How do you store an unsigned char then? (And whatever way that is > just pretend to the hardware that the struct is an unsigned char) Storing an unsigned char is expensive. It involves extra bit twiddling. (See below) > >>>> On word addressed machines (which /are/ still being built), it is >>>> almost certain that the minimum size for a struct is a complete >>>> word. This is because the C and C++ standards effectively promise >>>> that pointers to structs are all of the same size (the size of a >>>> pointer-to-struct does not depend on the contents of the struct). >>>> It is desirable that a pointer-to-struct be the smaller, >>>> cheaper-to-dereference pointer to word (rather than the larger >>>> more-expensive-to-dereference pointer to char), so the smallest >>>> struct has to occupy a whole word. >>> >>> I dont see why the size of a pointer to a struct affects the size of >>> a struct which in the case of an empty struct is often 1 byte? >> >> I don't think you have understood what a word addressed machine is! >> >> On most modern archictectures there are 8 bits stored at (for >> example) 0x100 and another 8 bits at 0x101. The 32 bits at 0x100 >> cover 0x100, 0x101, 0x102, and 0x103. >> >> On a word addressed machine, there may be 36 bits stored at 02000 and >> another (different) 36 bits stored at 02001. A simple 36-bit pointer >> can address individual words, but not sub-units within those words. >> To address individual bytes, you need a double-word pointer. One >> word identifies the word, and a few bits within the second word >> identifies which byte you are addressing. >> >> On such a machine, it makes sense for an empty struct to occupy a >> whole word (which is four nine-bit bytes), so that a pointer to >> struct can (always) be a single word pointer. > > Sounds like there is a choice. Either make unsigned char 36 bits and > use a small pointer or make unsigned char 9 bits and use a large > pointer. Yup. And the COMPILER writer gets to make that choice. > I dont know whether C++ will allow both? It will allow the compiler writer to make either of those choices, > It reminds me of the old Microchip PIC architecture > though. Last I looked they were working to make their hardware > compatible with C FWIW and just increasing the number of address > lines, because they were previously so difficult to deal with, with > the separate extra bits in an address and so on (though that was a > kind of paged memory IIRC). IOW in their case they > realised the downside of the idea as I understand it and moved to one > drop linear addressing for later designs. I believe it is a similar sort of idea. This is the same sort of thing as Prime changing their instruction set so that memset( ptr, 0, sizeof(ptr) ) set ptr to a null pointer (the natural representation of a null pointer on a Prime was 07777/000000). > > Maybe I have got the wrong end of the proverbial stick again though ? My point is that assuming >>> BOOST_STATIC_ASSERT(sizeof(u) == sizeof(unsigned char)) Means that there is a class of C++ implementations where the library will not work. It is then up to the library author to consider whether that class is suffiently important to change his implementation for (it may well not be). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

1 0