Да чем уж больно плюсы сложнее? Шаблонная магия? Без неё можно обойтись практически всегда. А что ещё? Указатели разве что - но ведь есть ссылки, да и что сложного в указателях? В дэльфи ведь они тоже есть. И новичка совсем не обязательно сразу кидать в работу с памятью - на первых порах можно жить и без указателей. Такие примеры из разряда эзотерики, типа такой: Код (C): i++ + ++i Их можно на любом языке составить, в реальности всё равно такого непонятного ужаса не будет. До перехода на LLVM дэльфи довольно умело юзал SSE, выдавая достаточно хороший код. Да, без чудес, которые выдают gcc/icc/msvc, но уверенный середнячок. Сложную математику я бы на нём писать не стал, выбрав Intel C++ с его AVX'овыми оптимизациями, но для задач фронтенда и работы с сетью (скачивание файлов, запросы к скриптам), где оптимизации кода практически никакой роли не играют, дэльфовый компилятор подходит хорошо. А с переходом на LLVM, думаю, с оптимизациями стало совсем хорошо. "Думаю" - потому что не смотрел, дэльфи не установлен, чтобы проверить. Но ведь мы именно это и обсуждаем. Я и на плюсах видел огромное количество ужасных поделок. Зайди на unknowncheats. Посмотри, как люди пишут драйвера для читов. Там у них и IRQL не соблюдается, и CR0.WP сбрасывают на PASSIVE_LEVEL без привязки потока к ядру, и память течёт рекой. Ну и что теперь, плюсы тоже запишем в язык для говнокодеров? Про то, что сейчас не надо знать архитектуру - к сожалению, да, практически ни в каких задачах, кроме сугубо системных, в её знании нет необходимости. Да, если знаешь, как система и процессор работают внутри, ты сможешь чуть оптимальнее писать код. Возможно, где-то применишь оптимизации, специфичные для процессора, и получишь +10% скорости. Но реальной необходимости в глубоком понимании системы нет - и языки стремятся ещё больше снизить порог вхождения в разработку. И это правильно: время программиста ценнее времени компьютера. Хоть я и люблю низкоуровневый кодинг, но посмотри, как удобно писать на джаве: ^ Просто читаем конфиг из Yaml-файлика. Не надо задумываться о памяти, не надо вообще думать о посторонних вещах (даже о чтении самого файла!): у тебя есть модель - ты тут же перекладываешь её на код. Только то, что тебе действительно нужно. И представь, сколько места заняло бы то же самое на плюсах. И как сильно плюсовый код потерял бы в наглядности. Именно такими должны быть языки - удобными, простыми и понятными. И не важно, что приложение будет весить не 10 килобайт, а 20 мегабайт. И пусть на таких языках будут школьники писать свои кривые поделки - это уже совершенно не важно. Главное, что ты сможешь кратчайшим и приятным путём решить свои задачи, не отвлекаясь на то, что вообще не должно тебя касаться. --- Сообщение объединено, 4 авг 2019 --- Подписываюсь под каждым словом!
HoShiMin, > Не надо задумываться о памяти, не надо вообще думать о посторонних вещах Отказ от указателей это очень старая парадигма, в частности VB. Задачи обхода защиты никто не снимал. В 10 кб кода найти уязвимость куда сложнее, чем в 20 мб. Защита нт проработана очень хорошо, но есть иные архитектуры, где система не заблокирует атаку.
Но ведь это очень узкоспециализированная область. Задачи вирусологии - это капля в море всех возможных задач. И даже нельзя сказать, что какие-то задачи более "серьёзные", чем другие. Ведь написать хороший балансировщик для серверов - задача не менее сложная, чем реверсить накрытый VMProtect'ом бинарник. Или нарисовать и сверстать красивый дизайн с продуманным UX. Чем эта задача хуже задач поиска уязвимостей? Ничем, ведь она так же нужна, потому что люди хотят работать в красивом и удобном окружении. Поэтому, все языки - просто инструменты для своих задач и плохих (и, тем более, "школьных") языков просто нет. А те же школьники, которые сегодня путаются в указателях и допускают какие-то глупые ошибки, создавая очевидные уязвимости, завтра наберутся опыта и станут синьорами, создавая продукты, на которые будет равняться весь IT-мир.
HoShiMin, > люди хотят работать в красивом и удобном окружении. Малварь кругом, она везде. А как только есть хоть какой то шанс успешной атаки, то он сразу используется и ищется огромным числом людей, так как это чистые бабки. Вот и получается что апп построенное такими специалистами" из г&п уверенных в том, что кроме скрипта ничего не нужно - являются источником уязвимостей и дохода. Разумеется юзерам это знать не нужно, их нужно убедить гуем что какой то говнософт является защитой.
Ну что ж теперь, вообще софт не писать? От языка здесь уже ничего не зависит, а в крупном софте неизбежно будут баги, и их будут фиксить, и будут находить новые. Да и много ли ты получишь, найдя переполнение буфера в каком-нибудь фотошопе? Что туда будешь инжектить? А какие-то критичные системные компоненты - опять же, узкоспециализированная область. --- Сообщение объединено, 4 авг 2019 --- Кстати, поддержку IOPL и IOPM сделал ещё в далёком 2015м и именно для синтезатора. Всё думал, вот перепишу его на прямую работу с портами, и вот уже 2019й, а воз и ныне там. И даже когда начал писать Kernel-Bridge, первым же делом написал набор функций для отдельной работы с пищалкой и портами. Почему-то, низкий уровень ассоциируется именно с такой незатейливой работой с железками. Или, может, просто ностальгия...
Ну блин, 50 минут на английском! Пролистал несколько слайдов - скорей всего, новичок если и столкнётся с этими случаями, то гораздо позже, когда уже приобретёт какой-то опыт. А скорей всего, не столкнётся вовсе. Например, значения неинициализированных переменных. Я даже не задумывался, в каких случаях чему они равны. Просто по-умолчанию считал, что там мусор, в каком бы месте программы они ни стояли. То есть, такие тонкости, которых если не знаешь - ничего катастрофического не случится. В данном конкретном случае, если новичку сказать, что в переменных до инициализации всегда будет мусор, меньше новичок понимать не будет. Не обязательно его сразу погружать в детали, что если переменная вот тут, то будет ноль, а если вот тут - что-то ещё. Даже безопаснее - меньше ошибок сделает, если не будет полагаться, что в переменной что-то лежит. И сама конференция эта явно не для тех, кто C++ первый раз в руках держит. А уж если даже профи с интересом узнают такие тонкости, то новичку сразу их знать точно не обязательно. Да и в любом языке хватает неочевидных деталей, но на порог вхождения они не влияют. А порог вхождения - это с ходу написать какой-нибудь хеллоу-ворлд, что-то посчитать, написать функцию, поработать со строками - всё это одинаково легко делается и в дэльфи, и в плюсах, да и на ассемблере, чего греха таить. Тот же FASM разобрал за один день: на ныне мёртвом fasm.su были туториалы, где первый же урок начинался с выдвигания дисковода на асме. А на втором уроке мы уже создавали гуёвое окошко. Так что... Нет ничего сложного, если есть желание.
Ты виксы путаешь с проф. малварью == виксы упражняются в красоте уязвимости кодов. А проф. малварь исходит из психики юзеря. от виксов же в полях толку особого нет, пч нет должной устойчивости в их работе.
50 минут фактов о твоем уютненьком языке, которых ты не знал... смотреть или нет - твое дело... ничего катастрофического не случается в твоем мелком проекте, который кроме тебя никому не нужен... в коммерции получается по-другому: компания нанимает обезьян, которые не знают о таких "тонкостях", они кодят гуан, незадумываясь о таких "тонкостях", потом за пару дней до релиза всплывает удивительный баг, который никто не может толком найти и отдебажить потому, что никто не знает о таких "тонкостях"... например я был тим лидом, которому пришлось сутки напролет сидеть и выуживать баг, который в свете неопределенного поведения появлялся только при включенных оптимизациях... само собой в реальной жизни на предложения шипить дебажную версию, которая работает, тебе просто посмеются в лицо... с тех пор я стараюсь с большими проектами на плюсах не иметь ничего общего... в дельфи таких вещей в разы меньше, чем в плюсах... если нет, то скинь мне видео об этом на 50 минут, я его посмотрю, ради саморазвития...
а как тебе это удаётся? главное выщимить модуль/и, с коего баг проистекает. А затем можно рассматривать возможные опции == к примеру, сборка капризных модулей без оптимизации, второй вариант == сборка другим компилем. так скоко проектов в делфях было и скоко в си/си++? при правильном поиске можно найти все проблемные модули и потом искать причины. в самом начале докладчик говорит об отсутствие начальной инициализации переменных == сразу возникает Вопрос: А ПРИ ЧЁМ ТУТ С++??? в любом языке для предсказуемости алго нужно делать явное присвоение значений всем переменным до их использования. единственный случай, когда сий закон можно не исполнять, это когда переменная выполняет роль буфера. Тогда её начальное значение не делает погоды от слова СОВСЕМ.
из этого можно сделать только один вывод - ты никогда не работал в больших проектах на плюсах... но при этом поспорить на форуме о том, чего не знаешь - милое дело... что в принципе норма для васма... не работаю со всякими гуано-организациями, которые застряли в 90ых... это не имеет никакого отношения к неопределенному и неспецифированному поведению в стандарте языка... научить правильному поиску равносильно научению всех тех "тонкостей", о которых я говорил...
вывод тут один == уровень кадров идёт вниз, поэтому возникают проблемы, о коих ты говоришь куча базовых кодов как раз-таки из тех времён и новомодные фреймворки ничего нового не тащат. компилей с полным соответствием стандарту япа не бывает, да и не может быть. Тем паче если сборка идёт с опциями оптимизации + использование кодов третьей стороны не улучшает ситуацию. нет, поиск указывает модуль, точку модуля и входные данные, при коих получается ошибка. Дальше ужо идёт разбор причины получаемой ошибки. доскональное знание стандартов япа во множестве случаев будет абсолютно бесполезным, пч эти стандарты описывают сферический компиль в вакууме.
нанимать обезьян дешевле, но при этом организации по какой-то неведомой причине заставляет их кодить на сложных языках, где достаточно просто стрелять себе по ногам... как бы стандартная библиотека Rust'а, как и тысячи библиотек этого языка написаны только на расте и не тянут зависимостей от сишного/плюсового кода... как бы GNAT компилятор полностью соответствует спецификации языка Ада, так же как GCC полностью соответствует стандарту C/C++... если компилятор не соответствует стандарту языка, то этот компилятор никто не будет использовать... проблема в том, что в стандарте сишечки и плюсов есть такие понятия, как неопределенное поведение... а у хороших языков таких понятий в стандарте нет... стандарты описывают семантику языка, компилятор не имеет права не соответствовать этому описанию...
я не об этом == тот же раст не тянет с собой новых функций (кои нельзя найти в с/с++) и/ль лучшего качества кода на выходе компиля. А вот пример мукЪ с этим самым растом https://hackernoon.com/why-im-dropping-rust-fd1c32986c88 кстати, шарой популярности тожЪ похвастать не может https://www.tiobe.com/tiobe-index/ неопределенность поведения далеко не только от стандарта зависит, но и от железки. к примеру, переполнение целочисленной переменной, округление плавающей запятой, закидоны многопоточности итд-итп. с/с++, однако, можно обвинить в довольно чудаковатом синтаксисе.. Код (Text): begin end смотрится гораздо информативней, чем Код (Text): { } иль "not x" гораздо лучше, чем "!x". если ж вернуться к "неопределенному поведению", то тута не столько вопрос используемого япа, сколько качество прописи самого алго == явная инициализация переменных, явное управление ресурсами. вопросы обратной совместимости, баги, смешанный код == усёго в стандарты не впихнёшь. так в этом и была главная ошибка "дружелюбных" япов == нужно дотягивать публику до приемлемого уровня, а не пытаться создать некую вапшебную тулзу для дураков.
Коллеги, если рассматривать делфю, как фронт, имеет смысл гнаться за свежими редакциями или стоит взять какую-то постарее?
Стоит, конечно. Новее - значит, лучше. Во всех смыслах: исправлены баги прошлых версий, введены новые фичи, новые оптимизации. Сам по себе вопрос странный - зачем брать старое, если есть новое?
ну-еть очень-очень спорное утв.. "исправлены старые баги" совсем не значит, что не появилось новых. "новые фичи" совсем не значит, что они являют собой особую ценность. "старая" версия ужо ценна тем, что под неё имеется богатая база сорцов/ртфм/манов. правильный ответ == нужно держать под рукой разные версии той же делфянки и ужо по ходу делов будешь видеть, что тебе нужно, а что не очень, и что совсем да никак
Дэльфи славится обратной совместимостью, все эти маны справедливы и для Delphi 7, и для новейшего 10.3.2. А новые баги - да, случается, но старых всё равно исправляется больше - достаточно взглянуть на changelog. Я вообще сторонник использования новейшего софта, использую и Chrome Canary, и инсайдерскую визуалку. Новшества важнее.
на обратную совместимость лучше лишний раз не полагаться "новое" -- еть очень спекулятивное понятие == если вещь изначально делается с прицелом на качество, там нет и не может быть чего-то реально ультра-нового от версии к версии. к тому же, весь софт делается по модульному принципу, то бишь исправление багов/добавка и/ль обновление фич носит сугубо локальный характер. да, и положительность любого обновления тоже не есмь абсолют. Однако, маркетинговые приёмчики пихают тебе "новый" софт скопом, что создаёт иллюзию массированного прогресса. это тоже довольно действенный маркетинговый приём
Gideon Vi, зайчик, помни о проксе ^^ https://exelab.ru/f/index.php?action=vthread&forum=2&topic=18414
