O lado negro do C++

[HugoDaniel]

Sem querer parecer muito mau (visto que ainda sou muito verde nestas coisas de forums), gostava de deixar à vossa apreciação uma apresentação à qual tive o prazer de assistir sobre o C++.

Está em inglês, e chama-se "The dark side of C++"

http://www.fefe.de/c++/c%2B%2B-talk.pdf

Muitos dos pontos aí abordados são irrelevantes e facilmente resolvidos com um bom IDE, no entanto muitos outros revelam problemas estruturais de desenho no C++.

Comentem por favor 😉

[Triton]

"With great power comes great responsibility." 😉

[OldCoder]

Maior parte das reclamações são válidas, e duvido muito que alguém considere o C++ uma linguagem perfeita. Mas por outro lado, muitas dessas reclamações resultam de possibilidades dentro de C++ que têm supostamente que funcionar de forma compatível com o seu antecessor C.

Posto isto, tenho umas observações sobre essa apresentação:

Para começar, "Too Powerful" não é um problema. 😄

Estilos são responsabilidade do programador. Qualquer linguagem dá liberdades nesse respeito, e não é culpa do C++ que alguém queira escrever uma coisa horrorosa como for(int i(0); i != n; ++i) (sim, eu prefiro o estilo "antiquado"). Hábitos são independentes da linguagem. Por exemplo, ambiguidade na sintaxe a(😉 sempre existiu, mas será corrigida no próximo standard. No entanto, já lá vão muitos anos sem confusões suficientes provocadas por isto. Coerência de estilo dentro de uma equipa evita sempre problemas.

O que ninguém se atreve a negar são os problemas provocados pelos destrutores, ou melhor, pelo operador delete diferenciado. Maior parte das vezes, conseguem evitar-se estes problemas ocultando operações na heap dentro de bibliotecas, e usando o princípio de RAII (resource allocation is initialization) para promover declarações de objectos na stack.

Finalmente, há imensas circunstâncias em que gestão determinista de memória é melhor que garbage collection. Pode-se sempre delimitar porções de um programa com chavetas {} para definir a longevidade de objectos.

[Triton]

Também concordo que muitas delas são válidas, e a maioria estão relacionadas com a compatibilidade com o C, uma das maiores vantagens do C++ face às alternativas. Nunca nos podemos esquecer que quando o Bjarne Stroustrup desenhou a linguagem, uma das suas preocupações foi esta compatibilidade com o C, de forma a poder usar a quantidade enorme de código disponível.

Eu ando a trabalhar num projecto (para terem noção do tamanho, tem ~20k LOC) e nunca tive grandes problemas relacionados com o C++. Quando me iniciei na linguagem confundia montes de coisas mas à medida que se vai conhecendo mais da linguagem, e se entende também a história por trás dessas funcionalidades, rapidamente percebemos o porquê de algo ser assim.

Mas existem sempre coisas que temos de ter atenção. Recomendo a leitura do livro "Effective C++" que explica estes pontos onde é preciso ter mais cuidado.

[HugoDaniel]

O RAII ainda se usa nos dias de hoje ? Como se resolvem então os problemas de concorrência de alocação em stack ? Quais as abordagens para se 'fazer RAII' em várias 'threads' ?

Gestão determinista de memória até ao ponto que fico com a heap toda fragmentada ?

Quão determinista é "determinista" ?

[OldCoder]

O RAII ainda se usa nos dias de hoje ? Como se resolvem então os problemas de concorrência de alocação em stack ? Quais as abordagens para se 'fazer RAII' em várias 'threads' ?

Gestão determinista de memória até ao ponto que fico com a heap toda fragmentada ?

Quão determinista é "determinista" ?

http://www.devx.com/SpecialReports/Article/38883/1954

[HugoDaniel]

Pois, nesse caso o argumento inicial com que ele começa a apresentação valida-se... 😉

Slide 7: "Ever-Changing Standard"

Em suma: "Useless maintenance work. Would have been less trouble in C."

[forcewill]

Não conheço linguagem que seja perfeita, admito no entanto que C++ não é perfeito e muito deve-se á querer manter compatibilidades com o C no entanto hoje em dia pareçe que ou as aplicações não são tão performance oriented ou por questões de custo se o evita em favor de linguagens chamadas "managed", com GC incluidos etc, e com API's cada vez mais completas que me faço algumas perguntas

os programadores de hoje têm medo de gerir a memória, e se sim então daqui a uns anos a maior parte deles nem terão uma ideia de como o SO funciona, o que mesmo em linguagens com GC deve-se sempre saber.

Quanto aos argumentos desse artigo devo dizer que alguns estão desactualizados (por ex o das templates '>>' solved in c++0x)

e o argumento C++ is too powerfull não pega, C++ é complexo sim, e torna-se um problema quando os programadores ou querem saber todos os detalhes da linguagem, ou aprendem por livros insuficientes.

Quanto ao standard sempre a mudar pessoalmente mt da funcionalidade do C++0x já deveria ter sido retificada á muito, e não é a unica linguagem a mudar não me lembro de generics em java á uns tempos, nem em C# no enanto não vejo ninguem a queixar-se disso lol

[HugoDaniel]

A respeito do C++0x,

quantas implementações estáveis existem ?

quantas implementações a 100% existem ?

Se a resposta é negativa em alguma destas questões, então:

Quanto tempo até tal acontecer ?

[OldCoder]

Pois, nesse caso o argumento inicial com que ele começa a apresentação valida-se... 😉

Slide 7: "Ever-Changing Standard"

Em suma: "Useless maintenance work. Would have been less trouble in C."

Tendo em conta que os atomics foram desenhados em 2006 ou 2007, e que farão parte de um standard que só será submetido à ISO em 2010, que a propósito, se atrasou porque alguns membros da comissão queriam implementar coisas como conceitos (que no fim, se adiaram para outra altura) e funções lambda. "Ever-changing", quando maior parte das "mudanças" são adições que mantêm compatibilidade com código existente, é um exagero.

Mas se alguém considera melhor implementar uma solução em C, melhor ainda. Apesar de tanta mudança, depois destes anos todos, o C++ ainda reteve compatibilidade com o C (e parcial com o C99).

A não ser que em vez de evoluir desde os anos 80, o C++ devesse ter morrido imediatamente.

[Triton]

O RAII ainda se usa nos dias de hoje ? Como se resolvem então os problemas de concorrência de alocação em stack ? Quais as abordagens para se 'fazer RAII' em várias 'threads' ?

Cada thread tem a sua própria stack, por isso o que queres dizer com os problemas de alocação em stack?

Em suma: "Useless maintenance work. Would have been less trouble in C."

Por acaso não concordei com esse aspecto. Só porque existe uma maneira nova de fazer uma coisa, não és obrigado a alterar o teu programa todo. C++ tem uma boa coisa, que é "backwards compatibility". Aquele exemplo que ele deu do "for" foi no mínimo ridículo.

E se estiveres a usar boost::threads então as alterações serão muito simples. Mas repara, podes continuar a usar as bibliotecas que já estás a usar, ninguém te obriga a modificar o programa só porque saiu uma melhor maneira de fazer as coisas.

[OldCoder]

A respeito do C++0x, a esmagadora maioria das melhorias já funcionam de forma estável e o draft do standard será entregue à ISO em 2010, mas maior parte dos compiladores mais populares (GCC, MSVC, e Borland C++, por exemplo) vão já começar a implementar algumas das melhorias do draft da comissão, tais como tipos enumerados reforçados, ou delegação de construtores dentro de classes.

Desde o standard de 2003, os compiladores costumam acompanhar as mudanças com grande rapidez. Mais depressa que a ISO. 😉

Por exemplo, usando a opção -std=c++ox no GCC, já se pode utilizar algumas destas adições.

[Triton]

Eu já uso as melhorias do TR1 nos meus programas no Visual C++ 2008 SP1. Sei que o Visual C++ 2010 já tras também lambdas e automatic type-inference.

[forcewill]

Eu uso o VS 2010 beta também, entre muitas novidades não relativas á linguagem mas sim ao compilador e intelissinse tais como compilação paralela e finalmente uma bd de intelisence k n "crasha" como antigamente e on the fly á medida que é necessário e olhando para os headers incluidos (recursiva)

e relativamente ao C++0X, lambda, auto, o caso do '>>' nas templates entre outras.

O C++0X está dividido em Releases sendo a primeira a TR1, quanto a compatibilidade

quote directo da wikipedia "Programming languages such as C++ use an evolutionary process to develop their definition. This process inevitably raises compatibility issues with existing code, which has happened occasionally during the C++ development process. However, according to the announcement made by Bjarne Stroustrup, inventor of the C++ language and member of the committee, the new standard will be "almost 100-percent compatible with the existing Standard C++"."

Tal como tem sido a filosofia do C++ de não tentar quebrar compatibilidades com código existente.

[Metaluim]

esse artigo é uma treta, aplica-se a qualquer linguagem (metendo as desvantagens de outra linguagem). Para o que é suposto fazer, o C++ é um equilíbrio perfeito, mas não uma linguagem perfeita, tal coisa não existe.