А скажите пожалуйста, ну вот в Java как известно это впервые было сделано - контроль границ массива нельзя отключить - это было сделано для безопасности. Потому что в C++ где этой проверки нет вообще, - огромное количество дыр в безопасности приложений в связи с этим, и для их выявления используются очень сложные методы.
Вы же с легкостью говорите, что я оттестировал - значит, не упадёт в Release. Откуда такая уверенность? И если упадёт, то может эта оптимизация не стоит безопасности?
Ну так сделайте спецификацию языка и реализуйте свой компилятор - и будет Вам счастье! А так получается, что Вы критикуете существующую реализацию и даете предложения, даже не зная, как там оно внутри устроено и какой кровью отольется эта “оптимизация”.
Вы с Фортраном не перепутали? Это там “убогий синтаксис” и высокая производительность. Которая в С/С++ и не снилась. Не пожалейте времени, взгляните в сторону того же Fortran 95, напишите на нем что-нибудь более-менее сложное по работе с массивами и увидите, как он легко “уделает” Ваши самые фантастические экзерсисы с С/С++, пусть там сто раз будут указатели. Да он сам написан на С, но писали его в фирмах, отдавших этому десятилетия и оптимизация там настолько “вылизана”, что простому смертному с улицы такое и за годы не написать.
Естественно, иначе бы эти языки давно были на помойке истории. Но сильные стороны С - это драйверы и компоненты операционных систем, С++ - большие ООП проекты, но уж никак не вычислительная математика. Ну не для того их разрабатывали.
“Настоящие программисты не используют Паскаль”
Настоящие программисты не используют Паскаль — эссе о программировании, которое написал Эд Пост (англ. Ed Post) из орегонской компании Tektronix. Оно было опубликовано как письмо редактору (англ.) в 29-м томе 7-го выпуска журнала Datamation в июле 1983 года.
Источник: Википедия.
компиляторы с проверкой границ массива; эти компиляторы душат творчество, запрещая наиболее интересные варианты оператора EQUIVALENCE и препятствуют модификации операционной системы с помощью отрицательных индексов массивов.
Именно!
Уже множество раз было сказано, что эта оптимизация ВКЛЮЧАЕТСЯ ДИРЕКТИВОЙ, то есть это осознанный выбор программиста. Если программа была множество раз протестирована, то с чего ей падать? Даже более того, выход за границы массива - далеко не самая большая и опасная дыра в безопасности. Кроме того, как правило, очень большие объёмы работ над массивами описываются простым кодом. Если программист косячит даже там, то он не совсем программист.
Всё к этому идёт. Хороший совет.
Боюсь, что это Вы не совсем понимаете последствий. Никакой катастрофы не будет. Буквально вчера разгребал ошибку с указателями в своей программе на C#. Представляете, небо не упало на землю, а марсиане не попытались захватить мир. При попытке залезть в системную память, сразу же прерывается выполнение и выдаётся исключение. .NET в любом случае не позволит напортачить. А Вы путаете CLR и процессор, что очень печально…
Поинтересуйтесь возрастом языка C/C++. На нём все компании пишут высоконагруженные системы. И Google и Yandex. Все. От мала до велика. Или Вы считаете, что там идиоты сидят, не знающие истины? Вам, кстати, никто не мешает предложить им перейти на Fortran. Я уверен, что после объяснения Вам положения каждого из языков, Вас попросят удалиться, причём не в самой вежливой форме.
А для чего же?
Вы не путаете высоконагруженные системы с вычислительной математикой? По-моему, путаете.
Если Вы не знаете даже этого, то предмета для обсуждения нет, ибо бесполезно.
С чего бы такое заключение? В общем, еще раз понятно, что бесполезно.
Да Вы просто крутышка, оказывается! Супер-пупер программист. Ну и оставайтесь им дальше)))
По моему вы слишком жестоко и предвзято относитесь к этой идее, если вам не нравится - не пользуйтесь директивой, никто от этого не пострадает. Если считаете что это сложно реализовать - пусть @Gleb делает, просто объясните что можно а что нельзя трогать. Кроме того, 20% это не мало, и в отличии от большинства мест (как Graph3D в котором постоянно принимаются худшие, по оптимизации, решения), массивы - это единственное что как ни крути, но придётся использовать, поэтому их оптимизировать надо всё же в первую очередь.
Путаете, Вы. Я ни разу не говорил про вычислительную математику.
Хотел бы услышать Вашу версию. Петросян то по ТВ не скоро появится.
Процессор выполняет тот код, который ему дадут. CLR при этом может производить оптимизацию и защиту. Вы разницы не видите.
Вы уверены, что это “просто”?
Если в ядро проекта полезут случайные посторонние люди, я буду в первых рядах тех, кто навсегда откажется от PascalABC.NET
Лучше бы Вы уже сейчас отказались от использования и позволили сделать хороший, эффективный современный язык.
“Остапа несло…”
“Детка, если ты будешь дальше продолжать в том же духе, я отберу у тебя и погремушку, и соску.”
Для этой фичи не надо анализатор кода, только разворачивать то что есть в другое выражение. с гитхабом проконтролировать что именно было изменено не составит труда. И ещё, проект открытый и задумывался с тем что помогать его разрабатывать будут все заинтересованные. Я не говорю про то чтоб сделали кашу из хотелок, всё надо контролировать всё равно.
Вы постоянно бракуете все предложения, касающиеся существенного улучшения языка. Вам не нравятся современные конструкции, Вы не хотите оптимизации… Почему бы Вам не начать писать сразу машинный код для лампового компьютера?
Перешли на прямое хамство? Ну, ну…
Ну Вы то тоже не особо мягко начали выражаться.
Но это не значит, что туда можно, как в помойку, сливать все, что угодно. Открытый проект означает, что Вы можете брать код и переделывать его для СВОИХ нужд. Либо давать советы разработчикам по совершенствованию этого кода, а примут они эти советы или нет - их личное дело. И не более того.
Если честно, то Вы не заинтересованы в улучшении языка.
Вам известно, как работает GitHub? То, что проект открытый, ещё не значит, что в репозиторий может вносить изменения кто угодно.
А МЫ РАЗВЕ НЕ ЭТИМ ЗАНИМАЕМСЯ?
Если бы это была личная переписка, я бы ответил, чем Вы занимаетесь. А тут даже эвфемизм не спасет от цензуры, так что промолчу.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021