- Boost - lists.boost.org

iostreams stdio_filter motivating example
by christopher diggins 01 Feb '05

01 Feb '05

I may finally have a good motivating example for stdio_filter: Consider the roman_numerals.cpp example from the Boost spirit library at http://tinyurl.com/3qw4k If I make a couple of minor modifications exclusively to the main, such as remove the superflous user prompting and rename it to something legal, i.e.: int RomanNumeralParse() { string str; while (getline(cin, str)) { if (str[0] == 'q' || str[0] == 'Q') break; unsigned n = 0; roman roman_p(n); if (parse(str.c_str(), roman_p).full) { cout << n << endl; } else { cerr << "parsing failure" << endl; return 1; } } return 0; } Using my current version of my filters library (not available online yet) I can now reuse the entire program from another, such as the following: void RomanNumeralParserTest() { stringstream sIn("MCMLXXIV"), sOut; sIn > SimpleMainFilter(RomanNumeralParse) > sOut; int n; sOut >> n; TEST(n == 1974); } Many examples from the Spirit examples, can be refactored in this manner, to become reusable with relatively little effort. I suppose one of the calculators would be even more interesting. Is this a good motivating example for introducing a stdio_filter into boost::iostreams? Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

3 2

Money/Currency uploaded to Sandbox
by Daniel Frey 31 Jan '05

31 Jan '05

Hi, just a quick note that I uploaded the money/currency-stuff to the sandbox files section. I also moved some stuff from the Yahoo-Files and I added two techniques in case someone is interested. The overload_literal_zero-technique is used in the money class, too. You can find the files here: <http://tinyurl.com/6prl6> = <http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di…> The money/currency-framework is seriously cut down. I lacks support for nan/infinity, swap(), etc. - it's just meant as a starter for more discussion, it's main point is to illustrate what I think should be allowed and what shouldn't wrt operators. Example: money / money -> decimal, exception on currency mismatch money / decimal -> money decimal / money -> compile time error Hope someone can make any use of it :o) Regards, Daniel

1 0

More on Serialization Link Issue
by Jared McIntyre 31 Jan '05

31 Jan '05

I'm still trying to track down the serialization link issue I'm having. I've tried using different archivers (text, etc), and the save and load for each _impl isn't in the libboost_serialization.lib. Is there something I need to be doing to force these to be built in my own code (since they are publicly defined in the boost includes), or should the impls be in the library? Jared

2 1

New Logging Library
by John Eddy 31 Jan '05

31 Jan '05

In response to a number of great suggestions and interesting examples, I have made some more changes to the logging library that I would like to make Boost-worthy. I still have some changes to make and am mulling over the way I would like to go about making them. At last posting, I had made a policy of the logging levels and they can now be user specified with my levels being the default (Thanks to Jason Hise for the suggestion). Since then, I have separated the management of a log from the log itself. the log itself is a very simple thing and implements whatever means of storage, display, etc. that it wishes (inspired by the suggestions and mantra example of Preston Elder). A couple examples I have created so far are a simple_log which keeps a list of entries for retrieval (by predicate for example), an ostream_log which immediately writes entries to a supplied ostream, a file_log which immediately writes entries into a file with a specified name. I have created these as examples but I don't see any reason why implementations for just about anything could not be created. I have implemented a callback system for log entries. A boost::function can be mapped to a logging level as a callback in case of an entry at the specified level. For example, this allows a user to catch what they consider to be a "fatal" error and act on it. (Thanks again to Preston Elder for the suggestion). I have implemented a means of converting from levels to string representations of those levels. This must also be carried out by the same policy class that defines the levels. It requires the implementation of a single, simple method in the class accepting a level and an ostream and writing the appropriate text into the ostream. I have implemented a means of customizing the format by which entries are written (Thanks to Preston Elder and Caleb Epstein for the suggestion). Again, it requires a policy class. This class must have a method that accepts an entry and writes it to a supplied stream. Of course, there is a null version for use in the case where you want to have specific logs do all the writing themselves. If you want to have custom formats for the entries, the only possibilities at this point are to log them all anonymously with a completely formatted message and use the text only entry writer or to implement some sort of logic in your logger/writer to distinquish the entries and format them accordingly. I am considering an ostream style message writing functionality as well. Something I plan to do but have not yet done is change from a char specific implementation (Thanks to Preston Elder for the suggestion) to one that's non-char specific. The code in it's current state is available for simple download from www.eng.buffalo.edu/~johneddy. It is not well Boost-ified yet but the directory structure is in place and some example files are available. Everything is implemented in header files at this point so no library need be built. There was a question of thread safety. The library is threadsafe if BOOST_LOGGING_THREADSAFE is defined. It currently depends on date_time and if thread safe, the thread library. Thanks for all your help, John

1 0

Re: shared_ptr inheritance query
by Dave Handley 31 Jan '05

31 Jan '05

Jonathan Wakely wrote: > > http://boost.org/libs/smart_ptr/enable_shared_from_this.html says: > > Requires: > enable_shared_from_this<T> must be an accessible base class of T. I've seen this - but even if I make the inheritance protected, VC++7.1 balks at it complaining that a conversion from the type T to enable_shared_from_this is available but inaccessible. > > Obviously using public inheritance works, but you might also be able to > make it work by making shared_ptr<T> a friend of policy<T> so it can do > the conversion. You'll also need to disable the BOOST_ASSERTs in > enable_shared_from_this.hpp by defining BOOST_DISABLE_ASSERTS or by > copying enable_shared_from_this.hpp and re-implementing the class > without the assertions. I have no idea if this is supposed to work, nor > if it will still work if the internals of shared_ptr or > enable_shared_from_this change. Caveat emptor. > I've tried friendship as you recommend, between shared_ptr<T> and policy<T>, but again without success. Interestingly, I actually get the error from a construction of a standard shared_ptr, without even using shared_from_this. I've gone as far as commenting out every call to shared_from_this in my code. If I inherit from enable_shared_from_this, the compiler complains on construction of a shared_ptr in the detail::sp_enable_shared_from_this line in the code below. If I also comment out enable_shared_from_this, everything compiles okay. template<class Y> explicit shared_ptr(Y * p): px(p), pn(p, checked_deleter<Y>()) // Y must be complete { detail::sp_enable_shared_from_this(p, p, pn); } This is remarkably frustrating, since there are a large number of implementation details in my policy class that I am keen to hide from the API, and the API works fine for all my other policies, it is just the shared_ptr policy that is collapsing. Dave

2 1

custom iterator comparisons (gcc 3.4.2)
by Gennadiy Rozental 31 Jan '05

31 Jan '05

I am getting following error while compiling my test with gcc 3.4.2 on Linux: gcc-C++-action ../../../bin/boost/libs/test/test/ifstream_line_iterator_test.test/gcc-3.4.2 /debug/ifstream_line_iterator_test.o /usr/local/gcc-3.4.2/lib/gcc/i686-pc-linux-gnu/3.4.2/../../../../include/c++ /3.4.2/bits/ios_base.h: In copy constructor `std::basic_ios<char, std::char_traits<char> >::basic_ios(const std::basic_ios<char, std::char_traits<char> >&)': /usr/local/gcc-3.4.2/lib/gcc/i686-pc-linux-gnu/3.4.2/../../../../include/c++ /3.4.2/bits/ios_base.h:738: error: `std::ios_base::ios_base(const std::ios_base&)' is private ../../../libs/test/test/ifstream_line_iterator_test.cpp:28: error: within this context /usr/local/gcc-3.4.2/lib/gcc/i686-pc-linux-gnu/3.4.2/../../../../include/c++ /3.4.2/streambuf: In copy constructor `std::basic_filebuf<char, std::char_traits<char> >::basic_filebuf(const std::basic_filebuf<char, std::char_traits<char> >&)': /usr/local/gcc-3.4.2/lib/gcc/i686-pc-linux-gnu/3.4.2/../../../../include/c++ /3.4.2/streambuf:769: error: `std::basic_streambuf<_CharT, _Traits>::basic_streambuf(const std::basic_streambuf<_CharT, _Traits>&) [with _CharT = char, _Traits = std::char_traits<char>]' is private ../../../libs/test/test/ifstream_line_iterator_test.cpp:28: error: within this context An error occured in line performing comparison: 26: ifstream_line_iterator it( "abc" ); 27: 28: BOOST_CHECK( it != ifstream_line_iterator() ); Looks like compiler end up generating copy constructor. Why did this happend? Is there workaround? Gennadiy

1 0

std::string construction/assignment
by Gennadiy Rozental 31 Jan '05

31 Jan '05

Hi, One of my unit tests is failing because following code throw an exception (gcc 3.2.3 linux): #include <list> #include <string> int main() { std::list<char> l; l.push_back( 'a' ); l.push_back( 'b' ); l.push_back( 'c' ); std::string( l.begin(), l.end() ); return 0; } Does it supposed to work? Is there workarounds? Gennadiy

2 1

shared_ptr inheritance query
by Dave Handley 31 Jan '05

31 Jan '05

I wonder if anyone could help me with a particular problem I'm having with shared_ptr. I'm working on a policy template, and I want the policy template to both privately inherit, and inject enable_shared_from_this - but the 2 things seem to be mutually exclusive. Let me give you an idea of what I'm trying to do (with some gross simplification to make the code a little simpler): template <class T> class policy : public enable_shared_from_this<T> { }; template <class T> class base : private policy<T> { public: shared_ptr<T> get_ptr() { return shared_from_this(); } }; class MyClass : public base<MyClass> { }; test() { shared_ptr<MyClass> obj( new MyClass ); shared_ptr<MyClass> obj1 = obj->get_ptr(); } If you run this you get a "conversion from MyClass* to boost::enable_shared_from_this<T> * exists, but is inaccessible" error (on VC++7.1). The same is true with protected inheritance. Is there any way around this? Thanks Dave Handley

2 1

[Boost.Test] Failure building regression tools.
by Martin Wille 31 Jan '05

31 Jan '05

Hi, I can't build the regression test helper programs anymore: In file included from /boost/head-regression/boost/boost/test/included/prg_exec_monitor.hpp:20, from ../../../tools/regression/compiler_status.cpp:749: /boost/head-regression/boost/boost/test/impl/cpp_main.ipp:59: error: syntax error before `(' token /boost/head-regression/boost/boost/test/impl/cpp_main.ipp:68: error: parse error before `try' /boost/head-regression/boost/boost/test/impl/cpp_main.ipp:75: error: ISO C++ forbids declaration of `result' with no type /boost/head-regression/boost/boost/test/impl/cpp_main.ipp:75: error: redefinition of `int result' Looks like Boost.Test is the culprit. Regards, m

1 0

Re: Fw: [boost] Re: Complex type failure with boost::lexical_cast
by Kevlin Henney 31 Jan '05

31 Jan '05

In message <000c01c506b9$fed670b0$0300000a@pc>, Terje Slettebø <tslettebo(a)broadpark.no> writes >----- Original Message ----- >From: "Preston A. Elder" <prez(a)neuromancy.net> >To: <boost(a)lists.boost.org> >Sent: Sunday, January 30, 2005 4:56 AM >Subject: [boost] Re: Complex type failure with boost::lexical_cast > >I am of the opinion we should follow the standard (ie. STL) in this one. >The STL would accept both, and since we rely on operator>>, so should we. Technically, the _STL_ doesn't do anything about spaces because it doesn't do anything with I/O ;-) However, given that I/O streams handle spaces inconsistently wrt what we think of as the representation of a type, it does not seem the best example to follow -- people prefer something that works consistently. >I mean, if you're going to be anal about spaces, be completely anal about >them, but I don't think we should be, I think accepting whitespace before >and after is correct, just as the stringstream operator>> does by default. And that is where the problems begin. The older versions of lexical_cast had problems because they behaved like the other types that work with I/O streams... but since the other types don't work consistently or sensibly with I/O streams, this causes problems. For example, if we do as the standard does, then lexical_cast will not work when reading a single whitespace character and it will pick out the first space-separated sequence from a string. It is unlikely anyone would consider this desirable. So, if you're going to deal with spaces, deal with them consistently and avoid surprises. And over time this is what lexical_cast has been converging on. This latest bug is one that will be fixed, continuing the trend towards total consumption of the input representation -- we thought we had it, but this corner case was missed and fixing it will improve coverage. Reverting to inconsistent behaviour is not an attractive option. Hope that clarifies the rationale! Kevlin -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

2 1