Плешивому деду, похоже, что и не нужны специалисты. Он про этот ваш ЫнтЫрнет-то лишь по наслышке от нужных органов знает. Ему бабушки нужны, которые носочки будут вязать (недавно с трибуны так и говорил).
В этом есть только одна серьёзная проблема. Молодые дурачки часто даже без профильного образования, наслушавшись каких-нибудь блогерных идиотов или только лишь в погоне за сиюминутной модой, повторяют глупые мантры про смерть Паскаля (или ещё какого-нибудь языка), и при этом сами тратят время лишь на скриптовые и жутко тормозные убожества типа Питонов. Я ещё понимаю, если бы они все при этом на Си/C++ или новомодном Rust умели писать, но в подавляющем количестве случаев нет ;) Ну а в результате просто мало специалистов осталось по этой весьма ПРАКТИЧНОЙ для ряда задач с прагматичной точки зрения технологии.
Хотя, Паскаль в том же TIOBE даже сейчас на 10-м месте держится, а про кучу промелькнувших за десятки лет “новомодных” языков уже давно и позабыть успели :D
Ну лично я от паскаля в виде Lazarus пока отказываться не собираюсь. НО не для интерфейсов, а для очень быстрого компактного и непрожорливого бэкенда.
Если эту среду использовать с умом, то результат получается не на много медленнее чем на Си/С++, НО в десятки раз быстрее всякого скриптового г-на (см. mORMot ). При этом писать в разы легче, чем на Сях, ошибку допустить существенно сложнее, никаких тонн библиотек или фреимворков тащить не надо, тормозов от сборщика мусора нет, при большом желании можно хоть до ассемблера опускаться (включая ARM) и работать и отлаживать код можно уже хоть на "чайнике". На ARM встройке у меня всё работает и даже отладка через IDE. Размеры полностью самодостаточных исполняемых фалов по современным временам копеечные - у меня ~5 мегабайт.
За светлое будущее Delphi не скажу, но там народ вроде даже активно под мобилки какие-то коммерческие поделки стал писать на FMX и вроде им давно обещают WebAssembly подвезти.
В нашем разговоре пока что вы являетесь хз кем и хз умеете ли вы вообще код писать.
Ну со свой-то стороны в вас я вижу обычного "территориального охранника", просто тупо защищающего "хозяйскую территорию" из своей "будки", по принципу что доверили, то и будем защищать и "облаивать" всех, кто посягнёт на "святое" :D Ну или вам поговорить не с кем.
Я вам уже всё объяснил за своё использование C++ и за причины такового. Это просто много математики, связанной с обработкой, фильтрацией и т.п сигналов. Свой код я вам показывать не обязан, как и вашего не прошу, пока мало ли на собеседование не придёте (мир тесен).
Кстати, лет десять тому назад ради интереса даже проверяли алгоритмы на компиляторе Фортрана от Intel - и кое что даже считалось ещё быстрее, чем на C++. Но на Фортране оставлять это в современном продакшене - это уже страшно. Никто не поддержит потом.
Нравится вам современный C++ - да пожалуйста. Смотря как вы это используете. Если для игр (Unreal и т.п.) - вообще без вопросов, для крутых оригинальных серверных проектов или сложных и быстрых движков - тоже вопросов нет. Но в бизнес логику, а тем более в интерфейс я такое опасное и страшное "месиво" уже не потащу, да сейчас и мало кто потащит. Когда-то у нас даже были попытки на Qt перейти, но мы посмотрели на конечный результат с сотнями мегабайт Qt dll-лек, + оценили необходимый уровень среднего разработчика на C++ и кучу подводных камней и решили, что это мягко говоря не лучший путь.
Но вам всего хорошего с вашим безальтернативным С++, ну или реально оправданным в случае вышеперечисленного.
Вы собственный уровень владения инструментом, который критикуете, подтвердить не можете, а вас уже в обобщения бросает.
А вы свой уровень уже подтвердили? Собеседование у меня прошли? Ведь может, например, так оказаться, что по факту я вас с вашим "уровнем" на работу не взял бы, потому как общаюсь сейчас не вашими знаниями, а со знаниями нейронки.
Но это не столько следствие сложности шаблонов, сколько непривычность к такого рода задачам.... ... Но, видимо, подобные извраты нужны для того, чтобы язык развивался.
Не нужны излишне большие извраты в языках, чтобы язык был эффективен в том числе и сточки зрения быстродействия конечного кода. Извраты чаще появляются тогда, когда старые языки пытаются натянуть на то, на что они изначально были никак не рассчитаны. Вы, кажется, не понимаете сути моих и подобных претензий. Суть состоит в том, что избыточный идиотизм (читаем излишняя, нелогичная и НЕ интуитивизма сложность) синтаксиса языка, который по хорошему давно нужно было оправить на покой и заменить чем-то более приятным и совместимым (типа D или типа того), как раз и порождает этот "кошмар" в исходниках библиотеки, где без поллитры адекватному инженеру (не гику) не разобраться.
Я ещё в первом после написал, что "бабушка уже полная, пора бы менять" (tm) ;) НО многие скажут, что мол весомой альтернативы этой "бабке" пока нет. И к сожалению будут правы. Просто потому, что как минимум два главных игрока таких как MS и Intel штампуют высокоэффективные компиляторы только для C++.
вы предъявляете ваши личные сложности с изучением кода современных C++ных шаблонов ...
Да я не столько свои личные предъявляю, а скорее общие констатирую. При том, что абсолютное большинство туда даже и не лезет. Я-то могу быть не показателем. Я, как и говорил, использую этот язык и библиотеку лишь время от времени в чисто прикладном плане. Но вот когда видишь как люди годами на практике использующие С++ в непростых проектах и даже преподающие его студентам, в том числе и с тонкостями работы с шаблонами (включая и sfinae и пр.), вдруг лезут в реальные тексты современных шаблонов и впадают в ступор - вот тут и возникают вопросики в плане адекватности развития архитектуры данного языка.
Вы поймите, мне по большому счёту на это всё пофигу. Однако, даже когда я ещё очень давно учился в универе, то один умный препод не принимал зачёты у тех, кто выпендриваясь писал дважды в одном выражении унарные префисные/постфиксные операторы увеличения/уменьшения. Ибо это крайне плохой стиль как с точки зрения переносимости такого выражений (например, даже в Java или C# получите другой ответ), так и с точки зрения последующего понимания. Так вот складывается такое ощущение, что разработчики современных стандартов C++ (уже начиная прямо с 11-го) как раз таки и состоят из тех не сдавших зачёты идиЁтов, для которых главное - это выпендриться и создать жуткую обфускацию в понимании кода.
Знали бы вы инструмент, о котором рассуждаете, проблем с предоставлением конкретики не было бы.
Так я в отличии от вас и не корчу из себя эксперта по современным текстам библиотечных шаблонов С++.
Но только может оказаться, что ваше понимание текстов стандартной библиотеки может быть ровно таким же как у вышеупомянутого гуру по С++. Он кстати довольно известная личность в российском С++ сообществе и в ваших аналогиях к “Карузо” куда ближе.
Вообще кроме С++ я ещё использую 3 языка и среды не считая ассемблеров. И вот “удивительно”, что когда я по необходимости лезу в тексты библиотек этих языков и сред, то почему-то мне практически всё там понятно. Но вот в коде шаблонов современного С++ возникают тонны вопросов даже при прохождении в отладке.
Особенно для языка, разрабатываемого коммитетом оторванных от реальной жизни нердов
Вот именно, что создаётся полное впечатление, что и сам язык и шаблонные библиотеки для него разрабатывают не инженеры, а исключительно асоциальные и засаленные нерды, для которых важно не сделать красивую, чистую, надежную архитектуру и синтаксис, а лишь в очередной раз извратиться и выпендриться в своем засаленном кружке для таких же как они чудиков. Ну каков язык - такие и адепты :D
И единственная правдоподобная версия – незнание инструмента о котором идет речь.
Ой не надо корчить из себя всезнающего эксперта. ;) Ибо не так давно как конкретно работают некоторые вещи в шаблонах мне даже человек писавший серьёзный код для авиамоделирования и преподававший C++ студентам не смог толком объяснить. Так же водил жалом по исходникам шаблонов и лишь делал предположения.
Но если даже вы и такой, то вас будет НУ крайне мало.
Ваша позиция понятна. Непонятно есть ли за ней какие-то объективные примеры.
Какие вам ещё примеры? Я же сказал, что использую VC++ тупо по причине того, что конечный результат dll-ки считает фильтры на 40% быстрее, чем альтернативы. C++ я по большому счёту не использую дальше 11-го стандарта ( какие-то возможности инициализации кажется из 17-го и всё ) А когда я заканчивал университет ещё и до 11-го было далеко.
И кстати на чистом Си с массивами было бы и ещё быстрее, но с шаблонами многие вещи-то писать всё же удобнее ;)
А инженеры, которые пишут собственно под контроллеры не используют у нас C++ - только чистый Cи. И к слову, по разговорам, они с Торвальдсом абсолютно солидарны.
И если честно, то C++ как современный ООП язык - #Овно конечно полное, но вот компиляторы MS и особенно Intel ну очень хорошие...
Я ничего не путаю. Я, например, могу сравнить это с текстами похожей сущности aka дженрики на других языках. Это безусловно не вполне равнозначные понятия, но тем не менее там всё гораздо прозрачнее. И в плане выделения памяти в том числе.
Вы просто хотите топить за C++ несмотря ни на что? Вы против того, что как синтаксис так и библиотека языка в последние лет 15 превращается в жуткую кашу, но при этом лишь усложняет и запутывает и без того не самый простой синтаксис и не самые простые подходы к разработке?. Ну это ваша позиция. У меня своя. Да далеко и не только у меня. В таком виде в бизнес-приложениях и даже на производстве по хорошему ему конечно не место. В узко системном программировании, как видим, его тоже побаиваются весьма многие. Зато игры, обработка видео, изображений, математика и прочий высоконагруженный контент - никуда с него в ближайшее обозримое время не слезут. Да и то - это не столько заслуга языка и библиотеки, сколько просто хороших с него компиляторов от той же MS. А так-то тот же intel fortran для чисто вычислительных задач может и более оптимальный ассемблерный код породить.
Это как раз когда-то на заре они не были запутанными. А сейчас я ради интереса залез в VC++ и в одном только модуле vector насчитал 3916 строчек кода!!! О точном предназначении больше половины которых придётся только догадываться. И Это не говоря об аллокаторах (в одном только xmemory 2624 строчки ) и т.п.
Ещё раз - если это в прикладном плане как у меня- типа выделил vector для дела и считай. Как-то работает и ладно - это одно. НО в системном программировании этому не место. Торвальдс тут прав.
Ну значит я вашу мысль не верно дочитал Правильно, setState через scheduleBuildFor ... как раз и приведет к перестройке всего дерева. на следующем кадре. Но это не значит, что им всегда нужно безконтрольно пользоваться. Он так или иначе приведет к пересозданию всего нижележащего дерева виджетов - а это не всегда быстро с учётом сверки больших списков с нижележащими в библиотеке элементами, как бы не уверяли разработчики flutter и фаза UI в профайлере далеко не всегда укладыватся в 17 мс.
Только если вы следуете "лучшим практикам иммутабельности" - самой идиотской идиоме, и на каждое движение пересоздаете весь список нижележащих данных.Тогда да, убогая иммутабельность неизлечима :)
Как раз я забил на иммутабельность после первой же попытки ещё в первых тестах. И перешёл на свой подход с версионностью данных. НО в случае с деревом следить за каждым листом как оказалось во многих случаях не слишком удобно, особенно при drag & drop частей того же дерева и походу внутренних багах таких компонентов как, например, animated_tree_view, перебилживать всё дерево виджетов целиком всё равно временами приходится.
ПЫ СЫ flutter используется нами как раз не для мобильной, а для WEB и десктоп разработки. И походу с высоконагруженными интерфейсами он справляется иногда с трудом, судя по профайлеру. Иногда приходитмся бороться за каждый кадр, но junk-и всё равно присутствуют.
Зачем вам так "полировать"? Лично меня тогда убила сложность понимания реального выделения памяти для шаблонных нужд при и без того излишней запутанности синтаксиса шаблонов современного С++. Я уже не помню всех деталей, и сейчас не буду ковырять, но точно было проще понять из прохождению по асеемблерному коду в отладке.
В том числе и эти абстракции с выделением памяти и саму неопределенность выделения памяти и критикуют системные программисты включая Торвальдса.
А лично я пишу на C++ только высоконагруженный вычислительный код отдельных библиотек. И из шаблонов использую обычно базовый минимум стандартной библиотеки типа vector и т.п. Меня в данном случае вся эта кухня с конкретным выделением памяти не особо волнует, поскольку в моём случае всё равно это пашет процентов на 40% быстрее чем, например, на том же Object Pascal (просто в моем случае FPC не очень хорошо оптимизирует плавающую точку и не умеет так агрессивно инлайнить как VC++. Хотя и сам FPC не для интерфейса, а для очень быстрого и не прожорливого backend-а).
Но как-то несколько лет тому назад полез в шаблоны, чтобы разобраться для дела, где на самом деле что хранится, и мягко говоря офигел от тонн абстракции над абстракциями в выделении памяти. По факту просто по ассемблеру уже посмотрел и всего делов. Поэтому, в целом наверное, могу понять, что имеет в виду Торвальдс, когда говорит, что C++ не место в системном программировании. К слову, ни один из знакомых программистов контроллеров не использует C++ (только Си), хотя у них есть возможность писать и на C++.
setState не делает ничего, только маркирует виджет как грязный
Не верно.
setState по любому заставит перестроить нижележащее дерево виджетов. А если у вас приличное такое дерево виджетов, и у этих виджетов нет однозначных ключей и flutter не сможет однозначно сопоставить это дерево с деревом элементов (Element), то это уже потянет за собой и реальную перерисовку через дерево объектов рендеринга.
Но иногда, даже если есть однозначные ключи для сопоставления виджетов с нижележащими элементами, это всё равно не спасает от накладных расходов на перестройку виджетов и их сравнение с элементами. Особенно большие задержки могут проявляться при отрисовке длинных листов, состоящих из множества элементов.
При этом не забывайте, что на подготовку всего дерева виджетов и на сравнение с деревом элементов у Flutter по хорошему есть только ~ 17ms в рамках одного кадра. А при этом, возможно, ещё и какой-то полезный код приложения нужно успеть выполнить.
Например, я минимум две недели оптимизировал работу по показу каталога через animated_tree_view, потому что нужно было реагировать на любые изменения этого каталога из вне, а так же и непосредственное его редактирование в виджете. Пришлось придумывать разные ChangeNotifier-ы и грамотно расставлять Selector-ы для перехвата событий провайдера, чтобы снизить перестройку дерева даже в сложных моментах ниже 17ms для среднего железа клиента.
(После просмотра первых ответов с примерами на С++) Не знаю, но лично я когда смотрю на код с наворотами на новомодных стандартах С++, то просто волосы на голове дыбом встают. И сам собой напрашивается вопрос: На кой вам всё это?!! Вам не кажется, что "бабку пора заменить, она уже полная" (из пошлого анекдота)? :D Из хорошего и простого низкоуровневого кросс-ассемблера aka Си за 40 с лишним лет сделали фиг знает что. НО для бизнеса он всё равно слишком сложен и опасен (и с каждым годом лишь всё сложнее и опаснее), а для системного программирования крайне избыточен и непредсказуем (здесь абсолютно согласен с Линусом Торвальдсом).
Лично я стал подозревать, что с языком что-то не так, еще когда move семантику ввели. Как бы причина была понятна, профит был ясен, но реализация в рамках синтаксиса языка уже начинала сильно напрягать, особенно когда внезапно провились всякие новые не очевидные правила сворачивания ссылок типа A&& & -> A& ; A&& && -> A&& и т.п. Ну а современные шаблоны на C++ -это вообще мрак, особенно что касается обобщенных подходов к выделению памяти и т.п.
А по поводу Rust - не знаю. Больше похоже на какой-то очередной хайп. IMHO Самая большая проблема как всегда - это невозможность легкого переноса legacy кода, при том, что экосистема ограничена в основном лишь системными вещами. Но спрашивается зачем кому-то переписывать уже годами работающий крайне быстрый и отлаженный код на Си?
Тем более, что были же здравые попытки начать с чистого листа с максимально возможной совместимостью по синтаксису как с Си так и с C++ - это был D. Но и то почему-то как-то не зашло. А Rust всё же куда существеннее отличается по синтаксису и подходам. И каковы шансы, что это зайдёт?...
Проблему с форматами скоро решат. Когда Роскомнадзор и Шадаев под аплодисменты ФСБ окончательно выключат всем "этот ваш ЫнтЫрнет", а в идеале и в их мечтах и все "эти ваши бесовские компуХтеры", то единственным утвержденным и одобренным форматом будут берестяные письма и документы на кириллице без англицизмов.
В конце квартала подводы с берестяными отчётами обученные грамоте дьяки и подьячие будут свозить в Приказы от главной казны, где внимательно всё изучать и провинившихся в недоимке бить плетьми.
Попытки померить любой интеллектуальный труд и тем более связанный с исследованиями и/или творчеством на манер количества выложенных каменщиком кирпичей всегда приводят к провалу. Иначе и не может быть.
Но ещё есть такой фактор, который я уже минимум 20 лет вижу в разных местах. Это такое уродливое явление как т.н. "менеджер проектов", который сам слабо представляет как именно устроен проект и/или технология, но натужно пытается этим руководить. Сейчас даже бывает, что и вообще сажают на руководство тех.проектами управленцев по общим вопросам - т.н. эФФективных мэ-э-энеджеров - т.е. профессионально ничего вообще не знающих болванов-недоучек с экономическим а то и с гуманитарным образованием. И особенно это характерно для России, где пристроить своего человека или родственника всегда важнее конечного результата (тут есть с чем сравнить, поскольку долгое время работал в сотрудничестве с европейскими компаниями).
IMHO Разумный подход для правильного развития проекта - это изначально грамотный подбор персонала и правильная его стимуляция (где-то деньги, где-то интересные задачи, где-то соревновательный подход).
Кстати, я-то давно наблюдаю весьма опасную тенденцию. Работает в одной конторе парень без профильного образования и как следствие без элементарных базовых знаний. Чего случайно не спросишь, например, а почему здесь элементарно через XOR не сделал или почему интерфейсы для унификации не использовал?...а в ответ только и слышишь: "а что это"? У него даже понятий о хранении чего бы то ни было в стеке или в куче нет никакого, не говоря уже о том что слово ассемблер он вообще не знает к чему применяется и т.п. Но как раз этот чел быстро и активно стал использовать ИИ, компенсируя отсутствие собственных знаний. И пихает всё, что нейронка выдаст, без особых проверок.
Это ведь даже не т.н. "джуниоры", это просто недоучки-коновалы, постигающие что-то исключительно через свою узкую практику. Понабрали этих деятелей "с рынка" в период когда кадров не хватало и когда "и так сойдет" - типа кнопочку на формочку и так положит рядом с картинкой.
Может внедрение ИИ как раз избавит от необходимости в таких недоучках. И заниматься инженерной работой будут люди с профильными дипломами.
Ты сам то пробовал? Ничего более мерзкого я в жизни не видел.:)
Именно, что уже пробовал и даже очень глубоко зарылся. Тот же React, но с нормальным строго-типизированным ООП подходом и относительно шустрым кодом как в найтиве так и в WebAssembly. Не идеал, конечно, и много своеобразных подходов, НО уже точно в сотни раз лучше богомерзкого JS.
Плешивому деду, похоже, что и не нужны специалисты. Он про этот ваш ЫнтЫрнет-то лишь по наслышке от нужных органов знает.
Ему бабушки нужны, которые носочки будут вязать (недавно с трибуны так и говорил).
ПЫ СЫ:
В этом есть только одна серьёзная проблема. Молодые дурачки часто даже без профильного образования, наслушавшись каких-нибудь блогерных идиотов или только лишь в погоне за сиюминутной модой, повторяют глупые мантры про смерть Паскаля (или ещё какого-нибудь языка), и при этом сами тратят время лишь на скриптовые и жутко тормозные убожества типа Питонов.
Я ещё понимаю, если бы они все при этом на Си/C++ или новомодном Rust умели писать, но в подавляющем количестве случаев нет ;)
Ну а в результате просто мало специалистов осталось по этой весьма ПРАКТИЧНОЙ для ряда задач с прагматичной точки зрения технологии.
Хотя, Паскаль в том же TIOBE даже сейчас на 10-м месте держится, а про кучу промелькнувших за десятки лет “новомодных” языков уже давно и позабыть успели :D
Ну лично я от паскаля в виде Lazarus пока отказываться не собираюсь.
НО не для интерфейсов, а для очень быстрого компактного и непрожорливого бэкенда.
Если эту среду использовать с умом, то результат получается не на много медленнее чем на Си/С++, НО в десятки раз быстрее всякого скриптового г-на (см. mORMot ).
При этом писать в разы легче, чем на Сях, ошибку допустить существенно сложнее,
никаких тонн библиотек или фреимворков тащить не надо, тормозов от сборщика мусора нет, при большом желании можно хоть до ассемблера опускаться (включая ARM) и работать и отлаживать код можно уже хоть на "чайнике".
На ARM встройке у меня всё работает и даже отладка через IDE. Размеры полностью самодостаточных исполняемых фалов по современным временам копеечные - у меня ~5 мегабайт.
За светлое будущее Delphi не скажу, но там народ вроде даже активно под мобилки какие-то коммерческие поделки стал писать на FMX и вроде им давно обещают WebAssembly подвезти.
Ну со свой-то стороны в вас я вижу обычного "территориального охранника", просто тупо защищающего "хозяйскую территорию" из своей "будки", по принципу что доверили, то и будем защищать и "облаивать" всех, кто посягнёт на "святое" :D
Ну или вам поговорить не с кем.
Я вам уже всё объяснил за своё использование C++ и за причины такового. Это просто много математики, связанной с обработкой, фильтрацией и т.п сигналов. Свой код я вам показывать не обязан, как и вашего не прошу, пока мало ли на собеседование не придёте (мир тесен).
Кстати, лет десять тому назад ради интереса даже проверяли алгоритмы на компиляторе Фортрана от Intel - и кое что даже считалось ещё быстрее, чем на C++.
Но на Фортране оставлять это в современном продакшене - это уже страшно. Никто не поддержит потом.
Нравится вам современный C++ - да пожалуйста. Смотря как вы это используете. Если для игр (Unreal и т.п.) - вообще без вопросов, для крутых оригинальных серверных проектов или сложных и быстрых движков - тоже вопросов нет.
Но в бизнес логику, а тем более в интерфейс я такое опасное и страшное "месиво" уже не потащу, да сейчас и мало кто потащит.
Когда-то у нас даже были попытки на Qt перейти, но мы посмотрели на конечный результат с сотнями мегабайт Qt dll-лек, + оценили необходимый уровень среднего разработчика на C++ и кучу подводных камней и решили, что это мягко говоря не лучший путь.
Но вам всего хорошего с вашим безальтернативным С++, ну или реально оправданным в случае вышеперечисленного.
А вы свой уровень уже подтвердили? Собеседование у меня прошли?
Ведь может, например, так оказаться, что по факту я вас с вашим "уровнем" на работу не взял бы, потому как общаюсь сейчас не вашими знаниями, а со знаниями нейронки.
Не нужны излишне большие извраты в языках, чтобы язык был эффективен в том числе и сточки зрения быстродействия конечного кода.
Извраты чаще появляются тогда, когда старые языки пытаются натянуть на то, на что они изначально были никак не рассчитаны.
Вы, кажется, не понимаете сути моих и подобных претензий. Суть состоит в том, что избыточный идиотизм (читаем излишняя, нелогичная и НЕ интуитивизма сложность) синтаксиса языка, который по хорошему давно нужно было оправить на покой и заменить чем-то более приятным и совместимым (типа D или типа того), как раз и порождает этот "кошмар" в исходниках библиотеки, где без поллитры адекватному инженеру (не гику) не разобраться.
Я ещё в первом после написал, что "бабушка уже полная, пора бы менять" (tm) ;)
НО многие скажут, что мол весомой альтернативы этой "бабке" пока нет. И к сожалению будут правы. Просто потому, что как минимум два главных игрока таких как MS и Intel штампуют высокоэффективные компиляторы только для C++.
А вы сво
Да я не столько свои личные предъявляю, а скорее общие констатирую.
При том, что абсолютное большинство туда даже и не лезет.
Я-то могу быть не показателем. Я, как и говорил, использую этот язык и библиотеку лишь время от времени в чисто прикладном плане.
Но вот когда видишь как люди годами на практике использующие С++ в непростых проектах и даже преподающие его студентам, в том числе и с тонкостями работы с шаблонами (включая и sfinae и пр.), вдруг лезут в реальные тексты современных шаблонов и впадают в ступор - вот тут и возникают вопросики в плане адекватности развития архитектуры данного языка.
Вы поймите, мне по большому счёту на это всё пофигу.
Однако, даже когда я ещё очень давно учился в универе, то один умный препод не принимал зачёты у тех, кто выпендриваясь писал дважды в одном выражении унарные префисные/постфиксные операторы увеличения/уменьшения. Ибо это крайне плохой стиль как с точки зрения переносимости такого выражений (например, даже в Java или C# получите другой ответ), так и с точки зрения последующего понимания.
Так вот складывается такое ощущение, что разработчики современных стандартов C++ (уже начиная прямо с 11-го) как раз таки и состоят из тех не сдавших зачёты идиЁтов, для которых главное - это выпендриться и создать жуткую обфускацию в понимании кода.
Так я в отличии от вас и не корчу из себя эксперта по современным текстам библиотечных шаблонов С++.
Но только может оказаться, что ваше понимание текстов стандартной библиотеки может быть ровно таким же как у вышеупомянутого гуру по С++. Он кстати довольно известная личность в российском С++ сообществе и в ваших аналогиях к “Карузо” куда ближе.
Вообще кроме С++ я ещё использую 3 языка и среды не считая ассемблеров. И вот “удивительно”, что когда я по необходимости лезу в тексты библиотек этих языков и сред, то почему-то мне практически всё там понятно. Но вот в коде шаблонов современного С++ возникают тонны вопросов даже при прохождении в отладке.
Вот именно, что создаётся полное впечатление, что и сам язык и шаблонные библиотеки для него разрабатывают не инженеры, а исключительно асоциальные и засаленные нерды, для которых важно не сделать красивую, чистую, надежную архитектуру и синтаксис, а лишь в очередной раз извратиться и выпендриться в своем засаленном кружке для таких же как они чудиков.
Ну каков язык - такие и адепты :D
Ой не надо корчить из себя всезнающего эксперта. ;)
Ибо не так давно как конкретно работают некоторые вещи в шаблонах мне даже человек писавший серьёзный код для авиамоделирования и преподававший C++ студентам не смог толком объяснить. Так же водил жалом по исходникам шаблонов и лишь делал предположения.
Но если даже вы и такой, то вас будет НУ крайне мало.
Какие вам ещё примеры? Я же сказал, что использую VC++ тупо по причине того, что конечный результат dll-ки считает фильтры на 40% быстрее, чем альтернативы.
C++ я по большому счёту не использую дальше 11-го стандарта ( какие-то возможности инициализации кажется из 17-го и всё )
А когда я заканчивал университет ещё и до 11-го было далеко.
И кстати на чистом Си с массивами было бы и ещё быстрее, но с шаблонами многие вещи-то писать всё же удобнее ;)
А инженеры, которые пишут собственно под контроллеры не используют у нас C++ - только чистый Cи. И к слову, по разговорам, они с Торвальдсом абсолютно солидарны.
И если честно, то C++ как современный ООП язык - #Овно конечно полное, но вот компиляторы MS и особенно Intel ну очень хорошие...
Я ничего не путаю.
Я, например, могу сравнить это с текстами похожей сущности aka дженрики на других языках.
Это безусловно не вполне равнозначные понятия, но тем не менее там всё гораздо прозрачнее. И в плане выделения памяти в том числе.
Вы просто хотите топить за C++ несмотря ни на что?
Вы против того, что как синтаксис так и библиотека языка в последние лет 15 превращается в жуткую кашу, но при этом лишь усложняет и запутывает и без того не самый простой синтаксис и не самые простые подходы к разработке?.
Ну это ваша позиция.
У меня своя. Да далеко и не только у меня.
В таком виде в бизнес-приложениях и даже на производстве по хорошему ему конечно не место.
В узко системном программировании, как видим, его тоже побаиваются весьма многие.
Зато игры, обработка видео, изображений, математика и прочий высоконагруженный контент - никуда с него в ближайшее обозримое время не слезут.
Да и то - это не столько заслуга языка и библиотеки, сколько просто хороших с него компиляторов от той же MS. А так-то тот же intel fortran для чисто вычислительных задач может и более оптимальный ассемблерный код породить.
Это как раз когда-то на заре они не были запутанными.
А сейчас я ради интереса залез в VC++ и в одном только модуле vector насчитал 3916 строчек кода!!! О точном предназначении больше половины которых придётся только догадываться.
И Это не говоря об аллокаторах (в одном только xmemory 2624 строчки ) и т.п.
Ещё раз - если это в прикладном плане как у меня- типа выделил vector для дела и считай. Как-то работает и ладно - это одно. НО в системном программировании этому не место. Торвальдс тут прав.
Ну значит я вашу мысль не верно дочитал
Правильно,
setStateчерезscheduleBuildFor... как раз и приведет к перестройке всего дерева. на следующем кадре.Но это не значит, что им всегда нужно безконтрольно пользоваться. Он так или иначе приведет к пересозданию всего нижележащего дерева виджетов - а это не всегда быстро с учётом сверки больших списков с нижележащими в библиотеке элементами, как бы не уверяли разработчики flutter и фаза UI в профайлере далеко не всегда укладыватся в 17 мс.
Как раз я забил на иммутабельность после первой же попытки ещё в первых тестах.
И перешёл на свой подход с версионностью данных.
НО в случае с деревом следить за каждым листом как оказалось во многих случаях не слишком удобно, особенно при drag & drop частей того же дерева и походу внутренних багах таких компонентов как, например, animated_tree_view, перебилживать всё дерево виджетов целиком всё равно временами приходится.
ПЫ СЫ flutter используется нами как раз не для мобильной, а для WEB и десктоп разработки. И походу с высоконагруженными интерфейсами он справляется иногда с трудом, судя по профайлеру. Иногда приходитмся бороться за каждый кадр, но junk-и всё равно присутствуют.
Зачем вам так "полировать"?
Лично меня тогда убила сложность понимания реального выделения памяти для шаблонных нужд при и без того излишней запутанности синтаксиса шаблонов современного С++.
Я уже не помню всех деталей, и сейчас не буду ковырять, но точно было проще понять из прохождению по асеемблерному коду в отладке.
В том числе и эти абстракции с выделением памяти и саму неопределенность выделения памяти и критикуют системные программисты включая Торвальдса.
А лично я пишу на C++ только высоконагруженный вычислительный код отдельных библиотек. И из шаблонов использую обычно базовый минимум стандартной библиотеки типа vector и т.п.
Меня в данном случае вся эта кухня с конкретным выделением памяти не особо волнует, поскольку в моём случае всё равно это пашет процентов на 40% быстрее чем, например, на том же Object Pascal (просто в моем случае FPC не очень хорошо оптимизирует плавающую точку и не умеет так агрессивно инлайнить как VC++. Хотя и сам FPC не для интерфейса, а для очень быстрого и не прожорливого backend-а).
Но как-то несколько лет тому назад полез в шаблоны, чтобы разобраться для дела, где на самом деле что хранится, и мягко говоря офигел от тонн абстракции над абстракциями в выделении памяти. По факту просто по ассемблеру уже посмотрел и всего делов.
Поэтому, в целом наверное, могу понять, что имеет в виду Торвальдс, когда говорит, что C++ не место в системном программировании.
К слову, ни один из знакомых программистов контроллеров не использует C++ (только Си), хотя у них есть возможность писать и на C++.
Не верно.
setState по любому заставит перестроить нижележащее дерево виджетов. А если у вас приличное такое дерево виджетов, и у этих виджетов нет однозначных ключей и flutter не сможет однозначно сопоставить это дерево с деревом элементов (Element), то это уже потянет за собой и реальную перерисовку через дерево объектов рендеринга.
Но иногда, даже если есть однозначные ключи для сопоставления виджетов с нижележащими элементами, это всё равно не спасает от накладных расходов на перестройку виджетов и их сравнение с элементами.
Особенно большие задержки могут проявляться при отрисовке длинных листов, состоящих из множества элементов.
При этом не забывайте, что на подготовку всего дерева виджетов и на сравнение с деревом элементов у Flutter по хорошему есть только ~ 17ms в рамках одного кадра.
А при этом, возможно, ещё и какой-то полезный код приложения нужно успеть выполнить.
Например, я минимум две недели оптимизировал работу по показу каталога через animated_tree_view, потому что нужно было реагировать на любые изменения этого каталога из вне, а так же и непосредственное его редактирование в виджете. Пришлось придумывать разные ChangeNotifier-ы и грамотно расставлять Selector-ы для перехвата событий провайдера, чтобы снизить перестройку дерева даже в сложных моментах ниже 17ms для среднего железа клиента.
(После просмотра первых ответов с примерами на С++)
Не знаю, но лично я когда смотрю на код с наворотами на новомодных стандартах С++, то просто волосы на голове дыбом встают. И сам собой напрашивается вопрос:
На кой вам всё это?!! Вам не кажется, что "бабку пора заменить, она уже полная" (из пошлого анекдота)? :D
Из хорошего и простого низкоуровневого кросс-ассемблера aka Си за 40 с лишним лет сделали фиг знает что. НО для бизнеса он всё равно слишком сложен и опасен (и с каждым годом лишь всё сложнее и опаснее), а для системного программирования крайне избыточен и непредсказуем (здесь абсолютно согласен с Линусом Торвальдсом).
Лично я стал подозревать, что с языком что-то не так, еще когда move семантику ввели. Как бы причина была понятна, профит был ясен, но реализация в рамках синтаксиса языка уже начинала сильно напрягать, особенно когда внезапно провились всякие новые не очевидные правила сворачивания ссылок типа A&& & -> A& ; A&& && -> A&& и т.п.
Ну а современные шаблоны на C++ -это вообще мрак, особенно что касается обобщенных подходов к выделению памяти и т.п.
А по поводу Rust - не знаю. Больше похоже на какой-то очередной хайп.
IMHO Самая большая проблема как всегда - это невозможность легкого переноса legacy кода, при том, что экосистема ограничена в основном лишь системными вещами. Но спрашивается зачем кому-то переписывать уже годами работающий крайне быстрый и отлаженный код на Си?
Тем более, что были же здравые попытки начать с чистого листа с максимально возможной совместимостью по синтаксису как с Си так и с C++ - это был D.
Но и то почему-то как-то не зашло. А Rust всё же куда существеннее отличается по синтаксису и подходам. И каковы шансы, что это зайдёт?...
Проблему с форматами скоро решат.
Когда Роскомнадзор и Шадаев под аплодисменты ФСБ окончательно выключат всем "этот ваш ЫнтЫрнет", а в идеале и в их мечтах и все "эти ваши бесовские компуХтеры", то единственным утвержденным и одобренным форматом будут берестяные письма и документы на кириллице без англицизмов.
В конце квартала подводы с берестяными отчётами обученные грамоте дьяки и подьячие будут свозить в Приказы от главной казны, где внимательно всё изучать и провинившихся в недоимке бить плетьми.
Попытки померить любой интеллектуальный труд и тем более связанный с исследованиями и/или творчеством на манер количества выложенных каменщиком кирпичей всегда приводят к провалу. Иначе и не может быть.
Но ещё есть такой фактор, который я уже минимум 20 лет вижу в разных местах. Это такое уродливое явление как т.н. "менеджер проектов", который сам слабо представляет как именно устроен проект и/или технология, но натужно пытается этим руководить.
Сейчас даже бывает, что и вообще сажают на руководство тех.проектами управленцев по общим вопросам - т.н. эФФективных мэ-э-энеджеров - т.е. профессионально ничего вообще не знающих болванов-недоучек с экономическим а то и с гуманитарным образованием.
И особенно это характерно для России, где пристроить своего человека или родственника всегда важнее конечного результата (тут есть с чем сравнить, поскольку долгое время работал в сотрудничестве с европейскими компаниями).
IMHO Разумный подход для правильного развития проекта - это изначально грамотный подбор персонала и правильная его стимуляция (где-то деньги, где-то интересные задачи, где-то соревновательный подход).
Кстати, я-то давно наблюдаю весьма опасную тенденцию.
Работает в одной конторе парень без профильного образования и как следствие без элементарных базовых знаний.
Чего случайно не спросишь, например, а почему здесь элементарно через XOR не сделал или почему интерфейсы для унификации не использовал?...а в ответ только и слышишь: "а что это"? У него даже понятий о хранении чего бы то ни было в стеке или в куче нет никакого, не говоря уже о том что слово ассемблер он вообще не знает к чему применяется и т.п.
Но как раз этот чел быстро и активно стал использовать ИИ, компенсируя отсутствие собственных знаний. И пихает всё, что нейронка выдаст, без особых проверок.
Это ведь даже не т.н. "джуниоры", это просто недоучки-коновалы, постигающие что-то исключительно через свою узкую практику.
Понабрали этих деятелей "с рынка" в период когда кадров не хватало и когда "и так сойдет" - типа кнопочку на формочку и так положит рядом с картинкой.
Может внедрение ИИ как раз избавит от необходимости в таких недоучках. И заниматься инженерной работой будут люди с профильными дипломами.
Именно, что уже пробовал и даже очень глубоко зарылся.
Тот же React, но с нормальным строго-типизированным ООП подходом и относительно шустрым кодом как в найтиве так и в WebAssembly.
Не идеал, конечно, и много своеобразных подходов, НО уже точно в сотни раз лучше богомерзкого JS.