- Boost - lists.boost.org

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

thoughts on a GUI component library
by Reece Dunn 29 Dec '04

29 Dec '04

Hi All, I have been working on revising my GUI library that is currently in the sandbox. The motivation for doing this was Andy Little's comment that most GUI libraries start from a particular operating system and then abstract its interface, providing work-arounds for other GUI systems. There are several considerations to make with a GUI library. For insatance, it should be possible to support GUI interfaces on portable devices (e.g. Palm Pilot/PalmOS) and terminal devices (like is done with the VIM editor). With these devices, code needs to be written to provide common components such as buttons. Also, the target operating system places design problems on creating a generic interface. For example, Windows supports char * and wchar_t * versions of its API, but the version that should be used depends on whether you are targetting Windows 9x or NT based systems. Windows also requires each component type to be registered before you can create an instance of it. Each operating system has different arguments that it passes when an event is generated, containing data relating to that event. Consideration must be made to allow events to be written generically, but also allow you to hook into OS-specific events and get OS-specific data. With all this in mind, how do you design a GUI library for C++? Although a GUI component exists on the screen and is drawn on that screen, the components and graphics elements should be kept seperate, since it is primarily the OSs role to render a component. There are shared elements (mostly the position, size and area types) and the graphics layer should allow for graphics-based events to be handled by the components library. Taking a look at how C++ is designed, it is predominantly data orientated. That is, C++ allows you to create new data types that fit into the language via operator overloading. The STL provides collections of data and algorithms for manipulating those collections. Terminal-based applications are supported by I/O streams that allow you to send data out and read data in. I have taken this as the primary design feature when implementing the GUI components. Thus, each component has an event to signal user interaction (ondatachanged, onselectionchanged, onpressed) and data that is associated with the component. The first thing that comes to mind when reading "data that is associated with the component" is data binding. I think it is a mistake to build data binding directly into the component architecture. The reason for this is twofold: You would need to use templates to bind the different data objects to the control which makes it harder to implement the controls in a platform-independant way and can lead to code bloat. Also, consider having a textbox widget that you use to enter the age. Having: gui::textbox< long > age; How does the textbox perform the conversion? By storing the data as a string, the user can extract the information on data collection like this: long age = boost::lexical_cast< long >( age_input.get_text()); or long age = ::atol( age_input.get_text()); Another thing to take into account is when an input field has a validity based on other component values. For example, the valitity of a dates day field is dependant on month and year. In this instance, it is best to put all the validation logic in the base component and extract the data to a date class such as Boost.DateTime's date. A component has a size and position, as well as visibility (visible or hidden) and enabled/disabled states. The component should make it easy to interoperate with native API. The majority of the current proposals (mine included) have taken the approach of providing native interoperability with the OS-specific data structures. This is very difficult to maintain properly and support generic code because of the different names of the data elements, types used (long or float) and whether an area is (position + size) or (top-left + bottom-right). Also, most OSs have (0,0) being the top-left corner, but MacOS has (0,0) being bottom-left. With this in mind, I have taken a drastic approach: do not provide native interoperability for size, position and area. I have designed them as: struct position{ float x; float y; }; struct size{ float dx; float dy; }; struct area { float top; float left; float width; float height; }; This means that the interface must convert these to the native representations and vise versa. The current implementation (Windows specific at this time) can be found at: http://uk.geocities.com/msclrhd/gui/gui.zip Thoughts? Comments? Regards, Reece

14 36

[iostreams] New version avaiable
by Jonathan Turkanis 29 Dec '04

29 Dec '04

Dear All, The latest version of the Iostreams library is now available: http://home.comcast.net/~jturkanis/iostreams/ I'd like to thank everyone who sent me bug reports after I posted the previous version. I will include you in the acknowledgments when I rewrite the documentation. Contents: - I. Changes - II. Supported platforms - III. Remaining bugs. ----- I. Changes. There are two important changes. First, the code conversion component has been renamed "code_converter", and it now has an optional Codecvt template parameter. Example. #include <boost/iostreams/code_converter.hpp> #include <boost/iostreams/device/mapped_file.hpp> // Perform code conversion using the global locale: typedef code_converter<mapped_file_source> wide_mapped_file_source; // Perform code conversion using utf8_codecvt_facet: typedef code_converter< mapped_file_source, utf8_codecvt_facet<wchar_t> > utf8_mapped_file_source; code_converter has now been tested with all the codecvt facets from the Dinkumware CoreX library. Second, there is now an option to build the libraries zlib and bzip2 from the source, rather than linking to a pre-built version. To build zlib from the source, define the following variables: ZLIB_SOURCE - path to the .co files ZLIB_INCLUDE - path to the .he files, if different from ZLIB_SOURCE To link to a pre-built version, define the follwing variables: ZLIB_INCLUDE - path to the .h files ZLIB_LIBPATH - path to the library or archive file ZLIB_BINARY - name of the library or archive file If ZLIB_LIBPATH is not defined, it is assumed that the library file is in a location where it will be found automatically. If ZLIB_BINARY is not defined, it defaults to "z" on UNIX and Cygwin, and to "zdll" on windows (see http://www.gzip.org/zlib/DLL_FAQ.txt) Similar remarks apply for bzip2. ----- II. Supported platforms The tests have been run on the following platforms: VC7.1 with Dinkumware GCC 3.2 (MinGW) GCC 3.4.2 (MinGW) GCC 3.4.1 (Cygwin) CodeWarrior 8.3 (static runtime only) Intel 7.1 with Dinkumware (static runtime only) Intel 8.0 with Dinkumware Borland 5.6.4 with STLPort Failures: - GCC (MinGW, Cygwin): wide streams not supported - Borland 5.6.4: undiagnosed runtime errors in seekable_file_test.cpp, direct_adapter_test.cpp and code_converter_test.cpp III. Remaining bugs. Although the bzip2 tests pass on all the platforms in II, there is an outstanding problem reported by Michel Decima which I haven't been able to fix yet. Best Regards, Jonathan

1 1