Re: [boost] Re: Re: possible addition to operators library
A technical thing. The question is, what do we prefer? I personally prefer a technical advantage as it creates safer overall code. I am used to work with several people in a large code-base and in my experience it's always a very helpful thing if the interface of your code leads to compile-errors when misused. Documentation will help you to reject the responsibility - it won't help you to get the job done. If the compiler rejects your code and the error message itself is anything but clear, you are at least forced to work on it. That's not nice in the moment you are faced with it, but in the long term it pays. The alternative (keep the safe-bool and document it) leads to hidden bugs that are IMHO hard to find. Remember that we have a very close view to a tiny code fraction. Imagine it to be the part of a 100.000 lines project. It compiles without a warning but calls operator int() instead of operator!(). No, I agree. You're right, much better to squint at error messages than to try and diagnose unexpected behaviour. Plus the messages I compared against were not all that bad to look at anyway, and all of them said something to the effect of can't convert class 'A' to 'int' or something. The VC issue bothers me, as I don't think I fully understand what exactly happens. Doesn't the compiler give any additional messages to explain what exactly is ambiguous for operator? Does anyone know this problem and has a work-around? Unfortunately I don't understand this. It can go in the documentation, with the work around to be : if (!!a ...) or if (a) if (...) Which, while a little annoying, is not a fatal problem. And hopefully the number of VC6 users should drop drastically when VC7.1 comes out anyway. Incidentally it compiles fine on Comeau. Finally, if we choose this route, this means that we can take the approach of providing operator! and a private operator some_number_type() while the user provides operator bool. This is more semantically correct in my opinion, anyone have any problems with this? Oh, I should have patches posted very soon. Sam ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
Daniel Frey wrote: Beman Dawes wrote: * Possible addition to operators library from Sam Partington Daniel Frey and Sam discussing changes. We need some discussion of it and I would like to see it in CVS and thus in the regression tests for some time. When Sam started the proposal, the branch for 1.30.0 has already happened (IIRC) and to me, this means bug-fixes only. I don't know when exactly you are planning to release 1.30.0, but if there is enough time and Sam (and others) would like to see the addition ASAP, we can try to push things a bit. Currently, it's an 1.31.0 item as far as I'm concerned. Sam, is this OK for you? Well, I would love to get in 1.30, but I think it may take a little longer that we'd hope. I've just spotted a problem with the private operator int() implementation which breaks almost every single operators test going! I will elaborate when I've done more testing. So yes, unfortunately, I think we're looking at a 1.31 item. Sam ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: possible addition to operators library
Unfortunately I don't understand this. It can go in the
documentation, with the work around to be :
if (!!a ...)
or
if (a)
if (...)
Of course. But I was hoping for a work-around at the library-side, not
at the user's side. What exactly are the overloads that the VC thinks
might match? Or what type does it try to cast the expression to
(instead
of bool)?
Yes, library side fix would be much nicer. But I'm stuck on this. The
compiler is _really_ helpful here:
z:\test.cpp(37) : error C2593: 'operator ' is ambiguous
thats it! The compiler docs suggest to resolve the ambiguity you explicity
cast one or both of the arguments of the operator. But
if (static_castbool(a) ...
is even more of a mouthful. At least there's still no danger of passive
errors.
Finally, if we choose this route, this means that we can take the
approach of providing operator! and a private operator
some_number_type() while the user provides operator bool. This is
more semantically correct in my opinion, anyone have any problems
with this?
Oh, I should have patches posted very soon.
Fine. Remember that the name should probably change to reflect the
corrected semantics. Something like 'bool_negatable'?
I don't think it does. Actually I always felt that bool_testable was wrong.
After all equality_comparable provides the inequality test. And
dereferenceable provides -. So bool_testable should provide the opposite
of bool testable. i.e. operator!. If you get me :-)
But then, there is still some slight illogic here: We provide
operator!,
but the protector is for operator bool. Two orthogonal concepts. Would
it make sense to separate them? If so, will 'bool_protector' have any
value? Those people not aware of the problem of providing operator
bool() will not use it, those that are aware will use Peter's
safe-bool-idiom when appropriate as it gives better error messages.
And
where safe-bool is not applicable, you don't need a protector anyway
AFAICS. Hm... thoughts?
I guess it comes down to the same sort of style as noncopyable. The people
who really need it
are those that aren't even aware there is a problem. Still, I am seeing
colleagues who almost never make use of boost make use of noncopyable
regularly because it is self documenting, I guess thats what we can hope
for.
As for whether we should seperate the two concepts, perhaps, but I don't any
occasions when I would want bool_testable and not bool_protector. Therefore
if we were to seperate them I would like bool_testable to derive from
bool_protector
bool_protector - prevents accidental conversions to int for classes with
operator bool
bool_testable - provides bool operator!(const T) AND bool_protector
templateclass T, class B = ::boost::detail::empty_base
struct bool_testable : bool_protectorT, B
{...};
But I do ask myself, is this a likely use-scenario?
Sam
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: possible addition to operators library
Indeed that's not very helpful. But at least - as you said - it fails to compile so I consider it a non-issue for the operators library. It's a VC6 problem and the users need to life with it whether or not they use the operators library, right? Yup. It is six years old after all. Anyway it is in the documentation, as well as a work-around. I don't think so and I wasn't suggesting that it would be a good idea. I think it's reasonable to have both things tied together. I just wanted to mention it and see what you think. I think that it's my job as the maintainer to try to break everything to see how robust it is (and hopefully not to frustrate anyone). As I'm new in this area, please correct me if I'm wrong. :) No, not at all, I think you're doing a very good job indeed, never any harm in taking the devils advocate. I think we now have had a fair amount of discussion and as long as you (or anyone else) don't find another problem, I'm looking forward for your next patch-set. :) Attached. Hopefully not made a mess of it. :-) Sam PS The problem I mentioned I was having with the tests was me not thinking properly. I compiled all the tests with an old set (1.29) of boost files by mistake, and lo and behold it none of them passed - amazing hey! Sorry, I'll keep my mouth shut in future. operators_test.cpp.patch Description: Binary data operators.htm.patch Description: Binary data operators.hpp.patch Description: Binary data ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: possible addition to operators library
Thanks for your comments Daniel, I will update the docs with a better
rationale and post the patch soon.
As for the issue below, I also have no idea how to go about automatically
selecting either method. Plus I think this might introduce complexities
which make the compiler's job that much harder to optimise. Could well be
wrong on that though.
Essentially I think the options are to
- document its unusual behaviour in the presence of other conversion
operators
- use the private operator int method.
So if we take the plusses and minuses for each method:
safe-bool:
+ obvious error messages (see list of error messages at end)
- problems with classes that provide other user-defined conversions
operators.
- requires declaration of operator! by user, which is a bit backward.
private operator int :
+ user provides operator bool, and our helper protects it from misuse, and
provides operator!
+ no clashes with other user-defined converion operators
- fails to work with if(a func()) on MSVC 6 at least - 'operator is
ambiguous'
- less helpful diagnostic messages.
The if (a something) is quite a serious defect, but it compiles fine on
gcc 2.95.3.
So it comes down to two things,
1) How important is it to have legible diagnostics?
2) How important is it to behave properly with other user-defined
conversions?
My gut feeling is that I'd rather have the safe-bool method, but I suspect
my judgement is coloured by two things:
- I never use user defined conversion operators
- I use MSVC 6 as my main compiler, and not being able to do if (a !a)
would bother me.
San
Diagonostic samples:
--
templateclass T, class B = ::boost::detail::empty_base struct
other_bool_testable : B
{
public:
operator bool() const { return !!static_castconst T(*this); }
private:
typedef signed char private_number_type;
operator private_number_type() const;
};
#if defined(USE_OTHER_BOOL_TESTABLE)
class A : public other_bool_testableA
#else
class A : public bool_testableA
#endif
{
public:
bool operator!() const { return false; }
};
void f(int);
void g(signed char);
void test(const A a)
{
if (a !a)
{
f(a);
g(a);
}
}
MSVC 6
***
safe-bool:
test.cpp(321) : error C2664: 'f' : cannot convert parameter 1 from 'const
class A' to 'int'
No user-defined-conversion operator available that can perform this
conversion, or the operator cannot be called
private operator :
test.cpp(319) : error C2593: 'operator ' is ambiguous
// when the conversion is not an exact match to the private operator i.e.
int to signed char
test.cpp(347) : error C2664: 'f' : cannot convert parameter 1 from 'const
class A' to 'int'
Ambiguous user-defined-conversion
//when it is an exact match
test.cpp(322) : error C2248: 'operator`signed char'' : cannot access private
member declared in class 'other_bool_testableclass A,class
boost::detail::empty_base'
C:\Work\SS\debugger\CodeScape\CBuilder.cpp(323) : see declaration of
'operator`signed char''
gcc 2.95.3 :
*
safe-bool:
test.cpp: In function `void test(const A )':
test.cpp:32: `const class A' used where a `int' was expected
with the private operator some_number() :
// if the private operator is not an exact match (e.g signed char to an int)
test.cpp:32: conversion from `const A' to `int' is ambiguous
test.cpp:6: candidates are:
other_bool_testableA,boost::detail::empty_base::operator bool() const
test.cpp:9:
other_bool_testableA,boost::detail::empty_base::operator signed char()
const
// if the private operator is an exact match you get
test.cpp:32: conversion from `const A' to `signed char' is ambiguous
test.cpp:6: candidates are:
other_bool_testableA,boost::detail::empty_base::operator bool() const
test.cpp:9:
other_bool_testableA,boost::detail::empty_base::operator signed char()
const
test.cpp:9: `other_bool_testableA,boost::detail::empty_base::operator
signed char() const' is private
test.cpp:35: within this context
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Hi all,
Hate to sound pushy, but I've no answer on this, were the patches ok? Would
you like me to repost them?
Or should I just drop it?
Cheers
Sam
- Original Message -
From: Sam Partington [EMAIL PROTECTED]
To: Boost mailing list [EMAIL PROTECTED]
Sent: Thursday, February 27, 2003 10:55 AM
Subject: Re: [boost] possible addition to operators library
Daniel Frey wrote:
Daniel Frey wrote:
No problem. IIRC it was Peter Dimov who came up with the safe-bool
idiom first. At least I saw it first from him. Another way which
works but results in worse error messages is this:
template class T, class B = ::boost::detail::empty_base
struct bool_testable : B
{
private:
operator int() const;
public:
operator bool() const
{
return !!static_cast T ( *this );
}
};
It should be a more efficient implementation for most of the points
Dave mentioned and it should also work in all cases (allowing the use
as a bool, int is private, thus not accessible and other conversions,
e.g. to 'long' are ambiguous. The drawback is, that the error
messages are not as clear and obvious as for Peter's idiom.
Well we'll stick with Peter's model then. I had figured it was Peter,
someone let me know if it wasn't.
Sam Partington (me!) wrote:
Is there another alternative to this? How about this:
typedef void (bool_testableT,B::*unspecified_bool_type)() const;
operator unspecified_bool_type() const
{
return !static_castconst T(*this) ? 0 :
reinterpret_castunspecified_bool_type(bool_testableT,B::operator
unspecified_bool_type);
}
Does this have any issues that I can't see? Ideally we could avoid
the reinterpret_cast, but how do you express the type of a
user-defined conversion operator for the type you're trying to
express? Beats me!
I was hoping for a response to this, but I know we're all busy, so I'll
take
the silence to mean that noone has any serious objections. I know lots of
you will see the reinterpret_cast and start shouting non-portable but in
this case all its doing is casting the return type of the function
pointer.
Also we're not going to use the pointer other than a compare to zero, so
providing there are no compilers that would reinterpret_cast to a zero, I
don't see a problem.
This is my preferred solution for now, as it avoids a lot of the overhead
problems that have worried some of you.
I've attached the patches, including docs and test.
Sam
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Daniel Frey wrote:
Daniel Frey wrote:
No problem. IIRC it was Peter Dimov who came up with the safe-bool
idiom first. At least I saw it first from him. Another way which
works but results in worse error messages is this:
template class T, class B = ::boost::detail::empty_base
struct bool_testable : B
{
private:
operator int() const;
public:
operator bool() const
{
return !!static_cast T ( *this );
}
};
It should be a more efficient implementation for most of the points
Dave mentioned and it should also work in all cases (allowing the use
as a bool, int is private, thus not accessible and other conversions,
e.g. to 'long' are ambiguous. The drawback is, that the error
messages are not as clear and obvious as for Peter's idiom.
Well we'll stick with Peter's model then. I had figured it was Peter,
someone let me know if it wasn't.
Sam Partington (me!) wrote:
Is there another alternative to this? How about this:
typedef void (bool_testableT,B::*unspecified_bool_type)() const;
operator unspecified_bool_type() const
{
return !static_castconst T(*this) ? 0 :
reinterpret_castunspecified_bool_type(bool_testableT,B::operator
unspecified_bool_type);
}
Does this have any issues that I can't see? Ideally we could avoid
the reinterpret_cast, but how do you express the type of a
user-defined conversion operator for the type you're trying to
express? Beats me!
I was hoping for a response to this, but I know we're all busy, so I'll take
the silence to mean that noone has any serious objections. I know lots of
you will see the reinterpret_cast and start shouting non-portable but in
this case all its doing is casting the return type of the function pointer.
Also we're not going to use the pointer other than a compare to zero, so
providing there are no compilers that would reinterpret_cast to a zero, I
don't see a problem.
This is my preferred solution for now, as it avoids a lot of the overhead
problems that have worried some of you.
I've attached the patches, including docs and test.
Sam
operators_test.cpp.patch
Description: Binary data
operators.htm.patch
Description: Binary data
operators.hpp.patch
Description: Binary data
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: resource manager naming
Could it not just be called shared. After all it is merely a more general term of shared_ptr. And the type of the resource kind of makes it implicit. e.g. sharedfile is a shared file. crystal. Though this doesn't fit at all with non sharing policies. Sam Alisdair Meredith wrote: Larry Evans wrote: Would the GOF name, proxy, be too non-specific? Policy names might provide the specifics (whether it's a pointer or a resource). Proxy, if anything, sends the wrong message to me. The name suggests 'reference', rather then 'owner' 'bookkeeper' is the best I can come up with so far, but that is a very odd word to type g and still too long. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Hi all,
Sorry I've been off air for a bit. I'll try to answer as much as I can in
this email.
Daniel Frey wrote:
I also think it would be fair to mention Dave as a contributor, too,
as he provided the way to reduce the overhead.
Of course, that bit was still there from the first time through, also
whoever came up with the original unspecified-bool-type idiom needs
acknowledged as well. No offence intended, merely laziness. Sorry.
David Abrahams wrote:
Sam Partington [EMAIL PROTECTED] writes:
Also seems to me that anyone who declares a global template operator!
deserves some problems!
I don't know why you think so.
Well, I don't mean that they deserve to be stoned to death or anything! But
they are going to be seeing some strange things anyway. I don't think us
providing with them another operator is going to cause them any more issues.
So, now with David's suggestion, I've attached what I propose.
I've tested to a small extent on MSVC6 and gcc 2.95, which are all
the compilers I have access to now.
(First time I've used a patch file so apologies if I've messed it up)
It's very nice, but you left out the most-important parts: patches
for the docs and testsuite.
How did I know someone would pull me up on that :-) I'm working on them, I
just need to get a handle on the test suite first. I was fairly sure that
the code patch was going to be enough to get us discussing for now.
Douglas Paul Gregor wrote:
myclass m;
yourclass y;
if (m == y) {
// what's this mean?
}
This is the reason boost::function has poisoned operator== and
operator!=.
Doesn't this require two user defined conversions, which stops this from
being possible? However I agree we should avoid possible problems like
this. The idea behind unspecified-bool-type is to return an obscure type
that can't be accidentally used where not expected - so I would say make it
as obscure as possible. To me this means a private nested struct. Which
I'll come to in a minute.
Daniel Frey wrote:
That won't work as you made it a nested struct so it is still
different for all instantiations. I think Dave meant to go for this
one:
This was intentional for the reason I've just stated above. I don't see
this as any efficiency problem, as certainly on the two compilers I've tried
there was no instantiation of safe_bool at all, without optimisations. With
optimisations on all of the code inlined into the ideal x != 0. Ok on
_some_ compilers this may be an issue, but that goes for just about all
things in boost.
As for making safe_bool reusable, I can only see one possible reason. Where
someone would want to make if (x) a valid construct but not if (!p). Is
this enough reason to allow it? If so then it does not really belong in
boost/operators.hpp, more likely boost/utitlity.hpp.
Is there another alternative to this? How about this:
typedef void (bool_testableT,B::*unspecified_bool_type)() const;
operator unspecified_bool_type() const
{
return !static_castconst T(*this) ? 0 :
reinterpret_castunspecified_bool_type(bool_testableT,B::operator
unspecified_bool_type);
}
Does this have any issues that I can't see? Ideally we could avoid the
reinterpret_cast, but how do you express the type of a user-defined
conversion operator for the type you're trying to express? Beats me!
Sam
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] possible addition to operators library
Hi,
While making myself an interim shared_resource class, I found myself reusing
the shared_ptr safe-bool conversion, and thought that really the idiom ought
to go into the operators library.
I am unsure about the name, but for now bool_testable seems to match the
naming style used by the rest of operators, and be reasonably clear about
its intent. Any suggestions gratefully received
Essentially you supply a operator! and it supplies an unspecified-bool-type
conversion operator.
//Key
//T: primary operand type
//t: values of type T
// TemplateSupplied Operations Requirements
//
// bool_testableT operator unspecified-bool-type() !t
template class T, class B = ::boost::detail::empty_base struct
bool_testable : B
{
private:
void safe_bool_conversion() const { }
public:
typedef void (bool_testableT, B::*unspecified_bool_type)() const;
operator unspecified_bool_type() const
{
return !static_castconst T(*this) ? 0 : bool_testableT,
B::safe_bool_conversion;
}
};
Any problems with this?
Sam
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Daniel Frey wrote:
Nice idea! I already had something similar in mind, but you managed to
make it really generic.
Not really, all I've done is to borrow the code from shared_ptr, and to put
into a shape like one of the existing unary operator helpers in
operator.hpp. Thanks anyway though :-)
The only problem I see is that an instance of safe_bool_conversion is
created which is not really needed. I suggest to rely on the operator!
provided by T:
template class T, class B = ::boost::detail::empty_base
struct bool_testable : B
{
private:
typedef bool (T::*unspecified_bool_type)() const;
public:
operator unspecified_bool_type() const
{
return !static_cast const T ( *this ) ? 0 : T::operator!();
}
};
I thought of this too, but this limits the user to using a member based
operator!. So I couldn't do this :
class A : public boost::bool_testableA
{
public:
int get();
};
bool operator!(const A a)
{
return a.get() == 0;
}
Of course I've never actually wanted to do that, so its maybe not a problem.
After all the conversion operator itself has to be a member, so it probably
isn't much of a restriction at all.
Then again, how much does the safe_bool_conversion function cost?
Sam
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
I think I agree, we want to provide as little restrictions as possible.
Also seems to me that anyone who declares a global template operator!
deserves some problems!
So, now with David's suggestion, I've attached what I propose.
I've tested to a small extent on MSVC6 and gcc 2.95, which are all the
compilers I have access to now.
(First time I've used a patch file so apologies if I've messed it up)
Sam
PS Did anyone who uses OE-Quote notice what a mess it made of the wrapping,
interpreting
B:: as three seperate reply inserts? and so miss out the B, and substitute
. ;-) Great program 99% of the time though.
David Abrahams wrote:
Sam Partington [EMAIL PROTECTED] writes:
I thought of this too, but this limits the user to using a member
based operator!. So I couldn't do this :
class A : public boost::bool_testableA
{
public:
int get();
};
bool operator!(const A a)
{
return a.get() == 0;
}
Of course I've never actually wanted to do that, so its maybe not a
problem. After all the conversion operator itself has to be a
member, so it probably isn't much of a restriction at all.
Ahem. The operators library is *all about* defining free function
operators. I don't think you should introduce a dependence on being
a member function.
Then again, how much does the safe_bool_conversion function cost?
More than I'd like. I'd prefer to use a single data member pointer,
since it's likely to be more efficient.
struct safe_bool
{
#ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS
private:
template class T, class B friend class bool_testable;
#endif
int x;
typedef int safe_bool::*type;
};
bool_testable.patch
Description: Binary data
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] smart_ptr vs smart_resource
Neat!
Have you just unwittingley submitted shared_resource?
Sam
Peter Dimov wrote:
You might want to use detail::shared_count instead. It may be
undocumented but it works and it sure isn't going away since that's
what shared_ptr uses under the hood.
#include boost/detail/shared_count.hpp
#include iostream
int get_int_based_resource()
{
std::cout get_int_based_resource()\n;
return 0;
}
void release_int_based_resource(int r)
{
std::cout release_int_based_resource( r )\n;
}
templateclass X class resource
{
public:
templateclass D resource(X x, D d): x_(x), n_(x, d)
{
}
private:
X x_;
boost::detail::shared_count n_;
};
int main()
{
resourceint r(get_int_based_resource(),
release_int_based_resource); resourceint r2(r);
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] smart_ptr vs smart_resource
David Abrahams wrote:
Phil Nash [EMAIL PROTECTED] writes:
Pointers are Resources
Resources are not (all) Pointers.
Actually,
Pointers *refer to* resources
Not all pointers refer to (are) resources
I like word games:
Not all resources are referred to using pointers.
I like the idea of changing smart_ptr to smart_resource, or smart_handle.
Now that I think about it I have never used a PBSP to actually store a
pointed to resource. I always to use them to store non-pointer based
resources, like socket handles, or registry key handles. If I have a
pointed to resource it always goes into a shared_ptr.
Something I've been doing lately:
templateclass T, void (*f)(T) struct resource_deleter
{
void operator()(T* t)
{
if (t)
f(*t);
delete t;
}
};
int get_int_based_resource() { return 0;}
void release_int_based_resource(int) {}
void f()
{
boost::shared_ptrint resource(new int(get_int_based_resource()),
resource_deleterint, release_int_based_resource());
// do something with the resouce
}
Essentially using shared_ptr as a scope guard. Of course what is stupid
about this method is the new and delete are totally unnecessary, and are
only there Obviously this is not an ideal solution, (at least) two better
solutions are available:
1) use a shared_resource, where there is no requirement to pass a T*. (But
there is no public one at the moment)
2) a PBSP, but using a policy based smart pointer seems no clearer to me
than doing what I've done above. (although it would remove the unnecessary
allocations).
So I find myself doing the above. (actually it is abstracted away in a
wrapper)
Anyway, my point is: I'd be very much in favour of shared_resource OR
renaming smart_ptr to smart_resource. (where the PBSP is demphasised from
being smart pointer, to a general smart resource handler)
Sam
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Encapsulate boost::bind in a template method
Hi
It won't compile because you're trying to bind a (CButton::*)() function to
CWindow*. See bjarne 15.5.1
Change the line marked to
boost::functionlong EventFunction = boost::bind(Function,
static_castT*(this));
Or you could use dynamic_cast to check that the cast is valid:
if (T* that = dynamic_castT*(this))
{
boost::functionlong EventFunction = boost::bind(Function, that);
}
Though you can make this less of a problem if you declare your handler
functions private, so that you are less likely to be able to pass duff
member function pointers. e.g.
class CWindow
{
// as before
};
class CWindowA : public CWindow
{
private:
long OnPaint();
};
class CWindowB : public CWindow
{
public:
CWindowB()
{
SetEventHandler(CWindowA::OnPaint); // won't compile now, as
CWindowA::OnPaint is inaccessible
}
private:
long OnPaint();
};
I think I would then be happy to use boost::polymorphic_downcast
(http://www.boost.org/libs/conversion/cast.htm)
HTH
Sam
PS I havn't checked the code, so apologies for any typos
- Original Message -
From: Matthias Hoffrichter
To: [EMAIL PROTECTED]
Sent: Wednesday, February 19, 2003 3:56 AM
Subject: [boost] Encapsulate boost::bind in a template method
Hi,
I want to encapsulate boost::find in a template method in a base class for
easier use.
Here is some code:
#include boost/function.hpp
#include boost/bind.hpp
class CWindow {
public:
CWindow() {
SetEventHandler(CWindow::OnCreate); // this call works
}
long OnCreate() {
return 0;
}
templatetypename T void SetEventHandler(long (T::*Function)()) {
**
boost::functionlong EventFunction = boost::bind(Function, this);
// ...
// Add EventFunction into a std::map
}
};
class CButton : public CWindow {
public:
CButton() {
SetEventHandler(CButton::OnPaint); // this call doesn't compile
}
long OnPaint() {
return 0;
}
};
int main() {
return 0;
}
The SetEventHandler call in the CButton's constructor generates 2 errors on
VC++ 7.0:
mem_fn_template.hpp(37): error C2440: 'newline' : 'CWindow *' can't be
converted in 'CButton *'
mem_fn_template.hpp(37): error C2647: '-*' : 'const
boost::_mfi::mf0R,T::F' can't be dereferenced in '$T'
It also doesn't compile on g++ 3.2.
If I copy paste the template method in every derived class the code
compiles well, but this can't be a good soluation. :(
And if i outcomment boost::functionlong EventFunction it also works, but
of course I need to work with boost::bind's return value. ;-)
Is there a way to solve this problem?
cu,
Matthias
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Policy-based smart pointers revisisted
[mailto:[EMAIL PROTECTED]]On Behalf Of Paul Mensonides I don't buy this argument about the complexity of many pointer types. I'm not going to make a judgement on whether a few distinct smart pointers are better than a single super pointer. I think we should have both and let users use whichever the like better. I think the problem with offering too many solutions to the same problem is that many users simply get baffled by the choice and use none. Take some of the people I work with, it has taken me many months just to get them to the point where they use shared_ptr. Just occasionally I see one of them write boost::noncopyable, or even boost/operator.hpp. If they had to decide whether to use shared_ptr, or slightly_faster_ptr, I think they would simply not bother. Simply, they won't make use of something unless they see quick and obvious benefits from it. And I don't think this attitude is at all unusual amongst programmers. Also, I can't see any future standard having more than one new pointer, and I can't see anything but the already widely used shared_ptr being it. However, all smart pointers provide basically the same interface, so keeping track of that is not that big an issue, as the differences in interface exist because of the various purposes of different smart pointers. Also, because smart pointers are templates, you already have a different smart pointer every time that you instantiate it with a different type. The compatibility issues between smart_ptr_AT and smart_ptr_BT can be handled without significantly more difficulty than smart_ptrbase and smart_ptrderived. There seems to me to be a very significant difference between smart_ptrbase - smart_ptrderived, smart_ptr_AT - smart_ptr_BT. The first is simply a cast and an attachment to the reference count. But the second requires that every strategy policy understands how to make use of every other strategy policy. i.e. for the following to work: smart_ptrT, my_own_cloning_policy f(); ... smart_ptrT, my_own_counting_policy a = f(); my_own_counting_policy needs to understand what my_own_cloning_policy does, and how to safely attach to it. The problem becomes exponential with each policy added. Not to mention heavily dependent. The other option, of simply not making such conversions possible makes for incompaible libraries, and lots of fix-up code to get around such problems. My vote is to keep things simple, and to keep shared_ptr and scoped_ptr as the only smart pointers. That said, I do like the way shared_ptr can improve itself if you give it something derived from counted_base, perhaps to compromise this method of adding variety of implementation could be extended. e.g. perhaps something derived from clonable_base could have cloning characteristics? As we've mentioned loki, is there any update on Loki - boost integration? A quick check of the archives and nothing seems to have been mentioned since may or so. Sam ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Policy-based smart pointers revisisted
[mailto:[EMAIL PROTECTED]]On Behalf Of Sam Partington That said, I do like the way shared_ptr can improve itself if you give it something derived from counted_base, perhaps to compromise this method of adding variety of implementation could be extended. e.g. perhaps something derived from clonable_base could have cloning characteristics? Oops, typing faster than I think as usual. I was just trying to come up with some example of other extensions to shared_ptr through the same method of counted_base. This was a poor example. Obviously a shared_ptr with cloning characteristics would confuse everybody, myself more than most I suspect. Sorry! Sam ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
