Аналоги функций высшего порядка в С++

Лучше не часто, чем вообще никогда, не?

А что, структура матриц меняется со временем? Не, конечно всякие там гигантские sparse-матрицы на Java лучше делать, чем на Си.

А есть какая разница? Кто-то говорил, что

Ты никогда не сможешь без компактификации получить результаты лучше, чем с компактификацией.

Это не значит, что java в любом случае быстрее? Я, конечно, и близко не программист, заранее извиняюсь, могу любую тупость ляпнуть.

Но можно и с разреженными потренироваться. При перемножении разреженно-строчных матриц, емнип, всё равно получается два больших линейных куска со случайным доступом к одному из них. Что аллокатор Java тут сделает?

Ты тупой. Ссылки меняются на месте во время работы GC. Никакого лишнего уровня dereferencing там нет, идиот.

нет, это ты идиот - в C++ тоже нет никакого лишнего уровня в рантайме. Он есть только в исходнике.

У тебя же для A, B и C где-то еще есть объекты A', B' и C', в каждом из которых по указателю на A, B и C. В A и в B следующим элементом задан C', и только оттуда ссылка на реальное положение C. Ты идиот.

не. идиот это ты. ссылка это в любом случае какой-то указатель куда-то. Если я двигаю объект C, мне необходим список ссылок, на то, где этот C используется (A→B→), как раз твои A' B'. А без этого списка узнать, какие A и B юзают C можно только через libastral. Жаль, что ты не знаешь простых вещей.

Ты опять его не понял. Кстати, ты похоже действительно не понимаешь, как работает GC.

не. идиот это ты.

Сходи к врачу. У тебя явно шизофрения. Просто так, на ровном месте, такими дебилами люди не становятся.

Если я двигаю объект C, мне необходим список ссылок,

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

А без этого списка узнать, какие A и B юзают C можно только через libastral.

Может, тебе стоит сделать вдоль, после того, как ты так жидко обосрался? Ведь над тобой теперь все ржать будут!

Кстати, ты похоже действительно не понимаешь, как работает GC.

в жабе оно похоже без «пилять, шлюха» никак не работает. Судя по вышеприведённому описанию.

нет, это ты идиот - в C++ тоже нет никакого лишнего уровня в рантайме. Он есть только в исходнике.

Але, придурок, как раз в C++ тебе лишний уровень необходим - как иначе ты двигать объекты будешь, не изменяя всех ссылок (а изменять их ты не можешь, потому как не можешь отличить ссылку от не-ссылки).

Твоя мамка - шлюха-наркоманка, однозначно. Иначе как ты таким говном получился-то?

Не нужен тебе список ссылок. Это, недоносок, GC, он все ссылки и так найдет. Без списка, недоумок.

и как-же, позвольте узнать?

Может, отрыжка шлюхи, ты все же наконец прочитаешь, как работает compactifying stop and copy? Хотя бы тут: http://c2.com/cgi/wiki?StopAndCopy

Тебе совсем ничего не говорят словосочетания «GC руты», «периметр» и т.п.? Про «поколения» даже спрашивать не буду.

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

Тебе совсем ничего не говорят словосочетания «GC руты», «периметр» и т.п.? Про «поколения» даже спрашивать не буду.

вот и правильно. Не спрашивай. Всё равно не поймёшь.

При перемножении разреженно-строчных матриц, емнип, всё равно получается два больших линейных куска со случайным доступом к одному из них. Что аллокатор Java тут сделает?

Я туплю. Символьная часть алгоритма действительно может сильно зависеть от реализации аллокатора.

Как, ты еще не сделал вдоль? Так смачно обосрался - и все равно продолжаешь свою клоунаду? Браво, силён! Непрошибаемая дубовая башка!

Именно. Вообще символьные вычисления от реализации GC и аллокатора сильно зависят. Mathematica такой тормоз не в последнюю очередь благодаря своему замшелому reference counting движку.

...но не факт, что в случае с разреженными матрицами боттлнек будет именно в аллокации. Там и сильно случайного доступа и ветвлений достаточно.

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