я сколько общался со страдальцами - все жаловались на синтаксис я сам не могу быть объективен, так как на плюсах пишу уже лет 15 и давно глаз замылен т.е. что-то типа typedef boost::shared_ptr< Frame > FramePtr; FramePtr frame = boost::make_shared< Frame >( data, width, height, pixelformat ); не вызывает проблем никаких, но для многих может быть непривычным
зачем. это говно уже вымерло и никому не надо. к счастью. и если мне уж КРАЙНЕ важен будет предсказуемый перфоманс, я возьму си. код по итогу получится и чище и читаемей и сопровождаемей.
значит дебилы-страдальцы попадались. Это бывает. Конкретно тут -- разве что type inference могла бы пофиксить синтаксис, да и то, не сильно: убрать typedef и/или тип значения frame. Но в данном куске кода это всего лишь косметика, к такому придираться низко. К отсутствию type inference придерусь, но это не синтаксис, а типизация (которую я бы назвал "семантика для компилятора", хотя слишком вольно звучит). В остальном -- пример очень понятный с точки зрения синтаксиса, если знать, что такое "t1<t2>" и "::" и представлять параметризованные типы данных (так называемая "большая лямбда" в функциональщине, "типы, зависящие от типов").
boost - это не ональная пробка. это трансцендентальный ональный отбойный молоток для режекции гланд якорем от титаника. большего пиздеца в жизни не видел. как ЭТО можно вообще использовать и быть уверенным в том, что оно будет работать - зогадко.
> если не делать встроенные функции в мс-стиле с стопицот NULL параметров
А если делать?... Если в количестве параметров обшибёшься, то очень быстро программа улетит. Хотя и ругань компилятора тут гораздо приятнее, конечно. Про это речь?
Ну вот там Никита упомянул http://metaclass.livejournal.com/701072.html?thread=12798864#t12798864 про неудобства с функциями со стопицот параметров, у которых 2/3 NULL. Естественно, что первое, что приходит в голову, что макроассемблер должен быть типизированный. Ну и так далее ;-)
Ну-ну, попробуй. Будет эмуляция С++ на монадах и хаскельном синтаксисе, в три раза многословнее Си, ибо скорее всего очень много низкоуровневых моментов придется прописывать явно.
Page 5 of 7