On quinta-feira, 2 de agosto de 2012 14.50.04, Thiago Macieira wrote:
The macro expands to nothing in C++98 mode. That means code using the API
so marked and compiling in C++98 mode will simply not gain the benefits of
the keyword, but should see no side effects.
Updates on the noexcept work:
On terça-feira, 7 de agosto de 2012 13.37.27, Thiago Macieira wrote:
3) MSVC reportedly stores the exception specification in the mangled name.
I have not been able to reproduce this with my MSVC 2010 and I haven't
been able to reach Marius for confirmation yet. It could be either MSVC
2012
On Friday 03 August 2012 15:42:49 marius.storm-ol...@nokia.com wrote:
On 03/08/2012 07:49, ext Thiago Macieira wrote:
And operator== can't change incompatibly.
Does this mean that we should have an
bool QDateTime::isIdentical(const QDateTime dt)
function too (effectively an
On Thursday 02 August 2012 23:01:55 you wrote:
On Thursday August 2 2012, Konrad Rosenbaum wrote:
On Thursday 02 August 2012, Thiago Macieira wrote:
On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote:
Where is qHash(QDateTime) defined? It doesn't seem to be where I
On sexta-feira, 3 de agosto de 2012 09.58.24, Konrad Rosenbaum wrote:
For QTime and QDate this is uncritical - these are the native storage
format, although a few methods would have to be marked noexcept as well.
Which I've done, except for inline methods.
For QDateTime this potentially
On 03/08/2012 07:49, ext Thiago Macieira wrote:
On sexta-feira, 3 de agosto de 2012 09.58.24, Konrad Rosenbaum
wrote:
The problem with QDateTime is that the operator== also does some
calculations. It compares as equal two QDateTime objects with
different times and timezones, provided that
On 3 August 2012 08:58, Konrad Rosenbaum kon...@silmor.de wrote:
For QDateTime this potentially involves heavy calculations. The upside of this
is that this guarantees unchanged hashes even if the internal representation
of QDateTime changes. How hard is the requirement to create the same hash
On Friday August 3 2012, Thiago Macieira wrote:
On quinta-feira, 2 de agosto de 2012 23.57.58, Marc Mutz wrote:
noexcept(std::declvalObject().f()) should work.
Unfortunately, while the C++11 compiler support seems to be going fine, the
library support is lagging WAY behind. Add to that the
On quinta-feira, 2 de agosto de 2012 23.57.58, Marc Mutz wrote:
noexcept(std::declvalObject().f()) should work.
error: invalid use of incomplete type ‘struct Object’
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden
--
Sergio AhumadaOn 03.08.12 18:13 ext Giuseppe D'Angelo wrote:
On 3 August 2012 08:58, Konrad Rosenbaum kon...@silmor.de wrote:
For QDateTime this potentially involves heavy calculations. The upside of this
is that this guarantees unchanged hashes even if the internal representation
of
I'd like to propose we add Q_DECL_NOEXCEPT to many methods in our API.
We already took the decision to turn exception off in most modules, except
QtCore and where exceptions were used, like QtXmlPatterns. This is the next
step.
The Q_DECL_NOEXCEPT macro expands to noexcept, which is a new
I'd say go ahead. Since adding it shouldn't change the ABI/name mangling, we
can introduce this gradually anyway.
Cheers,
Lars
On Aug 2, 2012, at 2:50 PM, ext Thiago Macieira thi...@kde.org
wrote:
I'd like to propose we add Q_DECL_NOEXCEPT to many methods in our API.
We already took the
Thiago spaketh:
I'd like to propose we add Q_DECL_NOEXCEPT to many methods in our API.
We already took the decision to turn exception off in most modules, except
QtCore and where exceptions were used, like QtXmlPatterns. This is the next
step.
The Q_DECL_NOEXCEPT macro expands to noexcept,
On quinta-feira, 2 de agosto de 2012 13.00.22, lars.kn...@nokia.com wrote:
I'd say go ahead. Since adding it shouldn't change the ABI/name mangling, we
can introduce this gradually anyway.
By the way, let's be conservative instead of doing it throughout.
Once added, the noexcept keyword cannot
Hi Thiago,
On Thursday August 2 2012, Thiago Macieira wrote:
I'd like to propose we add Q_DECL_NOEXCEPT to many methods in our API.
+1 from me, too.
[Though it doesn't seem to help with the problem that move constructors can't
be inline if the class uses smart pointers. It still wants to call
On quinta-feira, 2 de agosto de 2012 16.02.43, Marc Mutz wrote:
Need to be careful with templates. Can't use add the unrestricted noexcept
there, need to use noexcept(noexcept(expr)), which is even uglier
templatetypename T inline uint qHash(const T t, uint seed)
Hi,
On Thursday 02 August 2012 15:27:03 Thiago Macieira wrote:
For example, in when I was just now adding it to qHash for QDateTime, I
realised it does complex operations. Right now, none of those operations
allocate memory, but it's actually very close to doing that. QDateTime has
a d
On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote:
Hi,
On Thursday 02 August 2012 15:27:03 Thiago Macieira wrote:
For example, in when I was just now adding it to qHash for QDateTime, I
realised it does complex operations. Right now, none of those operations
allocate
On 02/08/2012 07:50, ext Thiago Macieira wrote:
The macro expands to nothing in C++98 mode. That means code using the
API so marked and compiling in C++98 mode will simply not gain the
benefits of the keyword, but should see no side effects.
The presence of the keyword does not affect binary
On quinta-feira, 2 de agosto de 2012 17.15.26, marius.storm-ol...@nokia.com
wrote:
So, perhaps we can identify the cases where they are similar and use
that with MSVC until proper noexcept()/noexcept(type) support is provided?
Yes. I can identify where they are similar: nowhere.
If you add
On 02/08/2012 12:19, ext Thiago Macieira wrote:
On quinta-feira, 2 de agosto de 2012 17.15.26, marius.storm-ol...@nokia.com
wrote:
So, perhaps we can identify the cases where they are similar and use
that with MSVC until proper noexcept()/noexcept(type) support is provided?
Yes. I can
On 02/08/2012 12:32, ext marius.storm-ol...@nokia.com wrote:
On 02/08/2012 12:19, ext Thiago Macieira wrote:
On quinta-feira, 2 de agosto de 2012 17.15.26, marius.storm-ol...@nokia.com
wrote:
So, perhaps we can identify the cases where they are similar and use
that with MSVC until proper
On quinta-feira, 2 de agosto de 2012 17.32.36, marius.storm-ol...@nokia.com
wrote:
the compiler can eliminate the mechanics of tracking the lifetime of
certain unwindable objects in such a function, and significantly reduce
the code size.
That's in the caller.
The problem is in the callee.
On Thursday 02 August 2012, Thiago Macieira wrote:
On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote:
Where is qHash(QDateTime) defined? It doesn't seem to be where I
expected it (qhash.* or qdatetime.*).
qdatetime.{h,cpp}
Ok, found it - had the wrong branch checked
On quinta-feira, 2 de agosto de 2012 19.25.31, marius.storm-ol...@nokia.com
wrote:
Anyways, I see that LLVM/libc++
(http://llvm.org/svn/llvm-project/libcxx/trunk/include/__config) defines
it like this:
#if (__has_feature(cxx_noexcept))
# define _NOEXCEPT noexcept
# define
On quinta-feira, 2 de agosto de 2012 19.47.46, marius.storm-ol...@nokia.com
wrote:
This tells me that MSVC's implementation of throw() == noexcept(true)
for all intents and purposes, and we can use that in Qt.
Ah, that changes everything. But we can just use __declspec(nothrow) then, to
be on
On Thursday August 2 2012, Konrad Rosenbaum wrote:
On Thursday 02 August 2012, Thiago Macieira wrote:
On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote:
Where is qHash(QDateTime) defined? It doesn't seem to be where I
expected it (qhash.* or qdatetime.*).
Hi Thiago,
On Thursday August 2 2012, Thiago Macieira wrote:
The benefits are:
- callers do not need to emit exception handlers around such functions
- the compiler may assume that no exception unexpectedly happens inside
that function body, foregoing exception handlers inside it as well.
On sexta-feira, 3 de agosto de 2012, às 00.25.04, you wrote:
AFAIU, the compiler needs to make sure that std::terminate is called if an
unexpected exception is thrown, which would require the equivalent of a
function-try-catch block where the catch block calls std::terminate().
Do you have a
On quinta-feira, 2 de agosto de 2012 23.57.58, Marc Mutz wrote:
noexcept(std::declvalObject().f()) should work.
Unfortunately, while the C++11 compiler support seems to be going fine, the
library support is lagging WAY behind. Add to that the fact that some
compilers are being used with
30 matches
Mail list logo
