C және C++ тілдеріндегі inline функциялар

Кіріспе

C және C++ бағдарламалау тілдеріндегі функциялар
C және C++ бағдарламалау тілдеріндегі желілік функциялар

C және C++ бағдарламалау тілдерінде желілік функция – `inline` кілт сөзімен белгіленген функция; ол екі мақсатқа қызмет етеді:
Біріншіден, ол компиляторға функцияның денесін тікелей кодқа ауыстыруды ұсынатын (бірақ міндеттемейтін) директива болып табылады, яғни функцияны шақыру орнына оның кодын енгізу арқылы функция шақыруға кеткен уақытты үнемдейді. Бұл жағынан ол `register` сақтау класы спецификаторына ұқсас, ол да оңтайландыру бойынша кеңес береді. Желілік функцияның екінші мақсаты – байланыс мінез-құлқын өзгерту, бірақ бұл мәселе өте күрделі. Бұл C/C++ тілдеріндегі жеке компиляция және байланыс үлгісіне байланысты қажет, себебі функцияның анықтамасы (коды) оны пайдаланатын барлық модульдерде қайталанған болуы керек. Бұл компиляция кезінде желілік кеңейтуге мүмкіндік береді. Егер функцияның сыртқы байланысы болса, байланыс кезінде қақтығыс туындауы мүмкін (сыртқы символдардың бірегейлігі бұзылады). C және C++ (сондай-ақ GNU C және Visual C++ сияқты түрлері) осы мәселені әртүрлі жолдармен шешеді.

С99

C99 стандартында сызықтық түрде анықталған функция ешқашан, ал сыртқы сызықтық түрде анықталған функция әрқашан сырттан көрінетін функцияны шығарады. C++ стандартынан айырмашылығы, аударма бірліктері арасында бөлісілген сырттан көрінетін функцияны қажет болған жағдайда ғана шығаруға рұқсат жоқ. Егер сызықтық декларациялар сыртқы сызықтық декларациялармен немесе біліктіліксіз декларациялармен (яғни, сызықтық белгішесі немесе сақтау класы жоқ) қосылса, аударма бірлігінде міндетті түрде анықтама болуы керек (біліктіліксіз, сызықтық немесе сыртқы сызықтық) және оған сәйкес сырттан көрінетін функция шығарылады. Сызықтық түрде анықталған функция бағдарламаның басқа бір жерінде сол аттас бір функцияның болуын қажет етеді, ол сыртқы сызықтық түрде немесе біліктіліксіз анықталған болуы керек. Егер бағдарламаның барлық бөлігінде осындай бірнеше анықтама берілсе, байланыстырушы қайталанатын символдар туралы шағымданады. Егер мұндай анықтама болмаса, байланыстырушы міндетті түрде шағымдана бермейді, себебі барлық қолданылулар сызықтық түрде енгізілген болса, ол қажет емес. Бірақ ол шағымдануы мүмкін, өйткені компилятор әрқашан сызықтық белгішені назарға алмауға және функцияға шақыруларды жасауға болады, әсіресе код оптимизацияланбаған кезде. (Бұл қажетті мінез-құлық болуы мүмкін, егер функцияның барлық жерде міндетті түрде сызықтық түрде енгізілуі керек болса және олай болмаса қате туындауы керек.) Ыңғайлы тәсіл – сызықтық функцияларды бас файлдарда анықтау және әр функция үшін бір c файлды құру, онда оның сыртқы сызықтық декларациясы және тиісті бас файлды анықтамасымен қосу. Декларацияның «қосудан» бұрын немесе кейін болуы маңызды емес. Функцияның барлық қолданылулары сызықтық түрде енгізілген жағдайда, соңғы орындалатын файлға қолжетімсіз кодтың қосылуын болдырмау үшін gnu89 сыртқы сызықтық функцияны біліктіліксіз функция ретінде қайта анықтауға рұқсат беретінін ескеру қажет. Ал C99 сызықтық түрде қайта анықтауға рұқсат бермейді. Осылайша, gnu89 extern inline қайта анықталмағанда C99 inline сияқты, ал gnu89 inline болса C99 extern inline сияқты; басқаша айтқанда, gnu89 стандартында сызықтық деп анықталған функция әрқашан және сыртқы сызықтық деп анықталған функция ешқашан сырттан көрінетін функцияны шығара алмайды. Мұның себебі – бұл айнымалыларға ұқсас, олар сыртқы деп анықталғанда ешқашан жадта орын алмайды, ал сыртқы деп анықталмағанда әрқашан жадта орын алады. C99 стандартының себебі керісінше, егер сызықтық түрін пайдалану функцияның сызықтық емес нұсқасын әрқашан шығаруға әкелетін қосымша әсерге ие болса, бұл таңқаларлық болар еді, бұл оның атауынан көрінетін нәрсеге қайшы келеді. Сызықтық функциялар үшін дәл бір сырттан көрінетін функцияның болуын қажет ету және одан туындайтын қолжетімсіз код мәселесі туралы C99 ескертулері gnu89 стандартына да қатысты. gcc компиляторының 4.2 нұсқасына дейін және оның ішінде std=c99 нақты көрсетілген жағдайда да gnu89 сызықтық семантикасын қолданды. 5-ші нұсқада бұл Unix C компиляторларының бастапқыланбаған жаһандық айнымалылардың сыртқы емес анықтамалары үшін дәстүрлі мінез-құлқына сәйкес келеді.

In C99, a function defined inline will never, and a function defined extern inline will always, emit an externally visible function. Unlike in C++, there is no way to ask for an externally visible function shared among translation units to be emitted only if required. If inline declarations are mixed with extern inline declarations or with unqualified declarations (ie., without inline qualifier or storage class), the translation unit must contain a definition (no matter whether unqualified, inline, or extern inline) and an externally visible function will be emitted for it. A function defined inline requires exactly one function with that name somewhere else in the program which is either defined extern inline or without qualifier. If more than one such definition is provided in the whole program, the linker will complain about duplicate symbols. If, however, it is lacking, the linker does not necessarily complain, because, if all uses could be inlined, it is not needed. But it may complain, since the compiler can always ignore the inline qualifier and generate calls to the function instead, as typically happens if the code is compiled without optimization. (This may be the desired behavior, if the function is supposed to be inlined everywhere by all means, and an error should be generated if it is not.) A convenient way is to define the inline functions in header files and create one c file per function, containing an extern inline declaration for it and including the respective header file with the definition. It does not matter whether the declaration is before or after the include. To prevent unreachable code from being added to the final executable if all uses of a function were inlined, it is advised with the exception that gnu89 permits redefinition of an extern inline function as an unqualified function, while C99 inline does not. Thus, gnu89 extern inline without redefinition is like C99 inline, and gnu89 inline is like C99 extern inline; in other words, in gnu89, a function defined inline will always and a function defined extern inline will never emit an externally visible function. The rationale for this is that it matches variables, for which storage will never be reserved if defined as extern and always if defined without. The rationale for C99, in contrast, is that it would be astonishing if using inline would have a side effect—to always emit a non inlined version of the function—that is contrary to what its name suggests. The remarks for C99 about the need to provide exactly one externally visible function instance for inlined functions and about the resulting problem with unreachable code apply mutatis mutandis to gnu89 as well. gcc up to and including version 4.2 used gnu89 inline semantics even when std=c99 was explicitly specified. With version 5, This matches the traditional behavior of Unix C compilers for multiple non extern definitions of uninitialized global variables.