- Boost - lists.boost.org

Re: [boost] [thread] monotonic xtime
by Matt Doyle 10 Apr '06

10 Apr '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Ulrich Eckhardt snip> > On a related note, why doesn't the threading lib offer any > means to yield for > a certain time? In more than nine out of ten cases, this is > the way I do > things, waiting for a certain point in time - like > Boost.Thread does - is > rather the exception than the rule. I'd like to second that request, needing to use the win32 Sleep just kills the portability. My workaround for yielding is - #if defined _MSC_VER || WIN32 # include <windows.h> // for Sleep # define MILLI_SECOND_SLEEP(value) (Sleep(value)) #else # include <unistd.h> // for usleep # define MILLI_SECOND_SLEEP(value) (usleep(value * 1000)) #endif but that's just a hack, it really should be in the library. Matt Scanned by McAfee GroupShield {X3BTB534}

2 1

[FYI] RCF 0.2
by Jarl Lindrud 10 Apr '06

10 Apr '06

Hi all, I just thought I would announce that I've released v. 0.2 of RCF, a portable C++ IPC framework. It makes extensive use of boost, including Boost.Threads, Boost. Serialization, and the recently accepted asio library, so maybe people on this list will find it of interest :) http://www.codeproject.com/threads/Rcf_Ipc_For_Cpp.asp /Jarl.

7 14

[review assessment] Property tree library
by Thorsten Ottosen 10 Apr '06

10 Apr '06

Dear all, I have studied Marcin Kalicinski's Property tree library and its documentation. (For those who are interested, you may look at the library in the boost sandbox under the property_tree folders.) For a few weeks, Marcin has enhanced and simplified the interface. I now find the library fit for a review. Rewiew Wizzards, please arrange for a slot in the review queue. best regards Thorsten

1 0

boost::noninheritable class (was Re: Sealed C++ class)
by Vladislav Lazarenko 10 Apr '06

10 Apr '06

Hello, dear community. I have uploaded the code to the vault - "Generic Programming/noninheritable.zip" (http://boost-consulting.com/vault/index.php?action=downloadfile&filename=no…) The library, some documentation, examples and MSVC project files are present. It would be great if you will include this small library to official boost distribution. If no, let interested people download and use it anyway. Unfortunately, I can test it only with MSVC 7.1 now. So any help is welcome. Please review. Thank you very much for time taken to read this message and probably the code. Regards, Vladislav Lazarenko.

1 0

MultiArray warning under /Za
by Sohail Somani 10 Apr '06

10 Apr '06

Boost 1.33.1 In multi_array.hpp: struct populate_index_ranges { multi_array_types::index_range operator()(multi_array_types::index base, multi_array_types::size_type extent) { return multi_array_types::index_range(base,base+extent); The parameter name extent seems to be typedef'ed previously. This results in: external\boost\include\boost\multi_array.hpp(46) : warning C4224: nonstandard extension used : formal parameter 'extent' was previously defined as a type I've changed it in my tree to be extent_. Sohail

2 1

asio review results -- asio accepted
by Jeff Garland 10 Apr '06

10 Apr '06

All - I'm pleased to announce that asio has been accepted into Boost. As usual with a Boost review, the asio review generated plenty of discussion, issues, and controversy. Comments ranged from high praise, including success stories of projects in production, to serious design concerns and issues. On balance, in my judgment, asio provides a generally solid library that is ready for inclusion into the Boost library -- providing key functionality in an area that developers have a strong need. Of course, like anything else, asio is not perfect -- a number of key issues were uncovered during the review. In terms of required changes I'm only going to cite a few: - Fixes to dynamic memory allocation issues - Interface changes to support ipv4 and ipv6 seamlessly at runtime - Improvements to support strongly typed socket interfaces Chris has communicated a couple possible solutions to the memory allocation issue and I'll ask that the interface and other changes for this issue continue to be discussed on the Boost list so consensus can be achieved on the best resolution. Other key improvements that should be explored as future enhancements include: - Possible removal of some of the c-style interfaces - Exploration of higher level iostream integrations - Performance improvements - Improved documentation (wouldn't be Boost w/o this one) Chris has a much longer list of changes garnered from the review and is well on his way to addressing many of them. Note that there were several threads and discussions about performance, which is particularly critical for the domain covered by asio. One of the performance issues is the dynamic memory allocation issue cited above. In general, the reviewers have extremely high expectations here. However, after reviewing the discussion and library it's my belief that many developers will find asio performance sufficient to build significant projects with only the memory allocation changes. I expect Chris will be able to address some of the other performance issues cited by reviewers in asio over time. Once again I'll apologize to the Boost community for the delay in the review results. The delay was entirely due to my own personal scheduling issues and should not reflect on asio in any way. Thanks again to all the reviewers for their effort and especially to Chris for his tremendous effort in bringing asio to Boost! Jeff

6 10

[asio] iostreams support?
by Christopher Kohlhoff 10 Apr '06

10 Apr '06

Hello all, One request that came out of the asio review was that some sort of iostreams support, similar to the existing iostreams example included with asio, should become part of the library's public interface. I'd like to start some discussion on what form iostreams support should take in asio. Here are my ideas so far, which only really cover the highest level. The goals of iostreams support are to: - Support simple use cases. (Does this include servers?) - Abstract away complexities like io_service (aka demuxer), host resolution, etc. In asio's CVS post-review I have changed the socket types to be "strongly typed", e.g.: ip::tcp::socket ip::udp::socket ipv4::tcp::socket etc.. Following this pattern, for protocols that are stream based (like tcp) I plan to include typedefs for iostream objects, e.g.: ip::tcp::iostream For a client-side connection, this could be used as follows: ip::tcp::iostream s("somehost.com", "http"); This would automatically resolve the host and service names, and take care of managing IPv4 or IPv6 protocol independence for you (i.e. it will try all endpoints returned by resolving the host/service until it gets one that works). What lies between this high level interface and the current asio interface? Exactly how much of it is exposed as part of the public interface? I know Jeff Garland has some ideas about integration with streambufs, so I'll let him expand on them. Others please do feel free to jump in. The internals of iostreams is not an area I am familiar with. Cheers, Chris

1 0

Re: [boost] Sealed C++ class.
by Martin Bonner 10 Apr '06

10 Apr '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Sebastian Redl Sent: 07 April 2006 16:14 To: boost(a)lists.boost.org Subject: Re: [boost] Sealed C++ class. > Vladislav Lazarenko wrote: > >> template <typename T> >> class sealed : virtual private sealed_::sealed_impl<sealed, T> >> >> > Interesting idea. Any particular reason why this inheritance is > virtual? > sealed_impl being a template should be rare to duplicate as a base, > and > having no data members or virtual functions, it should be irrelevant > even if it was duplicated. On the other hand, you introduce the > troubles > that come with virtual inheritance. > > Sebastian Redl If I write class Broken : public UniquePerson {}; Then the constructor of Broken has to invoke the constructor of sealed_impl. However the constructor is private, so it can't. The result is a compilation error. The problem is the code: template <typename T1, typename T2> class sealed_impl { friend typename T1; friend typename T2; ... 7.1.5.3 p2 says "[Note: this implies that, within a class template with a template type-parameter T, the declaration friend class T; is ill-formed.]" In other words, you can't do that :-( -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

9 13

[regex] regex_replace_example and the doc
by Shunsuke Sogame 10 Apr '06

10 Apr '06

Hi, I now recall this attractive example's mistake. <libs/regex/example/snippets/regex_replace_example.cpp> line89-90 maybe should be: extern const char* pre_expression = "(<)|(>)|(&)|\\r"; extern const char* pre_format = "(?1<)(?2>)(?3&)"; Thus, <libs/regex/doc/regex_replace.html> highlighted by this cpp is weird. :-) -- Regards, Shunsuke Sogame

3 2

Re: [boost] namespace naming -- the question to moderators
by Bulygin, Sergey 10 Apr '06

10 Apr '06

Even from my light boost.typeof experience, i know that this problem with MS precompiled headers is a show-stopper for comfortable boost.typeof usage. This is why I am actively vote for this fix. Best Regards, Sergey Bulygin "Arkadiy Vertleyb" <vertleyb(a)hotmail.com> wrote in message news:<e174i9$8aj$1(a)sea.gmane.org>... > "Tobias Schwinger" <tschwinger(a)neoscientists.org> wrote > > Arkadiy Vertleyb wrote: > > > FWIW, I don't think we need this for typeof. All we need is to define > some > > > templates in, for example, <unnamed>::boost_typeof, and then refer to > them > > > as boost_typeof::blah. > > > > > > > Hmmm... That's about what I was talking about. > > > > Figuring that "boost_typeof" (other than "_mpl") is a name that's pretty > unlikely to collide > > with user code, you probably won't need a configuration macro for its > name. > > > > > No leading "::" is needed. > > > > And (so joking doesn't obscure the message of my previous post) there is > no "::" in the code! > > I used "::" simply to denote the namespace lives in the root namespace > :-)... > > So, we seem to be in total agreement :-) > > My only concern was that this violates the Boost naming convention, but I > think > getting things to work is more important. Besides, you pointed to a > precedent. I also > know another one -- bind placeholders. > > I will not be available next week, but after that, unless somebody suggests > a better alternative, > I will implement this (I hope CVS is stable at that point, and we are not > yet in the code freeze). > > Regards, > Arkadiy > > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0