|
|
||
|---|---|---|
|
|
||
|
FAQ |
+K3 -O --abstract_pointer --abstract_float
.o
and .ii files and start over. A more sophisticated
way to diagnose the problem is to search the .ii
files for the duplicates, and remove only those .ii
files and their corresponding .o files. An easy
way to search for duplicates is run the following UNIX commands
in the directory that contains the .ii files.
cat *.ii | sort | uniq -d
grep to find the .ii files that contain
the duplicates. Remove these .ii files and the corresponding
.o files and recompile.
| Redistributable files | libKCC* |
|---|
KCC --link_command_prefix `which purify` a.o b.o ...
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
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).
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. Another useful symbol
that it defines is _EXCEPTIONS, which is defined
if and only if exceptions are enabled.
KCC supports the December 1996 draft-standard ISO version of <stack>, which takes different arguments than the old HP STL version. See here for details.