Вопросы по С/С++ (СИ)

WiseLord

Ну так и понятно, что ругается на неизвестный тип SensorConf - инклюд, в котором он, видимо, определён, закомментирован чуть выше.

Реклама

arkhnchul

не про это спрашивал, ну ладно, сойдет. Вижу.
"recipe for target 'SensorConf.o' failed" - т.е. ошибка возникает при попытке скомпилять SensorConf.cpp
из-за адского месива в инклудах прототип из PrintFunc.h появляется в собираемом коде раньше, чем описание класса SensorConf из SensorConf.h. Прикрепил выхлоп препроцессора , гляньте на него.

идея организовать для простоты один мегазаголовочник (здесь - main.h), в который прицеплены вообще все остальные заголовочники и который потом прямо или через какую-нибудь задницу - типа местного global_vars.h или еще чего - появляется в каждом из исходников проекта, очень простая, очевидная и неправильная. Не надо так делать без веских причин.

Реклама

WiseLord

А зачем Вам в PrintFunc.h включать main.h? Что оттуда нужно конкретно здесь, в этом файле?

Добавлено after 4 minutes 49 seconds:
arkhnchul, вопрос не к Вам, естественно.

Хотя идея одного "мега" инклюда вполне могла бы сработать. Лишь бы там были только прототипы функций, описания структур, макросы, и не более того. И, естественно, никаких объявлений переменных. И никаких включений других заголовочных файлов того же проекта, которые могут включать его самого, формируя циклические включения.

ПростоНуб

WiseLord, почему в одном общем заголовочном файле нельзя объявлять переменные? Я всегда так делаю, решая проблему одним дефайном в исходнике, в чьем обьектнике будет располагатся статический сегмент.
А рекурсивное включение легко избегается одним #ifndef и дефайном.

Добавлю примеры.
В одном из исходных файлов проекта объявляем

Код: Выделить всё

#define _MAIN_C_

Во включаемом общем файле делаем так:

Код: Выделить всё

#ifndef _MAIN_H_INCLUDED
#define _MAIN_H_INCLUDED

#ifdef __cplusplus
extern "C" {
#endif

#ifdef _MAIN_C_
#define _MAIN_EXTERNAL_
#else
#define _MAIN_EXTERNAL_ extern
#endif // _MAIN_C_
...
_MAIN_EXTERNAL_ int some_global_static_variable;
...
#ifdef __cplusplus
}
#endif

#endif // _MAIN_H_INCLUDED

Реклама

Billi34

Прошу прощения за поздний ответ. Утром предоставлю объяснялки. Отладчиков симуляторов нет но есть лишнее "дерганье ногами" в "железе". Код предоставлю.

Реклама

VladislavS

Billi34, ты же нас фактически послал с советами сделать нормальную структуру программы. Типа "и так сойдёт". Ну теперь пожинай плоды. Твой код в принципе неуправляем. Это было понятно сразу. Когда опытный программист смотрит на код и не понимает как он работает, то такой код в топку. Впрочем, он и не работает, как и ожидалось.

Добавлено after 52 minutes 13 seconds:
[uquote="arkhnchul",url="/forum/viewtopic.php?p=3705026#p3705026"]идея организовать для простоты один мегазаголовочник (здесь - main.h), в который прицеплены вообще все остальные заголовочники и который потом прямо или через какую-нибудь задницу - типа местного global_vars.h или еще чего - появляется в каждом из исходников проекта, очень простая, очевидная и неправильная. Не надо так делать без веских причин.[/uquote]А я так делаю. #pragma once и namespace позволяют безболезненно инклюдить что угодно и куда угодно, если заголовочные файлы у вас действительно заголовочные. Единственный минус такого подхода - время компиляции. Но, во-первых, современные компиляторы умеют не компилировать много раз одни и те же заголовочные файлы. Во-вторых, у меня на ноуте, который является основным местом сборки эмбеддерских проектов, 8-ядерный проц и SSD. Ну будет у навороченного проекта полная сборка на 5 сек больше, да и чёрт с ним. На простых проектах разница вообще о-малое. Зато я получаю кучу плюсов для себя любимого.

Реклама

ПростоНуб

[uquote="VladislavS",url="/forum/viewtopic.php?p=3705079#p3705079"]#pragma once[/uquote]
Не универсально, так как нестандартная конструкция, поддерживаемая не всеми компиляторами. Мой же вариант, приведенный выше, работает с любым компилятором.
Так же #pragma once не позволяет использовать X-Macro, а иногда хочется.

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

VladislavS

Компиляторы, которые я использую, все поддерживают. Мне этого достаточно. Много компиляторов С++17 не поддерживают, и что, тоже не использовать?

ПростоНуб

VladislavS, все течет, все изменяется. Завтра Вам понадобится использовать новый компилятор, а старый код не получится в него всунуть. Из тех компиляторов, которые я использую, не поддерживает, например, SDCC. Будете для того же PDK14 писать на урезанном C от Padauk?

А X-Macro зачем себя лишать?

P.S. С++17 позволю использовать программистам на проектах через несколько лет, не раньше. Пока подавляющее большинство компиляторов его не поддерживают, использование слишком рисковано из-за непереносимости кода. До сих пор на проектах допускаю использовать только C++11, как максимум, если об ином не настаивает сам заказчик. Например, у меня до сих пор ряд проектов на VS2011, которые перетаскивать под VS2017 надо по неделе на каждый. Под VS2019 даже не пробовал еще.
Если заказчик согласен платить по стандартной ставке за неделю работы (120 тыс. руб. без НДС), то, конечно, перетащу. Но пока никто не настаивал )))

ARV · Сообщение **ARV** » Вс сен 22, 2019 12:18:03

Как же вы задолбали, профессионалы!!!

Вам мало профессиональных сообществ?! Или там у всех письки больше, потому вы тут рассказывает о своих профессиональных достижениях?!

Billi34

И снова здравствуйте. Не зря говорят "утро вечера мудренее". Нашлись синтаксические ошибки. И временные не состыковки.
пока справляюсь.

ПростоНуб

ARV, а Вы задолбали хроническим оффтопиком и флудом. Ни о каких достижениях я ни слова не говорил. Все достижения на сайте моего работодателя и в моем LinkedIn. Здесь им не место.

ARV · Сообщение **ARV** » Вс сен 22, 2019 13:16:24

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3705216#p3705216"]VladislavS, все течет, все изменяется. Завтра Вам понадобится использовать новый компилятор, а старый код не получится в него всунуть. Из тех компиляторов, которые я использую, не поддерживает, например, SDCC. Будете для того же PDK14 писать на урезанном C от Padauk?

А X-Macro зачем себя лишать?

P.S. С++17 позволю использовать программистам на проектах через несколько лет, не раньше. Пока подавляющее большинство компиляторов его не поддерживают, использование слишком рисковано из-за непереносимости кода. До сих пор на проектах допускаю использовать только C++11, как максимум, если об ином не настаивает сам заказчик. Например, у меня до сих пор ряд проектов на VS2011, которые перетаскивать под VS2017 надо по неделе на каждый. Под VS2019 даже не пробовал еще.
Если заказчик согласен платить по стандартной ставке за неделю работы (120 тыс. руб. без НДС), то, конечно, перетащу. Но пока никто не настаивал )))[/uquote]есть ли в этом сообщении хоть одно полезное слово, пррливающее свет хоть на какой-то аспект С/С++?!

VladislavS

Макросы зло, язык идёт в сторону отказа от них. И пусть #pragma once будет самой большой моей проблемой, я это как-нибудь переживу

ПростоНуб

ARV, ну если у Вас так плохо с восприятием печатного текста, напишу тоже самое более развернуто:
1. Использование #ifndef ... #define... #endif более универсально, чем использование #pragma once, так как не только поддерживается всеми компиляторами, но так же не ограничивает использование X-Macro.
2. Переход на новые стандарты языка всегда чреват проблемами при переносе старых проектов на этот новый стандарт. Этот переход требует правок в старом коде и последующей отладки с тестированием. Например, именно поэтому в том же Arduino IDE используется довольно старый GCC 5.4.0, полноценно поддерживающий только C++11, но никак не С++17. Для последнего полноценная поддержка появилась только в GCC 7.x.x

Добавлено after 3 minutes 3 seconds:
VladislavS, Вы вообще в порядке? Покажите мне хотя бы один проект на C/С++ без макроопределений. В тот день, когда препроцессор перестанет поддерживать макросы, не останется программистов, желающих этим препроцессором пользоваться )))

arkhnchul

[uquote="WiseLord",url="/forum/viewtopic.php?p=3705032#p3705032"]И никаких включений других заголовочных файлов того же проекта, которые могут включать его самого[/uquote]я, собственно говоря, про это.

VladislavS писал(а):А я так делаю. #pragma once и namespace позволяют безболезненно инклюдить что угодно и куда угодно

а зачем?

VladislavS

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3705307#p3705307"]VladislavS, Вы вообще в порядке? Покажите мне хотя бы один проект на C/С++ без макроопределений. В тот день, когда препроцессор перестанет поддерживать макросы, не останется программистов, желающих этим препроцессором пользоваться )))[/uquote]Да, будет ломка, однако, сел ля ви.

Добавлено after 2 minutes 9 seconds:
[uquote="arkhnchul",url="/forum/viewtopic.php?p=3705321#p3705321"]а зачем?[/uquote]Удобно. Всё подключается в одном месте - легко контролировать. Всё доступно везде, мало ли где что я использовать буду.

arkhnchul

[uquote="VladislavS",url="/forum/viewtopic.php?p=3705335#p3705335"]Да, будет ломка, однако, сел ля ви.[/uquote]как прагмами и constexpr-ами заменить условную компиляцию?
[uquote="VladislavS",url="/forum/viewtopic.php?p=3705335#p3705335"]мало ли где что я использовать буду.[/uquote]вот это и есть, собственно, фиговая практика.

ПростоНуб

arkhnchul, мне тоже интересно, как обойтись без макросов. У меня один и тот же проект с разным одним дефайном в командной строке собирается для разных клиентов совершенно по разному. И кто-то меня заставит иметь гимморой с проектом для каждого клиента и постоянными мержами между ними?

FeCat

[uquote="arkhnchul",url="/forum/viewtopic.php?p=3705026#p3705026"]не про это спрашивал, ну ладно, сойдет. Вижу.
"recipe for target 'SensorConf.o' failed" - т.е. ошибка возникает при попытке скомпилять SensorConf.cpp
из-за адского месива в инклудах прототип из PrintFunc.h появляется в собираемом коде раньше, чем описание класса SensorConf из SensorConf.h. Прикрепил выхлоп препроцессора , гляньте на него.

идея организовать для простоты один мегазаголовочник (здесь - main.h), в который прицеплены вообще все остальные заголовочники и который потом прямо или через какую-нибудь задницу - типа местного global_vars.h или еще чего - появляется в каждом из исходников проекта, очень простая, очевидная и неправильная. Не надо так делать без веских причин.[/uquote]

Переделал, для каждого .cpp индивидуальный список только необходимых инклудов, + extern для отдельных функций и переменных. И всё собралось нормально.

Вопрос. Где идеологически правильнее объявлять и определять объекты которые используются во многих местах?
Вообще хочется почитать какой нибудь стандарт на тему организации структуры программ, актуальный для уровня 1000 - 30000 строк кода.