Arquivos #include .c ou .h ?

[alessandro]

Há coisas que deixamos passar por despercebidas e depois de algum tempo ficam martelando na nossa cabeça...

Qual a diferença entre salvar configurações, definições em um arquivo .c ou .h? Há alguma diferença na complição final manter dos dados em uma dessas extenções? Sempre usei .c, mas vejo que boa parte das pessoas usam .h ou mesclam essas opções.



Alessandro

[andre_luis]

Voce levantou uma questão interessante. Realmente, nao parece haver um consenso ou padronizacao a respeito disso.

Eu, particularmente, coloco definicoes no .h e funcoes no .c
Mas, e as macros ? Eu coloco no .h pois para mim sao definicoes.

+++

[alessandro]

Realmente não sei se a separação de usar um ou outro é vantagem em alguma coisa ou padronização entre funções e definiçoes.

Talvez cada pessoa tenha alguma opinião ou use de forma diferente já que possívelmente em relação a compilação e resultado final sejam parecidos.



Alessandro

[chipselect]

#include "arquivo.c"

Eu acho que fica um pouco estranho. Não sei como é o padrão em compiladores pra microcontroladores, mas para PC, esse tipo de coisa quase não se vê em programas profissionais.

Quando preciso incluir funções que vão em um arquivo .c, geralmente incluo o .h dele e o .c é compilado e linkado automaticamente, utilizando a ferramenta MAKE ou qualquer coisa do tipo.

Talvez para microcontroladores, isso não importa muito porque os programas são bem pequenos e talvez os compiladores nem possuem um utilitário tipo o MAKE, pois a necessidade de gerência de projeto seja muito pequena, quase zero.

No caso de microcontrolador, geramente eu crio uma lib pra não incluir um .c, incluir só o .h é apenas um padrão de trabalho.

[andre_luis]

Acho que a prática de se realizar 'include' em arquivos .c se deve mais à uma questão organizacional, como o caso que voce citou das bibiotecas, pois fica muito mais inteligivel e portável um programa que trabalhe com driver's de acesso a dispositivos de hardware - por exemplo - encapsulados num único arquivo.

#include "arquivo.c"
Eu acho que fica um pouco estranho...

No caso, pro compilador, isso funciona como se voce estivesse meramente substituindo todo o conteudo do arquivo pela diretiva, agindo como um 'carimbo'; o que significa que isso só vai funcionar se o conteúdo do arquivo incluido estiver de acordo com a área onde o arquivo for incluída ( protótipo, declaração, execução )

+++

[__JEREK__]

eu particularmente faço o programa principal em .C e o resto todo em .h

as vezes quando vc baixa um exemplo da net, onde são usados arquivos .C como biblioteca você tem que ficar procurando qual é o arquivo .C principal para compilar, que geralmente o programador não deixa muito claro quem é o principal.

programa principal em .C (um arquivo C por projeto apenas)

o resto (biblioteca, definições, etc) em .h

[Nakai]

Eu uso o PICC da Hi-Tech e não uso #include "arquvo.c" eu só uso #include"arquvo.h". O arquivo.h contem protótipos e definições. Na hora da compilação são compilados todos os arquivos e são gerados os .obj depois o linker junta todos estes .obj e .lib pra fazer o .hex. O hitech dá pra gerar os .lib mas ainda não testei, dizem que o código fica menor pois a função só será incluída se ela for usada.

[chipselect]

Jerek

isso aí é tarefa do make

[__JEREK__]

Jerek

isso aí é tarefa do make

olá chipselect, tudo blz??

desculpe, eu não entendi, o que é make??

[Red Neck Guy]

Os arquivos *.h são Headers, que na verdade seriam a principio para conter informações referentes ao *.C a que se referem...
Uma biblioteca bem escrita, por exemplo, teria dois arquivos. Um C com o código das funções, variaveis globais e tal. E outro arquivo H com os protótipos de função, definições de tipo, identificadores utilizados no escopo e assim por diante.
Nos bons livros de C, tipo o C completo e total do Herbert Schild, isso é comentado.
Esse blá-blá-blá todo parece bobagem, mas pense quando se trabalha em equipes, não tem como usar esses códigos sem padronização nenhuma...

[chipselect]

boa tarde Jerek

O Make é muito comum em Unix, é uma ferramenta para ajudar na compilação, ele roda baseado em um script próprio, localiza os arquivos relevantes, compila e efetua o link.

Quando a gente compila o kernel do Linux, rodamos o make... ele faz tudo que precisa pra compilar. Geralmente indicamos o "arquivo de script", como por exemplo, os comandos:
$make config
$make clean

Quando um código fonte tem vários arquivos, geralmente ele vem com um arquivo script do make junto, para facilitar as coisas. Infelizmente GCC, Visual Studio e Borland CBuilder utilizam "make" diferentes.

Quando utilizamos muito os ambientes integrados de desenvolvimentos, ficamos "isolados" desses detalhes de programação, mas esses ambientes muito provavelmente utilizam alguma forma de "make".

[andre_luis]

...arquivo H com os protótipos de função, definições de tipo, identificadores utilizados no escopo e assim por diante...

A inclusão também do protótipo no .H é coerente quando se coloca os includes no início do arquivo. Acredito que isso ( includes apenas no início ) deveria ser também uma regra. Já vi programa com um #include no meio do arquivo.

+++

[chipselect]

#include no meio do arquivo?

afff, nem quero saber do resto do código...