Например TDA7294

Форум РадиоКот • Просмотр темы - Для профи, сборка разбитого проекта по header'ам
Форум РадиоКот
Здесь можно немножко помяукать :)



Текущее время: Чт июл 18, 2019 22:29:46

Часовой пояс: UTC + 3 часа [ Летнее время ]


ПРЯМО СЕЙЧАС:



Начать новую тему Ответить на тему  [ Сообщений: 13 ] 
Автор Сообщение
Не в сети
 Заголовок сообщения: Для профи, сборка разбитого проекта по header'ам
СообщениеДобавлено: Ср июл 18, 2018 17:36:09 
Встал на лапы

Карма: 4
Рейтинг сообщений: 4
Зарегистрирован: Чт дек 09, 2010 13:03:08
Сообщений: 85
Откуда: Зеленоград
Рейтинг сообщения: 0
Всем привет, проект вырос, стало затруднительно продолжать разработку

Вынес все классы в разные .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 18:12:10 
Вымогатель припоя
Аватар пользователя

Карма: 10
Рейтинг сообщений: 66
Зарегистрирован: Вт май 01, 2018 20:44:47
Сообщений: 621
Рейтинг сообщения: 0
Какие-то надуманные проблемы. Посмотрите как сделаны те же stm-овские библиотеки - там десятки модулей. Если правильно заголовочные файлы оформлять, то никаких проблем не возникает. Можно подробнее обсудить разные подходы, если есть желание.


Вернуться наверх
 
JLCPCB, всего $2 за прототип печатной платы! Цвет - любой!

Отличное качество, подтвержденное более чем 600,000 пользователей! Более 10,000 заказов в день.

Зарегистрируйтесь и получите два купона по 5$ каждый:https://jlcpcb.com/quote

Не в сети
 Заголовок сообщения: Re: Для профи, сборка разбитого проекта по header'ам
СообщениеДобавлено: Ср июл 18, 2018 18:18:52 
Прорезались зубы

Карма: 9
Рейтинг сообщений: 73
Зарегистрирован: Чт ноя 06, 2014 14:09:06
Сообщений: 219
Рейтинг сообщения: 0
"Мешанинина" у Вас какая-то.

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


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

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


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

===
ЗЫ. привели бы маленький пример, в котором видны Ваши проблемы. Лично я не понял, что вызывает у Вас затруднения.


Последний раз редактировалось viiv Ср июл 18, 2018 18:30:58, всего редактировалось 2 раз(а).

Вернуться наверх
 
PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $88 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay
Не в сети
 Заголовок сообщения: Re: Для профи, сборка разбитого проекта по header'ам
СообщениеДобавлено: Ср июл 18, 2018 18:21:39 
Опытный кот

Карма: 15
Рейтинг сообщений: 142
Зарегистрирован: Вс июн 19, 2016 10:32:03
Сообщений: 814
Рейтинг сообщения: 0
Вынес все классы в разные .h файлы с описанием в .cpp

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


Вернуться наверх
 
Плавкие предохранители LittelFuse. Грамотный подбор

Выбор оптимального плавкого предохранителя требует учета многих параметров. Для упрощения выбора оптимального предохранителя и автоматизации расчетов Littelfuse предлагает онлайн-утилиту. Подробнее>>
Не в сети
 Заголовок сообщения: Re: Для профи, сборка разбитого проекта по header'ам
СообщениеДобавлено: Ср июл 18, 2018 18:37:59 
Вымогатель припоя
Аватар пользователя

Карма: 10
Рейтинг сообщений: 66
Зарегистрирован: Вт май 01, 2018 20:44:47
Сообщений: 621
Рейтинг сообщения: 0
Что-то мне подсказывает, что ТС если про препроцессор если и слышал, то не видел :)


Вернуться наверх
 
Немногим дороже дискретного решения: новое поколение импульсных стабилизаторов Mornsun

Практически во всех радиоэлектронных устройствах массово применяются линейные понижающие стабилизаторы напряжения типа КРЕН в корпусе TO220 (другое обозначение – 78хх) и им подобные для формирования основного напряжения питания схемы.
Данные стабилизаторы позволяют без особых затрат получить нужное для каскада или узла схемы напряжение, если устройство питается от внешнего источника с более высоким напряжением. Для этого требуются… Подробнее>>
Не в сети
 Заголовок сообщения: Re: Для профи, сборка разбитого проекта по header'ам
СообщениеДобавлено: Ср июл 18, 2018 18:43:45 
Друг Кота
Аватар пользователя

Карма: 28
Рейтинг сообщений: 144
Зарегистрирован: Пн июл 28, 2008 23:12:01
Сообщений: 3474
Рейтинг сообщения: 0
V2oD2o, вы сперва с просто С разберитесь и основами компиляции, а уж потом на плюсы посматривайте.
И если это вАААще первое ваше знакомство с яву и МК , то плюсы вообще крайне противопоказаны ...


Вернуться наверх
 


Не в сети
 Заголовок сообщения: Re: Для профи, сборка разбитого проекта по header'ам
СообщениеДобавлено: Ср июл 18, 2018 18:44:37 
Встал на лапы
Аватар пользователя

Карма: 1
Рейтинг сообщений: 19
Зарегистрирован: Пн ноя 02, 2009 06:27:41
Сообщений: 118
Откуда: С-Пб
Рейтинг сообщения: 0
Всем привет, проект вырос, стало затруднительно продолжать разработку

Вынес все классы в разные .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 20:02:18 
Встал на лапы

Карма: 4
Рейтинг сообщений: 4
Зарегистрирован: Чт дек 09, 2010 13:03:08
Сообщений: 85
Откуда: Зеленоград
Рейтинг сообщения: 0
Какие-то надуманные проблемы. Посмотрите как сделаны те же stm-овские библиотеки - там десятки модулей. Если правильно заголовочные файлы оформлять, то никаких проблем не возникает. Можно подробнее обсудить разные подходы, если есть желание.


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

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


не по теме

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


Вернуться наверх
 
Prist.ru предлагает скидку всем частным лицам при покупке приборов АКИП, GW Instek, APPA (кроме осциллографов АКИП-4115/1А, GDS-71102)!

Интересные новинки уже на складе:

Осциллограф АКИП-4126Е

Многоканальные источники питания серии GPP

Не в сети
 Заголовок сообщения: Re: Для профи, сборка разбитого проекта по header'ам
СообщениеДобавлено: Ср июл 18, 2018 20:05:24 
Вымогатель припоя
Аватар пользователя

Карма: 10
Рейтинг сообщений: 66
Зарегистрирован: Вт май 01, 2018 20:44:47
Сообщений: 621
Рейтинг сообщения: 0
Вопрос не понят
Давайте с чего-нибудь начнём. Вот пример небольшого класса. Что из этого непонятно?

hmc704t.h

hmc704t.cpp

main.h

main.cpp


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

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


Вернуться наверх
 
Купить электронные компоненты в LCSC

Отправка со склада через 4 часа после заказа!
900 000 пользователей, 3000+ заказов в день!
Зарегистрируйтесь сегодня и получите скидку 8 долларов на первый заказ!
Не в сети
 Заголовок сообщения: Re: Для профи, сборка разбитого проекта по header'ам
СообщениеДобавлено: Ср июл 18, 2018 23:29:33 
Встал на лапы
Аватар пользователя

Карма: 1
Рейтинг сообщений: 19
Зарегистрирован: Пн ноя 02, 2009 06:27:41
Сообщений: 118
Откуда: С-Пб
Рейтинг сообщения: 0
Кстати, а для чего вот это - #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 06:38:59 
Вымогатель припоя
Аватар пользователя

Карма: 10
Рейтинг сообщений: 66
Зарегистрирован: Вт май 01, 2018 20:44:47
Сообщений: 621
Рейтинг сообщения: 0
Кстати, а для чего вот это - #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 16:06:45 
Встал на лапы
Аватар пользователя

Карма: 1
Рейтинг сообщений: 19
Зарегистрирован: Пн ноя 02, 2009 06:27:41
Сообщений: 118
Откуда: С-Пб
Рейтинг сообщения: 0
one не будет видеть two и three т.к. они вызываются позже, как не тусуй очередность - всегда будет задействован какой либо функционал еще не подключенного файла

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


Вернуться наверх
 
Не в сети
 Заголовок сообщения: Re: Для профи, сборка разбитого проекта по header'ам
СообщениеДобавлено: Чт июл 19, 2018 16:13:27 
Встал на лапы

Карма: 4
Рейтинг сообщений: 4
Зарегистрирован: Чт дек 09, 2010 13:03:08
Сообщений: 85
Откуда: Зеленоград
Рейтинг сообщения: 0
Надо будет реальный пример собрать, а то кто в лес кто по дрова, суть всего выше-написанного понятна, но без примера разговор не предметный :)


Вернуться наверх
 
Показать сообщения за:  Сортировать по:  Вернуться наверх
Начать новую тему Ответить на тему  [ Сообщений: 13 ] 

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB
Extended by Karma MOD © 2007—2012 m157y
Extended by Topic Tags MOD © 2012 m157y