Re: [boost] Re: Re: Reflection system in C++ using templates
I would have expected that for member function pointers arg1_type would be typedef cv class_type* arg1_type; But isn't the class_type pointer hidden? AFAIK, you can't call a member function pointer as if it's function pointer with an explicit 'this' parameter. So how is the arg1_type classtype? But on the other hand, that's what bind does - so you can bind the class instance to be called.. Really what's better is a mem_fun adaptor - like boost::mem_fun except at compile time, since the member function pointer is a template parameter. * template function -> function > That way you could also call nested functors inside the class, which allows more flexibility. So disregard that code for extending function_traits to work with member function pointers =P It wasn't very good anyway. Lin. _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Request for Config Macro( was RE: Re: [test] "unix"identification )
> > So, Let introduce one. I need something for coming release. > > Done: it's called BOOST_HAS_SIGACTION > > John. Why it doesn't get defined for Visual Age C++ on AIX? Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] 'optional' - request for extension
Anthony Williams wrote:
> Aleksey Gurtovoy writes:
> >
> > The following is a sketch of a potential use case for the
> > newly-accepted and already very useful 'optional' class.
> >
> > Suppose you have a pure RAII guard/locker which unconditionally
> > does its job:
> >
> > struct RAII_lock
> > : boost::noncopyable
> > {
> > RAII_lock(entity& e);
> > ~RAII_lock();
> > };
> >
> > and you want to write a semantic equivalent to the following
> >
> > boost::scoped_ptr lock( cond ? new
RAII_lock(entity) : 0 );
> > // ...
> >
> > expect for the dynamic allocation part. How would you do it?
> >
> > IMO the following seems only natural:
> >
> > boost::optional lock( cond, entity );
> > // ...
> >
> > The only problem with the above is that currently you cannot
> > write something like this. It would be nice if we could, IMO.
> >
> > Thoughts?
>
> * Firstly, this would require optional to be able hold
> non-copy-constructible types, whereas the current requirement
> say "T must be CopyConstructible".
>
> You could drop the "CopyConstructible" requirement if you said that
> boost::optional is only itself CopyConstructible/Assignable/
> Swappable if T is CopyConstructible.
Yep, that's what I would argue for.
> However, this leaves the
> question of how to get the value in there in the first place; the
> answer to which is ...
>
> * Secondly, you would need a templated constructor to allow T
> to be constructed using another type.
Correct, that's what I am hoping to pursue :).
>
> Or you could initialize it with optional, since
> this template constructor does already exist, and already does
> the "right thing".
Hmm, that's an interesting idea. In my case, 'entity' is already
exist, though, (and is noncopyable itself) so it should be
'optional' instead. Still interesting.
But, of course, that still wouldn't work with the current 'optional'
(for one, operators * and -> would have a reference-to-reference
problem). If the CopyConstructible requirement is changed as
outlined the above, it should though, shouldn't it? Fernando?
>
> * Thirdly, you would need a special custom constructor which
> takes a conditional.
Yep. I think it's entirely reasonable. After all, 'optional' does have a
bool inside itself, and the conditional is going to map into that one
directly.
>
> You could get round it like below:
>
> boost::optional optionalEntity;
> if(cond)
> optionalEntity.reset(entity);
>
> // if optionalEntity is not initialized, neither is lock
> // else lock is constructed using the conversion constructor
> boost::optional lock(optionalEntity);
>
> You can do this with the current implementation, since the
> CopyConstructible requirement isn't actually verified with a concept
> check, but you'd have to get the requirement dropped if you were to
> rely on it
I could if not the reference-to-reference problem, but thanks for the
suggestion.
> (which would probably mean implementing templated
> constructor/reset/operator= to avoid _having_ to use an optional
> to initialize your optional)
Yes, I would prefer the use case to be supported with the minimal
verboseness on the user side. Otherwise I might as well write
'optional_lock' with the required semantics - which is an option.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Win32 Metrowerks problems [was Re: [test] revision two]
> No, it is some sort of configuration problem. Look on "metrowerks linking errors" thread. It about the same issue with different undefined symbol There was also compilation error with metrowerks. I fixed it couple hours ago. Unfortunately I do not have direct access to this compiler so metrowerks specific errors sometime may creep in waiting for regression test results (I hope to resolve this soon). Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Sockets - what's the latest?
On Thursday, February 13, 2003, at 12:08 PM, Jason House wrote: * How easy will support for SCTP be to work into the boost socket library? ... and how easy would the interface be to use? I looked at the docs on www.sctp.de and downloaded the source, and the fatal flaw seems to be what I found in adaptation.c. It appears both the routing socket and the sctp socket are built on raw IP. At least on Linux, Darwin, and Windows NT/2000, you need root privileges to open one of these. Thus, the daemon to handle the protocol will have to be installed by and run as an administrator, and will therefore not be usable by many clients who do not control the machine they use. I think a UDP-based implementation rather than a raw IP-based one would do as well (with some wasted overhead) and not need admin privileges or the cooperation of the operating system manufacturer to get installed. Does anyone know if there is a UDP-based implementation? -- Brian ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Win32 Metrowerks problems [was Re: [test] revision two]
At 08:17 PM 2/13/2003, Beman Dawes wrote: >At 05:12 PM 2/13/2003, Rozental, Gennadiy wrote: > > >> However, problems with Boost.Test broke a lot of Metrowerks tests. > > > >For some reason I could not locate Metrowerks compilation errors on Test > >Status page. As for Metrowerks linking errors I have a suspicion that it > >has something to do with Metrowerks toolset. > > > >Also I could not locate errors from errors_handling_test. I fixed it in > >last update and it should work now (At least it works for me on 4 win32 > >compilers using bjam) > >The same with result_report_test. > >Hum. I'll try clearing out old bin files and see if that helps. No, it is some sort of configuration problem. The linker is looking for a symbol __CrtSetReportHook (see below). This is part of the Windows SDK, which Metrowerks does support. It looks like for some reason, the library isn't being found. My MWWinx86Libraries setup looks like this: MWWinx86Libraries=+C:\Program Files\Metrowerks\CodeWarrior\MSL;+C:\Program Files\Metrowerks\CodeWarrior\Win32-x86 Support; I changed it to the following: MWWinx86Libraries=+C:\Program Files\Metrowerks\CodeWarrior\MSL;+C:\Program Files\Metrowerks\CodeWarrior\Win32-x86 Support;+C:\Program Files\Metrowerks\CodeWarrior\Win32-x86 Support\Libraries\Win32 SDK; But still no luck. Any Metrowerks experts out there? --Beman mwld -search -maxerrors 5 -maxwarnings 20 -export dllexport -nowraplines -g -subsystem console -o "d:\boost-regr\libs\filesystem\test\bin\operations_test.test\cwpro8\debug\runtime-link-dynamic\operations_test.exe" @"d:\boost-regr\libs\filesystem\test\bin\operations_test.test\cwpro8\debug\runtime-link-dynamic\operations_test.CMD" ### mwld Linker Error: # Undefined symbol: '__declspec(dllimport) __CrtSetReportHook (__imp___CrtSetReportHook)' # referenced from 'int boost::execution_monitor::execute(bool, int) (?execute@execution_monitor@boost@@QAEH_NH@Z)' in execution_monitor.cpp:192 Errors caused tool to abort. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Sockets - what's the latest?
On Wednesday, February 12, 2003, at 03:11 PM, Jason House wrote: Once I heard there was a generic socket library in development, I thought I'd add a quick feature request. I would like to see the ability to have multiple streams through the same socket. This is pseudo-doable over TCP, by encoding the logical stream into the TCP stream. Unfortunately, a lot of what is done with multiple TCP streams is done that way to keep each stream distinct and keep a single lost packet in one stream from holding up other streams during retransmission. If you don't care about the lag, it's just a matter of your application-level protocol encoding the stream ID. If you really want separate, reliable, synchronized streams over a single connection, you'll need a new transmission-level protocol. It would be built on top of UDP (unless you have the clout to get all popular operating systems to ship with your protocol), and that's just a whole big can of worms you don't want to open. Still, if you can't resist, try reading through W. Richard Stevens' _TCP/IP Illustrated, Volume 2_. It walks you through the BSD implementation and can help you code your new protocol, either on top of TCP or over raw IP packets. Also, you can get lots of good tips by reading the Linux IP stacks, though I wouldn't recommend the Coriolis commentary book. If all you're concerned with is the server knowing what client is connecting, just have a handshake on each connection, authorizing the stream. Maybe the first stream can carry a code #, server to client, that the client must subsequently use when establishing subsequent connections. It all depends on how secure you intend to be, but at this point it's out of the scope of a Boost sockets implementation. -- Brian ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [test] revision two
At 05:12 PM 2/13/2003, Rozental, Gennadiy wrote: >> However, problems with Boost.Test broke a lot of Metrowerks tests. > >For some reason I could not locate Metrowerks compilation errors on Test >Status page. As for Metrowerks linking errors I have a suspicion that it >has something to do with Metrowerks toolset. > >Also I could not locate errors from errors_handling_test. I fixed it in >last update and it should work now (At least it works for me on 4 win32 >compilers using bjam) >The same with result_report_test. Hum. I'll try clearing out old bin files and see if that helps. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [test] revision two
At 04:19 PM 2/13/2003, Rene Rivera wrote: >>When I got back, random_test had been looping for six hours. Sigh. I don't >>know that's related. > >I had similar problems with the OpenBSD tests. It ran last night and I woke >up to it still hung, using 99% CPU, in one test (thread/test_condition). >Killed it and a few others after that to make it complete. thread/test_condition under GCC was a long time problem for Win32/GCC, although the symptom was a hang with no CPU activity. Bill Kempf put in some kind of trap to detect this, and that solved the problem as far as testing went (although I don't think he has found why the behavior is pathological). You might want to make sure he is aware the same or similar problem is showing up on OpenBSD. That may help him to diagnose it. As far as random/random_test goes, it has been a problem for a long time (although not looping until today), failing on most or all Win32 compilers. Jens hasn't responded to emails, so if someone else could suggest patches it would be a help. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
At 04:56 PM 2/13/2003, Rene Rivera wrote: >OK, I've made some changes to the page... Added an "Age" column, removed >green from the age color scheme, and moved the age color scheme to the age >column only. > >Comments? The changes seem nice improvements to me. Dropping the Age colors entirely would be fine with me, although I don't feel strongly about it. Thanks for the tweaks! --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Request: BOOST_ENABLE_LONG_LONG
Gennaro Prota <[EMAIL PROTECTED]> writes: > On Thu, 13 Feb 2003 11:52:59 -, "John Maddock" > <[EMAIL PROTECTED]> wrote: > > [..] >>I hear what you say, but I keep coming back to: this is largely an Intel >>compiler specific problem, > > No, it's a matter of not making a silent use of non standard features. > >>and most users really do expect their libraries >>to support long long whenever the compiler does. > > Maybe. But we can't second such attitudes. Otherwise someone might > expect __complex__, or incomplete enumeration types. Where do you > stop? > >>Personally I don't want to >>have to answer a flood of questions along the lines of "why doesn't >>some_type_trait work correctly?" > > Oh, that's really underestimating users' intelligence. There's no need for us to argue about this, is there? Can't we detect whether the compiler is supporting "long long" and only enable the long long code under those circumstances? In fact, /don't/ we do that? If this is just about inconvenient warnings, it seems to me that telling people "disable long long support or disable the warning" is a perfectly sensible approach. What am I missing? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [test] revision two
Rene Rivera <[EMAIL PROTECTED]> writes: > [2003-02-13] Beman Dawes wrote: > >>At 11:53 AM 2/13/2003, Gennadiy Rozental wrote: >> >> >> > Hi, everybody >> >> > >> >> > Today I committed second revision to Boost.Test library. >> >> >> >> Wow, is that a good idea one day before we branch for release? >> > >> >I should have done it week ago, but was really sick. Anyway, It does not >> >contain anything that should break backward compartibility. >> >>However, problems with Boost.Test broke a lot of Metrowerks tests. >> >>--Beman >> >>PS: I started the Win32 tests running this morning, and then left right >>away for a meeting. >> >>When I got back, random_test had been looping for six hours. Sigh. I don't >>know that's related. >> >>I'll run the Win32 tests several times a day as long as lots of changes are >>being checked in. > > I had similar problems with the OpenBSD tests. It ran last night and I woke > up to it still hung, using 99% CPU, in one test (thread/test_condition). > Killed it and a few others after that to make it complete. > > Since this is release time I'll try and run the tests more frequently, twice > a day at least, until things get better. Didn't something just like this happen with Boost.Test just before 1.29.0 was released? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Sockets - what's the latest?
Boris Schäling <[EMAIL PROTECTED]> writes: >> [...] >> How about borrowing ideas from ACE, but implementing them in >> modern C++? Or has that been discussed already? Or is the ACE >> framework too obsolete-C++ to be a useful design? > > We probably should at least consider ACE ideas. But I guess this would > require several of us to dig into ACE which would delay further a Boost > socket library. However ACE could be a valuable investment? >From what I've heard, the ACE architecture is highly interdependent, with everything depending on everything else. There /might/ be something to be gained by looking at its interface, but I would approach it with caution. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Sockets - what's the latest?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David B. Held > Sent: Thursday, February 13, 2003 10:57 PM > To: [EMAIL PROTECTED] > Subject: [boost] Re: Sockets - what's the latest? > [...] > How about borrowing ideas from ACE, but implementing them in > modern C++? Or has that been discussed already? Or is the ACE > framework too obsolete-C++ to be a useful design? We probably should at least consider ACE ideas. But I guess this would require several of us to dig into ACE which would delay further a Boost socket library. However ACE could be a valuable investment? Boris ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Sockets - what's the latest?
>> Noone knows as there is no consensus on how the library's >> architecture should look like. There are different approaches and >> proposals at Boost Wiki and in the sandbox but what's still missing >> is the big picture. As far as there are no ideas of how to get a >> reasonable model which incorporates different things like >> blocking/non-blocking/multiplexing/asynchronous/extensible... there >> won't be much progress. I've been thinking about that and hope to >> come up with an idea in a few days. Actually I think we have come a bit on the design and could churn out something that could be use as a foundation for further discussion. I think whats missing is the reactor part for event notification using eg select. Actually I think that a select based reactor would be a sensible next step to make a proof of concept on the current design. > How about borrowing ideas from ACE, but implementing them in > modern C++? Or has that been discussed already? Or is the ACE > framework too obsolete-C++ to be a useful design? I have looked at that direction while experimenting with the design in the sandbox at least for the asynch parts (proactor, asynch_acceptor, asynch_data_socket). And for the layer 2 standard multplexing of events via select i think the reactor pattern would fit. I don't have a problem with a borrowing concepts from ACE or POSA2 (Pattern Oriented Software Architecture 2) to implement boost.sockets layer 2, do any other of you have strong opinions on patterns used in ACE and mentioned in POSA2? /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [test] revision two
> However, problems with Boost.Test broke a lot of Metrowerks tests. For some reason I could not locate Metrowerks compilation errors on Test Status page. As for Metrowerks linking errors I have a suspicion that it has something to do with Metrowerks toolset. Also I could not locate errors from errors_handling_test. I fixed it in last update and it should work now (At least it works for me on 4 win32 compilers using bjam) The same with result_report_test. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
[2003-02-13] Beman Dawes wrote: >At 12:35 PM 2/13/2003, David Abrahams wrote: > > >Whatever we do with color, most of the text that needs to be readable > >should be black on white. That's been shown to be most readable for > >most people, on average. > >That's a good point. Color-blind people may have trouble with anything that >depends purely on color to convey information. Yes, good point. OK, I've made some changes to the page... Added an "Age" column, removed green from the age color scheme, and moved the age color scheme to the age column only. Comments? -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Sockets - what's the latest?
"Boris Schäling" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > Noone knows as there is no consensus on how the library's > architecture should look like. There are different approaches and > proposals at Boost Wiki and in the sandbox but what's still missing > is the big picture. As far as there are no ideas of how to get a > reasonable model which incorporates different things like > blocking/non-blocking/multiplexing/asynchronous/extensible... there > won't be much progress. I've been thinking about that and hope to > come up with an idea in a few days. How about borrowing ideas from ACE, but implementing them in modern C++? Or has that been discussed already? Or is the ACE framework too obsolete-C++ to be a useful design? Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Sockets - what's the latest?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason House > Sent: Thursday, February 13, 2003 9:09 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [boost] Re: Sockets - what's the latest? > I guess that my original commentary could be revised to some new > questions: > > * How easy will support for SCTP be to work into the boost socket > library? ... and how easy would the interface be to use? Noone knows as there is no consensus on how the library's architecture should look like. There are different approaches and proposals at Boost Wiki and in the sandbox but what's still missing is the big picture. As far as there are no ideas of how to get a reasonable model which incorporates different things like blocking/non-blocking/multiplexing/asynchronous/extensible... there won't be much progress. I've been thinking about that and hope to come up with an idea in a few days. Boris > [...] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Status of Boost, Solaris and Sun WorkShop 6 Compiler?
At 11:02 AM 2/13/2003, David Abrahams wrote: >That said, the level of support for Sun compilers is likely to depend >on two things in the future: > > 1. Sun's willingness to address the serious bugs in their compiler > implementation which prevent much progress at all from being > made. Given a reasonably well-conforming compiler, little > specific attention should be needed in order to get most things > working well. > > 2. Someone stepping up to run regular regression tests on Sun, and > someone at Boost getting them set up to do it. I believe > someone at Mentor Graphics volunteered to run the tests, but I > think we may have dropped the ball on our side. Now that we have both documentation and a script, a number of people have been able to get the tests running on various platforms. Perhaps those that care about Sun could search the archives for the message from the Mentor Graphics folks, and ask them to give the tests a try. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Help with policy_ptr
At 01:47 AM 2/12/2003, David B. Held wrote: >...I hope there's still a chance for it to be considered for the >next version of the standard library. The April meeting deadline is not for the next version of the Standard Library; rather it is for the Library Technical Report. While nothing has been formally decided, I'm personally hoping that the LWG will start accumulating proposals for a 2nd Technical Report right away. Proposals accepted for a second TR might miss the next revision of the standard, but they still would be on track for eventual inclusion. Regardless of the details, please don't give up on this or any other valuable work just because it isn't going to be ready for the April C++ committee meeting. Rather, concentrate on getting it ready for Boost review and acceptance. That's a big step forward for a library. Standardization can come later. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [test] revision two
[2003-02-13] Beman Dawes wrote: >At 11:53 AM 2/13/2003, Gennadiy Rozental wrote: > > >> > Hi, everybody > >> > > >> > Today I committed second revision to Boost.Test library. > >> > >> Wow, is that a good idea one day before we branch for release? > > > >I should have done it week ago, but was really sick. Anyway, It does not > >contain anything that should break backward compartibility. > >However, problems with Boost.Test broke a lot of Metrowerks tests. > >--Beman > >PS: I started the Win32 tests running this morning, and then left right >away for a meeting. > >When I got back, random_test had been looping for six hours. Sigh. I don't >know that's related. > >I'll run the Win32 tests several times a day as long as lots of changes are >being checked in. I had similar problems with the OpenBSD tests. It ran last night and I woke up to it still hung, using 99% CPU, in one test (thread/test_condition). Killed it and a few others after that to make it complete. Since this is release time I'll try and run the tests more frequently, twice a day at least, until things get better. -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [test] revision two
At 11:53 AM 2/13/2003, Gennadiy Rozental wrote: >> > Hi, everybody >> > >> > Today I committed second revision to Boost.Test library. >> >> Wow, is that a good idea one day before we branch for release? > >I should have done it week ago, but was really sick. Anyway, It does not >contain anything that should break backward compartibility. However, problems with Boost.Test broke a lot of Metrowerks tests. --Beman PS: I started the Win32 tests running this morning, and then left right away for a meeting. When I got back, random_test had been looping for six hours. Sigh. I don't know that's related. I'll run the Win32 tests several times a day as long as lots of changes are being checked in. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
At 12:35 PM 2/13/2003, David Abrahams wrote: >Whatever we do with color, most of the text that needs to be readable >should be black on white. That's been shown to be most readable for >most people, on average. That's a good point. Color-blind people may have trouble with anything that depends purely on color to convey information. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Borland specific defects : new config defines?
John Maddock wrote: > I think I like that - do you want to put together the headers? Sorry, been out the country on short notice all this week. I suspect it's a bit close to 1.30 to be making such a change in config now, but I'll try to get something together next week for testing after it's branched. -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Sockets - what's the latest?
Hey, that's a cool find. I also found a homepage for SCTP http://www.sctp.de/ I've CC'd the point of contact from the website. >From what I've read (which is fairly minimal :[), it looks like SCTP would work well for what I was thinking. I guess that my original commentary could be revised to some new questions: * How easy will support for SCTP be to work into the boost socket library? ... and how easy would the interface be to use? * I believe that the socket library is being written to allow different protocols, but I wonder if it would handle multi-streamed protocols easily. I don't know if this kind of implementation would most easily be implemented as sockets inside of a socket... [EMAIL PROTECTED] wrote: > > I'm just a lurker and maybe I missed something, but what you describe > sounds like SCTP (RFC 2960 - the 'other' stream protocol). If the generic > socket library supported SCTP, would that meet your requirements? > > > Jason House > <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] > Sent by: cc: > boost-bounces@list Subject: [boost] Re: Sockets - >what's the latest? > s.boost.org > > > 02/12/2003 03:11 > PM > Please respond to > Boost mailing list > > > > Once I heard there was a generic socket library in development, I thought > I'd add > a quick feature request. I would like to see the ability to have multiple > streams through the same socket. > > Having had recent issues with a game and a proxy/firewall, I thought that I > might > try and see if I can do a long shot that might have beneficial results for > the > future... The problem with games, is that they try to form multiple > connections > between client and host. > > This boils down to providing two distinct benefits. > 1: Programs can easily perform complex communications over a single port. > 2: Without multiple streams, problems can occur when there are multiple > clients > behind a proxy connecting to a host outside of the proxy. If the client > only > forms a single connection to the host, there won't be a problem because the > random > source port will differentiate each stream. So, when multiple clients > connect to > a host from behind a proxy, the host can only differentiate each stream by > the > random source port. So, when the clients form a second connection to the > host, > each stream gets differentiated from each other, but there is no mapping of > random > source port ot the distinct client. > > Example of #2. > Computers A & B connect to host H through proxy P. The host will see the > following connections: > P:1 => H:1 > P:2 => H:1 > P:3 => H:2 > P:4 => H:2 > > There is no way to pair connections on H:2 with connections on H:1 > > Now, without a proxy, it would be > A:1 => H:1 > B:2 => H:1 > B:3 => H:2 > A:4 => H:2 > > Now, it is very clear how to pair the connections... both connections from > A go > together, and both connections from B go together. > > Of course, this might not be a role specifically for a new stream type, It > could > just be a wrapper of some kind. From the library standpoint, the wrapper > kind of > adds a distinctive type of functionality... I would like to somehow make > it easy > and intuitive for somebody considering multiple connections between two > computers > to use this different socket form instead. If it remains as an obscure > combination of libraries, or as something unimplemented, it is likely that > programs requiring multiple connections per client process to hit issues > with > proxy servers. > > I'm interested to see what kind of reaction this creates from the list :) > Is it normal to add a default wrapper to a library in order to make a > common form > of usage easier? I guess that the class responsible for handing how > multiple > streams gets multiplexed could be made into some kind of template > parameter... > > "Michel André" wrote: > > > > Anyone who was working on it - what's the current state of play? The > > > flurry of mail on here a while back seemed to fizzle out. Is that > > > because development has stalled? > > > If I can help out with what limited time and knowledge of the subject > > > I have I will. I really want to see this library in boost, and I know > > > there are > > > many others who do. > > > > > > > Hugo Duncan and I have been juggling ideas about a socket library for > boost > > and discussing on the boost wiki and partly on the list. > > > > And we have started with an rough sketch of how a socket library for > boost > > could look like. It's currently checked in into the boost sandbox. > > > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket > > contains some of the discussions and details. > > > > The work has not been progressing as much as I want due
[boost] Re: Operator result type inference
Miroslav Silovic wrote: > I noticed that boost::lambda library has a complete implementation of > the type inference for the operator results (i.e. inferring that char > + > int returns an int). I would really like to be able to use that in my > code, however, the Lambda implementation is currently undocumented. > What's the entry point for that code? Are there any tests/examples? > > Miro > Check the 'types_promotion_traits' code by Aleksey Gurtovoy (both in the Wiki and the file-area) for example. It also mentions the LL connection. I too would like to see something like this become official! /Fredrik ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Any interest in a stats class
Stats are definitely a must-have for Boost, but as ever, the presentation is not so easy to agree upon. But it is also crucial to get the most accurate answer, and be able to prove it. For example, B D McCullough, American Statistician Nov 1998 52(4), 358 and 1999 53(2) 149-159 assessed several stats packages, and some came out rather badly - you can guess which was worst, by far! NIST provide some test datasets http://www.itl.nist.gov/div898/strd/ against which code can be judged (and some naive algorithms fail badly). Although I can see the benefits of an STL-style, I also have some difficulty in imagining how the results returned can be other than reals? Even if we 'input' integer types, although sum can sensibly also be integer, I have some difficulty in seeing how the the mean, variance etc are useful as integer types? And to expose the unsuspecting user to the risk of surprise seems unhelpful? Benefits from STL-style would be most obvious if can be applied to a circular buffer into which new data can be fed while stats can be recalculated Kalman filter style. While calculating the mean and variance, it is probably worth calculating the higher two skew and kurtosis too. And of course the median (and some percentiles) are also often more useful than the mean. Finally, there is the unsolved matter of the math functions we still badly need. Confidence intervals are more informative than standard deviations etc. Paul Dr Paul A Bristow, hetp Chromatography Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Garland > Sent: Tuesday, February 11, 2003 4:19 PM > To: Boost mailing list > Subject: RE: [boost] Any interest in a stats class > > > Scott K wrote: > > > Hi all, > > I have a small family of statistics classes which I have used from time > > to time. The one I use most often is simply called stats. > > Here's an example of it's use: > > ...details snipped... > > I'm sure there are folks interested in statistical (and other) > functions. I've developed exactly this sort of class in the > past so I understand the utility. However, I suspect some of > us would hope statistical algorithms to be formulated as STL > Algorithm extensions. Specifically concerning statistics see: > > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?STLAlgo rithmExtensions/StatisticsAlgorithms > > and more generally: > > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?STLAlgo rithmExtensions > > We definitely need volunteers to take these rough Wiki musings and > convert them into actual documented libraries. I'm not sure this > is what you had in mind, but I, for one, would welcome your effort > either way! > > Jeff > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Request: BOOST_ENABLE_LONG_LONG
On Thu, 13 Feb 2003 11:52:59 -, "John Maddock" <[EMAIL PROTECTED]> wrote: [..] >I hear what you say, but I keep coming back to: this is largely an Intel >compiler specific problem, No, it's a matter of not making a silent use of non standard features. >and most users really do expect their libraries >to support long long whenever the compiler does. Maybe. But we can't second such attitudes. Otherwise someone might expect __complex__, or incomplete enumeration types. Where do you stop? >Personally I don't want to >have to answer a flood of questions along the lines of "why doesn't >some_type_trait work correctly?" Oh, that's really underestimating users' intelligence. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
Rene Rivera <[EMAIL PROTECTED]> writes: > [2003-02-11] Beman Dawes wrote: > >>At 09:01 AM 2/10/2003, Toon Knapen wrote: >> >> >I think the traffic-light colors should suffice. I find adding black >> >confusing. >> >>I agree. The traffic-light metaphor falls apart when you add black. > > Yea, but black is used in the regresion tests themselves. How does it not > fall appart there? > > Do we just get rid of black, and the 48 hour test become green? Or is there > some better way to show age? Whatever we do with color, most of the text that needs to be readable should be black on white. That's been shown to be most readable for most people, on average. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Borland specific defects : new config defines?
On Thu, 13 Feb 2003 12:01:47 -, "John Maddock"
<[EMAIL PROTECTED]> wrote:
>I'm not sure if this is due to a compiler bug or what, but basically it's
>due to the way that STLport is set up: the names are declared in namespace
>stlport (which is an alias for either _STL or _STLD depending upon the
>build), and then imported into std with:
>
>namespace std{
>using namespace stlport;
>}
>
>in STLports _suffix.h. This works fine for most cases, but not when the
>name is already present in namespace std (as is the case with the is*
>functions for example).
Ah! I didn't realize this was the case! Yes, that's how qualified
lookup for namespace members works; if there's a direct declaration of
the searched name in the nominated namespace then any using directive
contained therein is ignored (for the purpose of looking up the name).
Strictly speaking, the standard refers that rule to user-declared
namespaces, not std. However... :-)
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [test] revision two
> > Hi, everybody > > > > Today I committed second revision to Boost.Test library. > > Wow, is that a good idea one day before we branch for release? I should have done it week ago, but was really sick. Anyway, It does not contain anything that should break backward compartibility. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] random: request for Box-Muller implementation of normal_d istribution
Sure.
In NR they propose to do pretty much what
you are doing, but they made one step further to avoid sin/cos calls.
Here is the code from NR:
if (iset == 0) { //We don't have an extra
deviate handy, so
do {
v1=2.0*ran1(idum)-1.0;
//pick two uniform numbers in the square extending
//from -1 to +1 in each direction, v2=2.0*ran1(idum)-1.0;
rsq=v1*v1+v2*v2;
// see if they are in the unit circle,
} while (rsq >= 1.0
|| rsq == 0.0); //and if they are not, try again.
fac=sqrt(-2.0*log(rsq)/rsq);
//Now make the
Box-Muller transformation to get two normal deviates. Return one and
//save the other for
next time.
gset=v1*fac;
iset=1; //Set flag.
return v2*fac;
} else
{ //We have
an extra deviate handy,
iset=0;
//so unset the flag,
return gset;
//and return it.
}
As I mentioned before switching to this
schema improved performance of my app by 20%.
App is doing monte-carlo simulation, it
spends majority of the time generating normally distributed random numbers, but
does some other calculation as well, so performance improvement is even bigger.
-Original Message-
From: Matthias Troyer
[mailto:[EMAIL PROTECTED]]
Sent: Thursday,
February 13, 2003 12:27 AM
Can you elaborate as to what the difference between
Box-Muller and the implemented method is? As far as I understand Box-Muller it
is just the implemented algorithm.
[boost] Shared Boost library compiled with HP aCC
Title: Message Hello, Did somebody manage to link shared library with HP aCC and run the jgrep example ? It links but the excutable crashed !! (OK with the library is static built) Thanks. Pascal.
Re: [boost] Status of Boost, Solaris and Sun WorkShop 6 Compiler?
Gary Gale <[EMAIL PROTECTED]> writes: > I've noticed that toolsets for the Sun WorkShop C++ compiler, both with and > without STLport support have appeared in boost/tools/build/. > > Does anyone on the list have any indication as to when this compiler will > make it to "fully supported" status? > > I've seen previous mailings that suggest that support for the WorkShop > compiler is in progress; if other list members are actively following this > up then I'd be happy to join in (as deadlines permit of course!). We don't really have a notion of "fully supported" here, except on a library-by-library basis at the discretion of individual developers. That said, the level of support for Sun compilers is likely to depend on two things in the future: 1. Sun's willingness to address the serious bugs in their compiler implementation which prevent much progress at all from being made. Given a reasonably well-conforming compiler, little specific attention should be needed in order to get most things working well. 2. Someone stepping up to run regular regression tests on Sun, and someone at Boost getting them set up to do it. I believe someone at Mentor Graphics volunteered to run the tests, but I think we may have dropped the ball on our side. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [test] revision two
"Gennadiy Rozental" <[EMAIL PROTECTED]> writes: > Hi, everybody > > Today I committed second revision to Boost.Test library. Wow, is that a good idea one day before we branch for release? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Sockets - what's the latest?
I'm just a lurker and maybe I missed something, but what you describe sounds like SCTP (RFC 2960 - the 'other' stream protocol). If the generic socket library supported SCTP, would that meet your requirements? Jason House <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: cc: boost-bounces@list Subject: [boost] Re: Sockets - what's the latest? s.boost.org 02/12/2003 03:11 PM Please respond to Boost mailing list Once I heard there was a generic socket library in development, I thought I'd add a quick feature request. I would like to see the ability to have multiple streams through the same socket. Having had recent issues with a game and a proxy/firewall, I thought that I might try and see if I can do a long shot that might have beneficial results for the future... The problem with games, is that they try to form multiple connections between client and host. This boils down to providing two distinct benefits. 1: Programs can easily perform complex communications over a single port. 2: Without multiple streams, problems can occur when there are multiple clients behind a proxy connecting to a host outside of the proxy. If the client only forms a single connection to the host, there won't be a problem because the random source port will differentiate each stream. So, when multiple clients connect to a host from behind a proxy, the host can only differentiate each stream by the random source port. So, when the clients form a second connection to the host, each stream gets differentiated from each other, but there is no mapping of random source port ot the distinct client. Example of #2. Computers A & B connect to host H through proxy P. The host will see the following connections: P:1 => H:1 P:2 => H:1 P:3 => H:2 P:4 => H:2 There is no way to pair connections on H:2 with connections on H:1 Now, without a proxy, it would be A:1 => H:1 B:2 => H:1 B:3 => H:2 A:4 => H:2 Now, it is very clear how to pair the connections... both connections from A go together, and both connections from B go together. Of course, this might not be a role specifically for a new stream type, It could just be a wrapper of some kind. From the library standpoint, the wrapper kind of adds a distinctive type of functionality... I would like to somehow make it easy and intuitive for somebody considering multiple connections between two computers to use this different socket form instead. If it remains as an obscure combination of libraries, or as something unimplemented, it is likely that programs requiring multiple connections per client process to hit issues with proxy servers. I'm interested to see what kind of reaction this creates from the list :) Is it normal to add a default wrapper to a library in order to make a common form of usage easier? I guess that the class responsible for handing how multiple streams gets multiplexed could be made into some kind of template parameter... "Michel André" wrote: > > Anyone who was working on it - what's the current state of play? The > > flurry of mail on here a while back seemed to fizzle out. Is that > > because development has stalled? > > If I can help out with what limited time and knowledge of the subject > > I have I will. I really want to see this library in boost, a
[boost] mem_fun & iterator_adaptors
Hi
Consider this case of boost::mem_fn applied to data members and in
association with boost::iterator_adaptors.
#include
#include
struct foo {
int m_data;
// ..
};
std::vector data;
...
boost::make_projection_iterator(data.begin(), boost::mem_fn(&foo::m_data))
The line above "should" IMHO work, but with the current impl (VC7, latest
CVS) it ends up as a reference-to-reference problem. I believe this is a
very important and common(?) use-case.
What's the rationale for mem_fn to (in the case of data members) make it's
return_type a reference? Should mem_fn change to use a "plain" typedef (like
std::unary_function) or could iterator_adaptor perhaps mangle the input type
to avoid the reference-to-reference problem?
(I haven't tested with the sandbox iterator_adaptor v2 though)
Regards
/Fredrik Blomqvist
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::ref for function objects
On Thursday 13 February 2003 10:12 am, Peter Dimov wrote: > > --Compatibility-- > > This version of ref.hpp is backwards-compatible with the existing > > version of > > ref.hpp on a compiler that can handle the new ref.hpp (needs partial > > specialization and proper SFINAE handling). At some point I'll write a > > stripped-down version that other compilers can handle. > > I tried to do this once and failed. It's hard to make operator() work on > deficient compilers (esp. the zero-arg version that is not a template) > without breaking ref(x) where x is not a function object. Yep, this is the killer. Can't try to use result_type because it might not be there, can't detect result_type on broken compilers, and can't stop the declaration from being instantiated :(. Could just go with the limitation that arity 0 function objects won't work unless a return type is specified by the user. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::ref for function objects
Douglas Gregor wrote: > We've discussed making boost::ref/boost::cref work for arbitrary > functions > objects before. I just committed a version of ref.hpp that supports > this > ability to the sandbox. With this code, you can write: > > std::transform(c.begin(), c.end(), out, boost::ref(f)); > > or, if you don't want the return type deduced, specify it as in > Boost.Bind: > > std::transform(c.begin(), c.end(), out, boost::ref(f)); > > Features of this implementation: > - Return type deduction (discussed below) > - Argument type deduction (discussed below) > - Able to handle function objects that have multiple arities (e.g., > can be > invoked with 0 or 2 arguments) That's very nice! [...] > --Compatibility-- > This version of ref.hpp is backwards-compatible with the existing > version of > ref.hpp on a compiler that can handle the new ref.hpp (needs partial > specialization and proper SFINAE handling). At some point I'll write a > stripped-down version that other compilers can handle. I tried to do this once and failed. It's hard to make operator() work on deficient compilers (esp. the zero-arg version that is not a template) without breaking ref(x) where x is not a function object. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 'optional' - request for extension
- Original Message -
From: "Anthony Williams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Thursday, February 13, 2003 7:05 AM
Subject: Re: [boost] 'optional' - request for extension
> Aleksey Gurtovoy writes:
> >
> > The following is a sketch of a potential use case for the
newly-accepted and
> > already very useful 'optional' class.
> >
I'm glad to see optional<> being already exercised!
> > Suppose you have a pure RAII guard/locker which unconditionally does
its
> > job:
> >
> > struct RAII_lock
> > : boost::noncopyable
> > {
> > RAII_lock(entity& e);
> > ~RAII_lock();
> > };
> >
> > and you want to write a semantic equivalent to the following
> >
> > boost::scoped_ptr lock( cond ? new RAII_lock(entity) :
0 );
> > // ...
> >
> > expect for the dynamic allocation part. How would you do it?
> >
> > IMO the following seems only natural:
> >
> > boost::optional lock( cond, entity );
> > // ...
> >
> > The only problem with the above is that currently you cannot write
something
> > like this. It would be nice if we could, IMO.
> >
> > Thoughts?
>
OK, I can see the motivation: We can have a noncopyable class
and need an optional object of it.
Following optional semantics, it would be spelled:
boost::optional lock;
if ( cond )
lock.reset( RAII_lock(entity) ) ;
But there is a probem: as William pointed out, reset() _needs_
to use T::T(T const&) in order acquire its own copy of the object;
but in this case is noncopyable, so the above won't compile.
> * Firstly, this would require optional to be able hold
non-copy-constructible
> types, whereas the current requirement say "T must be CopyConstructible".
>
Indeed.
> You could drop the "CopyConstructible" requirement if you said that
> boost::optional is only itself CopyConstructible/Assignable/Swappable
if T
> is CopyConstructible.
Right.
>However, this leaves the question of how to get the
> value in there in the first place; the answer to which is ...
>
With the current implementation it is possible to construct the contained
object in-place.
> * Secondly, you would need a templated constructor to allow T to be
constructed
> using another type.
>
Exactly.
One possibility would be add additional templated ctor and reset that just
forward the arguments to T's contructor
(optional's interface could use a trailing tag to differentiate these).
A problem with this is that the Argument Forwarding problem is burried
into optional's itself.
Another approach would be to create a generic delay-factory object and just
let
optional use it:
Something like:
template
struct in_place_factory0
{
in_place_factory0 ( A0& a0_ ) : a0(a0_) {}
T* operator() ( void* address ) const { return new (address) T(a0) ; }
A0& a0 ;
} ;
template
in_place_factory0 in_place ( A0& a0 ) { return
in_place_factory0(a0) ; }
which requires the following changes in optional<>:
template
class optional
{
public :
template
explicit optional ( Factory f )
:
m_initialized(false)
{
construct_inplace(f);
}
...
private :
template
void construct_inplace ( Factory f )
{
f(m_storage.address());
m_initialized = true ;
}
} ;
The above would allow something like this:
optional l( in_place(entity) );
If the same in-place idiom is used on reset(), the complete
solution will look, following optional<>'s way:
boost::optional lock;
if ( cond )
lock.reset( in_place(entity) );
What do you think?
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Weak ref. via atomicity (RE: Smart pointers:...)
Alexander Terekhov wrote:
[...]
> Pavel Vasiliev wrote:
>> I place here the corrected version of my previous code.
> Well,
> Given: two threads -- A and B,
>thread A has "strong" one,
>thread B has "weak" one,
>strong_count == 1, weak_count == 2.
> Thread A, in release_strong:
>atomic_decrement(&strong_count) == 0,
> Thread B, in acquire_strong_from_weak:
>lock,
>see atomic_increment(&strong_count) > 0,
>(strong_count == 1, weak_count == 2)
>return true (and unlock),
>...
>enter release_strong()
>atomic_decrement(&strong_count) == 0,
>enter strong_refs_lost(),
>see strong_count == 0,
>set strong_count < 0,
>unlock,
>destroy,
>enter release_weak(),
>atomic_decrement(&weak_count) == 1,
>(strong_count < 0, weak_count == 1)
>...
>enter release_weak(),
>atomic_decrement(&weak_count) == 0,
>destruct_self()
> Thread A, enter strong_refs_lost():
Yeah... This attempt failed :-(. Thanks for preventing me from getting
into troubles!
However,
> WHA.. Nah, Lukashenko retires and establishes peace and democracy in
> the Middle East. ``Not bad.'' ;-)
I'd better leave my code as is. Or even dereference a NULL-pointer :-).
[...]
> pthread_refcount_decrement() // with msync for proper mut.obj-cleanup
> pthread_refcount_decrement_nomsync() // without any msync whatsoever
"nomsync" here stands for "no memory view update even when counter drops
to 0"? If yes, then you probably should not use it in
> void release_weak() {
>int status = pthread_refcount_decrement_no_msync(&weak_count);
>if (PTHREAD_REFCOUNT_DROPPED_TO_ZERO == status)
> destruct_self();
> }
Consider the following:
> Given: two threads -- A and B,
>thread A has "strong" one,
>thread B has "weak" one,
>strong_count == 1, weak_count == 2.
Thread A releases the last "strong" reference.
destruct_object() deletes p_object AND modifies the refs instance
(e.g. sets p_object to NULL for debug reasons).
strong_count == 0, weak_count == 1
Thread B releases the last "weak" reference.
release_weak() calls destruct_self() on expired memory view.
"Or am I just missing and/or misunderstanding something?" :-)
Pavel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: BGL bfs and dfs
> > > > I'm using customized-internal properties that do not have 'color' > > information. Now, algorithms (undirected_dfs() for example) need to map > > each vertex and edge to its respective color, so in the previous case, the > > maps must be passed as arguments to the algorithms (OTOH, if I were using > > color_maps for both vertex and edge internal properties, the > > bgl_named_params<> version of the function would do the job, and I wouldn't > > care about the mapping.) That's what I meant when I said that having > > internal properties requires the mapping . > > Understood. You can't attach vertex_color like adjacency_list class allows, > right? No, because that template parameter was already taken by my custom-property. > > You're right. Did you overload add_vertex() and/or add_edge() functions to > > receive the 'property' container or a std::back_insert_iterator (pointing > > to the prop. cont.)? > > No, I've made the [] method of property map resize the underlying vector if > index is out of range. Quite simple. That'll be for vertex_map. If one's using std::map<> as the edge-color-map, no more actions are needed because the value is simply stored in the map if the key doesn't exist. > Rereading my sentence, I understand that is was poorly worded. I meant that I > should be able to create, for every kind of graph, external property map that > will work without requiring me to manually assign indices. That'd be nice! > > > >Specifically, for all graphs both vertex_descriptor and > > > edge_descriptor should be comparable, so that you can use map directly. > > > > Can you tell me more about this? AFAIK, vertex_descriptor is of type size_t > > (vecS) and edge_descriptor is of type ::boost::detail::edge_base<>. > > I meant that > std::map< typename graph_traits::vertex_descriptor>, int> > and > std::map< typename graph_traits::edge_descriptor>, int> Is here 'int' the index of the vertex/edge container? > > should always work, regardless of the type 'G'. size_t will work now (although > inefficient). But edge_base<> is not comparable, so it won't work. I think > it should have operator< That would be nice. Then I could create a map like: std::map::edge_descriptor, default_color_type> as an external edge-color-map, without the need of put() and get() overloading. I think that's the best solution! Specifically, if line 688 of boost/boost/graph/detail/adjacency_list.hpp would have returned : this->m_source < other.m_source || (!(other.m_source < this->m_source) && this->m_target < other.m_target), then edge mapping would have been simpler. > I think that edge_descriptor should contain edge index inside it. When you > create new edge, the next free index is allocated from a list of free indices > (or num_edges(g) is used). When you delete edge, it's index is added to > the list of free indices. This design requires one extra int per edge, plus > the store of free indices --- the max number of edges graph ever had, > in the worsts case, but probably quite little in practice. What's the advantage to have an edge-index stored? The only one that comes to my mind is to use it as edge-container index; however, if this is the case, all indeces should be updated every time an edge is added or deleted. > > > > In both cases, you should be able to write > > > > > > edge_property_map::type pm; > > > > > > and have it work. What do you think? > > > > AFAIK, that's for internal properties. Please correct me if I'm wrong. > > I don't know what this syntax does now :-) I mean that this or similiar syntax > should be used to find the type suitable for external property map. > > > > I think that external property maps should be improved, like I describe > > > > above > > > > > or it some other way. It hits me quite often. > > > > I guess you're refering to the documentation; if that's the case, I agree. > > Documentation hits me too. But I would also like to be able to provide > external properties for edges easily. Agree completely! > > - Volodya > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > vladimir josef sykora morphochem AG gmunder str. 37-37a 81379 muenchen tel. ++49-89-78005-0 fax ++49-89-78005-555 [EMAIL PROTECTED] http://www.morphochem.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [PRB] boost.function and Visual Age
On Thursday 13 February 2003 06:12 am, Markus Schöpflin wrote: > Hi there, > > currently, boost.function and Visual Age don't get along very well. > Unfortunately, I have no idea where to start in order to fix the problems. > > Could anyone please take a look at the regression logs and give me a > hint where to start? That doesn't look good at all. function_n_test is the first testcase to work on, but it's giving some frightening errors: "/home/auto/schoepf/src/extern/boost-cvs/libs/function/test/function_n_test.cpp", line 596.3: 1540-0130 (S) "boost::function1" is not declared. "/home/auto/schoepf/src/extern/boost-cvs/libs/function/test/function_n_test.cpp", line 636.5: 1540-0130 (S) "boost::function2" is not declared. My first inclination would be to check the preprocessed output of the test, because it's possible that the preprocessor is failing miserably. Look for valid definitions of boost::function0, boost::function1, etc. (You can send me the preprocessed output privately if you'd like) Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Reflection system in C++ using templates
On Thursday 13 February 2003 01:01 am, Lin Xu wrote: > Attached is a prelimary replacement for function_traits.hpp. (When should I > use the files section on yahoo? When should I attach? copy and paste code > inline?) If it's really short, post a context diff. If it's short, attach. If it's longer than short, put it in the sandbox or files section. > I added specializations for member function pointers, and for those > specializations, a typedef class_type which is the class type of the > pointer. For no-PTS compilers I added a set of template functions for > function pointers. I would have expected that for member function pointers arg1_type would be typedef cv class_type* arg1_type; (where cv is the cv-qualifiers from the member function pointer). > Unfortunely when I tried to test this by doing: > cout << boost::function::arity << endl; > The following errors occured: > main.cpp: In instantiation of `boost::function_traits': > main.cpp:33: instantiated from here > main.cpp:33: base class `boost::detail::function_traits_helper (A::**)()>' >has incomplete type > It looks like the add_pointer doesn't know what to do with member function > pointers. It knows what to do, it just doesn't do what we want. The add_pointer should only be performed when is_pointer::value is false. > This may affect many things, so I didn't touch anything else :) > > Would this affect boost::function? (from what I know it has some kind of > member function pointer adaptor?) It won't affect boost::function (which doesn't even use function_traits). boost::signal could be affect, but only if function_traits stops working for function types. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Patch for function/function_base.hpp
Dave Gomboc wrote: > > > Ah, that's the reason. But given my recent discomfort about > > unmaintainable code, look at it again: > > > > # if BOOST_WORKAROUND(__HP_aCC, <= 33900) > > template struct enable_if; > > # else > > template struct enable_if; > > # endif > > > > Does this really makes sense? Shouldn't we just keep one version with > > names for template parameters? AFAICS this should work for all compilers > > and it could be a general boost coding guideline to always provide names > > for template parameters. Comments? > > Nah, the vendors will never fix problems that we hide. In some regular > code I might just switch it, but since some vendors _are_ using Boost to > test their compiler conformance, we should leave the HP workaround in (and > use the same or a new workaround for VisualAge also). That way, when they > compile with BOOST_NO_CONFIG they will see the problem. It's a reasonable approach. Another one might be a macro called BOOST_UNUSED_TEMPLATE_PARAMETER which will be used like BOOST_STATIC_CONSTANT and resolves to nothing for conforming compilers and leaves a dummy name in for broken compilers. Usage: template< BOOST_UNUSED_TEMPLATE_PARAMETER( bool, cond ), BOOST_UNUSED_TEMPLATE_PARAMETER( typename, T ) > struct enable_if; Note that I do not prefer this style, I just want to mention another option. I think it's still better than #ifdef's but I won't bother too much if there is one coding guideline which could solve all issues. Boost is already too complicated to add political/educational stuff for compiler vendors instead of adding just the technically needed stuff for compilers. We could continue by adding BOOST_FOR to replace all for-loops in case a compiler has broken scope for declared variables. For conforming compilers: #define BOOST_FOR for and for broken compilers: #define BOOST_FOR if(false);else for there are so many ways to obfuscate the code... hehe... Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Linker trouble when building regex lib
That's exactly what happened! What an a**e! Thanks for replies Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Maddock Sent: 13 February 2003 11:11 To: Boost mailing list Subject: Re: [boost] Linker trouble when building regex lib > I'm newish to C++ and very new to boost. > > I've just tried to build the object library for regex > in Borland Builder 5 Pro on Windows XP. I ran the make > on bcb5, got no errors at that stage, but when I try to compile my app > within the Builder IDE I get a fatal linker error: Cannot load > BOOST_REGEX_BCB5_MDI.LIB. Any ideas? Sounds like you didn't install the libraries with: make -fbcb5.mak install Regards, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Patch for function/function_base.hpp
On Thursday 13 February 2003 04:38 am, Daniel Frey wrote: > Ah, that's the reason. But given my recent discomfort about > unmaintainable code, look at it again: > > # if BOOST_WORKAROUND(__HP_aCC, <= 33900) > template struct enable_if; > # else > template struct enable_if; > # endif > > Does this really makes sense? Shouldn't we just keep one version with > names for template parameters? AFAICS this should work for all compilers > and it could be a general boost coding guideline to always provide names > for template parameters. Comments? FWIW, I didn't apply the patch directly but instead changed it to what you ask: template struct enable_if; I'd be fine with making this a coding guideline... Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] typ_traits documentation nitpick
boost::is_polymorphic documentation is written in a slightly larger font
than the rest of the items and there's also a spelling error ('magority')
in the following text.
/Fredrik
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] bad links in regression table logs
I notice that the links to the source files and library documentation in the regression test tables are broken: should they be directed to www.boost.org rather than sourceforge.net/boost ? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Request: BOOST_ENABLE_LONG_LONG
> >> Could we subordinate BOOST_HAS_LONG_LONG to > >> defined(BOOST_ENABLE_LONG_LONG)? > > > >Even if we're willing to break user code and tell them they have to > >define that macro explicitly, we'd have to be very careful; we have > >tests that exercise long long and we don't want to break those or > >disable that part of the testing. > > Yes. Those tests would simply have to #define BOOST_ENABLE_LONG_LONG. > All the rest would remain the same. > > The idea was for defined(BOOST_ENABLE_LONG_LONG) to be a necessary > (but not sufficient) condition to *define* BOOST_HAS_LONG_LONG. At the > point of usage one would still deal with BOOST_HAS_LONG_LONG only, and > the typical code snippet involving long long would still appear as: > > #ifdef BOOST_HAS_LONG_LONG > ... > #endif > > > (Maybe the idea is clearer if one mentally renames BOOST_HAS_LONG_LONG > to BOOST_USE_LONG_LONG) I hear what you say, but I keep coming back to: this is largely an Intel compiler specific problem, and most users really do expect their libraries to support long long whenever the compiler does. Personally I don't want to have to answer a flood of questions along the lines of "why doesn't some_type_trait work correctly?", remember that we already have had a minor flood of requests for better long long support in various libraries (mainly integer). So... under what conditions should we not define BOOST_HAS_LONG_LONG for the Intel compiler - is this a version thing - I thought all recent EDG front ends defined __NO_LONG_LONG when it's not available? (How do the platform headers detect whether long long is supported or not?) I guess we could also add BOOST_DISABLE_LONG_LONG as well if it's really required. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Borland specific defects : new config defines?
> >The two defects are:
> >The various std::isdigit, islower, isalnum etc. convenience functions
> >will not compile.
>
> Please could you post a concrete example?
#include
int main()
{
return std::isupper('c', std::locale()); // error overload not found.
}
but can be fixed with:
#include
namespace std{
using stlport::isupper;
}
int main()
{
return std::isupper('c', std::locale()); // OK got it now
}
I'm not sure if this is due to a compiler bug or what, but basically it's
due to the way that STLport is set up: the names are declared in namespace
stlport (which is an alias for either _STL or _STLD depending upon the
build), and then imported into std with:
namespace std{
using namespace stlport;
}
in STLports _suffix.h. This works fine for most cases, but not when the
name is already present in namespace std (as is the case with the is*
functions for example).
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Request for Config Macro( was RE: [boost] Re: [test] "unix"identification )
> So, Let introduce one. I need something for coming release. Done: it's called BOOST_HAS_SIGACTION John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Fix for some Interval library tests
> At 10:07 PM 2/7/2003, Dave Gomboc wrote: > >> I suggest adding another boost defect: BOOST_BROKEN_ADL (or similar) > > > >How about BOOST_LIBRARY_IMPL_VULNERABLE_TO_ADL? It's not that the > >compiler's ADL implementation is broken, it's that the library > >implementation isn't protected against ADL lookups where it needs to be. > > The rule-of-thumb is to begin these deficiency macros with BOOST_NO_ to > make it clear a conforming implementation does not need the macro. > > So BOOST_NO_STD_LIB_ADL_PROTECTION might be a better name. > > John Maddock is really the gatekeeper for this sort of macro, and he is > also familiar with the Borland compiler. John, what do you think? Sorry to be dense, but I don't understand the issue (I admit I haven't been following this thread) do you have simple a test case? Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Linker trouble when building regex lib
> I'm newish to C++ and very new to boost. > > I've just tried to build the object library for regex > in Borland Builder 5 Pro on Windows XP. I ran the make > on bcb5, got no errors at that stage, but when I try to compile > my app within the Builder IDE I get a fatal linker error: > Cannot load BOOST_REGEX_BCB5_MDI.LIB. Any ideas? Sounds like you didn't install the libraries with: make -fbcb5.mak install Regards, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Patch for function/function_base.hpp
> Ah, that's the reason. But given my recent discomfort about > unmaintainable code, look at it again: > > # if BOOST_WORKAROUND(__HP_aCC, <= 33900) > template struct enable_if; > # else > template struct enable_if; > # endif > > Does this really makes sense? Shouldn't we just keep one version with > names for template parameters? AFAICS this should work for all compilers > and it could be a general boost coding guideline to always provide names > for template parameters. Comments? Nah, the vendors will never fix problems that we hide. In some regular code I might just switch it, but since some vendors _are_ using Boost to test their compiler conformance, we should leave the HP workaround in (and use the same or a new workaround for VisualAge also). That way, when they compile with BOOST_NO_CONFIG they will see the problem. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
At 11:38 AM 2/12/2003, Rene Rivera wrote: >[2003-02-11] Beman Dawes wrote: > >>At 09:01 AM 2/10/2003, Toon Knapen wrote: >> >> >I think the traffic-light colors should suffice. I find adding black >> >confusing. >> >>I agree. The traffic-light metaphor falls apart when you add black. > >Yea, but black is used in the regresion tests themselves. How does it not >fall appart there? > >Do we just get rid of black, and the 48 hour test become green? Or is there >some better way to show age? SourceForge CVS browsing used a scheme where recent commits are reported as "n hours", less recent as "n days", still less recent as "n weeks", and really old files as "n months". One the release happens, there will be a set of tests for 1_30_0 which will grow old, yet there is nothing wrong with that. I'm wondering if the hour/day/week/month scheme would work better, particularly for those release tests? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Heap question
Hello, I am implementing an algorithm that requires a heap. In my algorithm, I need to do two operations, similar to that required by Dijkstra's algorithm: 1. Use a secondary array to index the nodes of the heap. This is so that a node in the heap can be found in constant time. 2. Decrease the key (priority) of a node in the heap. The Boost heap implementation (http://www.boost.org/libs/pri_queue/heap.html) supports the decrease-key operation. But reading the documentation, I'm not sure if the first requirement is satisfied. If I index the nodes using iterators, then what I require is for these iterators to be valid even after the heap is changed, eg after insertion, deletion or decreasing the key. Is that the case? Thanks. __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
On Wednesday 12 February 2003 17:38, Rene Rivera wrote: > [2003-02-11] Beman Dawes wrote: > > >At 09:01 AM 2/10/2003, Toon Knapen wrote: > > > > >I think the traffic-light colors should suffice. I find adding black > > >confusing. > > > >I agree. The traffic-light metaphor falls apart when you add black. > > Yea, but black is used in the regresion tests themselves. How does it not > fall appart there? you've got a point there ! > Do we just get rid of black, and the 48 hour test become green? Or is there > some better way to show age? I would suggest to just use 3 colors : or black, yellow and red or green, yellow and red using both green and black is confusing. These colors should be used for the both the regression overview as well as the regression-logs per platform IMHO toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Status of Boost, Solaris and Sun WorkShop 6 Compiler?
-Original Message- From: Gary Gale [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 10:35 AM To: Boost Mailing List ([EMAIL PROTECTED]) Subject: [boost] Status of Boost, Solaris and Sun WorkShop 6 Compiler? I've noticed that toolsets for the Sun WorkShop C++ compiler, both with and without STLport support have appeared in boost/tools/build/. Does anyone on the list have any indication as to when this compiler will make it to "fully supported" status? I've seen previous mailings that suggest that support for the WorkShop compiler is in progress; if other list members are actively following this up then I'd be happy to join in (as deadlines permit of course!). Gary -- Gary Gale Mail: [EMAIL PROTECTED] Senior Formscape Architect Phone: +44 (0)1252 618731 Formscape Software Ltd Web: www.formscape.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Copyright in Jam files
Boosters, with one (1) day before the branch for release, there's still time to get those copyright statements in place without needing to merge and tag the files - please try to add them as soon as possible. As we've just recently concluded that copyright statements are needed for the various build files too, we need some extra focus on that before 1.30.0. There has been great improvement during the last few weeks with regards to "soft errors" such as missing copyright statements, erroneous line endings and tabs, broken links in HTML files, and other minor nuisances that may not be so rewarding to fix but definitely add to the overall quality once taken care of. Thanks to all for the progress, and keep up the good work! Cheers, Bjorn Karlsson ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Operator result type inference
I noticed that boost::lambda library has a complete implementation of the type inference for the operator results (i.e. inferring that char + int returns an int). I would really like to be able to use that in my code, however, the Lambda implementation is currently undocumented. What's the entry point for that code? Are there any tests/examples? Miro ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: BGL bfs and dfs
vladimir josef sykora wrote: > > > Having internal properties means the mapping edge_descriptor -> 'edge > > > color' and vertex_descriptor -> 'vertex color' is needed. > > > > I don't understand what you mean, > > I'm using customized-internal properties that do not have 'color' > information. Now, algorithms (undirected_dfs() for example) need to map > each vertex and edge to its respective color, so in the previous case, the > maps must be passed as arguments to the algorithms (OTOH, if I were using > color_maps for both vertex and edge internal properties, the > bgl_named_params<> version of the function would do the job, and I wouldn't > care about the mapping.) That's what I meant when I said that having > internal properties requires the mapping . Understood. You can't attach vertex_color like adjacency_list class allows, right? > > > For vertex-color > > > mapping this is straightforward because vertex_descriptor is of type > > size_t > > > > (when using vectS) and the mapping can be easily implemented with a > > > random-access container. > > > > Unless your graph can grow! You'd have to automatically grow container > > then, > > > if you want to continue using the same property map. I've implemented > > such a property map, but so far, Jeremy has not commented. > > You're right. Did you overload add_vertex() and/or add_edge() functions to > receive the 'property' container or a std::back_insert_iterator (pointing > to the prop. cont.)? No, I've made the [] method of property map resize the underlying vector if index is out of range. Quite simple. > > > However, for edge-color mapping this is not the > > > case. I did it using std::map, color_type>, > > and > > > > of course, overloading put() and get(), not without first inspecting > > that > > > > edge_descriptor type has two data-members: m_source, and m_target, so > > the > > > > functions would look like: > > > > I always though that you should be able to add external edge / vertex > > property > > > to every graph. > > I guess you're saying "customized properties": i.e. properties that are not > provided by the BGL. I doubt that external properties could be attached to > the graph (at least I don't know how); once the internal properties are > taken, external maps are needed. One can concatenate properties though, but > then the bgl_named_params<> version of the algorithms won't work anymore. Rereading my sentence, I understand that is was poorly worded. I meant that I should be able to create, for every kind of graph, external property map that will work without requiring me to manually assign indices. > >Specifically, for all graphs both vertex_descriptor and > > edge_descriptor should be comparable, so that you can use map directly. > > Can you tell me more about this? AFAIK, vertex_descriptor is of type size_t > (vecS) and edge_descriptor is of type ::boost::detail::edge_base<>. I meant that std::map< typename graph_traits::vertex_descriptor>, int> and std::map< typename graph_traits::edge_descriptor>, int> should always work, regardless of the type 'G'. size_t will work now (although inefficient). But edge_base<> is not comparable, so it won't work. I think it should have operator< > > > For some kinds of graph, vertices and edges should have automatically > > assigned > > > indices. > > Of course, since vertices and edges are strored in Sequences, and they > inherently have indices. The point is how to enumerate them > comprehensively. For vertices is no problem: one can do: vertex-number = > sequence-index. But what happens with edges? For example, what happens when > I want to get the edge connecting v1 with v2? Which scalar should I assign > to that edge? What BGL does is navigate through the whole out-edge-list of > v1 until an edge is found that has v2 for target. Otherwise the edge is not > found. But there's no way in constant time to check if an edge exists or > not. I think that edge_descriptor should contain edge index inside it. When you create new edge, the next free index is allocated from a list of free indices (or num_edges(g) is used). When you delete edge, it's index is added to the list of free indices. This design requires one extra int per edge, plus the store of free indices --- the max number of edges graph ever had, in the worsts case, but probably quite little in practice. > > In both cases, you should be able to write > > > > edge_property_map::type pm; > > > > and have it work. What do you think? > > AFAIK, that's for internal properties. Please correct me if I'm wrong. I don't know what this syntax does now :-) I mean that this or similiar syntax should be used to find the type suitable for external property map. > > I think that external property maps should be improved, like I describe > > above > > > or it some other way. It hits me quite often. > > I guess you're refering to the documentation; if that's the case, I agree. Documentation hits me too. But I would also like to be abl
[boost] Re: Weak ref. via atomicity (RE: Smart pointers:...)
Pavel Vasiliev wrote: [...] > Interestingly. pthread_refcount_enroll_one() in your implementation > really eliminates need in any explicit locking. I hope so. Yeah, as you wrote ...problem is much the same: "test and conditionally increment" . > > Your code showed also that I overlooked the more simple way to deal > with weak_count. To satisfy aesthetic feelings ^^ ;-) > I place here the corrected version of my previous code. Well, Given: two threads -- A and B, thread A has "strong" one, thread B has "weak" one, strong_count == 1, weak_count == 2. Thread A, in release_strong: atomic_decrement(&strong_count) == 0, Thread B, in acquire_strong_from_weak: lock, see atomic_increment(&strong_count) > 0, (strong_count == 1, weak_count == 2) return true (and unlock), ... enter release_strong() atomic_decrement(&strong_count) == 0, enter strong_refs_lost(), see strong_count == 0, set strong_count < 0, unlock, destroy, enter release_weak(), atomic_decrement(&weak_count) == 1, (strong_count < 0, weak_count == 1) ... enter release_weak(), atomic_decrement(&weak_count) == 0, destruct_self() Thread A, enter strong_refs_lost(): WHA.. Nah, Lukashenko retires and establishes peace and democracy in the Middle East. ``Not bad.'' ;-) Well, presuming that I'm NOT missing and/or misunderstanding something with respect to the "flow" above, a sort of "moral" is that you should better NOT increment a ZERO count... unless you *really* wish to have something along the lines of: http://groups.google.com/groups?selm=3D021EA4.E2217C09%40web.de (Subject: Re: Objects in container: creation and deletion details) with Zombies, resurrection [God rules], etceteras. And, BTW, < Forward Inline > Original Message Newsgroups: comp.programming.threads Subject: Re: threadsafe reference counting Alexander Terekhov wrote: > > < kinda pthread_refcount_t-"SKETCHv3" > Here's the "updated" SKETCH: PTHREAD_REFCOUNT_MAX // upper bound PTHREAD_REFCOUNT_INITIALIZER(N) // macro for statics INIT pthread_refcount_init() // mutex like but with initial value pthread_refcount_destroy() // also mutex like pthread_refcount_getvalue() // see "COW_AtomicInt3" string example pthread_refcount_setvalue() // see "COW_AtomicInt3" string example pthread_refcount_increment() // without any msync whatsoever pthread_refcount_add() // without any msync but with r.checking pthread_refcount_decrement() // with msync for proper mut.obj-cleanup pthread_refcount_subtract() // with msync and with r.checking pthread_refcount_decrement_nomsync() // without any msync whatsoever pthread_refcount_subtract_nomsync() // without any msync but with r.checking pthread_refcount_enroll_one()// without any msync whatsoever pthread_refcount_enroll_many() // without any msync but with r.checking pthread_refcount_attr_*()// PROCESS_SHARED and etc. attr-stuff std::size_t as "value type" // for get/set/add/... "value" param PTHREAD_REFCOUNT_DROPPED_TO_ZERO // for pthread_refcount_decrement*() // and pthread_refcount_sub() to // indicate "dropped to zero" condition // that MAY be used to safely destroy // associated ref.counted object or // simply continue -- increment/setval // also used for weak->strong "enrolls" // by pthread_refcount_enroll_one() and // pthread_refcount_enroll_many() Uhmm, as WW-aka-Attila says... Kapis? Comments/suggestions/objections/whatever? (an essay from David Butenhof would be greatly appreciated as well ;-) ) regards, alexander. -- http://www.usenix.org/publications/library/proceedings/c++94/full_papers/ellis.a ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Weak ref. via atomicity (RE: Smart pointers:...)
Pavel Vasiliev wrote:
[...]
> pthread_refcount_enroll_one() (== "increment_if_non_zero()") may be
> emulated in Win32 (using InterlockedCompareExchange()).
Yeah, archaic Win95(/Intel386) aside. AFAIK, InterlockedCompareExchange
(/cmpxchg) "Requires Windows 98 or later" (/486+).
>
> The problem is what to do on e.g. current Unix'es + GCC.
> Alternatives are either wait for pthread_refcount_t in many pthreads
> implementations or to explicitly use inline assembler(s).
>
> Other alternatives?
>
> The problem is so obvious that the question may be thought rhetorical.
> But I really ask whether you have some suggestions.
http://lists.boost.org/MailArchives/boost/msg30364.php
("> Well, I guess...")
regards,
alexander.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [PRB] boost.function and Visual Age
Hi there,
currently, boost.function and Visual Age don't get along very well.
Unfortunately, I have no idea where to start in order to fix the problems.
Could anyone please take a look at the regression logs and give me a
hint where to start?
Some examples of the error messages are:
"/home/auto/schoepf/src/extern/boost-cvs/libs/function/test/allocator_test.cpp",
line 63.16: 1540-0064 (S) Syntax error: "(" was expected but "," was
found.
"/home/auto/schoepf/src/extern/boost-cvs/libs/function/test/function_arith_cxx98.cpp",
line 19.39: 1540-1118 (S) The declaration of "f" uses the undefined
class "boost::function >" when
the class must be complete.
"/home/auto/schoepf/src/extern/boost-cvs/libs/function/test/stateless_test.cpp",
line 44.3: 1540-0130 (S) "boost::function2" is not declared.
Markus
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] condition::notify_all
I was just looking at the win32 implementation of the condition variable class in the thread library and noticed something odd. In version 1.7 of condition.cpp, there is a bug fix for condition::notify_one. At the beginning of the function, a mutex is acquired, but not all control paths resulted in the mutex being released. Part of the fix involved making sure that the mutex is always released. However, it looks like the same behavior still exists in the current version of condition.cpp for notify_all (win32)--not all control paths will release the mutex. Am I mistaken, or is this a bug? Also, the BOOST_HAS_MPTASKS version of notify_one looks like it has the same bug as the win32 version in version 1.6 of condition.cpp. --Scott McCaskill __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Status of Boost, Solaris and Sun WorkShop 6 Compiler?
I've noticed that toolsets for the Sun WorkShop C++ compiler, both with and without STLport support have appeared in boost/tools/build/. Does anyone on the list have any indication as to when this compiler will make it to "fully supported" status? I've seen previous mailings that suggest that support for the WorkShop compiler is in progress; if other list members are actively following this up then I'd be happy to join in (as deadlines permit of course!). Gary -- Gary Gale Mail: [EMAIL PROTECTED] Senior Formscape Architect Phone: +44 (0)1252 618731 Formscape Software Ltd Web: www.formscape.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Patch for function/function_base.hpp
Markus Schöpflin wrote: > > Daniel Frey wrote: > > > Markus Schöpflin wrote: > > >>This was the original source: > >> > >>template struct enable_if; > >>---^ > >> > >>Visual Age doesn't like this, it needs a name here. > > > > ^^ > > > > Ah, that's the reason. But given my recent discomfort about > > unmaintainable code, look at it again: > > > > # if BOOST_WORKAROUND(__HP_aCC, <= 33900) > > template struct enable_if; > > # else > > template struct enable_if; > > # endif > > > > Does this really makes sense? Shouldn't we just keep one version with > > names for template parameters? AFAICS this should work for all compilers > > and it could be a general boost coding guideline to always provide names > > for template parameters. Comments? > > Agreed, if it works for all compilers, let's just keep the version > with the names. (And add a comment that it should stay like it is!) No, don't add a comment. Let's make it a boost coding guideline, otherwise we will clutter the code again with comments instead of workarounds. Remember that this is only one example of a line with template parameters. Would you like to add a comment for every line all over boost? Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: BGL bfs and dfs
> > Having internal properties means the mapping edge_descriptor -> 'edge > > color' and vertex_descriptor -> 'vertex color' is needed. > > I don't understand what you mean, I'm using customized-internal properties that do not have 'color' information. Now, algorithms (undirected_dfs() for example) need to map each vertex and edge to its respective color, so in the previous case, the maps must be passed as arguments to the algorithms (OTOH, if I were using color_maps for both vertex and edge internal properties, the bgl_named_params<> version of the function would do the job, and I wouldn't care about the mapping.) That's what I meant when I said that having internal properties requires the mapping . > > > For vertex-color > > mapping this is straightforward because vertex_descriptor is of type size_t > > (when using vectS) and the mapping can be easily implemented with a > > random-access container. > > Unless your graph can grow! You'd have to automatically grow container then, > if you want to continue using the same property map. I've implemented such > a property map, but so far, Jeremy has not commented. You're right. Did you overload add_vertex() and/or add_edge() functions to receive the 'property' container or a std::back_insert_iterator (pointing to the prop. cont.)? > > > However, for edge-color mapping this is not the > > case. I did it using std::map, color_type>, and > > of course, overloading put() and get(), not without first inspecting that > > edge_descriptor type has two data-members: m_source, and m_target, so the > > functions would look like: > > I always though that you should be able to add external edge / vertex property > to every graph. I guess you're saying "customized properties": i.e. properties that are not provided by the BGL. I doubt that external properties could be attached to the graph (at least I don't know how); once the internal properties are taken, external maps are needed. One can concatenate properties though, but then the bgl_named_params<> version of the algorithms won't work anymore. >Specifically, for all graphs both vertex_descriptor and > edge_descriptor should be comparable, so that you can use map directly. Can you tell me more about this? AFAIK, vertex_descriptor is of type size_t (vecS) and edge_descriptor is of type ::boost::detail::edge_base<>. > > For some kinds of graph, vertices and edges should have automatically assigned > indices. Of course, since vertices and edges are strored in Sequences, and they inherently have indices. The point is how to enumerate them comprehensively. For vertices is no problem: one can do: vertex-number = sequence-index. But what happens with edges? For example, what happens when I want to get the edge connecting v1 with v2? Which scalar should I assign to that edge? What BGL does is navigate through the whole out-edge-list of v1 until an edge is found that has v2 for target. Otherwise the edge is not found. But there's no way in constant time to check if an edge exists or not. > > In both cases, you should be able to write > > edge_property_map::type pm; > > and have it work. What do you think? AFAIK, that's for internal properties. Please correct me if I'm wrong. > > (The autonumbering can be implemented without much overhead, it seems to me). > > > unsigned int source=key.m_source; > > unsigned int target=key.m_target; > > if(source>target) std::swap(source,target);// canonizing for > > undirected graph > > Will this work for directed graph? If not, I think you should assert that > Graph is undirected. For directed graphs, just get rid of the canonization. Then (v1,v2) != (v2,v1). The strict weak ordering is preserved. > > I think that external property maps should be improved, like I describe above > or it some other way. It hits me quite often. I guess you're refering to the documentation; if that's the case, I agree. > > - Volodya > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > vladimir josef sykora morphochem AG gmunder str. 37-37a 81379 muenchen tel. ++49-89-78005-0 fax ++49-89-78005-555 [EMAIL PROTECTED] http://www.morphochem.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Patch for function/function_base.hpp
Daniel Frey wrote: Markus Schöpflin wrote: When posting the patch, I didn't even realize that the code was legal and that this is a problem with VACPP6. And the aCC workaround fixes the problem for VA, too. This was the original source: template struct enable_if; ---^ Visual Age doesn't like this, it needs a name here. ^^ Ah, that's the reason. But given my recent discomfort about unmaintainable code, look at it again: # if BOOST_WORKAROUND(__HP_aCC, <= 33900) template struct enable_if; # else template struct enable_if; # endif Does this really makes sense? Shouldn't we just keep one version with names for template parameters? AFAICS this should work for all compilers and it could be a general boost coding guideline to always provide names for template parameters. Comments? Agreed, if it works for all compilers, let's just keep the version with the names. (And add a comment that it should stay like it is!) Markus ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] suggest a "select" in mpl
Hi,
The "for-each" in mpl is used to generate codes, which apply some function to each
element in a sequence. Well, I wonder if there could be more generators, "select"(a
better name?) for example.
"select" is used to apply some function to a specified element in a sequence(the case
in the FSM example, not each element). So it could be used to generate codes like the
"if-else/switch" structure. Here's an example.
#include
#include "select.hpp"
#include
struct find_helper {
private:
const double* X_; // array
const double& a_; // element to be found
int& pos_; // result, position of the given element
public:
find_helper(const double* X, const double& a, int& pos)
: X_(X), a_(a), pos_(pos) {}
bool operator ()(int i)
{
if(X_[i] == a_)
{
pos_ = i;
return true;// "true" means it's been handled
}
return false; // "false" means to continue
}
};
template
struct find_element_c {
static int do_(T* X, const T& a)
{
int r = N;
mpl::select< // "select" returns true if
mpl::range_c//the functor has been applied,
>(find_helper(X, a, r)); // otherwise false.
return r;
}
};
#include
int main()
{
double X[5] = {1.0, 2.1, 3.5, 6.6, 5.4};
std::cout << find_element_c::do_(X, 3.5) << std::endl;
}
output: 2
The generated code might look like:
if(X[0] == 3.5)
return 0;
if(X[1] == 3.5)
return 1;
if(X[2] == 3.5)
return 2;
if(X[3] == 3.5)
return 3;
if(X[4] == 3.5)
return 4;
The implementation of the "select" template could be rather similar to "for_each".
namespace boost {
namespace mpl {
namespace aux {
template
struct select_impl
{
template<
typename Iterator
, typename LastIterator
, typename TransformFunc
, typename F
>
static bool execute(
Iterator*
, LastIterator*
, TransformFunc*
, F
)
{
return false;
}
};
template <>
struct select_impl
{
template<
typename Iterator
, typename LastIterator
, typename TransformFunc
, typename F
>
static bool execute(
Iterator*
, LastIterator*
, TransformFunc*
, F f
)
{
typedef typename Iterator::type item;
typedef typename apply1::type arg;
value_initialized x;
if(aux::unwrap(f, 0)(boost::get(x)))
return true;
typedef typename Iterator::next iter;
return select_impl::value>::execute(
(iter*)0, (LastIterator*)0, (TransformFunc*)0, f);
}
};
} // namespace aux
template<
typename Sequence
, typename TransformOp
, typename F
>
inline
bool select(F f, Sequence* = 0, TransformOp* = 0)
{
typedef typename begin::type first;
typedef typename end::type last;
typedef typename lambda::type transform_op;
return aux::select_impl< boost::is_same::value >::execute(
(first*)0, (last*)0, (transform_op*)0, f);
}
template<
typename Sequence
, typename F
>
inline
bool select(F f, Sequence* = 0)
{
return select >(f);
}
} // namespace mpl
} // namespace boost
Regards,
Jonathan Wang
[EMAIL PROTECTED]
2003-02-13
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 'optional' - request for extension
Aleksey Gurtovoy writes:
>
> The following is a sketch of a potential use case for the newly-accepted and
> already very useful 'optional' class.
>
> Suppose you have a pure RAII guard/locker which unconditionally does its
> job:
>
> struct RAII_lock
> : boost::noncopyable
> {
> RAII_lock(entity& e);
> ~RAII_lock();
> };
>
> and you want to write a semantic equivalent to the following
>
> boost::scoped_ptr lock( cond ? new RAII_lock(entity) : 0 );
> // ...
>
> expect for the dynamic allocation part. How would you do it?
>
> IMO the following seems only natural:
>
> boost::optional lock( cond, entity );
> // ...
>
> The only problem with the above is that currently you cannot write something
> like this. It would be nice if we could, IMO.
>
> Thoughts?
* Firstly, this would require optional to be able hold non-copy-constructible
types, whereas the current requirement say "T must be CopyConstructible".
You could drop the "CopyConstructible" requirement if you said that
boost::optional is only itself CopyConstructible/Assignable/Swappable if T
is CopyConstructible. However, this leaves the question of how to get the
value in there in the first place; the answer to which is ...
* Secondly, you would need a templated constructor to allow T to be constructed
using another type.
Or you could initialize it with optional, since this template
constructor does already exist, and already does the "right thing".
* Thirdly, you would need a special custom constructor which takes a conditional.
You could get round it like below:
boost::optional optionalEntity;
if(cond)
optionalEntity.reset(entity);
// if optionalEntity is not initialized, neither is lock
// else lock is constructed using the conversion constructor
boost::optional lock(optionalEntity);
You can do this with the current implementation, since the CopyConstructible
requirement isn't actually verified with a concept check, but you'd have to
get the requirement dropped if you were to rely on it (which would probably
mean implementing templated constructor/reset/operator= to avoid _having_ to
use an optional to initialize your optional)
HTH
Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Patch for function/function_base.hpp
Markus Schöpflin wrote: > > Daniel Frey wrote: > > > On Wed, 12 Feb 2003 18:37:51 +0100, Markus Schöpflin wrote: > > > >> Attached is a small patch for function_base.hpp. On line 302, > >> there is a T missing. > > > > Just a stupid question: Why is it "missing"? What is this patch > > supposed to fix? > > This was the original source: > > template struct enable_if; > ---^ > > Visual Age doesn't like this, it needs a name here. ^^ Ah, that's the reason. But given my recent discomfort about unmaintainable code, look at it again: # if BOOST_WORKAROUND(__HP_aCC, <= 33900) template struct enable_if; # else template struct enable_if; # endif Does this really makes sense? Shouldn't we just keep one version with names for template parameters? AFAICS this should work for all compilers and it could be a general boost coding guideline to always provide names for template parameters. Comments? Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [test] revision two
Hi, everybody Today I committed second revision to Boost.Test library. I am not planning any more code changes in this release. If I have time I will try to reflect changes made in revision one and two in documentation (Release notes with changes log will be present in any case). Here is approximate list of things that came with this revision: * XML log format is introduced Now user willing to automate errors processing could get a log in XML format. Command line switch is introduced that manage log format: --log_format=[XML|HRF] will force XML or human readable format respectively. * XML report format is introduced Now user willing to automate results analysis could get a result report in XML format. Command line switch is introduced that manage report format: --report_format=[XML|HRF] will force XML or human readable format respectively. * Command line option --output_format is introduced that both log/report format simultaneously * BOOST_CHECK_NO_THROW test tool is introduced Name says it all. * BOOST_BITWISE_CHECK test tool is introduced Allows to perform bitwise comparisons of the two arguments provided. Will report as many errors as many bits mismatch. Mismatch position is reported. * Documentation default palette changed to white * Components examples and test documentation page is introduced. Now all test/examples links lead to this page that has summary information about all of them, that include expected output, type of test and so on. * Signal handling selection algorithm fixed. It's tentative fix, that will need to be substituted with BOOST_HAS_SIGACTION checks once they are introduce. Current change allowed to use signal handling with gcc on win32 also. * C strings usage in minimized as much as possible. * class_properties header modified to use Boost.Preprocessor for friends declaration * other minor changes and bug fixes Let me know about any issues. Regards, Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] 'optional' - request for extension
The following is a sketch of a potential use case for the newly-accepted and
already very useful 'optional' class.
Suppose you have a pure RAII guard/locker which unconditionally does its
job:
struct RAII_lock
: boost::noncopyable
{
RAII_lock(entity& e);
~RAII_lock();
};
and you want to write a semantic equivalent to the following
boost::scoped_ptr lock( cond ? new RAII_lock(entity) : 0 );
// ...
expect for the dynamic allocation part. How would you do it?
IMO the following seems only natural:
boost::optional lock( cond, entity );
// ...
The only problem with the above is that currently you cannot write something
like this. It would be nice if we could, IMO.
Thoughts?
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Patch for function/function_base.hpp
Daniel Frey wrote: On Wed, 12 Feb 2003 18:37:51 +0100, Markus Schöpflin wrote: Attached is a small patch for function_base.hpp. On line 302, there is a T missing. Just a stupid question: Why is it "missing"? What is this patch supposed to fix? This was the original source: template struct enable_if; ---^ Visual Age doesn't like this, it needs a name here. Marus ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
