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

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

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.

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.

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.

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 :)

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.

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.

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.

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.

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,

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)

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 ++.

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.

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

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).

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.

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.

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.

É 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. :)