On 8/15/10 10:22 PM, Stefan Strasser wrote:
Zitat von Joel de Guzman <joel@boost-consulting.com>:
the name caused both david and me to fundamentally misunderstand the macro, and I'm supposed to explain to the library user that it is the absolute wrong thing to do to adapt a class using ADAPT_CLASS.
And I still don't understand the reason why. You mentioned that because it does not return a reference it should not be called a "class" adaptor. But I can't figure out why a reference to an actual object should be a requirement.
it isn't a sequence of values anymore but a sequence of objects that are convertible to the values. which can cause many subtle problems, among them probably some of the same as those of vector<bool>.
one fusion-specific problem:
struct A{ int i; };
struct F{ void operator()(int) const{ /* do something */ } template<typename T> void operator()(T) const{} };
fusion::for_each(A(),F()); //does something A a; fusion::for_each(a,F()); //does nothing.
a "const" sequence is iterated as values, but a non-const sequence is iterated as proxy objects, which aren't matched to the "int"-overload.
Here's my use case (if I haven't given it yet). If you or anyone can provide a better solution to what's provided, I'm all ears: class foo { public: int x() const; void x(int n); int y() const; void y(int n); private: // encapsulated }; Now, adapt that class to fusion.
Anyway... for the sake of moving forward, let me open the door to name suggestions. I can probably suggest ADAPT_ADT.
ADT?
Abstract Data Type.
ADAPT_EXPR would be my suggestion, as it can also be used to make a fusion sequence out of some global variables for example.
Good point. But still doesn't cut it for me. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net