- Boost - lists.boost.org

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

[Boost-bugs] [ boost-Bugs-1191322 ] copy ctor for empty() regex throws bad_expression
by SourceForge.net 27 Apr '05

27 Apr '05

Bugs item #1191322, was opened at 2005-04-27 14:19 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=1191322&group_… Category: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: copy ctor for empty() regex throws bad_expression Initial Comment: in boost 1.32: regex A; regex B = A; // throws bad_expression ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1191322&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

SmartPtrs: Making Code Self-Describing. Do we need more SmartPtrs?
by Pavel Chikulaev 27 Apr '05

27 Apr '05

Hi boosters, Please consider the following code which we IMO too often see in other libraries: class Foo; Foo * Bar(Foo *); What can we say about this pretty C-like function? It gets pointer Foo and returns pointer Foo. That's all we can be sure about it. But that's not enough to start working with it. But without looking at documentation we can't say whether we should delete these pointers or function Bar will handle it. What if even documentation says anything about it, what to do then? Thanks C++, we've got auto_ptr. Now we explicitly mark that who should care about pointers. So, if we have auto_ptr<Foo> Bar(auto_ptr<Foo>) we do know how to work with it even without looking at the documentation. Example 1: We are the developer of function Foo. And we need to mark somehow that returned pointer is property of Foo internals and it shouldn't be deleted by the client function. We can achieve this using weak_ptr, but what if Foo internals doesn't have any shared_ptr's ? What to return then? Plain pointer? No Way! We need a way to explicitly say that we return copy of pointer that can't be deleted and no synchronization is needed. So, IMO We need another smart pointer type. Unfortunately, I didn't think of a good name for it, so it's still unnamed, but I think you understand what I am proposing. Example 2: We are developer of function Foo again. And now we need to mark that pointer argument is needed only for time of execution of Foo (it wasn't collected anywhere), and user cares about deallocation. How are we going to write such code and make it self-describing at the same time? Plain pointer? No Way! That would be a C-style, but we need something like C++-style... This time we don't have even one std or boost candidate for such job. So we need one more smart_ptr. Again, this one needs a good name too. --- So, anybody interested? Do we need them? Or we've already have some alternative solution I didn't find? Please let me know. Just wanted make code a bit more self-describing, there is no place for dumb pointers at all in high-level C++ programming. And Is there any place for such smart pointers in Boost? As always any comments are welcome. P.S. Description of boost.smart_ptr on libraries page still says that there are 5 smart pointers, instead of actual 6. -- Pavel Chikulaev

4 3

Re: [boost] Re: [test][comeau] problem with va_list
by JOAQUIN LOPEZ MU?Z 27 Apr '05

27 Apr '05

----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Miércoles, Abril 27, 2005 9:20 pm Asunto: [boost] Re: [test][comeau] problem with va_list > > 2. Is it ok to commit an obvious patch to > > boost/test/impl/test_tools.ipp so as to work around > > this problem? > > Could you first to post a patch here? > Of course, I won't touch the CVS before exposing here the patch --this'll be tomorrow, though, as I'm away from my IDE noew. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0