I was thinking. If oprerator==(T) can be unsafe, do we really need it?
std::optional has it, however we're not forced to copy std; dereferencing opt
is just one more symbol to type and it will behave like real pointer.
Иван Комиссаров
___
Development
Well, it doesn't compile.
Neither compile
int *a=0;
if (a==true) {}
At least, for clang.
Иван Комиссаров
> 21 авг. 2014 г., в 20:47, Thiago Macieira
> написал(а):
>
>> On Thursday 21 August 2014 20:29:36 Иван Комиссаров wrote:
>> Thiago, i've written a test for a bool optional. Does it work
On Thursday 21 August 2014 20:29:36 Иван Комиссаров wrote:
> Thiago, i've written a test for a bool optional. Does it work as expected?
>
> void tst_QOptional::boolOptional()
> {
> QOptional nullOpt;
> QOptional trueOpt(true);
> QOptional falseOpt(false);
>
> QVERIFY(!(nullOpt ==
do you suggest me to wait about 5 years before i can start working on a new
imageformats api? i won't be able to break api in qt6, so i have to wait till
qt7?)
Иван Комиссаров
21 авг. 2014 г., в 20:29, Milian Wolff написал(а):
> On Thursday 21 August 2014 09:18:22 Thiago Macieira wrote:
>> On
Thiago, i've written a test for a bool optional. Does it work as expected?
void tst_QOptional::boolOptional()
{
QOptional nullOpt;
QOptional trueOpt(true);
QOptional falseOpt(false);
QVERIFY(!(nullOpt == false));
QVERIFY(!(nullOpt == true));
QVERIFY((nullOpt != false));
On Thursday 21 August 2014 09:18:22 Thiago Macieira wrote:
> On Thursday 21 August 2014 13:24:23 Иван Комиссаров wrote:
> > We can't wait that long when committee will accept std::optional. Are you
> > sure it would get into c++14? I'm not. Next, when will MSVC support c++14?
> > It still has no su
On Aug 21, 2014, at 5:16 PM, Marc Mutz wrote:
> On Thursday 21 August 2014 16:52:05 Thiago Macieira wrote:
>> But I'd like QOptional o = QString() result in a null
>> (disengaged) QOptional too.
Why would that be?
The optional got a QString value assigned. It shouldn’t care about more.
> Too
On Thursday 21 August 2014, Marc Mutz wrote:
> On Thursday 21 August 2014 16:52:05 Thiago Macieira wrote:
> > But I'd like QOptional o = QString() result in a null
> > (disengaged) QOptional too.
>
> Too clever for a general optional class, IMO:
>
> QOptional qs = QString();
> QOptional ss =
On Thursday 21 August 2014 16:52:05 Thiago Macieira wrote:
> But I'd like QOptional o = QString() result in a null
> (disengaged) QOptional too.
Too clever for a general optional class, IMO:
QOptional qs = QString();
QOptional ss = std::string();
qs will be disengaged and ss will be engaged
On Thursday 21 August 2014 13:18:35 Иван Комиссаров wrote:
> Conclusion - we have 6 identical checks which can be avoided using
> QOptional
>
> So, i still think that simply returning QNothing() from these functions is
> a great improvement.
I'd say throwing an exception is what should happen, bu
On Thursday 21 August 2014 16:33:12 André Somers wrote:
> Thiago Macieira schreef op 21-8-2014 16:14:
> > On Thursday 21 August 2014 11:15:01 Julien Blanc wrote:
> >> Do you mean that you would change QSqlRecord::value to return, instead
> >> of a QVariant that can be null, a QVariant holding eithe
André Somers schreef op 21-8-2014 16:33:
> Thiago Macieira schreef op 21-8-2014 16:14:
>> I'd like to deprecate QVariant's internal
>> nullability concept and make it rely on carrying a QOptional for a type to be
>> null.
>>
>> If we don't do that, then QVariant: of a QOptional could be:
>>
>>1
Thiago Macieira schreef op 21-8-2014 16:14:
> On Thursday 21 August 2014 11:15:01 Julien Blanc wrote:
>> Do you mean that you would change QSqlRecord::value to return, instead
>> of a QVariant that can be null, a QVariant holding either an optional or
>> a non-optional object ? I don’t see any adva
Yes, it has both operator(T) and operator RestrictedBool
Still, i don't see a problem -
if (opt1 == false)
is equal to
if (opt1.operator==(false))
than expression is false.
If it is equal to
if (bool(opt1) == false)
than we have a problem. However, why the hell should compiler try to convert
t
On Thursday 21 August 2014 15:18:35 Иван Комиссаров wrote:
> QString::toInt() calls:
> QString::toIntegral_helper() (which has "if (ok)" check) which calls:
> QLocaleData::stringToLongLong (which again has "if (ok)" check); calls:
> QLocaleData::numberToCLocale (return bool, fuuuh) OR
> QLocaleData
On Thursday 21 August 2014 06:52:06 Keränen Pasi wrote:
> Hi Thiego,
>
> Sorry didn¹t mean to jump the gun. Still a bit new to the Qt process. Just
> to clarify, the module is not yet part of ³Qt proper². I guess a more
> correct term for it would have been ³a playground type of preview of a
> pot
On Thursday 21 August 2014 11:34:17 Иван Комиссаров wrote:
> Иван Комиссаров
>
> 21 авг. 2014 г., в 2:10, Thiago Macieira
написал(а):
> > The optional-cast-to-boolean is a source of problems for the current
> > std::optional. That hasn't been solved.
> >
> > QOptional opt1 = false;
> > QOptiona
On Thursday 21 August 2014 11:29:12 Иван Комиссаров wrote:
> In gerrit Jørgen Lind suggested to rename class to QMaybe. What do you
> think?
That's the original name I had for the class when Is started writing it in
2010, due to the D-Bus proposal for maybe type.
However, in C++ we should call i
On Thursday 21 August 2014 11:15:01 Julien Blanc wrote:
> Do you mean that you would change QSqlRecord::value to return, instead
> of a QVariant that can be null, a QVariant holding either an optional or
> a non-optional object ? I don’t see any advantages in doing so. That
> would make sense if
On Thursday 21 August 2014 11:17:36 Milian Wolff wrote:
> On Thursday 21 August 2014 13:13:15 Иван Комиссаров wrote:
> > Of course, i can:)
> >
> > bool ok;
> > const int value = string.toInt(&ok);
> > if (ok)
> >
> > qDebug() << "value is" << value;
> >
> > //
> > const auto value = st
On Thursday 21 August 2014 13:24:23 Иван Комиссаров wrote:
> We can't wait that long when committee will accept std::optional. Are you
> sure it would get into c++14? I'm not. Next, when will MSVC support c++14?
> It still has no support for constexprs and unicode literals, AFAIK. More,
> Qt has to
> Bot classes do NOT allow any default conversions (neither bool nor
> value nor string) which made their usage a bit more verbose but
> improved readability and safety a lot.
My experience has been similar. I took the std::optional proposal as a
starting point and stripped it back to just the bas
On 21/08/2014 13:01, Poenitz Andre wrote:
> Julien Blanc wrote:
>> There are two strong arguments in favor of optional :
>> - real life tends to show that the optional &ok parameter is often
>> missed in context it should not, leading to hard to find bugs.
>> - optional is much more friendly to st
People who are using this class are telling you - it is useful:) Discussions
started by people who never used this class. And it is ok - i am skeptical to
many new features too.
Иван Комиссаров
21 авг. 2014 г., в 16:16, Bubke Marco написал(а):
> Actually I like the idea but not so much the bo
Actually I like the idea but not so much the bool conversion operator. A
explicit method would be better. What about adding it in Qt Creator and testing
how useful it is? Is it not better to do something and speak about experiences
as to theorize in long discussions about the value of something
Actually, i plan to add Error class after (and if) QOptional will be merged. It
requires big discussion too (i like idea if having an error code, but it would
be better if we use a typed enum instead of int which should add 2nd template
parameter - T and ErrorEnum). I don't want to discuss all o
In our projects we are using a Result class that also exists as a
derived Outcome class. That Result class consists of a boolean
(telling if an error occurred or not) and optional eror code and an
optional error message. The derived Outcome class adds a value for
functions that do not only
You're forgetting that we're talking about private API for now, which means we
also need to look at the toInt implementation:
QString::toInt() calls:
QString::toIntegral_helper() (which has "if (ok)" check) which calls:
QLocaleData::stringToLongLong (which again has "if (ok)" check); calls:
QLoca
Julien Blanc wrote:
> There are two strong arguments in favor of optional :
> - real life tends to show that the optional &ok parameter is often
> missed in context it should not, leading to hard to find bugs.
> - optional is much more friendly to static verification than &ok
(dependancy between v
Иван Комиссаров
21 авг. 2014 г., в 14:37, Robert Knight написал(а):
> I've written a basic Option class with a minimal interface to
> address the problems with bool* OK args Julien mentioned and found it
> useful - both
> in terms of communicating that something may not have a value and also
>
I've written a basic Option class with a minimal interface to
address the problems with bool* OK args Julien mentioned and found it
useful - both
in terms of communicating that something may not have a value and also
it avoids the need for an invalid/null/empty version of T to be
defined.
*However
On Thu, 21 Aug 2014, Julien Blanc wrote:
There are two strong arguments in favor of optional :
- real life tends to show that the optional &ok parameter is often
missed in context it should not, leading to hard to find bugs. People
just write
const int value= string.toInt();
optional makes it
AFAIK the better examples/ideas can be found in the design rationale of
std::optional.
For example (may be, also the bad one:) ), it can be good if you can
distinguish initialized/non-initialized state, instead of
having
int m_val; //every possible integer value is reasonable
bool m_valInitializ
On 21/08/2014 11:50, Poenitz Andre wrote:
> Hausmann Simon wrote:
>> On Thursday 21. August 2014 13.13.15 Иван Комиссаров wrote:
>>> Of course, i can:)
>>>
>>> bool ok;
>>> const int value = string.toInt(&ok);
>>> if (ok)
>>> qDebug() << "value is" << value;
>>>
>>> //
>>> const auto valu
Den 21-08-2014 11:43, Иван Комиссаров skrev:
>
> Иван Комиссаров
>
> 21 авг. 2014 г., в 13:25, Simon Hausmann
> написал(а):
>
>> On Thursday 21. August 2014 13.13.15 Иван Комиссаров wrote:
>>
>> To be honest: I find the "bool ok" variant much easier to read.
>>
>> "if (value)" on an auto variable
On Thursday 21 August 2014 09:50:04 Poenitz Andre wrote:
> Hausmann Simon wrote:
> > On Thursday 21. August 2014 13.13.15 Иван Комиссаров wrote:
> > > Of course, i can:)
> > >
> > > bool ok;
> > > const int value = string.toInt(&ok);
> > > if (ok)
> > >
> > > qDebug() << "value is" << value;
Hausmann Simon wrote:
> On Thursday 21. August 2014 13.13.15 Иван Комиссаров wrote:
> > Of course, i can:)
> >
> > bool ok;
> > const int value = string.toInt(&ok);
> > if (ok)
> > qDebug() << "value is" << value;
> >
> > //
> > const auto value = string.toInt();
> > if (value)
> > qD
Иван Комиссаров
21 авг. 2014 г., в 13:25, Simon Hausmann написал(а):
> On Thursday 21. August 2014 13.13.15 Иван Комиссаров wrote:
>
> To be honest: I find the "bool ok" variant much easier to read.
>
> "if (value)" on an auto variable can mean so many things. In the
> above example you could
On Thursday 21. August 2014 13.13.15 Иван Комиссаров wrote:
> Of course, i can:)
>
> bool ok;
> const int value = string.toInt(&ok);
> if (ok)
> qDebug() << "value is" << value;
>
> //
> const auto value = string.toInt();
> if (value)
> qDebug() << "value is" << *value;
To be honest
21 авг. 2014 г., в 13:17, Milian Wolff написал(а):
On Thursday 21 August 2014 13:13:15 Иван Комиссаров wrote:
>> Of course, i can:)
>>
>> bool ok;
>> const int value = string.toInt(&ok);
>> if (ok)
>>qDebug() << "value is" << value;
>>
>> //
>> const auto value = string.toInt();
>> if
On 21/08/2014 11:17, Milian Wolff wrote:
> On Thursday 21 August 2014 13:13:15 Иван Комиссаров wrote:
>> Of course, i can:)
>>
>> bool ok;
>> const int value = string.toInt(&ok);
>> if (ok)
>> qDebug() << "value is" << value;
>>
>> //
>> const auto value = string.toInt();
>> if (value)
>>
Milian Wolff [m...@milianw.de]
> On Thursday 21 August 2014 13:13:15 Иван Комиссаров wrote:
> > Of course, i can:)
> >
> > bool ok;
> > const int value = string.toInt(&ok);
> > if (ok)
> > qDebug() << "value is" << value;
> >
> > //
> > const auto value = string.toInt();
> > if (value)
> >
On Thursday 21 August 2014 13:13:15 Иван Комиссаров wrote:
> Of course, i can:)
>
> bool ok;
> const int value = string.toInt(&ok);
> if (ok)
> qDebug() << "value is" << value;
>
> //
> const auto value = string.toInt();
> if (value)
> qDebug() << "value is" << *value;
This is a sou
On 21/08/2014 00:07, Thiago Macieira wrote:
> On Wednesday 20 August 2014 20:49:03 Marc Mutz wrote:
>> I don't find the QVariant::isNull behaviour any useful or intuitive. It's
>> too smart. You can always use v.value().isNull() because value() will
>> return a default-constructed T if invalid.
>
Of course, i can:)
bool ok;
const int value = string.toInt(&ok);
if (ok)
qDebug() << "value is" << value;
//
const auto value = string.toInt();
if (value)
qDebug() << "value is" << *value;
Иван Комиссаров
21 авг. 2014 г., в 13:09, Poenitz Andre написал(а):
Иван Комиссаров [abba..
Иван Комиссаров [abba...@gmail.com] wrote:
> The goal is to get rid of ugly "int QString::toInt(bool *ok = 0)" functions.
Can you maybe spell out some code to demonstrate why this is
ugly, and how the use of QOptional would improve that?
Andre'
___
Deve
Please look at "Improving toInt..." discussion
http://lists.qt-project.org/pipermail/development/2014-February/015422.html
The goal is to get rid of ugly "int QString::toInt(bool *ok = 0)" functions.
Besides, this class can be used in other places; take a look at
http://qt-project.org/doc/qt-4.8
Иван Комиссаров wrote:
> I've started working on a QOptional class
> (https://codereview.qt-project.org/#/c/92006/).
> As Thiago mentioned in gerrit, there are some things to discuss.
3) Why do we need that class at all?
Andre'
___
Development mailing
Иван Комиссаров
21 авг. 2014 г., в 2:10, Thiago Macieira написал(а):
> The optional-cast-to-boolean is a source of problems for the current
> std::optional. That hasn't been solved.
>
> QOptional opt1 = false;
> QOptional opt2 = 0;
> if (opt1)
> // this is true!
> if (opt2)
> // t
In gerrit Jørgen Lind suggested to rename class to QMaybe. What do you think?
Иван Комиссаров
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Forgot to mention, that the “stable” branch of my three.js port should run
out of the box on top of QtCanvas3D, the dev branch is always work in
progress more or less so might work, but probably doesn't. You can find
the stable branch at: https://github.com/tronlec/three.js/tree/stable
Pasi
On 2
51 matches
Mail list logo
