- Boost - lists.boost.org

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

OT Query: Robert G. Burger and R. Kent Dybvig, "Printing Floating-Point Numbers Quickly and Accurately"
by Paul A Bristow 08 Mar '06

08 Mar '06

Sorry for an Off-topic question, but does anyone know of a C/C++ Implementation of a C++ algorithm based on the paper by Robert G. Burger and R. Kent Dybvig, entitled: "Printing Floating-Point Numbers Quickly and Accurately" http://portal.acm.org/citation.cfm?doid=989393.989430 ACM subscribers only http://citeseer.ist.psu.edu/cache/papers/cs/2654/http:zSzzSzwww.cs.indiana.e duzSz~burgerzSzFP-Printing-PLDI96.pdf/printing-floating-point-numbers.pdf Many thanks. Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow(a)hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html

2 2

[date_time] [MSVC8] Memory leak in operator<<(ptime)
by Alo Sarv 08 Mar '06

08 Mar '06

The following test app illustrates a memory leak that I'v been able to produce so far with MSVC 8.0 (earlier versions not tested). GCC 4.0 seems to be unaffected. The leakage in case of this test app is around 12kb/s. #include <iostream> #include <boost/date_time/posix_time/posix_time.hpp> using namespace boost::posix_time; int main(int argc, char *argv[]) { ptime t(second_clock::local_time()); while (true) { std::cout << t << "\r"; } return 0; } Tested against Boost 1.33.1 release. Compiled with cl test.cpp /I c:\boost_1_33_1 /D _CRT_SECURE_NO_DEPRECATE /EHsc /D BOOST_ALL_NO_LIB -- Alo Sarv

6 15

[Boost-bugs] [ boost-Support Requests-1445474 ] boost.iostreams file_descriptor and sharing
by SourceForge.net 08 Mar '06

08 Mar '06

Support Requests item #1445474, was opened at 2006-03-08 01:03 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=1445474&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost.iostreams file_descriptor and sharing Initial Comment: Hi! I have couple of questions about the behavior of boost::iostreams::file_descriptor. First, I've noticed that it always opens files with exclusive access. That is, it calls CreateFileA with a dwShareMode of 0, which means that "the object cannot be shared and cannot be opened again until the handle is closed". Is this by design? Wouldn't it be reasonable to use a share mode of FILE_SHARE_READ when opening a file only for reading? Second, the function file_descriptor::open has a third parameter 'base', which appears to be extra open mode bits that are always on, in addition to those in the second parameter to stream::open. What is the purpose of this? Since there is a stream::open function with three parameters I can specify these extra bits as well when opening the file, in order to actually get the file opened only for reading, but I worry that this will somehow violate the design of the file_descriptor class. I've modified my copy of file_descriptor::open to use a share mode of FILE_SHARE_READ when opening a file only for reading and am now calling stream::open with three arguments in order to make this happen. Is this safe? It appears to work in the very limited cases I've tried so far. Yours, Gunnar Blomberg (Gunnar.Blomberg(a)iar.se) PS. Thanks for an excellent library! DS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1445474&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

[V2, 1.34] Qt support issues
by Juergen Hunold 08 Mar '06

08 Mar '06

Hi ! The branch for the 1.34 is coming nearer and I've been thinking about the support for Trolltech's Qt Library. Right now, we have a minimal toolset named "qt.jam" which provides rudimental support for Qt <= 3.3.5. Is does not have library name detection (necessary on Win32) and no support for Qt3 image embedding. And then we have a toolset named "qt4.jam" which provides much better support for Qt >= 4.1. Is has support for all kinds of "moc" invocation and provides support for image embedding via Qt4 "rcc" resource compiler. I think it would be best to rename "qt.jam" to "qt3.jam" and mark it as "unmaintained" or maybe "deprecated" or both. The old "qt4.jam" should be named "qt.jam". I think this is the last chance to do a clean switch before we switch to V2 and provide an obsolete toolset as "qt.jam" I hope that this change can be made while we are in feature freeze because V1 has never had any "official" support for any version of Qt. Volodya, Thomas: What are you thinking about this ? And now for some more technical problems: qt4.jam has an optional "prefix" parameter which defaults to QTDIR when not provided by the user. I'd like the prefix (aka Qt install dir) parameter to be required as Trolltech officially dropped the usage of QTDIR with Qt4. Alls paths are compiled into the "qmake" makefile generator when running configure. I think we should drop QTDIR support, too. And last: I can't use qt.jam and qt4.jam side-by-side because both use the same "types/qt.jam" file and bjam just segfaults while trying to load both toolsets. -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * hunold(a)ive-mbh.de ! www.ive-mbh.de

2 1

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

08 Mar '06

----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). 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. HOWEVER, if your structures and unions are using unsigned char, why not just use "unsigned char *" instead? If you are using unsigned short (or longer types), then you are almost certain to be safe. It is not guaranteed by the standard; a compiler /can/ pad all structures to 256 bits if it wants to, but in practise compilers don't. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

3 3