Você pode criar aplicações web utilizando CGI com C.
Eu já criei alguns exemplos de página web com a linguagem C.
A produtividade não é boa, até porque não é o objetivo da linguagem ser produtivo em projetos web, mas é possível fazer quase qualquer tipo de sistema web com ela.
Você pode criar aplicações web utilizando CGI com C.
Eu já criei alguns exemplos de página web com a linguagem C.
A produtividade não é boa, até porque não é o objetivo da linguagem ser produtivo em projetos web, mas é possível fazer quase qualquer tipo de sistema web com ela.[/quote]
À grosso modo dá pra fazer sim sistemas pra Web com CGI’s. O sistema que eu dou manuntenção atualmente tem uns CGI’s em Delphi que geram HTML com CSS pra fazer algumas páginas Web da aplicação. É um negócio bastante feio e de baixa produtividade, mas é algo que dá pra fazer com C.
Você pode criar aplicações web utilizando CGI com C.
Eu já criei alguns exemplos de página web com a linguagem C.
A produtividade não é boa, até porque não é o objetivo da linguagem ser produtivo em projetos web, mas é possível fazer quase qualquer tipo de sistema web com ela.[/quote]
À grosso modo dá pra fazer sim sistemas pra Web com CGI’s. O sistema que eu dou manuntenção atualmente tem uns CGI’s em Delphi que geram HTML com CSS pra fazer algumas páginas Web da aplicação. É um negócio bastante feio e de baixa produtividade, mas é algo que dá pra fazer com C.[/quote]
Com as tecnologias atuais, você tem que ter um bom motivo para desenvolver usando CGI.
Você pode criar aplicações web utilizando CGI com C.
Eu já criei alguns exemplos de página web com a linguagem C.
A produtividade não é boa, até porque não é o objetivo da linguagem ser produtivo em projetos web, mas é possível fazer quase qualquer tipo de sistema web com ela.[/quote]
À grosso modo dá pra fazer sim sistemas pra Web com CGI’s. O sistema que eu dou manuntenção atualmente tem uns CGI’s em Delphi que geram HTML com CSS pra fazer algumas páginas Web da aplicação. É um negócio bastante feio e de baixa produtividade, mas é algo que dá pra fazer com C.[/quote]
Com as tecnologias atuais, você tem que ter um bom motivo para desenvolver usando CGI.[/quote]
Pois é, estamos falando só pra dizer mesmo que é possível desenvolver Web com C. Não que alguém vá fazer isso hoje em dia (até porque como já citaram mais de uma vez aqui, C não foi concebido pra esse tipo de desenolvimento).
cara eu to muito confuso… nos Docs ta escrito que é C
…mais na pasta HotSpot da OpenJDK realmente é 95% C++
Diretório: openjdk\hotspot\src\share\vm
dentro dessa pasta esta todo o codigo que da pra ser usado entre os SOs win/linux/solaris etc…:
esse código da openjdk não é o código original da jdk não é… ?
pode ser que hoje, as vms da oracle sejam em C++…
nem sei… antes dava pra baixar os fontes, ai a oracle comprou, zicou tudo
[/quote]
O “código original do JDK” é o OpenJDK mais alguns fontes referentes a bibliotecas que a Oracle/Sun tinha comprado para poder usar no JDK e que ela não pode redistribuir como código open-source. Mas o objetivo da Oracle é justamente de substituir tudo por código open-source, exceto, é claro, por um pedaço do código que ela precisa para criar uma versão paga do JDK (que tem alguns recursos de monitoração que não existem nessa versão que você baixa de graça).
Elas sempre foram em C++, sei lá porque o documento fala em “ANSI C”. Deve ser um documento criado por alguém do departamento de marketing 
cara eu to muito confuso… nos Docs ta escrito que é C
…mais na pasta HotSpot da OpenJDK realmente é 95% C++
Diretório: openjdk\hotspot\src\share\vm
dentro dessa pasta esta todo o codigo que da pra ser usado entre os SOs win/linux/solaris etc…:
esse código da openjdk não é o código original da jdk não é… ?
pode ser que hoje, as vms da oracle sejam em C++…
nem sei… antes dava pra baixar os fontes, ai a oracle comprou, zicou tudo
[/quote]
O “código original do JDK” é o OpenJDK mais alguns fontes referentes a bibliotecas que a Oracle/Sun tinha comprado para poder usar no JDK e que ela não pode redistribuir como código open-source. Mas o objetivo da Oracle é justamente de substituir tudo por código open-source, exceto, é claro, por um pedaço do código que ela precisa para criar uma versão paga do JDK (que tem alguns recursos de monitoração que não existem nessa versão que você baixa de graça).
Elas sempre foram em C++, sei lá porque o documento fala em “ANSI C”. Deve ser um documento criado por alguém do departamento de marketing
[/quote]
rsrsrs…
Mudando um pouco do assunto principal do tópico, mas já que tocaram em “openjdk”. Alguém aí já usou o 7? Ou sabem me dizer se melhorou em relação ao 6?
Alguém usou um framework para se criar web em C? Ou vocês escreveram código GDI na mão?
É que acho muito engraçado, pq geralmente o pessoal de Java compara C e C++ básicos, sem o uso de qualquer framework (inclusive as padrão, como STL) com Java + todos os frameworks existentes.
Sei que existem frameworks interessantes e renomados para desenvolvimento web em C.
E claro, você usará C na linguagem do servidor, mas provavelmente produzirá páginas em uma linguagem de script + html + javascript, um modelo muito parecido com o que fazemos com Java e JSP.
Mas claro, o forte do C em web não é velocidade de desenvolvimento (até pq, mesmo com tudo, o C ainda é o C), mas ter um servidor extremamente enxuto, capaz de processar com leveza milhares de requisições por segundo.
[quote=ViniGodoy]
Mas claro, o forte do C em web não é velocidade de desenvolvimento (até pq, mesmo com tudo, o C ainda é o C), mas ter um servidor extremamente enxuto, capaz de processar com leveza milhares de requisições por segundo.[/quote]
O problema de programadores C e C++ é que eles pararam no tempo. Pensam que “programa rápido” é aquele que vai de 1 a 1 bilhão em nanosegundos.
Não é assim que se mede performance em um sistema com alta concorrência.
[quote=Longino]O problema de programadores C e C++ é que eles pararam no tempo. Pensam que “programa rápido” é aquele que vai de 1 a 1 bilhão em nanosegundos.
Não é assim que se mede performance em um sistema com alta concorrência.[/quote]
Quem foi que parou no tempo?
Existem frameworks inteiros só para lidar com concorrência, e outros que tem concorrência em seu núcleo, tais como boost::thread, Qt, e ZeroMQ.
Existem até ferramentas para multithreading altamente paralelo sem uso de locks, integração com linguagens funcionais, entre outras coisas.
Aliás, muito antes de aparecer em outras linguagens, já se fazia processamento paralelo com Cuda e OpenCL, em processadores de placas de vídeo com mais de 200 núcleos.
Se quiser fazer trolling, Longino, pelo menos informe-se antes.
[quote=Longino][quote=ViniGodoy]
Mas claro, o forte do C em web não é velocidade de desenvolvimento (até pq, mesmo com tudo, o C ainda é o C), mas ter um servidor extremamente enxuto, capaz de processar com leveza milhares de requisições por segundo.[/quote]
O problema de programadores C e C++ é que eles pararam no tempo. Pensam que “programa rápido” é aquele que vai de 1 a 1 bilhão em nanosegundos.
Não é assim que se mede performance em um sistema com alta concorrência.[/quote]
você pode postar sua experiência com benchmarks para todos os leitores aqui. Dessa maneira as pessoas podem se esclarecer e tirar suas próprias conclusões.
[quote=ViniGodoy][quote=Longino]O problema de programadores C e C++ é que eles pararam no tempo. Pensam que “programa rápido” é aquele que vai de 1 a 1 bilhão em nanosegundos.
Não é assim que se mede performance em um sistema com alta concorrência.[/quote]
Quem foi que parou no tempo?
Existem frameworks inteiros só para lidar com concorrência, e outros que tem concorrência em seu núcleo, tais como boost::thread, Qt, e ZeroMQ.
Existem até ferramentas para multithreading altamente paralelo sem uso de locks, integração com linguagens funcionais, entre outras coisas.
Aliás, muito antes de aparecer em outras linguagens, já se fazia processamento paralelo com Cuda e OpenCL, em processadores de placas de vídeo com mais de 200 núcleos.
Se quiser fazer trolling, Longino, pelo menos informe-se antes.[/quote]
Tenho trabalhado com a QtConcurrent. Atende bem os problemas que enfrento no dia a dia.
http://developer.qt.nokia.com/doc/qt-4.8/qtconcurrent.html
O exemplo abaixo mostra como gerar thumbnails de várias imagens repartindo o processamento em várias threads
[code] #include
#include
#include
#include
#include
#include <qtconcurrentmap.h>
#ifndef QT_NO_CONCURRENT
QImage scale(const QImage &image)
{
qDebug() << “Scaling image in thread” << QThread::currentThread();
return image.scaled(QSize(100, 100), Qt::IgnoreAspectRatio, Qt::SmoothTransformation);
}
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
const int imageCount = 20;
// Create a list containing imageCount images.
QList<QImage> images;
for (int i = 0; i < imageCount; ++i)
images.append(QImage(1600, 1200, QImage::Format_ARGB32_Premultiplied));
// Use QtConcurrentBlocking::mapped to apply the scale function to all the
// images in the list.
QList<QImage> thumbnails = QtConcurrent::blockingMapped(images, scale);
return 0;
}
int main()
{
qDebug() << “Qt Concurrent is not yet supported on this platform”;
}
#endif[/code]
[quote=juliocbq][quote=Longino][quote=ViniGodoy]
Mas claro, o forte do C em web não é velocidade de desenvolvimento (até pq, mesmo com tudo, o C ainda é o C), mas ter um servidor extremamente enxuto, capaz de processar com leveza milhares de requisições por segundo.[/quote]
O problema de programadores C e C++ é que eles pararam no tempo. Pensam que “programa rápido” é aquele que vai de 1 a 1 bilhão em nanosegundos.
Não é assim que se mede performance em um sistema com alta concorrência.[/quote]
você pode postar sua experiência com benchmarks para todos os leitores aqui. Dessa maneira as pessoas podem se esclarecer e tirar suas próprias conclusões.[/quote]
Por que todo desenvolvedor C++ se acha a última bolacha do pacote? Não tenho nada contra linguagem alguma, mas programadores C++ são o pior grupo de fanbabacas do planeta Terra. Não existe nada que C++ faça que outras tecnologias não façam melhor, e ainda deixa a desejar em diversos aspectos.
Dá uma olha nisso: http://lambda-the-ultimate.org/node/1277 . O cara é um dos fundadores da Epic, e ele fala da experiência dele e o que ele espera das próximas tecnologias. Admitindo que C++ é inadequado para o que ele faz. E essa é a realidade, C++ é inadequado para o desenvolvimento moderno de software. Essa porcaria pertence ao século XX, e não ao nosso.
Dá uma olhada nisso aqui: http://www.sics.se/~joe/apachevsyaws.html . O Apache, escrito em C, pede arrego para um sistema escrito em Erlang.
Não sei de onde tiraram que “sistema feito em C” é “melhor”, é mais provável que seja pior (e mais lento, e mais bugado, etc), pois o pobre do desenvolvedor precisará fazer tudo manualmente.
Não me acho a última bolacha do pacote porque conheço c++, trabalho com várias outras linguagens e sei a importância delas.
c++ também suporta recursos funcionais. Além do mais esse quesito funcional e questão de paralelismo não é garantia de software liso. Posso citar vários casos em que repartir processamento em várias threads pode arrebentar com o desempenho de um software, e uma delas é em operações de I/O.
Se o apache não suporta 4000 sessões paralelas é porque ele não foi desenhado para isso. Simples assim. Não tem nada a ver com o tipo de linguagem.
Esse artigo é tão sinistro que não tem nem data de publicação. O último postado lá com data é de 2002.
[quote]Não sei de onde tiraram que “sistema feito em C” é “melhor”, é mais provável que seja pior (e mais lento, e mais bugado, etc), pois o pobre do desenvolvedor precisará fazer tudo manualmente.
[/quote]
É mais rápido porque o compilador gera código enxuto e mais otimizado do que qualquer tecnologia que tenha várias camadas de software. É simplesmente uma questão física.
Quanto menos instruções a se executar em um processador, mais rápido é o programa. Por essa razão o melhor programador é aquele que melhor domina algoritmos. O que deixa essa sua tese sobre linguagens modernas completamente quebrada.
Em vez de ficar postando esses artigos sem data de publicação você poderia falar por si mesmo. Mostrando as vantagens das linguagens funcionais(porque realmente existem muitas). Iria agregar muito para nós mesmo.
[quote=juliocbq]
É mais rápido porque o compilador gera código enxuto e mais otimizado do que qualquer tecnologia que tenha várias camadas de software. É simplesmente uma questão física.[/quote]
Você sabia que diversas linguagens, assim como Scheme ou Common Lisp, compilam para C e rodam nativamente? Não é necessário usar C para se ter esse tipo de performance. A minha implementação CL não tem esse tipo de compilação, mas quem sabe um dia.
Aliás, otimizações feitas em tempo de execução, que são impossíveis em C, podem trazer inúmeras vantagens. Não é simplesmente uma questão de “código enxuto”. A única coisa que “código enxuto” garante é que ele ocupará menos memória, mas não necessariamente será mais rápido ou melhor.
[quote=juliocbq]
Em vez de ficar postando esses artigos sem data de publicação você poderia falar por si mesmo. Mostrando as vantagens das linguagens funcionais(porque realmente existem muitas). Iria agregar muito para nós mesmo.[/quote]
Linguagens funcionais são um assunto bem grande. Eu tento postar o que é pertinente ao tópico sendo discutido. A apresentação do Tim Sweeney no lambda-the-ultimate é muito interessante para quem gosta de linguagens de programação, pois é um termômetro sobre o que empresas líderes de mercado pensam.
o número de instruções sempre ditará a velocidade de um programa. Quantidade de memória utilizada é proporcional ao número de recursos alocados dinamicamente. Se otimizações feitas em tempo de execução ditassem desempenho, todas os runtimes que interpretam ou utilizam de just in time compilation teriam desempenho superior a runtimes estáticos e sabemos muito bem que isso não é verdade.
Como linguagens funcionais não “guardam estado” se torna fácil paralelizar e verificar programas. Tento utilizar o máximo desses recursos quando trabalho com c#. Mas em termos de cpu e memória esse tipo de ferramenta é menos eficiente que linguagens imperativas. A seção Efficiency issues explica isso no artigo seguinte.
acredito que o futuro seja uma linguagem mista entre esses paradigmas, o que c# e c++11 estão se tornando.
Essa porcaria que você se refere é a base de quase todos os programas que você usa. Inclusive do sistema operacional que você está utilizando no momento.
Se não fosse essa porcaria, você não teria a linguagem Java como ela é hoje.
Seu comentário foi desnecessário e sem fundamento algum.
[quote=Stacker]
Essa porcaria que você se refere é a base de quase todos os programas que você usa. Inclusive do sistema operacional que você está utilizando no momento.
Se não fosse essa porcaria, você não teria a linguagem Java como ela é hoje.
Seu comentário foi desnecessário e sem fundamento algum.[/quote]
Você tem a mínima de noção de como um compilador funciona? A pergunta não é provocação não, é apenas porque a sua afirmação foi tão esdrúxula que dá a impressão que você acha que “C++” é a razão disso tudo existir. Haha
Se não fosse C, seria Pascal. Se não fosse Pascal, seria outra. E assim por diante. C++ não tem absolutamente nada de especial. É uma linguagem porca e obsoleta.
o número de instruções sempre ditará a velocidade de um programa. Quantidade de memória utilizada é proporcional ao número de recursos alocados dinamicamente. Se otimizações feitas em tempo de execução ditassem desempenho, todas os runtimes que interpretam ou utilizam de just in time compilation teriam desempenho superior a runtimes estáticos e sabemos muito bem que isso não é verdade. [/quote]
Não, não é. Em um sistema concorrente, isto é, qualquer desktop das Casas Bahia nos dias de hoje, a performance se obtem através de paralelização. E tanto a linguagem C quanto C++ não escalam para grandes quantidades de threads.
O exemplo que coloquei no post anterior trata justamente disso. Erlang é uma linguagem funcional projetada para concorrência e justamente por isso dá pau no Apache.
Otimizações em tempo de execução, por exemplo a remoçao de array bound check ou compilação, podem sim deixar o código mais rápido do que nativo.
[quote=juliocbq]
acredito que o futuro seja uma linguagem mista entre esses paradigmas, o que c# e c++11 estão se tornando.[/quote]
Haha.
Pelo amor de Deus, vai se informar. C++ somente agora tem biblioteca de Threads como parte do padrão. Bem-vindo à 1995. O negócio é tosco demais.
O C#, embora seja melhor do que C++, ainda tem os mesmos problemas que Java. Está longe de ser uma solução viável.
[quote=Longino][quote=Stacker]
Essa porcaria que você se refere é a base de quase todos os programas que você usa. Inclusive do sistema operacional que você está utilizando no momento.
Se não fosse essa porcaria, você não teria a linguagem Java como ela é hoje.
Seu comentário foi desnecessário e sem fundamento algum.[/quote]
Você tem a mínima de noção de como um compilador funciona? A pergunta não é provocação não, é apenas porque a sua afirmação foi tão esdrúxula que dá a impressão que você acha que “C++” é a razão disso tudo existir. Haha
Se não fosse C, seria Pascal. Se não fosse Pascal, seria outra. E assim por diante. C++ não tem absolutamente nada de especial. É uma linguagem porca e obsoleta.[/quote]
Hehehe
Eu acho C e C++ linguagens bonitas. Gosto pessoal.
Eu acho que é a forma de programar que pode ser porca. A linguagem não.
Se C tem ponteiros, é necessario saber trabalhar com eles.
Todos os Linux são escritos em C e C++ (E acho que continuarão), por isso que nunca essas linguagens serão obsoletas.
[quote=Longino]
Não, não é. Em um sistema concorrente, isto é, qualquer desktop das Casas Bahia nos dias de hoje, a performance se obtem através de paralelização. E tanto a linguagem C quanto C++ não escalam para grandes quantidades de threads.[/quote]
Não adianta paralelizar grandes blocos de código e esperar desempenho. Tente fazer esse tipo de processamento em cima de um arquivo que vai ter no mínimo uma queda de 20x o desempenho da sua aplicação. É só você ler os artigos acima.
Dá pau no apache porque o mesmo não foi desenhado para esse tipo de solução. É tão difícil assim de entender?
Não podem e nunca poderão. Pode fazer qualquer benchmark com esse tipo de tecnologia que elas sempre perderão para soluções estáticas. Aliás, posso te garantir que o quesito vm morrerá daqui alguns anos. Esse tipo de runtime é inútil, porque garbage collection e a maioria das funcionalidades presentes neles podem ser implementadas em soluções estáticas. Vide a linguagem “d”.
http://www.d-programming-language.org/comparison.html
[quote]Haha.
Pelo amor de Deus, vai se informar. C++ somente agora tem biblioteca de Threads como parte do padrão. Bem-vindo à 1995. O negócio é tosco demais.
O C#, embora seja melhor do que C++, ainda tem os mesmos problemas que Java. Está longe de ser uma solução viável.[/quote]
O engraçado é que na sua cabeça todas as soluções que não são viáveis são as mais utilizadas no planeta e ainda em larga escala. Linguagens funcionais estão a milênios de poder solucionar os problemas que as imperativas resolvem hoje (em termos de desempenho)
A perda de desempenho de compiladores funcionais é ainda logarítimica. E isso deixa todos os resultados bem abaixo das demais imperativas.
E eu tenho ainda que me informar? Você deveria trabalhar num filme de comédia. rsrsrs
Em vez de ficar me agredindo e acabar por queimar o filme do seu nick(longino) você poderia postar fatos.