Hi, just my 2 cents: just coding some database stuff using QVariants,
and invariably (especially Monday mornings) it takes me a couple of
milliseconds extra to comprehend what the tooltip for QVariant's toInt()
means:
int toInt(bool *ok = 0) const;
instead, if qvariant.h could be written using nullptr or Q_NULLPTR:
int toInt(bool *ok = Q_NULLPTR) const;
It would increase the quality of Qt for me, at least.
Rgrds Henry
On 2015-02-09 08:36, Bo Thorsen wrote:
> Den 08-02-2015 kl. 22:42 skrev André Pönitz:
>> On Sun, Feb 08, 2015 at 10:17:40PM +0100, Allan Sandfeld Jensen wrote:
>>> What would be the point of macros if they always expanded? The entire point
>>> and usefulness of these macros is that they expand to standard keywords when
>>> those standard keywords exists.
>>
>> What's the point of using a macro in circumstances where a portable, standard
>> conforming, safe-to-use, shorter-to-type, version _without_ using a macro
>> exists?
>>
>> I.e. in case of a simple pointer initialization, why should one *ever* prefer
>>
>> void something()
>> {
>> Foo *f = Q_NULLPTR;
>> ...
>> }
>>
>> over
>>
>> void something()
>> {
>> Foo *f = 0;
>> ...
>> }
>>
>> ?
>>
>> For the sake of keeping this part of the discussion simple, I specifically
>> mean 'Q_NULLPTR, the macro', _not_ 'nullptr', and I specifically mean the
>> context of initializing a local pointer variable. So: Any advantage? Any
>> advantage outweighing the disadvantages?
>
> For this simple example, there is absolutely no benefit. Not even if you
> had replaced Q_NULLPTR with nullptr.
>
> But you forget that it isn't about this simple case. It's about the
> harder cases, which makes you want to compile your code with warnings
> about 0 for pointers. And that's impossible if at least the Qt headers
> are not clean for it.
>
> Whether we should use Q_NULLPTR in the cpp files is more of our own choice.
>
> Bo Thorsen,
> Director, Viking Software.
>
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
