ZHN:
Gente, o que há de tão especial com streams? stdio é tão fácil de se usar e funciona
bem em C++, pelo menos aparentemente.
KUEHL: Dietmar Kuehl <kuehl@horn.informatik.uni-konstanz.de>
Há alguns prós e contras no uso de iostreams. De qualquer forma, considero que o uso de
iostreams é a melhor escolha na maioria, se não em todos os casos. Aqui estão os prós
e os contras:
Você pode integrar operações de I/O para os seus próprios tipos de dados
quando usa iostreams. Isso é impossível com stdio. A possibilidade de usar a
mesma sintaxe tanto para user defined types quanto para standard types é uma aplicação importante da facilidade de
sobrecarga, e torna o programa muito mais inteligível e de mais fácil manutenção.
Você pode integrar novas representações externas ao iostreams. Para
stdio, tal como definido em C90 (ISSO 9899), isso não é realmente possível. Você pode
resolver uma parte do problema usando vsprintf() e vsscanf(),
mas normalmente o código C é escrito para passar ao largo de FILE* e
você não pode definir uma nova representação externa acessada via um FILE*. Em
C++, os streams nos quais se quer escrever são identificados usando-se istream& e ostream& e os streams correspondentes podem ser facilmente extendidos
definindo-se sub-classes de
streambuf.
Verificação de tipos pode ser implementada tanto em stdio quanto em iostreams, e são
equivalentes, pelo menos para os tipos de dados standard. Eg. gcc
verifica se o string de formatação é compatível com o argumento, exceto quanto o string de formatação não é fornecido como uma literal.
Contudo, parece que esse recurso de verificação de tipos não é muito usado: eu ainda
estou para ver um uso não-trivial de stdio em um programa real em que não haja pelo
menos um erro de formatação de strings. De modo especial,
normalmente se erra na formatação de ponto flutuante, principalmente porque há
diferentes especificadores de formatação para ponto flutuante duplo: "%lf" e
"%f", respectivamente. Portanto, embora sejam conceitualmente equivalentes,
nesse aspecto em particular, iostreams é melhor.
O suporte para internacionalização em ambos é basicamente idêntico.
As dificuldades de se aprender stdio e iostreams são equivalentes.
stddio é definitivamente mais difícil - não raro, até mesmo experts cometem erros
sutís - mas tem uma grande quantidade de documentação. Por outro lado, iostream é mais
fácil de se aprender e seu uso é menos sujeito a erros - exceto quando se tenta
implementar classes derivadas de
istream e/ou ostream - mas está coberto por pouca
documentação. Todas as implementações atuais de iostreams são menos
eficientes que as implementações de stdio, seja em termos de tempo de
execução, tamanho do código, tempo de compilação e tamanho do objeto.
Há alguns recursos de iostream que não tem um equivalente em stdio.
(Eg, a possibilidade de alterar o modo como os tipos standard
são processados usando-se implementação do usuário em locale
objects), mas há, em contrapartida, algumas coisas que você não pode fazer com
iostream
(Eg, escrever apenas uma parte do string quando passa o
string como um char const).
Penso que cobri a diferenças mais importantes entre stdio e iostreams. Se houver outras,
sinta-se à vontade para me corrigir.
Eu considero que os prós de iostream são muito mais relevantes que os seus contras,
especialmente porque as operações de I/O com stdio ou iostream não são, normalmente,
operações pesadas e nem tem uma exigência de eficiência crítica. Quando assim for, é
fácil substituir o uso de iostream por stdio.
É claro que a avaliação de prós e contras não é rigososamente objetiva. É, antes,
um ponto de vista pessoal. Para a sua própria aplicação, você deve fazer o seu
próprio julgamento.
ZHN:
As poucas questões que ficaram por responder dizem respeito a história de stdio e de
iostream
KUEHL:
Bem, stdio foi apresentada por Kernighan e Richie com a versão original do C e permanece
sem nenhuma alteração importante desde então.
iostream passou por duas grandes implementações, onde a segunda representou uma grande
alteração técnica mas não alterou os conceitos básicos. Não posso dizer que
originalmente projetou ou implementou iostream, mas foi Jerry Schwartz quem apresentou a
separação de stream buffers relativamente cedo na história
do C++, mas após o release original de Stroustrup. Durante a padronização, algumas
funções foram renomeadas mas a grande alteração foi a introdução de templates para
suportar diferentes tipos de dados. Isso requereu a introdução de regionalização para
fazer frente a certos aspectos difíceis de se codificar em iostream mas que agora são
indispensáveis (Eg, formatação numérica)
ZHN:
É ou não é seguro usar ambos no mesmo programa?
KUEHL:
É absolutamente seguro usar stdio e iostream no mesmo programa. De fato, stdio e iostreams
interferem apenas nos standard streams (stdin, stdout, e stderr
vs. cin, cout, cerr, clog, wcin, wcout, wcerr,
e wclolg; todos são namespace std, é claro).
Se você escrever alternadamente a partir de stdio e a partir de iostream para esses
streams, pode ocorrer um problema. No entanto, por default - ou seja, a menos que você
invoque std::ios_base::sync_with_stdio(false)
os streams stdio são sincronizados com os correspondentes iostreams, o que
significa que esses iostreams não são buferizados (Isso não é totalmente verdadeiro,
mas está muito próximo da verdade).
Não há um modo padronizado de se usar qualquer outro stream a partir de stdio e de
iostream simultaneamente e assim não há que temer outros conflitos. No entanto, é
plenamente possível criar-se classes iostream para cooperar com FILE*.
ZHN:
E como stdio e iostream se relacionam, se é que se relecionam.
KUEHL:
A única relação entre stdio e iostream determinada pela
padronização é que:
- stdin e cin/wcin lem da mesma origem
- stdout e cout/wcin,
- stderr e cerr/wcerr,
- stderr e clog/wclog escrevem para o mesmo destino
Potencialmente, os streams correspondentes são, de certa forma, sincronizados.
ZHN:
Outra grande ajuda para muitos de nós, não treinados em C++, é: onde podemos encontrar
boas referências a respeito de streams.
KUEHL:
Pode-se encontrar alguma informação disponível na Web. Veja <http://www.dinkumware.com/>. |
