•  03-07-2019
  •  | 
  •  

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!

Foi útil?

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) é . No gcc, (que pode ter de ser incluído como ) puxa as declarações relevantes para o espaço global (assim você não precisa do std :: namespace prefix).

"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
/usr/include/c++/3.4.3/iostream Twitter / usr / include / c ++ / 3.4.3 / trás / iostream.h

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.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top