Visual studio не компилируется проект
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
Будем жить, Маэстро.
Конфигурация компьютера | |
Процессор: Intel Pentium 4 Socket 478 2.26 Ghz/512/533 BOX | |
Материнская плата: ABIT IS7-E2 i865PE+ICH5, S-478 VC 6ch SB Lan ATX 2 DDR 400 | |
Память: PQI DDR 512 Mb, 400 Mhz | |
HDD: SAMSUNG HD103SJ (1000 Гб, SATA) | |
Видеокарта: AGP ATI Radeon X1550 256/128 DDR2 (Palit) | |
Звук: Интегрированный звук | |
Блок питания: ATX Midle Tower CODEGEN 6205-C9 P4, 300W, 27 Ноября 2004 г. | |
CD/DVD: LG DVD-RW, GSA-H30N RBBB (SATA) | |
Монитор: Samsung SyncMaster 223BW(Digital) [NoDB] (HMEQ201792) [21.6" LCD-TFT Монитор] | |
ОС: Windows XP Professional (SP-3) Russian. Special Edition XP | |
Прочее: Borland C++ Builder 6.0 Enterprise Suite и CodeGear C++ Builder 2009 |
Какой тип проекта вы выбираете? По всей видимости вам нужно выбрать консольное приложение. Весь код правильный, попробуйте так.
1>------ Build started: Project: 458456, Configuration: Debug Win32 ------ 1>Build started 26.04.2011 14:59:58. 1>InitializeBuildStatus: 1> Touching "Debug\458456.unsuccessfulbuild". 1>ManifestResourceCompile: 1> All outputs are up-to-date. 1>LINK : error LNK2001: unresolved external symbol _mainCRTStartup 1>c:\users\nikomix\documents\visual studio 2010\Projects\458456\Debug\458456.exe : fatal error LNK1120: 1 unresolved externals 1> 1>Build FAILED. 1> 1>Time Elapsed 00:00:01.25 ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Я выбираю Win32 console application => Галочку на пустой проект и финиш. Потом Файл=> Новый => Файл C++(.ccp)
проверил в VS 2010 с настройками по умолчанию компилируется без ошибок
так что, с настройками что-то не так или установилась не правильно, попробуйте переустановить
Конфигурация компьютера | |
Процессор: AMD Phenom(tm) II X4 955 Processor (3.20 GHz) | |
Память: Kingston 2 GB (2 шт.) [4 GB] | |
HDD: Seagate 7200 rpm [1000 GB] | |
Видеокарта: NVIDIA GeForce GTS 250 | |
Монитор: Samsung SyncMaster [22 д.] | |
ОС: Windows 7 [Максимальная x64], Ubuntu 10.10 | |
Индекс производительности Windows: 6,8 - 7,3 баллов. |
я (только начинаю: ) создала в VS2010 проект для C/C++ Win32 пустой,
прибавила к нему работающие у всех (кроме меня: ) файлы .c
скомпиллировала их (все получилось без ошибок: )
Пробую построить проект (?)
а он пишет:
Ошибка 1 error LNK2019: ссылка на неразрешенный внешний символ _WinMain@16 в функции ___tmainCRTStartup c:\documents and settings\Ширмин\my documents\visual studio 2010\Projects\checkout-stars\checkout-stars\MSVCRTD.lib(crtexew.obj) checkout-stars
Ошибка 2 error LNK1120: 1 неразрешенных внешних элементов c:\documents and settings\ширмин\my documents\visual studio 2010\Projects\checkout-stars\Debug\checkout-stars.exe 1 1 checkout-stars
Что я делаю не так?
Я сижу не на своем компе, может как-то надо настройки VS сбросить?
Visual Studio включает эффективный интегрированный набор средств сборки и отладки проектов. Из этой статьи вы узнаете, как Visual Studio может помочь обнаружить проблемы в коде с помощью построения выходных данных, анализа кода, средств отладки и модульных тестов.
Мы разобрались, как работать с редактором, и написали код. Теперь необходимо убедиться, что код работает должным образом. Отладка в Visual Studio, как и в большинстве интегрированных сред разработки (IDE), осуществляется в два этапа: построение кода для обнаружения и устранения ошибок проекта и компилятора и выполнение кода для обнаружения ошибок времени выполнения и динамических ошибок.
Сборка кода
Существует два основных типа конфигурации сборки: отладка и выпуск. При использовании конфигурации отладка создается более крупный и медленный исполняемый файл, обеспечивающий более широкие интерактивные возможности отладки во время выполнения. Исполняемый файл конфигурации отладка никогда не следует отправлять. Конфигурация выпуск позволяет создать более быстрый оптимизированный исполняемый файл, подходящий для отправки (по крайней мере с точки зрения компилятора). По умолчанию используется конфигурация Отладка.
Самый простой способ выполнить сборку проекта — нажать клавишу F7, однако вы также можете начать сборку, выбрав в главном меню пункты Сборка > Собрать решение.
Процесс сборки можно наблюдать в окне Вывод в нижней части пользовательского интерфейса Visual Studio. Здесь отображаются ошибки, предупреждения и операции сборки. При наличии ошибок (или предупреждений выше заданного уровня) сборка завершится ошибкой. Можно щелкнуть ошибку и предупреждение, чтобы перейти к строке, где они возникли. Для перестроения проекта можно нажать клавишу F7 (чтобы перекомпилировать только файлы с ошибками) или CTRL+ALT+F7 (для чистого полного перестроения).
После успешного выполнения построения вы увидите примерно следующие результаты в окне Вывод:
Просмотр списка ошибок
Если вы внесли какие-либо изменения в код, который был ранее и успешно скомпилирован, возможно, возникнет ошибка. Если вы новичок в написании кода, возможно, их будет много. Ошибки иногда очевидны, например простая синтаксическая ошибка или неправильное имя переменной, а иногда их причину трудно выяснить, имея в распоряжении только зашифрованный код. Чтобы получить более четкое представление о проблеме, перейдите вниз окна Вывод сборки и щелкните вкладку Список ошибок. При этом вы перейдете к более организованному представлению ошибок и предупреждений для проекта и получите доступ к некоторым дополнительным параметрам.
Щелкните строку ошибки в окне Список ошибок, чтобы перейти в строку кода, в которой возникла ошибка. (Кроме того, номера строк можно включить, нажав клавиши Ctrl+Q, введя номера строк, а затем выбрав Включить или отключить отображение номеров строк в результатах. Это самый быстрый способ перехода в диалоговое окно Параметры, где можно включить номера строк.
Нажмите клавиши CTRL+G для быстрого перехода к номеру строки, в которой возникла ошибка.
Ошибку можно узнать по подчеркиванию красной волнистой линией Чтобы получить дополнительные сведения, наведите на нее указатель мыши. Внесите исправления, и подчеркивание исчезнет, хотя в результате исправления может возникнуть новая ошибка (это называется "регрессия").
Пройдите список ошибок и устраните все ошибки в коде.
Просмотр подробных сведений об ошибках
Многие ошибки трудны для восприятия, будучи представленными в терминах компилятора. В этом случае могут потребоваться дополнительные сведения. Из окна Список ошибок можно выполнить автоматический поиск в поисковой системе Bing для получения дополнительных сведений об ошибке или предупреждении. Щелкните правой кнопкой мыши по соответствующей строке записи и выберите Показать справочные сведения об ошибке из контекстного меню или щелкните гиперссылку с кодом ошибки в столбце код в списке ошибок.
В зависимости от настроек результаты поиска по коду и описанию ошибки откроются в веб-браузере либо во вкладке Visual Studio с результатами поиска Bing. Представленные результаты — из различных источников в Интернете, и, возможно, не все они будут полезными.
Анализ кода
Средства анализа выполняют поиск общих проблем в коде, которые могут привести к ошибкам времени выполнения или проблемам управления кодом.
Анализ кода C++
Чтобы выполнить анализ кода C++, запустите статический анализ кода. Запустить этот компонент после устранения всех очевидных ошибок, препятствующих успешной сборке, и потратить некоторое время, чтобы устранить создаваемые им предупреждения, — очень полезная привычка. Вы сможете избавиться от определенных будущих проблем, а также научитесь некоторым полезным приемам написания кода.
Нажмите клавиши ALT+F11 (или выберите в верхнем меню команду Анализ > Выполнить анализ кода в решении) для запуска статического анализа кода.
Все новые или обновленные предупреждения отображаются на вкладке Список ошибок в нижней части интегрированной среды разработки. Щелкните предупреждение для перехода к нему в коде.
Использование быстрых действий для исправления или рефакторинга кода
Если вы привыкли работать с клавиатурой, вы можете использовать клавиши со стрелками и сочетание клавиш CTRL+ . для проверки возможностей оптимизации и очистки кода!
Запуск очистки кода
Помимо форматирования пробелов, отступов и т. п., функция Очистка кода применяет определенные вами соглашения о стиле кода. Ваши настройки для каждого стиля кода считываются из файла EditorConfig, если такой существует в проекте, или из раздела Параметры стиля кода, который доступен через диалоговое окно Параметры.
Отладка выполняемого кода
Успешно завершив сборку кода и его очистку, запустите код, нажав клавишу F5 или выбрав команду Отладка > Начать отладку. Приложение будет запущено в среде отладки, и вы сможете пронаблюдать его поведение. Интегрированная среда разработки Visual Studio изменяется во время выполнения приложения: окно Вывод заменяется двумя новыми окнами (в конфигурации окон по умолчанию): окном с вкладками Видимые/Локальные/Контрольные значения и окном с вкладками Стек вызовов/Точки останова/Параметры исключений/Вывод. Эти окна имеют несколько вкладок, которые позволяют просмотреть и проверить переменные, потоки, стеки вызовов приложения и другие характеристики поведения во время выполнения приложения.
Остановите приложение, нажав клавиши SHIFT+F5 или кнопку Остановить. Кроме того, можно просто закрыть главное окно приложения (или диалоговое окно командной строки).
Задание простых точек останова
Точки останова — это один из самых простых и важных компонентов надежной отладки. Точка останова указывает, где Visual Studio следует приостановить выполнение кода, чтобы вы могли проверить значения переменных или поведение памяти либо выполнение ветви кода. После установки или удаления точек останова перестраивать проект не нужно.
Установите точку останова, щелкнув дальнее поле строки, в которой требуется приостановить выполнение, или нажмите клавишу F9, чтобы установить точку останова в текущей строке кода. Выполнение кода прерывается (останавливается) перед инструкциями для этой строки кода.
Чаще всего точки останова используются для решения следующих задач.
Чтобы точнее определить источник аварийного завершения или отсутствия отклика программы, расставьте точки останова вокруг и непосредственно в коде вызова метода, который, по вашему мнению, приводит к сбою. При выполнении кода в отладчике удаляйте, а затем снова устанавливайте точки останова ближе друг к другу, пока не найдете строку кода, вызывающую ошибку. Выполнение кода в отладчике описывается в следующем разделе.
При добавлении нового кода установите точку останова в его начале и выполните код, чтобы убедиться в том, что он работает правильно.
При реализации сложного поведения задайте точки останова для алгоритмического кода, чтобы можно было проверить значения переменных и данные при прерывании программы.
При написании кода C или C++ используйте точки останова для остановки кода, чтобы можно было проверить значения адреса (ищите значение NULL) и просмотреть значения счетчиков при отладке ошибок, связанных с памятью.
Дополнительные сведения о точках останова см. в статье Использование точек останова.
Проверка кода во время выполнения
Когда выполнение кода приостанавливается из-за достижения точки останова, строка кода, помеченная желтым цветом (текущий оператор), еще не выполнена. Вы можете выполнить текущий оператор и проверить, как изменились значения. Для выполнения кода в отладчике можно использовать ряд команд пошагового выполнения. Если отмеченный код является вызовом метода, вы можете выполнить шаг с заходом, нажав клавишу F11. Кроме того, можно выполнить шаг с обходом строки кода, нажав клавишу F10. Дополнительные команды и подробные сведения о пошаговом выполнении кода см. в статье Навигация по коду с помощью отладчика.
Код, представленный на предыдущей иллюстрации, может выполняться отладчиком по одному оператору. Для этого можно нажимать клавишу F10 или F11 (так как здесь нет вызова метода, результат выполнения обеих команд будет одинаковым).
Когда отладчик приостанавливает выполнение, можно проверить переменные и стеки вызовов, чтобы разобраться в происходящем. Находятся ли значения в тех диапазонах, которые вы ожидали увидеть? Выполняются ли вызовы в правильном порядке?
Наведите курсор на переменную для просмотра ее текущего значения и ссылок. Если отображается значение, которое вы не ожидали увидеть, возможно, в предыдущем или вызывающем коде имеется ошибка. Более подробные сведения об отладке см. в статье об использовании отладчика.
Кроме того, Visual Studio выводит на экран окно средств диагностики, где можно наблюдать за загрузкой ЦП и использованием памяти приложением в динамике по времени. В дальнейшем в процессе разработки приложения эти средства можно применять для выявления случаев непредвиденно высокой загрузки ЦП или чрезмерного выделения памяти. Это окно можно использовать в сочетании с окном Контрольные значения и точками останова, чтобы определить причину непредвиденно интенсивного использования или неосвобожденных ресурсов. Дополнительные сведения см. в статье Обзор возможностей профилирования.
Запуск модульных тестов
Модульные тесты — это первая линия защиты от ошибок в коде, так как при правильном проведении они позволяют проверять отдельные "модули" кода (как правило, это отдельные функции), которые проще отлаживать, чем всю программу. Visual Studio устанавливает платформу модульного тестирования Майкрософт для управляемого и машинного кода. Платформа модульного тестирования используется для создания модульных тестов, их запуска и передачи результатов таких тестов. Завершив внесение изменений, запустите модульные тесты повторно, чтобы убедиться, что код по-прежнему работает правильно. При использовании выпуска Visual Studio Enterprise можно настроить автоматический запуск тестов после каждой сборки.
Чтобы приступить к работе с модульными тестами, ознакомьтесь со статьей Создание модульных тестов для кода с помощью IntelliTest.
Дополнительные сведения о модульных тестах в Visual Studio, а также о том, как они могут помочь в создании более качественного кода, см. в статье Основные сведения о модульных тестах.
В этой статье приведены способы устранения неполадок компилятора Visual C++ или компоновщика Visual C++.
Применимо к: Microsoft Visual C++ 2010 Express, Visual Studio
Исходный номер базы знаний: 974229
Действие
При изучении возможной проблемы с компилятором Microsoft Visual C++ компилятором или компоновщиком важно получить как можно больше сведений о процессе сборки и используемых параметрах. В этой статье рассматриваются некоторые советы по устранению неполадок, которые помогут устранить проблему сборки или получить полную информацию для служба поддержки Майкрософт.
Решение
Для проблем компилятора, таких как внутренние ошибки компилятора (т. е. C1001), зависания или сбои, может быть полезно записать выходные данные препроцессора C/C++, чтобы предоставить упрощенный воспроизводимый пример проблемы. В интегрированной среде разработки Visual C++ для этого можно задать для свойства Generate Preprocessed File значение With Line Numbers (/P) или Without Line Numbers (/EP /P). Это свойство можно найти на страницах свойств проекта в разделе "Свойства конфигурации", "C/C++", "Параметры препроцессора".
Этот параметр можно задать на уровне проекта в меню Project. .i В этом случае он создаст файлы для всех исходных файлов в проекте или для одного файла, щелкнув правой кнопкой мыши файл в обозревателе решений, выбрав контекстное меню свойств, чтобы открыть диалоговое окно свойств для одного файла.
Параметр компилятора /P направляет CL.EXE для записи выходных данных препроцессора в файл. Добавление /EP подавит добавление сведений о номере строки в результирующий файл. /P достаточно, но /EP /P создаст меньший выходной файл. Созданный выходной файл препроцессора будет иметь то же имя, что и исходный скомпилированный файл, но с расширением файла a.i, например file1.cpp, создает выходной файл препроцессора file1.i в том же каталоге.
Компиляция продолжится после этапа препроцессора при использовании этого параметра, .OBJ то есть компилятор не создаст файл, и может появиться ошибка ссылки, отражая тот факт, что obJ-файлы не найдены.
Вы можете скомпилировать выходной файл препроцессора самостоятельно за пределами контекста Visual Studio проекта. Файл .i содержит весь код файла заголовка, .C .CPP замену макросов и предварительно обработанные сведения директив компилятора, необходимые для компиляции этого конкретного или исходного файла. Иными словами, это автономный модуль, который должен иметь возможность воспроизвести проблему компиляции без каких-либо зависимостей от других файлов. Результирующий файл часто будет большим и содержать большой объем пробелов.
Проблемы с компоновщиком
Для проблем компоновщика (ошибок типа LNKxxxx) можно использовать параметр командной строки компоновщика /LINKREPRO, чтобы создать тестовый случай, содержащий только входные данные компоновщика без зависимости от исходных файлов. /LINKREPRO использует следующий синтаксис:
'' — это полный путь к пустой папке в локальной файловой системе. Эта папка уже должна существовать. Компоновщик не создаст ее автоматически и создаст ошибку, если папка не существует.
Этот параметр не предоставляется напрямую в системе проекта. Чтобы добавить его в сборку, откройте меню "Свойства проекта**"** Project меню. В окне "Свойства конфигурации ", "Компоновщик ", /LINKREPRO: "Командная строка" в поле "Дополнительные параметры" введите переключатель (включая косую черту) и замените путь на существующий путь к локальной папке. Пример: /LINKREPRO:C:\TEMP\LINKREPRO\ .
Если в этом поле редактирования уже есть другие параметры компоновщика, разделите их запятыми.
Кроме того, можно использовать переменную LINK_REPRO среды. Если переменная LINK_REPRO среды существует, компоновщик считывает выходной путь из переменной среды и создает linkrepro. Параметр /LINKREPRO не требуется при использовании переменной LINK_REPRO среды. Чтобы использовать переменную LINK_REPRO среды, выполните следующие действия.
Откройте Visual Studio командной строке. Он устанавливается в меню " Пуск" Visual Studio папке под Инструменты Visual Studio папке.
Создайте LINK_REPRO переменную среды, указывав на существующий и пустой каталог, например: SET LINK_REPRO=C:\TEMP\LINKREPRO\
Запустите Visual Studio из той же командной строки, чтобы она совместно использует копию измененной среды.
Откройте проект и выполните перестроение всего проекта.
При LINK.EXE в сборке будет скопироваться все необходимое для связывания проекта с каталогом linkrepro. Среди скопированных файлов будут файлы объектов (. OBJ), необходимые файлы библиотеки (. LIB, включая библиотеки Майкрософт и файл ответа компоновщика (LINK. RSP), чтобы link больше не зависел от файла решения.
Чтобы убедиться, что у вас есть все необходимые файлы для воспроизведения проблемы со ссылкой, можно запустить LINK в каталоге, указанном переменной среды LINK_REPRO, используя файл ответа компоновщика, созданный linkrepro: LINK @link.rsp .
Перед этим используйте следующую команду, чтобы отключить эту функцию при использовании переменной среды командной строки. SET LINK_REPRO=
Этот процесс также можно использовать для проверки файлов, участвующих в создании библиотеки, при использовании LIB.EXE LINK /LIB.
Заявление об отказе от ответственности
Быстрый отказ от публикации
Статьи быстрого публикации предоставляют сведения непосредственно из организации поддержки Майкрософт. Сведения, содержащиеся в этом ниже, создаются в ответ на возникающие или уникальные темы или предназначены для дополнения других сведений базы знаний.
Заявление об отказе от ответственности
Корпорация Майкрософт и(или) ее поставщики не делают никаких представлений или гарантий относительно пригодности, надежности или точности сведений, содержащихся в документах и связанных с ними графиках, опубликованных на этом сайте ("материалы") для любых целей. Эти материалы могут включать технические неточности или опечатки и могут быть пересмотрены в любое время без уведомления.
В максимальной степени, разрешенной применимым законодательством, Корпорация Майкрософт и/или ее поставщики дисклеймировали и исключали все представления, гарантии и условия, будь то экспресс- или подразумеваемые или нормативные, включая представления, гарантии или условия названия, отсутствие нарушения, удовлетворительное состояние или качество, торговая доступность и пригодность для определенной цели, в отношении материалов.
Сразу скажу, что в финале мне удалось добиться сокращения времени компиляции решения с 4:24 минут до менее чем одной минуты. Детали под катом.
На старт!
В начале я собирался собрать отдельную тестовую машину с «чистой» ОС и одной лишь установленной программой — Visual Studio. Но потом решил, что тестировать сферических коней в вакууме будет не совсем верно. На компьютере программиста так или иначе будут установлены какой-нибудь браузер, антивирус, файловый менеджер, архиватор, текстовый редактор и т.д., а значит Студии придется работать со всем этим по близости. Значит, в таком режиме и будем её тестировать, на обычном компьютере разработчика (переустановив, правда, ради чистоты эксперимента, операционную систему и поставив свежие версии используемых в работе программ).
Набор экспериментов составлен по советом с сайтов Stackoverfow, RSDN, форумов MSDN, выдачи Google ну и просто из головы.
Объектом тестирования станет время полной компиляции решения. Перед каждым экспериментом вся папка проекта будет удаляться, код будет заново заливаться из репозитория, а Visual Studio перезагружаться. Каждый эксперимент будет повторяться трижды, результатом будет среднее время. После каждого эксперимента сделанные изменения откатываются.
Если кому-нибудь интересна аппаратная конфигурация моего компьютера, так вот она:
+ жесткий диск WD 500 Гб, 7200 RPM, 16 Мб кэш
+ Win 7 Профессиональная 32 бита со всеми возможными обновлениями
+ Visual Studio 2010 Professional с первым сервис-паком
В Windows включен режим максимальной производительности, отключен Aero и всякие анимации.
Исходное время компиляции моего решения: 4 минуты 24 секунды
Поехали!
Временные файлы — на RamDrive
Есть мнение, что самые медленные операции во время компиляции решения связаны с доступом к диску. Уменьшить это время можно путем использования RamDrive для временных файлов.
Результат: 4 минуты 13 секунд или -4.17% ко времени компиляции.
Вывод: прирост производительности имеется, хоть и небольшой. Если количество ОЗУ позволяет, этот совет можно применять в деле.
Весь проект — на RamDrive
Коль уж нам удалось немного ускорить компиляцию за счет выноса на RamDrive временных файлов, возможно получиться добиться еще лучших результатов, переместив туда всё решение (всё-таки более 4000 файлов).
Результат: 3 минуты 47 секунд или -14.02% ко времени компиляции.
Вывод: По началу этот эксперимент показался мне немного стрёмным — хранить исходники в оперативной памяти не лучший вариант (а вдруг пропадет питание?). Но, учитывая факт наличия бесперебойников, равно как и таких версий RamDrive, как от QSoft (с автоматическим дублированием измененных файлов с RamDrive на жесткий диск) убедили меня, что вариан возможен. Нужно только достаточно ОЗУ (и, по-хорошему, 64-битная ОС).
Весь проект — на флешку
Включение функции ReadyBoost в Windows
Microsoft расхваливает эту функцию именно за повышение производительности при работе с большим количеством относительно небольших блоков данных (наш вариант). Попробуем.
Результат: 4 минуты 17 секунд или -2.65% ко времени компиляции.
Вывод: вполне нормальный способ ускорения работы. Кроме необходимости 1 раз вставить флешку и настроить ReadyBoost других недостатков не имеет, а некоторый прирост производительности даёт.
Изменение количества одновременно компилирующихся проектов
Visual Studio при установке прописывает это число равным общему количеству ядер процессоров в Вашем ПК. Тем не менее, мы можем попробовать его изменить (делается это в настройках VS для С++ проектов) и оценить изменение производительности. Так как в моём компьютере 4-ядерный процессор, изначально это число было равным четырём.
Результат:
6 проектов компилируются одновременно — 4 минуты 34 секунды или +3.79% ко времени компиляции
2 проекта компилируется одновременно — 4 минуты 21 секунда или -1.14% ко времени компиляции
Вывод: я с самого начала ожидал, что увеличение числа одновременно компилирующихся проектов не даст никакого прироста производительности (так и вышло). Но вот почему уменьшение его до двух дало небольшой прирост для меня не очень понятно. Возможно, это просто статистическая погрешность, а может быть при компиляции 4-ех проектов Студия из-за их зависимостей теряет время на каком-то ожидании, что происходит реже при компиляции всего двух проектов. Если у кого-нибудь еще есть мысли по теме — прошу в комментарии.
Отключение вывода текста билда в окно Оutput
Меньше вывода текста при компиляции — быстрее результат.
Результат: 4 минуты 22 секунды или -0.76% ко времени компиляции
Вывод: прирост столь смехотворен, что не стоит даже комментариев. Он может быть как реальным, так и случайным.
Очистка корзины
Я вычитал этот совет на Stackoverflow. Аргументация была в том, что по ходу компиляции создаётся и удаляется масса мелких файлов, а процедура удаления в Windows работает медленнее при забитой корзине. Поскольку все предыдущие эксперименты я и так проводил при пустой корзине, мне пришлось проделать обратный эксперимент — положить в корзину 5000 файлов общим объёмом в 2 Гб.
Результат: 4 минуты 23 секунды или +0.38% ко времени компиляции.
Вывод: время компиляции осталось без изменений. Теория провалилась.
Ключ компилятора /MP
Ключ /MP — это тоже параллельная компиляция, но уже не проектов в решении, а файлов внутри каждого проекта.
Результат: 2 минуты 38 секунд или -40.15% ко времени компиляции
Вывод: это одно из самых существенных достижений среди всех поставленных экспериментов. Конечно, прирост столь высок в основном из-за 4-ядерности моего процессора, но вскоре такие (и еще более-ядерные процессоры) станут нормой в любом компьютере, так что включать опцию имеет смысл. При её включении компилятор честно предупреждает, что она не совместимо с ключом /Gm (Enable Minimal Rebuild), что вначале пугает — возникает мысль, что теперь при любом изменении любого файла будет происходить полная перекомпиляция решения. Так вот — нифига подобного! После изменения одного файла с кодом, как и ранее, будет перекомпилироваться только этот файл, а не всё решение. Всё, что делает ключ — это определяет выбор алгоритма определения взаимосвязей файлов кода и файлов заголовков в проекте (детальнее). Оба алгоритма неплохи и существенный прирост производительности от включения /MP во много раз превосходит недостатки от отключения /Gm.
Удаление папки решения из индекса поиска Windows
Есть мнение, что изменение файлов в папках, которые индексируются механизмом поиска ОС Windows, приводит к увеличению времени компиляции.
Результат: 4 минуты 24 секунды или никакого изменения во времени компиляции
Вывод: то ли индексирование в Windows сделано так хорошо, что вообще не замедляет работу других программ с диском, то ли это влияние минимально, то ли мне просто повезло и компиляция не совпала по времени с индексацией.
Unity Builds
Об этом механизме я рассказывал в прошлой статье.
Результат: 3 минуты 24 секунды или -22.73% ко времени компиляции.
Вывод: сокращение времени компиляции существенно. О всех достоинства и недостатках этой методики я уже писал, использовать его или нет Вы можете решить сами.
Завершение лишних программ
Работающие параллельно со Студией программы кушают память и ресурсы процессора. Их закрытие может положительно сказаться на скорости работы Студии. Итак, я закрываю Skype, QIP, Dropbox, GTalk, DownloadMaster, Mysql server.
Результат: 4 минуты 15 секунд или -3.41% ко времени компиляции
Вывод: во время компиляции придется обойтись без других программ. Никаких анекдотов и порнухи «пока оно там компилится». Вряд ли полный отказ от всех программ возможен для разработчика, но можно создать бат-файлы, включающие\выключащие все лишнее и иногда ими пользоваться.
Отключение антивируса
Если у Вас в системе установлен антивирус, то эта сволочь полезная программа постоянно проверяет все файловые операции. Таким образом, каждый участвующей в компиляции файл будет удостоен внимательного взгляда бдительного стража, что может замедлить время компиляции. Я, честно говоря, не был уверен, как настроить мой антивирус так, чтобы быть уверенным в полном игнорировании им моего проекта и попросту его удалил. Ваш антивирус, возможно, конфигурируется нужным образом.
Результат: 3 минуты 32 секунды или -19.07% ко времени компиляции
Вывод: удивительный результат. Я почему-то был уверен, что все эти *.cpp. *.h, *.obj файлы полностью антивирусом игнорируются и внимания удостоятся только скомпилированные исполняемые программы, что не очень сильно замедлит работу. Однако, факт налицо — почти минута времени экономии.
Дефрагментация жесткого диска
Файловые операции выполняются быстрее на дефрагментированом диске, а компиляция — это огромное количество файловых операций. Я специально оставил этот эксперимент напоследок, поскольку отменить дефрагментацию диска невозможно, а я хотел сделать эксперименты максимально независимыми.
Результат: 4 минуты 8 секунд или -6.06% ко времени компиляции
Вывод: практика согласуется с теорией. Поставьте себе дефрагментацию в планировщик и почаще.
Способы, которые, вероятно, помогли бы, но попробовать не вышло
Переход на 64-битную версию Windows
Есть предположение, что это дало бы некоторый прирост производительности, но портирование нашего проекта под x64, в силу его специфики, имеет не очень высокий приоритет и пока не реализовано. Соответственно, пока что нечего и тестировать.
Обновление процессора, памяти, замена HDD на SSD или RAID
Нужно сказать, что моя тестовая машинка не так уж плоха и до планового апгрейда еще далеко. Работаем с тем, что есть. По отзывам в интернете наибольшее влияние на время компиляции оказывает установка SSD.
Вынесение редко меняющихся проектов в отдельное решение
Это и так уже было сделано. Если в Вашем проекте подобное еще не реализовано — обязательно займитесь.
Xoreax's IncrediBuild или аналог
Распределение компиляции между компьютерами — это уже достаточно кардинальный шаг. Он требует покупки специального ПО, серьёзной настройки и некоторого «выворачивания наизнанку» процесса сборки. Но в очень больших проектах это может стать единственным возможным вариантом. На сайте Xoreax's IncrediBuild есть данные по приросту производительности, рассказы клиентов и куча другого спама разной полезной информации по теме.
Это всё, что я хотел рассказать о способах ускорения компиляции решений в Visual Studio, а в следующей статье я приведу несколько советов по ускорению работы самой IDE.
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
Будем жить, Маэстро.
Конфигурация компьютера | |
Процессор: Intel Pentium 4 Socket 478 2.26 Ghz/512/533 BOX | |
Материнская плата: ABIT IS7-E2 i865PE+ICH5, S-478 VC 6ch SB Lan ATX 2 DDR 400 | |
Память: PQI DDR 512 Mb, 400 Mhz | |
HDD: SAMSUNG HD103SJ (1000 Гб, SATA) | |
Видеокарта: AGP ATI Radeon X1550 256/128 DDR2 (Palit) | |
Звук: Интегрированный звук | |
Блок питания: ATX Midle Tower CODEGEN 6205-C9 P4, 300W, 27 Ноября 2004 г. | |
CD/DVD: LG DVD-RW, GSA-H30N RBBB (SATA) | |
Монитор: Samsung SyncMaster 223BW(Digital) [NoDB] (HMEQ201792) [21.6" LCD-TFT Монитор] | |
ОС: Windows XP Professional (SP-3) Russian. Special Edition XP | |
Прочее: Borland C++ Builder 6.0 Enterprise Suite и CodeGear C++ Builder 2009 |
Какой тип проекта вы выбираете? По всей видимости вам нужно выбрать консольное приложение. Весь код правильный, попробуйте так.
1>------ Build started: Project: 458456, Configuration: Debug Win32 ------ 1>Build started 26.04.2011 14:59:58. 1>InitializeBuildStatus: 1> Touching "Debug\458456.unsuccessfulbuild". 1>ManifestResourceCompile: 1> All outputs are up-to-date. 1>LINK : error LNK2001: unresolved external symbol _mainCRTStartup 1>c:\users\nikomix\documents\visual studio 2010\Projects\458456\Debug\458456.exe : fatal error LNK1120: 1 unresolved externals 1> 1>Build FAILED. 1> 1>Time Elapsed 00:00:01.25 ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Я выбираю Win32 console application => Галочку на пустой проект и финиш. Потом Файл=> Новый => Файл C++(.ccp)
проверил в VS 2010 с настройками по умолчанию компилируется без ошибок
так что, с настройками что-то не так или установилась не правильно, попробуйте переустановить
Конфигурация компьютера | |
Процессор: AMD Phenom(tm) II X4 955 Processor (3.20 GHz) | |
Память: Kingston 2 GB (2 шт.) [4 GB] | |
HDD: Seagate 7200 rpm [1000 GB] | |
Видеокарта: NVIDIA GeForce GTS 250 | |
Монитор: Samsung SyncMaster [22 д.] | |
ОС: Windows 7 [Максимальная x64], Ubuntu 10.10 | |
Индекс производительности Windows: 6,8 - 7,3 баллов. |
я (только начинаю: ) создала в VS2010 проект для C/C++ Win32 пустой,
прибавила к нему работающие у всех (кроме меня: ) файлы .c
скомпиллировала их (все получилось без ошибок: )
Пробую построить проект (?)
а он пишет:
Ошибка 1 error LNK2019: ссылка на неразрешенный внешний символ _WinMain@16 в функции ___tmainCRTStartup c:\documents and settings\Ширмин\my documents\visual studio 2010\Projects\checkout-stars\checkout-stars\MSVCRTD.lib(crtexew.obj) checkout-stars
Ошибка 2 error LNK1120: 1 неразрешенных внешних элементов c:\documents and settings\ширмин\my documents\visual studio 2010\Projects\checkout-stars\Debug\checkout-stars.exe 1 1 checkout-stars
Что я делаю не так?
Я сижу не на своем компе, может как-то надо настройки VS сбросить?
Читайте также: