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

Boost License Permission
by Kevlin Henney 15 Sep '04

15 Sep '04

I give permission for all my contributions to Boost to be moved to the Boost Software License Version 1. Kevlin Henney -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

1 0

[filesystem]: bug and patch in path_posix_windows.cpp
by Angus Leeming 15 Sep '04

15 Sep '04

There are lots of "#ifdef BOOST_WINDOWS ... #endif" blocks wrapping code to handle the ':' in libs/filesystem/path_posix_windows.cpp. In one place only is the preprocessor block missing, which I believe is a bug. Patch attached. Silly test case. Without the patch, this: #include <boost/filesystem/path.hpp> #include <iostream> #include <string> namespace fs = boost::filesystem; int main() { std::string const PATH="/usr/local/bin:/usr/bin:/bin"; fs::path const path(PATH, fs::no_check); std::cout << PATH << '\n' << path.native_file_string() << std::endl; return 0; } Produces /usr/local/bin:/usr/bin:/bin /usr/local/bin:usr/bin:bin under *nix. Regards, Angus

2 1

recursive mutex and condition
by James Ahlborn 15 Sep '04

15 Sep '04

hey, I was wondering if any of the boost developers could tell me if recursive mutexes are supposed to work with conditions? From the code, it would seem to be the case, however in reality things aren't so happy. I have a fairly small test case which shows that the locking doesn't work if you recursively lock a mutex and then try to do a condition wait/notify. I'm testing this on red hat 7.3 and fedora core 2. My guess as to why it's broken is because the boost condition uses posix recursive mutexes internally, which also seem to fail the recursive mutex/condition test (at least on the OS's mentioned above). Anyone have any thoughts on this? I'll include my test case below. The error (for me) happens that when Thread2 releases the "inner" lock, Thread1 proceeds, even though Thread2 should still be holding the lock. (ps- i'm aware that there are some mem leaks in the program, i just simplified it for testing). thanks, -james ------------------------------------------------------- #include <string> #include <iostream.h> #include <boost/thread.hpp> #include <boost/smart_ptr.hpp> #include <boost/bind.hpp> using namespace boost; using namespace boost::detail::thread; class ThreadBase : private boost::noncopyable { public: void start() { m_thread.reset(new boost::thread(boost::bind(&ThreadBase::run, m_weakThis.lock()))); } void join() { m_thread->join(); } protected: virtual void run() = 0; ThreadBase() : m_thread(), m_weakThis() {} virtual ~ThreadBase() {} void initWeakThis(boost::weak_ptr<ThreadBase> weakThis) { m_weakThis = weakThis; } boost::shared_ptr<boost::thread> m_thread; boost::weak_ptr<ThreadBase> m_weakThis; private: }; class Thread2 : public ThreadBase { recursive_mutex* _mutex; condition* _cond; protected: Thread2(recursive_mutex* mutex, condition* cond) : ThreadBase(), _mutex(mutex), _cond(cond) {} public: static shared_ptr<Thread2> create(recursive_mutex* mutex, condition* cond) { shared_ptr<Thread2> tmp(new Thread2(mutex, cond)); tmp->initWeakThis(tmp); return tmp; } virtual ~Thread2() { cerr << "Thread2 dying\n"; } virtual void run() { cerr << "Thread2 acquiring lock(1)\n"; recursive_mutex::scoped_lock sl1(*_mutex); cerr << "Thread2 acquiring lock(2)\n"; { recursive_mutex::scoped_lock sl2(*_mutex); cerr << "Thread2 sleeping...\n"; ::sleep(5); cerr << "Thread2 signalling...\n"; _cond->notify_all(); cerr << "Thread2 releasing lock(2)\n"; } cerr << "Thread2 sleeping (again)...\n"; ::sleep(5); cerr << "Thread2 releasing lock(1)\n"; } }; class Thread1 : public ThreadBase { recursive_mutex _mutex; condition _cond; protected: Thread1() : ThreadBase() {} public: static shared_ptr<Thread1> create() { shared_ptr<Thread1> tmp(new Thread1()); tmp->initWeakThis(tmp); return tmp; } virtual ~Thread1() { cerr << "Thread1 dying\n"; } virtual void run() { cerr << "Thread1 acquiring lock(1)\n"; scoped_lock<recursive_mutex> sl1(_mutex); cerr << "Thread1 acquiring lock(2)\n"; { scoped_lock<recursive_mutex> sl2(_mutex); cerr << "Thread1 starting Thread2\n"; shared_ptr<Thread2> t2 = Thread2::create(&_mutex, &_cond); t2->start(); t2.reset(); cerr << "Thread1 waiting\n"; _cond.wait(sl2); cerr << "Thread1 releasing lock(2)\n"; } cerr << "Thread1 releasing lock(1)\n"; } }; int main(int argc, char** argv) { cerr << "Main Starting...\n"; shared_ptr<Thread1> t1 = Thread1::create(); t1->start(); t1->join(); cerr << "Main First Run\n"; // run it again t1->start(); t1->join(); t1.reset(); cerr << "Main Done\n"; return 0; }

1 0

Re:Re: [boost] Re: mpl apply_if.hpp question
by Robert Ramey 15 Sep '04

15 Sep '04

Aleksey wrote >> But, really, how hard can a global search/replace be? Or is Spirit >> 1.6.1 archived? >No, it's not. Or, to be exact, the latest 1.6.x version which we are >supposed to compile against is not -- >http://article.gmane.org/gmane.comp.parsers.spirit.devel/1964. >I'd _much_ prefer to have this fixed by search & replace, more so because >it'd have to be done eventually sooner or later anyway, if Spirit 1.6.x is >meant to live past this release. I'm agnostic on this - I just want to be able to run the serialization library on all the platforms its designed to run on. If spirit 1.6.x gets fixed to use eval_if - the issue disappears. I don't have the access to fix it and wouldn't do so anyway. I'm afraid to touch it - If I break it then I have to buy it. So, I've checked in apply_if pending fixup in spirit 1.6.x at which point the apply_if can be removed (again). This is just a spirit issue - no changes in the serialization library itself are indicated. Robert Ramey

4 3

Explicit test markup problems
by Vladimir Prus 15 Sep '04

15 Sep '04

Hello, the colors on http://www.meta-comm.com/engineering/boost-regression/developer/program_opt… seems to be incorrect: 1. I've tried to mark all *dll tests on como as failing, but they are still yellow. 2. I never marked vc7 as failing, but still it's deep green (unexpected pass). Any ideas what's wrong? - Volodya

2 1

program_options problem on platforms with incomplete wchar_t
by Harri Pasanen 15 Sep '04

15 Sep '04

Hello, Looking at program_options headers, it does not appear to guard against BOOST_NO_STD_WSTRING being defined? This poses a problem when using gcc on platforms such as Solaris, HP-UX, as functions like std::codecvt<wchar_t, char, __mbstate_t>::do_length(...) are not defined in the libstdc++. Is this a know problem, should I come up with a patch, or what? Regards, Harri Pasanen This message, including any attachments, is intended only for the person(s) to whom it is addressed. If you received it in error, please let us know and delete the message from your system. This message may be confidential and may fall under the duty of non-disclosure. Any use by others than the intended addressee is prohibited. Trema shall not be liable for any damage related to the electronic transmission of this message, such as failure or delay of its delivery, interception or manipulation by third parties, or transmission of viruses or other malicious code. This message, including any attachments, is intended only for the person(s) to whom it is addressed. If you received it in error, please let us know and delete the message from your system. This message may be confidential and may fall under the duty of non-disclosure. Any use by others than the intended addressee is prohibited. Trema shall not be liable for any damage related to the electronic transmission of this message, such as failure or delay of its delivery, interception or manipulation by third parties, or transmission of viruses or other malicious code.

2 1

bjam help...
by John Torjo 15 Sep '04

15 Sep '04

How do I set bjam to print (eventually to a file) all the commands it executes? I'm trying to configure gcc, and I don't know what I do wrong:( Best, John -- John Torjo -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4.0 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

4 4

RE: [boost] Formal review of "Output Formatters" library begins today
by Reece Dunn 14 Sep '04

14 Sep '04

Paul A Bristow wrote: >| [mailto:boost-bounces@lists.boost.org] On Behalf Of Reece Dunn >| > "Boost prefers clarity to curtness". >| >| I have been giving this some thought. What I am looking at at >| the moment is >| something like: >| >| std::pair >| < >| std::pair< int, std::vector< char > >, >| std::list< boost::math::quaternion< float > > >| > mct; > >Which leaves me puzzling what on earth mct can be short for ! >myVeryContrivedContainerType? > >Is this a complex demo assemblage? Yes. It was to give an example of the new (planned) naming scheme to output mct [my_complex_type]. >| namespace io = boost::io; >| namespace fmt = boost::io::format; > >using boost::io::format; > >would allow you to replace fmt with format? Which is much easier to >understand, >especially for those for whom english is not their first language? I would prefer to use a namespace alias where possible as I dislike unnecessarily polluting the global namespace. As to namespace format = boost::io::format; vs namespace fmt = boost::io::format; you can see that these are aliases for "boost::io::format", just like namespace fs = boost::filesystem; As long as it is put at the top of the code examples/tests and put in the documentation introdution at the beginning, clearly stating that "fmt" is a namespace alias for "boost::io::format" I don't see it being a problem. The problem with the current implementation naming scheme is that it uses Xfmt consistently and most importantly, *the user has no control over this*. Feel free in your code to use: namespace format = boost::io::format; or equivalent. Is there a concensus for/against the use of the shorter fmt::basic(), etc. in the docs and code? Dave? John? >Have I commented this correctly (and informatively)? Yes. Although I am not sure of the behaviour of using on a namespace name (don't you need a using namespace or a namespace alias?) >| std::cout << io::object( mct, >| fmt::pair >| ( >| fmt::pair( fmt::basic(), fmt::container()), // basic used for >int, container is a vector. >| fmt::container( fmt::nary()) // container is list, and n in the >nary is 4 for a quaternion. >| ) >| ); > > >| With io::delimiter holding one of the delimiter values. >| io::wrapped_delimiter will replace io::openclose_formatter in holding >open/close delimiter pairs > >why wrappED? io::wrapper? ({} [] ... The io::wrapped_delimiter above is a holder for open and closing pairs, so io::wrapper_delimiter doesn't seem syntactically correct. Maybe io::wrapp*ing*_delimiters? >| and io::sequence_delimiter replaces io::formatter. > >io::separator? , | ... Maybe io::sequence_delimiters. This is because it contains open/close *and* separator delimiters, since it is controlling how a sequence type is rendered. >(Of course, if English spelling made any sense whatever, it would be >separater - but it hasn't got to be the premier language by being phonetic, >consistent and logical, has it?) Causing me a great deal of confusion (even being a native English speaker!) >Paul > >PS >/rubbing_it_in_mode on > >some filenames have the spelling mistake too ;-) >This may confuse some using search later. Doh! >/rubbing_it_in_mode off >and finally > > std::cout << boost::io::formatob( vec ).format( "{ ", " }" ); ><<<<<<<<<<< >isn't this missing a ':' separator??? > // output: { 1 : 2 : 3 } Thorsten spotted this as well. I have updated the docs to: // output: { 1, 2, 3 } Thanks, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

bgl question: in which namespace to put the functions
by Andreas Fabri 14 Sep '04

14 Sep '04

Hello, Developping code so that BGL algorithms can run on the vertices and edges of CGAL triangulations, I am wondering if there are rules or recommendations for in which namespace the functions source, target, vertices, out_edges ... shall go. In boost, because it is boostish code, or in CGAL, because that is the namespace where the triangulation lives in? thank's in advance, andreas

2 1

any interest in Boost Unification and Backtracking library (UBL)?
by G. Wang 14 Sep '04

14 Sep '04

Hi, all, Unification and backtracking are the two key concepts of Prolog language. Prolog language is one of the preferred ways to develop "intelligent" software. I am wondering how many people here are interested in a Boost Unification and Backtracking Library (UBL). UBL will implement the unification and backtracking feature with the help of both preprocessor meta-programming (Boost Preprocessor library) and template meta-programming (MPL). With UBL, you will define Prolog-like predicates right inside your C++ code. ========== Why do we need it? =========================== 1. a C++ and Prolog combined solution may not be convenient. You need to write a lot of wrapper code to allow bi-directional communications between Prolog code and C++ code. Standard Prolog is not an Object Oriented Programming Language. As such, you need to write even more code to allow Prolog to access C++ class instances. Worse yet, each prolog implementation has its own way to interface with foreign languages. So your wrapper code most likely would not be portable to other Prolog implementations. 2. Unlike C++, Prolog is not strong-typed. Folks in the C++ land too long may not like anything that is not strong-typed. 3. C++ is a multi-paradigm language. At beginning, it was procedure oriented. Then it's object oriented. During the past few years, functional oriented programming in C++ and even aspect oriented programming in C++ become hot topics and real possibility. Now why don't we give C++ a logic programming flavor? 4. UBL allows the programmer to switch back and forth among the multi-paradigm seamlessly, therefore make it easier to combine the right features of each paradigm to solve a given problem. Better yet, you do not need to lean a new language (Prolog). =========== Is UBL feasible?=================== The short answer is yes. I already have the prototype up and running in VC++ 7.1. The 8-queen problem takes less than 28 seconds on my Athlon 2200+ to find all answers. The prototype does have its fair share of shortcomings: 1. template based metaprogramming in general, and the prototype of UBL in particular, takes too long to compile any non-trivial code. Or may not be able to compile at all. 2. syntax wise UBL predicates are not as straight-forward or visually appealing as the equivalent predicates in Prolog. Here is a predicate in UBL: BOOST_UBL_PREDICATE_2_( is_grandfather_of, Person, Person ) { BOOST_UBL_VARIABLES_3 ( Person, X , Person, Y , Person, Z ); typedef clause< LHS<X, Y> , is_father_of< X, Z > , is_father_of< Z, Y > > type; }; Here is the equivalent predicates in Prolog: is_grandfather_of(X, Y) :- is_father_of(X, Z), is_father_of( Z, Y). 3. In my plan, the Lambda library will provide the "fast-lane" between UBL and your C++ instances, member functions and member variables. Of course, that is not done yet.

5 6