RE: [boost] binding
Thanks, and yes, I am using MSVC (6)
Your answer makes sense, and it works fine!
That problem is a fairly irritating however
I'm suprised the bug fell through to MSVC7
-Original Message-
From: Craig Henderson [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 07, 2003 12:32 AM
To: [EMAIL PROTECTED]
Subject: [boost] Re: binding
Greg,
>From the Linker Error, it looks like you're using Microsoft Visual C++. I
discovered a bug recently with MSVC7.0 which may be the same as you're
seeing here, but it is reported to be fixed in Everett.
The bug occurs if you pass a template function as a parameter to another
template function as a functor. The caller must specify the template
parameters explicitly, and the functor is called without any knowledge of
templates. However, if this is the only call to the functor with these
template parameters, then the compiler fails togenerate code for the
template and the linker fails with unresolved external.
Try adding a separate call to the function GenAlg::RouletteWheel(class
CGAController *) in a harmless piece of code to force the compiler to
generate the templated code.
HTH
-- Craig
"Greg Dehaas" <[EMAIL PROTECTED]> wrote in message
430AD3105AC1D511B8990010B5C225C710ACBC@DMISERVER01">news:430AD3105AC1D511B8990010B5C225C710ACBC@DMISERVER01...
> Hi all,
>
> Could someone please tell me how to achieve a functor binding to a
templated
> function?
>
> I have a namespace GenAlg with this inside:
>
> namespace GenAlg
> {
> template
> unsigned long RouletteWheel(TController *oController)
> {
> ...
> }
> }
>
>
> elsewhere I have a
>
> boost::function1 fncSelection;
>
>
> I try to set fncSelection to RouletteWheel like so:
>
> fncSelection = boost::bind(GenAlg::RouletteWheel long>,_1);
>
>
> And my compiler's reply is:
>
> genetics.obj : error LNK2001: unresolved external symbol "unsigned long
> __cdecl GenAlg::RouletteWheel(class CGAController *)"
> (?RouletteWheel@GenAlg@@YAKPAVCGAController@@@Z)
>
>
> Help? Please?
> I'm sure this is stupid, simple stuff for you guys, and so annoying for me
> :)
> Greg
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] STLFilt for the rest of us
At TCS3, I met Leor Zolman, the author of STLFilt, the C++ error message "decryptor." He asked what it would take for me to start using STLFilt, and I told him I didn't care about most of what he was doing -- compressing STL iterator types down to sensible typedefs, and removing information that most people find useless but I find essential. We started to talk about what I *do* need: a useful re-ordering for GCC error messages, so I don't have to wade through an instantiation backtrace just to see what went wrong, and some nice wrapping for long template types. I'm pleased to say that Leor did an amazing job. It's GCC-only for the time being; here's a sample of some of the output, wrapped a bit more-narrowly than you'd probably want, so that it won't be mangled by mailers: c:/boost/boost/function/function_template.hpp:98: `a0' has incomplete type c:/boost/boost/function/function_template.hpp: In static member function `static boost::detail::function::unusable boost::detail::function ::void_function_invoker4< void (*)(int*, int, int&, float&), void, int[], int, int& , float >::invoke( boost::detail::function::any_pointer, int[], int, int&, float )': c:/boost/libs/function/test/sum_avg_portable.cpp:21: instantiated from here c:/boost/boost/function/function_template.hpp:448: instantiated from `void boost::function4< void, int[], int, int&, float >::assign_to( void (*)(int*, int, int&, float&) , boost::detail::function::function_ptr_tag )' c:/boost/boost/function/function_template.hpp:432: instantiated from `void boost::function4< void, int[], int, int&, float >::assign_to(void (*)(int*, int, int&, float&))' c:/boost/boost/function/function_template.hpp:293: instantiated from `boost::function4< void, int[], int, int&, float >::function4( void (*)(int*, int, int&, float&) , boost::detail::function::enable_if< boost::type_traits::ice_not< boost::is_same::value >::value, int >::type )' c:/boost/boost/function/function_template.hpp:346: instantiated from `boost::detail::function::enable_if< boost::type_traits::ice_not< boost::is_same:: value >::value , boost::function4& >::type boost::function4:: operator=(void (*)(int*, int, int&, float&))' c:/boost/libs/function/test/sum_avg_portable.cpp:21: instantiated from here For reference, you can compare this with: http://boost.sourceforge.net/regression-logs/cs-linux-links.html#sum_avg_portable%20gcc If this looks useful to you, get Leor's Beta from http://www.bdsoft.com/tools/stlfilt.html. Look for the phrase "template metaprogramming". BTW, there are lots of options; if you don't like leading commas, for example, you can turn them off. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] serial_ptr
I need a pointer that can store pointer or an ID. I thought maybe
I could make a policy set for smart_ptr, but that turns out to be
too tricky. I don't think this kind of thing is appropriate for a
smart pointer because of the interface, but I just wanted to get
some opinions on the technique, and see if there are any
improvements to be made.
#include // std::memcpy()
#include // placement new
#include // std::swap()
#include // std::runtime_error
#include
//--
--
namespace boost
{
//
template >
class serial_ptr
{
private:// Types
enum tag { t_id, t_pointer };
typedef Pointer pointer_type;
typedef char storage_type[sizeof(pointer_type)];
public: // Structors
serial_ptr(int id)
: tag_(t_id){ new (value_) int(id); }
serial_ptr(T* p)
: tag_(t_pointer) { new (value_)
pointer_type(p); }
serial_ptr(pointer_type const& p)
: tag_(t_pointer) { new (value_)
pointer_type(p); }
serial_ptr(serial_ptr const& p)
: tag_(p.tag_)
{
if (tag_ == t_id) new (value_) int(p);
elsenew (value_) pointer_type(p);
}
~serial_ptr(void)
{
if (tag_ == t_pointer)
{
reinterpret_cast(value_)->~pointer_type();
}
}
public: // Operators
serial_ptr& operator=(int id)
{
serial_ptr(id).swap(*this);
return *this;
}
serial_ptr& operator=(pointer_type p)
{
serial_ptr(p).swap(*this);
return *this;
}
serial_ptr& operator=(serial_ptr p)
{
swap(p);
return *this;
}
operator int(void) const
{
if (tag_ != t_id)
{
throw std::runtime_error("Invalid serial_ptr conversion");
}
return *reinterpret_cast(value_);
}
operator pointer_type(void) const
{
if (tag_ != t_pointer)
{
throw std::runtime_error("Invalid serial_ptr conversion");
}
return *reinterpret_cast(value_);
}
T* operator->(void) const
{
return operator pointer_type().operator->();
}
void swap(serial_ptr& p)
{
std::swap(tag_, p.tag_);
storage_type Tmp;
std::memcpy(Tmp, value_, sizeof(value_));
std::memcpy(value_, p.value_, sizeof(value_));
std::memcpy(p.value_, Tmp, sizeof(value_));
}
private:// Implementation
tag tag_;
storage_typevalue_;
};
//
} // namespace boost
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shifted_ptr<> <-> $100 smart pointer policies question
"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
b1v0v8$k1s$[EMAIL PROTECTED]">news:b1v0v8$k1s$[EMAIL PROTECTED]...
> First, thanks!
No problem, but it was just to help you get started. You obviously
know more about shifted_ptr than I do, so use your own experience
here. ;)
> [...]
> Great to know there is now some pre-condition like
> checking_policy.
Yup. Customizable checking is nice.
> [...]
> One little thing: the pointee_ must be of type T * because of
> polymorphic objects with multiple inheritance that keep shifting
> the pointer implicitly; and to have a fast operator *.
Ok. Then set it to T*. ;)
> [...]
> > shifted_storage(pointer_type p)
> > : pointee_(static_cast(
> > static_cast(static_cast(p)) -
> > sizeof(shifted_header)
> > ))
> > { }
> > // I think the arithmetic above is valid, because we're
> > dealing with // POD types, but IANALL, so take it with a
> > grain of salt
>
> Maybe it would be better to use 'shifted_address::get()'
> instead of 'static_cast(p)) - sizeof(shifted_header)' because
> pointer_type does not necessarily point to the beginning of the object.
Sure. That was just filler until you put in the more appropriate code. ;)
> [...]
> It's interesting to know that some checking_policy is provided. It kind
> of open doors to test the validity of the address at run-time.
> Conversions will be interesting also.
You might have to pull some tricks with the Ownership policy, I'm not
sure. For conversions, the pointer casts should work, unless you need
to do some tricks.
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shared_ptr question (with respect to thread safety)
On Thu, 2003-02-06 at 18:52, Trey Jackson wrote:
> Hamish Mackenzie wrote:
> >These scoped locks will go out of scope before you "do stuff".
>
> Right, thanks for the catch.
>
> I started writing it thinking I'd be doing some cool new
> meta-programming, but it turned into just simple object inheritance
> (thus the function calls that let the locks go out of scope).
>
> But my original intent was actually to try to get code substituted at
> compile time.
I think you had that bit right. Here is a more complete version of what
I think you wanted with a couple of syntax errors corrected.
template // perhaps "locking policy"
class mySuperLockedClass : public LockingStrategy
{
public:
void read()
{
typename LockingStrategy::read_lock_type l( this );
// do stuff
}
void write()
{
typename LockingStrategy::write_lock_type l( this );
// do stuff
}
};
class
EmptyLockingStrategy
{
struct lock_type : boost::noncopyable
{
lock_type( EmptyLockingStrategy * s ) {}
};
public:
typedef lock_type read_lock_type;
typedef lock_type write_lock_type;
};
class
MutexLockingStrategy
{
boost::mutex m_;
class lock_type less a couple syntax errors
{
public:
lock_type( MutexLockingStrategy * s ) : l_( s->m_ ) {}
private:
boost::mutex::scoped_lock l_;
};
public:
typedef lock_type read_lock_type;
typedef lock_type write_lock_type;
};
class
ReaderWriterLockingStrategy
{
boost::unimplemented::rwmutex m_;
public:
class read_lock_type
{
public:
read_lock_type( ReaderWriterLockingStrategy * s ) : l_( s->m_ ) {}
private:
boost::unimplemented::rwmutex::scoped_read_lock l_;
};
class write_lock_type
{
public:
write_lock_type( ReaderWriterLockingStrategy * s ) : l_( s->m_ ) {}
private:
boost::unimplemented::rwmutex::scoped_write_lock l_;
};
};
The only thing different from your original is that this uses RAII
(resource acquisition is initialization) to insert code in two places
(lock and unlock). You can put whatever other code you like in the
constructor and destructor of read_lock_type and write_lock_type.
You could have stuck with your original approach and used four functions
(read_lock, read_unlock, write_lock and write_unlock). Then added the
RAII later as a separate template class, but I think that would make the
implementation unnecessarily messy for the same end result.
> Any tips on how to do this?
> Is it possible in C++? I can see how to do it with lisp macros.
> I'm reading the MPL intro written by David Abrahams and Aleskey
> Gurtovoy, but it's slow going...
It is also worth checking out Modern C++ Design by Andrei Alexandrescu
if you haven't already. In particular the stuff on policies.
--
Hamish Mackenzie <[EMAIL PROTECTED]>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shifted_ptr<> <-> $100 smart pointer policies question
First, thanks!
David B. Held wrote:
> "Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
> b1tvp7$da3$[EMAIL PROTECTED]">news:b1tvp7$da3$[EMAIL PROTECTED]...
[...]
> Here's the "raw pointer c'tor":
>
> template
> smart_ptr(U const& p)
> : base_type(p, detail::init_first_tag())
> { checking_policy::on_init(get_impl(*this)); }
Great to know there is now some pre-condition like checking_policy.
> Here's what your storage_policy might look like:
>
> template
> class shifted_storage
> {
> public:
> typedef shifted_object* stored_type;// the type
> of the pointee_
> typedef shifted_object*const_stored_type; //
One little thing: the pointee_ must be of type T * because of polymorphic
objects with multiple inheritance that keep shifting the pointer implicitly;
and to have a fast operator *.
> object typedef T* pointer_type; // type
> returned by
> operator->
> typedef T const*const_pointer_type;
[...]
> shifted_storage(pointer_type p)
> : pointee_(static_cast(
> static_cast(static_cast(p)) -
> sizeof(shifted_header)
> ))
> { }
> // I think the arithmetic above is valid, because we're
> dealing with // POD types, but IANALL, so take it with a
> grain of salt
Maybe it would be better to use 'shifted_address::get()'
instead of 'static_cast(p)) - sizeof(shifted_header)' because
pointer_type does not necessarily point to the beginning of the object.
[...]
> public:
> friend inline pointer_type get_impl(shifted_storage const& sp)
> { return &sp.pointee_->m_object; }
>
> friend inline stored_type& get_impl_ref(shifted_storage& sp)
> { return sp.pointee_; }
[...]
> protected:
> void release()
> { pointee_ = 0; }
>
> static stored_type default_value()
> { return 0; }
>
> private:
> stored_type pointee_;
>
> public:
> BOOST_MPL_AUX_LAMBDA_SUPPORT(1, shifted_storage, (T))
> };
>
> #ifdef __BORLANDC__
> namespace mpl { BOOST_MPL_AUX_VOID_SPEC(1, shifted_storage) }
> #endif
>
> Dave
It's interesting to know that some checking_policy is provided. It kind of
open doors to test the validity of the address at run-time. Conversions
will be interesting also.
Philippe A. Bouchard
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr - Exception safety reprise
From: "David B. Held" <[EMAIL PROTECTED]> > "Dave Abrahams" <[EMAIL PROTECTED]> wrote in message > 001201c2ce26$533cae40$6501a8c0@penguin">news:001201c2ce26$533cae40$6501a8c0@penguin... > > [...] > > It's clear to me why that could happen. It could be just a simple- > > minded rule to avoid violating the standard requirements, which > > are written so that no two objects of the same type can have the > > same address. The rule would be, "if I applied the EBO on this > > type, add some padding after it in an MI context so that other > > bases of the same type can't end up overlapping with it. It's a > > dumb rule, since it's easy enough to lay out empty bases in the > > single-inheritance case at the beginning of the object, and since > > all types have size > 0, you don't need to do anything other than > > "not optimize" in the MI case. > > So it's actually a pessimization as the result of an optimization? > Ouch. That's one plausible explanation. > > [...] > > I'm interested in what happens when either of ownership or > > storage are themselves empty. > > Oddly enough, VC++ gets the size right for destructive_copy (4), > but bcc insists the size is 8. In this case, I don't know what's going > on, because optimally_inherit only leaves one base class (which > can be proven by trying to static_cast to the policies), so there > isn't even MI involved. It's just outright EBO failure. > > > And, of course, the independent tests not based on smart_ptr. > > I've done some of these. When I first ran across size problems, > it was the first thing I did. However, the simplicity of the tests does > not give you a good idea of what happens in smart_ptr. That is, a > lot of the simple tests pass with the desired results. It's when > the tests get more and more smart_ptr baggage that you begin > to see different results. It will be a lot more instructive if you can narrow down which specific piece of baggage is causing the problem so that you're not thinking of this in terms of smart_ptr components all the time. Otherwise, you'll never have a good idea of which policy design choices will cause what size-effects. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr - Exception safety reprise
"Dave Abrahams" <[EMAIL PROTECTED]> wrote in message 001201c2ce26$533cae40$6501a8c0@penguin">news:001201c2ce26$533cae40$6501a8c0@penguin... > [...] > It's clear to me why that could happen. It could be just a simple- > minded rule to avoid violating the standard requirements, which > are written so that no two objects of the same type can have the > same address. The rule would be, "if I applied the EBO on this > type, add some padding after it in an MI context so that other > bases of the same type can't end up overlapping with it. It's a > dumb rule, since it's easy enough to lay out empty bases in the > single-inheritance case at the beginning of the object, and since > all types have size > 0, you don't need to do anything other than > "not optimize" in the MI case. So it's actually a pessimization as the result of an optimization? Ouch. > [...] > I'm interested in what happens when either of ownership or > storage are themselves empty. Oddly enough, VC++ gets the size right for destructive_copy (4), but bcc insists the size is 8. In this case, I don't know what's going on, because optimally_inherit only leaves one base class (which can be proven by trying to static_cast to the policies), so there isn't even MI involved. It's just outright EBO failure. > And, of course, the independent tests not based on smart_ptr. I've done some of these. When I first ran across size problems, it was the first thing I did. However, the simplicity of the tests does not give you a good idea of what happens in smart_ptr. That is, a lot of the simple tests pass with the desired results. It's when the tests get more and more smart_ptr baggage that you begin to see different results. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [mpl] More problems with MSVC 7.0, 8-/
Aleksey,
The attached code works like a dream on MSVC 7.1, but MSVC 7.0 again has its
problems:
Problem No. 1: Expression 1 does not seem to work, because Derived is an
incomplete type:
To reproduce, you might want to comment-out expression 3 and uncomment
expression 4.
Problem No. 2: mpl::fold produces errors similar to the ones I had with
transform yesterday
In the original file, please comment out expression 1 and uncomment
expression 2 to reproduce.
Luckily, I can continue with MSVC7.1 now, so these bugs have low priority.
Thank you!
Best regards,
Andreas
#include
#include
#include
#include
#include
#include
#include
#include
#include
template< class Event >
class event_handler
{
protected:
event_handler() {}
~event_handler() {}
private:
virtual bool handle_event( const Event & theEvent ) = 0;
};
template< class Derived, class Event, class Destination >
class transition_handler : public event_handler< Event >
{
private:
virtual bool handle_event( const Event & ) { /* */ }
};
template< class Event, class Destination >
struct transition
{
template< class Derived >
struct apply
{
typedef transition_handler< Derived, Event, Destination > type;
};
};
namespace mpl = boost::mpl;
template< class T >
struct make_list : public mpl::apply_if<
mpl::is_sequence< T >, mpl::identity< T >,
mpl::identity< mpl::list< T > > > {};
class empty_type {};
template< class Base1, class Base2 >
struct derive
{
struct type : public Base1, public Base2 {};
};
class EvPause {};
class EvStop {};
class Paused {};
class Stopped {};
using namespace mpl::placeholder;
template< class Derived, class Transitions >
struct state_base_type
{
private:
typedef typename make_list< Transitions >::type transition_list;
// The following is a problem, because Derived is incomplete
typedef typename mpl::transform< /* 1 */
transition_list, mpl::apply1< _, Derived > >::type handler_list;
//typedef mpl::list< transition_handler< Derived, EvPause, Paused > >
// handler_list; /* 2 */
public:
// There are problems with the following as well, errors are similar
// to the ones I had with transform yesterday
typedef typename mpl::fold< /* 3 */
handler_list, empty_type, derive< _1, _2 > >::type type;
//typedef empty_type type; /* 4 */
};
class Running : public state_base_type< Running,
mpl::list< transition< EvPause, Paused >,
transition< EvStop, Stopped > > >::type {};
int main()
{
// this is just to see the type in the debugger
Running * pState1 = 0;
pState1;
return 0;
}
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: binding
Greg,
>From the Linker Error, it looks like you're using Microsoft Visual C++. I
discovered a bug recently with MSVC7.0 which may be the same as you're
seeing here, but it is reported to be fixed in Everett.
The bug occurs if you pass a template function as a parameter to another
template function as a functor. The caller must specify the template
parameters explicitly, and the functor is called without any knowledge of
templates. However, if this is the only call to the functor with these
template parameters, then the compiler fails togenerate code for the
template and the linker fails with unresolved external.
Try adding a separate call to the function GenAlg::RouletteWheel(class
CGAController *) in a harmless piece of code to force the compiler to
generate the templated code.
HTH
-- Craig
"Greg Dehaas" <[EMAIL PROTECTED]> wrote in message
430AD3105AC1D511B8990010B5C225C710ACBC@DMISERVER01">news:430AD3105AC1D511B8990010B5C225C710ACBC@DMISERVER01...
> Hi all,
>
> Could someone please tell me how to achieve a functor binding to a
templated
> function?
>
> I have a namespace GenAlg with this inside:
>
> namespace GenAlg
> {
> template
> unsigned long RouletteWheel(TController *oController)
> {
> ...
> }
> }
>
>
> elsewhere I have a
>
> boost::function1 fncSelection;
>
>
> I try to set fncSelection to RouletteWheel like so:
>
> fncSelection = boost::bind(GenAlg::RouletteWheel long>,_1);
>
>
> And my compiler's reply is:
>
> genetics.obj : error LNK2001: unresolved external symbol "unsigned long
> __cdecl GenAlg::RouletteWheel(class CGAController *)"
> (?RouletteWheel@GenAlg@@YAKPAVCGAController@@@Z)
>
>
> Help? Please?
> I'm sure this is stupid, simple stuff for you guys, and so annoying for me
> :)
> Greg
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: A new boost::thread implementation?
Dave Abrahams wrote: [...] > > 2) You're still hiding the thread creation. > > Absolutely. High-level vs. low-level. Yeah ... > > > This is a mistake to me for > > two reasons. First, it's not as obvious that a thread is being created > > here (though the new names help a lot). > > Unimportant, IMO. Who cares how an async_call is implemented under the > covers? ... but to me, that "async_call"-thing is nothing but "a future" [one would also need an "executor" to make some use of it]. I can think of "a thread" as a sort of "executor" but not the other way around. http://gee.cs.oswego.edu/dl/concurrent/dist/docs/java/util/concurrent/Future.html http://gee.cs.oswego.edu/dl/concurrent/dist/docs/java/util/concurrent/Executor.html http://gee.cs.oswego.edu/dl/concurrency-interest regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shared_ptr question (with respect to thread safety)
"Trey Jackson" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> I was unable to get that to compile.
> Linux gcc 3.2.1, or HP aCC: HP ANSI C++ B3910B X.03.32
>
> The linux error gave me a syntax error before the '{' token on the lines
> declaring 'insertCode' in both SubstituteHello and SubstituteGoodbye.
That's correct.
> ,
> | #include
> |
> | using std::cout; using std::endl;
> |
> | template
> | struct userClass {
> |void function() {
> | // code is inserted here, not a function call to a member of
> | ToBeSubstituted::insertCode();
> | }
> | };
> |
> | struct SubstituteHello {
> | typedef void fn();
> |
> | static fn insertCode {
> | cout << "hello world" << endl;
> | }
> | };
You can use a typedef to declare a function, but not to define one.
This code should actually be:
static void insertCode() { ...
> | struct SubstituteGoodbye {
> | typedef void fn();
> |
> | static fn insertCode {
> | cout << "goodbye world" << endl;
> | }
> | };
And here.
> [...]
> This compiles, runs with undesired behavior;
> ,
> | struct SubstituteHello {
> | typedef void fn();
> |
> | static void insertCode()
> | {
> | dummy d;
> | cout << "Hello World" << endl;
> | }
That's pretty much how you have to do it.
> | //typedef void fn();
> | //static fn insertCode {
> | // cout << "hello world" << endl;
> | //}
> | };
> `
> [...]
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr - Exception safety reprise
From: "David B. Held" <[EMAIL PROTECTED]> > "Dave Abrahams" <[EMAIL PROTECTED]> wrote in message > 008c01c2ce1f$87ca8620$6501a8c0@penguin">news:008c01c2ce1f$87ca8620$6501a8c0@penguin... > > [...] > > What do you mean that its *place* in the hierarchy affects the size? If > > it's in the hierarchy, it's a base. Sorry, I thought that "it" is "noncopyable", not "ref_counted". > But if it's not in the smart_ptr hierarchy, it's not a base. So if it's not > a base, it's at the top (or bottom) of the hierarchy, with noncopyable as a > base. And that's my point. Being a base changes its size. No, it doesn't. It can't. sizeof(ref_counted) is the same no matter where you measure it. What changes is the size that gets contributed to its derived class. It's clear to me why that could happen. It could be just a simple-minded rule to avoid violating the standard requirements, which are written so that no two objects of the same type can have the same address. The rule would be, "if I applied the EBO on this type, add some padding after it in an MI context so that other bases of the same type can't end up overlapping with it. It's a dumb rule, since it's easy enough to lay out empty bases in the single-inheritance case at the beginning of the object, and since all types have size > 0, you don't need to do anything other than "not optimize" in the MI case. > > BTW, these are not the kind of tests I was thinking of. I was more > > interested in simple tests with SI and MI using dummy classes with > > zero or more data members and trivial/non-trivial ctors/dtors. > > Yes, like what Jason Shirk did. It's just that I did a diff of the version > that was the right size and the one that wasn't, and saw that change, > so I wanted to test it right away. The weird thing is, the storage policy > also has an empty base for the policy adaptor, and yet, it doesn't > seem to affect the size of smart_ptr. Go figure. But like Jason also > pointed out, the order of bases makes a difference, so maybe the > fact that storage_policy comes first affects the size. I noticed that > this is actually the case on bcc, and I suspect, on most compilers. > > Anyway, non-copyable doesn't really convey the right concept > anyway, since ref_counted defines copy c'tors! I just wanted to hide > the assignment operator, and doing that "manually" works fine. I'm interested in what happens when either of ownership or storage are themselves empty. And, of course, the independent tests not based on smart_ptr. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: SmartPtr - Exception safety reprise
"Dave Abrahams" <[EMAIL PROTECTED]> wrote in message 008c01c2ce1f$87ca8620$6501a8c0@penguin">news:008c01c2ce1f$87ca8620$6501a8c0@penguin... > On Thursday, February 06, 2003 3:13 PM [GMT+1=CET], > David B. Held <[EMAIL PROTECTED]> wrote: > > > "David B. Held" <[EMAIL PROTECTED]> wrote in message > > b1m57m$702$[EMAIL PROTECTED]">news:b1m57m$702$[EMAIL PROTECTED]... > > > > > [...] > > > > > I mean, the optimally_inherit eliminates the empty bases, and > > > > > yet there is size bloat. So VC++ makes the class bigger for > > > > > some other reason than that it has empty bases. I will try to > > > > > write some tests to see why that is, or at least how. > > > > > > > > I repeat, I bet it's MI-related. > > > > > > The proof of the pudding is in the eating. > > > > I got a chance to taste the pudding, the the results are inconclusive. > > The cause of the size bloat was that I had changed ref_counted to > > inherit from noncopyable. Seems like an innocent enough change. > > Seems that for the single-inheritance case, we should see some > > EBO action, right? Well, we do, unless ref_counted is a base in > > an MI hierarchy. Why its place in an hierarchy should change its > > size is a mystery to me, > > What do you mean that its *place* in the hierarchy affects the size? If it's > in the hierarchy, it's a base. > I bet this is the effect he observed: http://lists.boost.org/MailArchives/boost/msg43187.php ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr - Exception safety reprise
"Dave Abrahams" <[EMAIL PROTECTED]> wrote in message 008c01c2ce1f$87ca8620$6501a8c0@penguin">news:008c01c2ce1f$87ca8620$6501a8c0@penguin... > [...] > What do you mean that its *place* in the hierarchy affects the size? If > it's in the hierarchy, it's a base. But if it's not in the smart_ptr hierarchy, it's not a base. So if it's not a base, it's at the top (or bottom) of the hierarchy, with noncopyable as a base. And that's my point. Being a base changes its size. > [...] > BTW, these are not the kind of tests I was thinking of. I was more > interested in simple tests with SI and MI using dummy classes with > zero or more data members and trivial/non-trivial ctors/dtors. Yes, like what Jason Shirk did. It's just that I did a diff of the version that was the right size and the one that wasn't, and saw that change, so I wanted to test it right away. The weird thing is, the storage policy also has an empty base for the policy adaptor, and yet, it doesn't seem to affect the size of smart_ptr. Go figure. But like Jason also pointed out, the order of bases makes a difference, so maybe the fact that storage_policy comes first affects the size. I noticed that this is actually the case on bcc, and I suspect, on most compilers. Anyway, non-copyable doesn't really convey the right concept anyway, since ref_counted defines copy c'tors! I just wanted to hide the assignment operator, and doing that "manually" works fine. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shared_ptr question (with respect to thread safety)
>I don't think you need that document. Whatever could be:
>
>typedef void fn(); static fn
>
>In other words, make them static functions. userClass::function just needs
>to add a couple of parens after "insertCode" ;-)
I was unable to get that to compile.
Linux gcc 3.2.1, or HP aCC: HP ANSI C++ B3910B X.03.32
The linux error gave me a syntax error before the '{' token on the lines
declaring 'insertCode' in both SubstituteHello and SubstituteGoodbye.
,
| #include
|
| using std::cout; using std::endl;
|
| template
| struct userClass {
|void function() {
| // code is inserted here, not a function call to a member of
| ToBeSubstituted::insertCode();
| }
| };
|
| struct SubstituteHello {
| typedef void fn();
|
| static fn insertCode {
| cout << "hello world" << endl;
| }
| };
|
| struct SubstituteGoodbye {
| typedef void fn();
|
| static fn insertCode {
| cout << "goodbye world" << endl;
| }
| };
|
| int main()
| {
| userClass u1;
| u1.function(); // prints 'hello world'
| userClass u2;
| u2.function(); // prints 'goodbye world'
|
| return 0;
|
| }
`
I tried a similar vesion, only without the 'typedef void fn();'
To me, the two chunks of code appear the same. How are the two chunks
semantically different? (I imagine they are different or you wouldn't
have introduced the extra 'typedef void fn()').
This compiles, runs with undesired behavior;
,
| struct SubstituteHello {
| typedef void fn();
|
| static void insertCode()
| {
| dummy d;
| cout << "Hello World" << endl;
| }
|
| //typedef void fn();
| //static fn insertCode {
| // cout << "hello world" << endl;
| //}
| };
`
But the generated code appeared to resulted in the destructor of d
being called being before any code in the userClass method 'function'
gets evaluated.
Is that the expected behavior? I'd hoped for truly in-lined code (for
lack of a better term), w/out the lexical scope of 'insertCode' being
introduced.
This is all going back to the desire to factor out the mutex locking,
and wanting to insert (or not) a simple line:
boost::mutex::scoped_lock l(mutex_)
and not have the lock released until the end of the method 'function'.
Apologies if this seems trivial.
The help is appreciated.
TJ
--
Trey Jackson
[EMAIL PROTECTED]
"Every day, the hummingbird eats its own weight in food.
You may wonder how it weighs the food.
It doesn't. It just eats another hummingbird."
-- unknown
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr - Exception safety reprise
On Thursday, February 06, 2003 3:13 PM [GMT+1=CET], David B. Held <[EMAIL PROTECTED]> wrote: > "David B. Held" <[EMAIL PROTECTED]> wrote in message > b1m57m$702$[EMAIL PROTECTED]">news:b1m57m$702$[EMAIL PROTECTED]... > > > > [...] > > > > I mean, the optimally_inherit eliminates the empty bases, and > > > > yet there is size bloat. So VC++ makes the class bigger for > > > > some other reason than that it has empty bases. I will try to > > > > write some tests to see why that is, or at least how. > > > > > > I repeat, I bet it's MI-related. > > > > The proof of the pudding is in the eating. > > I got a chance to taste the pudding, the the results are inconclusive. > The cause of the size bloat was that I had changed ref_counted to > inherit from noncopyable. Seems like an innocent enough change. > Seems that for the single-inheritance case, we should see some > EBO action, right? Well, we do, unless ref_counted is a base in > an MI hierarchy. Why its place in an hierarchy should change its > size is a mystery to me, What do you mean that its *place* in the hierarchy affects the size? If it's in the hierarchy, it's a base. > but taking out noncopyable restores that > magical size. Now, I would appreciate it if people with Intel, CW, > and some other compilers would try out the code in the sandbox > and see if the first test passes (turn on --log-level=all, and pipe the > output to your favorite paginator). BTW, these are not the kind of tests I was thinking of. I was more interested in simple tests with SI and MI using dummy classes with zero or more data members and trivial/non-trivial ctors/dtors. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: A new boost::thread implementation?
> > > async_result later = spawn(foo)(a, b, c); > > > > Mustn't use the name spawn() here. It implies a thread/process/what ever > > has been spawned at this point, which is not the case. Or has it (he says > > later, having read on)? > > It has. It must, because a/b/c might be temporaries. You must have started the new thread and copied the arguments to the new thread before you can return from the spawn call, since otherwise the temporaries might have been destroyed in the meantime. > Sorry, IMO there's nothing "obvious" about your syntax. It looks cumbersome > and low-level to me. Right. That's exactly my criticism. Calling a function on a new thread should be just as simple as calling it sequentially. And spawn(foo)(a,b,c); i.e. not using the return value, should just create a detached thread. > I'm sure I'm never biased , and I tend to like your syntax better. > However, I recognize what Bill is concerned about. Let me suggest a > compromise: > > async_result later = spawn(foo)(a, b, c); > ... > thread& t = later.thread(); > // do whatever with t > ... > double now = later.join(); // or later.get() The way I went is to derive async_result from thread, so you get the .thread() function for free as a derived-to-base conversion. Actually, async_result<>=thread<> and thread=thread_base in what I have, but that's just naming. > You could also consider the merits of providing an implicit conversion > from async_result to T. Possible, but I'd say too confusing. Cheers W. - Wolfgang Bangerth email:[EMAIL PROTECTED] www: http://www.ticam.utexas.edu/~bangerth/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: A new boost::thread implementation?
Dave Abrahams said: > On Thursday, February 06, 2003 12:33 PM [GMT+1=CET], > William E. Kempf <[EMAIL PROTECTED]> wrote: > >> Dave Abrahams said: >> >> > > Hmm... that would be >> > > an interesting alternative implementation. I'm not sure it's as >> "obvious" as the syntax I suggested >> > >> > Sorry, IMO there's nothing "obvious" about your syntax. It looks >> cumbersome and low-level to me. Let me suggest some other syntaxes >> for async_result, though: >> > >> > async_call later(foo, a, b, c) >> > >> > or, if you don't want to duplicate the multi-arg treatment of >> bind(), just: >> > >> > async_call later(bind(foo, a, b, c)); >> > ... >> > ... >> > double d = later(); // call it to get the result out. >> >> The two things that come to mind for me with this suggestion are: >> >> 1) You've explicitly tied the result into the call. I chose the other >> design because the result is just that, only a result. > > Hm? How is the result not a result in my case? I didn't say it wasn't a result, I said that it wasn't "only" a result. In your case it's also the call. >> An asynchronous call can be bound to this result more than once. > > ...and if it can't be default-constructed? That's what boost::optional<> is for ;). >> 2) You're still hiding the thread creation. > > Absolutely. High-level vs. low-level. But I think too high-level. I say this, because it ties you solely to thread creation for asynchronous calls. >> This is a mistake to me for >> two reasons. First, it's not as obvious that a thread is being >> created here (though the new names help a lot). > > Unimportant, IMO. Who cares how an async_call is implemented under the > covers? I care, because of what comes next ;). >> Second, and this is more >> important, you've bound this concept to boost::thread explicitly. >> With the fully seperated concerns of my proposal, async_result can be >> used with other asynchronous call mechanisms, such as the coming >> boost::thread_pool. >> >>asyc_result res1, res2; >>thread_pool pool; >>pool.dispatch(bind(res1.call(foo), a, b, c)); >>pool.dispatch(bind(res2.call(foo), d, e, f)); >>d = res1.value() + res2.value(); > > This one is important. However, there are other ways to deal with this. > An async_call object could take an optional thread-creation parameter, > for example. It's not "thread-creation" in this case. You don't create threads when you use a thread_pool. And there's other examples as well, such as RPC mechanisms. And personally, I find passing such a "creation parameter" to be turning the design inside out. It might make things a little simpler for the default case, but it complicates usage for all the other cases. With the design I presented every usage is treated the same. More importantly, if you really don't like the syntax of my design, it at least allows you to *trivially* implement your design. Sometimes there's something to be said for being "lower level". >> > That's what we mean by the terms "high-level" and "encapsulation" >> ;-) >> >> Yes, but encapsulation shouldn't hide the implementation to the point >> that users aren't aware of what the operations actually are. ;) > > I don't think I agree with you, if you mean that the implementation > should be apparent from looking at the usage. Implementation details > that must be revealed should be shown in the documentation. I was referring to the fact that you have no idea if the "async call" is being done via a thread, a thread_pool, an RPC mechanism, a simple message queue, etc. Sometimes you don't care, but often you do. -- William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr - Exception safety reprise
"David B. Held" <[EMAIL PROTECTED]> wrote in message b1m57m$702$[EMAIL PROTECTED]">news:b1m57m$702$[EMAIL PROTECTED]... > > > [...] > > > I mean, the optimally_inherit eliminates the empty bases, and > > > yet there is size bloat. So VC++ makes the class bigger for > > > some other reason than that it has empty bases. I will try to > > > write some tests to see why that is, or at least how. > > > > I repeat, I bet it's MI-related. > > The proof of the pudding is in the eating. I got a chance to taste the pudding, the the results are inconclusive. The cause of the size bloat was that I had changed ref_counted to inherit from noncopyable. Seems like an innocent enough change. Seems that for the single-inheritance case, we should see some EBO action, right? Well, we do, unless ref_counted is a base in an MI hierarchy. Why its place in an hierarchy should change its size is a mystery to me, but taking out noncopyable restores that magical size. Now, I would appreciate it if people with Intel, CW, and some other compilers would try out the code in the sandbox and see if the first test passes (turn on --log-level=all, and pipe the output to your favorite paginator). Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [build] request for modification.
On Thursday, February 06, 2003 2:43 PM [GMT+1=CET], Gennaro Prota <[EMAIL PROTECTED]> wrote: > On Thu, 6 Feb 2003 12:20:59 -0500 (EST), Ronald Garcia > <[EMAIL PROTECTED]> wrote: > > > > It looks like the intel compiler still supports long long when used with > > the -ansi option. > > Do you mean /Za? We're discussing the linux compiler, and yes the Windows compiler also supports "-ansi". -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: A new boost::thread implementation?
On Thursday, February 06, 2003 12:33 PM [GMT+1=CET], William E. Kempf <[EMAIL PROTECTED]> wrote: > Dave Abrahams said: > > > > Hmm... that would be > > > an interesting alternative implementation. I'm not sure it's as > > > "obvious" as the syntax I suggested > > > > Sorry, IMO there's nothing "obvious" about your syntax. It looks > > cumbersome and low-level to me. Let me suggest some other syntaxes for > > async_result, though: > > > > async_call later(foo, a, b, c) > > > > or, if you don't want to duplicate the multi-arg treatment of bind(), > > just: > > > > async_call later(bind(foo, a, b, c)); > > ... > > ... > > double d = later(); // call it to get the result out. > > The two things that come to mind for me with this suggestion are: > > 1) You've explicitly tied the result into the call. I chose the other > design because the result is just that, only a result. Hm? How is the result not a result in my case? > An asynchronous call can be bound to this result more than once. ...and if it can't be default-constructed? > 2) You're still hiding the thread creation. Absolutely. High-level vs. low-level. > This is a mistake to me for > two reasons. First, it's not as obvious that a thread is being created > here (though the new names help a lot). Unimportant, IMO. Who cares how an async_call is implemented under the covers? > Second, and this is more > important, you've bound this concept to boost::thread explicitly. With > the fully seperated concerns of my proposal, async_result can be used with > other asynchronous call mechanisms, such as the coming boost::thread_pool. > >asyc_result res1, res2; >thread_pool pool; >pool.dispatch(bind(res1.call(foo), a, b, c)); >pool.dispatch(bind(res2.call(foo), d, e, f)); >d = res1.value() + res2.value(); This one is important. However, there are other ways to deal with this. An async_call object could take an optional thread-creation parameter, for example. > > I like the first one better, but could understand why you'd want to go > > with the second one. This is easily implemented on top of the existing > > Boost.Threads interface. Probably any of my suggestions is. > > Yes, all of the suggestions which don't directly modify boost::thread are > easily implemented on top of the existing interface. No duh ;-) > > That's what we mean by the terms "high-level" and "encapsulation" ;-) > > Yes, but encapsulation shouldn't hide the implementation to the point that > users aren't aware of what the operations actually are. ;) I don't think I agree with you, if you mean that the implementation should be apparent from looking at the usage. Implementation details that must be revealed should be shown in the documentation. > But I'll admit that some of my own initial confusion on this particular > case probably stem from having my brain focused on implementation details. Ha! > > > I found this > > > surprising enough to require careful thought about the FULL example > > > you posted to understand this. > > > > Like I said, I can't argue with user confusion. Does the name > > "async_call" help? > > Certainly... but leads to the problems I addresed above. There's likely a > design that will satisfy all concerns, however, that's not been given yet. P'raps. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [build] request for modification.
On Thu, 6 Feb 2003 12:20:59 -0500 (EST), Ronald Garcia <[EMAIL PROTECTED]> wrote: >It looks like the intel compiler still supports long long when used with >the -ansi option. Do you mean /Za? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shifted_ptr<> <-> $100 smart pointer policies question
"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
b1tvp7$da3$[EMAIL PROTECTED]">news:b1tvp7$da3$[EMAIL PROTECTED]...
> [...]
> $100 Question:
> When I am looking at the "Storage Policy", p. 189, Modern C++ Design;
> the class must be initialized by a StoredType object while in my situation
> the StoredType is a shifted_object and 'new (so) T' returns a pointer
> to T (member of shifted_boject). What am I supposed to do if I want
> to keep it optimized and simple?
Step 1) Check out policy_ptr in the sandbox. Step 2) Use the template
c'tor in smart_ptr. Step 3) Make your storage policy take the appropriate
type.
Here's the "raw pointer c'tor":
template
smart_ptr(U const& p)
: base_type(p, detail::init_first_tag())
{ checking_policy::on_init(get_impl(*this)); }
Here's what your storage_policy might look like:
template
class shifted_storage
{
public:
typedef shifted_object* stored_type;// the type of the
pointee_
typedef shifted_object*const_stored_type; // object
typedef T* pointer_type; // type returned by
operator->
typedef T const*const_pointer_type;
typedef add_reference::type
reference_type; // type returned by
operator*
typedef add_reference::type
const_reference_type;
typedef shifted_storage type;
typedef storage_policy_tag policy_category;
protected:
shifted_storage()
: pointee_(default_value())
{ }
template
shifted_storage(shifted_storage const& rhs)
: pointee_(default_value())
{ }
shifted_storage(scalar_storage const&)
: pointee_(default_value())
{ }
shifted_storage(pointer_type p)
: pointee_(static_cast(
static_cast(static_cast(p)) -
sizeof(shifted_header)
))
{ }
// I think the arithmetic above is valid, because we're dealing with
// POD types, but IANALL, so take it with a grain of salt
~shifted_storage()
{ boost::checked_delete(pointee_); }
void swap(scalar_storage& rhs)
{ std::swap(pointee_, rhs.pointee_); }
pointer_type get_pointer() const
{ return &pointee_->m_object; }
reference_type get_reference() const
{ return pointee_->m_object; }
bool is_valid() const
{ return pointee_ != default_value(); }
public:
friend inline pointer_type get_impl(shifted_storage const& sp)
{ return &sp.pointee_->m_object; }
friend inline stored_type& get_impl_ref(shifted_storage& sp)
{ return sp.pointee_; }
protected:
void release()
{ pointee_ = 0; }
static stored_type default_value()
{ return 0; }
private:
stored_type pointee_;
public:
BOOST_MPL_AUX_LAMBDA_SUPPORT(1, shifted_storage, (T))
};
#ifdef __BORLANDC__
namespace mpl { BOOST_MPL_AUX_VOID_SPEC(1, shifted_storage) }
#endif
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: integral_c on g++2.95.3
On Thu, 06 Feb 2003 18:54:16 +0100, Gennaro Prota <[EMAIL PROTECTED]> wrote: >and defined, the former to either > >BOOST_STATIC_CONSTANT(type, alias = expr) or nothing, and the latter >to name or expr, according to the compiler. To expr or alias. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shared_ptr question (with respect to thread safety)
From: "Trey Jackson" <[EMAIL PROTECTED]>
> Hamish Mackenzie wrote:
> >These scoped locks will go out of scope before you "do stuff".
>
> Right, thanks for the catch.
>
> I started writing it thinking I'd be doing some cool new
> meta-programming, but it turned into just simple object inheritance
> (thus the function calls that let the locks go out of scope).
>
> But my original intent was actually to try to get code substituted at
> compile time.
>
> e.g.
>
> template
> class userClass {
> void function() {
> // code is inserted here, not a function call to a member of
ToBeSubstituted
> ToBeSubstituted::insertCode;
> }
> }
>
> class SubstituteHello {
>insertCode {
> cout << "hello world" << endl;
> }
> }
>
> class SubstituteGoodbye {
>insertCode {
> cout << "goodbye world" << endl;
> }
> }
>
>
> userClass u1;
> u1.function(); // prints 'hello world'
>
> userClass u2;
> u2.function(); // prints 'goodbye world'
>
>
>
>
>
> Any tips on how to do this?
> Is it possible in C++? I can see how to do it with lisp macros.
> I'm reading the MPL intro written by David Abrahams and Aleskey
> Gurtovoy, but it's slow going...
I don't think you need that document. Whatever could be:
typedef void fn(); static fn
In other words, make them static functions. userClass::function just needs
to add a couple of parens after "insertCode" ;-)
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shared_ptr question (with respect to thread safety)
Peter Dimov wrote: >Have you tried? ;-) Nope, I'm afraid I'd mess it up - as in the point below. >Nope. You still need the counter mutex penalty. See example 2, that modifies >two different shared_ptr instances, with well defined results. Those two >instances can well share a count. Ahhh..., I didn't see that. point: The reference count is per object allocated, not per pointer. >Yep. But a well designed program doesn't need this construct. The extra >overhead would only "help" badly designed programs, but everyone will have >to pay. Right, I was still operating under the idea that you could make it work with just one mutex per shared_ptr. >I'm pretty sure that there are programs where the unnecessary >synchronization overhead would be unacceptable. But these cases are much >rarer than one might think. Yeah, I'd have thought so too. But I'm currently sharing the QTs between threads and messed something up b/c the threaded version (with >1 thread) takes many times as long as the serial version... And I was tired of having to recompile pretty much everything in the project b/c I'd changed a basic container. That's another thread for another group. >Depends on what you mean by "a technical reason". It is very controversial >whether the cost of an extra template parameter can be considered a >technical reason. :-) Fair enough. Since writing template code is always a struggle between me and the compiler I can see the desire to avoid adding extra template parameters. TJ -- Trey Jackson [EMAIL PROTECTED] "... at this point, the elephant is looking like an irate Roseanne." -- Fran Drescher ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Smart pointers: One more implementation +question
Pavel Vasiliev wrote: [...] > I really think that having the only mutex for all short smart > pointer-related interlocked operations will not harm performance of > real-life applications in mp systems. In my code this mutex is used > only for really short operations like "lock, increment, save to > temporary, unlock, test the temporary". It is hard to imagine that > contention will often occur for so short operations. Well, "raw" contention aside, with "ping-pong" I mean that with your design clients might rather quickly get into trouble with respect to "false sharing" effect(s) -- writing to "cache line" that is also held by another processor. The problem here is rather expensive communications needed to invalidate the other processor's cache-line, feed it with "up-to-date" data [that's most likely an additional "slow trip" to memory], etc. Well, you might want to take a look at: < "Performance Management Guide" [AIX 5L Version 5.1] > http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/2365c31.htm#HDRI42667 (Lock Granularity) http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/2365c31.htm#HDRI26126 (Cache Coherency) http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/2365c33.htm#HDRI14109 (Multiprocessor Throughput Scalability) < etc. "general" stuff from this publication > regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shared_ptr question (with respect to thread safety)
Hamish Mackenzie wrote:
>These scoped locks will go out of scope before you "do stuff".
Right, thanks for the catch.
I started writing it thinking I'd be doing some cool new
meta-programming, but it turned into just simple object inheritance
(thus the function calls that let the locks go out of scope).
But my original intent was actually to try to get code substituted at
compile time.
e.g.
template
class userClass {
void function() {
// code is inserted here, not a function call to a member of ToBeSubstituted
ToBeSubstituted::insertCode;
}
}
class SubstituteHello {
insertCode {
cout << "hello world" << endl;
}
}
class SubstituteGoodbye {
insertCode {
cout << "goodbye world" << endl;
}
}
userClass u1;
u1.function(); // prints 'hello world'
userClass u2;
u2.function(); // prints 'goodbye world'
Any tips on how to do this?
Is it possible in C++? I can see how to do it with lisp macros.
I'm reading the MPL intro written by David Abrahams and Aleskey
Gurtovoy, but it's slow going...
TJ
--
Trey Jackson
[EMAIL PROTECTED]
Pilots usually try to equalize the following equation:
# takeoffs = # landings
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Minimal test tool - very minor comments
From: "Gennadiy Rozental" <[EMAIL PROTECTED]> > > Plain black on white please. Sorry to be so boring. > > Use btl-simple.css style instead of btl.css. Both are located in style > subdirectory. You will need to change the header of doc files for that It's hard to understand why you're still using colors despite the fact that people have almost universally requested that you change to be consistent with the rest of the Boost site, and that IIRC you asked Beman and I to weigh in and we agreed with the requests for black-on-white. FWIW, many studies have been done which bear this out as the most-effective combination; examine any website professionally-designed for a major company and you will find that this practice is used almost universally. There's a reason for that: it works. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Suggestion for new test library test tool
> I would like to suggest the addition of the test tool > BOOST_CHECK_NO_THROW to the boost test library. It's purpose should be > obvious from the name and I think it would be quite handy when testing > construction of objects. > > Markus Why would you need that? It's already checked automatically. If exception is thrown, you will get the notificatinon from test monitor. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: integral_c on g++2.95.3
On Thu, 6 Feb 2003 06:05:23 -0600, Aleksey Gurtovoy
<[EMAIL PROTECTED]> wrote:
>Fernando Cacciola wrote:
>> I was suspicious of next/prior in integral_c<> from the beggining...
>> That's why I asked what was the intended role of integral_c<>,
>> and why does it feature next/prior.
>
>It has 'next'/'prior' members because it's the easiest/most efficient
>way to implement 'next/prior< integral_c >::type' functionality
>on compilers that don't support partial template specialization.
However, if we agree that when having autonomous next/prior we will
only use them to access next/prior< .. >::type and that the user
*must* specialize them for everything else than integral_c we could
use:
template
struct next {
typedef integral_c type;
};
template
struct prior {
typedef integral_c type;
};
which doesn't require PTS. Of course the problem of dealing with
compiler idiosyncracies is now shifted to next and prior rather than
being on integral_c directly. However I find that having a conditional
around a whole template definition is at least clearer than having it
in its middle just for a single member.
If the problem that we have here is general enough we could probably
have two new macros, say (just thinking out loud):
DECLARE_NON_TYPE_TEMPLATE_ARGUMENT_ALIAS(type, expr, alias)
and
#define USE_NON_TYPE_TEMPLATE_ARGUMENT(expr, alias)
which would be used, for instance, as:
template
struct next {
DECLARE_NON_TYPE_TEMPLATE_ARGUMENT_ALIAS
(T::value_type, T::value, alias);
typedef integral_c< typename T::value_type,
(USE_NON_TYPE_TEMPLATE_ARGUMENT(T::value, alias) + 1)> type;
};
and defined, the former to either
BOOST_STATIC_CONSTANT(type, alias = expr) or nothing, and the latter
to name or expr, according to the compiler. Disgusting things to code
though, just like the conditionals :-/
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Minimal test tool - very minor comments
> > > 1 Need to have language extensions enabled. (for WINNT?) > > > > Do I use any nonstandard language extensions? > > No, but code that gets pulled in (WINNT?)does, so the MS project Properties > requires /Za. This is a minor disadvantage if you like to be 'strict'. Could you be more specific which header require this option? BTW MSVC65 does not seems to require it. > > > 2 Need to have /EHa rather than /EHs for async exceptions. (for WINNT?) > > > > You need to clarify on that. Why would I want to force async exception > > model? > > I can't imagine, but the MSVC compiler 7.0 reports that /EHa is required for it > to compile, and it does. (I suspect it is something like winnt.h that is pulled > in?) MSVC 6.5 does not require async model. Would be strange for 7.0 to require it. > > > 4 Warnings level 4 ok, (except get two warnings about test_main's unused > > args). They are used. Sorry I misundestood you. You could not declare argments names in test_main if you are not using them > Plain black on white please. Sorry to be so boring. Use btl-simple.css style instead of btl.css. Both are located in style subdirectory. You will need to change the header of doc files for that. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [build] request for modification.
From: "Ronald Garcia" <[EMAIL PROTECTED]> > On Wed, 5 Feb 2003, Dave Abrahams wrote: > > > On Wednesday, February 05, 2003 7:26 PM [GMT+1=CET], > > Ronald Garcia <[EMAIL PROTECTED]> wrote: > > > > > On Wed, 5 Feb 2003, Dave Abrahams wrote: > > > > > > > On Wednesday, February 05, 2003 5:58 PM [GMT+1=CET], > > > > Ronald Garcia <[EMAIL PROTECTED]> wrote: > > > > > > > > > On Wed, 5 Feb 2003, Rene Rivera wrote: > > > > > > > > > > > [2003-02-05] Ronald Garcia wrote: > > > > > > > > > > > > > > I would like to request the addition of the -ansi flag to the > > > > > > > [ ... ] > > > > > > > > I think that if all the flag does is to cause errors on incorrect code, we > > should just add it and forget about options. However, if it disables > > certain language extensions like long long that are not likely to be used > > unintentionally, we should think twice. > > > > 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. Thanks, Dave -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost.Test with templated test cases... or is itbind?(was:Howto make Boost.Test work with function objects?)
> >test->add(BOOST_TEST_CASE(::boost::bind(&fn, 1))); > > I just tried this and MSVC7 tells me: > > test_charset.cpp(50) : error C2664: > 'boost::unit_test_framework::test_case > *boost::unit_test_framework::create_test_case(void (__cdecl > *)(void),std::string)' : cannot convert parameter 1 from > 'boost::_bi::bind_t' to 'void (__cdecl *)(void)' > with > [ > R=void, > F=void (__cdecl *)(int), > L=boost::_bi::list_av_1::type > ] > No user-defined-conversion operator available that can > perform this conversion, or the operator cannot be called > > Is this a problem with me, my compiler, or something else? > > Markus Did you include unit_test_suite_ex.hpp? If yes, try to separate &fn: function0 tc = &fn Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: A new boost::thread implementation?
Dave Abrahams said: >> Hmm... that would be >> an interesting alternative implementation. I'm not sure it's as >> "obvious" as the syntax I suggested > > Sorry, IMO there's nothing "obvious" about your syntax. It looks > cumbersome and low-level to me. Let me suggest some other syntaxes for > async_result, though: > > async_call later(foo, a, b, c) > > or, if you don't want to duplicate the multi-arg treatment of bind(), > just: > > async_call later(bind(foo, a, b, c)); > ... > ... > double d = later(); // call it to get the result out. The two things that come to mind for me with this suggestion are: 1) You've explicitly tied the result into the call. I chose the other design because the result is just that, only a result. An asynchronous call can be bound to this result more than once. 2) You're still hiding the thread creation. This is a mistake to me for two reasons. First, it's not as obvious that a thread is being created here (though the new names help a lot). Second, and this is more important, you've bound this concept to boost::thread explicitly. With the fully seperated concerns of my proposal, async_result can be used with other asynchronous call mechanisms, such as the coming boost::thread_pool. asyc_result res1, res2; thread_pool pool; pool.dispatch(bind(res1.call(foo), a, b, c)); pool.dispatch(bind(res2.call(foo), d, e, f)); d = res1.value() + res2.value(); > I like the first one better, but could understand why you'd want to go > with the second one. This is easily implemented on top of the existing > Boost.Threads interface. Probably any of my suggestions is. Yes, all of the suggestions which don't directly modify boost::thread are easily implemented on top of the existing interface. >> as evidenced by the questions I've raised here, > > Can't argue with user confusion I guess ;-) > >> but worth considering. Not sure I care for "spawn(foo)(a, b, c)" >> though. I personally still prefer explicit usage of Boost.Bind or some >> other binding/lambda library. But if you want to "hide" the binding, >> why not just "spawn(foo, a, b, c)"? > > Mostly agree; it's just that interfaces like that tend to obscure which > is the function and which is the argument list. OK. That's never bothered me, though, and is not the syntax used by boost::bind, so I find it less appealing. >> > This approach doesn't get the asynchronous call wound up with the >> meaning of the "thread" concept. >> >> If I fully understand it, yes it does, but too a lesser extent. What >> I mean by this is that the async_result hides the created thread >> (though you do get access to it through the res.thread() syntax). > > That's what we mean by the terms "high-level" and "encapsulation" ;-) Yes, but encapsulation shouldn't hide the implementation to the point that users aren't aware of what the operations actually are. ;) But I'll admit that some of my own initial confusion on this particular case probably stem from having my brain focused on implementation details. >> I found this >> surprising enough to require careful thought about the FULL example >> you posted to understand this. > > Like I said, I can't argue with user confusion. Does the name > "async_call" help? Certainly... but leads to the problems I addresed above. There's likely a design that will satisfy all concerns, however, that's not been given yet. -- William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [build] request for modification.
On Wed, 5 Feb 2003, Dave Abrahams wrote: > On Wednesday, February 05, 2003 7:26 PM [GMT+1=CET], > Ronald Garcia <[EMAIL PROTECTED]> wrote: > > > On Wed, 5 Feb 2003, Dave Abrahams wrote: > > > > > On Wednesday, February 05, 2003 5:58 PM [GMT+1=CET], > > > Ronald Garcia <[EMAIL PROTECTED]> wrote: > > > > > > > On Wed, 5 Feb 2003, Rene Rivera wrote: > > > > > > > > > [2003-02-05] Ronald Garcia wrote: > > > > > > > > > > > > I would like to request the addition of the -ansi flag to the > > > > > > [ ... ] > > > > > I think that if all the flag does is to cause errors on incorrect code, we > should just add it and forget about options. However, if it disables > certain language extensions like long long that are not likely to be used > unintentionally, we should think twice. > 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. Cheers, ron ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: A new boost::thread implementation?
> >> async_result res; > >> thread t(bind(res.call(), a, b, c)); > >> // do something else > >> d = res.value(); // Explicitly waits for the thread to return a > >> value? > > > > This does the same, indeed. Starting a thread this way is just a little > > more complex (and -- in my view -- less obvious to read) than writing > > thread t = spawn(foo)(a,b,c); > > Not sure I agree about "less obvious to read". If your syntax had been >thread t = spawn(foo, a, b, c); > I think you'd have a bit more of an argument here. And I certainly could > fold the binding directly into boost::thread so that my syntax would > become: > > thread t(res.call(), a, b, c); > > I could even eliminate the ".call()" syntax with some implicit > conversions, but I dislike that for the obvious reasons. I specifically > chose not to include syntactic binding in boost::thread a long time ago, > because I prefer the explicit seperation of concerns. So, where you think > my syntax is "less obvious to read", I think it's "more explicit". If you do all this, then you'll probably almost arrive at the code I posted :-) Still, keeping the analogy to the usual call foo(a,b,c), I prefer the arguments to foo in a separate pair of parentheses. However, there is another point that I guess will make your approach very hard: assume void foo(int, double, char); and a potential constructor for your thread class template thread (void (*p)(A,B,C), A, B, C); Then you can write foo(1,1,1) and arguments will be converted automatically. However, you cannot write thread t(foo, 1, 1, 1); since template parameters must be exact matches. There really is no other way than to first get at the argument types in a first step, and pass the arguments in a second step. You _need_ two sets of parentheses to get the conversions. > > Actually it does duplicate the work, but not because I am stubborn. We > > have an existing implementation for a couple of years, and the present > > version just evolved from this. However, there's a second point: when > > starting threads, you have a relatively clear picture as to how long > > certain objects are needed, and one can avoid several copying steps if > > one does some things by hand. It's short anyway, tuple type and tie > > function are your friend here. > > I'm not sure how you avoid copies here. Since you have control over lifetimes of objects, you can pass references instead of copies at various places. > > t->kill (); > > t->suspend (); > > Someone sees that there's a function yield() but doesn't have the time > > to read the documentation, what will he assume what yield() does? > > How does "someone see that there's a function yield()" with out also > seeing that it's static? No need to read documentation for that, as it's > an explicit part of the functions signature. Seeing it used in someone else's code? Just not being careful when reading the signature? I think it's the same argument as with void* : if applied correctly it's ok, but in general it's considered harmful. W. - Wolfgang Bangerth email:[EMAIL PROTECTED] www: http://www.ticam.utexas.edu/~bangerth/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Suggestion for new test library test tool
I would like to suggest the addition of the test tool BOOST_CHECK_NO_THROW to the boost test library. It's purpose should be obvious from the name and I think it would be quite handy when testing construction of objects. Markus ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_class
On Wed, 05 Feb 2003 14:37:34 +0100, Daniel Frey
<[EMAIL PROTECTED]> wrote:
>Maybe it's just me but the boost source is feeling more
>and more unmaintainable given the extrem use of MACROs to workaround
>each and every problem some compilers have. Am I the only one who feels
>uncomfortable with it?
No, you are not the only one. Conditionals are also sometimes abused.
Another scourge is the "#include the world" problem: sometimes, for
instance, just one or two of the type traits are needed and you find
#include (removed now, AFAICS from the CVS). Now,
I'm not pointing out the oversight, all the more so because Dave has
corrected it, but that include, alone, inflates the include tree by
764 entries. That's the case for other boost headers as well. So think
about what harms it is when you use them light-heartedly.
Genny.
begin 644 IncludeTree.zip
M4$L#!!0(``J-1B[2>/%@7!8``+L_`@`/26YC;'5D951R964N='AT
M[5U1;]NXTGU?8/]#@._Y%FVGV_OJK2:R$
MEDEI9BB*H\6E,TM6D^/!V/-_^ZV91EW=P\
M?_CTX?;;AX]_WOS[Z73S_V9S\_'+S:>O?]Y^_//SMYO;CQ]7O__V^V^-J9L/
M^9\WN^)@;FYO_J\XY+O3UKS>X_[UW^U5([__=M-B^&^Z>_[AOFE>'AZ*Q_>;
M]6_X_OON1E^&;G1_JDU%N-OJT^#=:K,S>;/.R_VQV)EJ369[]Q%S_[K9[HJ-
M\^[N%KP7GIO]9#WM[Z>FV!7-K[_&;FK3_H:A?=QES4-9[0G$K38^KP;;Z&Y^
M_[,XK&ZI]_XZS/_T\%#\?7U/]WVM/^]ZC?56O^^*?=O9/SS]Y>X2_A%A/>/O
M>5:W';<9>$?>^UR0J9NJ.#S^-6R6_U;6:/A>E/7#SZWC5OC;W=H6>JG1[KFZ
ML'9K_L[-L?_<>'>^L^Z<[1[+JFB>]B-WQM_]XFWGS:^C0=P:@+K]''BBKGW=^=V^_VB]-0]A%`'DYCK*GJ[LNH?9
M@R8QZZP-#+_6]='DX;P!O'9'#&BON<].?Z_[EY,C@`]!K&\]X_B-];$RQZK,
M35V7U?TQJ[)]P,#N@](BEG"G6JV[3$<80&EUA/04?L$&YWEZNNW%57D6Z$3[
M&&O)D3WY+WE]]%,^R[`AY8;PB]
MMT5JF?,<
M\5$]VX12I3L7)#37X2#(HVBN0T,8[11Z,HQQZH`>QE[#)<']2HV5GM#4M^58
M%H>F/U%)!;(!0ABOS+X='.VX>#"5.>0F7J]SM40@NJG*'^;P/B\;/T#Y6NQ(
M1\YV.,\QHDP"<"BE$TT`K@N4()P`O+93BR=`$',YQ>)EB"A`&&MIE1%Q8@K`
M]2:S"BH`PU'[EBU%E5<`7V,>3<-2@9J$APPM3<)I"*.M23@58>PU":?ZX)5G
M/5+44.%IR'93"%I@T$2Y+KH)0I);U'-DXOU6")6,V*/"0^T6GT6VO]A-&?4!
MY"8UB]0L,HRZ9I%I.A[OQR422/<7G_$3(B'I1`">TGZQDSB2+M
M-X1*N38I&ZN*_[8^F
MC.,`1J."[EMAIL PROTECTED]',.I:K>U.MC.:%,ZS#>'HWD;R*L8W*!
M3$-8MN0"CX^$#,J%(&O29E4NA)F32GZX$&:)A.S+A3"K$KA?`->+S;FFJ@\V
M9REC@&U`Y"5/+OBX7L?HE8?=L(432G0;`[1[$@VQ>+N]J,ZS73;Q-G4=4,W2
M%"7XF*>]:8H$P_"J>1KUKM"1QEGW""04QQV(3.4)Y0Y:0N*B'/DQ#Y["*(@G7O5=#]]D
MW<+K2:2+6!XGR0(VR"*9XC7,I(4%Y06+UC#+!,[N2!>K;-X+6H?B-R*12/7Q
M]45TWTFGR53J@`'7,]VX8J`YG/9)GGC7,('NA)OH#8%`&I$!I%]-T">-R+WZ
MF_0DYXSX#K.]JG4@;?1LBDWH;@9CP'.@J^E?!M:;K^$WPHSP!4W[XL2%!@_Q
MM-LX#H%,1^<8=(XA!L+,TCD&G6,@@.OU=(YA0K`-D3G'X`G]JU0;2PYAP(R^
M\D5\%9DP;^ZQO<5/B5QW+ZV!4\'CI#5PK8&S$6:-UL`C@.O=M`8^`=A&R*N!
M]Y4'YH,CN>5O7&EVDM-1AX!KFU:SWYO]QE3QN0-(-`AF)$X6_-QQE>;S]0^G
M0P[1:9YW`>!Q$O9B`&&&X`NZK_>#FW7W61=MI(AO((#/K3,TT>*G#D%OZ1:1
MNR8JNP/(E!94>@?PN$DOOP."+)-;@@>$F2:Q#`\(LTIZ*1X09F'B'<;,6)7ZXO4O7'.B:@TD19I:N
M.=`U!P1PO9ZN.9@0;$-DKCGP1O]OK%T-TJTZ<*@QVM>-V2'M;J06A\X`>=\W
M.IXR_D-8L/!0IIW.LC@LZBDCRL6B"`M-'LA4%I(X\#A)3AJ"+-)U--*MT74T
M$<#U;KJ.9@*PC9"WCL:A/U:(+Z=F30<&Z%\OI<%],#C'JA02;<(:@8C;LY`H
M>V1?S,Y,X>?S&`EE*==OZ#$B<\G1(&OT&!&IEN@Q(A."Z\7T&)$`L`V0=8S(
M592^DS2-/D"\=Y!(^MWT\%P1BCA6;\"3M,3DQ,=/VD#S4?&HXI&,(&M4/*IX
MI"',*A6/:+`YJWBDP\?U6C+P8O3,TG'X7&/<)W3MXZXC]0Y,JR-D$W6&*WKX
M"FK^?/Y!Y(^KR#26\:1Y^Z&K-B:"QT>UL6IC$L(L46T\(;A>3+5Q`-@&R-+&
M5W+HDZ19?!^!876,VQ7CN6Q'/JT=D_`/$)^U;IRA?E/&(IU])RN.-_XHHVL=E/.((
M)3?W^HI!PC[_D4A%<]V@5`7-XR)1/0=9(DLYAYFR$,6P0,4<9E$"M?++'5URINIRTZ,QCL3$`='V#HNF@D`!@&"&>]+:,6PQG?SE,5*#WG$
M^H24&8>'M:S=FL@4M/JGU3\JPDS1ZI]6_\[@>BNM_C'`)B^P^N>.Q7=2ILF'
M3!B1SUH'U#J@#T%6:!UP.H19H'7``'"]DM8!"6`3%U8'=,?8A10#?3W6;^SQ
M5XI'_-HJN_PW-6D`I65:P2_>US$Q&$[U@UTV1E7ZZXO'Y%6N_U@<=#Z[T"S=!Z[S@_&L*LT7JO%VRN6N\=AX_C
M0'!=2J$7442PK=R:=(L^+]MF%GUC&0"@MT\K`";M*Z
MW%,+?A@$6:(%O^D19H46_"8`UUMIP8\!-GF!!3]G*%[4:D^WF-#BGQ;_?`BR
M0HM_TR',`BW^!8#KE;3X1P";N+#BGS/$+J4$B-A#SA9$[Q^XS\90PG?=")J(
M]QUO_2F"'Z+H%;M4BF")._4=8L33WC3%A.X400ZQLO&%7)7-M![:;HU0F)W3
M43HHVH$GTAFA%#8L1ZV%521X7+2PJH754819H875"<#U5EI898!-7DAAU1%\
MOPI?06D_1<0$;&OA)JL-?$'4OH-629L9Y^P]C7>A%+?*(-^U&=Z\W==NE4`V
MA5MS4<5UB],A2>"P6R8D")79MW%OG3_'8PQ`-4^@O:G*'^;0IM;[8[$S561E
M"R!9@/\*<:Z#;0$D$SSN.N98[$#B:0W*2!EF'Q1ZA(_WWG\4+^7L@TQ)>`K:
M!X^;Q)2TCR#+Y!V19B/,-$G'I=D(LTKJT6DVPBQ,=(R:#:XW'!U.<_V*!)/V+KZX&9*'TR%/=_IXCT`W!'$KDV;H'P`B=WS.\Y#M:@,"YK1+'W;Z
M9#IS/+XE<=!Q/7B/WY;'E'#0L76#];&IUD]F=S01HTX'-BV"AQ?X8O#)_4;K
M%9.!QTOK%5JOF`1A%FF](B*X7D_K%1.";8C,>H4C[O^!GQ[:2"Q9$-;\1]L0
MO`.%-FT?\RA;:W>@T):I$KG#5+I"Y'&2K`Z#+)*I#,-,6EC$6[`B#+,LH1KD
M>K?42I#-6]*88!N12`'Z^#J"^3=ILU4#W(<^A\"=8-,^^-;K-,4FQL$[`"9[
M`0?:`)CL$ZPB9S*5IURYKD6R:N7QD:I8@ZR1IU;#S%E05%ZH2@VS*I%"Y7JQ
ME.J4S7DAW\O[#4B@2GUPUO>?H=D
M&IH1:484@C!S-"/2C,@!KA?3C"@`;`-D943N4"WFT'.`AX`MFG$KTF!EUV,5
M0S$C*))6H;UO'Q5K.=HX8TP?F&'='((H;N:UW/S'Y#,?UG71+"U12C>3AP`M@&RTN.K*/V9M:PG669\AUOU>2PCQ"D$
M.UPJE#*WQ*4^$9,U!$=3DC]#ME_R/\W]/YB2.4,@V\:V1]=PE[[WB
M)(P;G6\+A],3QJ^B2S5=Y*2=X/PI(D7"P5,;34[9X/'1Y%234Q+"+-'D=$)P
MO9@FIP%@&R`L.74$:DQ&)2E#Q:U.C+2_'X(?;FEBG.5=X_0^X]8A/I>MXRO2
M[%J"V:KFO/'#!G:YF3GUN6IZ),E/,=2]'*U$_GM>-]MV$/\UK\?T4L.[H?M*5=&OTI*L(X'JWT>&26
[boost] Re: Re: mpl::is_sequence< incomplete_type >?
Aleksey,
> Yep, I understand that; but I was specifically interested whether
> _incomplete types_ are an important case here. If it's more than
> just a corner-case situation, I'll look into fixing it.
[snip]
> But 'is_sequence' does work on MSVC 7.0, in general. So, unless
> passing an incomplete type is a common-place situation, I would
> recommend just to document the pitfall itself.
In my application the argument passed to is_sequence is _never_ a complete
type. See below for reasons.
> It was. Fixed now in the CVS.
Thank you very much! Both apply and apply1 work now. I will use apply1 as
you recommended.
Best regards,
Andreas
P.S. The following is an outline of how I define the states of a
statemachine. Inner states must "know" their outer state for much the same
reasons as a derived class must "know" its base. However, an outer state
must also be able to define which of its inner states is the initial state
(see 1). This leads to a circular dependency that can only be broken if the
InnerInitial parameter is permitted to be an incomplete type. To support
concurrent (or orthogonal) states an outer state can have multiple inner
initial states, that's why the user can also specify a list. Finally, an
empty list means that the defined state does not have an inner state, i.e.
it is itself a leaf state (2).
// our statemachine (context of all outermost states)
class StopWatch : public /* */ { /* */ };
template<
class Derived,
class Context, // either an outer state or a state_machine
class InnerInitial = mpl::list<> >
class state { /* */ };
// forward declare the inner initial state
class Running;
// the outer state
class Active : public state< Active, StopWatch, Running /* 1 */ > {};
// an inner state that happens to be the initial state
class Running : public state< Running, Active /* 2 */ > {};
// another inner state
class Paused : public state< Paused, Active /* 2 */ > {};
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: A new boost::thread implementation?
From: "William E. Kempf" <[EMAIL PROTECTED]> > > From: "Wolfgang Bangerth" <[EMAIL PROTECTED]> > >> This does the same, indeed. Starting a thread this way is just a > >> little more complex (and -- in my view -- less obvious to read) than > >> writing > >> thread t = spawn(foo)(a,b,c); > >> > >> But that's just personal opinion, and I'm arguably biased :-) > > > > I'm sure I'm never biased , and I tend to like your syntax better. > > However, I recognize what Bill is concerned about. Let me suggest a > > compromise: > > > > async_result later = spawn(foo)(a, b, c); > > Mustn't use the name spawn() here. It implies a thread/process/what ever > has been spawned at this point, which is not the case. Or has it (he says > later, having read on)? It has. > > ... > > thread& t = later.thread(); > > The thread type will be Copyable and Assignable soon, so no need for the > reference. Hmm... does this member indicate that spawn() above truly did > create a thread that's stored in the async_result? Yes. > Hmm... that would be > an interesting alternative implementation. I'm not sure it's as "obvious" > as the syntax I suggested Sorry, IMO there's nothing "obvious" about your syntax. It looks cumbersome and low-level to me. Let me suggest some other syntaxes for async_result, though: async_call later(foo, a, b, c) or, if you don't want to duplicate the multi-arg treatment of bind(), just: async_call later(bind(foo, a, b, c)); ... ... double d = later(); // call it to get the result out. I like the first one better, but could understand why you'd want to go with the second one. This is easily implemented on top of the existing Boost.Threads interface. Probably any of my suggestions is. > as evidenced by the questions I've raised here, Can't argue with user confusion I guess ;-) > but worth considering. Not sure I care for "spawn(foo)(a, b, c)" though. > I personally still prefer explicit usage of Boost.Bind or some other > binding/lambda library. But if you want to "hide" the binding, why not > just "spawn(foo, a, b, c)"? Mostly agree; it's just that interfaces like that tend to obscure which is the function and which is the argument list. > And if we go this route, should be remove the boost::thread constructor > that creates a thread in favor of using spawn() there as well? > >thread t = spawn(foo, a, b, c); Good point. I dunno. I don't see a problem with the idea that async_call adds little or nothing to thread > > This approach doesn't get the asynchronous call wound up with the > > meaning of the "thread" concept. > > If I fully understand it, yes it does, but too a lesser extent. What I > mean by this is that the async_result hides the created thread (though you > do get access to it through the res.thread() syntax). That's what we mean by the terms "high-level" and "encapsulation" ;-) > I found this > surprising enough to require careful thought about the FULL example you > posted to understand this. Like I said, I can't argue with user confusion. Does the name "async_call" help? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: io operations for stl containers?
Jason House wrote:
> Terje Slettebø wrote:
>
> > Another possibility might be to have a sentry object, doing automatic state
> > saving and restoring in the constructor and destructor. In fact, there are
> > already such classes in Boost: Daryle Walker's I/O state savers, which fits
> > this situation like a glove.
> >
>
> I think that I like your solution better :) putting it constructor/deconstructor
> does seem better. I can't even argue that it's more typing for multi-line
> expressions...
Well, I know at least have more fuel to think about...
First of all, does your constructor take the stream as an argument? It would have to
in order to do state saving in the constructor... If so, that at least makes prevents
the following case (that probably needs special handling)
{
io_format<> var1(...);
std::cout << var1 << stuff;
std::cerr << var1 << more_stuff;
}
My understanding is that the constructor would not perform state saving, but that it
is the call to << that has to perform the locking. So what happens when multiple
streams are used?
what happens when you have 2 or more io_formats in the same function used on the same
stream?
example
{
io_format var1(...), var2(...);
std:: cout << var1 << stuff1;
std::cout << var2 << stuff2;
std::cout << var1 << stuff3;
std::cout << var2 << stuff4;
std::cout << io_format(...) << stuff5;
} /* deconstruct all 3 io_format's ... not necessarilly in the right order! */
Here, var1, var2, and the unnamed class from the last line in the function are all
being deconstructed at the same time. Some caution needs to occur here. Is that what
the state-saver class you referred to does already?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: A new boost::thread implementation?
> From: "Wolfgang Bangerth" <[EMAIL PROTECTED]> >> This does the same, indeed. Starting a thread this way is just a >> little more complex (and -- in my view -- less obvious to read) than >> writing >> thread t = spawn(foo)(a,b,c); >> >> But that's just personal opinion, and I'm arguably biased :-) > > I'm sure I'm never biased , and I tend to like your syntax better. > However, I recognize what Bill is concerned about. Let me suggest a > compromise: > > async_result later = spawn(foo)(a, b, c); Mustn't use the name spawn() here. It implies a thread/process/what ever has been spawned at this point, which is not the case. Or has it (he says later, having read on)? > ... > thread& t = later.thread(); The thread type will be Copyable and Assignable soon, so no need for the reference. Hmm... does this member indicate that spawn() above truly did create a thread that's stored in the async_result? Hmm... that would be an interesting alternative implementation. I'm not sure it's as "obvious" as the syntax I suggested, as evidenced by the questions I've raised here, but worth considering. Not sure I care for "spawn(foo)(a, b, c)" though. I personally still prefer explicit usage of Boost.Bind or some other binding/lambda library. But if you want to "hide" the binding, why not just "spawn(foo, a, b, c)"? And if we go this route, should be remove the boost::thread constructor that creates a thread in favor of using spawn() there as well? thread t = spawn(foo, a, b, c); > // do whatever with t > ... > double now = later.join(); // or later.get() > > You could also consider the merits of providing an implicit conversion > from async_result to T. The merits, and the cons, yes. I'll be considering this carefully at some point. > This approach doesn't get the asynchronous call wound up with the > meaning of the "thread" concept. If I fully understand it, yes it does, but too a lesser extent. What I mean by this is that the async_result hides the created thread (though you do get access to it through the res.thread() syntax). I found this surprising enough to require careful thought about the FULL example you posted to understand this. -- William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: A new boost::thread implementation?
From: "Wolfgang Bangerth" <[EMAIL PROTECTED]> > > > double d; > > > thread t = spawn(foo)(a,b,c); > > > // do something else > > > d = thread.return_value(); > > > > A solution like this has been proposed before, but I don't like it. This > > creates multiple thread types, instead of a single thread type. I think > > this will only make the interface less convenient, and will make the > > implementation much more complex. For instance, you now must have a > > seperate thread_self type that duplicates all of thread<> except for the > > data type specific features. These differing types will have to compare > > to each other, however. > > Make the common part a base class. That's how the proposal I sent you does > it :-) > > > > async_result res; > > thread t(bind(res.call(), a, b, c)); > > // do something else > > d = res.value(); // Explicitly waits for the thread to return a value? > > This does the same, indeed. Starting a thread this way is just a little > more complex (and -- in my view -- less obvious to read) than writing > thread t = spawn(foo)(a,b,c); > > But that's just personal opinion, and I'm arguably biased :-) I'm sure I'm never biased , and I tend to like your syntax better. However, I recognize what Bill is concerned about. Let me suggest a compromise: async_result later = spawn(foo)(a, b, c); ... thread& t = later.thread(); // do whatever with t ... double now = later.join(); // or later.get() You could also consider the merits of providing an implicit conversion from async_result to T. This approach doesn't get the asynchronous call wound up with the meaning of the "thread" concept. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] shifted_ptr<> <-> $100 smart pointer policies question
Hi,
I have a question about smart pointer policies. I feel this is some
missing link in shifted_ptr.
Definitions:
1)
struct shifted_header
{
union
{
int m_count;
void * m_owner;
};
...
};
2)
template
struct shifted_object
{
shifted_header m_header;
T m_object;
};
3)
void * operator new (size_t, shifted_type const &) returns a pointer of type
T, sizeof(shifted_object), member of shifted_object.
$100 Question:
When I am looking at the "Storage Policy", p. 189, Modern C++ Design; the
class must be initialized by a StoredType object while in my situation the
StoredType is a shifted_object and 'new (so) T' returns a pointer to T
(member of shifted_boject). What am I supposed to do if I want to keep
it optimized and simple?
Thanks,
Philippe A. Bouchard
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: A new boost::thread implementation?
> >> > double d; >> > thread t = spawn(foo)(a,b,c); >> > // do something else >> > d = thread.return_value(); >> >> A solution like this has been proposed before, but I don't like it. >> This creates multiple thread types, instead of a single thread type. >> I think this will only make the interface less convenient, and will >> make the implementation much more complex. For instance, you now must >> have a seperate thread_self type that duplicates all of thread<> >> except for the data type specific features. These differing types >> will have to compare to each other, however. > > Make the common part a base class. That's how the proposal I sent you > does it :-) Simplifies the implementation, but complicates the interface. >> async_result res; >> thread t(bind(res.call(), a, b, c)); >> // do something else >> d = res.value(); // Explicitly waits for the thread to return a >> value? > > This does the same, indeed. Starting a thread this way is just a little > more complex (and -- in my view -- less obvious to read) than writing > thread t = spawn(foo)(a,b,c); Not sure I agree about "less obvious to read". If your syntax had been thread t = spawn(foo, a, b, c); I think you'd have a bit more of an argument here. And I certainly could fold the binding directly into boost::thread so that my syntax would become: thread t(res.call(), a, b, c); I could even eliminate the ".call()" syntax with some implicit conversions, but I dislike that for the obvious reasons. I specifically chose not to include syntactic binding in boost::thread a long time ago, because I prefer the explicit seperation of concerns. So, where you think my syntax is "less obvious to read", I think it's "more explicit". > But that's just personal opinion, and I'm arguably biased :-) As am I :). >> Hopefully you're not duplicating efforts here, and are using >> Boost.Bind and Boost.Function in the implementation? > > Actually it does duplicate the work, but not because I am stubborn. We > have an existing implementation for a couple of years, and the present > version just evolved from this. However, there's a second point: when > starting threads, you have a relatively clear picture as to how long > certain objects are needed, and one can avoid several copying steps if > one does some things by hand. It's short anyway, tuple type and tie > function are your friend here. I'm not sure how you avoid copies here. Granted, the current implementation isn't optimized in this way, but it's possible for me to reduce the number of copies down to what I think would be equivalent to a hand coded implementation. >> > thread<> t = spawn(foo)(a,b,c); >> > t.yield ();// oops, who's going to yield here? >> >> You shouldn't really ever write code like that. It should be >> thread::yield(). But even if you write it the way you did, it will >> always be the current thread that yields, which is the only thread >> that can. I don't agree with seperating the interfaces here. > > I certainly know that one shouldn't write the code like this. It's just > that this way you are inviting people to write buglets. After all, you > have (or may have in the future) functions > t->kill (); > t->suspend (); > Someone sees that there's a function yield() but doesn't have the time > to read the documentation, what will he assume what yield() does? How does "someone see that there's a function yield()" with out also seeing that it's static? No need to read documentation for that, as it's an explicit part of the functions signature. > If there's a way to avoid such invitations for errors, one should use > it. I understand the theory behind this, I've just never seen a real world case where someone's been bitten in this way. I know I never would be. So I don't find it very compelling. But as I said elsewhere, I'm not so opposed as to not consider making these free functions instead because of this reasoning. I would be opposed to another class, however, as I don't think that solves anything, but instead makes things worse. -- William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] A new boost::thread implementation?
On Wednesday, February 05, 2003 4:05 PM [GMT+1=CET], William E. Kempf <[EMAIL PROTECTED]> wrote: > > On Wednesday, February 05, 2003 3:04 PM [GMT+1=CET], > > William E. Kempf <[EMAIL PROTECTED]> wrote: > > > > > > What I would like to see is a new boost::thread implementation > > > which meets the following requirements. > > > > > > > > a. There shall be two interfaces to a thread. One for creation of a > > > >thread, from here on called boost::thread. And, one for the > > > > created thread, from here on called boost::thread::self. > > > > > > Self? Why? If it's on operation that can *only* be made on the > > > current thread, then a static method is a better approach. Otherwise, > > > I could make a "self" instance and pass it to another thread, which > > > could then attempt an operation that's not valid for calling on > > > another thread. > > > > It would seem to me that, given the availability of p->yield() as a > > syntax for invoking a static function, it'd be better to use a > > namespace-scope function to avoid errors and for clarity. > > OK, I can buy that over a seperate self class. This was discussed at one > point, but the particular issue with p->yield() was never brought up. I'm > not sure I find it compelling, because which thread yields should be > evident from the documentation, and I don't see anyone ever using this > syntax. But compelling or not, I'm not opposed to making this a free > function if others think it's clearer in this regard. Here's the extent of my argument: 1. It's easy to miss "static" in a member function declaration 2. Various things lead people to write this->foo() even for static functions 3. Other people reading that code may tend to write that->foo() Anyway, I'm not heavily committed to this argument, but I've grown away from using static member functions in this way, and tend toward free functions for clarity. Now I tend to just use static members as a way of carrying a function along with a type in a metaprogramming context -- the type gets passed to a template and the function can then be used -- much like using function pointers as template parameters. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Repost: [boost] [regex] Linker errors with MSVC
John Maddock wrote:
> > I'm reposting this, because I think, that this bug should be fixed,
> > but there wasn't any response to the first mail. I would
> try to fix it
> > myself, but the errors are so weird, that I'm not able to
> grasp, how
> > to do it :-)
>
> Sorry I missed the first one: the problem is simple: the
> header you are using (boost/regex/src.hpp) is undocumented
> and deprecated, and doesn't include all the source files any
> more (I'll get that fixed though). Add instances.cpp and
> winstances.cpp to the list of source files included and it
> should fix your problem.
I've added (after the #include "boost/regex/src.cpp"):
#include "libs/regex/src/instances.cpp"
#include "libs/regex/src/winstances.cpp"
But this doesn't solve the unresolved externals linker errors (sorry :-)
Regards Hartmut
> > >
> > > Hi all,
> > >
> > > I get a bunch of linker errors while compiling the following
> > > testcase with VC6.5/VC7.1 (current Boost CVS):
> > >
> > > test_regex.cpp:
> > >
> > > #include
> > >
> > > #define BOOST_REGEX_NO_LIB
> > > #define BOOST_REGEX_STATIC_LINK
> > > #include "boost/regex.hpp"
> > > #include "boost/regex/src.cpp"
> > >
> > > int main()
> > > {
> > > boost::reg_expression rxstr;
> > > char const *pteststr = "anyregexp";
> > >
> > > rxstr = std::string("anyregexp");
> > > boost::match_results what;
> > > boost::regex_search(pteststr, &pteststr[9], what, rxstr,
> > > boost::match_default);
> > > return 0;
> > > }
> > >
> > > Command line: cl -I$(BOOST_ROOT) -GX test_regex.cpp
> > >
> > > Note: the regex library isn't given to the compiler!
> > >
> > > At least one other compiler (I tried ICL7.0) compiles and
> links this
> > > without any problems. Any clues?
> > >
> > > Regards Hartmut
> > >
> > >
> > >
> > > ___
> > > Unsubscribe & other changes:
> > > http://lists.boost.org/mailman/listinfo.cgi/boo> st
> > >
> >
> >
> >
> > ___
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>
> ___
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boo> st
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Smart pointers: One more implementation +question
Andrei Alexandrescu wrote: >> (in short: "Parameterization discourages users", "Template parameters >> affect the type", "Having a single pointer type is important for >> stable library interfaces". Sorry for possible out-of-context citation) > Your agreement with the statements above would naturally lead you to NOT > define yet another smart pointer, but instead, to work on perfecting > shared_ptr. Convictions and actions should best work in agreement. "One > Pointer Type is Good" and "I Have One More Pointer Implementation For You > Guys to Look At" don't go together. So if you were to start work on a > project now, what smart pointer would you use for a stable library > interface? If you'd use yours, does it mean you consider it intrinsically > better than shared_ptr? I think many would disagree for a variety of > objective reasons. (Some of them I mentioned in a reply to shifted_ptr, and > if I'm not wrong they apply to your work as well.) Then you might say, yes, > it all depends on what the project's context is. Then I come and say, /my > point exactly/. boost::shared_ptr must retain compatiblility with older versions. It can not be turned to another ways without harming many current users. I tried to write a more generic implementation that still replicates the strongest features of shared_ptr. For example, refc_ptr supports true intrusive ptrs with their little overhead. And it even supports semi-intrusive ptrs that are a clear replacement for intrusive ones. In this sense, yes, I think that refc_ptr is better than shared_ptr. I propose the idea. If it deserves living (that is still to be verified), I don't mind if it is implemented in some other smart pointer, for example policy-based one. > The whole purpose of smart_ptr is to devise a framework that makes it easy > for people like *you* to create their own smart pointers without having to > fight their way through all the syntactic and semantic gunk. Yes. In one of my projects I used 4 different types of smart pointers. 3 of them were std::auto_ptr, COM-ptr and a self-made library-specific ptr. It would be nice to have all these pointers in one framework like Loki::SmartPtr. But I still sure that pointers of the family like boost::shared_ptr (and my refc_ptr) are another story. Fighting through the syntactic, semantic and portability problems is challenge, but their functionality is even harder challenge. > Not that I don't think the fun aspect ain't important. I think this is my > main problem with Loki::SmartPtr: people seem to have more fun writing > smart pointers from scratch, than writing policies for it. If that persists > over time, then by all means Loki::SmartPtr ain't that cool. Seriously: fun > *is* important :o). :-) This my refc_ptr is about 2 years old. I improved it from time to time, after looking to boost, or reading Modern C++ Design. All this were for my own pleasure, you are right. For me your Loki::SmartPtr was rather a collection of well-defined considerations and hints. Most probably, I am not alone in this... I think you also designed Loki::SmartPtr mostly for your own fun :-). Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Minimal test tool - very minor comments
An absolutely invaluable tool.
> >
> > Perhaps worth documenting for MSVC 7.0 (and probably 6.5?)
> >
> > 1 Need to have language extensions enabled. (for WINNT?)
>
> Do I use any nonstandard language extensions?
No, but code that gets pulled in (WINNT?)does, so the MS project Properties
requires /Za. This is a minor disadvantage if you like to be 'strict'.
>
> > 2 Need to have /EHa rather than /EHs for async exceptions. (for WINNT?)
>
> You need to clarify on that. Why would I want to force async exception
> model?
I can't imagine, but the MSVC compiler 7.0 reports that /EHa is required for it
to compile, and it does. (I suspect it is something like winnt.h that is pulled
in?)
> > 3 std for loop scope is OK.
> I did not get this at all. What do you mean?
(/Zc:forScope) C++ Standard is permitted. This would cause users a problem if
they used code assuming the non-standard previous for loop scope extending after
the end of the loop. So users could be reassured that there isn't a problem
here.
> > 4 Warnings level 4 ok, (except get two warnings about test_main's unused
> args). They are used.
But not by my program, so when I swap int main(){.. to int test_main(int argc,
char* argv[]){ .. I get the entirely expected warnings. I'm only saying that
users would like to know that they can safely use the most picky warning level 4
safely.
> > (and there are several spilling misfakes in that section
> Did you mean "spelling mistakes"? Could you send them to me?
For example (& I think I saw others when I read it before):
'invironment'. ' usiform' errors
Minimal 'testinf' facility
you will be limited 'ti' the set of features
to 'snitch' to one the two 'chaises' above.
(Mea culpa too. I haven't found how to spell check html documents as effectively
as MS Word yet). Suggestions from other Boosters?
> > - and why is the document background so gray?)
> All pages have the same background. What would you prefer?
Plain black on white please. Sorry to be so boring.
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] binding
Hi all,
Could someone please tell me how to achieve a functor binding to a templated
function?
I have a namespace GenAlg with this inside:
namespace GenAlg
{
template
unsigned long RouletteWheel(TController *oController)
{
...
}
}
elsewhere I have a
boost::function1 fncSelection;
I try to set fncSelection to RouletteWheel like so:
fncSelection = boost::bind(GenAlg::RouletteWheel,_1);
And my compiler's reply is:
genetics.obj : error LNK2001: unresolved external symbol "unsigned long
__cdecl GenAlg::RouletteWheel(class CGAController *)"
(?RouletteWheel@GenAlg@@YAKPAVCGAController@@@Z)
Help? Please?
I'm sure this is stupid, simple stuff for you guys, and so annoying for me
:)
Greg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Smart pointers: One more implementation +question
Alexander Terekhov wrote: >> >> "Pavel Vasiliev" <[EMAIL PROTECTED]> wrote in message >> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> > [...] >> > In my implementation of refc_ptr operator= performs >> > incrementing/decrementing within a single guarded section (since >> > the only global instance of interl. op. mutex is used for all > ^ >> > cases). So the copying via operator= is about twice faster in my >> > implementation. > Really? What about contention? Well, it's a nice way to play > ping-pong on a multiprocessor system... or am I just missing > and/or misunderstanding something? Ok, I expected this question just from you, Alexander :-). Much of my thread safety knowledge is adjusted by your postings and links that you provided in them. I really think that having the only mutex for all short smart pointer-related interlocked operations will not harm performance of real-life applications in mp systems. In my code this mutex is used only for really short operations like "lock, increment, save to temporary, unlock, test the temporary". It is hard to imagine that contention will often occur for so short operations. Though the problem may be with contention while in a system-level code for locking/unlocking. The time it takes may be large enough. But to my knowledge (please correct me if I misunderstand something) usually no matter which exactly mutex is being locked/unlocked - all CPUs must wait due to hardware issues. But even if I am wrong, slight performance loses due to contension seem (to me) to be not important compared to the resources saved (only one mutex instead of a new one for each allocated object. Spinlock is not always available). > It's probably a bit more exciting to take care of all possible races > without "a true lock" protecting both counters. I'm not sure that the > true locking is *necessary* to support weak references. Do you have > an illustration, Pavel? Alexander, I can not currently add more to the discussions concerning weak references support. I mean that I have the same issues as Peter Dimov with shared_ptr/weak_ptr. My implementation differs but the problem is much the same: "test and conditionally increment". I would be very interested to learn about a portable way to protect both counters with only one interlocked operation. But if it takes two or more interl. ops., then the spinlock mutex does the things better. Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: io operations for stl containers?
Terje Slettebø wrote:
> >From: "Jason House" <[EMAIL PROTECTED]>
> > I thought of one thing that might work reasonably well.
> >
> > How about making ++io_format< T > save the current format in a stack.
> > and having io_format< T>-- restore the previously queuued format
>
> I've thought of the exact same thing. :) Not how the syntax for it would be,
> but when I was thinking of this, it suddenly occurred to me: State savers!
>
> This essentially creates a scope in the state space. As you say, you may
> then read the currently set format, and restore it afterwards. The
> restoration is important, and there are issues such as exception safety.
>
> > so, then something like
> >
> > > > std::cout << ++io_format("\n|","|\n","|")--
> > > > << ++io_format (&)[3][3]>("---","---","---")--
> > > > << board << '\n';
> >
> > would save and restore the formating for char(&)[3][3] and char(&)[3] and
> never
> > stomp on anything else.
>
> In this case, it seems it saves and restores the format, before the format
> gets a chance to be used. In other words, the scope only covers the state
> saving, not the output.
The idea was pre-increment and post-decrement... I wasn't sure if pre & post
operators work the same for classes as they do for primitive types.
> Another possibility might be to have a sentry object, doing automatic state
> saving and restoring in the constructor and destructor. In fact, there are
> already such classes in Boost: Daryle Walker's I/O state savers, which fits
> this situation like a glove.
>
> In your original posting, you had this example:
>
> >For instance, if you have a type
> >map >
>
> >and custom_object's stream output uses io_format >, then
> >you are going to run into trouble if it wants a different formatting.
>
> Such a custom object may then have something like the following in its
> stream output:
>
> boost::io::ios_pword_saver(stream,index);
>
> // Set stream state, and do output.
>
> That's all. :)
>
> This also ensures that the state is restored properly, even in the presence
> of exceptions, something the ++/-- way won't do. Of course, this requires
> the pword-index, so one might make the interface more user friendly, and fit
> the rest, for example by making the state saver a manipulator, itself.
>
> As I understand, the lifetime of a temporary object extends until the end of
> the full expression it's used in, so the following should be well-defined:
>
> std::vector v;
>
> std::cout << composite_save >() << composite_format(...) << v <<
> '\n';
>
> This saves the format at the start, and restores it at the end.
>
> An alternative is a named temporary, such as:
>
> composite_save > sentry(stream);
>
> // Set format and do output
I think that I like your solution better :) putting it constructor/deconstructor
does seem better. I can't even argue that it's more typing for multi-line
expressions...
When I originally started this, I said that it was the same complaint I have about
io_manip... It would be neat to have a replacement/wrapper boot library for
io_manip.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shared_ptr question (with respect to thread safety)
On Wed, 2003-02-05 at 18:09, Trey Jackson wrote:
> template
> class mySuperLockedClass : public LockingStrategy
> {
> public:
> void read()
> {
> LockingStrategy::readlock();
> // do stuff
> }
> void write()
> {
> LockingStrategy::writelock();
> // do stuff
> }
> };
>
...
> struct
> MutexLockingStrategy
> {
> boost::mutex m_;
> void readlock()
> {
> boost::mutex::scoped_lock l(m_);
> }
> void writelock()
> {
> boost::mutex::scoped_lock l(m_);
> }
> };
>
These scoped locks will go out of scope before you "do stuff".
You can extend the scope using something like...
template
class mySuperLockedClass : public LockingStrategy
{
public:
void read()
{
typename LockingStrategy::read_lock_type l( this );
// do stuff
}
void write()
{
typename LockingStrategy::write_lock_type l( this );
// do stuff
}
};
struct
MutexLockingStrategy
{
boost::mutex m_;
class read_lock_type
{
public:
readlock_type( MutexLockingStrategy * s ) : l_( s->m_ )
private:
boost::mutex::scoped_lock l_;
}
class write_lock_type
{
public:
writelock_type( MutexLockingStrategy * s ) : l_( s->m_ )
private:
boost::mutex::scoped_lock l_;
}
};
// etc.
--
Hamish Mackenzie <[EMAIL PROTECTED]>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Smart pointers: One moreimplementation+question
Peter Dimov wrote: > > intrusive_ptr will be "official" (read: I finally wrote something resembling > a documentation) in the upcoming 1.30. But that's not my point. My point is > that you need an intrusive smart pointer. Of course shared_ptr cannot offer I know I needed an intrusive smart pointer, the question was how to get it. For Loki, it took me some time to figure out some details on how to write the correct policy and it then worked fine. For boost, I only found the solution for shared_ptr and was surprised to see the object growing that much. > this with its non-intrusive design. It never attempted to. The optional > intrusive counting "feature" (that's been removed) was offered only as a > potential solution to the "shared from this" problem. I understand. Well, I think I should then try to add intrusive_ptr to my benchmark and see how it performs :) 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] Re: Re: Smart pointers: One more implementation +question
On Thursday, February 06, 2003 8:10 AM [GMT+1=CET], David Bradley <[EMAIL PROTECTED]> wrote: > I wonder if there may have been issues or holes in the policy based > pointer implementation that I worked on years ago that we didn't > encounter or think about at the time. I'm trying to figure out where the > wasted space would be in a policy based design. Most compilers don't optimize away the space for empty base classes in a multiple inheritance scenario. See http://www.boost.org/libs/utility/operators.htm#chaining -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] is_class
John Maddock wrote: > > Seems I don't understand the current version in detail. Isn't the > fall-back version basically: > > is_class = >!is_union && >!is_array && >!is_reference && >!is_void && >!is_function > > No, you missed out is_pointer and is_member_pointer and maybe other from the > list. Why can't I see them?? Look at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/boost/type_traits/is_class.hpp?rev=1.5&content-type=text/vnd.viewcvs-markup There is no !is_pointer or !is_member_pointer there. I don't get it, sorry... 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] Re: Re: Re: Re: Smart pointers: One moreimplementation+question
Daniel Frey wrote: > Peter Dimov wrote: >> >> Daniel Frey wrote: >>> >>> I aim for a smart pointer which is 4 bytes and adds another 4 bytes >>> to the intrusivly counted object - no more. AFAICS boost cannot >>> offer this with the current design. >> >> If I understand correctly, you are saying that you want something >> close to boost::intrusive_ptr, but boost::shared_ptr is not it. > > The documentation mentions scoped_ptr, scoped_array, shared_ptr, > shared_array and weak_ptr. I don't know which of all the other > pointers occasionally mentioned at this list are "officially" > supported smart pointers. Is there a list available that I can refer > to to select the right pointer? intrusive_ptr will be "official" (read: I finally wrote something resembling a documentation) in the upcoming 1.30. But that's not my point. My point is that you need an intrusive smart pointer. Of course shared_ptr cannot offer this with its non-intrusive design. It never attempted to. The optional intrusive counting "feature" (that's been removed) was offered only as a potential solution to the "shared from this" problem. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Smart pointers: One more implementation +question
Dave Abrahams wrote: Not so for Boost 1.29.0: you didn't have to pay for a separate count object. In the current CVS, you do. However, using BOOST_SP_USE_QUICK_ALLOCATOR, having a separate count object doesn't have to incur any "extra" storage per object. If the mozilla designers want less storage overhead than that, they'd have to give up features of boost::smart_ptr that would seem to be important for a project like that: weak references, correct interoperability across DLL boundaries, safe upcasting of pointers to objects without virtual destructors, to name a few. None of that is to say that they didn't make the right choice for their project. That's good to know. This discussion has brought up some issues that I probably need to raise about what's being done in Mozilla as well. I have some concerns, because creating smart pointers can appear to be deceptively simple. That's a shame. There's no reason we can't "go the policy based route" as well, provided we can get the issues worked out. As I suggested earlier, and as evidenced by the choices of the Mozilla designers, people who want custom smart pointers are usually interested in efficiency. So far, we don't have a policy-based design which doesn't incur wasted space for *each pointer* on common compilers. That's a lot more serious than incurring overhead once, for a separate count object, in a lot of applications, since the whole point of a "shared" pointer is that there are more pointers than objects ;-) I wonder if there may have been issues or holes in the policy based pointer implementation that I worked on years ago that we didn't encounter or think about at the time. I'm trying to figure out where the wasted space would be in a policy based design. Any overhead at the for the pointer is something to seriously consider and weigh. David Bradley ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Do Jamfiles need copyrights?
On Thursday, February 06, 2003 6:57 AM [GMT+1=CET], Toon Knapen <[EMAIL PROTECTED]> wrote: > Recently had a talk with a patent-laywer from Philips. I deduced following > from this conversation (my own interpretation and IANAL) > > Copyright is automatic. From the moment you make something, you own the > copyright (so > actually no explicit copyright statement is necessary although it is > advised). From the > moment you change a file that is copyrighted by somebody else, copyright is > shared (of course, generally the copyright does not allow you to make > modifications) > > Now open-source projects (including boost) want to provide more rights to > the user as the default copyright allows. So we add a copyright notice also > indicating a license. This license is necessary to allow others to make > modifications, distribute it etc. > > So that's why the boost source-code can be considered open-source. However > if a Jamfile > does not contain a license, default copyright-right apply and thus the > Jamfile can not be distributed by others than the copyright-holder. > > So we certainly need to add a license statement and at the same time might > indicate > the copyright too (Indicating the license is still the most important > aspect). This all corresponds pretty well to what lawyers have been telling me. Also, remember that Sean parent asked that when the license requires a copy of itself in all "copies", it should say "copies of the source code", just to avoid misunderstanding about any requirement to include it in executables. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Repost: [boost] [regex] Linker errors with MSVC
> I'm reposting this, because I think, that this bug should be fixed, but
> there wasn't any response to the first mail. I would try to fix it
> myself, but the errors are so weird, that I'm not able to grasp, how to
> do it :-)
Sorry I missed the first one: the problem is simple: the header you are
using (boost/regex/src.hpp) is undocumented and deprecated, and doesn't
include all the source files any more (I'll get that fixed though). Add
instances.cpp and winstances.cpp to the list of source files included and it
should fix your problem.
> >
> > Hi all,
> >
> > I get a bunch of linker errors while compiling the following
> > testcase with VC6.5/VC7.1 (current Boost CVS):
> >
> > test_regex.cpp:
> >
> > #include
> >
> > #define BOOST_REGEX_NO_LIB
> > #define BOOST_REGEX_STATIC_LINK
> > #include "boost/regex.hpp"
> > #include "boost/regex/src.cpp"
> >
> > int main()
> > {
> > boost::reg_expression rxstr;
> > char const *pteststr = "anyregexp";
> >
> > rxstr = std::string("anyregexp");
> > boost::match_results what;
> > boost::regex_search(pteststr, &pteststr[9], what, rxstr,
> > boost::match_default);
> > return 0;
> > }
> >
> > Command line: cl -I$(BOOST_ROOT) -GX test_regex.cpp
> >
> > Note: the regex library isn't given to the compiler!
> >
> > At least one other compiler (I tried ICL7.0) compiles and
> > links this without any problems. Any clues?
> >
> > Regards Hartmut
> >
> >
> >
> > ___
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boo> st
> >
>
>
>
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] is_class
Seems I don't understand the current version in detail. Isn't the fall-back version basically: is_class = !is_union && !is_array && !is_reference && !is_void && !is_function No, you missed out is_pointer and is_member_pointer and maybe other from the list. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] regression tests on Aix
I'm forced to halt my weekly updates of the Aix status pages for a while. Both machines we have are at the end of their lease and we're still discussing with IBM on the terms of a new machine. I hope the situation will be resolved quickly. Sorry for the inconvenience. still-commited-to-update-the-VisualAge-status-pages-at-least-weakly- and-assist-developers-ly yours. toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Smart pointers: One more implementation+question
Peter Dimov wrote: > > Daniel Frey wrote: > > > > I aim for a smart pointer which is 4 bytes and adds another 4 bytes > > to the intrusivly counted object - no more. AFAICS boost cannot offer > > this with the current design. > > If I understand correctly, you are saying that you want something close to > boost::intrusive_ptr, but boost::shared_ptr is not it. The documentation mentions scoped_ptr, scoped_array, shared_ptr, shared_array and weak_ptr. I don't know which of all the other pointers occasionally mentioned at this list are "officially" supported smart pointers. Is there a list available that I can refer to to select the right pointer? 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] shared_ptr question (with respect to thread safety)
Trey Jackson wrote: > Peter Dimov wrote: > >The overhead is usually acceptable, even with a plain pthread_mutex. > > Agreed. With that in mind, why wasn't the shared_ptr *also* protected > by a mutex? Because that would be two mutexes instead of one, which directly translates to twice as much time overhead + per-pointer size overhead for the additional mutex, all that for questionable benefits. > You *could* make all reasonable operations on pointers thread safe > with a mutex. (where reasonable = all the examples shown on the > boost::shared_ptr documentation). Have you tried? ;-) > Why wasn't that done? > > i.e. > if the reference count for a shared pointer is thread safe > in simultaneous write, why not make the pointer value thread safe as > well? See above. Per-pointer mutex, questionable value. > from boost docs: > , >> boost::shared_ptr p, p3; >> >> // thread A >> p = p3; // reads p3, writes p >> >> // thread B >> p3.reset(); // writes p3, simultaneous read/write undefined > ` > > you've already got the mutex "penalty" in the counter. > why not pull it out of there, put it in the shared pointer, > and then you've got thread safe pointers. right? Nope. You still need the counter mutex penalty. See example 2, that modifies two different shared_ptr instances, with well defined results. Those two instances can well share a count. Furthermore, even if the above were defined, why would you want to do that? The value of p would be unspecified, depending on what thread got there first. > i understand that there's no guarantee on what p will point to, but > we know it's not going to point to garbage - but it *will* be p3 or 0. Yep. But a well designed program doesn't need this construct. The extra overhead would only "help" badly designed programs, but everyone will have to pay. > I started thinking about this with my own work. > I've got a query-tree class (2-D binary tree) that sometimes needs to > be thread-safe, and sometimes not - in the same executable. > > e.g. I want to be able to do: > > QT unsafe_tree; > > QT thread_safe_tree; > > and this applies to all sorts of containers/classes. Yes, this is a reasonable design. It's a tradeoff between safety and performance. You assert that you'll never, ever, share unsafe_tree between threads. For container classes this is pretty easy to enforce. With shared_ptr things are a bit more complicated since it often leads to designs where it's not known in advance whether a particular shared_ptr instance is shared with other parts of the program. It is typically a good idea to mentally track ownership, but in some cases it's easier to just think locally, and not bother with the big picture. I'm pretty sure that there are programs where the unnecessary synchronization overhead would be unacceptable. But these cases are much rarer than one might think. > >> Just wondering if the above strategy could be used in the case of > >> shared_count, and if not, why not? > > > >Because of the extra LockingStrategy parameter. :-) > > Yeah, but is there a technical reason for not doing something like the > above? Depends on what you mean by "a technical reason". It is very controversial whether the cost of an extra template parameter can be considered a technical reason. :-) > I'm wondering what the downside would be? > > The upsides I can see are: > > 1) pulls mutex details outside of the class > 2) gets rid of ugly '#ifdef BOOST_HAS_THREADS' lines Actually the mutex details are already outside of the class. They are encapsulated in lightweight_mutex. The ugly #ifdef lines are redundant, too. You can remove them in your local copy, and things will still work. #ifdefs are there only because some compilers can't optimize out the empty mutex, and others can, but complain for unused variables and code with no effects. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Smart pointers: One more implementation+question
Daniel Frey wrote: > > I aim for a smart pointer which is 4 bytes and adds another 4 bytes > to the intrusivly counted object - no more. AFAICS boost cannot offer > this with the current design. If I understand correctly, you are saying that you want something close to boost::intrusive_ptr, but boost::shared_ptr is not it. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: integral_c on g++2.95.3
Fernando Cacciola wrote: > I was suspicious of next/prior in integral_c<> from the beggining... > That's why I asked what was the intended role of integral_c<>, > and why does it feature next/prior. It has 'next'/'prior' members because it's the easiest/most efficient way to implement 'next/prior< integral_c >::type' functionality on compilers that don't support partial template specialization. Of course, on a conforming compiler, they don't have to be there. > If our interpretation is correct, next/prior would render the program > ill-formed in some usages of integral_c<> with enums, so, if it is > intended to represent 'integral constant expressions' and not just > 'integral values' I think it should have next/prior removed. That's what I'll do, for the conforming platforms. Thanks for pursuing the issue, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost.Test with templated test cases... or is it bind?(was:How to make Boost.Test work with function objects?)
Hubert Holin wrote:
I am stumbling on another problem, though.
Given
boost::unit_test_framework::test_suite * test = BOOST_TEST_SUITE("");
if I have the following normal function
void fn(int)
{
}
then I can do the following
test->add(BOOST_TEST_CASE(::boost::bind(&fn, 1)));
I just tried this and MSVC7 tells me:
test_charset.cpp(50) : error C2664:
'boost::unit_test_framework::test_case
*boost::unit_test_framework::create_test_case(void (__cdecl
*)(void),std::string)' : cannot convert parameter 1 from
'boost::_bi::bind_t' to 'void (__cdecl *)(void)'
with
[
R=void,
F=void (__cdecl *)(int),
L=boost::_bi::list_av_1::type
]
No user-defined-conversion operator available that can
perform this conversion, or the operator cannot be called
Is this a problem with me, my compiler, or something else?
Markus
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Results of Cray SV1 regression tests
On Wednesday 05 February 2003 23:26, Matthias Troyer wrote: > On Wednesday, February 5, 2003, at 04:52 PM, Toon Knapen wrote: > > On Wednesday 05 February 2003 10:27, Matthias Troyer wrote: > >> After we get the regrssion tests to work, there will be a special > >> challenge for ublas or MTL-3: Calling the BLAS routine where > >> appropriate will be essential in getting any decent performance on > >> these types of CPUs. Does anybody know what the progress is on calling > >> BLAS from ublas where appropriate? > > > > The BLAS and LAPACK bindings for ublas are not complete yet but the > > most important functions are available. > > Great. Is this part of the boost CVS It's in the sandbox. If you're not familiar with the sandbox, drop me a line. > > > > Recently, Joerg started adding blocked operations (which deteriorate > > performance > > on vector-processors) so in the future we might need configuration > > macros to > > indicate if we're on superscalar or vector machines. > > That will indeed be useful once we start running large production codes > with sparse matrices on vector machines. For dense matrices the BLAS > calls should take care of the optimization? Again an advantage of using vendor-tune blas ;-) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Do Jamfiles need copyrights?
Recently had a talk with a patent-laywer from Philips. I deduced following from this conversation (my own interpretation and IANAL) Copyright is automatic. From the moment you make something, you own the copyright (so actually no explicit copyright statement is necessary although it is advised). From the moment you change a file that is copyrighted by somebody else, copyright is shared (of course, generally the copyright does not allow you to make modifications) Now open-source projects (including boost) want to provide more rights to the user as the default copyright allows. So we add a copyright notice also indicating a license. This license is necessary to allow others to make modifications, distribute it etc. So that's why the boost source-code can be considered open-source. However if a Jamfile does not contain a license, default copyright-right apply and thus the Jamfile can not be distributed by others than the copyright-holder. So we certainly need to add a license statement and at the same time might indicate the copyright too (Indicating the license is still the most important aspect). On Wednesday 05 February 2003 23:18, Beman Dawes wrote: > At 01:16 PM 2/5/2003, Martin Wille wrote: > > >Beman Dawes wrote: > >> Bjorn Karlsson and I are wondering if Boost should require copyrights > on > >> Jamfiles. > > > >Jamfiles are part of the build system; they won't become part of > >a an executable. So everything is fine when a vendor ships a > >binary or a DLL. > > > >However, when Boost is incorporated to some other open source > >project, missing copyrights and licences might become a problem. > > > >Moreover, copyright statements hinder evil-doers to wrongfully > >claim ownership. > > > >I'm not a lawyer, so I'm just guessing, bit I think we should > >put copyrights into Jamfiles, Makefiles and the like as well. > > I'm convinced. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: mpl::is_sequence< incomplete_type >?
Andreas Huber wrote: > > It might be possible to fix it, but it will require some work. Let > > me know if it's important for you, and I'll move it up in my TODO > > list. > > Well, it is not that important since mpl::is_sequence<> is only used > to provide some syntactic sugar. Yep, I understand that; but I was specifically interested whether _incomplete types_ are an important case here. If it's more than just a corner-case situation, I'll look into fixing it. > I could just as well tell my users > that they always have to specify an mpl::list containing a single > type instead of a type under MSVC... But 'is_sequence' does work on MSVC 7.0, in general. So, unless passing an incomplete type is a common-place situation, I would recommend just to document the pitfall itself. > P.S. While making my first serious steps with mpl yesterday, I ran > into some weird errors while trying to compile the following with > MSVC 7.0. Could this also be a limitation of my platform? It was. Fixed now in the CVS. But even on conforming compilers, the following line is currently problematic, because of the maximum arity limit on metafunctions that can participate in lambda expressions: typedef boost::mpl::transform< trans_list, boost::mpl::apply< _, Running > >::type handler_list; Since, under the cover, the main 'apply' template has BOOST_MPL_METAFUNCTION_MAX_ARITY + 1 template parameters, it fails to be properly handled by the lambda facility, causing the code to fail. A short-term workaround is to use a numbered 'apply' form instead - in your case, 'apply1'. I'll look into fixing the problem for the upcoming release. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Smart pointers: One more implementation +question
On Thu, 06 Feb 2003 03:20:14 +0100, Dave Abrahams wrote:
> On Wednesday, February 05, 2003 3:53 PM [GMT+1=CET], Daniel Frey
> <[EMAIL PROTECTED]> wrote:
>
>> > Which compiler? How were you using intrusive counting?
>>
>> I used some benchmark code which compared several smart-pointers (my
>> own and the boost version). I had a simple class
>>
>> #define LOAD int dummy[2];
>>
>> struct A0 { LOAD };
>> struct A1 : boost::counted_base { LOAD };
>>
>> The size of A0 is 8 bytes, the size of A1 was 20 bytes for the Intel
>> (6/7) compiler and 44 bytes for the GCC (3.2.1). If you like, I can
>> send the complete code.
>
> No need. The size of A1 should be 16 bytes on most 32-bit
> architectures, but there's nothing fancy going on here. If compilers
> are making bigger classes it's just
>
> GCC-3.2.3 on x86 reports:
>
> sizeof(A0) = 8
> sizeof(sp_counted_base) = 16
> sizeof(A1) = 24
>
> They didn't change the object layout, so I'm a little shocked at your
> figure of 44 bytes. With threading disabled, it's:
>
> sizeof(A0) = 8
> sizeof(sp_counted_base) = 12
> sizeof(A1) = 20
This is the result of the Intel compiler I tested, thus I think my code is
OK. Still the GCC 3.2.1 reported 44 bytes. Your results are for the GCC
3.2.3 which makes me hoping the best. If I find the time, I will fetch the
GCC 3.2.2 and check it again.
> This is as small as you could expect it to be given the requirements. In
> any case, that method of making intrusive pointers has been deprecated,
> and replaced with a new one which doesn't add more than the size of the
> count to your object (of course, you pay for a separately allocated
> count object which is 12/16 bytes depending on threading).
Maybe I'm too worried about that, but I would guess that this can make a
difference. Intrusive counting saves allocations, which is one of it's
biggest benefits, having to allocate small objects as a side-dish is
something I don't want from a smart pointer.
I aim for a smart pointer which is 4 bytes and adds another 4 bytes to the
intrusivly counted object - no more. AFAICS boost cannot offer this with
the current design. Loki is much better, but some first benchmarks show
that it has some performance problem in certain cases: Swapping some
pointers around was ~10 times slower than both boost's pointers and ~20
times slower than my smart pointers. I will keep analysing it and report
more results later.
>> Because it addresses the same problems. I don't want to insult anyone
>> here by taking away users or (even worse) developers.
>
> I don't think anyone will be insulted. Nobody around here is jealously
> guarding development resources, AFAICT.
>
>> Although I am pretty sure
>> I can do that even if I intend to, but this impression is what I would
> ^^^ "can't?"
Of course. (Would this be a candidate for the typo-of-the-year? ;)
>> like to avoid.
>
> Don't worry about it. The more discussion, the more better.
>
>> > > Andrei has done a lot of good things not just by creating them, but
>> > > also by writing a book about it.
>> >
>> > Agreed, of course. What I mean is that I'm not completely satisfied
>> > with the implications that his MI design has for smart pointer size
>> > on real-world compilers.
>>
>> And size does matter - the smaller the better ;) Which reminds me to
>> add Andrei's PBSP to my benchmark and check some stuff. The problem for
>> me is that I know the importance of documentation, but I'm not good in
>> writing it :o)
>
> No offense intended, but that's a bit of a cop-out. If you're going to
> be the one asking for better comprehensibility, it isn't really fair to
> plead "I'm bad at documentation."
That I'm not good at writing documentation doesn't mean I won't do it.
It's just something that takes me longer than others (comparing it with my
colleagues) and as I am not a native english speaker, the result may be a
weird way of expressing things :) And this is the reason why I always
prefer more readable code over more documentation.
Regards, Daniel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
