Кто любит RISC в жизни, заходим, не стесняемся.
Ответить

Для профи, сборка разбитого проекта по header'ам

Ср июл 18, 2018 16:36:09

Всем привет, проект вырос, стало затруднительно продолжать разработку

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

Особенность всех IDE, и условно стандартной обработки через make all - например в блокноте - подразумевает сборку всех .cpp файлов в .o - по условию %.cpp - отсюда проблема видимости разными классами - других классов, и упорядочить include - не представляется возможным, т.е.:

#include one
#include two
#include three

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

Предварительное объявление не актуально, эту роль выполняет .h

Еще при сборке .cpp от .h - есть проблема видимости констант и инклюдов указанных в main.cpp

Если собирать только один файл main.cpp - все собирается прекрасно, но времени уходит на сборку - куча, .cpp => .o => .elf => .bin, можно конечно какой нибудь пакетный файл сделать, но не хотелось бы отходить от makefile

Кто то встречал решения по данной проблеме, или может кто то разрабатывает что то серьёзнее чем однофайловый проект и тоже сталкивался ?

Может какие то директивы есть для указания того что файл .cpp является дополнением для заголовочного .h и его не надо обрабатывать до обработки файлов без директив?

Убрать использование одного класса из другого и передавать ссылки\указатели - не вариант, это будет over 9000 указателей для обработки нужных данных

Re: Для профи, сборка разбитого проекта по header'ам

Ср июл 18, 2018 17:12:10

Какие-то надуманные проблемы. Посмотрите как сделаны те же stm-овские библиотеки - там десятки модулей. Если правильно заголовочные файлы оформлять, то никаких проблем не возникает. Можно подробнее обсудить разные подходы, если есть желание.

Re: Для профи, сборка разбитого проекта по header'ам

Ср июл 18, 2018 17:18:52

"Мешанинина" у Вас какая-то.

Особенность всех IDE, и условно стандартной обработки через make all - например в блокноте - подразумевает сборку всех .cpp файлов в .o - по условию %.cpp - отсюда проблема видимости разными классами - других классов, и упорядочить include - не представляется возможным, т.е.:


В си/С++ раздельная компиляция. Т.е. каждый файл *.c/*.cpp компилируется независимо от других. Из этого Вы и должны исходить.
Если не рассматривать, совсем редкие и экзотические случаи, то *.c/*.cpp вообще никогда никуда не инклудятся.

Может какие то директивы есть для указания того что файл .cpp является дополнением для заголовочного .h и его не надо обрабатывать до обработки файлов без директив?


Как *.cpp может являться дополнением *.h файла??? *.cpp - это исходники. В *.h файлах вообще не должно быть того, что генерирует код.
Я бы сказал, что *.h файл является дополнением c/cpp файла (если предположить, что слово "дополнение" здесь может быть применимо), так как в нем описан интерфейс использования объектов/функций из реализация которых находится в *.с/с++ файлах.

===
ЗЫ. привели бы маленький пример, в котором видны Ваши проблемы. Лично я не понял, что вызывает у Вас затруднения.
Последний раз редактировалось viiv Ср июл 18, 2018 17:30:58, всего редактировалось 2 раз(а).

Re: Для профи, сборка разбитого проекта по header'ам

Ср июл 18, 2018 17:21:39

Вынес все классы в разные .h файлы с описанием в .cpp

Это как? Тоже хотелось бы глянуть на пример...

Re: Для профи, сборка разбитого проекта по header'ам

Ср июл 18, 2018 17:37:59

Что-то мне подсказывает, что ТС если про препроцессор если и слышал, то не видел :)

Re: Для профи, сборка разбитого проекта по header'ам

Ср июл 18, 2018 17:43:45

V2oD2o, вы сперва с просто С разберитесь и основами компиляции, а уж потом на плюсы посматривайте.
И если это вАААще первое ваше знакомство с яву и МК , то плюсы вообще крайне противопоказаны ...

Re: Для профи, сборка разбитого проекта по header'ам

Ср июл 18, 2018 17:44:37

Всем привет, проект вырос, стало затруднительно продолжать разработку

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

А зачем классы внутри класса если это только не наследование? Скорее всего в этом и проблема. Класс - это самодостаточный объект, и он не должен зависеть от наличия другого класса и редко, когда внутри класса используются внешние объявления переменных или констант.
Все что нужно, передается в класс либо частями, либо в виде структуры, так проще.

Особенность всех IDE, и условно стандартной обработки через make all - например в блокноте - подразумевает сборку всех .cpp файлов в .o - по условию %.cpp - отсюда проблема видимости разными классами - других классов, и упорядочить include - не представляется возможным, т.е.:

#include one
#include two
#include three

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

Если все привести в порядок, то будет все видеться. Ведь инклуды от классов, это всего лишь предварительные объявления.
Если класс самодостаточный, то он будет использоваться в головном файле, вы же все равно создадите объект.
Код:
#include one
#include two
#include three
...
one *Class1;
two *Class2;
three *Class3 ;
.....
Class1->init();
Class1->Dofunc1(&struct1);
Class1->exit();
delete Class1;
....
....

И юзайте их вдоль и поперек и инклуды вешайте как угодно.
Если надо класс сделать в классе, то подумайте, может проще сделать наследование и добавить нужные методы,
чем делать перекрестные ссылки.

Re: Для профи, сборка разбитого проекта по header'ам

Ср июл 18, 2018 19:02:18

Какие-то надуманные проблемы. Посмотрите как сделаны те же stm-овские библиотеки - там десятки модулей. Если правильно заголовочные файлы оформлять, то никаких проблем не возникает. Можно подробнее обсудить разные подходы, если есть желание.


Вопрос не понят, да и библиотеки не используются

Добавлено after 1 minute 49 seconds:
V2oD2o, вы сперва с просто С разберитесь и основами компиляции, а уж потом на плюсы посматривайте.
И если это вАААще первое ваше знакомство с яву и МК , то плюсы вообще крайне противопоказаны ...


не по теме

Добавлено after 11 minutes 9 seconds:
Что то видимо без примера сложно понять..

Re: Для профи, сборка разбитого проекта по header'ам

Ср июл 18, 2018 19:05:24

Вопрос не понят
Давайте с чего-нибудь начнём. Вот пример небольшого класса. Что из этого непонятно?

hmc704t.h

hmc704t.cpp

main.h

main.cpp


V2oD2o, вы сперва с просто С разберитесь и основами компиляции, а уж потом на плюсы посматривайте.
Вместе с тем, в плюсах есть такая штука как namespace, которая сильно помогает в этом деле.

либо в виде структуры
В плюсах класс и структура это одно и то же, за мелким отличием.

Re: Для профи, сборка разбитого проекта по header'ам

Ср июл 18, 2018 22:29:33

Кстати, а для чего вот это - #define HMC704T_CPP ?
И потом вот это #ifdef HMC704T_CPP ....
Зачем делать:
#define HMC704T_CPP
#include "main.h"
Объявления внешних констант можно было и в .h запихать (extern const HMC704_CP cpVSfreq[];),
чего им делать в .cpp

И смысл использовать выбор шаблона класса в препроцессоре ?
Не проще бы просто вначале того же main.h при компиляции 2 строчки раскомментировать и все ?
Или проще вспоминать, где же там идет выбор шаблона...
Да и объявление класса можно было в main тогда вынести и было бы видно где он объявляется,
а не гадать. Проще даже отлаживать.

Структура и класс это почти одно и тоже, разве что некоторые формальности опущены. Но это тут ни причем.

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

Re: Для профи, сборка разбитого проекта по header'ам

Чт июл 19, 2018 05:38:59

Кстати, а для чего вот это - #define HMC704T_CPP ?
И потом вот это #ifdef HMC704T_CPP ....
Зачем делать:
#define HMC704T_CPP
#include "main.h"
Потому что, в заголовочном файле есть часть кода, которая предназначена только для "своего" модуля. Глобальные переменные и экземпляры самого класса, которые должны быть видны наружу, я объявляю в заголовочном файле, так как это часть интерфейса модуля. Надо продублировать объявление и extern на него. Я делаю это в одном месте - так проще писать и тяжелее ошибиться. Если делать это в разных местах, то труднее контролировать всё ли объявлено и одинаково ли объявлено. Конечно же, компилятор, ткнёт носом, но потом по разным файлам не надо лазить, чтобы привести всё в соответствие. Или, например, объявлены выходы процессора, к которым подключен синтезатор. Когда я буду использовать этот класс в другом проекте, то подключу заголовочный файл, поправлю только в нём определение выводов и всё. Всё что касается описания/параметризации интерфейса модуля сосредоточено в одном месте. А так как вне модуля никому не положено знать про ножки к которым подключен синтезатор, то они спрятаны под ифдеф и как бы сосланы в cpp. Тем более, что выводы это не просто какие-то дефайны, а серьёзные классы из другого пространства имён.

Объявления внешних констант можно было и в .h запихать (extern const HMC704_CP cpVSfreq[];),
чего им делать в .cpp
А что ей делать в .h? Она закрытая, используется только в одном методе класса, зачем её светить всему миру? В заголовочном файле только интерфейс модуля. Возможно, вас смутил extern, но в данном случае он не светит наружу массив, а лишь предварительно описывает его тип чтобы можно было использовать в методе класса. А само определение массива в конце модуля, чтобы не засорять реализации методов мусорными данными.

И смысл использовать выбор шаблона класса в препроцессоре ?
Не проще бы просто вначале того же main.h при компиляции 2 строчки раскомментировать и все ?
Или проще вспоминать, где же там идет выбор шаблона...
Шаблоны это вообще отдельная тема. Я специально пример с шаблоном взял, чтобы вопросы появились. С шаблонами всегда идёт борьба с компилятором, чтобы он инстанцировал все нужные реализации да ещё не там где он хочет, а там где хочу я, чтобы сохранить модульность программы. Творческий процесс всегда :) В данном случае я создаю три объекта класса синтезатора и объявляю интерфейс к ним. Другие модули ничего о шаблонах знать не должны, они знают лишь что есть эти три объекта и как ими пользоваться.

Да и объявление класса можно было в main тогда вынести и было бы видно где он объявляется,
а не гадать. Проще даже отлаживать.
Почему в main? Он и в других модулях используется. Нет уж, всё что касается объявлений класса должно быть сосредоточено в модуле в котором он живёт. Зачем мне по всему проекту это размазывать. Чтобы использовать классы/объёкты модуля, достаточно просто подключить его заголовочный файл. Всё что нужно для работы модуля, написано/скрыто внутри модуля.

Структура и класс это почти одно и тоже, разве что некоторые формальности опущены. Но это тут ни причем.
Мимо :) У структуры кишки по умолчанию public, а у класса private - вот и всё отличие.

Просто видать писалось все это давно, потом рихтовалось и пыталось взлететь.
Нет, тут ничего не притянуто за уши, каждая строка это осознанный выбор на этапе написания модуля. Остальные модули построены по тому же принципу.

Честно говоря, наверное надо просто составить структуру программы, классы сделать без вставок препроцессоров и будет все проще и понятней. Честно говоря, тяжело будет кому-то потом это все понимать.
Можете на моём примере показать как?

Классы мелкие, думаю можно их переправлять постепенно.
Но как говорится, работает... ничего не меняй.
Что вы там переправлять собрались? Всё написано и работает ровно так как задумано.

Спасибо за содержательные вопросы, думаю ТС будет над чем подумать.

Re: Для профи, сборка разбитого проекта по header'ам

Чт июл 19, 2018 15:06:45

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

Мне конечно не сложно повторить, но, чего вы ожидали, если ваш класс объявляется сразу после описания его реализации?
Если вы его не объявите, то у вас будут ошибки в компиляции, т.к. другие классы ничего еще о нем не знают.
А если вы его просто не хотите использовать больше, то что еще отвалится?
Я в свое время от этого отказался, т.к. иногда лишние модули становятся не нужны, и я просто в main комментирую 1 строку
и нужные блоки (можно даже через ifndef это сделать, если проектов много, а функционал часто используется).
Чтобы из 10 модулей оставить только 2, я даже не думаю, что там у них внутри. Просто выключаю в головном файле лишнее
и компилю. Если через препроцессор, то закомментировать 8 дефайнов куда проще, чем искать, что там еще отвалится.
Как-то так.

Re: Для профи, сборка разбитого проекта по header'ам

Чт июл 19, 2018 15:13:27

Надо будет реальный пример собрать, а то кто в лес кто по дрова, суть всего выше-написанного понятна, но без примера разговор не предметный :)
Ответить