Frequently Asked Questions



Table of Contents      

Introduction

Getting Up and Running

 

Debugging

New C++ Features

 

External Interface   

Tutorials

Man Page

FAQ   


Index of Questions


I am not concerned about how fast my program runs. How do I make KAI C++ compile programs quickly?

Use +K0 to set the lowest level of optimization.

 

How do I make KAI C++ work hardest to optimize my program?

If your program is machine-independent C++, set the command-line options as shown below.

+K3 -O --abstract_pointer --abstract_float

 

If your program is dependent upon the machine architecture, you may have to turn off abstract pointer and abstract float.

 

What is the speed advantage for turning off exceptions?

It differs depending upon the code. For the parts of a program that do not contain exception-handling constructs, the advantage seems to be no better than 10% (at the highest level of optimization). However, inline throws and try blocks are best avoided for sake of code bloat.

 

 

KAI C++ optimized away my static char rcsid[] = "info";!

Eliminating simple unused static objects is a necessary optimization for some kinds of programs. An alert KCC user found the following alternative phrasing not yet recognizable as extra baggage:

#define RCSID(x) namespace {                                \
    inline const char* rcsid_f(const char *p) { return p; } \
    const char *rcsid=rcsid_f(x);                           \
  }
  

 

When KAI C++ links my program, why does it sometimes recompile some of my object files?

KAI C++ is automatically instantiating templates.

 

KAI C++ will not link my program because it says that a template is assigned to more than one file.

This can happen in several situations:
  1. You can explicitly force several files to hold the same template. Perhaps an inadvertent (implicit?) inclusion of a .h or a .cpp file has produced the same template instantiation twice. The prelinker names two of the files and the template which collided, start your search there.
  2. On KCC 3.x, you have tried to reuse a .o file in two different link steps and the template assignments are conflicting. We recommend building separate applications in separate directories.
  3. You're using -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.
  4. Under --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.
  5. A bug in KCC 3.3 releases prior to patch level "f" causes a corrupt .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.
 
If you suspect some 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
This produces a list of duplicates and finds the .ii files to which they've become assigned. Remove these .ii files and the corresponding .o files and recompile.

 

What files am I allowed to redistribute when I distribute my applications?

You may not redistribute any files except for the run-time components below:
KCC_BASE/lib*/libKCC*

These run-time components, and derivatives thereof, may be embedded in object code form only in your application. Shared Libraries from KCC versions 3.3 and later may be distributed without modification. Check your license agreement for the terms and conditions of redistribution.

You must include the following notice in the documentation of any product that includes a RTC or portion thereof:

Copyright © 1996-1999 by Kuck & Associates, Inc.; All rights reserved.

 

How do I use Purify® with KCC?

Purify and similar binary editing tools run as prefixes to the linker. If, like Purify, your linker prefix tool does not recognize 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 ...
Except for KCC versions 3.3a,b & c, the argument to --link_command_prefix may rely on KCC to search the command path.
In versions later than KCC 3.3d, a bug is fixed which restores the KCC 3.2 ability to accept multiple tokens separated by blanks as a quoted argument to --link_command_prefix. For example:
KCC --link_command_prefix "purify -cache-dir=$HOME/pcache" ...

 

I have an old G++ code that uses templates. How do I compile it with KCC?

For information on the migration problem, check the migration document available on KAI's web site.

 

Overloaded operator resolution problems

Try the command-line option --cfront_3.0 or --cfront_2.1 when compiling source files written for older compilers that are cfront compatible. By default, KCC uses the draft standard ISO C++ rules for resolving overloaded operators, not the cfront rules.

 

The most common problem is demonstrated by the example below. Numbers in parentheses refer to sections of the April 1995 public copy of the ISO Working Paper.

 

 
When compiled by KCC (without Cfront mode switches), we get:

line 9: error: more than one operator "[]" matches these operands: built-in operator "pointer[integer]" function "ONE::operator[]"

 

KCC found two matches because there are two possible "conversion sequences," and each involves a different parameter.

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.

Under the ARM (Cfront) rules, 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:

 

For parameter 0, Match B is "better" than A since B requires no conversion of parameter 0.
For parameter 1, Match A is "better" than B since A requires no conversion.

 

Thus neither match is better than the other and there is an ambiguity. So, this leaves the question of how to change the code to make it acceptable to ISO C++ compilers. The probable intent was to have match 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;

 

Multiply defined symbol error

Besides culprits obvious to C programmers, there are new culprits specific to templates.

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.

 

Undefined symbol error

Besides culprits obvious to C programmers, there are new culprits specific to virtual-function-tables and templates.

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.

 

How to I turn a warning into an error?

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.

  1. Use the option --display_error_number to make KCC report the number n associated with the warning.
  2. Use the option --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".

 

What special preprocessor symbols does KCC define?

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.

 

Why won't my code using class stack compile?

KCC supports the standard ISO version of <stack>, which takes different arguments than the old HP STL version. See here for details.


Copyright © 1996-1999. All rights reserved.

E-Mail KAI Technical Support   E-Mail KAI   Contact KAI   

This file last updated on 29 July 1999.