I think there probably should be a assertS, or something like that, for
people who want to make sure that their assertion is using correct
variables (static-type-checking).
What's wrong with static_assert()? If it's ugly, I have no problem with that
(static_cast, reinterpret_cast, etc.).
static_assert is fine with me, what is not neat is
stlsoft_static_assert.
However, it often is the case that the
programmer changes from constants to variables. In these cases the
programmer does not want to be searching through the code looking for
all asserts and changing them to assertS. Futhermore, if you pass in
constant parameters into a function such as:
void func(int X)
{
assert(X > 0);
}
...
func(10); //Contant
...
int y = z+10;
func(y);
The compiler should be able to identify these and apply them as if the
assert was static, at compile time. Otherwise you'd need to write two
versions of the function to have one with static assertion.
If I change something that was formerly subject to a static assertion, it is
a *very good thing* that the compiler balks in one or more places where an
assertion was applied to the thing changed. The compiler is doing exactly
what it should, in bringing to my attention as many of the ramifications of
my change as possible. Hiding it is just asking for trouble.
I wouldn't call this hiding, I'd call it early detection of possible
errors. Non-static asserts would be promoted to static asserts if
possible. The compiler already *hides* plenty of things. If you pass a
constant as a parameter into a function that takes variables, it
doesn't spat off error messages that your passing in a contant (of
couse you can have functions which only take in constants). Besides,
you don't always have to