@Chris-Kawa said in Unnecessary const referencing:

Notice that you're actually doing what I proposed i.e. have an overload for copy and ref variants.

No argument there.

The inlined && forward is just an unrelated complication for style points.

As far as we are talking + 42, if for example the body was something like:

template <typename T> std::remove_reference_t<T> foo1(T&& a) { return smthng(std::forward<T>(a)) + 42; }

Where smthng is some other templated nonsense (or simply overloaded), then, I'm sure you'd agree the forward is no longer redundant. :)

Btw. I love how the float version transforms into a fixed point xmm arithmetic with magic constant. Compilers are so smart these days :)

Yeah, true enough. Although you can still catch them missing optimization opportunities from time to time.

@JonB said in Unnecessary const referencing:

Why write this getting-more-complex-all-the-time code if you can ...

What Chris said (... and since this is indeed an academic discussion at this point).

@JonB said in Error handling (Linux, Qt 5.15):

If you really feel this strongly about the way Delphi/CBuilder handles this (which btw only started out as checking for a null pointer,

Look as an Access Violation handling can be realized withing a function (Linux QTcreator). My example looks not very pleasant but QT developers probably can make macros to make it look good. Yes, in the business of handling first were logjumps, then try/catch followed.

jmp_buf ape; void AcessViolationHandler(int signum) { _ML.p("AcessViolationHandler is called"); //this is my logger // Do stuff here then return to execution below longjmp(ape, 1); } //------------------ void Tmq_blf::on_actionAccess_Violation_tst_triggered() { struct sigaction act; struct sigaction oldact; memset(&act, 0, sizeof(act)); act.sa_handler = AcessViolationHandler; act.sa_flags = SA_NODEFER | SA_NOMASK; sigaction(SIGSEGV, &act, &oldact); int i = 10, *j=NULL; if (0 == setjmp(ape)) { *j = i; sigaction(SIGSEGV, &oldact, &act); } else { sigaction(SIGSEGV, &oldact, &act); /* handle SIGSEGV */ } QMessageBox bx; bx.setText("The app survived AccessViolation and continue to run"); bx.exec(); } //------------------

@Chris-Kawa said in `this` inside lambda body:

That also goes for lambdas. You can't do obj->someFunctionThatIsNotAMember() or obj->someLambda and have them get obj as this. As always there are standard proposals though (I doubt they will ever get accepted, but who knows) :)

Yep, that clarifies! I thought there might be a way that you could do that, but apparently not from C++.

Thanks for your responses.

@Kent-Dorfman said in C++ null runtime checking:

Of course these grand ideals only apply to code destined for release.

I always said this was about enabling only for debug. But I agree it doesn't give me much if I have a debugger available.

@Axel-Spoerl Thanks , I did post "sarcastic" ...." it compiles" in "the lounge".

Maybe I could ask for it to be moved .....

and do as you suggested after

@AnneRanch simplilfied() will squeeze possibly more spaces between bluetooth.service; and disabled into only one space. This will make sure contains() call more accurate.

@Chris-Kawa I did not realize I made a duplicate post , so I am adding my goof here . Sorry for wasting space.
I think I got the concept of containers, but I am obviously missing something else.

What am I missing in my code ?

Decaration

QList<const QBluetoothDeviceInfo* > RemoteDeviceInfo;

This works

RemoteDeviceInfo.append(&info);

// verify text = "!!!!!!!!! DEBUG verify RemoteDeviceInfo \n"; text += " name \n"; text += RemoteDeviceInfo.at(0)->name(); qDebug() << text; m_ui->plainTextEdit_8->appendPlainText(text); // m_ui->plainTextEdit_3->appendPlainText(text for(auto &device:RemoteDeviceInfo) { text = " BUILD range loop test "; m_ui->plainTextEdit_8->appendPlainText(text); text = " device name "; text += device->name(); m_ui->plainTextEdit_8->appendPlainText(text); }

when I attempt to verify RemoteDeviceInfo) using another method

it fails

if(!RemoteDeviceInfo.isEmpty()) passes OK
{
for (auto &device:RemoteDeviceInfo)
{
text = " For loop test ";
qDebug() << text;
text = " device address \n";
text += device->address().toString(); fails here
qDebug() << text;
m_ui->plainTextEdit_8->appendPlainText(text);
text = " device name \n";
text += device->name(); // >address().toString()
qDebug() << text;
m_ui->plainTextEdit_8->appendPlainText(text);

} } }

My debug shows no contents in RemoteDeviceInfo when used in another method.

@Andy314 said:

Strange it comes with the new Qt-version
QMAKE_CXXFLAGS += -permissive

Qt6 requires C++17 and requires permissive- switch in MSVC (not to confuse with -permissive, which is the same as /permissive). Further C++ standards in MSVC imply permissive- and are required for some of the new features like modules or concepts. Qt6 requires it to avoid having to support non-standard code paths for a single supported compiler.

permissive- switch turns off all language extensions and makes the implementation conformant with the standard.

As @kshegunov said, you should not be using permissive. It locks you into MSVC specific toolchain and will make updates to future standards harder and error prone.
I'd say keep the standard conformance on and fix code that is nonstandard.

@Chris-Kawa

We were beyond floppies by then. The first computer I used had 10.5 inch (I think, unless it was only 8 inch) floppies, https://www.computinghistory.org.uk/det/10247/Nord-ND305-355-Floppy-Disk/ :)

@AnneRanch I did not realize that pairingFinished( emulates the SIGNAL.
I get compiler warning that it is missing "emit" , which is kind of
superficial if it generates SIGNAL without "emit".

localDevice.requestPairing(adapter.address(), QBluetoothLocalDevice::AuthorizedPaired); localDevice.pairingFinished(adapter.address(), QBluetoothLocalDevice::Pairing());

PARTIALLY SOLVED

@kshegunov said in question about singletons:

static variables inside a function are automatically thread-safe (since C++11). A class variable is not automatically thread-safe.

No they aren't. Only the initialization is thread-safe, which is also guaranteed for any global static (scoped or not).

Thank you for clarifying this. It is what I meant (but not what I wrote).

@JonB Thanks but no, I had a wrong syntax.
SOLVED

@AR --

You are going to keep having problems with these embedded command line sequences. quoting/escaping embedded command sequences is a PITA, and can be mitigated by creating subshell scripts and just calling the script instead of trying to build a long convoluted command line on execution. It also has the benefit of allowing for easier testing because you can work out the script directly and not involve Qt until you are ready.

@nasimChildOfDesert said in Sqlite connection QSqlDatabasePrivate::addDatabase: duplicate connection name 'qt_sql_default_connection', old connection removed.:

threading, mutex, socketprograming TCP

You don't need threading for sockets/tcp when you use Qt. Seaching for 'Qt threading' or looking at the QTcpSocket documentation should be a good start.

Here is an update.
Went back to project backup copy and got rid of the gibberish.

The result of the "ln" ( '/dev/rfcomm0' -> '/dev/ttyUSB0' ) is now in the temporary file
which resides in my main .pro folder .
Do not like it there , but...

I like to redirect good "ln" result into QString using stdio - if possible-
,and error too.
I am working on that but could still use some assistance to add that to the current command.

"TASK unlink "
" echo q | sudo -S -k unlink /dev/rfcomm0 "
[sudo] password for nov25-1: " echo q | sudo -S -k unlink /dev/rfcomm0 SUCCESS un linked "
" Result system 0"
"TASK link - add tee "
" echo q | sudo -S -k ln -s -v /dev/ttyUSB0 /dev/rfcomm0 | tee temporary_link_file.txt"
[sudo] password for nov25-1: '/dev/rfcomm0' -> '/dev/ttyUSB0'
" echo q | sudo -S -k ln -s -v /dev/ttyUSB0 /dev/rfcomm0 | tee temporary_link_file.txt SUCCESS linked "
" Result system 0"

@mzimmers

Unless I'm misreading the thread, there is a fundemental difference between a class trait object and an inherited class. you can't get "parent" of a trait object and expect it to be the class where the trait is instantiated.

When using pure inheritence, you can refer to parent(), but you better use the correct type cast operation when doing so.

IOW, parent or superclass access works for is_a, but not for has_a.

@JonB I would agree with Kent, avoid. It's far too easy to blow past the stack size with this with no warning. With constant sizes you can static check this. With dynamic containers you use the heap, so no problem either. With this you never know.
It's also worth mentioning that it makes stuff like sizeof become a runtime evaluation instead of a constant compile time expression, so another potential downside. I'd say being explicit about your stack usage is always a good thing and leaving it to runtime parameters is asking for trouble.
Besides, it's a compiler extension, so locking you into that particular brand. Something I would avoid too.

@JoeCFD The stack sizes are a per thread resource, yes, but they allocate address space and physical memory pages can be mapped as needed. A modern PC runs hundreds of threads at a time and it's easy to get into GB territory of address space allocations just for stacks, even if physical memory use is a lot lower. Large stacks can be an issue where address space is limited, e.g. on 32 bit systems, or can lead to degraded performance due to large amount of small chunks and fragmentation. The stack size is a balancing act. The defaults are different on different platforms, but you can always set your own size for your app. If you know it's stack hungry or that it barely uses it and you have a lot of threads running you can configure stack size via compiler switches.

@AnneRanch
You have to set the break point in the implementation, i.e. usually the cpp file.
The constructors listed are definitions ;-)
You probably want to debug the first one, which takes only a parent argument.