Page 1 of 1

QStringParser::toInteger<> bug

Posted: Thu Sep 09 2021 10:15 pm
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.

Re: QStringParser::toInteger<> bug

Posted: Sat Sep 11 2021 11:08 pm
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));

Re: QStringParser::toInteger<> bug

Posted: Thu Sep 16 2021 3:16 pm
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.

Re: QStringParser::toInteger<> bug

Posted: Thu Sep 16 2021 11:33 pm
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.