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

BOOST_NO_SFINAE not in docs
by Robert Ramey 27 Nov '04

27 Nov '04

in looking through some of the compiler config files, I find BOOST_NO_SFINAE. However, I don't find this in the config documentation. Is there a reason why it shouldn't be there? Robert Ramey

2 1

Re: [ANN] Phoenix-2 Preview
by Joel 27 Nov '04

27 Nov '04

Zhuo Qiang wrote: > > what about _a = var(arg1) which IMO is more explicit I considered that syntax too. Unecessarily verbose, IMO. The argN (like var(x)) already has reference semantics. That is why you can write: ++arg1 for example, instead of the more verbose: ++var(arg1). IMO, argN should always be implicitly an L-value, for consistency. >>>though the following code gives what I expect: >>> int i = 1; >>> >>> let(_a = val(_1)) >>> [ >>> cout << --_a << ' ' >>> ](i); >>> cout << i << endl; >> >>Exactly! args are L-values. vals are R-values. >> >>I'll emphasize that in the docs. Mind if I steal your example? > > > Sure! As you wish. Done :-) Thanks! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 0

Re: [ANN] Phoenix-2 Preview
by Joel 27 Nov '04

27 Nov '04

Zhuo Qiang wrote: > I've just tried it and there's a question: > > int i = 1; > > let(_a = _1) > [ > cout << --_a << ' ' > ](i); > cout << i << endl; > > the output of above is : 0 0 > and I expected it to be "0 1" > seems _a hold a "reference" to _1 which in turn is just a reference of i.Is > it right? > I thought _a = _1 had some value semantic. That's right. That's the correct behavior. As noted in the docs: The type of the local variable assumes the type of the lambda-expression. Type deduction is reference preserving. For example: let(_a = arg1, _b = 456) _a assumes the type of arg1: a reference to an argument, while _b has type int. This is necessary because otherwise, we won't have l-value access to outer lambda-scopes. > though the following code gives what I expect: > int i = 1; > > let(_a = val(_1)) > [ > cout << --_a << ' ' > ](i); > cout << i << endl; Exactly! args are L-values. vals are R-values. I'll emphasize that in the docs. Mind if I steal your example? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 0

Re: [boost] Alternate Boost Logo
by Beman Dawes 27 Nov '04

27 Nov '04

At 08:03 PM 11/26/2004, Reid Sweatman wrote: >This time with the file actually attached. <g> It was a long, drunken >weekend... I guess I'm just a person who thinks in terms of words rather than images. As images go your suggestion is fine, but I like the ones that have the word "Boost" in them. At least for some of the logos posted so far, I usually like "C++" being there too. --Beman

1 0

Alternate Boost Logo
by Reid Sweatman 27 Nov '04

27 Nov '04

> -----Original Message----- > From: Reid Sweatman [mailto:drunkardswalk@earthlink.net] > Sent: Wednesday, November 24, 2004 2:33 PM > To: 'boost(a)lists.boost.org' > Subject: RE: [boost] Re: Logo... and page design. <all snipped> This time with the file actually attached. <g> It was a long, drunken weekend... Just curious, and my feelings aren't hurt or anything, but did everyone really consider my idea so worthless as not to merit the time to dump on it? <g> Reattached in it's original, fine-minute quickie form here, in case the message is gone. Incidentally, my quick take on the ones I was able to view: the rocket ones were mostly really well done, but mostly way over-busy, as well. There was one that was sufficiently close to mine that they could likely be combined; might try that tonight. The Text ones were okay, but lifeless. The square braces didn't work for me, mostly, save for perhaps the one that formed a split-C (and someone had to point that out to me before I realized that was what it was). Reid

1 0

CW version 0x3004?
by Stefan Slapeta 26 Nov '04

26 Nov '04

Has anyone ever seen CW defining the version to 0x3004? Seems it's not handled by boost.config at the moment and boost.bind doesn't compile, either. Stefan

2 2

Re: [boost] Re: Boost Sandbox layout?
by Roland Schwarz 26 Nov '04

26 Nov '04

Michael Walter wrote: >Hm yeah I know of these, I thought those more resembled hard links. Hmm. > > > I would say: neither nor. They are implemented at the filesystem driver, so they are similar to an hardlink, but they can span devices, so they are similar to a symlink. Also you can only link directories, and not files. Roland

3 3

[named_params] Metafunction for extracting parameter types.
by Cromwell Enage 26 Nov '04

26 Nov '04

In the course of refactoring my multi-state mazes library to use Boost.NamedParams, I discovered that I couldn't create a default predecessor map without the proper vertex type, and I couldn't get that type without knowing the type of the input graph. So I went ahead and created a metafunction called find_named_param that helped me to accomplish this task. For example, you have the following tag types for your key words: struct input_graph_t; struct input_index_map_t; ... Then in your function, you can extract your types like so: typedef typename find_named_param< Params , input_graph_t >::type InputGraph; typedef typename find_named_param< Params , input_index_map_t , property_map< InputGraph , vertex_index_t > >::type InputIndexMap; Thus, given the following keywords: keyword<input_graph_t> input_graph; keyword<input_index_map_t> input_index_map; Assignment becomes less tedious: InputGraph& in_g = p[input_graph]; InputIndexMap index_map = p[ input_index_map | get(vertex_index_t(), in_g) ]; The third template parameter in find_named_param is the type whose member typedef ::type will be returned if the named parameter is unspecified. Of course, leaving this template parameter unspecified will result in a compile-time error if the function requires the named parameter. The corresponding argument type should be the same as (or assignment-compatible with) the type of the default value of the named parameter. The changes made to <boost/named_params.hpp>, in addition to effectively removing the dependency on BOOST_MPL_LIMIT_METAFUNCTION_ARITY, now include moving typedef H head_type; typedef T tail_type; out of the conditional macro body while remaining in detail::list, and adding the necessary functionality to make find_named_param work. I wouldn't call it sufficiently tested; however, the attached program works under MinGW (GCC 3.2) and MSVC 7.1. Happy Thanksgiving! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

Website MPL Docs.
by Thomas Witt 26 Nov '04

26 Nov '04

Maybe I am just going nuts but the mpl doc links on the website seem to be broken. http://www.boost.org/libs/libraries.htm contains a link to: http://www.boost.org/libs/mpl/doc/index.html This document seems to be outdated and all the links in this document seem to be broken. The following url seems to point to the current docs http://www.boost.org/libs/mpl/doc I am lost Thomas -- Thomas Witt witt(a)acm.org

1 0

Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 26 Nov '04

26 Nov '04

I wrote a prog that spawns threads (RED HAT Fedora Core 2), and after spawning 283 or so threads, it stops running and 'Aborted' is printed. It doesn't matter if I spawn them one after each other, or only 10 at a time, or if the threads only last 1 second or if they all stick around until the 283rd thread is spawned. Every combination I've tried results in the prog aborting at about the 283rd thread spawn. Does this sound familiar to anybody? Is there something my thread must do to properly shut itself down? Does it need to call some kind of procedure to announce it is going away for proper cleanup? I couldn't see anything in the examples like that. And is there documentation explaining the examples? I failed to find any. My thread procedure: void updatethread(void* inparams) { thread_params *tparam; tparam=(thread_params *)inparams; int local_threadid = tparam->param1; std::string DID = tparam->param2; { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread:" << local_threadid << " running. " "UPDATE for " << DID << std::endl; } // wait some secs (just for debug, remove when real work is being done) boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 2; boost::thread::sleep(xt); { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread:" << local_threadid << " Exiting. " << std::endl; } { boost::mutex::scoped_lock scoped_lock(numthreads_mutex); --activethreads; } } MAIN calls it with this: //spawn thread tparam.param1=threadid; tparam.param2=dids[i]; boost::thread *pt; pt = thrds.create_thread(thread_adapter(&updatethread, (void*)&tparam)); Thanks, Tim

3 2