Forum Replies Created
-
Posts
-
Sorry, I cannot say anything about it because I prepared my talk during Chandler’s presentation. I can only say that this was the topic of the day.
I watch the talk tomorrow and will give my opinion. Now, I’m in the airplane and the bandwidth is too bad. I will ask Diana. Maybe she can kick in.There is no super keyword in C++.
You can only explicitly call the member function (https://godbolt.org/z/GznKsrezE):
class Account{ public: Account(double amt): balance(amt){} void withdraw(double amt){ balance -= amt; } double getBalance() const { return balance; } protected: double balance; }; class BankAccount: public Account{ public: BankAccount(double amt): Account(amt){} void withdraw(double amt) { if ((balance - amt) > 0.0) BankAccount::withdraw(amt); } }; int main() { BankAccount bank1(100.5); bank1.withdraw(10.5); }
Here is the answer of André Müller, creator of the cheat sheets:
“Yes, it is ordered according to “features supported”, so from simplest to most elaborate since I figured this is what one cares about most when writing / reading / talking about a lambda expression. That C++11 comes up twice and the C++23 part is sandwiched in between these two is due to the fact that in C++11 it was not allowed to omit the parameter list when also supplying specifiers like “mutable” (in C++23 it will be).”
It is no contradiction, but Andrea’s formulation may mislead.
- It is unspecified how a lambda is implemented.
- Andreas’s observers different sizes of lambdas depending on the ordering of its elements.
=> His statement is an observation about the clang implementation of lambdas. His observation is not applicable to another compiler, compiler version, or compiler used with other flags. The C++ standards specifies nothing about the layout of a lambda.
As Tobias mentioned, your Visual Studio Intellisense uses a different toolchain or the toolchain differently. You have to check the Visual Studio configuration. My first assumption was that it was a question of optimization or not. Miscrosoft sometimes complains about code compiled in debug mode, which it accepts in release mode.
Honestly, I can not reproduce it and have no idea. Additionally, I studied the various versions of delete.
My only guess it that your overload differs because of the noexcept specifier. When you read here https://en.cppreference.com/w/cpp/language/noexcept_spec noexcept takes with C++17 not part in overload resolution. Meaning, you can not overload on noexcept.
Maybe, it was not specified in C++11/14, and you have, therefore, unspecified behavior.
Here is the general rule: A user-defined or implicitly generated destructor of a type MyType is noexcept by default. If one of the members or bases of MyType has a destructor without a noexcept guarantee, the destructor of MyType has no noexcept guarantee, too.
Consequently, declare your destructor noexcept if you are not sure that all members have a noexcept destructor.
The following program models in a simplified way RAII similar to all containers of the STL, including std::vector and std::string.
class Vector { int* data; public: Vector(const int size) { data = new int[size]; } // acquire memory ~Vector() { delete[] data; } // release memory void do() {} }; void functionUsingVector() { Vector vector(1000000); // lifetime of vector is bound to its scope vector.do(); } // automatic destruction and deallocation of vector and its data
The critical observation is that the destructor of vector would also be called if an exception happens inside the function functionUsingVector.
