История изменений
Исправление quiet_readonly, (текущая версия) :
Потому что разработчикам больше важен QML и точат последние годы по большей части именно его.
В QtCreator точат всё одновременно, тем более что архитектура этому способствует: все подсистемы разделены на плагины (сейчас их 30-40), и зависимости между плагинами формируют граф без циклов, так что программист физически не может сделать какую-то фичу без добавления нормального интерфейса в один из ключевых плагинов (например Core, CppTools, ProjectExplorer, AnalyzerBase) или использования существующего интерфейса, и едва ли может поломать другие подсистемы.
Про C++11 ни слова, потому что полная поддержка нового стандарта требует множества доработок существующего парсера C++, даже в том, что относится к c++98. Правда Digia действительно мало внимания уделяет этой задаче (если не считать ревью кода): Erik Verbruggen (ментейнер всех языковых редакторов вообще и C++ в частности) последние полгода часто занят на новом движке для QML, который будет в составе Qt 5.2.
Сейчас доработкой парсера C++ занимаются добровольцы, и помощь им была бы кстати. При этом не обязательно тратить на это много времени, можно проверять патчи от наиболее активного добровольца или собирать дополнительную информацию по багам.
Проверка патчей для парсера C++ обычно включает в себя
- Проверку работоспособности QtCreator с наложенным патчем на проектах, активно использующих boost — потому что раньше уже бывали креши и срабатывание, казалось бы, невозможных ситуаций
- Поиск примеров кода, потенциально способных сломать парсер и не включённых в юнит-тесты для этого патча. Например, один из патчей в первом варианте исправлял подсветку такого кода
Но создавал проблемы на таком
// Some complex template code t<A>.inner.foo;А разница только в операторе доступа: dot, arrow или ::.// Some complex template code t<A>.inner::go();
Исходная версия quiet_readonly, :
Потому что разработчикам больше важен QML и точат последние годы по большей части именно его.
В QtCreator точат всё одновременно, тем более что архитектура этому способствует: все подсистемы разделены на плагины (сейчас их 30-40), и зависимости между плагинами формируют граф без циклов, так что программист физически не может сделать какую-то фичу без добавления нормального интерфейса в один из ключевых плагинов (например Core, CppTools, ProjectExplorer, AnalyzerBase) или использования существующего интерфейса, и едва ли может поломать другие подсистемы.
Про C++11 ни слова, потому что полная поддержка нового стандарта требует множества доработок существующего парсера C++, даже в том, что относится к c++98. Правда Digia действительно мало внимания уделяет этой задаче (если не считать ревью кода): Erik Verbruggen (ментейнер всех языковых редакторов вообще и C++ в частности) последние полгода часто занят на новом движке для QML, который будет в составе Qt 5.2.
Сейчас доработкой парсера C++ занимаются добровольцы, и помощь им была бы кстати. При этом не обязательно тратить на это много времени, можно проверять патчи от наиболее активного добровольца или собирать дополнительную информацию по багам.
Проверка патчей для парсера C++ обычно включает в себя
- Проверку работоспособности QtCreator с наложенным патчем на проектах, активно использующих boost — потому что раньше уже бывали креши и срабатывание, казалось бы, невозможных ситуаций
- Поиск примеров кода, потенциально способных сломать код и не включённых в юнит-тесты для этого патча. Например, один из патчей в первом варианте исправлял подсветку такого кода
Но создавал проблемы на таком
// Some complex template code t<A>.inner.foo;А разница только в операторе доступа: dot, arrow или ::.// Some complex template code t<A>.inner::go();