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

RO>Я знаю, что MSVC — хороший компилятор, и MSVS — хорошая IDE. Но есть и более другие хорошие компиляторы! Почему все считают, что если вопрос задан в rsdn.cpp, то обязательно используются Microsoft® Windows® и Microsoft® Visual Studio™?

Ну как почему? Потому что по умолчанию предполагается, что перцы, которые круты настолько, что познали все перлести "ещё более лучших, чем MSVC компиляторов" не забывают указать ОС, сред(у/ы) разработки и прочие подробности в своих сообщениях

Давно задаюсь вопросом — есть ли разница?

#include "file.h"
#include <file.h>

в каких случаях пишут <> а в каких ""

Я знаю, что MSVC — хороший компилятор, и MSVS — хорошая IDE. Но есть и более другие хорошие компиляторы! Почему все считают, что если вопрос задан в rsdn.cpp, то обязательно используются Microsoft® Windows® и Microsoft® Visual Studio™?

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

S>Давно задаюсь вопросом — есть ли разница?

Yesti!

S>#include "file.h"
Iskati v tekushey directorii (local location)
S>#include <file.h>
Iskati v sootv. s ustanovkami Visual Studio (global location)

S>в каких случаях пишут <> а в каких ""

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

S>Давно задаюсь вопросом — есть ли разница?

S>#include "file.h"
S>#include <file.h>

S>в каких случаях пишут <> а в каких ""


Если не формально, то <> — файлы стандартных/известных библиотек, "" — свои файлы. Если формально, то:

C99 6.10.2

Source file inclusion

Constraints
A #include directive shall identify a header or source file that can be processed by the
implementation.

Semantics

A preprocessing directive of the form
# include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by
the specified sequence between the < and > delimiters, and causes the replacement of that
directive by the entire contents of the header. How the places are specified or the header
identified is implementation-defined.

A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified
by the specified sequence between the " delimiters. The named source file is searched
for in an implementation-defined manner. If this search is not supported, or if the search
fails, the directive is reprocessed as if it read
# include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original
directive.

A preprocessing directive of the form
# include pp-tokens new-line
(that does not match one of the two previous forms) is permitted. The preprocessing
tokens after include in the directive are processed just as in normal text. (Each
identifier currently defined as a macro name is replaced by its replacement list of
preprocessing tokens.) The directive resulting after all replacements shall match one of
the two previous forms.143) The method by which a sequence of preprocessing tokens
between a < and a > preprocessing token pair or a pair of " characters is combined into a
single header name preprocessing token is implementation-defined.

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

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

S>>Давно задаюсь вопросом — есть ли разница?

S>>#include "file.h"
S>>#include <file.h>

S>>в каких случаях пишут <> а в каких ""


R>Если не формально, то <> — файлы стандартных/известных библиотек, "" — свои файлы. Если формально, то:

R>C99 6.10.2

Стоит отметить, что в стандарте фактически ничего не описано — все папки — Implementation defined. Т.е. нужно обращаться к документации по конкретному компилятору.
Но общепринято, что "" — это папка, где лежит текущая единица трансляции.
А папки для <> задаются в настройках компилятора. Локально для проекта можно определить в свойствах проекта, или глобально для всех проектов можно определить в Tools -> Options -> Projects&Solutions -> VC++Directories -> Show directories for: Include files
Глобальные настройки очень удобно для задания папок для boost, ACE и т.д. Настроить один раз и больше не париться.


R>

спасибо, догадывался что так и есть

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

RO>Я знаю, что MSVC — хороший компилятор, и MSVS — хорошая IDE. Но есть и более другие хорошие компиляторы! Почему все считают, что если вопрос задан в rsdn.cpp, то обязательно используются Microsoft® Windows® и Microsoft® Visual Studio™?

Попробуй просто смириться

R>Стоит отметить, что в стандарте фактически ничего не описано — все папки — Implementation defined. Т.е. нужно обращаться к документации по конкретному компилятору.
R>Но общепринято, что "" — это папка, где лежит текущая единица трансляции.
R>А папки для <> задаются в настройках компилятора. Локально для проекта можно определить в свойствах проекта, или глобально для всех проектов можно определить в Tools -> Options -> Projects&Solutions -> VC++Directories -> Show directories for: Include files
R>Глобальные настройки очень удобно для задания папок для boost, ACE и т.д. Настроить один раз и больше не париться.

А ИМХО неудобно. Лично я очень давно не пользуюсь, по след. причинам:
Во-1, это нужно делать отдельно на каждой машине на которой будет работать девелопер или собираться проект.
Во-2 — поимеем проблем если разные проекты требуют разных версий этих самых ACE-ов и boost-ов.
В-3 — поимеем интересные и трудные для понимания спецэффекты при совпадении имён файлов (а это к сожалению случается часто) в разных библиотеках, подключенных таким образом.

Лично мне кажется что всё же удобнее иметь все библиотеки в системе контроля версий, вместе с самим проектом, и обращаться к ним по относительным ссылкам. А если неохота затаскивать все сорцы third-party библиотеки к себе в репозиторий — тут SVN со свом svn:external рулит.

R>

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

L>А ИМХО неудобно. Лично я очень давно не пользуюсь, по след. причинам:
L>Во-1, это нужно делать отдельно на каждой машине на которой будет работать девелопер или собираться проект.
L>Во-2 — поимеем проблем если разные проекты требуют разных версий этих самых ACE-ов и boost-ов.
L>В-3 — поимеем интересные и трудные для понимания спецэффекты при совпадении имён файлов (а это к сожалению случается часто) в разных библиотеках, подключенных таким образом.

L>Лично мне кажется что всё же удобнее иметь все библиотеки в системе контроля версий, вместе с самим проектом, и обращаться к ним по относительным ссылкам. А если неохота затаскивать все сорцы third-party библиотеки к себе в репозиторий — тут SVN со свом svn:external рулит.

Остаётся только переписать все библиотеки, претендующие на роль стандартных. Тот же буст, например — там все инклуды выглядят как <boost/xxxxx.hpp>
Кстати, boost/ — это некоторая гарантия от совпадения имён файлов.
А что касается разных версий — если какая-то программа несовместима с новыми версиями библиотеки, то в настройках проекта этой программы можно указать путь до конкретной ветки библиотеки (будь то в системе контроля версий или вне её). Никто же не заставляет пихать пути в SET INCLUDE= или в настройки IDE.

Есть и ещё один момент. <> позволяют более гибко обращаться с деревом каталогов.
А относительные пути
— во-первых, громоздче,
— во-вторых, не прощают ошибок, сделанных на стадии проектирования своего рабочего места (пути к каталогам проекта и к каталогам сторонней библиотеки),
— в-третьих, ответвление проекта влечёт за собой ответвление библиотеки. В ряде случаев это оправдано (заморозка кода), а в другом ряде — бессмысленно.

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

Скажем, если я хочу ветвить синхронно

c:\svn\trunk\
    lib\boost-12345\include\boost - здесь живёт буст версии 12345
    products\myproduct\sources - здесь живёт мой проект
        myproduct.dsp ссылается на ..\..\..\lib\boost-12345\include

Смена версии буста — в зависимости от критичности, это или замена содержимого lib\boost-12345, или добавление нового каталога lib\boost-67890 и корректировка .dsp/.dsw-файлов тех проектов, которым это важно.
Оцените масштаб работ, если все #include были относительные.

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

RO>Я знаю, что MSVC — хороший компилятор, и MSVS — хорошая IDE. Но есть и более другие хорошие компиляторы! Почему все считают, что если вопрос задан в rsdn.cpp, то обязательно используются Microsoft® Windows® и Microsoft® Visual Studio™?

Внеси гармонию, расскажи коротенько, как сделать то же самое
— в проектах СиБилдера
— в мейк-файлах
— в других файлах конфигурации проектов
Если, разумеется, там есть кардинальные отличия от того, как это делается в VS.

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

S>в каких случаях пишут <> а в каких ""

разница в большей степени стилистическая,
чтоб различать свои библиотеки от стандартных и библиотек сторонних вендоров.
у нас в стандарте кодирования принято так: "" — заголовки к своим либам которые билдятся как часть проекта/солюшена
<> — заголовки к сторонним либам, которые не являются частью билда или нашего солюшена но используются в нем

К>Остаётся только переписать все библиотеки, претендующие на роль стандартных. Тот же буст, например — там все инклуды выглядят как <boost/xxxxx.hpp>
К>Кстати, boost/ — это некоторая гарантия от совпадения имён файлов.
К>А что касается разных версий — если какая-то программа несовместима с новыми версиями библиотеки, то в настройках проекта этой программы можно указать путь до конкретной ветки библиотеки (будь то в системе контроля версий или вне её). Никто же не заставляет пихать пути в SET INCLUDE= или в настройки IDE.

Э... Налицо недопонимание Я против прописывания именно [b]глобальных[b] установок, но ничуть не призываю прописывать полностью относительные пути в каждом #include. Против include directories, специфичных для проекта, лично я ничего не имею.

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

S>>в каких случаях пишут <> а в каких ""

A>разница в большей степени стилистическая,


Я бы не назвал некомпилируемость стилистической деталью!
Файл 123.h лежит рядом:

#include "123.h" // Ok
#include <123.h> // Cannot open include file: '123.h': No such file or directory

msvc2005

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

К>Внеси гармонию, расскажи коротенько, как сделать то же самое
К>- в проектах СиБилдера
-I/path

К>- в мейк-файлах
-I/path

К>- в других файлах конфигурации проектов
-I/path

К>Если, разумеется, там есть кардинальные отличия от того, как это делается в VS.
-I/path — тру, VS must die ;-)

К>Впрочем, если файлы проектов у IDE имеют жёсткую структуру, и пути к библиотекам там присутствуют в строго определённых местах, то в makefile можно поизгаляться самыми немыслимыми способами. Особенно, когда проект многоэтажный.
…если используется IDE, зачем трогать мэйкфайлы? И наоборот?

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

R>Файл 123.h лежит рядом:
R>

R>#include "123.h" // Ok
R>#include <123.h> // Cannot open include file: '123.h': No such file or directory
R>

Ну добавть точку к каталогам со внешними инклюдами

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

RO>Я знаю, что MSVC — хороший компилятор, и MSVS — хорошая IDE. Но есть и более другие хорошие компиляторы! Почему все считают, что если вопрос задан в rsdn.cpp, то обязательно используются Microsoft® Windows® и Microsoft® Visual Studio™?

А ты угадай с одного раза, на какую торговую марку какой известной фирмы очень похоже название RSDN?

You will always get what you always got
  If you always do  what you always did

Socket пишет:
> Давно задаюсь вопросом — есть ли разница?
> #include "file.h"
> #include <file.h>

Особой нет.
Принято если заголовок системный (стандартного С) — писать <>
Если свой — "". А вот если каких-то нестандартных библиотек —
тут уже сложнее, не понятно, куда ты их отнесешь.

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

S>Давно задаюсь вопросом — есть ли разница?

S>#include "file.h"
S>#include <file.h>

S>в каких случаях пишут <> а в каких ""

в двух словах — реализация выбирает способ А, по которому ищутся и подключаются хедеры, включенные через <>.
Потом она выбирает способ Б, по которому ищутся и подключаются хедеры, включенные через "". Если способ Б обломался и ничего не нашел, то она попробует тот же хедер поискать по способу А.

Так что, вообще говоря, ты можешь все подключать через "" — и все должно работать.
Исключение составляют случаи, когда у тебя есть разные хедеры с одинаковыми именами, и ты хочешь дать приоритет одному из них, причем приоритет состоит в том, что более приоритетный файл находится только по способу А, а менее приоритетный — по способу Б (который включает в себя А). Тогда придется использовать именно угловые скобки.

Во всех остальных случаях смело используй простые кавычки.

В приципе, способы А и Б в разных реализациях могут давать разные эффекты, так что, например, подключение по способу А будет быстрее, чем по способу Б — тогда имеет смысл использовать именно способ А.

Еще важный момент, хоть и теоретический. Хедеры — это не обязательно файлы. Реализация сама определяет, что она называет хедерами.
Например, какого-нибудь хедера <memory> может запросто не существовать в системе в виде файла, а программа все равно будет компилироваться (если, конечно, реализация удовлетворяет стандарту).

You will always get what you always got
  If you always do  what you always did

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

E>Ну как почему? Потому что по умолчанию предполагается, что перцы, которые круты настолько, что познали все перлести "ещё более лучших, чем MSVC компиляторов" не забывают указать ОС, сред(у/ы) разработки и прочие подробности в своих сообщениях

Есть ещё одна категория перцев — которые познали только Билдера или вообще третий Борланд...

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

К>Есть ещё одна категория перцев — которые познали только Билдера или вообще третий Борланд...

1) ИМХО их очень мало (относительно)
2) АФАИК они быстро научаются, что они не мэйнстрим, и в вопросах таки указывают своё стредство разработки