फोरट्रान 95 के लिए परियोजना संकलन को गति देने के लिए हैक

सूक्ति

लगभग 15 साल पहले, जब वे अभी भी MSBuild के बारे में नहीं जानते थे, तो ऐसे लोग थे जो फोरट्रान पर बड़े निपटान कार्यक्रमों को लिखना पसंद करते थे, लेकिन धार्मिक कारणों से इसका उपयोग नहीं करते थे ...

प्रशिक्षण स्तर

औसत।

प्रस्तावना

आपका दिन शुभ हो!

"फोरट्रान" शब्द आपकी आत्मा में कई अलग-अलग बदलावों का कारण बन सकता है (ओबेरॉन के साथ भ्रमित नहीं होना)।
यदि आपको लगता है कि उसका समय पहले ही बीत चुका है, तो बस इस लेख को अनदेखा करें।

परिचय

आप सोचते थे कि जब आप लिखेंगे तो क्या होगा

call Foo(); 

?

सही उत्तर - यह सब उस पर निर्भर करता है जहां आप इसे लिखते हैं। यदि बाड़ पर चाक - तो जल्द ही बुरे इरादों वाला एक चौकीदार आपके ऊपर आ जाएगा।

यदि आप फ़ाइल FooProgram.f90 में अपने पसंदीदा टेक्स्ट एडिटर में इसे लिखते हैं, तो यह संभावना है कि इस तरह से आप फ़ोर्टन कंपाइलर को इस बिंदु पर FOO प्रक्रिया को कॉल करने के लिए कह सकते हैं, इसके लिए कोई भी पैरामीटर पारित किए बिना।

 !FooProgram.f90 Program FooProgram call Foo(); end program 

मेरा अनुभव मुझे बताता है कि इस बिंदु पर, इंटेल कंपाइलर _FOO सबरूटीन कॉल कोड सम्मिलित करता है।
यानी इस स्तर पर कोई सत्यापन नहीं होता है। यदि लिंकर ऑब्जेक्ट फ़ाइलों की असेंबली के दौरान _FOO वर्ण पाता है और स्थिर पुस्तकालय (फोरट्रान लोअरकेस और अपरकेस अक्षरों के बीच अंतर नहीं करता है, ताकि वर्ण हमेशा अपरकेस हों। इसके अलावा, फोरट्रान में एक अंडरस्कोर के साथ पहचानकर्ता की पहचान करना शुरू करने के लिए मना किया गया है), यह _FOO, और के लिए लिंक की अनुमति देगा। सब कुछ आपके काम आएगा।
यदि वह नहीं मिला, तो वह लिखेगा:

 1>------ Build started: Project: Console1, Configuration: Debug Win32 ------ 1>Compiling with Intel(R) Visual Fortran 11.1.051 [IA-32]... 1>FooProgram.f90 1>Linking... 1>FooProgram.obj : error LNK2019: unresolved external symbol _FOO referenced in function _MAIN__ 1>Debug\Console1.exe : fatal error LNK1120: 1 unresolved externals 1> 1>Build log written to "file://F:\2011_03_12\CPP_PROJECTS\Console1\Console1\Debug\BuildLog.htm" 1>Console1 - 2 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== 

कैच लगता है?

यह सही है - कोई स्थिर जाँच नहीं होगी। और अगर फू को एक अन्य संकलन इकाई में परिभाषित किया गया है तो Bar.f90 निम्नानुसार है:

 !Bar.f90 Subroutine Foo(bar) Integer, intent(in) :: bar Write(*,*) bar; end subroutine 

?

अनिश्चितता आपका स्वागत करती है, आपकी सौतेली बहन को भेद्यता कहते हैं।

बात यह है कि Bar.f90 के अंदर FOO "बाहरी प्रक्रिया" प्रकार की एक प्रोग्राम यूनिट (प्रोग्राम यूनिट) है।
लेकिन हमें याद है कि फोरट्रान 95 में तीन प्रोग्राम यूनिट हैं:

• मुख्य कार्यक्रम
• मॉड्यूल
• डेटा प्रोग्राम इकाइयों को ब्लॉक करें

यह सबसे दिलचस्प है, ज़ाहिर है, सॉफ्टवेयर इकाई मॉड्यूल।
यह वह है जो संकलन चरण में हमें स्थैतिक सत्यापन प्राप्त करने में मदद करेगा
एक संशोधित कार्यक्रम पर विचार करें:

 !FooProgram2.f90 Program FooProgram use BarModule; call Foo(); end program !Bar.f90 module BarModule contains Subroutine Foo(bar) Integer, intent(in) :: bar Write(*,*) bar; end subroutine end module 

जब आप असेंबली शुरू करते हैं, तो कैरिंग कंपाइलर आपको बताएगा कि मापदंडों के बिना आपको FOO को कॉल नहीं करना चाहिए:

 1>------ Build started: Project: Console1, Configuration: Debug Win32 ------ 1>Compiling with Intel(R) Visual Fortran 11.1.051 [IA-32]... 1>Bar.f90 1>FooProgram.f90 1>F:\2011_03_12\CPP_PROJECTS\Console1\Console1\FooProgram.f90(4): error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface. [BAR] 1>compilation aborted for F:\2011_03_12\CPP_PROJECTS\Console1\Console1\FooProgram.f90 (code 1) 1> 1>Build log written to "file://F:\2011_03_12\CPP_PROJECTS\Console1\Console1\Debug\BuildLog.htm" 1>Console1 - 2 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== 

कंपाइलर को कैसे पता चला कि मुख्य कार्यक्रम के प्रोग्राम यूनिट में FOO कॉल कार्यान्वयन से मेल नहीं खाता है? भाग में, उन्होंने स्वयं आपको उत्तर दिया: उन्होंने FOO को एक स्पष्ट इंटरफ़ेस के साथ एक प्रक्रिया पर विचार करना शुरू किया, जिसे हमने विश्वासघात से तोड़ने की कोशिश की।

यहाँ मैं धोखा देगा और अस्थायी रूप से संकलन प्रक्रिया पर दृश्य को एक घोषणा के रूप में बदल देगा।

दो प्रक्रियाओं पर विचार करें:
पहला: प्रोग्राम यूनिट के संकलन के परिणामस्वरूप एक विनिर्देशन मॉड्यूल जिसमें इस तरह के तत्व शामिल हैं:

• डेटा ऑब्जेक्ट
• मापदंडों
• संरचनाओं
• प्रक्रियाओं
• ऑपरेटरों

इस जानकारी को फोरमैन कंपाइलर ने बरमोडुलेमोड फ़ाइल (हेडल फाइल्स और सीएलआर के लिए हैलो) में रखा है।

दूसरा: मॉड्यूल विनिर्देशन को किसी अन्य सॉफ़्टवेयर इकाई में आयात करना।
रेखा संकलन के दौरान यही होता है

 use BarModule; 

यह मानते हुए कि पहली प्रक्रिया को संक्षेप में प्रक्रिया दो से पहले कहा जाता है, यह हमारे लिए स्पष्ट हो जाता है कि संकलक हमारी त्रुटि के बारे में हमें कैसे बता पा रहा था।
वास्तव में, अब FOO () एक स्पष्ट है, और पहले की तरह अंतर्निहित नहीं है, FOO प्रक्रिया का कॉल है। संकलक जाँच करने में सक्षम है।

सब ठीक लगने लगा है। सभी लोग खुश हैं।

हम अपने आवेदन के निर्माण, मॉड्यूल द्वारा मॉड्यूल लिखना शुरू करते हैं। और संकलनकर्ता हमें संकलन चरण पर मूर्खतापूर्ण कोडिंग त्रुटियों को पकड़ने में मदद करता है।

हमारे पास FOO_BAZmodule मॉड्यूल और FOO_BAZ प्रक्रिया है।
यानी रिएक्टर कूलिंग लूप में कूलेंट की गतिशीलता की गणना के लिए हमारी "भारी परियोजना" अब इस तरह दिखती है:

 !FooProgram.f90 Program FooProgram use BarModule; call Foo(1); end program !Bar.f90 module BarModule contains Subroutine Foo(bar) use FOO_BAZModule Integer, intent(in) :: bar Write(*,*) bar; call Foo_BAZ(); end subroutine end module !Foo_Baz.f90 module FOO_BAZModule contains subroutine FOO_BAZ() write(*,*) "FOO_BAZ" endsubroutine end module 

ऐसा लगता है कि निर्भरता की श्रृंखला FooProgram <- Foo <- Foo_BAZ को दो में तोड़ा जा सकता है:
FooProgram <- Foo और Foo <- Foo_BAZ।
हालांकि, कंपाइलर सर्वशक्तिमान नहीं है। और Foo_Baz के कार्यान्वयन में किसी भी बदलाव के साथ, आप देखेंगे कि बिल्ड लॉग इस तरह दिखता है:

 1>------ Build started: Project: Console1, Configuration: Debug Win32 ------ 1>Compiling with Intel(R) Visual Fortran 11.1.051 [IA-32]... 1>FOO_BAZ.f90 1>Bar.f90 1>FooProgram.f90 1>Linking... 1>Embedding manifest... 1> 1>Build log written to "file://F:\2011_03_12\CPP_PROJECTS\Console1\Console1\Debug\BuildLog.htm" 1>Console1 - 0 error(s), 0 warning(s) ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== 

Bar.f90 और FooProgram.f90 को पुनर्बीमा के लिए पुन: स्थापित किया गया था, एक प्राथमिकता।

मेरा विश्वास करो, यह असहनीय है जब आवेदन के आधे हिस्से को इस तथ्य के कारण फिर से बनाया जाता है कि आपने स्ट्रिंग में एक अतिरिक्त स्थान जोड़ा था ...

लेकिन क्या होगा यदि निर्माण प्रणाली (मेरे उदाहरण में, इंटेल विज़ुअल फोरट्रान पर आधारित) इस तरह से मेरे स्पष्ट कार्यों के साथ काम करती है?

वास्तव में हैक

जैसा कि आप देख सकते हैं, FOO_BAZ के लिए इंटरफेस अंतर्निहित रूप से उत्पन्न हुए थे, क्योंकि हमने केवल इन प्रक्रियाओं के साथ संकलक प्रदान किया है। खैर - निहितार्थ हमें फिर से रोकता है ...
हम इसे FOO_BAZ प्रक्रिया के लिए इंटरफ़ेस के स्पष्ट विवरण का उपयोग करके हटा देते हैं:

 interface subroutine FOO_BAZ() endsubroutine endinterface 

इस इंटरफ़ेस को मॉड्यूल FOO_BAZModule में रखें

 !Foo_baz.f90 module FOO_BAZModule interface subroutine FOO_BAZ() endsubroutine endinterface contains subroutine FOO_BAZ() write(*,*) "FOO_BAZ 2" endsubroutine end module 

लेकिन जब संकलन, एक अप्रिय आश्चर्य हमें इंतजार कर रहा है:

 1>------ Build started: Project: Console1, Configuration: Debug Win32 ------ 1>Compiling with Intel(R) Visual Fortran 11.1.051 [IA-32]... 1>FOO_BAZ.f90 1>F:\2011_03_12\CPP_PROJECTS\Console1\Console1\FOO_BAZ.f90(8): error #6645: The name of the module procedure conflicts with a name in the encompassing scoping unit. [FOO_BAZ] 1>compilation aborted for F:\2011_03_12\CPP_PROJECTS\Console1\Console1\FOO_BAZ.f90 (code 1) 1>Bar.f90 1>FooProgram.f90 1> 1>Build log written to "file://F:\2011_03_12\CPP_PROJECTS\Console1\Console1\Debug\BuildLog.htm" 1>Console1 - 2 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== 

मॉड्यूलर प्रक्रिया का नाम इंटरफ़ेस के नाम के साथ संघर्ष करता है।

क्या करें?
क्या हम जो हार मानने की कोशिश कर रहे हैं, वह हमारे ऊपर हावी हो जाएगा, और हम अपरिवर्तित कोड के तथ्य पर फिर से काम करने पर अपना आधा काम करने के लिए बर्बाद होंगे?

हक। दूसरा कदम

हम FOO_BAZ इंटरफ़ेस के कार्यान्वयन को एक अलग संकलन इकाई में निकालते हैं:

 !Foo_baz.f90 module FOO_BAZModule interface subroutine FOO_BAZ() endsubroutine endinterface end module !FOO_BAZ_Implementation.f90 subroutine FOO_BAZ() write(*,*) "FOO_BAZ 2" endsubroutine 

संकलन ...

 1>------ Build started: Project: Console1, Configuration: Debug Win32 ------ 1>Compiling with Intel(R) Visual Fortran 11.1.051 [IA-32]... 1>FOO_BAZ_Implementation.f90 1>FOO_BAZ.f90 1>Bar.f90 1>FooProgram.f90 1>Linking... 1>Embedding manifest... 1> 1>Build log written to "file://F:\2011_03_12\CPP_PROJECTS\Console1\Console1\Debug\BuildLog.htm" 1>Console1 - 0 error(s), 0 warning(s) ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== 

खैर अब, तीन फ़ाइलों के बजाय, आपको चार संकलन करना होगा। हैक काम नहीं किया?
हम FOO_BAZ के कार्यान्वयन में बदलाव करेंगे, जो अब "बाहरी प्रक्रिया" प्रकार की एक कार्यक्रम इकाई बन गई है, और संख्या संकलन:

 1>------ Build started: Project: Console1, Configuration: Debug Win32 ------ 1>Compiling with Intel(R) Visual Fortran 11.1.051 [IA-32]... 1>FOO_BAZ_Implementation.f90 1>Linking... 1>Embedding manifest... 1> 1>Build log written to "file://F:\2011_03_12\CPP_PROJECTS\Console1\Console1\Debug\BuildLog.htm" 1>Console1 - 0 error(s), 0 warning(s) ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== 

वह सब है। हैक काम कर गया।

अतिरिक्त संकलन इकाई के अलावा, इस हैक के लिए क्या भुगतान करना होगा?
तथ्य यह है कि अब हम इस तथ्य के लिए जिम्मेदार हैं कि विनिर्देश "बाहरी प्रक्रिया" FOO_BAZ मॉड्यूल FOO_BAZModule से इंटरफ़ेस FOO_BAZ को संतुष्ट करता है (मेल खाता है)।

निष्कर्ष

क्या हमें वही नहीं मिला है जो हमें प्रवेश द्वार पर मिला था?
व्यावहारिक दृष्टिकोण से - नहीं, उन्होंने ऐसा नहीं किया, क्योंकि मैनुअल सत्यापन अब केवल अंतिम चरण में आवश्यक है - इंटरफ़ेस का कार्यान्वयन।

मेरे डिजाइन प्रोजेक्ट में, एक समान हैक ने मुझे मॉड्यूल से स्थिर कोड का एक बड़ा टुकड़ा डिस्कनेक्ट करने की अनुमति दी जो सक्रिय विकास के तहत थे।

उपसंहार

बेशक, अब जब .NET प्लेटफ़ॉर्म के लिए कंपाइलरों के परिवार की पूरी परियोजना तक पहुंच है, उसी क्षण जब आप Microsoft Visual Studio में कोड लिख रहे हैं, तो ये विचार केवल एक अच्छी प्रकृति वाली मुस्कान पैदा कर सकते हैं, लेकिन यह मत भूलो कि इंजीनियरिंग के माहौल में वे जल्दी जाने के लिए तैयार नहीं हैं प्रबंधित कोड, जबकि इंटेल फोरट्रान संकलक को विकसित करना जारी रखता है।
और फोरट्रान स्वयं अभी भी खड़ा नहीं है: फोरट्रान 2003 और फोरट्रान 2008 मानक लंबे समय से हमारे लिए उपलब्ध हैं।
एक साल पहले, मेरे सहयोगी ने इस तथ्य पर मेरा ध्यान आकर्षित किया कि आपके परीक्षण के लिए आज प्रस्तावित हैक नए मानकों में परिलक्षित होता था, हालांकि, जहां तक ​​मुझे पता है, यह अभी तक अधिकांश फोरट्रान संकलकों में लागू नहीं किया गया है: दोनों वाणिज्यिक और स्वतंत्र रूप से वितरित।

संदर्भ

इस आलेख ने Intel® Visual Fortran Console Application प्रोजेक्ट का उपयोग करते हुए Intel Visual Studio * 2008, 11.1.3468.2008, कॉपीराइट © 2002-2009 Intel Corporation के लिए Intel® Visual Fortran Compiler Integration का उपयोग किया।
* अन्य नामों और ब्रांडों को दूसरों की संपत्ति के रूप में दावा किया जा सकता है।
Microsoft Visual Studio 2008 के लिए
संस्करण 9.0.30729.1 सपा © 2007 Microsoft निगम
और Intel® Fortran Compiler से सामग्री 11.1 उपयोगकर्ता और संदर्भ मार्गदर्शिकाएँ
Ps लेखक किसी भी कथन के संबंध में ईमानदारी से गलत हो सकता है।