Search This Blog

Saturday, November 27, 2010

enum Types in C++



Introduction

In C and C++, enum types can be used to set up collections of named integer constants. (The keyword enum is short for ``enumerated''.)The traditional C way of doing this was something like this:
#define SPRING   0
#define SUMMER   1
#define FALL     2
#define WINTER   3
An alternate approach using enum would be
enum { SPRING, SUMMER, FALL, WINTER };

enum declarations

There are two kinds of enum type declarations. One kind creates a named type, as in
enum MyEnumType { ALPHA, BETA, GAMMA };
If you give an enum type a name, you can use that type for variables, function arguments and return values, and so on:
enum MyEnumType x;  /* legal in both C and C++ */
MyEnumType y;       // legal only in C++
The other kind creates an unnamed type. This is used when you want names for constants but don't plan to use the type to declare variables, function arguments, etc. For example, you can writeenum { HOMER, MARGE, BART, LISA, MAGGIE };

Values of enum constants

If you don't specify values for enum constants, the values start at zero and increase by one with each move down the list. For example, given
enum MyEnumType { ALPHA, BETA, GAMMA };
ALPHA has a value of 0, BETA has a value of 1, and GAMMA has a value of 2.If you want, you may provide explicit values for enum constants, as in
enum FooSize { SMALL = 10, MEDIUM = 100, LARGE = 1000 };

C++ enum type conversion rules

These rules apply to C++ only. The rules for C are different.There is an implicit conversion from any enum type to int. Suppose this type exists:
enum MyEnumType { ALPHA, BETA, GAMMA };
Then the following lines are legal:
int i = BETA;      // give i a value of 1
int j = 3 + GAMMA; // give j a value of 5
On the other hand, there is not an implicit conversion from int to an enum type:
MyEnumType x = 2;    // should NOT be allowed by compiler
MyEnumType y = 123;  // should NOT be allowed by compiler 
Note that it doesn't matter whether the int matches one of the constants of the enum type; the type conversion is always illegal. 

Saturday, November 6, 2010

Destructor

The symmetric operation is the destruction of objects. This is required as soon
as the object dynamically allocates other objects.
The special method defined to do that is called the destructor, and is called as
soon as the compiler need to deallocate an instance of the class. There is only
one destructor per class, which return no value, and has no parameter. The
name of the destructor is the class name prefixed with a ~.
We can now re-write our matrix class :

class Matrix {
int width, height;
double *data;
public:
Matrix(int w, int h) {
width = w; height = h;
data = new double[width * height];
}
~Matrix() { delete[] data; }
double getValue(int i, int j) {
if((i<0) || (i>=width) || (j<0) || (j>=height)) abort();
return data[i + width*j];
}
void setValue(int i, int j, double x) {
if((i<0) || (i>=width) || (j<0) || (j>=height)) abort();
data[i + width*j] = x;
}
};

Constructors

The C++ syntax defines a set of special methods called constructors. Those
methods have the same name as the class itself, and do not return results. They
are called when the variable of that type is defined :

#include
#include
class NormalizedVector
{
double x, y;
public:
NormalizedVector(double a, double b) {
double d = sqrt(a*a + b*b);
x = a/d;
y = b/d;
}
double getX() { return x; }
double getY() { return y; }
};
int main(int argc, char **argv) {
NormalizedVector v(23.0, -45.0);
cout << v.getX() << ’ ’ << v.getY() << ’\n’;
NormalizedVector *w;
w = new NormalizedVector(0.0, 5.0);
cout << w->getX() << ’ ’ << w->getY() << ’\n’;
delete w;
};

The same class can have many constructors :
#include
#include
class NormalizedVector {
double x, y;
public:
NormalizedVector(double theta) {
x = cos(theta);

y = sin(theta);
}
NormalizedVector(double a, double b) {
double d = sqrt(a*a + b*b);
x = a/d;
y = b/d;
}
double getX() { return x; }
double getY() { return y; }
};

Wednesday, November 3, 2010

Compatibility of C and C++


The C and C++ programming languages are closely related. C++ grew out of C, as it was designed to be source-and-link compatible with C. Due to this, C code is often developed with C++ IDEs, integrated with C++ code, and compiled in C++ compilers. While most C source code will compile as C++ code without any changes, certain language differences prevent C++ from being a strict superset of C.
Likewise, C++ introduces many features that are not available in C and in practice almost all code written in C++ is not conforming C code. This article, however, focuses on differences that cause conforming C code to be ill-formed C++ code, or to be conforming/well-formed in both languages but to behave differently in C and C++.
Bjarne Stroustrup, the creator of C++, has suggested that the incompatibilities between C and C++ should be reduced as much as possible in order to maximize inter-operability between the two languages. Others have argued that since C and C++ are two different languages, compatibility between them is useful but not vital; according to this camp, efforts to reduce incompatibility should not hinder attempts to improve each language in isolation. The official rationale for the 1999 C standard (C99) "endorse[d] the principle of maintaining the largest common subset" between C and C++ "while maintaining a distinction between them and allowing them to evolve separately," and stated that the authors were "content to let C++ be the big and ambitious language."
Several additions of C99 are not supported in C++ or conflict with C++ features, such as variadic macros, compound literals, designated initializers, variable-length arrays, and native complex-number types. The long long int datatype and restrict qualifier defined in C99 are not included in the current C++ standard, but some compilers such as the GNU Compiler Collection provide them as an extension. The long long datatype along with variadic templates, with which some functionality of variadic macros can be achieved, will be in the next C++ standard, C++0x. On the other hand, C99 has reduced some other incompatibilities by incorporating C++ features such as // comments and mixed declarations and code.

Constructs valid in C but not C++

One commonly encountered difference is that C allows a void* pointer to be assigned to any pointer type without a cast, whereas C++ does not; this idiomappears often in C code using malloc memory allocation. For example, the following is valid in C but not C++:
void* ptr;
int *i = ptr;       /* Implicit conversion from void* to int* */
or similarly:
int *j = malloc(sizeof(int) * 5);     /* Implicit conversion from void* to int* */
In order to make the code compile in both C and C++, one must use an explicit cast:
void* ptr;
int *i = (int *) ptr;
int *j = (int *) malloc(sizeof(int) * 5);
Another portability issue from C to C++ are the numerous additional keywords that C++ introduced. This makes C code that uses them as identifiers invalid in C++. For example:
struct template 
{
    int new;
    struct template* class;
};
is valid C code, but is rejected by a C++ compiler, since the keywords "template", "new" and "class" are reserved.
C++ compilers prohibit using goto or switch from crossing an initialization, as in the following C99 code:
void fn(void)
{
  goto flack;
  int i = 1;
flack:
  ;
}
There are many other C syntaxes which are invalid or behave differently in C++ :
  • The comma operator can result in an "l-value" (a quantity that can be used for the left-hand side of an assignment) in C++, but not in C.
  • C does not allow a given typedef to be duplicated in the same scope, whereas C++ allows repeated typedefs.
  • Enumeration constants (enum values) are always of type int in C, whereas they are distinct types in C++ and may have size different from that of int.
  • C++ identifiers are not allowed to contain two or more consecutive underscores in any position. C identifiers are not allowed to start with two or more consecutive underscores, but may contain them in other positions.
  • C++ also changes some C standard library functions to add additional const qualifiers, e.g. strchr returns char* in C and const char* in C++.
  • In both C and C++ one can define nested struct types, but the scope is interpreted differently (in C++, a nested struct is defined only within the scope/namespace of the outer struct).
  • Non-prototype ("K&R"-style) function declarations are not allowed in C++, although they have also been deprecated in C since 1990. Similarly, implicit function declarations (using functions that have not been declared) are not allowed in C++, but have also been deprecated in C since 1999.
  • C allows structunion, and enum types to be declared in function prototypes, whereas C++ does not.
  • structunion, or enum declaration in C++ usually implies an implicit typedef of the same name, while in C it does not.
  • In C, a function prototype without arguments, e.g. int foo();, implies that the parameters are unspecified. Therefore it is legal to call such a function with one or more arguments, e.g. foo(42, "hello world"). In contrast, in C++ a function prototype without arguments means that the function takes no arguments, and calling such a function with arguments is ill-formed. In C, the correct way to declare a function that takes no arguments is by using 'void', as in int foo(void);.


Constructs that behave differently in C and C++

There are a few syntactical constructs that are valid in both C and C++, but produce different results in the two languages.
For example, character literals such as 'a' are of type int in C and of type char in C++, which means that sizeof 'a' will generally give different results in the two languages: in C++ it will be 1in C it will be sizeof(int) which on architectures with 8 bit wide char will be at least 2. As another consequence of this type difference, in C 'a' will always be a signed expression, regardless of whether or not char is a signed or unsigned type, whereas for C++ this is compiler implementation specific.
The static keyword is used in C to restrict a function or global variable to file scope (internal linkage). This is also valid in C++, although C++ deprecates this usage in favor of anonymous namespaces (which are not available in C). Also, C++ implicitly treats any const global as file scope unless it is explicitly declared extern, unlike C in which extern is the default. Conversely,inline functions in C are of file scope whereas they have external linkage by default in C++.
Several of the other differences from the previous section can also be exploited to create code that compiles in both languages but behaves differently. For example, the following function will return different values in C and C++:
extern int T;
 
int size(void)
{
    struct T {  int i;  int j;  };
 
    return sizeof(T);
    /* C:   return sizeof(int)
     * C++: return sizeof(struct T)
     */
}
This is due to C requiring struct in front of structure tags (and so sizeof(T) refers to the variable), but C++ allowing it to be omitted (and so sizeof(T) refers to the implicit typedef). Beware that the outcome is different when the extern declaration is placed inside the function: then the presence of an identifier with same name in the function scope inhibits the implicit typedef to take effect for C++, and the outcome for C and C++ would be the same. Observe also that the ambiguity in the example above is due to the use of the parenthesis with the sizeof operator. Using sizeof T would expect T to be an expression and not a type, and thus the example would not compile with C++.
Both C99 and C++ have a boolean type bool with constants true and false, but they behave differently. In C++, bool is a built-in type and a reserved keyword. In C99, a new keyword, _Bool, is introduced as the new boolean type. In many aspects, it behaves much like an unsigned int, but conversions from other integer types or pointers always constrained to 0 and 1. Other than for other unsigned types, and as one would expect for a boolean type, such a conversion is 0 if and only if the expression in question evaluates to 0 and it is 1 in all other cases. The header stdbool.hprovides macros booltrue and false that are defined as _Bool1 and 0, respectively.


Linking C and C++ code

While C and C++ maintain a large degree of source compatibility, the object files their respective compilers produce can have important differences that manifest themselves when intermixing C and C++ code. Notably:
  • C compilers do not name mangle symbols in the way that C++ compilers do.
  • Depending on the compiler and architecture, it also may be the case that calling conventions differ between the two languages.
For these reasons, for C++ code to call a C function foo(), the C++ code must prototype foo() with extern "C". Likewise, for C code to call a C++ function bar(), the C++ code for bar() must be declared with extern "C".
A common practice for header files to maintain both C and C++ compatibility is to make its declaration be extern "C" for the scope of the header:
/* Header file foo.h */
#ifdef __cplusplus /* If this is a C++ compiler, use C linkage */
extern "C" {
#endif
 
/* These functions get C linkage */
void foo();
 
struct bar { /* ... */ };
 
#ifdef __cplusplus /* If this is a C++ compiler, end C linkage */
}
#endif
Differences between C and C++ linkage and calling conventions can also have subtle implications for code that uses function pointers. Some compilers will produce non-working code if a function pointer declared extern "C" points to a C++ function that is not declared extern "C".
For example, the following code:
void my_function();
extern "C" void foo(void (*fn_ptr)(void));
 
void bar()
{
   foo(my_function);
}
Using Sun Microsystems' C++ compiler, this produces the following warning:
$ CC -c test.cc
"test.cc", line 6: Warning (Anachronism): Formal argument fn_ptr of type
extern "C" void(*)() in call to foo(extern "C" void(*)()) is being passed
void(*)().
This is because my_function() is not declared with C linkage and calling conventions, but is being passed to the C function foo().