RE: [boost] Properties implementation available

From: Hamish Mackenzie (boost_at_[hidden])
Date: 2002-02-19 08:49:00

On Tue, 2002-02-19 at 09:13, Geurt Vos wrote:
> 
> > On Mon, 2002-02-18 at 09:04, Geurt Vos wrote:
> > > My usual answer to this is: So?
> > > How many properties will a class have? I'd say if there were
> > > more than a few, you're doing something wrong, but lets make
> > > it 7 as maximum 'acceptable' number of properties. On all 
> > > platform I tested the implementation on, a pointer-to-object
> > > has a size of 4 bytes. 7 * 4 = 28 bytes per class. You'll need
> > > a whole lot of such objects for it to make a difference. True,
> > > seven is not worst case, but it's definitely a bad case...
> > 
> > How about the example you used of a coordinate type?  If you used it in
> > a vector graphics library it would almost double the memory used.
> > 
> 
> It's true what you say, but it doesn't mean a thing!
> I mean, just saying it uses more or less memory, or it's
> faster or slower simply doesn't provide any argument why
> you should choose one or another approach. Saying it's
> too slow because 1)..., 2)... and 3)... or it uses too
> much memory because ..., now that might (!) make you
> think about the approach chosen (or which one to choose).

1) The problem is that in a lot of cases you would want to add
properties to save memory. Allowing the read/write functions to store
their values efficiently. If the saving is less then 4 bytes you would
actualy end up using more memory because of the overhead.

Backing it up with a real world example

For instance say you want to check the corporate address book of a large
company 100,000 people with 2 different email systems to make sure the
two are in sync.  Now each user has 30 or so properties averaging 8
characters or so.

So 100,000 x 2 x 30 = 6,000,000

Now if your string overhead is say 16 bytes (some in std::string some in
the heap) you don't want individual strings for every property ((16+8) x
6M = 144MB). So instead you opt for an index (using the SMTP address)
and storing the rest in a single csv string and parsing them out when
you need them.

It would be nice to use properties in this situation but the process
already uses 48MB (8 x 6M) and using properties would add 24MB.

> ...but it is exactly what I was afraid of: it won't
> be accepted by the sheer fact that it uses more memory
> and object creation is slower...

and

2) And it requires you to change your object in two or more places each
time you add/remove/rename a propery.

3) It breaks the default copy constructor and assignment operator.

4) I am still messing with changes to my proposed move.hpp.  One of them
is for moving blocks of objects.  In some cases you can optomize this to
use memcpy or memmove.  One of the situations where this is not posible
is if the object stores pointers to itself.

But I reckon a proxy approach will fix all of these complaints.

> > a) Use multiple inheritance 
> > 
> > class value {}; 
> > 
> > class A : public 
> > property_owner< A, int, value, &A::get_value, &A::set_value >, 
> > property_lookup< A > 
> > { 
> > public: 
> > } x; 
> 
> This won't work. get_value and set_value aren't
> known at this point.

Doh!

I am not sure if my idea about preventing the user from copying the
return type will work. Which could be a problem.

We need a way to prevent this

template< typename T >
void f( T x )
{
  x = 5;
}

f( object.some_property() ); // oops just changed some_property() to 5

> > b) Use a macro. Yuk but it might be the simplest solution. 
> 
> You could, but I won't...

I might, but I won't tell anyone if I do ;-)

> > Yeah but my Zaurus only has 24MB RAM and a lot of that is used up once I
> > run samba and openssh :-)
> > http://www.sharp.co.uk/pda/pda.htm
> > 
> 
> Linux + Java...and you're complaining every property 
> takes a few bytes of memory? :)

I still have the Tandy 100 my Grandfather gave me when he upgraded to a
Tandy 200.
I can't throw it away it has over 24 thousand bytes in it!!! :-)

Hamish Mackenzie