- Boost - lists.boost.org

Fusion + New Iterator Concepts?
by Brandon Kohn 15 Feb '09

15 Feb '09

Greetings Ladies and Gents, I've been kicking around a problem in which I'm trying to create an access policy interface which specializes compile-time and run-time access to values mapped on an integral index. I.e. something like: value_type access<T>::get<Index>( T t ) value_type access<T>::get( T t, size_t index ) Where access<T> describes a specialized access policy for T. In this context T is a sequence of anything (polymorphic even) that provides a value_type instance. The elements of T may be simple values, a generator() instance, A member function of some type etc. I began implementing an access type to specialize compile-time indexed access which assumes T is a model of the Boost.Fusion RandomAccessSequence which works wonderfully. I then began to write an extension that allows me to define fusion sequences of member functions (which provide the required values.) This is where I seem to have hit a snag. Among the use-cases I would like to support is a case where the value is returned from the provider using pass-by-value semantics. Fusion seems to be built using iterator concepts which essentially expect the underlying types to be able to provide a reference type. Looking further I found a document in the Boost.Iterator library defining "New Iterator Concepts" ( see: http://www.boost.org/doc/libs/1_38_0/libs/iterator/doc/new-iter-concepts.ht… ) . This document seems to define exactly what I need which is the separation of traversal behavior from access behavior. My question (finally!) is whether or not anyone has thought about applying these ideas to Boost.Fusion (or if they are perhaps already supported in some undocumented form?) Cheers, Brandon

2 1

Re: [boost] boost interprocess / shared memory question
by Ion Gaztañaga 15 Feb '09

15 Feb '09

Naveen Santhanam wrote: > Hello, > > We have a windows application (a process) that requires a large data > file (approx. 100 MB) to perform a task. We have a master that launches > several instances of this application. We would like to share the large > data file across the processes such that, there is just one instance of > the data file in physical memory without any disc access. Hence each > application will have a small footprint in memory during execution. We > have tried using a managed shared memory object from the > boost::interprocess library to achieve this. However, this doesn’t help > us as the memory footprint of the application goes up upon access of the > data file. Is there a way to achieve the desired single footprint > memory sharing? Does this work as expected with other OSes? When managed_shared_memory is used (in Windows this is emulated with a temporary memory mapped file). The OS will allocate memory on demand as you access the file, and that memory will be shared across processes: although you see that each process has 100 MB extra memory, the global used memory will grow only 100MB, because those 100MB are shared across processes. If you don't need managed features and just read raw data from a file, you can use file_mapping and mapped_region to map /unmap a concrete memory region and avoid mapping the whole file. But of course, this will require much more manual work. Regards, Ion

1 0

[serialization] export.hpp changes from 1.37 to 1.38
by Chard 14 Feb '09

14 Feb '09

The BOOST_CLASS_EXPORT.. macros have been moved into a detail namespace (1.38) from a (public) anonymous namespace (1.37). I'm guessing that the reasoning for this was in order to avoid many definitions of the class singletons. However, this appears to have enforced that all of the guids (for all archive types) now have to reside in a single compilation unit. The attached code illustrates the limitation; this compiles under 1.37 but results in duplicate symbol definitions in 1.38 (with MSVC7.1). It worked with 1.37 because the anonymous namespace ensured no symbol clashes, but now the symbols are all in the same namespace. The example shows a case where two archive types (xml and binary) might be in use. The obvious solution to this (simple) case would be to just use a single compilation unit, which brings in the guids for both binary and xml. However, turning a blind eye to the 'untidiness', this fix does not help with the project we're working on. In our project, there is not just a simple type being serialized; there are a lot more classes and a bit of mpl thrown in. This actually resulted in breaching the COFF symbol limit (approx. 65k) with MSVC7.1, so we were forced to split the serialization. In fact, we had to split both the save and load parts of the binary serialization. Our current workaround is to use the archive.register_type<...> method, and ignore the export macros, but this does mean ensuring all types are covered (as described in the documentation).

2 3

Re: [boost] RFC: interest in Unicode codecs?
by Graham 14 Feb '09

14 Feb '09

Esben, >I think you have gotten something mixed up. UTF-8 and UTF-32 (aka UCS4) are >just two encodings of the same character set, including the combining you >mentioned (which are really not that uncommon, e.g. m?l?e contains 2 >characters which could be written by combining glyphs. In practical terms, >UTF-32 is somewhat useless. (A case might be made for UTF-16, though) >Kind regards, Esben Having written both basic text editors and Unicode text editors, I can say that if you are going Western Hemisphere then may be more efficient to go UTF-8. If you stick to Unicode Code Page 0 then UTF-16 might be appropriate if you have no formatting bits, but by the time you want to do a full Unicode text editor you end up with [from memory] 21 or 22 bits of the UTF-32 encoding, and the remaining bits for your own formatting info if you need it [font/ colour etc]. With surrogates, you are still [very] slightly encoded in a 32 bit width, but this is a very acceptable trade off for simplicity. In that sense UTF-32 is a misnomer as it does not occupy a full 32 bits, but it is still an encoding ! Yours, Graham

1 0

Re: [boost] Review Request: Introduction of boost::string, namespace and string-conversion functions
by Anders Dalvander 14 Feb '09

14 Feb '09

On Sat, 14 Feb 2009 22:41 +1100 Vladimir Batov wrote: > Yes, 'convert' is well worth considering. It might work both ways as > well. > Like > > string s = boost::string::convert(-1); // to string > int i = boost::string::convert(str); // from string That would be: string s = boost::string::convert(-1); // to string int i = boost::string::convert<int>(str); // from string And with that we're almost back at the interface of boost::lexical_cast once again. Also the user might want to convert between std::wstring and std::string, and in C++0x, std::u8string, std::u16string, and std::u32string. Regards, Anders Dalvander

1 0

Re: [boost] Review Request: Introduction of boost::string namespace, and string-conversion functions
by Anders Dalvander 14 Feb '09

14 Feb '09

On Fri, Feb 13, 2009 at 07:15 +1000, Vladimir Batov <batov(a)people.net.au> wrote: >> 2. The name of the namespace. >> >> People largely seem content with "boost::string". I think that is a pretty bold statement as your proposal for boost::string was initially posted merely 26 hours earlier. Perhaps this library should be bundled with the Boost String Algorithms Library, and reside in the boost::algorithm namespace. >> 3. Naming of the conversion functions. >> >> The "to/from/is" set seems to sit well with the majority of people. I really like the compactness of to/from/is, but something about it feels strange. It feels a bit backward as boost::string::to converts from a string, and boost::string::from converts to a string. Perhaps parse and to_string (or construct). namespace bsa = boost::algorithm; // or boost::string, or boost::convert, or boost::text, or boost. int i_from_s = bsa::parse<int>(s); std::string s_from_i = bsa::to_string<std::string>(i); >> 8. Throw/No-Throw Behavior. >> >> You might have noticed that the interface above *never* throws anything on failure. >> >> template<class T, class String> >> >> boost::string::value<T> >> >> boost::string::to(String const&, T const& =T()) throw(); >> >> template<class T> >> >> boost::string::value<std::string> >> >> boost::string::from(T const&) throw(); I don't think it is a good idea to have the nothrow exception specification on either boost::string::from nor boost::string::to as the underlying mechanism (iostreams I would believe) or copy-construction of T or construction of String could throw exceptions. Nothrow simply cannot be guaranteed. Regards, Anders Dalvander

2 1

Request For a feature - Templated virtual functions
by Gokulakannan Somasundaram 14 Feb '09

14 Feb '09

Hi All, As you all know, there are situations, wherein the virtual function usage can be replaced with templates. But virtual functions can never be used with templates, since all the instantiations have to be tracked to form the virtual function table. But we can ask the user to provide a typelist of classes, that would probably be used with the virtual template function. I think this would solve this issue for most of the cases. Analyzing the instances where this would be useful - a) Any virtual function, which might need different types of arguments (not related to the inheritance hierarchy) b) I have a multi-method design pattern, where in i need more than one run-time resolution through the virtual functions. But sometimes, i might know one of the actual derived classes involved, with which i can avoid one virtual function call. I am not an expert in C++, but one way of achieving this would be to manually have a hash table with all the necessary function pointers for each class in the base class hierarchy and one such set for each of the classes mentioned in the typelist. Waiting for your feedback. Thanks in advance, Gokul.

8 21

[future] @Tom -> review result?
by Tom Brinkman 14 Feb '09

14 Feb '09

>> One last sentence, we should not forget that the interface of the future >> library has already gone through the standard committe. It should work the other way around. Are we going to start picking through libraries that have already been standardized in Cx0 and begin adding them to boost? Not a good idea in my view. The interface is already available. Use it. But why go to the trouble of adding it as a top-level boost library to a library. What is so special about the futures library? Why does Anthony not just slip "futures" it into boost::threads. He maintains that library. Its a non-issue. He doesn't need our approval to do that. Considering the way this review has floundered at this point, that is the best outcome that I can see. If we put it up for review again as top-level boost library, it will need to be fully documented, with samples and test cases. The library has been on the review boards for over a year. Plenty of time for these to have been added. //Tom

6 6

problems with iterator_adaptor after update to 1_38_0
by Oliver Kullmann 13 Feb '09

13 Feb '09

Hello, in the process of updating from 1_34_1 to 1_38_0 I get a lot of compiler errors all related to boost/iterator/iterator_adaptor.hpp; it's quite some time ago that I've written the code, and the compiler messages are cryptic as ever (using gcc version 4.12.0). The error messages all look like /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Boost/1_38_0+4.1.2/include/boost/iterator/iterator_adaptor.hpp:358: error: no match for ‘operator-’ in ‘((const boost::iterator_adaptor<boost::transform_iterator<FunctionHandling::First<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, boost::use_default, boost::use_default>, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, const OKlib::SATCompetition::SuperSeries, boost::use_default, const OKlib::SATCompetition::SuperSeries&, boost::use_default>*)y)->boost::iterator_adaptor<Derived, Base, Value, Traversal, Reference, Difference>::base [with Derived = boost::transform_iterator<FunctionHandling::First<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, boost::use_default, boost::use_default>, Base = std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, Value = const OKlib::SATCompetition::SuperSeries, Traversal = boost::use_default, Reference = const OKlib::SATCompetition::SuperSeries&, Difference = boost::use_default]() - ((const boost::iterator_adaptor<boost::transform_iterator<FunctionHandling::First<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, boost::use_default, boost::use_default>, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, const OKlib::SATCompetition::SuperSeries, boost::use_default, const OKlib::SATCompetition::SuperSeries&, boost::use_default>*)this)->boost::iterator_adaptor<boost::transform_iterator<FunctionHandling::First<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, boost::use_default, boost::use_default>, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, const OKlib::SATCompetition::SuperSeries, boost::use_default, const OKlib::SATCompetition::SuperSeries&, boost::use_default>::m_iterator’ /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_bvector.h:182: note: candidates are: ptrdiff_t std::operator-(const std::_Bit_iterator_base&, const std::_Bit_iterator_base&) I believe there was a discussion on the boost iterator library lately, but I don't think there was a clear outcome. So perhaps somebody, just be seeing this, can guess what the problem could be. It is not yet clear to me where the above error really comes from (some templates and some macros are in the way), but perhaps something doesn't work with the following convenience adaptors: template <class Range> struct RangeFirstConst { typedef typename boost::range_const_iterator<Range>::type iterator; typedef typename IteratorFirst<iterator>::type iterator_first; typedef boost::iterator_range<iterator_first> type; }; template <class Range> struct RangeFirstMutable { typedef typename boost::range_iterator<Range>::type iterator; typedef typename IteratorFirstMutable<iterator>::type iterator_first; typedef boost::iterator_range<iterator_first> type; }; template <class Range> typename RangeFirstConst<Range>::type range_first(const Range& r) { typedef RangeFirstConst<Range> range_first_const; typedef typename range_first_const::type range; typedef typename range_first_const::iterator_first iterator; using boost::begin; using boost::end; return range(iterator(begin(r)), iterator(end(r))); } template <class Range> typename RangeFirstMutable<Range>::type range_first(Range& r) { typedef RangeFirstMutable<Range> range_first_mutable; typedef typename range_first_mutable::type range; typedef typename range_first_mutable::iterator_first iterator; using boost::begin; using boost::end; return range(iterator(begin(r)), iterator(end(r))); } range_first(range) is supposed to take a range over pairs, and return a range of the first components of the pairs. Would be glad about any comments. Oliver

2 1

Happy 100 libraries on Boost
by vicente.botet 13 Feb '09

13 Feb '09

Hi, Every body have remarqued that there are more and more libraries on Boost. Currently 94 lines on the page "boost_1_38_0/libs/libraries.htm#Alphabetically". And there are already 8 accepted and not yet included: * Property Tree Marcin Kalicinski May 20, 2006 * Time Series Eric Niebler August 17, 2007 * Forward (fast-track) Tobias Schwinger December 7, 2007 * Factory (fast-track) Tobias Schwinger December 21, 2007 * Floating Point Utilities Johan Råde Mars 8, 2008 * Thread-Safe Signals Frank Hess November 19, 2008 * Globally Unique Identifier Andy Tompkins November 29, 2008 * Constrained Value Robert Kawulak December 10, 2008 Which one will be the 100? And for which release (1.39 or 1.40)? Independently of which one will be the 100 I think that the Boost community can congratulate himself of his success. The 100 library delivery could be the occasion to celebrate this success on Boost. Any ideas? Best, Vicente _____________________ Vicente Juan Botet Escribá

1 0