Ця інформація вже застаріла, бо є

#pragma once

Усі мейнстріймові компілери підтримують цю опцію.

І напишіть ще про нічні жахи програмістів - мадярська нотація для найменувань змінних. І чому заголовкові файли вінди використовують чудернацькі типи даних? (Бо вона писалася до стандартизації сєй)

Файна стаття, дякую.

Та кілька монеток вставлю:

Отут не погоджуся. Якщо код попаде до іншого програміста, є ризик, що він сплутає аббревіатуру зі скороченням всередині назви.

Якби стаття присвячувалася Пітону, я б зрозумів таке. Але який сенс на хрестах? Контроль доступу до полів визначається на етапі компіляції, і спроба прямого втручання у приват ззовні викличе бугурт компілятора.

Якщо недоля спричинила нестачу уяви, то просто додайте води this.

Плюс у карму. Порушення цього положення викликало у мене певний ступор під час переходу від qt до fltk, а потім до wxWidgets.

calcSmth, countSmth, processSmth - залежно, що саме рахує і яким чином.

Знову я єретик-ортодокс, по ходу...

Поки я пишу під віндою, такий стиль (крім .c++ - лолват?) прийнятний. А під іксами ліпше брати .hxx, .cxx, які умовно покажуть, що програма написанна саме для іксових систем.

А як же inline-методи? Якщо метод описати прямо у заголовку, він стає inline автоматично, і якщо там щось просте типу setMyField(F* f){field = f;}, то який сенс засмічувати код сирця такими прищами?

Згоден, крім табуляції: її розмір у пробілах дозволяють регулювати чи не всі нормальні редактори.

Зайва операція - зайві проблеми, особливо якщо не є необхідною.

Знову падіння продуктивності. Не так уже й складно зрозуміти, що предикат у блоці if - це неявний bool. Плюс граблі, якщо забути "==" замість "="...

Імго, кожній конструкції - своя сфера використання.

о_О?

____

Якось так.

А якщо цикл написаний якраз особисто для Ктулху з метою створення якогось тайм-аута/затримки?

for(;;)
{
    Sleep(n);
    if( wakeUpDude())
        break;
}

Не дійдемо. Пригадую, що читав про загальноприйнятість .*xx назв для систем сімейства Unix серед цпп-розробників.

За таку класику халтуру треба молотком відбивати пальці. І Кент Бек буде першим у черзі на отримання молотка для цього.

Ну і яка ймовірність того, що ви попадете на систему, де не буде навіть vim'а чи ще чогось езотеричнішого?

Довелося мені у недалекому минулому ваяти синтаксичний аналізатор текстових файлів. Мушу сказати, що поняття продуктивності нікуди не пропадало, особливо коли брався набір із порядка 1000 файлів по кількасот кб кожен.
Оптимізатор - теж дуже умовна річ. Можливо, програміст хотів ув одному моменті робити більше речей прямо у регістрах процесора, а оптимізатор вирішить по-своєму, бо є універсальним, а все універсальне - це лише матсподівання...

Якось я пропустив період, коли do-while слід було використовувати повсюдно.

Best. Тут визнаю переваги do-while над for(;;) для даної задачі.

Стосовно оптимізації: спробуйте скопмілювати

  clock_t start=clock();
  int t=1;
  for(int i=0;i<1000000;i++)t=t*2+1;
  clock_t time1=clock()-start;
  t=1;
  for(int i=0;i<1000000;i++)t=(t<<1)|1;
  clock_t time2=clock()-time1;
  cout << "operation 1:" << time1 <<" operation 2:" <<time2;

і відпишіться по результатах...

По коду:

#include <cstdio>
#include <ctime>

int main()
{
    clock_t start = clock();
    
    int t = 1;
    
    for(int i = 0; i<1000000; i++)
        t = t*2 + 1;
    clock_t time1=clock()-start;
    t = 1;
    
    for(int i = 0; i<1000000; i++)
        t = (t<<1)|1;
    clock_t time2 = clock() - time1;
    printf("operation 1: %u\noperation 2: %u\n", time1, time2);
    
    return 0;
}

Тут двояка тема - з одного боку дійсно воно швидше, бо використовуються команди shl/shr, а з іншого якщо компілятору так писати, то чи не леше принаймні частину проекта написати мовою асемблера і злінкувати усе разом або ж інлайн-ассемблером скористатись?

P.S.
Високорівневі кодери будуть гадати на кавовій гущи, а повний опис причини швидкості того коду можливо побачити лише порівнявши згенеровані асм лістинги декількох мейнстріймових компіляторів із різними опціями.

ці дрібні "оптимізації" на кшталт заміни *2 на <<1 чи пропускання ==0 ніц не оптимізують

Найдурніше те, що вони оптимізують, тому на джерельні коди С для 8051 процесора без сліз не глянеш. Хоча доки ви не майните біткойни/ламаєте хеш/створюєте 3д гру воно несуттєво впливає на результат. Принаймні VC++ 2010 прості як двері. Мабуть я створю статтю з порівнянням оптимізацій різних алгоритмів/різних процесорів, бо вмію реверс інженерити.

Приклад 1
Чому в дупу п'яний кодер, що знає лише одну двадцяту частину машинних команд, створює за один прохід асемблерний лістинг оптимальніший за багатопрохідні вумні компілятори С++ для процесорів архітектури х86?
Відповідь полягає в регістровій архітектурі х86 процесора. Найшвидше процесор робить операції саме із регістрами. Регістрів загального значення небагато (EAX, EBX, ECX, EDX, EDI, ESI) і на всі змінні їх не вистачає. До того ж регістри EDI, ESI, ECX використовуються для копіювання/порівняння, тому компілятори часто їх не використовують. Команда ділення/множення впливає на регістри EAX, EDX. Тому в більшості випадків компілятор зберігає змінні не у регістрах, а в пам'яті, іноді копіюючи їх у регістри для різних операцій і результат.. записує знову в па'мять. Тобто компіляторний лістинг буде повільнішим відсотків на 100% за асемблерний лістинг старого алконафта тільки через відсутність нормального розподілу регістрів. Людина має інтуїцію і вміє розкладувати пас'янcи краще за комп'ютер. Але це стосується лише CISC архітектури й х86 зокрема.
Стосовно оптимізації для 8051 архітектури напишу трохи згодом.