>Конечно, так. Статья, как раз, и нацелена показать, что сделать самодостаточными каждый заголовочный файл с учетом всех зависимостей — «нудная» задача и ее можно решить по-другому.
Буквально сегодня, разбирая старый проект, в котором используется метод «единого включения», наткнулся на вышеописанную мной проблему. В одном из заголовочных файлов нужна была банальщина, версия библиотеки. Чтобы не тянуть все-все хедеры кто-то когда-то сэкономил и включил только один файл с нужным функционалом. Всё работало до тех пор, когда этот файл собирался после другого, в котором «всё включено». Так вот, убирал я «мертвый» код из проекта, и получилось так, что этот «неправильно включенный» хедер начал собираться раньше.
Получается что? Изменился пользовательский код (который раньше работал корректно), а ошибку компилятор выдает во внутренних заголовочных файлах либы, которую никто и не трогал. Неаккуратненько и фрустрирует немного.
>А если теперь задаться вопросом: действительно ли, так необходимо реализовывать для пользователя библиотеки возможность подключения отдельных ее элементов?
Хорошо, когда SomeLib по объему не больше boost::shared_ptr. Тогда действительно, можно на вопрос ответить однозначно «нет»: написал один раз и забыл. Включай да пользуй.
Но в чем-то более крупном лучше я потрачу на 5 минут больше времени (на свежую голову), проверив все зависимости, чем буду через год голову ломать «почему меняя инклюды местами всё перестаёт собираться»
Как там писали? Чем позже найдена ошибка, тем дороже её устранение.
>Встречный вопрос, как Ваш подход применим при реализации библиотеки разработчиком (при поставке ее только в виде заголовочных файлов)?
На личном примере и советую, причем как со стороны разработчика библиотеки, так и со стороны её использования. И правило «напиши код так, чтобы неправильно использовать библиотеку было трудно» не раз себя хорошо зарекомендовал.
Да и вообще. Как-то простой совет с порядком инклюдов перерастает в сочинение «Один мой день», не нравится мне это.
А в чем проблема в публичный интерфейс включить нужные инклюды? Интерфейс на то и интерфейс, чтобы определять всё необходимое для работы.
Пример (хедергарды опущены): a.h: // интерфейс
#include // в интерфейсе будет вектор. Инклюдим.
class A
{
public:
virtual ~A(){};
virtual std::vector getVector() = 0;
}
class B : public A
{
public:
virtual ~B(){};
virtual std::vector getVector()
{
// реализация
return m_Data;
};
private:
std::vector m_Data;
}
c.h:
// нет инклюда вектора! Забыли включить, например. (1)
struct C
{
std::vector arr; // (2) см ниже.
}
use1.cpp: // Ваш вариант.
#include // СТЛ в начале
#include "c.h" // (2) не ругается
#include "a.h"
use2.cpp: // тут самое интересное
#include "c.h" // (3) ругается
#include "a.h"
#include // СТЛ в конце
use3.cpp
#include "a.h"
#include "c.h" // (4) не ругается ни в каком случае.
}
Может, я чего-то не понимаю в этой жизни, но при моем варианте я при ошибке в use2.cpp в месте (3) полезу в (1) и вставлю недостающий инклюд. В Вашем случае (use1.cpp) ошибки сборки не будет и файл c.h, вероятно, так и останется с недочетом.
Более того, если поменять включение "a.h" и "c.h" местами (как это сделано в use3.cpp) - то всё будет собираться. И ломать голову, почему в (4) всё собирается, а в (2) - нет - ну хотя бы лишняя потеря времени.
Самодостаточность файлов это включает в себя независимый порядок их включения, разве не так?
Меняется, Билли, меняется.
В обоих случаях блок внутри if'а не сработает. Но в Вашем случае $this->billing->makePayment() выполнится, а в моем — нет.
Почему? Потому что парсер «ленивый».
В Вашем примере:
он смотрит на первую часть условия, находит там false, а за ним — логическое «и». Значит на второй операнд можно и не смотреть.
В моем:
проводит успешную оплату. Потом применяет «и» на false и внутрь блока уже не заходит.
Судя по жалобе клиента я предположил, что Вы использовали именной мой вариант.
От себя добавлю, что порядок инклюдов хорошо бы вести такой:
а) публичные инклюды SomeLib
б) внутренние инклюды SomeLib
в) инклюды 3rd-party либ (boost, Qt, libpng etc)
г) инклюды STL
Это позволяет жестче следить за самодостаточностью файлов (п 4)
Общее правило: Чем более «низкоуровневый» файл включается, тем ниже он в списке.
«На практике оказалось, что Ада, заняв предназначенную ей нишу в военных и родственных им разработках встроенных систем, за пределы данной ниши так и не вышла, ни на Западе, ни в СССР, ни на постсоветском пространстве.»
Так что отключить pepper — пока только и спасает.
Буквально сегодня, разбирая старый проект, в котором используется метод «единого включения», наткнулся на вышеописанную мной проблему. В одном из заголовочных файлов нужна была банальщина, версия библиотеки. Чтобы не тянуть все-все хедеры кто-то когда-то сэкономил и включил только один файл с нужным функционалом. Всё работало до тех пор, когда этот файл собирался после другого, в котором «всё включено». Так вот, убирал я «мертвый» код из проекта, и получилось так, что этот «неправильно включенный» хедер начал собираться раньше.
Получается что? Изменился пользовательский код (который раньше работал корректно), а ошибку компилятор выдает во внутренних заголовочных файлах либы, которую никто и не трогал. Неаккуратненько и фрустрирует немного.
>А если теперь задаться вопросом: действительно ли, так необходимо реализовывать для пользователя библиотеки возможность подключения отдельных ее элементов?
Хорошо, когда SomeLib по объему не больше boost::shared_ptr. Тогда действительно, можно на вопрос ответить однозначно «нет»: написал один раз и забыл. Включай да пользуй.
Но в чем-то более крупном лучше я потрачу на 5 минут больше времени (на свежую голову), проверив все зависимости, чем буду через год голову ломать «почему меняя инклюды местами всё перестаёт собираться»
Как там писали? Чем позже найдена ошибка, тем дороже её устранение.
>Встречный вопрос, как Ваш подход применим при реализации библиотеки разработчиком (при поставке ее только в виде заголовочных файлов)?
На личном примере и советую, причем как со стороны разработчика библиотеки, так и со стороны её использования. И правило «напиши код так, чтобы неправильно использовать библиотеку было трудно» не раз себя хорошо зарекомендовал.
Да и вообще. Как-то простой совет с порядком инклюдов перерастает в сочинение «Один мой день», не нравится мне это.
Пример (хедергарды опущены):
a.h: // интерфейс
#include // в интерфейсе будет вектор. Инклюдим.
class A
{
public:
virtual ~A(){};
virtual std::vector getVector() = 0;
}
b.h: // реализация
#include "a.h"
#include // используем вектор? Опять инклюдим.
class B : public A
{
public:
virtual ~B(){};
virtual std::vector getVector()
{
// реализация
return m_Data;
};
private:
std::vector m_Data;
}
c.h:
// нет инклюда вектора! Забыли включить, например. (1)
struct C
{
std::vector arr; // (2) см ниже.
}
use1.cpp: // Ваш вариант.
#include // СТЛ в начале
#include "c.h" // (2) не ругается
#include "a.h"
use2.cpp: // тут самое интересное
#include "c.h" // (3) ругается
#include "a.h"
#include // СТЛ в конце
use3.cpp
#include "a.h"
#include "c.h" // (4) не ругается ни в каком случае.
}
Может, я чего-то не понимаю в этой жизни, но при моем варианте я при ошибке в use2.cpp в месте (3) полезу в (1) и вставлю недостающий инклюд. В Вашем случае (use1.cpp) ошибки сборки не будет и файл c.h, вероятно, так и останется с недочетом.
Более того, если поменять включение "a.h" и "c.h" местами (как это сделано в use3.cpp) - то всё будет собираться. И ломать голову, почему в (4) всё собирается, а в (2) - нет - ну хотя бы лишняя потеря времени.
Самодостаточность файлов это включает в себя независимый порядок их включения, разве не так?
В обоих случаях блок внутри if'а не сработает. Но в Вашем случае
$this->billing->makePayment()выполнится, а в моем — нет.Почему? Потому что парсер «ленивый».
В Вашем примере:
он смотрит на первую часть условия, находит там false, а за ним — логическое «и». Значит на второй операнд можно и не смотреть.
В моем:
проводит успешную оплату. Потом применяет «и» на false и внутрь блока уже не заходит.
Судя по жалобе клиента я предположил, что Вы использовали именной мой вариант.
В общем, добро пожаловать в программирование.
а) публичные инклюды SomeLib
б) внутренние инклюды SomeLib
в) инклюды 3rd-party либ (boost, Qt, libpng etc)
г) инклюды STL
Это позволяет жестче следить за самодостаточностью файлов (п 4)
Общее правило: Чем более «низкоуровневый» файл включается, тем ниже он в списке.
if ($this->billing->makePayment() && false)(void)opaque;
вместо
if (opaque) items += size — size;
Более сакрального смысла, чем избавиться от предупреждения о неиспользованном параметре, я не вижу.
Так что PVS молодец и в этом случае.
Там хоть ограничения в 140 символов нет ;)
В Seamonkey!
«На практике оказалось, что Ада, заняв предназначенную ей нишу в военных и родственных им разработках встроенных систем, за пределы данной ниши так и не вышла, ни на Западе, ни в СССР, ни на постсоветском пространстве.»