0xd34df00d
07.11.2011 18:41 Azoth_primary
Как бы объяснить долбоебу, что запихивание во вьюшку бизнес-логики — пиздец? И что реализация во вьюшке говн-адаптеров к модели для внешнего мира, ибо «модель лень получать» — тоже пиздец?
И почему мне все это очевидно?
47 comments
recommend
bookmark
subscribe
Дай почитать книжку вроде «Проектирование ПО для чайников», если есть такая
Можно пойти на компромисс и зделоть как в Qt. Для тяп-ляп All-in-one, а для четкости — M-V. Беда в том, что чувак твой просто еще застрял в стадии "тяп-ляп".
не обьясняй, сразу в щщи с вертушки
Зачем объяснять? Тупо отправь читать что-то на тему "mvc for idiots".
вспомнилась передача «Для самых маленьких и тупых»
Там нужно что-то попроще.
Он далеко :(
Он не либу пишет, к сожалению.
это ты о ком?
И где ты только находишь таких девелоперов. У нас в ынтырпрайзе все проще )
Угадай с π/4 раз.
Какие есть :(
ты себе заводишь миньонов и тенишь их писать личкрафты? :-D
игно?
Кстати, отказаться от m-v бывает полезно для оптимизаций. Скажем, пилишь ты быстро обновляющийся график, тебе для скорости лучше дать в него C-массивы, чем векторы-модели-хуе-мое. Опасно и не православненько для плюсоеба, но чистая скорость же.
Его ж выгнали, не?
Именно!
А он все равно чо-то пишет.
Тут плейлист медиаплеера, тут это не нужно :3
Хм, тогда кинь ему статьи из того же Qt, проще не бывает же.
он принципиально не читает доки и любые статьи по теме
Он принципиально долбоеб ? :)
Што, ты тоже считаешь что c-style arrays и алгоритмы на них мифическим образом работают быстрее их аналогов, использующих вектор?
Да :(
да
Нет, дело не в самом векторе, а в способе высунуть его в API, например.
И да, почитай внутренности STL в той же MSVC, как неоднозначно там раскиданы оптимизации по алгоритмам. std::copy то, конечно, memcpy как пить дать для всяких интегральных типов и указателей, а вот остальное далеко не так радужно.
Я намекаю на то, что для шаблонов так и нет спецификации ABI в C++11. Те же Java/C# спокойно позволяют сувать наружу дженерики.
Спецификация ABI есть хоть для чего-то в C++?
А причина невозможности сувать наружу, если ты о переходе границ юнитов компиляции, совсем в другом.
Ну я так понимаю просто в том, что специализация генерится по факту использования, а поскольку шаблон торчит наружу, то использования нет, значит нет специализаций. Если бы они генерились, то оно бы противоречило всем устоям, угу.
Блин, я ошибся. memcpy там запрещен. memove только (который медленнее из-за проверок перекрытия). Отсылаю в Advanced STL Video Lectures на MSDN Channel 9.
Типа того (если я тебя правильно понял). Они по определению не могут генериться, потому что непонятно, для чего шаблон может использоваться — там, вообще говоря, не менее чем счетное множество вариантов.
Просто темплейты в C++ — это действительно функция времени компиляции. А дженерики в шарпах-явах — хуита времени исполнения с некоторыми профитами и гарантиями от компилятора.
Ну что за миф про «memmove медленней»?
С затиранием типов, зато, ага. Правда и в C++ его юзают, в том же std::shared_ptr оно используется для уравнивания make_shared и простого конструирования.
У тебя завелся литературный негр от программирования? :)
Ну как сказать, ты же не будешь отрицать, что проверка в memmove есть, а в memcpy нет ? ;) (по референсу, а не по реализациям, особенно в этом линукс-мирке)
Я буду отрицать, что проверка заметно медленнее. Достаточно сравнить, какой указатель больше, и какой меньше, и для этого выбрать стратегию копирования — в сторону роста или уменьшения адресов.
Даже я, прикладноблядь, все это знаю.
Ты очень удивишься, если возьмешь любую живую реализацию и сосчитаешь, сколько разных проверок есть в memcpy.
Уже давно никто не пишет просто rep movsb.
Потому, конечно, можно упорно утверждать, что memmove медленнее из-за одного лишнего сравнения, но, гм, зачем?
>>Also on some architectures memcpy() can benefit from using CPU instructions for moving blocks of memory — something that memmove() cannot use.
http://stackoverflow.com/questions/19609...
Ну вообще, да, тут спор уже никчемный с моей стороны, утрирую больно (про memmove vs memcpy).
Это будет верно только в том случае, если граница "наложения" буферов будет находиться внутри такого блока. И, очевидно, только для одного этого блока.
Я уже слился, поскольку сам разуверовал :) Но в любом случае, спасибо.
Я тоже прикладноблядь ;[
как как, ногой по яйцам
дедфудовщина... yet another one прецедент, доказывающий, что даже люди, которые осознают большую часть говна мира не могут банально забороть его в себе.
Че.
да бред какой-то, чё