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

A>А мне зачем эти абстракции нужны? Чтобы они протекли?

И как именно они протекут?

A> Чтобы поиметь лишний геморрой при сопряжении с каким-нибудь LPARAM, из которых (сопряжений) реальная работа разработчика и состоит чуть менее, чем полностью?

Я работаю вот уже реально 30 лет с C, C++ и многими другими языками уровня "портабельный ассемблер или чуть выше". И у меня было крайне мало работ, на которых "реальная работа разработчика" состояла бы "чуть менее, чем полностью" из "сопряжения с каким-нибудь LPARAM".

Если речь про взаимодействие со средами, где важны точные размеры и расположения каких-нибудь полей — да, такое происходит постоянно. Сетевые протоколы с элементами типа "трёхбитное поле". Форматы данных аудиокодека. Всё это бывает. Но надо понимать, что это — то, что происходит за границей внутреннего хозяйства. Поэтому такие структуры, например, помечаются attribute((packed)) в GCC и pragma pack(1) в виндовых компиляторах. Но из этого не следует, что всем структурам и вообще всем типам данных надо следовать этому. Внутренним — точно не нужно.

A> (Ничего себе, "И только для согласования с конкретными тараканами нижнего уровня"!) Или чтобы нельзя было прикинуть размер файла с данными?

Файл с данными это уже случай упаковки — в значительном смысле, тех самых тараканов нижнего уровня.

A>Кстати. Просто мимоходом. Тебе не кажется, что range -50...+80 — это источник ошибок? Мина замедленного действия?

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

A> Когда пляшут от байтиков, проблема диапазона возникает раз в несколько лет, и тогда берут тип экспоненциально большей размерности. И это не вечный процесс. Он прекращается, когда компьютеры становятся достаточно взрослыми. Тип общего назначения i128 уже никому не нужен.

То-то он присутствует в расширениях одновременно GCC и MSVC.

A> Там уже вектора, SIMD и прочее подобное роялит. С паскалевским же подходом вся твоя жизнь превратится в одну большую проблему диапазонов.

Вызываю обосновательную бригаду.

A> Тем и отличается практично мыслящий разраб от архитектурного космонавта. (Любезность за любезность ).

У меня как раз никакой астронавтики, чистая практичность. Да, для технического уровня времён, когда писали C, она была неподъёмна. Но прошло 50 лет, а вы всё мыслите мерками тех времён...

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

Не все, к счастью. Но, как известно, для каждой проблемы найдётся простое, ясное, неправильное решение. Точнее, неправильным является непредоставление диапазонных и прочих урезанных типов с автовыводом базового типа. Сами по себе i32 не виноваты, виновата чрезмерная опора на них.

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

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

N>>Не справляются.
FLY>Это проблем только С,

C++ вообще-то В C ещё не стреляет, хотя там близко к этому.

N>>Какой имеющийся? То что для C++, неизбежно включающее в себя интерпретатор подмножества языка — в таком виде ни на что непригоден.
FLY>Причем здесь С и С++? Мы же говорим о новых языках, которыми мечтают их заменить. Зачем все, что нагородили и позволяется в C, тащить в новое, почему не сделать так, чтобы не возникало неоднозначностей и прочего?

Ну вот для устранения неоднозначностей, как оказалось, говорить "var", "let" и пр. в объявлениях переменных/полей — критично.

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

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

N>>Сейчас раздаётся заметное количество голосов, чтобы на 64-битных платформах int был тоже 64-битным.
_>Зачем?

См. ниже.

N>>Потому что сразу упрощается дофига аспектов.
_>Каких?

Например, влезет ли индекс в int, когда он size_t. Влезет ли указатель.

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

N>Ну вот для устранения неоднозначностей, как оказалось, говорить "var", "let" и пр. в объявлениях переменных/полей — критично.
То есть вместо того чтобы запретить то, что мешает и приводит к неоднозначностям, бороться с этим будем путем добавления новых конструкций?

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

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

N>>Ну вот для устранения неоднозначностей, как оказалось, говорить "var", "let" и пр. в объявлениях переменных/полей — критично.
FLY>То есть вместо того чтобы запретить то, что мешает и приводит к неоднозначностям, бороться с этим будем путем добавления новых конструкций?

Так а как его запретить-то, если оно нужно?

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

N>Так а как его запретить-то, если оно нужно?
А где может пригодиться запись имени параметра внутри скобок int a(int(b))? Ну или вот такое приведение типа как в первом примере? На мой взгляд int i = (int)d; и читается куда лучше чем int i(int(d)); и парсится проще.

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

FLY>Я говорил, что спустя полвека все вдруг решили вернуться к паскалевской декларации. А не то что она тупиковая.
Да банально всё идёт по спирали: просто подросли дети, которые никогда не видели паскаля и считают раз это другое и не как у всех — значит однозначно лучше существующего.

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

FLY>То есть вместо того чтобы запретить
А оно "мешает и приводит к неоднозначностям" только в руках безумцев, которые как раз легко детектятся по использовании таких конструкций везде где ни попадя.
Запрещать это путь к самокастрации — лучше оставить, на случай когда это реально понадобится.

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

FLY>А где может пригодиться запись имени параметра внутри скобок int a(int(b))? Ну или вот такое приведение типа как в первом примере? На мой взгляд int i = (int)d; и читается куда лучше чем int i(int(d)); и парсится проще.

Единообразие для POD типов добавили когда добавили templates, внутри которых будет уже

    Foo bar (Foo (foobar));

и ты уже не знаешь что там за тип в Foo — int или MySuperPuperBigInt

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

N>Например, влезет ли индекс в int, когда он size_t. Влезет ли указатель.
Если в коде для адресов в памяти или индексов (ну разишо для заведомо известной малой размерности, хотя это тоже такоЭ) везде напихан int — этот код плохо пахнет.
size_t спецом ввели для того, чтоб работать с адресами и размерностями в памяти.
И тем более нельзя использовать signed значения для unsigbed адресации.

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

A>Тип общего назначения i128 уже никому не нужен.

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

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

N>>"Паскалевская" декларация не тупик, это как раз единственный на сейчас беспроблемный стиль. Но чтобы понять это, надо было не просто создать C, а добиться, чтобы его стали использовать все.
FLY>Я говорил, что спустя полвека все вдруг решили вернуться к паскалевской декларации. А не то что она тупиковая.

Я наберусь наглости процитировать ту реплику, на которую я отвечал:

FLY>>> По этому вернемся к Паскалевской декларации? Мы тут полвека промучались и поняли, что это тупик, давайте еще дальше откинемся.

Мне как-то сложно понять её иначе, чем то, что "паскалевская" декларация не ведёт ни к чему полезному.
Если это не так, объясните, что имелось в виду...

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

N>>Например, влезет ли индекс в int, когда он size_t. Влезет ли указатель.
CC>Если в коде для адресов в памяти или индексов (ну разишо для заведомо известной малой размерности, хотя это тоже такоЭ) везде напихан int — этот код плохо пахнет.
CC>size_t спецом ввели для того, чтоб работать с адресами и размерностями в памяти.
CC>И тем более нельзя использовать signed значения для unsigbed адресации.

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

"unsigned адресация" в пространстве индексов массивов C, vector и array C++, прочих контейнеров C++ просто не существует, в том смысле, который ты, кажется, вкладываешь — потому что там не используется адрес в памяти в явном виде. То, что адресный уровень C/C++ представляет тебе как указатель, это просто некая битовая хрень, которая обычно побитно совпадает с адресом, но ты её в этом виде использовать не имеешь права.

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

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

N>>Так а как его запретить-то, если оно нужно?
FLY>А где может пригодиться запись имени параметра внутри скобок int a(int(b))?

Это синтаксис конструктора. Объявление такого типа создаёт переменную-объект, задавая аргументы конструктора.

FLY> Ну или вот такое приведение типа как в первом примере? На мой взгляд int i = (int)d;

А это уже присвоение значения объекту, который до того, если не получится сэкономить, инициализирован конструктором по умолчанию. Чувствуешь разницу?
Если нет, ты мало наступал на грабли C++ ;(

Они просто разные. Отождествлять их нельзя.

Как ты бы предполагал такое записать в случае нескольких параметров? Moo m1 = (arg1, arg2);, что ли? Так оно ещё больше собьёт с толку.

То, о чём ты говоришь, могло бы быть альтернативно записано, конечно, кучей методов, например, Moo m1 = @construct(arg1, arg2);, где @construct — какой-то синтаксический элемент специально для этого. Но так не сделали, а вместо этого в C++11 ввели синтаксис с {} для разрешения неоднозначностей (ну и начав современные догонялки до 19 разных видов инициализации).

FLY> и читается куда лучше чем int i(int(d)); и парсится проще.

C++11 сделал тут возможным, и часто желательным, int i{int(d)}. Остальное см. выше. Я в целом понимаю, чего ты хотел бы добиться, и немного поддерживаю. Но тут начинаются другие проблемы.

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

N>И как именно они протекут?

Возьми какой-то реальный сценарий. Не знаю, "Мужик фотографирует кису и отправляет фотку в мессенджере". И посмотри, во что превратится жизнь, если ты слезешь с байтов. Отринешь проклятое наследие Си. Выберешь язык с типами-диапазонами, и с нуля всё напишешь.

Для начала, сколько цветов будет иметь у тебя пиксел? Как у Эппл, "тысячи цветов", "миллионы цветов"? Наверно, ты всё-таки возьмёшь цветовую модель. Скажем, RGB. Спросишь у производителя матрицы, сколько он даёт градаций на канал, и напишешь тип {r: 0..64, g: 0..64, b: 0..64} (когда я последний раз интересовался вопросом, аппаратные возможности моников были именно такие, а сенсоров ещё хуже). И вот с этим ужасом тебе придётся таскаться всю дорогу.

Сколько будет весить необработанная фотография 1920*1080? Ага, ты, конечно, в уме округлил до байтиков и радуешься. А ты попробуй как в суде присяжных: когда говорят, мол, вы должны игнорировать эту улику, она получена незаконно. Ведь твоя цель — мыслить без привязки к байтам.

Как получить данные? У тебя идёт от драйвера матрицы сплошной поток. И он, конечно, байтовый. Ты его остановишь и будешь перепаковывать в {r: 0..64, g: 0..64, b: 0..64}?

А как кису вывести на экран? Здравствуй, for { for {} } ? В случае байтов тебе, скорее всего, максимум, придётся порядок строк инвертировать при подготовке буфера. (Это зависит от "тараканов"). В лучшем случае — просто скопировать буфер целиком.

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

N>Файл с данными это уже случай упаковки — в значительном смысле, тех самых тараканов нижнего уровня.

И что с того? Сериализация — не пример, из чего состоит работа чуть менее, чем полностью?

A>>Кстати. Просто мимоходом. Тебе не кажется, что range -50...+80 — это источник ошибок? Мина замедленного действия?

N>Не кажется. На один потенциальный случай, когда это мина замедленного действия, происходит несколько сотен других, для которых миной замедленного действия является, наоборот, попадание невалидных данных в переменные просто за счёт того, что их определение в виде int дало возможность сохранить такое значение.

Но хранятся-то реально данные всё равно в int'е (в реальном мире, где не изобрели чипы переменной битности). А ты просто предлагаешь абстрагироваться от этого. Во имя чистоты подхода.

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

И вот он, момент, когда бизнес-требования к диапазону выросли. Незначительно. Температура на Земле, как известно, снизу ограничена не -50, а чуть поменьше. -70 или -80, не помню точно. И ты приплыл. С кодебазой, где на каждом повороте аж компилятором проверяется, что температура не меньше -50. Ты даже последовательно модули обновить не сможешь. Только перевыкатывать всю систему целиком!

A>> Когда пляшут от байтиков, проблема диапазона возникает раз в несколько лет, и тогда берут тип экспоненциально большей размерности. И это не вечный процесс. Он прекращается, когда компьютеры становятся достаточно взрослыми. Тип общего назначения i128 уже никому не нужен.

N>То-то он присутствует в расширениях одновременно GCC и MSVC.

Ты, наверно, пропустил слова "общего назначения". Может и присутствует, но не как таковой.

A>> Там уже вектора, SIMD и прочее подобное роялит. С паскалевским же подходом вся твоя жизнь превратится в одну большую проблему диапазонов.
N>Вызываю обосновательную бригаду.

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

Никакие случаи "мини-вектор", "мини-структура" и т.п., конечно же, не принимаются.

А если окажется, что я ошибся, я просто заменю i128 на i256. Потому что изначальный тезис был — что процесс экспоненциального увеличения массово используемых типов — не бесконечен. Об этом легко забыть, если не следить за мыслью, не воспринимать ответ как единое целое, а механически дробить его на предложения и доковыриваться к каждому по отдельности (что я не слишком уважаю).

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

N>Не все, к счастью. Но, как известно, для каждой проблемы найдётся простое, ясное, неправильное решение. Точнее, неправильным является непредоставление диапазонных и прочих урезанных типов с автовыводом базового типа. Сами по себе i32 не виноваты, виновата чрезмерная опора на них.

Да, их тут тысячи! ©

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

A>>Тип общего назначения i128 уже никому не нужен.
CC>

Это ж как надо себя не уважать, чтобы что-то отвечать тому, кого считаешь тухлой селёдкой. Тем более, после того, как "селёдка" послала тебя нахер.

Здравствуйте, Alekzander, Вы писали:
A>Возьми какой-то реальный сценарий. Не знаю, "Мужик фотографирует кису и отправляет фотку в мессенджере". И посмотри, во что превратится жизнь, если ты слезешь с байтов. Отринешь проклятое наследие Си. Выберешь язык с типами-диапазонами, и с нуля всё напишешь.

Прекрасный пример, имхо.
A>Для начала, сколько цветов будет иметь у тебя пиксел?
Для начала, нужно определиться с задачами. "Фотографирует кису", "отправляет фотку в мессенджер". То есть, наверное, у нас там будет какой-то нативный формат, который отдаётся сервисом уровня операционной системы, и он существенно зависит от модели смартфона, версии драйвера и прочих несущественных подробностей.
И будет, наверное, какой-то формат, принимаемый мессенджером. Плюс ограничения как на пиксельные размеры, так и на общий вес картинки.
То есть задача, в целом, сводится к "пережать изображение из одного формата в другой, попутно сменив ей разрешение".
Отлично. Для смены разрешения у нас есть алгоритмы фильтрации — билинейные, бикубические, и т.п. В общем случае, мы вычисляем некоторый цифровой фильтр.
В терминах какого формата мы это будем делать? Очень вряд ли это будет device-dependent bitmap.
Нам захочется записать алгоритм в терминах чего-то device-independent; в простом случае это будет просто некоторое усреднение по R/G/B каналам; в сложном случае может пригодиться HSL-модель или что-то такое, более близкое к человеческому восприятию.
Отлично, пиксел у нас будет представляться некоторым типом, у которого есть, например, свойства R, G, и B некоторых типов.
В терминах такого обобщённого типа мы и напишем наши алгоритмы ресамплинга.
Естественно, никаких for{for{}} там не будет — это означает прибивание гвоздями определённого порядка обхода, что может оказаться неэффективным на реальной целевой аппаратуре.
У нас будет какая-то обобщённая библиотека алгоритмов над изображениями, которой мы скармливаем ядро фильтра, записанное в том самом абстрактном виде, и получаем конкретный код, оптимально применяющий этот фильтр.
А собственно, работа "с байтами" у нас должна быть спрятана в алгоритм декомпрессора, который умеет байтовый поток превращать в stride-ы пикселов, представленных в комфортном для фильтрации формате.
И у декомпрессоров будет отдельное подмножество "random-access decompressor", который позволяет обращаться к пикселам в произвольном порядке. Для таких декомпрессоров можно специализировать алгоритм фильтра алгоритмом декомпрессора, чтобы получить объединённый однопроходный алгоритм.
Самый простой вариант такого декомпрессора — это отображалка "упакованного типа" с битовыми полями (например, {r: 0..31, g: 0..64, b: 0..31}) в {R: half, G: half, B: half}.

A>Как у Эппл, "тысячи цветов", "миллионы цветов"? Наверно, ты всё-таки возьмёшь цветовую модель. Скажем, RGB. Спросишь у производителя матрицы, сколько он даёт градаций на канал, и напишешь тип {r: 0..64, g: 0..64, b: 0..64} (когда я последний раз интересовался вопросом, аппаратные возможности моников были именно такие, а сенсоров ещё хуже). И вот с этим ужасом тебе придётся таскаться всю дорогу.
"Всю дорогу" с этим ужасом таскаться было не надо уже 20 лет тому назад.

A>Как получить данные? У тебя идёт от драйвера матрицы сплошной поток. И он, конечно, байтовый. Ты его остановишь и будешь перепаковывать в {r: 0..64, g: 0..64, b: 0..64}?
Смотря что и как отдаётся из "драйвера матрицы". Если там, не к ночи будь помянут, какой-нибудь JPEG, то придётся останавливать и перепаковывать, потому что экран не умеет показывать JPEG. Он умеет показывать только некий Device-Dependent битмап, формат которого разве что случайно может совпасть с форматом, который идёт с камеры.

A>Короче, куда же ты денешься от байтов с подводной-то лодки.

A>Но хранятся-то реально данные всё равно в int'е (в реальном мире, где не изобрели чипы переменной битности). А ты просто предлагаешь абстрагироваться от этого. Во имя чистоты подхода.

A>И вот он, момент, когда бизнес-требования к диапазону выросли. Незначительно. Температура на Земле, как известно, снизу ограничена не -50, а чуть поменьше. -70 или -80, не помню точно. И ты приплыл. С кодебазой, где на каждом повороте аж компилятором проверяется, что температура не меньше -50. Ты даже последовательно модули обновить не сможешь. Только перевыкатывать всю систему целиком!
Это какая-то странная фобия. Замена определений пользовательских типов — совершенно рядовая операция. Она затруднена только в библиотеках — да и там для большинства частых случаев есть привычные рецепты.
А для "прикладного типа", специфичного для нашего конкретного проекта, это совершенно рутинная штука. И как раз языки, в которых есть возможность валидировать диапазонные типы, позволяют такие вещи делать гораздо легче.
Потому что в "голом" C-коде невозможно найти все места, где разработчик заложился на то, что температура снизу ограничена -50. В итоге пришедшие в рантайме -61 сломают его код совершенно неожиданным образом — более того, скорее всего собственно место, где "вылетит", будет совсем не там, где была сделана ошибка диапазона. "Ачотакова, это же просто инт".

То, что пока что таких языков мало — это проблема, а не решение. Просто очень сложно реализовать такие типы корректным и непротиворечивым образом на уровне языка. То, что там было в Паскале — так, детский сад.
Но мы потихонечку движемся к формальной верификации программ. Вот, в промышленные языки not null уже завезли; ещё чуть-чуть подождать — глядишь, и зависимые типы подвезут.

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

S>Для начала, нужно определиться с задачами. "Фотографирует кису", "отправляет фотку в мессенджер". То есть, наверное, у нас там будет какой-то нативный формат, который отдаётся сервисом уровня операционной системы, и он существенно зависит от модели смартфона, версии драйвера и прочих несущественных подробностей.

А это кто писать будет? Я, собственно, эту часть и рассматривал в своём посте. Включая предпросмотр.

У нас тут, видимо, недопонимание, потому что вся критика этой части относится к тому, что хронологически начинается после неё.

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

M>В интернетах пишут, что годится:
M>https://github.com/vladimirvivien/go-cshared-examples
Это скорее не про библиотеки, а про то, что если уж очень хочется интегрировать Go-код в проект, то некоторые пути существуют.

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

S>>Ну, вот он, ключ к успеху. Сначала нужно вообще узнать, что этот код неправильно работает.
CC>Да как то я сразу так написал и оно сразу работало.

Да уж прям таки — вы как то узнали, что надо исправить код в том самом месте

S>>https://godbolt.org/z/8jz98GEaK
CC>У меня в реальном коде как раз всё с переменными (BigNumber, все значения из памяти читаются) и работает.

50 оттенков отрицания, сезон 29 эпизод 18