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

ПростоНуб

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 строк кода.

VladislavS

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

jcxz

[uquote="FeCat",url="/forum/viewtopic.php?p=3705652#p3705652"]Где идеологически правильнее объявлять и определять объекты которые используются во многих местах?[/uquote]
Объявлять - в хидерах очевидно.

arkhnchul

[uquote="FeCat",url="/forum/viewtopic.php?p=3705652#p3705652"]Где идеологически правильнее объявлять и определять объекты которые используются во многих местах?[/uquote]определять в своих заголовочниках вестимо. Объявлять - уже поразнообразнее. В целом, как бы это выразить - там, где это более логично в конкретном случае) Скажем, в исходнике, который наиболее интенсивно использует сей объект. Или в том, который структурно является, так скажем, "основным" его потребителем. Или там, где по логике вещей начинается взаимодействие с объектом. Или в отдельном файле.
вообще общая идея - лучше стараться не пихать в исходник того, без чего он соберется. Электронщики любят сооружать один файл с глобальными переменными - ну на то они и электронщики, а не программисты) В крупных проектах наоборот не редкость заголовочники, содержащие исключительно описание одной extern переменной и соответствующие им исходники из двух строчек, ее объявляющие.
[uquote="FeCat",url="/forum/viewtopic.php?p=3705652#p3705652"]какой нибудь стандарт на тему организации структуры программ, актуальный для уровня 1000 - 30000 строк кода.[/uquote]нет какого-нибудь явного стандарта. Общие практики есть, актуальные для любого объема. Основу можно сформулировать как "сооружай из кода отдельные блоки, а не лапшу".

[uquote="VladislavS",url="/forum/viewtopic.php?p=3705662#p3705662"]Обоснование будет?[/uquote]обоснование того, почему сильная связь разнонаправленных участков кода и хаотичное "мали ли где чего" вместо их разделения и изолирования - так себе подход? нет, не будет.

ARV · Сообщение **ARV** » Пн сен 23, 2019 15:00:24

arkhnchul писал(а):определять в своих заголовочниках вестимо. Объявлять - уже поразнообразнее.

имхо, в великом и могучем термины "определять" и "объявлять" вполне могут быть взаимозаменяемыми... что кардинально искажает смысл в контексте программирования.

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

описание

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

extern uin8_t var;
void foo(void);

реализация

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

uint8_t var;

void foo(void){
   printf("foo\n");
}

использование

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

var = 12;
foo();

ПростоНуб

ARV, если Вы видели пример моего заголовочного файла выше, то могли заметить, что описание и реализация у меня всегда совмещены в одной конструкции. А уж в какой объектник попадет "реализация", точнее в каком объектнике будет выделена память и сформирована внешнаяя ссылка для компоновщика на эту память - совершенно не принципиально.

ARV · Сообщение **ARV** » Пн сен 23, 2019 15:06:32

ПростоНуб писал(а):описание и реализация у меня всегда совмещены в одной конструкции.

возможно, для С++ это нормально, но для Си - не совсем.

VladislavS

[uquote="arkhnchul",url="/forum/viewtopic.php?p=3705942#p3705942"]обоснование того, почему сильная связь разнонаправленных участков кода и хаотичное "мали ли где чего" вместо их разделения и изолирования - так себе подход? нет, не будет.[/uquote]Что такое "сильная связь", не знаю такого термина в программировании? Разделены они пространствами имён - ни один модуль другому не мешает в принципе. А возможность пользоваться всеми своими библиотеками, объектами, классами и т.д. в любом месте программы вполне естественна и удобна. Единственное чем я за это плачу - время сборки.

Добавлено after 2 minutes 43 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=3705963#p3705963"]

ПростоНуб писал(а):описание и реализация у меня всегда совмещены в одной конструкции.

возможно, для С++ это нормально, но для Си - не совсем.[/uquote]
Какая разница то? Вполне нормальный подход и для C, там что #ifdef запретили? Зато всё в одном месте - труднее ошибиться.

ПростоНуб

ARV, пример то был как раз на C