В нашем случае было принято решение отказаться от разделения на Renderable и Updatable, ограничившись одним базовым VisualActivity. Это добавило некоторую избыточность
Это же ужасно. Стоило бы просто отказаться от наследования реализации, заменить её аггрегацией и множественным наследованием «интерфейсов».
Если в метод передается анонимная функция вида SomeMethod(x => OtherMethod(x)), это можно переписать короче: SomeMethod(OtherMethod).
Это можно назвать η-conversion.
Поля, помеченные как const, объявлены в классе, однако используются только компилятором
В частности, это значит, что если некоторая константа была выставлена наружу как const field, то её изменение требует перекомпиляции не только используемой сборки, но и использующей (т.е. ломающее изменение). Предоставление property такого недостатка лишено.
Фактически они различаются только тем, что на методе и содержащем его классе ставится атрибут ExtensionAttribute, который подсказывает компилятору, что данный метод можно использовать как метод-расширение.
Проще говоря, extension-методы — это не фича, это сахар.
… законченные мысли на языке: фразы, предложения или даже несколько предложений… каждая карточка передавала законченную мысль, а десять знакомых слов помогут вплести старое слово в клубок ассоциаций, который и есть, по сути, наша память.
Примеры из учебника по грамматики – тоже хорошие кандидаты на попадание на карточки, но ещё лучше добавлять на карточки предложения с незнакомыми грамматическими конструкциями из других источников...
Подобным подходом занимается т.н. корпусная лингвистика. Один из лучших словарей на эту тему — Collins COBUILD Learner's Dictionary.
Есть такая реальная детская игра, в которой шарики нужно загнать в определенное место проходя лабиринт. Лабиринт наклоняют в разные стороны, шарик при этом катится и нужно попасть в нужные проходы.
Текущая реализация MonoGame для Windows 8 позволяет опрашивать состояние сенсора экрана с помощью класса TouchPanel из области видимости Xna.Framework.Input.Touch.
Если нет требований кроссплатформенности, можно ли использовать стандартные средства для работы с тач-скрином из библиотеки классов .NET for Windows Store?
Но вот идея про то, что в include должны быть публичные хедеры заставляет задуматься.
Более того, иногда случается даже так, что пользователю должны поставляться и некоторые приватные хедеры. Т.е. хедеры, содержащие детали реализации, которые: 1) должны быть доступны из интерфейсных заголовков, 2) не предполагается, что пользователь будет их явно включать. Обычно (Boost, Loki) такие заголовки кладутся в подпапки detail или details.
Но я не люблю *.h и *.cpp файлы держать в перемешку.
Косметически, может, и некрасиво. Но о них стоит думать не как об «h'никах и cpp'шках», а как про «код и интерфейс». В Бусте это нормальная практика.
Вам рассказывать как программировать?
Я имею в виду, как согласовывать их файловые структуры, зависимости по сборке (топологическая сортировка, таймстемпы), etc. Или предполагается, что общего корня сборки у них не будет, они будут изолированы в никак не связанных между собой каталогах? Работа ведь ведётся одновременно и над раннером, и над библиотекой, и над другой библиотекой, от которой зависит первая, etc.
В предложенном шаблоне я вижу один проект. Меня интересует, что будет выполнять роль общего «солюшена» или «воркспейса» при добавлении зависимого проекта.
Который должен уметь почти все что выше описанный проект :)
Да, ок. Правда в этом случае папка include/ избыточна. Она обычно содержит публичные заголовки, которых в демоне нет. В библиотеках приватные (чисто технические, не торчащие наружу) заголовки по возможности лучше прятать в src/ — они выступают только в роли исходников, но не интерфейса.
Любая разработка начинается с чего то. Это один из вариантов с чего я начинаю.
А как этот шаблон продолжать наполнять «мясом», то есть библиотеками, содержащими фактический код, а не инфраструктурную обвязку?
Я согласен со всем что вы написали про библиотеки. Но сравнивать это с тем что делал я это так же, как говорить данный проект идет ортогонально C# идеологии — абсолютно верно, но бессмысленно.
Возможно, ты прав, я неоправданно примерил шаблон на себя. Просто любой код, что я пишу на C++ — это всегда разрабатывается как библиотека (даже если нет пользователей кроме её разработчиков, и API — один класс). Если мне нужен в конечном счёте исполняемый файл, то проект будет в виде библиотека + тонкий runner с точкой входа, не содержащий логики кроме вызова методов библиотеки. В дальнейшем удобно накидывать разные раннеры для разных платформ, или раннеры тестов, демок, etc.
Начну с того что я не предоставляю библиотеку. Это даже близко на нее не похоже и цели такой тоже не было. На этом пожалуй и закончу :)
Если речь не о промышленной разработке, а о накидывании прилаг (демонов) «для себя» или однократных экспериментов в стол, то да, наверное, не стоит заморачиваться с точки зрения использования «проекта NULL» как библиотеки. Но зачем тогда туда тащить версию из, прости господи, Subversion, пять шелл-скриптов и генерацию скриптов сборки CMake'ом?
ИМХО практика писать чистый, поддерживаемый и расширяемый код, весь из себя ООП по канонам банды четырех — сильно переоценивается… только имеет смысл исключительно для больших проектов...
Это ж не о том немного. Если было бы два способа, один из которых правильный и муторный, а второй — рабоче-крестьянский и быстрый, то да, можно обсуждать, какой где применим.
А в случае с файловой иерархией это два равных по начальным трудозатратам подхода. Только один экономнее по последующим трудозатратам, и уже обкатан практикой. И это применимо не только к C++, но и к Си тоже.
И кстати идиотский лейаут это не так страшно.
Ох, не скажи. Мне приходится работать с вышеупомянутой китайской библиотекой. У них два десятка папок, в некоторых по несколько уровней подпапок. И включение в своих заголовках (в том числе глубоко вложенных) производят так, будто они просто есть в include path. Соответственно, в скриптах сборки нужно указать гадзиллион каталогов, да ещё этот набор немножко разный для трёх целевых платформ.
А я хочу один раз в скрипте сборки добавить в include path папку вроде $(Qbit_ExtInclude)chineselib-1.2.3/include/ (там лежит единственная папка chineselib), а везде в коде писать явно #include "chineselib/magicheader.h" вместо просто #include "magicheader.h"
Ок, значит чисто технически никаких проблем нет, и вы это признаете.
Нет, не признаю, я описал эти проблемы. (Можно на «ты», тем более знакомы в жеже же.)
А проблемы, которые появятся при разрастании этой конкретной библиотеки можно решать по мере их поступления
Их лучше не решать, а сразу избегать. И никогда не использовать относительные пути в скриптах сборки, директивах включения, etc.
Внутренние заголовки, тот же version.h например, используются только при сборке либы и наружу не отдаются.
Я специально оговорил это в предыдущем комментарии. Не нравится приватный заголовок version.h, подставляй вместо него в мои комментарии публичный заголовок utils.h. Имя не важно, в примерах я просто считаю version.h публичным заголовком (API), используемым как автором библиотеки, так и пользователем.
Причем эта система сборки совершенно не связана с той системой, которая собирает приложение, например нет «утечки» include-path.
«Утечка» есть. Ещё раз рассмотри пример выше с Module/foo.cpp; все приведённые там рассуждения относятся также и к публичному заголовку Module/foo.h. Как из него подключить «version.h»? Как «version.h», как "../version.h" или как «MyLibrary/version.h»? Я показал, почему первые два способа плохи.
Подавляющему же числу библиотек достаточно примитивной плоской структуры вида libName/libName.h, где дополнительные публичные заголовочные файлы живут в той же папке libName/.
Так я об этом и говорю. Только в include path должна включаться не папка libName/, а её родитель. Чтобы использование было не #include "header.h", а #include "libName/header.h". Но это не только на пользовательской стороне; так же требуется, чтобы этого соглашения придерживался автор библиотеки.
Как бы хорошо ссылаться на буст, но надо понимать, что это нетипичный пример.
Да почти все широко используемые библиотеки используют это соглашение. Я привёл пример четырёх навскидку, но могу перечислить гораздо больше (тупо по списку пройтись).
Между прочим все более-менее серьезные библиотеки собираются и устанавливаются и только потом их используют.
В идеальном мире так и есть. На практике же часто практичнее включить исходники сторонней библиотеки в процесс сборки своей. Но это не важно, на соглашении о файловом дереве для заголовков это не влияет.
Далее бинарники и публичные заголовки либо устанавливаются в регламентированные локации на файловой системе, либо вручную тащатся в папку проекта.
У нас в команде «установка в систему» (не регламентированную локацию, а в ту, куда удобнее разработчикам) происходит только для Boost. Остальные библиотеки тащатся в дерево проекта. Да, в основном в собранном в виде. В исключительных случаях — в виде исходников, и включаются в скрипты сборки. Но, опять же, к обсуждаемой теме это отношения не имеет.
Проект доступен в Google Code, но только для read-only. Это не потому что я жадный, я просто не знаю как открыть доступ для всех.
Если открыть доступ на запись для всех, то кто угодно сможет вносить любые правки, в том числе неосознанно ломать или зловредно вандалить.
При желании вносить правки, пишите ваш g-email, добавлю вас к проекту.
Не стоит добавлять к проекту незнакомых людей. Механизм правок от посторонних лиц в системах управления версиями называется pull request (не знаю поддерживается ли в Google Code).
А в чем проблема конкретно с «version.h», его же никто напрямую не включает.
Конкретно version.h, может, никто и не включает. А какой-то другой файл, скажем, кто-то будет включать; utils.h, например. Имя не важно, дальше я буду продолжать использовать version.h для примера.
При этом сам MySupeLib.h можно включать как #include<foo/bar/MySuperLib.h>, это ничему не противоречит.
И что это за «foo/bar/»? Мне эту директорию самому надо создать, и копировать в него заголовки из папки MySuperLib/include/?
поскольку «путь» разрешается относительно текущего файла а потом уже относительно include path.
Другой вопрос. Появится субмодуль Module/, а в нём файл foo.cpp. Как он должен включать version.h? // Module/foo.cpp
#include "version.h" // 1) Нет разрешения относительно текущего файла, будет поиск в include path, // где равноправны «мой» и «его» экземпляры version.h.
#include "../version.h" // 2) Теперь файл Module/foo.cpp тяжело перемещать по необходимости (например, вглубь), // потому что помимо его перемещения в Module/Subsubmodule/ нужно _исправить его код_, // добавив больше «точек»: #include "../../version.h"
#include "MyLibrary/version.h" // 3) Текущий файл Module/foo.cpp можно спокойно перемещать, потому что // он использует не относительный путь, а отсчитываемый от корня.
На счет С++ namespace, я их специально не использую тут, потому что не знаю какие.
Насчёт C++ namespace я ни слова не упомянул. Я говорил про квалификацию имён файлов префиксами директорий.
Я ни в коем случае не буду использовать название компании в исходных кодах.
Если не название компании, то хотя бы название библиотеки, если гарантирована уникальность её имени. (Название компании просто позволяет избежать проблем, если кто-то другой использует библиотеку с таким же именем, а кто-то третий использует обе библиотеки, скажем, PngUtils, SvgTools, etc.)
Вы наверно пишите на Java или C#, потому что вот именно там я такую штуку видел очень часто.
В том числе и на C#. И эта «частая штука» там неспроста.
Не знаю ни одной широкоизвестной библиотеки, где заголовки включались бы как #include "version.h"
Везде используется паттерн #include "SomeLibrary/version.h" #include "AnotherLibrary/version.h" ...
(А нет, одну знаю, но она написана китайцами.)
Я даже имя проекта в сорсах не использую.
Ну вот у тебя есть заголовок version.h и в своих заголовках ты его подключаешь как version.h, и пользователю твоей библиотеки предполагается подключать его как version.h. А что будет, если у пользователя есть свой файл version.h, а ещё он использует какую-то китайскую поделку, где есть свой version.h? При разворачивании препроцессором директив включения, как он должен понять, какой из version.h где включать?
Я даже имя проекта в сорсах не использую.
Тут мы имеем твоё мнение против мнения авторов Boost, Box2D, SFML, Loki, etc. Все они внутри (и для внешних пользователей это предполагается тоже) включают заголовки отсчитывая от корня с именем проекта.
Мне кажется, что ты свою схему просто не обкатывал на проектах, состоящих из множества модулей, использующих несколько сторонних API и в свою очередь предлагающих себя как API сторонним пользователям.
1) Неправильная иерархия папок для организации заголовочных файлов. Твоя реализация предполагает включение файлов таким образом: #include "program_options.h" #include "version.h"
А должно подразумевать указание «пространства имён» (как в Бусте и везде): #include "MyCompany/MyProject/program_options.h" #include "MyCompany/MyProject/version.h"
2) Такая иерархия файлов плохо масштабируется. Попробуй рассмотреть пример не отдельно взятого проекта в вакууме, а взаимодействие пары пользовательских модулей (например, library и runner), заданных заголовками и исходниками, и пары сторонних библиотек, заданных заголовками и предкомпилированными бинарниками.
Surface Pro — толстый тяжёлый дорогой энергожрущий x86 с вентилятором. Как в принципе его можно противопоставлять Surface?
Почему в обзоре сравнивается WindowsRT с Windows 8, а не WindowsRT с iOS? Что-то я не слышал возгласов — «Ах, iOS недотягивает до MacOS, в топку iPad!»
Это же ужасно. Стоило бы просто отказаться от наследования реализации, заменить её аггрегацией и множественным наследованием «интерфейсов».
На планшете не получается сделать Win+X или ПКМ в углу.
Это можно назвать η-conversion.
В частности, это значит, что если некоторая константа была выставлена наружу как const field, то её изменение требует перекомпиляции не только используемой сборки, но и использующей (т.е. ломающее изменение). Предоставление property такого недостатка лишено.
Проще говоря, extension-методы — это не фича, это сахар.
Подобным подходом занимается т.н. корпусная лингвистика. Один из лучших словарей на эту тему — Collins COBUILD Learner's Dictionary.
… И как раз для этой игры Майкрософт сделали пример:
http://code.msdn.microsoft.com/windowsapps/DirectX-Marble-Maze-Game-e4806345
Если нет требований кроссплатформенности, можно ли использовать стандартные средства для работы с тач-скрином из библиотеки классов .NET for Windows Store?
Jon Skeet пишется без «h», фишка у него такая.
Более того, иногда случается даже так, что пользователю должны поставляться и некоторые приватные хедеры. Т.е. хедеры, содержащие детали реализации, которые: 1) должны быть доступны из интерфейсных заголовков, 2) не предполагается, что пользователь будет их явно включать. Обычно (Boost, Loki) такие заголовки кладутся в подпапки detail или details.
Косметически, может, и некрасиво. Но о них стоит думать не как об «h'никах и cpp'шках», а как про «код и интерфейс». В Бусте это нормальная практика.
Я имею в виду, как согласовывать их файловые структуры, зависимости по сборке (топологическая сортировка, таймстемпы), etc. Или предполагается, что общего корня сборки у них не будет, они будут изолированы в никак не связанных между собой каталогах? Работа ведь ведётся одновременно и над раннером, и над библиотекой, и над другой библиотекой, от которой зависит первая, etc.
В предложенном шаблоне я вижу один проект. Меня интересует, что будет выполнять роль общего «солюшена» или «воркспейса» при добавлении зависимого проекта.
Да, ок. Правда в этом случае папка include/ избыточна. Она обычно содержит публичные заголовки, которых в демоне нет. В библиотеках приватные (чисто технические, не торчащие наружу) заголовки по возможности лучше прятать в src/ — они выступают только в роли исходников, но не интерфейса.
А как этот шаблон продолжать наполнять «мясом», то есть библиотеками, содержащими фактический код, а не инфраструктурную обвязку?
Возможно, ты прав, я неоправданно примерил шаблон на себя. Просто любой код, что я пишу на C++ — это всегда разрабатывается как библиотека (даже если нет пользователей кроме её разработчиков, и API — один класс). Если мне нужен в конечном счёте исполняемый файл, то проект будет в виде библиотека + тонкий runner с точкой входа, не содержащий логики кроме вызова методов библиотеки. В дальнейшем удобно накидывать разные раннеры для разных платформ, или раннеры тестов, демок, etc.
Если речь не о промышленной разработке, а о накидывании прилаг (демонов) «для себя» или однократных экспериментов в стол, то да, наверное, не стоит заморачиваться с точки зрения использования «проекта NULL» как библиотеки. Но зачем тогда туда тащить версию из, прости господи, Subversion, пять шелл-скриптов и генерацию скриптов сборки CMake'ом?
Это ж не о том немного. Если было бы два способа, один из которых правильный и муторный, а второй — рабоче-крестьянский и быстрый, то да, можно обсуждать, какой где применим.
А в случае с файловой иерархией это два равных по начальным трудозатратам подхода. Только один экономнее по последующим трудозатратам, и уже обкатан практикой. И это применимо не только к C++, но и к Си тоже.
Ох, не скажи. Мне приходится работать с вышеупомянутой китайской библиотекой. У них два десятка папок, в некоторых по несколько уровней подпапок. И включение в своих заголовках (в том числе глубоко вложенных) производят так, будто они просто есть в include path. Соответственно, в скриптах сборки нужно указать гадзиллион каталогов, да ещё этот набор немножко разный для трёх целевых платформ.
А я хочу один раз в скрипте сборки добавить в include path папку вроде
$(Qbit_ExtInclude)chineselib-1.2.3/include/(там лежит единственная папка chineselib), а везде в коде писать явно#include "chineselib/magicheader.h"вместо просто#include "magicheader.h"Нет, не признаю, я описал эти проблемы. (Можно на «ты», тем более знакомы в жеже же.)
Их лучше не решать, а сразу избегать. И никогда не использовать относительные пути в скриптах сборки, директивах включения, etc.
Я специально оговорил это в предыдущем комментарии. Не нравится приватный заголовок version.h, подставляй вместо него в мои комментарии публичный заголовок utils.h. Имя не важно, в примерах я просто считаю version.h публичным заголовком (API), используемым как автором библиотеки, так и пользователем.
«Утечка» есть. Ещё раз рассмотри пример выше с Module/foo.cpp; все приведённые там рассуждения относятся также и к публичному заголовку Module/foo.h. Как из него подключить «version.h»? Как «version.h», как "../version.h" или как «MyLibrary/version.h»? Я показал, почему первые два способа плохи.
Так я об этом и говорю. Только в include path должна включаться не папка libName/, а её родитель. Чтобы использование было не
#include "header.h", а#include "libName/header.h". Но это не только на пользовательской стороне; так же требуется, чтобы этого соглашения придерживался автор библиотеки.Да почти все широко используемые библиотеки используют это соглашение. Я привёл пример четырёх навскидку, но могу перечислить гораздо больше (тупо по списку пройтись).
В идеальном мире так и есть. На практике же часто практичнее включить исходники сторонней библиотеки в процесс сборки своей. Но это не важно, на соглашении о файловом дереве для заголовков это не влияет.
У нас в команде «установка в систему» (не регламентированную локацию, а в ту, куда удобнее разработчикам) происходит только для Boost. Остальные библиотеки тащатся в дерево проекта. Да, в основном в собранном в виде. В исключительных случаях — в виде исходников, и включаются в скрипты сборки. Но, опять же, к обсуждаемой теме это отношения не имеет.
Если открыть доступ на запись для всех, то кто угодно сможет вносить любые правки, в том числе неосознанно ломать или зловредно вандалить.
Не стоит добавлять к проекту незнакомых людей. Механизм правок от посторонних лиц в системах управления версиями называется pull request (не знаю поддерживается ли в Google Code).
Конкретно version.h, может, никто и не включает. А какой-то другой файл, скажем, кто-то будет включать; utils.h, например. Имя не важно, дальше я буду продолжать использовать version.h для примера.
И что это за «foo/bar/»? Мне эту директорию самому надо создать, и копировать в него заголовки из папки MySuperLib/include/?
Другой вопрос. Появится субмодуль Module/, а в нём файл foo.cpp. Как он должен включать version.h?
// Module/foo.cpp#include "version.h"// 1) Нет разрешения относительно текущего файла, будет поиск в include path,// где равноправны «мой» и «его» экземпляры version.h.#include "../version.h"// 2) Теперь файл Module/foo.cpp тяжело перемещать по необходимости (например, вглубь),// потому что помимо его перемещения в Module/Subsubmodule/ нужно _исправить его код_,// добавив больше «точек»: #include "../../version.h"#include "MyLibrary/version.h"// 3) Текущий файл Module/foo.cpp можно спокойно перемещать, потому что// он использует не относительный путь, а отсчитываемый от корня.Насчёт C++ namespace я ни слова не упомянул. Я говорил про квалификацию имён файлов префиксами директорий.
Если не название компании, то хотя бы название библиотеки, если гарантирована уникальность её имени. (Название компании просто позволяет избежать проблем, если кто-то другой использует библиотеку с таким же именем, а кто-то третий использует обе библиотеки, скажем, PngUtils, SvgTools, etc.)
В том числе и на C#. И эта «частая штука» там неспроста.
Не знаю ни одной широкоизвестной библиотеки, где заголовки включались бы как
#include "version.h"Везде используется паттерн
#include "SomeLibrary/version.h"#include "AnotherLibrary/version.h"...(А нет, одну знаю, но она написана китайцами.)
Ну вот у тебя есть заголовок version.h и в своих заголовках ты его подключаешь как version.h, и пользователю твоей библиотеки предполагается подключать его как version.h. А что будет, если у пользователя есть свой файл version.h, а ещё он использует какую-то китайскую поделку, где есть свой version.h? При разворачивании препроцессором директив включения, как он должен понять, какой из version.h где включать?
Тут мы имеем твоё мнение против мнения авторов Boost, Box2D, SFML, Loki, etc. Все они внутри (и для внешних пользователей это предполагается тоже) включают заголовки отсчитывая от корня с именем проекта.
Мне кажется, что ты свою схему просто не обкатывал на проектах, состоящих из множества модулей, использующих несколько сторонних API и в свою очередь предлагающих себя как API сторонним пользователям.
#include "program_options.h"#include "version.h"А должно подразумевать указание «пространства имён» (как в Бусте и везде):
#include "MyCompany/MyProject/program_options.h"#include "MyCompany/MyProject/version.h"2) Такая иерархия файлов плохо масштабируется. Попробуй рассмотреть пример не отдельно взятого проекта в вакууме, а взаимодействие пары пользовательских модулей (например, library и runner), заданных заголовками и исходниками, и пары сторонних библиотек, заданных заголовками и предкомпилированными бинарниками.
Почему в обзоре сравнивается WindowsRT с Windows 8, а не WindowsRT с iOS? Что-то я не слышал возгласов — «Ах, iOS недотягивает до MacOS, в топку iPad!»