Знали бы вы инструмент, о котором рассуждаете, проблем с предоставлением конкретики не было бы.
Так я в отличии от вас и не корчу из себя эксперта по современным текстам библиотечных шаблонов С++.
Но только может оказаться, что ваше понимание текстов стандартной библиотеки может быть ровно таким же как у вышеупомянутого гуру по С++. Он кстати довольно известная личность в российском С++ сообществе и в ваших аналогиях к “Карузо” куда ближе.
Вообще кроме С++ я ещё использую 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.
Не столь важно как бы выглядел интернет с Flash, ВАЖНО, что в нем было бы значительно меньше такого редкостного дЭрьма как JS для создания Веб морд и приложений. Хотя, для чисто сайтов JS для поддержки HTML в ограниченном количестве не так уж и плох.
Dart+Flutter или WebAssembly для других ходовых языков с UI - всё что угодно - лишь бы только эту гадолсть в виде JS в её чистом виде вытесняли из разработки собственно приложений, ибо как серьёзный язык JS гадость редкостная, а TS просто костыль сверху.
Все уже начинают слегка уставать от этих бесконечных обещаний. Но только затраты на ИИ пока не окупаются, а пузырь всё больше и больше как и страхи.
Сам давно уже использую ИИ в работе, но по факту лишь для типовых шаблонных набросок, либо для проверки типовых алгоритмов, либо разжеванного ответа с примерами по какой-то технологии.
Десятки раз уже пытался разным нейронкам подсунуть что-то на уровне хотя бы переведи вот этот интерфейс с кодом на другой язык и библиотеку или создай что-то по моим дизайн наброскам и описанию, НО при этом на выходе получаю в лучшем случае какой-то набор шаблонных обрубков или по факту не рабочий заготовок.
Ведь современные нейронки просто тупо пытаются найти минимум линейной функции на основе тысяч кем-то уже написанных текстов и кода, адаптируя его под минимум моего запроса и при этом вовсе не обладают хоть каким-то интеллектом и сознанием, а лишь имитируют таковой.
Лично мой прогноз, что в ближайшие несколько десятков лет программирование как таковое никуда не исчезнет. Особенно в виде оригинальных проектов и новых библиотек или технологий. Скорее упростятся и ускорятся типовые бизнес-штамповки как то создай типовой сайт или простенькое типовое мобильное бизнес-приложение и т.п. Эти вещи будут штамповать уже не команда из 10 говн@кодеров и дизайнеров на HTML+JS, а 1-2 человека за вполне скромную ЗП. НО если нужен будет не типовой, а оригинальный проект, то так же придется раскошелится на живых программистов.
А вот если ИИ перерастёт во что-то большее чем тупо модель линейной алгебры с обучением на патернах и начнет реально думать и осознавать, то не только программисты станут последними кузнецами, а вообще все люди на планете земля будут больше не нужны.
Тебе всё никак не успокоиться, смотрю ))) Не плачь, ещё попишешь на любимых Дельфях! ) А я может даже на Lazarus еже немного попишу в качестве поддержки своего легаси.
А ты сходи потом на очередную конференцию, послушай ободряющие сказки про светлое будущее Дельфей. Попей чайку с дельфи-дедами 50-60 и выше. Я на подобном российском сборище был как раз когда мне ~28 было. Всеволод Леонов тогда на сцене "плясал". И уже тогда я чувствовал себя пионЭром среди дряхлых дедов.
Но только я свой "маленький частный корабль" сейчас всё же веду уже подальше от Дельфей. Мне это добра уже и даром не надо, тем более по таким ценам.
Зачем ему Дельфи, если в его команде все пишут на C# с 2008-го? Просто когда-то они писали под WinForms и под ASP.NET. А лет ~5 тому назад он объединил всё в Blazor.
купить VStudio + костыли в виде DevEx (запрещено в РФ), Гут!!!
Поверьте, что на все эти "запреты" в коммерческом применении всем положить с прибором . Единственное, что все на свободные SQL серверы переехали из-за проблемы с лицензиями.
В моем же случае, кроме меня на Дельфи тоже уже некому писать. Но и я точно уже не буду. Только один небольшой backend сервер на Лазаре, и то потому, что там много легаси ObjectPascal кода для связи с определенными устройствами. Со временем может и это перепишу, если время будет.
Проектов на FMX у нас уже много и все давно в проде у клиентов.
Очень рад за вас, что вы сможете продлить жизнь Дельфям и слегка подкормить исхудавшее Быдлокодеро хотя бы даже и в рамках своей маленькой дельфёвой "резервации" (команды, конечно же я хотел сказать, команды) :)
с того момента как MS подложила свинью - угробила Xamarin и при этом отказалась от поддержки Linux в WinUI.
MS долго не задумывается на тему забросить технологию, если не видит перспектив. Я так понимаю, что для C# они сделали основную ставку на WEB UI. Знакомый переписал проект на C#+Blazor + DevEx компоненты для Blazor. Как бы пока всё здорово. Очень доволен.
Но у меня сил меньше, чем у него и отдельного WEB дизайнера я приглашать не хочу. Поэтому попробую WEB и мобилки на Flutter. По сути та же декларативная a-la WEB разметка, но без необходимости связываться с HTML+CSS. Хотя и со своими тараканами, но зато все как бы в рамках одного языка и одной структуры. Опять же реактивный подход дисциплинирует и избавляет от необходимости делать навороты в виде MVC. Собственно все ковыряния и тесты и уже пройдены, проект запущен в производство.
Так что при таких вводных Дельфи вполне себе вариант.
Да пожалуйста, если кому-то так кажется.
Но именно по этому я поставлю на Flutter, закончу проектик, а там через пару лет видно будет. Delphi - нет, Если только на backend. Но для этого есть абсолютно бесплатный Лазарь, который ничем не хуже с этим справляется.
Так я в отличии от вас и не корчу из себя эксперта по современным текстам библиотечных шаблонов С++.
Но только может оказаться, что ваше понимание текстов стандартной библиотеки может быть ровно таким же как у вышеупомянутого гуру по С++. Он кстати довольно известная личность в российском С++ сообществе и в ваших аналогиях к “Карузо” куда ближе.
Вообще кроме С++ я ещё использую 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.
Не столь важно как бы выглядел интернет с Flash,
ВАЖНО, что в нем было бы значительно меньше такого редкостного дЭрьма как JS для создания Веб морд и приложений.
Хотя, для чисто сайтов JS для поддержки HTML в ограниченном количестве не так уж и плох.
Dart+Flutter или WebAssembly для других ходовых языков с UI - всё что угодно - лишь бы только эту гадолсть в виде JS в её чистом виде вытесняли из разработки собственно приложений, ибо как серьёзный язык JS гадость редкостная, а TS просто костыль сверху.
Все уже начинают слегка уставать от этих бесконечных обещаний.
Но только затраты на ИИ пока не окупаются, а пузырь всё больше и больше как и страхи.
Сам давно уже использую ИИ в работе, но по факту лишь для типовых шаблонных набросок, либо для проверки типовых алгоритмов, либо разжеванного ответа с примерами по какой-то технологии.
Десятки раз уже пытался разным нейронкам подсунуть что-то на уровне хотя бы переведи вот этот интерфейс с кодом на другой язык и библиотеку или создай что-то по моим дизайн наброскам и описанию,
НО при этом на выходе получаю в лучшем случае какой-то набор шаблонных обрубков или по факту не рабочий заготовок.
Ведь современные нейронки просто тупо пытаются найти минимум линейной функции на основе тысяч кем-то уже написанных текстов и кода, адаптируя его под минимум моего запроса и при этом вовсе не обладают хоть каким-то интеллектом и сознанием, а лишь имитируют таковой.
Лично мой прогноз, что в ближайшие несколько десятков лет программирование как таковое никуда не исчезнет. Особенно в виде оригинальных проектов и новых библиотек или технологий. Скорее упростятся и ускорятся типовые бизнес-штамповки как то создай типовой сайт или простенькое типовое мобильное бизнес-приложение и т.п. Эти вещи будут штамповать уже не команда из 10 говн@кодеров и дизайнеров на HTML+JS, а 1-2 человека за вполне скромную ЗП.
НО если нужен будет не типовой, а оригинальный проект, то так же придется раскошелится на живых программистов.
А вот если ИИ перерастёт во что-то большее чем тупо модель линейной алгебры с обучением на патернах и начнет реально думать и осознавать, то не только программисты станут последними кузнецами, а вообще все люди на планете земля будут больше не нужны.
Тебе всё никак не успокоиться, смотрю )))
Не плачь, ещё попишешь на любимых Дельфях! )
А я может даже на Lazarus еже немного попишу в качестве поддержки своего легаси.
А ты сходи потом на очередную конференцию, послушай ободряющие сказки про светлое будущее Дельфей. Попей чайку с дельфи-дедами 50-60 и выше.
Я на подобном российском сборище был как раз когда мне ~28 было. Всеволод Леонов тогда на сцене "плясал". И уже тогда я чувствовал себя пионЭром среди дряхлых дедов.
Но только я свой "маленький частный корабль" сейчас всё же веду уже подальше от Дельфей. Мне это добра уже и даром не надо, тем более по таким ценам.
Зачем ему Дельфи, если в его команде все пишут на C# с 2008-го?
Просто когда-то они писали под WinForms и под ASP.NET. А лет ~5 тому назад он объединил всё в Blazor.
Поверьте, что на все эти "запреты" в коммерческом применении всем положить с прибором . Единственное, что все на свободные SQL серверы переехали из-за проблемы с лицензиями.
В моем же случае, кроме меня на Дельфи тоже уже некому писать. Но и я точно уже не буду.
Только один небольшой backend сервер на Лазаре, и то потому, что там много легаси ObjectPascal кода для связи с определенными устройствами. Со временем может и это перепишу, если время будет.
Очень рад за вас, что вы сможете продлить жизнь Дельфям и слегка подкормить исхудавшее Быдлокодеро хотя бы даже и в рамках своей маленькой дельфёвой "резервации"
(команды, конечно же я хотел сказать, команды) :)
MS долго не задумывается на тему забросить технологию, если не видит перспектив. Я так понимаю, что для C# они сделали основную ставку на WEB UI.
Знакомый переписал проект на C#+Blazor + DevEx компоненты для Blazor. Как бы пока всё здорово. Очень доволен.
Но у меня сил меньше, чем у него и отдельного WEB дизайнера я приглашать не хочу. Поэтому попробую WEB и мобилки на Flutter.
По сути та же декларативная a-la WEB разметка, но без необходимости связываться с HTML+CSS. Хотя и со своими тараканами, но зато все как бы в рамках одного языка и одной структуры.
Опять же реактивный подход дисциплинирует и избавляет от необходимости делать навороты в виде MVC.
Собственно все ковыряния и тесты и уже пройдены, проект запущен в производство.
Да пожалуйста, если кому-то так кажется.
Но именно по этому я поставлю на Flutter, закончу проектик, а там через пару лет видно будет.
Delphi - нет, Если только на backend. Но для этого есть абсолютно бесплатный Лазарь, который ничем не хуже с этим справляется.