|
Boost : |
From: David B. Held (dheld_at_[hidden])
Date: 2003-03-17 09:56:54
"Gennaro Prota" <gennaro_prota_at_[hidden]> wrote in message
news:ni9b7vc6dris443rhvo37smpamvem1rreb_at_4ax.com...
> [...]
> What monster are you creating, man? :-)
I must be the only one here that actually writes application code,
because it never ceases to amaze me how everyone else can follow
all these neat and tidy rules for writing "pure" code. I happen to
have a business app where a lot of business data gets stored in each
object, and really, 10 fields isn't that large, and hardly a "monster".
By comparison, open up your favorite contact manager, and look
how many fields each contact has, and imagine that being
encapsulated as an object. ;)
> Ok, assuming that you need so much parameters, and that there's
> a speed gain with using call_traits,
Considering that some of the fields are std::vector<>s, and some
of them are bools, you tell me. ;)
> [...]
> foo f(x1, x2, x3, (void(*)(X1, X2, X3))0 );
Clever, but I don't need call_traits<> that badly. ;) I'll just make
everything a const&. If you could take the address of a c'tor, this
actually might be possible. Consider this code, which illustrates
what I want to do:
#define PARAM(t) boost::call_traits<t>::param_type
template <typename T>
class wrapper
{
template <typename U1, typename U2, ...>
wrapper(int v, PARAM(U1) v1, PARAM(U2) v2, ...,
void (*)(U1, U2, ...) = &T::T)
: value_added_member_(v), data(v1, v2, ...) { }
private:
int value_added_member_;
T data_;
};
Unfortunately, &T::T isn't allowed. I understand why (sort of), but
it might actually make your trick be useful (or maybe not, I don't
know). On the other hand, I suppose I could create a Create()
function for each T, and use that instead (except that then I lose
value semantics, which are more important than some syntax
sugar).
> [...]
> As ugly as sin, but shouldn't make your Frankenstein appear
> much worse than it already is :-)
LOL! Well, I don't like the large number of parameters any more
than you do, but considering the alternatives, it's really not a bad
solution.
Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk