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

OS X Link Problems
by Alan 08 Jan '05

08 Jan '05

I built boost thus: bjam "-sTOOLS=darwin" -sBUILD="debug release <runtime-link>static/dynamic" After hacking around the xml_grammar.cpp problems, I get the link errors where the following functions cannot be found. (Removed a lot of extra stuff to try and display only the library and missing function. If you'd like to see all 183 lines that is possible.) I'm wondering if some test functions that are not meant to be in the library are referenced by something included in the library. darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/debug/runtime-link-static/shared-linkable-true/libboost_prg_exec_monitor-sd-1_32.dylib ld: Undefined symbols: cpp_main(int, char**) darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/debug/shared-linkable-true/libboost_prg_exec_monitor-d-1_32.dylib ld: Undefined symbols: cpp_main(int, char**) darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/debug/shared-linkable-true/libboost_prg_exec_monitor-d-1_32.dylib ld: Undefined symbols: cpp_main(int, char**) darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/release/runtime-link-static/shared-linkable-true/libboost_prg_exec_monitor-s-1_32.dylibld: Undefined symbols:cpp_main(int, char**) darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/release/shared-linkable-true/libboost_prg_exec_monitor-1_32.dylib ld: Undefined symbols: cpp_main(int, char**) darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_test_exec_monitor.dylib/darwin/debug/runtime-link-static/shared-linkable-true/libboost_test_exec_monitor-sd-1_32.dylibld: Undefined symbols:test_main(int, char**) darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_test_exec_monitor.dylib/darwin/debug/shared-linkable-true/libboost_test_exec_monitor-d-1_32.dylibld: Undefined symbols:test_main(int, char**) darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_test_exec_monitor.dylib/darwin/release/shared-linkable-true/libboost_test_exec_monitor-1_32.dylibld: Undefined symbols:test_main(int, char**) darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_unit_test_framework.dylib/darwin/debug/runtime-link-static/shared-linkable-true/libboost_unit_test_framework-sd-1_32.dylibld: Undefined symbols:init_unit_test_suite(int, char**) -- Alan Gutierrez - alan(a)engrm.com

6 7

[gui] Shoulders of Giants
by Alan Gutierrez 08 Jan '05

08 Jan '05

I'd like to take some time and study what has gone before. If I think of a list of successful windowing libraries the following come to mind. http://www.torjo.com/win32gui/ http://www.wxwindows.org/ http://java.sun.com/docs/books/tutorial/uiswing/ http://www.tcl.tk/ http://www.trolltech.com/ http://developer.apple.com/cocoa/ I plan on having the documentation for these windowing libraries on hand, as well as the source code, where available. I've advocated the use of a CSS layout component to render the View-Controller aspect in fashion that is cross-platform and i18n. This is my pet, so I'm interested in reading through existing web browser work. http://mozilla.org/ http://www.konqueror.org/features/browser.php http://developer.apple.com/darwin/projects/webcore/ https://xhtmlrenderer.dev.java.net/ I'm sharing these thoughts to see if anyone has must see, must consider projects to suggest. Maybe by looking at these lists someone can tell me if I'm totally missing a concept. -- Alan Gutierrez - alan(a)engrm.com

6 6

[type_traits] request for decayed<T>::type
by Thorsten Ottosen 06 Jan '05

06 Jan '05

Hi, The following trait is supposed to make it easier to forward arguments in generic code and in particular string literals. For example, I will use it when I update boost.assign to use const T& arguments instead of T arguments. It could also be used to make a better version of std::make_pair(): template< class F, class S > inline std::pair< typename decayed<F>::type, typename decayed<S>::type > make_pair( const F& f, const S& s ) { return std::pair< typename decayed<F>::type, typename decayed<S>::type >( f, s ); } Any thoughts from the type_traits authors? Do anybody mind if I add this to the cvs and make some docs for the type-traits library? br -Thorsten begin 666 decayed.cpp M(VEN8VQU9&4@/&)O;W-T+W)A;F=E+W9A;'5E7W1Y<&4N:'!P/@T*(VEN8VQU M9&4@/&)O;W-T+W1Y<&5?=')A:71S+VES7V%R<F%Y+FAP<#X-"B-I;F-L=61E M(#QB;V]S="]M<&PO979A;%]I9BYH<' ^#0HC:6YC;'5D92 \8F]O<W0O;7!L M+VED96YT:71Y+FAP<#X-"B-I;F-L=61E(#QU=&EL:71Y/@T*#0IN86UE<W!A M8V4@8F]O<W0-"GL-"B @("!N86UE<W!A8V4@9&5C87EE9%]D971A:6P-"B @ M("![#0H@(" @(" @('1E;7!L871E/"!C;&%S<R!4(#X-"B @(" @(" @<W1R M=6-T(')A;F=E7W!O:6YT97(-"B @(" @(" @>PT*(" @(" @(" @(" @='EP M961E9B!C;VYS="!T>7!E;F%M92!R86YG95]V86QU93Q4/CHZ='EP92H@='EP M93L-"B @(" @(" @?3L-"B @("!]#0H@(" @#0H@(" @=&5M<&QA=&4\(&-L M87-S(%0@/@T*(" @('-T<G5C="!D96-A>65D#0H@(" @>PT*(" @(" @("!T M>7!E9&5F('1Y<&5N86UE(&UP;#HZ979A;%]I9E]C/"!I<U]A<G)A>3Q4/CHZ M=F%L=64L#0H@(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @ M(" @(&1E8V%Y961?9&5T86EL.CIR86YG95]P;VEN=&5R/%0^+ T*(" @(" @ M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @("!M<&PZ.FED96YT M:71Y/%0^(#XZ.G1Y<&4@='EP93L-"B @("!].PT*#0H@(" @=&5M<&QA=&4\ M(&-L87-S($8L(&-L87-S(%,@/@T*(" @(&EN;&EN92!S=&0Z.G!A:7(\('1Y M<&5N86UE(&1E8V%Y960\1CXZ.G1Y<&4L( T*(" @(" @(" @(" @(" @(" @ M(" @('1Y<&5N86UE(&1E8V%Y960\4SXZ.G1Y<&4@/@T*(" @(&UA:V5?<&%I M<B@@8V]N<W0@1B8@9BP@8V]N<W0@4R8@<R I#0H@(" @>PT*(" @(" @("!R M971U<FX@<W1D.CIP86ER/"!T>7!E;F%M92!D96-A>65D/$8^.CIT>7!E+" - M"B @(" @(" @(" @(" @(" @(" @(" @(" @='EP96YA;64@9&5C87EE9#Q3 M/CHZ='EP92 ^*"!F+"!S("D[( T*(" @('T-"@T*?0T*#0HC:6YC;'5D92 \ M<W1R:6YG/@T*#0II;G0@;6%I;B@I#0I[#0H@(" @8F]O<W0Z.F1E8V%Y960\ M:6YT/CHZ='EP92!I;G1E9V5R(#T@,3L-"B @("!B;V]S=#HZ9&5C87EE9#QC M:&%R6S)=/CHZ='EP92!C:&%R7W!T<B ](")F;V\B.PT*(" @(&)O;W-T.CID M96-A>65D/&-O;G-T(&-H87);,ET^.CIT>7!E(&-C:&%R7W!T<B ](")F;V\B M.PT*(" @(&)O;W-T.CID96-A>65D/'=C:&%R7W1;,ET^.CIT>7!E('=C:&%R M7W!T<B ]($PB9F]O(CL-"B @("!B;V]S=#HZ9&5C87EE9#QC;VYS="!W8VAA M<E]T6S)=/CHZ='EP92!C=V-H87)?<'1R(#T@3")F;V\B.PT*#0H@(" @<W1D M.CIP86ER/'-T9#HZ<W1R:6YG+'-T9#HZ<W1R:6YG/B!P(" ](&)O;W-T.CIM M86ME7W!A:7(H(")F;V\B+" B8F%R(B I.PT*(" @('-T9#HZ<&%I<CQS=&0Z M.G-T<FEN9RP@:6YT/B @(" @(" @<#(@/2!B;V]S=#HZ;6%K95]P86ER*" B M9F]O(BP@,2 I.PT*#0H@(" @<W1D.CIP86ER/'-T9#HZ=W-T<FEN9RQS=&0Z M.G-T<FEN9SX@<#,@(#T@8F]O<W0Z.FUA:V5?<&%I<B@@3")F;V\B+" B8F%R M(B I.PT*(" @('-T9#HZ<&%I<CQS=&0Z.G=S=')I;F<L(&EN=#X@(" @(" @ M(' T(" ](&)O;W-T.CIM86ME7W!A:7(H($PB9F]O(BP@,2 I.PT*#0HO+R @ M("!I;G0@87)R87E;,3!=.PT*+R\@(" @<W1D.CIP86ER/&EN="HL:6YT*CX@ M<#4@/2!B;V]S=#HZ;6%K95]P86ER*"!A<G)A>2P@87)R87D@*3L-"@T*?0T* ` end

6 19

g++ STL/MPL conflicts?
by Arkadiy Vertleyb 06 Jan '05

06 Jan '05

Hi all, I was porting my older stuff into Boost 1.32, and it went fine with VC71. However, using g++ 3.3, I ran into a lot of naming conflicts between STL and MPL algoritms, such as find_if, copy_if, etc. From looking into previous posts, I can see that tis relates to a combination of problems in the g++ STL, such as using unqualified calls, and ADL not working correctly. Does anybody know if the problem was fixed in later versions of GCC? Thanks, Arkadiy

8 24

[Random] uniform_int vs. uniform_real vs. uniform_01
by Doug Gregor 05 Jan '05

05 Jan '05

I'm having a few problems dealing with uniform_real and uniform_01. The basic issue is that uniform_real does not always produce values between its min and its max. The problem consistently occurs when I'm using minstd_rand as my generator (one of the linear_congruential variants). For instance, if I write: template<typename RandomNumberGenerator> void foo(RandomNumberGenerator& gen) { uniform_int<int> rand_int(some_min_int, some_max_int); // Okay, some_min_int <= x <= some_max_int int x = rand_int(gen); uniform_real<double> rand_double(some_min_double, some_max_double); // Uh-oh, some_min_double <= y <= some_max_double doesn't always hold double y = rand_double(gen); } Looking at the source to uniform_real, the problem is obvious: result_type operator()(Engine& eng) { return eng() * (_max - _min) + _min; } uniform_real assumes that the engine returns a value in [0, 1], but doesn't check that. If this is correct (I hope it isn't!), the "obvious" answer is to use uniform_01<RandomNumberGenerator...> as input to uniform_real. However, uniform_01 is also broken in several ways: 1) It isn't a random distribution because its operator() does not accept an engine. Instead, the engine is embedded in the uniform_01 object. 2) uniform_01 stores the incoming random number generator by _value_, so the original generator "gen" does not advance. You can't even fake it with uniform_01<RandomNumberGenerator&>, because that creates reference-to-reference problems. Below is a small patch to make uniform_real<...> behave nicely. As for uniform_01: we should deprecate it in 1.33.0 and remove it afterwords, because it is hopelessly broken and not even included in the TR. Doug Index: uniform_real.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/random/uniform_real.hpp,v retrieving revision 1.14 diff -u -r1.14 uniform_real.hpp --- uniform_real.hpp 27 Jul 2004 03:43:32 -0000 1.14 +++ uniform_real.hpp 30 Dec 2004 22:11:33 -0000 @@ -50,7 +50,11 @@ void reset() { } template<class Engine> - result_type operator()(Engine& eng) { return eng() * (_max - _min) + _min; } + result_type operator()(Engine& eng) { + return static_cast<result_type>(eng() - eng.min()) + / (eng.max() - eng.min()) + * (_max - _min) + _min; + } #if !defined(BOOST_NO_OPERATORS_IN_NAMESPACE) && !defined(BOOST_NO_MEMBER_TEMPLATE_FRIENDS) template<class CharT, class Traits>

3 3

auto-link and comeau?
by Robert Ramey 04 Jan '05

04 Jan '05

I've made source changes to accommodate Comeau. Now even static libraries fail to compile on with this compiler. Is this the intention or am I missing something. Robert Ramey

6 21

RE: [boost] Re: FYI Lambda Question
by Brian Braatz 04 Jan '05

04 Jan '05

> -----Original Message----- > On Behalf Of Aleksey Gurtovoy > Subject: [boost] Re: FYI Lambda Question > Brian Braatz writes: > > We MIGHT have some missing files? I am about to convert to > > boost 1.32 I am still on 1.31. In the 1.31 zip file I > > downloaded (and am using), the header does not exist in the > > utility dir. > > That's 'cause 'result_of' was introduced in 1.32. > > > I grepped the boost tree for result_of and only > > found one comment in transform_iterator.hpp which is stated > > as a question ("do we need to adjust the way > > function_object_result is computed for the standard proposal > > (e.g. using Doug's result_of)?") (line 64). > > > > The link to the web page you sent me points to a HPP file. > > This file does not seem to exist in utility. For experimenting, > > I copied the file referenced in the page below to > > boost\utility. It complained on the line > > > > #include <boost/mpl/has_xxx.hpp> > > > > That has_xxx.hpp does not exist. > > Again, it does in 1.32. > Thanks you *very much* for help here. This issue is pushing me to convert to 1.32 (which is good- I am doing that NOW). And without help from everyone who is added thoughts, I would still be in the bicycle shed. (I still am but I now see the door). :) Once I get converted and get my code working, I will post to this list a quick how to on what the resolution to the original question was (this way other folks can find the solution in the future by searching mail archives). ****************** SEPARATE THREAD: It would be nice if boost doc pages pointed to a WIKI or something for people to add things to the documentation (not officially added mind you- just ammendums)(similar to how people can comment on products on amazon.com for example) . I.e. once I get code working on how to deduce return type from a lambda functor, it would be nice if I could put that info someplace easy for others to find. OR- Is the solution for me to write up a page of documentation and simply request it be added to the lambda documentation? (which raises the issue)- is there any process for this? Thanks Again Guys. It is the people that give boost the real "boost" :)

2 1

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

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