Re: [Development] Naming convention for (scoped) enums

[Christian Kandeler]

On Thu, 17 May 2018 08:14:15 +
Alex Blasche  wrote:

> The naming conventions for enums state that each enum value name must repeat 
> a part of the enum Type name (for details see 
> https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values)
> 
> In case of scoped enums this becomes a superfluous rule as the type has to be 
> mentioned anyway. Does anybody object to modifying the above definition by 
> adding an exception for scoped enums where you do not have to repeat a part 
> of the enum type name?

I would not have even assumed that the rule applies to scoped enums, but it 
can't hurt to write it down explicitly. Perhaps the section should be rewritten 
so that the unscoped enums are the special case rather than the other way 
around.


Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Naming convention for (scoped) enums

[Tor Arne Vestbø]

> On 17 May 2018, at 10:14, Alex Blasche  wrote:
> 
> Hi,
> 
> The naming conventions for enums state that each enum value name must repeat 
> a part of the enum Type name (for details see 
> https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values)
> 
> In case of scoped enums this becomes a superfluous rule as the type has to be 
> mentioned anyway. Does anybody object to modifying the above definition by 
> adding an exception for scoped enums where you do not have to repeat a part 
> of the enum type name?

Sounds like a sensible thing +1

Tor Arne 




> --
> Alex
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Naming convention for (scoped) enums

[Giuseppe D'Angelo]

Il 17/05/2018 10:14, Alex Blasche ha scritto:

In case of scoped enums this becomes a superfluous rule as the type has to be 
mentioned anyway. Does anybody object to modifying the above definition by 
adding an exception for scoped enums where you do not have to repeat a part of 
the enum type name?


I approve of the change. In Qt 5.11 we've already started introducing 
enum classes that do not repeat the enumeration name in the enumerators 
(e.g. QAbstractItemModel::CheckIndexOption). I would also double-down 
and say that every new enumeration in Qt has to be an enum class.


My 2 cents,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Mårten Nordheim as an approver

[Alex Blasche]

Congratulations to Mårten. The rights have been adjusted.

--
Alex


From: Development  
on behalf of Edward Welbourne 
Sent: Wednesday, 25 April 2018 1:40:41 PM
To: development@qt-project.org
Subject: [Development] Nominating Mårten Nordheim as an approver

Hi all,

I'd like to nominate Mårten Nordheim for Approver.

We've had him here at TQtC, in the Core & Network team, for a bit over a
year; he's been reviewing steadily and finding mistakes I miss.  As well
as diverse work in qtbase, he's also dabbled in the qtnetworkauth and
qtwebsockets modules.  Here's his list of changes in gerrit:

https://codereview.qt-project.org/#/q/owner:"M%25C3%25A5rten+Nordheim",n,z

and the (somewhat busier) list of what he's reviewed:

https://codereview.qt-project.org/#/q/reviewer:"M%25C3%25A5rten+Nordheim",n,z

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Naming convention for (scoped) enums

[Alex Blasche]

Hi,

The naming conventions for enums state that each enum value name must repeat a 
part of the enum Type name (for details see 
https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values)

In case of scoped enums this becomes a superfluous rule as the type has to be 
mentioned anyway. Does anybody object to modifying the above definition by 
adding an exception for scoped enums where you do not have to repeat a part of 
the enum type name?

--
Alex
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Code contributions via bug reports and forum posts

[Tuukka Turunen]

On 16/05/2018, 19.07, "Development on behalf of Thiago Macieira" 
 wrote:
>
>   To all users: please continue submitting contributions through the 
>contribution system as much as you can. Submitting patches via the bug 
>reporting tool may not work if the assignee or maintainer in question does 
> not 
>work for the Qt Company and there's no one who does that is willing to 
> accept 
>the responsibility of submitting it on your behalf.

Yes, absolutely. We should not reduce normal codereview use. For any of these 
"casual contributions", someone needs to do the work to get the patch in via 
codereview (and in most cases also do some changes to the patch as well). 
Intention is not do regular contributions in this way, just to allow similar 
approach for all users as has been the case for commercial license holders 
since ages. 

Yours,

Tuukka

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Urgent help needed: determining endianness at compile time in INTEGRITY

[Kimmo Ollila]

> So they are defined but not required to be equal to something?
Yup, that's right

Regards,
Kimmo Ollila

-Original Message-
From: Development  On 
Behalf Of Thiago Macieira
Sent: torstaina 17. toukokuuta 2018 9.47
To: development@qt-project.org
Subject: Re: [Development] Urgent help needed: determining endianness at 
compile time in INTEGRITY

On Wednesday, 16 May 2018 23:26:27 PDT Kimmo Ollila wrote:
> Endianness Macros
> One of these symbols is always defined to specify the endianness of 
> the target processor.
> 
> __BIG_ENDIAN__
> Big Endian byte order.
> 
> __LITTLE_ENDIAN__
> Little Endian byte order.

So they are defined but not required to be equal to something?

Ok, will change the change.

--
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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Urgent help needed: determining endianness at compile time in INTEGRITY

[Thiago Macieira]

On Wednesday, 16 May 2018 23:26:27 PDT Kimmo Ollila wrote:
> Endianness Macros
> One of these symbols is always defined to specify the endianness of the
> target processor.
> 
> __BIG_ENDIAN__
> Big Endian byte order.
> 
> __LITTLE_ENDIAN__
> Little Endian byte order.

So they are defined but not required to be equal to something?

Ok, will change the change.

-- 
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] Urgent help needed: determining endianness at compile time in INTEGRITY

[Kimmo Ollila]

Hi,

>From INTEGRITY documentation I found the following macros:

Endianness Macros
One of these symbols is always defined to specify the endianness of the target 
processor.

__BIG_ENDIAN__
Big Endian byte order.

__LITTLE_ENDIAN__
Little Endian byte order.

I tested and these are working.

Best regards,
Kimmo Ollila

-Original Message-
From: Development  On 
Behalf Of Thiago Macieira
Sent: keskiviikkona 16. toukokuuta 2018 19.19
To: development@qt-project.org
Subject: [Development] Urgent help needed: determining endianness at compile 
time in INTEGRITY

We've got a change blocked because some third-party code is unable to find a 
macro that determines the endianness of the target while compiling with GHS's 
compiler for INTEGRITY.

Can someone help? Any of the following would help:

(a) documentation link stating what macro is set

(b) a simple test program in C that shows how to determine the endianness at 
compile time

(c) a function that does 64-bit host-to-network and back conversions on 
INTEGRITY

(d) an actual patch to TinyCBOR - https://github.com/intel/tinycbor (file
src/compilersupport_p.h)

Please note that Qt doesn't seem to have a problem -- qprocessordetection.h has 
an #error and it's not triggering. So it would seem Qt has a solution. I have 
not looked at the code because I need to submit to the third-party and I need 
therefore MIT-licensed solutions. A Qt Company employee could open 
qprocessordetection.h and determine how it makes this work -- the only other 
copyright holder of relevance in that file is Intel.

For reference, TinyCBOR already tries these tests:
__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
__BYTE_ORDER == __BIG_ENDIAN
BYTE_ORDER == BIG_ENDIAN
defined(__ARMEB__) || defined(__MIPSEB__) || defined(__sparc__)

__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
__BYTE_ORDER == __LITTLE_ENDIAN
BYTE_ORDER == LITTLE_ENDIAN
defined(__ARMEL__) || defined(__i386) || defined(__i386__) || 
defined(__x86_64) || defined(__x86_64__) || \
defined(__amd64) || defined(__MIPSEL__)

It's possible it's one of those and there's something else wrong. I don't have 
access to the toolchain and therefore can't test to see what it is.
--
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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development