Я когда тестил 2.5.0 — тоже столкнулся с этой проблемой. Бажный релиз.
В 2.4.1 меньше багов парсинга С++, в т.ч. и есть подержка фич С++11 (auto, lambda).
Так что если вы используете креатор не ради какой-то конкретной версии Qt то попробуйте 2.4.1
Ну еще можно попробовать следующие версии (а их уже несколько).
Вполне вероятно уже пофиксили.
2.4.1 бустовский shared_ptr нормально парсит. А С++11 я пока в продакшене не применял.
А какая у вас версия креатора?
Я выше уже писал — в некоторых версиях парсинг ломался.
Да не надо мне рассказывать как это внутри реализуется — я это отлично знаю.
Внутри, в генерируем коде, может быть все что угодно. Например, следуя вашей логике возражений, в джаве в каком то смысле вообще нет никаких типов, классов и методов, а есть интерпретатор и куски бинарных данных которые интерпретируются.
Неявное преобразование типов это вообще-то и есть синтаксический сахар.
То что у джавы оно допускается не везде, не означает что его там нет.
Но на самом деле мое возражение связано с некорректностью утверждения что при сильной типизации недопускаются выражения с разными типами. Оно по сути бессмысленно, что подтвержается моим примером.
Да нет здесь никакой другой ситуации.
Сроки — это часть языка, у них есть тип.
Вы не можете переопределить оператор + для других типов.
Возможность такого сложения для строк предоставляется не библиотекой, а встроенной системой типов джавы во время компиляции, и является ничем иным как неявным преобразованием типов.
В статье речь идет про типы вообще.
int — тип
String — тип
1 + «a» — выражение с различными типами
Какая разница какие там свойства у String если данный пример противоречит приведенному в статье свойству сильной типизации — «не позволяет смешивать в выражениях различные типы»
Сильная типизация выделяется тем, что язык не позволяет смешивать в выражениях различные типы и не выполняет автоматические неявные преобразования, например нельзя вычесть из строки множество.
…
Примеры:
Сильная: Java
Eclipse умеет все, но он тормозит.
QtCreator 2.4.1 (который в репах fc17 и др. дистров) умеет autocomplete для shared_ptr.
В более поздних версиях эта фича периодически ломалась, но я на них не переходил.
В целом между QtCreator с его быстротой (по ощущениям самый быстрый из всех озвученных в посте) но 90% поддержкой С++ и Eclipse с его ужасной скоростью но почти полной поддержкой С++, я выбрал QtCreator.
Ну потому что это же сил нет, такое терпеть в Eclipse, а QtCreator самое важное поддерживает.
Так я ж написал — алгоритму не нужна синхронизация.
Вот поток А пишет в цикле 1,2,3…
А поток Б читает в цикле и куда-то копирует то что удалось прочитать.
При этом алгоритму не требуется гарантировать чтение 3 если другой поток записал 3.
Устраивает любое предыдущее значение.
Переупорядочивание влияет когда от прочитанного значения зависит что делать дальше, а тут просто задача прочитать. Поэтому тут это нерелевантно.
В частности пример с модификацией N — это именно такой алгоритм.
int v;
void set(int a)
{
static_assert(PLALTFORM_HAS_ATOMIC_INT_STORE);
v = a;
}
int get()
{
static_assert(PLALTFORM_HAS_ATOMIC_INT_STORE);
return v;
}
И один поток вызывает set, а второй get без синхронизации (допустим алгоритму не требуется синхронизация, например задача второго потока просто копировать куда-то значние установленное в первом потоке) — то по новому стандарту это UB.
А на практике у нас макрос детектится в configure перед сборкой и программа для левых платформ не соберется, а для остальных платформ она будет абсолютно корректной.
Я понимаю.
Но есть стандарт, а есть стандарт дефакто.
Десятки лет люди писали абсолютно корректные в пределах широкого круга платформ многопоточные программы которые с точки зрения нового стандарта имеют UB.
Если сравнивать этот UB и например UB из второго предложенного в комментах варианта модификации N (с выходом за пределы массива), то второе — это хак и вообще неприемлим при программировании.
А вот чтение из массива целых без синхронизации из других потоков вполне применимо и безопасно для определенного класса алгоритмов.
The execution of a program contains a data race if it contains two conflicting actions in
different threads, at least one of which is not atomic, and neither happens before the
other. Any such data race results in undefined behavior.
Т.е. несинхронизированное И неатомарное чтение/запись в одну переменную из разных потоков — это гонка и UB.
Но на большинстве платформ существует широкий класс типов данных запись/чтение которых атомарно.
Например int, который рассматривается в примере с циклом — с практической точки зрения никаких гонок там не будет.
Хотя признаю, по последнему стандарту формально будет UB — поскольку вполне возможно что существует платформа где запись в int неатомарна, хотя мне такая неизвестна.
В 2.4.1 меньше багов парсинга С++, в т.ч. и есть подержка фич С++11 (auto, lambda).
Так что если вы используете креатор не ради какой-то конкретной версии Qt то попробуйте 2.4.1
Ну еще можно попробовать следующие версии (а их уже несколько).
Вполне вероятно уже пофиксили.
А какая у вас версия креатора?
Я выше уже писал — в некоторых версиях парсинг ломался.
Внутри, в генерируем коде, может быть все что угодно. Например, следуя вашей логике возражений, в джаве в каком то смысле вообще нет никаких типов, классов и методов, а есть интерпретатор и куски бинарных данных которые интерпретируются.
Неявное преобразование типов это вообще-то и есть синтаксический сахар.
То что у джавы оно допускается не везде, не означает что его там нет.
Но на самом деле мое возражение связано с некорректностью утверждения что при сильной типизации недопускаются выражения с разными типами. Оно по сути бессмысленно, что подтвержается моим примером.
Сроки — это часть языка, у них есть тип.
Вы не можете переопределить оператор + для других типов.
Возможность такого сложения для строк предоставляется не библиотекой, а встроенной системой типов джавы во время компиляции, и является ничем иным как неявным преобразованием типов.
int — тип
String — тип
1 + «a» — выражение с различными типами
Какая разница какие там свойства у String если данный пример противоречит приведенному в статье свойству сильной типизации — «не позволяет смешивать в выражениях различные типы»
И что, в джаве так нельзя написать?
Потому что меня не устраивает метрика, в которой данные функции имеют одинаковый вес:
QtCreator 2.4.1 (который в репах fc17 и др. дистров) умеет autocomplete для shared_ptr.
В более поздних версиях эта фича периодически ломалась, но я на них не переходил.
В целом между QtCreator с его быстротой (по ощущениям самый быстрый из всех озвученных в посте) но 90% поддержкой С++ и Eclipse с его ужасной скоростью но почти полной поддержкой С++, я выбрал QtCreator.
Ну потому что это же сил нет, такое терпеть в Eclipse, а QtCreator самое важное поддерживает.
Что данные не точны — то что изначально известно при построении алгоритма?
Вот поток А пишет в цикле 1,2,3…
А поток Б читает в цикле и куда-то копирует то что удалось прочитать.
При этом алгоритму не требуется гарантировать чтение 3 если другой поток записал 3.
Устраивает любое предыдущее значение.
Переупорядочивание влияет когда от прочитанного значения зависит что делать дальше, а тут просто задача прочитать. Поэтому тут это нерелевантно.
В частности пример с модификацией N — это именно такой алгоритм.
И один поток вызывает set, а второй get без синхронизации (допустим алгоритму не требуется синхронизация, например задача второго потока просто копировать куда-то значние установленное в первом потоке) — то по новому стандарту это UB.
А на практике у нас макрос детектится в configure перед сборкой и программа для левых платформ не соберется, а для остальных платформ она будет абсолютно корректной.
Но есть стандарт, а есть стандарт дефакто.
Десятки лет люди писали абсолютно корректные в пределах широкого круга платформ многопоточные программы которые с точки зрения нового стандарта имеют UB.
Если сравнивать этот UB и например UB из второго предложенного в комментах варианта модификации N (с выходом за пределы массива), то второе — это хак и вообще неприемлим при программировании.
А вот чтение из массива целых без синхронизации из других потоков вполне применимо и безопасно для определенного класса алгоритмов.
Т.е. несинхронизированное И неатомарное чтение/запись в одну переменную из разных потоков — это гонка и UB.
Но на большинстве платформ существует широкий класс типов данных запись/чтение которых атомарно.
Например int, который рассматривается в примере с циклом — с практической точки зрения никаких гонок там не будет.
Хотя признаю, по последнему стандарту формально будет UB — поскольку вполне возможно что существует платформа где запись в int неатомарна, хотя мне такая неизвестна.
Да и читаемость не меньше, а больше — именно за счет того что это идиома и ее все знают.
И с чего вы решили что оптимизации нет? Из этой статьи что ли? Ну так в комментах уже опровергли.
Про ошибки тоже спорно.