Dlaczego ludzie dodają własny folder do standardowej ścieżki dołączania?

Question

Patrząc na różnych ciekawych projektach nad na GitHub, natknąłem się na następujący plik:

https://github.com/charliesome/slash/blob/master/src/lib/regexp.c

Wydaje się, jakby był jego własne pliki tak samo jak standardowych nagłówków:

#include <slash/lib/regexp.h> 

Zamiast tego:

#include "slash/lib/regexp.h" 

Myślę, że zmienia ścieżkę dołączania, aby ta możliwość ale moje pytanie brzmi: dlaczego? Czy składnia cudzysłowu nie została stworzona dla takich sytuacji (w tym własnego pliku nagłówkowego)?

Answer 1

Ułatwia zmianę struktury katalogów projektu poprzez zmianę ścieżki dołączania do pliku Makefile. Na przykład, możesz zacząć z wszystkimi nagłówkami w myproj/src, a teraz chcesz mieć dodatkowy folder myproj/include dla wszystkich nagłówków.

Answer 2

W przypadku projektów o umiarkowanym rozmiarze, w szczególności instalowalnych, często wygodniej jest przechowywać nagłówki w oddzielnym katalogu, takim jak include/, w katalogu głównym projektu zamiast w pliku C.

Po dodaniu tego katalogu do ścieżki obejmują, wybór <> lub "" staje się stylistycznym jedno - "" jest konieczne tylko w przypadku ścieżek względnych lub jeśli dodać obejmują katalogów poprzez -iquote zamiast -I, co nie jest szczególnie powszechne.

Argumentem za używanie "" byłoby jawne oznaczenie nagłówków jako specyficznych dla projektu.

Argumentem za używanie <> byłoby to, że włączenie nagłówka będzie wyglądało tak samo w kodzie użytkownika i biblioteki.