Thread: Please rate at my code

Originally Posted by Sebastiani

Either way, ASSERTS ARE STRICTLY FOR DEBUGGING and should ALWAYS be disabled in the release build, regardless of the size or complexity of the program...

Not entirely...
There is such a thing as compile-time asserts. In C++ that typically means static_assert, or in C various macros like C_ASSERT are used. These are used precisely for finding mistakes at compile time, without having to debug the program. That is what should be used in this case.
Also, compile-time asserts are meant to be enabled for all project build types, which is fine since they have no run-time impact.


Make sure you test your function for an input value of -2147483648. An implementation that does not use an unsigned type internally will normally fail with that value, asuming 32-bit ints.

Originally Posted by Barney McGrew

Mostly, I'd think. I suppose there are also situations where you might want to print an integer with padding in a base that isn't supported by the *printf family.

Quite often you don't have a sprintf(). On an embedded system it might not be provided. On MS Windows you have wsprintf(), but it doesn't handle floating point values (no kidding), so you have to implement your own. Whilst my_atoi couldn't be used as it stands, it would be simple to retype char as w_char.