Судя по вашему ответу вы мебель в иномарке кабриолете возите… А мешок картошки только складываете в багажник мерседеса… Это называется «Вася не учился в автошколе, но купил себе феррари и разбился...» Про скоростной режим в дождь ничего не слышали? Чем лучше пилить дерево бензопилой или лобзиком?
В языках программирования, на которых мне приходилось писать, везде есть UB. Глубоко сомневаюсь, что UB нет в haskell и там нельзя выстрелить себе в ногу.
В случае с bash тут безграмотность на лицо и не знание техники безопасности, обработки исключений, и правильного написания кода.
Простой пример, вы взяли бензопилу спилить дерево, не зная техники безопасности и правил работы с бензопилой приступили к работе, в итоге бензопила отскочила и отрезала вам ногу, или дерево упало вам на голову. Кто виноват Бензопила!??? Дерево!??? Вы сами? Значит ли это, что бензопила плохая и не безопасная? Подходит ли бензопила выкручивать шурупы? А можете ли вы спилить дерево отверткой?
sergio_nsk человек про потенциальные проблемы написал, ниже вам правильно ответили.
По коду сразу понятно, что человек просто не владеет shell скриптом и программирует на другом языке, так не делают люди, которые пишут хорошо скрипты и майтейнерят крупные сервера, программы, и линукс дистрибутивы. Уже не однократно писал на хабре про обработку исключений в shell скриптах, как обычно в скрипте их, отсюда куча проблем. Почему-то в нормальных языках исключения обрабатывают, а в shell про них просто забывают. В shell немного другая логика чем в привычных языках программирования, некоторые вещи с виду и без опыта делаются не удобно и не стоит шуроповертом пытаться забивать гвозди, у bash только одна основная функция автоматизация выполнения команд, куда еще для удобства входят конвеерное выполнение команд и потоковое редактирование. Когда говорят про безопасность bash это такая же ересь, как к примеру сказать, что на R нельзя написать десктоп приложения и синтаксис его не удобен и поэтому язык плохой, там нет безопасности, и он не создан вообще для сложных приложений. Shell скрипт так же как R заточен строго под свои функции и синтаксис их для этого создан. Вы когда нибудь программировали на R?
Насчет стандартов они не всегда поддерживаются компилятором, даже недавно где-то читал статью, что ради производительности компиляторы не спешат добавлять поддержку некоторых функций новых стандартов C++, и что в приоритете у них производительность. Да и есть к примеру самый известный ключ оптимизации -ffast-math, который в угоду производительности частично отказывается от совместимости со стандартом. К примеру про алгоритм разворачивания циклов, который в gcc 9 добавили по умолчанию, а до этого он включался ключем оптимизации, слышал, что он тоже нарушает стандарт. В любом случае оказался прав, асм листинг при использовании массива был в раза 1.5 короче, и работает примерно на 1% быстрее.
Действительно это так, жизнь объектов созданных new не должна заканчиваться при выходе, иначе теряется весь смысл указателей. Так в примере она же локальная и указатель никуда не передается, в таком случае мы просто получим утечку памяти.
Компилятор может как угодно оптимизировать код, тут никто не знает.
Могу предположить, что может использоваться inline для new. Это лишь предположения, что вполне возможно такое поведение с современными компиляторами, не давно с людьми смотрели как GCC развернул циклы и как LLVM, люди с опытом, которые занимаются написанием компиляторов не могли понять, что делает GCC и как оптимизировал код. LLVM посчитал цикл бесконечным и не смог развернуть, GCC его развернул и выплюнул очень длинный ассемблерный код. Как итог GCC был значительно быстрее и это с дефолтными настройками.
1. Это была опечатка, указатель на массив.
2. Компилятор может как угодно оптимизировать код, тут никто не знает. Сейчас компиляторы значительно умные, и там может быть что угодно, зависит от реализации. Все правильно new изначально размещал всегда в куче. Если указатель далее никуда не передается, то компилятор вполне может предсказать поведение. Предлагаю вам взять несколько современных компиляторов и разобрать ассемблерный код на выходе.
3. Когда даже не константа, если размер стека нам позволяет, то мы можем выделить нужный размер и сместить указатель на вершину стека.
4. Все то, только поведение зависит от компилятора и ключей оптимизации. Что на выходе будет предсказать сложно, новые компиляторы оптимизируют агрессивнее.
Грубая ошибка для C++. Много где встречал, что это является плохим тоном. Для базовых числовых типов не желательно использовать массив из указателей и использовать new, если переменная локальная! Основная проблема, что при указателях C++ может разместит массив в куче, а не в кэше(на стеке), отсюда алгоритм может потерять в скорости. Но посмотрел плюс минус скорость одинаковая при размере 100000, и видимо компилятор все же оптимизировал код, но с указателями примерно на 0.2с медленее(не смотрел почему, но некоторые компиляторы все же добавляют разименовывание указателя). Правильно для локальных массивов делать:
cbelkin математический алгоритм генерации случайных чисел с нужным распределением, на java отрабатывает 2.5с, на C++ с O2 оптимизацией под Linux 4.1с, на Windows с O2 — 6.3c, на NodeJS 5.2c. Да развиты, но не всегда идеально кэшем пользуются и не всегда могут развернуть циклы. На самом деле, еще скорость зависит от реализации стандартной библиотеки. Факторов много. Вот к примеру отправил pastebin.com/rhpWvssR в багрепорт LLVM, почти в 1.6 раз медленнее GCC, LLVM не может развернуть полностью цикл. Пишут виртуальные машины, люди, которые понимают C, C++ и компиляторы, лучше чем 90% программистов C++ и С. Они еще знают все популярные алгоритмы и пишут отдельно оптимизации кода под компиляторы и платформы. Это тот уровень к которому надо всем стремиться так как они делают просто чудеса. Сейчас JVM и NodeJS мягко говоря подтирают попу за слабыми программистами, сглаживают и даже прощают их грубые ошибки. Основной минус в скорости NodeJS и JVM это сборка мусора, если лишний раз ее не тригерить, то можно приличных скоростей добиться. Переписав алгоритм и минимизировав сборку мусора, даже на JS реально добиться существенного ускорение алгоритма. У NodeJS еще минус нет строгой типизации, отсюда есть оверхед — дополнительная проверка переменных. На личном опыте знаю, что не сложно добиться отличных скоростей на любом языке, главное знать как и понимать его особенности. К примеру кто пишет браузерные игры, они знают, что если взять к примеру анимацию с частотой кадров 30 кадров в секунду, то один кадр — страница должна рендериться менее чем за 30мс, иначе анимация будет дерганная. Поэтому там строго лишний раз не тригерят изменения стилей и сборку мусора, правильно используется подготовка кадров в циклах, иначе легко улететь более чем за 1с на отрисовку одного кадра, что происходит на большом количестве сайтов, и еще бывает тормозят они на мобильных устройствах.
dwdraugr причем тут полубог? Бессмертными богами считают себя люди, которые не читают документацию, но с пеной у рта пишут, что bash не безопасный язык программирования и при этом не понимают самых простых вещей. Подобные вещи из unpredictable behavior описываются в документации, и на нормальных курсах по программированию. Даже есть специальные задания на курсах по программированию на тренировку подобных кейсов. Такие вещи есть не только в shell скрипте, а во всех языках. Часто при трудоустройстве в солидную компанию, есть задания на понимание их и вас просто не примут, если вы их не знаете! С опытом такие вещи сразу бросаются в глаза, потому что это не какая-то супер сложная ошибка, а самая простая и детская. Конечно в шараж конторе ушатать сервер может вам сойдет с рук, но если убьете кластер в крупной компании, с вас за убытки могут взыскать очень приличную сумму и трудовую вам напишут не приятную запись, с которой вас почти никуда не возьмут… Да и best practice это использовать shellcheсk.
Совершали ли вы опасные ошибки при написании shell-скриптов?
Конечно, не совершает ошибок только тот кто ничего не делает. И сервера удаленные убивал и систему на рабочем компе. Правда было это лет 20 назад. Наверное самые распространенные грабли на которые наступал, это были правила файервола на удаленном сервере.
Это не C программист писал, а какой-то PHP гавнокодер. Нормальный кодер сразу видит и понимает потенциальные проблемы кода. Про что статья, я писал практически под каждым постом про shell скрипт, какие проблемы могут возникнуть и как от них защититься. Но тут на хабре действительно больше гавнокодеров, чем думающих и практикующих, и меня тупо заминусовали люди, которые не пишут правильно скрипты. Такое ощущение, что люди никогда даже в глаза официальную документацию не видели.
Речь про некие оболочки для админских задач, возможно, интерактивных из консоли.
С каких пор непревилегированные пользователи выполняют админские задачи?
Вам не кажется, что тут проблемы в архитектуре приложения, но никак не в шелл скрипте?
Такое количество кода поддерживать ничего сложного. Проблема не в количестве кода, а что архитектор приложения мудак. Такие вещи предусматриваются на этапе проектирования. Как правильно делать такое, уже ниже отписал. У меня есть скрипты в тысячи строк. Нет ничего не реального…
Есть сервер. На нем есть непривилегированные пользователи. Скрипт запускается либо со sticky bit/suid или чем-то подобным, либо прописан в sudo у пользователя на исполнение.
Это называется архитектор мудак. Можно уволнять. Запускать шелл скрипты через вебсервер это сверх извращение. Для выполнения задач от вебсервера где-то видел используют perl скрипт, но самое правильное пишется сервер с FIFO очередью(команды могут выполняться долго, вебсервер не может ждать выполнения, и должен быстро вернуть страницу на запрос), который будет принимать, валидировать и выполнять сообщения от вебсервера. bash это обычный язык сценариев, не надо молотком шурупы закручивать!
Вполне приличный скриптовый язык сценариев, ни больше ни меньше. Автоматизировать работу вполне удобно, хоть мне знакомы с десяток языков программирования и опыт программирования около 25 лет, для своих целей shell скрипт хорошо подходит. Вам никто не мешает переписать скрипт например на perl или любой другой язык. Вы всегда шуроповертом гвозди забиваете и утверждаете, что это плохой инструмент? Выстрелить в ногу можно в любом языке, все претензии не языку, а к автору скрипта, что он мудак и не смог нормально написать. С дуру даже коего чего можно сломать… Гавнокодеров в любом языке программирования полно.
Полностью согласен. Такое ощущение, что люди официальную документацию никогда не читали, и все поведение давно уже описано. Делают непонятные открытия туалетной бумаги в своих статьях вместо газеты, и всем пытаются о ней рассказать. Что все давно уже используют туалетную бумагу их не волнует…
ntsaplin открою секрет, несколько топовых авторов с большим количеством постов, продают инвайты и так же голоса накрутки, видимо создали сетку аккаунтов. Так же на хабр есть просто замечательная функция поощряющая накрутку и называется она «Программа Поощрения Авторов», с одной стороны штука хорошая, но так как некоторые авторы фултайм заняты постингом статей на хабр, то они живут с этого и как говорится грех себе не помочь, чтобы не сидеть месяц у пустой тарелки…
Была бы еще защита от накрутки, крупные компании были не раз замечены в накрутке голосов, в комментариях не редко срач и только негативные комментарии на публикацию, а автор еще пытается хамить на правильную критику, но самое интересное у таких людей и у статей репутация растет на хабре, когда мигом должны были бы увести в минус, да и статья мягко говоря слабая и автор больше пиарится, чем пользу хочет принести…
В случае с bash тут безграмотность на лицо и не знание техники безопасности, обработки исключений, и правильного написания кода.
Простой пример, вы взяли бензопилу спилить дерево, не зная техники безопасности и правил работы с бензопилой приступили к работе, в итоге бензопила отскочила и отрезала вам ногу, или дерево упало вам на голову. Кто виноват Бензопила!??? Дерево!??? Вы сами? Значит ли это, что бензопила плохая и не безопасная? Подходит ли бензопила выкручивать шурупы? А можете ли вы спилить дерево отверткой?
По коду сразу понятно, что человек просто не владеет shell скриптом и программирует на другом языке, так не делают люди, которые пишут хорошо скрипты и майтейнерят крупные сервера, программы, и линукс дистрибутивы. Уже не однократно писал на хабре про обработку исключений в shell скриптах, как обычно в скрипте их, отсюда куча проблем. Почему-то в нормальных языках исключения обрабатывают, а в shell про них просто забывают. В shell немного другая логика чем в привычных языках программирования, некоторые вещи с виду и без опыта делаются не удобно и не стоит шуроповертом пытаться забивать гвозди, у bash только одна основная функция автоматизация выполнения команд, куда еще для удобства входят конвеерное выполнение команд и потоковое редактирование. Когда говорят про безопасность bash это такая же ересь, как к примеру сказать, что на R нельзя написать десктоп приложения и синтаксис его не удобен и поэтому язык плохой, там нет безопасности, и он не создан вообще для сложных приложений. Shell скрипт так же как R заточен строго под свои функции и синтаксис их для этого создан. Вы когда нибудь программировали на R?
Вот примерно как делается правильно:
Могу предположить, что может использоваться inline для new. Это лишь предположения, что вполне возможно такое поведение с современными компиляторами, не давно с людьми смотрели как GCC развернул циклы и как LLVM, люди с опытом, которые занимаются написанием компиляторов не могли понять, что делает GCC и как оптимизировал код. LLVM посчитал цикл бесконечным и не смог развернуть, GCC его развернул и выплюнул очень длинный ассемблерный код. Как итог GCC был значительно быстрее и это с дефолтными настройками.
2. Компилятор может как угодно оптимизировать код, тут никто не знает. Сейчас компиляторы значительно умные, и там может быть что угодно, зависит от реализации. Все правильно new изначально размещал всегда в куче. Если указатель далее никуда не передается, то компилятор вполне может предсказать поведение. Предлагаю вам взять несколько современных компиляторов и разобрать ассемблерный код на выходе.
3. Когда даже не константа, если размер стека нам позволяет, то мы можем выделить нужный размер и сместить указатель на вершину стека.
4. Все то, только поведение зависит от компилятора и ключей оптимизации. Что на выходе будет предсказать сложно, новые компиляторы оптимизируют агрессивнее.
Грубая ошибка для C++. Много где встречал, что это является плохим тоном. Для базовых числовых типов не желательно использовать массив из указателей и использовать new, если переменная локальная! Основная проблема, что при указателях C++ может разместит массив в куче, а не в кэше(на стеке), отсюда алгоритм может потерять в скорости. Но посмотрел плюс минус скорость одинаковая при размере 100000, и видимо компилятор все же оптимизировал код, но с указателями примерно на 0.2с медленее(не смотрел почему, но некоторые компиляторы все же добавляют разименовывание указателя). Правильно для локальных массивов делать:
Вторая причина компилятор может векторизовать циклы при работе с массивом, а с указателями нет. Тут подробно расписано.
stackoverflow.com/questions/2305770/efficiency-arrays-vs-pointers
Третья причина при выходе из функции массив автоматически удалится.
Конечно, не совершает ошибок только тот кто ничего не делает. И сервера удаленные убивал и систему на рабочем компе. Правда было это лет 20 назад. Наверное самые распространенные грабли на которые наступал, это были правила файервола на удаленном сервере.
С каких пор непревилегированные пользователи выполняют админские задачи?
Вам не кажется, что тут проблемы в архитектуре приложения, но никак не в шелл скрипте?
Это называется архитектор мудак. Можно уволнять. Запускать шелл скрипты через вебсервер это сверх извращение. Для выполнения задач от вебсервера где-то видел используют perl скрипт, но самое правильное пишется сервер с FIFO очередью(команды могут выполняться долго, вебсервер не может ждать выполнения, и должен быстро вернуть страницу на запрос), который будет принимать, валидировать и выполнять сообщения от вебсервера. bash это обычный язык сценариев, не надо молотком шурупы закручивать!