Нет, тут как раз энумерацией описываются только тип магов (или его специализация). Все объекты логики приложения остаются объектами (с отдельными классами) и в коде тоже. То есть солдат и маг — абсолютно разные объекты с разными характеристиками, пусть и унаследованные от общего класса юнит. Вообще в приложении любой объект со своей логикой должен быть отражён не больше и не меньше так же, как и в человеческом описании. То есть у вас есть Герой с Юнитами (маги, воины, стрелки, разведчики), Карта с Препятствиями (брёвна, озёра, горы и т.п.) вот как вы их описали бы дизайнеру или другому разработчику, так и должно оно выглядеть в коде. Чтобы я мог заглянуть и сразу найти класс Маг и посмотреть что и как я могу поправить в его интерфейсе/реализации, безо всяких лишних бредовых лишних сущностей.
На самом деле справа в первом примере класс Менеджер лишний вплоть до введения печки. Делался хлеб = создание объекта Хлеб. Во втором примере и далее Менеджер = Печка, которая печёт хлеб, вот тут и надо вводить класс Печка/Менеджер. Так в целом справа отличный подход. Пользователю вашей библиотеки нужно от интерфейса не больше и не меньше, чем требует логика приложения. Ему нужно сначала Хлеб, потом Печка, а в конце Кирпич. Вот только сразу возникнет вопрос у пользователя библиотеки Маркуса: «А где печка, что я заказывал?». Не думаю, что ответ: «Менеджер — это на самом деле Печка!», — его устроит. Скорее всего следующий вопрос «А нафига?!» своей риторичностью приведёт Маркуса к небольшому рефакторингу по переименованию Менеджера в Печку.
ORM со всеми моделями, сущностями и коллекциями придумали для удобства использования. Если использование ORM становится неудобным, в нём пропадает всякий смысл, следует перейти к использованию SQL-запроса. Я понимаю что типизованные конструкции превращаются просто в строку, но сделать ошибку в нечитабельной ORM-конструкции на порядок больше чем в чётко выстроеном простом и читаемом запросе с несколькими AND или OR, на который глядишь и всё понятно.
Имхо, если запорожец не едет в гору, есть смысл доехать на велосипеде. Толкать в гору запорожец, только потому что он машина и едет быстрее немного нелогично. Так и тут, смысл использовать ORM в задаче, которую он не покрывает.
Мне больше нравится PyDev для Eclipse. Мало того, что он бесплатный, так его уже выкачиваешь (или отдельно ставишь) компилятор C++ (для расширений очень полезно). В него идёт отличный SVN клиент (хотя вру, даже два, мне больше нравится тот что сторонний). PyCharm конечно хорош, но я ни на что не променяю «универсальный звездолёт», мне просто нравится видеть что изменилось и коммитить в репозиторий всё в том же окне. А при разработке C++ проектов иметь возможность писать скрипты на Python (какая-нибудь генерация констант по файлу например), Очень удобная вещь Eclipse + CDT + PyDev + Subclipse.
Есть смысл посмотреть в сторону Django, шаблоны оттуда пошли во все остальные платформы.
Если конечно не пугает перспектива разработки на питоне.
В коде шаблона (по сути обычный HTML) встречаются конструкции вида {{ name }} или {% if var > lim %}, ну или {% for x in mass %}.
А уже в коде на сервере вызывается простая функция render_to_response( 'page.html', { name: Some.objects.get( descr='Petya' ) } )
Эта функция при ответе заполнит всё нужными значениями при отправке на клиентскую сторону.
Никто не спорит, что на С++ можно исхитриться писать так же эффективно, как и на Си. Вот только проблема в том, что сделав пару #include из STL и написав объектный модуль с иерархией и наследованием объектов событий (был такой протокол), мы поимели увеличение прошивки ровно в два раза с 0,7 МБ до почти 1.4 МБ. Мало того что её ещё приходится заливать дольше, так ещё и компилируется всё это добро крайне небыстро. Пришлось сделать кусок прошивки опциональным, после чего он стал крайне непопулярным и его редко кто включал в сборку.
Функционал С++ никогда на этом уровне не был настолько уж жизненно необходим. Что за такая нелюбовь с Си, что прямо так и тянет потратиться там, где дорог каждый байтик.
Первый человек, которому нужна производительность многопоточного приложения и выбирающий между Python и Perl. При желании можно создать неуправляемый поток ОС напрямую через API платформы. Причём я бы посоветовал писать C-extension, если уж нужна и производительность и функционал питона.
Спасибо большое за статью. Стоит заметить, что многопоточности питона хватает выше крыши, для того чтобы распараллелить эмуляцию действий различных пользователей на сайте, а также тестирование любого массового сетевого взаимодействия. Мало того, тут GIL даже помогает, мы видим в каком потоке остановились во время отладки и видим стек. Насколько я помню ограничения GIL позволяют сериализовать состояние потока, включая его имя, а также позволяет спокойно отлаживаться в одном потоке, так что остальные потоки в этот момент не мешают.
Давно известный факт, используешь список — помни что размер у него запрашивать — зло.
В общем-то поэтому почти никогда не использую std::list.
Чаще всего требуется std::deque — отличный контейнер, с быстрой индексацией и линейным запросом размера, не кирпич как std::vector, и не цепочная колбаса как std::list.
В третьем питоне первый же отступ берётся за эталон. Никаких миксов пробелов и табов, либо пробелы, либо таб. Причём если отступ задан пробелами, то размер отступа фиксируется по эталону.
Если уж так прямо волнует отсутствие единообразия синтаксиса, могу предложить сравнить с языком Python, который, кстати, имеет отличную библиотеку обвязки С++ boost::python
Python:
if a < b: # без вариантов
a = c
func( b * b )
else: # без вариантов
b = c
func( a * a )
C++:
if( a < b ) { // или всё же на следующей строке?
a = c;
func( b * b );
} // или всё же на той же строке, что и else! а может вообще на предыдущей!
else { // или всё же на следующей строке?
b = c;
func( a * a );
} // или всё же на следующей строке?
Имеется в виду, что аргументы было бы выгоднее сделать const T&, от сохранения видимо никуда не денешься, однако было бы здорово сохранять ссылку на протяжении всей цепочки вызовов, а не копировать всё содержимое объекта. Использование такой конструкции рано или поздно приведёт к рекурсивному/цепочному использованию подобных функций и обобщению их в библиотеку общего пользования. Поэтому было бы здорово чуть-чуть доработать рабочий пример.
А теперь представим, что мы набираем с помощью Вашей функции HTML-страничку, состоящую из длинного списка (результат простого SELECT например). Например первый аргумент фиксированный, и он и будет результатом. Нужно пройти по результату запроса и набрать результат. Насколько эффективно будет использовать std::string вместо const std::string? Учитывая, что мы подразумеваем список элементов или просто параграфов , то было бы неплохо ещё складывать с const char*. Опять же тут мы снова получаем промежуточное преобразование в std::string с копированием. C++ такой язык, где либо получаем максимум эффективности, либо у начальства рано или поздно возникают вопросы «А почему на скриптовом языке получается быстрее?»
curry_<int,int,int>(sum) замените на std::string, придётся писать ряд реализаций для const std::string&, а также специализацию для const char*. Строки тоже можно складывать, так что сумма должна уметь считаться и от них.
Ещё есть сумма N-мерных векторов, матриц MxN, сумма комплексных чисел. Каждый из этих объектов нуждается в передаче по ссылке, а не по значению. Сохранять куда бы то ни было по значению, значит копировать = потеря по времени для функции, которая претендует на всеобщее употребление, т.е. критична к производительности.
Полностью согласен. Если нужно строгое разделение по типам, не поленитесь создать новый тип с удобным интерфейсом. Иначе потонете в море неявных приведений. Шаблоны всё-таки не для этого придумывали, здесь утиной типизацией даже и не пахнет. Изначально есть какой-то примитивный тип и необходимо сделать ещё два совместимых. Так и задайте два новых типа явно.
Сейчас очень много завязано на питон 2.х, переход на 3.х сопряжён с рядом трудностей, связанных с ограничениями питона 3 и отсутствием обратной совместимости там, где её и не должно быть. Однако при портировании как правило вылезают косяки: строки и массивы байт в питоне 2.х — одно и то же, это отследить сложно но можно, однако во всех сетевых библиотеках приходится проходиться по всем send/receive и менять data на data.encode() и data.decode(). Ну и всякие неприятные мелочи, которые 2to3 сама понять не в состоянии. Автор PyBrain будет очень доволен, во всяком случае, я надеюсь, проявит больше энтузиазма, нежели авторы Selenium, чью библиотеку я когда-то портировал.
Как раз это здорово, что понятия символа отделили от понятия байта. То что символ можно сравнивать с односимвольной строкой — это логично, и подобное лексическое сравнение есть везде. А вот второе бред — сравнивать массив байт с байтом. Естественно False. Всё логично, как и всегда в питоне.
Что до уровней абстракции, то они всегда возникают естественным путём. В данном случае строка имеет неизмеримо высший уровень абстракции нежели массив байт. Вы же не задумываетесь о кодировке, когда что-то пишете на бумаге.
Имхо, если запорожец не едет в гору, есть смысл доехать на велосипеде. Толкать в гору запорожец, только потому что он машина и едет быстрее немного нелогично. Так и тут, смысл использовать ORM в задаче, которую он не покрывает.
Если конечно не пугает перспектива разработки на питоне.
В коде шаблона (по сути обычный HTML) встречаются конструкции вида {{ name }} или {% if var > lim %}, ну или {% for x in mass %}.
А уже в коде на сервере вызывается простая функция render_to_response( 'page.html', { name: Some.objects.get( descr='Petya' ) } )
Эта функция при ответе заполнит всё нужными значениями при отправке на клиентскую сторону.
Функционал С++ никогда на этом уровне не был настолько уж жизненно необходим. Что за такая нелюбовь с Си, что прямо так и тянет потратиться там, где дорог каждый байтик.
В общем-то поэтому почти никогда не использую std::list.
Чаще всего требуется std::deque — отличный контейнер, с быстрой индексацией и линейным запросом размера, не кирпич как std::vector, и не цепочная колбаса как std::list.
Python:
C++:
Ещё есть сумма N-мерных векторов, матриц MxN, сумма комплексных чисел. Каждый из этих объектов нуждается в передаче по ссылке, а не по значению. Сохранять куда бы то ни было по значению, значит копировать = потеря по времени для функции, которая претендует на всеобщее употребление, т.е. критична к производительности.
Что до уровней абстракции, то они всегда возникают естественным путём. В данном случае строка имеет неизмеримо высший уровень абстракции нежели массив байт. Вы же не задумываетесь о кодировке, когда что-то пишете на бумаге.