When I wrote code a long time ago, one useful compiler feature I often used was that of typecasting. There are basically 2 types of programming languages (strongly typed and weak typed). With strongly typed languages such as Pascal and FORTRAN compilers, typecasting can force the conversion of one data type to another data type for useful reasons. In weak typed languages such as C and C++ you can do the conversion implicitly. In other words the C compiler will not complain if you are walking off a cliff. With strongly typed languages you are forced to tell the compiler– "Yes I know what I am doing, walk me off this cliff." The value with typecasting is that it provides an "extra" step and makes you think about the conversion. If no typecast operand was used for a conversion the compiler would issue errors on mismatched data types.
Below is a code fragment from a realtime OS called VAXELN. The compiler was called EPASCAL and it did support typecasting as well as many other real time extensions. The typecast was indicated with the ‘::’ operand.
begin walk:=header.flink; repeat if walk::^store^.id=id_in
then begin error (); walk:=address(header); found:=true; end else walk:=walk^.flink; until walk = address(header); end;
For me personally it did make a difference in producing quality code. Finding bugs, especially obscure ones, early in the implementation cycle makes sense. How many times have you had levels of indirection too many or too little with that pointer (^) that caused havoc? Clever code that a compiler can handle is nice, but code should be clean, easy to follow to the point of being self documenting. Keep the clever part of the project to the algorithm and/or design. Code it straight forward. Quality and stability does make a difference. Ask the customer who runs your software…