Изпечатай

[4096bits]

Скоро... Па колко да беше скоро?! Една година мисля мина от тогава. Но като се има предвид колко отдавна подхващах С, една година си е нищо пауза....
Та скоро, като се опитвах да си припомня кое, как не искаш и на мен да ми захапе #include чекните.
Щом му задаваш път, сигурно не е от вградените библиотеки
Не зная от коя версия, но ми трябваше много време да разбера, че вече не е
#include <iostream.h>
а
#include <iostrеam>
без .h накрая

Но мисля, че твоя случай не е такъв

[growchie]

Абе най-добре прочетете това http://tldp.org/HOWTO/Program-Library-HOWTO/dl-libraries.html гледам голяма каша е в главите на доста хора. #include е директива за препроцесора, не за линкера. Линкера от инклуди не се интересува, той търси символи във вече генерирания машинен код за да ги навърже.

[gat3way]

Всъщност, в днешно време не е 100% вярно че линкерът не се интересува от инклуди, защото теоретично, в зависимост от това което се инклудва е възможно това да повлияе на процеса на линкване. Става разбира се по доста индиректен начин, но е възможно. Причината е в LTO оптимизациите дето от известно време са доста модерни нещо. Там процесът малко се променя, линкерът вече не е толкова тъп просто да "събира" няколко object файла в някакъв ELF такъв - те на практика дори object файловете вече може да не са същите като преди. Вместо relocatable машинен код, може да има някаква междинна репрезентация между C кода и машинния код, което вече позволява да минават допълнителни link-time оптимизации преди да се "генерира" крайния ELF файл. Така на практика, нещата между компилатор и линкер леко се размиват.

Та пак на въпроса - възможно е include-натите хедъри да повлияят на линкването, особено ако съдържат разни препроцесорни директиви, които влачат функционални "промени". На практика не особено вероятно, но това не означава че е невъзможно.