Usage of INT_MAX, etc.
hausmann at kde.org
Tue Oct 24 20:30:36 BST 2006
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:
> >>(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
> >>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel