C++ Gurus

When you want to include some headers of a library you also must pass the include path to the compiler.
If you use cmake, use target_include_directories() and add the desired include paths there. Later when you use this library (aka you link them with target_link_libraries()), cmake will automatically add the paths specified.

clazy is also using libclang

Hi and welcome to devnet,

What are you using currently ? QtQuick ? The graphics view framework ?

See https://doc.qt.io/qt-6/qtcharts-changes-qt6.html

Works. Thank Christian again.

@Redman said in reinterpret_cast for received tcp packets:

01:00:00:00:01:00:01:00:00:00:01:00:00:00:00:00:00:00:01:00:00:00

This is what you'd expect for a packed struct (as you have figures out). It worked before because both sides were using C++ and so both sides were not using packed structs (so much about the "well defined protocol").

In order to not have that problem @J-Hilk is right to write a constructor expecting a QByteArray. For sending you should also pack the members into a QByteArray yourself. This also makes you immune to the order of the members (which is only guaranteed by a very, very recent C++ standard). It is also common practice to order members from biggest to smallest, so you can adhere to alignment rules and still get the most compact representation. This would also solve your problem (on the C++ side; I don't know Python) that you don't have to explicitly pack the struct.

@GrecKo said in Iterator as a member: Tree/Graph-like structure:

pick the container with the friendliest API depending on how you plan to access it.

Still what @Christian-Ehrlicher and @JonB suggested doesn't sound too bad :)
Will definitely try it.

Similar question: Why is QButtonGroup using a QHash-map for its member buttons? :))
I doubt that there ever will be thousands of button widgets in one group :)

@SimonSchroeder
Your description above is in substance, correct. I had to check it to make sure myself. ;^) By assigning the string literal to an array (const or not) it is considered "auto class". When you create a pointer to the string literal the pointer will "typically" point to a RO-data segment containing the literal.

@osirisgothra said in Problem using overridden methods:

I do really like being able to do this:

which opens a wonderful window that

You could write a QtCreator extension/plugin and try to find out how to get your hand on the data you need.

displays EVERY child class of that object with a checkbox by each function. You can just check off each signature you want to override

Probably via the Code Model / Symbols.

If you wanna try it, start a new topic.
People who have more experience with such things than I do may be able to help you then.

See https://doc.qt.io/qt-6/debug.html : set QT_FATAL_WARNING, run your app in the debugger and see where you create a QWidget before a QApplication.

@JoeCFD said in To singleton or not to singleton, that is the question....:

Calling baz() with using "using Foo;" can cause confusing while two namespaces are present at the same place.

In the concrete example you have given, it would not compile because the compiler cannot resolve the overload (i.e. Foo1::baz or Foo2::baz). You'd still need to use a fully qualified name. It only gets confusing when you have Foo1::baz(int) and Foo2::baz(double). You might write baz(1); when you actually want to call Foo2::baz. The software might even do the right thing for years. Someone might just introduce Foo1::baz years down the line and suddenly the behavior changes.

@JonB said in Template class as parameter question:

What happens when another container has a different definition of count() which does not return an int (or number)? Maybe your syntax is not quite correct and it would have to be requires(T t) { int t.count(); }?

I guess this would be some additional requirement using std::is_same_v and decltype(t.count()). I'm still on C++17, so I haven't used concepts myself.

@JonB said in Template class as parameter question:

Hmph! But that's is just what e.g. QList is, and loads of other containers.

A container class is an obvious example where a general purpose implementation makes sense. But, you usually don't implement your own containers. Furthermore, most of the time I would have at least int and double in mind for containers. So, making them general purpose from the get go is a given. But, I don't have to make all my algorithms general purpose such that they might be reusable decades down the line if ever. If there is a current need for general purpose code, make it general purpose. Otherwise it just make maintenance more complicated while being unnecessary. I guess it might also introduce additional bugs because you try to be extra clever.

Well, first of all (user-defined) operators in C++ are just functions. Hence, it means you can call them using the function syntax (like mentioned as operator[](someIndex)). To understand why you cannot just write [someIndex] we need to look at the history of C++; or rather C. We get the index operator syntax from plain arrays and pointers. These require the array or pointer to be explicitly written before the operator: p[i] or array[i]. (To be more precise: These are the same as i[p] and i[array] because officially in C these are equivalent to p+i=i+p and array+i=i+array. However, this weird syntax does not work for operator[] overloading and doesn't help to make my point.) In the same way you need to write the object on which to call the overloaded operator[] in front of the index access. If you could use implicit this, the same would need to apply e.g. for the binary operator+ and the like. What about operator=? I personally also think that just [someIndex] is not really readable. It doesn't show directly that you want to use an index operator. I prefer that you must write (*this)[someIndex] explicitly. In most places I would use it like this. Only when I want to make plain that I want to forward to operator[] (as was initially asked) I would make the forwarding aspect clear by writing operator[](someIndex).

Furthermore, now it is too late to introduce the short-hand syntax (implicit this) into C++. [] without an object preceeding it is already reserved for introducing lambdas. I would expect that the compiler error for return [someIndex]; would say something along the lines that the body for the lambda function is missing. (return [someIndex]{}; would return a lambda that does nothing, but captures someIndex by value. Function arguments () are optional for lambdas if they are empty.)

Sometimes when I need to use some operators (not necessarily the index operator) several times inside a member function (and I'm annoyed at writing (*this) over and over again) I would write auto &self = *this;. Then, it is much nicer to write return self[someIndex];. (The name self is derived from other OO languages that use a reference self to the object instead of a pointer this.)

@GrecKo said in SIGNAL/SLOT() macros in Qt's source code:

@Pl45m4 said in SIGNAL/SLOT() macros in Qt's source code:

The string-based connection does not need QObject receiver.

The signature is QObject::connect(const QObject *, const char *, const QObject *, const char *, Qt::ConnectionType ) though

This was referring to this overload:

QMetaObject::Connection QObject::connect(const QObject *sender, const char *signal, const char *method, Qt::ConnectionType type = Qt::AutoConnection) const

Which implies that the target is the current object.

This is different from the similar (yet different) PMF variant as there's no implicit target in that case. Hence the recommendation to use the variant which has a context object.

Each class has its own vtable (it is not per object). Each object then has a pointer to the vtable. When you have a pointer to a base class pointing to an object of a derived class, it just uses the pointer to the vtable and calls the appropriate function. Like mentioned before, this is only one indirection. (It gets more complicated with multiple inheritance.)

Concerning Objective-C: Most strings for message are compile-time known strings. This means that "string comparison" in reality is most of the time just comparison of pointers. The runtime also uses a little cache to speed up the most recent function calls.

BTW: Since we are always talking about performance here. There is a CppCon talk on Youtube "Optimizing Away C++ Virtual Functions May be Pointless" https://youtu.be/i5MAXAxp_Tw?si=ieyiW3G31UMmANV-

@J-Hilk
Yes, as you say, it comes from UI app. I often pick the UI template for a test project so I get the QApplication and necessary Makefile/cmake stuff but then uncheck the "create .ui file" box as I don't want that and create widgets in code. Which leaves me with the empty destructor code. I am now happy that I don't need that unless I want it.

Here is another idea: Treat the intervals as sets and compute their intersections.

Start with the first interval and compute the intersection with every other interval. Store the intersections inside a second vector. The second vector should now have n-1 elements (intersection of 1st with 2nd, 1st with 3rd, 1st with 4th, ..., 1st with nth, but not 1st with 1st). Now you take the intervals in this second vector and intersect them with all original intervals again (first interval in the second vector is for 1st with 2nd, so we only need to start intersecting starting from 3rd, for the second interval we start from the 4th interval, and so on). The intersections are then stored inside a third vector. If there are only empty intervals inside the third vector, we can stop for now. Otherwise we throw away the second vector and repeat this process with the third vector. (The second vector is intersections containing 2 intervals, the third vector contains intersections of 3 intervals, so we don't need the second vector anymore if there are non-empty intervals in the third vector.) From the last vector we get from this process we keep one intersected interval (just take the first non-empty intersection) and remember it. It is the intersection with the most intervals including the first interval. Now, we repeat this for the second interval, and so on.

This should give as for each interval the maximum of intersections containing this interval and the interval limits of the intersection. You can just pick the intersected interval with the highest number of intersections and use the minimum of that interval as the number.

It is a little tricky to wrap your head around this (initially I thought it would be little easier). The way I described it runtime would be at least O(n³). I'm not sure if this is good or bad.

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