- Boost - lists.boost.org

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

Anyone Interested in a C++ to HTML pretty printer?
by christopher diggins 31 Dec '04

31 Dec '04

I am nearly finished a public domain C++ to HTML tool with syntax coloring. This is primarily intended as a demonstration of the YARD parser, but with practicial applications. I am wondering if anyone in the Boost community be interested in using the tool for sprucing up the code examples for the documentation to their libraries? The pretty printer recognizes and colors keywords, identifiers, string literal, character literals, number literals, macros and comments. It does so by using <span class="xxx"></span> tags around the elements. This means that italics / style / coloring can be controlled by a separate CSS file. There are some future enhancements which could be interesting as well such as: - automated hyper-linking of #include directives - javsascript open / close of code blocks { } Anyone interested? Christopher Diggins http://www.cdiggins.com http://www.heron-language.com

7 8

rational with finite precision
by Andras Erdei 31 Dec '04

31 Dec '04

i think the documentation on boost::rational is misleading, and it cannot be used with finite precision (e.g. the built-in) types at all: whenever the result of an operation cannot be represented exactly, it returns something totally bogus for example with rational<short> let's try to add 191/181 (=1.055...) and 197/193 (=1.021...) the exact result is 72520/34933 (=2.076...), and we get 6984/-30603 (=-0.229...)! i don't think the intended audience can "code in anticipation of such issues" (the task of determining when these issues come up has the same complexity as doing the actual arithmetic) imho this also means that the pre-calculated gcd() trick in op+= doesn't buy much: finite precision calculations will still fail randomly and my guess would be that it only makes unlimited precision calculations slower (2 gcd() calls + 4 op/()s instead of 1 gcd() call) fixing rational<> to work with finite precision integers so that for calculations like the above we get the best representable approximation (in this case 3197/1540 = 2.076, precise to 7 digits) is pretty straightforward -- the gcd() function implicitly calculates all representable approximations -- but would require rewriting the whole class br, andras

7 25

Serialization and async messaging
by Scott Woods 30 Dec '04

30 Dec '04

Hi, I have been doing a lot of async messaging over TCP and have looked through the serialization library in the hope that it could be applied to the task. If the serialized representation of an object has an unknown length then its reasonable to say that we dont know how many network blocks will be consumed, i.e. the receiver may read 1 or more blocks before completion. We also cant guarantee that the flurry of recv's that might result from an FD_READ (sorry to those non-Windows folks), will neatly terminate on an object boundary. IMHO the input function (operator>>) needs to be "re-entrant" if serialization can be used in an async environment. Repeated calls should be perfectly acceptable. Ultimately it would return an indication that a complete object has indeed been loaded. Some "state" needs to be held somewhere. My best guess is that this is not the case but I cant find anything conclusive (without wading deeper into code). Can anyone comment? ps: Its a thoroughly amazing library.

6 15

[iostreams] Problem using with MinGW GCC 3.4.2
by Daniel Schlyder 30 Dec '04

30 Dec '04

Hi, I get the following error when trying to compile a simple test (attached) using vector_sink from the tutorial with MinGW GCC 3.4.2: boost_iostreams.cpp: In function `int main()': boost_iostreams.cpp:41: error: invalid operands of types `boost::io::streambuf_facade< vector_sink, char_traits<char>, boost::io::output > ()(vector_sink)' and `int' to binary `operator<<' Please accept my apologies if I've overlooked something crucial in the docs. In case it matters, here is a list of changes I made to make the lib compile cleanly: 1. E:\libs\boost\libs\iostreams\build\../src/mapped_file.cpp:168: error: `::GetFileSizeEx' has not been declared According to MSDN, GetFileSizeEx() is only available under Windows 2000 and newer, so I had to remove this file from Jamfile sources. Maybe there should be a define for this, like for the compression code. 2. E:/libs/boost/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:150: error: `default_filter_buffer_size' undeclared (first use this function) E:/libs/boost/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:151: error: `default_buffer_size' undeclared (first use this function) E:/libs/boost/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:155: error: `default_pback_buffer_size' undeclared (first use this function) Fixed by including 'boost/iostreams/constants.hpp'. 3. E:/libs/boost/boost/iostreams/categories.hpp:102: warning: virtual base `boost::io::input_seekable' inaccessible in `boost::io::iostream_tag' due to ambiguity E:/libs/boost/boost/iostreams/categories.hpp:102: warning: virtual base `boost::io::device_tag' inaccessible in `boost::io::iostream_tag' due to ambiguity E:/libs/boost/boost/iostreams/categories.hpp:102: warning: virtual base `boost::io::output_seekable' inaccessible in `boost::io::iostream_tag' due to ambiguity Fixed by replacing struct seekable_device_tag : device_tag, seekable { }; with struct seekable_device_tag : virtual device_tag, seekable { }; and struct seekable : input_seekable, output_seekable, detail::one_head { }; with struct seekable : virtual input_seekable, virtual output_seekable, detail::one_head { }; 4. E:/libs/boost/boost/iostreams/detail/streambuf/linked_streambuf.hpp:54: error: variable or field `close' declared void E:/libs/boost/boost/iostreams/detail/streambuf/linked_streambuf.hpp:54: error: `close' declared as a `virtual' field E:/libs/boost/boost/iostreams/detail/streambuf/linked_streambuf.hpp:54: error: expected `;' before '( ' token Fixed by including 'ios'. 5. E:/libs/boost/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:377:1: warning: multi-line comment Fixed by changing to C-style comment. Not sure whether this is a problem with the code or GCC not handling the '\' in the macro definition properly. I also removed duplicate include of 'boost/iostreams/constants.hpp' in 'boost/iostreams/stream_facade.hpp'. TIA, -- Daniel Schlyder http://bitblaze.com/

2 4

Rendering Strategies
by Alan Gutierrez 30 Dec '04

30 Dec '04

I send a message to Noah Stein, where I think I've gotten a bit closer to what I'm trying to convey with rendering strategies, so I'm going to paste the relevent part... [paste] I want to drive home the point that hit-testing is easy for axis-aligned bounding boxes, and complicated visibility and hit testing is not necessary for a Symbian UI. Through generic programming, I'd like to leave it out when I don't need it, not think about it when I don't have to. The Win32 GDI mistake was to create a tree of graphic objects, each materialized in memory. Recognizing the common models of content rendering, you can devise better strategies than the allocation of a chunk of memory for every axis-aligned bounding box on the screen. (Or, conversely, throwing up your hands and saying that anything further is in the application domain. This is old, this is bad. It's widgets or the pen.) [snip] I agree that you can nest a canvas, in a form, in a document, and you can do this because of an axis-aligned box convention. It is exactly what I'd like to be able to do. Use a *canvas* renderer to render an vector graphics image in the corner of a button, or use a *document* renderer to draw formatted tool tips read from a resource file. (If I'm on a /G/UI that is.) A nested axis-aligned bounding box paradigm that rules UI organization. However, a *grid* has special needs. A *document* has special needs. A *document* should not have to materialize an object for each axis-aligned bounding box, attaching a font, pen, brush, background to each. Not when there is an obvious convention of inheriting styles from the containing bounding box. See? Recognize the rendering strategy, then you can optimize design. For a *document* each box need only be t,l,r,b, and, /and/ can be disposed of when it is off screen. For a *grid* you don't need a structure to represent the axis-alined box, you only need the height of reach row and the width of each column. Ah, but not of /each/ row and column, you can have a sparse list that indicates a change in row or column width, since they tend to be uniform. A *grid* does not need to keep components in memory, they only exist when activated. Materialized axis-aligned boxes are optimal for a *form*. For a fixed set of axis-aligned boxes, you can create an object, and take advantage of optimization that comes from using memory. Materialized axis-aligned boxes are also optimal for partitioning a window's client area. Thus my concern that this model will be mistaken for a panacea. Good for some things. Non-applicable for others. When it's not applicable, I don't think the library designers should throw up their hands and go, oh, looks like an application problem. Here's some grahpics utilities. Good luck. A *grid* or a *document* or a *form* have conventions that lend themselves to optimizations. Am I getting somewhere? -- Alan Gutierrez - alan(a)engrm.com

1 0

[date_time] catalog.xml in CVS
by Vladimir Prus 30 Dec '04

30 Dec '04

Hi, the date_time, specifically the libs/date_time/xmldoc directory, includes the catalog.xml file: File: catalog.xml Status: Up-to-date Working revision: 1.1 Repository revision: 1.1 /cvsroot/boost/boost/libs/date_time/xmldoc/catalog.xml,v I think it should not, as the file is generated by Boost.Build, and placing a version which includes paths like: file:///usr/local/src/bart is likely to lead to errors. - Volodya

3 8

RE: [boost] Top Ten Ideas For NEW Features Not Included in Surveyed Libs
by Brian Braatz 30 Dec '04

30 Dec '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Alan Gutierrez > Libs > > 1) Documents. > > Any new UI library without a flowing text strategy is doomed > to failure. > > Discuss. [Brian Braatz] ????? What is a flowing text strategy? Discuss!

2 1

[mpl] value2type generalization of int_ needed
by Larry Evans 30 Dec '04

30 Dec '04

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?

2 4