C++ Gurus

Solved! I think this error was also related to the compiler option "/Zc:hiddenFriend-".

Found it! This error was caused by the compiler option "/Zc:hiddenFriend-" !

In general you define a simple template class like this: template<typename T> class A { }; This can then be used with A<int> myA; Sometimes you want to have a different implementation for a specific type which we call a template specialization: template<> class A<int> { }; Just as with function overloading where the compiler picks the function with the best fit for the parameter types, the compiler will pick the most specific specialization. Sometimes you don't want a specific type but some specific sort of type, e.g. a pointer: template<typename T> class A<T*> { }; Now, if you write A<int*> pInt; or A<double*> pDouble; it will match the specialization for pointers. In the same way class Logger3<R(Args...)> will match any function as template argument. One of the "modern C++" features is Args... which means any number of types (0 or more). (The ... introduces a list of types.) So, R(Args...) can match void() or void(int) or int(double,int) etc. Because we are just interested in the function signature this looks like a function declaration, but without any function name between the return type and the argument list.

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-