- Boost - lists.boost.org

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

CVS is back online.
by David Abrahams 29 Dec '04

29 Dec '04

-- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

Developer CVS is down
by David Abrahams 29 Dec '04

29 Dec '04

.ssh: connect to host cvs.sourceforge.net port 22: Connection reset by peer Worse yet, the site status page hasn't been updated since 12-22! This has been reported to SourceForge. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

Re: smart_ptr and handles
by Dirk Gregorius 29 Dec '04

29 Dec '04

Works perfectly now. Thanks for your help guys!!! > 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; I take that as a christmas present :-) The compiler just started to complain about void* is not HDC and I was just starting to add the needed casts. This is really cool! Thanks a lot - you saved me from writing a lot of extra code... I wish you both all the best for the new year!! -Dirk

1 0

Re: smart_ptr and handles
by Dirk Gregorius 29 Dec '04

29 Dec '04

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'

2 1

Re: [boost] Re: thoughts on a GUI component library
by Marcelo E. Magallon 29 Dec '04

29 Dec '04

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

1 0

Re: smart_ptr and handles
by Dirk Gregorius 29 Dec '04

29 Dec '04

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

3 3

addressof with Metrowerks and Boost Function/Signal
by Reece Dunn 29 Dec '04

29 Dec '04

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: <boost/function/function_template.hpp> (470) - if (!detail::function::has_empty_target(addressof(f))) { + if (!detail::function::has_empty_target(boost::addressof(f))) { <boost/signals/trackable.hpp> (105) - add_if_trackable(addressof(t)); + add_if_trackable(boost::addressof(t)); Regards, Reece

2 1

Re: [boost] Re: thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 29 Dec '04

29 Dec '04

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

1 0