История изменений

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

🤦‍♂️

В STL строки до сих пор без счетчиков ссылок. Сколько уже крестовых библиотек заново реализовали строки только по этой причине?

Не так уж и много. И вот незадача: многие реализации так и остались без счетчиков ссылок, либо применяют их только для больших строк, либо используют и std::string, и custom_string одновременно.

Именно потому, если бы C++ проектировался и решения взвешивались, то деструкторы никогда бы не должны были высвобождать память под объектом, включая случаи, когда в память записывается другой объект, поскольку это фактически неявный free-malloc.

Бред. Конкретный класс написан так, чтобы высвобождать память под объектом после его удаления, так как ссылочные циклы достаточно нечастое явление.

Да, челы изобрели garbage collector, теперь с квадратными колесами.

Это не garbage collector.

Я подчеркиваю, что челы из гугла банально борятся со врожденными недостатками C++, которых просто не должно было стать еще на этапе проектирования ЯП

Нет. Челы из гугла озадачились проблемой UAF – и сделали для своего типа свое поведение. Твои рассказы про невозможность чего-то там оказались бредом.

(8000 измененных файлов, бг-г-г):

Rewrite most Foo* field_ pointer fields to raw_ptr<Foo> field_.

Сразу в лужу.

Я уничтожил объект, он уничтожил все объекты, на которые ссылался — в чем тут проблема?

Два объекта ссылаются друг на друга. Уничтожай.

Проблема в том, что ты мыслишь в той же патологической парадигме «вызов деструктора наделяет область хранения неопределенным значением»

Цитату, ссылку на сообщение.

В принципе, с приседаниями эта проблема решаема:

Такой же необучаемый пишет статьи. Код – просто пушка.

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

🤦‍♂️

В STL строки до сих пор без счетчиков ссылок. Сколько уже крестовых библиотек заново реализовали строки только по этой причине?

Не так уж и много. И вот незадача: многие реализации так и остались без счетчиков ссылок, либо применяют их только для больших строк, либо используют и std::string, и custom_string одновременно.

Именно потому, если бы C++ проектировался и решения взвешивались, то деструкторы никогда бы не должны были высвобождать память под объектом, включая случаи, когда в память записывается другой объект, поскольку это фактически неявный free-malloc.

Бред. Конкретный класс написан так, чтобы высвобождать память под объектом после его удаления, так как ссылочные циклы достаточно нечастое явление.

Да, челы изобрели garbage collector, теперь с квадратными колесами.

Это не garbage collector.

Я подчеркиваю, что челы из гугла банально борятся со врожденными недостатками C++, которых просто не должно было стать еще на этапе проектирования ЯП

Нет. Челы из гугла озадачились проблемой UAF – и сделали для своего типа свое поведение. Твои рассказы про невозможность чего-то там оказались бредом.

(8000 измененных файлов, бг-г-г):

Rewrite most Foo* field_ pointer fields to raw_ptr<Foo> field_.

Сразу в лужу.

Я уничтожил объект, он уничтожил все объекты, на которые ссылался — в чем тут проблема?

Два объекта ссылаются друг на друга. Уничтожай.

Проблема в том, что ты мыслишь в той же патологической парадигме «вызов деструктора наделяет область хранения неопределенным значением»

Цитату, ссылку на сообщение.