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

A>А можно это сказать не мне, а товарищу выше? Который утверждает, что в Греции всё есть?
Ты ж читать банально не умеешь.

A>В соответствии с названием, битность его опять же, не определена. Он может быть хоть 20 бит, если такова целевая платформа.
Если тебе надо вмещать 16битные значения — тебе этот тип подходит.
В чём проблема?
Или тебе тут в портки уже насрало железо, которое не имеет именно 16битных регистров?

A>Я уж молчу, что меня хлебом не корми, а дай в коде писать такое замечательное название как std::uint_least8_t.
Открой наконец уже для себя typedef и переименуй его в "Гоша"

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

S>Им дают язык, который намеренно делает простое — сложным, а сложное — чудовищно сложным.
Язык ничего такого не делает, это делают странные люди, которые пытаются долбить стену перфоратором, не включив его в розетку.
Если понимать язык и не пытаться сделать на нём странное — всё работает офигенно хорошо. Я с прошлого века на плюсах пишу и доволен как слон. А этим постоянно "яйца мешают".

S>Грабли разложены именно так, чтобы как можно сильнее бить "средних" специалистов — которым кажется, что они понимают, как работает язык.
А тебе не кажется что если у "шпециалиста" понимания нет но зато есть непокобелимая уверенность в собственных заблуждениях то в этом совсем не язык виноват?

S>UB, из которого язык состоит чуть менее, чем полностью


S>И вот поверх всего этого ужоснаха люди таки ухитряются писать более-менее работоспособные программы.
Что говорит о том, что ты совсем чуть чуть, процентов так на 100500, преувеличил.

S>Это ж нужно шибко мозг вывернуть, чтобы написать корректную арифметику для типа "размером в хрен знает сколько бит, но не меньше 8".
Вообще не вижу проблемы.

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

A>Трудно мне представить, как сидит программист и рассуждает сам с собою: однажды мой код могут перенести на другую платформу, на которой не будет восьмибитного беззнакового целого. Но я точно знаю, что на этой платформе есть смысл оптимизировать память, а не процессор, и поэтому объявлю-ка я массив как std::uint_least8_t. Потому что есть ведь ещё std::uint_fast8_t. Который как std::uint_least8_t, но только компилятор попробует подобрать размер, соответствующий регистру. Хотя и это не гарантируется.

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

A>А наши, земные программисты пишут не на modern C++, а на чём-то более вменяемом. Например, на Qt. Или на WinAPI.
Ты щас смешал в одну кучу язык, фреймворк и API

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

S>

S>var provider: mdx::expression_tree::abstract_cell_provider_uptr = std::make_unique<mdx::expression_tree::cell_providers::distinct>(...);
S>

Вот никогда не понимал смысла везде писать вот эти портянки имён?
Typedef забанен что ли?

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

A>А ядра как писали на Си, так и пишут.
Давно уже там есть плюсы.

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

A>>А ядра как писали на Си, так и пишут.
S>И на C++ писали. CreatorCray не даст соврать.
Я и сейчас пишу.

S>Вы уж определитесь: либо обязательна к использованию, либо нет.
+1

A>>Используй те её части, которые быстры и годятся для использования в ядре.
S>Так это же вы сейчас про C++.
+1

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

A>А вообще, вот тут целый обзор на эту тему: https://softwareengineering.stackexchange.com/questions/316217/why-does-the-type-go-after-the-variable-name-in-modern-programming-languages
Все вокруг "можно опустить тип при инициализации" топчутся

var a : int;
var b = 10;

Но, допустим C#, нисколько не мешает так же отбрасывать тип при инициализации:

int a;
var b = 10;

Еще пишут, что если тип длинный, то сложно определить саму переменную за ним. Как бу-то все без подсветки в нотепаде кодят.

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

FLY>Еще пишут, что если тип длинный, то
... это косяк в дизайне. Если он длинный потому что составной — это тоже косяк, хоть и поменьше
Ну и всегда есть typedef.

FLY> сложно определить саму переменную за ним. Как бу-то все без подсветки в нотепаде кодят.
Да таких если послушать то создаётся ощущение что у них и вовсе ничего кроме ed под рукой нету

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

A>>А наши, земные программисты пишут не на modern C++, а на чём-то более вменяемом. Например, на Qt. Или на WinAPI.
CC>Ты щас смешал в одну кучу язык, фреймворк и API

Да я как тот чел с сортировщиком из Идиократии. Вечно всё смешиваю. Языки и стандартные библиотеки, например.

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

A>>А можно это сказать не мне, а товарищу выше? Который утверждает, что в Греции всё есть?
CC>Ты ж читать банально не умеешь.

Напомнить? В ответ на: "Наличие плавающего размера — это одна из самых уродливых черт С/С++" ты написал: "В С++ ты сам решаешь чем тебе пользоваться".

Из чего следует, что альтернатива плавающему размеру таки есть. Потому что, ну вот решил я воспользоваться типом фиксированной 32-битности, и как мне это сделать, если его там нет?

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

A>>А если бы ты везде юзал тип i32, она бы у тебя не собиралась под разные платформы? Или оптимизацию нельзя было бы прикрутить?

N>Собиралась. При этом компилятор задолбал бы warning'ами, работало бы медленнее и временами падало.

Ворнингами о чём?

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

A>>>А если бы ты везде юзал тип i32, она бы у тебя не собиралась под разные платформы? Или оптимизацию нельзя было бы прикрутить?
N>>Собиралась. При этом компилятор задолбал бы warning'ами, работало бы медленнее и временами падало.
A>Ворнингами о чём?

О несовпадении размерностей типов. В адресной арифметике все целые должны быть иметь вполне определенный размер.

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

A>Трудно мне представить, как сидит программист и рассуждает сам с собою: однажды мой код могут перенести на другую платформу, на которой не будет восьмибитного беззнакового целого. Но я точно знаю, что на этой платформе есть смысл оптимизировать память, а не процессор, и поэтому объявлю-ка я массив как std::uint_least8_t. Потому что есть ведь ещё std::uint_fast8_t. Который как std::uint_least8_t, но только компилятор попробует подобрать размер, соответствующий регистру. Хотя и это не гарантируется.

A>Блин, мне кажется если такие программисты и есть, то их заслали с Марса.

A>А наши, земные программисты пишут не на modern C++, а на чём-то более вменяемом. Например, на Qt. Или на WinAPI. Они берут макрос UINT, а дальше за всё отвечает Майкрософт

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

using Float = double; // float;

Т.е. эквивалентно "взятию макроса UINT".

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

A>>>>А если бы ты везде юзал тип i32, она бы у тебя не собиралась под разные платформы? Или оптимизацию нельзя было бы прикрутить?
N>>>Собиралась. При этом компилятор задолбал бы warning'ами, работало бы медленнее и временами падало.
A>>Ворнингами о чём?

N>О несовпадении размерностей типов. В адресной арифметике все целые должны быть иметь вполне определенный размер.

Ты видел программу с 16-битными шортами, скомпилированную под 32 бита? Откуда там несовпадение размерностей и ворнинги? То же самое относится к программе с жёстко 32-битными интами, скомпилированной как под 32 бита, так и под 64.

Или что, мне надо было оговорить, что "везде юзал тип i32" не означает, что можно/нужно кастить указатели к i32? (По крайней мере, без #ifdef'ов).

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

A>Напомнить? В ответ на: "Наличие плавающего размера — это одна из самых уродливых черт С/С++" ты написал: "В С++ ты сам решаешь чем тебе пользоваться".
A>Из чего следует, что альтернатива плавающему размеру таки есть.
Наличие чего угодно где угодно не означает что тебя принуждают пользоваться только этим.

A>и как мне это сделать, если его там нет?
Кого и где нет? Подрубай платформенный header с определениями под таргет платформу, typedef их в MyMagicTypeBlah, и юзай его у себя везде.

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

S>>

S>>var provider: mdx::expression_tree::abstract_cell_provider_uptr = std::make_unique<mdx::expression_tree::cell_providers::distinct>(...);
S>>

CC>Вот никогда не понимал смысла везде писать вот эти портянки имён?

Использование полных имен позволяет легко и быстро перемещать куски кода из одной части проекта в другую. Если в начале .cpp-файла делать какую-то настройку пространств имен под себя, типа:

namespace fs = std::filesystem;
namespace cell_providers = mdx::expression_tree::cell_providers;
...

то нарываешься на проблемы там, где такой настройки нет или она сделана по-другому (а когда над проектом работают разные люди, то это неизбежно).
Если такая настройка делается не в начале .cpp-файла, а в каком-то ограниченном скоупе, то появляется лишняя забота запоминать что и в каком контексте под какими именами доступно.

Использование using some_ns::some_type_name для того, чтобы можно было использовать some_type_name без пространства имен вводит дополнительный геморрой, т.к. приходится следить за тем, где эти using-и сделаны, а где нет. Делать кучу таких using-ов в самом начале .cpp-файла, чтобы о таких вещах не думать, как по мне так себе идея. Особенно в .cpp-файлах где интегрируется функциональность из разных библиотек и/или частей проекта и где смешивается куча типов из разных пространств имен.

Использование же using namespace some_ns (по типу using namespace std; в начале .cpp-файла, как некоторые любят делать)... Фу, кака. Слишком много всякого разного внезапно может попасть в текущий контекст. И перестать работать, если скопипастить кусок кода в другой контекст.

При использовании полных имен гораздо точнее работает Doxygen. По крайней мере по моим впечатлениям. Если использовать какие-то виды сокращений из описанных выше, то Doxygen может либо вообще не проставлять перекрестные ссылки, либо вести их не туда.

CC>Typedef забанен что ли?

typedef -- это окаменевшее говно мамонта. Откройте для себя using.

Кроме того, если using массово используется для того, чтобы переименовать сущности из библиотеки X под себя, то это введение второго словаря сущностей, но ради чего? Ради удовлетворения своих эстетических пристрастий?

Одно дело, когда using делается чтобы скрыть детали реализации (типа на этой платформе у нас ssize -- это int32, а на этой int64). Другое дело когда объявляется ICellProvider вместо abstract_cell_provider просто потому, что кого-то тошнит от snake_case.

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

S>Использование полных имен
... сильно ухудшает читабельность кода.

S> позволяет легко и быстро перемещать куски кода из одной части проекта в другую.
И как часто тебе это надо?

S> Если в начале .cpp-файла
Это делается не в каждом .cpp а в общем .h

S>Использование using some_ns::some_type_name для того, чтобы можно было использовать some_type_name без пространства имен вводит дополнительный геморрой
используй typedef, чтобы сделать короткое уникальное и читабельное имя.

S>При использовании полных имен гораздо точнее работает Doxygen.
Он генерит такую же нечитаемую документацию.

S>typedef -- это окаменевшее говно мамонта. Откройте для себя using.
Ты токашо столько проблем с ним перечислил что похоже тебе лучше закрыть для себя using

S>это введение второго словаря сущностей, но ради чего?
Ради того, чтоб видеть код и его логику а не продираться через километровые наслоения namespaces, которые часто откровенно abused.

S>Другое дело когда объявляется ICellProvider вместо abstract_cell_provider просто потому, что кого-то тошнит от snake_case.
А как насчёт ICellProvider вместо some_fancy_lib_name_because_we_liked_the_word_we_found_in_the_dictionary::some_namespace_for_some_shit_and stuff::yadda_yadda_framework_and_whistles::some_fancy_ass_long_name_because_fuck_you_thats_why::super_duper_cells_something_something_dark_side::fancy_long_provider_name_to_provide_some_obscure_crap_obvioulsy::foo?

Pzz>Я чё-то не понял. А зачем у них int гвоздями прибит к i32?
Чай не Томпсон с Пайком делают-то...

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

S>>Использование полных имен
CC>... сильно ухудшает читабельность кода.

У меня наоборот. Но я Vim-ер, у меня своеобразные пристрастия.

S>> позволяет легко и быстро перемещать куски кода из одной части проекта в другую.
CC>И как часто тебе это надо?

Постоянно. По крайней мере для того, чтобы unit-тесты писать часто приходится фрагменты туда-сюда перекидывать.

S>> Если в начале .cpp-файла
CC>Это делается не в каждом .cpp а в общем .h

Тогда это второй словарь. Кому-то, видимо, нужна дополнительная ментальная нагрузка.

S>>Использование using some_ns::some_type_name для того, чтобы можно было использовать some_type_name без пространства имен вводит дополнительный геморрой
CC>используй typedef, чтобы сделать короткое уникальное и читабельное имя.

Есть компонент (сторонняя либа) в котором есть уже понятное имя. Что-то вроде file_formats::default_format_detector. Про это имя знают все, кто пользуется file_formats. Потом я начинаю в своих кусках кода заменять его на FmtDetector, а работающий над другими кусками Вася Пупкин заменяет его на format_prober. И когда я заглядываю в код Пупкина, то мне нужно разбираться что за prober и откуда он взялся, а Пупкин не будет понимать что за FmtDetector.

Да ну нафиг такое щасте.

S>>При использовании полных имен гораздо точнее работает Doxygen.
CC>Он генерит такую же нечитаемую документацию.

Пока что это лучшее из имеющегося. Иногда без него тяжко. Особенно поработав с любителями писать "самодокументирующийся код". И если Doxygen-у можно помочь, то лучше помочь.

S>>typedef -- это окаменевшее говно мамонта. Откройте для себя using.
CC>Ты токашо столько проблем с ним перечислил что похоже тебе лучше закрыть для себя using

Это были проблемы не с using-ом, а с желанием ввести свои собственные имена.

S>>это введение второго словаря сущностей, но ради чего?
CC>Ради того, чтоб видеть код и его логику а не продираться через километровые наслоения namespaces, которые часто откровенно abused.

Проще разобраться в существующих именах, чем каждый раз заучивать новые.

S>>Другое дело когда объявляется ICellProvider вместо abstract_cell_provider просто потому, что кого-то тошнит от snake_case.
CC>А как насчёт ICellProvider вместо some_fancy_lib_name_because_we_liked_the_word_we_found_in_the_dictionary::some_namespace_for_some_shit_and stuff::yadda_yadda_framework_and_whistles::some_fancy_ass_long_name_because_fuck_you_thats_why::super_duper_cells_something_something_dark_side::fancy_long_provider_name_to_provide_some_obscure_crap_obvioulsy::foo?

Мне уж показалось, что CreatorCray начал читать что ему пишут и думать над написанным. Но нет, ошибся.

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

S>Но я Vim-ер, у меня своеобразные пристрастия.
Это кстати многое объясняет.

S>Постоянно. По крайней мере для того, чтобы unit-тесты писать часто приходится фрагменты туда-сюда перекидывать.
А переиспользовать никак?

CC>>Это делается не в каждом .cpp а в общем .h
S>Тогда это второй словарь. Кому-то, видимо, нужна дополнительная ментальная нагрузка.
Да просто не надо себе в голову заталкивать мегадлинные имена совсем, они всё равно туда плохо помещаются.
Ну и запоминать их тоже нафиг надо, для этого есть intellisense

S>Потом я начинаю в своих кусках кода заменять его на FmtDetector, а работающий над другими кусками Вася Пупкин заменяет его на format_prober.
См выше про единый .h

S>Пока что это лучшее из имеющегося.
Он же и худший.

S>Это были проблемы не с using-ом, а с желанием ввести свои собственные имена.
Имена вводятся через typedef а не через using.

S>Проще разобраться в существующих именах, чем каждый раз заучивать новые.
Не проще если имена уже нечитабельные.

S>Мне уж показалось, что CreatorCray начал читать что ему пишут и думать над написанным. Но нет, ошибся.
Я так понимаю раз ты опять резко ломанулся в кусты — ты с написанным согласен но признать это не в состоянии.