Boost logo

Boost :

From: PORKOLAB Zoltan (gsd_at_[hidden])
Date: 2004-12-29 21:37:41


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_at_[hidden] wrote:

> Send Boost mailing list submissions to
> boost_at_[hidden]
>
> 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_at_[hidden]
>
> You can reach the person managing the list at
> boost-owner_at_[hidden]
>
> 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_at_[hidden]>
> Subject: [boost] [mpl] value2type generalization of int_ needed
> To: boost_at_[hidden]
> Message-ID: <cqu6mg$l97$1_at_[hidden]>
> 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_at_[hidden]>
> Subject: [boost] Re: [mpl] value2type generalization of int_ needed
> To: boost_at_[hidden]
> Message-ID: <cqu87i$ojv$1_at_[hidden]>
> 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_at_[hidden]>
> Subject: [boost] Re: [mpl] value2type generalization of int_ needed
> To: boost_at_[hidden]
> Message-ID: <cqu8vn$qfh$1_at_[hidden]>
> 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_at_[hidden]>
> Subject: Re: [boost] [date_time] catalog.xml in CVS
> To: boost_at_[hidden]
> Message-ID: <200412291600.13740.ghost_at_[hidden]>
> 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_at_[hidden]>
> Subject: [boost] Re: [mpl] value2type generalization of int_ needed
> To: boost_at_[hidden]
> Message-ID: <cqua92$tds$1_at_[hidden]>
> 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_at_[hidden] (Dave Harris)
> Subject: Re: [boost] Re: thoughts on a GUI component library
> To: boost_at_[hidden]
> Message-ID: <memo.192880_at_[hidden]>
>
> In-Reply-To: <20041223171108.GB6938_at_[hidden]>
> alan-boost_at_[hidden] (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_at_[hidden]>
> Subject: [boost] Re: smart_ptr and handles
> To: boost_at_[hidden]
> Message-ID: <41D2B65F.40506_at_[hidden]>
> 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_at_[hidden]>
> Subject: Re: [boost] addressof with Metrowerks and Boost
> Function/Signal
> To: boost_at_[hidden]
> Message-ID: <2C25580F-59A2-11D9-AA59-000D932B7224_at_[hidden]>
> 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_at_[hidden]>
> Subject: Re: [boost] Re: smart_ptr and handles
> To: boost_at_[hidden]
> Message-ID: <20041229142011.GA67252_at_[hidden]>
> 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_at_[hidden]>
> Subject: Re: [boost] [date_time] catalog.xml in CVS
> To: boost_at_[hidden]
> Message-ID: <20041229142142.M12777_at_[hidden]>
> 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_at_[hidden]>
> Subject: Re: [boost] Re: Namespaces vs. directory placement
> To: <boost_at_[hidden]>
> Message-ID: <003b01c4edb3$501ec820$6401a8c0_at_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_at_[hidden]>
> Subject: [boost] Re: [date_time] catalog.xml in CVS
> To: boost_at_[hidden]
> Message-ID: <cquf6c$9ce$1_at_[hidden]>
> 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_at_[hidden]>
> Subject: Re: [boost] Re: smart_ptr and handles
> To: <boost_at_[hidden]>
> Message-ID: <007201c4edb4$e4173980$6401a8c0_at_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_at_[hidden]>
> Subject: [boost] Re: smart_ptr and handles
> To: boost_at_[hidden]
> Message-ID: <41D2C469.7030907_at_[hidden]>
> 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_at_[hidden]>
> Subject: Re: [boost] Re: [date_time] catalog.xml in CVS
> To: boost_at_[hidden]
> Message-ID: <20041229145838.M39611_at_[hidden]>
> 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_at_[hidden]>
> Subject: Re: [boost] Re: smart_ptr and handles
> To: boost_at_[hidden]
> Message-ID: <20041229150641.GA70310_at_[hidden]>
> 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_at_[hidden]>
> Subject: Re: [boost] Re: Serialization and async messaging
> To: boost_at_[hidden]
> Message-ID: <989aceac04122907105ca21332_at_[hidden]>
> Content-Type: text/plain; charset=US-ASCII
>
> On Wed, 29 Dec 2004 00:27:23 -0500, Jody Hagins
> <jody-boost-011304_at_[hidden]> 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_at_[hidden]>
> Subject: Re: [boost] Re: smart_ptr and handles
> To: <boost_at_[hidden]>
> Message-ID: <000b01c4edba$204131e0$6401a8c0_at_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_at_[hidden]>
> Subject: Re: [boost] Re: thoughts on a GUI component library
> To: boost_at_[hidden]
> Message-ID: <20041229150821.GA7250_at_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_at_[hidden]>
> Subject: [boost] Re: Re: [date_time] catalog.xml in CVS
> To: boost_at_[hidden]
> Message-ID: <cquido$hhj$1_at_[hidden]>
> 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_at_[hidden]>
> Subject: [boost] Re: Re: [date_time] catalog.xml in CVS
> To: boost_at_[hidden]
> Message-ID: <pan.2004.12.29.15.59.12.221317_at_[hidden]>
> 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 &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
> End of Boost Digest, Vol 956, Issue 2
> *************************************
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk