LINUX.ORG.RU

В C++ добавят Rust

 , , ,


2

4

Привет, ЛОР! Я тебе покушать принёс.

Опубликован черновик расширения Safe C++, представляющего собой надмножество языка с возможностью отключать в коде Undefined Behaviour и прочие небезопасные штуки. Safe C++ добавляет в язык также borrow checker, pattern matching и другие функции, знакомые и любимые программистами на Rust. unsafe блоки входят в комплект.

Пример кода:

#feature on safety
#include <std2.h>

int main() safe {
  std2::vector<int> vec { 11, 15, 20 };

  for(int x : vec) {
    // Ill-formed. mutate of vec invalidates iterator in ranged-for.
    if(x % 2)
      mut vec.push_back(x);

    std2::println(x);
  }
}

Ошибка при сборке этого кода:

$ circle iterator.cxx -I ../libsafecxx/single-header/
safety: during safety checking of int main() safe
  borrow checking: iterator.cxx:10:11
        mut vec.push_back(x);
            ^
  mutable borrow of vec between its shared borrow and its use
  loan created at iterator.cxx:7:15
    for(int x : vec) {

Чтение за пределами обычных массивов также станет невозможным:

#feature on safety
#include <cstdint>

int main() safe {
  int array[4] { 1, 2, 3, 4 };
  size_t index = 10;

  // Panic on out-of-bounds array subscript.
  int x = array[index];
}

Результат:

$ circle subscript_array.cxx
$ ./subscript_array
subscript_array.cxx:9:17
int main() safe
subscript is out-of-range of type int[4]
Aborted (core dumped)

Таким образом, сишники и плюсисты наконец научатся писать нормальный код, который не падает с сегфолтами и не портит стэк. Так заживём!

Ссылка: https://safecpp.org/draft.html

★★★★★

Последнее исправление: hateyoufeel (всего исправлений: 2)

Ответ на: комментарий от ox55ff

И в расте оно есть! в улучшеном виде, просто выкинули антипатерновое наследование данных.

Пример GObject в сишке.

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

Это вызов .clone(), чтобы боров отстал

не, это реализация аффинной типизации, которая позволяет, например, typestate программинг запилить - для системщины и протоколов самое то, плюсовый вот до растового не дотягивает; ещё позволяет определённые оптимизации проводить без всяких лишних УБ, ну и способствует более поддерживаемой архитектуре, в общем пушка

zurg
()
Последнее исправление: zurg (всего исправлений: 1)
Ответ на: комментарий от LamerOk

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

zurg
()
Ответ на: комментарий от zurg

то с лёгкостью же должен запилить пример, которой переиграет нас тут всех и уничтожит, разве нет?

Ты, сука, пьяный, чтоле?

CPU time: 233.56 seconds
...
CPU time: 0.23 seconds

Какой ещё пример тебе нужен, алконавт?

степень произвольности арифметики выбирай по своему вкусу (но в разумных пределах со скидкой на наш вот этот лоровский уровень лени)

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

LamerOk ★★★★★
()
Последнее исправление: LamerOk (всего исправлений: 1)
Ответ на: комментарий от alysnix

тогда и ножики надо выкинуть туда же

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

anonymous
()
Ответ на: комментарий от alysnix

чтобы хранить и передавать такие указатели нужен только один регистр, а чтобы ваши «nullable» - два. и никто в своем уме это делать не будет, поскольку именно указатель с нулом - это идеальный nullable тип.

Идеальный для процессора да, для языков программирования уже нет, понятно что для системных языков это нужно, но должно быть сильно ограниченно, лучше всего на данный момент это сделано в rust реальная работа с указателями доступна только в unsafe, для основного кода вместо указателя или ссылка (всегда валидная) или Option. Тот же Option в расте если T имеет «нулевое» значение оптимизируется так что в памяти реально занимает sizeof(T) байтов без всякого оверхеда.

anonymous
()
Ответ на: комментарий от anonymous

Тот же Option в расте если T имеет «нулевое» значение оптимизируется так что в памяти реально занимает sizeof(T) байтов без всякого оверхеда.

оно везде так. указатель в с++ тоже nullable автоматом. в том и дело, что то, что уже имеет null значение - есть nullable by default. а тому, что не имеет null, например числу, пришлепывают лишнее поле с признаком is_null.

сишный указатель с null это идеальный nullable тип. товарищ просто не понимает, и хочет из идеального nullable типа, сделать еще какой-то nullable.

кстати никто не мешает иметь в любом языке с сырым указателем null не равный нулю. а просто быть реальным адресом некоего обьекта с именем Null в памяти. просто от этого толку мало.

alysnix ★★★
()
Ответ на: комментарий от LamerOk

Ты такой же тупой как alysnix ?

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

я спорил с товарищем что утверждал, что питон обгонит с++, если взять нумпай, поскольку нумпай использует simd. на что я сказал, что и с++ может использовать simd, и нагнет питон по-любому.

после чего влез ты, и начал орать, что трава зеленая, а твой пример исчерпываще говорит, что си быстрей питона. а это все знают и без твоих барабанов, пионер.

alysnix ★★★
()
Ответ на: комментарий от alysnix

я вообще твои пионерские открытия, что трава зеленая, солнце светит, а си быстрее питона и не обсуждал вовсе.

А нахер ты тогда влез в дискуссию:

твой си код офигенен. ты просто считаешь среднее от картинки?

, если не понимаешь, о чём она?

после чего влез ты,

Я (раузмеется) не начинал разговор с тобой. Это ты его начал.

LamerOk ★★★★★
()
Последнее исправление: LamerOk (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

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

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

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

ссылки и указатели служат для разных целей. указатели для адресной арифметики и для близости к железу, что эту арифметику имеет.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

оно везде так.

Не везде в С++ std::optional нет до сих пор этой оптимизации, да и со ссылками он не может работать.

указатель в с++ тоже nullable автоматом. в том и дело, что то, что уже имеет null значение - есть nullable by default.

Плохо то, что нулевой указатель также легко разыменовывать как и ненулевой, очень легко ошибиться, это недостаток не только C++ но и явы с шарпом, но в них хотя бы нет UB. В rust (и функциональных языках откуда это содрано) сделано более правильно, без явной распаковки (паттерн матчинг и т. п.) просто нет доступа к значению.

а тому, что не имеет null, например числу, пришлепывают лишнее поле с признаком is_null.

Но тут уже никуда не денешься, в коде без Option точно также надо будет где-то хранить этот признак.

anonymous
()
Ответ на: комментарий от anonymous

Плохо то, что нулевой указатель также легко разыменовывать как и ненулевой, очень легко ошибиться,

ну и что? если есть такая боязнь - берешь ссылку вместо указателя.

вместо T* ptr, пишешь T& ref. это в с++. в си ссылок нет вроде, но могли бы ввести.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

вместо T* ptr, пишешь T& ref. это в с++. в си ссылок нет вроде, но могли бы ввести.

Ссылки в C++ возможно использовать далеко не во всех вариантах. Для выделения памяти, например, нельзя.

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

Ты, похоже, сам не понимаешь, зачем он. Вычисление адресов на асме и указатели в Си – разные вещи. Например, в Си ты не можешь просто взять и вычесть два указателя друг из друга, потому что это может быть UB. Хуже того, у тебя по адресу (void*)0 может быть замаплена страница, никто этому не мешает в принципе, но из-за сишной шизофрении ты не можешь туда обратиться. То есть, можешь, конечно, но компилятор стопудов напихает тебе говна в код. Но вот такое будет работать:

$ sysctl vm.mmap_min_addr=0
#include <sys/mman.h>
#include <stdio.h>
#include <string.h>

int main(void) {
    char *addr = mmap(NULL, 6, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED|MAP_ANONYMOUS, -1, 0);
    if (addr == MAP_FAILED) {
        perror("mmap");
        return 1;
    }
    strcpy(addr, "abcxyz");
    printf("Mapped into addr=0x%X\n", addr);
    printf("%s\n", addr);
    printf("%s\n", NULL);
}
hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 3)
Ответ на: комментарий от hateyoufeel

Хуже того, у тебя по адресу (void*)0 может быть замаплена страница, никто этому не мешает в принципе,

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

а в чем проблема-то? будете лазать по нулевому адресу в какой-то «типа обьект». никто не мешает. просто это не будет никак системой перехватываться.

вообще не понимаю сути претензий.

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

Я тебе, короче, скажу по секрету: некоторые платформы мапят нулевую страницу по дефолту.

вообще не понимаю сути претензий.

Суть в том, что выбор какого-то особенного значения для обозначения указателя – плохая идея. Строить вокруг этого значения какие-то малополезные оптимизации, называть работу с ним Undefined Behaviour и срать в код компилятором – просто тупость. Короче, мы возвращаемся к тому, что Си – очень плохой язык, на самом-то деле.

Кстати, заметь, что mmap при ошибке возвращает MAP_FAILED ((void*)-1), а не NULL. Что в принципе немного лучше.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 3)
Ответ на: комментарий от alysnix

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

Option это единица системы типов, вокруг которой можно навернуть compile-time проверок, чтобы ты не мог случайно значение вытащить.

anonymous
()
Ответ на: комментарий от alysnix

с какой вообще стати указатель не может быть равен некоему наперед заданному числу,

Со стандарта Си, в котором написано, что указатель обязательно должен указывать на некий реально существующий объект, либо на адрес сразу после конца массива, либо быть равен NULL. Это единственные три варианта. В противном случае, компилятор может тебе в штаны насрать (и обязательно насрёт!) оптимизациями вокруг UB.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Суть в том, что выбор какого-то особенного значения для обозначения указателя – плохая ещё.

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

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

нормальная это идея. это просто нуллабл тип.

Нет. В nullable type этот самый null является отдельным значением.

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

Чо? Дядя, тебя обманули, туда какого только говна не размещают.

то есть нулл для значения адреса имеет аппаратную природу и поддержку

Не имеют.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Кстати, заметь, что mmap при ошибке возвращает MAP_FAILED ((void*)-1), а не NULL. Что в принципе немного лучше.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

Кстати, заметь, что mmap при ошибке возвращает MAP_FAILED ((void*)-1), а не NULL. Что в принципе немного лучше.

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

Ну, да. Юниксоподобные оси – та ещё клоунада, тут ты правильно заметил. А венда ваще мапит говна в нулевую страницу из коробки только так, но только для досовских прог (когда это ещё было актуально).

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

В nullable type этот самый null является отдельным значением.

никто в системном софте, на асме тем более, не будет держать таблицы адресов или списки в виде нуллабл, с отдельным полем - признаком нул или нет. будут просто писать ноль в поле адреса и радоваться жизни.

а ради защиты железку сделают так, чтобы при попытке выставить адрес 0 генерилось прерывание номер такое-то.

все остальное - извращение больных людей, коих множество.

alysnix ★★★
()
Ответ на: комментарий от alysnix

никто в системном софте, на асме тем более

Так в системном софте или на асме? На асме системный софт, за исключением пары кусков в ядре, никто не пишет уже лет 30.

не будет держать таблицы адресов или списки в виде нуллабл, с отдельным полем - признаком нул или нет

А, собственно, почему? Кучу другой инфы же хранят об адресах. Права доступа там и так далее.

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

Хотя мне кажется, ты тут просто свои фантазии расписываешь, а от ассемблера у тебя просто травма.

а ради защиты железку сделают так, чтобы при попытке выставить адрес 0 генерилось прерывание номер такое-то.

Так сделают или сделали? Я вот сейчас покопал доки по x86_64, и там никто не мешает писать в физический адрес 0x0. В виртуальный тем более не мешает, я это выше показал.

все остальное - извращение больных людей, коих множество.

Почему? То, что ты привык к этому говну, не отменяет того, что это всё реально говнище-то полное.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

А, собственно, почему? Кучу другой инфы же хранят об адресах. Права доступа там и так далее.

Я больше скажу – в ядре настолько охренели, что используют куски указателей чтобы коды ошибок пихать: https://elixir.bootlin.com/linux/v6.11/source/include/linux/err.h#L59

anonymous
()
Ответ на: комментарий от MOPKOBKA

Ты лучше скажи как должно быть, куда NULL должен указывать?

NULL никуда не должен указывать, потому что ты не можешь его разименовать. То что NULL == 0 это просто так сложилось из глубины веков.

anonymous
()
Ответ на: комментарий от MOPKOBKA

Сейчас процессоры только 48 бит используют, архитектурное ограничение на физическую память 52 бита, поэтому все правильно делают.

Это просто костыль, коих там много. Суть в том, что никто не мешает засунуть в указатель бит его валидности. Другое дело, что это никого ни от чего не спасет, потому что не может быть проверено в compile time. Проблема сишки в том, что это попросту очень плохой язык, который нельзя сделать лучше из-за импотенции комитета и отвратительной проблемы обратной совместимости с уже понаписанным говном.

anonymous
()
Ответ на: комментарий от hateyoufeel

Это вообще очень странная жалоба, зачем тебе писать в нулевую страницу? Ты не должен так опираться на адреса в своем коде, если хочешь что бы он был переносим. Если переносимость тебе не важна, то UB тебе тоже не страшен, ты пишешь под конкретную платформу со знанием что происходит при разыменовании указателя.

MOPKOBKA ★★★★
()
Ответ на: комментарий от hateyoufeel

А, собственно, почему?

а потому, что это нафиг никому не надо. потому что в списках поле даже next - тоже делать option???

берем вот лисп. там вообще все на парах указателей сделано. размер ячейки, или как оно у них там - два указателя. указатель на значение и указатель на следующую ячейку. пусть адрес равен 32 бита. ячейка - 64 бита.

поскольку вы требуете чтобы указатели были типа option<..> - то вам или надо паковать option в 32 бита - но это то же самое, что просто вводить нулл.

или размер ячейки будет 128 бит и вы потеряете половину памяти просто на биты is_null.

кстати в лиспах этих вместо нула, используют адрес некого обьекта nil…но это те же орехи, только в профиль. вместо нуля берется некий фиксированный адрес.

alysnix ★★★
()
Ответ на: комментарий от MOPKOBKA

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

Мой комментарий ещё как верен:

A null pointer has a reserved value that is called a null pointer constant for indicating that the pointer does not point to any valid object or function.

Ты не можешь это разименовывать, потому что в языке C ссылка на невалидный объект – UB. Если твоя программа так делает, твоя программа не является программой на языке C.

anonymous
()
Ответ на: комментарий от anonymous

Это и не делается для проверки в compile time или качественного улучшения обработки ошибок, я обсуждал только обрезание указателя а не язык.

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

MOPKOBKA ★★★★
()
Ответ на: комментарий от LamerOk

разупорись уже, нет никакой 1000 раз, ты просто взял и тупо затормозил на порядки питоновскую версию, на ровном месте, единственное что доказал что можно взять и бессмысленно затормозить любой язык, ну и кто тут пьян?

на любую сколь угодно более простую арифметику, где есть обращения ко всем элементам матрицы.

можешь сразу погуглить какой-нибудь «numpy image processing» и посмотреть как это делается, и попытаться найти там такой вот тупой вложеный цикл из своего примера

zurg
()
Ответ на: комментарий от MOPKOBKA

Язык неплохой, ядро же развивается, ну а безопасность Линуса не особо волнует видимо

Ядро не особо-то развивается. Тут недавно замеряли, nginx поверх минимального bare metal рантайма работает в 4 раза быстрее, чем поверх лялекса. Ядро старое, сложное, жирное, медленное и отвратительно расширяется. И сишка тут никак не помогает.

anonymous
()
Ответ на: комментарий от alysnix

куда и указывает. на нулевой адрес, аппаратно защищенный от доступа к нему.

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

anonymous
()
Ответ на: комментарий от MOPKOBKA

Это вообще очень странная жалоба, зачем тебе писать в нулевую страницу? Ты не должен так опираться на адреса в своем коде, если хочешь что бы он был переносим. Если переносимость тебе не важна, то UB тебе тоже не страшен, ты пишешь под конкретную платформу со знанием что происходит при разыменовании указателя.

Дело не конкретно в нулевой странице, а в том, что в пространстве значений типа «указатель» у функции разыменование есть разрыв.

Ты лучше скажи как должно быть, куда NULL должен указывать?

На то, что лежит в том куске памяти, очевидно. 0x0 не должно быть каким-то специальным значением.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Ну ты можешь предложить альтернативное защищенным страницам решение. Если альтернативное значение тебя не устраивает, значит нужно хранить дополнительное, и увеличить указатели в два раза как выше писал alysnix? Все же этим свойством пользуются, Option<T> из Rust оптимизирует Empty как NULL если у него T указатель.

У тебя готовый, оптимизированный, машинный Option. Еще он не зависит от языка, и даже если в ассемблере ты допустишь ошибку с NULL, программа быстро вылетит. Я читал советы по программированию из 60х, там как раз советовали резервировать в начале памяти и диска место, потому что там постоянно будет оказываться мусор из за ошибок. Поэтому NULL хорош не только тем что это значение на какой то адрес, но и тем что он 0, начальный адрес, индекс.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 5)
Ответ на: комментарий от anonymous

А, собственно, почему? Кучу другой инфы же хранят об адресах. Права доступа там и так далее.

Я больше скажу – в ядре настолько охренели, что используют куски указателей чтобы коды ошибок пихать: https://elixir.bootlin.com/linux/v6.11/source/include/linux/err.h#L59

Я намекал на таблицу MMU, так-то. Но в указатели инфу не только ядро пихает. Достаточно хотя бы того, что адреса обычно должны быть выровнены, и в последние несколько бит тоже можно чего-то присунуть.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от MOPKOBKA

Все же этим свойством пользуются, Option из Rust оптимизирует Empty как NULL если у него T указатель.

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

Я повторю свой тезис в максимально сжатом виде: на уровне языка не должно быть никаких специальных указателей, а ошибки должны возвращаться явно с использованием системы типов. Как именно это всё представлено после компиляции в машинном коде, на самом деле, вообще насрать 10 раз.

У тебя готовый, оптимизированный, машинный Option. Еще он не зависит от языка, и даже если в ассемблере ты допустишь ошибку с NULL, программа быстро вылетит.

Это не Option. Ты бы ещё нулевой делитель назвал Option. Ведь при делении на 0 тоже программа быстро вылетит.

даже если в ассемблере ты допустишь ошибку с NULL, программа быстро вылетит.

Алсо, смотри-ка, не вылетела!

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 4)
Ответ на: комментарий от zurg

ты просто взял и тупо затормозил на порядки питоновскую версию

Ну так ускорь её хотя бы раз в десять. Что б не в тысячу сливал, а хотя бы в сто.

такой вот тупой вложеный цикл

Ну замени его на острый разложенный цикл. Покажи класс.

Главное не забудь выполнить основное условие:

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

Специально для тебя разжёвываю в 100500 раз: замена арифметики на питоне вызовом сишного кода - это провал.

LamerOk ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Поэтому NULL хорош не только тем что это значение на какой то адрес, но и тем что он 0, начальный адрес, индекс.

Это вообще малозначительная деталь. Он так же мог бы быть 0xffffffff и ничего бы не изменилось.

anonymous
()
Ответ на: комментарий от hateyoufeel

Я тред весь не читал, Option на уровне языка это хорошо, да. Тогда нету смысла опускаться до обсуждения возможности или невозможности записи в 0 на разных архитектурах. Достаточно реализации как в Rust когда при наличии аппаратно защищенных страниц выбирается 0 или другое значение в Option.

Алсо, смотри-ка, не вылетела!

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

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

Я повторю свой тезис в максимально сжатом виде: на уровне языка не должно быть никаких специальных указателей, а ошибки должны возвращаться явно с использованием системы типов. Как именно это всё представлено после компиляции в машинном коде, на самом деле, вообще насрать 10 раз.

дурной твой тезис. не философствуй больше. и языки бывают разные, и концептов всяких хоть ж. ешь.

си это язык написания драйверов, кернелов, рантаймов и всего такого. ему не нужны твои мощные «концепты», взятые не пойми откуда. ему нужны концепты максимально просто отображаемые на машинный код, а не абстрактные философии.

хочешь философий - на лиспе пиши.

вы там начитались какой-то дури от руста небось, вот вас и носит.

alysnix ★★★
()
Ответ на: комментарий от alysnix

си это язык написания драйверов, кернелов, рантаймов и всего такого. ему не нужны твои мощные «концепты»

Почему не нужны?

ему нужны концепты максимально просто отображаемые на машинный код, а не абстрактные философии.

Си крайне херово отображается в машинный код.

hateyoufeel ★★★★★
() автор топика