- Boost - lists.boost.org

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

[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

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

[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

[Boost-bugs] [ boost-Bugs-1445242 ] read_write_mutex missing in release?
by SourceForge.net 08 Mar '06

08 Mar '06

Bugs item #1445242, was opened at 2006-03-08 01:16 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=1445242&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: Bernhard Ãbelacker (huafbauer) Assigned to: Nobody/Anonymous (nobody) Summary: read_write_mutex missing in release? Initial Comment: Is there a reason for removing this files from the release package for at least version 1.33.1? (They are even tagged for version 1.33.1) read_write_mutex.hpp http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/thread/read_write_m… read_write_lock.hpp http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/thread/detail/read_… read_write_mutex.cpp http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/thread/src/read_writ… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1445242&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

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

07 Mar '06

Patches item #1438991, was opened at 2006-02-26 07:54 Message generated for change (Comment added) made by dbenbenn 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: Nobody/Anonymous (nobody) 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 16: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

[parameter] Binding type.
by Rene Rivera 07 Mar '06

07 Mar '06

I've been Boost.Parameter a bit by now and I have some usability feedback. There is one thing that currently bugs be a bit, the type defined by parameter::binding. All my uses so far have been of the form: typedef typename boost::remove_reference< boost::remove_const< boost::parameter::binding<ArgPack,tag::something>::type >::type >::type something_t; something_t s = args[something]; Or equivalent thereof. So every use I have I end up removing the ref and const because I'm really interested in the original type, and hence want to make a copy. Now I understand the rational outlined in "Eliminating Copies" <http://www.boost.org/libs/parameter/doc/html/index.html#eliminating-copies>. But I think that isn't enough of a justification for dirtying up the user interface, as above. I'd rather that the binding type where the value type so that one would have: typedef typename boost::parameter::binding<ArgPack,tag::something>::type something_t; something_t s = args[something]; Having it that way one still has the option of more naturally using the reference type as; something_t const & q = args[something]; And possibly also providing the container standard binding::value_type, and binding::const_reference. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

3 5