C ou C++

mslomp
(usa Slackware)

Enviado em 29/09/2008 - 22:54h

o "lixo" por nós referido não deve ser entendido sob ótica pejorativa. o resultado será o mesmo, porém por caminhos distintos. assim como se pode unir dois pontos através de uma reta (o caminho mais curto), podemos uni-los através de um arco ou uma série de retas congruentes. admitindo-se velocidade constante, logicamente o caminho reto será percorrido mais rapidamente. como não se pode alterar a rota, então o problema seria mexermos na velocidade a fim de que ao menos o tempo total do percurso mais longo seja no mínimo igual ao do mais curto. mas aí já é outra história, e renderia uma outra (boa) discussão.

eu acabei não emitindo opinião sobre C ser uma linguagem condenada à morte ou não. bem, tirando os aspectos tocantes à tradição e o "romantismo" por detrás da linguagem C, eu acredito que enquanto houverem necessidades que exijam, ou ao menos se adequem mais ao uso de C, ela estará entre nós. muitas linguagens ao longo dos anos surgiram com a premissa de "substituir o C". no entanto, elas permanecem no underground, enquanto o C parece não perder a majestade. isso ocorre até mesmo com outras linguagens antigas e que ainda são muito utilizadas, como é o caso da linguagem ADA. o grande erro dessas linguagens ditas promissoras cuja finalidade seria desbancar o C e seus derivados, em minha opinião, é acabarem por "viajar na maionese" acrescentando inúmeros "facilitadores" e implementações embutidas para tudo, e isso acaba por criar "lixo" demais, tornando-as inviáveis para aplicações críticas, ao contrário de C, onde as implementações específicas não fazem parte da linguagem, mas sim de bibliotecas externas como a libc por exemplo. felizmente o C++ seguiu esse mesmo raciocínio, abstendo-se de bibliotecas "core", e isso também fará o C++ se perpetuar, ou pelo menos ficar por aí por um longo tempo.

deixo aqui um fato curioso para que os amigos possam refletir se C++ veio ou não para substituir o C tradicional e/ou se essa substituição seria mesmo possível:
há um tempo atrás, no grupo de discussão de desenvolvedores do GCC, surgiu a idéia de reescrever o GCC em C++. uns a favor, outros não, cada um apresentando seus prós e contras. eis que então alguém expôs uma idéia bastante paradoxal, do tipo "quem veio antes, o ovo ou a galinha". seguinte: tendo sido C++ gerado através do C, um compilador auto-suficiente (capaz de, a partir de um bootstrap, compilar a si mesmo - e o GCC o é) em C++ deveria ser capaz de, antes de mais nada, implementar o próprio C++ - e para isso precisamos do C, que é sua linguagem-mãe. ou seja, seria necessário que o bootstrap fosse feito por um compilador C!
bem, o resultado dessa discussão é que há cerca de 2 ou 3 meses foi criado um branch na árvore do gcc chamada gcc-in-cxx que tenta reescrever o compilador em C++. ainda não há muito movimento por lá, mas creio que dentro de algum tempo as coisas se tornem interessantes.

ao colega Pedro Rafael: a quantas andam suas pesquisas e o desenvolvimento do seu aplicativo?

stremer
(usa Arch Linux)

Enviado em 30/09/2008 - 10:28h

simplesmente fantastico os comentários.
Agora dando meu "pitaco" e sendo um pouco mais curto e grosso. Falo: Aprenda... você pode nunca programar microcontroladores para precisar de assembly mas um dia poderá precisar dele para otimizar uma função de um programa em C, ou até criar um objeto todo em Assembly que será utilizado por um gigantesco sistema em Basic, ou até mesmo otimizar uma rotina de um sistema em java, acessando um objeto em C via JNI. Aprender pelo menos o basico de como funciona Assembly, compiladores e processadores é fundamental para qualquer programador pois um dia você pode precisar. Ignorar isto é burrice, como ja foi falado, é o que diferencia "usuários de ferramentas" de pessoas que resolvem problemas (vulgos gerentes de projeto como exemplo citado). C é uma linguagem poderosa que não vai morrer, ja sobreviveu ao tempo e como toda ferramenta, tem o seu propósito, devido a estar mais proxima da maquina. Imagine um kernel todo escrito somente em Assembly. Agora se observar o kernel linux grande parte dele é em Assembly mas a maior parte é em C pois ajuda a compreensão alem da portabilidade. Eu diria que C++ é melhor para sistmas gigantescos que precisam de uma certa performance e determinados recursos ainda não alcançados com um Java da vida mas que precisem de um código de facil manutenção. Sistemas tipicos para usuários finais, que também são muito diferentes de um Web Site ou de um sistema de cadastro de clientes feito em Java. Sei la, Java é uma otima linguagem, mas é preciso analisar se ela vai te atender, da mesma forma que temos de analisar se um sistema operacional ira nos atender.
No seu caso eu recomendo 100% aprender C e claro... Assembly...

albertguedes
(usa Gentoo)

Enviado em 30/09/2008 - 11:11h

Olá Pedro.
Se aceita uma sugestão, pra você que faz matemática, experimente o fortran.
Eu estudo física e não há linguagem melhor pra se trabalhar com funções matemáticas do que ele. Afianl, pra estar vivo por mais de 40 anos, o Fortran não é pouca coisa.
Até mais.

mslomp
(usa Slackware)

Enviado em 30/09/2008 - 22:00h

e particularmente para quem deseja aprender C e/ou C++, o Assembly fará com que alguns conceitos sejam trazidos à luz de forma mais prática e menos cabalística, como é o caso dos ponteiros (que são famosos por causarem confusão tanto para iniciantes quanto para experts).
é claro que, no caso do Pedro (o autor do tópico), não há necessidade de que ele deva tornar-se um guru da progrmação, haja visto que ele está estudando estatística, e não algo como ciência da computação. porém, mesmo como matemático, é importante observar que a matemática hoje utiliza a computação largamente, por motivos óbvios. sendo assim, um sólido conhecimento em programação irá agregar a ele muito valor como profissional, e com certeza isso será um grande diferencial num mercado concorrido como o atual.

em relação a linguagens como Java, conforme citado pelo stremer, há um fator crucial no que tange o desempenho da mesma em aplicações realmente críticas, e essa nem sempre é culpa do fato de possuir uma máquina virtual como pano de fundo, e sim do programador. uma máquina virtual nada mais é do que uma camada executiva operando sobre outra (o hardware real). a máquina virtual executará suas instruções, baseada nos seus bytecodes pré-programados e então a partir de cada combinação irá instruir (ou traduzir) o hardware real, que enfim executará no ambiente real. a grosso modo, uma máquina virtual é um interpretador de bytecodes. embora o compilador (tradutor para bytecodes) do java efetue diversas otimizações, a máquina virtual (que é um software) já possui estaticamente embutidos diversos métodos de operação conforme os bytecodes fornecidos. é aí que começa o problema. eu sei, fãs do Java, ela não é interpretada. ao menos não no sentido literal, mas comporta-se como tal sob alguns aspectos (como o que citei acima). exemplo clássico aplicado às linguagens interpretadas (amigos fãs de php, python e etc, reflitam isso) e que de certa maneira também afeta as baseadas em máquinas virtuais: o problema do laço for. na máquina virtual (ou num interpretador) já estão lá "impressas" as instruções sobre como traduzir o for para a máquina real (digamos, através de comparações e instruções do tipo jump).
aí o programador faz algo tipo:

for(i=0;i<=1000;i++)
x=i;

ok. como o exemplo é simples, mais uma vez a fins de entendimento apenas, desconsidere otimizações para o caso do compilador Java, supondo que esse laço for seja realmente transformado em uma série de jumps e comparações (em bytecode) conforme o pré-determinado na máquina virtual.
então suponhamos que a máquina virtual faça a seguinte tradução para o hardware real, baseando-se em seu template embutido para o laço for:

; eax fará o papel de x. ecx fará o papel de i
xor ecx,ecx
loop:
cmp ecx,1000d
jg exit
mov eax,ecx
inc ecx
jmp loop
exit:

ou seja: entre loop: e jmp loop (inclusive), serão executadas 5 instruções 1001 vezes (pois começa com ecx=0, e não estou contando a última vez incompleta com ecx=1001).
mas aí o programador recebe uma luz divina e resolve mudar tudo, fazendo pelo método mais difícil, tedioso, ilegível e aparentemente burro:

x = 0;
x = 1;
x = 2;
...
x = 1000;

dá uma trabalheira né? para nós sim, mas olhemos lá no outro lado da história:

mov eax,0d
mov eax,1d
...
mov eax,1000d

nosso amigo processador deve agora uma cerveja ao programador, pois reduziu seu trabalho a 1/5 do anterior - apenas 1 instrução sendo executada 1001 vezes, mudando-se apenas a abordagem lá na camada humana da coisa. o prejuízo está apenas no tamanho de código, mas aumentamos mais do que consideravelmente seu desempenho.

mas claro que isso não desmerece Java nem qualquer outra linguagem que se comporte de maneira semelhante. apenas discutimos aqui o uso das linguagens em aplicações (realmente) críticas, e para tais aplicações o melhor mesmo é permanecermos mais próximos da máquina (real), ainda que isso nos distancie um pouco da linguagem humana.

javamizer
(usa Suse)

Enviado em 30/09/2008 - 23:14h

Queria dexar só mais um humilde comentário de um auto-didata que nunca sentou nem no banco de um curso de extensão pra aprender se "x" é uma letra do alfabeto ou ou uma variável ou um ponteiro (ô delícia, que infelizmente não tem em Java), mas aprendeu tudo "no queixo duro".
Sinto-me honrado em ser chamado de acadêmico.

Para alguns colegas pode parecer estranho eu chegar aqui na comunidade de C/C++ e vir falando de Java, que Java é uma "evolução de C++". Primeiramente deixe explicar melhor meu ponto de vista, pois antes falei no calor da discução e não disse direito o que pensava na verdade:

Acho que Java é uma "evolução" (no sentido bom da palavra), simplesmente por trazer seu escopo de uma maneira mas "burocrática" (também no sentido bom da palavra), como comentado anteriormente por um colega, aí os colegas podem dizer: o que cara? então java é um gesso e você ainda gosta dela! Muito bem, mas por causa dessas "burocrácias" um código java é imensamente mais legível para iniciantes, e é justamente de iniciantes que empresas de desenvolvimento de software de pequeno e médio porte estão cheias! Me desculpem se não citei que sou Analista Contábil e trabalho em uma empresa de consultoria e auditoria.

Não acho também que java seja melhor que C, C++ ou qualquer outra linguagem, mas como vários colegas citaram ela tem suas qualidades e não são poucas (build once, run anywhere).
Particularmente gosto muito mais de programar em C e C++ pois pra mim não são linguagens, são duas obras de arte, em Java por exemplo não existem structs, ponteiros ou algo como malloc ou free, e é aí que está na minha opinião grande parte do brilho desseas linguagens, e particularmente fiquei "triste", por um lado, quando aprendi Java, justamente por falta dessas features.

E para terminar (ou não, hehe) gostaria que recompartilhar um post que fiz a tempos atraz aqui na comu que me rendeu alguns chingamentos, só pra ninguém pensar: Java é uma linguagem interpretada, tem uma VM embaixo, é lenta, o que esse cara quer provar?

É a implementação de uma lista duplamente encadeada em C++ e em Java respectivamente, que na prática não prova que Java pode ser mais rápido que C++ (shut up fanáticos!), é claro, mas pelomenos prova que não é tão medíocre quanto pensam por aí e como eu pensava, pois em sistemas sob demanda o que temos é extress de memória, basicamente, estou certo?
Fanáticos de plantão, quanto ao paralelismo é CLARO que pode ser implementado com threads em C++, não sejam óbvios por favor, não estou querendo provar nada.

http://vitorpamplona.com/wiki/JavaVsC+com+Processadores+CoreX

stremer
(usa Arch Linux)

Enviado em 01/10/2008 - 14:37h

hpedro... não vou discutir com vc a respeito de ser um guru em informática ou especialista sem ter feito nenhum curso pois acho que não cabe entrarmos neste detalhe neste post.

Só acho que o que você falou não faz muito sentido... ponteiros, structs, malloc, free não estão la por que são legais mas estão la pq dependendo do que você vai precisar fazer, poderá fazer bem melhor graças a eles...

Em relação a sua comparação de java e c++, novamente entramos no detalhe da melhor ferramenta para melhor tarefa... Você implementou uma lista encadeada... nesta situação java atendeu melhor, mas isso não significa que irá atender em todas... experimente desenvolver um web site com cgi em C (como se fazia antigamente)... agora para um propósito desses php acaba sendo muito mais produtivo e muitas vezes melhor até mesmo na performance, pois para criação do tal website, ninguem estaria pensando em um código c extremamente otimizado...
Em relação ao uso dos processadores... você poderia trabalhar com mais de um processador em C, só que teria que gerenciar o uso de memória dentre outras coisas em threads separadas o que resultaria um código muito mais complexo do que uma simples implementação de lista encadeada, ou seja, no mesmo caso que o php atenderia melhor a web, nesse tipo de caso o java atendeu melhor, mas não significa que seja realmente mais rapido... significa que o java melhora muita "implementação simples" mas por outro lado acaba te limitando de fazer muita coisa...
cada ferramenta deve ter seu devido uso...
infelizmente no brasil nossa realidade na maior parte das vezes é sermos usuários de tecnologia e não criadores destas, o que criamos na maior parte das vezes são sistemas de acesso a dados e que na maior parte das vezes, linguagens como VB/Delphi/Java/php/asp/etc acabam atendendo perfeitamente...

mslomp
(usa Slackware)

Enviado em 01/10/2008 - 15:33h

eu lembro de ter visto o tópico que o hpedro se referiu, onde a discussão beirou o baixo nível. eu ainda não li totalmente aquele benchmark, apenas dei uma olhada por cima (mais tarde, assim que o tempo permita, lerei com atenção).
bem, mesmo em uma rápida olhada, há 2 pontos a considerar que por si já acarretam prejuízo para o C++ na comparação. observe que não estou colocando em dúvida o teste, até mesmo porque ainda não li com a atenção necessária, então não formei opinião. são apenas alguns pontos notáveis desde já.

1 - quando você compila o código java, vai embutido junto o código "core" do java. ou seja, para esse caso, não haverá chamadas a componentes externos, tudo ocorre dentro do próprio "executável". daí já se observa que C++ já saiu em desvantagem injustamente, pois numa compilação padrão, os componentes "core" do C++ estarão em bibliotecas externas (libc e libstdc++). e como já citei em um post anterior, chamadas externas, queira-se ou não, vão afetar a performance da aplicação.
bom, para que haja justiça, o código C++ deveria ser compilado estaticamente, para que, da mesma forma que no java, não haja chamadas externas:

$ g++ chain.cpp -O3 -static

num teste rápido aqui, isso por si só já aumentou em mais de 20% a performance em termos de velocidade (e nem estou sob um core2, e sim num obsoleto athlon-xp).

2 - a máquina virtual do java já vem "de fábrica" tunada para rodar otimizado em processadores modernos, incluindo o core2. pergunta: seu gcc foi compilado para gerar código otimizado para o core2? pergunto isso porque o gcc que vem por padrão na maioria das distros ou é o native ou tunado para arquiteturas inferiores, por questões de compatibilidade. o do slackware, por exemplo, vem tunado para i486.
solução: compilar o próprio gcc, em uma versão 4.3+ (o suporte a core2 foi introduzido no md-i386 a partir do gcc 4.2) ou, melhor ainda, na versão 4.4 (devel) ativando suporte a core2 (-march=core2 - march, não mtune - pode experimentar também o nocona)

eMineiro
(usa Ubuntu)

Enviado em 17/11/2008 - 14:39h

Olá pferrarezi tenho 2 artigos para você ler!!

O primeiro tópico é o tópico de gente como você, escreve sem pensar ou sem ter embasamento algum no que está falando, leia também os comentários.
http://vidageek.net/2008/08/18/linguagens-de-programacao-c/

O segundo tópico é o direito de resposta do tópico acima:
http://murilo.wordpress.com/2008/11/14/direito-de-defesa-ao-cmaismais/

Veja cara, hoje em dia as linguagens são demasiadas grandes demais para se comparar ela por inteira.
Nao discuto com você em que java pode ser mais eficiente do que c ou c++ em alguns casos, mas em outros casos ele perde.
Se fosse assim, depois do c++ não existiria mais C, assim como depois do Java nao existiria C++

Agora quanto ao tópico.:
Cara você pode usar escolher qual das duas você quiser, as duas irão lhe proporcionar o mesmo efeito para este caso, procure opiniões de pessoas da sua area que programam em C ou C++, se eu fosse lhe recomendar eu lhe recomendaria C pois é a linguagem em que atualmente programo.

gondim
(usa FreeBSD)

Enviado em 11/01/2009 - 22:01h

Olá pessoal,

Sou novo aqui e vi que nos posts se falou muito e muito bem sobre C e seu uso atualmente. Achei interessante colocar os recentes números sobre o uso de várias linguagens. Sabendo-se que C subiu 2,01% em 2008 e C++ em segundo com 1,39%. Abaixo o link para vocês verem. :)

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Grande abraço

removido
(usa Nenhuma)

Enviado em 12/01/2009 - 13:33h

E o vencedor da BATALHA DAS LINGUAGENS É : ..... :)

Teixeira
(usa Linux Mint)

Enviado em 12/01/2009 - 20:15h

Quanto a essa coisa de "evolucao", isso nao quer dizer necessariamente que houve melhorias gritantes sobre a linguagem predecessora.

Senao vejamos:
Assembly resolve TODOS os problemas de programacao aproveitando-se de todos os recursos do processador. Como desvantagem, e' de programacao mais dificil e menos intuitiva, o que torna a documentacao uma verdadeira lastima.
Felizmente, os tais mnemonicos apareceram para quebrar o nosso galho.

Aproveitando-se das vantagens do Assembly em relacao a sua intimidade com o processador veio a linguagem C, guardando um pouco dos misterios de sua linguagem-mae.

A partir dai' as linguagens de niveis mais proximos ao ser humano - e mais longe do processador - passaram a ser vistas como melhorias ou evolucoes pelos programadores, pois sua utilizacao aumenta em muito o rendimento humano para elaborar o codigo.

Ou seja, gasta-se bem menos tempo para escrever as linhas de comando que, juntas, perfazem o programa.

O preco disso e' a grande quantidade de adendos - por vezes desnecessarios - que serao carregados juntamente com o programa para que ele venha a funcionar conforme o esperado.

Portanto, uma linguagem nem sempre e' "melhor" ou "pior" que outra.
Apenas mais adequada, ou nao, para uma determinada finalidade.

E as evolucoes serao sempre benvindas, muito embora saibamos que em alguns casos alguma coisa melhorou "para pior" isto e', que eventualmente venhamos a perder certas caracteristicas que nos agradavam anteriormente e que, de uma hora para outra, deixaram de ser implementadas, ou agora o sao de uma forma diferente de nosso agrado.