- Boost - lists.boost.org

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

[aligned_storage] problem for GCC 3.2 and proposed solution
by Joaquín Mª López Muñoz 26 Nov '04

26 Nov '04

The following program: #include <boost/aligned_storage.hpp> struct foo { foo(int x){} private: boost::aligned_storage<sizeof(int)> a; }; int main() { foo f(5); return 0; } fails in GCC 3.2 20020927 with the error: /usr/local/boost_1_32_0/boost/aligned_storage.hpp: In function `int main()': /usr/local/boost_1_32_0/boost/aligned_storage.hpp:75: ` boost::aligned_storage<size_, alignment_>::aligned_storage(const boost::aligned_storage<size_, alignment_>&) [with unsigned int size_ = 4, unsigned int alignment_ = 0ffffffff]' is private Digging into aligned_storage.hpp, I find the following workaround: #if !BOOST_WORKAROUND(__GNUC__, <= 2) private: // noncopyable aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); #else // gcc2.x public: // _should_ be noncopyable, but GCC compiler emits error aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); #endif // gcc2.x workaround So, it seems like the problem was known but incorrectly assumed to affect GCC 2.x only. Anyone objects to extending the workaround to GCC 3.x? It remains to know whether this problem (that seems like an incorrect application of the copy ellision rules) persists in GCC 3.4.x, and in case it is fixed, which last version is for which we should have the workaround. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

date_time from HEAD
by Victor A. Wagner Jr. 26 Nov '04

26 Nov '04

I've gone back to running regression tests from CVS HEAD, but the results don't seem to be displayed anywhere online. I've discovered in compiling my own programs, that there appears to be me a missing #include <boost/shared_ptr> missing from time_clock.hpp (also microsocond_time_clock.hpp?? .. I don't use it so I cannot tell) Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

[patch] Fix for Boost.Test (bad XML format)
by Ferdinand Prantl 26 Nov '04

26 Nov '04

Hello, here we are yet another one fix for Boost.Test. Ending tangs of TestCase and TestSuite were accidentally extended with a dangling attribute value, e.g.: </TestSuite="UnicodeTest"> The fix for supplied_log_formatters.cpp is attached and it's quite clear. Apparently my former fixes did no get into 1.32; they help only HP compiler anyway, and maybe only the version I use. This one is more serious ;-) F. -----Original Message----- From: Ferdinand Prantl Sent: Friday, November 05, 2004 12:35 To: boost(a)lists.boost.org Subject: Compile fix for Boost.Test for aCC on HP-UX Hello, you can find a small fix for boost/test/detail/basic_cstring/basic_cstring.hpp attached and a dirty workaround for a compiler bug in aCC for boost/test/unit_test_suite.hpp. As of the latter; the compiler seems to get confused by equal names in different namespaces and classes; renaming Impl helps or making the previous structure friend helps too (this I chose to minimize the change). Ferda HP-UX B.11.11 U 9000/800 aCC: HP ANSI C++ B3910B A.03.37 <<basic_cstring.hpp.diff>>

1 0

Re: Boost Sandbox layout?
by Rene Rivera 26 Nov '04

26 Nov '04

Any comments on this from the Boost Sandbox admins, or anyone? -------- Original Message -------- Subject: Re: Boost Sandbox layout? Date: Wed, 17 Nov 2004 18:41:58 -0600 David Abrahams wrote: > Rene Rivera <grafik.list(a)redshift-software.com> writes: > >>Was there ever a discussion as to the layout? (A cursory search did >>not reveal anything) > > I like what I _think_ you're suggesting we actually should do, but > would you mind spelling it out for everyone's benefit? I was trying not to prejudice the conversation if there was already reasons for the current layout... But since you ask :-) I think it would more beneficial to have each library in an individual sub directory of the boost-sandbox. Each library would still be required to follow the regular Boost layout within itself. For example I'm putting together the warnings submission and it would be nice to set it up like this: /boost-sandbox/warnings /boost/utility/warnings.hpp /libs/utility /docs/warnings.html /test /Jamfile /nowarn_unused_var_test.cpp Having the isolated subdir would remove the 3 drawbacks I mentioned. But itself has some drawbacks: 1) Some of the setup files would be duplicated. Like the boost.png, Jamfile, Jamrules, and boost-build.jam at the "top" level. But at the same time it means that the library would be truly standalone. 2) An eventual long list of directories right at the top. One advantage is the reduce complexity of management by the library authors. As it would be much easier to do things like remove a library from the sandbox after it's been accepted into Boost, a single recursive cvs remove and commit instead of finding all the files and dirs. It might even be possible to setup some form of script automation to make snapshots of the individual libraries automatically available (without CVS access). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

5 7

[fsm] Adapted to 1.32
by Andreas Huber 25 Nov '04

25 Nov '04

Dear Boosters The fsm submission has been adapted to the 1.32 release. The zip can be found here: http://boost-sandbox.sf.net/fsm.zip The docs are also available online: http://boost-sandbox.sf.net/libs/fsm Feedback is highly welcome! Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

interest in a type_iterator (cast_iterator) ?
by troy d. straszheim 25 Nov '04

25 Nov '04

I'm wondering if there is any interest in a "type_iterator", built on top of the iterator_adaptor. If so I'll send it out. It is a kind of combination of transform_iterator and filter_iterator, where the transform is a cast, and the filter predicate is whether or not each entry in the container passes the cast. This you would want to do when iterating over heterogenous containers (where you are forced to reconstruct type information by downcasting) or containers of boost::any. I was going to call it downcast_iterator but the boost::any stuff isn't a downcast, so I came up with type_iterator. Maybe cast_iterator is better? Generally it looks like this type_iterator<TypeThatIWant, UnderlyingIterator> Here's an example: struct Base { virtual ~Base() {} }; struct Derived : public Base { virtual ~Derived(){}; virtual void OnlyDerivedHasThis(){} }; vector<Base*> v; // love boost::assign v += new Base, new Derived, new Base, ... etc. type_iterator<Derived,vector<Base*>::iterator> iter = make_type_iterator<Derived>(v.begin(), v.end()); while (iter.base() != iter.end()) { (*iter)->OnlyDerivedHasThis(); ++iter; } In order to cooperate with associative containers, containers of shared_ptr's and so forth, the type_iterator maps the type of the underlying iterator (and the cast used) like this: underlying iterator's type_iterator's cast reference_type reference_type ----------------------------------------------------------------------------- Base*& Derived*& dynamic_cast<> shared_ptr<Base>& shared_ptr<Derived>& dynamic_pointer_cast<> any& Derived*& any_cast<> pair<T,Base*>& pair<T,Derived*>& dynamic_cast<> pair<T,shared_ptr<Base> >& pair<T,shared_ptr<Derived> >& dynamic_pointer_cast<> pair<T,any>& pair<T,Derived*>& any_cast<> For instance: type_iterator< Derived, std::map<string,shared_ptr<Base> > > iter; *iter <= returns type pair<string,shared_ptr<Derived> >& I'm sure there are things that need changing, (for instance, should the "any" map to Derived* or just Derived? Should it incorporate the behavior of indirect_iterator and do an extra dereference? Dunno.) I'm just wondering if there is interest before I generalize too far beyond what my client needs. DISCLAIMER: it's widely believed that the need to iterate like this (or the need to downcast at all) indicates a lousy inheritance hierarchy and that in these cases the desire to downcast should be removed via improving the base classes. I hope I don't provoke any lectures on the evils of downcasting: this iterator is not intended to substitute for good class design... cheers, troy d. straszheim

1 0