0xd34df00d
13.07.2012 05:29 Azoth_primary
Как выглядит расчет размера пиксмапа на плюсцах?
px.depth () * px.width () * px.height ();
А на сишечке?
fz_pixmap_components (MuCtx_, px) * fz_pixmap_width (MuCtx_, px) * fz_pixmap_height (MuCtx_, px);
Пока сибляди пердолятся с явной передачей стейта, учетом ссылок и недоэкзепшонами, плюсобоги давно написали требуемый код и радуются себе
57 comments
recommend
bookmark
subscribe
о, б-же, почему не
d * w * h;
ну или
px.d * px.w * px.h
???)
Потому что так устроена кококо инкапсуляция в сишечке. Олсо, авторы mupdf так решили.
инкапсуляция ... в сишечке ...
объекты ... в сишечке ...
фабрики ... в сишечке ...
да они ёб-лись
Да.
А в C# бы так и выглядело, ибо есть properties, а вот плюсобоги соснули.
В гейдеве модно придумывать свое ООП для C :)
В плюсах пропертиз пишутся на коленке за минуту.
А как бы это в хаскеле выглядело с Control.Arrow... Ох.
И что, будет без макросов и с нормальным синтаксисом аля "доступ к полю" ?
объясните мне, чем пропетриз отличают от публичных членов,
Т.е. Q_PROPERTY я юзаю и сам, ага.
Под проперти спрятаны геттеры и сеттеры, очевидно же. Которые вызываются неявно. Акромя того, проперти позволяют семантически выделить настраиваемую часть класса. Посмотри, как устроены те же плагины для QtDesigner.
Да. Вызов геттера при доступе на чтение (const) и сеттера на запись.
Уебищно.
все равно не понимаю, почему вы так писаетесь от них
А ну-ка запали :)
Кто спорит ?
Никто не писается, здесь это онтопик.
Щя, нагуглю статеечку на кывте.
Я вообще не понимаю, нахуй они их так сделали.
http://www.rsdn.ru/article/vcpp/props.xm...
как-то оверхедно получается
Што.
Оверхэдненько, но мне нравится.
Не уверен насчет оверхеда. Компилеры нынче умные и заинлайнят тривиальные вещи.
Указатели на функции заинлайнят ? 12 байт оверхэда памяти съедят ? Пруф или не было.
Память хуита. Указатели на функции иногда инлайнятся, по крайней мере, гцц. Пруфы сам гугли.
>Память хуита
типичный личкрафтописатель (
Компиляторы нанче умеют инлайнить вещи из других модулей? Например, если я в цикле 100000 раз сделаю printf, он у меня заинлайнится?
LTO. Могут и синлайнить.
Хотя, я не уверен, что принтф сам по себе инлайнится, varargs и хуе-мое все же.
Особенно писаемся адовой злостью, когда что-то, являющееся property, начинает по сети делать запросы в БД.
Как будто простой геттер не может.
Олсо, а вот в функциональных языках такой проблемы нет по определению ;3
геттер — хотя бы видно, что это функция. короче считаю дурным тоном если property лезет за пределы объекта.
функциональные языки не умеют работать с базами данных?
Ваганыч, залогиньтесь.
ну объясни же, какой проблемы нету и почему
лол — в самую точку
Что геттер или свойство или еще что куда-то там полезет.
Все, что куда-то лезет во внешний мир и не является referetially transparent, по построению системы типов языка должно быть упихано в IO-монаду, а это ваще сразу видно.
при чем здесь вообще функциональные языки? это к типизации скорее отношение имеет. ну и, собственно, да, еще можно в исходники посмотреть и убедиться что оно куда-то лезет. вопрос-то в том, что это в любом случае сделать можно и это уёбищно (даже если написать большими буквами про IO-монаду).
Ты что ли вообще не понимаешь, что IO — unescapable?
А функциональщина притом, что я бы посмотрел на императивный чистый язык без сайдэффектов и с явно выделенным IO-подобием. Покажешь?
В C# бы выглядело как px.Depth*px.Width*px.Height, что отличалось бы от плюсцов только отсутствием скобочек.
В первой фразе имеется ввиду IO monad, а не ввод-вывод, есличо.
Могу показать функциональный без IO-монад. Показать?
Ну и, собственно, от того, что я явно буду знать, что property будет куда-то лезть по сети — какая разница, узнаю я об этом из прочтения исходников, или из IO-монады? Какая разница, создавать костыли скрыто или явно?
Можно и лисп функциональным назвать, и что?
Потому что исходников может не быть. Потому что исходники могут поменяться. Потому что, блять, нахуя вообще обходить весь граф исходников, когда можно положиться на систему типов и тайпчекер? А то какой-то питон получается уже — нахуя нам типы, мы лучше напишем юнит-тесты! Нахуя нам проверка наличия сайд-эффектов, мы лучше полазаем руками по исходникам и напишем еще тестов!
еще раз. IO-монады — это очень круто. проблемы в твоих утверждениях про "в функциональных языках этих проблем нету", наверное ты имел в виду языки с IO-монадами, а не функциональные языки. а также в том, что проблемы всё равно есть, просто ты о них легче можешь догадаться.
ну и, собственно, юнит-тесты всё равно писать придётся, когда вокруг тебя сплошные IO-монады (код, который я пишу, реально имел бы IO-монады практически везде, потому на мой взгляд выигрыш был бы минимальным, а вот в не-веб проектах с удовольствием ощутил бы преимущества от явного указания наличия сайд-эффектов)
Естественно. Я имел ввиду нормальную функциональщину с хорошей системой типов, позволяющей делать такие вещи.
Почти всегда можно инкапсулировать всю логику в чистую часть, а с внешним миром общаться из main, условно.
ReadOnly пропертя с геттером такого содержимого не ?
Конечно, смысла в ней мало, но сам подход.
> Почти всегда можно инкапсулировать всю логику в чистую часть, а с внешним миром общаться из main, условно.
вот нихуюшечки! конечно, каждый из нас хотел бы построить систему в виде "выбрал все необходимые входящие данные — запустил систему — на выходе получил набор сигналов для изменения БД и прочего IO", это было бы легче как юнит-тестировать, так и монадами обкладывать, абсолютно похуй, выигрыш и там и там был бы. но, по крайней мере для веба, это совершенно нереально (или сверх-дорого и ненужно).
Посмотри в сторону happstack, что ли.
Зачем? Я говорю о вещах, не зависящих от языка или платформы.
А там интересный подход к этому всему. Правда, слишком много монад, я ниасилил.
Подход, который я описал, описывали на каком-то переписывании какой-то биржи очень детально. Собственно, отсутствие IO у них там привело не только к тому, что охуенно всё тестируется, но и к тому, что вся эта система (биржи) работает в одном потоке! При этом в состоянии обслужить всю биржу за нехуй делать.
Но это биржи, умные дядьки, большие ресурсы на разработку и всё такое, а не веб-бомжи :)
http://martinfowler.com/articles/lmax.ht...
как хаскель выучу — посмотрю обязательно
у нас на проекте макрос есть
class Ololo
{
DEFINE_SIMPLE_STATE(SomeType, type, Type);
private:
SomeType type;
}
Вот сам макрос:
#define DEFINE_SIMPLE_STATE(type, vname, fname) \
public: \
inline type fname() const { return (type)vname; }; \
inline void fname(type _state) { vname = _state; }; \
private:
Property обычно не нужен. Обычно бывает нужна интроспекция и динамическое добавление публичных членов/методов (хотя это тоже можно посчитать за плохой дизайн), но так как это в плюсах невозможно просто, то и делают это через чёртовы Property
Я просил без макросов, так и ежу понятно же.