сообщество плюсовиков потеряло единственного с++ одепта(T4r4sB) который противостоял растоманам?
или я чего то непонял?

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

надо сказать, что на расте поведение аналогично

let i: i8 = -1;
println!("{}", i as u64);

18446744073709551615

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

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

SP>надо сказать, что на расте поведение аналогично

SP>

SP>let i: i8 = -1;
SP>println!("{}", i as u64);
SP>

SP>

SP>18446744073709551615

Пример не идентичный )

let i: i8 = 0xff;
println!("{}", i as u64);

error: literal out of range for `i8`
--> src\main.rs:2:17
|
2 | let i: i8 = 0xff;
| ^^^^
|
= note: the literal `0xff` (decimal `255`) does not fit into the type `i8` and will become `-1i8`
= help: consider using the type `u8` instead
= note: `#[deny(overflowing_literals)]` on by default
help: to use as a negative number (decimal `-1`), consider using the type `u8` for the literal and cast it to `i8`
|
2 | let i: i8 = 0xffu8 as i8;
| ~~~~~~~~~~~~

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

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

CRT>Вот ты так понимаешь: "ЗНАКОВОЕ, расширенное до бОльшего колва бит."
Мне интуитивно понятно что сначала происходит расширение битности, банально потому что я начинал с ассемблера и знаю как оно работает в проце.

CRT>а кто-то понимает так "если я преобразую в беззнаковый тип, какого хрена он знаковый бит размножает??"
Этому человеку банально не хватает знаний архитектуры железа.

CRT>Что за хрень? (был когда-то вопрос у меня). Я же применяю БЕЗЗНАКОВЫЙ сдвиг >>>, то есть не должен знаковый бит копироваться в освобождаемые биты! Оказывается оператор >>> нифига не байт сдвигает — он не умеет байты сдвигать. Сначала байт расширяется до int, потом int сдвигается беззнаково — получаем 0x7fffffff, а потом результат впихивается в байт обрубая старшие биты. Потому что integer promotion
"Учите матчасть!" (С)

CRT>понятно что это правила, но эта подветка пошла от вопроса "Что не так с integer promotion?".
С ним всё так, не так с теми, кто не знает и не хочет узнавать.

CRT>то есть "а не лучше ли если бы были другие правила или лучше так оставить?"
ЛОЛ! С++ низкоуровневый язык который растёт от железа.
Если человек не имеет базовых знаний и не желает читать документацию — будут вот такие вопросы.

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


Р>> ЯП это же инструмент, следовательно его нужно освоить,помимо новых идей в расте компилятор умный.

R>Освоить ради освоения, или ради чего?
Не попробуешь не узнаешь. так ведь.

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

Z>Zig вообще ничем не похож и ничего нового особо не приносит.
Z>В нем никаких новых идей по сравнению с С нет, только синтаксис другой.

строгая типизация, да и defer один только уже круто.
вот взять яп с исключениями. try finally
где-то ниже по коду закрыли файл(или нет).
а тут открыли и следующей строкой defer f.close();
наглядно и надежно.

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

Р>Не попробуешь не узнаешь. так ведь.
Хехе, ты правда не догадываешься какого объёма банка с червями открывается этой невинной фразой?

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

Р> R>Освоить ради освоения, или ради чего?

Р> Не попробуешь не узнаешь. так ведь.

Часто, достаточно понюхать, пробовать не обязятально

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

Р>строгая типизация, да и defer один только уже круто.

Круто тем, что его можно забыть написать?

Р>вот взять яп с исключениями. try finally

Вот взять C++, ЯП с исключениями. Никаких finally. Деструкторы рулят и бибикают.

Даже собственный defer можно наговнякать за 5 минут.

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


CRT>>Вот ты так понимаешь: "ЗНАКОВОЕ, расширенное до бОльшего колва бит."
CC>Мне интуитивно понятно что сначала происходит расширение битности, банально потому что я начинал с ассемблера и знаю как оно работает в проце.

Понятно что расширение битности. А вот будет размножаться или нет знаковый бит при преобразовании знакового типа к более широкому беззнаковому типу — это из какой конструкции ассемблера тебе интуитивно понятно?

В ассемблере вообще у переменных нет знаковости или беззнаковости. Ты объявляешь размерность переменной: 1, 2, 4 или 8 байтов. А знаковоые они или беззнаковые ты никак не объявляешь.
Ты когда работаешь с ними, сам явно выбираешь какие команды использовать — те которые трактуют переменную как знаковую, или те которые трактуют ее как беззнаковую.

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

S>Здравствуйте, Разраб, Вы писали:

Р>>строгая типизация, да и defer один только уже круто.

S>Круто тем, что его можно забыть написать?

S>Вот взять C++, ЯП с исключениями. Никаких finally. Деструкторы рулят и бибикают.

По той же логике можно и обертку с деструктором забыть написать. Или забыть raii применить.

Вообще такую закономерность наблюдаю — чем сложнее какая-то штука делается, тем чаще про нее "забывают". А в языках где-то же самое делается просто — почему-то не забывают.

Программисты на с/с++ самые забывчивые получаются. И проецируют свой нерелевантный опыт на другие языки программирования.

Здравствуйте, Константин Б., Вы писали:

S>>Вот взять C++, ЯП с исключениями. Никаких finally. Деструкторы рулят и бибикают.

КБ>По той же логике можно и обертку с деструктором забыть написать. Или забыть raii применить.

Что характерно, что Си-программисты, которые думают, что программируют на C++, как раз и забывают.
Тогда как одно из отличий C++программистов от Си-программистов в том, что C++программисты про RAII не забывают, а используют во все поля.

КБ>Программисты на с/с++ самые забывчивые получаются.

Вообще-то само по себе "программисты на c/c++" -- это сферический конь в вакууме. Т.к. нет такого языка, как c/c++.

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

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

S>Здравствуйте, Константин Б., Вы писали:

S>>>Вот взять C++, ЯП с исключениями. Никаких finally. Деструкторы рулят и бибикают.

КБ>>По той же логике можно и обертку с деструктором забыть написать. Или забыть raii применить.

S>Что характерно, что Си-программисты, которые думают, что программируют на C++, как раз и забывают.
S>Тогда как одно из отличий C++программистов от Си-программистов в том, что C++программисты про RAII не забывают, а используют во все поля.

Ну вот и программисты на zig не забывают defer.

КБ>>Программисты на с/с++ самые забывчивые получаются.

S>Вообще-то само по себе "программисты на c/c++" -- это сферический конь в вакууме. Т.к. нет такого языка, как c/c++.

Да. Это два отдельных языка. Утверждение справедливо и для тех и для других.

S>Но даже если забить на это, то пруффы какие-то будут? Или это все из личного опыта?

Сразу после пруфов про забытые defer.

Здравствуйте, Константин Б., Вы писали:


S>>Вот взять C++, ЯП с исключениями. Никаких finally. Деструкторы рулят и бибикают.

КБ>По той же логике можно и обертку с деструктором забыть написать.

Можно. Только деструктор ты пишешь один раз при определении класса, а потом много раз пользуешься классом .
а defer тебе надо каждый раз писать при использовании.
соответственно вероятность забыть написать defer — выше. Или такая же, если ты пользуешься классом только один раз.

хотя я бы от defer или finally в С++ не отказался. Шлепать свой класс для каждого типа объекта из какого-нибудь API на С не очень удобно.

Здравствуйте, Константин Б., Вы писали:

КБ>>>Программисты на с/с++ самые забывчивые получаются.

S>>Вообще-то само по себе "программисты на c/c++" -- это сферический конь в вакууме. Т.к. нет такого языка, как c/c++.

КБ>Да. Это два отдельных языка. Утверждение справедливо и для тех и для других.

В C++ деструкторы вызываются автоматически, так что для C++программистов "справедливо" сильное переувеличение.

S>>Но даже если забить на это, то пруффы какие-то будут? Или это все из личного опыта?

КБ>Сразу после пруфов про забытые defer.

Да легко. Было сказано:

Круто тем, что его можно забыть написать?

Итак, нужно доказать что "можно забыть".
Есть ли в zig какие-то средства, которые заставляют разработчика использовать defer для освобождения ресурсов (закрытия файла, например)?
Вроде нет. А раз так, раз по рукам никто не бьет, значит забыть написать defer можно.

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

Тогда как вы высказались вот так:

Программисты на с/с++ самые забывчивые получаются.

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

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

CRT>хотя я бы от defer или finally в С++ не отказался. Шлепать свой класс для каждого типа объекта из какого-нибудь API на С не очень удобно.

Оно уже есть. Да и собственный вариант наговнокодить на коленке можно если не за 5мин, то за 15-20 наверняка.

Для многих C-шных библиотек, в которых функции возвращают указатели на что-то при создании (типа того же fopen), отлично работает стандартный unique_ptr с кастомным deleter-ом. Но вот почему-то об этом знают далеко не все

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

S>Да легко. Было сказано:
S>

Круто тем, что его можно забыть написать?

S>Итак, нужно доказать что "можно забыть".
S>Есть ли в zig какие-то средства, которые заставляют разработчика использовать defer для освобождения ресурсов (закрытия файла, например)?
S>Вроде нет. А раз так, раз по рукам никто не бьет, значит забыть написать defer можно.

Замечательно. Есть ли в С++ средства которые заставляют разработчика использовать raii для освобождения ресурсов (закрытия файла, например)?
Вроде нет. А раз так, раз по рукам никто не бьет, значит забыть использовать raii можно.

Здравствуйте, Константин Б., Вы писали:

S>>Да легко. Было сказано:
S>>

Круто тем, что его можно забыть написать?

S>>Итак, нужно доказать что "можно забыть".
S>>Есть ли в zig какие-то средства, которые заставляют разработчика использовать defer для освобождения ресурсов (закрытия файла, например)?
S>>Вроде нет. А раз так, раз по рукам никто не бьет, значит забыть написать defer можно.

КБ>Замечательно. Есть ли в С++ средства которые заставляют разработчика использовать raii для освобождения ресурсов (закрытия файла, например)?
КБ>Вроде нет. А раз так, раз по рукам никто не бьет, значит забыть использовать raii можно.

Да, можно. Разве я утверждал, что нельзя? Перечитайте, плз, еще раз то, что вам пишут.

А теперь пруфф утверждения про:

Программисты на с/с++ самые забывчивые получаются.

Или слив?

Здравствуйте, Константин Б., Вы писали:

КБ>Замечательно. Есть ли в С++ средства которые заставляют разработчика использовать raii для освобождения ресурсов (закрытия файла, например)?

Ну и как бы нельзя не поделиться ссылкой: ifstream (равно как и ofstream, равно как и fstream). Если вы открыли файл, то не закрыть его вы просто так уже не сможете.

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

S>Здравствуйте, Константин Б., Вы писали:

КБ>>Замечательно. Есть ли в С++ средства которые заставляют разработчика использовать raii для освобождения ресурсов (закрытия файла, например)?

S>Ну и как бы нельзя не поделиться ссылкой: ifstream (равно как и ofstream, равно как и fstream). Если вы открыли файл, то не закрыть его вы просто так уже не сможете.

Конечно смогу

new std::ifstream("file.txt");