January 2005 - Boost - lists.preview.boost.org

[thread] Resource usage in Win32 version of condition class
by Don G 03 Jan '05

03 Jan '05

I just joined the mailing list, so please pardon me for (and educate me on) failed points of etiquette. You all have done some fine work! I may be worried over something inconsequential, but the condition class creates three kernel objects per instance. Granted, one would have to instantiate hundreds of these objects to notice a problem, but STL collections make such things trivial. For example, in a previous job one of our teams created a large, in-memory database that had a mutex/condvar on lots of objects. I guess that I am concerned by the non-portable "cost of use" equation (say vs. pthreads). One could write code that was perfectly reasonable on Unix and quite terrible on Windows. Some years ago I also implemented a condvar on Win32, but the technique I used required only one event per thread (a CondVar was nothing more than a list of stack structures guarded by the associated mutex). In the FWIW category, I could see no benefit (and lots of pain) binding the condvar to the mutex at the time of wait(), so in my implementation a condvar was permantently bound to its mutex (as in "condvar::condvar(mutex & m)"). I have yet to find a case where the posix-style, free association was needed. Best regards, Don Griffin __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

2 1

[shared_ptr] Why aren't atomic integer operations used?
by Don G 03 Jan '05

03 Jan '05

I was reading the shared_ptr and shared_count classes and noticed that a mutex is used when it appears that atomic inc/dec could be used instead. Unless I am missing something? The atomic operations would be far better in terms of resource usage. It seems (to me anyway) far too expensive to have a mutex allocated for every object under management. On platforms where atomic inc/dec don't exist (if there are any<g>), a pool of mutexes be used. The object's pointer would be hashed to produce the appropriate mutex, thereby ensuring a consistent mutex for each object and a low likelihood of undesired contention. Also, an upper bound on the number of mutexes allocated vs. objects. Best, Don PS: This is now only my 2nd post, so if I am not following proper protocol, please feel free to advise. __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250

2 1

Anyone interested in network interface (sockets) library?
by Don G 03 Jan '05

03 Jan '05

I was curious if others have discussed this before. I searched and found nothing on "socket" or "network". Best, Don __________________________________ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com

2 1

Boost Files Section
by Robert Ramey 03 Jan '05

03 Jan '05

Following the "Files" link on the main page takes me to the Yahoo files section - which turns out to be full. Where should files be loaded to and downloaded from - and shouldn't the link on the main page point to that? Robert Ramey

1 0

RE: [boost] Re: [gui] The Big Picture [and wxWidgets]
by Brian Braatz 03 Jan '05

03 Jan '05

> -----Original Message----- > On Behalf Of Matt S Trentini > Subject: [boost] Re: [gui] The Big Picture [and wxWidgets] > > Heya Rene, > > That all sounds great; perhaps we should be helping out the wx guys > rather than come up with our own library...? > > Does anyone else have any good reason why we should create a completely > new library assuming that those issues are addressed? (License could be > one problem quite aside from the technical issues.) > > Keep in mind that starting a GUI library from scratch is going to take > *significant* time. > > And is wxWindows our "best bet"? It's certainly going to be easier than > trying to convince the Qt folks to get rid of their preprocessor... ;) > > It'd be fantastic if all the issues I brought up with wxWidgets were > addressed and we ensured that it worked well with the other boost > libraries. > > Is there anything anyone else wants or needs that wxWidgets couldn't > supply? [Brian Braatz] I have been watching this whole thread closely, and just wanted to send out a mail in support of the idea of collaboration. I have written many UI Frameworks ON TOP of things like MFC and OWL, and even just writing something ON TOP Of one of those things is a huge task. In one case this was my primary job for several years. It is one of those things where to get something demo-able is easy. But "Completing" it is a different issue entirely. If you look at all the fundamental issues discussed in this thread, i.e. do we have our own point coordination system etc, you can see that there is more here than meets the eye. I will end my thoughts here with the (repeated) suggestion that making a thin layer above the current WxWindows will allow for a Boost.Gui in a short timeframe that has an incredible API interface. :) Brian

6 13

Named Template Params
by David Greene 03 Jan '05

03 Jan '05

I see that a Named Params library has been accepted into Boost. Great! Is this named template params or named function params? I've actually been working on a named template params implementation of my own so I'm particularly curious about what Dave and Daniel have done, whether it be for templates or functions. Is there an accessible page of documentation somewhere? There's been a named_template_params.hpp in the sandbox for a long time. What's going on with that? Is there general interest in a named template parameters library? -Dave

5 10

GUI History
by David Abrahams 02 Jan '05

02 Jan '05

2 2

feature wish for boost 1.32.1 or 1.33.0: pkg-config support
by Andreas Pokorny 01 Jan '05

01 Jan '05

Hi Boosters, I am using boost in several projects now, and some of these projects will be released as open source. So they will have a configure script that checks the compiling host, and which should report missing libraries. I saw many open source projects adding boost to their source code tree directly, thus these projects dont have to check the proper boost versions, or library names. That solve the problem, but thats not a fine solution. To simplify using boost libraries i would like to see boost supporting pkg-config or a different maybe better approach which fits better to boost's needs. But first I would like to explain how pkg-config works, and how pkg-config makes using librariers simple. The pkg-config package can be found here: http://pgk-config.freedesktop.org/wiki/Software_2fpkgconfig It seems to work on all unix systems and windows. The pkg-config script parses .pc files from several locations in the system, and allows querrying the existance, version, compiler flags and linker flags of installed libraries. For example the gtkmm-2.0.pc file looks like that on suse systems: prefix=/opt/gnome exec_prefix=${prefix} libdir=/opt/gnome/lib includedir=${prefix}/include Name: GTKmm Description: C++ wrapper for GTK+ Requires: glibmm-2.0 gdkmm-2.0 pangomm-1.0 atkmm-1.0 gtk+-2.0 Version: 2.2.8 Libs: -L${libdir} -lgtkmm-2.0 Cflags: -I${includedir}/gtkmm-2.0 -I${libdir}/gtkmm-2.0/include Thus when running 'pkg-config --libs gtkmm-2.0' One gets the output: -Wl,--export-dynamic -L/opt/gnome/lib -lgtkmm-2.0 -lgdkmm-2.0 -latkmm-1.0 -lgtk-x11-2.0 -lpangomm-1.0 -lglibmm-2.0 -lsigc-1.2 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 which can be used to link a gtkmm application to all libraries needed. With the help of pkg-config can write simple makefiles, or build scripts which execute pkg-config directly. But pkg-config also comes with a nice m4 script to invoke it properly with autoconf. PKG_CHECK_MODULES(GTKMM, gtkmm-2.0, ,[AC_MSG_ERROR("Gtkmm-2.0 missing")]) I am not sure how to provide transparent support for different toolsets, and there is no way to specify further flags, like mt debug ... So qt for example has adds two files qt.pc and qt-mt.pc. So maybe pkg-config is not the right tool for boost. But at least for a large amount of the gcc-boost users it would be fine. Maybe boost could provide a similar facility for autotools. So maybe a small "boost-config" that gets flags like toolset, debug-switch, a version range descriptor, and then prints the compiler and/or linker flags. And a small m4/shell script that makes invoking that tool even simpler. Regards Andreas Pokorny

10 31

[gui] GUI Taxonomy
by Alan Gutierrez 01 Jan '05

01 Jan '05

The OS Direction I'm looking over wxWindows. I'd like to avoid this sort of thing, yet another wrapper library. They seem to have done as Andy Little and Reece Dunn have cautioned against, and started with a particular OS as a model, rather than starting with a model. As I look closer, or stand back and squint, the object heirarchy appears to be a usual-suspects collection of GUI objects, wxPen, wxWindow, wxFocusEvent, et al. Oh, and wxObject. *sigh* Perhaps they didn't start with an particular OS, but they certialy started at the OS and worked their way up, rather than starting at application and working their way back. It is vital to address the design of the primitives. It is a mistake to think of a GUI as merely a collection of primitives. After thirty years, the GUI has begun to develop a set of canonical forms. Any new GUI library should recognize these forms, and cater to the needs of the developer who must implement them. A Taxonomy - The Dialog A collection of widgets, gathered together in a window that usually of a fixed size, usually presented to the user in a modal state. Hence the term dialog, indicating a back and forth between the user and the application. Most dialog systems include a means to specify the layout of a dialog from a resource file. Dialog applications include setting preferences, choosing files, notification of errors, specification of search criteria. - The Grid A collection of widgets, arranged in scrollable rows and columns, in a resizable window, where widgets can be added or removed as the inserts or deletes data. Newer windowing libraries such as Delphi's VCL or Swing provide a grid library, for a time it seemed to be a defining characteristic of a new entry into the GUI arena. Grid heavy applications include spreadsheets, databases, and accounting applications. - The Document Text with a flow direction, broken by whitespace and hyphenation, along with imagry, and object, grouped by blocks, gathered into columns and tables. Most recent application frameworks provide support for the document model by making a component of a web browser, or providing a rich text edit control. Document applications include web browsering, word processing, and reporting. - The Canvas A blank surface onto which shapes are input, usually through manipulation of the mouse, as in drag and drop, and grabbing handles, or else output but still responsive to mouse clicks. There are many shape libraries available, but this is generally the sort of thing that gets written time and again. Canvas applications include illustration, diagraming, charting. - An Example A contemporary personal finance program uses The Dialog to set preferences and to open files, The Grid to display a check register for editing, The Document to display a nicely formatted balance sheet and a hyperlinked start page, and The Canvas to render a pie chart of spending by category. What did I miss? The Application Direction I'm representing this taxonomy since in discussion I'm finding that there are different needs for different problems, and we should know which problems we are addressing. Hit-testing a widget in a dialog or a grid ought to be a trivial operation, hit-testing a line of text in a document somewhat more difficult, and hit-testing a partially exposed polygon on a canvas a real challenge. One should not pay for what one does not need. Validation is a concern for dialogs and grids, but it isn't a concern of a bar chart. Even if when developing a full-blown drawing application, one should not have to pick up the pen and draw out each tool-tip, or call out, when those could be rendered as little documents. -- Alan Gutierrez - alan(a)engrm.com

7 33