C++ Gurus

Never Mind, turns out there was a bug elsewhere in my code. Both methods work lol. I should really call it a day...

Hi, If you want to to mock QSerialPort you have to make it replaceable in your class. Use a QIODevice pointer as member and either add a setter or a constructor parameter so you can use either QSerialPort or your own mock device. This means that you need to refactor your logic a bit to setup the port. On a side note, your class has two different things that look suspicious: It seems to be doing way too many things seeing its internal and the class name singleton implementation more often than not are architectural issues.

@JonB We learn more from discussions. I do not feel you are difficult in any way.

UPDATE/CORRECTION I tried again with switching Use clangd on and off. Somehow it seems it didn't "take" right formerly. Now I do see different behaviour. I find that sometimes when I start Creator, it warns me I have don't have enough memory for clangd, I selected "Enable anyway", it still red-underlines [[fallthrough]];. Then I go to Preferences, switch off clangd and then switch it back on, that clears the complaint. It seems I have to switch off and back on every time to make it work. Sigh.... With clangd switched on I can use any of the [[fallthrough]]; annotations which get through gcc compiler and code editor does not red underline them. Q_FALLTHROUGH() macro still requires a blank line without clangd, but works without blank line with clangd. Fair enough, @aha_1980 has warned me that it will be "problematic* with the internal code model rather than clangd. So all in all I can now use [[fallthrough]]; in my code with clangd, that is apparently "standard" C++ 17 so I accept that.

@SimonSchroeder Thanks, that's great to know. Marking yours as solution.

Hi, The best way to do it is to create a subdirs project as described here. Even though it shows it for an application with libraries, the same concept applies to adding tests. You can check the Qt 5 sources, they are using that concept there.

Doxygen is a good choice, I don't know if it will fit your requirements exactly though. It can show nice class-subclass hierarchies if you enable dot diagrams. In cmake this can be done like so: find_package(Doxygen REQUIRED dot) (https://www.doxygen.nl/manual/diagrams.html) This will result in something like this: https://www.doxygen.nl/manual/examples/diagrams/html/class_c.html

FWIW, since you are using the STL streams classes, note that you have buffer size control in the STL classes. One could weakly argue that you should use the Qt file IO methods instead of STL streams, since mixing frameworks is often the cause of problems in programming.

@Pl45m4 I am now good on the algorithm. The one I am using (via @J-Hilk/ChatGPT) gives me a satisfactory answer I can work with and place my objects.

@SimonSchroeder Sorry, but I don't think any part of my questions relate to random numbers or generators or distribution/uniformity performance. They are questions about C++ (especially the as-yet-unanswered question #3). With regard to the static-ness/number of times to call the initial "seeding" when comes with std::random_device rd; std::mt19937 gen(rd()); I only wish to reseed once and then accept the random number which comes from that, as is standard practice with random number generators (e.g. for old-style rand() we used to call srand() just once).

QString myString = "First line\nSecond line"

@SimonSchroeder said: But I'm not sure if this distinction is possible It's not. The delete operator can't be cv qualified. Here's a fun quirk: struct Foo { void itIsFine() const { delete this; } ~Foo() { bar = 42; } int bar = 0; }; const Foo* foo = new Foo(); foo->itIsFine(); so not only can you delete an object through a pointer to const, but a const function can mutate the object without mutable or const_cast by deleting the object it is being called on;)

@jeremy_k that is weird. some examples place the directive after the declaration and others before like it shouldn't matter...but you are right. It did make a different. Placing it before the declation cause the warning to be igrnored. looks like gcc documention is wrong...go figure. LOL wrong in TWO PLACES...First, they say "unused" is a valid attribute, and second, internal examples sometimes place the attribute after the decl. Hmmm.

@mzimmers said in can't compare lists of my struct: I removed the QObject derivation, and now it seems to work. If you don't plan to ever use meta-object related stuff, then you really don't need a QObject derived class or the Q_OBJECT macro (for metacalls / qt signals).

Which Qt Version and C++ standard are you using?

I have a same question,but I can't change Qt Version or c++ standard. do you have other suggestions? Thank you in advance for your help

@Bharath-kumar As @Christian-Ehrlicher has said. I don't understand: in your code you know how to produce a certain number of digits via QString formattedString = QString::number(doubleValue, 'e' , 4);, so why do you have QString dataString = data.toString(); earlier and expect that to produce a limited number of digits?

@JonB said in matherror issue: If the int _matherr (struct _exception *pexcept) appears in merr.c you need to trace from there to find out where it (_exception) is defined. Maybe it's a MinGW-only definition/file, I don't know. If I compile in Clang int err_ind = 0; int _matherr (struct _exception *pexcept) { err_ind = 1; } Compilation OK, but math exception doesn't work

If you want an integrated application (not the variant with QProcess that @SGaist suggested), the first step would be to separate your command line application: parse the command line parameters into variables and the actual functionality should then be refactored to a separate function, that takes these variables as function arguments. This ensures, that the same function can be called from your GUI application. Inside the GUI application you would then have input widgets for each variable and a button labeled "Run" (or similar). When "Run" is clicked, you collect all the different inputs and call your refactored function. If this takes longer to run, you should put it into a separate thread (and then the other solution "use a QProcess" is not too different to implement, though for the perfect solution threads should be used, but QProcess will be easier). Maybe for threading a simple QtConcurrent::run() will suffice. You will have some trouble if there is important console output (writing to stdout/stderr) of your existing application. How do you want to interact/signal errors? For a good solution this would require deeper changes into your existing application. With the QProcess approach the only thing you can do is to show the output to the user. Otherwise, you could use callback function for output. In the case of your command line application this can still write to the console by default, and for your GUI application you register a callback that shows a QMessageBox. Maybe the callback can even return a value (e.g. from the message box) to continue or abort.