Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Когда необходимо обеспечить парный вызов метода (сначала с одними параметрами, потом с другими - отменяющими первый вызов), лучше таких вот мелких объектов еще ничего не придумано.
Налицо не говнокод, а недостаток понимания.
По-моему лучше просто быть внимательнее, чем подобные шняги. А то потом непонятно почему начинают отрисовываться части со сглаживанием и без.
Даже укоротить это до context_->smoothingMode(bool) и то понятнее и удобнее. И пусть низкоуровневые товарищи поправят, но вроде как вызвать метод два раза побыстрее, чем создавать для этого экземпляр класса.
Быстрее конечно, память же не надо выделять.
Хотя это тоже вопрос - если этот класс на стеке, то тут уже надо мерять.
И еще вопрос в том, как компилятор на это посмотрит. Если соптимизирует - то вообще пофигу.
> По-моему лучше просто быть внимательнее, чем подобные шняги.
Подход неправильный.
Если развить эту мысль - то зачем вообще использовать языки высокого уровня? Лучше просто потребовать от программиста быть повнимательнее. И пусть в машинных кодах программит.
> А то потом непонятно почему начинают отрисовываться части со сглаживанием и без.
Заворачивание функций в класс как раз и гарантирует, что при деструкции объекта в обязательном порядке будет вызвана функция, отключающая сглаживание. В результате неразберихи становится гораздо меньше, чем если требовать от программиста вызвать отключалку сглаживания вручную (то return из функции неожиданный сработал, то эксепшен пришел, то программист в чужом коде не разобрался).
> И пусть низкоуровневые товарищи поправят, но вроде как вызвать метод два раза побыстрее, чем создавать для этого экземпляр класса.
Напомню, что речь идет о GUI. О каком-таком "быстрее" мы говорим? 🙂 Пара сэкономленных машинных команд - это ничто.
Создание экземпляра данного класса на стеке - это две операции:
1. Сохранить указатель на контекст по адресу в стеке
2. Вызвать метод по указателю.
Область памяти под объект выделяется в кадре стека - это бесплатно с точки зрения накладных расходов.
Итак, от "ручного" вызова функции наш объект отличается фактически только одним-единственным присваиванием. Вы ради этой экономии будете заставлять программистов отслеживать парность вызовов по всему коду?
надо смотреть асмовый листинг...
по моему тут все заинлайнится... а если указатель на контекст сделать константным, то и на стеке ничего не будет...
и виртуальный деструктор не нужен...
Наличие виртуального деструктора - единственный прокол в этом коде. Плюс один лишний пойнтер в классе (на _vtbl).
Даже вызов деструктора любой более-менее вменяемый компилятор оптимизирует в обычный call.
В первом случае - честное вычисление, во втором - константа вычислена на этапе выполнения.
В случае с константными членами класса с С++, конечно, не все так прямолинейно. При создании объекта на стеке под константный мембер будет отведено место. Но тем не менее кое-какие оптимизации возможны и в этом случае (особенно если класс шаблонный).
В обоих случаях хороший компилятор подсчитает это на этапе компиляции и не будет городить огород из инструкций с включенной оптимизацией. Чем пользуетесь? Что-за говнокомпилятор?
новичек? иногда выбор компилятора навязывает платформа... это под виндой их десяток, а под ПС3 он один, и под iPhone - один, и еще бог знает (а консолей и мобильных девайзов сейчас развелось достаточно) где он тоже один...
профессионализм как раз заключается в умении писать код а не выбирать компиляторы...
Вместо того, чтобы улучшать качество своего кода, ты переваливаешь ответственность на компилятор. Типа, компилятор должен сам разобраться, где тут что, и оптимизировать соответственно.
Это признак непрофессионализма, как совершенно верно заметил pushkoff. Отказ от расстановки const - это прежде всего отказ от документирования собственного кода. Нет const - нет сведений о том, можно ли изменять значение в данном месте кода или нет. Меньше сведений о коде - больше работы придется сделать тем, кто будет поддерживать твой код после тебя.
Не говоря уже о том, что надеяться на интеллектуальность компилятора там, где он проявлять интеллект вовсе даже не обязан - детский сад.
>где он проявлять интеллект вовсе даже не обязан
Обязан. 🙂
>Типа, компилятор должен сам разобраться, где тут что, и оптимизировать соответственно.
Как признак оптимизации const я раставлять не обязан. Если глупый компилятор соптимизирует мне то, что помечено, как const, а я потом это место const_cast'ом запаганю, то это исключительно глупость компилятора. Если не понятно, то могу привести пример.
>const - это прежде всего отказ от документирования собственного кода
Я где-нибудь сказал, что их не ставлю? Я сказал, что это не имеет отношение к оптимизации.
Налицо не говнокод, а недостаток понимания.
Даже укоротить это до context_->smoothingMode(bool) и то понятнее и удобнее. И пусть низкоуровневые товарищи поправят, но вроде как вызвать метод два раза побыстрее, чем создавать для этого экземпляр класса.
Хотя это тоже вопрос - если этот класс на стеке, то тут уже надо мерять.
И еще вопрос в том, как компилятор на это посмотрит. Если соптимизирует - то вообще пофигу.
Подход неправильный.
Если развить эту мысль - то зачем вообще использовать языки высокого уровня? Лучше просто потребовать от программиста быть повнимательнее. И пусть в машинных кодах программит.
> А то потом непонятно почему начинают отрисовываться части со сглаживанием и без.
Заворачивание функций в класс как раз и гарантирует, что при деструкции объекта в обязательном порядке будет вызвана функция, отключающая сглаживание. В результате неразберихи становится гораздо меньше, чем если требовать от программиста вызвать отключалку сглаживания вручную (то return из функции неожиданный сработал, то эксепшен пришел, то программист в чужом коде не разобрался).
> И пусть низкоуровневые товарищи поправят, но вроде как вызвать метод два раза побыстрее, чем создавать для этого экземпляр класса.
Напомню, что речь идет о GUI. О каком-таком "быстрее" мы говорим? 🙂 Пара сэкономленных машинных команд - это ничто.
Создание экземпляра данного класса на стеке - это две операции:
1. Сохранить указатель на контекст по адресу в стеке
2. Вызвать метод по указателю.
Область памяти под объект выделяется в кадре стека - это бесплатно с точки зрения накладных расходов.
Итак, от "ручного" вызова функции наш объект отличается фактически только одним-единственным присваиванием. Вы ради этой экономии будете заставлять программистов отслеживать парность вызовов по всему коду?
по моему тут все заинлайнится... а если указатель на контекст сделать константным, то и на стеке ничего не будет...
и виртуальный деструктор не нужен...
Даже вызов деструктора любой более-менее вменяемый компилятор оптимизирует в обычный call.
Кто-то такое сказал? const никогда не влияет на оптимизацию.
А вообще приведи хоть один дизасемблерный листинг, где из-за const произошла оптимизация? Небывает такого.
int a = 5;
const int b = 5;
printf( "%d\n", a + 5 );
printf( "%d\n", b + 5 );
Ассемблерный код:
movl a, %eax
addl $5, %eax
movl %eax, 4(%esp)
movl $.LC0, (%esp)
call printf
movl $10, 4(%esp)
movl $.LC0, (%esp)
call printf
В первом случае - честное вычисление, во втором - константа вычислена на этапе выполнения.
В случае с константными членами класса с С++, конечно, не все так прямолинейно. При создании объекта на стеке под константный мембер будет отведено место. Но тем не менее кое-какие оптимизации возможны и в этом случае (особенно если класс шаблонный).
В свете этой радости использованный компилятор, уверяю вас, абсолютно не важен.
А const ставить милионы раз. На лицо не оптимальность принятого решения. 🙂
профессионализм как раз заключается в умении писать код а не выбирать компиляторы...
;p
Это признак непрофессионализма, как совершенно верно заметил pushkoff. Отказ от расстановки const - это прежде всего отказ от документирования собственного кода. Нет const - нет сведений о том, можно ли изменять значение в данном месте кода или нет. Меньше сведений о коде - больше работы придется сделать тем, кто будет поддерживать твой код после тебя.
Не говоря уже о том, что надеяться на интеллектуальность компилятора там, где он проявлять интеллект вовсе даже не обязан - детский сад.
Обязан. 🙂
>Типа, компилятор должен сам разобраться, где тут что, и оптимизировать соответственно.
Как признак оптимизации const я раставлять не обязан. Если глупый компилятор соптимизирует мне то, что помечено, как const, а я потом это место const_cast'ом запаганю, то это исключительно глупость компилятора. Если не понятно, то могу привести пример.
>const - это прежде всего отказ от документирования собственного кода
Я где-нибудь сказал, что их не ставлю? Я сказал, что это не имеет отношение к оптимизации.
вот твой предидущий пост http://govnokod.ru/2657