- Boost - lists.boost.org

[IO] Just a little status update.
by Sebastian Redl 28 Sep '07

28 Sep '07

Hi, Some people might remember that I had plans for a new I/O system. Well, today I finished two important milestones, so I thought I'd give a very brief update as to what I was up to. By now, I've designed and implemented: 1) Concepts for reading, writing, mark/reset and tell/seek. 2) Various forms of in-memory sources and sinks, fully tested. 3) Various forms of file sources and sinks, implemented for POSIX and Win32 but as of yet untested. 4) A read-ahead buffer. (Reads a big block and serves further requests out of that.) 5) A chaining system to conveniently build chains out of these components. 6) A type erasure source to hide type complexity. Right now, it is possible to construct a buffered in-memory source (yeah, like that's useful) with this code: source<octet> src( read_mem_unowned(sample_data, sample_size) | buffer<8>() ); This construct a source that reads octets from the memory area at sample_data (which has a size of sample_size units), buffered by an 8-byte read-ahead buffer. The resulting sink uses type erasure to get the short type. Overhead is exactly one virtual call for every operation. If that's too much for you, you can specify the full type of the source: fixed_readahead_buffer_filter<non_owned_mem_source<octet>, 8> If you do that, GCC inlines the entire read operation under -O3 - it all boils down to a few memmoves. (It's a few because buffering in-memory operations only adds overhead without benefit. But whatever.) Conversely, if you wanted to write data, you could do this (not yet implemented): sink<octet> snk( write_mem() | buffer<8>() ); The chaining system is powerful enough to allow the chain stubs to select the appropriate type. The full type of the generated sink is: fixed_write_collect_buffer_filter<mem_sink<octet>, 8> The problem here is getting the data out. I've thought of a system for doing that in such a case, but that's for a separate post. For now, you could just construct the sink separately and then chain it in: mem_sink<octet> data_sink; sink<octet> snk( chain(data_sink) | buffer<8>() ); Now snk holds a reference to data_sink. (So data_sink must stay valid.) And you can get at the sink's underlying vector by calling data_sink.data(). If you don't like the operators, you can use chain() instead: chain(write_mem()).chain(buffer<8>()) Under C++0x, you can get use auto and decltype to get the exact type with less typing with something like this: auto sink_spec(write_mem() | buffer<8>()); decltype(sink_spec)::stream_type snk(sink_spec); Also not implemented, but planned, are text streams. Reading an ISO-8859-1 text file in the finished library would look like this: source< text<utf_8> > src( // A source of UTF-8 text. read_file(filename) | buffer<1024>() | text_decode<utf_8>("ISO-8859-1") ); Things I have to do now: 1) Implement type erasures for sinks and bidi-devices. 2) Make type erasures gracefully handle missing functionality in the underlying devices. That is, if a device can't handle seeking, it shouldn't have to implement no-op or throwing stubs for the seek methods. The erasure should do that. 3) Implement lots more components. 4) Test the file devices. 5) Make writing components easier. Right now, using components is easy, but writing them a bit of a mess due to the chain system. 6) Get started on the text parts. I hope I'll be back soon with more to tell. Sebastian Redl

2 2

Re: [boost] [circular_buffer] Fixes for Tru64/CXX
by Jan Gaspar 28 Sep '07

28 Sep '07

Yes please. Thank you Markus. Jan ----- Original Message ---- From: Markus Schöpflin <markus.schoepflin(a)comsoft.de> To: boost(a)lists.boost.org Sent: Friday, 28 September, 2007 10:14:53 AM Subject: [boost] [circular_buffer] Fixes for Tru64/CXX Hello, attached patch makes the space optimized test pass for this platform. It adds two missing fwd declarations to details.hpp and a workaround to space_optimized.hpp. OK to commit? Markus ___________________________________________________________ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html

2 1

Continuations in C++
by Daniel Gutson 28 Sep '07

28 Sep '07

Hi Boost community, Despite I´m a newby using Boost, I wanted to ask some users about a very old yet useful idea: the continuations. As an experiment, I made an extremely simple example of how a continuation could look like in C++, and now I was wondering either how can Boost and this concept make benefit of each other: in the case of the concept, what´s the best way to implement continuations using boost, and in the case of boost, whether a new library or extension to functional can be extended to support this feature. The design goals I setted are: - avoid usage of stack and recursion - basic design principles (such as Law of Demeter) compliancy - avoid complex iterative functions for implementing iterative algorithms - provide both a standard way of implementing this, and a platform-specific calling convention with compiler hacks - maximize simplicity In order to test the idea, I made a very simple test implementing a classic factorial using continuations. The ´library´ part of my code is: template <class INFO> class Caller { public: typedef void Continuation(Caller<INFO>& caller, INFO& info); private: INFO& info; Continuation* next; public: Caller(Continuation* ini, INFO& init_info) : info(init_info), next(ini) {} void operator()() { while (next != NULL) next(*this, info); } void stop_calling() { next = NULL; } void set_next(Continuation* cont) { next = cont; } }; /////////////////////////// And the factorial example is: //////////// struct Info { int level; int result; }; void fun2(Caller<Info>& caller, Info& info) { if (info.level > 0) { info.result *= info.level; info.level--; } else caller.stop_calling(); } void fun1(Caller<Info>& caller, Info& info) { info.result = 1; info.level = 5; caller.set_next(fun2); } int main() { Info info; Caller<Info> c(fun1, info); c(); cout << info.result << endl; } Now the three questions: - how can this be best implemented using boost? - is this of enough interest so to be an enhancement of functional, or even a new library? - could Boost provide a mix of calling-convention plus library implementation (compiler-specific) so the above example could be even simpler? I can think of some g++ hacks. Thanks, and my apologies if this isn´t the proper place to post this. Sincerely, Daniel Gutson.

3 5

[circular_buffer] Fixes for Tru64/CXX
by Markus Schöpflin 28 Sep '07

28 Sep '07

Hello, attached patch makes the space optimized test pass for this platform. It adds two missing fwd declarations to details.hpp and a workaround to space_optimized.hpp. OK to commit? Markus Index: circular_buffer/space_optimized.hpp =================================================================== --- circular_buffer/space_optimized.hpp (revision 39572) +++ circular_buffer/space_optimized.hpp (working copy) @@ -14,6 +14,7 @@ #endif #include <boost/type_traits/is_same.hpp> +#include <boost/detail/workaround.hpp> namespace boost { @@ -1234,7 +1235,11 @@ ensure_reserve(new_capacity, new_size)); } #if BOOST_CB_ENABLE_DEBUG +# if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(70190006)) + this->invalidate_iterators_except(end()); +# else invalidate_iterators_except(end()); +# endif #endif } @@ -1254,7 +1259,11 @@ circular_buffer<T, Alloc>::set_capacity( ensure_reserve(new_capacity, size())); #if BOOST_CB_ENABLE_DEBUG +# if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(70190006)) + this->invalidate_iterators_except(end()); +# else invalidate_iterators_except(end()); +# endif #endif } Index: circular_buffer/details.hpp =================================================================== --- circular_buffer/details.hpp (revision 39572) +++ circular_buffer/details.hpp (working copy) @@ -24,6 +24,14 @@ template <class Traits> struct nonconst_traits; +template<class ForwardIterator, class Diff, class T, class Alloc> +void uninitialized_fill_n_with_alloc( + ForwardIterator first, Diff n, const T& item, Alloc& alloc); + +template<class InputIterator, class ForwardIterator, class Alloc> +ForwardIterator uninitialized_copy_with_alloc( + InputIterator first, InputIterator last, ForwardIterator dest, Alloc& alloc); + /*! \struct const_traits \brief Defines the data types for a const iterator.

1 0

Re: [boost] Proposal: Polymorphic Value Objects
by Igor.Smirnov＠cern.ch 28 Sep '07

28 Sep '07

Hello, I am trying to respond on the discussion (in the developer's list) on the indicated topic which were in 3-7 Sept. 2007. Not sure my e-mail will go by the right way (because of some technical troubles). But trying... Mathias Gaunard wrote: > Edd Dawson wrote: > > I'm confused. Surely the whole point of shared_ptr is to relieve the > >programmer > > of the burden of worrying when its still used. > The problem is that with large programs you're not able to tell easily > where it is being used. (also, you may create cycles by oversight, but > that could be fixed eventually) > The fact that it is automatically destructed when not used doesn't not > mean that it can't be still used at wrong places, especially after code > refactoring and modifications. > > > How are programs made more deterministic? > Because ownership is fixed to a scope. You thus perfectly know when the > object will be constructed and destructed. > With shared ownership, ownership is fully dynamic, and thus not > determined. These statements (from Mathias Gaunard) are very similar to those which I was trying to popularize in this news group a few years ago and first time even some 5-7 years ago. Though it seemed that I could not convince the majority (in particular that the shared pointers are in general unnecessary). But I am myself still convinced, although admit that shared pointer is acceptable in some rare exclusive circumstances. But, the content of Foo class, which Mathias Gaunard proposed in its first mail, is not clear for me. May be I am behind progress, but I do not know a way to make cloning pointer (or that Mathias' value object, but this seems to be the same in principle) to be non-intrusive. You anyway need virtual cloning function in each class of the hierarchy. I am trying to maintain an Internet page about these things, see http://cern.ch/ismirnov/safetl Regards Igor Smirnov

5 8

Keeping Boost in sync and extending it.
by Michael Marcin 28 Sep '07

28 Sep '07

Hello, I work with Boost on a daily basis and generally I work with svn trunk. I also use some boostified libraries that are not officially accepted into Boost yet. There are also times when I need to make changes to the way a component or library behaves that are not well factored enough to make it in to the official tree but serve their purpose. How do I manage these complications? At present I have a folder named boost which has an external named clean to svn trunk and a folder named patch which mirror's trunk's layout but contains some unofficial boost components from the vault or the sandbox as well as some local modifications but not a full copy of trunk. The first problem comes up while extending BBv2 to handle a new compiler. I must point boost-build.jam to a directory and it will look there for all its files so if I have changes I have to copy the entire boost/tools/build folder into the patch directory tree. Now I'm free to modify it and add files but it will quickly go stale and need to be resynced with trunk. I thought of creating svn patch files, checking those into my local repository and then just applying those patches when I checkout but those cannot handle the addition of files. It also makes it impossible to simply checkout from svn and have things just work which I very much want. I have a similar problem with the open source Adobe libraries which relates back to Boost. I need to patch those libraries to point to my version of Boost not theirs so I don't have 2 versions of Boost floating around in my code. In the past I've just copied the whole repository done my changes locally and hand merged with the latest from the Boost repository when I needed to update. This is tedious and error prone. Does anyone else have this problem? If so, how did you solve it? Thanks, Michael Marcin

4 3

[serialization] export.hpp (or type_info_implementation.hpp) is NOT self-contained and causes compile error
by Sean Huang 27 Sep '07

27 Sep '07

The following code should compile: #include <boost/serialization/export.hpp> class A { }; BOOST_CLASS_EXPORT( A ); instead I got: error C2027: use of undefined type 'boost::serialization::extended_type_info_impl<T>' 1> with 1> [ 1> T=A 1> ] Which file needs to be included to make this compile? Regards, Sean

2 1

compile errors with iterator_facade.hpp
by William SleemanIV 27 Sep '07

27 Sep '07

1 0

'shared mutual exclusion'
by Gottlob Frege 27 Sep '07

27 Sep '07

There was a long discussion about shared_mutex et al, and that was great. I don't want to start it all over again, but I was just wondering about the name: - I agree that 'reader writer', while known, might not be the best basis for a name - 'shared' is part of the answer but - aren't the terms 'shared' and 'mutual exclusion' (as in 'mutex'), well, mutually exclusive? ie somewhat contradicting? also, maybe 'shareable' is better than 'shared'? (other than an argument over whether it should have an 'e' stuck in the middle there or not) so how about: 'sharable_exclusion' (still sounds contradictory?) (sharex?) 'access_controller' - doesn't use known terminology, but is closer to what is really going on - it controls access to a resource. or 'shareable_access'? or ? shared_or_exclusive_access is probably the 'truest' description (and closest to reader_writer, as it does list both 'sides of the coin'), but a bit wordy... Tony

3 2

[intrusive] New source-breaking version uploaded to SVN
by Ion Gaztañaga 27 Sep '07

27 Sep '07

Hi to all, I've uploaded to SVN a new version of Boost.Intrusive that uses the new option specification syntax discussed some time ago in this mailing list: using namespace boost::intrusive; class MyClass : public list_base_hook < void_pointer<offset_ptr<void> > , link_mode<auto_unlink> > { //... }; typedef list<MyClass, constant_time_size<false> > IntrusiveList; The new syntax is more verbose, but easier for common uses: class MyClass : unordered_set_base_hook<> { friend operator==(...); friend hash_value(...); }; //We don't need to specify default hash and equality functors typedef unordered_set<MyClass> MyHashSet; I've uploaded the new documentation here: http://igaztanaga.drivehq.com/intrusive Documentation is still lacking but I think it's fairly adapted to the new syntax. Apart from the new syntax, new features: -> Added stateful value traits. -> Fixed bug in 64 bit platforms (thanks Glenn!). -> Added support for custom bucket traits in unordered containers. -> Added option to use masks instead of modulo operations to determine the bucket number from the hash value (provided bucket length is always power of two). -> Changed all recursive functions from red-black tree algorithms with non-recursive ones (thanks Steven!). Interface change is a big change in the library, so I expect complaints from users. But I think the new syntax is much easier to use, specially as new options are added (unordered containers now receive upt o 7 options!). And the time to do breaking changes is before the library is officially released. Suggestions, improvements and comments are welcome ;-) Regards, Ion P.S.: If users prefer the old syntax, we can go back again to the old way. Just be polite ;-)

3 4