Когда не следует помещать прототипы функций C в заголовочные файлы - PullRequest
Новая
       32

Когда не следует помещать прототипы функций C в заголовочные файлы

0 голосов
/ 06 июня 2018

Есть ли причина, по которой не рекомендуется размещать прототипы функций C / C ++ в заголовочных файлах, а размещать их в верхней части основного файла .c / .cpp?

Например,Я мог бы написать файл dothis.c: 

#include "funcs.h"

int main(int argc, char ** argv) {
   // some code
   int result = doThis();
   // more code

   return 0;
}

int doThis(void) {
   // code and return value
}

И в моем файле funcs.h я бы написал: 

#ifndef FUNCS_H
#define FUNCS_H

int doThis(void);

// more function prototypes

#endif // FUNCS_H

Есть ли причина, по которой лучшеПоместите прототип (ы) (если их много) вместо файла .c / .cpp?Например: 

#include "funcs.h"

int doThis(void);

// more function prototypes

int main(int argc, char ** argv) {
   // some code
   int result = doThis();
   // more code

   return 0;
}

int doThis(void) {
   // code and return value
}

В первом случае, мне кажется, было бы полезно иметь много прототипов функций в отдельном заголовочном файле плюс документацию, чтобы логически отделить декларацию от реализации и чтобы было проще понять, чтоосновной файл делает.

1 Ответ

0 голосов
/ 06 июня 2018

Есть ли причина, по которой не рекомендуется размещать прототипы функций C / C ++ в заголовочных файлах, а размещать их в верхней части основного файла .c / .cpp?

Единственный момент, который имеет для меня смысл, - это когда функции являются деталями реализации других функций.Конечно, в этом случае я предпочитаю определять их в области видимости файла, используя функции с областью действия файла, используя квалификатор static или помещая их в пространство имен, специфичное для файла .cpp.

Для всех других функций ятрудно оправдать не помещение объявления в файл заголовка и #include использование файла заголовка в файлах, которые используют функции, и в файле, который определяет функции.

...