This is not a C++ library issue but a question of mathematical terminology. In mathematics, a norm can mean different things:
What you call norm is the Euclidian norm, which is the distance to the origin. In C++ it's abs(). This naming convention has the advantage of being consistent for complex and for real numbers (the origin in the latter case being ...
Christophe's post, whilst fully correct, does not actually answer the question why the terms look like they do.
To give you definite answer for the reasons, you would have to ask someone from the C++ standard committee, but let me make an "educated guess":
There was already a function name std::abs in use for the euclidean norm for float and double values,...
Performance optimization doesn't lend itself to these kinds of generalized rules, and I'm not sure that the rules you proposed were ever good ways to optimize.
Here's a better plan:
Set specific performance requirements. (i.e. define "good enough.")
Start with well-written code that takes advantage of routine performance optimizations such as sensible ...
Aside from the already given reasons, there is a strong performance reason: taking the square root is significantly slower than the other needed calculations.
For many applications, the returned value is perfectly sufficient (like comparison to other norm values), and taking the square root would be wasted effort. If you happen to need the square root, you ...
Three quotes to sumarize good practices regarding optimizations:
Premature optimization is the root of all evil Donald Knuth
Don't diddle code, find better algorithms Kernighan&Plauger
Debugging is twice as hard as writing the code. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it....
As mentioned by amon in a comment: You can require this to be an rvalue reference by adding && to the function signature:
Bar transformIntoBar() &&
This way, the following code fails to compile:
Bar bar = foo.transformIntoBar();
// compile error (clang):
// 'this' argument to member function 'transformIntoBar' is an ...
Unless there is a good reason not to (meaning your string needs the terminator), I would prefer changing the signature:
void foo(std::string_view path)
It potentially increases efficiency for the caller and the callee.
path = "some default";
is thereafter efficient and the obvious thing to do.
Go for a good interface ...
"Big function (several thousand lines) to avoid function call overhead"
In my experience exactly the opposite. Compilers tend to have problems creating good code for huge functions. I've had examples where execution time was really important to me, and I got considerable measurable speedup by extracting small loops into separate functions - code generated ...
The reading is easy to develop, but running it takes a lot of time. The second part needs development and experimentation. So I want to recompile and run the second part many times.
In this case, multiple threads is unlikely to solve your problem.
To automatically share memory between threads, they all belong to the same process. And that is where the ...
If you find yourself needing to add more data to your full inheritance stack over time, you should ask yourself whether inheritance makes sense in the first place.
It is odd for base classes to be extended that often. It defeats the purpose of inheritance and violates the O in SOLID.
You can mask that problem by wrapping everything up in an argument bundle ...
You are at the right place for a review of your design. But this is not a code review site, so don't expect an in-depth inspection here.
What strikes me first looking at the classes is that:
there is no relation between the Snake and either FieldGrid or Tile: it feels hard to believe that both could be as independent as this diagram suggests, ...
This will not work in view of C++ object lifecycle and the construction logic. Here is what happens:
you construct a MyClassDerived
Before the (empty) MyClassDerived constructor body is invoked, first the base object is constructed and then the member variables (with their default constructor unless you use a mem-initializer).
The MyClass constructor is ...
Not specific to C++ but one of the most common misconceptions I see is the idea that things will be faster if you pull all your data together before moving to the next step of your algorithm. This manifests itself in a number of ways. For example:
Building gigantic data messages
Loading large data structures into memory
Running process A for every item in ...
I see lots of good answers, but not one currently answering your literal question
So I'd like to know if they have a founded reason to exist.
As I remember correctly, each of these techniques had their justification around 20 to 30 years ago on slow hardware, especially for some not-so-sophisticated compilers or interpreters, in cases where even micro-...
Since it is a template you can have complex<int> - what should the return-type be for the "usual norm"? float? double? (Using int would be natural for a template, but doesn't work well.)
Obviously it can be solved in various ways, but here the standard avoid that question by returning what would normally be the square of the norm.
Yes, this is feasible, but... there is a risk of data race on X.
Some more details:
C++ comes with a standard library that fully supports multithreading in a portable way.
The general approach to your problem is the producer/consumer pattern. The producer reads the data and stores it in X. The consumer(s) process data in X.
The problem is that X ...
Your design challenge
On one side, you have an abstraction IShape, and more specialized abstractions like IShapeConvex, IShapeHullConvex. On the other side, you have implementations of these abstractions BtShape, BtShapeConvex, and BtShapeHullConvex.
No multiple inheritance ?
If the world was simple:
Either the abstraction would only be an interface. ...
The builder may not be what you think
The builder pattern is IMHO one of the least understood GoF patterns and there is a lot of confusion about it out there. To make it worth, another pattern is also called a builder, and has nothing to do (except its name) with the GoF builder.
The intent of the GoF builder is:
separate the construction of ...