June 2006 - Boost - lists.preview.boost.org

C++ Comittee mailing deadline
by AlisdairM 16 Jun '06

16 Jun '06

Jumping in with a quick reminder before Beeman gets here <g> The deadline for the 'mid-term mailing' for the next ISO Committee meeting is a week on Friday, and for the pre-meeting mailing is the middle of September. This is the official deadline for new proposals for Library TR2. If there are any Boost libraries you would like to see included, now is the time to start writing papers! If you are concerned that you have never written a Committee paper before, just shout! There are plenty of people on this group with experience to help, even if much of our time is already committed to other papers ;¬) In particular, Boost libraries I would personally like to see written up for TR2 which do not yet have proposals are: format signals tokenizer I am aware of at least one effort to write up dynamic_bitset. I am going to try to write up tokenizer for the mid-term myself if no-one else steps forward, but am already limitted on time. Collaborators and co-authors are likewise encouraged to step forwards <g> -- AlisdairM

8 8

monadic (template) metaprogramming
by Korcan Hussein 16 Jun '06

16 Jun '06

It would be so useful if we could get monads in boost mpl (possibly for boost.preprocessor & boost.fusion aswell). I've tired to attempting a general solution for boost mpl but i keep hitting a snag, it's due to the fact that metafunction arguments are essentially untyped, it just confuses the hell out of me since i'm so use to the typeful approach in haskell. So i'm wondering if you guys could help me out, here are two links that implement monads in Scheme: http://groups.google.com/group/comp.lang.functional/msg/2fde5545c6657c81 http://okmij.org/ftp/Scheme/monad-in-Scheme.html This might be useful in help us out in implementing them in boost mpl (due to the fact of scheme's untyped nature).

2 2

shared_ptr thread safety
by John Ky 16 Jun '06

16 Jun '06

Hi, What does "undefined" mean in the shared_ptr documentation about thread safety? http://www.boost.org/libs/smart_ptr/shared_ptr.htm#ThreadSafety I'd like to be able to do simultaneous read/writes, but on a global shared pointer without locking, but I'm unsure of the consequences. -John

1 1

[Boost-bugs] [ boost-Patches-1507034 ] [integer] add support for integers longer than long
by SourceForge.net 16 Jun '06

16 Jun '06

Patches item #1507034, was opened at 2006-06-15 22:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1507034&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott McMurray (me22) Assigned to: Nobody/Anonymous (nobody) Summary: [integer] add support for integers longer than long Initial Comment: With the endian discussion, I looked at Boost.Integer to try to figure out why it didn't support long long and __int64 where possible. Since I couldn't see a reason why it shouldn't, I went ahead and implemented it. The only major interface change is adding additional ValueUpper template parameters to int_(max|min)_value_t and uint_value_t. They default to 0, so no valid old code should be affected. They allow the programmer to use, for example, uint_value_t<0x34567890,0x12> to request a type that can hold 0x1234567890 or int_min_value_t<-0x34567890,-0x12> to request a type that can hold -0x1234567890, which will properly fail if there are no types available over 32 bits (instead of just truncating the constant and giving the wrong result). I also took the opportunity to add int_exact_t templates for cases where an exact number of bits is needed. int_exact_t<32>::exact, for example. ( Ideally this would be an additional typedef inside int_t and uint_t, but I couldn't come up with a simple way of doing that. If it were acceptable to have exact as a typedef for void when not available, it'd be easy, but that goes against existing practice. ) If this isn't wanted, it's very easy to remove. If this looks good I'll try to decipher the macros in the test suite to add some new ones. The changes don't cause any regressions from integer_test.cpp under my g++ 3.3.6, 3.4.6, or 4.1.1. In keeping with the rationale and noticing that it works just about all the compilers, I used no partial specialisation or recursion, so I'm hoping that it'll work fine in the more troublesome compilers as well. Unfortunately portage tell me that gcc-2* is to old to work with the rest of my system, so I haven't been able to try. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1507034&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1506914 ] Still assertion failure in boost::format for empty strings
by SourceForge.net 15 Jun '06

15 Jun '06

Bugs item #1506914, was opened at 2006-06-15 20:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1506914&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel KrÃ¼gler (daniel_kruegler) Assigned to: Nobody/Anonymous (nobody) Summary: Still assertion failure in boost::format for empty strings Initial Comment: The assertion failure of boost::format in case of empty string arguments that occured since VS2005 has been partly fixed by cepstein in March 2006. This fix was partial, because there still exists a corner case, where this assertion can take place: #include <iostream> #include <ostream> #include <string> #include <boost/format.hpp> int main() { std::string arg; // empty string boost::format fmt = boost::format("%=8s") % arg; std::string s = fmt.str(); std::cout << s << std::endl; } The proposed patch looks in unified syntax: Index: feed_args.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/format/feed_args.hpp,v retrieving revision 1.29 diff -u -r1.29 feed_args.hpp --- feed_args.hpp 22 Mar 2006 15:13:25 -0000 1.29 +++ feed_args.hpp 15 Jun 2006 19:49:37 -0000 @@ -63,7 +63,8 @@ if(n_before) res.append(n_before, fill_char); if(prefix_space) res.append(1, prefix_space); - res.append(beg, size); + if (size) + res.append(beg, size); if(n_after) res.append(n_after, fill_char); } } // -mk_str(..) and in standard syntax: Index: feed_args.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/format/feed_args.hpp,v retrieving revision 1.29 diff -r1.29 feed_args.hpp 66c66,67 < res.append(beg, size); --- > if (size) > res.append(beg, size); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1506914&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Sun Studio 11 Compiler jam file patches - basic v1 toolset.
by Timo Geusch 15 Jun '06

15 Jun '06

As mentioned in the sunpro experts thread, I've been building Boost on the Sun Studio 11 compiler (5.8) with a slightly different v1 jamfile which is based on the one Simon Atanasyan published in his blog. I took out a couple of lines that caused problem when building with Python... Anyway, the main changes are: - It defaults to using the compiler-supplied STLport library. From what I understand, Sun doesn't support/isn't really interested in fixing problems that occur in conjunction with the old RogueWave "STL" they also ship for backwards compatibility reasons. - It switches on standard C++ temp variable lifetimes. Normally the SUN compiler uses scoping rules that are backward-compatible with ancient versions of the compiler but these produce "interesting" results with modern C++ code. - Several other flags that supposedly make the compiler grok templates better. The attached patch is against the 1.34 RC CVS version but should apply cleanly to 1.33.x as well. I'd appreciate if someone with the necessary priviledges could commit it. I'll try to provide the necessary patches for v2 in the next few days as well. Regards, Timo

1 0

Re: [boost] [asio] Trying to make SSL work with an existing client/server system
by Scott 15 Jun '06

15 Jun '06

Hi Chris, Thanks very much for the reply. > It sounds to me as though you're using the SSL example from the > "boost layout" asio proposal (where everything is in the namespace > boost::asio) with the headers from the non-boost package of asio > (where the namespace is just asio). The SSL example is found in > src/examples/ssl in the non-boost package. You are correct. We grabbed the version from sourceforge several months ago (v3.6). I downloaded the latest from anonymous CVS - wow. Quite a few changes there (demuxer is now io_service, etc. etc.). I'm in the process of rewriting our code to the latest asio. When I'm done, I hope you (or someone with SSL experience) wouldn't mind answering a few questions about getting SSL working. I basically just want a simple encrypted tcp stream, with a minimal of fuss. I don't need certificates (at least I don't think I do). All I want is the server and client to generate keys on startup automatically and use those keys to negotiate the symmetric cypher during handshaking. If there's an easy way to hook that up, please let me know. The example client/server SSL seems unwieldy. It actually makes you type a pass phrase when the server starts. I really don't want that. Thanks, Scott

3 2

[serialization] - xdr-archives?
by Oliver.Kowalke＠qimonda.com 15 Jun '06

15 Jun '06

Hello, did someone tried to implement XDR-archive? I know that Jack Reeves illustrated an XDRstream implementation on CUJ/C++ forum. Regards, Oliver

1 0

[serialization] Small patches for serialization of STL containers
by Tarjei Knapstad 15 Jun '06

15 Jun '06

Here's a few patches against HEAD to comment out unused 'file_version' parameters in the load()/save() funtions in the serialization of some of the STL containers. (The compiler emits quite a mess if set to warn on unused parameters). It's only a minor annoyance, but would be nice if these could be snuck into 1.34 :) -- Tarjei

1 1

[Boost-bugs] [ boost-Patches-1506528 ] [serialization] comment out unused variables
by SourceForge.net 15 Jun '06

15 Jun '06

Patches item #1506528, was opened at 2006-06-15 10:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1506528&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tarjei Knapstad (tarjeik) Assigned to: Nobody/Anonymous (nobody) Summary: [serialization] comment out unused variables Initial Comment: The attached patches comments out quite a few unused parameters in the save()/load() funtions for STL containers in the Boost.Serialization library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1506528&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0