Я поддерживаю около 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>Спрашиваю, потому-что планирую других программистов привлекать для доработок и удобно должно быть не только мне одному
Здравствуйте, 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>Лучше выражайте свой творческий потенциал, ваши идеи и мысли в функциональности фрейморка — фреймворки для этого и пишут, для функциональности.
Имена не влияют на функциональность.
Здравствуйте, maks1180, Вы писали:
W>>Короче говоря: хотите, чтоб люди пользовались, делайте как общепринято, а не как вы считаете нужным. M>Не соглашусь.
Ваше право. Но если вы пришли на форум за советом — я вам его даю:
W>>QT по своему называют, например quint32 и люди пользуются — не плюются от этого.
Ответил про это в соседней ветке.
W>>Лучше выражайте свой творческий потенциал, ваши идеи и мысли в функциональности фрейморка — фреймворки для этого и пишут, для функциональности. M>Имена не влияют на функциональность.
Даже не знаю что на это ответить. Я где-то писал, что имена влияют на функциональность?
Я понимаю, что никому не нравится когда его критикуют, но именно это дает возможность стать лучше.
Я писал о том, что лучше и полезнее сосредоточить ваши усилия на функциональности, а не на том, что уже давно устаканилось.
W>>>Лучше выражайте свой творческий потенциал, ваши идеи и мысли в функциональности фрейморка — фреймворки для этого и пишут, для функциональности. M>>Имена не влияют на функциональность. W>Даже не знаю что на это ответить. Я где-то писал, что имена влияют на функциональность? W>Я понимаю, что никому не нравится когда его критикуют, но именно это дает возможность стать лучше. W>Я писал о том, что лучше и полезнее сосредоточить ваши усилия на функциональности, а не на том, что уже давно устаканилось.
Так я уже написал фреймворк с именами типов U*/I*. Вы предлагаете поменять на стандартные или потратить это время на увеличения функциональности ?
Здравствуйте, maks1180, Вы писали:
M>Так я уже написал фреймворк с именами типов U*/I*. Вы предлагаете поменять на стандартные или потратить это время на увеличения функциональности ?
Единственное, что я предлагаю — это системно подойти к вопросу. Подумать о том, о чем вы судя по всему не думали, или думали, но только с одной стороны. Это не только имен типов касается, а всех подобных вопросов (которые не влияют на функциональность).
Что делать с уже совершенными ошибками, считать ли их вообще ошибками или нет — это ваше дело. Однако не стоит удивляться, что исправление ошибок займет дополнительное от запланированного время, это нормально. И лучше бы это сделать до того, как вашим творчеством начнут пользоваться другие люди. Иначе уже вам придется сохранять преемственность и оставлять даже неудачные решения на долгие годы вперед.
M>>Так я уже написал фреймворк с именами типов U*/I*. Вы предлагаете поменять на стандартные или потратить это время на увеличения функциональности ? W>Единственное, что я предлагаю — это системно подойти к вопросу. Подумать о том, о чем вы судя по всему не думали, или думали, но только с одной стороны. Это не только имен типов касается, а всех подобных вопросов (которые не влияют на функциональность).
Я как раз системно подошёл, посмотрел существующие фреймвокри и новые языки программирования, выбрал из них самое лучшее, в том числе и короткие имена типов.
Потом появилось сомнение как лучше, и я решил вынести этот вопрос на дискусию.