QStringParser::toInteger<> bug

Discuss anything related to product development
Post Reply
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

QStringParser::toInteger<> bug

Post by seasoned_geek »

bool okFlag = false;
char32_t c = QStringParser::toInteger<char32_t>(text, &okFlag);


https://www.copperspice.com/docs/cs_api/class_qchar32.html
QChar32 (char32_t c)

FAILED: src/CMakeFiles/Example3.dir/edtbasewidget.cpp.o
/usr/bin/c++ -DBUILD_DATE=\"09/09/2021\" -Isrc -I/home/roland/sf_projects/roland_hughes-csscintilla/copperspice_examples/Example3/src -isystem /usr/local/include/QtCore -isystem /usr/local/include/QtGui -isystem /usr/local/include/CsScintilla -g -DSCINTILLA_CS -DSCI_LEXER=1 -D_CRT_SECURE_NO_DEPRECATE=1 -Wall -Wextra -Wuninitialized -pedantic -Werror -std=gnu++17 -MD -MT src/CMakeFiles/Example3.dir/edtbasewidget.cpp.o -MF src/CMakeFiles/Example3.dir/edtbasewidget.cpp.o.d -o src/CMakeFiles/Example3.dir/edtbasewidget.cpp.o -c /home/roland/sf_projects/roland_hughes-csscintilla/copperspice_examples/Example3/src/edtbasewidget.cpp
In file included from /usr/local/include/QtCore/qstring.h:2,
from /usr/local/include/QtCore/qiodevice.h:28,
from /usr/local/include/QtCore/qdatastream.h:29,
from /usr/local/include/QtCore/qpair.h:27,
from /usr/local/include/QtCore/QPair:1,
from /usr/local/include/CsScintilla/CsScintillaEdit.h:11,
from /home/roland/sf_projects/roland_hughes-csscintilla/copperspice_examples/Example3/src/edtbasewidget.h:7,
from /home/roland/sf_projects/roland_hughes-csscintilla/copperspice_examples/Example3/src/edtbasewidget.cpp:12:
/usr/local/include/QtCore/qstringparser.h: In instantiation of ‘static R QStringParser::toInteger(const T&, bool*, int) [with R = char32_t; T = QString8]’:
/home/roland/sf_projects/roland_hughes-csscintilla/copperspice_examples/Example3/src/edtbasewidget.cpp:1262:63: required from here
/usr/local/include/QtCore/qstringparser.h:385:17: error: no match for ‘operator>>’ (operand types are ‘std::istringstream’ {aka ‘std::__cxx11::basic_istringstream<char>’} and ‘char32_t’)
385 | stream >> retval;
| ~~~~~~~^~~~~~~~~
In file included from /usr/include/c++/9/iterator:65,
from /usr/local/include/QtCore/cs_string.h:26,


This cascades for about 15-20 screens as the compiler tries every possible interpretation except a matching one.
ansel
Posts: 152
Joined: Fri Apr 10 2015 8:23 am

Re: QStringParser::toInteger<> bug

Post by ansel »

Looking at the docs on cppreference, it will seem like char32_t is an unsigned integer type. However, this is part of the documentation for C.

To find the correct definition for char32_t, you need to make sure you are in the C++ documentation. In C++, char32_t is not actually a numeric type. It is a "type for UTF-32 character representation" but does not support arithmetic or any of the normal operations you would expect from integer types.

For this reason, there are no iostream operators defined for char32_t, since one purpose of these character representation types was to prevent implicit conversions. The same is true for char16_t and char8_t.

If you really have a string which contains a number, and that number represents a codepoint value, you will need code like the following:

Code: Select all

bool okFlag = false;
char32_t c = static_cast<char32_t>(QStringParser::toInteger<int32_t>(text, &okFlag));
Ansel Sermersheim
CopperSpice Cofounder
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: QStringParser::toInteger<> bug

Post by seasoned_geek »

If it is a deliberate decision, then this is still a bug. The template code should be trapping char32_t specifically and delivering a meaningful message at compile time instead of letting the compiler generate close to 25 screens of attempts, exceeding scroll back buffers while offering zero information about what is really wrong.
ansel
Posts: 152
Joined: Fri Apr 10 2015 8:23 am

Re: QStringParser::toInteger<> bug

Post by ansel »

seasoned_geek wrote: Thu Sep 16 2021 3:16 pm If it is a deliberate decision, then this is still a bug. The template code should be trapping char32_t specifically and delivering a meaningful message at compile time instead of letting the compiler generate close to 25 screens of attempts, exceeding scroll back buffers while offering zero information about what is really wrong.
Of course we make choices. However, saying that char32_t is not supported in this template is not a choice we made, it is part of the standard. It would not be practical to add more template code to test for every single invalid data type. We are not responsible for template spew, that is part of the compiler and that happens frequently when template preconditions are violated. When we are solving template errors, we always redirect the output to a file. Yes, the output can be quite large.

One of the features they have added to C++20 is the ability to specify a requirement on template parameters, which is intended to produce a more readable error. We do not feel our user base is ready to migrate from C++17 to C++20 at this time.
Ansel Sermersheim
CopperSpice Cofounder
Post Reply