> - Это не массив. Я же сказал - к доктору.Ты уверен, что к доктору мне, а не тебе? Что по-твоему такое std::vector, если не массив? Может ты думаешь, что это дерево?
> - Это массивы как раз - без кавычек. А, используют - всего лишь все Сишники... Но, вам конечно видней кто они...
Это как раз "массивы". Потому что C не различает массивы и указатели. Это было офигенной фишкой языка поначалу, но сейчас это одна из тех вещей, которая топит и C, и C++. Что-то я начинаю подозревать, что ты не видел массивов нигде, кроме как в C, и при этом ты пытаешься рассуждать о массивах, так? Это глупость, мнение C о массивах -- это довольно специфичное мнение, основной фишкой которой является то, что массив и указатель на первый элемент массива -- это одно и то же. Ты мыслишь о языках программирования, не зная их и глядя на них через призму C, и иначе не умеешь, так? Если ты ещё в состоянии слышать меня, то выслушай совет: пойди и освой lisp. Я бы рекомендовал взять либо racket либо common lisp (sbcl, например). sbcl -- это жёстко и олдфажно, racket -- это очень молодёжно и под смузи зайдёт неплохо. Вообще полезно освоить lisp: repl lisp'а в качестве калькулятора и не только арифметического офигенно заходит. Но мало того, это даст тебе возможность смотреть на C со стороны, а не только изнутри.
> - Подмена массива, идентификатора и указателя - смешиванием в кучу.
Конечно. Ритчи думал, что так будет круто. Оно поначалу и было круто, но сейчас боком вышло.
> А, что идентификатор массива указатель на массив - "секрет Полишенеля" только такому "профи" как вы...
Чё? Ты тут как-то слишком сложно завернул, я не понимаю, что ты хочешь сказать. Ты не мог бы перефразировать?
> Очевидно всем кроме вам. Даже если разжевать (выше).
Тут я опять не понял, но, мне думается, что если "выше" заменить на "ниже", то тогда эта твоя фраза обретает некий смысл: ты ведь ниже предпринял попытку разжевать, так?
> - Вот и нет, проверка была опциональной. А, person->name[-2] - хак, за который несёт ответственность его автор (в отл. от доступа по указателю), т.к.массивы в Си только с 0.
В C нет массивов. person->name[-2] -- это синтаксический сахар для *(person->name - 2).
> И проверка была даже далеко не везде, насколько я предполагаю только для статических массивов и легко адресумых в них указателей, а не любых указателей, так что ваш пример - вообще ещё и мимо.
> Но, даже такая ограниченная проверка - всёравно неприемлема...
Мне почему-то кажется, что здесь ты излагаешь своё собственное мнение, которые ты сочинил таким образом, чтобы оно подпирало бы твои догмы. Я с радостью соглашусь, что я ошибаюсь, но только после того как увижу ссылку на разработчиков gcc, обосновывающих отказ от проверок на выход за границы массивов.
> Да, я уже понял - все тупые кроме вас...
Да. Ты можешь спросить у любого здесь.
> И особо одарённым: я не возражаю против автоматических проверок, я возражаю против наглых и лживых утверждений что они бесплатны. Дезъинформации что Rust ровня Си по производительности.
А я возражаю против необоснованных утверждений. Ты не знаешь rust'а, ты не знаешь как оптимизируются автоматические проверки на выход за границы массива, ты не знаешь как их прожёвывает современный процессор -- всё это незнание я прям в глазах твоих вижу и в твоём эротичном голосе слышу. И несмотря на это ты продолжаешь утверждать, не приводя ни одного аргумента, кроме своей непоколебимой уверенности в своей непоколебимой правоте.
У rust'а есть недостатки, но ты про них не знаешь ничего, ты не упомянул ни одного реального недостатка rust'а. Например у него ОГРОМНЫЕ проблемы с разделяемыми библиотеками, эти проблемы проистекают из самой сути языка, и я очень сомневаюсь, что rust когда-нибудь будет решать эти проблемы так, как их решает, например, Swift. Можно ещё упомянуть, что раст провоцирует людей писать переусложнённый код, оверинжиниринг во все поля, там всё так круто, что просто не остановиться, и хочется описать в типах свою программерскую мысль со всеми завитушками, в том числе и с теми, которые нахрен не нужны. Можно упомянуть то, что rust ещё не закончен нифига, тот же async/await сейчас находится на этапе MVP, то есть minimum viable product, то есть его использовать конечно уже можно, но его ещё допиливать и допиливать. Есть основания надеятся, что это допиливание не поломает код, который ты напишешь сегодня, но не факт. Если тебя волнует производительность, то можно упомянуть осложнения работы с указателями, которые приводят к тому, что сложнозаморочные структуры данных в памяти создавать сложно и заморочно. Если тебе это реально интересно, я могу найти ссылку на реп, где мужик пилит аналог libxml2 на расте: он поставил своей целью создать реализацию, которая будет не медленнее libxml2, некоторое время потыкался, и перешёл на raw-указатели для организации структур в памяти. То есть на указатели, которые являются полными аналогами указателей в C. Я сам не вчитывался в его код (надо будет как-нибудь на досуге), но издалека я не вижу в чём прикол писать это на rust'е. И во всяком случае это показывает ограничения раста.
Но вместо этих _реальных_ замечаний в отношении раста, ты мне несёшь какой-то бред про проверку на выход за границы массива, не имея за этим бредом никаких аргументов. Ты пойми, если ты приведёшь мне сейчас кусок кода на rust'е, из которого rustc не сможет выкинуть проверку на выход за границы массива, которую следовало бы выкинуть, я буду _очень_ рад. В отличие от тебя, я люблю когда мне доказывают, что я не прав, потому что это приводит к тому, что я самым беспринципным образом изменяю своё мнение, и в следующий раз моим оппонентам становится ещё сложнее доказать мне, что я не прав. Поэтому не стесняйся, напиши здесь неоптимизируемый код на rust'е.
