(C++)++

Сподобился прочитать сорсы функции std::move и std::forward.


Что-то они в этом Сипипи совсем куда-то не туда зашли. Уж лучше многоярусные навороты в духе буста или Александеску, чем вот такие интересные примеры хлопков одной рукой.

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

академическое

Вот чего я не пойму никак - это как правильно делать выгрузку модулей в системе вроде DCOM.

Там имеется такой забавный race-condintion, что когда модуль решает, что все его объекты уничтожены и его можно выгружать, это решение принимается в коде самого модуля, так что, приняв подобное решение, код может не успеть покинуть модуль, как модуль уже будет выгружен системным тредом, успевшим черезчур быстро прочитать состояние "все объекты уничтожены", что приведет к крэшу. Классику эту еще Don Box описывал.

Можно, конечно, ввести некий протокол, обязывающий уже вызывающий код менять состояние модуля, скажем, декрементируя некоторую переменную, адрес которой он может узнать, запросив модуль. Т.е. вместо того, чтобы вести учет ссылок внутри модуля, можно обязать делать это вызывающий код. На С++ подобное можно вообще завернуть в то, что методы модуля могут возвращать некие объекты, которые, деструктурируясь, модифицирут состояние модуля, причем код модификаторов забит в .h файлы, т.е. заведомо влинковывается в код вызывающего клиента. Я, впрочем, не уверен, что стандарт С++ гарантирует, что код из .h заведомо влинкуется или заинлайнится в код клиента.

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

Оба решения, впрочем, представляются какими-то уродливыми, натужными. А вот нормального решения, про которое можно сказать "именно так и надо это решать" что-то пока не видно.

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