В C ++ я плачу за те, що не їмо?

Розглянемо наступні привітні світові приклади в C і C ++:

main.c

#include <stdio.h>

int main()
{
    printf("Hello world\n");
    return 0;
}

main.cpp

#include <iostream>

int main()
{
    std::cout<<"Hello world"<<std::endl;
    return 0;
}

Коли я компілюю їх у godbolt для складання, розмір коду С становить лише 9 рядків ( gcc -O3):

.LC0:
        .string "Hello world"
main:
        sub     rsp, 8
        mov     edi, OFFSET FLAT:.LC0
        call    puts
        xor     eax, eax
        add     rsp, 8
        ret

Але розмір коду C ++ становить 22 рядки ( g++ -O3):

.LC0:
        .string "Hello world"
main:
        sub     rsp, 8
        mov     edx, 11
        mov     esi, OFFSET FLAT:.LC0
        mov     edi, OFFSET FLAT:_ZSt4cout
        call    std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)
        mov     edi, OFFSET FLAT:_ZSt4cout
        call    std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
        xor     eax, eax
        add     rsp, 8
        ret
_GLOBAL__sub_I_main:
        sub     rsp, 8
        mov     edi, OFFSET FLAT:_ZStL8__ioinit
        call    std::ios_base::Init::Init() [complete object constructor]
        mov     edx, OFFSET FLAT:__dso_handle
        mov     esi, OFFSET FLAT:_ZStL8__ioinit
        mov     edi, OFFSET FLAT:_ZNSt8ios_base4InitD1Ev
        add     rsp, 8
        jmp     __cxa_atexit

... що набагато більше.

Відомо, що в С ++ ви платите за те, що їсте. Отже, у такому випадку, за що я плачу?

За що ви платите, це зателефонувати у важку бібліотеку (не настільки важка, як друк на консолі). Ви ініціалізуєтеostream об'єкт. Є кілька прихованих сховищ. Потім ви називаєте, std::endlщо не є синонімом \n. iostreamБібліотека дозволяє регулювати безліч параметрів і покласти навантаження на процесор , а не програміста. Це те, за що ти платиш.

Давайте розглянемо код:

.LC0:
        .string "Hello world"
main:

Ініціалізація потокового об'єкта + cout

    sub     rsp, 8
    mov     edx, 11
    mov     esi, OFFSET FLAT:.LC0
    mov     edi, OFFSET FLAT:_ZSt4cout
    call    std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)

Дзвінок coutЩе раз щоб надрукувати нову лінію та залишити

    mov     edi, OFFSET FLAT:_ZSt4cout
    call    std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
    xor     eax, eax
    add     rsp, 8
    ret

Статична ініціалізація сховища:

_GLOBAL__sub_I_main:
        sub     rsp, 8
        mov     edi, OFFSET FLAT:_ZStL8__ioinit
        call    std::ios_base::Init::Init() [complete object constructor]
        mov     edx, OFFSET FLAT:__dso_handle
        mov     esi, OFFSET FLAT:_ZStL8__ioinit
        mov     edi, OFFSET FLAT:_ZNSt8ios_base4InitD1Ev
        add     rsp, 8
        jmp     __cxa_atexit

Також важливо розрізняти мову та бібліотеку.

До речі, це лише частина історії. Ви не знаєте, що написано у функціях, які ви викликаєте.

Отже, у такому випадку, за що я плачу?

std::cout є більш потужним і складним, ніж printf . Він підтримує такі речі, як локали, державні прапори форматування тощо.

Якщо вони вам не потрібні, використовуйте std::printfабо std::puts- вони доступні в <cstdio>.

Відомо, що в С ++ ви платите за те, що їсте.

Я також хочу дати зрозуміти, що C ++ ! = Стандартна бібліотека C ++. Стандартна бібліотека повинна бути загальноприйнятою та "досить швидкою", але це буде часто повільніше, ніж спеціалізована реалізація того, що вам потрібно.

З іншого боку, мова C ++ прагне дати можливість писати код, не платячи зайві додаткові приховані витрати (наприклад, відмова virtual, відсутність збору сміття).

Ви не порівнюєте C і C ++. Ви порівнюєте printfі std::coutякі здатні до різних речей (локалів, форматів штатів тощо).

Спробуйте використовувати наступний код для порівняння. Godbolt генерує однакову збірку для обох файлів (тестовано з gcc 8.2, -O3).

main.c:

#include <stdio.h>

int main()
{
    int arr[6] = {1, 2, 3, 4, 5, 6};
    for (int i = 0; i < 6; ++i)
    {
        printf("%d\n", arr[i]);
    }
    return 0;
}

main.cpp:

#include <array>
#include <cstdio>

int main()
{
    std::array<int, 6> arr {1, 2, 3, 4, 5, 6};
    for (auto x : arr)
    {
        std::printf("%d\n", x);
    }
}

У ваших списках справді порівнюються яблука та апельсини, але не з тієї причини, що міститься в більшості інших відповідей.

Давайте перевіримо, що насправді робить ваш код:

C:

• надрукувати один рядок, "Hello world\n"

C ++:

• потоковий рядок "Hello world"уstd::cout
• потік std::endlманіпулятора вstd::cout

Мабуть, ваш C ++ код виконує вдвічі більше роботи. Для справедливого порівняння слід поєднати це:

#include <iostream>

int main()
{
    std::cout<<"Hello world\n";
    return 0;
}

… І раптом ваш збірний код на mainвигляд дуже схожий на C:

main:
        sub     rsp, 8
        mov     esi, OFFSET FLAT:.LC0
        mov     edi, OFFSET FLAT:_ZSt4cout
        call    std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)
        xor     eax, eax
        add     rsp, 8
        ret

Насправді ми можемо порівнювати код C і C ++ рядок за рядком, і відмінностей існує дуже мало :

sub     rsp, 8                      sub     rsp, 8
mov     edi, OFFSET FLAT:.LC0   |   mov     esi, OFFSET FLAT:.LC0
                                >   mov     edi, OFFSET FLAT:_ZSt4cout
call    puts                    |   call    std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)
xor     eax, eax                    xor     eax, eax
add     rsp, 8                      add     rsp, 8
ret                                 ret

Єдина реальна відмінність полягає в тому, що в C ++ ми викликаємо operator <<два аргументи ( std::coutі рядок). Ми могли б усунути навіть цю незначну різницю, використовуючи ближчий C eqivalent:, fprintfякий також має перший аргумент, що вказує потік.

Це залишає код складання для _GLOBAL__sub_I_main, який генерується для C ++, але не C. Це єдиний справжній накладний вигляд, який видно в цьому списку збірок (є більше, невидимий накладні витрати для обох звичайно, мов, звичайно). Цей код виконує одноразове налаштування деяких стандартних функцій бібліотеки C ++ на початку програми C ++.

Але, як пояснено в інших відповідях, відповідна різниця між цими двома програмами не знайдеться в монтажному виході mainфункції, оскільки весь важкий підйом відбувається за лаштунками.

Відомо, що в С ++ ви платите за те, що їсте. Отже, у такому випадку, за що я плачу?

Це просто. Ви платите std::cout. "Ви платите лише за те, що їсте" не означає, що "ви завжди отримуєте найкращі ціни". Звичайно, printfдешевше. Можна стверджувати, що std::coutце безпечніше і універсальніше, тому більша його вартість виправдана (вона коштує більше, але забезпечує більшу цінність), але це не вистачає суті. Ви не використовуєте printf, ви використовуєте std::cout, тому ви платите за користування std::cout. Ви не платите за користування printf.

Хороший приклад - віртуальні функції. Віртуальні функції мають певні вимоги до витрат і простору, але лише якщо ви їх фактично використовуєте. Якщо ви не використовуєте віртуальні функції, ви нічого не платите.

Кілька зауважень

1. Навіть якщо C ++ код оцінює більше інструкцій по збірці, це все-таки кілька інструкцій, і будь-які накладні витрати все ще, ймовірно, карбуються фактичними операціями вводу / виводу.

2. Насправді іноді це навіть краще, ніж "у С ++ ви платите за те, що їсте". Наприклад, компілятор може встановити, що виклик віртуальної функції в деяких обставинах не потрібен, і перетворити його в невіртуальний виклик. Це означає , що ви можете отримати віртуальні функції для безкоштовно . Хіба це не чудово?

"Перелік складання для printf" НЕ для printf, а для put (вид оптимізації компілятора?); printf набагато складніше, ніж ставить ... не забувайте!

Я бачу тут кілька вагомих відповідей, але я збираюся трохи детальніше розібратися.

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

Абстракція

Отже, у такому випадку, за що я плачу?

Ви платите за абстракцію . Уміння писати простіший і більш дружній для людини код - це дорога ціна. У C ++, що є об'єктно-орієнтованою мовою, майже все є об'єктом. Коли ви використовуєте будь-який об'єкт, під кришкою завжди будуть три основні речі:

1. Створення об'єкта, в основному розподіл пам'яті для самого об'єкта та його даних.
2. Ініціалізація об'єкта (зазвичай за допомогою якогось init()методу). Зазвичай розподіл пам'яті відбувається під кришкою, як перше, на цьому кроці.
3. Руйнування об'єкта (не завжди).

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

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

Що насправді відбувається в C ++?

Ось вона, розбита:

1. The std::ios_baseКлас инициализируется, який є базовим класом для всього I / O пов'язані між собою .
2. The std::coutОб'єкт инициализируется.
3. Ваша рядок завантажується і передається в те std::__ostream_insert, що (як ви вже з'ясували за назвою) - це метод std::cout(в основному <<оператор), який додає рядок до потоку.
4. cout::endlтакож передається в std::__ostream_insert.
5. __std_dso_handleпередається в __cxa_atexit, що є глобальною функцією, яка відповідає за "очищення" перед виходом з програми. __std_dso_handleсама покликана цією функцією для розселення та знищення інших глобальних об'єктів.

Отже, використовуючи C ==, нічого не платячи?

У коді С відбувається дуже мало кроків:

1. Ваша рядок завантажується та передається putsчерез ediреєстр.
2. puts називається.

Ніде об'єктів немає, отже, не потрібно нічого ініціалізувати / знищувати.

Це , однак , не означає , що ви не «платити» за що в C . Ви все ще платите за абстракцію, а також ініціалізацію стандартної бібліотеки С та динамічну роздільну здатність printfфункцією (або, власне,)puts , оптимізована компілятором, оскільки вам не потрібна будь-яка рядка формату), все ще відбувається під кришкою.

Якби ви писали цю програму чистою збіркою, вона виглядала б приблизно так:

jmp start

msg db "Hello world\n"

start:
    mov rdi, 1
    mov rsi, offset msg
    mov rdx, 11
    mov rax, 1          ; write
    syscall
    xor rdi, rdi
    mov rax, 60         ; exit
    syscall

В основному це призводить лише до виклику write syscall, за яким слід exitsyscall. Тепер це був би найменший мінімум, щоб здійснити те саме.

Узагальнити

C - це набагато голіше , і це лише мінімальний необхідний мінімум, залишаючи повний контроль користувачеві, який здатний повністю оптимізувати та налаштувати все, що завгодно. Ви говорите процесору завантажити рядок у реєстр, а потім викликаєте функцію бібліотеки, щоб використовувати цей рядок. З іншого боку, C ++ є набагато складнішим та абстрактнішим . Це має величезну перевагу при написанні складного коду та дозволяє простіше писати та більш дружній для людини код, але це, очевидно, коштує. Завжди буде недолік продуктивності в C ++, якщо порівнювати з C у таких випадках, оскільки C ++ пропонує більше, ніж потрібно для виконання таких основних завдань, і, таким чином, це додає більше витрат .

Відповідаючи на ваше головне питання :

Я плачу за те, що не їмо?

У цьому конкретному випадку так . Ви не використовуєте нічого, що C ++ може запропонувати більше, ніж C, але це лише тому, що немає нічого в тому простому фрагменті коду, який C ++ міг би вам допомогти: він настільки простий, що C ++ вам взагалі не потрібен.

О, і тільки ще одне!

Переваги C ++ можуть не здаватися очевидними на перший погляд, оскільки ви написали дуже просту і невелику програму, але подивіться на трохи складніший приклад і побачите різницю (обидві програми роблять точно те саме):

C :

#include <stdio.h>
#include <stdlib.h>

int cmp(const void *a, const void *b) {
    return *(int*)a - *(int*)b;
}

int main(void) {
    int i, n, *arr;

    printf("How many integers do you want to input? ");
    scanf("%d", &n);

    arr = malloc(sizeof(int) * n);

    for (i = 0; i < n; i++) {
        printf("Index %d: ", i);
        scanf("%d", &arr[i]);
    }

    qsort(arr, n, sizeof(int), cmp)

    puts("Here are your numbers, ordered:");

    for (i = 0; i < n; i++)
        printf("%d\n", arr[i]);

    free(arr);

    return 0;
}

C ++ :

#include <iostream>
#include <vector>
#include <algorithm>

using namespace std;

int main(void) {
    int n;

    cout << "How many integers do you want to input? ";
    cin >> n;

    vector<int> vec(n);

    for (int i = 0; i < vec.size(); i++) {
        cout << "Index " << i << ": ";
        cin >> vec[i];
    }

    sort(vec.begin(), vec.end());

    cout << "Here are your numbers:" << endl;

    for (int item : vec)
        cout << item << endl;

    return 0;
}

Сподіваємось, ви чітко бачите, що я тут маю на увазі. Також зауважте, як у C ви повинні керувати пам'яттю на нижчому рівні, використовуючи, mallocі freeяк вам потрібно бути більш уважними щодо індексації та розмірів, і як вам потрібно бути дуже конкретними при введенні даних та друку.

Є кілька помилок, для початку. По-перше, програма C ++ не дає 22 інструкцій, це більше схоже на 22 000 з них (я витягнув це число з капелюха, але він приблизно знаходиться в бальній частині). Також код С не призводить до 9 інструкцій. Це лише ті, кого ти бачиш.

Що робить код C, це те, що він робить багато речей, які ви не бачите, він викликає функцію з CRT (яка зазвичай, але не обов'язково присутня як спільна lib), а потім не перевіряє повернене значення чи обробку помилки та виправлення. Залежно від параметрів компілятора та оптимізації, він навіть не викликає, printfале putsщось ще примітивніше.
Ви могли також написати більш-менш ту саму програму (за винятком деяких невидимих ​​функцій init) і в C ++, якби тільки та сама функція викликала ту саму функцію. Або, якщо ви хочете бути надто правильним, ця сама функція має префікс std::.

Відповідний код C ++ насправді зовсім не те саме. Хоча все <iostream>це добре відоме тим, що є товстою потворною свинею, яка додає величезних накладних витрат на невеликі програми (у "справжній" програмі ви насправді не так багато помічаєте), дещо справедливіша інтерпретація полягає в тому, що вона робить жахливою багато чого, що ви не бачите і який просто працює . Включаючи, але не обмежуючись, магічне форматування майже будь-яких випадкових речей, включаючи різні формати чисел та локалі та щось подібне, буферизацію та правильне поводження з помилками. Помилка обробки? Ну так, вгадайте, що, виведення рядка може насправді не вдатися, і на відміну від програми C, програма C ++ не буде ігнорувати це мовчки. Враховуючи, щоstd::ostreamробить під кришкою, і не знаючи нікого, це насправді досить легка вага. Не так, як я його використовую, бо ненавиджу синтаксис потоку із пристрастю. Але все ж, це досить приголомшливо, якщо врахувати, що це робить.

Але звичайно, C ++ в цілому не настільки ефективний, як C. Він не може бути настільки ефективним, оскільки це не те саме, і це не те саме. Якщо нічого іншого, C ++ створює винятки (і код для їх генерування, обробки або відмови), і він дає певні гарантії, які C не дає. Тож, звичайно, щось на зразок програми C ++ обов'язково має бути трохи більшим. Однак у великій картині це ніяк не має значення. Навпаки, по- справжньому програм я не рідко виявляв, що C ++ працює краще, тому що з тих чи інших причин, здається, надаються позитивніші оптимізації. Не питайте мене, чому, зокрема, я б не знав.

Якщо замість вогню і забути-сподіватися на найкраще ви дбаєте написати код C, який є правильним (тобто ви фактично перевіряєте наявність помилок, і програма поводиться правильно при наявності помилок), то різниця незначна, за наявності.

Ви платите за помилку. У 80-х, коли компілятори недостатньо добре перевіряють рядки формату, перевантаження оператора розглядалося як хороший спосіб забезпечити певний вигляд безпеки типу під час io. Однак кожна з її банерних функцій з самого початку реалізована погано або концептуально збанкрутіла:

<іоманіп>

Найвідповідальнішою частиною потоку C ++ io api є існування цієї бібліотеки форматування заголовків. Окрім того, що є гідним та некрасивим та схильним до помилок, він підключає форматування до потоку.

Припустимо, ви хочете роздрукувати рядок з 8-значним нульовим значенням, заповненим шістнадцятковим неподписаним int, а потім пробілом, а потім подвійним з 3-ма десятковими знаками. З <cstdio>, ви можете прочитати стислий рядок формату. З <ostream>, вам потрібно зберегти старий стан, встановити вирівнювання праворуч, встановити символ заповнення, встановити ширину заповнення, встановити базу в шестигранну, вивести ціле число, відновити збережений стан (інакше ваше ціле форматування забруднить ваше плавання формату), виведіть простір , встановіть позначення на фіксовану, встановіть точність, виведіть подвійний і новий рядок, а потім відновіть старе форматування.

// <cstdio>
std::printf( "%08x %.3lf\n", ival, fval );

// <ostream> & <iomanip>
std::ios old_fmt {nullptr};
old_fmt.copyfmt (std::cout);
std::cout << std::right << std::setfill('0') << std::setw(8) << std::hex << ival;
std::cout.copyfmt (old_fmt);
std::cout << " " << std::fixed << std::setprecision(3) << fval << "\n";
std::cout.copyfmt (old_fmt);

Перевантаження оператора

<iostream> є дочіркою плаката про те, як не використовувати перевантаження оператора:

std::cout << 2 << 3 && 0 << 5;

Продуктивність

std::coutв кілька разів повільніше printf(). Насичений Featuritis і віртуальна відправка дійсно має своє значення.

Безпека нитки

І те <cstdio>й <iostream>інше є безпечним, оскільки кожен виклик функції є атомним. Але, printf()отримує набагато більше за один дзвінок. Якщо запустити наступну програму з <cstdio>опцією, ви побачите лише рядок f. Якщо ви використовуєте <iostream>багатоядерну машину, ви, ймовірно, побачите щось інше.

// g++ -Wall -Wextra -Wpedantic -pthread -std=c++17 cout.test.cpp

#define USE_STREAM 1
#define REPS 50
#define THREADS 10

#include <thread>
#include <vector>

#if USE_STREAM
    #include <iostream>
#else
    #include <cstdio>
#endif

void task()
{
    for ( int i = 0; i < REPS; ++i )
#if USE_STREAM
        std::cout << std::hex << 15 << std::dec;
#else
        std::printf ( "%x", 15);
#endif

}

int main()
{
    auto threads = std::vector<std::thread> {};
    for ( int i = 0; i < THREADS; ++i )
        threads.emplace_back(task);

    for ( auto & t : threads )
        t.join();

#if USE_STREAM
        std::cout << "\n<iostream>\n";
#else
        std::printf ( "\n<cstdio>\n" );
#endif
}

Цей приклад полягає в тому, що більшість людей проявляють дисципліну, щоб ніколи не писати в один дескриптор файлу з декількох потоків. Ну, і в такому випадку вам доведеться зауважити, що <iostream>допоможе захопити замок на <<кожного >>. В той час як <cstdio>ви не будете блокувати так часто, і навіть у вас є можливість не блокувати.

<iostream> витрачає більше блокувань для досягнення менш стійкого результату.

На додаток до того , що всі інші відповіді сказали,
є також той факт , що std::endlце НЕ те ж саме , як '\n'.

Це, на жаль, поширена помилка. std::endlне означає "новий рядок",
це означає "надрукувати новий рядок і потім промити потік ". Промивання не з дешевих!

Повністю ігноруючи відмінності між printfі std::coutна мить, щоб бути функціонально еквівалентним вашому прикладу C, ваш приклад C ++ повинен виглядати так:

#include <iostream>

int main()
{
    std::cout << "Hello world\n";
    return 0;
}

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

С

#include <stdio.h>

int main()
{
    printf("Hello world\n");
    fflush(stdout);
    return 0;
}

C ++

#include <iostream>

int main()
{
    std::cout << "Hello world\n";
    std::cout << std::flush;
    return 0;
}

Порівнюючи код, ви завжди повинні бути обережними, що ви порівнюєте, як за подібне, і щоб ви розуміли наслідки того, що робить ваш код. Іноді навіть найпростіші приклади складніші, ніж деякі люди усвідомлюють.

Хоча існуючі технічні відповіді правильні, я вважаю, що питання в кінцевому підсумку випливає з цієї помилки:

Відомо, що в С ++ ви платите за те, що їсте.

Це лише маркетингові бесіди від спільноти C ++. (Справедливо кажучи, в усіх мовних спільнотах ведуться маркетингові розмови.) Це не означає нічого конкретного, від якого можна серйозно залежати.

"Ви платите за те, що використовуєте", означає, що функція C ++ має накладні витрати лише тоді, коли ви використовуєте цю функцію. Але визначення "ознаки" не є нескінченно детальним. Часто ви в кінцевому підсумку активуєте функції, які мають декілька аспектів, і хоча вам потрібен лише підмножина цих аспектів, часто реалізація цієї функції частково не практична або неможлива.

Загалом, багато (хоча і не всі) мови прагнуть бути ефективними з різним ступенем успіху. C ++ десь на масштабі, але в його дизайні немає нічого особливого чи магічного, що дозволило б досягти успіху в цій цілі.

Функції вводу / виводу в C ++ написані елегантно та розроблені таким чином, що вони прості у використанні. Багато в чому вони є вітриною об'єктно-орієнтованих функцій на C ++.

Але ви справді відмовляєтеся від невеликої продуктивності натомість, але це мізерно порівняно із часом, який ваша операційна система зайняла для роботи з функціями на нижчому рівні.

Ви завжди можете повернутися до функцій стилю C, оскільки вони є частиною стандарту C ++, або, можливо, взагалі відмовитися від переносимості та використовувати прямі дзвінки в операційну систему.

Як ви бачили в інших відповідях, ви платите, коли ви посилаєтесь на загальні бібліотеки та виклику складних конструкторів. Тут немає особливого питання, більше захоплення. Я зазначу деякі аспекти реального світу:

1. Барн мав основний принцип дизайну, щоб ніколи не дозволяти ефективності бути причиною для перебування в C, а не C ++. Зважаючи на це, потрібно бути обережними, щоб досягти цієї ефективності, і є випадкові ефективність, яка завжди працювала, але не була "технічно" в специфікаціях C. Наприклад, макет бітових полів насправді не вказаний.

2. Спробуйте переглядати ostream. О мій боже його роздутий! Я не був би здивований, коли знайшов там симулятор польоту. Навіть stdlib's printf () зазвичай працює близько 50K. Це не ліниві програмісти: половина розміру printf стосувалася непрямих аргументів точності, якими більшість людей ніколи не користується. Практично кожна бібліотека дійсно обмежених процесорів створює власний вихідний код замість printf.

3. Збільшення розмірів, як правило, забезпечує більш обмежений та гнучкий досвід. Як аналогія, торговий автомат продасть чашку кавоподібної речовини за кілька монет, і вся транзакція займає менше хвилини. Заїзд у хороший ресторан передбачає сервірування столу, сидіння, замовлення, очікування, отримання гарної чашки, отримання рахунку, оплата за ваш вибір форм, додавання чайових напоїв та побажання гарного дня на виході. Це інший досвід і зручніше, якщо ви завітаєте з друзями за складною їжею.

4. Люди все ще пишуть ANSI C, хоча рідко K&R C. Мій досвід - ми завжди компілюємо його за допомогою компілятора C ++, використовуючи кілька налаштувань конфігурації, щоб обмежити те, що перетягується. Є хороші аргументи для інших мов: Go видаляє поліморфні накладні та шалений препроцесор ; було кілька хороших аргументів щодо розумнішої упаковки поля та компонування пам’яті. ІМХО Я думаю, що будь-який мовний дизайн повинен починатися з переліку цілей, як і Дзен Пітона .

Це була весела дискусія. Ви запитуєте, чому ви не можете мати магічно малі, прості, елегантні, повні та гнучкі бібліотеки?

Відповіді немає. Відповіді не буде. Це відповідь.