December 2004 - Boost - lists.preview.boost.org

Anyone Interested in a C++ to HTML pretty printer?
by christopher diggins 31 Dec '04

31 Dec '04

I am nearly finished a public domain C++ to HTML tool with syntax coloring. This is primarily intended as a demonstration of the YARD parser, but with practicial applications. I am wondering if anyone in the Boost community be interested in using the tool for sprucing up the code examples for the documentation to their libraries? The pretty printer recognizes and colors keywords, identifiers, string literal, character literals, number literals, macros and comments. It does so by using <span class="xxx"></span> tags around the elements. This means that italics / style / coloring can be controlled by a separate CSS file. There are some future enhancements which could be interesting as well such as: - automated hyper-linking of #include directives - javsascript open / close of code blocks { } Anyone interested? Christopher Diggins http://www.cdiggins.com http://www.heron-language.com

7 8

rational with finite precision
by Andras Erdei 31 Dec '04

31 Dec '04

i think the documentation on boost::rational is misleading, and it cannot be used with finite precision (e.g. the built-in) types at all: whenever the result of an operation cannot be represented exactly, it returns something totally bogus for example with rational<short> let's try to add 191/181 (=1.055...) and 197/193 (=1.021...) the exact result is 72520/34933 (=2.076...), and we get 6984/-30603 (=-0.229...)! i don't think the intended audience can "code in anticipation of such issues" (the task of determining when these issues come up has the same complexity as doing the actual arithmetic) imho this also means that the pre-calculated gcd() trick in op+= doesn't buy much: finite precision calculations will still fail randomly and my guess would be that it only makes unlimited precision calculations slower (2 gcd() calls + 4 op/()s instead of 1 gcd() call) fixing rational<> to work with finite precision integers so that for calculations like the above we get the best representable approximation (in this case 3197/1540 = 2.076, precise to 7 digits) is pretty straightforward -- the gcd() function implicitly calculates all representable approximations -- but would require rewriting the whole class br, andras

7 25

Serialization and async messaging
by Scott Woods 30 Dec '04

30 Dec '04

Hi, I have been doing a lot of async messaging over TCP and have looked through the serialization library in the hope that it could be applied to the task. If the serialized representation of an object has an unknown length then its reasonable to say that we dont know how many network blocks will be consumed, i.e. the receiver may read 1 or more blocks before completion. We also cant guarantee that the flurry of recv's that might result from an FD_READ (sorry to those non-Windows folks), will neatly terminate on an object boundary. IMHO the input function (operator>>) needs to be "re-entrant" if serialization can be used in an async environment. Repeated calls should be perfectly acceptable. Ultimately it would return an indication that a complete object has indeed been loaded. Some "state" needs to be held somewhere. My best guess is that this is not the case but I cant find anything conclusive (without wading deeper into code). Can anyone comment? ps: Its a thoroughly amazing library.

6 15

[iostreams] Problem using with MinGW GCC 3.4.2
by Daniel Schlyder 30 Dec '04

30 Dec '04

Hi, I get the following error when trying to compile a simple test (attached) using vector_sink from the tutorial with MinGW GCC 3.4.2: boost_iostreams.cpp: In function `int main()': boost_iostreams.cpp:41: error: invalid operands of types `boost::io::streambuf_facade< vector_sink, char_traits<char>, boost::io::output > ()(vector_sink)' and `int' to binary `operator<<' Please accept my apologies if I've overlooked something crucial in the docs. In case it matters, here is a list of changes I made to make the lib compile cleanly: 1. E:\libs\boost\libs\iostreams\build\../src/mapped_file.cpp:168: error: `::GetFileSizeEx' has not been declared According to MSDN, GetFileSizeEx() is only available under Windows 2000 and newer, so I had to remove this file from Jamfile sources. Maybe there should be a define for this, like for the compression code. 2. E:/libs/boost/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:150: error: `default_filter_buffer_size' undeclared (first use this function) E:/libs/boost/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:151: error: `default_buffer_size' undeclared (first use this function) E:/libs/boost/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:155: error: `default_pback_buffer_size' undeclared (first use this function) Fixed by including 'boost/iostreams/constants.hpp'. 3. E:/libs/boost/boost/iostreams/categories.hpp:102: warning: virtual base `boost::io::input_seekable' inaccessible in `boost::io::iostream_tag' due to ambiguity E:/libs/boost/boost/iostreams/categories.hpp:102: warning: virtual base `boost::io::device_tag' inaccessible in `boost::io::iostream_tag' due to ambiguity E:/libs/boost/boost/iostreams/categories.hpp:102: warning: virtual base `boost::io::output_seekable' inaccessible in `boost::io::iostream_tag' due to ambiguity Fixed by replacing struct seekable_device_tag : device_tag, seekable { }; with struct seekable_device_tag : virtual device_tag, seekable { }; and struct seekable : input_seekable, output_seekable, detail::one_head { }; with struct seekable : virtual input_seekable, virtual output_seekable, detail::one_head { }; 4. E:/libs/boost/boost/iostreams/detail/streambuf/linked_streambuf.hpp:54: error: variable or field `close' declared void E:/libs/boost/boost/iostreams/detail/streambuf/linked_streambuf.hpp:54: error: `close' declared as a `virtual' field E:/libs/boost/boost/iostreams/detail/streambuf/linked_streambuf.hpp:54: error: expected `;' before '( ' token Fixed by including 'ios'. 5. E:/libs/boost/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:377:1: warning: multi-line comment Fixed by changing to C-style comment. Not sure whether this is a problem with the code or GCC not handling the '\' in the macro definition properly. I also removed duplicate include of 'boost/iostreams/constants.hpp' in 'boost/iostreams/stream_facade.hpp'. TIA, -- Daniel Schlyder http://bitblaze.com/

2 4

Rendering Strategies
by Alan Gutierrez 30 Dec '04

30 Dec '04

I send a message to Noah Stein, where I think I've gotten a bit closer to what I'm trying to convey with rendering strategies, so I'm going to paste the relevent part... [paste] I want to drive home the point that hit-testing is easy for axis-aligned bounding boxes, and complicated visibility and hit testing is not necessary for a Symbian UI. Through generic programming, I'd like to leave it out when I don't need it, not think about it when I don't have to. The Win32 GDI mistake was to create a tree of graphic objects, each materialized in memory. Recognizing the common models of content rendering, you can devise better strategies than the allocation of a chunk of memory for every axis-aligned bounding box on the screen. (Or, conversely, throwing up your hands and saying that anything further is in the application domain. This is old, this is bad. It's widgets or the pen.) [snip] I agree that you can nest a canvas, in a form, in a document, and you can do this because of an axis-aligned box convention. It is exactly what I'd like to be able to do. Use a *canvas* renderer to render an vector graphics image in the corner of a button, or use a *document* renderer to draw formatted tool tips read from a resource file. (If I'm on a /G/UI that is.) A nested axis-aligned bounding box paradigm that rules UI organization. However, a *grid* has special needs. A *document* has special needs. A *document* should not have to materialize an object for each axis-aligned bounding box, attaching a font, pen, brush, background to each. Not when there is an obvious convention of inheriting styles from the containing bounding box. See? Recognize the rendering strategy, then you can optimize design. For a *document* each box need only be t,l,r,b, and, /and/ can be disposed of when it is off screen. For a *grid* you don't need a structure to represent the axis-alined box, you only need the height of reach row and the width of each column. Ah, but not of /each/ row and column, you can have a sparse list that indicates a change in row or column width, since they tend to be uniform. A *grid* does not need to keep components in memory, they only exist when activated. Materialized axis-aligned boxes are optimal for a *form*. For a fixed set of axis-aligned boxes, you can create an object, and take advantage of optimization that comes from using memory. Materialized axis-aligned boxes are also optimal for partitioning a window's client area. Thus my concern that this model will be mistaken for a panacea. Good for some things. Non-applicable for others. When it's not applicable, I don't think the library designers should throw up their hands and go, oh, looks like an application problem. Here's some grahpics utilities. Good luck. A *grid* or a *document* or a *form* have conventions that lend themselves to optimizations. Am I getting somewhere? -- Alan Gutierrez - alan(a)engrm.com

1 0

[date_time] catalog.xml in CVS
by Vladimir Prus 30 Dec '04

30 Dec '04

Hi, the date_time, specifically the libs/date_time/xmldoc directory, includes the catalog.xml file: File: catalog.xml Status: Up-to-date Working revision: 1.1 Repository revision: 1.1 /cvsroot/boost/boost/libs/date_time/xmldoc/catalog.xml,v I think it should not, as the file is generated by Boost.Build, and placing a version which includes paths like: file:///usr/local/src/bart is likely to lead to errors. - Volodya

3 8

RE: [boost] Top Ten Ideas For NEW Features Not Included in Surveyed Libs
by Brian Braatz 30 Dec '04

30 Dec '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Alan Gutierrez > Libs > > 1) Documents. > > Any new UI library without a flowing text strategy is doomed > to failure. > > Discuss. [Brian Braatz] ????? What is a flowing text strategy? Discuss!

2 1

[mpl] value2type generalization of int_ needed
by Larry Evans 30 Dec '04

30 Dec '04

mpl has int_ which wraps an int value, but I've needed something similar for other types, in particular, for enumerated types. I'm suggesting something like: //template to create a type from a value of some type. template < typename ValueType //type of value to be "typified" > struct value2type { typedef ValueType value_type ; template < value_type ValueInstance //value to be typified. > struct instance //the type created from ValueInstance {}; }; The name is modelled after In2Type in Alexandrescu's _Modern C++ Design_ which is also where the "typified" comes from. Could this template, or something like it be added to mpl?

2 4

Re: Boost Digest, Vol 956, Issue 2
by PORKOLAB Zoltan 30 Dec '04

30 Dec '04

Helló http://lists.boost.org/MailArchives/boost/ http://lists.boost.org/MailArchives/boost/msg77147.php Érdemes bele-bele nézni a listába. üdv gsd On Wed, 29 Dec 2004 boost-request(a)lists.boost.org wrote: > Send Boost mailing list submissions to > boost(a)lists.boost.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.boost.org/mailman/listinfo.cgi/boost > or, via email, send a message with subject or body 'help' to > boost-request(a)lists.boost.org > > You can reach the person managing the list at > boost-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost digest..." > > > The boost archives may be found at: http://lists.boost.org/MailArchives/boost/ > > Today's Topics: > > 1. [mpl] value2type generalization of int_ needed (Larry Evans) > 2. Re: [mpl] value2type generalization of int_ needed (Daniel Wallin) > 3. Re: [mpl] value2type generalization of int_ needed (Larry Evans) > 4. Re: [date_time] catalog.xml in CVS (Vladimir Prus) > 5. Re: [mpl] value2type generalization of int_ needed (Larry Evans) > 6. Re: Re: thoughts on a GUI component library (Dave Harris) > 7. Re: smart_ptr and handles (Dirk Gregorius) > 8. Re: addressof with Metrowerks and Boost Function/Signal > (Douglas Gregor) > 9. Re: Re: smart_ptr and handles (Jonathan Wakely) > 10. Re: [date_time] catalog.xml in CVS (Jeff Garland) > 11. Re: Re: Namespaces vs. directory placement (Peter Dimov) > 12. Re: [date_time] catalog.xml in CVS (Vladimir Prus) > 13. Re: Re: smart_ptr and handles (Peter Dimov) > 14. Re: smart_ptr and handles (Dirk Gregorius) > 15. Re: Re: [date_time] catalog.xml in CVS (Jeff Garland) > 16. Re: Re: smart_ptr and handles (Jonathan Wakely) > 17. Re: Re: Serialization and async messaging (Caleb Epstein) > 18. Re: Re: smart_ptr and handles (Peter Dimov) > 19. Re: Re: thoughts on a GUI component library (Marcelo E. Magallon) > 20. Re: Re: [date_time] catalog.xml in CVS (Vladimir Prus) > 21. Re: Re: [date_time] catalog.xml in CVS (Bart) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 29 Dec 2004 06:07:19 -0700 > From: Larry Evans <cppljevans(a)cox-internet.com> > Subject: [boost] [mpl] value2type generalization of int_ needed > To: boost(a)lists.boost.org > Message-ID: <cqu6mg$l97$1(a)sea.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > mpl has int_ which wraps an int value, but I've needed > something similar for other types, in particular, > for enumerated types. I'm suggesting something > like: > > //template to create a type from a value of some type. > template > < typename ValueType //type of value to be "typified" > > > struct > value2type > { > typedef > ValueType > value_type > ; > template > < value_type ValueInstance //value to be typified. > > > struct > instance //the type created from ValueInstance > {}; > }; > > The name is modelled after In2Type in Alexandrescu's > _Modern C++ Design_ which is also where the "typified" > comes from. > > Could this template, or something like it be added to mpl? > > > > ------------------------------ > > Message: 2 > Date: Wed, 29 Dec 2004 13:33:55 +0100 > From: Daniel Wallin <dalwan01(a)student.umu.se> > Subject: [boost] Re: [mpl] value2type generalization of int_ needed > To: boost(a)lists.boost.org > Message-ID: <cqu87i$ojv$1(a)sea.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1 > > Larry Evans wrote: > > mpl has int_ which wraps an int value, but I've needed > > something similar for other types, in particular, > > for enumerated types. I'm suggesting something > > like: > [snip] > > > > Could this template, or something like it be added to mpl? > > What's wrong with mpl::integral_c<> ? > > -- > Daniel Wallin > > > > ------------------------------ > > Message: 3 > Date: Wed, 29 Dec 2004 06:46:23 -0700 > From: Larry Evans <cppljevans(a)cox-internet.com> > Subject: [boost] Re: [mpl] value2type generalization of int_ needed > To: boost(a)lists.boost.org > Message-ID: <cqu8vn$qfh$1(a)sea.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 12/29/2004 05:33 AM, Daniel Wallin wrote: > [snip] > > What's wrong with mpl::integral_c<> ? > OOPS. I missed that. Thanks. > > > > ------------------------------ > > Message: 4 > Date: Wed, 29 Dec 2004 16:00:12 +0300 > From: Vladimir Prus <ghost(a)cs.msu.su> > Subject: Re: [boost] [date_time] catalog.xml in CVS > To: boost(a)lists.boost.org > Message-ID: <200412291600.13740.ghost(a)cs.msu.su> > Content-Type: text/plain; charset="iso-8859-1" > > On Wednesday 29 December 2004 13:04, Vladimir Prus wrote: > > Hi, > > the date_time, specifically the libs/date_time/xmldoc directory, includes > > the catalog.xml file: > > And date_time_autodoc.boostbook/ and other *.boostbook files should not be in > CVS, too. > > - Volodya > > > ------------------------------ > > Message: 5 > Date: Wed, 29 Dec 2004 07:08:25 -0700 > From: Larry Evans <cppljevans(a)cox-internet.com> > Subject: [boost] Re: [mpl] value2type generalization of int_ needed > To: boost(a)lists.boost.org > Message-ID: <cqua92$tds$1(a)sea.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 12/29/2004 06:46 AM, Larry Evans wrote: > > On 12/29/2004 05:33 AM, Daniel Wallin wrote: > > [snip] > > > >> What's wrong with mpl::integral_c<> ? > > > > OOPS. I missed that. Thanks. > > I started to use it; however, in the particular application > I have (located at http://boost-sandbox.sourceforge.net/vault/index.php? > in placeholders_test.cpp), the T must be separate from the value. > In other words instead of: > > template<class T, T N> struct integral_c, > > I need the N to be separate in order to use it as the a_index template > argument to typemap_valued_placeholdered<,>::at<a_index>. > > Can you see any other way? > > TIA. > > > > ------------------------------ > > Message: 6 > Date: Wed, 29 Dec 2004 13:40 +0000 (GMT) > From: brangdon(a)cix.compulink.co.uk (Dave Harris) > Subject: Re: [boost] Re: thoughts on a GUI component library > To: boost(a)lists.boost.org > Message-ID: <memo.192880(a)cix.compulink.co.uk> > > In-Reply-To: <20041223171108.GB6938(a)maribor.izzy.net> > alan-boost(a)engrm.com (Alan Gutierrez) wrote (abridged): > > > That's okay for simple things, but for any serious printing work > > > you need to know you're talking to a printer. For example, you > > > may need to embed postscript in your output stream. > > > > I'd like to look at how OS X is able to make a PDF of everything. > > I can think of two ways. First, the PDF can reflect what would be printed > if the printer did not support postscript (which not all printers do). > Second, PDF can itself contain embedded postscript. > > -- Dave Harris, Nottingham, UK > > > > ------------------------------ > > Message: 7 > Date: Wed, 29 Dec 2004 14:51:27 +0100 > From: Dirk Gregorius <dirk(a)dirkgregorius.de> > Subject: [boost] Re: smart_ptr and handles > To: boost(a)lists.boost.org > Message-ID: <41D2B65F.40506(a)dirkgregorius.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Thanks for your help and sorry for not looking carefully at the > documentation: > > I tried the following for a Windows device context: > > The creation function is: HDC GetDC( HWND) > The deletion function is: int ReleaseDC( HWND, HDC ); > > // Code like in the documentation... > typedef shared_ptr<void> handle; > handle make_dc( HWND hWnd ) > { > // The release function takes two arguments, so I tried an adapter > functor...unfortunately it does not work > handle( GetDC( hWnd ), bind1( ReleaseDC, hWnd ) ); > } > > My problem is to bind the window handle to the custom delete function. > My compilter spits aout a lot of error messages here. > Can I use boost::bind here or boost::function? > > > BTW: How does shared_ptr call the custom delete function? For a COM > object it should call in the D'tor: > > raw_ptr->Release(); > > While in my case it should call ( what is the usual way in the C++ > standard IIRC ): > > Release( raw_ptr ); > > Does the shard_ptr interface figures this out in some clever way and > manage this internally? > > Regards, > > -Dirk > > > > > ------------------------------ > > Message: 8 > Date: Wed, 29 Dec 2004 09:01:44 -0500 > From: Douglas Gregor <dgregor(a)cs.indiana.edu> > Subject: Re: [boost] addressof with Metrowerks and Boost > Function/Signal > To: boost(a)lists.boost.org > Message-ID: <2C25580F-59A2-11D9-AA59-000D932B7224(a)cs.indiana.edu> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > > On Dec 26, 2004, at 11:15 AM, Reece Dunn wrote: > > > I am getting ambiguity errors on Metrowerks 9.2 when using > > Boost.Function and Boost.Signal. These errors can be corrected with > > the following patches: > > Thanks! The patches are in CVS now. > > Doug > > > > ------------------------------ > > Message: 9 > Date: Wed, 29 Dec 2004 14:20:11 +0000 > From: Jonathan Wakely <cow(a)compsoc.man.ac.uk> > Subject: Re: [boost] Re: smart_ptr and handles > To: boost(a)lists.boost.org > Message-ID: <20041229142011.GA67252(a)compsoc.man.ac.uk> > Content-Type: text/plain; charset=us-ascii > > On Wed, Dec 29, 2004 at 02:51:27PM +0100, Dirk Gregorius wrote: > > > Thanks for your help and sorry for not looking carefully at the > > documentation: > > > > I tried the following for a Windows device context: > > > > The creation function is: HDC GetDC( HWND) > > The deletion function is: int ReleaseDC( HWND, HDC ); > > > > // Code like in the documentation... > > typedef shared_ptr<void> handle; > > handle make_dc( HWND hWnd ) > > { > > // The release function takes two arguments, so I tried an adapter > > functor...unfortunately it does not work > > handle( GetDC( hWnd ), bind1( ReleaseDC, hWnd ) ); > > } > > Should that be bind, not bind1 ? > > It's not hard to write your own deleter if you can't do it with a > binder: > > struct DCReleaser > { > DCReleaser(HWND hwnd) : hwnd(hwnd) {} > void operator()(void* p) { ReleaseDC( hwnd, (HDC)p ); } > HWND hwnd; > }; > > handle make_dc( HWND hWnd ) > { > return handle( GetDC( hWnd ), DCReleaser(hWnd) ); > } > > but ... > > > My problem is to bind the window handle to the custom delete function. > > My compilter spits aout a lot of error messages here. > > Can I use boost::bind here or boost::function? > > I think bind(ReleaseDC, hWnd, _1) should work. > > > BTW: How does shared_ptr call the custom delete function? For a COM > > object it should call in the D'tor: > > > > raw_ptr->Release(); > > > > While in my case it should call ( what is the usual way in the C++ > > standard IIRC ): > > > > Release( raw_ptr ); > > > > Does the shard_ptr interface figures this out in some clever way and > > manage this internally? > > The custom deleter's function operator is called with the managed > pointer as its argument, e.g. for a deleter d and pointer p: d(p) > > jon > > -- > "Ye have locked yerselves up in cages of fear; > and behold, do ye now complain that ye lack freedom." > - Lord Omar Khayyam Ravenhurst > "Epistle to the Paranoids," HBT > > > ------------------------------ > > Message: 10 > Date: Wed, 29 Dec 2004 07:21:42 -0700 > From: "Jeff Garland" <jeff(a)crystalclearsoftware.com> > Subject: Re: [boost] [date_time] catalog.xml in CVS > To: boost(a)lists.boost.org > Message-ID: <20041229142142.M12777(a)crystalclearsoftware.com> > Content-Type: text/plain; charset=iso-8859-1 > > On Wed, 29 Dec 2004 16:00:12 +0300, Vladimir Prus wrote > > On Wednesday 29 December 2004 13:04, Vladimir Prus wrote: > > > Hi, > > > the date_time, specifically the libs/date_time/xmldoc directory, includes > > > the catalog.xml file: > > This is an internally used file, so it shouldn't cause errors - but perhaps an > error has crept in? Are you seeing a problem when you try and generate the > overall boost results? I noted before that for the 1.32 pdf date-time was > excluded and no one explained why/how that happened since the html was clearly > generated :-( > > > And date_time_autodoc.boostbook/ and other *.boostbook files should > > not be in CVS, too. > > Yes, well, since we haven't been sucessful in getting all of the doxygen to > boost-book bridge to work well for date-time we have to slightly modify the > generated files for our purpose. So that's why those are there. > > Jeff > > > > ------------------------------ > > Message: 11 > Date: Wed, 29 Dec 2004 16:33:05 +0200 > From: "Peter Dimov" <pdimov(a)mmltd.net> > Subject: Re: [boost] Re: Namespaces vs. directory placement > To: <boost(a)lists.boost.org> > Message-ID: <003b01c4edb3$501ec820$6401a8c0@pdimov2> > Content-Type: text/plain; format=flowed; charset="Windows-1252"; > reply-type=original > > Jonathan Turkanis wrote: > > The occurence of boost::io::put in the above example has to be > > qualified, since otherwise it will refer to the member function being > > defined. > > What I have to say has nothing to do with namespaces or directory placement, > but... > > Given that in the documentation you speak of user-defined overloads of > boost::io::read et al, it might be worthwhile to point out that two-phase > lookup will not see these user overloads. If you want to have an overload > customization point in a template, you have to use an unqualified call. And > choose the identifiers wisely. :-) > > > > ------------------------------ > > Message: 12 > Date: Wed, 29 Dec 2004 17:32:44 +0300 > From: Vladimir Prus <ghost(a)cs.msu.su> > Subject: [boost] Re: [date_time] catalog.xml in CVS > To: boost(a)lists.boost.org > Message-ID: <cquf6c$9ce$1(a)sea.gmane.org> > Content-Type: text/plain; charset=us-ascii > > Jeff Garland wrote: > > > On Wed, 29 Dec 2004 16:00:12 +0300, Vladimir Prus wrote > >> On Wednesday 29 December 2004 13:04, Vladimir Prus wrote: > >> > Hi, > >> > the date_time, specifically the libs/date_time/xmldoc directory, > >> > includes the catalog.xml file: > > > > This is an internally used file, so it shouldn't cause errors - but > > perhaps an > > error has crept in? Are you seeing a problem when you try and generate > > the > > overall boost results? > > No, I see a problem when trying to build date_time docs. > > > I noted before that for the 1.32 pdf date-time was > > excluded and no one explained why/how that happened since the html was > > clearly generated :-( > > I recall it was some kind of fop -> pdf convert bug, but I'm not sure. > > >> And date_time_autodoc.boostbook/ and other *.boostbook files should > >> not be in CVS, too. > > > > Yes, well, since we haven't been sucessful in getting all of the doxygen > > to boost-book bridge to work well for date-time we have to slightly modify > > the > > generated files for our purpose. So that's why those are there. > > You mean that each time after modifying headers, you have to manually tweak > the generated files? > > - Volodya > > > > > ------------------------------ > > Message: 13 > Date: Wed, 29 Dec 2004 16:44:22 +0200 > From: "Peter Dimov" <pdimov(a)mmltd.net> > Subject: Re: [boost] Re: smart_ptr and handles > To: <boost(a)lists.boost.org> > Message-ID: <007201c4edb4$e4173980$6401a8c0@pdimov2> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > Jonathan Wakely wrote: > > struct DCReleaser > > { > > DCReleaser(HWND hwnd) : hwnd(hwnd) {} > > void operator()(void* p) { ReleaseDC( hwnd, (HDC)p ); } > > HWND hwnd; > > }; > > > > handle make_dc( HWND hWnd ) > > { > > return handle( GetDC( hWnd ), DCReleaser(hWnd) ); > > } > > Yep. Note also that shared_ptr will call the deleter with an HDC, not a > void*, so the cast in operator() is not necessary: > > void operator()(HDC p) const { ReleaseDC( hwnd, p ); } > > > > I think bind(ReleaseDC, hWnd, _1) should work. > > That's what I'd use, too. :-) > > > > ------------------------------ > > Message: 14 > Date: Wed, 29 Dec 2004 15:51:21 +0100 > From: Dirk Gregorius <dirk(a)dirkgregorius.de> > Subject: [boost] Re: smart_ptr and handles > To: boost(a)lists.boost.org > Message-ID: <41D2C469.7030907(a)dirkgregorius.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Thanks - the custom functor works, but I don't understand why using > boost::bind or std::bind1 fails: > > Does anybody know why the compiler complains about this? > > typedef shared_ptr<void> handle; > handle make_dc( HWND hWnd ) > { > handle spHandle( GetDC( hWnd ), bind( &ReleaseDC, hWnd, _1 ) ); > return handle; > } > > The compiler has problems with the return_value. I will attach the > compiler output to the end of the mail. It is in german but you should > get the idea anyway. > > c:\Programme\Microsoft Visual Studio .NET 2003\Visual Studio SDKs\Boost > 1.32\include\boost\bind.hpp(62) : error C2039: 'result_type': Ist kein > Element von 'operator``global namespace''' > c:\Programme\Microsoft Visual Studio .NET 2003\Visual Studio SDKs\Boost > 1.32\include\boost\bind.hpp(62) : error C2146: Syntaxfehler: Fehlendes > ';' vor Bezeichner 'type' > c:\Programme\Microsoft Visual Studio .NET 2003\Visual Studio SDKs\Boost > 1.32\include\boost\bind.hpp(62) : error C2955: 'boost::_bi::type': für > die Verwendung einer Vorlagenklasse ist eine Vorlagen-Argumentliste > erforderlich > c:\Programme\Microsoft Visual Studio .NET 2003\Visual Studio > SDKs\Boost 1.32\include\boost\bind.hpp(111): Siehe Deklaration von > 'boost::_bi::type' > > > ------------------------------ > > Message: 15 > Date: Wed, 29 Dec 2004 07:58:38 -0700 > From: "Jeff Garland" <jeff(a)crystalclearsoftware.com> > Subject: Re: [boost] Re: [date_time] catalog.xml in CVS > To: boost(a)lists.boost.org > Message-ID: <20041229145838.M39611(a)crystalclearsoftware.com> > Content-Type: text/plain; charset=iso-8859-1 > > On Wed, 29 Dec 2004 17:32:44 +0300, Vladimir Prus wrote > > Jeff Garland wrote: > > > > > On Wed, 29 Dec 2004 16:00:12 +0300, Vladimir Prus wrote > > >> On Wednesday 29 December 2004 13:04, Vladimir Prus wrote: > > >> > Hi, > > >> > the date_time, specifically the libs/date_time/xmldoc directory, > > >> > includes the catalog.xml file: > > > > > > This is an internally used file, so it shouldn't cause errors - but > > > perhaps an > > > error has crept in? Are you seeing a problem when you try and generate > > > the > > > overall boost results? > > > > No, I see a problem when trying to build date_time docs. > > Maybe you can be more explicit about what you are doing and the errors you are > seeing. BTW, we haven't been able to build docs for quite awhile now and our > requests for help have gone unanswered on the boost-doc list. We weren't sure > what magic was applied to do the 1.32 release. > > > > I noted before that for the 1.32 pdf date-time was > > > excluded and no one explained why/how that happened since the html was > > > clearly generated :-( > > > > I recall it was some kind of fop -> pdf convert bug, but I'm not sure. > > Ok. > > > >> And date_time_autodoc.boostbook/ and other *.boostbook files should > > >> not be in CVS, too. > > > > > > Yes, well, since we haven't been sucessful in getting all of the doxygen > > > to boost-book bridge to work well for date-time we have to slightly modify > > > the > > > generated files for our purpose. So that's why those are there. > > > > You mean that each time after modifying headers, you have to > > manually tweak the generated files? > > That's correct -- although I think we actually use a script to do it. Sorry > to say I've been hands-off of this for awhile so I don't know the details. > Hopefully Bart will post later and describe the details. > > Jeff > > > ------------------------------ > > Message: 16 > Date: Wed, 29 Dec 2004 15:06:41 +0000 > From: Jonathan Wakely <cow(a)compsoc.man.ac.uk> > Subject: Re: [boost] Re: smart_ptr and handles > To: boost(a)lists.boost.org > Message-ID: <20041229150641.GA70310(a)compsoc.man.ac.uk> > Content-Type: text/plain; charset=us-ascii > > On Wed, Dec 29, 2004 at 04:44:22PM +0200, Peter Dimov wrote: > > > Jonathan Wakely wrote: > > > struct DCReleaser > > > { > > > DCReleaser(HWND hwnd) : hwnd(hwnd) {} > > > void operator()(void* p) { ReleaseDC( hwnd, (HDC)p ); } > > > HWND hwnd; > > > }; > > > > > > handle make_dc( HWND hWnd ) > > > { > > > return handle( GetDC( hWnd ), DCReleaser(hWnd) ); > > > } > > > > Yep. Note also that shared_ptr will call the deleter with an HDC, not a > > void*, so the cast in operator() is not necessary: > > > > void operator()(HDC p) const { ReleaseDC( hwnd, p ); } > > Yes, of course it will. Silly me. Thanks, Peter. > > > >I think bind(ReleaseDC, hWnd, _1) should work. > > > > That's what I'd use, too. :-) > > Finally, Dirk, if you don't want to use shared_ptr<void> (and casts) > everywhere you can include boost/type_traits.hpp and use remove_pointer: > > typedef shared_ptr<remove_pointer<HDC>::type> dc_handle; > typedef shared_ptr<remove_pointer<HWND>::type> wnd_handle; > > jon > > -- > "It is unbecoming for young men to utter maxims." > - Aristotle > > > ------------------------------ > > Message: 17 > Date: Wed, 29 Dec 2004 10:10:17 -0500 > From: Caleb Epstein <caleb.epstein(a)gmail.com> > Subject: Re: [boost] Re: Serialization and async messaging > To: boost(a)lists.boost.org > Message-ID: <989aceac04122907105ca21332(a)mail.gmail.com> > Content-Type: text/plain; charset=US-ASCII > > On Wed, 29 Dec 2004 00:27:23 -0500, Jody Hagins > <jody-boost-011304(a)atdesk.com> wrote: > > > I think Scott is saying that operator>> is insufficient because it can > > not do a partial read of what is there... it wants to snarf all 4K. > > I think at least one person here is mixing pickles and milk, as my old > Latin teacher used to say. > > Firstly, the serialization library doesn't use operator>> or > operator<< at all. If you're using these operators on some sort of > socket iostream and you don't want blocking to occur, thats your first > mistake. > > When reading/writing data with sockets, its up to you to use an > appropriate protocol that can detect "message" boundaries so you know > when you have a complete block of data to work with. See for example > the BEEP protocol (http://beepcore.org/) for a nice specification and > implementation. > > Don't tightly couple this communications layer to the application > layer. The two layers should just pass "complete" blocks of data > (e.g. serialized objects) between each other. > -- > Caleb Epstein > caleb dot epstein at gmail dot com > > > ------------------------------ > > Message: 18 > Date: Wed, 29 Dec 2004 17:21:48 +0200 > From: "Peter Dimov" <pdimov(a)mmltd.net> > Subject: Re: [boost] Re: smart_ptr and handles > To: <boost(a)lists.boost.org> > Message-ID: <000b01c4edba$204131e0$6401a8c0@pdimov2> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=response > > Dirk Gregorius wrote: > > Thanks - the custom functor works, but I don't understand why using > > boost::bind or std::bind1 fails: > > > > Does anybody know why the compiler complains about this? > > > > typedef shared_ptr<void> handle; > > handle make_dc( HWND hWnd ) > > { > > handle spHandle( GetDC( hWnd ), bind( &ReleaseDC, hWnd, _1 ) ); > > return handle; > > } > > The problem is that ReleaseDC uses the __stdcall calling convention: > > http://boost.org/libs/bind/bind.html#Q_win32_api > > #define BOOST_BIND_ENABLE_STDCALL to turn on __stdcall support (and change > "return handle" to "return spHandle"). > > > > ------------------------------ > > Message: 19 > Date: Wed, 29 Dec 2004 09:08:21 -0600 > From: "Marcelo E. Magallon" <mmagallo(a)debian.org> > Subject: Re: [boost] Re: thoughts on a GUI component library > To: boost(a)lists.boost.org > Message-ID: <20041229150821.GA7250(a)jacinta.casa> > Content-Type: text/plain; charset=us-ascii > > On Tue, Dec 28, 2004 at 05:28:15PM -0500, Alan Gutierrez wrote: > > > > That's easy: you start with a vector description of *everything* > > > and plug a rasterizer where needed. This vector description in > > > Quartz is called DPS: Display PostScript. > > > > > This gives you the gimmicks you see on MacOS X, for example window > > > minimization and maximization effects. You just need to start > > > with a rectangle, and subdivide the edges, and apply some > > > transformation to them. Then you can use algebraic grid > > > generation to compute the inner grid. And now you only need to > > > apply the grid transformation to the elements of the window. > > > > So where can I learn about algebraic grid generation? > > I'm not at the office now, I'll write this down and mail you a couple > of references next week. I think they could be useful for getting you > started if you have interest in the topic. It's nothing more than just > careful interpolation. > > > I understand what you are saying architecure wise. Do you really > > feel that it is easy? Could it be cross-platform? I'm of a mind > > that you start with rendering soultions, rather than widgets. > > It's conceptually easy. > > The basic idea is that you need some sort of abstraction to display > hardware, nothing new there. If you orient this abstraction towards > raster devices like the screen, you basically tie both of your hands > behind your back when it comes to dealing with significantly different > devices like a printer or a text-based UI. > > If you start with vector graphics, rendering to the screen is easy, > it's "just" rasterization (ok, it's full of pesky details, but that's a > different thing). Rendering to a printer is either transforming your > vector description to the printer's vector description (PostScript, > ...) or rasterizing at a given resolution. > > There's still nothing new there. > > You could implement OS X's gimmicks on top of X11 or GDI, with some > amount of pain involved. The problem is neither is particularly good > at working with affine transformations or texture application or alpha > blending or shading. Here's where Quartz shines. This is also what > Cairo Graphics is trying to be. > > Could this be cross platform? It depends on what you mean by that. > > Would something like this work across platforms? Sure, why not? > > Would something like this work across platforms if you want to use the > native widgets? Probably not. > > And yes, I tend to think about the rendering part of the problem > because that's what I do and that's what interests me. It's also one > of the spots that hinders portability: don't take it too far, think of > something as simple as fonts. I would also like to see a nice event > loop system (because that's one wheel I've reinvented many times > already and I don't feel I've gotten it right yet), so if you start > discussing that (from the Boost POV) I will pay closer attention :-) > > I my opinion GTK+ has got the whole UI thing right (or "as right as it > can get"). They have clear boundaries between different parts of the > system: rendering (with GDK as an abstraction on top of X11 and > others), widgets (GTK+ itself), accessibility (ATK), text handling and > rendering (Pango), themability. Where GTK+ sucks at is extensibility: > it's a pain to write new widgets. The whole signaling business in GTK+ > is also awkward to say the least. GTKmm is an improvement over GTK+, > but there are some corners which still feel somewhat "wrong" (perhaps > because GTK+ is "still underneath") > > On the other hand I think Qt got and still gets the whole thing wrong. > (That and the fact that they reinvented wheels that didn't need > reinventing in the first place). > > I'm getting way off-topic... > > Marcelo > > > ------------------------------ > > Message: 20 > Date: Wed, 29 Dec 2004 18:27:52 +0300 > From: Vladimir Prus <ghost(a)cs.msu.su> > Subject: [boost] Re: Re: [date_time] catalog.xml in CVS > To: boost(a)lists.boost.org > Message-ID: <cquido$hhj$1(a)sea.gmane.org> > Content-Type: text/plain; charset=us-ascii > > Jeff Garland wrote: > > > On Wed, 29 Dec 2004 17:32:44 +0300, Vladimir Prus wrote > >> Jeff Garland wrote: > >> > >> > On Wed, 29 Dec 2004 16:00:12 +0300, Vladimir Prus wrote > >> >> On Wednesday 29 December 2004 13:04, Vladimir Prus wrote: > >> >> > Hi, > >> >> > the date_time, specifically the libs/date_time/xmldoc directory, > >> >> > includes the catalog.xml file: > >> > > >> > This is an internally used file, so it shouldn't cause errors - but > >> > perhaps an > >> > error has crept in? Are you seeing a problem when you try and generate > >> > the > >> > overall boost results? > >> > >> No, I see a problem when trying to build date_time docs. > > > > Maybe you can be more explicit about what you are doing and the errors you > > are > > seeing. > > Sure. > 1. I have up-to-date CVS tree. > 2. I run "bjam --v2" in libs/date_time/xmldocs and get: > > xslt-xsltproc bin/gcc/debug/date_time.docbook > ../../../tools/boostbook/dtd/boostbook.dtd:412: warning: failed to load > external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" > %DocBook; > ^ > Entity: line 1: > (many screens of similar errors omitted). > 3. I remove catalog.xml and run bjam again. Everything works. > > > BTW, we haven't been able to build docs for quite awhile now > > I know it was broken for about a week (because I broke it), but it should be > working now. > > > and > > our > > requests for help have gone unanswered on the boost-doc list. > > We weren't > > sure what magic was applied to do the 1.32 release. > > I'm not sure what problems you refer too, sorry. > > >> >> And date_time_autodoc.boostbook/ and other *.boostbook files should > >> >> not be in CVS, too. > >> > > >> > Yes, well, since we haven't been sucessful in getting all of the > >> > doxygen to boost-book bridge to work well for date-time we have to > >> > slightly modify the > >> > generated files for our purpose. So that's why those are there. > >> > >> You mean that each time after modifying headers, you have to > >> manually tweak the generated files? > > > > That's correct -- although I think we actually use a script to do it. > > Sorry to say I've been hands-off of this for awhile so I don't know the > > details. Hopefully Bart will post later and describe the details. > > Ok. > > - Volodya > > > > > ------------------------------ > > Message: 21 > Date: Wed, 29 Dec 2004 08:59:15 -0700 > From: Bart <bartmann_nsd(a)yahoo.com> > Subject: [boost] Re: Re: [date_time] catalog.xml in CVS > To: boost(a)lists.boost.org > Message-ID: <pan.2004.12.29.15.59.12.221317(a)yahoo.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, 29 Dec 2004 07:58:38 -0700, Jeff Garland wrote: > > > On Wed, 29 Dec 2004 17:32:44 +0300, Vladimir Prus wrote > >> Jeff Garland wrote: > >> > >> > On Wed, 29 Dec 2004 16:00:12 +0300, Vladimir Prus wrote > >> >> On Wednesday 29 December 2004 13:04, Vladimir Prus wrote: > >> >> > Hi, > >> >> > the date_time, specifically the libs/date_time/xmldoc directory, > >> >> > includes the catalog.xml file: > >> > > >> > This is an internally used file, so it shouldn't cause errors - but > >> > perhaps an > >> > error has crept in? Are you seeing a problem when you try and generate > >> > the > >> > overall boost results? > >> > >> No, I see a problem when trying to build date_time docs. > > > > Maybe you can be more explicit about what you are doing and the errors you are > > seeing. BTW, we haven't been able to build docs for quite awhile now and our > > requests for help have gone unanswered on the boost-doc list. We weren't sure > > what magic was applied to do the 1.32 release. > > > >> > I noted before that for the 1.32 pdf date-time was > >> > excluded and no one explained why/how that happened since the html was > >> > clearly generated :-( > >> > >> I recall it was some kind of fop -> pdf convert bug, but I'm not sure. > > > > Ok. > > > >> >> And date_time_autodoc.boostbook/ and other *.boostbook files should > >> >> not be in CVS, too. > >> > > >> > Yes, well, since we haven't been sucessful in getting all of the doxygen > >> > to boost-book bridge to work well for date-time we have to slightly modify > >> > the > >> > generated files for our purpose. So that's why those are there. > >> > >> You mean that each time after modifying headers, you have to > >> manually tweak the generated files? > > > > That's correct -- although I think we actually use a script to do it. Sorry > > to say I've been hands-off of this for awhile so I don't know the details. > > Hopefully Bart will post later and describe the details. > > > > Jeff > > We wanted the doxygen created reference to have three sections: date_time, > gregorian, & posix_time with a fourth to be added later (local_time). > Boostbook generated a boostbook file for each section, however, all three > boostbook files had the same section and title tags. Our script rewrites > those tags and adds a copyright notice. > > It's a bit of extra work but we have a nicely nested set of reference docs > as a result. > > Building the docs from anywhere other than > boost_root/libs/date_time/xmldoc will not produce the boostbook files but > simply uses them. > > Bart > > > > ------------------------------ > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > End of Boost Digest, Vol 956, Issue 2 > ************************************* >

1 0

Top Ten Ideas For NEW Features Not Included in Surveyed Libs
by Alan Gutierrez 29 Dec '04

29 Dec '04

1) Documents. Any new UI library without a flowing text strategy is doomed to failure. Discuss. -- Alan Gutierrez - alan(a)engrm.com

1 0