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

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

smart_ptr and handles
by Dirk Gregorius 29 Dec '04

29 Dec '04

Dear group, is it possible to use smart_ptr with handles ( e.g. HWND, HBRUSH, HDC, etc )? Wouldn't it be quite convenient to have something like a scoped or shared resource? The idea came when I looked my OpenGL initialisation code, where I have to free the resource explictly every time an error occurs, which make the code somehow a little bit more difficult to read and I though that it would be nice to have some kind of RAII mechanism here. Regards, -Dirk

5 4

Re: [gui] Concerning Scope (Was: thoughts on a GUI component library)
by brangdon＠cix.compulink.co.uk 29 Dec '04

29 Dec '04

In-Reply-To: <20041224050911.GA9037(a)maribor.izzy.net> alan-boost(a)engrm.com (Alan Gutierrez) wrote (abridged): > > I'm a bit concerned about the scope of this boost project. Our > > drawing framework is pretty huge. > > This is an important discussion to have sooner than later. > > 1) Is a GUI project a bad idea? > > 2) Is Boost the right place for the a GUI project? Supposing "yes" to both, that still leaves the question of scope. Possibly a "GUI" could just mean a high-level windowing system, and not a graphics drawing system. There is a lot to do just managing a tree of rectangles and dispatching events to and through them. The windowing system should arguably not care about the contents of the rectangles. It seems to me that adding a graphics system, with pens and brushes and polygons and text and bitmaps and wotnot, makes the project much bigger. Which isn't to say we shouldn't do it, and do all of it, but perhaps it is worth dividing it up into chunks or layers that are more or less independent. If that is possible. > I believe the time is ripe for a small, light-weight, XML + CSS > renderer to attack the new surge of RSS content on the web. OK. Perhaps my issue is that when I think of "GUI" I don't immediately translate that into "XML + CSS". -- Dave Harris, Nottingham, UK

6 6