RE: [boost] Properties implementation available

From: Geurt Vos (G.Vos_at_[hidden])
Date: 2002-02-18 04:04:12

> > It should work fine for at least GCC 2.95.3, Borland
> > C++ 5.5.1 and Intel C++ 5.0. It simply can't be done
> > for Visual C++ 6.0 & 7.0.
> > 
> > Geurt
> > 
> 
> Famous last words: "can't be done".  Loki was ported to VC6, 
> so I'm sure
> it's possible.
> 

porting Loki to VC6? pfff, nothing as simple as that! 
But seriously, the one real thing in loki that VC6 doens't
support is partial template specialization. I've seen the
recent way to kind of add support for it to VC6, but I 
still think the easiest way to get around it is by using
full specialization within classes. So for VC6, something
like is_same I would implement as following:

template <typename T1, typename T2>
struct is_same {
    template <typename> struct Helper {
        enum { result = false };
    };
    template <> struct Helper<T2> {
        enum { result = true };
    };
    enum { result = Helper<T1>::result };
};

but anyways, not counting possible ICEs and things I
overlooked, there are two issues:

1. support for the following:

template <typename T, T v> class A {};

class B {
public:
        typedef void (B::*T)();
        void F();

        A<T,&B::F> a; // <-- VC6: B is undefined
};

2. support for type conversions like:
I have 'T *', but also need 'T &',
'const T &' and 'const T *'.

You can get around this by wrapping a class around
it like pointer<T> (instead of simply 'T*'). Except
that still the first issue needs to be resolved, I
found this syntax unacceptable...

> While I love the idea of a language only implementation of properties,
> you really need compiler support for the complete solution.
> 
> First, I find it unacceptable to store a pointer to the self in the
> property object.  If I wanted all data members to have corresponding
> properties, I have quite likely doubled the size of my object.
> 

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...

Secondly, you're talking about VC6, running on Windows, right?
Machines on Windows (or actually, machines on anything) are 
loaded with memory. Well, at least in such a way that it 
doesn't matter whether an application uses 1Mb or 10Mb of 
memory. If it does, I suggest buying some memory because 
there's far worse out there than properties.

So why bother about this issue? Getting it to work is my first
concern, and maybe, just maybe reduce the amount of memory 
used...but usually I don't bother...

> Second, it won't work with bitfields.
> 

Elaborate. Example?

> I would think you want to provide the ability to have a "virtual"
> property not backed by any data member (perhaps the value is 
> stored in a
> dictionary.)  You may already have that support, but I didn't see it.
> 

Um, I'm uncertain what you mean. You mean that it should be
possible the 'set' and 'get' are virtual? That's no problem,
pointers to virtual member functions will do just that...

> Last, I'll point out VC6 and beyond has full compiler support for
> properties.  I don't like the syntax, but it looks like this:
> 
> 	struct S {
> 		int __declspec(property(get=get_foo,put=put_foo)) foo;
> 		int get_foo();
> 		void put_foo(int value);
> 	};
> 
> The compiler simply maps s.foo into the appropriate get or 
> put function, depending on the context.
> 

Cool, didn't know that. I would also rather prefer language
support, but as long as it isn't there...

Geurt