Войти
ПрограммированиеФорумОбщее

Движок на Си (2 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 418 Следующая »
#15
(Правка: 8:54) 8:51, 7 июня 2019

u960
> Вы имеете ввиду с помощью префиксов обозначать их модульность типа: SV_***** -
> серверные функции, CL_**** - клиента, RD_**** - рендер и так далее?
Почти так. Учитывай только, что двух букв будет недостаточно, имена зачастую длиной 30-40 символов. Слава богу, линкеры давно уже поддерживают имена длиннее 6-8 символов, а когда не поддерживали, приходилось выкручиваться с препроцессором.

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


#16
(Правка: 9:36) 9:29, 7 июня 2019

Zab
> Учитывай только, что двух букв будет недостаточно, имена зачастую длиной 30-40
> символов.
Ты там книгу на Си пишешь что ли? Чисто из интереса, можно посмотреть хотя бы на кусочек кода?

mr.DIMAS
> Автоматическое управление ресурсами
А можно об этом пункте по-подробнее?

#17
9:47, 7 июня 2019

Vlad2001_MFS
> Ты там книгу на Си пишешь что ли? Чисто из интереса, можно посмотреть хотя бы на кусочек кода?
Извини, код времен более чем двадцатилетней давности я скорее всего не найду уже. Даже если я его заархивировал и куда-то положил, те носители наверняка уже сдохли, дискеты столько не живут. Но если и выжили они,  где сейчас прочитать пятидюймовый диск?

Оперировать длинными именами удобнее, чем каждый раз вспоминать какая аббревиатура что значит. Само собой, постоянно используемые средства получают короткие префиксы. Используемое же лишь иногда удобнее снабдить именем, которое само себе комментарий. Длинные имена получаются даже на C++, а без плюсов к этому еще и несколько уровней префиксов добавляется.

Если хочешь посмотреть пример не моего подобного кода, ищи в open source исходники firebird, к примеру. Это и есть тот открытый вариант интербейза, с которым я когда то вполне успешно работал изнутри. В open source подобного много, но некачественный код там встречается весьма часто, за interbase я могу поручиться в качестве, потому и советую смотреть именно его.
Но имена там относительно короткие, по моим вкусам. Хотя... смотря что за задачи решаются. Особо длинные имена тянет использовать в усмерть прикладных фрагментах.

#18
10:20, 7 июня 2019

Не всегда есть выбор на чем работать. На чем надо - на том и будем.

#19
10:37, 7 июня 2019

Zab
> где сейчас прочитать пятидюймовый диск?
У меня есть, чем прочитать)

В firebird вроде и не особо длинные имена.

#20
10:42, 7 июня 2019

Всегда эти длинные префиксы в чужом коде бесят. У себя в енумах - одна, две, максимум три буквы - чисто чтоб конфликтов избежать. А смысл понятен по имени, префикс для него не нужен.

#21
10:46, 7 июня 2019

Vlad2001_MFS
> В firebird вроде и не особо длинные имена.
Не особо. Увеличь их мысленно раза в три и получишь примерный вид моего кода.
Еще раз подчеркну, есть разница между библиотеками, становившимися частью твоего языка, и тем, чем желательно не забивать голову. Инструмент проектируешь, осваиваешь, запоминаешь его вдоль и поперек, в нем "особо много болтающие имена" может и вредны. Иное дело, когда ты сделал процедуру чтобы ей 2-3 раза всего воспользоваться. Какой смысл давать ей короткое имя?

#22
(Правка: 10:53) 10:53, 7 июня 2019

Zab
Абсолютно с тобой согласен, но настолько длинные("Увеличь их мысленно раза в три") имена мне еще не приходилось писать.

#23
(Правка: 11:38) 10:54, 7 июня 2019

В некоторых проектах на си без плюсов активно используют статик имена для приватных данных модулей, чтобы не передраться на уровне линкера. На мой взгляд, это очень неудобно. Даже если сейчас модуль маленький и хорошо разместился в одном файле, кто сказал, что он маленьким останется? Работать же с едиными простынями, которые сам себе запретил разбивать на файлы, это изврат, лучше уж сорокасимвольные имена.

Однако, все эти проблемы в C++ решены. Если выбор инструмента не сделан насильно за вас, не вижу причины использовать голый си.

#24
(Правка: 11:40) 11:37, 7 июня 2019

kCMBufferQueueTrigger_WhenDurationBecomesGreaterThanOrEqualToAndBufferCountBecomesGreaterThan = 12;

#25
11:42, 7 июня 2019

entryway
> kCMBufferQueueTrigger_WhenDurationBecomesGreaterThanOrEqualToAndBufferCountBecomesGreaterThan
Всему есть предел...
Даже если хочется писать имена настолько длинные, полезно помнить, что линкеры имеют ограничение. Оно давно уже не 6-8 символов, но все равно есть. Не хочется же нарываться на конфликты возникающие от того, что хвост имени будет проигнорирован и совпадет то, что совпадать не имеет права. И можно считать что сильно повезло, если оно не скомпилируется, хуже если молча наложится.

#26
12:40, 7 июня 2019

а не проще для массива переменных использовать структуру (struct) ?

автор топика решил SDL переписать ?))) Осталось только native код под андроид и прочие огрызки напилить и будет круто.

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

#27
12:51, 7 июня 2019

mr.DIMAS
> - Position-based физика
Что это значит?

Вообще судя по всем это ровно то, что я все начинал писать, но забрасывал, потому что не хватало сахарку из C++ в виде ссылок и неймспейсов.

#28
12:54, 7 июня 2019

Dampire
> Что это значит?
Статья от Suslik'a

#29
0:11, 8 июня 2019

mr.DIMAS
круто!

но Си сложный язык, в том плане что ручной mangling имён и копипаста в отсутствие шаблонов
макросы зло : )

Страницы: 1 2 3 418 Следующая »
ПрограммированиеФорумОбщее