c é uma linguagem de médio nível. Não se pode comparar as duas porque são ferramentas completamente diferentes. [quote] int main(){ //What a hell??Pra que merda main tem retorno int?? char c = 5000000; //Mais …

C é ling. de louco

D

douglaskd 14 de fev. de 2012

O JAVA FOI FEITO EM C…

o cara que manja mais java no mundo é louco por que programa em C ??? :?

C é antigo…ja existem tantos sistemas ai de baixo nivel que contem pogs como as que você citou…que se houvesse uma “atualização” da linguagem…daria muitas zicas nos códigos fontes…

mais tem coisa que eu admito é uma barbaridade rs…

você é professor de faculdade mesmo ?

S

Stacker 14 de fev. de 2012

Eu diria que eles são sortudos.

Quase todas as universidade de ponta que você for você vai ver que a linguagem base é C.

Você aprende muito programando em C.

R

rmendes08 15 de fev. de 2012

Como o julio disse, são ferramentas completamente diferentes. Dificilmente você vai conseguir escrever uma aplicação Web em C, acho que até existe CGI para C, mas com certeza sua produtividade será terrível. Em compensação, é a ferramenta ideal quando você precisa controlar hardware, interagir com o SO ou então fazer um controle da memória utilizada.

J

juliocbq 15 de fev. de 2012

Stacker:
juliocbq:

Se o “dar c” resume lecionar essa linguagem na faculdade seus alunos estão perdidos.

Eu diria que eles são sortudos.

Quase todas as universidade de ponta que você for você vai ver que a linguagem base é C.

Você aprende muito programando em C.

Não critiquei a linguagem c. Critiquei a quantidade de código escrito errado lá em cima. Se você ler por inteiro o meu post vai ver que eu concordo com você.

Não tem como ficar comparando java com c porque a segunda é uma linguagem concebida para programação de sistemas. Quando se diz sistemas quer dizer sistemas operacionais mesmo. Uma categoria de desenvolvimento chamada system programming.

A linguagem c é desenhada para desenvolver compiladores, kernels, softwares para microcontroladores e não para o desenvolvimento de aplicações como é o caso da java.

G

getAdicted 15 de fev. de 2012

Nietzsche:
Tenho um contato com Java a algum tempo…comecei na faculdade a dar C,
como essas cosias são possíveis?

int main(){ //What a hell??Pra que merda main tem retorno int?? char c = 5000000; //Mais de 16 bits unsigned O.O return 5; printf("%d",5); //O retorno ta na linha de cima,codigo inalcançável!! }

Alguem mais aew concorda comigo?Tava a um tempao sem postar,precisava compartilhar isso!!
Saudade de Java…tudo certinho,tudo no seu devido lugar…humpff :(

Esquece velho, C e Java são linguagens com propósitos diferentes, mesmo assim, como dizia um amigo: “C eh esculpir na pedra, Java eh macinha para modelar…” e C não é fortemente tipada como o Java.

[]'s

E

entanglement 15 de fev. de 2012

Nietzsche:
Tenho um contato com Java a algum tempo…comecei na faculdade a dar C,
como essas cosias são possíveis?

int main(){ //What a hell??Pra que merda main tem retorno int?? char c = 5000000; //Mais de 16 bits unsigned O.O return 5; printf("%d",5); //O retorno ta na linha de cima,codigo inalcançável!! }

Alguem mais aew concorda comigo?Tava a um tempao sem postar,precisava compartilhar isso!!
Saudade de Java…tudo certinho,tudo no seu devido lugar…humpff :(

Você está dando aulas de C? Aprenda algumas coisinhas antes de falar besteira.

a) O tipo de retorno da função main é “int” porque você fazer isto em C:

int main (int argc, char *argv[]) {
    return 1;
}

equivale a fazer isto em Java:

public static void main (String[] args) {
    System.exit (1);
}

Aliás, há vários jeitos corretos de declarar o main. Por exemplo, do jeito que eu escrevi, do jeito que você fez, ou então:

int main (int argc, char *argv[], char *envp[]) {

onde envp é um array das variáveis de ambiente do sistema (tal como System.getenv() no Java).

b) Um char tem 8 bits (não 16 bits como no Java - preste atenção!). O compilador pode aceitar o código acima - e nesse caso o comportamento, a rigor, é indefinido*, ou então gerar um warning. Isso é feito CONSCIENTEMENTE. Isso não é classificado como um erro.

O comportamento mais comum é a atribuição acima ser equivalente a:

char c = (char ) (5000000 & 0xFF);

mas pode ser que o compilador gere código equivalente a:

char c = (char ) ((5000000 & 0xFF000000) >> 24);

Portanto, você precisa tomar cuidado e sempre prestar atenção em todos os warnings que o compilador gera.

c) Na definição da linguagem C nada está escrito que o compilador tenha de fazer análise de fluxo e aceitar código “unreachable” (inalcançável). Ele pode gerar um warning nesse caso. Se você pensar bem, uma análise de fluxo bem-feita e na verdade mais difícil de fazer que parece, e muito código que você, em uma primeira olhada, diria que o código é executável, mas se a análise for feita, você vai ver que não é. Isso normalmente é feito por alguns compiladores (como o clang) que analisam seu programa inteiro (não apenas uma função isolada) para determinar se há “código morto”.

E

entanglement 15 de fev. de 2012

Aham, o JDK foi escrito em uma mistura de várias linguagens: C++, Assembly e Java.

Cuidado que C não é C++, assim como seu pai não é você. Ele “pode ter a sua cara” e metade dos seus genes, mas não é você.

M

maior_abandonado 15 de fev. de 2012

o problema ai seria a quantidade de gambiarra, não a linguagem em si… e gambiarra existe em qualquer linguagem.

D

douglaskd 15 de fev. de 2012

Aham, o JDK foi escrito em uma mistura de várias linguagens: C++, Assembly e Java.

Cuidado que C não é C++, assim como seu pai não é você. Ele “pode ter a sua cara” e metade dos seus genes, mas não é você.

nos Docs da Sun ta escrito que o runtime foi escrito em Ansi C

http://java.sun.com/docs/overviews/java/java-overview-1.html

“The Java system itself is quite portable. The compiler is written in Java and the runtime is written in ANSI C with a clean portability boundary. The portability boundary is essentially a POSIX subset.”

não posso dizer que o jdk original não usou C “nunca vi o código original”…mais o OpenJdk nas pastas do Hotspot e Native…usam tanto C++ quanto C…talves o assembly esteja no meio do código

mais na real…

o runtime é o verdadeiro java…ele que interpreta os bytecodes java e transforma em binario…essa transformação pelo hotspot em algumas partes é compilada em C++, mas o executavel la que segura a JVM que esta dentro do runtime é em Ansi C

por exemplo, o PHP foi feito em C, e é como se os bytecodes java estivessem no mesmo nivel de um código em php, para ser interpretado pelo Runtime (php.exe e JRE.exe)

J

juliocbq 15 de fev. de 2012

é verdade. O objetivo da linguagem c é ter pouca abstração do hardware, para que você possa fazer o que é passível de ser feito em assembly sem ter que lidar diretamente com mnemônicos.

M

maior_abandonado 15 de fev. de 2012

é verdade. O objetivo da linguagem c é ter pouca abstração do hardware, para que você possa fazer o que é passível de ser feito em assembly sem ter que lidar diretamente com mnemônicos.

<troll> há quem diga que usar uma linguagem com pouca abstração assim hoje em dia com as opções que temos não é coisa de gente normal </troll>

hehe… brincadeira…

E

entanglement 15 de fev. de 2012

Aham, o JDK foi escrito em uma mistura de várias linguagens: C++, Assembly e Java.

OK, concordo que há alguns fontes em C no fonte do JDK (que pode ser baixado em http://www.java.net/download/openjdk/jdk7u2/promoted/b13/openjdk-7u2-fcs-src-b13-17_nov_2011.zip ) mas eles normalmente são para implementar certas coisas, como o suporte a compressão via zlib, que foram escritos por terceiros. Mas o grosso mesmo é C++, que não é C, assim como você não é seu pai (ou sua mãe), embora tenha metade dos genes dele (dela).

J

juliocbq 15 de fev. de 2012

é verdade. O objetivo da linguagem c é ter pouca abstração do hardware, para que você possa fazer o que é passível de ser feito em assembly sem ter que lidar diretamente com mnemônicos.

<troll> há quem diga que usar uma linguagem com pouca abstração assim hoje em dia com as opções que temos não é coisa de gente normal </troll>

hehe… brincadeira…

apesar de alguns falarem esse monte de bobagens, esse tipo de linguagem é essencial no desenvolvimento de hardware. Existem linguagens de sistemas mais modernas como c++ e d(Que também são linguagens de alto nível).

por exemplo, em um hd moderno hoje existem uma boa quantidade de circuitos de controle que necessitam desse tipo de software.

E

entanglement 15 de fev. de 2012

O runtime do Java é bem grande, e ele realmente tem muito código em C++. Por exemplo, o just-in-time compiler, que é um programa super-complexo e que é necessário para o Java transformar os bytecodes (.class) para código de máquina, é em C++.

J

juliocbq 15 de fev. de 2012

o hotspot usa parte do projeto llvm para otimizar código de máquina.

eu nunca usei esse clang aí, mas deve ser bom.

http://llvm.org/

D

douglaskd 15 de fev. de 2012

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

D

douglaskd 15 de fev. de 2012

aqui ta a definição dos bytecodes no arquivo bytecodes.cpp

// initialize bytecode tables - didn't use static array initializers
  // (such as {}) so we can do additional consistency checks and init-
  // code is independent of actual bytecode numbering.
  //
  // Note 1: NULL for the format string means the bytecode doesn't exist
  //         in that form.
  //
  // Note 2: The result type is T_ILLEGAL for bytecodes where the top of stack
  //         type after execution is not only determined by the bytecode itself.

  //  Java bytecodes
  //  bytecode               bytecode name           format   wide f.   result tp  stk traps
  def(_nop                 , "nop"                 , "b"    , NULL    , T_VOID   ,  0, false);
  def(_aconst_null         , "aconst_null"         , "b"    , NULL    , T_OBJECT ,  1, false);
  def(_iconst_m1           , "iconst_m1"           , "b"    , NULL    , T_INT    ,  1, false);
  def(_iconst_0            , "iconst_0"            , "b"    , NULL    , T_INT    ,  1, false);
  def(_iconst_1            , "iconst_1"            , "b"    , NULL    , T_INT    ,  1, false);
  def(_iconst_2            , "iconst_2"            , "b"    , NULL    , T_INT    ,  1, false);
  def(_iconst_3            , "iconst_3"            , "b"    , NULL    , T_INT    ,  1, false);
  def(_iconst_4            , "iconst_4"            , "b"    , NULL    , T_INT    ,  1, false);
  def(_iconst_5            , "iconst_5"            , "b"    , NULL    , T_INT    ,  1, false);
  def(_lconst_0            , "lconst_0"            , "b"    , NULL    , T_LONG   ,  2, false);
  def(_lconst_1            , "lconst_1"            , "b"    , NULL    , T_LONG   ,  2, false);
  def(_fconst_0            , "fconst_0"            , "b"    , NULL    , T_FLOAT  ,  1, false);
  def(_fconst_1            , "fconst_1"            , "b"    , NULL    , T_FLOAT  ,  1, false);
  def(_fconst_2            , "fconst_2"            , "b"    , NULL    , T_FLOAT  ,  1, false);
  def(_dconst_0            , "dconst_0"            , "b"    , NULL    , T_DOUBLE ,  2, false);
  def(_dconst_1            , "dconst_1"            , "b"    , NULL    , T_DOUBLE ,  2, false);
  def(_bipush              , "bipush"              , "bc"   , NULL    , T_INT    ,  1, false);
  def(_sipush              , "sipush"              , "bcc"  , NULL    , T_INT    ,  1, false);
  def(_ldc                 , "ldc"                 , "bk"   , NULL    , T_ILLEGAL,  1, true );
  def(_ldc_w               , "ldc_w"               , "bkk"  , NULL    , T_ILLEGAL,  1, true );
  def(_ldc2_w              , "ldc2_w"              , "bkk"  , NULL    , T_ILLEGAL,  2, true );
  def(_iload               , "iload"               , "bi"   , "wbii"  , T_INT    ,  1, false);
  def(_lload               , "lload"               , "bi"   , "wbii"  , T_LONG   ,  2, false);
  def(_fload               , "fload"               , "bi"   , "wbii"  , T_FLOAT  ,  1, false);
  def(_dload               , "dload"               , "bi"   , "wbii"  , T_DOUBLE ,  2, false);
  def(_aload               , "aload"               , "bi"   , "wbii"  , T_OBJECT ,  1, false);
  def(_iload_0             , "iload_0"             , "b"    , NULL    , T_INT    ,  1, false);
  def(_iload_1             , "iload_1"             , "b"    , NULL    , T_INT    ,  1, false);
  def(_iload_2             , "iload_2"             , "b"    , NULL    , T_INT    ,  1, false);
  def(_iload_3             , "iload_3"             , "b"    , NULL    , T_INT    ,  1, false);
  def(_lload_0             , "lload_0"             , "b"    , NULL    , T_LONG   ,  2, false);
  def(_lload_1             , "lload_1"             , "b"    , NULL    , T_LONG   ,  2, false);
  def(_lload_2             , "lload_2"             , "b"    , NULL    , T_LONG   ,  2, false);
  def(_lload_3             , "lload_3"             , "b"    , NULL    , T_LONG   ,  2, false);
  def(_fload_0             , "fload_0"             , "b"    , NULL    , T_FLOAT  ,  1, false);
  def(_fload_1             , "fload_1"             , "b"    , NULL    , T_FLOAT  ,  1, false);
  def(_fload_2             , "fload_2"             , "b"    , NULL    , T_FLOAT  ,  1, false);
  def(_fload_3             , "fload_3"             , "b"    , NULL    , T_FLOAT  ,  1, false);
  def(_dload_0             , "dload_0"             , "b"    , NULL    , T_DOUBLE ,  2, false);
  def(_dload_1             , "dload_1"             , "b"    , NULL    , T_DOUBLE ,  2, false);
  def(_dload_2             , "dload_2"             , "b"    , NULL    , T_DOUBLE ,  2, false);
  def(_dload_3             , "dload_3"             , "b"    , NULL    , T_DOUBLE ,  2, false);
  def(_aload_0             , "aload_0"             , "b"    , NULL    , T_OBJECT ,  1, true ); // rewriting in interpreter
  def(_aload_1             , "aload_1"             , "b"    , NULL    , T_OBJECT ,  1, false);
  def(_aload_2             , "aload_2"             , "b"    , NULL    , T_OBJECT ,  1, false);
  def(_aload_3             , "aload_3"             , "b"    , NULL    , T_OBJECT ,  1, false);
  def(_iaload              , "iaload"              , "b"    , NULL    , T_INT    , -1, true );
  def(_laload              , "laload"              , "b"    , NULL    , T_LONG   ,  0, true );
  def(_faload              , "faload"              , "b"    , NULL    , T_FLOAT  , -1, true );
  def(_daload              , "daload"              , "b"    , NULL    , T_DOUBLE ,  0, true );
  def(_aaload              , "aaload"              , "b"    , NULL    , T_OBJECT , -1, true );
  def(_baload              , "baload"              , "b"    , NULL    , T_INT    , -1, true );
  def(_caload              , "caload"              , "b"    , NULL    , T_INT    , -1, true );
  def(_saload              , "saload"              , "b"    , NULL    , T_INT    , -1, true );
  def(_istore              , "istore"              , "bi"   , "wbii"  , T_VOID   , -1, false);
  def(_lstore              , "lstore"              , "bi"   , "wbii"  , T_VOID   , -2, false);
  def(_fstore              , "fstore"              , "bi"   , "wbii"  , T_VOID   , -1, false);
  def(_dstore              , "dstore"              , "bi"   , "wbii"  , T_VOID   , -2, false);
  def(_astore              , "astore"              , "bi"   , "wbii"  , T_VOID   , -1, false);
  def(_istore_0            , "istore_0"            , "b"    , NULL    , T_VOID   , -1, false);
  def(_istore_1            , "istore_1"            , "b"    , NULL    , T_VOID   , -1, false);
  def(_istore_2            , "istore_2"            , "b"    , NULL    , T_VOID   , -1, false);
  def(_istore_3            , "istore_3"            , "b"    , NULL    , T_VOID   , -1, false);
  def(_lstore_0            , "lstore_0"            , "b"    , NULL    , T_VOID   , -2, false);
  def(_lstore_1            , "lstore_1"            , "b"    , NULL    , T_VOID   , -2, false);
  def(_lstore_2            , "lstore_2"            , "b"    , NULL    , T_VOID   , -2, false);
  def(_lstore_3            , "lstore_3"            , "b"    , NULL    , T_VOID   , -2, false);
  def(_fstore_0            , "fstore_0"            , "b"    , NULL    , T_VOID   , -1, false);
  def(_fstore_1            , "fstore_1"            , "b"    , NULL    , T_VOID   , -1, false);
  def(_fstore_2            , "fstore_2"            , "b"    , NULL    , T_VOID   , -1, false);
  def(_fstore_3            , "fstore_3"            , "b"    , NULL    , T_VOID   , -1, false);
  def(_dstore_0            , "dstore_0"            , "b"    , NULL    , T_VOID   , -2, false);
  def(_dstore_1            , "dstore_1"            , "b"    , NULL    , T_VOID   , -2, false);
  def(_dstore_2            , "dstore_2"            , "b"    , NULL    , T_VOID   , -2, false);
  def(_dstore_3            , "dstore_3"            , "b"    , NULL    , T_VOID   , -2, false);
  def(_astore_0            , "astore_0"            , "b"    , NULL    , T_VOID   , -1, false);
  def(_astore_1            , "astore_1"            , "b"    , NULL    , T_VOID   , -1, false);
  def(_astore_2            , "astore_2"            , "b"    , NULL    , T_VOID   , -1, false);
  def(_astore_3            , "astore_3"            , "b"    , NULL    , T_VOID   , -1, false);
  def(_iastore             , "iastore"             , "b"    , NULL    , T_VOID   , -3, true );
  def(_lastore             , "lastore"             , "b"    , NULL    , T_VOID   , -4, true );
  def(_fastore             , "fastore"             , "b"    , NULL    , T_VOID   , -3, true );
  def(_dastore             , "dastore"             , "b"    , NULL    , T_VOID   , -4, true );
  def(_aastore             , "aastore"             , "b"    , NULL    , T_VOID   , -3, true );
  def(_bastore             , "bastore"             , "b"    , NULL    , T_VOID   , -3, true );
  def(_castore             , "castore"             , "b"    , NULL    , T_VOID   , -3, true );
  def(_sastore             , "sastore"             , "b"    , NULL    , T_VOID   , -3, true );
  def(_pop                 , "pop"                 , "b"    , NULL    , T_VOID   , -1, false);
  def(_pop2                , "pop2"                , "b"    , NULL    , T_VOID   , -2, false);
  def(_dup                 , "dup"                 , "b"    , NULL    , T_VOID   ,  1, false);
  def(_dup_x1              , "dup_x1"              , "b"    , NULL    , T_VOID   ,  1, false);
  def(_dup_x2              , "dup_x2"              , "b"    , NULL    , T_VOID   ,  1, false);
  def(_dup2                , "dup2"                , "b"    , NULL    , T_VOID   ,  2, false);
  def(_dup2_x1             , "dup2_x1"             , "b"    , NULL    , T_VOID   ,  2, false);
  def(_dup2_x2             , "dup2_x2"             , "b"    , NULL    , T_VOID   ,  2, false);
  def(_swap                , "swap"                , "b"    , NULL    , T_VOID   ,  0, false);
  def(_iadd                , "iadd"                , "b"    , NULL    , T_INT    , -1, false);
  def(_ladd                , "ladd"                , "b"    , NULL    , T_LONG   , -2, false);
  def(_fadd                , "fadd"                , "b"    , NULL    , T_FLOAT  , -1, false);
  def(_dadd                , "dadd"                , "b"    , NULL    , T_DOUBLE , -2, false);
  def(_isub                , "isub"                , "b"    , NULL    , T_INT    , -1, false);
  def(_lsub                , "lsub"                , "b"    , NULL    , T_LONG   , -2, false);
  def(_fsub                , "fsub"                , "b"    , NULL    , T_FLOAT  , -1, false);
  def(_dsub                , "dsub"                , "b"    , NULL    , T_DOUBLE , -2, false);
  def(_imul                , "imul"                , "b"    , NULL    , T_INT    , -1, false);
  def(_lmul                , "lmul"                , "b"    , NULL    , T_LONG   , -2, false);
  def(_fmul                , "fmul"                , "b"    , NULL    , T_FLOAT  , -1, false);
  def(_dmul                , "dmul"                , "b"    , NULL    , T_DOUBLE , -2, false);
  def(_idiv                , "idiv"                , "b"    , NULL    , T_INT    , -1, true );
  def(_ldiv                , "ldiv"                , "b"    , NULL    , T_LONG   , -2, true );
  def(_fdiv                , "fdiv"                , "b"    , NULL    , T_FLOAT  , -1, false);
  def(_ddiv                , "ddiv"                , "b"    , NULL    , T_DOUBLE , -2, false);
  def(_irem                , "irem"                , "b"    , NULL    , T_INT    , -1, true );
  def(_lrem                , "lrem"                , "b"    , NULL    , T_LONG   , -2, true );
  def(_frem                , "frem"                , "b"    , NULL    , T_FLOAT  , -1, false);
  def(_drem                , "drem"                , "b"    , NULL    , T_DOUBLE , -2, false);
  def(_ineg                , "ineg"                , "b"    , NULL    , T_INT    ,  0, false);
  def(_lneg                , "lneg"                , "b"    , NULL    , T_LONG   ,  0, false);
  def(_fneg                , "fneg"                , "b"    , NULL    , T_FLOAT  ,  0, false);
  def(_dneg                , "dneg"                , "b"    , NULL    , T_DOUBLE ,  0, false);
  def(_ishl                , "ishl"                , "b"    , NULL    , T_INT    , -1, false);
  def(_lshl                , "lshl"                , "b"    , NULL    , T_LONG   , -1, false);
  def(_ishr                , "ishr"                , "b"    , NULL    , T_INT    , -1, false);
  def(_lshr                , "lshr"                , "b"    , NULL    , T_LONG   , -1, false);
  def(_iushr               , "iushr"               , "b"    , NULL    , T_INT    , -1, false);
  def(_lushr               , "lushr"               , "b"    , NULL    , T_LONG   , -1, false);
  def(_iand                , "iand"                , "b"    , NULL    , T_INT    , -1, false);
  def(_land                , "land"                , "b"    , NULL    , T_LONG   , -2, false);
  def(_ior                 , "ior"                 , "b"    , NULL    , T_INT    , -1, false);
  def(_lor                 , "lor"                 , "b"    , NULL    , T_LONG   , -2, false);
  def(_ixor                , "ixor"                , "b"    , NULL    , T_INT    , -1, false);
  def(_lxor                , "lxor"                , "b"    , NULL    , T_LONG   , -2, false);
  def(_iinc                , "iinc"                , "bic"  , "wbiicc", T_VOID   ,  0, false);
  def(_i2l                 , "i2l"                 , "b"    , NULL    , T_LONG   ,  1, false);
  def(_i2f                 , "i2f"                 , "b"    , NULL    , T_FLOAT  ,  0, false);
  def(_i2d                 , "i2d"                 , "b"    , NULL    , T_DOUBLE ,  1, false);
  def(_l2i                 , "l2i"                 , "b"    , NULL    , T_INT    , -1, false);
  def(_l2f                 , "l2f"                 , "b"    , NULL    , T_FLOAT  , -1, false);
  def(_l2d                 , "l2d"                 , "b"    , NULL    , T_DOUBLE ,  0, false);
  def(_f2i                 , "f2i"                 , "b"    , NULL    , T_INT    ,  0, false);
  def(_f2l                 , "f2l"                 , "b"    , NULL    , T_LONG   ,  1, false);
  def(_f2d                 , "f2d"                 , "b"    , NULL    , T_DOUBLE ,  1, false);
  def(_d2i                 , "d2i"                 , "b"    , NULL    , T_INT    , -1, false);
  def(_d2l                 , "d2l"                 , "b"    , NULL    , T_LONG   ,  0, false);
  def(_d2f                 , "d2f"                 , "b"    , NULL    , T_FLOAT  , -1, false);
  def(_i2b                 , "i2b"                 , "b"    , NULL    , T_BYTE   ,  0, false);
  def(_i2c                 , "i2c"                 , "b"    , NULL    , T_CHAR   ,  0, false);
  def(_i2s                 , "i2s"                 , "b"    , NULL    , T_SHORT  ,  0, false);
  def(_lcmp                , "lcmp"                , "b"    , NULL    , T_VOID   , -3, false);
  def(_fcmpl               , "fcmpl"               , "b"    , NULL    , T_VOID   , -1, false);
  def(_fcmpg               , "fcmpg"               , "b"    , NULL    , T_VOID   , -1, false);
  def(_dcmpl               , "dcmpl"               , "b"    , NULL    , T_VOID   , -3, false);
  def(_dcmpg               , "dcmpg"               , "b"    , NULL    , T_VOID   , -3, false);
  def(_ifeq                , "ifeq"                , "boo"  , NULL    , T_VOID   , -1, false);
  def(_ifne                , "ifne"                , "boo"  , NULL    , T_VOID   , -1, false);
  def(_iflt                , "iflt"                , "boo"  , NULL    , T_VOID   , -1, false);
  def(_ifge                , "ifge"                , "boo"  , NULL    , T_VOID   , -1, false);
  def(_ifgt                , "ifgt"                , "boo"  , NULL    , T_VOID   , -1, false);
  def(_ifle                , "ifle"                , "boo"  , NULL    , T_VOID   , -1, false);
  def(_if_icmpeq           , "if_icmpeq"           , "boo"  , NULL    , T_VOID   , -2, false);
  def(_if_icmpne           , "if_icmpne"           , "boo"  , NULL    , T_VOID   , -2, false);
  def(_if_icmplt           , "if_icmplt"           , "boo"  , NULL    , T_VOID   , -2, false);
  def(_if_icmpge           , "if_icmpge"           , "boo"  , NULL    , T_VOID   , -2, false);
  def(_if_icmpgt           , "if_icmpgt"           , "boo"  , NULL    , T_VOID   , -2, false);
  def(_if_icmple           , "if_icmple"           , "boo"  , NULL    , T_VOID   , -2, false);
  def(_if_acmpeq           , "if_acmpeq"           , "boo"  , NULL    , T_VOID   , -2, false);
  def(_if_acmpne           , "if_acmpne"           , "boo"  , NULL    , T_VOID   , -2, false);
  def(_goto                , "goto"                , "boo"  , NULL    , T_VOID   ,  0, false);
  def(_jsr                 , "jsr"                 , "boo"  , NULL    , T_INT    ,  0, false);
  def(_ret                 , "ret"                 , "bi"   , "wbii"  , T_VOID   ,  0, false);
  def(_tableswitch         , "tableswitch"         , ""     , NULL    , T_VOID   , -1, false); // may have backward branches
  def(_lookupswitch        , "lookupswitch"        , ""     , NULL    , T_VOID   , -1, false); // rewriting in interpreter
  def(_ireturn             , "ireturn"             , "b"    , NULL    , T_INT    , -1, true);
  def(_lreturn             , "lreturn"             , "b"    , NULL    , T_LONG   , -2, true);
  def(_freturn             , "freturn"             , "b"    , NULL    , T_FLOAT  , -1, true);
  def(_dreturn             , "dreturn"             , "b"    , NULL    , T_DOUBLE , -2, true);
  def(_areturn             , "areturn"             , "b"    , NULL    , T_OBJECT , -1, true);
  def(_return              , "return"              , "b"    , NULL    , T_VOID   ,  0, true);
  def(_getstatic           , "getstatic"           , "bJJ"  , NULL    , T_ILLEGAL,  1, true );
  def(_putstatic           , "putstatic"           , "bJJ"  , NULL    , T_ILLEGAL, -1, true );
  def(_getfield            , "getfield"            , "bJJ"  , NULL    , T_ILLEGAL,  0, true );
  def(_putfield            , "putfield"            , "bJJ"  , NULL    , T_ILLEGAL, -2, true );
  def(_invokevirtual       , "invokevirtual"       , "bJJ"  , NULL    , T_ILLEGAL, -1, true);
  def(_invokespecial       , "invokespecial"       , "bJJ"  , NULL    , T_ILLEGAL, -1, true);
  def(_invokestatic        , "invokestatic"        , "bJJ"  , NULL    , T_ILLEGAL,  0, true);
  def(_invokeinterface     , "invokeinterface"     , "bJJ__", NULL    , T_ILLEGAL, -1, true);
  def(_invokedynamic       , "invokedynamic"       , "bJJJJ", NULL    , T_ILLEGAL,  0, true );
  def(_new                 , "new"                 , "bkk"  , NULL    , T_OBJECT ,  1, true );
  def(_newarray            , "newarray"            , "bc"   , NULL    , T_OBJECT ,  0, true );
  def(_anewarray           , "anewarray"           , "bkk"  , NULL    , T_OBJECT ,  0, true );
  def(_arraylength         , "arraylength"         , "b"    , NULL    , T_VOID   ,  0, true );
  def(_athrow              , "athrow"              , "b"    , NULL    , T_VOID   , -1, true );
  def(_checkcast           , "checkcast"           , "bkk"  , NULL    , T_OBJECT ,  0, true );
  def(_instanceof          , "instanceof"          , "bkk"  , NULL    , T_INT    ,  0, true );
  def(_monitorenter        , "monitorenter"        , "b"    , NULL    , T_VOID   , -1, true );
  def(_monitorexit         , "monitorexit"         , "b"    , NULL    , T_VOID   , -1, true );
  def(_wide                , "wide"                , ""     , NULL    , T_VOID   ,  0, false);
  def(_multianewarray      , "multianewarray"      , "bkkc" , NULL    , T_OBJECT ,  1, true );
  def(_ifnull              , "ifnull"              , "boo"  , NULL    , T_VOID   , -1, false);
  def(_ifnonnull           , "ifnonnull"           , "boo"  , NULL    , T_VOID   , -1, false);
  def(_goto_w              , "goto_w"              , "boooo", NULL    , T_VOID   ,  0, false);
  def(_jsr_w               , "jsr_w"               , "boooo", NULL    , T_INT    ,  0, false);
  def(_breakpoint          , "breakpoint"          , ""     , NULL    , T_VOID   ,  0, true);

  //  JVM bytecodes
  //  bytecode               bytecode name           format   wide f.   result tp  stk traps  std code

  def(_fast_agetfield      , "fast_agetfield"      , "bJJ"  , NULL    , T_OBJECT ,  0, true , _getfield       );
  def(_fast_bgetfield      , "fast_bgetfield"      , "bJJ"  , NULL    , T_INT    ,  0, true , _getfield       );
  def(_fast_cgetfield      , "fast_cgetfield"      , "bJJ"  , NULL    , T_CHAR   ,  0, true , _getfield       );
  def(_fast_dgetfield      , "fast_dgetfield"      , "bJJ"  , NULL    , T_DOUBLE ,  0, true , _getfield       );
  def(_fast_fgetfield      , "fast_fgetfield"      , "bJJ"  , NULL    , T_FLOAT  ,  0, true , _getfield       );
  def(_fast_igetfield      , "fast_igetfield"      , "bJJ"  , NULL    , T_INT    ,  0, true , _getfield       );
  def(_fast_lgetfield      , "fast_lgetfield"      , "bJJ"  , NULL    , T_LONG   ,  0, true , _getfield       );
  def(_fast_sgetfield      , "fast_sgetfield"      , "bJJ"  , NULL    , T_SHORT  ,  0, true , _getfield       );

  def(_fast_aputfield      , "fast_aputfield"      , "bJJ"  , NULL    , T_OBJECT ,  0, true , _putfield       );
  def(_fast_bputfield      , "fast_bputfield"      , "bJJ"  , NULL    , T_INT    ,  0, true , _putfield       );
  def(_fast_cputfield      , "fast_cputfield"      , "bJJ"  , NULL    , T_CHAR   ,  0, true , _putfield       );
  def(_fast_dputfield      , "fast_dputfield"      , "bJJ"  , NULL    , T_DOUBLE ,  0, true , _putfield       );
  def(_fast_fputfield      , "fast_fputfield"      , "bJJ"  , NULL    , T_FLOAT  ,  0, true , _putfield       );
  def(_fast_iputfield      , "fast_iputfield"      , "bJJ"  , NULL    , T_INT    ,  0, true , _putfield       );
  def(_fast_lputfield      , "fast_lputfield"      , "bJJ"  , NULL    , T_LONG   ,  0, true , _putfield       );
  def(_fast_sputfield      , "fast_sputfield"      , "bJJ"  , NULL    , T_SHORT  ,  0, true , _putfield       );

  def(_fast_aload_0        , "fast_aload_0"        , "b"    , NULL    , T_OBJECT ,  1, true , _aload_0        );
  def(_fast_iaccess_0      , "fast_iaccess_0"      , "b_JJ" , NULL    , T_INT    ,  1, true , _aload_0        );
  def(_fast_aaccess_0      , "fast_aaccess_0"      , "b_JJ" , NULL    , T_OBJECT ,  1, true , _aload_0        );
  def(_fast_faccess_0      , "fast_faccess_0"      , "b_JJ" , NULL    , T_OBJECT ,  1, true , _aload_0        );

  def(_fast_iload          , "fast_iload"          , "bi"   , NULL    , T_INT    ,  1, false, _iload);
  def(_fast_iload2         , "fast_iload2"         , "bi_i" , NULL    , T_INT    ,  2, false, _iload);
  def(_fast_icaload        , "fast_icaload"        , "bi_"  , NULL    , T_INT    ,  0, false, _iload);

  // Faster method invocation.
  def(_fast_invokevfinal   , "fast_invokevfinal"   , "bJJ"  , NULL    , T_ILLEGAL, -1, true, _invokevirtual   );

  def(_fast_linearswitch   , "fast_linearswitch"   , ""     , NULL    , T_VOID   , -1, false, _lookupswitch   );
  def(_fast_binaryswitch   , "fast_binaryswitch"   , ""     , NULL    , T_VOID   , -1, false, _lookupswitch   );

  def(_return_register_finalizer , "return_register_finalizer" , "b"    , NULL    , T_VOID   ,  0, true, _return);

  def(_fast_aldc           , "fast_aldc"           , "bj"   , NULL    , T_OBJECT,   1, true,  _ldc   );
  def(_fast_aldc_w         , "fast_aldc_w"         , "bJJ"  , NULL    , T_OBJECT,   1, true,  _ldc_w );

  def(_shouldnotreachhere  , "_shouldnotreachhere" , "b"    , NULL    , T_VOID   ,  0, false);

isso é só a definição...

L

Luiz_Augusto_Prado 15 de fev. de 2012

Nietzsche:
Tenho um contato com Java a algum tempo…comecei na faculdade a dar C,
como essas cosias são possíveis?

int main(){ //What a hell??Pra que merda main tem retorno int?? char c = 5000000; //Mais de 16 bits unsigned O.O return 5; printf("%d",5); //O retorno ta na linha de cima,codigo inalcançável!! }

Alguem mais aew concorda comigo?Tava a um tempao sem postar,precisava compartilhar isso!!
Saudade de Java…tudo certinho,tudo no seu devido lugar…humpff :(

Se não estou enganado, o Turbo C da Borland já dava warnings sobre codigos inalcançáveis.

Confesso que eu tenho saudades do C, quando os hardwares eram novos e não existiam drivers para eles:

#include<stdio.h>
#include<dos.h>

void clr(void);
void get_c();
void cursor_p(void);
void s_page(void);

union REGS reg;

main()
{
	clr();
	get_c();
	putch(reg.h.ah);
	putch(reg.h.al);
}

void clr(void)
{
	reg.h.ah=0;
	reg.h.al=3;
	int86(0x0010,&reg,&reg);
}

void get_c()
{
	reg.h.ah=0;
	int86(0x0016,&reg,&reg);
}

void cursor_p(void)
{
	reg.h.bh=0;
	reg.h.al=3;
	int86(0x0010,&reg,&reg);
}

void s_page(void)
{
	reg.h.al=1;
	reg.h.ah=5;
	int86(0x0010,&reg,&reg);
}

A instrução int86 e o _asm eram nossa salvação.
Acho que nesse tempo a codificação era tão complicada que qualquer coisa que “funcionasse”, com gambiarra ou não era glorificada.

S

Stacker 15 de fev. de 2012

juliocbq:
Stacker:
juliocbq:

Se o “dar c” resume lecionar essa linguagem na faculdade seus alunos estão perdidos.

Eu diria que eles são sortudos.

Quase todas as universidade de ponta que você for você vai ver que a linguagem base é C.

Você aprende muito programando em C.

Não critiquei a linguagem c. Critiquei a quantidade de código escrito errado lá em cima. Se você ler por inteiro o meu post vai ver que eu concordo com você.

Não tem como ficar comparando java com c porque a segunda é uma linguagem concebida para programação de sistemas. Quando se diz sistemas quer dizer sistemas operacionais mesmo. Uma categoria de desenvolvimento chamada system programming.

A linguagem c é desenhada para desenvolver compiladores, kernels, softwares para microcontroladores e não para o desenvolvimento de aplicações como é o caso da java.

http://en.wikipedia.org/wiki/System_programming

Eu entendi sim :D.

E concordo com você. São de propósitos muito diferentes.

S

Stacker 15 de fev. de 2012

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.

M

matheuslmota 15 de fev. de 2012

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.

À 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.

S

Stacker 15 de fev. de 2012

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.

À 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.

Com as tecnologias atuais, você tem que ter um bom motivo para desenvolver usando CGI.

M

matheuslmota 15 de fev. de 2012

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.

À 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.

Com as tecnologias atuais, você tem que ter um bom motivo para desenvolver usando CGI.

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).

E

entanglement 15 de fev. de 2012

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

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

J

juliocbq 15 de fev. de 2012

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

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

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?

V

ViniGodoy 15 de fev. de 2012

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.

L

Longino 15 de fev. de 2012

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.

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.

V

ViniGodoy 15 de fev. de 2012

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.

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.

J

juliocbq 15 de fev. de 2012

Longino:
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.

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.

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.

J

juliocbq 15 de fev. de 2012

ViniGodoy:
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.

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.

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

#include <QImage>
 #include <QList>
 #include <QThread>
 #include <QDebug>
 #include <QApplication>
 #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;
 }

 #else

 int main()
 {
         qDebug() << "Qt Concurrent is not yet supported on this platform";
 }

 #endif

L

Longino 16 de fev. de 2012

juliocbq:
Longino:
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.

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.

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.

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.

J

juliocbq 16 de fev. de 2012

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.

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.

É 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.

L

Longino 16 de fev. de 2012

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.

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.

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.

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.

J

juliocbq 16 de fev. de 2012

Longino:

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. :)[/quote]
Sei sim, os compiladores de vala e objective c também funcionam dessa maneira. Mas sei também que o código gerado por eles pode ou não ser mais rápido dependendo do problema. O resultado em c pode ser um pouco maior do que uma pessoa com conhecimento necessário conseguiria produzir. A tabela abaixo mostra que c lisp pode ser até 10x mais lerdo que c para determinados tipos de problemas.

http://www.cliki.net/Performance%20Benchmarks

[quote]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.

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.

S

Stacker 16 de fev. de 2012

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.

L

Longino 17 de fev. de 2012

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.

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.

L

Longino 17 de fev. de 2012

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.

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.

juliocbq:

acredito que o futuro seja uma linguagem mista entre esses paradigmas, o que c# e c++11 estão se tornando.

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.

L

Luiz_Augusto_Prado 17 de fev. de 2012

Longino:
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.

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.

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.

J

juliocbq 17 de fev. de 2012

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.

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

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.

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.

L

Longino 17 de fev. de 2012

juliocbq:
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.

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.

Isso não faz o mínimo sentido. O problema de linguagens imperativas é justamente a dificuldade em paralelizar algoritmos. Linguagens funcionais são naturalmente paralelizáveis por causa do uso de estado imutável. Ou seja, o desenvolvedor não precisa fazer nada, a linguagem já faz tudo.

juliocbq:

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.

Dá pau no apache porque o mesmo não foi desenhado para esse tipo de solução. É tão difícil assim de entender?

Tem gente aqui que acha que um sistema feito em C, é “mais rápido” ou “melhor”. Provei que não é nem um e nem outro.

juliocbq:

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.

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

:shock:

Quê!? O dinamismo em ambiente de desenvolvimento é essencial não apenas para a melhora da performance de acordo estatísticas de uso do software, mas também para confiabilidade.

Métodos usados em linguagens como C++, contagem de referência, não fazem o custo desaparecer, apenas o dividem ao longo da aplicação. E coisas como alocação pode ser mais lenta do que Java.

juliocbq:

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)

Haha. Você não viu o link da apresentação do cara da Epic? Lá ele diz que C++ é inadequado e sugere coisas que seriam intreressantes.

juliocbq:

Em vez de ficar me agredindo e acabar por queimar o filme do seu nick(longino) você poderia postar fatos.

Jà psotei vários. Mas lhe falta conhecimento fundamental a respeito do que fala. Pesquise informações sobre paralelização e o paradigma funcional antes de falar qualquer coisa.

V

ViniGodoy 17 de fev. de 2012

Pessoal, peço que não respondam o Longino. Ele é um troller conhecido, chamado que antes atendia por thiagosc. Teve a conta bloqueada do fórum, pelo tom agressivo e pedante, e agora voltou com esse nick.

A argumentação dele nunca foi técnica. O histórico dele nunca mostrou qualquer contibuição com o fórum, nem o usuário apresentou qualquer trabalho concreto que tenha feito. O usuário é fãboy de linguagens funcionais, e sempre fala mal de qualquer linguagem diferente. Até hoje, não sei nem o que ele vem fazer no GUJ, além de trolling.

Eu, particularmente, estou insistindo que se bloqueie novamente a conta desse usuário. Assim, posso parar de trancar tópicos interessantes, como esse poderia ser.

M

Meth 14 de fev. de 2012

Tenho um contato com Java a algum tempo…comecei na faculdade a dar C,
como essas cosias são possíveis?

int main(){ //What a hell??Pra que merda main tem retorno int?? char c = 5000000; //Mais de 16 bits unsigned O.O return 5; printf("%d",5); //O retorno ta na linha de cima,codigo inalcançável!! }

Alguem mais aew concorda comigo?Tava a um tempao sem postar,precisava compartilhar isso!!
Saudade de Java…tudo certinho,tudo no seu devido lugar…humpff

M

Meth 17 de fev. de 2012

juliocbq:

Se o “dar c” resume lecionar essa linguagem na faculdade seus alunos estão perdidos.

Eu tive uma aula apenas…C não faz controle de nada,posso adcionar 10 milhões numa variável que so deveria aceitar 255 sendon unsigned!!Fazenbdo teste la em casa eu saquei que ao colocar os milhoes no char os bits sao eliminados!!
Foi somente uma aula compade,custa ser um pouco,um POUCO amigavel???

O.O ,mais post foi longeee!!Nem acreditei…

M

Meth 17 de fev. de 2012

What a hell??É pecado ser newbie nessa poha?E falei do literal a ser atribuiido na variavel,e nao do tipo primitivo char…
O.o

44 Respostas

Topicos relacionados