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

A>Наличие плавающего размера — это одна из самых уродливых черт С/С++. Ты хоть раз извлёк из этого пользу? Твою программу перенесли на другую платформу без изменения одной строчки кода, и у юзеров ВДРУГ появился доступ к расширенному диапазону? Так никто не пишет лет тридцать уже. Все типы должны иметь однозначно и строго заданный размер, точка

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

Ну и как бы то ни было, вместе с Си этот изменчивый тип проник в POSIX, а тем самым проник всюду. Поэтому как бы то ни было, если язык претендует выжить в существующей экосистеме C/C++, ему хорошо бы эту странную черту Си как-то поддерживать.

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

S>Во-первых, не я. Я только использую. К развитию языка или его библиотеки отношения не имею от слова совсем.

Любой активный член комьюнити влияет на язык.

A>>Если стандартная библиотека обязательна к использованию, это не значит

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

Называется "упрусь и буду до конца делать вид, что не понимаю, о чём речь".

Объясняю второй раз и последний. В третий объяснять не буду.

То, что в других языках стандартная библиотека "обязательна к использованию", означает, что если Вася, пишущий на C#, начнёт пилить свою альтернативную стандартную библиотеку или хотя бы алиасы к ней, его, мягко говоря, не поймут коллеги. В то же самое время CreatorCray предлагает именно это, и для плюсов это нормально.

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

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

A>Объясняю второй раз и последний. В третий объяснять не буду.

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

A>То, что в других языках стандартная библиотека "обязательна к использованию", означает, что если Вася, пишущий на C#, начнёт пилить свою альтернативную стандартную библиотеку или хотя бы алиасы к ней, его, мягко говоря, не поймут коллеги.

Попробуйте сделать тоже самое в C++ и у вас потребуют обоснование зачем вы это делаете. И, с высокой долей вероятности, не поймут.

A>В то же самое время CreatorCray предлагает именно это

в областях, где CreatorCray недостаточно того, что есть в stdlib.

A>, и для плюсов это нормально.

Да, нормально не использовать то, что недостаточно эффективно (слишком ресурсоемко, недостаточно предсказуемо), а использовать что-то другое (в том числе и сделанное своими руками).

A>Но это не значит, что если Вася будет писать код с высокими требованиями к перфу (а я видел на шарпе прекрасные и быстрые драйвера, например), он обязан тащить туда вызовы всего самого тяжёлого, что есть в стандартной библиотеке.

Еще раз повторю: вы сейчас про C++ и говорите.

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

A>>С идеей, как я понял, сделать нативный код безопаснее за счёт повышенного контроля.
CC>Идея эта в сферическом вакууме хороша и благородна
CC>У меня претензии как раз к тому, в какое уродство это выразилось в реализации.

Возможно. Я на нём ничего конкретного не написал и не берусь судить.

A>>Понимаешь, это не надъязыковая идеология. Это идеология конкретно C++.
CC>Нет. С++ в отличие от новомодных языков как раз не диктует тебе как тебе выбирать имена, как расставлять отступы и прочее.

Что "нет", если ты сам пишешь что опциональность СБ это для плюсов нормально? Я говорю о том, что это не везде так.

И, кстати, давай не будет валить в кучу СБ и "как тебе выбирать имена, как расставлять отступы". Я тоже не люблю, когда какой-то крендель за меня решает, как мне расставлять скобки, но пятнадцать стрингов и пять классов массивов это уже перебор. Это то, что в обиходе, я как-то сел и подсчитал.

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

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

Ага. То-то по стандарту "you should not rely on ::int32_t being defined by <cstdint> ... on a platform where an unsigned char is not 1 byte, uint8_t may not exist".

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

A>Ага. То-то по стандарту "you should not rely on ::int32_t being defined by <cstdint> ... on a platform where an unsigned char is not 1 byte, uint8_t may not exist".

Да, по стандарту типы с фиксированным количеством бит (вроде std::uint8_t или std::int16_t) опциональны, т.к. их тупо может не быть на целевой платформе.
Зато будут std::uint_least8_t и std::int_least16_t.

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

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

A>>Наличие плавающего размера — это одна из самых уродливых черт С/С++. Ты хоть раз извлёк из этого пользу?

N>С/С++ это системные языки. Соответственно, дождны быть типы данных, размер которых равен размеру машинного слова. В С/С++ это int, size_t, intptr_t, ptrdiff_t etc. Если ты не понимаешь значимости таких типов, то язык просто не для тебя, работай с другим. Тут без шуток и всякого унижения, без этого в принципе НИКАК, введение таких типов — это попытка сделать безопаснее то, что небезопасно и от чего уходят в других языках.

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

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

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

S>Потому что это пример. Нет мозгов это понять, давайте я вам другой пример напишу, в котором типы опускать не получается (из текущего проекта, но слегка изменен):
S>

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

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

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

A>>Ага. То-то по стандарту "you should not rely on ::int32_t being defined by <cstdint> ... on a platform where an unsigned char is not 1 byte, uint8_t may not exist".

S>Да, по стандарту типы с фиксированным количеством бит (вроде std::uint8_t или std::int16_t) опциональны, т.к. их тупо может не быть на целевой платформе.

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

S>Зато будут std::uint_least8_t

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

Я уж молчу, что меня хлебом не корми, а дай в коде писать такое замечательное название как std::uint_least8_t.

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

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

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

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

В остальных случаях оно не то что бы опасно, но бесполезным может быть.

Я лично ни разу не сталкивался с ошибкой потерянного возврата. А вот писать (void) перед вызовами кода особо ретивых библиотекарей порой напрягает.

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

Pzz>Ну и как бы то ни было, вместе с Си этот изменчивый тип проник в POSIX, а тем самым проник всюду. Поэтому как бы то ни было, если язык претендует выжить в существующей экосистеме C/C++, ему хорошо бы эту странную черту Си как-то поддерживать.

Мне кажется — я подчёркиваю, что это только моё мнение — всё наоборот. С/С++ выжил только потому, что де-факто имел фиксированную ширину. Соответственно, проблем с фиксированностью не будет.

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

S>>Потому что это пример. Нет мозгов это понять, давайте я вам другой пример напишу, в котором типы опускать не получается (из текущего проекта, но слегка изменен):
S>>

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

AD>С var будет так же, только длиннее.

А кто сказал, что цель -- это сделать короче?

Мне бы хотелось видеть код _понятнее_, пусть даже ценой нескольких "лишних" символов.

Т.е. вот так _для меня_ гораздо лучше:

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

AD>К тому же апкастить в этой точке нет необходимости, скорее всего.

Это очень круто, когда кто-то на форуме лучше знает, что мне нужно. Очень. Круто.

Не было бы необходимости, можно было бы написать:

auto provider = std::make_unique<mdx::expression_tree::cell_providers::distinct>(...);

Или, как бы _мне лично_ хотелось бы:

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

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

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

AD>Наоборот — есть ограниченный набор случаев, когда опасно.

Простите, не понял что именно опасно? Опасно терять возвращаемое значение или опасно его не терять?

AD>- всякие сишные штуки, возвращающие ресурсы,

В последние пару лет GCC под линуксом прекрасно ругается, когда игнорируется возврат какой-то Си-шной функции, типа функции write.

AD>- всякая шелупонь в стиле си, которая результат отдает в аргументе, а возвращает признак того, что там что-то осмысленное.

Тут не понял, если Си-шная функция фигачит что-то в out-параметр, а возвращает либо 0, либо -1, то опасно этот 0/-1 игнорировать или опасно его обрабатывать?

AD>Я лично ни разу не сталкивался с ошибкой потерянного возврата.

Замечательно, это ваш опыт. Возможно, ув.тов.Nuzhny и его учтет. Я рассказал про свой.

Здравствуйте, Alekzander, Вы писали:
A>Я уж молчу, что меня хлебом не корми, а дай в коде писать такое замечательное название как std::uint_least8_t.
Я с каждым годом всё больше уважаю разработчиков С++.
Им дают язык, который намеренно делает простое — сложным, а сложное — чудовищно сложным.
Грабли разложены именно так, чтобы как можно сильнее бить "средних" специалистов — которым кажется, что они понимают, как работает язык.
А потом приходит какой-нибудь demonic optimizer, который пользуется наличием в прикладном коде UB, из которого язык состоит чуть менее, чем полностью, и молча меняет семантику кода на произвольную.

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

Ну вот, в обсуждаемом случае — std::uint_least8_t плох не столько названием (его же можно заалиасить лёгким движением руки), сколько трудностью написания кода с его использованием.
Это ж нужно шибко мозг вывернуть, чтобы написать корректную арифметику для типа "размером в хрен знает сколько бит, но не меньше 8".

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

A>>>Ага. То-то по стандарту "you should not rely on ::int32_t being defined by <cstdint> ... on a platform where an unsigned char is not 1 byte, uint8_t may not exist".

S>>Да, по стандарту типы с фиксированным количеством бит (вроде std::uint8_t или std::int16_t) опциональны, т.к. их тупо может не быть на целевой платформе.

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

Товарищ сверху (если вы про CreatorCray) пишет под конкретный компилятор и конкретную платформу. Что очень и очень часто встречается в мире C++. И он точно знает на что на данной платформе можно расчитывать.

S>>Зато будут std::uint_least8_t

A>В соответствии с названием, битность его опять же, не определена. Он может быть хоть 20 бит, если такова целевая платформа.

Если вам для вычисления необходимы 8 бит, то вы их гарантированно получаете. А дальше вопрос: вам шашечки или ехать?

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

Он пока вообще не родился. А учитывая привычку Google хоронить свои разработки, перспективы родиться под вопросом.

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

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

В смысле, не рассчитывает? У меня программа собирается под разные платформы, 32 и 64 бита, х86 и АРМ. Есть операции с памятью, арифметика указателей и т.д. Оно всё работает без макросов и других изменений. Я рассчитываю.

A>А вообще, тут есть здравое зерно. Язык, в котором способность быть хорошим языком общего назначения сознательно принесена в жертву малочисленным системным сценариям, действительно не для меня. Поэтому эта тема создана для обсуждения Carbon. Если ты не заметил

У языка С++ вполне конкретная цель была при его создании, эволюция описана создателем в отдельной книге. Можно сказать, что себе никто не изменял и принципы, заложенные изначально, соблюдаются.
Про Carbon тема уже не первая и даже не вторая. Его идеология понятна, ребята работают.

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

S>Здравствуйте, Alekzander, Вы писали:
A>>Я уж молчу, что меня хлебом не корми, а дай в коде писать такое замечательное название как std::uint_least8_t.
S>Я с каждым годом всё больше уважаю разработчиков С++.
S>Им дают язык, который намеренно делает простое — сложным, а сложное — чудовищно сложным.
S>Грабли разложены именно так, чтобы как можно сильнее бить "средних" специалистов — которым кажется, что они понимают, как работает язык.
S>А потом приходит какой-нибудь demonic optimizer, который пользуется наличием в прикладном коде UB, из которого язык состоит чуть менее, чем полностью, и молча меняет семантику кода на произвольную.

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

S>Ну вот, в обсуждаемом случае — std::uint_least8_t плох не столько названием (его же можно заалиасить лёгким движением руки), сколько трудностью написания кода с его использованием.
S>Это ж нужно шибко мозг вывернуть, чтобы написать корректную арифметику для типа "размером в хрен знает сколько бит, но не меньше 8".

Я не уверен, что эти люди реально существуют

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

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

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

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

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

N>В смысле, не рассчитывает? У меня программа собирается под разные платформы, 32 и 64 бита, х86 и АРМ. Есть операции с памятью, арифметика указателей и т.д. Оно всё работает без макросов и других изменений. Я рассчитываю.

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

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

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

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

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

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

A>Ага. То-то по стандарту "you should not rely on ::int32_t being defined by <cstdint> ... on a platform where an unsigned char is not 1 byte, uint8_t may not exist".
И? Не поддерживаемых на платформе типов не будет, а ты что ожидал?
И с каких пор int32_t это тип "плавающего размера", о которых шла речь?