On Tuesday, 14 April 2020 20:54:57 -03 Nathan Myers wrote:
> I see that you are confused about the origins of Posix
> and Unix networking practices, as well as WG21's. ISO
> WG21 was convened in 1990. The ntohs etc. macros precede
> 1990. Qt does not.
Yes, it does. The first release was in 1994, b
On 4/14/20 5:28 AM, Lars Knoll wrote:
On 14 Apr 2020, at 10:17, Nathan Myers
mailto:n...@cantrip.org>> wrote:
On 4/13/20 3:41 PM, Ville Voutilainen wrote:
It also doesn't require smoking crack to suggest that
WG21 considers code breakage due to new identifiers
clashing with existing macros;
14.04.2020, 22:18, "Ville Voutilainen" :
> On Tue, 14 Apr 2020 at 12:31, Lars Knoll wrote:
>> What kind of argument is that? htons as a macro was worth considering, but
>> the ones in Qt are not?
>>
>> Fixing the htons macro also "only requires changing one place" in the
>> System C library.
On Tue, 14 Apr 2020 at 11:22, Nathan Myers wrote:
> Neither does Ville have authority to speak on behalf of
> the Library Evolution Working Group.
The slight difference, of course, is that I enumerated bits of
rationale that were actually uttered in that
discussion, rather than colorful suggestio
On Tue, 14 Apr 2020 at 12:31, Lars Knoll wrote:
> What kind of argument is that? htons as a macro was worth considering, but
> the ones in Qt are not?
>
> Fixing the htons macro also "only requires changing one place" in the System
> C library. You are forgetting, that both changes break a huge
On 14 Apr 2020, at 17:02, Matthew Woehlke
mailto:mwoehlke.fl...@gmail.com>> wrote:
On 14/04/2020 05.28, Lars Knoll wrote:
I believe there is mostly a consensus here to find a way to get rid
of those macros. But many of our users do seem to like the ‘emit’
keyword as an annotation to a signal emis
On 14/04/2020 05.28, Lars Knoll wrote:
I believe there is mostly a consensus here to find a way to get rid
of those macros. But many of our users do seem to like the ‘emit’
keyword as an annotation to a signal emission, and it is being used
extensively in existing code bases.
You know what woul
On 4/14/20 11:30 AM, Allan Sandfeld Jensen wrote:
> No, any GUI-related API requires QGuiApplication, and any widget-related
> API QApplication.
>
In theory, but see https://codereview.qt-project.org/c/qt/qtbase/+/47846
I would stick to the documented contract, without any fancy ad-hoc
On Dienstag, 14. April 2020 02:08:22 CEST Giuseppe D'Angelo via Development
wrote:
> Hi,
>
> On 4/14/20 1:34 AM, Konstantin Tokarev wrote:
> >> The golden rule is that you're not allowed to touch any Qt API without
> >> creating a Q*Application object first, unless the documentation says
> >> oth
On 14 Apr 2020, at 10:17, Nathan Myers
mailto:n...@cantrip.org>> wrote:
On 4/13/20 3:41 PM, Ville Voutilainen wrote:
On Mon, 13 Apr 2020 at 06:11, Nathan Myers
mailto:n...@cantrip.org>> wrote:
The prevailing feeling in the room, when the vote was taken,
was that Qt people MUST BE SMOKING C
On 4/13/20 3:41 PM, Ville Voutilainen wrote:
On Mon, 13 Apr 2020 at 06:11, Nathan Myers wrote:
The prevailing feeling in the room, when the vote was taken,
was that Qt people MUST BE SMOKING CRACK if they think
the ISO 14882 C++ Standard should or would tiptoe around Qt's
aggressive abuse
11 matches
Mail list logo
