Re: [Interest] Interest Digest, Vol 92, Issue 8

2019-05-07 Thread Roland Hughes


On 5/7/2019 12:14 PM, Thiago Macieira wrote:

On Tuesday, 7 May 2019 05:13:33 PDT Ola Røer Thorsen wrote:

lør. 4. mai 2019 kl. 17:51 skrev Thiago Macieira 
No, the size of something definitely fits in int on 32-bit systems. And
why do
you need to do any static_cast in the first place?

We build our code using gcc with the options "-Wall -Wextra -Werror" and
this leads us to have to use static_cast for example when comparing int and
unsigned int (or std::size_t). A mix of using std::array, std::string and
QVector/QByteArray often gives a few extra static casts, not that it
bothers me too much.

Well, that's your problem: mixing the APIs. The committee has recognised that
it should have used signed types, but it can't change now.

If there's ever an STL2 (std2 namespace), it'll use signed.


It's not just mixing C++ APIs. It is interfacing with devices which use 
unsigned octates in groups for the size followed by a contiguous block 
of octates for the data. When they accept text input it has to be sent 
this way and when they communicate text responses it comes back this way.


There are also the big data blocks like X-RAY/MRI images and such which 
need to be loaded into larger than signed int containers for manipulation.


I haven't dug under the hood but I wonder if this impacts memory mapping of 
files. Maybe not if there is no container.

uchar * dl_map = m_libraryFile.map(0, m_libraryFile.size());


developer@developer-U18-64-VirtualBox:~$ ./test_sizes
short int: 2
  int: 4
 long int: 8
long long int: 8
   size_t: 8
void*: 8
 unsigned int: 4
 uint32_t: 4
 uint64_t: 8
   void *: 8
unsigned long: 8
 uint32_t max: 4294967295
 uint max: 4294967295
 uint64_t max: 18446744073709551615

developer@developer-U18-64-VirtualBox:~$ cat test_sizes.c
#include 
#include 
#include 

int main() {
printf( "short int: %zd\n" , sizeof(short int) ) ;
printf( "  int: %zd\n" , sizeof(int) ) ;
printf( " long int: %zd\n", sizeof(long int) ) ;

printf( "long long int: %zd\n", sizeof(long long int) ) ;
printf( "   size_t: %zd\n", sizeof(size_t) ) ;
printf( "void*: %zd\n", sizeof(void *) ) ;
printf( " unsigned int: %zd\n", sizeof(unsigned int));
printf( " uint32_t: %zd\n", sizeof(uint32_t));
printf( " uint64_t: %zd\n", sizeof(uint64_t));
printf( "   void *: %zd\n", sizeof(void *));

printf( "unsigned long: %zd\n", sizeof(unsigned long) );

printf( " uint32_t max: %u\n", UINT32_MAX);
printf( " uint max: %u\n", UINT_MAX);
printf( " uint64_t max: %lu\n", UINT64_MAX);

return 0;
}developer@developer-U18-64-VirtualBox:~$
=
developer@developer-U18-64-VirtualBox:~$ lscpu
Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
 
=


The ptrdiff_t comment earlier is a red herring.

https://en.cppreference.com/w/cpp/types/ptrdiff_t

typedef /*implementation-defined*/ ptrdiff_t;

=

The static cast issue is a problem in the embedded device world. Well, 
it is an annoyance in the embedded device world. It's a documentation 
and defending your honor nightmare in regulated device world such as 
medical devices. Probably nuke systems as well.


Some shops won't or cannot let you use an int.

If they are changing from int to q-whatever defined type there will 
probably be some compilation cleanup anyway so unsigned wouldn't be bad 
unless someone is cheating somewhere and initializing size to -1



--
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread André Pönitz
On Tue, May 07, 2019 at 05:49:03PM +0300, Konstantin Tokarev wrote:
> >
> > (Honorable mention: QStringView is 64-bit ready.)
> 
> You were asking when static_casts between int and size_t are needed.
> Interfacing Qt-based code with Standard Library types is one of such cases.

C++20 and std::ssize(std::container) to the rescue.

Andre' 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Qt 5.13 QtWebEngine GN Error

2019-05-07 Thread Oliver Niebuhr
Hello Kirill.

Interesting. I probably will not be able to Test this before the next
weekend but I pinned it in my Browser :)

Thank you!
Oliver

On 07/05/2019 19:45, Kirill Burtsev wrote:
> Hello Oliver,
> 
> for me it compiles fine with this
> fix: https://codereview.qt-project.org/#/c/260969/
> 
> *From:* Interest  on behalf of Oliver
> Niebuhr 
> *Sent:* Sunday, May 5, 2019 14:04
> *To:* interest@qt-project.org
> *Subject:* Re: [Interest] Qt 5.13 QtWebEngine GN Error
>  
> I installed all the VS 2017 Stuff (v141 Compiler Toolset, v141 ATL and
> MFC) under VS 2019 and I still get the same Error! There is another 5.12
> to 5.13 Forward Merge in the works - when this has happened, I will test
> again and create a Bug Report if it still occurs.
> 
> Thanks
> Olli
> 
> 
> On 05/05/2019 11:01, Oliver Niebuhr wrote:
>> Alright, here is the File that Errors out:
>> 
>> "[23070/26025] ninja -t msvc -e environment.x64 -- "C:\Program Files
>> (x86)\Microsoft Visual
>> Studio\2019\Community\VC\Tools\MSVC\14.20.27508\bin\HostX64\x64/cl.exe"
>> /nologo /showIncludes  -DUSE_AURA=1 -DNO_TCMALLOC -DOFFICIAL_BUILD
>> -DCHROMIUM_BUILD -DTOOLKIT_QT -D_HAS_EXCEPTIONS=0 -D__STD_C
>> -D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE
>> -D_ATL_NO_OPENGL -D_WINDOWS -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS
>> -DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL -D_USING_V110_SDK71_
>> -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -DWIN32_LEAN_AND_MEAN
>> -DNOMINMAX -D_UNICODE -DUNICODE -DNTDDI_VERSION=0x0A02
>> -D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00 -DNDEBUG -DNVALGRIND
>> -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DBLINK_CORE_IMPLEMENTATION=1
>> -DWEBP_EXTERN=extern -DUSE_EGL -DBLINK_IMPLEMENTATION=1 -DINSIDE_BLINK
>> -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DWEBRTC_CHROMIUM_BUILD
>> -DWEBRTC_WIN -DABSL_ALLOCATOR_NOTHROW=1 -DNO_MAIN_THREAD_WRAPPING
>> -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DUSE_CHROMIUM_ICU=1
>> -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE
>> -DUCHAR_TYPE=wchar_t -DGOOGLE_PROTOBUF_NO_RTTI
>> -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DSK_HAS_PNG_LIBRARY
>> -DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY -DSK_SUPPORT_GPU=1
>> "-DSK_GPU_WORKAROUNDS_HEADER=\"gpu/config/gpu_driver_bug_workaround_autogen.h\""
>> -DGR_GL_FUNCTION_TYPE=__stdcall -DV8_DEPRECATION_WARNINGS
>> -DLEVELDB_PLATFORM_CHROMIUM=1 -DDeleteFile=DeleteFileW
>> -DLEVELDB_PLATFORM_CHROMIUM=1 -DWTF_USE_WEBAUDIO_FFMPEG=1
>> -DSUPPORT_WEBGL2_COMPUTE_CONTEXT=1 -DWTF_USE_DEFAULT_RENDER_THEME=1
>> -DUSE_LIBJPEG_TURBO=1 -DV8_DEPRECATION_WARNINGS -DLIBXSLT_STATIC -Igen
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/libyuv/include
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/libwebp/src
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/wtl/include
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/khronos
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/gpu
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/webrtc_overrides
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/webrtc
>> -Igen/third_party/webrtc
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/abseil-cpp
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/ced/src
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/icu/source/common
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/icu/source/i18n
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src
>> -Igen/protoc_out
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/boringssl/src/include
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/skia/config
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/skia/ext
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/c
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/config
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/core
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/docs
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/effects
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/encode
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/gpu
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/pathops
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/ports
>> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chrom

Re: [Interest] Qt 5.13 QtWebEngine GN Error

2019-05-07 Thread Kirill Burtsev
Hello Oliver,

for me it compiles fine with this fix: 
https://codereview.qt-project.org/#/c/260969/

From: Interest  on behalf of Oliver Niebuhr 

Sent: Sunday, May 5, 2019 14:04
To: interest@qt-project.org
Subject: Re: [Interest] Qt 5.13 QtWebEngine GN Error

I installed all the VS 2017 Stuff (v141 Compiler Toolset, v141 ATL and
MFC) under VS 2019 and I still get the same Error! There is another 5.12
to 5.13 Forward Merge in the works - when this has happened, I will test
again and create a Bug Report if it still occurs.

Thanks
Olli


On 05/05/2019 11:01, Oliver Niebuhr wrote:
> Alright, here is the File that Errors out:
>
> "[23070/26025] ninja -t msvc -e environment.x64 -- "C:\Program Files
> (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.20.27508\bin\HostX64\x64/cl.exe"
> /nologo /showIncludes  -DUSE_AURA=1 -DNO_TCMALLOC -DOFFICIAL_BUILD
> -DCHROMIUM_BUILD -DTOOLKIT_QT -D_HAS_EXCEPTIONS=0 -D__STD_C
> -D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE
> -D_ATL_NO_OPENGL -D_WINDOWS -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS
> -DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL -D_USING_V110_SDK71_
> -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -DWIN32_LEAN_AND_MEAN
> -DNOMINMAX -D_UNICODE -DUNICODE -DNTDDI_VERSION=0x0A02
> -D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00 -DNDEBUG -DNVALGRIND
> -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DBLINK_CORE_IMPLEMENTATION=1
> -DWEBP_EXTERN=extern -DUSE_EGL -DBLINK_IMPLEMENTATION=1 -DINSIDE_BLINK
> -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DWEBRTC_CHROMIUM_BUILD
> -DWEBRTC_WIN -DABSL_ALLOCATOR_NOTHROW=1 -DNO_MAIN_THREAD_WRAPPING
> -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DUSE_CHROMIUM_ICU=1
> -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE
> -DUCHAR_TYPE=wchar_t -DGOOGLE_PROTOBUF_NO_RTTI
> -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DSK_HAS_PNG_LIBRARY
> -DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY -DSK_SUPPORT_GPU=1
> "-DSK_GPU_WORKAROUNDS_HEADER=\"gpu/config/gpu_driver_bug_workaround_autogen.h\""
> -DGR_GL_FUNCTION_TYPE=__stdcall -DV8_DEPRECATION_WARNINGS
> -DLEVELDB_PLATFORM_CHROMIUM=1 -DDeleteFile=DeleteFileW
> -DLEVELDB_PLATFORM_CHROMIUM=1 -DWTF_USE_WEBAUDIO_FFMPEG=1
> -DSUPPORT_WEBGL2_COMPUTE_CONTEXT=1 -DWTF_USE_DEFAULT_RENDER_THEME=1
> -DUSE_LIBJPEG_TURBO=1 -DV8_DEPRECATION_WARNINGS -DLIBXSLT_STATIC -Igen
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/libyuv/include
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/libwebp/src
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/wtl/include
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/khronos
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/gpu
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/webrtc_overrides
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/webrtc
> -Igen/third_party/webrtc
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/abseil-cpp
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/ced/src
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/icu/source/common
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/icu/source/i18n
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src
> -Igen/protoc_out
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/boringssl/src/include
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/skia/config
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/skia/ext
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/c
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/config
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/core
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/docs
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/effects
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/encode
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/gpu
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/pathops
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/ports
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/utils
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/include/codec
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/src/gpu
> -I../../../../../q5s/qt5/qtwebengine/src/3rdparty/chromium/third_party/skia/src/sksl
> -I../../../../../q5s/qt5/qtwebengi

Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Bernhard Lindner

> You were asking when static_casts between int and size_t are needed.
> Interfacing Qt-based code with Standard Library types is one of such cases.

Yes, and it is a nightmare.
But this has been discussed in a different thread before.

-- 
Best Regards, 
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Thiago Macieira
On Tuesday, 7 May 2019 07:42:45 PDT Giuseppe D'Angelo via Interest wrote:
> > It is still discussed? I thought it is pretty high at the priority list
> > anyway.
> No such patch has landed, and the discussion on the mailing list
> stopped. I'm just guessing it's going to be one of the major points of
> debate during the container changes expected for Qt 6. It needs some
> serious experiment on some big code base.

It's considered a concluded discussion: we want qsizetype.

The problem is actually making it happen.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Thiago Macieira
On Tuesday, 7 May 2019 05:13:33 PDT Ola Røer Thorsen wrote:
> lør. 4. mai 2019 kl. 17:51 skrev Thiago Macieira  
> > No, the size of something definitely fits in int on 32-bit systems. And
> > why do
> > you need to do any static_cast in the first place?
> 
> We build our code using gcc with the options "-Wall -Wextra -Werror" and
> this leads us to have to use static_cast for example when comparing int and
> unsigned int (or std::size_t). A mix of using std::array, std::string and
> QVector/QByteArray often gives a few extra static casts, not that it
> bothers me too much.

Well, that's your problem: mixing the APIs. The committee has recognised that 
it should have used signed types, but it can't change now.

If there's ever an STL2 (std2 namespace), it'll use signed.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Giuseppe D'Angelo via Interest

Hi,

Il 07/05/19 16:08, Ola Røer Thorsen ha scritto:

QByteArray bytes; // chosen because some api needs it later
std::vector other_bytes; // maybe returned from some 3rd party library
...
if (static_cast(bytes.size()) >= other_bytes.size()) {
     ...
}

I guess i could write stuff like

const std::size_t byteSize = bytes.size();
if (byteSize >= other_bytes.size())

but then I rather prefer static_cast. Note that I'm not saying we should 
change everything in Qt to unsigned int, I think that might break a lot 
of existing application code out there. Just saying that sometimes a 
static_cast is needed.


I see, and it's indeed mostly annoying. Again, out of curiosity, is the 
API forcing you to use a QByteArray coming from Qt itself?


Thanks,
--
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
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Giuseppe D'Angelo via Interest

Il 07/05/19 17:02, Jason H ha scritto:

Given how often I miss indexing negatives (to index from the end) It seems that 
we could do this in Qt6?
/me ducks


Note that you can (today!) use a range::view::reverse and pass positive 
indexes, counting backwards from the end. Adding this specific feature 
to QVector::operator[] won't be exactly welcomed (it'll add a branch 
inside inside of it).


My 2 c,

--
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
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Jason H


> Sent: Tuesday, May 07, 2019 at 9:31 AM
> From: "Giuseppe D'Angelo via Interest" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Operator QMap[] is casting to int?
>
> On 07/05/2019 14:42, Jason H wrote:
> >> Those will likely change to qsizetype in Qt 6. Which is still signed.
> >
> > This is disappointing. I'll only get half of the indexable space... can I 
> > get something in return? Having a negative index mechanism, like in Python, 
> > would be a way to alleviate some of the pain. Otherwise can you explain the 
> > rationale for not using signed?
>
> I guess you meant "not using unsigned" here?
>
>
> Half of the memory space is the theoretical maximum you get anyhow, no
> matter the signedness of the index, right?
>
> (You need to be able to take the pointer difference between any two
> positions in an array (including the one-past-the-end). Given that
> ptrdiff_t is the same size of a pointer, and has to be signed, that
> means that the biggest contiguous block of memory you can index is half
> of the address space. What am I not seeing?)

Ah, that's probably what I'm missing.

Given how often I miss indexing negatives (to index from the end) It seems that 
we could do this in Qt6?
/me ducks

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Konstantin Tokarev


07.05.2019, 17:45, "Giuseppe D'Angelo via Interest" :
> On 07/05/2019 16:11, Bernhard Lindner wrote:
>>>  1) the the change to qsizetype as an index type has not
>>>  happened yet, anyhow. It's still a huge question if it's doable in the
>>>  first place.
>>  It is still discussed? I thought it is pretty high at the priority list 
>> anyway.
>
> No such patch has landed, and the discussion on the mailing list
> stopped. I'm just guessing it's going to be one of the major points of
> debate during the container changes expected for Qt 6. It needs some
> serious experiment on some big code base.
>
> Disclaimer: I'm against this change, presented like that, on source
> compatibility reasons. If we can somehow get 100% SC, then I am totally
> in favour of it.
>
>>  I mean, if you don't do that in 2020 (Qt6), when will you do it? You can't 
>> do it in a
>>  minor release, can you?
>>
>>  x64 is standard in many applications and memory sizes are growing. I have 
>> seen to many
>>  platforms/frameworks die an early death because developers where afraid to 
>> enforce
>>  fundamental architectural fixes/improvements (including evolving 
>> language)... until it was
>>  too late.
>
> The hard answer would be: never.
>
> If you need a 64-bit ready byte
> array/vector/map/hash/list/deque/stack/..., the Standard Library has
> been providing them for a very long time now. Qt should make the
> transition towards them easier. The reason why I'm still in favour of
> the change above is getting a 64-bit QString, whose equivalent simply
> does not exist in the Standard Library yet.
>
> (Honorable mention: QStringView is 64-bit ready.)

You were asking when static_casts between int and size_t are needed.
Interfacing Qt-based code with Standard Library types is one of such cases.

-- 
Regards,
Konstantin

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Giuseppe D'Angelo via Interest

On 07/05/2019 16:11, Bernhard Lindner wrote:

1) the the change to qsizetype as an index type has not
happened yet, anyhow. It's still a huge question if it's doable in the
first place.

It is still discussed? I thought it is pretty high at the priority list anyway.


No such patch has landed, and the discussion on the mailing list 
stopped. I'm just guessing it's going to be one of the major points of 
debate during the container changes expected for Qt 6. It needs some 
serious experiment on some big code base.


Disclaimer: I'm against this change, presented like that, on source 
compatibility reasons. If we can somehow get 100% SC, then I am totally 
in favour of it.




I mean, if you don't do that in 2020 (Qt6), when will you do it? You can't do 
it in a
minor release, can you?

x64 is standard in many applications and memory sizes are growing. I have seen 
to many
platforms/frameworks die an early death because developers where afraid to 
enforce
fundamental architectural fixes/improvements (including evolving language)... 
until it was
too late.


The hard answer would be: never.

If you need a 64-bit ready byte 
array/vector/map/hash/list/deque/stack/..., the Standard Library has 
been providing them for a very long time now. Qt should make the 
transition towards them easier.  The reason why I'm still in favour of 
the change above is getting a 64-bit QString, whose equivalent simply 
does not exist in the Standard Library yet.


(Honorable mention: QStringView is 64-bit ready.)

My 2 c,
--
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: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Ola Røer Thorsen
> Could you make an example where the casts are needed? Maybe the code can
> be rearranged in a way that the casts are NOT needed in the first place.
>
>
QByteArray bytes; // chosen because some api needs it later
std::vector other_bytes; // maybe returned from some 3rd party library
...
if (static_cast(bytes.size()) >= other_bytes.size()) {
...
}

I guess i could write stuff like

const std::size_t byteSize = bytes.size();
if (byteSize >= other_bytes.size())

but then I rather prefer static_cast. Note that I'm not saying we should
change everything in Qt to unsigned int, I think that might break a lot of
existing application code out there. Just saying that sometimes a
static_cast is needed.

Cheers,
Ola
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Bernhard Lindner

> 1) the the change to qsizetype as an index type has not 
> happened yet, anyhow. It's still a huge question if it's doable in the 
> first place.

It is still discussed? I thought it is pretty high at the priority list anyway.

I mean, if you don't do that in 2020 (Qt6), when will you do it? You can't do 
it in a
minor release, can you? 

x64 is standard in many applications and memory sizes are growing. I have seen 
to many
platforms/frameworks die an early death because developers where afraid to 
enforce
fundamental architectural fixes/improvements (including evolving language)... 
until it was
too late.

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Giuseppe D'Angelo via Interest

On 07/05/2019 14:13, Ola Røer Thorsen wrote:
We build our code using gcc with the options "-Wall -Wextra -Werror" and 
this leads us to have to use static_cast for example when comparing int 
and unsigned int (or std::size_t). A mix of using std::array, 
std::string and QVector/QByteArray often gives a few extra static casts, 
not that it bothers me too much.


Could you make an example where the casts are needed? Maybe the code can 
be rearranged in a way that the casts are NOT needed in the first place.


Cheers,
--
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: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Giuseppe D'Angelo via Interest

On 07/05/2019 14:42, Jason H wrote:

Those will likely change to qsizetype in Qt 6. Which is still signed.


This is disappointing. I'll only get half of the indexable space... can I get 
something in return? Having a negative index mechanism, like in Python, would 
be a way to alleviate some of the pain. Otherwise can you explain the rationale 
for not using signed?


I guess you meant "not using unsigned" here?


Half of the memory space is the theoretical maximum you get anyhow, no 
matter the signedness of the index, right?


(You need to be able to take the pointer difference between any two 
positions in an array (including the one-past-the-end). Given that 
ptrdiff_t is the same size of a pointer, and has to be signed, that 
means that the biggest contiguous block of memory you can index is half 
of the address space. What am I not seeing?)



About the rationale of using signed indices, see the link earlier in the 
thread to the previous discussion.



Side notes: 1) the the change to qsizetype as an index type has not 
happened yet, anyhow. It's still a huge question if it's doable in the 
first place.


2) if you need containers bigger than 2^31 elements (assuming QVector 
gets fixed) then you can use the STL containers _today_.


3) there's only a handful of Qt APIs that take/return Qt containers. A 
goal for the Qt 5/6 transition would be make them container-agnostic 
(e.g. using output iterators), so not to tie anyone to use Qt containers.


--
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: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Jason H


> Sent: Tuesday, May 07, 2019 at 8:44 AM
> From: "Christian Gagneraud" 
> To: "Ola Røer Thorsen" 
> Cc: "interestqt-project.org" 
> Subject: Re: [Interest] Operator QMap[] is casting to int?
>
> On Wed, 8 May 2019 at 00:14, Ola Røer Thorsen  wrote:
> >
> >
> > lør. 4. mai 2019 kl. 17:51 skrev Thiago Macieira 
> > :
> >>
> >> No, the size of something definitely fits in int on 32-bit systems. And 
> >> why do
> >> you need to do any static_cast in the first place?
> >
> >
> > We build our code using gcc with the options "-Wall -Wextra -Werror" and 
> > this leads us to have to use static_cast for example when comparing int and 
> > unsigned int (or std::size_t). A mix of using std::array, std::string and 
> > QVector/QByteArray often gives a few extra static casts, not that it 
> > bothers me too much.
> 
> Same here, with the added pain of compiling qt with qreal=float for
> arm-linux and qt=double for x86-linux/windows

IIRC, there was [fairly] recently  a discussion on the Qt development list 
about that... Might want to check the archives.


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Jason H


> Sent: Saturday, May 04, 2019 at 11:48 AM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Operator QMap[] is casting to int?
>
> On Saturday, 4 May 2019 05:12:08 PDT Roland Hughes wrote:
> > On 5/4/19 5:00 AM, interest-requ...@qt-project.org wrote:
> > >> Unless Qt supports negative indexes (like python's [-1]) I would have
> > >> thought this would be an int. Thanks for catching that everyone.
> > >
> > > I'm assuming you made a typo there and meant to say "uint"? Regardless
> > > here's the official reason why Qt uses "int" for container indices:
> > > https://lists.qt-project.org/pipermail/interest/2013-September/008592.html
> >
> > There are an awful lot of places where Qt uses int when it should be
> > uint like when returning the size() of something.
>
> Those will likely change to qsizetype in Qt 6. Which is still signed.


This is disappointing. I'll only get half of the indexable space... can I get 
something in return? Having a negative index mechanism, like in Python, would 
be a way to alleviate some of the pain. Otherwise can you explain the rationale 
for not using signed?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Christian Gagneraud
On Wed, 8 May 2019 at 00:14, Ola Røer Thorsen  wrote:
>
>
> lør. 4. mai 2019 kl. 17:51 skrev Thiago Macieira :
>>
>> No, the size of something definitely fits in int on 32-bit systems. And why 
>> do
>> you need to do any static_cast in the first place?
>
>
> We build our code using gcc with the options "-Wall -Wextra -Werror" and this 
> leads us to have to use static_cast for example when comparing int and 
> unsigned int (or std::size_t). A mix of using std::array, std::string and 
> QVector/QByteArray often gives a few extra static casts, not that it bothers 
> me too much.

Same here, with the added pain of compiling qt with qreal=float for
arm-linux and qt=double for x86-linux/windows

Chris
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Ola Røer Thorsen
lør. 4. mai 2019 kl. 17:51 skrev Thiago Macieira :

> No, the size of something definitely fits in int on 32-bit systems. And
> why do
> you need to do any static_cast in the first place?
>

We build our code using gcc with the options "-Wall -Wextra -Werror" and
this leads us to have to use static_cast for example when comparing int and
unsigned int (or std::size_t). A mix of using std::array, std::string and
QVector/QByteArray often gives a few extra static casts, not that it
bothers me too much.

Cheers,
Ola
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Interest Digest, Vol 92, Issue 7

2019-05-07 Thread Roland Hughes


On 5/7/19 5:00 AM, interest-requ...@qt-project.org wrote:

Il 05/05/19 15:07, Roland Hughes ha scritto:

As a general rule try to use static cast, this works for most data type
casting.

Answer 2: what the different kinds of built-in casts are in C++, and
what they do.

Does it answer the question? No.

(Note that this is quoting Barr, without saying it out loud explicitly).


Do you ever bother to read? No.



==

Result: please, let's stop this charade. This is*clearly*  trolling, at
this point, and a waste of everyone's time.

I'm officially calling for moderation on this person.

Please stop your charade. You are *clearly* a troll and have been for a 
long time. You do not come here to learn or to help. Every post by 
anyone which includes any link or anything which dimples your view of 
the world you go off into a tirade on. This has happened numerous times.


I'm officially calling for moderation on you.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest