On 12/06/15 16:59,
development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of
Sean Harmer development-bounces+lars.knoll=theqtcompany@qt-project.org on
behalf of sean.har...@kdab.com wrote:
Thanks for structuring this! Much appreciated.
On Friday 12 June 2015 22:23:09
On 15/06/2015 12:49, Knoll Lars wrote:
On 15/06/15 12:27,
development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of
Simon Hausmann
development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of
simon.hausm...@theqtcompany.com wrote:
On Monday, June 15,
On Monday, June 15, 2015 10:18:38 AM Marc Mutz wrote:
[...]
QtConcurrent
A namespace for functions only, no public classes within.
QTest
A namespace for functions only, no public classes within.
_That_ argument again... :)
Could you explain to me why you think that classes
On 15/06/15 12:27,
development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of
Simon Hausmann development-bounces+lars.knoll=theqtcompany@qt-project.org
on behalf of simon.hausm...@theqtcompany.com wrote:
On Monday, June 15, 2015 10:18:38 AM Marc Mutz wrote:
[...]
On Friday 12. June 2015 14:42:44 Thiago Macieira wrote:
On Friday 12 June 2015 18:58:59 Marc Mutz wrote:
On Friday 12 June 2015 16:37:15 Thiago Macieira wrote:
On Friday 12 June 2015 12:12:17 Olivier Goffart wrote:
Which mean using things like std::function, std::unique_ptr, in our
On Monday 15. June 2015 17:24:39 Marc Mutz wrote:
On Monday 15 June 2015 11:49:40 Olivier Goffart wrote:
On Friday 12. June 2015 14:42:44 Thiago Macieira wrote:
On Friday 12 June 2015 18:58:59 Marc Mutz wrote:
On Friday 12 June 2015 16:37:15 Thiago Macieira wrote:
On Friday 12 June
On Monday 15 June 2015 11:49:40 Olivier Goffart wrote:
On Friday 12. June 2015 14:42:44 Thiago Macieira wrote:
On Friday 12 June 2015 18:58:59 Marc Mutz wrote:
On Friday 12 June 2015 16:37:15 Thiago Macieira wrote:
On Friday 12 June 2015 12:12:17 Olivier Goffart wrote:
Which mean
On Monday 15 June 2015 13:01:04 Sean Harmer wrote:
* The existing syncqt.pl works
syncqt actually has support for namespaces so you could #include NS/Class
but I think it's disabled since it has some bugs and nothing is using it. We
could re-enable it.
Note that the namespace should not be
On Monday 15 June 2015 17:24:39 Marc Mutz wrote:
Qt's binary compatibility is between Qt versions, not between toolchains,
and as such, I don't see a problem saying that if you change the toolchain
(STL (version)), then the BC guarantees are voided. That's just what we
have now already.
I
On Monday 15 June 2015 17:33:35 Thiago Macieira wrote:
On Monday 15 June 2015 17:24:39 Marc Mutz wrote:
Qt's binary compatibility is between Qt versions, not between toolchains,
and as such, I don't see a problem saying that if you change the
toolchain (STL (version)), then the BC
There seem to be two claims floating around:
(a) namespaces help avoiding name clashs
-- and --
(b) namespaces are not more onerous than poor man's prefixes
I see that that both can be true.
I cannot see that both can be true *at the same time*.
Which one can be true depends on the
On Monday 15 June 2015 17:43:58 Olivier Goffart wrote:
On Unix: Clang and GCC build are compatible,
Yes.
C++03/C++11/C++14 builds are
compatible.
No. On C++98, std::list is required to have O(1) splice(), in C++11+, O(1)
size() instead. The two are mutually exclusive, so std::list cannot
On 15.06.2015 08:52, Simon Hausmann wrote:
Perhaps there is a misunderstanding here, so let me confirm also what Joerg
said: At this point we're interested in discussion repository dependencies. I
understand that are somewhat parallel to the qt module dependencies and I
also
understand
On Monday 15 June 2015 21:01:54 André Pönitz wrote:
if so:
Please explain how that avoids name clashes.
You only need to add the prefix when the compiler tells you. E.g. if you use
QtGui::QTransform in one file and Qt3D::QTransform in another, in the same
project, you can write
On Monday 15 June 2015 22:12:46 Marc Mutz wrote:
I disagree. I understand what you said, but right now it is possible to
switch from libstdc++ to libc++ with no ill effects[*]. So the question
is should be asked the other way around: do we knowingly remove this
currently-working ability?
On Monday 15 June 2015 13:03:55 Thiago Macieira wrote:
b) Linux distributions that properly compile libc++ [*]
[*] provided, of course, that the two share their base C++ ABI, which
some
Linux distros have not yet learned to do.
By the way, the list of Linux distributions that properly
On Monday 15. June 2015 21:30:25 Marc Mutz wrote:
On Monday 15 June 2015 17:43:58 Olivier Goffart wrote:
On Unix: Clang and GCC build are compatible,
Yes.
C++03/C++11/C++14 builds are compatible.
No. [... std::list ...]
Yes. I was talking about Qt build, and since Qt does not use the
The file qtbase-opensource-src-5.4.2/lib/fonts/README
states:
'Copyright statements and the source of the qpf fonts are located in
../../src/3rdparty/fonts'
The directory src/3rdparty/fonts does not exist in qtbase-opensource-
src-5.4.2.tar.xz archive.
This directory exists in the 'old'
On Thursday, June 11, 2015 11:49:23 AM Marc Mutz wrote:
On Wednesday 10 June 2015 21:03:32 Stephen Kelly wrote:
I would encourage a discussion of why this module needs namespaces when
the rest of Qt gets by without them. There is certainly a consistency
angle.
I think you come a few
On Friday, June 12, 2015 09:47:44 AM Oswald Buddenhagen wrote:
On Thu, Jun 11, 2015 at 08:30:37PM +, Gladhorn Frederik wrote:
On Thursday 11. June 2015 18.47.40 Oswald Buddenhagen wrote:
you won't get rid of the redundant dependency specifications anyway,
because qt.pro (and the
On Monday 15 June 2015 08:24:22 Simon Hausmann wrote:
QtPatternist
An internal namespace, not reflected in the public API.
QtPatternist::Item appears in public functions of exported public API class
QXmlNodeModelIndex, e.g. Yes, now I see the comment (git grep hid it).
QtConcurrent
A
21 matches
Mail list logo
