К>Это ты Simula 67 сейчас обозвал "мощным объектно-ориентированным"?

Simula 67 introduced objects,[1]:2, 5.3 classes,[1]:1.3.3, 2 inheritance and subclasses,[1]:2.2.1 virtual methods,[1]:2.2.3 coroutines,[1]:9.2 and discrete event simulation,[1]:14.2 and features garbage collection.[1]:9.1

Divide and conquer: Small classes are easier to write, get right, test, and use. They are also more likely to be usable in a variety of situations. Prefer such small classes that embody simple concepts instead of kitchen-sink classes that try to implement many and/or complex concepts (see Items 5 and 6).

Designing fancy large classes is a typical mistake when starting object-oriented design. The prospect of having a class that offers complete and complex functionality in one shot can be quite alluring. However, designing smaller, minimal classes that can be easily combined is an approach that is more successful in practice for systems of any size, for many reasons:

A minimal class embodies one concept at the right level of granularity. A monolithic class is likely to embody several separate concepts, and using one implies dragging the intellectual overhead of all others. (See Items 5 and 11)

A minimal class is easier to comprehend, and more likely to be used and reused.

A minimal class is easier to deploy. A monolithic class must often be deployed as a bulky indivisible unit. For example, a monolithic Matrix class might attempt to implement and deploy exotic functionality such as computing the eigenvalues of a matrixeven when the majority of clients just want simple linear algebra. A better packaging would implement various functional areas as nonmember functions operating on a minimal Matrix type. Then the functional areas can be tested and deployed in separation to the callers who need them. (See Item 44)

Monolithic classes dilute encapsulation. When a class has many member functions that don't need to be members but areand therefore have gratuitous visibility to the class's private implementationthen the class's private data members become nearly as bad as public variables.

Monolithic classes usually result from an attempt to predict and deliver a "complete" solution to a problem; in practice, they virtually never succeed. There's always something more that people wantand something less, for that matter.

Monolithic classes are harder to make correct and error-safe because they often tackle multiple responsibilities. (See Items 5 and 44)

Что vector::reserve(count) устанавливает capacity ровно в count, если ему вообще нужно ее менять.
Т.е. каждый следующий reserve() делает realloc, если reserve(24) а потом 24x push_back
Однако! Если bevels таки включены, то reserve-то на 24 а push_back-ов больше

Оказывается...
Что vector::reserve(count) устанавливает capacity ровно в count, если ему вообще нужно ее менять.

std::string ::ToLower() это еще одно выделение памяти и копирование или move (который появился относительно недавно).
std::vector<std::string> ::Split() вообще ужас. Сколько там выделений памяти, копирований? Насколько это все разбросано и не попадет в L2, я думаю, объяснять не надо.
std::string ::printf, по моему мнению, уступает


(ostringstream() << "Hello" << 123).str();


printf нужен только в тех редких случаях, когда есть шаблоны сообщений, и их можно держать отдельно от кода.

prefer to design away downcasting: Refactor or redesign your code so that it isn't needed ...

G>(ostringstream() << "Hello" << 123).str();
G>

String original = L"Blah-blah-blah";
String copy = original;
copy.ToLower();

String original = L"Blah-blah-blah";
original.ToLower();

./configure
make
make install

Examples
Example: basic_string. The standard basic_string is a needlessly monolithic class with
103 member functions—of which 71 could be written as nonmember nonfriends
without loss of efficiency. Many of them duplicate functionality already available as
algorithms, or are themselves algorithms that would be useful more widely if they
weren't buried inside basic_string. (See Items 5 and 32, and [SutterO4].)

std::string item(begin, end);

static const struct partition part = {
    .name = "Boot",
    .start = 100 MBYTE,
    ...
};

class SomethingDoer
{
  static void DoSomething();
}

string s = o as string;
if(s == null)
{
  throw ...
}

string s = (string)o;

While we could make a member function to return length, it is better to make it a global friend function. If we do that, we will be able eventually to define the same function to work on built-in arrays and achieve greater uniformity of design. I made size into a member function in STL in an attempt to please the standard committee. I knew that begin, end and size should be global functions but was not willing to risk another fight with the committee. In general, there were many compromises of which I am ashamed. It would have been harder to succeed without making them, but I still get a metallic taste in my mouth when I encounter all the things that I did wrong while knowing full how to do them right. Success, after all, is much overrated. I will be pointing to the incorrect designs in STL here and there: some were done because of political considerations, but many were mistakes caused by my inability to discern general principles.)

10.3.2 Helper Functions
Typically, a class has a number of functions associated with it that need not be defined in the class itself because they don’t need direct access to the representation. For example:

int diff(Date a,Date b); // number of days in the range [a,b) or [b,a)
bool leapyear(int y);
Date next_weekday(Date d);
Date next_saturday(Date d);

Defining such functions in the class itself would complicate the class interface and increase the number of functions that would potentially need to be examined when a change to the representation was considered. How are such functions "associated" with class Date? Traditionally, their declarations were simply placed in the same file as the declaration of class Date, and users who needed Dates would make them all available by including the file that defined the interface.

Basically my belief is that nonvirtual member functions in general are an unnecessary cutesy in C++ that wahses people's brains, leads to bad programs, and will take many years to wear off. For smart pointers in particular, they can do even more harm.

I'll start with the punchline: If you're writing a function that can be implemented as either a member or as a non-friend non-member, you should prefer to implement it as a non-member function. That decision increases class encapsulation. When you think encapsulation, you should think non-member functions.
Surprised? Read on.

Голые байты на тех сценариях, в которых важно быстродействие memcpy, "перекачивают" блоками фиксированного размера. Это важно и это, действительно, даёт заметный профит

Сейчас единственное улучшение в нашей внутренней STL — это специализация векторов для POD-объектов, которые можно сразу через memcpy копировать.

Да еще ты дал код для копирования через memcpy невыровненных даных...
Какая боль... в обсуждении про то, как важен быстрый memcpy.

При копировании STL вектора для POD-типов в релизе он тоже перекачивает память через MMX/SSE/AVX точно так же, как в тех случаях, когда используются массивы заведомо известного размера.

http://code.metager.de/source/xref/gnu/glibc/sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S

    S1 s2;
    memcpy(&s2, s1, sizeof(S1));
000000013F8D1360  lea         rcx, [s2]
000000013F8D1365  mov         r8d, 2
000000013F8D136B  nop         dword ptr[rax + rax]
000000013F8D1370  vmovups     ymm0, ymmword ptr[rax]
000000013F8D1374  vmovups     ymmword ptr[rcx], ymm0
000000013F8D1378  vmovups     ymm0, ymmword ptr[rax + 20h]
000000013F8D137D  vmovups     ymmword ptr[rcx + 20h], ymm0
000000013F8D1382  vmovups     ymm0, ymmword ptr[rax + 40h]
000000013F8D1387  vmovups     ymmword ptr[rcx + 40h], ymm0
000000013F8D138C  vmovups     xmm0, xmmword ptr[rax + 60h]
000000013F8D1391  vmovups     xmmword ptr[rcx + 60h], xmm0
000000013F8D1396  lea         rcx, [rcx + 80h]
000000013F8D139D  vmovups     xmm1, xmmword ptr[rax + 70h]
000000013F8D13A2  vmovups     xmmword ptr[rcx - 10h], xmm1
000000013F8D13A7  lea         rax, [rax + 80h]
000000013F8D13AE  dec         r8
000000013F8D13B1  jne         main + 100h (013F8D1370h)
/* смотреть сюда: ниже идет прямой код для копирования остатка-хвостика данных, не кратных 128. */
000000013F8D13B3  vmovups     ymm0, ymmword ptr[rax]
000000013F8D13B7  vmovups     ymmword ptr[rcx], ymm0

std::string ::ToLower()
{
  ...
  return buffer; // вот оно то, которое можно избежать
}