- Boost - lists.preview.boost.org

[asio] Received 3 times RST, ACK before the boost TCP returns connection failure
by allen han 20 Feb '09

20 Feb '09

Hi: Pretty new to use the boost library for networking and experienced a problem to use the TCP socket on client side. 1. using the call below to connect server: mSocket.async_connect(endpoint,boost::bind(&handleConnect, this, boost::asio::placeholders::error, ++aEndPointIterator)); 2. found connection is failed, then close the socket void handleConnect(const boost::system::error_code &aErr, boost::asio::ip::tcp::resolver::iterator aEndPointIter) { if (!aErr) { ... } else if (aEndPointIter != boost::asio::ip::tcp::resolver::iterator()) { doClose(); ... } else { ... doClose(); } } 3. From Ethereal, found that SYN, RST/ACK have been sent 3 times before the connection is closed, Client sent Server SYN, Server sent Clinet RST, ACK Client sent Server SYN, Server sent Clinet RST, ACK Client sent Server SYN, Server sent Clinet RST, ACK Question: Any flag to inform the boost TCP stack to return error if it receives the first RST,ACK?

2 1

[1.38] PDF docs release candidate available
by John Maddock 19 Feb '09

19 Feb '09

The release candidate for the PDF build of the 1.38 docs is now available from http://boost.cowic.de/rc/pdf/, unless anyone spots any last minute issues, I'll put these on sourceforge at the weekend. Enjoy, John.

3 6

[date_time] How to build the docs?
by John Maddock 19 Feb '09

19 Feb '09

Am I correct in thinking that the date_time docs need some manual intervention to build correctly? Any instructions? Thanks, John.

1 0

[fusion] C++0x support?
by Ein Held 19 Feb '09

19 Feb '09

Hello is there any chance for c++0x support (rvalue forwarding for the containers' constructors and operator=s' in particular) for fusion in 1.39? Thank you

1 0

[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