- Boost - lists.boost.org

Trac Tasks - by assignee
by Marshall Clow 28 Sep '07

28 Sep '07

[ 23 open tasks today, 22 last week ] If you are maintaining a library, and have not logged into the trac system at <http://svn.boost.org/trac/boost/>, please do so ASAP. Until you do that, no tickets can be assigned to you, and will remain under "None". Instructions on working with tickets can be found at: <http://svn.boost.org/trac/boost/wiki/TicketWorkflow> and a mapping of user names to "real names" can be found at: <http://svn.boost.org/trac/boost/report/16> 16 grafik 7 djowel djowel 1174 Simplified template arg handling djowel 1175 What is punctuation? djowel 1200 Revamp the header information djowel 1245 Make Spirit grammars pass a non-const reference to self djowel 1263 Add include path searching for import & include. djowel 1264 Add option to specify qbk file to use. djowel 1279 Make sure multiple #import of a file imports the file only once. grafik 1040 boost.devel archive at ActiveState disconnected grafik 1088 Docs for template escape feature. grafik 1248 Restructure root/status content. grafik 1249 Restructure root/regression content. grafik 1250 Restructure root/people content. grafik 1251 Implement RSS backend for Quickbook. grafik 1253 Rework root/more/background.html grafik 1254 Rework root/more/bibliography.html grafik 1255 Rework root/more/boost_soc_2006_overview.html grafik 1256 Cleanup root/more/BoostCon* pages. grafik 1257 Cleanup root/more/*.(jpg|gif|png|ico) grafik 1258 Rework root/more/borland_cpp.html grafik 1259 Rework root/more/bugs.htm grafik 1265 Rework tools/regression/xsl_reports/runner/instructions.rst. grafik 93 Testing problems on AIX and OSF grafik 94 Better reporting of failed expectation. -- -- Marshall Marshall Clow Qualcomm, Inc. <mailto:mclow@qualcomm.com> The famous British scientist, Lord Kelvin, said: "When you measure what you are speaking about and express it in numbers, you know something about it, but when you cannot (or do not) measure it, when you cannot (or do not) express it in numbers, then your knowledge is of a meagre and unsatisfactory kind."

1 0

Re: [boost] [Boost-users] Boost test manual can not be accessed
by John Maddock 28 Sep '07

28 Sep '07

Peng Yu wrote: > Hi, > > The following webpage can not be accessed. Can somebody fix it. > http://www.boost.org/libs/test/doc/components/utf/getting_started/index.html Hmm, there's no such file under revision management either, Gennadiy do you know what the issue is here? John.

1 0

[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