Why we should use "t_" prefix for function parameters? What is the practical sense? I think it's just difficult to read. The function parameters should not be prefixed.

https://github.com/lefticus/cppbestpractices/blob/master/03-Style.md#distinguish-function-parameters

So this is mostly from a discussion perspective. I'm not experienced when it comes to C++, but I'm thinking about this discussion of limited scope.

I'm mostly concerned that we might spend too much time initializing objects. Assume I have a large object (say an image) that I want to run an operation on to get some value, and I further run several operations per picture (running different sorts of filters, etc. etc.) each of these operations needing their own copy of the image that they run their operations on. Further, all of this happens several times a second, since it comes from a video stream.

I would have some function treat_frame() working with each frame, and have that function call functions for each operation. Wouldn't limiting the scope of the working objects (having them local to each function) cause constructors and destructors for these quite large objects several times every second? From my perspective it seems wiser to allocate them once outside the scope of the loop, and then have them use the same memory over and over.

Not sure how far this goes though. I did something like the above in a university project, and in profiling it turned out a lot of time was spent in constructors and allocators. Not sure how it would be with something like the example code. Like, would the constructor get invoked every iteration in the below code?

// Good Idea
for (int i = 0; i < 15; ++i)
{
  MyObject obj(i);
  // do something with obj
}

In section "Avoid Raw Memory Access" using of std::unique_ptr can be added for arrays:

auto my_data = std::make_unique<MyDataClass>(128);

In the safety module, there is an example recommending using const to indicate an immutable getter method: std::string get_value() const { /* etc */ }

However, I think that best practices actually recommend going slightly further by also returning a const reference. Like this: std::string const &get_value() const { /* etc */ }

Can anyone confirm or deny this practice? Is it a best practice?

To facilitate navigation of this document directly, perhaps we should add "previous" "next" and "Table of Contents" links to the top and bottom of each page?

Instead of commenting out the code with /* */ you can use:

#if 0
void function_f(int param)
{
  (void)param;
}
#endif

In this case you can nest such commented out parts. Moreover, syntax highlighting still work in some IDEs.

// Better Idea
const std::string somevalue = [&](){
    if (somecase()) {
      return "Value A";
    } else {
      return "Value B";
    }
  }();

// Better Idea
const std::string somevalue =  somecase()) ? "Value A" :  "Value B";
      return "Value A";

It is stated here that

Operations on doubles are typically faster than floats.

I can not reproduce this. For my tests, doing math on floats and doubles is equally fast if SSE is not considered. I would even have expected that floats would be faster due to memory bandwidth but I am having trouble testing that since gcc keeps autovectorizing my code.

Anyway, can anyone confirm or deny the statement that doubles are faster than floats anywhere?

I started to fill the section about precompiled headers with some general information and some links to manuals for the common compiler. Any additional suggestions?

Very glad to hear that pre-increment should be preferred. However, your reasons are easily debunked in modern times where compilers will optimize both versions to the same machine level instructions. However, this argument breaks as soon as more complicated types are used: iterators. Your example uses plain old ints, but it would be clearer if you elaborated a little by using (user-defined) classes that overload ++.

In the Use the tools available section it is recommended to enable the flag -Wnon-virtual-dtor, and there is a note that says -Weffc++ warning mode can be too noisy, but if it works for your project, use it also. however, according to clang's documentation, these two flags are synonyms https://clang.llvm.org/docs/DiagnosticsReference.html#weffc

08-Considering_Performance.md in the section Char is a char, string is a string (third from last) How the performance in CPU different for "\n" and '\n' ?

In the 03-Style document, I read the following sentence:

If the member variable is not expected to change after the initialization, then mark it const.

However, we know that if, for example, we mark a container as const, we prevent it from being moved, possibly hindering performance. Marking fields as const is useful to enforce invariants; however, it "interferes" with performance. If both const correctness and performance are important, one could leave the field non-const, make it private and define a field getter.

coitre declares itself as depreacted:

from https://github.com/sakra/cotire/:

The functionality provided by cotire has been superseded by features added to CMake 3.16. Support for pre-compiling and unity builds is now built into CMake. Thus, there will not be any further updates or support for this project.

The current wording reads "/Wall - Also warns on files included from the standard library, so it's not very useful and creates too many extra warnings." – this reason does not seem to hold, because /external (i.e. /external:anglebrackets) exists and is effective in preventing /Wall warnings in the standard headers too.

A better reason to avoid /Wall would be a large number of informational diagnostics (i.e. https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4711?view=msvc-170) - but then again, these can be disabled individually.

It is stated:

Source control is an absolute necessity for any software development project. If you are not using one yet, start using one.

Which is true, but then there is a list of source control hosting services, which are not the same thing.

This moves the runtime performance discussion before the build time discussion

It was kind of surprising to discuss build-time performance first, something that most developers don't need to be worried about, especially now that C++20 has modules.