Как будем гарантировать, что объект-владелец еще жив?

С помощью грамотного проектирования структуры объектов. Часто Объекты устроены иерархически, тогда указатели от родителя к потомкам владеющие (unique_ptr), а от потомков к родителю не владеющие. Подсчёт ссылок нужен если не удаётся построить модель с единичным владением.

Спорить с тем, что web-ui это самый мощный, гибкий и кросплатформенный layout-engine на сегодняшний день, может только либо тролль, либо miltorg

Я поспорю, потому что на этом говне пишу нынче. «Мощный, гибкий, и кроссплатформенный» на самом деле назвается «тормознутый, перегруженный вековыми слоями наследия, и чуждый любой платформе».

Потому что это С. Каждый может использовать свои имена.

То есть этот пул каждый раз заново писать надо? В C++ есть стандартное средство.

Ты слишком широкими мазками берешь — шаблоны шаблонам рознь. Есть достаточно скромный STL, а есть Boost, или те же ренжи. Во многих проектах явно запрещено использовать буст и вообще тащить любые крупные либы с шаблонами в проект.

ну это был ответ на конкретный пример, когда проблема некоего абстрактного говнокода решается добавлением еще большего говнокода, но в этот раз на шаблонах. в итоге остается говнокод, но экспоненциально увеличивается время сборки, а исправить изначальную проблему становится еще сложнее.

Часто Объекты устроены иерархически, тогда указатели от родителя к потомкам владеющие (unique_ptr), а от потомков к родителю не владеющие

Часто объекты имеют не иерархические вазимоотношения, но некоторые кодеры пытаются натянуть сову на глобус. И да, в итоге это подсчет ссылок. Который не прокатывает в многопотоке, потому что JVM/CLR/Go дают сравнимую производительность.

То есть этот пул каждый раз заново писать надо?

Написал я один раз, теперь каждый раз могу сделать include и пользоваться.

Точно также как этот tsoding написал один раз https://github.com/tsoding/nothing/blob/master/src/system/lt.h и в следующем проекте просто делает include.

Ваш вопрос равносилен, тому что любую библиотеку нужно писать заного если она не в стандарте.

Кстати, у https://github.com/tsoding/nothing/blob/master/src/system/lt.h MIT License, так что можете просто копировать и пользоваться даже не написав 100 строк самостоятельно 1 раз…

И чем Си помогает бороться с этим, в нём можно обойтись без подсчёта ссылок? Подсчёт ссылок в C++ проще и надёжнее.

ну это был ответ на конкретный пример, когда проблема некоего абстрактного говнокода решается добавлением еще большего говнокода, но в этот раз на шаблонах. в итоге остается говнокод, но экспоненциально увеличивается время сборки, а исправить изначальную проблему становится еще сложнее

Если говорить про «конкретный пример», то так-то я могу заметить, что проблему долгой сборки C++ перенял ни у кого иного, как у Си.

И чем Си помогает бороться с этим, в нём можно обойтись без подсчёта ссылок? Подсчёт ссылок в C++ проще и надёжнее

Если тебе нужно автоматическое управление памятью при неплохой производительности, то есть JVM/CLR/Go, которые не используют подсчет ссылок, потому что сбор мусора является более эффективным механизмом автоматического управления, да и к тому же распознает циклы. Собсна, индустрия с крестов на них и перекатилась. Если же нужна высокая производительность, то неизбежно возникают ситуации «я знаю, что эта память здесь никуда не денется, потому мне не нужно прожигать лишние циклы процессора, а тем более рушить кэш записями — я просто передам указатель на память в другую функцию». По-настоящему оправдан подсчет ссылок не так часто, а в крестах его используют потому, что больше альтернатив нету.

Если же нужна высокая производительность, то неизбежно возникают ситуации «я знаю, что эта память здесь никуда не денется, потому мне не нужно прожигать лишние циклы процессора, а тем более рушить кэш записями — я просто передам указатель на память в другую функцию».

Кто мешает делать тоже самое в C++? В чём преимущество Си в плане системного программирования и производительности?

Конечно, лично я бы предпочел паскаль

Как интересно. И почему же - в нынешних реалиях?

Вообще, если ты заметил, все средства коммуникации через интернет являются зондами и это неспроста.

Корректное утверждение - «все распиаренные в последние годы средства…», далее по тексту. Проблема, скорее всего, не техническая, а политическая.

Тут политика очень вросла. Даже токс испортили.

А Матрикс?

Кто мешает делать тоже самое в C++? В чём преимущество Си в плане системного программирования и производительности?

Никто не мешает. Я и пишу, что в итоге на крестах пишут в стиле Си, с минимальным применением фичей крестов, в частности, без наследования классов и без крупных библиотек шаблонов. В итоге сам Си тянется к этому же стилю, с RAII на типах данных.

Как интересно. И почему же - в нынешних реалиях?

В нынешних реалиях уже довольно давно есть FPC, который кроссплатформенен и в том числе имеет LLVM бэкэнд.

Тут политика очень вросла. Даже токс испортили

А что с токсом?

Про LLVM для Pascal не знал.

Если говорить про «конкретный пример», то так-то я могу заметить, что проблему долгой сборки C++ перенял ни у кого иного, как у Си.

и приумножил раз в 100

Если говорить про «конкретный пример», то так-то я могу заметить, что проблему долгой сборки C++ перенял ни у кого иного, как у Си.

и приумножил раз в 100

Как и тридцать лет назад, основная затрата процессорного времени при компиляции C/C++ — это парсинг. Потому что язык изначально сделан криво и у него есть тяжелая контекстозависимость, вынуждающая парсер интерпретировать предыдущий текст, чтобы понять текущий обрабатываемый. Да, в крестах есть отдельные тяжелые случаи с рекурсиями шаблонов, которые могут перевесить парсинг, но как правило парсинг является основным фактором. То есть, чем больше компилятору нужно парсить кода, тем хуже.

clang для файла из 5 строчек с подключеним iostream выдает 40 тысяч строк кода и компилирует их пол секунды. clang для ренжей с прекомпилированным сорцом около 200 тыс строк тратит 2 секунды. То есть, цифры порядка 100 тысяч строк в секунду. MSVC для Си с достаточно генерирует 90 тысяч строк при достаточно большом числе подключаемых заголовков и скромном числе самих сорцов, и компилирует их полсекунды. То есть, где-то 200 тысяч строк в секунду. С радостью сравню мои результаты с вашими.

Таким образом, проблема компиляции C\C++ упирается в то, какой объем включаемых файлов вы используете. А этот объем неизбежно растет по мере роста уровня абстракций. Например, заголовки STL — это порядка 40 тыс строк. В то же время, заголовки Boost — это миллионы строк, пусть они и используются не все сразу. Далеко не все фичи STL можно натянуть на Си, а с Boost это и вовсе не прокатывает — придется переписывать алгоритмы из либы под каждый конкретный случай заново. То есть, экономия времени процессора достигается перекладыванием нагрузки на время программиста. И по мере роста количества таких заново написанных решений выясняется, что у них много заголовков — в том же питоне заголовки составляют около 20 тыс строк, то есть, при компиляции каждого питоньего модуля вы неизбежно получаете еще 20 тысяч строк в довесок ко всему тексту, что уже имеете.

То есть, фундаментальная проблема C/C++ заключается в том, что время компиляции плохо масштабируется по числу файлов при неизменном размере одного файла и соотношении сорцов/заголовков. Масштабирование получается примерно O(N^2 log N), что не есть куб, но квадрата всем хватает для того, чтобы при переходе с 100 тыс строк на миллион строк получить рост времени компиляции с одной секунды до нескольких минут, а при подходе к десяткам миллионов время уже начинает измеряться часами. Взять тот же хром, который весит 6 млн строк и компилируется 50 часов. Ядро Linux — он компилится два часа при размере в 27 млн строк. Лет тринадцать назад при размере в 8-9 млн он компилился менее часа, то есть, рост почти линейный. Это случилось благодаря тому, что основные заголовки слабо росли, а рост размера исходников происходил в основном за счет драйверов, которые составляют большую часть вообще всего репозитория ядра, при этом базовые сорцы линукса составляют порядка 5 млн строк. Это все равно плохое масштабирование по сравнению с паскалем, который при правильном построении связей модулей растет линейно по времени компиляции и компилирует 4 млн строк за две минуты (тру стори, между прочим, но сорцы я вам не дам).

Кстати, есть хороший пример с огнелисом против хрома. Огнелдис компилится примерно в 3.5 раза быстрее, чем хром, при этом содержит примерно в два раза меньше строк исходников. То есть, это тот самый намек на квадрат масштабируемости.

С радостью сравню мои результаты с вашими.

1 файл, 580 строк кода не считая #includes. понятно, что includes тоже хватает. метапрограммирование и все дела, разворачивается примерно в 100 тыс строк после шаблонов (опять же, не считая того что в #includes – чето я думаю там на многие миллионы счет пойдет). 2 минуты компиляция (i9, 32GB, SSD, clang - все по людски). есть еще штук пять подобных файлов, компилирующихся по одной-полторы минуты. эти ~2000 строчек кода в 5 файлах выжирают больше половины времени сборки всего таргета, в котором ~миллион строк кода, преимущественно ObjC. типичное время компиляции файла 0.1-0.2sec.

То есть, цифры порядка 100 тысяч строк в секунду.

это смотря какие строки :)

(на самом деле конечно 2 минуты это ничто.. в прошлом проекте время сборки занимало многие часы.. и ничего, с 2 компами для параллелизации, + билд ферма на 1000 одновременных билдов .. + много перекуров/кофе… и было даже терпимо)

разворачивается примерно в 100 тыс строк после шаблонов

Ты ничего не путаешь? Что разворачивается? Да, есть создание экземпляров шаблонов, но ему не соответствует никакое число строк — это делается уже с синтаксическим деревом, а потому намного быстрее парсинга.

Шаблоны тьюринг полны, потому можно вообще написать пять строчек, которые будут два часа выполняться. Но в реальных проектах такого почти никто не делает. К тому же, сделать что-то подобное на макросах си весьма и весьма сложно.

Ему соответствует то количество строк, которое необходимо теоретически чтобы получить тот же код без шаблонов. Каких-то еще причин для тормозов, типа циклов или еще чего-то такого, я в том коде не замечал, но если учесть, что никто не понимает что там написано - всякое может быть.

Своя собственная реализация криптографии. Точнее говнокод, в 2016 году им писали большой багрепорт, что-то пофиксили, а что-то осталось.

В 2020ом tree-контрол

Это сферический веб в вакууме с едущими в реальном вебе layout-ми. Даже в skype тут и там скроллы в неожиданных местах вылазят. Это ущербный UI.
Ну и шизофреничный - называешь treem а в xpath всё равно что-то другое. И да, рано или позно придётся лезть внутрь.

Аргументы уровня школьник.

А в vs code не вылазят. Где твой бог теперь?

У DOM есть сложившийся способ реализации. Набор того, что он отображает. А отображает он полное г...о, а не виджеты. С костыльным доступом к атрибутам, свойствам и событиям.

Ничего другого в xpath нет. Пользовательские теги часть стандарта. Кисни дальше в 96ом, маня.

Dom ничего не отображает. Он вообще никак не отвечает за отображение.

А в gtk никогда не вылазят. Хватит виджеты/контролы в html верстать.

Я понял, что ты живешь в собственном манямире.

Dom ничего не отображает. Он вообще никак не отвечает за отображение.

О да, потыкай меня разницей модели и инстанса, вместо ответа по существу.

И потыкаю. Ты же горе-неосилятор всего на свете, имеющий при этом всегда мнение. Типичное быдло.

Хуже, я SO driven developer.
Angular + TypeScript позволяют мне не так болезненно обращаться с web ui.

Sciter.

https://www.meme-arsenal.com/memes/898e00aef336ecf846a82b213d8fcb50.jpg

ТСу

nanoGui https://github.com/wjakob/nanogui + nanoVG https://github.com/memononen/NanoVG

Нет, понятно, что у вас Qt головного мозга в терминальной стадии и только Rust-ом вы в состоянии нормально пользоваться, но все-таки есть большой мир за пределами того, с чем вы знакомы.

Лол. Автор либы с 1.5 пользователями из солидарности толкает такую же васянскую либу. Сам-то пробовал её использовать?