Незвичне використання файлу .h у C

Під час читання статті про фільтрацію я виявив дивне використання .hфайлу - використовуйте його для заповнення масиву коефіцієнтів:

#define N 100 // filter order
float h[N] = { #include "f1.h" }; //insert coefficients of filter
float x[N];
float y[N];

short my_FIR(short sample_data)
{
  float result = 0;

  for ( int i = N - 2 ; i >= 0 ; i-- )
  {
    x[i + 1] = x[i];
    y[i + 1] = y[i];
  }

  x[0] = (float)sample_data;

  for (int k = 0; k < N; k++)
  {
    result = result + x[k]*h[k];
  }
  y[0] = result;

  return ((short)result);
}

Отже, чи нормально застосовувати float h[N] = { #include "f1.h" };цей спосіб?

Препроцесорні директиви, як-от #include, просто виконують заміну тексту (див. Документацію GNU cpp всередині GCC ). Це може статися в будь-якому місці (поза коментарями та рядковими літералами).

Однак a #includeповинен мати його #як перший непустий символ свого рядка. Отже, ви будете кодувати

float h[N] = {
  #include "f1.h"
};

^{Початкове запитання не було #includeу власному рядку, тому був неправильний код.}

Це не є звичайною практикою, але це дозволена практика. У такому випадку я б запропонував використовувати інше розширення, крім, .hнаприклад, використання #include "f1.def"або #include "f1.data"...

Попросіть свого компілятора показати вам попередньо оброблену форму. За допомогою GCC скомпілюйте gcc -C -E -Wall yoursource.c > yoursource.iта перегляньте створений редактор або пейджерyoursource.i

Я насправді вважаю за краще мати такі дані у власному вихідному файлі. Тому я б замість цього запропонував згенерувати автономний h-data.cфайл, використовуючи, наприклад, якийсь інструмент, такий як GNU awk (тому файл h-data.cпочинався б const float h[345] = {і закінчувався };...) А якщо це постійні дані, краще оголосіть їх const float h[](щоб він міг читати -тільки сегмент, як .rodataна Linux). Крім того, якщо вбудовані дані великі, компілятору може знадобитися час, щоб (марно) оптимізувати їх (тоді ви зможете h-data.cшвидко скомпілювати без оптимізації).

Отже, чи є звичайною практика використовувати float h [N] = {#include “f1.h”}; сюди?

Це не є нормальним, але є дійсним (буде прийнято компілятором).

Переваги використання цього: це позбавляє вас невеликої кількості зусиль, необхідних для кращого рішення.

Недоліки:

• це збільшує співвідношення WTF / SLOC вашого коду.
• він вводить незвичний синтаксис як у клієнтському коді, так і у включеному коді.
• щоб зрозуміти, що робить f1.h, вам доведеться подивитися, як він використовується (це означає, що вам потрібно додати додаткові документи до свого проекту, щоб пояснити цього звіра, або людям доведеться прочитати код, щоб побачити, що він робить означає - жодне рішення не є прийнятним)

Це один із тих випадків, коли додаткові 20 хвилин, витрачені на роздуми перед написанням коду, можуть позбавити вас декількох десятків годин прокльону коду та розробників протягом життя проекту.

Як вже пояснювалось у попередніх відповідях, це не є звичайною практикою, але є дійсною.

Ось альтернативне рішення:

Файл f1.h:

#ifndef F1_H
#define F1_H

#define F1_ARRAY                   \
{                                  \
     0, 1, 2, 3, 4, 5, 6, 7, 8, 9, \
    10,11,12,13,14,15,16,17,18,19, \
    20,21,22,23,24,25,26,27,28,29, \
    30,31,32,33,34,35,36,37,38,39, \
    40,41,42,43,44,45,46,47,48,49, \
    50,51,52,53,54,55,56,57,58,59, \
    60,61,62,63,64,65,66,67,68,69, \
    70,71,72,73,74,75,76,77,78,79, \
    80,81,82,83,84,85,86,87,88,89, \
    90,91,92,93,94,95,96,97,98,99  \
}

// Values above used as an example

#endif

Файл f1.c:

#include "f1.h"

float h[] = F1_ARRAY;

#define N (sizeof(h)/sizeof(*h))

...

Ні, це не нормальна практика.

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

Існує, однак, «шаблон» , який включає в себе в тому числі файлу в таких випадкових місцях: X-макроси , такі як ті .

Використання X-макросу полягає в тому, щоб визначити колекцію один раз і використовувати її в різних місцях. Єдине визначення, що забезпечує узгодженість цілого. Як тривіальний приклад розглянемо:

// def.inc
MYPROJECT_DEF_MACRO(Error,   Red,    0xff0000)
MYPROJECT_DEF_MACRO(Warning, Orange, 0xffa500)
MYPROJECT_DEF_MACRO(Correct, Green,  0x7fff00)

які тепер можна використовувати різними способами:

// MessageCategory.hpp
#ifndef MYPROJECT_MESSAGE_CATEGORY_HPP_INCLUDED
#define MYPROJECT_MESSAGE_CATEGORY_HPP_INCLUDED

namespace myproject {

    enum class MessageCategory {
#   define MYPROJECT_DEF_MACRO(Name_, dummy0_, dummy1_) Name_,
#   include "def.inc"
#   undef MYPROJECT_DEF_MACRO
    NumberOfMessageCategories
    }; // enum class MessageCategory

    enum class MessageColor {
#   define MYPROJECT_DEF_MACRO(dumm0_, Color_, dummy1_) Color_,
#   include "def.inc"
#   undef MYPROJECT_DEF_MACRO
    NumberOfMessageColors
    }; // enum class MessageColor

    MessageColor getAssociatedColorName(MessageCategory category);

    RGBColor getAssociatedColorCode(MessageCategory category);

} // namespace myproject

#endif // MYPROJECT_MESSAGE_CATEGORY_HPP_INCLUDED

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

#include "myimage.xpm"

в їх коді C.

Це вже не вважається хорошим.

Код ОП виглядає Cтак, про що я поговорюC

Чому це зловживання препроцесором?

#includeДиректива препроцесора призначена для включення вихідного коду. У цьому випадку та у випадку з OP це не справжній вихідний код, а дані .

Чому це вважається поганим?

Бо це дуже негнучко . Ви не можете змінити зображення без перекомпіляції всієї програми. Ви навіть не можете включити два зображення з однаковою назвою, тому що це створить некомпілюючий код. У випадку з ОП він не може змінити дані без перекомпіляції програми.

Інша проблема полягає в тому, що це створює тісний зв'язок між даними та вихідним кодом , наприклад файл даних повинен містити принаймні кількість значень, визначених Nмакросом, визначеним у файлі вихідного коду.

Тісне зв’язування також накладає формат на ваші дані, наприклад, якщо ви хочете зберегти значення матриці 10x10, ви можете вибрати використовувати одновимірний масив або двовимірний масив у своєму вихідному коді. Перехід від одного формату до іншого призведе до змін у вашому файлі даних.

Ця проблема завантаження даних буде легко вирішена за допомогою стандартних функцій вводу / виводу. Якщо вам дійсно потрібно включити деякі зображення за замовчуванням, ви можете вказати шлях за замовчуванням до зображень у своєму вихідному коді. Це щонайменше дозволить користувачеві змінити це значення (за допомогою параметра #defineабо -Dпід час компіляції) або оновити файл зображення без необхідності перекомпілювати.

У випадку OP, його код буде більш багаторазовим, якщо коефіцієнти FIR та x, yвектори передаються як аргументи. Ви можете створити structдля зберігання разом ці значення. Код не був би неефективним, і він став би багаторазовим навіть з іншими коефіцієнтами. Коефіцієнти можна завантажувати під час запуску із файлу за замовчуванням, якщо користувач не передає параметр командного рядка, який замінює шлях до файлу. Це усуне потребу в будь-яких глобальних змінних і зробить наміри програміста явними. Ви навіть можете використовувати ту саму функцію FIR у двох потоках, за умови, що кожен потік має свою власну struct.

Коли це прийнятно?

Коли ви не можете зробити динамічне завантаження даних. У цьому випадку вам доведеться завантажувати свої дані статично і ви змушені використовувати такі методи.

Слід зазначити, що відсутність доступу до файлів означає, що ви програмуєте для дуже обмеженої платформи , і тому вам доведеться робити компроміси. Це буде так, якщо ваш код працює, наприклад, на мікроконтролері.

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

Наприклад, надання реальної Cфункції, що повертає коефіцієнти, а не наявність напівформатованого файлу даних. Потім цю Cфункцію можна було визначити у двох різних файлах, один з яких використовує введення-виведення для цілей розробки, а інший повертає статичні дані для побудови випуску. Ви скомпілюєте правильний вихідний файл умовно.

Бувають ситуації, коли потрібно або використовувати зовнішні інструменти для створення .C-файлів на основі інших файлів, що містять вихідний код, або, якщо зовнішні інструменти генерують C-файли з непомірно великою кількістю коду, підключеного до інструментів генерації, або використання коду #includeдирективи різними "незвичними" способами. З цих підходів я б припустив, що останній - хоч і хиткий - часто може бути найменшим злом.

Я пропоную уникати використання .hсуфікса для файлів, які не дотримуються звичайних конвенцій, пов'язаних з файлами заголовків (наприклад, шляхом включення визначень методів, виділення простору, що вимагає незвичного контексту включення (наприклад, в середині методу), що вимагає декількох включення з різними визначеними макросами тощо. Я також взагалі уникаю використання .cабо .cppдля файлів, які вбудовані в інші файли, за #includeвинятком випадків, коли ці файли використовуються в основному автономно [я можу в деяких випадках, наприклад, мати файл, fooDebug.cщо містить #define SPECIAL_FOO_DEBUG_VERSION[новий рядок] `#include" foo. c "` `якщо я хочу мати два об'єктні файли з різними іменами, сформовані з одного джерела, і один із них є" звичайною "версією.]

Моя звичайна практика полягає в тому, щоб використовувати .iяк суфікс або створені людиною, або створені машиною файли, які призначені для включення, але звичайними способами, з інших вихідних файлів C або C ++; якщо файли створюються машиною, я, як правило, інструмент генерації включатиме в перший рядок коментар, що ідентифікує інструмент, який використовується для його створення.

До речі, одним із прийомів, коли я це використав, було те, коли я хотів дозволити програму будувати, використовуючи лише командний файл, без сторонніх інструментів, але хотів порахувати, скільки разів вона була побудована. У своєму пакетному файлі я включив echo +1 >> vercount.i; то у файлі vercount.c, якщо я правильно згадую:

const int build_count = 0
#include "vercount.i"
;

Кінцевий ефект полягає в тому, що я отримую значення, яке збільшується при кожній збірці без необхідності покладатися на будь-які сторонні інструменти для її створення.

Коли препроцесор знаходить #includeдирективу, він просто відкриває вказаний файл і вставляє його вміст, ніби вміст файлу було б записано в місці розташування директиви.

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

Наприклад, це f1.hможе виглядати так

#ifndef _f1_h_
#define _f1_h_

#ifdef N
float h[N] = {
    // content ...
}

#endif // N

#endif // _f1_h_

І файл .c:

#define N 100 // filter order
#include “f1.h”

float x[N];
float y[N];
// ...

Мені це здається трохи більш нормальним - хоча наведений вище код можна ще вдосконалити (наприклад, усунувши глобалісти).

Додавання до того, що сказали всі інші, - зміст f1.h повинен бути таким:

20.0f, 40.2f,
100f, 12.40f
-122,
0

Тому що текст в f1.h буде ініціалізувати відповідний масив!

Так, він може містити коментарі, інші функції або використання макросів, вирази тощо.

Для мене це звичайна практика.

Препроцесор дозволяє розділити вихідний файл на скільки завгодно фрагментів, які збираються директивами #include.

Це має великий сенс, коли ви не хочете захаращувати код довгими / не для читання розділами, такими як ініціалізація даних. Як виявляється, мій файл "ініціалізація масиву" має довжину 11000 рядків.

Я також використовую їх, коли деякі частини коду автоматично генеруються якимись зовнішніми інструментами: дуже зручно, щоб інструмент просто генерував його шматки, і включав їх до решти коду, написаного від руки.

У мене є кілька таких включень для деяких функцій, які мають кілька альтернативних реалізацій, залежно від процесора, деякі з них використовують вбудовану збірку. Включення роблять код більш керованим.

За традицією директива #include використовувалась для включення файлів заголовків, тобто наборів оголошень, що виставляють API. Але ніщо цього не вимагає.

Я читав, що люди хочуть рефакторинг і кажуть, що це зло. І все-таки я використовував у деяких випадках. Як сказали деякі люди, це директива препроцесора, тому включає вміст файлу. Ось випадок, коли я використовував: побудову випадкових чисел. Я будую випадкові числа, і я не хочу робити це кожного разу, коли не компілюю жодного під час виконання. Отже, інша програма (зазвичай це скрипт) просто заповнює файл згенерованими номерами, які включені. Це дозволяє уникнути копіювання вручну, це дозволяє легко змінювати числа, алгоритм їх генерування та інші приємності. Ви не можете легко звинуватити практику, в такому випадку це просто правильний шлях.

Я використовував методику OP, щоб впродовж певного часу розміщувати файл include для частини ініціалізації даних декларації змінної. Так само, як і OP, включений файл був сформований.

Я виділив створені файли .h в окрему папку, щоб їх можна було легко ідентифікувати:

#include "gensrc/myfile.h"

Ця схема розпалася, коли я почав використовувати Eclipse. Перевірка синтаксису Eclipse була недостатньо складною, щоб впоратися з цим. Він реагував би повідомленням про синтаксичні помилки там, де їх не було.

Я повідомив зразки до списку розсилки Eclipse, але, схоже, не було великого інтересу до "виправлення" перевірки синтаксису.

Я змінив свій генератор коду, щоб взяти додаткові аргументи, щоб він міг генерувати всю декларацію змінної, а не лише дані. Тепер він генерує синтаксично правильні файли включення.

Навіть якщо я не використовував Eclipse, я вважаю, що це краще рішення.

У ядрі Linux я знайшов приклад, який є IMO, прекрасний. Якщо ви подивитесь на файл заголовка cgroup.h

http://lxr.free-electrons.com/source/include/linux/cgroup.h

Ви можете знайти директиву, що #include <linux/cgroup_subsys.h>використовується двічі, після різних визначень макросуSUBSYS(_x) ; цей макрос використовується всередині cgroup_subsys.h, щоб оголосити кілька імен Linux-груп (якщо ви не знайомі з cgroups, це зручний інтерфейс, який пропонує Linux, який потрібно ініціалізувати під час завантаження системи).

У фрагменті коду

#define SUBSYS(_x) _x ## _cgrp_id,
enum cgroup_subsys_id {
#include <linux/cgroup_subsys.h>
   CGROUP_SUBSYS_COUNT,
};
#undef SUBSYS

кожен SUBSYS(_x)оголошений в cgroup_subsys.h стає елементом типу enum cgroup_subsys_id, тоді як у фрагменті коду

#define SUBSYS(_x) extern struct cgroup_subsys _x ## _cgrp_subsys;
#include <linux/cgroup_subsys.h>
#undef SUBSYS

кожен SUBSYS(_x)стає оголошенням змінної типу struct cgroup_subsys.

Таким чином, програмісти ядра можуть додавати cgroups, модифікуючи лише cgroup_subsys.h, тоді як попередній процесор автоматично додаватиме відповідні значення перерахунку / декларації у файлах ініціалізації.