Ви написали код. Він працює. Але тепер ви хочете використовувати генератор rand() або процедуру bubble_sort у зовсім іншому проекті. Копіювання та вставка – це лінь. Це також крихкий підхід. Коли ви оновлюєте одну версію, вам потрібно шукати кожну копію коду.
Професійне рішення? Створіть бібліотеку.
В екосистемі C бібліотека – це не магічна чорна скринька. Це лише два файли, що виконують різні ролі. Вам потрібен заголовний файл (.h ) та вихідний файл (.c ). Файл заголовку повідомляє іншому світу, які функції існують. Початковий файл виконує реальну роботу.
Створення інтерфейсу: util.h
Заголовний файл діє як договір. Він не містить логіки. Він містить обіцянки. Константи, типи та прототипи функцій.
Створіть файл із ім’ям util.h.
`
Ключові слова extern виконують тяжку роботу. Вони кажуть компілятору: «Не шукай тут реалізацію. Я знайду її пізніше під час лінківки». Якщо ви застрягли на застарілому компіляторі, що передує сучасним стандартам C, видаліть параметри bubble_sort. Старі компілятори такі прискіпливі.
Приховування механізмів: util.c
Тепер сам код. Збережіть це як util.c.
`
Зверніть увагу на директиву include. Ми використовуємо лапки (`util.h' ), а не кутові дужки (
Ось тонкий момент: rand_seed. Він знаходиться в util.c. Його немає в util.h. Це приховування інформації у дії. Код, який використовує цю бібліотеку, може викликати rand(), але не може звертатися безпосередньо до seed (зерна). Стан інкапсульовано. Для суворого контролю ви можете додати ключове слово static перед визначенням змінної. Це надійно блокує доступ. Жодного зовнішнього доступу. Крапка.
Використання бібліотеки: main.c
Тепер напишіть програму, яка її використовує. Збережіть це як main.c.
`
Коротше? Так. Чистіший? Безперечно. Основна програма не дбає про те, як rand() генерує числа. Вона просто вимагає число. Це розподіл і є вся суть.
Компіляція та лінківка
Як перетворити ці окремі файли на працюючий виконуваний файл? Ви слідуєте трикроковому танцю.
Спочатку скомпілюйте вихідний код бібліотеки в об’єктний файл. Припускаючи, що ви використовуєте UNIX-подібну систему з GCC:
`
Прапор -c тут є обов’язковим. Він каже компілятор зупинитися після створення об’єктного файлу. Він створює util.o. Цей файл містить машинний код, але неповний. У ньому немає функції main. Він може працювати самостійно. Це компонент, а чи не продукт.
Далі скомпілюйте вашу основну програму:
`
Це генерує main.o. Знову ж таки, просто машинний код. Досі без логіки бібліотеки.
Зрештою, зв’яжіть їх разом.
`
Ця команда бере обидва об’єктні файли і зшиває їх в один виконуваний файл з ім’ям main. Тепер у вас є повна програма. Запустіть її за допомогою ./main (або просто main, якщо ви використовуєте Windows або вона додана до вашого PATH).
Це багато кроків для двох функцій. Але уявіть, якби ви робили це для проекту із п’ятдесятьма файлами. Ви компілюєте кожен файл .c один раз. Ви пов’язуєте їх разом. Змінили функцію у бібліотеці? Перекомпілюйте лише цей файл. Перев’яжіть. Решта залишається недоторканою.
Makefiles автоматизують цей
