February 2009 - Boost - lists.preview.boost.org

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

[serialization] Bug with hash_map and Visual Studio 2008
by Raindog 13 Feb '09

13 Feb '09

The following conversation applies to VC9 also. http://thread.gmane.org/gmane.comp.lib.boost.user/12609/focus=12609 I fixed it using the same method suggested there but for the dinkumware.hpp configuration. (IE: Added a #define BOOST_HAS_HASH)

2 1

Re: [boost] [graph] updates
by Andrew Sutton 13 Feb '09

13 Feb '09

> > > Since nearly every algorithm requires a vertex index map in one way or > > another, these may as well be concepts. Also, its a convenient > documentary > > artifact that lets you write, "If your graph is not a *IndexMap, then you > > must provide an index map as an exterior property." > > Ah, interesting. That is helpful. It's part of a plan for generalized graph semantics framework, so we can discuss EdgeWeightedGraphs, NamedVertexGraphs, etc. Or, more specifically what to do when graphs don't model those concepts. > > Documentation for these features is forthcoming. Its part of my project > to > > (finally) migrate the BGL docs over to quickbook. There are tests for > most > > of these features - some are in progress - others are woefully inadequate > > and under development. Since I'm generally pretty busy, these will > probably > > materialize slowly. I'm aiming at 1.40. > > > Quickbook documentation for BGL would be *wonderful*. Perhaps someone > from the Boost Documentation project would like to help out (?). > They already have... somebody wrote an HTML to quickbook program :) I just have to dig out a reference to it. Plus, I have some of the quickbook framework built into the SOC project from 2007. Now if only I can get the toolchain to buil the docs correctly. Andrew Sutton andrew.n.sutton(a)gmail.com

3 3

[1.38.0] regexp compile error on Solaris 10 Sun Studio 11
by Paulo Moura Guedes 13 Feb '09

13 Feb '09

Hi, I had successfully compiled regexp library with boost_1_34_1 but with version boost_1_38_0 I'm getting this error: dmake -f sunpro.mak CC -c -O2 -I../../../ -o sunpro/libboost_regex/cregex.o ../src/cregex.cpp "../../..//boost/regex/v4/basic_regex_parser.hpp", line 379: Error: Could not find a match for std::distance<std::ForwardIterator, std::Distance>(const char*, const char*) needed in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_open_paren(). "../../..//boost/regex/v4/basic_regex_parser.hpp", line 255: Where: While instantiating "boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_open_paren()". "../../..//boost/regex/v4/basic_regex_parser.hpp", line 255: Where: Instantiated from boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_extended(). "../../..//boost/regex/v4/basic_regex_parser.hpp", line 126: Where: Instantiated from boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse(const char*, const char*, unsigned). "../../..//boost/regex/v4/basic_regex.hpp", line 106: Where: Instantiated from boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::do_assign(const char*, const char*, unsigned). "../../..//boost/regex/v4/basic_regex.hpp", line 273: Where: Instantiated from non-template code. "../../..//boost/regex/v4/basic_regex_parser.hpp", line 379: Error: Formal argument x of type const std::pair<unsigned, unsigned>& in call to std::vector<std::pair<unsigned, unsigned> >::push_back(const std::pair<unsigned, unsigned>&) is being passed int. "../../..//boost/regex/v4/basic_regex_parser.hpp", line 255: Where: While instantiating "boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_open_paren()". "../../..//boost/regex/v4/basic_regex_parser.hpp", line 255: Where: Instantiated from boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_extended(). "../../..//boost/regex/v4/basic_regex_parser.hpp", line 126: Where: Instantiated from boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse(const char*, const char*, unsigned). "../../..//boost/regex/v4/basic_regex.hpp", line 106: Where: Instantiated from boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::do_assign(const char*, const char*, unsigned). "../../..//boost/regex/v4/basic_regex.hpp", line 273: Where: Instantiated from non-template code. "../../..//boost/regex/v4/basic_regex_parser.hpp", line 428: Error: Could not find a match for std::distance<std::ForwardIterator, std::Distance>(const char*, const char*) needed in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_open_paren(). "../../..//boost/regex/v4/basic_regex_parser.hpp", line 255: Where: While instantiating "boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_open_paren()". "../../..//boost/regex/v4/basic_regex_parser.hpp", line 255: Where: Instantiated from boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_extended(). "../../..//boost/regex/v4/basic_regex_parser.hpp", line 126: Where: Instantiated from boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse(const char*, const char*, unsigned). "../../..//boost/regex/v4/basic_regex.hpp", line 106: Where: Instantiated from boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::do_assign(const char*, const char*, unsigned). "../../..//boost/regex/v4/basic_regex.hpp", line 273: Where: Instantiated from non-template code. 3 Error(s) detected. *** Error code 3 dmake: Fatal error: Command failed for target `sunpro/libboost_regex/cregex.o' Any help appreciated. Regards, Paulo

3 4

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

13 Feb '09

>> I realy think that freezing this library will have as consequence the freeze of at least these libraries: >> ThreadPool, AsynchronousExecutors, Threader/Joiner (both included for the moment in Interthreads), >> Active Object ... There is nothing keeping these other libraries from using "futures". Nothing is frozen. In fact, most utility libraries are added to boost by slipping them into other boost libraries. There is a certain priviledge to being a top-level boost library. It needs to be reserved for libraries that have received the appropriate amount of peer review. That cleary did not occur here. I agree that if a "review" does not generate enough reviews, than it should be scheduled again, with refined review criteria to attract more reviewers the next time. That is how I am inclined to proceed. Adding concurrent programming libraries to boost without lots and lots of peer review is a mistake. It is an extremely difficult subject. Unless persuaded otherwise, those will be the instructions that I will be giving the "Review Wizards". //Tom

2 1

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

13 Feb '09

>> as Vicente lready ask - what is the result of the future review?! >> @Tom could you confirm that you are still working on the review summary? Yes, i'm still working on it. I've created a test framework that explores issues that I'm concerned about. For the most part, I'm more concerned about the bigger picture and how parralel programming is added to boost. There are many issues that will need to be considered. The story of parralel programming is still evolving and needs the input of many more people who have practical real world experience, particularly about task managment. Of course, you can still comment on how you would like to procceed. Unfortunately, as far as this review goes, I would have liked to see many more comments and reviews.

3 2

[iostreams] container_device
by Dmitry Vinogradov 13 Feb '09

13 Feb '09

I found it will be useful to have container_source/sink/device classes (from libs/iostreams/example/container_device.hpp) right inside the Iostreams library. What do you think about it?

3 2

Re: [boost] Review Request: Introduction of boost::string namespace and string-conversion functions
by a k 13 Feb '09

13 Feb '09

> From the user point the interface I'd like to propose might look like the > following: > > int i; > std::string s; > > 1) int i_from_s = boost::string::to<int>(s); // throws > 2) std::string s_from_i = boost::string::from<int>(i); > 3) bool s_is_i = boost::string::is<int>(i); Do you consider adding an extra parameter for locale, to get rid of dependency on the global one? Regards, &rzej

2 1

[boost.filesystem] unable to autolink with visual c++ 2005-2008
by Sean Farrow 13 Feb '09

13 Feb '09

Hi: With the latest svn revision, I am unable to autolink with visual studio 2005-2008. How canI fix this? Cheers Sean.

2 1

update to 1_38_0: "classic" spirit not working anymore
by Oliver Kullmann 12 Feb '09

12 Feb '09

Hi, with 1_38_0 I can't get any code compiling related to spirit; all that worked with 1_34_1. According to those compiler warnings I'm using now the "classic" versions, but this doesn't help. Consider #include <boost/spirit/include/classic_core.hpp> namespace OKlib { namespace Parser { template <typename CharT = char, typename ParseIterator_ = const CharT*> class ParserBase { public : typedef CharT char_type; typedef ParseIterator_ ParseIterator; typedef boost::spirit::scanner<ParseIterator> scanner_type; This used to work (with boost/spirit/core.hpp), but now I get the error message (gcc version 4.1.2): ParserBase.hpp:27: error: ISO C++ forbids declaration of ‘scanner’ with no type ParserBase.hpp:27: error: typedef name may not be a nested-name-specifier ParserBase.hpp:27: error: expected ‘;’ before ‘<’ token where line 27 is the line where scanner_type is defined. ??? Did the definition of class template scanner change (apparently it now has two parameters)? Oliver

2 2

Boost.Move Where we are with move semantic emulation on C++03 compilers?
by vicente.botet 12 Feb '09

12 Feb '09

Hi, Some weeks ago Howard Hinnant presented on this ML a quite satisfactory emulation of C++0x move semantics. There is also Boost.Move, the adaptation to boost by Daniel James of the Adobe implementation, which was inspired by the move library written by Dave Abrahams and the work on move done by Dave Abrahams and Howard Hinnant. This library is esential to avoid a profusion of move emulation implementation on each library and start to build generics with move semantics. Can we expect to have a proposal for review soon? Thanks, Vicente

6 9

Interest in operator_cast?
by Nick Carroll 12 Feb '09

12 Feb '09

Idea: casting function which invokes an explicitly defined cast operator on a type if defined, else generates a compile-time error. See http://stackoverflow.com/questions/209793/any-way-to-cast-with-class-operat… for discussion of motivation and design. Would there be any interest in incorporating this into boost/cast?

1 0

how to specify options for Boost-building?
by Oliver Kullmann 12 Feb '09

12 Feb '09

Hello, I want to build version 1_38_0, but I can't progress due to missing build-documentation. I need to use bjam (due to special demands on the build), and my platform is Linux. Apparently besides this little bit of information at http://www.boost.org/doc/libs/1_38_0/more/getting_started/unix-variants.html there is nothing available? (Even to get there is not obvious --- you need to click on "microsoft install" first, in order to find a further link to Linux/Unix install?) So well, I invoke "bjam --help": Usage says bjam [options] [properties] [install|stage] where under "properties" we find Properties: toolset=toolset Indicates the toolset to build with. variant=debug|release Select the build variant link=static|shared Whether to build static or shared libraries threading=single|multi Whether to build single or multithreaded binaries runtime-link=static|shared Whether to link to static or shared C and C++ runtime. What's the syntax here?? "--toolset=gcc", as one finds it on that webpage above, or "toolset=gcc", as that information seems to suggest (since for the options the "--" is mentioned)?? Unfortunately, it seems that, different from all other build systems I'm aware of, bjam doesn't print out a summary of what it will be doing. I tried many variations of syntax, but apparently it never worked out. There is an option which is potentially relevant, "--build-type", but again I don't know what are the possible parameters for that --- since there are no examples, I don't know how to read the cryptic listing (syntax-wise). What I need to achieve is simple: 1) I need to specify a locally installed gcc toolset: Past installations suggested to use the options --toolset=gcc-4.1.2 --toolset-root=PATH-TO-LOCAL-INSTALLATION --"-sGCC_ROOT_DIRECTORY=PATH-TO-LOCAL-INSTALLATION" I can't find any information on that topic. 2) I need a local installation of boost; that works out: --prefix=XXX --build-dir=YYY no problem here. 3) No python; this seems also unproblematic (but apparently it vanished from the documentation?) --without-python 4) Only simple names for the built libraries; this seems also to work with --layout=system 5) No multi-threading: Don't know how to achieve this: Somehow "threading=single" seems to be needed here, but I don't know how to specify it (whatever I do, I always end up with libraries with the "mt"-ending). Glad for any help. Oliver

4 7

RFC: interest in Unicode codecs?
by Graham 12 Feb '09

12 Feb '09

Dear Cory, Your UTF standard conversion class looks very interesting. It does however, not give access to the unicode data for grapheme or glyph work. I posted a full unicode character support library at http://www.boostpro.com/vault/ unicode_lib.zip but Rogier and I ran out of time before completing the string class to go with it. If you feel up to it and want to develop a full Unicode support library in addition to your codec, feel free ! Yours, Graham Barnett >Is there interest in having a Unicode codec library submitted to Boost? > >Here is what I have (only tested with GCC 4.3 on Debian, and VC++ 2008): >http://svn.int64.org/viewvc/int64/snips/unicode.hpp > >Right now it is pretty simple to use: > >transcode<utf8, utf16le>(forwarditerator, forwarditeratorend, >outputiterator, traits [, maximum]); >transcode<wchar_encoding, utf32be>(inputrange, outputrange, traits [,maximum]); > >There is also a codecvt facet which supports any-to-any. > >Supports UTF-8, UTF-16, and UTF-32, in little or big endian. Has a >special wchar_encoding that maps to UTF-16 or UTF-32 depending on your >platform. A traits class controls error handling. > >-- >Cory Nelson

1 0

Review Request: Introduction of boost::string namespace and string-conversion functions
by Vladimir.Batov＠wrsa.com.au 12 Feb '09

12 Feb '09

Based on the previous string-conversion-related discussion that revolved around lexical_cast (started with http://lists.boost.org/Archives/boost/2009/01/147013.php) and Dave's suggestion (http://lists.boost.org/Archives/boost/2009/02/147995.php) I would like to propose to create a new boost::string namespace where I'd expect all string-related functionality might be logically housed. Dave already mentioned that "Jeff Garland had a really nice set of proposed extensions to std::string that could live in the same space". My immediate interest/proposal in that namespace would be the string-conversion functionality. The basics of that functionality are currently handled by lexical_cast but need extended and unambiguously tagged as *string*-related conversions. During discussion I've got a strong impression that the majority of people, the lexical_cast author (Kevlin) and the maintainer (Alex) strongly favor leaving lexical_cast as-is and having a fresh start capitalizing on the past experiences. Therefore I'd like to propose the string-conversion functionality that'd be housed inside that mentioned boost::string namespace. This proposal of mine probably is not as conventional as I have no implementation code to show. That is because before committing to it any further (or dragging someone else into it) I would initially like to see if we can agree on 1) creating boost::string (or some other as descriptive name) namespace; 2) the interface for that proposed string-conversion functionality. After that I expect the implementation to be largely a technical issue. >From the user point the interface I'd like to propose might look like the following: int i; std::string s; 1) int i_from_s = boost::string::to<int>(s); // throws 2) std::string s_from_i = boost::string::from<int>(i); 3) bool s_is_i = boost::string::is<int>(i); The above convert a string to an integer (#1), an integer to a string (#2) and check if conversion is possible (#3). #1 and #2 behave like lexical_cast currently does (throw on failure). #3 is a non-throwing check if #1 will succeed (to avoid handling an exception thrown by #1). For example, int i_from_s = boost::string::is<int>(s) ? boost::string::to<int>(s) // safe to request conversion : some-failure-value; I like to/from names as they allow me to read the code as it was merely English -- "string to int", "string from int". I expect string::to() and string:;from() to return a helper object as Dave suggested namespace string { template <class T> struct value { operator T() const; // throws iff parse unsuccessful bool good() const; // true iff parse will succeed ... }; } That'll allow as to make the interface consistent and extendable/chainable: 4) int i_from_s = boost::string::to<int>(s)(-1); The above is a non-throwing variation of #1 with the default value provided for failed conversion. 5) int i_from_s = boost::string::to<int>(s)(std::hex); 6) std::string s_from_i = boost::string::from<int>(i)(std::hex); The above is variations of #1 and #2 with the std::hex manipulator/formatter applied. That "chained" approach would allow to keep the interface consistency without sacrificing the flexibility. For example, 7) int i_from_s = boost::string::to<int>(s)(-1)(std::hex)(yet-another-manipulator); or add some other features when the need arises. Off the cuff the actual conversion might look something along the following lines: template<class T, class Char> boost::string::value::operator T() { std::basic_istringstream<Char> stream(string_); if (manipulators) stream >> manipulator_ >> ... >> value_; else stream >> value_; if (stream.fail()) if (no_default) throw something; else return default_value_; return value_; } Thanks, Vladimir.

12 19

[future] @Tom -> review result?
by k-oli＠gmx.de 12 Feb '09

12 Feb '09

Hello, as Vicente lready ask - what is the result of the future review?! @Tom could you confirm that you are still working on the review summary? Oliver

1 0

Profiling template instantiations
by Steven Watanabe 12 Feb '09

12 Feb '09

AMDG Over the last few days, I've been working on a tool that counts the number of class template instantiations in a translation unit. To use it from a jamfile import profile_templates : : directory of the tool ; template-profile result : some_file.cpp : <include>some_directories ; If everything works, this will create a file with the extension .tp which will contain the number of times each class template was instantiated, with the most common templates at the top. I've put a zip of a rough version in the vault. http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Caveats: I've only tested with Visual C++ 9.0 and gcc 3.4.4 on cygwin so far. Other compilers won't work, yet. Other versions of these compilers may or may not work. It may be necessary to add link=static to the bjam command line. In Christ, Steven Watanabe

6 20