Re: [Interest] Interest Digest, Vol 92, Issue 8
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?
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
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
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?
> 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?
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?
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?
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?
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?
> 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?
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?
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?
> 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?
> 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?
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?
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?
> 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?
> 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?
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?
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
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
