On Thu, Jun 28, 2012 at 6:46 PM, Stephan Beal <sgb...@googlemail.com> wrote:
> 64-bits. size_t has at least the following drawbacks compared to using a > fixed-size integer type: > - In C++ size_t is often problematic in template specializations because in invariably collides with one of the other integer types (which might also be fully specialized). _Which_ fixed-size int type it collides with is platform-dependent and leads to convoluted workarounds like this: http://code.google.com/p/v8-juice/source/browse/convert/include/cvv8/detail/convert_core.hpp#1207 (that particular ugly hack is for long vs long-long, but the same applies to size_t) Sticking with fixed-size integers simply bypasses a whole range of downstream unsightliness, and a solution which bypasses problems by its very nature (as opposed to requiring extra effort to work around them) is always the winning solution in my book. So i don't mind at all making the blanket statement, "avoid size_t in new APIs." -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
