enum Color
{
black = 0,
darkred = {1, "Bloody Mary"},
white = 15 -- Snow white won't get commented
}
Мне кажется языку не хватает встроенной возможности расширения синтаксиса.
А то немного «улучшенную» версию enum'ов пришлось ждать до C++11. И все вкусняшки в языке нужно протаскивать через комитет по стандартизации.
Если бы в языке была бы стандартная возможность расширять синтаксис — хотя бы просто на уровне синтаксического сахара, как в данном примере. То многие улучшения могли быть обкатаны заранее и самые востребованные и «выжившие » в конкурентной борьбе пошли бы в стандарт. По аналогии с расширением стандартной библиотеки за счет переноса каких-то вещей из буста.
Плюс нишевые расширения, а ля Qt moc generator, были бы реализованы без дополнительных зависимостей и пре-генерации (вернее она стала бы стандартным шагом при обработке исходных кодов, наравне с раскрытием макросов, компиляцией и т.п.).
Хотя Страуструп и опасался того, что разные компиляторы C++ вводят дополнительные несовместимые языковые конструкции. Я думаю в этом вопросе нужно было не противостоять этой тенденции, а возглавить её. То есть стандартизировать её и вопрос совместимости сам бы отпал.
Яркий пример того, как не надо писать статьи. Без обид.
На хабре есть заметки и ссылки о том, как писать хорошие статьи.
В школе иногда за сочинение ставят тройку с пометкой — сбился на пересказ произведения.
Здесь та же ситуация — много написано о том, КАК и ЧТО сделано, но мало написано ЗАЧЕМ
Сейчас планирую написать более полезные скриптовые плагины. Один для Jenkins, типа этого QtCreator-Jenkins-Plugin, только на QML. И еще для JIRA какой-нибудь небольшой нотификатор. Пока основная проблема со сборкой под windows.
Было бы круто на js писать правила для автоматического рефакторинга или же умные сниппеты.
Если можно, опишите, как это должно выглядеть и работать. Можно будет попробовать сделать.
/irony Похоже в России accessibility не шибко в моде.
Меня интересует более приземленный вопрос: как поддерживать accessibility в Qt и какими программами это можно проверять под Windows/Linux/MacOS?
Если брать Qt подход, то у них ссылки не сохраняются в принципе, если передается что-то, что можно сохранять, то передается указатель (посмотрите mutexlocker, filestream, например)
Кстати, посмотрел аналог mutexlocker из STL — std::lock_guard. У разработчиков стандарта подход, отличный от разработчиков Qt, и они передают в конструкторе ссылку и запоминают её.
Совершенно согласен.
Вопрос в другом — как сделать SignalSpy, который сможет тестировать слоты, которые передают в параметре объект, не предназначенный для последующего сохранения (по ссылке).
Либо мы говорим, что по ссылке передавать значения в сигналах это плохой тон и закрываем тему: о).
часто ли QObject передается по ссылке? Обычно по указателю.
Вы правы, обычно передают по указателю. При этом, по хорошему, надо проверять, что переданный указатель не нулевой. Ссылка говорит о том, что переданный объект существует.
С некопируемыми объектами оно не будет работать явно
То есть для некоторых случаев пользоваться этим средством SignalSpy нельзя в принципе.
а с битами ссылками оно будет работать непредсказуемо. Первый вариант гораздо лучше.
С битыми ссылками оно будет работать так же, как и с битыми указателями. Проблему битых указателей не решить.
Если человек передаёт указатель, то он вполне может ожидать, что объект, на который указатель указывает, не будет скопирован. А для ссылок это поведение не естественно, этого никто не ожидает. А код должен вести себя предсказуемо, тем более что ваш класс будут использовать с новым, не проверенным кодом. В таком случае ошибки, скорее всего, будут искать совсем не в том месте.
У меня немного другая логика. Если объект нельзя копировать — это выражается в С++ запретом оператора и конструктора копирования и вы не сможете случайно его скопировать. Если объект почти никогда нельзя копировать (например очень тяжелый), но в редких случаях нужно, то делают специальные функции или методы, которые этим занимаются и «случайно» их вызвать нельзя (Clone, Copy). Ссылки в С++ дают чуть больше выразительности, по сравнению с указателями из С.
Думаю нужно просто сделать два варианта SignalSpy — по умолчанию c decay и специальная версия без decay для «клинических» случаев с cсылками.
Мне кажется проблему с ссылками в общем виде не решить.
Либо могут быть битые ссылки, как вы указали, что может быть актуально и при передаче указателей.
Либо, при использовании decay, не будет работать с не-копируемыми объектами (например QObject&).
Не могу пока проверить в деле, но мне кажется будут проблемы, если в параметрах сигналов есть ссылочные типы.
Хранить их в QList<std::tuple<ParamT...> > наверное нельзя.
Честно сказать я не сильно разбирался с системой плагинов для QtCreator, поэтому могу высказывать лишь свои предположения. А вы решите — реальный это вариант или нет.
Ведь мы можем определить интерфейс доступа к QtCreator api (который, к слову сказать, периодически изменяется и его еще нужно поддерживать)
Этот довод касается и всех существующих плагинов — они могут «ломаться» при смене API. Если в API используются QObject derived классы, то протолкнуть их в скриптинг очень просто — зарегистрировать под какими-то именами все синлтоны (хотя я смотрю там используются в основном статические функции а ля Core::ModeManager::addWidget).
а как при этом быть с другими функциями, которые возможно новый плагин захочет использовать?
Опять таки, это проблема скриптинга. Как мне использовать какую-либо полезную функцию в скриптинге? Либо библиотека позволяет зарегистрировать свой API в скриптинге, либо надо это делать за неё посредством proxy библиотеки. Может быть в Qt есть единый подход для регистрации API в скриптинге (например, библиотека должна экспортировать функцию void initScripting(QScriptEngine* engine); )
Я об этом и говорю — много мороки.
а тут бац — текстовые файлы и никаких пересборок. Понравился плагин — скачал 3Kb текстовый файл и пользуйся на здоровье.
Существенное облегчение в распространении плагинов налицо (это как с python, порог вхождение невысок, легко разрабатывать и пользоваться, отсюда куча полезных инструментов и программ на нём).
Спасибо за статью.
С плагинами в QtCreator всё красиво и понятно, кроме одного — распространять плагин хочется в бинарном виде (что бы потребители не заморачивались).
А для этого нужно вытаскивать исходники QtCreator'а, собирать его нужным компилятором и в итоге получается плагин для одной платформы и одного компилятора. И так для всех платформ и компиляторов.
В качестве идеи предлагаю следующее:
Может можно создать для QtCreator'a один плагин, который будет грузить рядом лежащий *.qml или *.js файл и исполнять его в окружении QtCreator'а. Если в QScriptingEngine зарегистрировать точки доступа к QtCreator API, то можно будет разрабатывать плагины на JavaScript и поставлять только текстовые файлы (*.qml или *.js) для любой конфигурации QtCreator'а.
Да, похожие проекты есть. Какие-то бесплатные, какие-то нет. Я постарался упростить работу с properties для программиста.
Что бы можно было просто сгенерировать класс, готовый к использованию, как в GUI, так и в С++ коде. Плюс, так как мои свойства — наследники QObject, получаем почти задаром скриптинг. Например:
Есть тест для скриптинга (см. TestProperty::propertyScripting), нам можно посмотреть примеры (в том числе подключение к слотам).
Есть сохранение в QDataStream, наверное стоит сделать сохранение в JSON.
Надеюсь проект будет полезен. Если есть вопросы по функциональности или нужно более подробно описать, как этим пользоваться или расширять, как говориться: You are welcome!
Сейчас более активно занимаюсь вторым проектом qt-items, по мотивам моей первой статьи. Но если появятся запросы в этом проекте — постараюсь оперативно их решать.
Отсутствие комментариев, как отсутствие вопросов после лекции, говорит о том, что, либо совсем ничего не понятно, либо, наоборот, всё понятно. Надеюсь здесь второй вариант: о)
Мне кажется языку не хватает встроенной возможности расширения синтаксиса.
А то немного «улучшенную» версию enum'ов пришлось ждать до C++11. И все вкусняшки в языке нужно протаскивать через комитет по стандартизации.
Если бы в языке была бы стандартная возможность расширять синтаксис — хотя бы просто на уровне синтаксического сахара, как в данном примере. То многие улучшения могли быть обкатаны заранее и самые востребованные и «выжившие » в конкурентной борьбе пошли бы в стандарт. По аналогии с расширением стандартной библиотеки за счет переноса каких-то вещей из буста.
Плюс нишевые расширения, а ля Qt moc generator, были бы реализованы без дополнительных зависимостей и пре-генерации (вернее она стала бы стандартным шагом при обработке исходных кодов, наравне с раскрытием макросов, компиляцией и т.п.).
Хотя Страуструп и опасался того, что разные компиляторы C++ вводят дополнительные несовместимые языковые конструкции. Я думаю в этом вопросе нужно было не противостоять этой тенденции, а возглавить её. То есть стандартизировать её и вопрос совместимости сам бы отпал.
Plain text с каким-то простеньким синтаксисом будет в самый раз.
На хабре есть заметки и ссылки о том, как писать хорошие статьи.
В школе иногда за сочинение ставят тройку с пометкой — сбился на пересказ произведения.
Здесь та же ситуация — много написано о том, КАК и ЧТО сделано, но мало написано ЗАЧЕМ
Если можно, опишите, как это должно выглядеть и работать. Можно будет попробовать сделать.
Меня интересует более приземленный вопрос: как поддерживать accessibility в Qt и какими программами это можно проверять под Windows/Linux/MacOS?
Только я немного не понял из статьи — почему нам, всё-таки, нужен Reflection?: о)
Кстати, посмотрел аналог mutexlocker из STL — std::lock_guard. У разработчиков стандарта подход, отличный от разработчиков Qt, и они передают в конструкторе ссылку и запоминают её.
Там и с указателями осторожно надо работать. Значит будем работать без ссылок ;o).
Вопрос в другом — как сделать SignalSpy, который сможет тестировать слоты, которые передают в параметре объект, не предназначенный для последующего сохранения (по ссылке).
Либо мы говорим, что по ссылке передавать значения в сигналах это плохой тон и закрываем тему: о).
Вы правы, обычно передают по указателю. При этом, по хорошему, надо проверять, что переданный указатель не нулевой. Ссылка говорит о том, что переданный объект существует.
То есть для некоторых случаев пользоваться этим средством SignalSpy нельзя в принципе.
С битыми ссылками оно будет работать так же, как и с битыми указателями. Проблему битых указателей не решить.
У меня немного другая логика. Если объект нельзя копировать — это выражается в С++ запретом оператора и конструктора копирования и вы не сможете случайно его скопировать. Если объект почти никогда нельзя копировать (например очень тяжелый), но в редких случаях нужно, то делают специальные функции или методы, которые этим занимаются и «случайно» их вызвать нельзя (Clone, Copy). Ссылки в С++ дают чуть больше выразительности, по сравнению с указателями из С.
Думаю нужно просто сделать два варианта SignalSpy — по умолчанию c decay и специальная версия без decay для «клинических» случаев с cсылками.
Либо могут быть битые ссылки, как вы указали, что может быть актуально и при передаче указателей.
Либо, при использовании decay, не будет работать с не-копируемыми объектами (например QObject&).
Думаю первый вариант достаточно безопасный.
Хранить их в QList<std::tuple<ParamT...> > наверное нельзя.
Этот довод касается и всех существующих плагинов — они могут «ломаться» при смене API. Если в API используются QObject derived классы, то протолкнуть их в скриптинг очень просто — зарегистрировать под какими-то именами все синлтоны (хотя я смотрю там используются в основном статические функции а ля Core::ModeManager::addWidget).
Опять таки, это проблема скриптинга. Как мне использовать какую-либо полезную функцию в скриптинге? Либо библиотека позволяет зарегистрировать свой API в скриптинге, либо надо это делать за неё посредством proxy библиотеки. Может быть в Qt есть единый подход для регистрации API в скриптинге (например, библиотека должна экспортировать функцию void initScripting(QScriptEngine* engine); )
а тут бац — текстовые файлы и никаких пересборок. Понравился плагин — скачал 3Kb текстовый файл и пользуйся на здоровье.
Существенное облегчение в распространении плагинов налицо (это как с python, порог вхождение невысок, легко разрабатывать и пользоваться, отсюда куча полезных инструментов и программ на нём).
С плагинами в QtCreator всё красиво и понятно, кроме одного — распространять плагин хочется в бинарном виде (что бы потребители не заморачивались).
А для этого нужно вытаскивать исходники QtCreator'а, собирать его нужным компилятором и в итоге получается плагин для одной платформы и одного компилятора. И так для всех платформ и компиляторов.
В качестве идеи предлагаю следующее:
Может можно создать для QtCreator'a один плагин, который будет грузить рядом лежащий *.qml или *.js файл и исполнять его в окружении QtCreator'а. Если в QScriptingEngine зарегистрировать точки доступа к QtCreator API, то можно будет разрабатывать плагины на JavaScript и поставлять только текстовые файлы (*.qml или *.js) для любой конфигурации QtCreator'а.
Прошу прощения, если сморозил глупость: о)
Ждать встречи в Нижнем Новгороде или нет (19 апреля уже близко)?
Что бы можно было просто сгенерировать класс, готовый к использованию, как в GUI, так и в С++ коде. Плюс, так как мои свойства — наследники QObject, получаем почти задаром скриптинг. Например:
Есть тест для скриптинга (см. TestProperty::propertyScripting), нам можно посмотреть примеры (в том числе подключение к слотам).
Есть сохранение в QDataStream, наверное стоит сделать сохранение в JSON.
Сейчас более активно занимаюсь вторым проектом qt-items, по мотивам моей первой статьи. Но если появятся запросы в этом проекте — постараюсь оперативно их решать.