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

[jamboost] Boost.Build V2, Milestone 10 released
by Vladimir Prus 04 Nov '06

04 Nov '06

I'm pleased to announce that the next milestone release of Boost.Build V2 is available at http://prdownloads.sourceforge.net/boost/boost-build-2.0-m10.tar.bz2 http://prdownloads.sourceforge.net/boost/boost-build-2.0-m10.zip See also http://boost.org/boost-build2/ for online docs (a copy is included in distribution). Due to large number of improvements all users are encouraged to upgrade. Changes in this release: Many toolsets were added: Intel, Metrowerks, Comeau, aCC, vacpp. Documentation was converted to BoostBook and improved. Performance was improved. - Toolsets initialization syntax is much more uniform. Compiler and linker flags can now be specified. - The algorithm for computing build properties was improved. Conditional requirements can be chained, and a number of bugs were fixed. - Specific order of properties can be specified. - The main target rules can be called from everywhere, not necessary from Jamfile. - Check for "unused sources" removed. - The <library> feature affects only linking now. - The <file> feature now works only for libraries. - Simpler syntax for "searched" libraries was added. - New <dependency> feature. Unix: The right order of static libraries on Unix is automatically computed. The <hardcode-dll-paths> feature is the default. gcc: The -fPIC option is passed when creating shared libraries. Problems with distcc were solved. Sun: It's now possible to use the sun linker (as opposed to gnu), and to compile C files. Darwin: Shared libraries are now supported. MSVC: Before resource files compilation, the setup script is invoked. Options deprecated in 8.0 are not longer used. The following bugs were fixed: - The <unit-test> rule did not handle the <library> property. - Don't add "bin" to the build directory explicitly specified by the user. - Allow <include-type> to select staged targets, even with <traverse-dependencies>off. - Includes for the form '# include <whatever>" did not work. - (Qt) Add paths to all dependent libs to uic command line, which helps if the UI files uses plugins. - Using <toolset-msvc:version>xxx in requirements was broken. - Error message printed when target can be found is much more clear. - Inline targets in sources of 'stage' did not work. - Don't produce 'independent target' warnings on Windows - (gcc) The <link-runtime>static did not work. - (gcc) Suppress warnings from the 'ar' tool on some systems. - (gcc) Don't try to set soname on NT. Developer visible changes: - Generator priorities are gone, explicit overrides are used. - 'Active' features were removed - Support for VMS paths was added. Thanks to Christopher Currie, Pedro Ferreira, Philipp Frauenfelder, Andre Hentz, Jurgen Hunold, Toon Knapen, Johan Nilsson, Alexey Pakhunov, Brock Peabody, Michael Stevens and Zbynek Winkler who contributed code to this release. - Volodya

3 5

[Python] Slice test fails on Intel 8.1 at runtime
by Stefan Slapeta 23 Oct '06

23 Oct '06

This is not a new failure, but the failure is reported for the first time. Please could anybody have a look at it? See http://tinyurl.com/4n2fx Thanks, Stefan

5 12

New implementation of remove_xxx for vintage compilers
by Peder Holt 28 Mar '06

28 Mar '06

Hi. I have started implementing some of the missing type_traits functionality for vintage compilers using typeof. The following are complete, and seem to work flawlessly on VC 6.5 and 7.0: remove_pointer remove_reference remove_bounds The source is available at: http://groups.yahoo.com/group/boost/files/typeof_vintage.zip The use of typeof in this respect, makes remove_xxx much more flexible. Would it be possible to start using this scheme for compilers without partial template specialization support? #define BOOST_MAX_TYPEOF_SIZE 20 #include <boost/test/minimal.hpp> //Include typeof_define.hpp in all header files where new types are added to typeof. #include <boost/typeof/typeof_define.hpp> #include <complex> #include <boost/type_traits/remove_reference.hpp> #include <boost/type_traits/remove_pointer.hpp> #include <boost/type_traits/remove_bounds.hpp> #include <boost/type_traits/is_same.hpp> template<typename A0> struct X {}; template<typename A0,unsigned int A1> struct Y {}; template<typename A0,typename A1,long A2> struct Z {}; BOOST_TYPEOF_DEFINE_TEMPLATE(X,1,(typename)) BOOST_TYPEOF_DEFINE_TEMPLATE(Y,2,(typename,unsigned int)) BOOST_TYPEOF_DEFINE_TEMPLATE(Z,3,(typename,typename,long)) BOOST_TYPEOF_DEFINE_TEMPLATE(std::complex,1,(typename)) int test_main(int, char*[]) { BOOST_TEST((boost::is_same<X<int>* const[8][9],boost::remove_bounds<X<int>* const[5][8][9]>::type>::value)); BOOST_TEST((boost::is_same<Z<X<double&>,Y<bool[4][7],12324>,0>* const*,boost::remove_pointer<Z<X<double&>,Y<bool[4][7],12324>,0>* const**volatile>::type>::value)); //VC7.1 fails to compile remove_reference. BOOST_TEST((boost::is_same<Y<int,345>** const,boost::remove_reference<Y<int,345>** const&>::type>::value)); typedef BOOST_TYPEOF(5.+std::complex<double>(6,7)) result_type; BOOST_TEST((boost::is_same<result_type,std::complex<double> >::value)); return 0; } -- Peder Holt

8 29

[ANN] Phoenix-2 Preview
by Joel de Guzman 01 Dec '05

01 Dec '05

Hi, Hi. Here's a preview of Phoenix V2. This will probably be the last release of the library. Phoenix V2 will be the basis of the Phoenix and Boost.Lambda merger. You can get it here: http://spirit.sourceforge.net/dl_more/phoenix-2.zip You can browse the draft docs here: http://tinyurl.com/6crgp What's new? A lot. This is a total rewrite based on earlier discussions with Jaakko Jarvi. The library's is built on top of Fusion and of course MPL. Of particular interest are local variables and lambda-lambda scopes: http://tinyurl.com/3mn6w There is also a set of lazy functions that work on STL sequences (e.g. push_back etc.): http://tinyurl.com/46bbm and pretty soon, a final TODO item (built on top of scopes/ lambda), lazy STL algorithms (e.g. find_if, etc). The scopes section (link provided above) in the docs illustrates how to write lazy functions that accept higher order functions (e.g. for_each). Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

5 19

[Review] Named parameters library
by Doug Gregor 10 Jul '05

10 Jul '05

The formal review of the Named Parameters library by David Abrahams and Daniel Wallin starts today and runs until Monday, November 22nd. The Named Parameters library provides a framework for writing functions that can accept arguments by name or by position. The use of named parameters can improve the readability of calls to these functions, especially when the functions have many parameters with default values. The Named Parameters library allows one to write a new_window function that allows a call such as: window* w = new_window("alert2", movable = true); The library is available in the Boost sandbox here: boost/named_params.hpp libs/utility And in the files area (login required): http://groups.yahoo.com/group/boost/files/named_params.zip Reviewers may wish to compare this solution to the named parameters already used by the Boost Graph Library, documented here: http://www.boost.org/libs/graph/doc/bgl_named_params.html Please send your reviews either to the Boost list or to me personally. The former is preferred, because it allows the community to consider your review as well. When writing your review, you may wish to consider the following questions (from http://www.boost.org/more/formal_review_process.htm#Comments) - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? As always, please remember to clearly state whether you believe the library should be accepted into Boost. Thank you Doug Gregor Review Manager, Named Parameters library

23 131

[signals] Performance
by Jody Hagins 04 Apr '05

04 Apr '05

Are there any docs which describe the performance of the signal/slot library? I was about to embark on a performance study because I want to use it in a very high performance critical code path, but I thought I'd ask if anyone else may have already done some work in this area. Thanks!

12 35

IMPORTANT: yahoogroups admin rights problem
by Toon Knapen 30 Mar '05

30 Mar '05

Hello ALL, As many of you might know, currently we are unable to add new members to the ublas-ml. The problem is that only Joerg has the rights to add members to the list but Joerg does not respond anymore. Could some of you try to contact Joerg or give me his telephone number that I talk to him about this. If we do not have a solution by end of November I will create a new project on yahoogroups (and we all have to switch). Additionally we need to contact Joerg and Mathias (again!) about applying the Boost Software License. I currently have the impression that they are not willing to change ublas to the BSL. In that case IMO, we will have to rewrite uBLAS to not get thrown out of boost. Again his phone-number would be handy if you have it available. Please contact the ml or me asap about the above issues or we will need to take drastic actions. toon

4 4

Open watcom
by Charles Schwartz 30 Mar '05

30 Mar '05

Does anyone know of the status of Watcom (http://www.openwatcom.org/) w.r.t. boost compilation? Are there plans to test against this compiler in the future?

8 12

RE: [boost] Call for Volunteers: the Synopsis project
by Stefan Seefeld 30 Mar '05

30 Mar '05

Hi Volodya, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > Sent: September 30, 2004 03:04 > Count me as interested. Are you going to base that parser on > OpenC++, which, > IIRC, was used by Synopsis some time ago? Last time a looked > at OpenC++, it > did not even distinguish between ordinary names and > typenames, which makes me > wonder if it's a good parser. You are right, there remains a lot of work to be done. The C++ parser backend of synopsis which we are talking about here is indeed based on OpenC++, but has already undergone lots of improvements. In its original design the parser didn't contain any form of semantic analysis such as symbol lookup to disambiguate certain expressions. For what it had been used so far it was good enough. I'm now working on the features that allow it to get closer to the standard, i.e. constant expression evaluation, symbol (type) lookup, etc. As I said, any help would be very appreciated ! Regards, Stefan

2 2

Warnings in Boost.Thread
by Janusz Piwowarski 29 Mar '05

29 Mar '05

Hi all, When Boost.Thread is compiled in release mode, there are a lot of warnings about unused variable 'int loop_count' in read_write_mutex.cpp. They comes from code like: int loop_count = 0; while (m_state == -1) { BOOST_ASSERT(++loop_count == 1); ++m_num_waiting_readers; m_waiting_readers.wait(l); --m_num_waiting_readers; } If loop is for second evaluation of condition only, i think it would be better to write: if (m_state == -1) { ++m_num_waiting_readers; m_waiting_readers.wait(l); --m_num_waiting_readers; BOOST_ASSERT(m_state != -1); } Regards, Janusz

2 1

[filesystem] Major changes before standardization
by Beman Dawes 13 Feb '05

13 Feb '05

I'm currently working on a major revision of the Boost filesystem library aimed at getting it ready to be proposed to the C++ committee for the next Library TR. The critical technical change required is internationalization. The plan is to provide a templated basic_path class, with typedefs for path and wpath. In other words, an approach very similar to the current std::basic_string, std::string, and std::wstring. Doing this adds a certain amount of complexity compared to the current path class. For example, a path_traits class has to be introduced to give basic_paths on user defined types a way to import the conversions, delimiters, and other traits. To offset the added complexity, I'd like to reduce some of the complexities in the current design: * Eliminate the distinction between native and generic grammars; either would be permitted in all contexts. As well as simplifying the class interface a bit, this will also eliminate a source of user confusion. * Move the name error checking from the basic_path class into stand alone functions. Although the current error checking could be further improved by Peter Dimov's suggested change allowing failure to be treated as either a warning or a hard error, moving it out of the class simplifies the interface, allows full path (rather than name-by-name) error checks, and eases internationalization. The primary downside of these changes will be that users who want path portability checks will have to code calls to checking functions that are currently being called automatically. The internationalization of the library is a big enough change that we will probably want to have at least a mini-review once the changes are complete. Comments? --Beman

12 55

StringAlgo::split issue
by Dirk Gregorius 29 Jan '05

29 Jan '05

Hi, I used the split function on the following string: vector<string> tokens; string str= "( 448 448 64 ) ( 448 0 64 ) ( 0 448 64 ) name 0 0 0 0.5 0.5 0 0 0"; split( tokens, str, is_any_of( ()), token_compress_on ); // I pass 'space' , '(' and ')' into is_any_of() I was supposed to get 18 tokens. The first nine values, the string "name" and the remaining eight digits. "split" always returns a string vector containing 19 tokens, where the first element of the vector is an empty string. Why does the function insert empty strings into the collection? Can I use split to obtain the 18 wanted tokens? -Dirk

3 4

Re: [iterator] small feature request
by David Abrahams 23 Jan '05

23 Jan '05

Eric Niebler wrote: > The iterator_adaptor<> template has a base() function to access the > underlying iterator. Well and good. However, iterator_adaptor<> doesn't > have a public typedef for the iterator type returned from this function. > Can it be added? > > Rationale: > Given some iterator of type T that is built of an unknown number of > adaptors, extract the underlying iterator. Consider: > > template<class Iter> > typename disable_if<is_adapted<Iter>,Iter>::type > base(Iter const & it) > { > return it; > } > > template<class D,class B,class V,class T,class R,class Di> > ?????????? > base(iterator_adaptor<D,B,V,T,R,Di> const & it) > { > return base(it.base()); > } > > I can't think of a way to write the return type of the second overload. > If iterator_adaptor had a nested typedef for its Base template > parameter, this would be very straightforward. Seems reasonable. Can you submit a patch? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 6

xml_grammar.cpp and OS X
by Alan 17 Jan '05

17 Jan '05

What is the state of the release build hang on xml_grammar.cpp on OS X? Has anyone endevoured to block out the offending optiminzation? This is were I saw the message discussed last. http://aspn.activestate.com/ASPN/Mail/Message/2233439 -- Alan Gutierrez - alan(a)engrm.com

13 36

[program_options] multi-line description patch
by Bertolt Mildner 17 Jan '05

17 Jan '05

What do you think about the attached patch to enable correct formated multi-line option descriptions? It is not pretty but is has the following features: - Formats multi-line descriptions using first_column_width and a given line length (currently hardcoded). - If set up for a shell with 80 chars per line it uses only 79 *but* also formats correctly in larger shells. - Handles '\n' in description strings. - Trimms leading *single* spaces in new lines (" that" gets trimmed, but " leave my formatting" not). - Words are not chopped at line endings but put to new line (if not more that half the line would be empty). Known problems: - If the current shell has too short lines the formatting is all messed up. - Chokes on '\t', they are currently not handled in any way. - Sacrifices one char to be able to format correctly in larger shells. - Code is a "iterator arithmetic" hell. :( - The line length should be a parameter of options_description with a default value (probably 80). With this users may query the current shell for its line length, if possible. Patch compiles fine on CW 8.3 and VC 7.1. Maybe heaving two modes would also be a good idea? One as a "safe mode" where one char is sacrifices but the line length may be longer and another mode where the exact line length is known and fully used ... The following code ... ---------------------------------------------------------- po::options_description options("Options"); options.add_options() ("help", "a long help msg a long help msg a long help msg a long help msg a long help msg a long help msg a long help msg a long help msg ") ("well_formated", "As you can see this is a very well formatted option description.\n" "You can do this for example:\n\n" "Values:\n" " Value1: does this and that\n" " Value2: does something else\n" " Value3: has a very long\n description.") ; std::cout << options << "\n"; ---------------------------------------------------------- ... gives this output. ---------------------------------------------------------- Options: --help a long help msg a long help msg a long help msg a long help msg a long help msg a long help msg a long help msg a long help msg --well_formated As you can see this is a very well formatted option description. You can do this for example: Values: Value1: does this and that Value2: does something else Value3: has a very long description. ----------------------------------------------------------

4 19

RFC: mixing std::map and boost::optional
by Ulrich Eckhardt 13 Jan '05

13 Jan '05

I had the idea to use boost::optional on the interface of a std::map-like object. I have neither coded a prototype nor is this a fully grown design yet, I'd just like to discuss this idea. The rough outline is this: class my_map { public: optional<value>& operator[](key const&); optional<value> const& operator[](key const&) const; // iterators, ctors, dtor, etc the same private: optional<value> const m_empty_value; tree< pair<key, optional<value> > > m_content; }; The important differences to std::map are: 1. operator[] is available as const and non-const memberfunction. The const memberfunction returns 'm_empty_value' in case the key is not found. The non-const one inserts a new node into the tree and returns a reference to that. 2. operator[] return an optional<value>, not a direct value. This means that you have to check the return-value of this call. OTOH, you _can_ check the return value to see if a key was associated with a value. Some example code, compared with the equivalents using std::map: // two maps std::map<string,float> stdmap; my_map<string,float> mymap; // const references, for cases where it makes a difference std::map<string,float> const& stdmapc = stdmap; my_map<string,float> const& mymapc = mymap; ///////// inserting an element: stdmap["key"] = 41.0f; mymap["key"].reset(42.0f); ///////// accessing an element access(stdmap["key"]); std::map<string,float>::const_iterator it = stdmapc.find("key"); if(it!=stdmapc.end()) access(it->second); else access(float()); boost::optional<float>& value = mymap["key"]; if(value) access(*value); else access(float()); boost::optional<float> const& value = mymap["key"]; if(value) access(*value); else access(float()); ///////// removing an element stdmap.erase("key"); mymap["key"].reset(); ///////// finding out if an element exists if(stdmap.find("key") != stdmap.end()) found(); if(mymap["key"]) found(); ///////// iterating and accessing for(std::map<string,float>::const_iterator it=stdmap.begin(); it!=stdmap.end(); ++it) access(it->second); for(my_map<string,float>::const_iterator it=mymap.begin(); it!=mymap.end(); ++it) if(it->second) access(*(it->second));

2 1

program_options: compilation fixes
by Graham Bennett 12 Jan '05

12 Jan '05

Hi, parsers.cpp and value_semantic.cpp in 1.32.0 both use 'tolower' without including <cctype>, which on my platform is not included as a side-effect of one of the other headers. I have attached patches which make it compile cleanly for me. Thanks, Graham. -- Graham Bennett

2 1

Boost Thread - Read Write Mutex Problem
by David Brownell 11 Jan '05

11 Jan '05

When running the simple program listed below, the scoped_read_lock appears to never acquire a read lock on the mutex and, as a result, the program never finishes. In looking through the documentation, I don't think there is anything additional I need to do and was a bit surprised that this didn't work. Here is the code: boost::read_write_mutex m(static_cast<boost::read_write_scheduling_policy::read_write_scheduling_pol icy_enum>(alternating_many_reads)); std::cout << "Before\n"; { boost::read_write_mutex::scoped_write_lock l(m); } std::cout << "Middle\n"; { boost::read_write_mutex::scoped_read_lock l(m); } std::cout << "After\n"; And some more details: - Windows XP SP2 - Microsoft Visual Studio 2003 - I am compiling with the Multithreaded DLL version of the CRT, so boost_thread-vc71-mt-gd-1_32.lib is being used - test_read_write_mutex.cpp completed without problems - writer_priority and reader_priority completed without problems. Only alternating_many_reads and alternating_single_read seem to have problems. Thanks for your help! David Brownell

3 2

[iostreams] Version of Iostreams compatible with 1.32 available
by Jonathan Turkanis 11 Jan '05

11 Jan '05

Hi All, A version of the Iostreams library designed to work with release 1.32 is now available: http://home.comcast.net/~jturkanis/iostreams/ This version does not incorporate all the changes decided on during the review, but most of the name changes have been applied. In particular, - The library is now contained entirely in the iostreams subdirectories of <boost> and <libs>. - Resources are now called Devices - The i/o mode Inout has been renamed Bidirectional - The concept Buffered has been renamed Multi-Character - Filters are now located in the directory boost/iostreams/filter - Devices are now located in the directory boost/iostreams/device The library has been tested on VC7.1, Intel 7.1-8.0 for Windows, Codewarrior 8.3 and GCC 3.2 (mingw). Unfortunately, I have noticed some regressions of GCC 3.3-4, but am working to correct them. I am confident that the library will eventually work on GCC 3.3+ and Borland 5.6.4. In addition, I may be able to provide limited support for VC6-7.0. I'm hoping to get a version into CVS soon. Also, several of the fixes that people sent me during the review have been removed because they caused regressions. They have not been forgotten -- they will be incorporated in to the final version in modified form. -- Jonathan Turkanis technews(a)kangaroologic.com

10 35

[gui] The Big Picture
by Reece Dunn 10 Jan '05

10 Jan '05

Hi All, We have different people with different needs and ideas as to what constitutes a UI system. The general concensus is that the resulting library should be designed independant of any target implementation and should support general platforms such as text-based systems. It is also advisable to allow interaction with a target platform to allow for platform-specific user code if required. There are several layers to a (G)UI library: [1] The platform independant layer. [2] The geometry layer - unit type, point, size, rect. [3] The base graphics layer - fonts, canvas, pens, images, etc. [4] The event handling layer - event loop, events, event handlers. [5] The UI object layer - frames, forms, widgets, lightweight objects, etc. Each of these layers is conceptually independant, but builds on top of the other. Should there be a separate library for each of these layers (Boost.Platform, Boost.Geometry, Boost.Graphics, Boost.Events and Boost.UIObject)? The design for the UI object layer must be able to support: * native-based UI objects that are dynamically constructed. * native-based UI objects taken from pre-built elements, e.g. objects on a form. * lightweight UI objects that are not native-based. * custom drawn native-based UI objects (either dynamically constructed or from pre-constructed objects), in essence a hybrid of native-based and lightweight UI objects. All of these UI object forms need to be supported, including bindings to different platforms/APIs. I see the basic UI object heirarchy as: ui::object ui::frame ui::form ui::main_frame ui::popup ... ui::widget ui::textfield ui::textarea ui::button ui::grid ui::table ... ui::layout_manager ui::flow_layout ... Here, I want to keep the UI object heirarchy as simple as possible. That is, the heirarchy is not dependant on platform specifics, but the UI object group to which the object belongs. A UI object consists of event processing and sizing/positioning. A frame is a UI object that has border (frame) decoration, with a main frame being a top-level frame, a form being a frame that is defined by an external resource and a popup is a frame that hosts components (e.g. a list of menu items for a specific menu item). A widget is a UI object that has specific events and data associated with it. A layout manager is a lightweight UI object that aids the positioning of widgets. The question is how to make it easy to specify both lightweight and native UI objects. Using a component< render_as< Renderer > > structure does not allow for an easy implementation -- how do you map the implementation details for a specific component and how do you make it extensible? I do not yet see an easy approach. I am thinking of a PIMPL-style implementation, but using templates to simplify allocation does not allow for easy construction of UI objects. Consider: ui::button ok( "OK", ui::button::push ); ui::button_impl< ui::lightweight_button > cancel( "Cancel" ); Likewise, having a constructor that takes an implementation, how do we construct the generic interface that allows this implementation. Consider: ui::button cancel( "Cancel", new ui::lightweight_button()); Also, having a shallow interface (i.e. each UI object is a top-level object), you would need duplicate code to handle common things like event handling and move/resize operations. All of these approaches has their own advantages and disadvantages. Regards, Reece

21 45

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