In C ++, sto pagando per quello che non sto mangiando?

Consideriamo i seguenti esempi di ciao mondo in C e 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;
}

Quando li compilo in godbolt in assembly, la dimensione del codice C è solo 9 righe ( gcc -O3):

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

Ma la dimensione del codice C ++ è di 22 righe ( 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

... che è molto più grande.

È famoso che in C ++ paghi per quello che mangi. Quindi, in questo caso, per cosa sto pagando?

Quello che stai pagando è chiamare una libreria pesante (non pesante come stampare sulla console). Si inizializza un ostreamoggetto. Ci sono alcuni archivi nascosti. Quindi, chiami per il std::endlquale non è sinonimo \n. La iostreamlibreria ti aiuta a regolare molte impostazioni e a mettere il carico sul processore anziché sul programmatore. Questo è ciò per cui stai pagando.

Rivediamo il codice:

.LC0:
        .string "Hello world"
main:

Inizializzazione di un oggetto ostream + 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)

Richiamo di coutnuovo per stampare una nuova linea e svuotare

    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

Inizializzazione archiviazione statica:

_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

Inoltre, è essenziale distinguere tra la lingua e la biblioteca.

A proposito, questa è solo una parte della storia. Non sai cosa è scritto nelle funzioni che stai chiamando.

Quindi, in questo caso, per cosa sto pagando?

std::coutè più potente e complicato di printf. Supporta cose come locali, flag di formattazione con stato e altro.

Se non ti servono, usa std::printfo std::puts- sono disponibili in <cstdio>.

È famoso che in C ++ paghi per quello che mangi.

Voglio anche chiarire che C ++ ! = La libreria standard C ++. La libreria standard dovrebbe essere di uso generale e "abbastanza veloce", ma spesso sarà più lenta di un'implementazione specializzata di ciò di cui hai bisogno.

D'altra parte, il linguaggio C ++ si sforza di rendere possibile la scrittura di codice senza pagare costi nascosti extra non necessari (ad esempio opt-in virtual, nessuna raccolta dei rifiuti).

Non stai confrontando C e C ++. Stai confrontando printfe std::cout, che sono in grado di cose diverse (locali, formattazione con stato, ecc.).

Prova a utilizzare il seguente codice per il confronto. Godbolt genera lo stesso assembly per entrambi i file (testato con 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);
    }
}

Le tue inserzioni stanno effettivamente confrontando mele e arance, ma non per il motivo implicito nella maggior parte delle altre risposte.

Controlliamo cosa fa effettivamente il tuo codice:

C:

• stampare una singola stringa, "Hello world\n"

C ++:

• eseguire lo streaming della stringa "Hello world"instd::cout
• flusso del std::endlmanipolatore instd::cout

Apparentemente il tuo codice C ++ sta facendo il doppio del lavoro. Per un confronto equo dovremmo combinare questo:

#include <iostream>

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

... e all'improvviso il tuo codice assembly mainsembra molto simile a quello di 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

In effetti, possiamo confrontare il codice C e C ++ riga per riga e ci sono pochissime differenze :

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

L'unica vera differenza è che in C ++ chiamiamo operator <<con due argomenti ( std::coute la stringa). Potremmo rimuovere anche quella leggera differenza usando un C eqivalent più vicino: fprintfche ha anche un primo argomento che specifica il flusso.

Questo lascia il codice assembly per _GLOBAL__sub_I_main , che viene generato per C ++ ma non C. Questo è l'unico vero overhead visibile in questo elenco di assembly (c'è altro overhead invisibile per entrambi ovviamente lingue). Questo codice esegue un'installazione singola di alcune funzioni di libreria standard C ++ all'avvio del programma C ++.

Ma, come spiegato in altre risposte, la differenza rilevante tra questi due programmi non si troverà nell'output di assemblaggio della mainfunzione poiché tutto il sollevamento pesante avviene dietro le quinte.

È famoso che in C ++ paghi per quello che mangi. Quindi, in questo caso, per cosa sto pagando?

È semplice. Paghi per std::cout. "Paghi solo ciò che mangi" non significa "ottieni sempre i prezzi migliori". Certo, printfè più economico. Si può affermare che std::coutè più sicuro e più versatile, quindi il suo maggior costo è giustificato (costa di più, ma fornisce più valore), ma ciò non vale. Non usi printf, usi std::cout, quindi paghi per l'utilizzo std::cout. Non paghi per l'utilizzo printf.

Un buon esempio sono le funzioni virtuali. Le funzioni virtuali hanno alcuni costi di runtime e requisiti di spazio, ma solo se effettivamente utilizzati. Se non usi le funzioni virtuali, non paghi nulla.

Alcune osservazioni

1. Anche se il codice C ++ restituisce ulteriori istruzioni di assemblaggio, è ancora una manciata di istruzioni e qualsiasi sovraccarico di prestazioni è comunque ridotto dalle effettive operazioni di I / O.

2. In realtà, a volte è persino meglio di "in C ++ paghi per quello che mangi". Ad esempio, il compilatore può dedurre che la chiamata di funzione virtuale non è necessaria in alcune circostanze e trasformarla in chiamata non virtuale. Ciò significa che potresti ottenere funzioni virtuali gratuitamente . Non è fantastico?

La "lista assembly per printf" NON è per printf, ma per put (tipo di ottimizzazione del compilatore?); printf è molto più complesso di quanto metta ... non dimenticare!

Vedo alcune risposte valide qui, ma ho intenzione di approfondire un po 'di più i dettagli.

Vai al riepilogo di seguito per la risposta alla tua domanda principale se non vuoi passare attraverso questa intera parete di testo.

Astrazione

Quindi, in questo caso, per cosa sto pagando?

Stai pagando per l' astrazione . Essere in grado di scrivere un codice più semplice e più umano ha un costo. In C ++, che è un linguaggio orientato agli oggetti, quasi tutto è un oggetto. Quando usi qualsiasi oggetto, tre cose principali succederanno sempre sotto il cofano:

1. Creazione di oggetti, sostanzialmente allocazione di memoria per l'oggetto stesso e i suoi dati.
2. Inizializzazione dell'oggetto (di solito tramite un init()metodo). Di solito l'allocazione della memoria avviene sotto il cofano come prima cosa in questo passaggio.
3. Distruzione di oggetti (non sempre).

Non lo vedi nel codice, ma ogni volta che usi un oggetto tutte e tre le cose sopra devono accadere in qualche modo. Se dovessi fare tutto manualmente, il codice sarebbe ovviamente molto più lungo.

Ora, l'astrazione può essere realizzata in modo efficiente senza aggiungere spese generali: il metodo inline e altre tecniche possono essere utilizzate sia dai compilatori che dai programmatori per rimuovere le spese generali di astrazione, ma non è questo il caso.

Cosa sta realmente succedendo in C ++?

Eccolo, suddiviso:

1. La std::ios_baseclasse è inizializzata, che è la classe base per tutto ciò che riguarda l'I / O.
2. L' std::coutoggetto è inizializzato.
3. La tua stringa viene caricata e passata a std::__ostream_insert, che (come hai già capito con il nome) è un metodo di std::cout(sostanzialmente l' <<operatore) che aggiunge una stringa al flusso.
4. cout::endlviene anche passato a std::__ostream_insert.
5. __std_dso_handleviene passato a __cxa_atexit, che è una funzione globale responsabile della "pulizia" prima di uscire dal programma. __std_dso_handlestesso viene chiamato da questa funzione per deallocare e distruggere gli oggetti globali rimanenti.

Quindi usando C == non pagando nulla?

Nel codice C, stanno accadendo pochissimi passaggi:

1. La tua stringa viene caricata e passata putstramite il ediregistro.
2. puts viene chiamato.

Nessun oggetto da nessuna parte, quindi non è necessario inizializzare / distruggere nulla.

Questo però non significa che non stai "pagare" per nulla C . Stai ancora pagando per l'astrazione, e anche l'inizializzazione della libreria standard C e la risoluzione dinamica della printffunzione (o, in realtà puts, che è ottimizzata dal compilatore poiché non hai bisogno di alcuna stringa di formato) avvengono ancora sotto il cofano.

Se dovessi scrivere questo programma in puro assemblaggio sarebbe simile a questo:

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

Il che in pratica si traduce solo in invocazione della write syscall seguita dalla exitsyscall. Ora questo sarebbe il minimo indispensabile per realizzare la stessa cosa.

Riassumere

C è molto più semplice e fa solo il minimo indispensabile, lasciando il pieno controllo all'utente, che è in grado di ottimizzare completamente e personalizzare praticamente tutto ciò che vogliono. Dite al processore di caricare una stringa in un registro e quindi chiamate una funzione di libreria per usare quella stringa. Il C ++ invece è molto più complesso e astratto . Questo ha un enorme vantaggio quando si scrive un codice complicato e consente una scrittura più semplice e un codice più umano, ma ovviamente ha un costo. Ci sarà sempre uno svantaggio in termini di prestazioni in C ++ se confrontato con C in casi come questo, poiché C ++ offre più di quanto è necessario per svolgere tali compiti di base e quindi aggiunge più sovraccarico .

Rispondere alla domanda principale :

Sto pagando per quello che non sto mangiando?

In questo caso specifico, sì . Non stai sfruttando nulla di ciò che C ++ ha da offrire oltre a C, ma è solo perché non c'è niente in quel semplice pezzo di codice con cui C ++ potrebbe aiutarti: è così semplice che non hai davvero bisogno del C ++.

Oh, e solo un'altra cosa!

I vantaggi del C ++ potrebbero non sembrare ovvi a prima vista, poiché hai scritto un programma molto semplice e piccolo, ma guarda un esempio un po 'più complesso e vedi la differenza (entrambi i programmi fanno esattamente la stessa cosa):

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;
}

Spero che tu possa vedere chiaramente cosa intendo qui. Nota anche come in C devi gestire la memoria a un livello inferiore usando malloce freecome devi essere più attento riguardo all'indicizzazione e alle dimensioni, e come devi essere molto specifico quando prendi input e stampa.

Ci sono alcune idee sbagliate per cominciare. Innanzitutto, il programma C ++ non porta a 22 istruzioni, è più simile a 22.000 (ho estratto quel numero dal mio cappello, ma è approssimativamente nel campo di baseball). Inoltre, il codice C non risulta in 9 istruzioni. Quelli sono solo quelli che vedi.

Ciò che fa il codice C è, dopo aver fatto molte cose che non vedi, chiama una funzione dal CRT (che di solito è ma non necessariamente presente come lib condivisa), quindi non controlla il valore restituito o gestisce errori e salvataggi. A seconda del compilatore e delle impostazioni di ottimizzazione, non si chiama nemmeno davvero , printfma puts, o qualcosa di ancora più primitivo.
Avresti potuto scrivere più o meno lo stesso programma (ad eccezione di alcune funzioni invisibili di init) anche in C ++, se solo avessi chiamato la stessa funzione nello stesso modo. Oppure, se si desidera essere super corretti, è stata aggiunta la stessa funzione con il prefisso std::.

Il corrispondente codice C ++ non è in realtà la stessa cosa. Mentre tutto <iostream>è ben noto per essere un brutto maiale grasso che aggiunge un immenso sovraccarico per piccoli programmi (in un programma "reale" non si nota molto), un'interpretazione un po 'più giusta è che fa un terribile molte cose che non vedi e che funzionano . Incluso ma non limitato alla formattazione magica di praticamente qualsiasi cosa casuale, compresi diversi formati numerici e locali e quant'altro, buffering e corretta gestione degli errori. Gestione degli errori? Bene sì, indovina un po ', l'output di una stringa può effettivamente fallire e, diversamente dal programma C, il programma C ++ non ignorerebbe silenziosamente. Considerando cosastd::ostreamfa sotto il cofano, e senza che nessuno se ne accorga, è in realtà piuttosto leggero. Non come se lo usassi perché odio la sintassi del flusso con passione. Tuttavia, è davvero fantastico se si considera ciò che fa.

Ma certo, C ++ nel complesso non è efficiente quanto C può essere. Non può essere così efficiente poiché non è la stessa cosa e non sta facendo la stessa cosa. Se non altro, C ++ genera eccezioni (e codice per generare, gestire o fallire su di esse) e offre alcune garanzie che C non dà. Quindi, certo, un programma C ++ deve necessariamente essere un po 'più grande. Nel quadro generale, tuttavia, questo non ha importanza in alcun modo. Al contrario, per i programmi reali , raramente non ho trovato le prestazioni del C ++ migliori perché, per un motivo o per l'altro, sembra prestare ottimizzazioni più favorevoli. Non chiedermi perché, in particolare, non lo saprei.

Se, invece di sparare e dimenticare la speranza per il meglio, ti interessa scrivere il codice C che è corretto (cioè controlli effettivamente gli errori e il programma si comporta correttamente in presenza di errori), allora la differenza è marginale, se esistente.

Stai pagando per un errore. Negli anni '80, quando i compilatori non erano abbastanza buoni per controllare le stringhe di formato, il sovraccarico dell'operatore era visto come un buon modo per applicare una parvenza di sicurezza del tipo durante io. Tuttavia, ognuna delle sue funzionalità di banner è implementata male o concettualmente fallita dall'inizio:

<Iomanip>

La parte più ripugnante del flusso C ++ io api è l'esistenza di questa libreria di intestazioni di formattazione. Oltre ad essere stato brutto e soggetto a errori, accoppia la formattazione allo stream.

Supponiamo di voler stampare una riga con int esadecimale senza segno a 8 cifre senza segno seguita da uno spazio seguito da un doppio con 3 cifre decimali. Con <cstdio>, puoi leggere una stringa di formato concisa. Con <ostream>, devi salvare il vecchio stato, impostare l'allineamento a destra, impostare il carattere di riempimento, impostare la larghezza di riempimento, impostare la base su esadecimale, generare l'intero, ripristinare lo stato salvato (altrimenti la formattazione dei numeri interi inquinerà la formattazione float), genera lo spazio , imposta la notazione su fixed, imposta la precisione, stampa il double e il newline, quindi ripristina la vecchia formattazione.

// <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);

Sovraccarico dell'operatore

<iostream> è il bambino poster di come non utilizzare il sovraccarico dell'operatore:

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

Prestazione

std::coutè più volte più lento printf(). La featuritis dilagante e l'invio virtuale fanno la differenza.

Sicurezza del filo

Entrambi <cstdio>e <iostream>sono thread-safe in quanto ogni chiamata di funzione è atomica. Ma printf()ottiene molto di più per chiamata. Se esegui il seguente programma con l' <cstdio>opzione, vedrai solo una riga di f. Se lo usi <iostream>su una macchina multicore, probabilmente vedrai qualcos'altro.

// 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
}

La risposta a questo esempio è che la maggior parte delle persone esercita la disciplina per non scrivere mai su un singolo descrittore di file da più thread in ogni caso. Beh, in questo caso, dovrete osservare che <iostream>saranno utilmente prendere un blocco su ogni <<singolo >>. Considerando <cstdio>che, non si bloccherà più spesso e si ha anche la possibilità di non bloccare.

<iostream> spende più blocchi per ottenere un risultato meno coerente.

Oltre a ciò che hanno detto tutte le altre risposte,
c'è anche il fatto che nonstd::endl è la stessa .'\n'

Questo è purtroppo un malinteso comune. std::endlnon significa "nuova riga",
significa "stampa una nuova riga e quindi svuota il flusso ". Il lavaggio non è economico!

Ignorando completamente le differenze tra printfe std::coutper un momento, per essere funzionalmente eqvuialent al tuo esempio C, il tuo esempio C ++ dovrebbe assomigliare a questo:

#include <iostream>

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

Ed ecco un esempio di come dovrebbero essere i tuoi esempi se includi il flushing.

C

#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;
}

Quando si confronta il codice, si dovrebbe sempre fare attenzione a confrontare like per like e comprendere le implicazioni di ciò che il codice sta facendo. A volte anche gli esempi più semplici sono più complicati di quanto alcuni credano.

Mentre le risposte tecniche esistenti sono corrette, penso che la domanda alla fine derivi da questo malinteso:

È famoso che in C ++ paghi per quello che mangi.

Questo è solo un discorso di marketing della comunità C ++. (Per essere onesti, ci sono discorsi di marketing in ogni comunità linguistica.) Non significa nulla di concreto da cui poter seriamente dipendere.

"Paghi per quello che usi" dovrebbe significare che una funzione C ++ ha un sovraccarico solo se la usi. Ma la definizione di "caratteristica" non è infinitamente granulare. Spesso finirai per attivare funzionalità con molteplici aspetti e anche se hai solo bisogno di un sottoinsieme di tali aspetti, spesso non è pratico o possibile per l'implementazione includere parzialmente la funzionalità.

In generale, molte lingue (sebbene probabilmente non tutte) si sforzano di essere efficienti, con vari gradi di successo. Il C ++ è da qualche parte nella scala, ma non c'è nulla di speciale o magico nel suo design che gli permetta di avere perfettamente successo in questo obiettivo.

Le funzioni di Input / Output in C ++ sono elegantemente scritte e progettate in modo da essere semplici da usare. Per molti aspetti sono una vetrina per le funzionalità orientate agli oggetti in C ++.

Ma in effetti si rinuncia a un po 'di prestazioni in cambio, ma questo è trascurabile rispetto al tempo impiegato dal sistema operativo per gestire le funzioni a un livello inferiore.

Puoi sempre ricorrere alle funzioni di stile C poiché fanno parte dello standard C ++, o forse rinunciare del tutto alla portabilità e utilizzare le chiamate dirette al tuo sistema operativo.

Come hai visto in altre risposte, paghi quando ti colleghi a librerie generali e chiami costruttori complessi. Non c'è una domanda particolare qui, più una lamentela. Indico alcuni aspetti del mondo reale:

1. Barne aveva un principio progettuale fondamentale per non lasciare che l'efficienza fosse un motivo per rimanere in C piuttosto che in C ++. Detto questo, bisogna fare attenzione a ottenere queste efficienze e ci sono efficienze occasionali che hanno sempre funzionato ma non erano "tecnicamente" all'interno delle specifiche C. Ad esempio, il layout dei campi di bit non è stato specificato.

2. Prova a guardare attraverso ostream. Oh mio Dio, è gonfio! Non sarei sorpreso di trovare un simulatore di volo lì dentro. Anche stdlib's printf () di solito esegue circa 50K. Questi non sono programmatori pigri: metà della dimensione di printf aveva a che fare con argomenti di precisione indiretti che la maggior parte delle persone non usa mai. Quasi tutte le librerie del processore veramente vincolate creano il proprio codice di output anziché printf.

3. L'aumento delle dimensioni di solito fornisce un'esperienza più contenuta e flessibile. Per analogia, un distributore automatico venderà una tazza di sostanza simile al caffè per poche monete e l'intera transazione richiederà meno di un minuto. Entrare in un buon ristorante implica un tavolo, sedersi, ordinare, aspettare, prendere una bella tazza, ottenere un conto, pagare nella scelta dei moduli, aggiungere una mancia e farsi augurare una buona giornata all'uscita. È un'esperienza diversa e più conveniente se fai un salto con gli amici per un pasto complesso.

4. Le persone scrivono ancora ANSI C, sebbene raramente K&R C. La mia esperienza è che la compiliamo sempre con un compilatore C ++ usando alcune modifiche di configurazione per limitare ciò che viene trascinato. Vi sono buoni argomenti per altre lingue: Go rimuove l'overhead polimorfico e il preprocessore pazzo ; ci sono stati alcuni buoni argomenti per un impacchettamento dei campi e un layout di memoria più intelligenti. Secondo me, qualsiasi progetto di linguaggio dovrebbe iniziare con un elenco di obiettivi, proprio come lo Zen di Python .

È stata una discussione divertente. Ti chiedi perché non puoi avere librerie magicamente piccole, semplici, eleganti, complete e flessibili?

Non c'è risposta. Non ci sarà una risposta. Questa è la risposta