RE: [boost] properties in C++

From: Geurt Vos (G.Vos_at_[hidden])
Date: 2002-02-13 11:23:22

> >
> > > For instance, this straight-forward example looks great but
> > > it doesn't work:
> > >
> > > >     boost::property<
> > > >         boost::read<int,A,&A::get_it>,
> > > >         boost::write<int,A,&A::set_it>
> > > >     > value;
> > >
> > > &A::get_it can only be a constant expression if get_it is a
> > > 'static' member;
> > > but a static member cannot access a property value.
> > >
> >
> > Why isn't &A::get_it (as non-static) a constant expression?
> > I have to admit I didn't look it up in the standard, but when
> > I find that every real C++ compiler(*) eats it, I am not tempted
> > to look it up.
> >
> > Geurt
> >
> OK. I mess up with the wording...
> 
> I'll try it again...
> 
> What I meant to say was that a member function must be 
> bounded to an object
> in order to call it.
> This 'bounding' is known as a  'closure'. A closure, which 
> doesn't exist in
> C++ as a language feature, is basically a pointer to an object plus a
> pointer to a member function.
> Although the address of a member function is certainly a constant
> expression -so you can use it as a template parameter- the 
> address of an
> object isn't, so you can't use a closure (object*+memfun*) as 
> a template
> parameter.
> 
> In your example, the object address is totally missing from 
> the interface
> and the sketch you've shown.
> 
> When you do
>    A.value = 100 ;
> how does the property 'value' receives &A?
> 

Ah, I now see what you mean. '*this' is passed to the
constructor of 'value' (as you feared :).

> The typical solutions that I'm aware of require the property 
> constructor to
> receive A*. Thus, 'value' cannot be default constructed and every
> constructor for A requires a proper initialization of  
> 'value'. This is the
> sort of complications that usually renders the technique not 
> too friendly
> and ultimately discarded.
> 

I kind of agree, it simply doesn't come at no cost. I've
been using it for some time, but don't consider it that 
much of an issue, basically because none of my classes 
really have that many properties (or constructors).

There are other issues. For instance, when a class has
a property<> as member, it is automatically 'non-copyable'.

Geurt