Usage of INT_MAX, etc.

[Simon Hausmann]

On Tuesday 24. October 2006 21:22, Jaroslaw Staniek wrote:
> Simon Hausmann said the following, On 2006-10-24 21:02:
> > On Tuesday 24. October 2006 20:27, Jarosław Staniek wrote:
> >>Hello,
> >>
> >>(I). The problem
> >>
> >>I propose to use macros like INT_MAX instead of 2147483647, and so on in
> >>KDE code. For instance, KInputDialog uses hardcoded numbers like
> >>2147483647:
> >>
> >>int KInputDialog::getInteger (const QString & caption,
> >>		const QString &  	label,
> >>		int  	value = 0,
> >>		int  	minValue = -2147483647,
> >>		int  	maxValue = 2147483647,
> >>[..]
> >>
> >>INT_MAX, INT_MIN, ULLONG_MAX, etc. is defined within POSIX in limits.h.
> >>I noticed Qt (qinputdialog.h) does not use it. My suspect is that values
> >>like INT_MAX are not hardware-independent, while the API has to be
> >> portable at source code level. So maybe using INT_MAX and friends is not
> >>recommended? I may be wrong but so far I found two rules:
> >
> > From Qt's perspective INT_MAX and friends are perfectly fine. Don't look
> > at qinputdialog.h as reference :). limits.h is included in various public
> > header files and for example qlayoutitem.h uses INT_MAX.
> >
> > I don't think another level of indirection buys us anything here :)
>
> So if this is the case, could we switch to INT_MAX, etc. in methods like
> KInputDialog::getInteger(), to allow developers passing the default values
> a bit easier (by writing INT_MAX instead of copying/pasting 2147483647 in
> every place when they want to e.g. specify 'QWidget* parent' arg?

I don't get the 'QWidget* parent' part but yeah, I for one don't see a 
problem :)

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061024/9b70894d/attachment.sig>