Каковы плюсы и минусы указания префикса включения в исходном файле по сравнению с параметром пути поиска компилятора? - PullRequest
3 голосов
/ 06 октября 2011

Когда библиотека C или C ++ поставляется с несколькими заголовками, они обычно находятся в определенной папке. Например, OpenCV предоставляет cv.h и highgui.h в папке opencv.

Самый распространенный способ их включения - добавить эту папку opencv в путь поиска прекомпилятора (например, gcc -I/pathto/opencv) и просто включить заголовки по имени файла в исходный файл (например, * 1008). *)

Существует альтернатива, поскольку довольно часто папки с заголовками находятся вместе с другими (например, в /usr/include или в каком-то общем пути для команды разработчиков) в родительской папке. В этом случае достаточно указать папку заголовка в исходном файле (например, #include <opencv/cv.h>), если родительская папка уже находится в пути.

Единственная проблема, с которой я могу столкнуться при использовании этой альтернативы, - это система, в которой все заголовки находятся в одной папке. Однако эта альтернатива предотвращает неоднозначности (например, если две библиотеки имеют заголовок vector.h), упрощает настройку другой системы сборки и, вероятно, более эффективна при поиске файла заголовка прекомпилятором.

Учитывая этот анализ, я бы склонялся к альтернативе, но подавляющее большинство кода, который я нашел в Интернете, используют первое. Например, Google возвращает около 218000 результатов для "#include <cv.h>" против 79100 для "#include <opencv/cv.h>". Я пропускаю преимущества обычного пути или недостатки альтернативы?

Ответы [ 4 ]

4 голосов
/ 06 октября 2011

Они имеют несколько разные цели, и я думаю, что нужно использовать осторожно.

Рассмотрим тот факт, что в случае -I это было /pathto/opencv. Возможно, вы предлагаете #include <opencv/cv.h>, но вы никогда не напишите #include </pathto/opencv/cv.h>. Для этого есть причина: вы ожидаете, что cv.h - это всегда в каталоге с именем opencv, потому что он всегда выпускается, тогда как pathto - это именно то место, где находятся файлы этой библиотеки. был установлен на вашем компьютере (или в вашем дистрибутиве, что угодно).

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

Как вы уже заметили, полезно иметь его в качестве устранения неоднозначности, особенно для файла с двухсимвольным именем, но если вы думаете, что кто-то может захотеть поместить cv.h в другое место, тогда Вы должны оставить это. Это в значительной степени компромисс, который вы делаете - заголовок всегда должен быть в каталоге opencv, но стоит ли вам полагаться на это как на гарантию, как на цену неоднозначности?

4 голосов
/ 06 октября 2011

Мое личное предпочтение - иметь <opencv/cv.h>.

Почему?Потому что я человек с ограниченным умом и гораздо более важными делами, чем помнить, что cv.h происходит из библиотеки opencv.

Поэтому, хотя библиотеки, с которыми я работаю, всегда находятся в выделенномпапки, я структурирую их как:

<specific library folder>/include/<library name>/...

Это помогает мне вспомнить, откуда берутся эти заголовки.

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

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

Это также значительно упрощает организацию списка включений (и групповых включений вместе).

2 голосов
/ 06 октября 2011

Я предполагаю, что основная проблема с использованием #include <opencv/cv.h> заключается в том, что вы не обязательно хотите добавлять полный родительский путь.

Взяв пример, когда он был установлен в /usr/local при использованиис полным путем, вам нужно добавить -I/usr/local/include в вашу командную строку.Это может иметь всевозможные побочные эффекты.

Например, для совершенно другого приложения, возможно, кто-то установил библиотеки GNU iconv там.И вдруг ваше приложение, которое также выполняет #include <iconv.h>, извлекает заголовки из автономной библиотеки iconv вместо реализации в glibc.

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

1 голос
/ 06 октября 2011

Причины первой версии:

  • Вы не всегда можете установить заголовки / библиотеку по стандартному пути.Иногда у вас нет root-доступа.
  • вы не хотите загрязнять путь, добавляя весь путь для всех установленных вами библиотек.
  • например, вы можете иметь 2 версииустановлена ​​та же библиотека (в вашем случае openCV), и вы хотите, чтобы некоторые ваши проекты были скомпилированы с одной библиотекой, а другие - с другой.Если вы поместите их в путь, вы получите столкновение имен.Для меня это одна из главных причин (именно для OpenCv у меня установлены версии 1.x и 2.x, а некоторые проекты скомпилированы с 1.x, а некоторые с 2.x).
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...