Em C ++, estou pagando pelo que não estou comendo?

Vamos considerar os seguintes exemplos de olá mundo em 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 eu os compilo em godbolt para montagem, o tamanho do código C é de apenas 9 linhas ( gcc -O3):

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

Mas o tamanho do código C ++ é 22 linhas ( 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

... que é muito maior.

É famoso que em C ++ você paga pelo que come. Então, neste caso, pelo que estou pagando?

O que você está pagando é chamar uma biblioteca pesada (não tão pesada quanto imprimir no console). Você inicializa um ostreamobjeto. Há algum armazenamento oculto. Então, você chama o std::endlque não é sinônimo \n. A iostreambiblioteca ajuda a ajustar muitas configurações e sobrecarregar o processador, e não o programador. É por isso que você está pagando.

Vamos revisar o código:

.LC0:
        .string "Hello world"
main:

Inicializando um objeto 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)

Ligando coutnovamente para imprimir uma nova linha e liberar

    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

Inicialização estática de armazenamento:

_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

Além disso, é essencial distinguir entre o idioma e a biblioteca.

BTW, isso é apenas uma parte da história. Você não sabe o que está escrito nas funções que está chamando.

Então, neste caso, pelo que estou pagando?

std::couté mais poderoso e complicado do que printf. Ele suporta coisas como localidades, sinalizadores de formatação com estado e muito mais.

Se você não precisar deles, use std::printfou std::puts- eles estão disponíveis no <cstdio>.

É famoso que em C ++ você paga pelo que come.

Também quero deixar claro que C ++ ! = The C ++ Standard Library. A Biblioteca Padrão deve ser de uso geral e "rápida o suficiente", mas geralmente será mais lenta que uma implementação especializada do que você precisa.

Por outro lado, a linguagem C ++ se esforça para tornar possível escrever código sem pagar custos ocultos extras desnecessários (por exemplo, opt-in virtual, sem coleta de lixo).

Você não está comparando C e C ++. Você está comparando printfe std::coutcapaz de diferentes coisas (localidades, formatação com estado, etc.).

Tente usar o seguinte código para comparação. Godbolt gera o mesmo conjunto para os dois arquivos (testado com 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);
    }
}

Suas listagens estão realmente comparando maçãs e laranjas, mas não pelo motivo implícito na maioria das outras respostas.

Vamos verificar o que seu código realmente faz:

C:

• imprima uma única sequência, "Hello world\n"

C ++:

• transmitir a string "Hello world"parastd::cout
• transmitir o std::endlmanipulador parastd::cout

Aparentemente, seu código C ++ está fazendo o dobro do trabalho. Para uma comparação justa, devemos combinar isso:

#include <iostream>

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

… E de repente seu código de montagem mainparece muito semelhante ao 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

De fato, podemos comparar o código C e C ++ linha por linha, e há muito poucas diferenças :

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

A única diferença real é que, em C ++, chamamos operator <<com dois argumentos ( std::coute a string). Poderíamos remover até mesmo essa pequena diferença usando um C eqivalent: mais próximo fprintf, que também possui um primeiro argumento especificando o fluxo.

Isso deixa o código de montagem para _GLOBAL__sub_I_main, que é gerado para C ++, mas não para C. Essa é a única sobrecarga verdadeira visível nesta lista de montagens (há mais, sobrecarga invisível para ambos idiomas, é claro). Esse código executa uma instalação única de algumas funções da biblioteca padrão do C ++ no início do programa C ++.

Mas, como explicado em outras respostas, a diferença relevante entre esses dois programas não será encontrada na saída de montagem da mainfunção, pois todo o trabalho pesado acontece nos bastidores.

É famoso que em C ++ você paga pelo que come. Então, neste caso, pelo que estou pagando?

Isso é simples. Você paga std::cout. "Você paga apenas pelo que come" não significa "você sempre obtém os melhores preços". Claro, printfé mais barato. Pode-se argumentar que std::couté mais seguro e versátil, portanto, seu maior custo é justificado (custa mais, mas agrega mais valor), mas isso não leva em consideração. Você não usa printf, usa std::cout, então paga pelo uso std::cout. Você não paga pelo uso printf.

Um bom exemplo são as funções virtuais. As funções virtuais têm alguns requisitos de custo e espaço em tempo de execução - mas apenas se você realmente as usar. Se você não usa funções virtuais, não paga nada.

Algumas observações

1. Mesmo se o código C ++ for avaliado para obter mais instruções de montagem, ainda há algumas instruções e qualquer sobrecarga de desempenho provavelmente ainda será diminuída pelas operações de E / S reais.

2. Na verdade, às vezes é ainda melhor do que "em C ++ você paga pelo que come". Por exemplo, o compilador pode deduzir que a chamada de função virtual não é necessária em algumas circunstâncias e transformá-la em chamada não virtual. Isso significa que você pode obter funções virtuais gratuitamente . Isso não é ótimo?

A "lista de montagem para printf" NÃO é para printf, mas para puts (tipo de otimização do compilador?); printf é muito mais complexo do que coloca ... não se esqueça!

Vejo algumas respostas válidas aqui, mas vou detalhar um pouco mais.

Vá para o resumo abaixo para obter a resposta para sua pergunta principal, se você não quiser passar por toda essa parede de texto.

Abstração

Então, neste caso, pelo que estou pagando?

Você está pagando pela abstração . Ser capaz de escrever códigos mais simples e mais amigáveis ​​ao homem tem um custo. No C ++, que é uma linguagem orientada a objetos, quase tudo é um objeto. Quando você usa qualquer objeto, três coisas principais sempre acontecem sob o capô:

1. Criação de objeto, basicamente alocação de memória para o próprio objeto e seus dados.
2. Inicialização de objeto (geralmente através de algum init()método). Normalmente, a alocação de memória acontece sob o capô como a primeira coisa nesta etapa.
3. Destruição de objetos (nem sempre).

Você não o vê no código, mas toda vez que você usa um objeto, todas as três coisas acima precisam acontecer de alguma forma. Se você fizesse tudo manualmente, o código seria obviamente muito mais longo.

Agora, a abstração pode ser feita de maneira eficiente, sem acrescentar sobrecarga: o inlining de método e outras técnicas podem ser usadas pelos compiladores e programadores para remover as sobrecargas da abstração, mas esse não é o seu caso.

O que realmente está acontecendo em C ++?

Aqui está, dividido:

1. A std::ios_baseclasse é inicializada, que é a classe base para tudo relacionado a E / S.
2. O std::coutobjeto é inicializado.
3. Sua string é carregada e passada para std::__ostream_insert, que (como você já descobriu pelo nome) é um método std::cout(basicamente o <<operador) que adiciona uma string ao fluxo.
4. cout::endltambém é passado para std::__ostream_insert.
5. __std_dso_handleé passado para __cxa_atexit, que é uma função global responsável pela "limpeza" antes de sair do programa. __std_dso_handleele próprio é chamado por essa função para desalocar e destruir os objetos globais restantes.

Então, usando C == não está pagando por nada?

No código C, muito poucas etapas estão acontecendo:

1. Sua string é carregada e passada putsatravés do ediregistro.
2. puts é chamado.

Nenhum objeto em qualquer lugar, portanto, não há necessidade de inicializar / destruir nada.

Este, porém, não significa que você não está "pagando" para qualquer coisa em C . Você ainda está pagando pela abstração, e também pela inicialização da biblioteca padrão C e da resolução dinâmica. A printffunção (ou, na verdade puts, que é otimizada pelo compilador, pois você não precisa de nenhuma sequência de formatação) ainda acontece sob o capô.

Se você escrevesse este programa em assembly puro, seria algo como isto:

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

O que basicamente resulta apenas em invocar o write syscall seguido pelo exitsyscall. Agora, esse seria o mínimo necessário para realizar a mesma coisa.

Resumir

C é bem mais simples , e apenas o mínimo necessário, deixando total controle ao usuário, que é capaz de otimizar e personalizar totalmente basicamente o que quiser. Você diz ao processador para carregar uma string em um registro e, em seguida, chama uma função de biblioteca para usar essa string. C ++, por outro lado, é muito mais complexo e abstrato . Isso tem uma enorme vantagem ao escrever códigos complicados e permite a criação de códigos mais fáceis e mais amigáveis ​​ao ser humano, mas obviamente tem um custo. Sempre haverá uma desvantagem no desempenho do C ++ se comparado ao C em casos como esse, pois o C ++ oferece mais do que o necessário para realizar essas tarefas básicas e, portanto, acrescenta mais sobrecarga .

Respondendo à sua pergunta principal :

Estou pagando pelo que não estou comendo?

Nesse caso específico, sim . Você não está tirando proveito de nada que o C ++ tenha a oferecer mais que o C ++, mas isso é apenas porque não há nada nesse trecho de código simples com o qual o C ++ possa ajudá-lo: é tão simples que você realmente não precisa do C ++.

Ah, e só mais uma coisa!

As vantagens do C ++ podem não parecer óbvias à primeira vista, pois você escreveu um programa muito simples e pequeno, mas observe um exemplo um pouco mais complexo e veja a diferença (os dois programas fazem exatamente a mesma coisa):

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

Espero que você possa ver claramente o que quero dizer aqui. Observe também como em C você precisa gerenciar a memória em um nível mais baixo usando malloce freecomo precisa ser mais cuidadoso com a indexação e os tamanhos e como precisa ser muito específico ao receber entradas e impressões.

Existem alguns conceitos errados para começar. Primeiro, o programa C ++ não resulta em 22 instruções, é mais como 22.000 delas (tirei esse número do meu chapéu, mas está aproximadamente no estádio). Além disso, o código C também não resulta em 9 instruções. Esses são apenas os que você vê.

O que o código C faz é que, depois de fazer muitas coisas que você não vê, ele chama uma função do CRT (que geralmente está presente, mas não necessariamente está presente como lib compartilhada), depois não verifica o valor de retorno ou o manipulador erros e falhas. Dependendo das configurações do compilador e da otimização, ele nem chama , printfmas é putsalgo ainda mais primitivo.
Você poderia ter escrito mais ou menos o mesmo programa (exceto algumas funções invis invisíveis) em C ++, se você chamasse a mesma função da mesma maneira. Ou, se você deseja ser super-correto, essa mesma função é prefixada com std::.

O código C ++ correspondente, na realidade, não é a mesma coisa. Embora tudo <iostream>isso seja conhecido por ser um porco feio e gordo que acrescenta uma imensa sobrecarga para pequenos programas (em um programa "real" você nem percebe muito)), uma interpretação um pouco mais justa é que ele faz uma terrível muitas coisas que você não vê e que simplesmente funcionam . Incluindo, mas não limitado a, formatação mágica de praticamente qualquer material aleatório, incluindo diferentes formatos e localizações de números e outros enfeites, armazenamento em buffer e tratamento de erros adequado. Manipulação de erros? Bem, sim, adivinhe, a saída de uma string pode realmente falhar e, ao contrário do programa C, o programa C ++ não ignoraria isso silenciosamente. Considerando o questd::ostreamsob o capô, e sem que ninguém perceba, é realmente muito leve. Não é como se estivesse usando, porque odeio a sintaxe do fluxo com paixão. Mas ainda assim, é incrível se você considerar o que faz.

Mas, com certeza, o C ++ em geral não é tão eficiente quanto C pode ser. Não pode ser tão eficiente, pois não é a mesma coisa e não está fazendo a mesma coisa. Se nada mais, o C ++ gera exceções (e código para gerar, manipular ou falhar nelas) e fornece algumas garantias que o C não fornece. Então, com certeza, um programa em C ++ precisa necessariamente ser um pouco maior. No geral, no entanto, isso não importa de forma alguma. Pelo contrário, para programas reais , raramente achei o C ++ com melhor desempenho porque, por um motivo ou outro, parece emprestar otimizações mais favoráveis. Não me pergunte por que, em particular, eu não saberia.

Se, em vez de despertar e esquecer a esperança de obter o melhor, você deseja escrever o código C correto (ou seja, na verdade, você verifica erros e o programa se comporta corretamente na presença de erros), a diferença é marginal, se existir.

Você está pagando por um erro. Nos anos 80, quando os compiladores não eram bons o suficiente para verificar as seqüências de formato, a sobrecarga do operador era vista como uma boa maneira de impor alguma aparência de segurança de tipo durante o io. No entanto, todos os seus recursos de banner são implementados mal ou conceitualmente falidos desde o início:

<iomanip>

A parte mais repugnante da API do fluxo C ++ io é a existência dessa biblioteca de cabeçalhos de formatação. Além de ser stateful, feio e propenso a erros, ele formata o fluxo.

Suponha que você queira imprimir uma linha com 8 dígitos int não assinados, preenchidos com zero, seguidos de um espaço seguido de um duplo com 3 casas decimais. Com <cstdio>, você começa a ler uma string de formato conciso. Com <ostream>, você deve salvar o estado antigo, definir o alinhamento para a direita, definir o caractere de preenchimento, definir a largura de preenchimento, definir a base como hexadecimal, gerar o número inteiro, restaurar o estado salvo (caso contrário, sua formatação inteira poluirá a formatação do flutuador), produzirá o espaço , defina a notação como fixa, defina a precisão, produza a linha dupla e a nova linha e restaure a formatação antiga.

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

Sobrecarga do operador

<iostream> é o filho do pôster de como não usar sobrecarga de operador:

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

atuação

std::couté várias vezes mais lento printf(). A façanha desenfreada e a expedição virtual cobram seu preço.

Segurança da linha

Ambos <cstdio>e <iostream>são thread-safe, pois cada chamada de função é atômica. Mas, printf()faz muito mais por chamada. Se você executar o seguinte programa com a <cstdio>opção, verá apenas uma linha de f. Se você usar <iostream>em uma máquina multicore, provavelmente verá outra coisa.

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

A réplica deste exemplo é que a maioria das pessoas exerce disciplina para nunca gravar em um único descritor de arquivo a partir de vários encadeamentos. Bem, nesse caso, você terá que observar que <iostream>será útil trancar uma fechadura em todos <<e cada um >>. Considerando que <cstdio>, você não estará bloqueando com tanta frequência e você ainda tem a opção de não bloquear.

<iostream> gasta mais bloqueios para obter um resultado menos consistente.

Além do que todas as outras respostas disseram,
também há o fato de que nãostd::endl é o mesmo .'\n'

Infelizmente, este é um equívoco comum. std::endlnão significa "nova linha",
significa "imprimir nova linha e liberar o fluxo ". Flushing não é barato!

Ignorando completamente as diferenças entre printfe std::coutpor um momento, para ser funcionalmente equivalente ao seu exemplo de C, seu exemplo de C ++ deve ficar assim:

#include <iostream>

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

E aqui está um exemplo de como devem ser seus exemplos se você incluir a descarga.

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

Ao comparar código, você deve sempre ter cuidado para comparar comparações semelhantes e entender as implicações do que seu código está fazendo. Às vezes, mesmo os exemplos mais simples são mais complicados do que algumas pessoas imaginam.

Embora as respostas técnicas existentes estejam corretas, acho que a pergunta deriva finalmente desse equívoco:

É famoso que em C ++ você paga pelo que come.

Esta é apenas uma palestra de marketing da comunidade C ++. (Para ser justo, há discussões sobre marketing em todas as comunidades de idiomas.) Isso não significa nada concreto do qual você possa confiar seriamente.

"Você paga pelo que usa" deve significar que um recurso C ++ só terá sobrecarga se você estiver usando esse recurso. Mas a definição de "um recurso" não é infinitamente granular. Freqüentemente, você acaba ativando recursos que possuem vários aspectos e, embora precise apenas de um subconjunto desses aspectos, geralmente não é prático ou possível para a implementação trazer o recurso parcialmente.

Em geral, muitos idiomas (embora provavelmente não todos) se esforçam para serem eficientes, com graus variados de sucesso. O C ++ está em algum lugar na escala, mas não há nada de especial ou mágico em seu design que permita que ele seja perfeitamente bem-sucedido nesse objetivo.

As funções de entrada / saída em C ++ são escritas com elegância e são projetadas para serem simples de usar. Em muitos aspectos, eles são uma vitrine para os recursos orientados a objetos em C ++.

Mas, na verdade, você renuncia um pouco do desempenho, mas isso é insignificante em comparação com o tempo gasto pelo seu sistema operacional para lidar com as funções em um nível mais baixo.

Você sempre pode voltar para as funções no estilo C, pois elas fazem parte do padrão C ++, ou talvez renuncie completamente à portabilidade e use chamadas diretas para o seu sistema operacional.

Como você viu em outras respostas, você paga quando vincula bibliotecas gerais e chama construtores complexos. Não há nenhuma pergunta em particular aqui, mais uma queixa. Vou apontar alguns aspectos do mundo real:

1. Barne tinha um princípio básico de design para nunca deixar a eficiência ser um motivo para permanecer em C, e não em C ++. Dito isto, é preciso ter cuidado para obter essas eficiências, e há eficiências ocasionais que sempre funcionaram, mas não foram 'tecnicamente' dentro da especificação C. Por exemplo, o layout dos campos de bits não foi realmente especificado.

2. Tente olhar através do ostream. Oh meu deus está inchado! Eu não ficaria surpreso ao encontrar um simulador de vôo lá. Até o printf () do stdlib geralmente roda cerca de 50K. Esses não são programadores preguiçosos: metade do tamanho da impressão estava relacionada a argumentos de precisão indiretos que a maioria das pessoas nunca usa. Quase todas as bibliotecas de processadores realmente restritos criam seu próprio código de saída em vez de printf.

3. O aumento no tamanho geralmente fornece uma experiência mais contida e flexível. Como analogia, uma máquina de venda automática venderá uma xícara de café como substância por algumas moedas e toda a transação leva menos de um minuto. Entrar em um bom restaurante envolve a colocação de uma mesa, sentar, pedir, esperar, tomar uma boa xícara, receber uma fatura, pagar em suas formas, adicionar uma dica e desejar um bom dia ao sair. É uma experiência diferente e mais conveniente se você estiver acompanhando os amigos para uma refeição complexa.

4. As pessoas ainda escrevem ANSI C, embora raramente K&R C. Minha experiência é que sempre o compilamos com um compilador C ++ usando alguns ajustes na configuração para limitar o que é arrastado. Existem bons argumentos para outros idiomas: Go remove a sobrecarga polimórfica e o pré-processador maluco ; existem alguns bons argumentos para empacotamento de campo e layout de memória mais inteligentes. IMHO Eu acho que qualquer design de linguagem deve começar com uma lista de objetivos, como o Zen do Python .

Tem sido uma discussão divertida. Você pergunta por que não pode ter bibliotecas magicamente pequenas, simples, elegantes, completas e flexíveis?

Não há resposta. Não haverá resposta. Essa é a resposta.