Function return values in GMP? (James Wheaton)

Décio Luiz Gazzoni Filho decio at
Fri Mar 3 04:53:23 CET 2006

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;



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); }

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

mpz_t *z, *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.


More information about the gmp-discuss mailing list