Mistura de códigos em C e C++

[Yoshio]

Olá pessoal.
Gostaria de saber se misturar códigos do C em C++ é errado? (Por
exemplo, utilizar cstdlib.h ou ctime.h)
Minha dúvida é porque como o C++ é derivado do C, não sei se utilizar
códigos do C é um fluxo natural da linguagem C++, não sendo apenas um
meio de prover compatibilidade com a linguagem C (workaround talvez).
Não sei se a pergunta é besta, mas é que achei somente artigos na
internet falando de como utilizar C em C++ e nada sobre o uso ou não
do C em C++.
Agradeço quem puder ajudar.

[/* Alberto Fabiano */]

2009/2/18 Yoshio <geany...@gmail.com>

Well,

       Não é elegante!

        Mas já vi esta combinção em vários grande projetos de embedded systems que utiliza C++. E ainda com pitadas de Assembly; que é inevitável!

[ivo nascimento]

Bem, ja vi mistura de codigos de C e C++ e concordo com o Alberto no fato de que não é elegante.
Ja vi sistemas escritos em C que utilizam um compilador C++ para serem gerados pois algumas coisas feitas no código somente os compiladores de C++ vão conseguir entender.
Pessoalmente, não vejo problema, portanto que tenha controle sobre o que você esta fazendo e o projeto não se torne algo de codigo complexo demais para manutenção(por complexo=bagunçado etc...)

2009/2/18 /* Alberto Fabiano */ <alb...@ccppbrasil.org>

--
Ivo Nascimento - Iann
-------------------------------------
|   twitter: ivonascimento .     |
|   http://ianntech.com.br.      |
|   ZCE ID 227463685            |
-------------------------------------

[Felipe Goron Farinon]

Pode-se usar as funções C em um programa C++. Só que porque usá-las
quando se pode usar por exemplo a classe std::string ao invés das
funções inseguras de manipulação de string em C?

- Felipe Farinon



2009/2/18 ivo nascimento <ian...@gmail.com>:

[Rick.]

Boa dia pessoal, sou programador Delphi e estou aprendendo c++ por prazer...

Mas a dica que posso dr como programador é..utilize todos os recursos do C++, creio que não irá precisar di C, porem ..se caso ja tiver algum projeto em C que queira compilar usando C++.. recomendo.aue converta o codigo..

é..esse foi meu primeiro coments..espero n ter falado merda..hehe

2009/2/18 Felipe Goron Farinon <felipe....@gmail.com>

[Erivaldo]

Talvez as libs em C sejam significantemente mais rapidas. Quando eu
participei da maratona de programacao, eramos orientados a usar printf
em vez do tradicional "cout <<", pq mesmo sendo mais elegante e type
safe, era mais lento. Se eu estivesse no linux agora testaria isso =)

2009/2/18 Felipe Goron Farinon <felipe....@gmail.com>:

--
Desadoc (Poldí no-perfectus)

[Felipe Magno de Almeida]

2009/2/18 Erivaldo <des...@gmail.com>:

>
> Talvez as libs em C sejam significantemente mais rapidas. Quando eu
> participei da maratona de programacao, eramos orientados a usar printf
> em vez do tradicional "cout <<", pq mesmo sendo mais elegante e type
> safe, era mais lento. Se eu estivesse no linux agora testaria isso =)

Ainda é mais lento em todos os compiladores que eu já usei :P.
Mas isso também é devido de a implementação do iostreams ser
normalmente feita sobre snprintf.
PS: Existem outros motivos também, como excesso de virtual calls.

[snip]

--
Felipe Magno de Almeida

[P.]

On 18 fev, 02:28, Yoshio <geanyos...@gmail.com> wrote:
> Olá pessoal.
> Gostaria de saber se misturar códigos do C em C++ é errado? (Por
> exemplo, utilizar cstdlib.h ou ctime.h)

Hum... Não existem estes headers em C ou C++.

Existem, por um lado, stdlib.h e time.h, e por outro lado existem
cstdlib e ctime.

Talvez essa confusão responsa em parte a sua pergunta.

--
P.

[P.]

On 18 fev, 09:25, Felipe Magno de Almeida <felipe.m.alme...@gmail.com>
wrote:
> 2009/2/18 Erivaldo <desa...@gmail.com>:

> > Talvez as libs em C sejam significantemente mais rapidas. Quando eu
> > participei da maratona de programacao, eramos orientados a usar printf
> > em vez do tradicional "cout <<", pq mesmo sendo mais elegante e type
> > safe, era mais lento. Se eu estivesse no linux agora testaria isso =)
>
> Ainda é mais lento em todos os compiladores que eu já usei :P.
> Mas isso também é devido de a implementação do iostreams ser
> normalmente feita sobre snprintf.
> PS: Existem outros motivos também, como excesso de virtual calls.

Em chamadas de I/O o tempo de CPU é irrisório.
O tempo total é dominado pela cópia de dados.

--
P.

[Felipe Magno de Almeida]

2009/2/18 P. <pedro....@member.fsf.org>:

Hehehe, faça benchmarks de printf e iostream, você verá que
não é tao irrisório.

> --
> P.

[Guedes]

On Wed, 2009-02-18 at 12:17 -0300, Felipe Magno de Almeida wrote:
> Hehehe, faça benchmarks de printf e iostream, você verá que
> não é tao irrisório.

Na minha opinião, tudo é questão de foco, qual é o foco?
Rapidez na execução do sistema?
Maior controle e gerenciamento de padrão de projeto?
Internacionalização do sistema?
Formatação de string?

Solicitações diferentes requerem recursos diferentes.

Guedes.

[Felipe Ferreri Tonello]

O ideal é usar somente C++, mas nem sempre isso é possível, principalmente ao fato do uso de bibliotecas externas, feitas em C, à aplicação. Caso isso aconteça, tenha certeza que a biblioteca é portável para C++. Normalmente, o que pega mais é a conversão de dados(cast), pois C++ é bem estrito quanto a isso, e em C não.
Cast em C, quando possível, é recomendado não ser explícito, pois será feiro implicitamente pelo compilador em tempo de compilação. Já o compilador de C++ vai gerar um error, nem mesmo um warning.

Agora, caso você queira fazer uma biblioteca em C++ que poderá ser usada em C, utilize POD(Plain Old Data)[1] Types.

Por isso que C é a linguagem mais usada, ela é mais compátivel com outras.

[1] http://en.wikipedia.org/wiki/Plain_Old_Data_Structures

Felipe Ferreri Tonello
felipe....@gmail.com
http://felipetonello.com

[Erivaldo]

se eh pra usar C++ a partir de C, vc pode usar estruturas de dados de
C++ mesmo, e encapsular suas operacoes através de funções q recebam um
ponteiro para o objeto (void* ?) como parametro. E quando incluir o
header no arquivo de implementacao fazer algo como:

extern "C" {
#include "my_header.h"
}

Não sei se eh necessario colocar o extern "C" na definicao da funcao
tbm, acho que nao...

2009/2/18 Felipe Ferreri Tonello <felipe....@gmail.com>:

--
Desadoc (Poldí no-perfectus)

[Felipe Silveira]

olá,

2009/2/18 Erivaldo <des...@gmail.com>

Talvez as libs em C sejam significantemente mais rapidas. Quando eu
participei da maratona de programacao, eramos orientados a usar printf
em vez do tradicional "cout <<", pq mesmo sendo mais elegante e type
safe, era mais lento. Se eu estivesse no linux agora testaria isso =)

Sim, eu também participei da maratona de programação e, na época, fizemos um teste usando o gcc no linux, e realmente o tempo de execução do "cout <<" era quaseo dobro do tempo gasto para um printf.

Acredito que, por mais deselegante que seja, essa fusão de C/C++ em alguns momentos é necessária, como em sistemas embarcados, onde performance é um fator primordial. Além disso, temos em muitos sistemas esta fusão por causa da existência de codigo legado em C. Aí, geralmente nao tem jeito...

Abraços!

--
Felipe Silveira
Engenharia da Computação        
Universidade Federal de Itajubá  
http://www.felipesilveira.com.br            
MSN: felipe...@hotmail.com
Skype: fsunifei  
-------------------------------------------------
 

--
Felipe Silveira
Engenharia da Computação        
Universidade Federal de Itajubá  
http://www.felipesilveira.com.br            
MSN: felipe...@hotmail.com
Skype: fsunifei  
-------------------------------------------------

[Felipe Ferreri Tonello]

2009/2/18 Felipe Silveira <webf...@gmail.com>

olá,

2009/2/18 Erivaldo <des...@gmail.com>

Talvez as libs em C sejam significantemente mais rapidas. Quando eu
participei da maratona de programacao, eramos orientados a usar printf
em vez do tradicional "cout <<", pq mesmo sendo mais elegante e type
safe, era mais lento. Se eu estivesse no linux agora testaria isso =)

Sim, eu também participei da maratona de programação e, na época, fizemos um teste usando o gcc no linux, e realmente o tempo de execução do "cout <<" era quaseo dobro do tempo gasto para um printf.

Acredito que, por mais deselegante que seja, essa fusão de C/C++ em alguns momentos é necessária, como em sistemas embarcados, onde performance é um fator primordial. Além disso, temos em muitos sistemas esta fusão por causa da existência de codigo legado em C. Aí, geralmente nao tem jeito...

Acredito que isso não tenha muito haver. Pois num caso de maratona de programação, você tem que desenvolver um algoritmo que imprima muitas vezes tal saída, e essa performance (de output) talvez seja necessária.
Agora, na vida real, um algoritmo não vai imprimir na saída, mas sim gerar um output para um outro input. Em outras palavras, essa performance do menor do cout em relação ao printf não é tão importante em um aplicação.
O uso de C em sistemas embarcados feitos em C++, se dá mais ao uso de bíbliotecas externas escritas em C.

[Felipe Ferreri Tonello]

2009/2/18 Erivaldo <des...@gmail.com>

se eh pra usar C++ a partir de C, vc pode usar estruturas de dados de
C++ mesmo, e encapsular suas operacoes através de funções q recebam um
ponteiro para o objeto (void* ?) como parametro. E quando incluir o
header no arquivo de implementacao fazer algo como:

extern "C" {
#include "my_header.h"
}

O uso da keywork "extern" serve para indicar ao compilador que a linkagem de tal função ou objeto se dá à outro escopo ou, possivelmente, outro arquivo fonte.

Toda função, tipo de função e objeto tem uma linkagem de linguagem, por uma string. Por padrão, em C++, a definição é "C++". A outra, e única, linkagem de linguagem é "C". Outras linguagem e específicações são definidas por outras implementações, não a padrão.

Você pode fazer essa linkagem com uma única declaração, ou então usando as chaves({}) para definir uma série de linkagens. Exemplo:

extern "C" void cfunc(int);
extern "C++" {
  void cppfunc(int);
  void cppfunc(double);
}

Essa linkagem faz parte das function's type, então o typedef verifica a linkagem da linguagem. Exemplo:

extern "C" { void (*funcptr)(int); }
funcptr = cppfunc; // da erro
funcptr = cfunc // ok =D

Lembrando que C não da suporte a function overloading, então só pode ter uma função com linkada como extern "C" com o mesmo nome.

 

Não sei se eh necessario colocar o extern "C" na definicao da funcao
tbm, acho que nao...

Não é necessário, pois estará dentro do escopo linkado como "C".
 

[Yoshio]

Opa, calma pessoal, acho que estamos fugindo um pouco do assunto ou eu
não expliquei corretamente minha dúvida.

A questão não é se C funciona no C++ ou se é mais rápido. A questão é
se utilizar C dentro de C++ é aceitável. Por exemplo, se fosse
possível utilizar C++ dentro do Java você faria um projeto Java com
códigos/funções/libs de C++ misturado? Não seria estranho ou
conceitualmente errado?

Outra coisa sobre as libs cstdlib e ctime, elas são consideradas libs
do C++ ou são apenas "workaround" para funcionar códigos do C?

Espero ter deixado claro.

[Felipe Ferreri Tonello]

2009/2/18 Yoshio <geany...@gmail.com>

Opa, calma pessoal, acho que estamos fugindo um pouco do assunto ou eu
não expliquei corretamente minha dúvida.

A questão não é se C funciona no C++ ou se é mais rápido. A questão é
se utilizar C dentro de C++ é aceitável. Por exemplo, se fosse
possível utilizar C++ dentro do Java você faria um projeto Java com
códigos/funções/libs de C++ misturado? Não seria estranho ou
conceitualmente errado?

Outra coisa sobre as libs cstdlib e ctime, elas são consideradas libs
do C++ ou são apenas "workaround" para funcionar códigos do C?

As clibs em C++ é um suporte às bibliotecas padrões do C, só que são feitas em C++, usando templates em boa parte delas.
Com elas você pode usar funções equivalentes às em C. Só que preste atenção, os headers são cstlib e não cstdlib.h(isso é uma prática descontínua).

[Thiago Adams]

> Gostaria de saber se misturar códigos do C em C++ é errado? (Por
> exemplo, utilizar cstdlib.h ou ctime.h)

Não é errado, desde que você use corretamente.

O que poderia ser o uso incorreto?
É incorreto, por exemplo, você chamar uma função do C++ que lançe
exceções através de uma função do C. Mas não é o único exemplo, várias
coisas poderiam ser misturadas de forma errada. Mesmo que eu quisesse
tentar lembrar de todos os problemas ainda assim deixaria algo de
fora.

Mas, como disse antes, se usar corretamente é normal a integração.
Alguns headers do C, fazem parte do padrão do C++ também. Exemplo:
<cstring>, <ctime> etc...


Se é indicado o uso do C no C++?
A resposta é depende.
Claro, que se eu ver alguém usando malloc com char* para usar strings
no C++, certamente vou perguntar por que não foi usado uma classe. Não
que esteja certo ou errado, mas é preciso uma justificativa para
diminuir a abstração de um tipo como uma string. A mesma coisa seria
para deixar de usar um vector, set, map etc..

Uma coisa que acho que não é clara para muita gente, é imaginar o C
como uma linguagem procedural e o C++ como uma linguagem somente OOP
aonde a parte procedural seria por compatibilidade.
C++ é na verdade uma linguagem multiparadigma, e o seu melhor uso
inclui o paradigma procedural.

[Virgilio Fornazin]

Exato.

O que manda é o bom senso na hora de usar o que precisa.

2009/2/18 Thiago Adams <thiago...@gmail.com>

[P.]

On 18 fev, 12:17, Felipe Magno de Almeida <felipe.m.alme...@gmail.com>
wrote:

> > Em chamadas de I/O o tempo de CPU é irrisório.
> > O tempo total é dominado pela cópia de dados.
>
> Hehehe, faça benchmarks de printf e iostream, você verá que
> não é tao irrisório.

Observe.

[psilva@joana bench]$ uname -a
Linux joana 2.6.27.12-170.2.5.fc10.i686 #1 SMP Wed Jan 21 02:09:37 EST
2009 i686 i686 i386 GNU/Linux

[psilva@joana bench]$ rpm -q glibc
glibc-2.9-3.i686

[psilva@joana bench]$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/
bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --
enable-checking=release --with-system-zlib --enable-__cxa_atexit --
disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c+
+,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-
plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --
enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/
usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-
cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)

[psilva@joana bench]$ cat loop2.c
#include <stdio.h>

static const char* latim = "Refrescat cus patus lacunae est.\n";

int
main (int argc, char* argv[]) {
for (int i = 0; i < 1000000; ++i) {
printf("%d: %s", i, latim);
}
return 0;
}

[psilva@joana bench]$ cat loop2.cpp
#include <iostream>

static const char* latim = "Refrescat cus patus lacunae est.\n";

int
main (int argc, char* argv[]) {
for (int i = 0; i < 1000000; ++i) {
std::cout << i << ": " << latim;
}
return 0;
}

[psilva@joana bench]$ gcc --std=c99 -Os loop2.c -o loop2c

[psilva@joana bench]$ g++ -Os loop2.cpp -o loop2cpp

[psilva@joana bench]$ time ./loop2c

<SNIP>

real 1m57.534s
user 0m0.431s
sys 0m1.847s

[psilva@joana bench]$ time ./loop2cpp

<SNIP>

real 1m46.419s
user 0m0.571s
sys 0m1.581s

[psilva@joana bench]$ time ./loop2c > /dev/null

real 0m0.266s
user 0m0.257s
sys 0m0.007s

[psilva@joana bench]$ time ./loop2cpp > /dev/null

real 0m0.372s
user 0m0.366s
sys 0m0.007s

O tempo de ambos os programas é dominado pelo acesso ao dispositivo de
saída.
O tempo de CPU propriamente dito é irrisório.

Nada na <iostream> implica que seja mais lenta ou mais rápida que a
<stdio.h>.
Esta é uma questão de qualidade da implementação.

Eu, por exemplo, escolhi malandramente otimizar os dois programas com -
Os ao invés de -O2.
Esta escolha deve favorecer o tamanho do programa, o que pode por
conseqüência garantir que ambos os programas caibam na cache.

Mesmo assim, observe que se nenhuma das chamadas neste programa foi
inlined, o programa C++ está penalizado com três chamadas de função em
comparação com uma chamada de função do programa C.
Porém, os números indicam que este fato não penaliza o tempo total em
absoluto.

É muito provável que não obstante essa diferença ambos os programas
façam um número mais ou menos igual de chamadas ao sistema operacional
devido ao bom uso de técnicas de buffering.

etc. etc.

--
P.

[Felipe Magno de Almeida]

2009/2/18 P. <pedro....@member.fsf.org>:

Você tentou jogar num arquivo? Ou enviar por rede
em uma rede gigabit...
Estes costumam ser I/Os mais comuns do que jogar
em uma tela em um programa real AFAIK.

[snip]

[P.]

On 18 fev, 16:48, Felipe Magno de Almeida <felipe.m.alme...@gmail.com>
wrote:

> Você tentou jogar num arquivo? Ou enviar por rede
> em uma rede gigabit...
> Estes costumam ser I/Os mais comuns do que jogar
> em uma tela em um programa real AFAIK.

Mas qual é a sua espectativa?
Ambos os programas, escrevendo em /dev/null, ocupam o mesmo tempo de
CPU.
Desse modo, os tempos de quaisquer variantes deverão ser dominados

pelo acesso ao dispositivo de saída.

Um teste para escrita em arquivo é mole, aplicando o mesmo truque de
pipe do sistema operacional.

[psilva@joana bench]$ time ./loopc > fooc

real 0m0.361s
user 0m0.141s
sys 0m0.106s
[psilva@joana bench]$ time ./loopcpp > foocpp

real 0m0.243s
user 0m0.122s
sys 0m0.099s

Se você estiver falando sobre modificar o programa, bem...
Não estaremos mais medindo printf e std::cout mas sim fprintf e
std::ofstream.
Os resultados devem ser os mesmos.

Jogar por uma rede gigabit não será mais um teste das funções
convencionais de formatação.
Nem a <stdio.h> nem a <iostream> possuem um formatador para canal de
rede.

Eu terei que programar meu próprio canal de rede e portanto nosso
benchmarking não será mais um benchmarking das bibliotecas de
formatação e sim um benchmarking no meu programa de rede.
Supondo que eu programe um canal de rede e compartilhe esse canal com
ambas as implementações o tempo deverá ser o mesmo.

Se alguém estiver se perguntando sobre "code bloat", eis.

[psilva@joana bench]$ ls -l loopc loopcpp
-rwxrwxr-x 1 psilva psilva 4942 Fev 18 16:08 loopc
-rwxrwxr-x 1 psilva psilva 6034 Fev 18 16:11 loopcpp


--
P.

[Rodrigo Kumpera]

A diferença de performance com iostream só é aparente com várias
threads, pois exige muito mais locking que costuma causar cache line bouncing.

Mas até aí, quem escreve no console com 20 threads? Eu consigo imaginar
várias aplicações fazendo isso, mas nenhuma iria usar buffered io da stdlib ou libc.

A única coisa que é realmente pior com iostreams é o bloat gerado em comparação
com printf. O binário final é maior e tem mais relocações. Porém, denovo, para quantos
isso realmente importa?

2009/2/18 P. <pedro....@member.fsf.org>

[Felipe Magno de Almeida]

2009/2/18 P. <pedro....@member.fsf.org>:

Eu estava falando de *printf e iostreams, nao std::cout e printf.
Você executou estes testes quantas vezes? Esse programa não mostra
um programa real, apenas um caso de brincadeira. Este por exemplo
não causa problemas de caching em virtual functions, não causa
problemas com o numero de chamadas a funções virtuais de streambuf
e assim vai.
Iostreams são sim mais lentos que printf e fazem diferença para muitas
aplicações que envolvem também I/Os.
Só que normalmente não pra quem quer imprimir log e número de linha :P.

> Jogar por uma rede gigabit não será mais um teste das funções
> convencionais de formatação.
> Nem a <stdio.h> nem a <iostream> possuem um formatador para canal de
> rede.

Estou falando de programas sendo utilizados normalmente por aí que
precisam de formatação, estes podem fazer através de printf e familia
ou por iostreams. Quem precisa de velocidade usa *printf, os que não
precisam (eu incluindo) usam iostreams e boost::lexical_cast.

> Eu terei que programar meu próprio canal de rede e portanto nosso
> benchmarking não será mais um benchmarking das bibliotecas de
> formatação e sim um benchmarking no meu programa de rede.
> Supondo que eu programe um canal de rede e compartilhe esse canal com
> ambas as implementações o tempo deverá ser o mesmo.

Dei como exemplo de rede e arquivos pois os mesmos possuem throughput
muito maior que imprimir no console, que é completamente inútil pra
aplicações comuns, mesmo testes maratona não usam console pra verificação.

[Rodrigo Kumpera]

2009/2/18 Felipe Magno de Almeida <felipe.m...@gmail.com>

> Eu terei que programar meu próprio canal de rede e portanto nosso

> benchmarking não será mais um benchmarking das bibliotecas de
> formatação e sim um benchmarking no meu programa de rede.
> Supondo que eu programe um canal de rede e compartilhe esse canal com
> ambas as implementações o tempo deverá ser o mesmo.

Dei como exemplo de rede e arquivos pois os mesmos possuem throughput
muito maior que imprimir no console, que é completamente inútil pra
aplicações comuns, mesmo testes maratona não usam console pra verificação.

Nos exemplos do Pedro ele escreve no /dev/null, que é o dispositivo mais rápido disponível
em qualquer sistema unix.

[Marcelo Castellani]

/* Alberto Fabiano */ escreveu:

> Mas já vi esta combinção em vários grande projetos de embedded
> systems que utiliza C++. E ainda com pitadas de Assembly; que é inevitável!

Não tem como fugir. O que dá pra fazer é tentar separar a aplicação em
camadas, uma de baixo nível em C e assembly e uma de "alto nivel" em C++.

--

Marcelo Castellani
--------------------------------------------------------------------------
http://www.hypequino.com
--
"Seu trabalho vai preencher uma grande parte da sua vida, e a única
maneira de se sentir verdadeiramente satisfeito é fazendo o que
acredita ser um grande trabalho. E a única maneira de fazer um grande
trabalho é amando o que você faz". (Steve Jobs)
--------------------------------------------------------------------------

[Rodrigo Strauss]

Não, não é errado. Funciona perfeitamente. A runtime do C++ é
implementada usando a runtime do C.

Rodrigo Strauss
http://www.1bit.com.br

2009/2/18 Yoshio <geany...@gmail.com>:
>
> Olá pessoal.

> Gostaria de saber se misturar códigos do C em C++ é errado? (Por
> exemplo, utilizar cstdlib.h ou ctime.h)

[Felipe Magno de Almeida]

2009/2/18 Rodrigo Kumpera <kum...@gmail.com>:

E nesse tem uma diferença razoavel de tempo entre os dois.

[P.]

On 19 fev, 09:05, Felipe Magno de Almeida <felipe.m.alme...@gmail.com>
wrote:
> 2009/2/18 Rodrigo Kumpera <kump...@gmail.com>:

>
> > Nos exemplos do Pedro ele escreve no /dev/null, que é o dispositivo mais
> > rápido disponível
> > em qualquer sistema unix.
>
> E nesse tem uma diferença razoavel de tempo entre os dois.

100 nanosegundos é uma diferença importante para que tipo de
programas?
Que tipo de programas usam formatação de strings em loops CPU bound?

--
P.

[Felipe Magno de Almeida]

2009/2/19 P. <pedro....@member.fsf.org>:

>
> On 19 fev, 09:05, Felipe Magno de Almeida <felipe.m.alme...@gmail.com>
> wrote:
>> 2009/2/18 Rodrigo Kumpera <kump...@gmail.com>:
>>
>> > Nos exemplos do Pedro ele escreve no /dev/null, que é o dispositivo mais
>> > rápido disponível
>> > em qualquer sistema unix.
>>
>> E nesse tem uma diferença razoavel de tempo entre os dois.
>
> 100 nanosegundos é uma diferença importante para que tipo de
> programas?

Considero 39,84% a mais uma diferença consideravel.

> Que tipo de programas usam formatação de strings em loops CPU bound?

Parsing é um exemplo bem óbvio.

> --
> P.

[Felipe Magno de Almeida]

2009/2/19 Felipe Magno de Almeida <felipe.m...@gmail.com>:

Digo, geração de texto pra parsing.

Pedro,

Se suas aplicações não fazem uso disso, sorte sua.
Mas o IOStreams é mais lento que printf (e consideravelmente)
em todas as implementações até hoje!
E onde isso é importante, o printf e familia devem ser utilizados.
Você pode discutir quanto quiser, enquanto IOStreams forem lento
isso não vai mudar.

[Felipe Magno de Almeida]

Eu mesmo já vi gente ter programa "tipo-maratona" ser recusado (ACM se não
me engano) por causa da iostreams. Limite de tempo.

[Rodrigo (skhaz)]

Segundo esse http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Streams
(e postado aqui, já não me lembro por quem) recomenda se usar printf,
mais não por performance e sim por formatação e melhor
compatibilidade com 64bits

--
http://www.skhaz.com/