| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | C++. (Pontos:3, Informativo) |
| | | Eu pessoalmente gosto muito de C++ pois e' uma boa combinacao de OO e uma linguagem em que ainda se pode ter controlo do que se esta' a fazer. O OO oferece paradigmas muito poderosos que facilitam muito quando temos sistemas muito complexos. Muitas das criticas a modelos orientados a objectos apenas se aplicam a sistemas pequenos. Quando estamos a desenhar/implementar um sistema extremamente complexo (muitos componentes e muito codigo) os paradigmas OO aplicam-se extremamente bem. Como exemplo, o servidor web da Zeus e' 95% escrito em C++ e usa muitos paradigmas OO. Se fosse escrito em C puro era 3x mais dificil de manter. Obviamente C++ nao e' ideal para coisas que sejam realmente baixo nivel (e.g., um kernel) -- mas e' quase perfeito para tudo o resto. Quanto a Java, espero que tenha muito sucesso -- e' a unica coisa que pode parar a M$. Regards,
-- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
|
| | | | | | "Quanto a Java, espero que tenha muito sucesso -- e' a unica coisa que pode parar a M$. "
Hummm se não teve sucesso até agora porque achas que terá no futuro ?
|
| | | | | Nao teve sucesso ?!? Fazias ideia que o Java neste momento e' a linguagem mais popular para aplicacoes empresariais ? E sabias que e' a 2a linguagem mais procurada em termos de empregadores (a seguir ao C++) ? http://www.pixeldate.com/dev/comparison/
-- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias |
| | | | Hummm por acaso não fazia ideia Java segundo e o perl em terceiro.
Thanks pela info
|
| | | | Nao teve sucesso?? O problema e' como todos nos sabemos o poder que a Sun tem pra implantar o quer que seja. Bem todos nos lembramos aqui a uns anos quando a Sun/Ibm e outras afins tentaram fazer o que agora a MIcrosoft esta a fazer com a plataforma .Net. As applications, os services a correr no servidor. Os ditos Fat Pcs seriam coisas do passado, voltariamos ao conceito servidor/cliente mas desta vez no modelo mais alargado. E a tentativa de implantar as suas boxes azuis a correrem solaris, e o hotjava pra aceder a net. So que saltou logo o carmo e atrindade pro meio da rua!!(a bom portugues) Neste momento Java Server programing e o que esta a dar!! quer seja jsp, java beans, java, servlets etcetc. Penso que e a unica maneira de parar a parafenalia que a Microgaitas ta a tentar impigir com o C#, aspx e por ai adiantee! TUX e DUKE pra mim nao existe conbinacao mais terrivel!!!
|
| | | | Nao sou um programador proficional. assim so posso partilhar a minha visao (que pode estar incorrecta) das vantagens de C++ relativamente a C para pequenos projectos (Os programas que faco estao maioritariamente vocacionados para "number crunching", principalmente para uso pessoal).
Assim so posso partilhar a minha visao (que pode estar incorrecta) das vantagens de C++ relativamente a C para pequenos projectos.
Como nao tenho uma formacao forte em tecnicas de programacao, se nao tenho cuidado acabo por escrever "codigo esparguete" muito facilmente, com proliferacao de variaveis globais, argumentos de funcoes quilometricos, ponteiros soltos, etc...
O C++ ajuda-me a estruturar as ideias e o codigo, principalmente pelo uso classes e templates. O facto do C++ ser mais exigente com os tipos que o C tambem ajuda bastante a identificar possiveis ambiguidades. O C++ nao substitui pensar nas coisas com antecedencia, mas da-me mais espaco de manobra. O facto do codigo ficar (a meu ver) mais claro e compartimentalizado permite mais facilmente o re-uso de rotinas, classes e modulos com o minimo de esforco, por intermedio de templates, ou usando heranca de classes.
Performance nao e a minha principal preocupacao (normalmente). O C++ tipicamente e mais lento que o C. Esta lentidao pode ser minimizada ou evitada mediante certas praticas de programacao. A seguinte pagina discute alguns desses problemas, mas outras paginas poderao ser mais adequadas.
http://www.extreme.indiana.edu/~tveldhui/papers/iscope97/
De notar que o g++ nao optimiza tanto como o gcc.
Acho q algumas das beneces do gcc 3.0 e um compilador c++ melhor e a libstd++ compativel com o padrao ISO (finalmente).
Quanto a livros, recomendo a biblia do C++ do Bkarne Strousup. A pagina dele tem uma argumentacao mais extensiva em defesa do C++ relativamente ao C, assim como o link para o livro dele.
http://www.research.att.com/~bs/homepage.html
Espero que ajude.
--- |
| | | | | | (...)De notar que o g++ nao optimiza tanto como o gcc.(...)
Optimiza sim, tanto o gcc como o g++ usam o mesmo motor para compilar, logo as optimizações são básicamente as mesmas.
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| | | | Por experiencia propria o g++ pelo menos nao optimiza "tail recursion" (converter chamadas recursivas de funcoes em ciclos), ao contrario do gcc.
Descobri isto por acaso quando fazia operacoes em listas muito grandes usando recursao de funcoes. Sem optimizacao a versao C dava "stack overflow" mas com optimizacao nao dava. Copy-paste da funcao recursiva para um programa de C++ dava sempre stack overflow.
Mais tarde explicaram-me que nao era um bug do gcc/g++ mas a consequencia desse tipo de optimizacao e que o g++ nao a suporta.
Deram-me essa explicacao como exemplo das diferencas entre optimizar c e c++. Infelizmente ja me esqueci da maior parte dos detalhes o que e uma pena :(
PS: Peco desculpa por o post original que estar tao MAL escrito, mas tive de o acabar a pressa.
--- |
| | | C++ (Pontos:3, Informativo) |
| | Sou programador de C++ desde 1992 e apesar de toda a evolução continua a ser a minha linguagem favorita. Está bem pensanda e estruturada e não te obriga a pensar os teus programas duma maneira pre-determinada pelos criadores da linguagem.
Quanto ás criticas ao paradigma de objectos, quando os objectos foram 'moda' é claro que ouve algum 'hype' sobre o assunto - muitas pessoas ficaram com a ideia de que de repente ficava muito facil fazer software, o que é claro não é verdade, usar objectos torna o desenvolvimento e a manutenção mais facil mas o segredo de teres um bom software não está numa metodologia ou ferramenta magica mas em muito esforço.
Podes encontrar uns tuturiais engraçados neste site (www.accu.org). Quanto a livros, alem do classico Strostrupp curto especialmente o do Lippman .
|
| | | | | Apesar de ultimamente o C++ ser a minha linguagem OO de eleição há que ter cuidado com a sua escolha como primeira linguagem OO. É já bem bem sabido que o C++ é quer um "better C" quer "Object Oriented C". O facto de a linguagem não impor regras rigidas sobre o estilo de progamação (tal como o perl) é bom por um lado, mas por outro torna-a pouco disciplinadora para quem começa a aprender o paradigma. Nesse sentido é capaz de ser mais sensato o começo com Smaltalk ou Java. Para quem andar no C++ aconselho vivamente a recorrer à STL (standard template library), tem a sua curva de aprendizagem mas permite gerar código muito eficiente (se bem que por vezes pouco legível) e introduz algumas coisas que doutro modo só seriam possíveis com linguagens de "informação de tipo em runtime" tal como o Java. Por exemplo com STL é possível usar uma mesma estrutura de "container" (conjunto, sequência, multi-conjunto) aplicando-a a vários tipos de dados (inteiros, complexos, strings, containers, ...). Já me têm falado muito bem do Python, se alguem quiser partilhar ...
|
| | | | | | | Para quem andar no C++ aconselho vivamente a recorrer à STL (standard template library), tem a sua curva de aprendizagem mas permite gerar código muito eficiente (se bem que por vezes pouco legível) e introduz algumas coisas que doutro modo só seriam possíveis com linguagens de "informação de tipo em runtime" tal como o Java. Por exemplo com STL é possível usar uma mesma estrutura de "container" (conjunto, sequência, multi-conjunto) aplicando-a a vários tipos de dados (inteiros, complexos, strings, containers, ...). Hummm... infelizmente a STL tende a ser horrivelmente mal implementada... por exemplo, a STL do GNU C++ e' simplesmente horrivel -- tem muitos problemas, e' um bocado inconsistente e nao suporta muitas coisas que o standard define (e.g., RTTI). Normalmente o que eu aconcelho e' usar apenas funcoes muito simples da STL, e implementar o resto de uma forma que tenhamos a certeza que funciona (por exemplo, *nunca* usem o tipo String no GCC -- construam o vosso proprio tipo). Como ponto informativo, aqui esta' o ranking (da minha experiencia pessoal) da qualidade dos compiladores C++/STL (em termos de suporte do standard e estabilidade do codigo gerado) em diversas plataformas: - 1 - Forte/Sun C++
- 2 - HP-UX CC
- 3 - GNU C++
- 4 - IBM AIX CC
- 5 - Tru64 (Compaq) CC
Cheers,
-- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
|
| | | | Não sei a que GCC te estás a referir mas não me parece que seja o 2.96/3.0 porque estes são já dos mais cumpridores do standard (apesar de ainda terem espaço para melhorias). Agora se te estás a referir ao 2.95.3 e anteriores esses sim são realmente vergonhosos em C++, não admira que a RedHat os tenha preterido em relação ao CVS do gcc estabilizado para a sua distro (ok, ok, há quem não concorde mas não quero relançar esta discussão).
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| | | por Anonimo Cobarde em 21-06-01 18:12 GMT (#10)
|
| De facto dei uma vista de olhos ao artigo sobre os problemas das linguagens OO e aquilo parece-me conversa de sectário anti-OO. Quanto ao sucesso das bases de dados relacionais vs OO deve-se ao facto de se basearem numa teoria matemática muito simples, mas muito poderosa.
Eu sou sectário pró-OO, mas não me vou detalhar muito nos fundamentos teóricos da coisa. Apenas por curiosidade histórica lembro que a base de Representação do Conhecimento de sistemas Orientados por Objectos nasceu num paper de 1975 dum senhor chamado Minsky (MIT-AI) sobre um sistema chamado KEE. A ideia da inferência baseada numa hierarquia de Frames (como se chamava então) nasceu neste trabalho.
Pessoalmente já nem uso C++. Java é melhor para tudo o que não seja necessário velocidade. Sim, é lento. Para além disso é horrivelmente chato porque não deixa fazer asneiras. Não tem ponteiros? Tem por todo o lado mas não precisamos de os ver. É interpretado e tem garbage collector . O que é porreiro, quantos de vocês já fizeram um programa em C++ com mais de 1000 linhas sem leaks? Usaram o Leak Tracer ou afim? É uma grande chatice, nada produtiva.
Como outras vantagens do java face ao C++ refira-se: - Interfaces
- Tratamento Obrigatório de Excepções
- Independência de plataforma
- Integração com Arquitecturas 3-Níveis e Web
- Biblioteca de base mais completa
No entanto para diversos tipos de aplicações o C++ continua a ser um bom compromisso.
O Smalltalk é OO puro mas é uma linguagem mais académica. O python é porreiro (principalmente o delicioso pormenor da identação dos blocos) mas não tenho experiência portanto não posso opinar melhor.
Senador
|
| | | | Hum... smalltalk80 ... isso ainda é usado sem ser para aprender o básico da programação OO ??
|
| | | | | | Não posso dizer que sou um fanático de linguagens orientadas por objectos, realmente a minha linguagem preferida é o C, mas por acaso gosto bastante de C++ e Java e até o Smalltalk é interessante pela sua pureza (é díficil descobrir o que realmente é linguagem uma vez que parece ser tudo objectos e classes de biblioteca). Orientação por objectos é um paradigma como outro qualquer e deve ser usado como outro qualquer, tendo em conta o problema e também a preferência do programador. O que eu detesto é ver o pessoal a dizer que OO é o Jesus Cristo salvador que vem livrar os programadores de todos os males de gestão e manutenção de código, não é!
Uma linguagem de programação não faz bons programas (ou fáceis de manter), boas práticas isso sim. Em C podem fazer-se programas igualmente complexos e grandes mantendo básicamente a mesma "facilidade" de manutenção do que se fossem feitos em C++ ou Java, basta para isso programar tendo em conta os príncipios básicos da encapsulação, localização, etc... O problema é que existem muitos programadores desleixados do género "é mais fácil usar uma variável global...embora lá!" ou "o autor da lib X diz que a função Y é interna, que se lixe...bora usar!" que não pensam no que fazem, que fazem código esparguete só porque o podem fazer. Isto leva-nos a uma coisa que custa a ouvir: Nem toda a gente está à altura do C (e mesmo do C++ uma vez que permite fugir à orientação por objectos), esses vão ter de usar linguagens mais restritivas como o Java e pagar o preço... eficiência.
PS: Sim o título é politicamente incorrecto.
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| | | | | | Boas !
Isso é uma das minhas GRANDES dúvidas relativamente a programação por objectos q talvez tu me possas explicar.
Por isso desculpem alguma bacorada minha, mas não tenho muita experiencia em C (e nada de C++).
Em C tb n poderá ser considerado programação por objectos por exemplo uma função chamada a partir duma library ?
Acho q tem as mesmas caracteristicas que a programação por objectos.
Ou o C++ oferece algo superior a isto ?
[]'s
|
| | | | Isso é mais para a parte de modularização.. ( que até é uma boa prática ) ajuda a reutilização e melhor organização do código, mas, na minha opinião, com OO ( embora não use OO há muito tempo ) consegue-se niveis de abstração mais elevados..
-- what was my problem with man You ask? No.. I ask you what was man's problem with me.. |
| | | | Nem por isso, mas na realidade a orientação por objectos não é estritamente uma feature da linguagem, é também uma maneira de programar que pode ser aplicada em linguagens não OO.
O que poderia ser considerada programação orientada por objectos em C seria algo como um módulo (ou lib) X em que todas as funções aceitam como primeiro parâmetro uma estrutura que contém todas as informações do ambiente (sem serem necessárias variáveis globais), por exemplo funcao_foo(FooObject *x, int a, int b) o que em C++ seria x.funcao_foo(int a, int b) para um objecto x.
Já agora o GTK+ usa algo como o descrito acima, por exemplo, um botão é um GtkButton e as funções para lidar com botões são gtk_button_qqcoisa(GtkButton *button, argumentos) (eg. void gtk_button_set_relief(GtkButton *button, GtkReliefStyle newstyle);).
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| | | | Certíssimo, mas escrever código OO em linguagens procedimentais é escrever direito por linhas tortas. É nestes casos que convém um programador estar à-vontade com várias linguagens de modo a poder escolher a que melhor se aplica sem estar condicionado por dominar menos bem algumas das linguagens.
A GTK+, que faz orientação aa objectos em C, de certeza que seria muito mais fácil de manter e desenvolver se tivesse sido escrita de raiz em C++ (não que o C++ seja a única linguagem OO, mas neste caso acho que seria a única a se perfilar).
E julgo que a GTK+ só começou a ser construída em C apenas porque os programadores estavam mais familiarizados com o C, do que propriamente por um planeamento rigoroso e cuidado, não alimentado por parcialidades ou gostos. Também é verdade que o suporte a C++ na altura não era grande coisa... mas mesmo assim. :-)
|
| | | | (...)mas escrever código OO em linguagens procedimentais é escrever direito por linhas tortas.(...)
Não é não, alguma orientação por objectos é a maneira certa de se programar em qualquer linguagem, evita na maior parte das vezes o uso de variáveis globais e outras coisas horrorosas, o que é bom.
(...)GTK+ só começou a ser construída em C apenas porque os programadores estavam mais familiarizados com o C, do que propriamente por um planeamento rigoroso e cuidado, não alimentado por parcialidades ou gostos.(...)
A principal razão do GTK+ ser feito em C, além da preferência dos programadores, é o facto de ser extremamente fácil fazer bindings para outras linguagens, e o GTK+ já tem imensos.
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| | | | Object Oriented Software Construction < Link Amazon> Falta-te de tudo acerca de Objectos sem nunca usar uma linguagem concreta (+-, mas descubram depois de ler o livro). Depois de te mostrar como se devem fazer as coisas (quer em termos de linguagem OO, quer do que os programadores devem usar), mostra as diferenças entre essa "teoria" e outras linguaguagens (c++ e java principalmente).
|
| | | | | De uma entrevista de 1993: CLB: What about object-oriented programming? Is it just a current buzzword, or does this approach appeal to you? Knuth: I've always thought of programming in that way, but I haven't used languages that help enforce the discipline; I've always enforced the discipline myself in other languages. Programming languages can now catch you if you make a mistake, and they make it easier for you to hide information from one part of the program to another. In my own programs, with older languages, I wouldn't use what I wasn't supposed to use; I would have to discipline myself to follow these rules. I could, so I did. There weren't programs I couldn't write... but the new tools do help. The problem that I have with them today is that... C++ is too complicated. At the moment, it's impossible for me to write portable code that I believe would work on lots of different systems, unless I avoid all exotic features. Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said "OK, we'll do them both". So the language is too baroque for my taste. But each user of C++ has a favorite subset, and that's fine. CWEB fully supports C++ as well as C. Como está (na prática) o C++ hoje em dia, quanto à questão da portabilidade e à profusão de "exotic features" (estas suponho que não terão diminuído... mas ainda não usei C++ e daí a curiosidade)?
|
| | | | | | Bem, o Knuth tem razão no que diz, o que interessa é disciplina na programação, as ferramentas só dão uma ajudinha.
Quanto ao estado do C++, bem... quem já programou em C++ e já deu uma olhada a todas as funcionalidades que ela contém decerto já chegou à conclusão que não houve "design", apenas o acrescento do funcionalidades ad-hoc. Quem decidia o que entrava para a linguagem devia ser do género "ei, isso é fixe, bora meter!" e não tinha absolutamente preocupação de como iria ficar o produto final. Resultado: excesso de funcionalidade. Ninguém consegue meter o C++ todo na cabeça, tem de se ter um livro para referência sempre à mão. No final cada um acaba por usar apenas um subset da linguagem, exactamente como diz o Knuth.
O C++ seria perfeito se o "stripassem" de algumas funcionalidades (mas sem chegar ao ponto do Java) como o "operator overloading" que dá mais chatisses do que alegrias.
É curioso que ele tenha dito isso em 93, porque hoje em dia o C++ tem muito mais funcionalidades, logo é ainda mais verdade!
-- Carlos Rodrigues
- "I think my men can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| |
|
