- Boost - lists.boost.org

nvcc cuda patch
by Andrey Asadchev 16 Jun '10

16 Jun '10

hello here is a small patch to make boost mpl libraries usable with cuda nvcc compiler. http://code.google.com/p/asadchev/source/browse/trunk/work/cuda/boost-cuda.…

2 1

Re: [boost] [Boost-commit] svn:boost r62919 - in trunk: boost/filesystem/v2 boost/filesystem/v3 libs/filesystem/v2/test libs/filesystem/v3/test
by Scott McMurray 16 Jun '10

16 Jun '10

On 13 June 2010 10:33, <bdawes(a)acm.org> wrote: > Author: bemandawes > Date: 2010-06-13 13:33:39 EDT (Sun, 13 Jun 2010) > New Revision: 62919 > URL: http://svn.boost.org/trac/boost/changeset/62919 > > [...] > > @@ -620,7 +620,7 @@ > basic_path< String, Traits > & ph ) > { > String str; > - is >> str; > + std::getline(is, str); // See ticket 3863 > ph = str; > return is; > } > I'm not convinced this is the right approach here, since cout << mypath << ' ' << myint; doesn't roundtrip with cin >> mypath >> myint; the way I expect operator<< and operator>> to work. Perhaps the portable pathname grammar could be extended to allow backslash-escaping of spaces and backslashes? That or remove the stream operators entirely and force people to choose which way they want to print the path and deal with the result as a fully-general string.

6 14

[log] auto_flush not flushing?
by Michael Caisse 15 Jun '10

15 Jun '10

I'm running on Vista and compiled with VC8. I have initialized the backend like this: ----------------------- typedef sinks::synchronous_sink< sinks::text_file_backend > sink_type; boost::shared_ptr< sink_type > sink = boost::make_shared< sink_type >( keywords::file_name = "%Y%m%d_%H%M%S_%5N.log", keywords::open_mode = (std::ios::out | std::ios::app), keywords::auto_flush = true, keywords::rotation_size = rotate_size // rotation size, in characters ); if( target_directory.empty() ) { target_directory = suggest_target_directory(); } // Set up where the rotated files will be stored sink->locked_backend()->set_file_collector( sinks::file::make_collector( keywords::target = target_directory, // where to store rotated files keywords::max_size = max_stored_size, // maximum total size of the stored files, in bytes keywords::min_free_space = min_free_space // minimum free space on the drive, in bytes )); sink->locked_backend()->auto_flush(true); // Upon restart, scan the target directory for files matching the file_name pattern sink->locked_backend()->scan_for_files(); typedef aux::add_common_attributes_constants< char > traits_t; sink->locked_backend()->set_formatter( formatters::stream << formatters::attr< unsigned int >(traits_t::line_id_attr_name()) << " [" << formatters::date_time< boost::posix_time::ptime >(traits_t::time_stamp_attr_name()) << "] [" << formatters::attr< attributes::current_thread_id::held_type >(traits_t::thread_id_attr_name()) << "] [" << formatters::attr< severity_level >(sources::aux::severity_attribute_name< char >::get()) << "] " << formatters::message< char >() ); core::get()->add_sink(sink); --------- Notice I have also added a call to auto_flush (for good measure with the keyword didn't work (o; ) What happens is that the log file shows up after the program exits. Since I was hoping to tail the file for some debug ... that isn't very convenient. Ideas of what I have done wrong? TIA michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 9

[log] Can Boost.Log be used in clean-up functions?
by Andrzej Krzemienski 15 Jun '10

15 Jun '10

Hi, By 'clean-up functions' I mean destructors or automatic objects, destructors of static objects, functions registered with std::atexit and std::terminate. So, what I want to ask is: Can I use Boost.Log for logging inside destructors of automatic objects? Destructors are exected not to throw by STL containers and algorithms, also it is often taught that a destructor throwing during stack unwinding ... Can the logging throw an exception? I guess it cn, and I guess, it my be unsafe to log in the destructor. Am I right? Can I use Boost.Log in functions that are run after function main finishes? I.e. can I safely log in destructors of static objects, or functions registered with std::atexit? Similarly, can I log in the std::terminate (if I have installed my custom handler)? When are log sources or sinks destroyed? Regards, &rzej

2 1

[xint] Fifth release -- one more round of reviews, please
by Chad Nelson 15 Jun '10

15 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One more time... the next iteration of the Extended Integer library (a arbitrary-length integer math library) is now available in the sandbox (at <https://svn.boost.org/svn/boost/sandbox/xint>) and the Vault (at <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z…>). It incorporates almost all of the suggestions offered on this list. The changes between this release and the last one are: * All three types (integer, nothrow_integer, and fixed_integer) have now been consolidated into a single template, using Boost.Parameter for the options. This release, like the last one, includes a slightly older version of Ion Gaztañaga's preliminary Move library too. I haven't tested it with the current version, but it should work with that as well. The Move library is not used by default, and makes only a slight difference to the speed when thread-safety is enabled. Still on my immediate to-do list: * Add an "unsigned" option, so that the mod operation will work as expected. * Add support for GCC's -fno-exceptions option. * Add more examples. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwTu5sACgkQp9x9jeZ9/wS2AQCfekF0zJW4TjDUhFNP/Cts6ZLC xXkAoNOchGNvIbJcimXnYo3PrSIF68or =4Knn -----END PGP SIGNATURE-----

2 7

Re: [boost] [Boost.Assign] list_of::range without an initial (single) element?
by Thorsten Ottosen 15 Jun '10

15 Jun '10

er skrev: > Michael McNeil Forbes wrote: >> What is the recommended way of initializing an array from a >> concatenation of other arrays? >> >> list_of::range looks right and I would like to use something like: >> >> array<int, 2> a = { 1, 2 }; >> array<int, 2> b = { 3, 4 }; >> array<int, 4> c = list_of<int>().range(a).range(b); >> >> However, list_of<int>() inserts a default value (so that >> list_of<int>().range(a).range(b) == {0,1,2,3,4}). Maybe we should add empty_list_of<int>() ? It's quite trivial to add. -Thorsten

1 0

[msm] Message queue and copy constructed events
by Christophe Henry 15 Jun '10

15 Jun '10

Hi Michael, >in case we use message queueing in our state machines (which we actually >have to because otherwise the pseudo exit state behaviour will not work >correctly) our events have to implement a copy constructor because there >is a possibility that some of them are queued. Actually for the pseudo exit states it's also so that the event from the outgoing transition can be convertible from the event coming from the inner transition. >We do not want that events >get copied because they are very big and it certainly decreases our >performance. >Could you not just store pointers to events so that the events do not get >copy constructed again? >Our understanding of the queuing implementation is that the event instance >is valid as long as the outer most process_event() is not returned to the >caller. In that case it is not a problem to just store those pointers. I suppose you are still talking about the pseudo exit states. It's not that simple because queuing can happen surprisingly fast. One could decide to defer inside the action method of the transition exiting the pseudo exit. It's a corner case, but I can imagine someone will one day find a use of it, like for about every single feature I put inside msm. >We also could use shared pointers as events and so only the shared >pointers get copy constructed. But this would mean that we have to put all >our events into shared pointers which also decreases performance and it >would look like strange passing shared pointer as reference to the >process_event() method. > >Do you have another idea in order to overcome this? Why not simply pimpl the big data from the event inside a shared_ptr as event's attribute? Or more efficiently, as I understand your data is useful only until the end of a process_event, keep a pointer to it, for example something like: { Data data; fsm.process_event(my_event(&data)); } // data is gone here >At the moment, we can not think of a proper solution for deferred events. >In that case there would be no other solution than copy deferred events. I'd prefer to avoid confusing users by using different behaviors, especially as the above solution seems pretty simple to implement. >Anyway, we would like to have a mechanism in order to influence the queue >implentation and change it to a user definied implementation. >Would it be possible to pass the queue type as an optional template >argument to the state machine? >This would the make state machine even more flexible and one does not have >to use std::queue. I'm thinking about this because someone requested the possibility of using no heap at all and providing a fixed-size array instead. It seems a reasonable request. Regards, Christophe

2 1

[Proto] Computing type in expression
by joel falcou 15 Jun '10

15 Jun '10

I have an expression wrapper class tied to a domain and a grammar. Everythign works ok except for the fact it seems I can't compute type inside the expression class that depends on the expression type itself. I end up with tons of incomplete type error in proto/fusion.hpp. The example is a bit big, i'm still working on a small repro but basically, what I do is using the expression framework from ym last mail is to have a value_type on expression which represent the value_type of the expression element. Regards

2 4

[proto] small breaking change
by Eric Niebler 15 Jun '10

15 Jun '10

I just made a change to proto in the effort to reduce compile times. There's a new expression type, proto::basic_expr, that is lighter weight than proto::expr in that it doesn't define the operator=, operator[] and operator() member functions. It's ideal as a base when extending expressions with proto::extends or BOOST_PROTO_EXTENDS. You'll get basic_expr instead of expr automatically if you use either of proto::generator or proto::pod_generator. That could surprise you if you were expecting to get an expr, so beware. Most normal uses of Proto will just work with this change, though, and if you measure you should see a modest improvement in your compile times. Please let me know if this breaks your code. -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 22

[trac] more spam
by Steven Watanabe 15 Jun '10

15 Jun '10

AMDG Here: https://svn.boost.org/trac/boost/ticket/1633 In Christ, Steven Watanabe

2 1