Многие известные мне стандарты кодирования запрещают использовать в директиве включения заголовочного файла шорткаты вида ../ (директория на уровень выше). Я четно говоря ни на одной из платформ на которых я работал (Windows, Linux, MacOS) проблем с использованием этих конструкций не встречал. Если вы сталкивались с проблемами при использовании шорткатов, пожалуйста расскажите.

И еще вопрос. Некоторые стандарты кодирования идут дальше и запрещают использовать конструкцию "foo.h", только <foo.h>. А это уже на мой взгляд рекомендация вредная, так как рискуем при компиляции получить файл не из каталога с проектом, а из истановленной в системе библиотеке. Что вы думаете об этом?

Здравствуйте, Ytz, Вы писали:

Ytz>Многие известные мне стандарты кодирования запрещают использовать в директиве включения заголовочного файла шорткаты вида ../ (директория на уровень выше). Я четно говоря ни на одной из платформ на которых я работал (Windows, Linux, MacOS) проблем с использованием этих конструкций не встречал. Если вы сталкивались с проблемами при использовании шорткатов, пожалуйста расскажите.

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

Ytz>И еще вопрос. Некоторые стандарты кодирования идут дальше и запрещают использовать конструкцию "foo.h", только <foo.h>. А это уже на мой взгляд рекомендация вредная, так как рискуем при компиляции получить файл не из каталога с проектом, а из истановленной в системе библиотеке. Что вы думаете об этом?

Я обычно использую следующее правило: ашники, локальные для данного компонента (скажем, для библиотеки) живут в той же директории, что и сишники и включаются через ковычки. Интерфейсные ашники живут в отдельной директории и включаются через угловые скобки. Чтобы не было конфликта имен, организуйте свою директорию с интерфейсными ашниками таким образом, чтобы включать их можно было так: #include <foo/bar.h> "foo" — название вашей организации или проекта. Если ашников много, можно использовать более одного уровня вложенности (#include <org/proj/foo.h>)

Заметьте, если интерфейсные ашники собраны в отдельную кучку со своей чёткой организацией, то и двоеточие использовать не надо.

Здравствуйте, Ytz, Вы писали:
Ytz>Многие известные мне стандарты кодирования запрещают использовать в директиве включения заголовочного файла шорткаты вида ../ (директория на уровень выше).
Ytz>Некоторые стандарты кодирования идут дальше и запрещают использовать конструкцию "foo.h", только <foo.h>.
Мне кажется, эти требования нацелены на то, чтобы расположение исходников и расположение заголовков были независимы друг от друга. Например, в ядре линукса, емнип, заголовки не перемешаваются с исходниками — а лежат в отдельном дереве папок, и пути к ним в инклюдах прописаны относительно корня этого дерева. Зачем так делается — я хз, наверное, чтобы проще было распространять заголовки отдельно от исходного кода.

Здравствуйте, Pzz, Вы писали:

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

Ну хорошо, вот например есть такая структура исходников:

.
  sources
    device
       abstract_device.h
       concrete_device_1
         concrete_device_1.h
         concrete_device_1.cpp
       concrete_device_2
         concrete_device_2.h
         concrete_device_2.cpp
       device_3
         concrete_device_3.h
         concrete_device_3.cpp

То есть в abstract_device.h обьявлен интерфейс, а в concrete_device_*.* конкретные реализации. Бардак это или нет? И как побороть искушение написать в #include "../abstract_device.h"? Причем abstract_device используется только внутри проекта, и соответственно не должен торчать наружу.

Здравствуйте, Ytz, Вы писали:

Ytz>Ну хорошо, вот например есть такая структура исходников:
1) Переделываем её в

proj
  include
    .....
  sources
    abstract
      a.h
    concrete1
      c1.h
      c1.cpp
    concrete2
      c2.h
      c2.cpp

2) Добавляем sources (или даже proj) в include path
3) Пишем #include <abstract/a.h> или, соответственно, #include <sources/abstract/a.h>

P.S. Это я теоретизирую, а на практике приходится сопровождать такой бардак в каталогах, что хочется выстрелить себе в ногу. И иногда даже удаётся выстрелить

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Ytz, Вы писали:
Ytz>>Многие известные мне стандарты кодирования запрещают использовать в директиве включения заголовочного файла шорткаты вида ../ (директория на уровень выше).
Ytz>>Некоторые стандарты кодирования идут дальше и запрещают использовать конструкцию "foo.h", только <foo.h>.
MC>Мне кажется, эти требования нацелены на то, чтобы расположение исходников и расположение заголовков были независимы друг от друга. Например, в ядре линукса, емнип, заголовки не перемешаваются с исходниками — а лежат в отдельном дереве папок, и пути к ним в инклюдах прописаны относительно корня этого дерева. Зачем так делается — я хз, наверное, чтобы проще было распространять заголовки отдельно от исходного кода.
Обычно из проекта выделяют заголовки, которые входят в SDK, они нужны и проекту и пользователям либы или DLL. Но вот зачем просто отделять заголовки от файлов трансляции — это вопрос.

Здравствуйте, Кодт, Вы писали:

К>2) Добавляем sources (или даже proj) в include path

IMHO include path лучше не использовать для файлов проекта, а только для библиотек.

Здравствуйте, Ytz, Вы писали:

Ytz>Многие известные мне стандарты кодирования запрещают использовать в директиве включения заголовочного файла шорткаты вида

Бред. Стандарт кодирования как таковой -- бред.

Ytz>И еще вопрос. Некоторые стандарты кодирования идут дальше и запрещают использовать конструкцию "foo.h", только <foo.h>.

Архимегабред. Так половина проектов не соберётся.

Ytz> А это уже на мой взгляд рекомендация вредная, так как рискуем при компиляции получить файл не из каталога с проектом, а из истановленной в системе библиотеке. Что вы думаете об этом?

А у меня -I. часто...

Здравствуйте, igna, Вы писали:

К>>2) Добавляем sources (или даже proj) в include path

I>IMHO include path лучше не использовать для файлов проекта, а только для библиотек.

Ну это какие-то комплексы. Чем моя библиотека хуже системной или скачанной из интернета? В большом проекте таких библиотек может быть много. Их даже может иметь смысл распостранять отдельно от исходников в скомпилированном виде с инсталлятором, чтобы необязательно было всем подряд их пересобирать.

Здравствуйте, Pzz, Вы писали:

I>>IMHO include path лучше не использовать для файлов проекта, а только для библиотек.

Pzz>Ну это какие-то комплексы. Чем моя библиотека хуже системной или скачанной из интернета?

Ничем. Я и написал "для библиотек", а ты почему-то прочитал "для системных или скачанных из интернета библиотек".

Здравствуйте, fk0, Вы писали:

fk0>Здравствуйте, Ytz, Вы писали:

Ytz>>Многие известные мне стандарты кодирования запрещают использовать в директиве включения заголовочного файла шорткаты вида

fk0> Бред.

Из общедоступных например стандарт Applied Informatics C++ Coding Style Guide Rule 19 здесь или Google Style Guide здесь

fk0> Стандарт кодирования как таковой -- бред.

Боюсь, что не уловил мысль.