"Tushar Mehta" wrote...
No reason why you shouldn't. I use Integer and Bytes to indicate
intent. In fact, I wish I could declare a variable as
X as Real {-49..+49} or
X as Whole Number {-100..-50}
and have the compiler / OS / firmware / hardware enforce integrity.

There are languages which provide this. It could be implemented in C++,
creating Real and Whole classes with definable lower and upper value bounds
and the ability to throw exceptions when values exceed these bounds. Granted
it's a lot of work, but the capability exists.

Now, whether 'simple' languages like BASIC should provide this is arguable.

The time for worrying about nanosecond performance improvements
resulting from hardware-aligned variables has long since past. The
only time I worried about that kind of stuff was when programming in
Assember on a IBM360 -- and even then just for a lark.

You the application programmer may not gain much from concerning yourself
with memory alignment issues, but the systems programmers who write language
compilers and interpretters must because it's IMPOSSIBLE (as in the
hardware/CPU can't do it) to do some things unless you start out at a 16- or
32-bit boundaries.

In this age of hardware floating point processing, the only thing provided
by smaller integer or floating point types is potentially more economical
use of system storage. Actual calculations are generaly unaffected whether
operands are 8, 16 or 32 bits long. For individual (scalar) variables, the
benefits from saving 1 or 3 bytes is more than offset by the *cumulative*
performance penalty of dealing with non-paragraph alignment. There are
stronger arguments in favor of actually conserving memory when it comes to
arrays of potentially more economical types.