السلام عليكم ..
بعد مشاركتي في موضوع الأخ مصطفى (سؤال : هل نعتبر تعليمات الـpreProcessor جزءاً من اللغة ؟)
قمت بتجريب بعض الأكواد التي عملت لها PreProcessing باستخدام الـــ (C Pre Processor) المسمى cpp فوجدت انه عندما يقوم باستبدال الــIncludes بمحتوى الملف الاصلي فإنه يقوم بوضع الرمز # متبوعا برقم السطر و اسم الملف الذي جاء منه الكود : مثل :
#100 "a.c"
أي ان الكود التالي لهذا السطر تم جلبه ابتداء من السطر 100 من الملف a.c و مهمة هذا السطر ان المترجم يعيد لنا اسم الملف الاصلي و رقم السطر الحقيقي عند حصول خطأ .. (طبعا بعد عملية الــ PreProcessing) تكون أرقام الاسطر في الكود قد تغيرت و عندما تدخل الأكواد للترجمة الفعلية و يكتشف المترجم أن هناك خطأ فإنه يعيد لنا اسم الملف و رقم السطر الحقيقي اعتمادا على المعلومات السابقة التي تم وضعها في مرحلة الــ PreProcessing .
الآن لنجرب الكود التالي و نحفظه في ملف باسم ab.c:
#680 "myDoc.pdf"main(){int y}و نترجمه (gcc على Cygwin) , طبعا الكود ينقصه فاصلة منقوطة في السطر الرابع , و لكن المترجم سيعطي الخطأ التالي:
# gcc -o ab ab.c myDoc.pdf: In function ?main?: myDoc.pdf:683: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?} ? token
:wacko: :wacko: :wacko:
يعطينا رسالة أنه في الملف myDoc.pdf في السطر 683 يوجد خطأ , علما انه لا يوجد ملف بهذا الاسم و الكود كله على بعضه 5 أسطر .
الذي حصل , أن الــ PreProcessor قد مرر السطر :
#680 "myDoc.pdf"
إلى المترجم (هنا الخطأ , المفروض ان يعترض), مع باقي الكود , ثم اكتشف المترجم انه لا يوجد فاصلة منقوطة , فسوف يعيد رسالة بالسطر و اسم الملف , للمستخدم , و هو سيأخذه من آخر سطر يبدأ بالرمز # .. الذي هو (#680 "myDoc.pdf") أي اعتبر أن الكود تم جلبه من الملف MyDoc.pdf من السطر 680 و سطرنا هو الثالث عمليا , فاعتبره أنه موجود في السطر 683 ..
برأيي أن المترجم gcc كان من المفروض ان لا يتم خداعه بهذه الطريقة . :) و انه من البداية يجب ان يعترض على الـــ PreProcessor Directive الموجود في السطر الأول .