Re: GMP compiled under MacOS/C++ wrap

[Hans Aberg]

At 08:13 +1000 2001/04/25, Kevin Ryde wrote:
>> I compiled GMP <ftp://ftp.gnu.org/pub/gnu/gmp/gmp-3.0.tar.gz> generic under
>> pre-MacOS X with Metrowerks CodeWarrior Pro 5 C/C++ compiler, using the
>> 32-bit gmp-mparam.h header. (Note that the Mac G4 CPU is 128 bit, and there
>> appears to be no header for that.)
>
>Does the Makefile and configure in the macos directory help?

The Makefile does not help at all under pre-MacOS X; it is completely
useless. Under MacOS X (which I do not have), GCC is available, and I
figure it would compile straight off with GCC.

When using an IDE in general, I figure that the Makefile is also useless.
RMS said he was interested in making a GNU IDE based on a Makefile; I think
this would be an interesting project, because one do then not loose the
programming power of a Makefile.

As for the configure file, I edited "config.in" by hand. If you have a lot
of people that is only using a IDE without a Makefile, it would help to
provide a config.h file for those compilers; otherwise, do not bother.

The UNIXi MacOS X has now been released, and I do not know exactly what
will happen then: On the one hand, GCC is available, on the other hand,
using an IDE helps a lot.

>> I started on a C++ wrap, classes gmp::integer, gmp::rational, gmp::floating
>> that expand to the GMP C functions. If you are interested, please let me
>> know. I don not plan to write all GMP functions into that wrap, but it
>> would not be difficult to do so. (More info below.)
>
>Gerardo Ballabio has made good progress on such a wrapper,
>
>        http://www.sissa.it/~ballabio/gmp++.html

Thank you for the reference.

In addition, I am now making a Flex/Bison parser, making it easy to test
the different arithmetic operations (calculator style).

If one wants to define formats for say rational numbers, it is easy to make
changes in Flex, while developing suitable rational number IO operations.
For example, I admit rational numbers of the form "n p/q", like "2 1/2",
without conflicting with other number formats.

>> - When making C++ classes, it would be natural to put in a reference count,
>> in order to avoid unnecessary copying.
>
>I thought heavy objects were best passed around by reference (but I'm
>not a c++ expert).

It is not possible (by empirical experience) under C++ to return a
reference from a function and combine it with a proper memory management
(for example, exceptions will screw it up). It is also not really possible
(skipping the details of this discussion) under C++ proper to implement a
conservative GC that will keep track of the lifespan of the references.

So one is left with a reference count of some sort.

>> But at least under C++, a ref-count seems reasonable, because arithmetic
>> operators can return gmp::integer, gmp::rational, and gmp::floating values
>> without calling a new dynamic allocation.
>
>An alternative is to keep a bit of a free list of initialized mpz_t or
>mpq_t's.  Could probably be thread safe with some care.  Doesn't work
>so well for mpf_t unless you're using the same precision everywhere.

I am not sure what you mean here: Keeping track of initialized objects in a
container of some sort is slow (and complicated).

The problem with this arithmetic library is that you are on such a low
level, so whatever one tries risk slowing it down considerably.

The most reasonable thing is to put in a ref count, and waiting for a
better C++ standard. :-)

Then, the traditional way of putting in a ref count would be having say the
"integer" class pointing at a structure with the count plus the
__mpz_struct. But then one gets, for each integer allocation a double
dynamic allocation, for the ref count structure plus the integer structure.

Again, I think that this might be slow. So therefore I want the
__mpz_struct have all its data in the pointer, plus reserved space for the
count.

The problem is that an invokation of "malloc" or "new" make take up as much
as several tens of cycles on the systems -- which is usually due to a poor
implementation of these memory allocation functions. But the fact is that
it is probably slow.

I have myself no direct need for speed optimization, so I could put in a
ref count the traditional way. (I am going to use these class in a dynamic
class hierarchy, which anyway has its own ref count.)

But if you want to add C++ header to the project, I think that will be
unacceptable.

>> My impression from reading this comment was that you had put in
>> "defined(__cplusplus)" just in order to make it work for Sun C/C++ (but I
>> perhaps read it wrong). But it is normal to not have __STDC__ defined under
>> C++.
>
>The comment has since been clarified:
>
>/* Sun workshop C 5.0 requires "##" for token pasting, but defines __STDC__
>   to 0, hence the use of defined(__STDC__) rather than __STDC__-0.  */

OK. Thank you.

  Hans Aberg