Я поддерживаю около 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>Классика же, разобраться в том, что другие написали, куда сложнее, чем самому колесо изобрести.

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

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

Здравствуйте, 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)

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

Работает на 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?

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

Какой вариант подходит здесь — не берусь оценить. Скорее всего избыток свободного времени и любовь к искусству

Здравствуйте, 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>Мне больше нравить U32 чем uint32_t и код короче.

uint32_t хорош тем, что это стандартный тип, не вызывающий никаких вопросов у программистов.

Здравствуйте, 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 местах по собственному коду.

Такие "библиотеки" встречаются часто:
https://github.com/Ai-Thinker-Open/GPRS_C_SDK/blob/master/include/std_inc/cs_types.h
https://docs.fd.io/vpp/18.01/d9/d49/types_8h.html
http://w1.fi/hostapd/devel/common_8h_source.html
https://rextester.com/discussion/SXD43384/bitfields-msvc

BFE>Такие "библиотеки" встречаются часто:

Да, но они тоже самое имеют ввиду под u8/u16/u32/i8/i16/i32, значит проблем с ними не будет ?

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

M>Да, но они тоже самое имеют ввиду под u8/u16/u32/i8/i16/i32, значит проблем с ними не будет ?

Это только если повезёт.
Если нет, то приходится править исходники и/или писать авторам и/или ещё как-то извращаться.
При этом надо молиться, чтобы нигде не нарваться на нарушение ODR.

За последний месяц меня 4 раза звали искать ошибку в чужом коде (я работаю консультантом). Так вот: дважды это было нарушение ODR при подключении новых библиотек; в первом случае пересечение по имени структуры (две разные структуры в двух разных библиотеках с совпадающими именами), во втором — совпадение по имени define с разными значениями для размера массива внутри структуры. Этот define был определён в двух разных файлах, каждый из которых подключался для двух разных статических библиотек, которые использовали общую третью библиотеку (в которой и определена структура). И вот, смотришь на код — код абсолютно корректный и довольно простой, а падает с разрушением стека. Приложение многопоточное, думаю — кто-то проехался по памяти из другой нитки, ставлю sleep, вижу, что падает в том же месте, значит дело в другом. Удаляю sleep, делаю простое обращение к массиву структуры всё падает с разрушением стека.... Короче, только через час нашёл, что define с одним и тем же именем в двух разных файлах, причём один из них даже в проект не включён, а просто на путях лежал...

А тут вы с короткими именами без namespace.
Ну что-ж.
Удачи вам в отладке.

BFE>За последний месяц меня 4 раза звали искать ошибку в чужом коде (я работаю консультантом). Так вот: дважды это было нарушение ODR при подключении новых библиотек; в первом случае пересечение по имени структуры (две разные структуры в двух разных библиотеках с совпадающими именами), во втором — совпадение по имени define с разными значениями для размера массива внутри структуры.

Разве компилятор не ругается когда встречает отпределение структуры которая уже определена ? То же самое и с define должно быть.

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

M>Разве компилятор не ругается когда встречает определение структуры которая уже определена ? То же самое и с define должно быть.

Обычно, нарушение ODR бывает, когда в разных единицах трансляции одноименные вещи чем-то отличаются.
Потом линковщик выбирает одну из реализаций и для объектников, которым не повезло, используется несоответствующее определение.
Например, структура или массив не того размера.

С т.з. компилятора для каждой единицы трансляции видно одно определение и это не ошибка.

Также и макросами, для них более того и переопределение не запрещено.
Если перед переопределением делать #undef, то и предупреждения не будет.

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

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

В пятом Qt по-моему любой класс можно использовать вместо STL класса. Это вроде ещё с 4ой версии началось, но не уверен. В Qt5 я вот только одного не пойму — QString практически полностью совместим по интерфейсу с std::striing, но, сцуко, у QString нет метода empty(), только isEmpty(). Повбывав бы

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

M>Разве компилятор не ругается когда встречает отпределение структуры которая уже определена ? То же самое и с define должно быть.

Ругается, но если два файла .cpp скомпилированы с разными заголовками, т.е. подключают разные .h, то совпадение по именам в этих .h файлах приводят к тому, что в .obj (.o, .lib) будут лежать определения с одинаковыми именами, но разными значениями/определениями. Компоновщик при линковке выбирает только одно значение/определение, а второе отбрасывает, что приводит к UB, которое иногда приводит к краху при исполнении.