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

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

namespace naming -- the question to moderators
by Arkadiy Vertleyb 10 Apr '06

10 Apr '06

Hi all, The typeof library defines some templates in the unnamed namespace. This was done to avoid ODR violations in certain contexts (although it introduces them in other contexts). The unnamed namespace used now is: boost::type_of::<unnamed> It turnes out MSVC 7.1 and 8.0 cannot handle this kind of namespace correctly in conjunction with precompiled headers. Specifically, if a template is defined inside such a namespace in the precompiled header, it cannot be specialized outside this precompiled header (for typeof this means types cannot be registered outside pch). The problem can be worked around by using a different kind of unnamed namespace, like, for example: <unnamed>::boost_typeof (<unnamed>::boost::type_of introduces ambiguity in some contexts) This kind of unnamed namespace can be handled correctly by both MS compilers, with respect to pch, but I don't believe it satisfies the Boost naming convention. OTOH, if no other solution is found, this is the only way we can achieve typeof compliance with pch, while still staying in the unnamed namespace. Thoughts? Regards, Arkadiy

6 10

[thread] attribute syntax
by MaximE 09 Apr '06

09 Apr '06

In my home grown POSIX threads wrapper I use expression templates to specify thread, mutex, condition attributes with the following syntax: mutex m(shared | recursive); thread t(..., detached | sched_policy(SCHED_FIFO) | sched_priority(1)); I thought it might be appealing for boost threads library to have something similar. Sketch code follows. #include <pthread.h> #include <memory> // sinposis class error; class thread; template<class T> struct concept; template<class left, class right> struct binary_op; template<class left, class right> binary_op<left, right> operator|(concept<left> const& l, concept<right> const& r); struct detached; struct sched_policy; struct sched_priority; class error : public std::exception { private: char const* s_; int c_; public: error(int code) : s_("thread::error"), c_(code) {} error(char const* s, int c) : s_(s), c_(c) {} int code() const { return c_; } char const* what() const throw() { return s_; } }; #define THREAD_CHK_CALL(call) \ do { \ if(int __thread_error_code__ = (call)) \ throw ::error(#call, __thread_error_code__); \ } while(0) template<class T> struct concept { T const& self() const { return static_cast<T const&>(*this); } }; template<class left, class right> struct binary_op : concept<binary_op<left, right> > { left const& l_; right const& r_; binary_op(left const& l, right const& r) : l_(l), r_(r) {} void apply(pthread_attr_t* a) const { l_.apply(a); r_.apply(a); } }; template<class left, class right> inline binary_op<left, right> operator|(concept<left> const& l, concept<right> const& r) { return binary_op<left, right>(l.self(), r.self()); } struct detached : concept<detached> { detached() {} static void apply(pthread_attr_t* a) { THREAD_CHK_CALL(::pthread_attr_setdetachstate(a, PTHREAD_CREATE_DETACHED)); } } const detached; struct sched_policy : concept<sched_policy> { int policy_; sched_policy(int p) : policy_(p) {} void apply(pthread_attr_t* a) const { THREAD_CHK_CALL(::pthread_attr_setschedpolicy(a, policy_)); } }; struct sched_priority : concept<sched_priority> { int priority_; sched_priority(int p) : priority_(p) {} void apply(pthread_attr_t* a) const { sched_param p; p.sched_priority = priority_; THREAD_CHK_CALL(::pthread_attr_setschedparam(a, &p)); } }; class thread { private: pthread_t id_; unsigned joinable_ : 1; private: // noncopyable thread(thread const&); thread& operator=(thread const&); private: struct scoped_attr { pthread_attr_t a; scoped_attr() { THREAD_CHK_CALL(::pthread_attr_init(&a)); } ~scoped_attr() { ::pthread_attr_destroy(&a); } }; private: template<class functor> void start(functor const& f, pthread_attr_t const* a) { struct t // trampoline { static void* f(void* a) { // copy the functor and free the allocated memory before // executing the functor std::auto_ptr<functor> f(static_cast<functor*>(a)); functor e(*f); f.release(); return e(); } }; std::auto_ptr<functor> e(new functor(f)); THREAD_CHK_CALL(::pthread_create(&id_, a, &t::f, e.get())); e.release(); } void start(void*(*fun)(void*), void* arg, pthread_attr_t const* a) { THREAD_CHK_CALL(::pthread_create(&id_, a, fun, arg)); } public: thread() : id_(::pthread_self()), joinable_(1) {} thread(void*(*fun)(void*), void* arg) : joinable_(1) { this->start(fun, arg, 0); } template<class functor> thread(functor const& f) : joinable_(1) { this->start(f, 0); } template<class A> thread(void*(*fun)(void*), void* arg, concept<A> const& attr) { scoped_attr a; attr.self().apply(&a.a); int j; THREAD_CHK_CALL(::pthread_attr_getdetachstate(&a.a, &j)); joinable_ = PTHREAD_CREATE_JOINABLE == j; this->start(fun, arg, &a.a); } template<class functor, class A> thread(functor const& f, concept<A> const& attr) { scoped_attr a; attr.self().apply(&a.a); int j; THREAD_CHK_CALL(::pthread_attr_getdetachstate(&a.a, &j)); joinable_ = PTHREAD_CREATE_JOINABLE == j; this->start(f, &a.a); } ~thread() { if(joinable_) ::pthread_detach(id_); } void* join() { if(!joinable_) throw error("thread::join()", 0); void* p; THREAD_CHK_CALL(::pthread_join(id_, &p)); joinable_ = 0; return p; } }; void* f(void*) { return 0; } int main() { thread t(f, 0, detached | sched_policy(SCHED_FIFO) | sched_priority(1)); }

1 0

Testing - further reading
by Andy Little 09 Apr '06

09 Apr '06

I came upon this report regarding "The Economic Impacts of Inadequate Infrastructure for Software Testing" published by NIST. It struck me that boosters might find it interesting in relation to testing. As well as info on tests It also provides information on the type of criteria users might employ to select software (Section 1.1 Software Quality Atrributes) with point by point atributes table (table 1.1) . I found it interesting to apply some of the questions in the table to my own work, which did well in some areas but not so well in others.. http://www.nist.gov/director/prog-ofc/report02-3.pdf regards Andy Little

1 0

[review] promotion traits - review period extended until April 9.
by Tobias Schwinger 08 Apr '06

08 Apr '06

Dear users & members of Boost, I decided to extend the review period of the fast-track review for Promotion Traits until April 9 because there were only three reviews until now. That is, you have another three days to submit your evaluation of the proposed Boost software. Cheer up, it's a small & fast-to-track submission! We're very much looking forward to your reviews. Download URL ============ http://cpp-experiment.sourceforge.net/promote-20050917.tar.gz About the submission ==================== The Promotion Traits extend Boost.TypeTraits with templates that compute the type after promotion has been applied. Example: // given template<typename T> struct some_algorithm; template<> struct some_algorithm<int> { [...] }; // [...] more specializations // , [...] some_algorithm< typename integral_promotion<T>::type > [...] // makes some_algorithm work for any type T that promotes to an integer // (that is enums and smaller integral types) without the need for // additional specialization Review questions ================ Please always explicitly state in your review, whether you think the library should be accepted into Boost. You might want to comment on the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards, Tobias (Review Manager)

3 3