Re: Unsignedness of std::size_t
On Apr 14, 12:57 am, Pete Becker <p...@versatilecoding.com> wrote:
Robust code calls functions with valid arguments unless the function is
specified to check for invalid values. If code calls a function with
invalid values (i.e. negative integer values when the function calls for
a non-negative value), the code is wrong.
I very much have the same opinion. The value being passed in should be
a responsibility of the caller. If the interface has exposed the
parameter type to be unsigned, the caller must respect that. Breaking
the contract can lead to evil things happening and the class designer
is not responsible for bad usage.
In this case, there are other problems as well:
1. What if the caller wanted a range >
std::numeric_limits<int>::max()? What would he do? He falls short of
it. What if f() and g() in the examples of the article returned
unsigned values? What would one consider wrong - a greater than
std::numeric_limits<int>::max()?
2. What does the class designer do? The article shows to throw an
exception or do some other things. Now, what those other things could
be? How does the caller know about it? Of course, from the post
condition, that is again a part of the contract of the interface. It
could throw an exception - and the caller will not catch it - is not a
problem of the designer. Also, is it an exceptional condition to be
handled?
Callers should respect the binding contract with the interfaces they
use to make their code work correct otherwise evil things will happen
to them.
This all does not mean there is no solution to the problem. There is,
and the most obvious one for the caller to put a debug assert that
checks the signedness of the result of (f()-g()). That is, let the
user handle these cases as they feel fit, why enforce something on
them? It is just a matter of transfer of ownership of handling of that
particular scenario.
Also, a signed int "IS-NOT-A" unsigned int. Why would he then do
something like this:
int count = something.getCount(); //getCount returns unsigned int
With C++0x, I think this could be got rid of (using auto specifier for
count) telling count to be of the type of that of its initializer
(unless I misinterpreted it completely).
Another similar example that I can think of is :
somefunctionexpectingsignedint(a+b+c) where a,b,c are signed ints
(could be result of 3 function calls). Can the failure of the above be
handled by the interface designer or could the failure be credited to
him? That would be ridiculous. Refer this -
http://www.ddj.com/blog/cppblog/archives/2006/10/the_abstraction.html?cid=GS
_blog_akoenig
The lesson is - always respect the interface contract.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]