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

[NStorm]

[uquote="ARV",url="/forum/viewtopic.php?p=3705951#p3705951"]имхо, в великом и могучем термины "определять" и "объявлять" вполне могут быть взаимозаменяемыми... что кардинально искажает смысл в контексте программирования.

лично я для себя и в беседах с другими предпочитаю использовать чуть иную терминологию, уже не допускающую разных толкований:[/uquote]
Во всей литературе уже давно определились как переводить declaration и definition - объявлять и определять. Не надо пожалуйста придумывать свою терминологию. Еще больше искажает смысл именно подобное.

[ARV]

уже давно определились как переводить declaration и definition

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

Какая разница то?

ну как бы реализация всегда является и описанием в Си, т.е. если в заголовок включить реализацию функции, например, а потом этот заголовок включить в несколько разных исходников, линкеру это не понравится. то же самое с переменными.
и никакие #ifdef не помогут

[NStorm]

[uquote="ARV",url="/forum/viewtopic.php?p=3705979#p3705979"]а вот я считаю, что определились не правильно. возможно, какой-то самый первый переводчик в русском языке не разбирался, как следует, и выбрал "буквальный" перевод, ну а остальные просто копипастили... а для русского важен не буквальный, а смысловой перевод. вот сколько лет читаю - столько и не могу привыкнуть. вам проще, если смогли. видимо, тоже не особо загружены знаниями в русском языке.[/uquote]
Мне тоже глаза режет немного. Но если чуть задуматься над корнями слов, то всё ясно. Объявить - просто объявление, оно же сообщение, что такое где-то есть. А определить - уже конкретно определиться, что это мы будем использовать.
В крайнем случае можно загуглить или подсмотреть в литературе. А вашу личную выдумку где смотреть каждый раз новому человеку?

[uquote="ARV",url="/forum/viewtopic.php?p=3705979#p3705979"]ну как бы реализация всегда является и описанием в Си, т.е. если в заголовок включить реализацию функции, например, а потом этот заголовок включить в несколько разных исходников, линкеру это не понравится. то же самое с переменными.
и никакие #ifdef не помогут[/uquote]
Человек выше про "объекник" говорил - .o файл, а не хидер.Правильно "объектники" называются юниты. Вот он очередной пример бед от своей терминологии.

EDIT: Точнее конечно .o файлик - это отдельная вещь, но в данном случая важна не она. Это вообще метод работы конкретного компилятора и к стандартам языка он не относится. В стандартах языка есть понятие "translation unit" - это один отдельный .c файл, со всеми его инклюдами препроцессора.

[arkhnchul]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3705966#p3705966"]Что такое "сильная связь", не знаю такого термина в программировании?[/uquote]а термина для этого нет. "Такое" это как раз использование всех своих объектов в любом наугад выбранном месте вместо организации четкой иерархии отдельных самостоятельных блоков и "клея" между ними.

Добавлено after 1 minute 54 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=3705979#p3705979"]а вот я считаю, что определились не правильно[/uquote]тем не менее, такая вот общепринятая терминология - сложившийся факт. Использовать ее лучше, чем каждому выдумывать свою собственную.

[ПростоНуб]

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

Добавлено after 4 minutes 51 second:
[uquote="NStorm",url="/forum/viewtopic.php?p=3705986#p3705986"]Правильно "объектники" называются юниты.[/uquote]
Почитайте хоть, что такое объектный файл
И не надо засорять русский язык английскими словами в русской транскрипции. Это уж точно "правильным" не назовешь )))

[NStorm]

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3705990#p3705990"]Почитайте хоть, что такое объектный файл
И не надо засорять русский язык английскими словами в русской транскрипции. Это уж точно "правильным" не назовешь )))[/uquote]
Я поправил пост. Я в курсе, что такое объектный файл. И что такое "единица трансляции". У вас же важно не в каком бинарном объектном файле окажется, а где оно будет на этапе "единицы трансляции" еще написано.
Обычно всем и транскрипция с unit понятна.

[ПростоНуб]

NStorm, у меня на этапе трансляции компилятор выделит память в объектном файле, сформированном из того исходного файла, в котором объявлен _MAIN_C_. С точки зрения программиста, действительно ли это исходный файл с функцией main() или какой-то иной - значения не имеет. После работы компоновщика это все равно станет неразличимым.
Сам я пишу #define _MAIN_C_ действительно в головном исходном файле. Просто чтобы не забыть объявить _MAIN_C_ в одном из файлов проекта.

[NStorm]

ПростоНуб, это да, я с этим и не спорил. ) Это для ARV писал, что речь об "объекнике" была, а не header'е. Потом перечитал свой пост, понял что возможно не очень ясно выразился и дополнил его.

Кстати (это уже о другом), ведь в чисто C (без плюсов) есть tentative definition и ваша конструкция для extern необязательна из примера в общем-то. Но имеет смысл.

[VladislavS]

[uquote="arkhnchul",url="/forum/viewtopic.php?p=3705989#p3705989"]а термина для этого нет. "Такое" это как раз использование всех своих объектов в любом наугад выбранном месте вместо организации четкой иерархии отдельных самостоятельных блоков и "клея" между ними.[/uquote]То есть, это чисто ваше IMHO? Ну тогда вопрос переходит в плоскость "чьё кунг-фу сильнее". Язык программирования и мой опыт позволяет писать абсолютно не конфликтующий между собой код. Это мой осознанный выбор. И пока не будет ссылки на более менее авторитетное исследование говорящее о вреде такого подхода, все это бла-бла-бла.

Более того, существует приём сборки проекта, когда все исходники собирают в одну большею кучу, которую скармливают компилятору. Так достигается максимальная оптимизация. Этим пользуются достаточно серьёзные проекты, поищите.

[ПростоНуб]

NStorm, если честно, не понял Вашу мысль. Если не формировать extern при включении этого заголовочного файла в остальные исходные тексты проекта, то компилятор выделит память под эту переменную в каждом объектном файле. И компоновщик отругается на дублирование имени внешней ссылки. А если в остальных файлах декларировать эту переменную, как extern (tentative definition), то сразу теряется смысл идеи - описывать переменную одной строкой один раз в одном месте. То бишь, то что я использую - просто мелкое удобство для ленивого программиста. Если вдруг эта переменная должна будет стать не uint8_t, а uint16_t, то править я это буду в одном месте и один раз )

Добавлено after 10 minutes 55 seconds:
[uquote="VladislavS",url="/forum/viewtopic.php?p=3706045#p3706045"]Более того, существует приём сборки проекта, когда все исходники собирают в одну большею кучу, которую скармливают компилятору. Так достигается максимальная оптимизация. Этим пользуются достаточно серьёзные проекты, поищите.[/uquote]
Не понимаю, как сочетать компиляцию всех исходников при сборке и серьёзный проект. Они что ли переходят от ежедневных ночных сборок к еженедельным? Если серьёзный проект надо пересобрать полностью, то это всяко на выходные процесс, ну никак не на ночь, даже с distcc. Не поделитесь ссылкой на то, что Вы имеете ввиду? Какого рода оптимизации от компилятора пытаются добиться таким путём?

[Reflector]

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3706049#p3706049"]Не поделитесь ссылкой на то, что Вы имеете ввиду? Какого рода оптимизации от компилятора пытаются добиться таким путём?[/uquote]
Один из примеров - это sqlite:

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

All of the individual C source code and header files (both manually-edited and automatically-generated) can be combined into a single big source file sqlite3.c called "the amalgamation". The amalgamation is the recommended way of using SQLite in a larger application. Combining all individual source code files into a single big source code file allows the C compiler to perform more cross-procedure analysis and generate better code. SQLite runs about 5% faster when compiled from the amalgamation versus when compiled from individual source files.

[ARV]

Вы inline функции в заголовочных файлах не реализуете?

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

А вашу личную выдумку где смотреть каждый раз новому человеку?

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

а не хидер

когда я говорил "хидер", меня поправляли "хЭдер". поэтому я использую свой "термин" - заголовочный файл или заголовок. насколько я помню, заголовочный файл - это тоже устоявшийся термин и не надо коверкать язык "хихэдером"

А X-Macro принципиально не пользуетесь?

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

Потом перечитал свой пост, понял что возможно не очень ясно выразился и дополнил его.

вот именно об этом я и говорил - самого первого переводчика стандарта Си никто не поправил, а сам он не стал лишний раз перечитывать, и вот... имеем то, что имеем

существует приём сборки проекта, когда все исходники собирают в одну большею кучу, которую скармливают компилятору. Так достигается максимальная оптимизация

дык вроде как LTO придумана именно для того, чтобы от этого отказаться... или я не прав?

если честно, не понял Вашу мысль

я тоже вашу, если честно отсылки "я писал ранее" плохо понтны, т.к. вы писали ранее слишком много, и рыться в анналах темы не интересно, и что вы там имели ввиду, остается не ясным. если в хихедере РЕАЛИЗОВАНО что-то, оно в неизменном виде попадет "во все модули трансляции", где этот хихедер использовался, что в итоге ОБЯЗАТЕЛЬНО НЕ ПОНРАВИТСЯ линкеру. как мне ранее показали, в С++ это не так, но я говорю только про Си.

Добавлено after 3 minutes 30 seconds:
кстати, господа-профессионалы, открою вам страшную тайну: самое полезное, что я почерпнул из форумов (к сожалению, не этого), это использование !! для получения гарантированного булева значения выражения все остальное, что вы пытаетесь донести до меня (любителя) лично меня не привлекает ни капли.

[arkhnchul]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3706045#p3706045"]пока не будет ссылки на более менее авторитетное исследование говорящее о вреде такого подхода, все это бла-бла-бла[/uquote]вам нужна ссылка на авторитетное мнение по поводу того, зачем вообще придумали всякие единицы трансляции, подключаемые библиотеки, классы там какие-то с методами, вместо того, чтобы просто вызывать глобально определенные функции для манипуляций над глобально определенными переменными? На кого-нибудь, кто исследовал общеинженерный/познавательный подход "подели сложную систему на отделенные друг от друга простые части"?
не, не дам. Буду гордо нести звание пизбалабола.
[uquote="VladislavS",url="/forum/viewtopic.php?p=3706045#p3706045"]существует приём сборки проекта, когда все исходники собирают в одну большею кучу, которую скармливают компилятору. Так достигается максимальная оптимизация. Этим пользуются достаточно серьёзные проекты, поищите.[/uquote]да, я в курсе.

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3706049#p3706049"]Не понимаю, как сочетать компиляцию всех исходников при сборке и серьёзный проект[/uquote]уходят от этапа компоновки на этапе сборки и, иногда, динамической компоновки в дальнейшем, получая монолитный объектник. Это на самом деле быстрее, чем компилять кучу мелких объектников и потом собирать их в кучу. Не обязательно пересобирать вообще абсолютно все на каждый чих - только тот набор исходников, из которого получается какой-нибудь из крупных объектников проекта.

[NStorm]

[uquote="ARV",url="/forum/viewtopic.php?p=3706067#p3706067"]видите ли в чем дело: мою терминологию поймет даже непрограммист, если он владеет русским языком, и при этом ему не потребуется рыться в гугле или вики. терминология же, требующая даже от специаста уточнений - плохая терминология.[/uquote]
"Непрограммист" не будет знать в чем разница. Язык C пока как бы не стал разговорным, чтобы на нём интуитивно писать. А программист не поймет, потому что знает другие определения. Я вот вас бы без вашего же описания не понял бы.

[uquote="ARV",url="/forum/viewtopic.php?p=3706067#p3706067"]вот именно об этом я и говорил - самого первого переводчика стандарта Си никто не поправил, а сам он не стал лишний раз перечитывать, и вот... имеем то, что имеем [/uquote]
На английском тоже очень знаете ли похоже и "мутно" звучит. И тоже многие путаются. Тем не менее в английском закреплены данные слова в стандарте. Вам их, равно как и уже устоявшийся перевод на русский, уже всё-равно не изменить на весь мир. Уж лучше смириться и использовать принятые стандартом термины. Иначе будете говорить на разных языках.

[VladislavS]

arkhnchul, ну вот смотри. В классическом С подход "раздёляй и властвуй" был единственно возможным. Прячешь реализацию в единице компиляции, выставляя наружу только интерфейс через extern и прототипы функций. Ну тут никуда не денешься, сиди и руками все "клей". Потом появился С++ с ООП, первым постулатом которого была инкапсуляция. Мы уже могли в класс прятать данные и методы и даже делать их private, чтобы уж точно никто их случайно потрогать не мог. Но всё равно, этого оказалось мало, глобальная область осталась так же не защищена. И тогда появляется namespace, под которую мы можем прятать всё что не должно быть просто так доступно во избежании конфликтов. Но если такая необходимость появляется, то доступ возможен. И примеров когда это удобно и совершенно безопасно можно привести множество.

[ПростоНуб]

[uquote="Reflector",url="/forum/viewtopic.php?p=3706065#p3706065"]Один из примеров - это sqlite[/uquote]
Такое ощущение, что он и единственный. Кроме него только мелочевку какую-то нашел.
И совершенно не понятно, как это слияние может повлиять на скорость выполнения? Ну размер еще компилятор может уменьшить, найдя дуплицирующийся код, если таковой имеется. Но скорость то как?

VladislavS, Вы бы попробовали скомпилировать, например, тот же GCC сам собой. Тогда бы прочуствовали соотношение по времени между компиляцией и компоновкой. Я то его сборку наблюдал многократно.

[arkhnchul]

VladislavS, мы, кажца, про разные вещи спорим. Когда все делают доступным везде, то обычно этим таки пользуются - зачем иначе городить огороды? - и тут блин начинается. Драйвер вывода на индикатор пинает термометры, потому что почему бы и нет, "ну он же только их показания выводит"(с). Функции подсчета CRC сами молча дописывают результат в конец буфера, "так она ж исключительно здесь используется, чего париться". Методы класса игнорируют собственные поля, ненуачо, "конфигурация же глобальная, какой идиот передаст что-то другое в конструктор". Такое вот все. Хочется полюбоваться вблизи на авторов сих идей и пожать их крепкие мужественные шеи.

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3706091#p3706091"]И совершенно не понятно, как это слияние может повлиять на скорость выполнения?[/uquote]компилятор обычно будет поумнее, чем программист линкер. Да навскидку даже тупо инлайнить мелкие функции, которые иначе были бы в другом объектнике и вызывались как положено, с толком и расстановкой - уже хлеб.
[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3706091#p3706091"]Вы бы попробовали скомпилировать, например, тот же GCC сам собой. Тогда бы прочуствовали соотношение по времени между компиляцией и компоновкой.[/uquote]сия метОда была придумана задолго до SSD и гигабайт оберативы под кэши) компоновка мелочни, равно как и запись временных файлов после препроцессора (не все умели обходиться без них) - интенсивные дисковые операции.

[VladislavS]

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3706091#p3706091"]VladislavS, Вы бы попробовали скомпилировать, например, тот же GCC сам собой. Тогда бы прочуствовали соотношение по времени между компиляцией и компоновкой. Я то его сборку наблюдал многократно.[/uquote]Ну GCC я сам не собирал, а ядро Linux собирал. Но мы же об микроконтроллерах всё же говорим. Много раз вы GCC на микроконтроллере запускали?

[uquote="arkhnchul",url="/forum/viewtopic.php?p=3706115#p3706115"]VladislavS, мы, кажца, про разные вещи спорим.[/uquote]Не знаю, я писал про один мегазаголовочный файл main.h в котором все остальные заголовочные файлы подключены. Зачем мне было приписывать беспорядочные половые межфайловые связи не понимаю.

Я про "сию метОду" (слияние исходников в один файл) слышал в одном из докладов на "C++ User Group". Там, правда, докладчик сознался, что прирост в производительности не стоит того геммора, который этот процесс на большом проекте порождает. И в конечном итоге они отказались от него.

[arkhnchul]

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

[VladislavS]

Хорошо, привожу пример. Есть у меня библиотека GPIO для ногодрыга. Согласись, дернуть ногой может абсолютно любой класс где угодно и когда угодно. Считаю разумным, что мне эта библиотека доступна в любой части программы посредством подключения через main.h. А не надо дёргать, ну и пусть она себе за namespace лежит нетронутой, кому от этого хуже.