On Jul 4, 11:27 am, pauldepst...@att.net wrote:
Quote:
While reading some source code, I saw a variable called "end" of type
"time". So I investigated what the type "time" meant and saw that
time was a typedef for "Real". So what does "Real" mean? "Real" is a
typedef for QL_REAL. So what does "QL_REAL" mean? QL_REAL is type
double via the line of code #define QL_REAL double.
>
I understand the need for generality and flexibility but this left me
thinking that "end" should have been declared as double in the first
place to make the code less opaque.
>
Is there any way to preserve the flexibility but avoid such an
unwieldy chain of typedefs. Is there any way of indicating to the
user via some sort of default type concept that type "time" is
generally double but could be changed later?
>
Since I admit that my first thought "Just make "time" a double in the
first place!" does lose flexibility, I'd like to ask how such a chain
of typedefs could (or whether it should) be avoided.
|
While obviously the ability to do this can be abused, there are many
cases when it's appropriate. Often it's the case that some library or
service presented in a header wants to use and expose a more
fundamental (often operating system specific) type, but they want to
preserve the ability to switch their clients across to some internal
or different underlying type (requiring a recompile but not client
code modification) if that ever becomes necessary.
Another possible approach is through any of the many varieties of
variant types, but they introduce often significant storage and
performance overheads, and oft-time potential for what are currently
compile-time errors to become much more serious run-time errors.
If it's bothering you, perhaps use an editor/IDE or writing a tool
that conveniently exposes/follows the chain of typedefs/defines.
Cheers,
Tony
Working through many typedefs 
