-
محاوره ای ++c
سلاح مخفي محبوبترين زبانهاي اسكريپتينگ، پشتيباني آنها از يك حالت
محاوره‌اي است. سيستمهاي LISP و BASIC به اين دليل محبوب شده‌اند
كه در آنها عبارات مي‌توانند تايپ شده و بلافاصله ارزيابي شوند، بدون شك
آنها خصوصيات ديگري نيز دارند اما اگر اينقدر تعاملي نبودند چندان مورد
توجه قرار نمي‌گرفتند. البته اين مسئله بيشترين نمود را در زبانهائي نظير
LISP دارد كه در آنها هر چيزي داراي ارزشي است حتي اگر صفر باشد، با اين
وجود تقريبا هر زبان برنامه نويسي مي‌تواند بصورت تعاملي مورد استفاده
قرار گيرد. چنين نحوه اجرائي از يك سبك برنامه نويسي "محاوره‌اي"
پشتيباني مي‌كند كه در آن واكنش كامپيوتر عملا آني است. عليرغم
محدوديتهاي سيستمهاي تعاملي نظير LISP، APL و يا FORTH، برنامه
نويسان هنگام كار با آنها بازدهي بسيار خوبي داشتند.
تنها ضرورت اين است كه زبان برنامه نويسي مبتني بر تابع باشد. در
اينصورت حتي پاسكال نيز مي‌تواند بصورت تعاملي تفسير شود. Eiffel و
Java مشكلاتي را بروز خواهند داد زير آنها مبتني بر كلاس هستند. يك
اجراي تعاملي از جاوا ضرورتا با فشار بر روي زبان انجام خواهد شد.
تفاوت بزرگ ميان دو محيط دسته‌اي (Batch) و تعاملي در اين است كه
محيطهاي دسته‌اي بايستي جريان تلفيقي خود را حفظ كنند، در حاليكه
محيطهاي تعاملي نيازمند حفظ جريان ارزشيابي هستند. معمولا سيستمهاي
تعاملي با بروز اولين خطا، تلاش خود براي كامپايل نمودن را متوقف مي‌كنند.
كامپايلرهاي ++C به آساني گيج مي‌شوند و اين مسئله باعث گيج شدن
برنامه نويس مي‌شود كه واقعا نيازمند آن است كه اول گزارش خطا را مشخص
نمايد. اين مسئله خصوصا در مورد برنامه نويسان تازه كار صحت دارد. من
در ابتدا كارم را با سيستمهاي محاوره‌اي ++C شروع كردم زيرا احساس
مي‌كردم آنها ابزارهاي بسيار مفيدي براي مبتدياني باشند كه در حال يادگيري
اين زبان هستند. آزادي در كاوش، يكي از قسمتهاي اساسي جريان آموزش
است و يادگيري زبان انساني در ابتدا با صحبت كردن آغاز مي‌شود، نه با
خواندن و يا نوشتن.
-
++C در مقايسه با BASIC براي كارهاي تعاملي مناسبتر است زيرا
عبارات آن مي‌توانند بيانهاي معتبر باشند. براي مثال شما مي‌توانيد يك
تكليف را تايپ كنيد، ارزش آن به شما نشان داده خواهد شد. همچنين متغيرها
نيز بيانهاي معتبر ++C هستند. آنچه مي‌خواهم در اين مقاله به شما نشان
دهم، قدرت استفاده از ++C در اين حالت تعاملي بصورت عملي است، و
اينكه اين كار چگونه مي‌تواند بطور بالقوه بازدهي برنامه نويسان را تقويت
نمايد.
++C تعاملي به يك هماهنگي نسبتا ملايم نياز دارد. در ++C
استانداردبيانها مي‌توانند با ساير توضيحات تركيب شوند، اما تنها در بدنه
توابع و يا كلاسها. در ++C تعاملي تعاريف توابع مي‌توانند بصورت
مفهومي عمومي با بيانها تركيب شوند.
} ;x*x return { (x double)sqr double >;
;(٢)sqr >;
٠.٤ (double)
;٢ = x double >;
;x >;
٠.٢=x (double)
تمام اينها بيانهاي معتبر ++C هستند، با اين استثنا كه هيچ محدوديت
مفهومي در استفاده از آنها وجود ندارد. در اينجا دوست قديمي و بدنام ما
(پردازنده) بسيار مفيد مي‌شود. براي مثال من براي استفاده از بيان IF
هميشگي، عموما يك ماكرو را تعريف مي‌كنم:
(++i ;(n) < i ;٠=i int)for (n,i)FOR define# >;
;endl << i << cout (٥,i)FOR >;
٠
١
٢
٣
٤ اين دليل ديگري بر اين مسئله است كه ++C زبان تعاملي بهتري نسبت به
پاسكال (و حتي بيسيك) است. اين يك زبان مختصر و مفيد است كه مي‌تواند
با ماكروها حتي از اين هم فشرده‌تر شود.
در حال حاضر ايجاد كردن مفاهيم خودتان در ++C رسمي اصولا ايده خوبي
نيست. اما در يك مضمون محاوره‌اي، مي‌توانيد از يك سبك غير رسميتر
استفاده كنيد. در يك سند قانوني رسمي به زبان انگليسي، نبايستي از
اختصارها (نظير "t'don") استفاده كنيد. اما در طول يك نشست تعاملي براي
پيگيري سريعتر تعامل، ممكن است از هر موردي كه از نظر نحوي قانوني
باشد، به كرات استفاده كنيد:
()end.(ls),()begin.(ls) (ls)ALL define# >;
;(arr,(ls)ALL)COPY >;
من اصولا در هنگام تهيه كدها تمايلي به انجام اينكار ندارم.
استفاده از ++C در يك شيوه تفسيري، بيش از حد پيچيده در نظر گرفته
مي‌شد اما اين يك مشكل تاريخي است كه بايستي در مسيري كه برنامه در
ابتدا بكار گرفته مي‌شد، انجام شود: پردازنده، مترجم (به C)، كامپايلر (به
اسمبلي)، اسمبلر (به كد ابجكت) و لينكر (به كد قابل اجرا). يك مفسر مدرن
نظير UnderC، ورودي را از طريق يك Tokenizer پيش پردازشي
دريافت مي‌كند، و آن را مستقيما به Pcode كامپايل مي‌كند كه بلافاصله پس
از آن اجرا مي‌شود. اين كد بطور آشكاري كندتر از نتيجه يك كامپايلر واقعي
است، اما سيستمهاي تعاملي تنها بايد از زمان واكنش انسان سريعتر باشند.
اصولا اگر شما بتوانيد كاري را در كمتر از ١٥٠ ميلي ثانيه انجام دهيد، شما
بعنوان يك عملگر آني در نظر گرفته مي‌شويد. اين مسئله كه در اجراهاي
تعاملي يك مبدله پيچيدگي/سرعت وجود دارد، افسانه‌اي است كه واقعيت
ندارد.
-
++C به اندازه كافي موجز است، اما شايد براي استفاده بصورت تعاملي بيش
از حد نحوي است. من مي‌پذيرم كه تايپ بيان For چندان آسان نيست، به
همين دليل پيشنهاد كردم كه ماكرو FOR را تعريف كنيد تا تمام كاري را كه
بايد تايپ كنيد برايتان انجام دهد. همچنين استفاده از ماكرو FOR كمتر
مستعد خطا است; من بارها به خاطر عوض شدن يك i با يك j در حلقه‌هاي تو
در تو گير افتاده‌ام. بطور عادي مردم به سرعت به سراغ تعريف توابع و كلاسها
نمي‌روند (در صورتيكه اينكار را انجام دهند تسهيلاتي براي كپي نمودن و
رونويسي آنها در يك فايل و يا به كليپ بورد وجود دارند)، كارهاي پيچيده
در يك فايل تايپ خواهد شد و در صورت نياز بارگذاري مي‌شوند.
يك پرسش جالبتر اين است كه آيا ++C به اندازه كافي گويا هست؟ مطمئنا
پاسكال چنين نيست (همانطور كه به اندازه كافي موجز نيست). مردم از
زبانهاي ويژه كاربرد استفاده مي‌كنند زيرا تنها چند ضرب كليد با تمامي
ابزارهاي حرفه خاص خود فاصله دارند. يكي از كاربردهائي كه اين نكته را
نشان مي‌دهد، الگوسازي الگوريتم پردازش سيگنال است.
++C بخاطر قابليت آن در تعريف دقيق معاني زباني به نحو مطلوب، براي
اينگونه كاربردها كاملا مناسب است. توابع مي‌توانند بردارهاي Passed
باشند و ممكن است بردارهائي را برگردانند. محاسبات با اعداد پيچيده از
نمادهاي معمولي استفاده مي‌كند. براي مثال يك سيستم تعاملي ++C
مي‌تواند به پيش‌الگوها امكان دهد تا طيف قدرت اختلافهاي مابين دو بردار
داده با يك خط را نشان دهند، نظير: ;((y+x)fft)abs)plot >;.
اين شيوه مناسبي براي شكستن اعداد نيست، اما اين مسئله در اينجا چندان
بحراني نيست. در واقع از مفسر استفاده شده است تا تركيبات تابعي را به
يكديگر بچسباند. خود تركيبات بايستي بصورت كتابخانه‌هاي اشتراكي بكار
گرفته شوند كه با يك كامپايلر بهينه سازي، ساخته شده‌اند.
اين نوع كاربردهاي مهندسي ممكن است تخصصي به نظر برسند، اما اكثر انواع
پروژه‌ها مي‌توانند از پيش الگوهاي تعاملي سود ببرند. در هسته بزرگترين
پروژه‌ها، طراحيهاي ناشناخته‌اي وجود دارند كه بايستي مورد كاوش قرار
گيرند. به نظر مي‌رسد برنامه نويسي اكتشافي با روند دقيق مهندسي نرم‌افزار
تناقض زيادي داشته باشد، اما مي‌تواند به اقسام گوناگوني در طراحي و
اجراي پروژه‌ها مشاركت نمايد. به گفته Sheil .A.B برنامه نويسي اكتشافي
به دنبال تقويت برنامه نويسان است، در حاليكه شيوه‌هاي ساختار يافته
طراحي شده‌اند تا برنامه نويسان را مهار كنند. هر دو اين شيوه‌ها در روند
توسعه نرم‌افزار داراي جايگاه خاص خود هستند. جايگاه ديگري كه حالت
تعاملي در توسعه دشوار دارد، آزمايش است. من متوجه شدم كه كلاسها
مشكلاتشان را در جين محاوره آشكار مي‌كنند. بدون شك شما نياز داريد
آزمونهاي ثابتي را براي بررسيهاي بعدي ايجاد نمائيد، اما ...
در مورد اين حقيقت كه حجم زيادي از اطلاعات هدر بايستي در بر گرفته
شوند، راهي وجود ندارد و اين هدرها بزرگترين قسمت از متن برنامه را كه
كامپايلر بايستي با آن سر و كار داشته باشد تشكيل مي‌دهند. يك برنامه
كوچك ٣٠ خطي ++C استاندارد كه با رشته‌ها و جريانهاي O/I سر و كار
دارد كامپايلر را درگير نزديك به ٩٠٠٠ خط فايلهاي هدر مي‌كند. توسعه
وابستگي مابين بخشهاي برنامه‌هاي بزرگ تا ساختن آنها بطور تغيير ناپذيري
يك فرآيند كسالت آور است.
-
در يك نشست تعاملي ++C، هدرها مي‌توانند از پيش بارگذاري شده و
حجم بيشتري از كامپايل مجدد مي‌تواند بطور سريعتري انجام شود زيرا اين
هدرها از قبل در سيستم حاضر هستند. هيچ مرحله لينكي وجود ندارد، تمام
شيوه‌هاي UnderC مراجعات غير مستقيمي به Pcode واقعي دارند بنابراين
نيازي به عبور از تمام مراجعات تابعي كه آدرسها را متصل مي‌كنند وجود
ندارد. اين ويژگي خصوصا هنگاميكه هدرها براي سيستم وارد شده‌اي هستند
كه به ندرت تغيير مي‌كند، بسيار خوب عمل مي‌كنند. هنگاميكه هدرها به يك
نشست تعاملي بارگذاري مي‌شوند، برنامه‌هاي آزمايش VTK در ++C
مي‌توانند در عرض چند ميلي ثانيه مجددا كامپايل شوند. اين مسئله باعث شد
براي سازماندهي محيط اسريپتينگ ++C بطور موثر، راهي به ذهن من
برسد: مفسر بعنوان سرور، مقيم مي‌ماند و يك راه‌انداز اسكريپت مشتري
كوچك با آن ارتباط برقرار مي‌كند و از آن براي اجراي اسكريپتها استفاده
مي‌كند. وضعيت كامپايلر ثابت مي‌ماند و هدر نياز دارند كه تنها در اولين اجرا
به حساب آورده شوند. اين مي‌تواند يك اجراي فوق‌العادي براي يك كاربرد
اسكريپتينگ CGI باشد. خود اسكريپتها مي‌توانند برنامه‌هاي اصلي كوچكي
باشند كه مابقي سيستم فراخواني مي‌كنند و وضعيت بايستي بطور خودكار
مابين ارتباطات مجزا حفظ شود.
با اين شيوه، مشكل وابستگي نيز بيشتر قابل كنترل است. براي مثال يك تغيير
عمومي بر روي كلاس، يك شيوه ديگر است. با وجود آنكه ممكن است آن
تعريف كلاس در سرتاسر سيستم مورد نياز باشد (احتمالا صدها هزار خط و يا
بيشتر)، ما تنها با كامپايل مجدد خود كلاس نياز داريم زيرا طرح كلي كلاس
تغيير نكرده است. در واقع شما تنها نياز داريد خود شيوه را كامپايل نمائيد.
پس اين امكان وجود دارد كه محيطي را ايجاد كنيد كه سيستمهاي بزرگ
++C، اغلب در عرض چند ميلي ثانيه (بجاي دقيقه‌ها و ساعتها) در آن قابل
ويرايش باشند. يك انتقاد در اين مورد اين است كه شما را تشويق به
Hacking مي‌كند، اما در عين حال اين شيوه شما را به آزمايش كل سيستم
نيزتشويق مي‌كند. برنامه‌نويسي اكتشافي مشوق يك انتقال از فكر كردن به قابل
اجراهاي يكپارچه است. در اينجا "برنامه‌اي" كه "راه‌اندازي" شده باشد وجود
ندارد. در عوض شما در داخل سيستم قرار داريد. من متوجه شده‌ام كه در
هنگام اشكال‌زدائي كاربردهاي GUI در محيطهاي سنتي زمان بسيار زيادي
به هدر مي‌رود كه جاي آزمايش شما را مي‌گيرد. اما در داخل سيستمهاي
تعاملي، كد مي‌تواند در هنگاميكه سيستم در حال اجرا است اصلاح شود.
چيزيكه در مورد اين امكانات متوجه شدم اين است كه يك زبان شي‌گراي
سنتي مانند ++C هنوز مي‌تواند در يك سبك اكتشافي مورد استفاده قرار
گيرد و ما مي‌توانيم از مشكلاتي كه واقعا در اجراهاي سنتي پيش مي‌آيند
عبور كنيم.
