Three types of Constants that exist in C++

In a previous posting, I explained that I am able to write C++ programs, that test some aspect of how the CPU performs simplistic computations, even though C++ is a high-level language, which its compiler tries to optimize, before generating a machine-language program, the latter of which is called the run-time.

As I pointed out in that posting, there exists a danger that the computation may not take place the way in which the code reads to plain inspection, more specifically, in the fact that certain computations will be performed at compile-time, instead of at run-time. In reality, both the compile-time and the run-time computations as such still take place on the CPU, but in addition, a compiler can parse and then examine larger pieces of code, while a CPU needs to produce output, usually just based on the contents of a few registers – in that case, based on the content of up to two input-registers.

I feel that in contrast with the example which I wrote will work, I should actually provide an example, which will not work as expected. The following example is based on the fact that in C++, there exist three basic types of constants:

  1. Literals,
  2. Declared constants,
  3. Constant Expressions.

Constant expressions are any expressions, the parameters of which are never variables, always operators, functions, or other constants. While they can increase the efficiency with which the program works, the fact about constant expressions which needs to be remembered, is that by definition, the compiler will compute their values at compile-time, so that the run-time can make use of them. The example below is an example in which this happens, and which exists as an antithesis of the earlier example:

 


// This code exemplifies how certain types of
// computations will be performed by the compiler,
// and not by the compiled program at run-time.

// It uses 3 types of constants that exist in C++ .

#include <cstdio>

int main () {
	
	// A variable, initialized with a literal
	double x = 0;
	
	// A declared constant
	const double Pi = 3.141592653589;
	
	// A constant expression, being assigned to the variable
	x = ( Pi / 6 );
	
	printf("This is approximately Pi / 6 : %1.12f\n", x);
	
	return 0;
}


 


dirk@Plato:~/Programs$ ./simp_const
This is approximately Pi / 6 : 0.523598775598
dirk@Plato:~/Programs$


 

If this was practical code, there would be no problem with it, purely because it outputs the correct result. But if this example was used to test anything about how the run-time behaves, its innocent Math will suffer from one main problem:

When finally assigning a computed value to the double-precision floating-point variable ‘x’ , the value on the right-hand side of the assignment operator, the ‘=’ , is computed by the compiler, before a machine-language program has been generated, because all of its terms are either literals or declared constants.

This program really only tests, how well the ‘printf()’ function is able to print a double-precision value, when instructed exactly in what format to do so. That value is contained in the machine-code of the run-time, and not computed by it.

BTW, There exists a type of object in C, called a Compound Literal, which is written as an Initializer List, preceded by a data-type, as if to type-cast that initializer list to that data-type. But, because all manner of syntax that involves initializer lists is distinctly C and not C++ , I’ve never given much attention to compound literals.

(Edit 11/13/2017 : )

In other words, if the code above contained a term of the form

( 1 / ( 1 / Pi ))

Then chances are high, that because this also involves a constant expression, the compiler may simplify it to

( Pi )

Without giving the programmer any opportunity, to test the ability of the CPU, to compute any reciprocals.

Dirk

 

CSEditing

In This Posting, I wrote that I had completed my testing of ‘Crystal Space 2.1‘ on the laptop I name ‘Klystron’ – for now, by installing the ‘Blender‘ add-on script, that would actually allow a user to create content.

But there was yet another facet of this open-source game engine, which I have not yet tested. This is the ‘CSEditing‘ extension. On the surface, this plug-in is supposed to permit in-game editing of content.

Digging a bit deeper reveals a flaw, in what my expectations were.

Crystal Space is not a game, but a set of libraries with an API, that allows its users to create games, but which also allows its users to create any type of application, which will then benefit from complex 3D-graphic output. If such a game or application has in-game editing, it will be because individual users gave their creations this ability. It is not as if any of the CS demos actually show off this ability, and thus, there are few or no 3D applications yet written, that use this additional API.

When we compile the libraries that comprise CSEditing, we also compile an executable – a run-time program, which is meant just to prove that the API exists and can be used from an application. This actual run-time is not in itself a comprehensive editor.

In fact, the loading of the shared libraries, which make this feature work, still needs to be taken care of by the user, who wants to use Crystal Space in C++ to create his application. AFAIK, CSEditing does not depend on the Crystal Entity Layer.

The actual CSEditing API only has sparse documentation, which would be very valuable in the future, seeing as users will be trying to integrate such an advanced feature into their indie creations. But this also seems to suggest, that this is very much a work in progress.

What the demo application does show, is the stated capability of subdividing the window into panels, each of which either display a 3D view, or which display certain types of information panels, and which can be used to select elements of the 3D scene. Based on this last capability, a C++ program should also be able to grab more properties from each of the selected nodes, than this scant run-time does in practice.

But then, this run-time only display certain information about ‘the scene graph’ as it were, without allowing its user to edit anything. It would be up to the user himself, to design a¬†better application that uses this API.

And so, users like me are more likely just to appreciate such full-featured applications as Blender, to do actual editing. Without targeting an audience ourselves, with a transferred ability to edit content.

Continue reading CSEditing