O C ++ moderno está se tornando mais prevalente? [fechadas]

132

Quando eu aprendi C ++ há 6 ou 7 anos, o que eu aprendi foi basicamente "C com Classes". std::vectorfoi definitivamente um tópico avançado, algo que você poderia aprender se realmente quisesse. E certamente não havia ninguém me dizendo que destruidores poderiam ser aproveitados para ajudar a gerenciar a memória. Hoje, em todo lugar que olho, vejo RAII e SFINAE e STL e Boost e, bem, Modern C ++. Mesmo as pessoas que estão apenas começando o idioma parecem aprender esses conceitos quase desde o primeiro dia.

Minha pergunta é: isso é simplesmente porque estou vendo apenas o "melhor", ou seja, as perguntas aqui no SO e em outros sites de programação que tendem a atrair iniciantes (gamedev.net), ou é realmente o representante do Comunidade C ++ como um todo?

C ++ moderno está realmente se tornando o padrão? Em vez de ser algo chique sobre o qual os especialistas escrevem, está se tornando "do jeito que o C ++ é"? Ou simplesmente não consigo ver as milhares de pessoas que ainda aprendem "C com classes" e escrevem suas próprias matrizes dinâmicas em vez de usar std::vector, e fazem o gerenciamento de memória chamando manualmente new / delete de seu código de nível superior?

Por mais que eu queira acreditar, parece incrível se a comunidade C ++ como um todo evoluiu muito em basicamente alguns anos. Quais são suas experiências e impressões?

(aviso: alguém que não esteja familiarizado com C ++ pode interpretar mal o título como perguntar se C ++ está ganhando popularidade em relação a outras linguagens. Essa não é a minha pergunta. "C ++ moderno" é um nome comum para um estilo de dialeto ou programação em C ++, nomeado após o livro " Design moderno em C ++: programação genérica e padrões de design aplicados ", e estou interessado apenas nisso versus" C ++ antigo ". Portanto, não é necessário me dizer que o tempo do C ++ já passou e todos devemos usar o Python;))

jalf
fonte
2
Infelizmente, acho que levará um tempo até que a comunidade C ++ como um todo seja avançada o suficiente para reconhecer como usar a biblioteca padrão e melhorar as próximas adições ao C ++ 0x, e muito menos implementar código usando metodologias semelhantes. No entanto, acho que o C ++ 0x traz muita esperança para aumentar a popularidade do C ++. Muitos inconvenientes sintáticos diários foram aprimorados. Sempre achei essas coisas mesquinhas, mas para pessoas externas que olham o idioma, essa é uma fonte comum de reclamação.
stinky472
15
No meu caso, sempre que encontro um profissional que entende técnicas modernas de C ++ como RAII e segurança de exceção (não necessariamente se referindo ao livro de Alexandrescu) ou mesmo os conceitos mais básicos, como iteradores e algoritmos genéricos, encontro mais dez que não entendem. Pelo menos no que diz respeito aos profissionais, muitos deles estão muito atrasados ​​nos prazos para aprender qualquer coisa que seja conhecida; portanto, mesmo os profissionais autoproclamados de C ++ geralmente têm muito a aprender. Receio estar também me tornando um daqueles com C ++ 0x: há muito que preciso aprender e ajustar para isso e tenho prazos a cumprir.
stinky472

Respostas:

76

Eis como acho que as coisas evoluíram.

A primeira geração de programadores de C ++ eram programadores de C, que de fato usavam C ++ como C com classes. Além disso, o STL ainda não estava em vigor, então é isso que C ++ essencialmente era.

Quando o STL foi lançado, isso avançou, mas a maioria das pessoas que escrevia livros, elaborava currículos e ministrava aulas aprendeu C primeiro, depois aquelas coisas extras em C ++, então a segunda geração aprendeu dessa perspectiva. Como outra resposta observada, se você se sente à vontade para escrever regularmente para loops, mudar para usar std::for_eachnão custa muito, exceto a sensação de que você está fazendo as coisas da maneira "moderna".

Agora, temos instrutores e escritores de livros que usam todo o C ++ e obtêm suas instruções a partir dessa perspectiva, como o Accelerated C ++ da Koenig & Moo e o novo livro de Stroustrup. Então não aprendemos char*então std::strings.

É uma lição interessante sobre quanto tempo leva para que os métodos "legados" sejam substituídos, especialmente quando eles têm um histórico de eficácia.

JohnMcG
fonte
13
Sim. Foi muito inteligente tornar o C ++ altamente compatível com o C por causa da enorme base instalada de codificadores C. Muito semelhante à estratégia bem-sucedida da MS de sempre manter a compatibilidade com o DOS. (Excelente blog See de Raymond Chen para os comprimentos muitas vezes dolorosos que eles foram para ...)
j_random_hacker
2
Opa, ficou um pouco tangente lá ... Quer dizer que acho que você está certo sobre a "divisão geracional" entre aqueles que mudaram de C (mas mantiveram o pensamento do estilo C) e aqueles cujo "primeiro gosto "foi pós-STL C ++.
j_random_hacker
57

Absolutamente sim. Para mim, se você não está programando C ++ nesse estilo "Modern C ++", como é chamado, então não faz sentido usar C ++! Você também pode usar C. "Modern C ++" deve ser a única maneira de programar C ++ na minha opinião, e eu esperaria que todos os que usam C ++ e que tenham programado dessa maneira "Moderna" concordem comigo. De fato, sempre fico completamente chocado quando ouço um programador C ++ que não tem conhecimento de coisas como um auto_ptr ou um ptr_vector. No que me diz respeito, essas idéias são básicas e fundamentais para C ++ e, portanto, eu não poderia imaginar isso de outra maneira.

Ray Hidayat
fonte
4
+1; Peguei o estilo "modern c ++" desde o início porque é a maneira natural de fazê-lo (se você não está pensando em C com classes).
1111 Adam Hawes
21
"Apenas use C?" C é malditamente poderoso.
Clark Gaebel 06/06/10
4
Os robôs com certeza não estarão programando em C ++, não são estúpidos o suficiente e congelariam tentando compilá-lo.
Matt Joiner
6
@ClarkGaebel Bem, se C é poderoso, então é C ++ pela sua herança de C sem seus problemas :)
legends2k
4
@rxantos, você diz que, como não temos muitas opções para avaliar o desempenho, por exemplo, ver a saída da montagem, temporizadores, monitores de RAM e muito mais. C ++ não é diferente de C nesse sentido. Em caso de dúvida, perfil. Qualquer outra coisa é apenas boato.
Underscore_d
25

Nos dias do Windows 3.1, C era o padrão. Quando o C ++ chegou ao mercado de desenvolvedores e mais tarde se tornou o padrão ANSI, foi a nova novidade. Popularizou o acrônimo OOP e alguns dos padrões básicos de design usando polimorfismo.

Agora, com a maior aceitação de plataformas gerenciadas de baixa barreira à entrada, como C # /. NET, há menos motivo para usar C ++. Grande parte da base de desenvolvedores terá uma escolha e vamos ser honestos: C ++ é um urso para aprender para um iniciante. Com o C #, você pode simplesmente executar com ele.

Isso deixa realmente apenas as plataformas que NECESSITAM C ++ e os evangelistas obstinados em C ++ para continuar praticando a arte. Essa é a comunidade que precisa e deseja todas as camadas de abstração consideradas "C ++ modernas".

Então, sim, acredito que "Modern C ++", como você declara, está se tornando mais prevalente. Embora seja predominante em um público diferente do usado no passado.

Spoulson
fonte
Vamos lá pessoal, esta resposta faz alguns bons pontos. C ++ não é perfeito, todos sabemos que, o próprio Bjarne reclama que é grande e difícil de aprender. Embora eu discorde sobre o porquê do Modern C ++ ter surgido tão gradualmente - IMHO, leva apenas um tempo para uma linguagem tão grande "avançar".
j_random_hacker
4
Então você está dizendo que os desenvolvedores mais comuns seguiram para C # e tal, enquanto os mais hard-core ficaram mais com C ++? (Não que não haja realmente pessoas inteligentes em C # /. NET, mas existem muitas menos inteligentes.) Faz certo sentido.
11269 David Thornley
3
Eu acho que é um ponto válido. É claro que isso não é verdade para todos, mas, em grande parte, concordo, a maioria das pessoas que tem uma escolha já optou por C #, Java ou outras linguagens.
jalf
3
Casos de uso: quero que um cliente Windows faça CRUD no meu banco de dados. Use C # /. NET ou C ++ / MFC? Quero um aplicativo Web ... Use C # / ASP.NET ou C ++ / ISAPI? Eu quero um clone "Nybbles" simples usando DirectX C # / .NET ou C ++ / MFC / WTL? Eu quero uma demonstração vencedora no Assembly09 ... definitivamente C ++ (vs. C #).
spoulson
8
Não sei se é uma questão de mais camadas de abstração ou mais dureza. Eu suspeito que é apenas que os tipos de abstrações disponíveis através de modelos simplesmente não estavam disponíveis em Java ou C #, então as pessoas que gostaram ou precisaram delas ficaram com C ++.
Kragen Javier Sitaker 5/11/09
16

Eu sou um desses caras que aprendeu a trabalhar com o STL e ouviu muito sobre RAII e boas práticas de programação C ++ desde o primeiro dia. ) concentre-se no uso de ferramentas STL em vez de criar suas próprias coisas e também forneça muitas "regras" para uma programação eficaz (ou "moderna").

Mas conversando com amigos, notei também que algumas empresas ainda trabalham com "C com classes", não com "C ++ moderno". Talvez a cultura proposta pelos autores e usuários do "Modern C ++" prevaleça algum dia :)

jfsantos
fonte
Onde trabalho, ainda usamos C com aulas, provavelmente porque há muitos veteranos que estão lá há um tempo. Eles parecem muito cautelosos até com o STL, e muito menos com o BOOST.
aneccodeal
12

Eu acho que você teve uma experiência ruim começando.

Você precisa adquirir livros C ++ eficazes de Scott Meyers . Comecei com C ++ com raiva em 1999, meu líder de equipe me fez sentar e ler C ++ efetivo e C ++ mais eficaz antes de me permitir verificar qualquer código.

A maior parte de seu conselho é sobre as linhas de "Não use este recurso , mas se for preciso, manter esta em mente"

Se você seguir o conselho dele, escreverá C ++ bom ou "Moderno".

Ele também tem um livro sobre STL, mas que eu não li.

Preocupação binária
fonte
Devo mencionar que este foi apenas o meu ponto de partida. Hoje, estou muito confortável com o STL, boost, RAII e tudo mais. Eu simplesmente me perguntava quão comum era minha experiência inicial.
jalf
9

Nos meus trabalhos em C ++, achei os recursos modernos cada vez mais usados, e mais pessoas me perguntaram sobre eles em exames e entrevistas por telefone. Tanto quanto eu posso dizer, eles estão pegando.

Eu aprendi C ++ originalmente como algo como C com classes; embora a linguagem tenha avançado muito além disso, os livros que li e as pessoas com quem trabalhei estavam firmemente presos ao "antigo C ++". RAII em que as pessoas pensariam, em vez de fazer automaticamente, e lembro-me de ler alguns dos primeiros artigos sobre os problemas de segurança de exceções.

Como apontado, há novos livros lançados agora. Muitos dos antigos ainda são relevantes, mas parecem cada vez mais explicar por que obviamente más idéias são ruins. (Da mesma forma, é difícil para os leitores modernos entenderem como eram as idéias revolucionárias de Freud de uma mente inconsciente, já que agora é a sabedoria convencional.)

Stroustrup acabou de lançar um livro didático, Programming: Principles and Practice Using C ++ . Comprei porque ainda não consegui aprender coisas boas de um livro da Stroustrup, mas não passei dos primeiros capítulos. Até agora, tudo o que posso dizer é que aprovo o modo como ele está começando, e é pelo menos uma boa introdução de como o C ++ deve ser usado.

David Thornley
fonte
Até as primeiras versões do STL não eram seguras contra exceções.
Kragen Javier Sitaker 5/11/09
2
Naquela época, ninguém sabia realmente escrever código com exceção de segurança. Isso foi elaborado nos anos seguintes à publicação da norma. Lembro-me de alguns dos artigos no relatório C ++.
22630 David Thornley
7

Enquanto trabalho no projeto em que estou envolvido, há muito código C ++ que evoluiu ao longo de um período significativo de tempo (há mais de 10 anos). A evolução da qual você fala é claramente visível lá: o código mais antigo geralmente é "C com classes" - ponteiros brutos, char*seqüências de caracteres e uso de funções C, matrizes etc; o código mais recente usa ponteiros inteligentes ATL e outros para gerenciar recursos, mas ainda se mantém nos loops codificados à mão na maioria das vezes, e o iterador é uma visão rara; e o mais novo está cheio de contêineres STL, algoritmos,shared_ptr(incluindo deleters personalizados para gerenciar identificadores etc.), modelos de função e classe fortemente genéricos e assim por diante. As técnicas de codificação "C com classes" mais tradicionais, como ponteiros não encapsulados em bruto com gerenciamento manual da vida útil, são muito criticadas nas revisões de código atualmente. A julgar por isso, parece que sua observação é precisa.

O desenvolvimento mais recente parece ser um modismo para as lambdas C ++ 0x - que tem um lado positivo, pois também inclina a balança em favor do uso de algoritmos padrão em loops codificados à mão, já que agora você pode ter todo o seu código alinhado com algoritmos também.

Pavel Minaev
fonte
6

Eu não diria que std :: vector se qualifica como "moderno" atualmente. É realmente básico.

Geralmente, minha impressão é que as pessoas adquiriram alguma experiência com o estilo C ++ moderno e ficaram um pouco sérias. Apenas para dar um exemplo simples, STL for_each foi interessante, mas na prática não agrega muito valor ao longo de um loop C simples. É mais difícil depurar e, às vezes, não oferece o melhor desempenho. Além disso, as construções para programação funcional no STL atual são geralmente muito complicadas, especialmente se você tiver experiência com uma linguagem funcional real como o ML.

Johan Kotlinski
fonte
1
por que você diz que o vetor não se qualifica como moderno? ainda é o estado da arte para muitos casos de uso, mesmo que seja básico. mas acho que algo básico não significa que não seja moderno. antes pelo contrário, se houver. mas eu acho que eu concordo com o seu segundo parágrafo :)
Johannes Schaub - litb
4
mas acho que isso ocorre porque algumas pessoas tentam usar for_each e amigos basicamente para tudo, mesmo para coisas como onde um simples loop for seria muito mais conciso - inchando um loop de 2 linhas com até 10 linhas. Espero mais pessoas a usar for_each e amigos quando lambda estará disponível em C ++ 1x embora
Johannes Schaub - litb
7
vetor sendo básico é exatamente o ponto. Nem sempre foi básico. Uma vez, era comumente visto como uma coisa super complicada (usava TEMPLATES) e ineficiente (não é uma matriz bruta). Algo em que os especialistas podem pregar, mas muitas pessoas simplesmente não confiam.
jalf
2
Talvez porque std :: for_each raramente seja o que você precisa em comparação com dizer ... std :: transform? O uso do algoritmo ajuda você a se livrar de um bug muito comum: condição incorreta do loop.
11119 Edouard A.
vector <bool> certamente não é básica ...
Kugel
6

Infelizmente, na minha experiência (Universidade Espanhola), a norma é não considerar as línguas em si. Eles usam as linguagens mais fáceis para ensinar programação (por exemplo, Java), porque é suposto ser fácil para professores e alunos e, em seguida, usam C para as classes do SO.

O C ++ é introduzido muito levemente (de qualquer forma, em qualquer curso), apenas para fornecer um C com classes. Eles não entram em impulso ou mesmo STL. Eu acho que acompanhar todas as características e o modo de pensar em C ++ é caro para professores e alunos. Quantos programadores de C ++ aqui conhecem o suficiente de todas as bibliotecas Boost para usá-las para fornecer uma solução melhor ou projetá-la? É preciso ter interesse em acompanhar todas as novas bibliotecas e idiomas.

No entanto, como eu disse, parece que a programação em geral (e as linguagens de programação em particular) não é levada muito a sério, pois parece ser uma tarefa temporal quando eles iniciam um trabalho, então esqueça como programar à medida que avançam no árvore da empresa. Muitas empresas aqui, e a própria Universidade, têm a sensação de que a programação pode ser feita por qualquer pessoa.

Se você seguir essa filosofia, para a maioria das pessoas que conheço, o C ++ sempre será "C com classes".

Saudações,

Diego Sevilla
fonte
A maior parte disso é muito comum na Ciência da Computação e, no geral, não acho que seja uma coisa ruim. (Não se concentra na linguagem, é claro. As línguas ensinadas devem obviamente ainda ser ensinadas adequadamente).
jalf
+1: "(Não é o foco no idioma, é claro. Os idiomas que o aRE ensinou obviamente ainda devem ser ensinados adequadamente)"
Jared Updike
6

Na minha experiência, isso depende muito da idade do produto / projeto de software. A maioria dos novos projetos que eu conheço usa C ++ moderno (RAII, STL, Boost). No entanto, existem muitos projetos C ++ com mais de 10 anos e você não vê C ++ moderno lá.

Além disso, lembre-se de que algumas das implementações STL mais populares foram praticamente quebradas até talvez cinco anos atrás (MSVC <7.0 e GNU <3.00)

Nemanja Trifunovic
fonte
4

Acho que a maior barreira que encontrei é o suporte a cadeias de ferramentas, especialmente em projetos de plataforma cruzada. Até alguns anos atrás, era comum ver notas de construção dizendo "a plataforma x precisa que o STLport funcione porque o compilador está funcionando". Mesmo agora, vejo problemas com pessoas que tentam usar várias dependências de terceiros vinculadas a diferentes versões do BOOST. Isso impossibilita a vinculação, o que significa que você deve voltar e reconstruir seus deps do zero.

Agora que quase todo mundo parou de usar o MSVC ++ 6, a bagunça do STLport está para trás. Mas assim que o TR1 está pronto, voltamos a "quais versões de quais ambientes o suportam e acertam" e mais uma vez isso atrasará a adoção.

Trabalho em um projeto iniciado em C (não em C ++) em 1992. A implantação de práticas modernas na base de código herdada seria impossível. Da mesma forma, trabalho em outro projeto muito mais próximo da vanguarda da linguagem C ++.

XenonofArcticus
fonte
3

Muitas equipes em que estive e ouvi falar consideram as grandes "estamos usando exceções?" questão. Este é o código para "estamos usando C ++ moderno?"

Depois de não usar exceções, você fica impedido de usar todo o poder da linguagem e de suas bibliotecas.

Porém, muitas bases de código mais antigas não têm exceção, e parece difícil aplicar exceções em uma base de código que não as espera, ou em uma equipe que não sabe usá-las. Portanto, a resposta nesses casos é frequentemente 'não'.

Na minha experiência, o C ++ moderno precisa de alguém que seja apaixonado por isso na equipe, que não suporta nada menos do que isso, para fazer isso. Ele também precisa superar as objeções daqueles que querem que seja mais parecido com o código legado.

Embora eu não ache que as antigas bases de código C ++ estejam desaparecendo muito rapidamente, acredito que há mais dessas pessoas apaixonadas no mundo do que há cinco anos atrás. Eles enfrentam a mesma batalha difícil que enfrentaram cinco anos atrás, mas são mais propensos a encontrar espíritos afins.

Drew Hoskins
fonte
3

Antes de responder a essa pergunta, você precisa concordar com o que é "Moderno". É improvável que isso aconteça, pois "Moderno" é uma palavra mal definida e significa coisas diferentes para pessoas diferentes. O título do livro de Alexandrescu (Design moderno em C ++) também não ajuda muito, pois é em grande parte um livro sobre metaprogramação de modelos, que é uma área específica do C ++, mas de modo algum a única.

Para mim, "Modern C ++"! = "Metaprogramação de modelos". Eu diria que os recursos do C ++ em cima do C se enquadram nessas categorias:

  • Classes (Construtores, Destrutores, RAII, Fundição dinâmica e RTTI)
  • Exceções
  • Referências
  • Estruturas de dados e algoritmos na biblioteca padrão (STL)
  • iostreams
  • Modelos simples de classe e função
  • Metaprogramação de modelos

Nenhuma delas é particularmente moderna, já que elas existem há quase 10 anos ou mais. A maioria desses recursos é útil e permitirá que você seja mais produtivo que o C direto para muitos casos de uso. Um bom programador deve e usará todos eles em um projeto de tamanho decente, mas uma dessas coisas não é como a outra:

Metaprogramação de modelos.

A resposta curta para a metaprogramação de modelos é apenas dizer não. Infelizmente, para algumas pessoas, é sinônimo de "programação C ++ moderna", devido ao livro, mas no final cria mais problemas do que resolve. A menos que o C ++ desenvolva mecanismos de programação genéricos melhores, como reflexão, não será adequado para programação genérica, e linguagens de nível superior como Python serão mais adequadas para esses casos de uso. Por esse e muitos outros motivos, consulte o C ++ FQA

Anton I. Sipos
fonte
6
A metaprogramação de modelos do IMHO quase nunca é necessária para a programação de aplicativos , onde serve apenas para fornecer níveis de generalidade provavelmente desnecessários ao custo da legibilidade e de erros difíceis de entender. Mas o OTOH é extremamente útil para especialistas na construção de bibliotecas (à la Boost), onde a generalidade adicional é útil e os mecanismos (feios, complicados e confusos) podem ser ocultados.
Jrandom_hacker
3
Você está certo de que a metaprogramação de modelos pode ser usada com bom gosto, se feita com moderação, principalmente nas bibliotecas. Mas, muitas vezes, tenho visto pessoas irem muito longe no caminho da metaprogramação de modelos, e seus programas sofrem como resultado. Eu não sou contra a metaprogramação, na verdade sou um forte defensor disso, é que as instalações do C ++ para isso são bastante grosseiras.
Anton I. Sipos 27/03
2

O melhor livro para aprender C ++. "Accelerated C ++", de Koenig & Moo, ensina o que você descreve como C ++ moderno, então acho que a maioria das pessoas hoje em dia está usando. Para aqueles que usam o C ++ há bastante tempo (desde meados dos anos 80, no meu caso), o C ++ moderno é um grande alívio das tarefas tediosas de escrever nossas próprias matrizes, seqüências de caracteres e tabelas de hash (repita ad nauseam).

anon
fonte
1
Não quero dizer necro, mas acabei de comprar o livro com base nesta recomendação. Nós vamos ter que ver!
Andrew Weir
2

De fato, observei os trabalhos em C ++ e as bibliotecas "modernas" são cada vez mais usadas nas descrições de tarefas; o MFC, que é uma biblioteca c ++ "antiga", é menos usado.

Rexxar
fonte
1

A padronização da linguagem no final dos anos 90 foi o primeiro passo, permitindo que os fabricantes de compiladores se concentrassem no conjunto "padrão" de recursos, além de permitir que a linguagem corrigisse algumas das arestas que apareceram durante o processo de padronização.

Isso, por sua vez, permitiu o desenvolvimento de estruturas baseadas em recursos padrão da linguagem, e não nos recursos fornecidos por uma implementação específica do compilador. A biblioteca Boost é notavelmente nesse sentido. Além disso, isso permitiu que o novo desenvolvimento fosse baseado em trabalhos anteriores, possibilitando soluções para problemas mais complexos.

Uma mudança notável aqui é como as estruturas anteriores eram baseadas na noção de classes base e classes derivadas (um recurso de tempo de execução). Agora, porém, os recursos mais avançados geralmente são baseados em modelos "recursivos" (um recurso de tempo de compilação).

O STL tem seus prós e contras, mas sobreviveu ao teste do tempo, se você quer algo que funcione e seja simples, o STL certamente tem algo para ajudá-lo a começar. Não faz sentido reinventar a roda (a menos que por razões didáticas).

O hardware do computador também deu grandes saltos a partir dos anos 90, então a memória e a CPU não são mais uma restrição para o compilador. Portanto, a maioria das otimizações teóricas dos livros agora é possível.

Os próximos passos da linguagem são o suporte à programação multinúcleo, que faz parte do esforço padrão de 0x.

Ismael
fonte
1

Sim e não. Certamente, para novos projetos, é cada vez mais popular. No entanto, ainda existem barreiras à adoção que são práticas, não políticas, que outros não mencionaram. Existem muitas bibliotecas comerciais C ++ que usam ABIs de compiladores antigos que não oferecem suporte adequado aos recursos vistos no Modern C ++, e muitas empresas confiam nessas bibliotecas. O Sun Studio no Solaris, por exemplo, não pode funcionar com o Boost sem o uso do STLport, mas qualquer biblioteca comercial de terceiros que você deseja usar exigirá a versão da STL da Sun. Mesma história com o GCC 2.95 e o Redhat Enterprise Linux.

Joseph Garvin
fonte
-3

É impressionante o pouco esforço necessário para tornar o c ++ mais estável. O sistema de alerta está em vigor, mas não está evoluindo muito. É ainda mais fácil dar um tiro no pé do que há 10 anos. Não sei por que, mas o c ++ ainda é meu idioma favorito. :)

AareP
fonte
Eu sugeriria a leitura de vários livros deste tópico antes de fazer reivindicações sobre o "pouco esforço" que está sendo colocado na estabilização de C ++ e que "é ainda mais fácil se dar um tiro no pé do que há dez anos".
Patrick Niedzielski
Claro, a biblioteca std fornece alguma estabilidade sobre a alocação de memória e manipulação de strings. Infelizmente, internamente, usa convenções de codificação tão estranhas que você acha que foi escrita por alienígenas ou algo assim. :)
AareP /
2
Como a biblioteca padrão é uma especificação, culpe o fornecedor do compilador por usar convenções de codificação internas estranhas. Além disso, convenções estranhas de codificação são instáveis ​​ou mais fáceis de dar um tiro no próprio pé. A maioria dessas convenções de codificação (falando pelo menos sobre a biblioteca MSVC e provavelmente também sobre outras) são projetadas para não interferir com você, de modo que você pode fazer coisas estúpidas e a biblioteca não precisa se importar. Se você codifica fora da especificação C ++, isso é diferente.
Patrick Niedzielski
Observe que uma implementação típica de STL (especialmente se incluída em um compilador específico) não precisa usar o C ++ padrão para se implementar. Ele pode muito bem usar o conhecimento específico da implementação em si mesmo, a fim de fornecer ao seu código as garantias prometidas pelo Padrão. Seu próprio código, no entanto, deve manter apenas o que o Padrão garante. Você não pode aprender as garantias padrão examinando uma implementação específica de C ++ ou STL.
precisa saber é o seguinte
Esta resposta foi escrita há uma década. Naquela época, era incrível quanto esforço estava sendo feito para tornar o c ++ mais estável. Essa foi uma das principais razões pelas quais o c ++ 0x demorou tanto para ser lançado como o c ++ 11.
David Hammen