Usage of INT_MAX, etc.
js at iidea.pl
Wed Oct 25 19:42:00 BST 2006
Thiago Macieira said the following, On 2006-10-25 18:37:
>>I am sorry, I'd like to talking about all the integer datatypes (hence
>>the "etc." in the "Usage of INT_MAX, etc." subject), and maybe floating
>>point (long double) is also affected. Sorry about choosing wrong
>>example. Talking about 'long's is better.
>>So: sizeof(long) is 8 under IA64 and 4 under powerpc (KDE is available
>>there on Linux and will be on MacOSX)
>>i.e. LONG_MAX/LONG_MIN/ULONG_MAX/ULONG_MIN are affected. I haven't
>>checked all the combinations yet.
>>Since the only constraint is that LONG_MAX >= 2147483647, LONG_MAX >=
>>INT_MAX, this could help:
>> #define LONG32_MAX 2147483647L
> What is a long32? Is that a long for when long is the same size as an int?
It is only the same as int if sizeof(int)==4. Hmm, to be compatible with Qt4,
maybe I should use INT32_MAX. See (*) below.
> If so, why not use INT_MAX?
Because INT_MAX tells you nothing about # of bits when you read the code. Even
if someone knows the standard, # of bits is >= 32. You mentioned it is == 32
on KDE-supported targets, so I added the example about long integers.
In a typical API methods 'int' means "big enough integer type". There is
remaining small percent of code in various apps that could not assume this.
LONG_MAX != INT_MAX. LONG_MAX can be 0x7FFFFFFFFFFFFFFF on some systems. If I
use int32, I know it's 4 bytes. If I use long I don't know this.
We're talking about code using at least qglobal.h, so compatible, convenience
defines can be:
#define INT32_MAX std::numeric_limits<qint32>::max()
#define INT64_MAX std::numeric_limits<qint64>::max()
> And, like it's been said, the constants are only useful if we don't know
> the size of a type. Since we know that this type is 32-bits in size, we
> know its limits.
See (**) below
> The database type limits are generally enforced and defined by the
> database backend, not by the application. A SMALLINT in one DB could be
> of a different size than the same name in another DB, or so I understand.
Types of a db server and db client's types are the same, what affects directly
the app using the client. E.g. when we want to convert 8 bytes to a long
integer value (e.g. fetched to mysql's char*), using int64 is safe and
longlong is not.
Then, e.g. in other code reading numbers from a data stream, checking the
input against INT64_MAX and INT64_MIN could be a bit more clear, before the
values are saved back to the db.
> My point is: I still don't see the use-case for these constants. If you
> know they are 32 bits in size, you know the limits. Or are you worried
> about people mis-typing the value?
(**) I am worried that 2147483647L tells nothing in the header file (or at
least you need to think two seconds about its meaning).
regards / pozdrawiam, Jaroslaw Staniek
Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
Kexi & KOffice: http://www.kexi-project.org, http://www.koffice.org
KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org
More information about the kde-core-devel