[boost] Re: Patch for function/function_base.hpp
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? Regards, Daniel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Reflection system in C++ using templates
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?)
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.
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'
has incomplete type
It looks like the add_pointer doesn't know what to do with member function
pointers.
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?)
Lin Xu
_
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
// Copyright (C) 2000 John Maddock ([EMAIL PROTECTED])
//
// Permission to copy and use this software is granted,
// provided this copyright notice appears in all copies.
// Permission to modify the code and to distribute modified code is granted,
// provided this copyright notice appears in all copies, and a notice
// that the code was modified is included with the copyright notice.
//
// This software is provided "as is" without express or implied warranty,
// and with no claim as to its suitability for any purpose.
#ifndef BOOST_TT_FUNCTION_TRAITS_HPP_INCLUDED
#define BOOST_TT_FUNCTION_TRAITS_HPP_INCLUDED
#include
#include
#include
namespace boost {
#ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
namespace detail {
template struct function_traits_helper;
template
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 0);
typedef R result_type;
};
template
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 1);
typedef R result_type;
typedef T1 arg1_type;
};
template
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 2);
typedef R result_type;
typedef T1 arg1_type;
typedef T2 arg2_type;
};
template
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 3);
typedef R result_type;
typedef T1 arg1_type;
typedef T2 arg2_type;
typedef T3 arg3_type;
};
template
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 4);
typedef R result_type;
typedef T1 arg1_type;
typedef T2 arg2_type;
typedef T3 arg3_type;
typedef T4 arg4_type;
};
template
typename T5>
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 5);
typedef R result_type;
typedef T1 arg1_type;
typedef T2 arg2_type;
typedef T3 arg3_type;
typedef T4 arg4_type;
typedef T5 arg5_type;
};
template
typename T5, typename T6>
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 6);
typedef R result_type;
typedef T1 arg1_type;
typedef T2 arg2_type;
typedef T3 arg3_type;
typedef T4 arg4_type;
typedef T5 arg5_type;
typedef T6 arg6_type;
};
template
typename T5, typename T6, typename T7>
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 7);
typedef R result_type;
typedef T1 arg1_type;
typedef T2 arg2_type;
typedef T3 arg3_type;
typedef T4 arg4_type;
typedef T5 arg5_type;
typedef T6 arg6_type;
typedef T7 arg7_type;
};
template
typename T5, typename T6, typename T7, typename T8>
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 8);
typedef R result_type;
typedef T1 arg1_type;
typedef T2 arg2_type;
typedef T3 arg3_type;
typedef T4 arg4_type;
typedef T5 arg5_type;
typedef T6 arg6_type;
typedef T7 arg7_type;
typedef T8 arg8_type;
};
template
typename T5, typename T6, typename T7, typename T8, typename T9>
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 9);
typedef R result_type;
typedef T1 arg1_type;
typedef T2 arg2_type;
typedef T3 arg3_type;
typedef T4 arg4_type;
typedef T5 arg5_type;
typedef T6 arg6_type;
typedef T7 arg7_type;
typedef T8 arg8_type;
typedef T9 arg9_type;
};
template
typename T5, typename T6, typename T7, typename T8, typename T9,
typename T10>
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 10);
typedef R result_type;
typedef T1 arg1_type;
typedef T2 arg2_type;
typedef T3 arg3_type;
typedef T4 arg4_type;
typedef T5 arg5_type;
typedef T6 arg6_type;
typedef T7 arg7_type;
typedef T8 arg8_type;
typedef T9 arg9_type;
typedef T10 arg10_type;
};
template
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 0);
typedef Class class_type;
typedef R result_type;
};
template
struct function_traits_helper
{
BOOST_STATIC_CONSTANT(int, arity = 1);
typedef Class class_type;
typedef R result_type;
typedef T1 arg1_type;
}
Re: [boost] random: request for Box-Muller implementation of normal_distribution
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. On Wednesday, February 12, 2003, at 09:30 AM, Lapshin, Kirill wrote: Hello all, We've noticed that normal_distribution using polar method, rather then Box-Muller. Is there a particular reason for not using Box-Muller? Looks to me like a quite an easy way to improve performance. The method with source code is described in Numerical Recipes. Changing current code to Box-Muller is just a few line code change. It improved performance of one of my apps by 20%, so the normal_distribution performance was even bigger. __ Kirill Lapshin 410-230-1123
[boost] Re: Request for const fix in unit_test_suite.hpp
Sure. Fixed. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Reflection system in C++ using templates
On Wednesday 12 February 2003 09:11 pm, Lin Xu wrote: > Hm... > - Function if the compiler supports PTS; > - If not, then the user would have to type in something like: > Function0. > > Looks good. Another (slightly offtopic) thing. I attempted to use > function_traits with a member function type. GCC spat out errors, and > looking at the source code I don't think it *should* work anyway. Correct? > If so, shouldn't there be an additional set of specializations for > function_traits that specialize for member function pointers? Right. function_traits was intended to work with function types (not function pointers, even), because that's what boost::function needed, but I'd be happy to see it extended to support member function pointers. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::ref for function objects
On Wednesday 12 February 2003 07:15 pm, David Abrahams wrote: > Douglas Gregor <[EMAIL PROTECTED]> writes: > > 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)); > > What's the key feature? Overloaded operator() on reference_wrapper? Yes. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Reflection system in C++ using templates
Hm... - Function if the compiler supports PTS; - If not, then the user would have to type in something like: Function0. Looks good. Another (slightly offtopic) thing. I attempted to use function_traits with a member function type. GCC spat out errors, and looking at the source code I don't think it *should* work anyway. Correct? If so, shouldn't there be an additional set of specializations for function_traits that specialize for member function pointers? Lin Xu. _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::ref for function objects
Douglas Gregor <[EMAIL PROTECTED]> writes: > 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)); What's the key feature? Overloaded operator() on reference_wrapper? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Sockets - what's the latest?
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 to a heavy workload > on my daytime job. But we certainly like some feedback on the progress so > far. Have we choosen a dead end or a viable path. The implementation in the > sandbox has been compiled with gcc/cygwin, bcc and vc6.0 and vc7.0. So we > need some input on porting to Unix especially the asynchrounous parts. > > So I would say that we have a long road to travel to finnish implementation, > produce documentation test cases and all that. And when we have come that > far there is the formal review and i guess there will be a lot of heat when > that will come ;). > > So I wouldn't count on sockets to be a part of boost for some time (unless > of course someone else submits another proposal or helps me and Hugo out on > what we have so far to speed the progess). > > Regards > /Michel > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::ref for function objects
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) The implementation is here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost-sandbox/boost-sandbox/boost/ref.hpp?rev=HEAD&content-type=text/plain Testcases are here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost-sandbox/boost-sandbox/libs/utility/ref_call_test.cpp?rev=HEAD&content-type=text/plain --Return type deduction-- - If the user specifies a return type, use it - Otherwise, if the class has a result_type typedef, use it - Otherwise, use Boost.Lambda-style sig::type --Argument type deduction-- - If typedefs arg1_type, arg2_type, ..., argN_type are available, use _precisely_ those argument types (as in Boost.Function) to define operator()(arg1_type), operator()(arg1_type, arg2_type), etc, up to 'N' for that particular class. - Otherwise, if the class has an argument_type typedef, define operator()(const argument_type&). If the class also has first_argument_type and second_argument_type, define operator()(const first_argument_type&, const second_argument_type&); - Otherwise, if the class has first_argument_type and second_argument_type, define operator()(const first_argument_type&, const second_argument_type&); - Otherwise, define a bunch of function templates that deduce the argument types at call time, e.g., template return-type-as-mentioned-before operator()(T1&, T2&, ..., TN&); There is always an operator() that takes no arguments. --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. The stripped-down version will feel a lot more like boost::bind: - Return type deduction will be limited to using a user-supplied return type, or else using ::result_type - Argument type deduction won't look for argN_types, argument_type, or first/second_argument_type, but will fall back to the set of function templates that deduce the argument types from the call. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [build] request for modification.
Beman Dawes <[EMAIL PROTECTED]> writes: > I've gone ahead and committed the change to CVS, but wonder if this is > really the option Ron wanted?. Intel's docs say: > > >-Qansi_alias directs the compiler to assume the following: > >Arrays are not accessed out of bounds. > > > >Pointers are not cast to non-pointer types, and vice-versa. > > > >References to objects of two different scalar types cannot alias. For > >example, an object of type int cannot alias with an object of type float, > >or an object of type float cannot alias with an object of type double. > > > >If your program satisfies the above conditions, setting the -Qansi_alias > >flag will help the compiler better optimize the program. However, if > your >program does not satisfy one of the above conditions, the > -Qansi_alias flag > >may lead the compiler to generate incorrect code. Seems to me it can't possibly be what Ron was after; that's all optimization-related stuff, not diagnostic-related as Ron wants. However, Ron was asking about Intel C++ for Linux; I presume you were messing with the windows version? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: regression tests on Aix
At 09:48 AM 2/12/2003, Markus Schöpflin wrote: >I just updated the regression tests for AIX for both Visual Age 5 and >Visual Age 6 and I will try to update at least once a week until Toon >gets access to another maching. Thanks! >On a side note, how do the compiler version numbers get into the >status tables? They don't show up for AIX and the comments in the >toolset jam file seem to indicate, that they somehow should. The version numbers are supposed to be extracted from the config_info.output file, which is part of the residue left by bjam. Let's see... The program scans for "version ", but the message in vacpp.hpp doesn't have that. Fixed in CVS. Thanks again! --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Minimal test tool - very minor comments & spellchecking documentation
Thanks - I couldn't find 'spell' or 'spelling' in the Frontpage 'help'! Paul > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Beman Dawes > Sent: Wednesday, February 12, 2003 4:31 PM > To: Boost mailing list; Boost mailing list > Subject: RE: [boost] Re: Re: Minimal test tool - very minor comments & > spell checking documentation > > > At 05:07 AM 2/11/2003, Paul A. Bristow wrote: > > >As for spell checking, MS FrontPage astonishingly doesn't appear to > include > >a spelling checker ... > > MS FrontPage has had a spell checker for years. Select "tools" menu, click > "page options...", and select the spelling options you prefer. > > HTH, > > --Beman > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Sockets - what's the latest?
> 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 to a heavy workload on my daytime job. But we certainly like some feedback on the progress so far. Have we choosen a dead end or a viable path. The implementation in the sandbox has been compiled with gcc/cygwin, bcc and vc6.0 and vc7.0. So we need some input on porting to Unix especially the asynchrounous parts. So I would say that we have a long road to travel to finnish implementation, produce documentation test cases and all that. And when we have come that far there is the formal review and i guess there will be a lot of heat when that will come ;). So I wouldn't count on sockets to be a part of boost for some time (unless of course someone else submits another proposal or helps me and Hugo out on what we have so far to speed the progess). Regards /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Sockets - what's the latest?
On Wednesday, February 12, 2003, at 05:53 AM, Phil Nash 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? I was going to chime in. I found the project docs at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/ wiki.pl?BoostSocket , but could not find an email address for contact. I can help with the design, though I'd probably cause fewer arguments as an implementor (why oh why does everyone always want to shoehorn UDP datagrams into a std::iostream interface?). Anyway, I've got many years experience on true BSD Sockets as well as close-enough APIs (WinSock, BeOS Network Kit) and proprietary designs like Apple's OpenTransport. I'm currently only set up to do implementation tasks on Mac and Windows, but if necessary could install Linux on one of my PCs. Whoever is organizing the Boost Sockets effort, feel free to contact me personally, and we can talk about what needs getting done. -- Brian Gray -- [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Patch for signals/trackable.hpp
On Wednesday 12 February 2003 12:41 pm, Markus Schöpflin wrote: > Attached is a small patch for signals/trackable.hpp. According to > 7.1.1(8), the mutable keyword cannot be applied on reference members > and Visual Age flags this as an error. I just removed the mutable > keyword an it compiles fine afterwards. > > Markus Thanks again. Applied. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Patch for function/function_base.hpp
On Wednesday 12 February 2003 12:37 pm, Markus Schöpflin wrote: > Attached is a small patch for function_base.hpp. On line 302, there is > a T missing. > > Markus Thanks. Applied. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: peak_of() proposal
Jon Kalb wrote: [...] > I'm afraid that I don't see your point. How is this relevant? It will prevent you to encounter this situation (if peak_of() is used only with smart_ptr<>s). peak_of() won't have to deal with it. It would also be possible to assert the parameter of peak_of() is valid, but only at run-time (less efficient). Philippe ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: A new boost::thread implementation?
Peter Dimov said:
> William E. Kempf wrote:
R result() const
{
boost::mutex::scoped_lock lock(m_mutex);
while (!m_result)
m_cond.wait(lock);
>>>
>>> This changes result()'s semantics to "block until op() finishes";
>>> what happens if nobody calls op()? Or it throws an exception?
>>
>> Changes the semantics? I thought this was what was expected and
>> illustrated in every example thus far?
>
> No, my example throws an exception when the call hadn't been made. It
> would also throw when the call has been made but did not complete due to
> an exception, had I added a try block in operator() that eats the
> exception.
Would work, but can complicate (not prevent) usage patterns where the
future<> is shared across threads. However, see below.
future(const future& other)
{
mutex::scoped_lock lock(m_mutex);
>>>
>>> I don't think you need a lock here, but I may be missing something.
>>
>> I have to double check the implementation of shared_ptr<>, but I was
>> assuming all it did was to synchronize the ref count manipulation.
>> Reads/writes of the data pointed at needed to be synchronized
>> externally.
>
> Yes, you are right. The lock is necessary to achieve the level of thread
> safety that you implemented. I think that a "thread neutral" (as safe as
> an int) future<> would be acceptable, since this is the thread safety
> level I expect from lightweight CopyConstructible components, but that's
> not a big deal.
I was focusing on making the type sharable across threads in a thread safe
manner. However, stepping back and thinking on it, I think that may have
been the wrong approach. Most usage patterns won't involve this sharing,
so paying the cost for synchronization regardless is probably not a good
idea. I think it would be better to take the "thread neutral" approach.
Thanks for getting me to think about this issue.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Patch for signals/trackable.hpp
Attached is a small patch for signals/trackable.hpp. According to
7.1.1(8), the mutable keyword cannot be applied on reference members
and Visual Age flags this as an error. I just removed the mutable
keyword an it compiles fine afterwards.
Markus
Index: trackable.hpp
===
RCS file: /cvsroot/boost/boost/boost/signals/trackable.hpp,v
retrieving revision 1.11
diff -c -r1.11 trackable.hpp
*** trackable.hpp 4 Feb 2003 12:20:06 - 1.11
--- trackable.hpp 12 Feb 2003 17:26:20 -
***
*** 183,189
{
}
! mutable std::vector& bound_objects;
};
} // end namespace detail
} // end namespace BOOST_SIGNALS_NAMESPACE
--- 183,189
{
}
! std::vector& bound_objects;
};
} // end namespace detail
} // end namespace BOOST_SIGNALS_NAMESPACE
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: A new boost::thread implementation?
William E. Kempf wrote:
> Sorry for late reply... had a hard disk problem that prevented
> accessing e-mail.
>
> Peter Dimov said:
>> William E. Kempf wrote:
[...]
>>> void operator()()
>>> {
>>> mutex::scoped_lock lock(m_mutex);
>>> if (m_result)
>>> throw "can't call multiple times";
>>
>> operator() shouldn't throw; it's being used as a thread procedure,
>> and
>> the final verdict on these was to terminate() on exception, I
>> believe.
>> But you may have changed that. :-)
>
> I'm not sure how the terminate() on exception semantics (which haven't
> changed) apply, exactly.
Operator() should not report errors with exceptions because no one could
possibly listen. It's being executed in a separate thread, and if an
exception escapes, terminate() will be called.
In my example, I omitted the try block in operator() since I didn't want to
implement the exception translation logic, but such a try block is
necessary. Thread procedures effectively have a throw() specification.
> But I assume you (and probably Dave) would
> prefer this to just be an assert and documented undefined behavior. I
> have no problems with that.
I would prefer a second call to either complete, overwriting the result, or
to be silently ignored.
>>> R result() const
>>> {
>>> boost::mutex::scoped_lock lock(m_mutex);
>>> while (!m_result)
>>> m_cond.wait(lock);
>>
>> This changes result()'s semantics to "block until op() finishes";
>> what happens if nobody calls op()? Or it throws an exception?
>
> Changes the semantics? I thought this was what was expected and
> illustrated in every example thus far?
No, my example throws an exception when the call hadn't been made. It would
also throw when the call has been made but did not complete due to an
exception, had I added a try block in operator() that eats the exception.
>>> future(const future& other)
>>> {
>>> mutex::scoped_lock lock(m_mutex);
>>
>> I don't think you need a lock here, but I may be missing something.
>
> I have to double check the implementation of shared_ptr<>, but I was
> assuming all it did was to synchronize the ref count manipulation.
> Reads/writes of the data pointed at needed to be synchronized
> externally.
Yes, you are right. The lock is necessary to achieve the level of thread
safety that you implemented. I think that a "thread neutral" (as safe as an
int) future<> would be acceptable, since this is the thread safety level I
expect from lightweight CopyConstructible components, but that's not a big
deal.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Patch for function/function_base.hpp
Attached is a small patch for function_base.hpp. On line 302, there is
a T missing.
Markus
Index: function_base.hpp
===
RCS file: /cvsroot/boost/boost/boost/function/function_base.hpp,v
retrieving revision 1.57
diff -c -r1.57 function_base.hpp
*** function_base.hpp 7 Feb 2003 14:03:35 - 1.57
--- function_base.hpp 12 Feb 2003 17:21:27 -
***
*** 299,305
# if BOOST_WORKAROUND(__HP_aCC, <= 33900)
template struct enable_if;
# else
! template struct enable_if;
# endif
template struct enable_if { typedef T type; };
--- 299,305
# if BOOST_WORKAROUND(__HP_aCC, <= 33900)
template struct enable_if;
# else
! template struct enable_if;
# endif
template struct enable_if { typedef T type; };
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: A new boost::thread implementation?
David Abrahams said:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
>>> From: David Abrahams <[EMAIL PROTECTED]>
>>> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>>
>>> > It's a tool that allows high-level interfaces to be built. Whether
>>> people will want/need to build their own high-level interfaces is
>>> another story.
>>>
>>> I think it's a valuable question to ask whether /everyone/ will want
>>> to create /the same/ high-level interface ;-). In other words, as
>>> long as we have a bunch of low-level thread primitives, I prefer to
>>> reduce interface complexity and increase encapsulation unless we can
>>> find a specific use for a medium-level interface.
>>
>> How about this compromise:
>
>
>
> I don't want either of these to have a separate function (operator() in
> this case) which initiates the call, for reasons described earlier
>
> My suggestion:
>
> template
> class future
> {
> public:
> template
> future(F const& f, Executor const& e)
> : m_pimpl(new async_call(f))
> {
> (*get())();
> }
>
> future(const future& other)
> {
> mutex::scoped_lock lock(m_mutex);
> m_pimpl = other.m_pimpl;
> }
>
> future& operator=(const future& other)
> {
> mutex::scoped_lock lock(m_mutex);
> m_pimpl = other.m_pimpl;
> }
>
> R result() const
> {
> return get()->result();
> }
>
> private:
> shared_ptr > get() const
> {
> mutex::scoped_lock lock(m_mutex);
> return m_pimpl;
> }
>
> shared_ptr > m_pimpl;
> mutable mutex m_mutex;
> };
>
> // Not convinced that this helps, but...
> template
> R result(future const& f)
> {
> return f.result();
> }
>
> ...and I don't care whether async_call gets implemented as part of the
> public interface or not, but only because I can't see a compelling
> reason to have it yet.
OK. Thanks for the input. I go from here.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: A new boost::thread implementation?
Peter Dimov said: > William E. Kempf wrote: >> >> It's not just the efficiencies that concern me with dynamic >> allocation. It's the additional points of failure that occur in this >> case as well. For instance, check out the article on embedded coding >> in the most recent CUJ (sorry, don't have the exact title handy). >> Embedded folks generally avoid dynamic memory when ever possible, so >> I'm a little uncomfortable with a solution that mandates that the >> implementation use dynamic allocation of memory. At least, if that's >> the only solution provided. > > This allocation isn't much different than the allocation performed by > pthread_create. An embedded implementation can simply impose an upper > limit on the total number of async_calls and never malloc. True enough. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: A new boost::thread implementation?
Sorry for late reply... had a hard disk problem that prevented accessing
e-mail.
Peter Dimov said:
> William E. Kempf wrote:
>>
>> How about this compromise:
>>
>> template
>> class async_call
>> {
>> public:
>> template
>> explicit async_call(const F& f)
>> : m_func(f)
>> {
>> }
>>
>> void operator()()
>> {
>> mutex::scoped_lock lock(m_mutex);
>> if (m_result)
>> throw "can't call multiple times";
>
> operator() shouldn't throw; it's being used as a thread procedure, and
> the final verdict on these was to terminate() on exception, I believe.
> But you may have changed that. :-)
I'm not sure how the terminate() on exception semantics (which haven't
changed) apply, exactly. But I assume you (and probably Dave) would
prefer this to just be an assert and documented undefined behavior. I
have no problems with that.
>> lock.unlock();
>> R temp(m_func());
>> lock.lock();
>> m_result.reset(temp);
>> m_cond.notify_all();
>> }
>>
>> R result() const
>> {
>> boost::mutex::scoped_lock lock(m_mutex);
>> while (!m_result)
>> m_cond.wait(lock);
>
> This changes result()'s semantics to "block until op() finishes"; what
> happens if nobody calls op()? Or it throws an exception?
Changes the semantics? I thought this was what was expected and
illustrated in every example thus far? Failure to call op() is a user
error that will result in deadlock if result() is called. The only other
alternative is to throw in result() if op() wasn't called, but I don't
think that's appropriate. The exception question still needs work. We
probably want result() to throw in this case, the question is what it will
throw. IOW, do we build the mechanism for propogating exception types
across thread boundaries, or just throw a single generic exception type.
>> return *m_result.get();
>> }
>>
>> private:
>> boost::function0 m_func;
>> optional m_result;
>> mutable mutex m_mutex;
>> mutable condition m_cond;
>> };
>>
>> template
>> class future
>> {
>> public:
>> template
>> explicit future(const F& f)
>> : m_pimpl(new async_call(f))
>> {
>> }
>>
>> future(const future& other)
>> {
>> mutex::scoped_lock lock(m_mutex);
>
> I don't think you need a lock here, but I may be missing something.
I have to double check the implementation of shared_ptr<>, but I was
assuming all it did was to synchronize the ref count manipulation.
Reads/writes of the data pointed at needed to be synchronized externally.
If that's the case, the assignment here needs to be synchronized in order
to insure it doesn't interrupt the access in op().
>> m_pimpl = other.m_pimpl;
>> }
>>
>> future& operator=(const future& other)
>> {
>> mutex::scoped_lock lock(m_mutex);
>
> -"-
>
>> m_pimpl = other.m_pimpl;
>> }
>>
>> void operator()()
>> {
>> (*get())();
>> }
>>
>> R result() const
>> {
>> return get()->result();
>> }
>>
>> private:
>> shared_ptr > get() const
>> {
>> mutex::scoped_lock lock(m_mutex);
>
> -"-
>
>> return m_pimpl;
>> }
>>
>> shared_ptr > m_pimpl;
>> mutable mutex m_mutex;
>> };
>
> As for the "big picture", ask Dave. ;-) I tend towards a refcounted
> async_call.
That's what future<> gives you, while async_call<> requires no dynamic
memory allocation, which is an important consideration for many uses.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [build] request for modification.
At 12:48 PM 2/6/2003, Dave Abrahams wrote: >> It looks like the intel compiler still supports long long when used with >> the -ansi option. I searched around for good specs, but could find no >> definitive outline of what other restrictions it adds. So at least as far >> as long long is concerned, it's good to go. > >OK, thanks. Why don't you: > >a. make a copy of the current regression results for Intel >b. modify the toolset to add -ansi >c. compare the results and see if any new errors crop up which shouldn't be >there. > >?? > >If all of that works out, you can check in the toolset mod. I gave it a try, and got this message: icl: warning: option '-Qansi' is deprecated; use '-Qansi_alias' instead I tried again, with -Qansi_alias, with no changes whatsoever in the test results. I've gone ahead and committed the change to CVS, but wonder if this is really the option Ron wanted?. Intel's docs say: >-Qansi_alias directs the compiler to assume the following: >Arrays are not accessed out of bounds. > >Pointers are not cast to non-pointer types, and vice-versa. > >References to objects of two different scalar types cannot alias. For >example, an object of type int cannot alias with an object of type float, >or an object of type float cannot alias with an object of type double. > >If your program satisfies the above conditions, setting the -Qansi_alias >flag will help the compiler better optimize the program. However, if your >program does not satisfy one of the above conditions, the -Qansi_alias flag >may lead the compiler to generate incorrect code. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Minimal test tool - very minor comments & spell checking documentation
At 05:07 AM 2/11/2003, Paul A. Bristow wrote: >As for spell checking, MS FrontPage astonishingly doesn't appear to include >a spelling checker ... MS FrontPage has had a spell checker for years. Select "tools" menu, click "page options...", and select the spelling options you prefer. HTH, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
[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? -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] random: request for Box-Muller implementation of normal_distribution
Hello all, We've noticed that normal_distribution using polar method, rather then Box-Muller. Is there a particular reason for not using Box-Muller? Looks to me like a quite an easy way to improve performance. The method with source code is described in Numerical Recipes. Changing current code to Box-Muller is just a few line code change. It improved performance of one of my apps by 20%, so the normal_distribution performance was even bigger. __ Kirill Lapshin 410-230-1123
Re: [boost] Re: Re: peak_of() proposal
On 2003-02-12 5:56 AM, "Philippe A. Bouchard" <[EMAIL PROTECTED]>
wrote:
> Jon Kalb wrote:
>> I wonder if it wouldn't be better to have a compile time error in this
>> situation rather than to create a trap for the unsuspecting. It does
>> put an additional burden on the user to ensure that the types are
>> indeed polymorphic, but I think they have that burden in any case.
>> The currently implementation allows them to be blissfully ignorant of
>> this situation.
>>
>> I appreciate that your library will document that it only works for
>> polymorphic types, but I fear that to be an insufficient prophylactic.
>
> Well in fact, the following assignment could be verified at compile-time
> with some smart_ptr<> checking policy:
>
> class A { char c; };
>
> class B { char c; };
>
> class C : public A, public B { char c; };
>
>
> smart_ptr pC = new C;
>
> smart_ptr pA = pC;// Ok.
>
> smart_ptr pB = new B;// [<- correction here] Ok.
>
> smart_ptr pA = new C;// Ok.
>
> smart_ptr pB = pC;// Generate compile-time error.
>
>
>
> Philippe A. Bouchard
I'm afraid that I don't see your point. How is this relevant?
Jon Kalb
[EMAIL PROTECTED]
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Weak ref. via atomicity (RE: Smart pointers:...)
Alexander Terekhov wrote:
> Peter Dimov wrote:
> [...]
>> You are missing the fact that nobody (even Google) has a clue as to what
>> pthread_refcount_enroll_one is/does. ;-)
> Ah. Sorry. Basically it's a rather simple "CAS"- ["compare-and-swap"]
> or "LL/SC"- [load-locked/store-conditional] based operation; in terms
> of proposed Java-atomics(*):
> extern "C" int pthread_refcount_enroll_one(pthread_refcount_t* rc) {
> size_t value;
> do {
> if ( 0 == (value = rc->__get()) )
> return PTHREAD_REFCOUNT_DROPPED_TO_ZERO;
> } while (!rc->__attemptUpdate(value, value + 1));
> return 0;
> }
> regards,
> alexander.
> (*) [but WITHOUT any memory synchronization/barriers for _enroll_*()]
> http://groups.google.com/groups?threadm=3D8B257C.4D8D58F%40web.de
> (Subject: Re: rwlock using pthread_cond (or Win32 events) [last
> link retired; stuff is available here: ])
pthread_refcount_enroll_one() (== "increment_if_non_zero()") may be
emulated in Win32 (using InterlockedCompareExchange()).
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.
Pavel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Request for const fix in unit_test_suite.hpp
Hello boosters,
I've justed stumbled across a problem when using the BOOST_CLASS_TEST_CASE
macro in a special way.
I am using class based test cases and want to run every testcase from a
clean environment, i.e. I need to create a new instance of my test class
for every test case.
To keep the code simple and clean I wrote myself a function that returns
the required shared_ptr on a test instance:
--- SNIP ---
boost::shared_ptr testInstance()
{
return boost::shared_ptr(new MyTest());
}
test_suite* init_unit_test_suite( int argc, char * argv[] ) {
test_suite* test= BOOST_TEST_SUITE( "My Unit Test" );
test->add(BOOST_CLASS_TEST_CASE(&MyTest::test1, testInstance()));
test->add(BOOST_CLASS_TEST_CASE(&MyTest::test2, testInstance()));
test->add(BOOST_CLASS_TEST_CASE(&MyTest::test3, testInstance()));
return test;
}
--- SNIP ---
This works perfectly well under Windows using the Microsoft compiler. On
Linux, using gcc (tried 2.96 and 3.2) it fails. The reason it fails is,
because the return value of testInstance() is put into a temporary (is
that the correct term?) variable and the test framework needs a
shared_ptr&. This reference ist not const at the moment, thus the (gcc)
compiler refuses to compile.
The problem can be illustrated this:
--- SNIP ---
class Object {
};
void test(Object& obj) {
}
Object makeObject() {
return Object();
}
void foo() {
test(makeObject()); // fails
Object obj = makeObject();
test(obj); // works
}
--- SNIP ---
Although test(makeObject()) should IMHO be just the same as the test(obj)
stuff, the former fails to compile.
I've tried to make the shared_ptr const in
unit_test_suite.hpp and succeeded (needed to add "const" in two
places...).
May I request that this fix is integrated into the base source tree?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Reflection system in C++ using templates
On Wednesday 12 February 2003 01:08 am, Lin Xu wrote: > Yeah, I guess it would. The syntax I had before was limited by my lack of > knowledge about how to extract the arguments and return type from a > classtype. But I can use function_traits<> right? But that requires partial > template specialization. Is there a way to get the types without PTS? How > does boost::function do it? Maybe I can mirror the syntax of > boost::Function. But boost::function doesn't have the function pointer as > an actual template parameter. There is no known way to extract the argument types from function pointers or member function pointers without PTS. The class template boost::function only works when the compiler can handle it (which includes requiring PTS); otherwise the user is stuck with function0, function1, etc. > I dont' know how to make that syntax work. I did originally want syntax > like that, but I didn't know how to write it without PTS (or a least > support non-PTS compilers nicely). Don't kill a good design because of bad compilers. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: regression tests on Aix
Hi! I just updated the regression tests for AIX for both Visual Age 5 and Visual Age 6 and I will try to update at least once a week until Toon gets access to another maching. On a side note, how do the compiler version numbers get into the status tables? They don't show up for AIX and the comments in the toolset jam file seem to indicate, that they somehow should. Markus ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: peak_of() proposal
Philippe A. Bouchard wrote:
[...]
> Well in fact, the following assignment could be verified at
> compile-time
> with some smart_ptr<> checking policy:
>
> class A { char c; };
>
> class B { char c; };
>
> class C : public A, public B { char c; };
smart_ptr pC = new C;
smart_ptr pA = pC;// Ok.
smart_ptr pB = new B;// [<- correction here] Ok.
smart_ptr pB = pC;// Generate compile-time error.
smart_ptr pB = new C;// Generate compile-time error.
Philippe A. Bouchard
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: peak_of() proposal
Jon Kalb wrote:
> On 2003-02-11 8:47 PM, "Philippe A. Bouchard" [EMAIL PROTECTED]
[...]
> This is as I suspected.
>
> I wonder if it wouldn't be better to have a compile time error in this
> situation rather than to create a trap for the unsuspecting. It does
> put an additional burden on the user to ensure that the types are
> indeed polymorphic, but I think they have that burden in any case.
> The currently implementation allows them to be blissfully ignorant of
> this situation.
>
> I appreciate that your library will document that it only works for
> polymorphic types, but I fear that to be an insufficient prophylactic.
Well in fact, the following assignment could be verified at compile-time
with some smart_ptr<> checking policy:
class A { char c; };
class B { char c; };
class C : public A, public B { char c; };
smart_ptr pC = new C;
smart_ptr pA = pC;// Ok.
smart_ptr pA = new C;// Ok.
smart_ptr pB = pC;// Generate compile-time error.
Philippe A. Bouchard
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Sockets - what's the latest?
Hi all, 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. Regards, [)o IhIL.. ___ 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? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Live summary of regression tests.
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. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::format named parameters
Alan Gutierrez wrote:
> Has there been any consderation given to the use of named parameters
> with boost::format?
>
> use boost::format;
>
> std::cout << format ("%first-name% %last-name%")
> % format::arg("first-name", "Alan")
> % format::arg("last-name", "Gutierrez")
> << std::endl;
>
> It would not be terribly difficult to implement.
>
I did something like this some time ago.
named_param p_name("name"), p_age("age");
std::string your_name = get_your_name();
unsigned int your_age = get_your_age();
std::cout << format("{name} is {age} years old.\n",
p_name = your_name,
p_age = your_age);
IMHO, it's very useful feature.
--
Alexander Nasonov
Remove -mycop from my e-mail address for timely response
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::variant - Status + Formal Review
The boost::variant library, currently available at Sourceforge/boost-sandbox, is ready for a formal review. We expect the final version to be ready within a day or two, at which point we will place a zipped package at the Boost's File section. The formal review (scheduled by Thomas Witt) will take place at 15-24th February. The Review manager is Jeff Garland. Eric Friedman Itay Maman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
