Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Wednesday 13. May 2015 09:45:30 Matthew Woehlke wrote: On 2015-04-30 16:04, Matthew Woehlke wrote: On 2015-02-20 14:42, Thiago Macieira wrote: On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote: for (auto const i : qtEnumerate(map)) Maybe it would be nice for Qt to provide one or both of these? Sounds easy enough. Want to give it a try? I *finally* got permission to share this. Sorry it took so long. The attached code, excluding the copyright notices, is hereby placed into the Public Domain. Permission is also granted to use the attached code under either the BSD license, as stated in the files themselves, or pursuant to Kitware's CLA with Qt. It is my hope that this is useful to other people. (Also that the first one finds its way into STL eventually :-), though that's a bit OT for here.) These are both C++11 code. At minimum, they'll need brace-initialization changed to parentheses-initialization in order to build in C++03 mode. However, qtIndexRange also uses trailing return type specification, and I'm not sure it's possible to avoid that without losing type deduction, which sort-of defeats the purpose. There are also lots of elided type specifiers, though those are easy enough to add. Personally, I wouldn't consider it a terrible loss if these were only available in C++11-or-later mode, since they're intended to be used with range-based for. Note that this should also work for foreach: foreach (const auto i, qtEnumerate(map)) I'm not sure if it will or not; it was designed to work in range-based for, i.e. it supplies begin() and end(). I'm not sure if that's enough to automagically work in Q_FOREACH. Thiago, do you want me to take another look at integrating these into Qt proper, or do you have it in hand? Ping? If you want to integrate something to Qt you need to upload the contribution through gerrit. I'm afraid your solution is not working with temporaries containers. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-05-14 10:58, Thiago Macieira wrote: On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote: I'm afraid your solution is not working with temporaries containers. That should be submitted as a change request to the standard. There are a couple of other cases where this bites people. It needs a new paper. Can you (both) please elaborate? That's... interesting. I'm taking a copy of the container and taking iterators from the copy. It seems to me that the RHS expression in a range-based for should most definitely not go out of scope within the for. Is that not the case? (Does range-based for just not work on temporaries at all?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote: I'm afraid your solution is not working with temporaries containers. That should be submitted as a change request to the standard. There are a couple of other cases where this bites people. It needs a new paper. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 14 May 2015 11:34:25 Matthew Woehlke wrote: On 2015-05-14 10:58, Thiago Macieira wrote: On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote: I'm afraid your solution is not working with temporaries containers. That should be submitted as a change request to the standard. There are a couple of other cases where this bites people. It needs a new paper. Can you (both) please elaborate? That's... interesting. I'm taking a copy of the container and taking iterators from the copy. It seems to me that the RHS expression in a range-based for should most definitely not go out of scope within the for. Is that not the case? (Does range-based for just not work on temporaries at all?) for (auto x : function(function2())) If function returns a temporary and function passes through a reference, then it effectively returns a dangling reference. That's because there's a sequencing point shortly before the loop that causes all temporaries to be destroyed. See 6.5.4 [range.stmt] paragraph 1. It has an expansion of what the range for is supposed to do. Note the presence of a semi-colon before the for. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggested addition to wiki.qt.io/Coding_Conventions
On Thursday 14 May 2015 09:33:59 Olivier Goffart wrote:
On Thursday 14. May 2015 08:48:36 Thiago Macieira wrote:
On Thursday 14 May 2015 02:15:54 Marc Mutz wrote:
[...]
The standard doesn't talk about DLLs and SOs. Semantics of those
constructs is supplied by the platform ABI, not std-C++.
Right.
Allow me to disagree!
The standard C++ defines all the semantics of the code unless it defines it
as implementation-defined or undefined behaviour.
The ABI is just an implementation detail and cannot overwrite the C++
standards.
Similar example to DLLs: Multithreading. The C++98 standard didn't talk about
multithreading. So a standards-conforming function could just say
int refCount;
void ref() { ++refCount; }
bool deref() { return --refCount; }
The standard guarantees that ++x turns x into x+1 (assuming no overflow
occurs), and -- turnx x into x-1. It says that int - bool conversion exists
and that the conversion result is (x != 0). So you can prove that in the above
code, deref() return true whenever it has been called as many times as ref()
has been before it (assuming refCount == 0 initially) - the basis of ref-
counting.
Enter MT, and none of the three guarantees above are valid anymore.
You have entered a realm outside std-C++. So you do when using DLLs, too.
C++11 talks about MT, so the above code gets what it deserves when ref() or
deref() are called from more than one thread: UB. Maybe modules will make
comparing addresses of inline functions across DLL boundaries UB.
I don't see a difference between the two examples.
Thanks,
Marc
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggested addition to wiki.qt.io/Coding_Conventions
On Thursday 14 May 2015 02:04:44 Thiago Macieira wrote:
On Thursday 14 May 2015 02:13:59 Marc Mutz wrote:
On Wednesday 13 May 2015 09:30:05 Thiago Macieira wrote:
The drawbacks only appear in debug builds, so is this worth the
uglification?
No, the drawbacks are *due to* MSVC debug builds. They *appear* in
release builds and all platforms, too. Exporting the whole class
restricts what kind
of changes we can make in a BC way. See e.g. QStringRef:
// ### Qt 6: make this constructor constexpr, after the destructor is
made trivial
inline QStringRef():m_string(0), m_position(0), m_size(0){}
// ### Qt 6: remove this copy constructor, the implicit one is fine
inline QStringRef(const QStringRef other)
:m_string(other.m_string), m_position(other.m_position),
m_size(other.m_size)
{}
// ### Qt 6: remove this destructor, the implicit one is fine
inline ~QStringRef(){}
I remember many more situations where this prevented useful changes,
though I'd have to dig deeper to provide details.
None of the three in your example are due to DLL exporting, outside of MSVC
debug builds.
The restriction on removing them right now is because doing so would make
the class trivially copyable or even trivial, which in turn means it's
passed differently (in registers) when passed by value. That has nothing
to do with DLLs and we cannot make trivial what wasn't trivial or
vice-versa.
Interesting. I didn't know that. Please document it on
https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
I guess that means we should revert ab8366b5923ec0feb730df98040885669f7bbe38,
too?
Then again, C++98 doesn't have the concept of trivial types. And QStringRef,
after the proposed changes for Qt 6, still isn't a C++98 POD. Does that mean
that C++11/C++98 builds become binary incompatible?
Thanks,
Marc
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggested addition to wiki.qt.io/Coding_Conventions
On Thursday 14. May 2015 08:48:36 Thiago Macieira wrote: On Thursday 14 May 2015 02:15:54 Marc Mutz wrote: On Wednesday 13 May 2015 23:36:29 Olivier Goffart wrote: On Thursday 14. May 2015 05:57:54 Thiago Macieira wrote: You cannot compare the addresses [of inline methods] This is intentional and if you rely on that, your code is flawed by design. Why not? The C++ standards does not forbid it. It defines that it works. I see no exceptions for inline functions in §5.10 (C++14). We rely on this when connecting using function pointers to inline slot with Qt::UniqueConnection So if the two connect statements are in different library that might fails... The standard doesn't talk about DLLs and SOs. Semantics of those constructs is supplied by the platform ABI, not std-C++. Right. Allow me to disagree! The standard C++ defines all the semantics of the code unless it defines it as implementation-defined or undefined behaviour. The ABI is just an implementation detail and cannot overwrite the C++ standards. For example, the C++ standard says that sizeof(char) is 1, and the ABI cannot say sizeof(char) is 4. Likewise, the C++ standard says that function pointers compare equal if they are both null [or] both point to the same function. The ABI cannot overwrite that and say but not for inline functions My point is that we made that choice when we decided to use -fvisibility- inlines-hidden. Ok, so we took the decision to use a compilation flag that is documented to break the C++ standard. But then we probably should document it as well, no? Try not to take the addresses of inlines and, if you do, don't compare them. But this is not documented. I would not say that someone you compare function pointer to inline function is flawed by design. UniqueConnection does not work for functors anyway, so people should get in the habit of assuming it doesn't work for anything else. This is not an argument. It's like saying square root does not work with negative number so people should get in the habit of assuming it doesn't work for anything else. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggested addition to wiki.qt.io/Coding_Conventions
On Thursday 14 May 2015 09:33:59 Olivier Goffart wrote: The standard C++ defines all the semantics of the code unless it defines it as implementation-defined or undefined behaviour. The ABI is just an implementation detail and cannot overwrite the C++ standards. For example, the C++ standard says that sizeof(char) is 1, and the ABI cannot say sizeof(char) is 4. Likewise, the C++ standard says that function pointers compare equal if they are both null [or] both point to the same function. The ABI cannot overwrite that and say but not for inline functions Correct. According to the standard, that is the case. My point is that we made that choice when we decided to use -fvisibility- inlines-hidden. Ok, so we took the decision to use a compilation flag that is documented to break the C++ standard. But then we probably should document it as well, no? Why? Where does it affect our users? We only do it inside the signal-slot system. All signals are, by construction, non-inline and we've gone through great pains to ensure that their addresses can be compared. The slots are a different matter. First of all, we don't often use UniqueConnection in our code and, when we do, we don't expect users to go and disconnect or reconnect what we've connected. So I don't see how it affects the users and therefore, there's nothing to be documented. Try not to take the addresses of inlines and, if you do, don't compare them. But this is not documented. I would not say that someone you compare function pointer to inline function is flawed by design. No, it's just good programming practice. If you take the address of a function, you force it to exist out-of-line (unless the compiler actually does constant propagation and inlines it through the pointer call).. We don't have to do everything the standard tells us to do. The standard says exceptions are good, we disagree. Another ABI issue is that we need to force the virtual tables to be anchored in a single library, which means all polymorphic classes must have at least one non-inline virtual member. The standard doesn't require that, but it's a good idea to so it. UniqueConnection does not work for functors anyway, so people should get in the habit of assuming it doesn't work for anything else. This is not an argument. It's like saying square root does not work with negative number so people should get in the habit of assuming it doesn't work for anything else. Well, they should if they don't control the input range. If you wrote code that depended on the result of sqrt() but didn't ensure that the input was non-negative, you'd eventually run into problems. Given that people use lambdas and functors (like std::bind, std::function, etc.) quite often, they need to learn that UniqueConnection won't work for them in all cases. Better simply not rely on the feature. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Multimedia and GStreamer 1.0 status
Lisandro Damián Nicanor Pérez Meyer wrote: Hi! GStreamer 0.1 will get removed from Debian unstable soon. Is there any chance to have GStreamer 1.0 support in 5.5.0? qtmultimedia 5.5 branch supports gst-1.x -- rex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
