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

[date_time] Trouble with operator+ and microsec(BIG_NUMBER)
by Christoph Mathys 19 Feb '09

19 Feb '09

Hello I'm using date_time on a 32b Ubuntu machine (1.36, gcc 4.2.4). The following code shows the problem (at least on my machine): (compiled with -O2 -Wall, without warnings) #include <iostream> #include <boost/date_time/posix_time/posix_time.hpp> #include <boost/date_time/gregorian/gregorian_types.hpp> using namespace std; namespace bpt = boost::posix_time; int main(int, char**) { const int64_t timeInNs = 1235051546649264674LL; const bpt::ptime EPOCH(boost::gregorian::date(1970, 1, 1)); bpt::ptime offset = EPOCH + bpt::microsec(timeInNs / 1000); cout << offset << std::endl; return 0; } I expect this program to print a date after 1.Jan 1970. However, I get the following output: 1969-Dec-21 19:28:13.710725 If I change timeInNs to 1235051546649264LL (I removed the last 3 digits), the date is after 1.1.1970. Whats wrong? Christoph

1 0

[log] Review-ready version in the Vault
by Andrey Semashev 19 Feb '09

19 Feb '09

After a long time of documenting, polishing and testing I'm glad to announce that Boost.Log has reached the level where public review request can be submitted. The automatic tests aren't entirely complete, however, the basic functionality is covered and most of what is not covered has been tried by hand. Major changes since my last publicly announced version: * Substantial documentation improvement. * Added several Windows-specific sinks: Event Log (simplified and advanced), Windows debugger and experimental Event Trace for Windows Vista and later. * Loggers now consist of a number of independent features that can be composed the way the user needs. User-defined features can be developed and injected into the mix. * Attribute value extractors improved. With the new extract function attribute values can be extracted from the attribute values view by employing lambda functors. * Some files and classes were moved or renamed to improve code clarity and shorten names. * A number of bugs fixed. * Added tests. The archive with the library source code, tests and docs is available in the Vault: http://tinyurl.com/cm9lum The online docs are also available on the SourceForge page: http://boost-log.sourceforge.net The latest code snapshot can be downloaded from CVS on the SourceForge project page: http://sourceforge.net/projects/boost-log The code should be compatible with Boost 1.38. Might also work with 1.37, but I didn't try. Comments are welcome.

15 69

Proposal: Post-Release Maintenance Team (WAS Re: [test] [gcc-4.3.2] check_is_close and check_is_small issues)
by Dean Michael Berris 19 Feb '09

19 Feb '09

On Thu, Feb 19, 2009 at 3:58 PM, Juergen Hunold <juergen.hunold(a)ivembh.de> wrote: > Hi Dean ! > > On Thursday 19 February 2009 02:34:05 Dean Michael Berris wrote: > >> Thanks for these links! Did they apply cleanly to Boost 1.38.0 for >> you? I tried both (in the given order above) and I got some rejections >> when I applied them to a cleanly unpacked distribution. > > Well, actually not ;-(( > I think you can safely ignore the patch to utils/runtime/cla/parameter.hpp as > this just fixes a regression which happened in between the changes. > I'll dig further into this and ask the maintainer for permission to merge at > least the warning fixes to the release branch. > Alright. Now this time, would there be any objections if I (or other people) tried managing a patch release for 1.38.0? Would anybody else be interested in helping release a 1.38.1 with fixes hand-ported from trunk to 1.38.0? I've found some Jamfile fixes required to work around the (I'm guessing, now defunct) 'message' function in Boost.Build v2 that's bundled with Boost 1.38 that might be worth looking at. I'm also interested in bringing in a newer version of Boost.Build from the nightly builds into the 1.38.0 release to be packaged as 1.38.1; HTH -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

2 3

[Serialization] BOOST_CLASS_EXPORT regression on SunCC
by Sohail Somani 19 Feb '09

19 Feb '09

>From version 1.34 to 1.35, the export of classes was modified so that all the archives did not need to be included before calls to BOOST_CLASS_EXPORT. I don't know why this was a problem to begin with. Anyway, this feature used to work on SunCC but with the new changes, there is a regression. This is caused by the dependence on ADL to instantiate the ptr_serialization_support members: SunCC just doesn't do it. So the instantiations never occur and you get an assertion failure when running the serialization tests under debug: Assertion failed: it != boost::serialization::singleton< oserializer_map<Archive> >::get_const_instance().end(), file vendor/boost_1_37_0/boost/archive/impl/archive_pointer_oseri\ alizer.ipp, line 64 I know how to fix it (instantiating manually for each Archive,Serializable pair, not a huge problem). I would suggest that Boost Serialization should have a fallback mechanism for these compilers. Perhaps along the lines of the old export functionality where the user would define the archives they are interested in. Thoughts?

5 32

Architecture Analysis of the boost libraries, e.g. spirit
by Bernhard Merkle 18 Feb '09

18 Feb '09

Hi boost developers, I have a question regarding the architecture of boost libraries. First some (short) background info: I have done some architectural analysis in the past for C++, C and Java projects. It is a static toolbased analysis approach and essentially it enables you to compare the "should"-architecture with the "is"-architecture. Nearly all projects suffer from some architectural decay over time (e.g. unwanted dependencies etc.) So I was interested how well those tools for architectural analysis cope with C++ template code and boost is an ideal candidate. :-) I have already successfully analyzed the boost spirit library. The architecture for spirit is documented under http://www.boost.org/doc/libs/1_38_0/libs/spirit/classic/doc/organization.h… and if that is still the "should"-architecture then i was already able to find some deviations/violations in the "is"-architecture. So my question: should all modules of Core (scanner, primitives, composite, non_terminal) be independent of each other ? other questions: - are there architectural documents for the other libraries ? - which would be good candidates from your point of view ? (I think e.g. analyzing dependencies to the mpl libs is interesting) - is there a common rule which parts are public and which are private ? (I saw some impl directories but am a bit unsure about the API stuff) - is there a document describing the dependencies between the different libs (the "should" architecture). (I know of the bcp tool but this documents the "is"architecture essentially) sorry for the long post, but I think this is really interesting stuff and I am open to contribute in the architectural area :-) kind regards, Berni.

1 0

Re: [boost] Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 18 Feb '09

18 Feb '09

Upgraded to the version 0.10. Added boost::string::is_string<T> SFINAE-based check. That allowed to discriminate the applicability of conversion functions. Now they demand one of the parameters to be a string (in broad sense, like C strings, std::(w)string, chat/wchar_t-based containers) and the other *not* a string. Have straighten up the main boost::string::convert() interface (was quite broken) so that all the tests now run as expected. g++ 4.2.4 (Linux) and Visual Studio 2008 are happy. Thanks, Vladimir.

4 6

[future|interprocess] Could futures live in shared memory and synchronize process?
by vicente.botet 18 Feb '09

18 Feb '09

Hi, I'm working on Boost.Synchro a synchronization library that try to provide generic synchronization mechanism that can be used so synchronize threads or process. As a future is a synchronization mechanism, I was wondering if futures are intrisic of mutil-threaded programs and so they live in the protected process memory or if the concept can be used in a multi-process context and have futures/promises living on shared memory. Ion, what do you think, could it be possible to use futures/promises to synchronize process? Have some one a specific use case for this? Best regards, _____________________ Vicente Juan Botet Escribá

3 5

[alogrithm] compile error with VS2008 in debug build (boost 1.38)
by Hansi 18 Feb '09

18 Feb '09

Hello, I have a strange problem. When I make a debug build from my program which uses minmax_element I get the following compile error: 1>c:\program files\microsoft visual studio 9.0\vc\include\utility(57) : error C2664: 'std::_Vector_iterator<_Ty,_Alloc>::_Vector_iterator(const std::_Vector_iterator<_Ty,_Alloc> &)' : cannot convert parameter 1 from 'int *const ' to 'const std::_Vector_iterator<_Ty,_Alloc> &' 1> with 1> [ 1> _Ty=int, 1> _Alloc=std::allocator<int> 1> ] 1> Reason: cannot convert from 'int *const ' to 'const std::_Vector_iterator<_Ty,_Alloc>' 1> with 1> [ 1> _Ty=int, 1> _Alloc=std::allocator<int> 1> ] 1> No constructor could take the source type, or constructor overload resolution was ambiguous 1> d:\projects\sandbox\boosttests\statistic\statistic.cpp(43) : see reference to function template instantiation 'std::pair<_Ty1,_Ty2>::pair<int*,int*>(const std::pair<int *,int *> &)' being compiled 1> with 1> [ 1> _Ty1=std::_Vector_iterator<int,std::allocator<int>>, 1> _Ty2=std::_Vector_iterator<int,std::allocator<int>> 1> ] 1>c:\program files\microsoft visual studio 9.0\vc\include\utility(57) : error C2664: 'std::_Vector_iterator<_Ty,_Alloc>::_Vector_iterator(const std::_Vector_iterator<_Ty,_Alloc> &)' : cannot convert parameter 1 from 'int *const ' to 'const std::_Vector_iterator<_Ty,_Alloc> &' 1> with 1> [ 1> _Ty=int, 1> _Alloc=std::allocator<int> 1> ] 1> Reason: cannot convert from 'int *const ' to 'const std::_Vector_iterator<_Ty,_Alloc>' 1> with 1> [ 1> _Ty=int, 1> _Alloc=std::allocator<int> 1> ] 1> No constructor could take the source type, or constructor overload resolution was ambiguous Is this a know issue. Is something wrong in my program? Best regards Hansjörg #include <algorithm> #include <vector> #include <iostream> #include <boost/algorithm/minmax_element.hpp> #include <boost/array.hpp> #include <boost/timer.hpp> using namespace boost; using namespace std; typedef array<int,100000000> dataarray; void do_tests(dataarray& data) { { timer t; std::pair< std::vector<int>::iterator, std::vector<int>::iterator > result = boost::minmax_element(data.begin(), data.end()); cout<<"min_max: minmax_element:"<<t.elapsed()<<endl; cout<<"minVal="<<*result.first<<",maxVal="<<*result.second<<endl; } } dataarray data; int main(int argc, char const* const* argv) { cout << "sorted array:" << endl; for(unsigned int i = 0; i< data.size();i++) { data[i] = i; } do_tests(data); cout << "random array:" << endl; std::srand(0); for(unsigned int i = 0; i< data.size();i++) { data[i] = std::rand(); } do_tests(data); return 0; }

4 4

_SECURE_SCL for msvc
by Hansi 18 Feb '09

18 Feb '09

Hello, the problem with _SECURE_SCL define was already discussed a few times on this list. But til now it came never to a end. Is there any interrest to get also compiled libraries for _SECURE_SCL enabled and _SECURE_SCL disabled? I think this would be really important because this compiler switch changes the abi and for that programs can crash. I think that a lot of people disable it already in their own programs, but may be they don't compile the boost libraries with this switch... Any comments? Regards Hansjörg

6 7

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

18 Feb '09

Thank you all who replied so far. It is very much and truly appreciated. Tally for far 1. The idea in principle seems to be largely accepted. Phil Endecott raised a concern if the effort was not a wheel-reinvention due to string/number conversions in N2408. I feel N2408 does not have as broad scope and has serious limitations (no user-type conversions, no handling of any container<char>, etc.) 2. The name of the namespace. People largely seem content with "boost::string". Andrey Semashev expressed a concern that the name was too generic and could clash with std::string (using namespace boost; using namespace std). A fair point. However, I do not feel it is a boost::string "problem" per se but rather the "problem" with using-directives (or rather mis-using-directives). Using-directives beat the whole purpose on a namespace and best avoided (see Stroustrup 8.2.3). From my actual experience it was not an issue. Long time ago I've introduced aux::string in two sizeable projects and honestly did not have one single complain about name clashing. Bo Persson also expressed a concern siting it'll make it "very hard to propose the utilities for inclusion in a future language standard". May be. May be not. When things of that magnitude happen (which seem quite remote at present) components get moved from a namespace to a namespace (several times) anyway. Like some stuff from the "boost" namespace moving to the "tr1" namespace just ultimately to be moved to the "std" namespace. Therefore, unless something major comes up later we are settling on "boost::string". 3. Naming of the conversion functions. The "to/from/is" set seems to sit well with the majority of people. The to_string/from_string was floated around as alternatives. I feel that the "_string" extension indeed serves a mildly useful purpose when the "string" namespace is obfuscated. Like namespace boost::string obfuscated; string str = obfuscated::from(i); // What the...? string str = obfuscated::to_string(i); // Somewhat better but still... When used sensibly string str = boost::string::from(i); or namespace boost::string str; string str = str::from(i); the intention seems clear and the following feels like a tautology: string str = boost::string::to_string(i); Robert Stewart mentioned that "is" is a poor name choice. It doesn't imply "can convert to" and can be expensive to execute. Fair enough. I'll keep the name around as a placeholder for a rainy day. We might not need it at all if we agree on something along the following lines: // No throw, return default on failure, dunno if failed. int i = boost::string::to<int>(str, default_value); // No throw, return default on failure, can check if failed. boost::string::value i = boost::string::to<int>(str, default_value); if (i.good()) successfully converted 4. String-To-Something Conversion Interface. Considerable number of people were not exactly happy with my off the cuff int i = boost::string::to<int>(str)(default_value); Well, I do not like it either... I just like saying/suggesting things that I regret later. :-) I probably got carried away by the functional-chain-ability concept. The main reason (for me) it is not good is that it imposes the default-constructibility requirement. I think people on the original lexical_cast-realted thread were pretty content with int i = boost::string::to<int>(str, -1); syntax. If so, then we won't need int i = to(str).or_default(-1) int i = to(str, default_ = -1) Can we agree on the following interface: template<class T, class String> boost::string::value<T> boost::string::to(String const&, T const& =T()) throw(); The usage is // Does not throw, returns -1 on failure. Don't care if failed int i1 = boost::string::to<int>(str, -1); // Does not throw, returns -1 on failure. Care if failed boost::value<int> i2 = boost::string::to<int>(str, -1); if (i2.good()) successful conversion6. 5. Formatting with manipulators. I've implemented a prototype and it works just fine. string str = "0xFF"; int i1 = boost::string::to<int>(str, -1) >> std::hex; // returns 255 int i2 = boost::string::to<int>(str, -1)(std::hex); // Same as above For the time being I keep both interfaces (via () and >>). 6. Something-To-String Conversion Interface. That did not seem to generate much heat at all. I'll summarize to make sure we see it the same way: template<class T> boost::string::value<std::string> boost::string::from(T const&) throw(); Does not throw. No default value (do we need one?). Returns string() of failure. Usage: std::string s1 = boost::string::from(-1); // 'int' type deduced std::string s2 = boost::string::from<double>(-1); // 'double' type forced std::string s3 = boost::string::from(15) >> std::hex; // returns "0xF" if (s1.empty()) conversion failed boost::string::value<std::string> s4 = boost::string::from(-1); if (s4.good()) conversion succeeded 7. Check-Convertibility Interface. If we agree on the behavior above (using boost::string::value), then the separate boost::string::is does not seem needed. 8. Throw/No-Throw Behavior. You might have noticed that the interface above *never* throws anything on failure. I would like to highlight the fact (as it's different from lexical_cast behavior) and make sure people are happy with it. Those who need an exception thrown could do boost::value<int> i2 = boost::string::to<int>(str, -1); if (!i2.good()) throw something youself; Is it satisfactory? 9. Requested features. a) Handling any container<char> (Phil Endecott). I implemented a rough cut using boost::range and it handles std::(w)string, char/wchar_t const* with ease. To handle any container we might look into extending the interface with something like template<class T, class Range> boost::string::value<T> boost::string::to(Range const&, T const& =T()) throw(); I have not looked into it throughly yet though. b) Integration with Spirit (Hartmut Kaiser). My focus is currently on the interface. Then, we can look at Spirit+boost-string behind it as a separate issue as it requires Joel (and other Spirit developers) involved. c) locale. I have not looked into it at all and I am not sure I am well-qualified. OTOH I hope it'll fit into the proposed interface as string s3 = boost::string::from(15) >> std::hex >> locale-related-functionality; or string s3 = boost::string::from(15)(std::hex)(locale-related-functionality); If so, then we can return to the issue when we get all the above taken care of. Thanks, Vladimir.

10 20

Re: [boost] Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 18 Feb '09

18 Feb '09

I am not sure I can answer all the questions sent so far individually. Some of the questions have been discussed/answered and hopefully this email might be of some help also. RE: convert() and directionality I've decided to stick with Robert's convert() (and his op>> as well. Thank you, Robert) as I agree with his view to leave the door open for possible extensions. That attitude has already proven useful to extend the conversions onto string-to-string (that I did not anticipate). With convert() it'll be easy to extend the existing functionality onto wstring<->u8string, etc. In string-to-string context the directionality issue is mute and I personally find convert() as very much appropriate. Even with string-to/from-type conversions directionality is still present (via types). I agree that with convert() the directionality is somewhat more subtle compared with to/from (or whatever the alternatives). RE: to/from: Yes, I understand quite a few people are not exactly thrilled with to/from. However, it is still here. Apologies. There are two (and a half) reasons for that -- 1) conceptual. Even though I am getting to like convert() more and more, I am still occasionally longing to express explicitly the direction of the conversion with to/from. 2) technical. This to/from-based interface is used in my current project and I am reluctant to needlessly disturb it in any way to avoid code reviews, etc. etc. 2.5) I happen to still like its terseness and directness as my code simply reads "string::to<int>" for string-to-int. I am getting more and more comfortable with convert() though. However, I've been using to/from for about 5 years and it feels like old shoes. Just give me some time to get used to something new. RE: to_string/from_string Somehow I did not like to_string/from_string from the start. I dunno. Just irrational primal dislike. I am sorry. Now it seems I might try putting some smoke-n-mirrors around that by justifying it by the functionality that Hartmut mentioned -- conversion from one symbol/character set to another. I've implemented it (v0.14) and it it like this: string encrypted = boost::string::convert(naked_str) >> my_cypher; string decrypted = boost::string::convert(encrypted) >> my_cypher; That is, we are converting from a string to again a string. In such context I very much like the direction-less nature of convert(). >> My problem is that I can't think of a case when I would be writing >> code that doesn't "know" if it is going "to" or "from" string. Again, string-to-string (or string-from-string) comes to mind. Any directionality seems superfluous and I personally find the code above quite appropriate. Any other suggestions are always welcome as hartmut only brought it up yesterday and I only gave it a cursory thought (can I say a "cursory" thought? it kinda does not feel right). >> I've needed to convert things specifically to std::string plenty of >> times to justify a simple interface where to_string returns >> std::string. I want to be able, in a header file, to just say: >> struct foo; >> std::string to_string( foo const & ); >> std::string to_string( foo const &, fmt ); >> and be done with it. I hope that the suggested interface and implementation allow enough flexibility and simplicity without limiting one to std::string only: namespace bstring = boost::string; std::string s1 = bstring::convert(foo); std::string s1 = bstring::convert(foo) >> std::hex; // add formatting std::Wstring s1 = bstring::convert(foo, std::wtring()); // convert to wide string std::Wstring s1 = bstring::convert<std::wstring>(foo); // same as above RE: convert("5").to<int>(), I like Scott's suggestion of the above. It looks cute. OTOH I am not sure where to stick it into though. Thanks, Vladimir.

4 3

[foreach] HELP NEEDED: intel-vc9-win-11.0
by Eric Niebler 18 Feb '09

18 Feb '09

Boost.Foreach is failing its tests on trunk on the intel-vc9-win-11.0 platform. If there is anyone with access to this platform who would like to run a couple of quick tests, you will be generously rewarded in your next life. Can't beat that. All you have to do is run foreach's tests 4 times with a slightly different config each time. In foreach.hpp, comment out all the config preprocessor gunk (everything between #include <boost/detail/workaround.hpp> and #include <boost/mpl/if.hpp>) and replace it with one of the following: #define BOOST_FOREACH_COMPILE_TIME_CONST_RVALUE_DETECTION or #define BOOST_FOREACH_RUN_TIME_CONST_RVALUE_DETECTION or #define BOOST_FOREACH_NO_CONST_RVALUE_DETECTION or #define BOOST_FOREACH_NO_RVALUE_DETECTION Report the number of test failures each time. Your karmic reward awaits. Thanks in advance, -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

Re: [boost] [Boost-commit] svn:boost r51307 - trunk/libs/ptr_container/test
by Juergen Hunold 18 Feb '09

18 Feb '09

Hi Thorsten ! On Tuesday 17 February 2009 23:42:41 nesotto(a)cs.aau.dk wrote: > Author: nesotto > Date: 2009-02-17 17:42:39 EST (Tue, 17 Feb 2009) > New Revision: 51307 > URL: http://svn.boost.org/trac/boost/changeset/51307 > > Log: > updated for nasty erase() bug.. > Text files modified: > trunk/libs/ptr_container/test/Jamfile.v2 | 3 ++- > trunk/libs/ptr_container/test/associative_test_data.hpp | 5 ++++- > trunk/libs/ptr_container/test/ptr_set.cpp | > trunk/libs/ptr_container/test/ptr_unordered_set.cpp +++++++-------------- 5 files changed, 70 insertions(+), > 18 deletions(-) > > Modified: trunk/libs/ptr_container/test/Jamfile.v2 > =========================================================================== >=== --- trunk/libs/ptr_container/test/Jamfile.v2 (original) > +++ trunk/libs/ptr_container/test/Jamfile.v2 2009-02-17 17:42:39 EST (Tue, > 17 Feb 2009) @@ -38,5 +38,6 @@ > [ sc-test ptr_unordered_set ] > [ sc-test ptr_unordered_map ] > [ sc-test ptr_circular_buffer ] > - > + [ sc-test ptr_multi_index_container ] > + It seems you forgot to "svn add ptr_multi_index_container.cpp" . Can you please add it as this completely breaks regression testing... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

autolinking
by James Mansion 18 Feb '09

18 Feb '09

I'd like to build a boost subset using my own build system. I'd like to turn off autolinking and control the names of the libraries, but it seems I can't. Is that intentional? I tried to use BOOST_AUTO_LINK_NOMANGLE as a starting point but setting that only helped for the first inclusion of auto_link.hpp, since it undefines it. Can I offer this trivial patch, or at least suggest something similar? Index: include/boost/config/auto_link.hpp =================================================================== --- include/boost/config/auto_link.hpp (.../ref/boost) (revision 758) +++ include/boost/config/auto_link.hpp (.../src/boost) (revision 758) @@ -304,6 +304,9 @@ && defined(BOOST_LIB_RT_OPT) \ && defined(BOOST_LIB_VERSION) +// JGM: provide global disable for autolink of Boost libraries. +#if !defined(BOOST_NO_AUTOLINK) + #ifndef BOOST_AUTO_LINK_NOMANGLE # pragma comment(lib, BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) "-" BOOST_LIB_TOOLSET BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT "-" BOOST_LIB_VERSION ".lib") # ifdef BOOST_LIB_DIAGNOSTIC @@ -316,6 +319,8 @@ # endif #endif +#endif // !BOOST_NO_AUTOLINK + #else # error "some required macros where not defined (internal logic error)." #endif @@ -355,14 +360,3 @@ #if defined(BOOST_AUTO_LINK_NOMANGLE) # undef BOOST_AUTO_LINK_NOMANGLE #endif - - - - - - - - - - -

2 1

[spirit] trunk failures due to wrong namespaces
by Juergen Hunold 17 Feb '09

17 Feb '09

Hi ! I've stumbled across some spirit test failures like http://tinyurl.com/bwkgvu The obvious fix seems to be to adjust "boost::math" to "boost::spirit::math" in all places. The attached patch tries to do that. Okay to commit ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

interprocess: error in boost::interprocess::file_lock::swap
by Anton Ivanov 17 Feb '09

17 Feb '09

Hi! current code of function boost::interprocess::file_lock::swap (in boost 1.38.0) is: #if !defined(BOOST_INTERPROCESS_RVALUE_REFERENCE) && !defined(BOOST_INTERPROCESS_DOXYGEN_INVOKED) void swap(detail::moved_object<file_lock> mother) { this->swap(mother.get()); } void swap(file_lock &other) #else void swap(file_lock &&other) #endif { file_handle_t tmp = m_file_hnd; other.m_file_hnd = other.m_file_hnd; other.m_file_hnd = tmp; } Seems, line: other.m_file_hnd = other.m_file_hnd; is wrong. Right version: m_file_hnd = other.m_file_hnd; Ticket https://svn.boost.org/trac/boost/ticket/2766 created. -- Yours sincerely, Anton Ivanov (ai(a)drweb.com)

2 1

[accumulator][minmax_element] Perfomance comparsion different min max algorithm
by Hansi 17 Feb '09

17 Feb '09

Hi, I have made today a few tests to compare the different possibilities to search min,max of a value. I had some really strange results which I don't have expected. As environment I use VS2008 Express edition,not managed, defines are SECURE_SCL=0 and NDEBUG=1. In the comparsion I got the following timings: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< min_element,max_element:73 minVal=0,maxVal=9999999 min_max: accumulator:2338 minVal=0,maxVal=9999999 min_max: minmax_element:86 minVal=0,maxVal=9999999 min/max handcoded:135 minVal=0,maxVal=9999999 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< For me the strange things are: - that std::min_element and std::max_element is faster as boost::minmax_element - the accumulator library seems in this example really slow Best regards Hansjörg The source code was: #include <algorithm> #include <boost/accumulators/accumulators.hpp> #include <boost/accumulators/statistics.hpp> #include <boost/algorithm/minmax_element.hpp> #include <boost/array.hpp> #include <boost\chrono\chrono.hpp> using namespace boost; using namespace boost::chrono; using namespace std; typedef array<int,10000000> dataarray; dataarray data;

5 8

Website news, 1.39 and Boost.Build
by Vladimir Prus 17 Feb '09

17 Feb '09

I have two questions about the news from website: 1. beta.boost.org does not list any 1.39 news, so it's not possible to validate that any addition to boost_1_39_0.qbk are ok. Can that file be somehow included? 2. How do I document Boost.Build changes? This is not exactly a "library". Thanks, Volodya

2 1

Re: [boost] Review Request: Introduction of boost::string, namespace and string-conversion functions
by Vladimir.Batov＠wrsa.com.au 17 Feb '09

17 Feb '09

> That would be: > > string s = boost::string::convert(-1); // to string > int i = boost::string::convert<int>(str); // from string Yes, or string s = boost::string::convert(-1, default_str); // to string int i = boost::string::convert(str, -1); // 'int' deduced from the second parameter > And with that we're almost back at the interface of boost::lexical_cast > once again. Yes, in fact my very first request was to extend lexical_cast. However, it was collectively decided to start a separate library to accommodate formatting, locales, etc. > Also the user might want to convert between std::wstring and > std::string, and in C++0x, std::u8string, std::u16string, and > std::u32string. Yes, now I am coming to realize that accommodating all that additional conversion-related functionality is better done without disturbing the existing lexical_cast. I am hoping the proposed boost::string::convert() "library" is sufficiently flexible to accommodate future growth including the conversions you mentioned. They will be implemented as specializations/overloads of that same boost::string::convert(). Although I have a suspicion that std::string<->std::wstring is not such an easy task. It is because (at present anyway) in my program I do not know if std::string is, say, UTF8 ot MBCS (which might happen to be UTF8 as on Linux or might not as on Windows, Solaris). With std::u8string, std::u16string, and std::u32string it certainly will be easy as we know what we are converting from/to. So, I suspect it'll be as easy as having std::wstring convert(std::u8string) std::u8string convert(std::wstring) Thanks, Vladimir.

1 0

What else shall I do before reuse a stringstream for date parsing?
by Bill David 17 Feb '09

17 Feb '09

To accelerate date parsing, I have writen a class to encapsulate the date parsing logic as following. But the second call to CDateParser::parseDate(str) always failed to parse the date string. What else shall I do before reuse the stringstream object? #include <stdio.h> #include <iostream> #include <sstream> using namespace std; #include "boost/date_time/posix_time/posix_time.hpp" using namespace boost::gregorian; using namespace boost::posix_time; class CDateParser { public: static void initialize(); static time_t parseDate(const string& s); private: static stringstream m_ss; //!< stringstream object used internally for date parsing }; stringstream CDateParser::m_ss; time_t CDateParser::parseDate(const string& str) { ptime p; m_ss.clear(); m_ss << str; m_ss >> p; if (m_ss.fail()) { cout << "do not understand: " << str << endl; return 0; } tm t = to_tm(p); return mktime(&t); } void CDateParser::initialize() { time_input_facet* timefacet = new time_input_facet("%a, %d %b %Y %H:%M:%S %z"); // will be automatically deleted by related locale object m_ss.imbue(locale(locale::empty(), timefacet)); } int main() { CDateParser::initialize(); string str; time_t t; str = "Fri, 18 Jul 2008 11:53:14 GMT"; t = CDateParser::parseDate(str); cout << ctime(&t) << endl; str = "Sat, 19 Jul 2008 11:53:14 GMT"; t = CDateParser::parseDate(str); cout << ctime(&t) << endl; }

3 6

[thread]link problem with ibboost_thread-vc71-mt-gd-1_38.lib
by WANG Xuewen 16 Feb '09

16 Feb '09

Hello, I had a dll using MFC as shared library which works fine with boost 1.35. Recently, I've started to look at 1.38 and got the following link problem: libboost_thread-vc71-mt-gd-1_38.lib(tss_pe.obj) : error LNK2005: __pRawDllMain already defined in mfcs71d.lib(dllmodul.obj) libboost_thread-vc71-mt-gd-1_38.lib(tss_pe.obj) : warning LNK4006: __pRawDllMain already defined in mfcs71d.lib(dllmodul.obj); second definition ignored I've searched on internet and mailing list archive and didn't find a solution to the problem. Does anyone have an idea? Thanks, Xuewen

2 1

Seeking writers to develop quarterly digests of Boost newsgroups
by Brian Wood 16 Feb '09

16 Feb '09

I'm planning to start an on line magazine called C++ Quarterly. *http://tinyurl.com/df6hn2 or **http://preview.tinyurl.com/df6hn2 * If you are interested in writing a quarterly digest of Boost Users and/or Boost Developers, please let me know. Alternatively, if you're interested in writing a non-digest article, I'd be happy to hear from you. Just to clarify something from the above link. I want to set things up so that advertisers send money directly to authors. Advertisers would send ads to us but money to authors. Brian Wood Ebenezer Enterprises www.webEbenezer.net <http://www.webebenezer.net/>

1 0

Releases and EOLS
by Rene Rivera 15 Feb '09

15 Feb '09

In the past there's been confusion as to what the release packages contain with regards to EOLs <https://svn.boost.org/trac/boost/ticket/2641>. My idea for dealing with the confusion is to tag the packages with an EOL indicator (as explained in the bug). Any other ideas? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 6

boost::ptr_container: seems bug in erase_if
by Anton Ivanov 15 Feb '09

15 Feb '09

Hi! In ptr_sequence_adapter.hpp we have function: template< class Pred > void erase_if( iterator first, iterator last, Pred pred ) { range_check(first,last); this->base().erase( std::remove_if( first.base(), last.base(), void_ptr_delete_if<Pred,value_type>(pred) ), this->base().end() ); } If we call this function with second parameter not equal to this->base().end() then function remove not only elemets for wich pred return true, but also all alement from last.base() to the end of container (this->base().end()). This is seems bug due to function documentation: template< class Pred > void erase_if( Pred pred ); template< class Pred > void erase_if( iterator begin, iterator end, Pred pred ); * Requirements: Pred must take an const T& argument * Effects: removes all elements t for which pred(t) returns true from the entire container or the specified range -- Yours sincerely, Anton Ivanov (ai(a)drweb.com)

3 4

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

[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