Re: [boost] Three Quick questions...

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-01 13:39:32

On Sunday 01 July 2001 01:18, you wrote:
> 1.  I'm working on a templatized (mathematical) function class that
> takes an argument of type ArgT and returns a type of RetT.  For one of
> the methods I need to multiply an ArgT by a RetT.  (If that operation
> isn't definted there should be a compile-time error.)  Is there a good
> way to specify the type (at compile time) returned by a function when
> given arguments of a specified type?  I'm thinking something like...
>
> template<class RegT, class ArgT>
> class Foo
> {
> public:
> typename operator*(RetT,ArgT) RetTimesArgT;
> RetT f(ArgT x) {...};
> RetTimesArgT fx(ArgT x) { return f(x)*x; };
> };
>
> Foo<float,int> bar;
>
> so I'd want bar.fx(3) to return a float.

You want the mythical 'typeof' operator :). AFAIK, this is not possible in 
C++ without an externsion. Some compilers (GCC and Metrowerks, possibly 
others) have a "typeof" extension  where you would change the typedef above 
to:

typedef typeof(RetT() * ArgT()) RetTimesArgT;

(ideally it would not require default-construction, but I don't want to 
clutter the example).

Libraries deal with this usually by defining trait classes that give the 
result types of operations used by the library. Other libraries try to 
emulate typeof itself using a type registration system of some sort (there is 
one in the files section that does this).

> 2.  I'm currently using a traits class that contains another class as
> a member variable.  If the traits class is initialized such that it's
> member variable is known at compile time, it can inline everything.
> If not, the compiler can put in function calls to get the traits
> needed.  I was thinking of changing the traits class so that instead
> of using a member variable it used a reference counted smart pointer
> to a variable.  That would make it a little nicer for the user.
> However, I'm a little worried that today's compiler might not be able
> to see through all the pointer dereferencing to inline out all the
> function calls.  Does anyone have experience with this?  If so, I'd
> like to hear about what your compiler was and what it could figure out
> and what it couldn't.

[can't help with this]

>
> 3.  I'm working on a mathematical function class.  One option is to
> use the boost::function as a base class.  Another option is for every
> function to take only one argument, which could of course be a tuple
> with several variables.  Presently, I'm working along the lines of the
> latter, since it seems easier to implement.  However, I thought I'd
> ask here before I get too involved to see if someone else would
> convince me this wasn't a good idea.
>
> Thanks,

Generally you would want to your mathematical function to be a function 
object to keep the overhead low. I don't see that boost::function fits into 
your scheme, but nor do I fully understand what you're working on.

        Doug