Eclipse 3.7.0 Indigo с CDT показывает много ложных ошибок компиляции

Question

Я обновил свой Ubuntu box до 11.10, а затем Eclipse также был обновлен до 3.7.0 Indigo с CDT 8.0.1

Тогда возникает следующая проблема:

Я включил векторный заголовочный файл, но компилятор сказал, что Symbol 'vector' could not be resolved. Я также определил #define int Comparable, но Eclipse также сказал Symbol 'Comparable' could not be resolved и так далее ...

Хотя возникает много ошибок, компиляция была успешно завершена!

Я пытался использовать g ++ для компиляции кода, без проблем.

Answer 1

Проблема в том, что существует несколько каталогов включения, которые отсутствуют с точки зрения индексатора.

Добавление следующего сработало для меня, но может зависеть от вашей конкретной настройки, где они на самом деле существуют:

/usr/include/c++/4.6.1
/usr/include/                
/usr/include/c++             
/usr/include/c++/4.6         
/usr/include/x86_64-linux-gnu
/usr/include/asm-generic
/usr/include/c++/4.6.1/x86_64-linux-gnu/

Они могут быть установлены в Project>Properties>C++ Include Paths

Предположительно, в будущем специализация платформы для CDT включит их автоматически. Я помню, что читал это где-то, но не могу предоставить ссылку.

Answer 2

Время от времени сбой Eclipse, виртуальной машины или компьютера или даже долгие месяцы разработки начинают сказываться на стабильности рабочей области, где Eclipse хранит все.

Проверьте каталог <workspace dir>\.metadata, чтобы понять, сколько Eclipse генерирует и хранит в вашей рабочей области. Каждый раз, когда вы добавляете плагин, обновляйте плагин, удаляйте плагин, который помещает и изменяет информацию в вашем рабочем пространстве.

Доказательством является то, что эта проблема обычно возникает сразу после обновления Eclipse. (В моем случае с Индиго).

Самый простой способ исправить запыленное рабочее пространство - использовать аргумент командной строки -clean для исполняемого файла eclipse.exe.

Справочные документы по Eclipse сообщают нам, что делает эта команда:

если установлено значение "true", любые кэшированные данные используются каркасом OSGi и время затмения будет уничтожено. Это очистит используемые кеши хранить разрешение зависимостей в связке и реестр расширений Eclipse данные. Использование этой опции заставит затмение переинициализировать эти кэши.

Существует три способа использования аргумента командной строки -clean:

1. Отредактируйте файл eclipse.ini, расположенный в вашем файле, и добавьте его в качестве первого аргумента в первой строке.
2. Отредактируйте ярлык, который вы используете для запуска Eclipse, и добавьте его в качестве первого аргумента.
3. Создайте пакетный или командный скрипт, который вызывает исполняемый файл Eclipse с аргументом -clean.

Преимущество шага 3 состоит в том, что вы можете держать скрипт и использовать его каждый раз, когда хотите очистить рабочее пространство.

Эта страница решила проблему для меня! Надеюсь, что она может помочь всем остальным.

Answer 3

В свойствах проекта перейдите в C / C ++ Build> Редактор цепочек инструментов, установите флажок Отображать только совместимые наборы инструментов, выберите Linux GCC и нажмите кнопку Применить.

Теперь, если вы перейдете в C \ C ++ General> Paths and Symbols, вы увидите новый список добавленных путей. Если вы перестроите индекс, сообщения об ошибках должны исчезнуть.

Answer 4

Обновленная опция индекса для активной конфигурации сборки работает для меня,

также я удалил некоторые файлы из списка файлов, которые были проиндексированы заранее,

Answer 5

Когда вы создаете проект C ++ (в моем случае из существующего кода), вы должны установить 'Toolchain for Indexer Settings' для используемого вами компилятора ('GNU Autotools Toolchains' в моем случае). После этого «Путь и символы» покажет правильный путь к файлам включения вашего компилятора. Ошибки исчезнут. Этот параметр был полезен только при создании проекта, его настройка позже не помогла.

В версии indigo 3.7.2 (и выше) ваши изменения могут вступать в силу после переиндексации. Затмение попросить «переиндексацию». Более низкие версии могут потребовать переиндексации тегов заголовков вручную и т. Д.

Answer 6

Анализ кода вызывает это.Это на самом деле не компиляция кода, а просто выполнение статических проверок для быстрой обратной связи.К сожалению, я не знаю, как это исправить, я просто отключил это.Извините, я на работе, поэтому у меня нет CDT передо мной, но я думаю, что-то вроде:

Window > Preferences > C++ General > Code Analysis

Перейдите туда и снимите все флажки, чтобы отключить его.

Answer 7

Я отвечаю здесь, потому что это самый близкий вопрос к моей проблеме.

Я использовал интеграцию QT Eclipse с Helios (3.6.2) без особых проблем. Я использовал mingw 4.6.2, который я установил в c: \ mingw. Я хотел перейти на Indigo, чтобы исправить некоторые незначительные проблемы, которые у меня были с CDT.

Однако в Indigo (3.7 SR2) Eclipse начал подчеркивать тривиальные функции, как неразрешенные, такие как:

function 'fprintf' could not be resolved
function 'memset' could not be resolved

, хотя #include не было подчеркнуто, его можно открыть и включить в заголовок fprintf. И хотя сам код скомпилирован нормально.

Если я вернусь в Гелиос, проблемы уйдут.

Я пытался переиндексировать, но безрезультатно. Я проверил мои пути включения, и они были:

c:\mingw\include
C:\MinGW\lib\gcc\mingw32\4.6.2\include

Сначала я только что включил первое, но не второе. Но затем я искал «неразрешенные включения», и stdio.h включал в себя stdarg.h, которого нет в основной папке включения mingw, поэтому я добавил второе. Но все же printf не был разрешен, и больше не было «неразрешенных включений».

Я создал новый проект C ++ с одним классом. Я добавил stdio.h, пути выше и вызов fprintf. Это было подчеркнуто! Хотя другие вещи из stdio не были подчеркнуты.

Теперь я знал, что это не просто проблема Qt.

Я немного поработал над этим, прежде чем прочесть нижний пост, предлагающий удалить пути включения и компиляцию. Я не верил, что это сработает, но попробовал. Удивительно, но даже если компиляция не удалась, ошибка исчезла!

Именно тогда я еще раз взглянул на пути включения. Они были обновлены на этапе компиляции до следующего:

c:/mingw/lib/gcc/mingw32/4.6.2/include-fixed
c:/mingw/include
c:/mingw/lib/gcc/mingw32/4.6.2/include
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/backward
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/mingw32
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++

Они были помечены как «встроенные» значения, которые, как я предполагаю, означают, что они не были добавлены мной и могут быть обновлены при следующем запуске сборки.

Итак, я думаю, что урок, в том числе каждый отдельный путь включения в Mingw, даже если Eclipse не находит его неразрешенным включением.

Следующим шагом было включение всех этих путей в мой проект Qt. К сожалению, после этого нерешенные функции остались. Кажется, это какая-то ошибка с путями включения Qt C / C ++, которые отличаются от путей включения CDT C / C ++.

Answer 8

Хорошо, вот что сработало для меня:

• удалил путь к файлам заголовков, которые я создал из пути включения

• скомпилировалпроект (очевидно, компилятор жалуется, так как в нем отсутствуют определяемые пользователем заголовки)

• повторно вставил путь к файлам заголовков, которые я создал

• скомпилировалпроект снова - отлично работал

Я не могу объяснить случай: (* ​​1021 *