On 28/06/2012 12:30 PM, Cory Nelson wrote:
On Thu, Jun 28, 2012 at 11:20 AM, Stephan Beal <sgb...@googlemail.com>wrote:
On Thu, Jun 28, 2012 at 5:57 PM, Simon Slavin <slav...@bigfraud.org>
wrote:
Now the URL:
<http://www.sqlite.org/src4/doc/trunk/www/design.wiki>
Just thought some people might enjoy reading and thinking about it.
FWIW, my 0.02 Euros regarding this line:
"SQLite4 makes use of standard data types such as size_t, int64_t,
uint64_t,
and others."
size_t does not have a specified size and causes all sorts of grief in
porting i/o-based APIs between 32/64 bits, in my experience. PLEASE use the
fixed-size integers defined in inttypes.h, and not size_t. There is of
course one notable caveat: MSC does not support inttypes.h/stdint.h BUT
there are free drop-in replacements available here:
http://code.google.com/p/msinttypes/
stdint was made available in VC++ 2010, though inttypes is still missing.
Probably not an issue -- I'm not sure how a public API would need inttypes
anyway. Also, perhaps you are seeing size_t be misused. A blanket "please
don't use" is nonsense.
I tend to agree with Simon on this. size_t is only useful when
expressing the amount of memory something might involve, when
constrained only by the size of the current machine's address space.
Major examples would include sizeof(), malloc(), and strlen(). C++
std::vector::size() is an anti-pattern, since the number of elements in
a vector is not a number of bytes. However, size_t isn't particularly
helpful even when used "correctly." Any 32-bit portable code can safely
use uint32_t everywhere: it's equivalent to size_t on 32-bits, and it
will silently convert to size_t whenever needed on a 64-bit machine; if
the code is 64-bit only -- most likely to allow for allocations larger
than 4GB -- then uint64_t can be used everywhere instead.
$0.02
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
