@rparon said in uninitialized data passed to QStringList QCoreApplication::arguments(): Hi jeremy_k, that is an interesting point, The point seems to have been missed. Treating const data as non-const is undefined behavior, and the C++ standard allows a conforming implementation to do anything when UB is invoked. Command line arguments and historical usage are irrelevant.

Build issues solved: [https://forum.qt.io/topic/162537/qt-creator-android-15-adb.exe-pull-system-bin-app_process64-error/]

@Kent-Dorfman said in I hear crickets chirping: Doesn't anyone have any esoteric C++ incantations to discuss. It's too quiet in here. Change of topic: I recently found some esoteric C++ incantations: a constexpr counter based on template instantiation: https://b.atch.se/posts/constexpr-counter/ . However, it seems that this behavior is about to be deprecated (you cannot rely on the order templates are instantiated). At the same time, something quite similar has occured in one of the reflection examples (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2996r12.html Chapter 3.17 "Compile-Time Ticket Counter"). This reflection proposal has been accepted, so we might be able to safely do a constexpr counter through reflection starting with C++26.

@JulsPower I understand you probably lack the motivation and time to do it, but it would be interesting to see the differences in the build between cmake generated makefile an qmake generated makfile. Obviously the two are building/linking differently. Smells like a build flag isn't the same in cmake debug

@JonB correct

@JonB Definitely is, thanks again for the help Jon

@Christian-Ehrlicher said in how to override qtcharts QBarSeries？: the export macros are wrong. Which is exactly what I wrote above in https://forum.qt.io/post/829183. I don't know about "name clash". Anyway if you are sure this cannot be done by adding a new subclass in own code then I am sure you will be right and the OP would be best just changing the existing Qt source.

@SGaist said in Connecting a QWebSocket to a given IPv6 address (no URL): What did you do that made things work ? It might be helpful to other people :-) There were two things: The QWebSocketServer was set to SecureMode, while on the client's side, the request URLs were all "ws://", so changing the QWebSocketServer to NonSecureMode helped a lot. When the lookup of QHostInfo is successful, the lookupId of is set to -1, and the errorString is then "Unknown error". So there really was no problem with this to begin with!

@aha_1980 said in How to switch off specific warnings in Qt Creator: @DiBosco Have you already seen https://stackoverflow.com/questions/22129383/removing-unused-parameters-warning-in-qtcreator ? For your case, it would be: QMAKE_CXXFLAGS_WARN_ON += -Wno-deprecated-copy Regards Ah, yes I had seen that. The English in the most upticked reply just made me go "What?". Just could not understand what they were saying, but I had tried: QMAKE_CXXFLAGS_WARN_ON += -Wdeprecated-copy Thinking why on earth would putting the warning on make it disappear, but out of desperation I gave it a go. Had I realised it needed -Wno-deprecated-copy, not -Wdeprecated-copy I'd've been fine hours ago. Many thanks for that, now doing just what I want. Also @JonB Thanks for your help too.

There are lots of differences in the command line options between VS and Qt. Basic project in both cases is the default GUI application. Qt: -c -nologo -Zc:wchar_t -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -permissive- -Zc:__cplusplus -Zc:externConstexpr -fsanitize=address -Zi -MDd -std:c++17 -utf-8 -W3 -w34100 -w34189 -w44456 -w44457 -w44458 -wd4577 -wd4467 -EHsc /Fddebug\asan_test.vc.pdb -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I..\..\dev\asan_test -I. -I..\..\Qt\6.9.0\msvc2022_64\include -I..\..\Qt\6.9.0\msvc2022_64\include\QtWidgets -I..\..\Qt\6.9.0\msvc2022_64\include\QtGui -I..\..\Qt\6.9.0\msvc2022_64\include\QtCore -Idebug -I. -I/include -I..\..\Qt\6.9.0\msvc2022_64\mkspecs\win32-msvc -Fodebug\ @C:\Users\jazzco\AppData\Local\Temp\main.obj.18184.15.jom VS: /JMC /permissive- /ifcOutput "WindowsASanTest\x64\Debug\" /GS /W3 /Zc:wchar_t /Zi /Gm- /Od /sdl /Fd"WindowsASanTest\x64\Debug\vc143.pdb" /Zc:inline /fp:precise /D "_DEBUG" /D "_WINDOWS" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /fsanitize=address /WX- /Zc:forScope /RTC1 /Gd /MDd /FC /Fa"WindowsASanTest\x64\Debug\" /EHsc /nologo /Fo"WindowsASanTest\x64\Debug\" /Fp"WindowsASanTest\x64\Debug\WindowsASanTest.pch" /diagnostics:column The options differ in VS are: /JMC = Just My Code /WX- = Treat Warnings as Errors OFF /sdl = Enables recommended Security Development Lifecycle /Od = disable optimization /D <> = define constant/macro /Gm- = disable miminal build (deprecated) /RTC1 = Enable fast runtime checks /GS = Checks buffer security /fp:precise = "precise" floating-point model; results are predictable. /Zc:forScope = Enforce Standard C++ for scoping rules (on by default). /Fo<> = Creates an object file. /external:W3 = Set warning level for external headers. /Gd = Uses the __cdecl calling convention. (x86 only) /TP = Specifies all source files are C++. /FC = Displays the full path of source code files passed to cl.exe in diagnostic text. /errorReport = deprecated I added several options to Qt, like -JMC -GS -sdl -RTC1 to get it up but the process still crashes in debug mode at the same spot even with a clean default project without the faulty source code. In release mode it works but doesn't recognize the malicious code. EDIT: fixed wrong VS command line

@SGaist Yes I know that but I was looking for a programatic way.

My full blown test app now runs on the X86_64 simulator it looks awful its ui was not designed for phone use but all the bells gongs and whistles are there and information from my database is populating the widgets which is good. Time now to reflect on what I have learned and tidy up loose ends, thanks to those who helped on this journey.

Sooooo, QMediaMetaData tmp = m_mp->metaData(); m_singers = tmp.value(QMediaMetaData::ContributingArtist).toString(); m_title = tmp.value(QMediaMetaData::Title).toString(); m_album = tmp.value(QMediaMetaData::AlbumTitle).toString(); m_duration = tmp.value(QMediaMetaData::Duration).toULongLong(); qDebug() << "Path:" << m_path; qDebug() << "Singers:" << m_singers; qDebug() << "Title:" << m_title; qDebug() << "Album:" << m_album; Works Fine !

@svadym said in QTableView performance: slow repaint of scroll area viewport: I can try to submit a bug report if you say that it's not normal. This would be nice. With a small reproducer (main.cpp only), a recent Qt version (6.9 and up) and some benchmark results from you. Also reduce the update rate to e.g. 10hz. It's fast enough - Noone can read that fast.

@SMF-Qt cool :)

Looks like the bug doesn't reproduce anymore.

@Stamp_it would also recommend to use 6.9.1

@kehr_I QString QSettings::fileName() const states: Returns the path where settings written using this QSettings object are stored. and also references QSettings::isWritable(). It is noticeable to me that it specifically mentions "writing" yet not "reading". Maybe this is significant for your failed-reading case? Plus isWritable() requires a non-readonly file (might yours be read-only, or lack user write permission?). I suggested you test for read/writability. In principle setPath() ought work, though you don't show it being called or where you set it to. I suggested trying a system-wide path rather than anything to do with, say, the user, at least to test. However since you have an inexplicable problem I suggested you test with a full, explicit path to QSettings() constructor instead of relying on setPath(), just in case. If it's different we know the cause, if it is not nothing is lost. You could have checked this by now.

@snoriman hi, The aqtinstall project seems to fit the description: command line installation of Qt.

@SimonSchroeder said in Using QList [] operator in const methods: Even if operator[](int) const returns a copy you have the exact same possible race condition in a multithreading environment. The only advantage is that it is fewer lines of code where this might occur. Multithreading seems an irrelevant point though because the competent programmer understands that accessing a shared resource needs a mutex, so if safe programming processes are observed then there is no race condition. re const vs non-const: totally agree and get it. It's the way things are...however, I do sometimes wish nothing was ever const and everything was mutable. :^)