Я поддерживаю около 4 программ на с++ регулярно и еще олоко 7 редко, они разношёрстные, так как писались без унификации и разными людьми.
Я решил, что их будет проще поддерживать если они будут в одном стиле и на общем фреймворке.
Вот уже почти как пол года я пишу свой фреймворк. Дело подошло к концу и сроко начну причёсывать приложения под него.
Для целочислинных типов я решил дать имена U8/U16/U32/U64 для безнаковых и I* для знаковых. Идея пришла от языка carbon, только там маленькими буквами.
Мне больше нравить U32 чем uint32_t и код короче.

1) стоит ли поменять на маленькие буквы u8/u16/u32/u64 i8/i16/i32/i64 ?
Мне кажется что глаз будет путать с именами переменных.

2) стоит ли поменять на <количество байт> т.е. U1/U2/U4/U8 I1/I2/I4/I8 ?
удобнее что у всех теперь одинаковая длина, ну и цифры меньше. Но мне кажется, что у новых программистов может возникнуть путаница, особенно U8 можно подумать что это 8 бит, а не 64 бита.
Как долго нужно будет привыкать к этому ?

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

Здравствуйте, maks1180, Вы писали:

M>1) стоит ли поменять на маленькие буквы u8/u16/u32/u64 i8/i16/i32/i64 ?

M>Спрашиваю, потому-что планирую других программистов привлекать для доработок и удобно должно быть не только мне одному

А почему стандартные не используешь??? 111

https://en.cppreference.com/w/cpp/types/integer

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

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

Можешь конкретно I8/U8 переименовать в I9/U9. Чтобы твои программисты не выходили из состояния изумления. По крайней мере не перепутают.

Здравствуйте, maks1180, Вы писали:

M>Мне больше нравить U32 чем uint32_t и код короче.
Если этот код больше никто не будет модифицировать и использовать, то пофигу. Твой код — твои страдания .

M>1) стоит ли поменять на маленькие буквы u8/u16/u32/u64 i8/i16/i32/i64 ?
Это может перекрываться строковыми литералами, например, operator""u8. Лучше бери стандартные типы С++17 и не выдумывай.

Здравствуйте, maks1180, Вы писали:

M>Мне больше нравить U32 чем uint32_t и код короче.
M>Спрашиваю, потому-что планирую других программистов привлекать для доработок и удобно должно быть не только мне одному


Если планируете других программистов привлекать, то в чем смысл вопроса?
Одна из причин наличия стандартной библиотеки C/C++ (описание которой является частью стандарта С/С++),
как раз является попытка упростить "вливание" новых программистов в проект.

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

M>>1) стоит ли поменять на маленькие буквы u8/u16/u32/u64 i8/i16/i32/i64 ?
K>Это может перекрываться строковыми литералами, например, operator""u8. Лучше бери стандартные типы С++17 и не выдумывай.

Про u8"" забыл, но всё равно такой код компилируется нормально
auto s1 = u8"hello"; u8 h = 9;

uint32_t — не удобно. Создатели современного языка carbon тоже так же посчитали.

Z>Если планируете других программистов привлекать, то в чем смысл вопроса?

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

Z>Одна из причин наличия стандартной библиотеки C/C++ (описание которой является частью стандарта С/С++),
Z>как раз является попытка упростить "вливание" новых программистов в проект.

C/C++ — развивается с учётом совместимости со старыми версиями и это накладывает значительные ограничения.
Новые языки такого не имеют и поэтому используют более удобные имена.
По мне так намного удобнее и быстрее писать u64 чем uint64_t.
Мой фреймворк не расчитан на глобальное использование, поэтому я могу использовать преимущество более коротких имён.

Зачем фреймворк QT ипользует свои имена для типов данных qint8, quint8, qint16, quint16 и так далее.
Почему они не используют стандартные имена ? quint16 ведь не намного короче uint16_t.

Здравствуйте, maks1180, Вы писали:

M>Для целочислинных типов я решил дать имена U8/U16/U32/U64 для безнаковых и I* для знаковых. Идея пришла от языка carbon, только там маленькими буквами.
M>Мне больше нравить U32 чем uint32_t и код короче.

Т.е. я правильно понимаю, что в целом фреймворке не нашлось проблемы серьезнее для выноса на форум, чем именование целочисленных типов?
Ладно, допустим.
Но лично я никогда не понимал тягу некоторых людей выворачивать стилистику по-своему, чтобы вот прямо как-то вот так вот!

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

W>Т.е. я правильно понимаю, что в целом фреймворке не нашлось проблемы серьезнее для выноса на форум, чем именование целочисленных типов?
W>Ладно, допустим.

Нашлось, их задавал в других топиках.

Здравствуйте, maks1180, Вы писали:

M>Зачем фреймворк QT ипользует свои имена для типов данных qint8, quint8, qint16, quint16 и так далее.
M>Почему они не используют стандартные имена ? quint16 ведь не намного короче uint16_t.

У Qt богатая история и эти имена в нем появились даже раньше первой стандартизации С++.
А дальше они (разработчики) просто сохраняют преемственность где это возможно.
У вас же совсем другая ситуация, при наличии всех современных подходов и инструментов, вы сознательно плодите сущности, повышая порог вхождения в вашу разработку.

W>Короче говоря: хотите, чтоб люди пользовались, делайте как общепринято, а не как вы считаете нужным.
Не соглашусь. QT по своему называют, например quint32 и люди пользуются — не плюются от этого.

W>Лучше выражайте свой творческий потенциал, ваши идеи и мысли в функциональности фрейморка — фреймворки для этого и пишут, для функциональности.
Имена не влияют на функциональность.

bnk>В смысле, ты сам не следуешь стандарту, но при этом хочешь заставить других следовать твоему стандарту?

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

Здравствуйте, maks1180, Вы писали:

W>>Короче говоря: хотите, чтоб люди пользовались, делайте как общепринято, а не как вы считаете нужным.
M>Не соглашусь.
Ваше право. Но если вы пришли на форум за советом — я вам его даю:

W>>QT по своему называют, например quint32 и люди пользуются — не плюются от этого.
Ответил про это в соседней ветке.

W>>Лучше выражайте свой творческий потенциал, ваши идеи и мысли в функциональности фрейморка — фреймворки для этого и пишут, для функциональности.
M>Имена не влияют на функциональность.
Даже не знаю что на это ответить. Я где-то писал, что имена влияют на функциональность?
Я понимаю, что никому не нравится когда его критикуют, но именно это дает возможность стать лучше.
Я писал о том, что лучше и полезнее сосредоточить ваши усилия на функциональности, а не на том, что уже давно устаканилось.

W>>>Лучше выражайте свой творческий потенциал, ваши идеи и мысли в функциональности фрейморка — фреймворки для этого и пишут, для функциональности.
M>>Имена не влияют на функциональность.
W>Даже не знаю что на это ответить. Я где-то писал, что имена влияют на функциональность?
W>Я понимаю, что никому не нравится когда его критикуют, но именно это дает возможность стать лучше.
W>Я писал о том, что лучше и полезнее сосредоточить ваши усилия на функциональности, а не на том, что уже давно устаканилось.

Так я уже написал фреймворк с именами типов U*/I*. Вы предлагаете поменять на стандартные или потратить это время на увеличения функциональности ?

Здравствуйте, maks1180, Вы писали:

M>Так я уже написал фреймворк с именами типов U*/I*. Вы предлагаете поменять на стандартные или потратить это время на увеличения функциональности ?
Единственное, что я предлагаю — это системно подойти к вопросу. Подумать о том, о чем вы судя по всему не думали, или думали, но только с одной стороны. Это не только имен типов касается, а всех подобных вопросов (которые не влияют на функциональность).
Что делать с уже совершенными ошибками, считать ли их вообще ошибками или нет — это ваше дело. Однако не стоит удивляться, что исправление ошибок займет дополнительное от запланированного время, это нормально. И лучше бы это сделать до того, как вашим творчеством начнут пользоваться другие люди. Иначе уже вам придется сохранять преемственность и оставлять даже неудачные решения на долгие годы вперед.

Здравствуйте, maks1180, Вы писали:

M>фреймворк QT

QT -- это QuickTime. То, о чём вы пишете, называется Qt.

А что твой фреймворк делает?

M>>Так я уже написал фреймворк с именами типов U*/I*. Вы предлагаете поменять на стандартные или потратить это время на увеличения функциональности ?
W>Единственное, что я предлагаю — это системно подойти к вопросу. Подумать о том, о чем вы судя по всему не думали, или думали, но только с одной стороны. Это не только имен типов касается, а всех подобных вопросов (которые не влияют на функциональность).

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

SD>Классика же, разобраться в том, что другие написали, куда сложнее, чем самому колесо изобрести.

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

Поэтому свой велосипед я делаю из лучших запчастей от других велосипедов...