Pergunta
Ao incluir um arquivo de cabeçalho em C ++, que é a diferença entre ...
1), incluindo o .h contra não incluindo o .h quando envolvê-lo em <> sinais?
#include <iostream> vs. #include <iostream.h>
2) envolvendo o nome do cabeçalho entre aspas duplas contra envolvê-lo em <> sinais?
#include <iostream.h> vs. #include "iostream.h"
Agradecemos antecipadamente!
Solução
Em resumo:
iostream.h está obsoleto - é a versão original Stroustrup, e iostream é a versão do comitê de padrões. Geralmente compiladores apontam ambos para a mesma coisa, mas alguns compiladores mais antigos não terão o mais velho. Em alguns casos estranhos ambos irão existir e ser diferente (para código de suporte legado) e, em seguida, deve ser específica.
"" versus <> significa simplesmente verificar os diretórios locais para o cabeçalho antes de ir para a biblioteca (na maioria dos compiladores).
-Adam
Outras dicas
Aqui está um link decente artigo.
Para resumir, a razão dada:
A versão da biblioteca iostream que o Comitê de Padrões produzido foi um pouco diferente da implementação Cfront. {Snip}
Para facilitar a transição, Comitê de Padrões C ++ declarou que o código incluindo o padrão C ++ cabeçalhos utilização iria incluir directivas carecem de uma extensão. Este compilador permitido fornecedores para enviar o velho estilo cabeçalhos biblioteca C ++ com a extensão .h e os novos cabeçalhos de estilo sem.
Uma vantagem de não usar a versão .h:
Existem várias razões pelas quais o novo código deve ser escrito usando o versão sem extensão do cabeçalho arquivos em vez das formas .h. o primeiro é a imprevisibilidade de tal código quando compilado em moderno compiladores. Como mencionado anteriormente, o resultado da utilização dos cabeçalhos .h é a aplicação específica. E como o tempo passa, a chance de que um dada compilador irá ter a biblioteca velho estilo disponíveis diminui.
Como a pessoa do comitê de padrões (X3J16) que propôs deixando de fora o .h, minha intenção original era resolver o debate sobre .h, .H, .hpp, extensões .hxx, arquivo ou .h ++; ou um desejo por algum que haja nenhuma implicação no padrão que este era o nome de um arquivo no disco, a fim de permitir que um IDE para puxar informações de cabeçalho pré-compilados fora do em algum lugar interna como um arquivo de recurso ou mesmo as entranhas do compilador.
Enquanto Unix considerado o nome do arquivo a ser uma única seqüência e não chegou a reconhecer o conceito de uma extensão, sistemas operacionais DEC tinha uma tradição de separar o nome da extensão, e fornecendo a "extensão default" se ele foi omitido no contextos particulares. É aí que eu tive a idéia de de deixá-lo até a implementação para usar qualquer extensão a implementação queria usar, e isso permitiu a implementação de nem mesmo ter este um arquivo no disco. (Eu era o representante de dezembro na comissão na época.)
A diferenciação entre o padrão e os cabeçalhos de pré-padrão foi um benefício adicional.
A forma padrão (e o único garantido para o trabalho) é "iostream.h" iria tentar primeiro a partir do diretório com o seu código-fonte, uma vez que "" é destinado a cabeçalhos de seu projeto. <> Deve ser sempre usado para cabeçalhos do sistema, e "" para os seus próprios cabeçalhos. Normalmente <> é usado para arquivos de biblioteca padrão, enquanto "sistema ou" é usado para arquivos de projeto. Eu não ficaria surpreso se o seu compilador procura localmente e quando não pode encontrá-lo o padrão é a versão da biblioteca padrão. Quanto ao .h, eu não acho que realmente importa se você usar C.
Em C ++, eu me lembro vagamente que havia uma versão mais recente e uma versão mais antiga e que, sem o h que era suposto ser a nova versão, mas eu nem tenho certeza a versão antiga ainda existe. Estes são realmente duas questões diferentes. A diferença entre o .he
cabeçalhos extensionless com a mesma
nome é histórico. Aqueles com
a extensão .h são da
Original C ++ padrão que não fez
tem algumas características modernas, tais como
namespaces e modelos. isso foi
mais simples para o novo padrão para colocar
essa mesma funcionalidade no novo
arquivos de cabeçalho para ser capaz de usá-los
novos recursos e manter o antigo (.h)
arquivos para compatibilidade com versões anteriores de
legado código. A diferença entre o #include
<...> e #include "..." formato é
a ordem em que o compilador
procura por arquivos. Este é geralmente
implementação dependente, mas o
idéia é que os <> Looks formato em
sistema de incluir diretórios em primeiro lugar,
enquanto "" Looks no mesmo diretório
como o arquivo de origem que #included-lo
em primeiro lugar. A resposta simples para a primeira resposta é que iostream.h não existe, pelo menos na implementação GCC. Se você estiver em * nix, digite % localizar iostream.h
Twitter / usr / include / c ++ / 3.4.3 / trás / iostream.h e % localizar iostream
O artigo de Como Zee diz, iostream.h é para compatibilidade com versões anteriores. Em relação aos nomes dos arquivos de cabeçalho C ++ padrão, nos primeiros dias (primeiros 2 anos) de X3J16, nos deparamos com uma discussão sobre o que a extensão deve estar nos arquivos de cabeçalho C ++ padrão. Em uso no momento por vários fornecedores (e influenciado por restrições que alguns sistemas operacionais colocados em nomes de arquivos) creio que foram .h, .H, .h ++, .hpp, .HXX, e possivelmente outros. Em uma reunião do grupo biblioteca sugeri que deixar a extensão off, e deixá-la até a implementação para fornecer uma extensão da sua escolha de arquivo padrão se havia nenhum no inclui a linha, ou usar o nome como uma chave em um banco de dados de arquivos de cabeçalho pré-compilados, se desejar. [Enquanto Unix-like sistemas tratam o nome do arquivo e 'extensão' como uma única seqüência, eu estava representando dezembro na comissão, e muitos sistemas operacionais DEC armazenada a extensão no diretório como um campo separado do nome. Então dezembro sistemas operacionais tiveram uma forte tradição de aplicar uma extensão padrão com base no qual o programa estava acessando o arquivo para que finalidade. Dizendo um montador 'X, Y = Z' pode resultar em leitura de arquivo de entrada Z.MAC (macro) e escrever a saída arquivos X.OBJ e Y.LST.] De qualquer forma, é evitado um longo, sem ganhar debate, para que o grupo foi junto com ele, e Andy Koenig apresentou as conclusões do grupo sobre este (entre outros) a toda a comissão, que aceitou. Acho que é um pouco divertido que implementações perdeu o ponto que eles poderiam aplicar uma extensão padrão de sua escolha (que eu acho que seria útil para editores e outras ferramentas) e só deixou a extensão fora do nome do arquivo. ) puxa as declarações relevantes para o espaço global (assim você não precisa do std :: namespace prefix).
/usr/include/c++/3.4.3/iostream
Twitter / usr / include / c ++ / 3.4.3 / trás / iostream.h