B
Bhushit Joshipura
I would like to gather views about an enhancement in C and C++ that
can lead to more robust programming.
First things first:
1. This posting addresses to both, C and C++. Please map an example to
your language of concern if it does not belong to your language of
concern.
2. Whatever I write here is a clear syntax error in both the
languages.
Pre-conditions and post-conditions to a function (method) are not only
important to theory or to comment inside code. They reflect in terms
of assert statements also. I propose to formalize them with prototype
/ declaration.
The idea:
1. Extend the concept of declaration (prototype) to a step further -
alongwith parameters, we specify assertions about them too. When the
function gets called (method gets invoked) these assertions, if
present, are [optionally] invoked before hitting the body of the
function.
For example, in C,
Current declaration:
int f ( int i, int *j, int k);
Possible extension 1:
int f (
int i {
i > 0 && i < INT_MAX
},
int *j {
j != NULL
},
int k {
k != some_global
}
);
2. Extend the concept of declaration to one more step further - we let
users add one more pair of parantheses in declaration to assert about
return value. This will complete the design as a communication to the
user who links the function (method) to her own code as well as will
generate a robust code.
For example, in C,
Current Declaration:
int *g (int i, int *j, int k);
Possible Extension 2:
int *g (
int i {
i > 0 && i < INT_MAX
},
int *j {
j != NULL
},
int k {
k != some_global
}
) (
j != NULL && __RETURN_VALUE__ != NULL
);
Advantages:
1. Clear communication to the person who links her code
2. Robust programming
3. Definitions (function bodies) become more readable
4. Assertions become more maintainable
Issues:
3.1 Can compare with constants and globals only. Those should be
visible in the .h file
3.2 As the standard does not (and probably will not) impose order of
evaluation of argument, we can not use one argument in assertion of
another argument. (We can not default to another argument in C++ for
the same reason, I guess.)
3.3 In a sense it violates WYSIWYG nature of C. No problem with C++
3.4 It may slow down execution. Compilers should provide a switch to
bypass assertions
3.5 Necessitates some error handler for assertion failure. (A good
code must already linking with some sort of <assert.h> or equivalent.)
3.6 Recursive call in an assertion (calling f in assertion of f's
argument) and similar stuff
can lead to more robust programming.
First things first:
1. This posting addresses to both, C and C++. Please map an example to
your language of concern if it does not belong to your language of
concern.
2. Whatever I write here is a clear syntax error in both the
languages.
Pre-conditions and post-conditions to a function (method) are not only
important to theory or to comment inside code. They reflect in terms
of assert statements also. I propose to formalize them with prototype
/ declaration.
The idea:
1. Extend the concept of declaration (prototype) to a step further -
alongwith parameters, we specify assertions about them too. When the
function gets called (method gets invoked) these assertions, if
present, are [optionally] invoked before hitting the body of the
function.
For example, in C,
Current declaration:
int f ( int i, int *j, int k);
Possible extension 1:
int f (
int i {
i > 0 && i < INT_MAX
},
int *j {
j != NULL
},
int k {
k != some_global
}
);
2. Extend the concept of declaration to one more step further - we let
users add one more pair of parantheses in declaration to assert about
return value. This will complete the design as a communication to the
user who links the function (method) to her own code as well as will
generate a robust code.
For example, in C,
Current Declaration:
int *g (int i, int *j, int k);
Possible Extension 2:
int *g (
int i {
i > 0 && i < INT_MAX
},
int *j {
j != NULL
},
int k {
k != some_global
}
) (
j != NULL && __RETURN_VALUE__ != NULL
);
Advantages:
1. Clear communication to the person who links her code
2. Robust programming
3. Definitions (function bodies) become more readable
4. Assertions become more maintainable
Issues:
3.1 Can compare with constants and globals only. Those should be
visible in the .h file
3.2 As the standard does not (and probably will not) impose order of
evaluation of argument, we can not use one argument in assertion of
another argument. (We can not default to another argument in C++ for
the same reason, I guess.)
3.3 In a sense it violates WYSIWYG nature of C. No problem with C++
3.4 It may slow down execution. Compilers should provide a switch to
bypass assertions
3.5 Necessitates some error handler for assertion failure. (A good
code must already linking with some sort of <assert.h> or equivalent.)
3.6 Recursive call in an assertion (calling f in assertion of f's
argument) and similar stuff