![]() |
My Project
|
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 ). | |
| CF_INLINE CanonicalForm FACTORY_PUBLIC | operator* (const CanonicalForm &lhs, const CanonicalForm &rhs) |
definition of configurable inline `CanonicalForm' methods.
Hierarchy: canonicalform
Header file: canonicalform.h
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 *'
**/
check whether we are included or translated and define `INCL_CF_INLINE_CC' if we are included
// temporarily switch off CF_USE_INLINE' and include canonicalform.h' if we are being translated. // CF_USE_INLINE_SAVE' is used to save the state of CF_USE_INLINE'. It is unset after use.
/* ! INCL_CF_INLINE_CC */
// regular include files
// set the value of `CF_INLINE' for the following methods and functions
#define CF_INLINE
/* ! defined( CF_USE_INLINE ) && defined( INCL_CF_INLINE_CC )
Definition in file cf_inline.cc.
| #define CF_INLINE inline |
| CF_INLINE CanonicalForm FACTORY_PUBLIC operator* | ( | const CanonicalForm & | lhs, |
| const CanonicalForm & | rhs ) |
Definition at line 524 of file cf_inline.cc.
| 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;' ).
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.
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.
Definition at line 503 of file cf_inline.cc.