|
||
---|---|---|
|
||
FAQ |
static char rcsid[] = "info";
!
+K3 -O --abstract_pointer --abstract_float
static char rcsid[] = "info";
!
#define RCSID(x) namespace { \
inline const char* rcsid_f(const char *p) { return p; } \
const char *rcsid=rcsid_f(x); \
}
-ptused -tused -ptall -tall
or similar
options to control template instantiation, but you haven't turned off
the prelink step, which (on KCC 3.3) can become caught in a loop trying
to undo what it thinks are "automatic template assignments".
We recommend dropping these undocumented arcane options altogether.
--one_instantiation_per_object
linking, some source edits
that result in reassignment of templates from one .o to another in the
link can become confused halfway through the reassignment. Follow the
directions below.
.ti
file to be written when compilation terminates early due to a syntax error.
In this case the prelinker error message is unusual in that it doesn't
actually mention a templated symbol. The message says some
simple_name is assigned to both same.o and same.o
.
In this case ti_files/same.ti
has become corrupted;
remove it and recompile same.o.
ti_files/
are corrupt, the slow
but sure way to fix the problem is to remove all *.o
and ti_files/*.ii
files and start over. A more sophisticated
way is to diagnose the problem by finding the duplicates, and remove only
the files in conflict. In addition to the files identified in the prelinker
error message, you can find all other duplication by running the following UNIX commands
in the directory that contains the .ii
files:
cat *.ii | sort | uniq -d >dups
fgrep -f dups *.ii
.ii
files to which
they've become assigned. Remove these .ii
files and the corresponding
.o
files and recompile.
KCC_BASE/lib*/libKCC*
KCC
as
a compiler driving the native linker, use the option --link_command_prefix
followed by the complete path to the tool. For example, to use
Purify, (which is on your default path) link your program
as follows:
KCC --link_command_prefix `which purify` a.o b.o ...
--link_command_prefix
may rely on KCC to search the command path.
--link_command_prefix
. For example:
KCC --link_command_prefix "purify -cache-dir=$HOME/pcache" ...
class ONE {
public:
int& operator[](unsigned int);
operator int*();
};
void
test1() {
ONE one;
one[0] = 1;
}
line 9: error: more than one operator "[]"
matches these operands: built-in operator "pointer[integer]"
function "ONE::operator[]"
A: (13.3.3.1.2) To parameter 0 (which is "one"), Apply the user-defined conversion: sequence ONE --> int*. This conversion allows built-in operator "pointer[integer]" to match. B: (13.3.3.1.1) To parameter 1 (which is "0"), Apply the standard conversion sequence: int --> unsigned int. This conversion allows function "ONE::operator[]" to match.
B
wins since
it involves only standard conversions. However, The ISO rules
are different (13.3.3). For a match to win, it must have "better"
conversion sequences for each parameter than the losing match.
So we have:
0
, Match B
is "better"
than A
since B
requires no conversion
of parameter 0
.
1
, Match A
is "better"
than B
since A
requires no conversion.
B
win. To do this, remove
the need for the conversion (int
-->
unsigned
int
) by making the actual
parameter unsigned. For instance:
one[0u] = 1;
Besides culprits obvious to C programmers, there are new culprits specific to templates.
--one_instantiation_per_object
--implicit_include
may cause non-template symbols to be multiply defined.
If neither of the above applies (and the problem is not obvious to a C programmer), please report the problem so that we can fix KCC or add the cause to the list above.
Besides culprits obvious to C programmers, there are new culprits specific to virtual-function-tables and templates.
The same rule applies to template classes, but its application is a bit more interesting because the prelinker determines which .o file gets the first non-inline virtual function (if there is one).
KCC
to build a (shared or unshared)
library may cause template symbols to be undefined,
because the prelinker was not run. See the section
on building libraries.
If none of the above applies (and the problem is not obvious to a C programmer), please report the problem so that we can fix KCC or add the cause to the list above.
Often there are certain warnings that a programmer feels should be errors. Unfortunately, sometimes tastes differ on this, and sometimes it is impossible for KCC to distinguish the cases that are definitive errors. To solve this problem, KCC allows the severity of each kind of warning to be changed to errors. There are two steps to do so.
--display_error_number
to make
KCC report the number n associated with the warning.
--diag_error
n to tell
KCC to consider the warning an error. The value of n
is the decimal integer (without other letters or punctuation)
reported by the previous step.
For example, warning number 414 concerns deletion of an object with incomplete class type. The draft-ISO standard says that such a deletion is legal if the class has a trivial destructor. If the destructor is non-trivial (does something interesting), the draft says the behavior is undefined, and in fact KCC will not call the destructor before deleting the object. Unfortunately, since the type is incomplete, KCC does not detect whether the deletion is really legal, but at least issues a warning about the potential problem. Programmers who are not depending upon the required behavior for objects with trivial destructors may wish to change the warning to an error. Below is an example showing how the warning number was found and changed to an error.
$ KCC -c --display_error_number example.C "example.C", line 4: warning #414-D: delete of pointer to incomplete class delete p; ^ $ KCC -c --diag_error 414 example.C "example.C", line 4: error: delete of pointer to incomplete class delete p; ^ 1 error detected in the compilation of "example.C".
KCC defines the symbol __KCC
.
If the symbol __KCC_VERSION
is defined,
it will have an integer value that is related to the current
version number of KCC. The rightmost two digits correspond to
the bug-fix release level (a==01, b==02, etc.).
The other digits correspond to the numeric portions of the
version number with the decimal point removed.
For example: KCC version 3.4d would
define __KCC_VERSION
as 3404
.
KCC defines _EXCEPTIONS
,
if and only if exceptions are enabled.
KCC supports the standard ISO version of <stack>, which takes different arguments than the old HP STL version. See here for details.