Переписал я часть своего проект в java стиль, т.е. когда реализация метода класса сразу в её декларации. Может быть есть правильное название этого стиля ?
java стиль мне больше нравиться особенно когда много мелких функций, и нужно часто менять их декларации или добавлять новые.
Если нужно хеадер посмотреть, то можно сделать в IDE Folding->Fold all и вы получите фактически header файл, с возможность раскрыть любую функцию.
1. Размер exe, в байтах
1) 263.680 — компиляция через много cpp файлов + линковка
2) 261.632 — компиляция через 1 cpp файл, который включает другие cpp файлы
далее, половина проекта переписана в java стиль
3) 250.880 — компиляция через 1 cpp файл
4) 253.440 — компиляция через 2 cpp файла + линковка
Использую gcc v10.2 on Windows 10. Оптимизация по размеру exe. Конечно же опции одинаковые, вот основная часть: -Os -ffunction-sections -Wl,--strip-all -Wl,--gc-sections
В map файле п2 есть неиcпользуемая функция, этим я объясняю почему п2 больше чем п3. Почему gcc не выкидывает её я не смог понять.
Разницу в размере между п1 и п3 не могу пока объяснить, думаю потому-что я не писал noexcept и компилятор смог оптимизировать когда сразу все функции увидел.
Разницу между п3 и п4 объясняю так — когда сразу не все функции даёшь, то оптимизация хуже работает.
Размер exe, в п3 зависит от порядка включения h файлов. Почему так ?
Может есть ещё какие-то объяснения изменения в размерах ?
2. Пробемы компиляции
Вылезли некоторые атрефакты компиляции, их я в отдельных ветках опишу.
Возникает проблема когда метод класса A использует класс B и наоборот. Приходится такие методы выностить в cpp файл — неудобно.
Может есть решение данной проблемы ?
Если нет решение, вижу следующее решение: пишу свой парсер/препроцессор и разбиваю 1 файл java стиль на 2 файла cpp+h и потом уже они компилируются.
Это нужно делать в прозрачном для пользователя режиме, а так же в случае ошибки ссылаться на место в оригинальном файле.
Но как показывает опыт gcc хуже оптимизирует cpp+h или я что-то не понимаю, нужно получить ответы на п1.
Может уже есть такие решения ? Велосипед не охото изобретать.
Здравствуйте, maks1180, Вы писали:
M>Переписал я часть своего проект в java стиль, т.е. когда реализация метода класса сразу в её декларации. Может быть есть правильное название этого стиля ?
header only
boost подключи — увидишь радость бытия
M>Возникает проблема когда метод класса A использует класс B и наоборот. Приходится такие методы выностить в cpp файл — неудобно. M>Может есть решение данной проблемы ?
Для особых ценителей — можно сыграть на том что шаблоны инстанцируются по факту использования использования а не по мере объявления, примерно так:
template <class SS=void>
struct MyScope
{
template <class SS2=void>
struct MrFirst
{
//никаких предварительных деклараций, заранее используем сущность которая будет объявлена позже
MyScope<SS2>::template MrSecond<> second{*this};
void f()
{
typename MyScope<SS2>::template MrSecond<> moreSecond{*this};
moreSecond.f();
}
};
template <class SS2=void>
struct MrSecond
{
MrSecond(MyScope<SS2>::template MrFirst<>& first)
: first{first}
{}
//если декларация на текущий момент уже существует то можно ее использовать прямо:
//MrFirst<>& first;
//но для единообразия пусть будет так:
MyScope<SS2>::template MrFirst<>& first;
void f()
{
typename MyScope<SS2>::template MrFirst<> moreFirst{};
//moreFirst.f();
}
};
};
int main()
{
MyScope<>::MrFirst<> first;
first.second.first.f();
return 1;
}
V>Для особых ценителей — можно сыграть на том что шаблоны инстанцируются по факту использования использования а не по мере объявления, примерно так:
Спасибо! Не идеальное решение, как для написания так и для чтения кода. Возможно так же что и компилироваться такой код будет в менее оптимизированный.
Здравствуйте, maks1180, Вы писали:
M>Переписал я часть своего проект в java стиль, т.е. когда реализация метода класса сразу в её декларации. Может быть есть правильное название этого стиля ?
Если вам нужно работать и поддерживать код C++, то только с разделением на заголовочный файл и реализацию.
Более того в заголовчном файле по возможности стоит избегать #include и использовать предварительное объявление.
Если работать в header only стиле, то каждое изменение может привести к перекомпиляции большого количества файлов вместо нескольких.
Это не существенно когда у вас всего несколько файлов, но когда проект большой, то будет тяжело работать.
А в чём проблема разделения кода ?
Сегодня все редакторы кода умеют это делать за вас в один щелчок.
Здравствуйте, maks1180, Вы писали:
M>Переписал я часть своего проект в java стиль, т.е. когда реализация метода класса сразу в её декларации. Может быть есть правильное название этого стиля ?
Это не java-стиль, это header-only стиль, я так писал, когда никакой джавы еще в планах не было
M>java стиль мне больше нравиться особенно когда много мелких функций, и нужно часто менять их декларации или добавлять новые. M>Если нужно хеадер посмотреть, то можно сделать в IDE Folding->Fold all и вы получите фактически header файл, с возможность раскрыть любую функцию.
Что мешает так делать в плюсах?
M>Возникает проблема когда метод класса A использует класс B и наоборот. Приходится такие методы выностить в cpp файл — неудобно.
Вообще не обязательно выносить в отдельный C++ файл
M>Может есть решение данной проблемы ?
Есть конечно. Пишешь в теле класса прототип, а реализацию — после определения всех зависимых классов с пометкой inline.
Я вообще, когда меня начинает напрягать много кода в интерфейсе класса, выношу все реализации в *_impl.h, который кладу рядом и включаю в конце основного файла
M>Если нет решение, вижу следующее решение: пишу свой парсер/препроцессор и разбиваю 1 файл java стиль на 2 файла cpp+h и потом уже они компилируются. M>Это нужно делать в прозрачном для пользователя режиме, а так же в случае ошибки ссылаться на место в оригинальном файле. M>Но как показывает опыт gcc хуже оптимизирует cpp+h или я что-то не понимаю, нужно получить ответы на п1. M>Может уже есть такие решения ? Велосипед не охото изобретать.
