- Boost - lists.boost.org

Re: Formal Review: FOREACH macro
by Sam Saariste 28 Apr '05

28 Apr '05

* What is your evaluation of the design? Very good. It's very easy to use and the support for lvalues access to container/range elements is very powerful and convenient. Also when using overloaded operators on the elements, the resulting code is much cleaner with FOREACH than with an iterator based loop. * What is your evaluation of the implementation? Brilliant * What is your evaluation of the documentation? Good. The library doesn't need too much documentation really. Maybe some pitfall section as already has been mentioned would be a useful addition. * What is your evaluation of the potential usefulness of the library? Very useful - it lets you express small ad-hoc algorithms in an elegant way and in the place where you want them. I have used it for more than 6 months now and have added it to my standard set of idioms. Once you get into the FOREACH mindset, you don't only want to use it for std::for_each type jobs but you would also want to use it for std::transform type ones. In situations where you can use push_back on a result container, FOREACH serves this purpose as it is. However, I have encountered situations where this was not possible and where I wanted a second macro, say FOREACH2, that iterates over 2 ranges simultaneously. I have had such a need on more than one occasion. One situation was as above and in other situations I had to combine the elements of two ranges. I implemented such a FOREACH2 macro myself based on Eric's implementation and it appeared to be relatively straightforward. For this reason, I would like to request this as an enhancement to the library. Users of FOREACH wouldn't be affected by such an additional macro, so I see little reason why people would object to it. Similarly, I could imagine use for a 3 range version, where the elements of two ranges are combined and the results get written into the third range exactly as you can do with std::transform. * Did you try to use the library? With what compiler? Did you have any problems? As mentioned above, I have used the library on a regular basis for over 6 months. All my experience is based on using it with VC7.1. I have not had any problems. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 6 month experience with the library from a user perspective. After reading Eric's article on Artima, I have studied the implementation in quite a bit of detail so that I could implement an extended version that would iterate over 2 ranges. * Are you knowledgeable about the problem domain? Not more or less than other experienced C++ developers. * Do you think the library should be accepted as a Boost library? YES, definitely. Cheers, Sam Saariste

2 1

aligned_storage not a POD?
by Peter Dimov 28 Apr '05

28 Apr '05

boost::aligned_storage is supposed to be an implementation of TR1 aligned_storage, which yields a POD. I even see a specialization of is_pod for aligned_storage in the header. However the class itself (::type only echoes its type back) does not seem a POD at all. It has a default constructor, destructor, a private copy constructor and whatnot. aligned_storage_test does not test its PODness, it only looks at is_pod. I think that a reasonable test for PODness would be to try to initialize with = {} (if nonscalar) and/or use it in a union. -- Peter Dimov http://www.pdimov.com

4 12

Small tuple extension
by Giovanni P. Deretta 28 Apr '05

28 Apr '05

Hi, I have been using a small extension to the tuple library 'get' function, that I have found very handy. It allows the extraction of an element of a tuple by specifying its type instead of the index. Example: given the tuple boost::tuple<type1, type2, type3> get<type1> returns the first element of the tuple of that type. This allows one to write more self describing code: you don't need to look up the tuple element type when you find an indexed get function buried deep inside some code. This is especially useful with nested tuples where for example 'get<3>(get<5>(get<0>(my_tuple)))' looks more like line noise than real code :). I use type wrappers to wrap built-in types and give them unique names (a typedef that creates unique objects instead of aliases would be really useful here!). Anyway, here is my code. It is really a quick hack, i probably did get returns type wrong (probably works only for value type elements), and I'm sure metaprogramming experts here can do much better. namespace detail { namespace mpl = boost::mpl; template <typename Tuple, typename Type, int Index> struct traverse { typedef typename ::boost::tuples::element<Index, Tuple>::type this_type; typedef typename mpl::if_ <boost::is_same <this_type, Type>, mpl::int_<Index>, typename traverse<Tuple, Type, Index-1>::type >::type type; }; template<typename Tuple, typename Type> struct traverse <Tuple, Type, -1> { typedef boost::mpl::int_ <boost::tuples::length<Tuple>::value> type; }; template <typename Tuple, typename Type> class index_of_type { public: typedef typename traverse<Tuple, Type, boost::tuples::length<Tuple>::value-1>::type type; }; } template <typename Type, typename Tuple> Type& get(Tuple& tp) { typedef typename detail::index_of_type<Tuple, Type>::type index; return boost::tuples::get<index::value>(tp); } template <typename Type, typename Tuple> const Type& get(const Tuple& tp) { typedef typename detail::index_of_type<Tuple, Type>::type index; return boost::tuples::get<index::value>(tp); } }

6 24

bind/smart_ptr expected failures not gray
by Peter Dimov 28 Apr '05

28 Apr '05

I think I have updated explicit-failures-markup.xml to mark the bind/smart_ptr expected failures as, well, expected, but I still see them as yellow. Am I doing something wrong/stupid? -- Peter Dimov http://www.pdimov.com

3 2

memory model
by Matt Hurd 28 Apr '05

28 Apr '05

As an occaisonal user and non-expert user of memory fencing, I'd like to see a portable implementation in boost as a step to capturing some memory semantics. Peter Dimov suggested he like Alexander's unidirectional model. I'm guessing at what he means... I'm not too fond of the acquire, release naming. I'd prefer something simpler to understand like publish and subscribe, though on some platforms this seems to have specific meaning... e.g. sparc. Any suggestions? What about a simple facade like: boost::memory::complete_reads(); boost::memory::complete_writes(); boost::memory::complete_all(); Simpler to understand but perhaps a bit misleading...? Or should it be kept normal with respect to common nomenclature: boost::synch::fence::load(); boost::synch::fence::store(); boost::synch::fence::full(); As a second point. On ia32, quite a popular platform, locking and unlocking mutexes has full fence semantics. On Sparc too. This is not the case on others. I'd like to be able to write optimal portable code for the case where I want a fence along with unlocking a mutex. I can think of a few courses of action: 1. full fence semantics required by mutex unlock and/or lock - overly costly and dumb I think 2. adjacent lock_unlock fence ops that may or may not be null ops boost::synch::fence::unlock_and_full() boost::synch::fence::lock_and_load() ;-) - seems awkward, especially for ia32 where they are no-ops 3. special lock and unlock ops for each case... yuck 4. a policy for a mutex that is used when locked and unlocked 5. forget it cause in practice you don't need it very often at all - probably true, but I have such a thing i use to speed up some stuff on sparc and ia32 where i have a very cheap is_empty check and don't care about other costs. 4 seems the most tolerant way... thoughts? If we can get some agreement, I'll put together a simple ia32 implementation for gcc and msvc with a short doc. Matt.

1 0

Fw: Function pointers, result_of<> and function_traits<>
by Peter Dimov 27 Apr '05

27 Apr '05

This post to boost-users describes what sounds like a bug in result_of. Delfin Rojas wrote: > Hello all, > > I am trying to get the return type of a member function given its > signature. Consider the following example from the boost result_of > test: > > struct X {}; > > int main > { > using namespace boost; > typedef int (X::*mem_func_ptr)(float); > > BOOST_STATIC_ASSERT((is_same<result_of<mem_func_ptr(X,char)>::type, > int>::value)); > } > > This test compiles/runs with no problems. Now, what I want is the > return type of a function with signature "int (X::*)()" > > I added the following to the test: > > typedef int (X::*empty_mem_func_ptr)(); > > BOOST_STATIC_ASSERT((is_same<result_of<empty_mem_func_ptr(X)>::type, > int>::value)); > > This does not compile. I get an error > boost_1_32_0\boost\utility\result_of.hpp(43) : error C2825: > 'F::template': cannot form a qualified name. > > I tried to do this same thing with function_traits but it seems > function traits does not support member function pointers at all. > > So this is all I have. If somebody can help me I would appreciate it. > > Thanks > > -delfin > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [boost] Re: [sockets] layers concept
by Iain Hanson 27 Apr '05

27 Apr '05

On Tue, 2005-04-26 at 13:54 +0300, Boris wrote: > Iain K. Hanson wrote: > > Hi > > > > I created the layers concept for the C++ Networking boost library. > > > > The layers I defined are: > > > > Layer 1 :- Light weight wrappers arround predominantl BSD socket > > concepts. > > > > Layer 2 :- Acceptor, Connector, Reactor, and Svc_Handler concepts ala > > ACE. > > > > Layer 3 :- An optional iostreams interface if desirable? > > > > Layer 4:- Applications layer - includes ftp, telent, http/s And user > > applications > > Is layer a package or a level of abstraction? I ask as I wonder if eg. layer > 3 is based on layer 2? Not having done much work on iostreams for sockets I thought it would be a little of both but I was not sure. I saw it as a higher layer abstraction that had greater easy of use but probably less flexibility/control. Whereas Layer 2 has much greater flexibility and control but a greater learning curve if you want/need the more advanced features. > > If you look at http://www.highscore.de/boost/net/packages.png I put the > packages "ace" (your layer 2) and "iostream" (your layer 3) both in layer 1 > because they don't necessarily depend on each other and I don't know if we > can tell which one of the two packages has a higher level of abstraction. > > > [...] > > Boris has also been atempting bto model Layer 1 but keeps calling > > itlayer 0. > > Hey, everyone called it level 0! :-) > > > we need a common nomenclture or confusion will reign. > > That's why I added the link to the package structure at > http://www.highscore.de/boost/net/packages.png everywhere to make sure we > talk about the same. It's quite similar to your layers concept except that > you created new application layer. There has always been a need for standard applications protocols such as FTP, Telnet, SMTP, HTTP, etc. But Beman Dawes wrote a set of requirements for a socket library that said something like sockets are a chapter in the book no the whole book. He meant to limit the scope of a socket library so that it might actual get finished. I refined that idea by comming up with my layers which we've been using for the last 3 or 4 years. Thats why I'm objecting to you subtracting 1 from the layer numbers. /ikh

4 6

[Boost-bugs] [ boost-Bugs-1191356 ] boost::blank - missing operators
by SourceForge.net 27 Apr '05

27 Apr '05

Bugs item #1191356, was opened at 2005-04-27 15:26 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=1191356&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Parent (sean_parent) Assigned to: Nobody/Anonymous (nobody) Summary: boost::blank - missing operators Initial Comment: Main issue: boost::blank !=, >, etc... not defined (only == and <) I'd like to replace adobe::empty_t <http://opensource.adobe.com/ structadobe_1_1empty__t.html> with boost::blank, but can't because of the lack of these operators. Minor issues: boost::blank is a poor name given the use of blank in the regex library. There does not appear to be any formal documentation for boost:: blank - (an index for boost would be very helpful). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1191356&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Re: Boost to the rescue
by JOAQUIN LOPEZ MU?Z 27 Apr '05

27 Apr '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Miércoles, Abril 27, 2005 11:05 pm Asunto: [boost] Re: Boost to the rescue > "JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> writes: > > > * As for #3 and #4, I've got this idea round my head > > that Boost would benefit of a "community site" where > > people of various expertise levels could mingle > > together, post Boost-related articles, etc. Something > > like CodeProject or Gamedev, which have a less

1 0

Re: [boost] Re: Boost to the rescue
by Bjørn Roald 27 Apr '05

27 Apr '05

Ummf... the damn touchpad on my laptop sendt my last message without asking me first. I finish it below: "Bjørn Roald" <bjorn(a)4roald.org> wrote: > One concern I have is that the boost project developers should focus on creating great proposals for the C++ standard, not becomming a market leading tool provider. Others could fill that role to avoid draining the developer team of attention to their important work. Bjørn

2 1