cf_inline.cc File Reference

definition of configurable inline ‘CanonicalForm’ methods. More...

#include "config.h"
#include "cf_assert.h"
#include "canonicalform.h"
#include "int_cf.h"
#include "imm.h"
#include "cf_factory.h"

Go to the source code of this file.

Macros
#define	CF_INLINE   inline

Functions
CF_INLINE CanonicalForm FACTORY_PUBLIC	operator+ (const CanonicalForm &lhs, const CanonicalForm &rhs)
	CF_INLINE CanonicalForm operator +, -, *, /, % ( const CanonicalForm & lhs, const CanonicalForm & rhs ) More...
CF_INLINE CanonicalForm FACTORY_PUBLIC	operator* (const CanonicalForm &lhs, const CanonicalForm &rhs)

Detailed Description

definition of configurable inline ‘CanonicalForm’ methods.

Hierarchy: canonicalform

Header file: canonicalform.h

Developers note:

The central class in Factory is, of course, ‘CanonicalForm’. Hence it is a quiet reasonable to assume that inlining its most important methods will improve execution speed. The same holds for some methods of the ‘CFIterator’ class. Everything on configurable inline ‘CanonicalForm’ methods explained here applies mutatis mutandis to the ‘CFIterator’ methods.

However, inlining ‘CanonicalForm’ methods has two major drawbacks:

o If ‘CanonicalForm’ methods simply would have been declared ‘inline’ it would have been necessary to include the definition of ‘InternalCF’ in ‘factory.h’. This would have been quite a contradiction to the internal nature of the class. Hence it seemed desirable to introduce a mechanism to have both the inlined versions for internal use and compiled versions for the library.

o Second, inlining in most cases leads to larger object code. E.g., inlining ‘CanonicalForm::~CanonicalForm()’ increases the object code by approx. 15% without any effect on computation speed. Thus another design aim was to keep things configurable. That is why the methods defined here are called "configurable inline methods".

The low level solution to both problems is the macro ‘CF_INLINE’ which either expands to ‘inline’ or nothing. The counterpart ‘CF_NO_INLINE’ exists only for convenience, it always expands to nothing. ‘CF_INLINE’ is set immediately before defining resp. declaring the methods to exclude any esoteric influences from included files.

The high level interface is the macro ‘CF_USE_INLINE’. If it is defined any header file that uses configurable inline methods defines them to be ‘inline’, otherwise they are defined as ordinary methods. ‘CF_USE_INLINE’ is defined in ‘config.h’ only.

To switch on (off) all configurable inline methods, it is sufficient to define (undefine) ‘CF_USE_INLINE’ in ‘config.h’. To switch off separate configurable inline methods it is necessary to prefix their declaration in ‘canonicalform.h’ by ‘CF_NO_INLINE’ instead of ‘CF_INLINE’. Furthermore, to avoid duplicate symbols at link time, their definition in this file has to be wrapped by an ‘#ifndef INCL_CF_INLINE_CC’.

It turned out that inlining the following methods (and only them) results in the best time to size ratio on Linux and HP machines: o all ‘CanonicalForm’ constructors o the binary ‘CanonicalForm’ operators ‘+’ and ‘*’

Definition in file cf_inline.cc.

Macro Definition Documentation

CF_INLINE

#define CF_INLINE   inline

Definition at line 109 of file cf_inline.cc.

Function Documentation

operator*()

CF_INLINE CanonicalForm FACTORY_PUBLIC operator*	(	const CanonicalForm &	lhs,
		const CanonicalForm &	rhs
	)

See also

CanonicalForm::operator *=()

Definition at line 524 of file cf_inline.cc.

{
    CanonicalForm result( lhs );
    result *= rhs;
    return result;
}

operator+()

CF_INLINE CanonicalForm FACTORY_PUBLIC operator+	(	const CanonicalForm &	lhs,
		const CanonicalForm &	rhs
	)

CF_INLINE CanonicalForm operator +, -, *, /, % ( const CanonicalForm & lhs, const CanonicalForm & rhs )

operators +, -, *, /, %(), div(), mod() - binary arithmetic operators.

The binary operators have their standard (mathematical) semantics. As explained for the corresponding arithmetic assignment operators, the operators ‘/’ and ‘%’ return the quotient resp. remainder of (polynomial) division with remainder, whereas ‘div()’ and ‘mod()’ may be used for exact division and term-wise remaindering, resp.

It is faster to use the arithmetic assignment operators (e.g., ‘f += g;’) instead of the binary operators (‘f = f+g;’ ).

Type info:

lhs, rhs: CurrentPP

There are weaker preconditions for some cases (e.g., arithmetic operations with elements from Q or Z work in any domain), but type ‘CurrentPP’ is the only one guaranteed to work for all cases.

Developers note:

All binary operators have their corresponding ‘CanonicalForm’ assignment operators (e.g., ‘operator +()’ corresponds to ‘CanonicalForm::operator +=()’, ‘div()’ corresponds to `CanonicalFormdiv()).

And that is how they are implemented, too: Each of the binary operators first creates a copy of ‘lhs’, adds ‘rhs’ to this copy using the assignment operator, and returns the result.

See also

CanonicalForm::operator +=()

Definition at line 503 of file cf_inline.cc.

{
    CanonicalForm result( lhs );
    result += rhs;
    return result;
}