Здравствуйте, maks1180, Вы писали:
M>Я поддерживаю около 4 программ на с++ регулярно и еще олоко 7 редко, они разношёрстные, так как писались без унификации и разными людьми. M>Я решил, что их будет проще поддерживать если они будут в одном стиле и на общем фреймворке. M>Вот уже почти как пол года я пишу свой фреймворк. Дело подошло к концу и сроко начну причёсывать приложения под него. M>Для целочислинных типов я решил дать имена U8/U16/U32/U64 для безнаковых и I* для знаковых. Идея пришла от языка carbon, только там маленькими буквами. M>Мне больше нравить U32 чем uint32_t и код короче.
M>1) стоит ли поменять на маленькие буквы u8/u16/u32/u64 i8/i16/i32/i64 ? M>Мне кажется что глаз будет путать с именами переменных.
M>2) стоит ли поменять на <количество байт> т.е. U1/U2/U4/U8 I1/I2/I4/I8 ? M>удобнее что у всех теперь одинаковая длина, ну и цифры меньше. Но мне кажется, что у новых программистов может возникнуть путаница, особенно U8 можно подумать что это 8 бит, а не 64 бита. M>Как долго нужно будет привыкать к этому ?
M>Спрашиваю, потому-что планирую других программистов привлекать для доработок и удобно должно быть не только мне одному
Лучше маленькими буквами и с битами. u8 .. u64 / i8 .. i64
Проще набирать и капс иногда режет глаз.
Про именование локальных переменных. Я последнее время их именую с v_ (напр v_name)
Свойства структур с m_ (m_name)
Работает на Windows и Unix, планирую ещё и на MacOS.
Работа со строками, форматирование строк (намного быстрее чем sprintf), файлы, объекты синхронизации, управление потоками, обработка исключений, логирование, работа со временем, таймер,
лёгкое шифрование (свой алгоритм), Base64 преобразование, подсчёт MD5, класс для удобной сериализации данных.
Пока всё, но буду дальше добавлять при необходимости. Например работу с сокетами.
Здравствуйте, maks1180, Вы писали:
M>Наоборот же, я посмотрел существующие фреймворки и новые языки программирования, выбрал из них самое лучшее, в том числе и короткие имена типов.
Здравствуйте, maks1180, Вы писали:
M>Работа со строками, форматирование строк (намного быстрее чем sprintf), файлы, объекты синхронизации, управление потоками, обработка исключений, логирование, работа со временем, таймер, M>лёгкое шифрование (свой алгоритм), Base64 преобразование, подсчёт MD5, класс для удобной сериализации данных.
Так это просто набор всяких разных библиотек. На фреймворк мягко говоря не тенет )
Здравствуйте, maks1180, Вы писали:
M>Я поддерживаю около 4 программ на с++ регулярно и еще олоко 7 редко, они разношёрстные, так как писались без унификации и разными людьми. M>Я решил, что их будет проще поддерживать если они будут в одном стиле и на общем фреймворке. M>Вот уже почти как пол года я пишу свой фреймворк. Дело подошло к концу и сроко начну причёсывать приложения под него. M>Для целочислинных типов я решил дать имена U8/U16/U32/U64 для безнаковых и I* для знаковых. Идея пришла от языка carbon, только там маленькими буквами. M>Мне больше нравить U32 чем uint32_t и код короче.
M>1) стоит ли поменять на маленькие буквы u8/u16/u32/u64 i8/i16/i32/i64 ? M>Мне кажется что глаз будет путать с именами переменных.
M>2) стоит ли поменять на <количество байт> т.е. U1/U2/U4/U8 I1/I2/I4/I8 ? M>удобнее что у всех теперь одинаковая длина, ну и цифры меньше. Но мне кажется, что у новых программистов может возникнуть путаница, особенно U8 можно подумать что это 8 бит, а не 64 бита. M>Как долго нужно будет привыкать к этому ?
M>Спрашиваю, потому-что планирую других программистов привлекать для доработок и удобно должно быть не только мне одному
Пока разработчики на современных языках решают задачи бизнеса, си плюс плюсеры создают очередные костыли, новые целочисленные типы, что дальше, заменить оператор сложения на слово PLUS?
Здравствуйте, microuser, Вы писали:
M>Пока разработчики на современных языках решают задачи бизнеса, си плюс плюсеры создают очередные костыли, новые целочисленные типы, что дальше, заменить оператор сложения на слово PLUS?
Неее, дело не в языке. Просто когда ты молод и необуздан, то все вокруг неправы хочется создать универсальный всемогутор.
Думаю, все через это проходили.
Повзрослев, начинаешь ценить своё время и использовать готовые решения. Но иногда оказывается дешевле сколхозить своё, чем адаптировать стандартное.
Какой вариант подходит здесь — не берусь оценить. Скорее всего избыток свободного времени и любовь к искусству
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, maks1180, Вы писали:
M>1) стоит ли поменять на маленькие буквы u8/u16/u32/u64 i8/i16/i32/i64 ? M>2) стоит ли поменять на <количество байт> т.е. U1/U2/U4/U8 I1/I2/I4/I8 ?
Заставь дурака богу молиться -- лоб расшибёт.
Как оно покрашено, и как названо не важно. Важно как внутри устроено.
Но проще, по целому спектру разных причин, придерживаться ISO-стандарта.
M>Работает на Windows и Unix, планирую ещё и на MacOS.
Это хорошо
Дальше вопросы: M>Работа со строками
Unicode из коробки (utf8/u1tf16/utf32, с конвертацией между ними и однобайтными)?
с честным поиском без ложных срабатываний "внутри codepoint" для utf8? PCRE?
работа "как с родными" std::string / std::wstring / std::string_view / std::wstring_view ? вообще аналог string_view существует?
M>форматирование строк (намного быстрее чем sprintf),
Стоп. а по сравнению с fmtlib? или std::format? точно быстрее? нужно ли было изобретать велосипед?
M>файлы, объекты синхронизации, управление потоками,
std::thread, std::filesystem чем не подходят? по второй либе в случае macos есть вопросы (при необходимости поддержки старых версий оси), но тогда проще взять boost::filesystem
M>логирование,
Куча готовых либ для ведения логов, под любые задачи. Синхронные, асинхронные, с соблюдениям порядка между потоками и только внутри потока и т.д.
С форматированием внутри hot-path и в отдельном потоке. Вплоть до бианрных логов отправляемых по сети на сервер логирования/телеметрии.
Почему не подошла ни одан существующая реализация?
M>лёгкое шифрование (свой алгоритм),
Почему не взять любой из стандартных через openssl например? Кто проверял криптоустойчивать алгоритма?
M>Base64 преобразование, подсчёт MD5,
Зачем изобретать велосипед? Чем не подходят готовые реализации? (Довод "они чужие, а не мои" -- это довод в ИХ пользу, а не самописного велосипеда)
У меня как-то вылезала проблема, где не получилось использовать boost::interprocess и пришлось пилить велосипед (автор либы отказался даже расматривать мой случай -- когда на одном компе запущены процессы с разным endiannes)
Но как только ситуация перестала быть актуальной, я с радостью выкинул велосипед и взял готовую реализацию.
M>>Работает на Windows и Unix, планирую ещё и на MacOS. K13>Это хорошо
K13>Но как только ситуация перестала быть актуальной, я с радостью выкинул велосипед и взял готовую реализацию.
В моём случаи важен был размер exe, стандартные либы сильно увеличивают его размер.
Так же софт был написан на VS 6.0, я пересобрал его на gcc но размер exe сильно увеличился — это НЕ понравилось. Почему он увеличился я сразу не смог понять и сейчас есть только предположение что библиотека libstd++ (в которой реализации обработки исключений) сильно увеличивает размер exe.
Здравствуйте, maks1180, Вы писали:
M>Так я уже написал фреймворк с именами типов U*/I*. Вы предлагаете поменять на стандартные или потратить это время на увеличения функциональности ?
Что-то вспоминается хрестоматийный анекдот про то, как вскипятить чайник... И желание всё свести к предыдущей задаче.
Здравствуйте, maks1180, Вы писали:
W>>Короче говоря: хотите, чтоб люди пользовались, делайте как общепринято, а не как вы считаете нужным. M>Не соглашусь. QT по своему называют, например quint32 и люди пользуются — не плюются от этого.
Тебе уже написали откуда это всё взялось, на новом Qt6 они наоборот расширили интерфейсы чтобы работать со стандартными контейнерами и типами, а QMap, qint остались для совместимости.
Здравствуйте, maks1180, Вы писали:
M>uint32_t — не удобно. Создатели современного языка carbon тоже так же посчитали.
И чем они это мотивировали, надеюсь как растоманы, не так как в С++?
Здравствуйте, maks1180, Вы писали:
AD>>А что твой фреймворк делает?
M>Работает на Windows и Unix, планирую ещё и на MacOS.
M>Работа со строками, форматирование строк (намного быстрее чем sprintf), файлы, объекты синхронизации, управление потоками, обработка исключений, логирование, работа со временем, таймер, M>лёгкое шифрование (свой алгоритм), Base64 преобразование, подсчёт MD5, класс для удобной сериализации данных.
M>Пока всё, но буду дальше добавлять при необходимости. Например работу с сокетами.
«Я нашел, как применить здесь нестирающиеся шины из полиструктурного волокна с вырожденными аминными связями и неполными кислородными группами. Но я не знаю пока, как использовать регенерирующий реактор на субтепловых нейтронах. Миша, Мишок! Как быть с реактором?» Присмотревшись к устройству, я без труда узнал велосипед. ПНВС, АБС
Там в паралельной ветке тебе написали что всё это уже существует.
Здравствуйте, maks1180, Вы писали:
M>Зачем фреймворк QT ипользует свои имена для типов данных qint8, quint8, qint16, quint16 и так далее. M>Почему они не используют стандартные имена ? quint16 ведь не намного короче uint16_t.
Потому, что Qt появился раньше, чем #include <stdint.h>
Здравствуйте, maks1180, Вы писали:
M>Я поддерживаю около 4 программ на с++ регулярно и еще олоко 7 редко, они разношёрстные, так как писались без унификации и разными людьми. M>Я решил, что их будет проще поддерживать если они будут в одном стиле и на общем фреймворке. M>Вот уже почти как пол года я пишу свой фреймворк. Дело подошло к концу и сроко начну причёсывать приложения под него.
Самый лучший вариант — постепенно рефакторить один из проектов, выращивая фремворк. Далее постепенно переводим все проекты на эту вещь.
То есть, итерационно, вырастили фичу X, перетащили её на все остальные проекты.
Просто так, без опоры в виде хорошего фидбека крайне трудно вырастить жизнеспособный фремворк.
M>Для целочислинных типов я решил дать имена U8/U16/U32/U64 для безнаковых и I* для знаковых. Идея пришла от языка carbon, только там маленькими буквами. M>Мне больше нравить U32 чем uint32_t и код короче. M>1) стоит ли поменять на маленькие буквы u8/u16/u32/u64 i8/i16/i32/i64 ? M>2) стоит ли поменять на <количество байт> т.е. U1/U2/U4/U8 I1/I2/I4/I8 ?
Не стоит,
1 т.к. ты не можешь сформулировать проблему, которую ты этим решаешь. Брать фичи из других яп/фремворков идея сильно так себе.
2 чем меньше ты добавляешь во фремворк, тем проще будет другим девелоперам
При этом стоит релизнуть фремворк как можно раньше, и наладить процесс деливери новых фич, когда ты будешь развивать фремворк, а остальные — потиху переходить на новые версии.
Здравствуйте, maks1180, Вы писали: M>Для целочислинных типов я решил дать имена U8/U16/U32/U64 для безнаковых и I* для знаковых.
Добавлю еще такое соображение против.
Имена состоящие только из заглавных букв и цифр имеют не иллюзорный шанс совпасть с каким-нибудь макросом.
Обычно макросы именно так именуют, иногда даже короткие имена встречаются.
При подключении какой-нибудь новой библиотеки или SDK твой код может перестать компилироваться (что еще так себе),
а хуже если тихо логика поменяется.
В моей практике был такой случай. Программист сделал enum с именами LEFT, RIGHT, UP, DOWN без указания значений.
Потом разбирались с непонятным глюком в поведении софтины. Компилировался проект без ошибки.
Оказалось, что где-то в хидерах чужой библиотеки был #define UP <что-то равное 1>.
Итого получается, что RIGHT == UP == 1.
Сейчас идешки хорошо подсвечивают макросы (тот случай был во времена VS6).
Но все равно патовая ситуация возникнет, если в нужной сторонней библиотеке определен макрос U32,
а у тебя эта U32 в 100500 местах по собственному коду.
Здравствуйте, qaz77, Вы писали:
M>>Для целочислинных типов я решил дать имена U8/U16/U32/U64 для безнаковых и I* для знаковых. Q>Но все равно патовая ситуация возникнет, если в нужной сторонней библиотеке определен макрос U32, Q>а у тебя эта U32 в 100500 местах по собственному коду.
Здравствуйте, maks1180, Вы писали:
M>Да, но они тоже самое имеют ввиду под u8/u16/u32/i8/i16/i32, значит проблем с ними не будет ?
Это только если повезёт.
Если нет, то приходится править исходники и/или писать авторам и/или ещё как-то извращаться.
При этом надо молиться, чтобы нигде не нарваться на нарушение ODR.
За последний месяц меня 4 раза звали искать ошибку в чужом коде (я работаю консультантом). Так вот: дважды это было нарушение ODR при подключении новых библиотек; в первом случае пересечение по имени структуры (две разные структуры в двух разных библиотеках с совпадающими именами), во втором — совпадение по имени define с разными значениями для размера массива внутри структуры. Этот define был определён в двух разных файлах, каждый из которых подключался для двух разных статических библиотек, которые использовали общую третью библиотеку (в которой и определена структура). И вот, смотришь на код — код абсолютно корректный и довольно простой, а падает с разрушением стека. Приложение многопоточное, думаю — кто-то проехался по памяти из другой нитки, ставлю sleep, вижу, что падает в том же месте, значит дело в другом. Удаляю sleep, делаю простое обращение к массиву структуры всё падает с разрушением стека.... Короче, только через час нашёл, что define с одним и тем же именем в двух разных файлах, причём один из них даже в проект не включён, а просто на путях лежал...
А тут вы с короткими именами без namespace.
Ну что-ж.
Удачи вам в отладке.
