Вариант: каждый тип — struct (чтобы успокоить себя насчёт производительности) со всеми полями readonly и удобным набором конструкторов. Все методы — чистые (можно для единообразия делать их все extension-методами, пополняя набор методов без вмешательства в определение struct-«ядра» библиотеки; дополнительный плюс такого правила — обязательное именование this параметра в реализации каждого такого extension-метода, как хочет автор этого поста); те из них, которые «мутаторы», возвращают новую («преобразованную») копию struct this-параметра (первого параметра в реализации extension-метода). Бонус: при такой дисциплине цепочечный синтаксис обеспечен для каждого типа «из коробки»: myS = myS.Transform1().Transform2().Transform3();. Лишнее копирование полей this-параметра в локальные переменные не требуется, дисциплина обеспечивает иммьютабельность автоматически. Правила для поддержания этой дисциплины при статической проверке вроде бы должны быть несложными.
В C++ есть идиома с вызовом Swap в конце метода, хорошо сочетается с идиомой pImpl (данные объекта хранятся в отдельном блоке — «реализации», а сам объект — «фасад» — обёртка над смартпойнером на этот блок). Дополнительные бонусы — простая дисциплина потоковой безопасности (надо позаботиться только о безопасности Swap) и сильная безопасность по исключениями (объект никогда не остаётся в некорректном «смешанном» состоянии, если посреди метода происходит исключение, при этом требование noexcept необходимо только для Swap). Эта идиома полуофициально поддерживается в STL (см. реализацию stl::swap для классов библиотеки плюс для POD типов).
При использовании этой идиомы дисциплину можно организовать такую. Объекты-реализации никогда не имеют методов, меняющих состояние, но, зато, имеют достаточно богатые наборы конструкторов. Основное тело метода объекта public API (фасада соответствующего объекта-реализации) состоит в построении новой версии объекта-реализации (при этом копировать поля текущего объекта в локальные переменные, как у автора поста, смысла нет — компилятор в помощь, поскольку pImpl-смартпойнтер фасада указывает на константный объект, да и все методы объекта-реализации помечены const). Эта часть метода завершается вызовом конструктора нового объекта-реализации, с сохранением указателя на него в локальную переменную — такой же смартпойнтер, как pImpl. Заключительный оператор метода — swap (std::swap, для единообразия) этой переменной и единственного поля фасада — pImpl.
Кстати, роль явного this (как у автора поста) здесь играет необходимость обращаться к реализации через единственное поле фасада — pImpl.
Дополнительная стоимость такого подхода, применяемого строго, понятна — но в каких-то применениях она оправдана, а узкие по производительности места можно и подрихтовать, если надо.
Упоминание auto_ptr («в грядущем переиздании») не рулит. Если вы можете повлиять на редактуру, сделайте, пожалуйста, сноску о том, что этот смарпойнтер is getting deprecated (replaced by unique_ptr) — или, ещё лучше, просто молча замените на unique_ptr. Автор одобрит, я уверен.
Приведу пример про ошибки с непарностью new / delete с [] и без: «неопределённое поведение» в стандарте объявлено всегда, а на практике компиляторы (я даже подозреваю, _все_ компиляторы) оптимизируют код для типов без деструкторов так, что разницы нет. Т.е. в данном случае мы имеем ситуацию «неопределённое поведение в реальном мире: всё работает без проблем», не знаю уж, к счастью или к несчастью. Нехорошая ошибка в коде есть. Теоретически (и практически, если удастся найти компилятор, который не делает вышеобозначенную оптимизацию) всё плохо. Всё становится действительно плохо, когда кому-то захочется отмодифицировать код, заменив тип элемента без деструктора на тип с деструктором. В этот момент этот программист и наступит на заботливо разложенные грабли (и, вероятно, разберётся и пофиксает). Но, пока этого не произошло, «все работает ЗАМЕЧАТЕЛЬНО!» :(.
"прочитаю — доложусь" — давай! Я буду тебе напоминать.
"Очень странная разметка у тебя :)" — у них тут какой-то агрессивный markdown. Я всего лишь поставил то ли два, то ли три пробела в начале двух параграфов "попроще: ..." и "посложнее: ..." и, видимо, эти пробелы послужили сигналами, что я цитирую код или что-то такое. Потом, почему английский подхватился жирным, а после // пошло сереньким синтезированным италиком, ну, я не хочу даже разбираться (посты здесь не пишу, нет смысла инвестировать внимание в это).
Спасибо Семён! Я статью из Nature распечатал ещё тогда и просмотрел по диагонали, но не изучил. Ты пишешь очень доходчиво.
По делу — с точки зрения отличия от "настоящего" AI у меня к AlphaGo две претензии / предложения, попроще и посложнее:
попроще: было бы интересно узнать, во сколько раз больше вычислительных ресурсов потребовалось бы, чтобы натренировать сети до такого же отличного уровня игры чисто через игры с самой собой, без обучения на большой базе игр экспертов (ты про этот аспект написал, кстати? вроде не вижу...);
посложнее: параметры системы (картинки-таблицы в твоей статье: топология сетей и параметры MCTS) тоже люди же подбирали, не само выросло... Вот эти дела чтобы самовыводились, это интересная (и гораздо более ресурсоёмкая) задача. Ты читал / слышал про General Game World Championships? http://www.general-game-playing.de/ (почему-то с 2011 года соревнования не проводились... Но сайт обновляется!)
про последний вопрос на тему robo advisory — абсолютно согласен с Дмитрием — на собственном опыте, кстати. Условно говоря, надираловка от конкретной фирмы (в моём случае — Швабс) в красивой обёртке. Подробности письмом.
Капитан Очевидность (TL;DR): матричный вариант всех ест с хрустом на завтрак. Господа, матрицы не причём, вопрос в том, используется возможность человеческого мозга абстрагировть, или нет.
«Это означает, что некоторые проблемы ES5, на которые разработчики жаловались годами так же никуда не денутся.» — странно, этот вопрос можно было бы решить расширением режима strict, типа strict6.
«В ES6 добавили очень нужные JavaScript-разработчикам шутки...» — абсолютно за, без чувства юмора определённого сорта программировать на JavaScript невозможно! Очень хорошо, что юмор теперь стандартизован!
Спасибо, я учту — у меня с Пайтоном знакомство шапочное и не особо позитивное, но, вероятно, мне просто не повезло. Просмотрю образовательные сайты, использующие Пайтон теперь.
Спасибо за информацию — я обязательно посмотрю OberonScript как возможный инструмент для онлайнового обучения, альтернативный таким сайтам с JavaScript и Python. Сейчас вспоминаю, приятель использовал для школьного программистского кружка Pascal-среду, спрошу у него, был это BlackBox или что-то другое.
Здравствуйте, я с Обероном знаком поверхностно (читал первое описание языка — кажется, в конце 80-х, немного следил за новостями, которые довольно редки), но в университетские годы реализовывал в студенческом коллективе Модулу-2 и немного писал прикладной софт на ней. Я предварил данный комментарий этим вступлением в попытке вас заинтересовать до степени получения ответного комментария — убедить в серьёзности моих двух вопросов:
№1: Существуют ли (и, если не существуют, планируются ли кем-либо) для Оберона средства автоматизированного доказательства правильности кода? (для примера — вот недавняя история про планомерное применение такого средства к стандартным функциями Java: habrahabr.ru/post/251751)
№2: Рассматривает ли кто-либо в Оберон-сообществе идею создания «богатой» педагогической направленности системы с Обероном в качестве языка, на котором пишут код ученики? Я недавно поверхностно исследовал тему и обнаружил, что из «взрослых» ЯП (т.е. вычёркивая Scratch и подобные системы «только для детей») наиболее богато в этой роли используются JavaScript (на Khan Academy, прежде всего) и Пайтон (что, на мой взгляд, не так уж сильно отличается от JavaScript). Пояснение насчёт эпитета «богатой» — легкодоступной для детей / непрофессионалов и естественно поддерживающей социализацию учебного / творческого процесса, как и продуктивную самостоятельную работу учеников без людей-менторов / с минимальным вложением сил менторов (эти аспекты обеспечивают успех и ценность сайтов калибра Khan Academy).
Если вы думаете над унификацией по проектам с коллективной разработкой, имеет смысл рассмотреть устоявшийся хорошо документированный фреймворк — про один из таких есть, на мой взгляд, толковая книга автора по имени Miro Samek «Practical UML Statecharts in C/C++, Second Editiion. Event-Driven Programming for Embedded Systems». Собственно, очевидное преимущество описываемого там фреймворка (автор назвал его QP, Quantum leaPs) — сам факт существования книги :) (я первое издание читал в бумажной копии, теперь имею pdf второго издания, прочту, когда реально понадобится).
(заглянул на сайт автора — у него, оказывается, графический инструмент ещё появился для моделирования, ещё один плюс...)
Извините, жду TypeScript 1.0, и его в этом обновлении таки-прибудет:
•Deliver TypeScript 1.0 RC for Visual Studio 2013.
TypeScript is an open-source language that makes it easier to create cross-platform, large-scale JavaScript applications that run on any browser or host. TypeScript offers developers the advantages of strongly-typed languages on top of the flexible, dynamic runtime, and the ubiquity of JavaScript. TypeScript, a typed superset of JavaScript that compiles to plain JavaScript, works seamlessly with existing JavaScript tools and libraries, and easily integrates with existing applications and sites. TypeScript's native types and class-based modular programming model enable scalability and better productivity through early error detection and enhanced tooling, such as Intellisense, code refactoring, and code navigation. For more information about TypeScript, go to the TypeScript website
Интересно. Вы профи в теме (глядя на ваши реплики выше), а я знаком с ней только из любопытства, прочитал несколько статей / презентаций на английском, так что я не чувствую себя достаточно квалифицированным для обсуждения в подробностях. Основной пункт для меня вот в чём: насколько я могу понять беглым поиском, сублинейные алгоритмы с предподготовкой (Contraction Hierarchies) на Хабре не описывались. Да, они имеют недостатки при добавлении специфических (жизненных, разумеется) усложнений вроде динамики весов, ограничений, и не дают выигрыша на произвольных графах. Однако, они весьма хорошо работают на статических материковых картах (так как естественно сложившиеся материковые карты имеют достаточно низкую хайвейную размерность). Да, при добавлении динамики / ограничений в алгоритмы доказанной оптимальностью маршрутов приходится жертвовать, но то, что они резко проиграют после этого A*, это вопрос для меня не очевидный. Про динамику я статьи не читал, но они существуют (я интересовался, чем занимались авторы прочитанных мной статей в последнее время, и видел публикации про динамически усложнения).
Вот, кстати, пример статьи на Хабре: habrahabr.ru/post/180269/ — оригинальное исследование, весьма вероятно на идеях близких к Contraction Hierarchies (вершины графа с большими степенями лежат на хайвейных шорткатах в другой терминологии), но без отсылок к смежным исследованиям (довольно многочисленным и разнообразным: область ведь довольно горячая); меня это несколько опечаливает. А сесть самому в выходные, написать код, погонять, написать обстоятельное изложение и т.п. при том, что это никак не относится к моей текущей работе, я не могу себе позволить, увы (ну и не особо осмысленно «соревноваться» с профессионалами в области или работать популяризатором их результатов на чистом энтузиазме). А вы не собираетесь написать свою заметку? Интересно было бы почитать-обсудить!
При использовании этой идиомы дисциплину можно организовать такую. Объекты-реализации никогда не имеют методов, меняющих состояние, но, зато, имеют достаточно богатые наборы конструкторов. Основное тело метода объекта public API (фасада соответствующего объекта-реализации) состоит в построении новой версии объекта-реализации (при этом копировать поля текущего объекта в локальные переменные, как у автора поста, смысла нет — компилятор в помощь, поскольку pImpl-смартпойнтер фасада указывает на константный объект, да и все методы объекта-реализации помечены const). Эта часть метода завершается вызовом конструктора нового объекта-реализации, с сохранением указателя на него в локальную переменную — такой же смартпойнтер, как pImpl. Заключительный оператор метода — swap (std::swap, для единообразия) этой переменной и единственного поля фасада — pImpl.
Кстати, роль явного this (как у автора поста) здесь играет необходимость обращаться к реализации через единственное поле фасада — pImpl.
Дополнительная стоимость такого подхода, применяемого строго, понятна — но в каких-то применениях она оправдана, а узкие по производительности места можно и подрихтовать, если надо.
"Очень странная разметка у тебя :)" — у них тут какой-то агрессивный markdown. Я всего лишь поставил то ли два, то ли три пробела в начале двух параграфов "попроще: ..." и "посложнее: ..." и, видимо, эти пробелы послужили сигналами, что я цитирую код или что-то такое. Потом, почему английский подхватился жирным, а после // пошло сереньким синтезированным италиком, ну, я не хочу даже разбираться (посты здесь не пишу, нет смысла инвестировать внимание в это).
По делу — с точки зрения отличия от "настоящего" AI у меня к AlphaGo две претензии / предложения, попроще и посложнее:
«В ES6 добавили очень нужные JavaScript-разработчикам шутки...» — абсолютно за, без чувства юмора определённого сорта программировать на JavaScript невозможно! Очень хорошо, что юмор теперь стандартизован!
№1: Существуют ли (и, если не существуют, планируются ли кем-либо) для Оберона средства автоматизированного доказательства правильности кода? (для примера — вот недавняя история про планомерное применение такого средства к стандартным функциями Java: habrahabr.ru/post/251751)
№2: Рассматривает ли кто-либо в Оберон-сообществе идею создания «богатой» педагогической направленности системы с Обероном в качестве языка, на котором пишут код ученики? Я недавно поверхностно исследовал тему и обнаружил, что из «взрослых» ЯП (т.е. вычёркивая Scratch и подобные системы «только для детей») наиболее богато в этой роли используются JavaScript (на Khan Academy, прежде всего) и Пайтон (что, на мой взгляд, не так уж сильно отличается от JavaScript). Пояснение насчёт эпитета «богатой» — легкодоступной для детей / непрофессионалов и естественно поддерживающей социализацию учебного / творческого процесса, как и продуктивную самостоятельную работу учеников без людей-менторов / с минимальным вложением сил менторов (эти аспекты обеспечивают успех и ценность сайтов калибра Khan Academy).
(заглянул на сайт автора — у него, оказывается, графический инструмент ещё появился для моделирования, ещё один плюс...)
•Deliver TypeScript 1.0 RC for Visual Studio 2013.
TypeScript is an open-source language that makes it easier to create cross-platform, large-scale JavaScript applications that run on any browser or host. TypeScript offers developers the advantages of strongly-typed languages on top of the flexible, dynamic runtime, and the ubiquity of JavaScript. TypeScript, a typed superset of JavaScript that compiles to plain JavaScript, works seamlessly with existing JavaScript tools and libraries, and easily integrates with existing applications and sites. TypeScript's native types and class-based modular programming model enable scalability and better productivity through early error detection and enhanced tooling, such as Intellisense, code refactoring, and code navigation. For more information about TypeScript, go to the TypeScript website
.
Вот, кстати, пример статьи на Хабре: habrahabr.ru/post/180269/ — оригинальное исследование, весьма вероятно на идеях близких к Contraction Hierarchies (вершины графа с большими степенями лежат на хайвейных шорткатах в другой терминологии), но без отсылок к смежным исследованиям (довольно многочисленным и разнообразным: область ведь довольно горячая); меня это несколько опечаливает. А сесть самому в выходные, написать код, погонять, написать обстоятельное изложение и т.п. при том, что это никак не относится к моей текущей работе, я не могу себе позволить, увы (ну и не особо осмысленно «соревноваться» с профессионалами в области или работать популяризатором их результатов на чистом энтузиазме). А вы не собираетесь написать свою заметку? Интересно было бы почитать-обсудить!