C ou C++

pedro Rafael
(usa Fedora)

Enviado em 25/09/2008 - 21:09h

Pessoal gostaria de saber se existe vantagem de usar a linguagem C em relação C++. Eu estudo matemática e preciso de uma lingagem pra trabalhar com função. Apesar de existir de existir inúmeros codigos feitos na área de matemática em Fortran e apesar de também existir linguagem sofisticada para trabalhar com funções como Haskell, meu professor quer que usemos C ou C++ pois ele afirma que é mais rápido e porque com elas trabalhamos mais perto dos hardware...

Eu tenho uma amigo que fala que C já era. Isso é verdade? Eu sei também que por C++ ter a ideia de classes e ser uma linguagem orientada à objeto, fica mais fácil reaproveitar os códigos aumentanto desssa forma a produtividade do programador. Mais será que existe alguma vantagem em usar C para meus trabalhos em matemática???

Eu já tenho um livro de C entitulado "C completo e Total" e nem uma material de C++ a não ser ums tutoriais que nem chegam perto do nível de explicação desse livro, pois tenho todos esses livros que baixei da net de graça em PDF.

Bem as perguntas básicas são essas: "Ha alguma vantagem em usar C em vez de C++?"
"Um programa feito em C++ tb pode ser feito em C, mesmo que o codigo seja maior e mais complicado????"


valeu pessoal

javamizer
(usa Suse)

Enviado em 26/09/2008 - 14:42h

Primeiramente:
C++ é um C melhorado, assim como Java é um C++ melhorado.
Um programa feito em C++ pode ser feito em C, mas o codigo será maior e mais complicado, pois em C++ existem recursos que não existem em C, como orientação a objeto e tudo a ela relacionada.

Entretanto:
Tu sabe programar orientado a objeto? Pois já li esse livro, e ele é C puro e 100% estruturado, nem cita o que é uma linguagem orientada a objeto pois isso não era usado quando o livro foi escrito.
Se vc se sente mais a vontade programando em C, com estruturas, e precisa desse programa para logo, faça seu programa em C mesmo, pois não vai dar tempo de aprender orientação a objeto, caso contrário faça em C++, e aprenda POO, pois orientação a objeto é uma tendência e veio para substituir programação estruturada.

thuck
(usa Debian)

Enviado em 26/09/2008 - 17:05h

Melhorado??? Vc está redondamente enganado. C++ não é a melhora do C, e muito menos Java é a melhoria do C++.

Eles usam paradigmas de programação diferente, e o fato de C++ ser OO, não o torna melhor que C.
C++ serve para um propósito completamente diferente do propósito de C. O mesmo vale para Java e C++. São linguagens de msm paradigma, mas são voltados para programações diferentes.

javamizer
(usa Suse)

Enviado em 26/09/2008 - 17:25h

Pedro Rafael, esqueci de citar que existem pssoas que encaram linguagens de programação como times de futebol, cada um escolhe o seu, alguns torcem para um time sem motivo algum, se ele ficar ruim com o passar dos anos a pessoa não deixa de torcer por ele, outros simplesmente arrumam um time que está ganhando para torcer, e existem pessoas que formam torcidas organizadas para espancar outros times e até mesmo pessoas do mesmo time deles caso manifestem desejo de torcer para outro time.
Não acredite em tudo o que dizem por aí na internet, antes, confirme de várias fontes antes de tomar decisões.
Todo mundo sabe que "C" evoluiu do "B", que "C++" evoluiu do "C", e que o "Java" evoluiu do "C++", se não sabe java aprenda e verá por si próprio.

thuck
(usa Debian)

Enviado em 26/09/2008 - 17:46h

Ai ai... tsc tsc. Obrigado pela instrução de como as linguagens de programação Evoluiram no decorrer do tempo, obrigado por falar que B->C->C++; fiquei abismado com a sua inteligência absoluta sobre a história das linguagens. Clap,clap,clap.

Vamos dar os parábens ao seu professor de Engenharia de Software, vc decorou direitinho a lição de casa, vamos lidar com a realidade das coisas e não delirar.

Java não é, e nunca será a evolução de C++. C++ não é melhor que C, são usadas para coisas diferentes. Se vc não entende que linguagens são ferramentas, e não uma questão de escolha pessoal, mas sim de qual é melhor para aquela situação, então por favor, não seja programador.
Em absoluto acho que devemos usar C em todas as situações, assim como acho que Java não deve ser usado para tudo, assim como acho que C++, também não, assim como nenhuma linguagem é A LINGUAGEM.

Todas tem qualidades e defeitos.

javamizer
(usa Suse)

Enviado em 26/09/2008 - 18:53h

Conclusão do tópico:

O usuário HPedro foi o único que tentou responder a pergunta do tópico até agora em vez de ficar procurando brigar com os colegas.

E parece que alguns programadores C não sabem programar em Java.

Pedro Rafael
(usa Fedora)

Enviado em 26/09/2008 - 23:49h

Bem o espaço ainda está aberto para respostas. Seria bem mais produtivo responder minha pergunta sem tantas brigas, apesar de até tirar algum proveito das respostas acima. Mais acredito que proveito seria bem melhor sem tanto bate boca...


mais de qualquer forma valeu aí...

f_Candido
(usa Ubuntu)

Enviado em 27/09/2008 - 10:16h

Seguindo a linha: B->C->C++->D?
Claro!!! Que não!!!.
Bom, mas respondendo ao tópico, ambas as linguagens são ótimas. Mas, para cada caso vai existir uma solução melhor. Um momento pode ser em C, outro em C++. Por exemplo até Python, poderia ser incluído nesta lista. Sim, Python tem um pacote super interessante para aplicações matemáticas. Então, cabe ao caso de uso, mostrar qual a melhor linguagem para aquele caso. Um detalhe: C não é ultrapassada, caso isso fosse verdade, Cobol já teria ido embora de aplicações comerciais. Mas volto a ressaltar, depende do caso de uso. Outro detalhe: Java usou a sintaxe da linguagem C++, mas foi fundamentada em SmallTalk, bom não sabe o que é Smalltalk? Bom, aí já é outro problema.

Abraços

javamizer
(usa Suse)

Enviado em 27/09/2008 - 10:27h

Pedro Rafael, conhece a wikipédia? É uma fonte de informações confiável.
veja que interessante:


"Em Smalltalk tudo é objeto: os números, as classes, os métodos, blocos de código, etc. Não há tipos primitivos, ao contrário de outras linguagens orientadas a objeto (como Java)".

http://pt.wikipedia.org/wiki/Smalltalk

Sem comentários.

thuck
(usa Debian)

Enviado em 27/09/2008 - 10:58h

Bem, como disse antes, mas aparentemente "existem pssoas que encaram linguagens de programação como times de futebol" e acham que Java, e OO são a salvação dos problemas dos softwares, e quem não usa esse tipo de programação é ultrapassado (WTF).

Bem, vamos lá. Primeiro, eu passei quatro anos programando em Java, e acho uma linguagem muito boa, embora seja extremamente burocrática. Segundo, não sou programador C, ela é uma linguagem boa, e não vai morrer, e por motivos completamente diferentes dos motivos de que porque Cobol não vai. Terceiro, OO realmente vai ser o paradigma dos próximos anos, MAS sinceramente não me importo em qual paradigma tenho que programar, simplesmente porque acredito que há situações em que cada um é uma solução melhor.

Usar OO e Java para tudo, ou C para tudo é uma limitação dos programados que dizem coisas como "existem pssoas que encaram linguagens de programação como times de futebol"; são esses programadores que vão usar um garfo para comer sopa, um garfo para abrir latas, um garfo para fazer burracos, não importa oo cenário, é sempre a mesma coisa.
Mas normalmente esse tipo de pessoa acaba somente com a parte de programação, e não vai virar gerente de projeto, onde vc precisa analisar os casos, e não ser preconceituoso e antes de saber o problema já falar que a solução é está ou aquele.

javamizer
(usa Suse)

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

OK, parece que chamos num acordo finalmente, concordo com o colega na afirmação acima exceto na indereta que me tange.

Pedro, prucure tirar proveito, e coloque uma coisa na cabeça, sempre que se comparam linguagens de programação isso gera muita polêmica.

Aprenda as liguagens que achar necessário mas lembre-se:

"Uma linguagem que não afeta seu jeito de pensar sobre programação não vale a pena aprender."

- Alan Jay Perlis

mslomp
(usa Slackware)

Enviado em 27/09/2008 - 11:45h

vou tentar ajudar em sua decisão focando-me no seu problema em específico (matemática), e levando em conta as linguagens C e C++ apenas, sem entrar em xiitismos e formalismos acadêmicos (que na teoria são muito bonitinhos, mas na prática nem sempre funcionam - e mais adiante ilustrarei isso)

como engenheiro e também colaborador do projeto GCC, posso analisar sua questão sob 2 pontos de vista distintos, mas que possuem muito em comum.
há tempos atrás pesquisei muito sobre o método de elementos finitos (fem) para análise térmica e de tensões em materiais, e como sabe, uma análise dessas pode levar à resolução de matrizes gigantescas, da ordem 100 mil x 100 mil, por exemplo. resolvê-las computacionalmente exige muito critério, onde um algoritmo mal pensado pode significar minutos ou até mesmo horas a mais de processamento. na época, dava meus primeiros passos com otimização de código e explorava o "submundo" do código do GCC, pude determinar a melhor abordagem para o meu problema, visando tanto a precisão quanto a velocidade de resposta, e é aqui que encaixarei minha opinião enquanto colaborador do GCC:

há um consenso entre os desenvolvedores do GCC, embora velado, que C++, do ponto de vista do desenvolvimento do compilador, dá muito mais dor de cabeça que o compilador C. isso porque a orientação a objetos, os templates e demais "features" do C++ podem, se não bem utilizados, levar a situações de código extremamente sujo e ininteligível não apenas para nós humanos, mas também para o próprio compilador. se você verificar a base de bugs (bugzilla) do GCC, vai notar que há muito mais ICEs (internal compiler error) reportados para o compilador C++ do que para o C.
e na minha opinião, quando se trabalha com matemática, é importante que o código seja o mais limpo e claro possível, pois um bugzinho qualquer pode virar um inferno. e, mais do que isso, vamos ver o que muda internamente, no campo do código gerado, ao utilizar C (numa abordagem procedural direta) ou C++ (oop):

tomemos um exemplo bobo, com uma soma simples. em C usando uma função e em C++ usando o método de uma classe:

C:
int soma(int,int);

int main(void) {
int x;
x = soma(3, 5);
return x;
}

int soma(int a,int b) {
return(a+b);
}

C++:
class oper {
public:
oper() {};
int soma(int a, int b) {
return(a + b);
}
};

int main(void) {
int x;
oper o;
x = o.soma(3, 5);
return x;
}

compilando ambos sem otimizações (a fim de enxergar o que acontece na prática), vamos ver o código gerado para a chamada da função soma em ambos os casos (não colocarei toda a saída assembly por questões de espaço):
$ gcc -S -c teste.c -o teste.c.s
$ g++ -S -c teste.cpp -o teste.cpp.s

C:
pushl $5
pushl $3
call _soma

C++:
pushl $5
pushl $3
leal -9(%ebp), %eax
pushl %eax
call __ZN4oper4somaEii

para ser mais otimista, nem estou considerando a descarga da pilha após cada chamada no caso C++. veja que temos 2 instruções a mais, um lea e um push, que a grosso modo salvam algumas informações de escopo local e buscam a posição do método na memória (visto que classes são tratadas como porções distintas do código). em um 486+, isso significa 2 ciclos de máquina a mais (lea = 1 ciclo, push = 1 ciclo também). aí você pode dizer: "ah, mas meu core duo pro ultra master com 500 núcleos e refrigeração a nitrogênio líquido nem vai sentir isso, afinal, o que são para ele 2 ciclos, apenas alguns míseros nanosegundos, talvez nem isso". vai sim, pode acreditar. tome o caso de nossas matrizes 100 mil x 100 mil. coloque essa chamada em um laço com milhões e milhões de iterações, por exemplo. teremos então, milhões e milhões de ciclos a mais sendo executados, consumindo tempo de processamento. e, como dizem na terra do tio sam, "time is money". perceba que esse exemplo é bobo, mas imagine um código mais complexo, com dezenas de chamadas a métodos, atribuições de propriedades, referências e derreferências de classes, etc. a coisa toda vai crescer exponencialmente, e o processador gastará mais tempo com isso do que com o trabalho útil em si. e em casos assim, mesmo ativando-se todas as otimizações aplicáveis, ainda assim sobrarão alguns ciclos. e observe que nem entramos no mérito da fpu, onde a coisa tende a piorar.

bem, não querendo colocar lenha na discussão causada por sua questão, apenas gostaria de fazer uma observação. quando da implementação do tree-ssa (que foi um grande passo e tornou possível inclusive 20 novas otimizações na geração de código), a partir do GCC4, resolveram utilizar uma abordagem totalmente acadêmica. resultado: na prática a coisa não deslanchava a contento. começaram então a surgir patches nada acadêmicos, digamos assim, e então a coisa começou a tomar forma. o próprio kernel do linux passou por isso, e tornou-se viável de fato quando foi perdendo o radicalismo acadêmico do "minix-like".

como leitura adicional, há alguns anos publiquei um artigo demonstrando de maneira simples de que modo a otimização afeta o código gerado (naquele caso, utilizando o compilador microsoft do visual c++). não foca nenhuma linguagem em específico, porém talvez possa ser útil apenas para ilustrar o assunto e ajudar na reflexão:
http://www.codeproject.com/KB/tips/optimizations.aspx

e agora, após toda essa leitura, e apenas para descontrair, aqui vai uma contribuição: quer ficar mais próximo do hardware? puxe a cadeira mais para a frente. :D