Function return values in GMP? (James Wheaton)

[Décio Luiz Gazzoni Filho]

On Mar 2, 2006, at 3:35 PM, Hans Aberg wrote:

> On 2 Mar 2006, at 17:08, Décio Luiz Gazzoni Filho wrote:
>
>> On Mar 2, 2006, at 10:21 AM, Hans Aberg wrote:
>>
>>> On 2 Mar 2006, at 00:33, Décio Luiz Gazzoni Filho wrote:
>>>>
>>>> Actually that is a well known problem with operator overloading  
>>>> in C+
>>>> + and which has been solved (though not 100% satisfactorily) using
>>>> the technique of `expression templates', which by the way is
>>>> implemented in the C++ wrapper for GMP.
>>>
>>> This does not solve the problem, because templates just provides  
>>> a static (compile time only) programming
>>
>> Expression templates solve the problem for 99.9% of users.
>
> Please back this up with facts. :-)
>

What do you expect, a survey? All I can tell is that I've been  
looking at the issue of arithmetic for some time already and you're  
the first I see mentioning derived classes. I take that to mean the  
rest of users are satisfied with the current situation. And as I  
can't see a real-world use for your idea either, I'd be pleased if  
you could point out a piece of code from a real application that  
benefits from your idea. I have gobs of code using the GMP C++  
wrapper to show in return.

>> Now certainly there are the hardcore abstract OO types who want to  
>> do everything dynamically. Still, I don't see why it'd be  
>> impossible to use expression templates and dynamic typing  
>> simultaneously.
>
> It's only that it's wholly unnecessary. Once one starts with  
> dynamoc programing there is littyle use and little point with  
> templates.
>

Great, so tell me how your non-template-based code will convert the code

base_t *x, *y, *z;
*x = *y + *z;

to

mpz_add(x,y,z);

without generating any temporaries and without incurring runtime  
overhead. It'd be a great revelation to me that it could be done  
without templates. Certainly you can mimic the template-based  
solution using an hierarchy of classes, but that has no clear benefit  
yet has the drawback of runtime overhead.

>> Meaning you could write code like this:
>>
>> ----------
>> base_t* x = new derived_t;
>> base_t* y = new derived_t;
>>
>> *x = *x + *y;
>> ----------
>>
>> and get the correct behavior without temporary generation.
>
> And how do you get it into polymorphic class hierarchy? And when  
> done, how does the virtual function class interface look like?
>

Certainly I won't bother to work out the low level details, because  
the problem isn't interesting to me. However, consider code like this  
(lifted from gmpxx.h):

struct __gmp_unary_plus
{
   static void eval(mpz_ptr z, mpz_srcptr w) { mpz_set(z, w); }
   static void eval(mpq_ptr q, mpq_srcptr r) { mpq_set(q, r); }
   static void eval(mpf_ptr f, mpf_srcptr g) { mpf_set(f, g); }
#ifdef __MPFR_H
   static void eval(mpfr_ptr f, mpfr_srcptr g, mp_rnd_t mode)
   { mpfr_set(f, g, mode); }
#endif
};

Suppose the mpz_t type were a C++ object, so that you would write  
code like this:

mpz_t *z, *w;
z->set(w);

instead of

mpz_set(z, w);

Writing code like this

struct __gmp_unary_plus
{
   static void eval(mpz_t* z, const mpz_t* w) { z->set(w);  }
   ...
};

and so on would allow you to plug in any derived type of mpz_t in  
place of mpz_t and it would work out. Of course you still need  
expression templates to avoid temporary generation, hence a purely  
non-template-based solution isn't possible. Unless of course you can  
answer my challenge above, but I'm not holding my breath.

>> Of course, it'd require some modifications from, say, the C++ GMP  
>> wrapper in order to generalize it, but it's possible. Now writing  
>> code where the expressions themselves are generated at runtime,  
>> say a calculator parsing user input, might indeed not work -- I  
>> haven't thought enough about it to be sure.
>
> So it seems. :-) Why don't you try it? :-)

Because I have no need for it, and in fact I'm waiting to see whether  
*you* have a need for it, such that your technique made more sense  
than the way it's already done in the C++ wrapper.

Décio