ممکن است این سوال مطرح شود که اصولا چه زمانی استانداردسازی زبانهای برنامهنویسی انجام میشود. اگر قبل از آن که زبان برنامهنویسی پیادهسازی شود و مورد آزمایش قرار گیرد، اقدام به استانداردسازی آن شود ممکن است در آینده با مشکلات بسیار روبهرو شود و ناچار به تغییر یا اصلاح آن شوند.
از سوی دیگر، اگر در استانداردسازی زبان تاخیر طولانی بهوجود بیاید ممکن است شاهد پیادهسازیهای متعددی از آن زبان باشیم که بهدلیل نداشتن یک مرجع واحد، ناسازگاریهای متفاوتی با هم خواهند داشت. بیشک در این مدت افراد بسیاری نیز با آن پیادهسازیها کار و به آنها عادت کردهاند و در نتیجه اگر کسی بخواهد از یک پیادهسازی به دیگری روی بیاورد در کار با آن دچار مشکل خواهد شد. همچنین اگر برنامهای را که به یک زبان واحد نوشته شده است و در کامپایلری بدون اشکال به فایل اجرایی نهایی منتج شده است، در پیادهسازی دیگر آن کامپایلر بخواهیم کنیم ممکن است با اشکالات متعدد روبهرو شویم که عملا اشکالیابی و اشکالزدایی آن را غیرممکن خواهد ساخت و در نتیجه فرد مجبور خواهد بود همواره با یک کامپایلر کار کند. این که نتوان یک برنامه به یک زبان واحد را در کامپایلرهای دیگر همان زبان کامپایل کرد، یک اشکال بزرگ بهشمار میرود که به آن نداشتن قابلیت انتقال1 گفته میشود.
لزوم قابلیت انتقال
شاید در نگاه برخی افراد قابلیت انتقال یک زبان برنامهسازی، مساله مهمی نباشد. مثلا ممکن است سوال شود که وقتی یک برنامه در کامپایلری مثل کامپایلر ++C بورلند بدون اشکال به فایل اجرایی تبدیل میشود، چه لزومی دارد آن را به کامپایلر ++C مایکروسافت انتقال دهیم؟ این سوال از دو دیدگاه قابل بررسی است. اول این که یک برنامه لزوما توسط یک نفر کامپایل نمیشود. ممکن است افراد مختلف که با کامپایلرهای مختلف کار کردهاند، بخواهند یک برنامه را کامپایل کنند. نمیتوان انتظار داشت که هر کس که میخواهد یک برنامه را کامپایل کند، حتما کامپایلر مربوط به آن را نصب کند. زیرا این کار مستلزم صرف زمان جهت آشنا شدن با آن کامپایلر، کار با ابزارهای آن و حتی نصب آن است. ضمن این که بهعلت پیروی نکردن کامپایلرها از یک استاندارد خاص، شخص باید با آن پیادهسازی از زبان نیز آشنا شود و جزئیات آن را فرا بگیرد.
دیدگاه دیگر به این مساله آن است که شخص بخواهد آن برنامه را در یک سیستم عامل دیگر اجرا کند. بنابر این حتی با پذیرفتن مشکلات یاد شده در دیدگاه اول، نصب آن کامپایلر در سیستم عامل دیگر امکانپذیر نخواهد بود. بهعبارت دیگر، بهعلت سازگار نبودن دو کامپایلر، که در دو سیستم عامل مجزا اجرا میشوند، انتقال یک برنامه از یک ماشین به ماشین دیگر با سیستمعامل متفاوت ممکن خواهد بود. بنابر این اجرای هر برنامه به یک سیستم عامل محدود خواهد شد و این باعث میشود تا برنامهما تنها برای کاربران سیستم عامل مورد نظر ما کار کند.
بنابر این به تاخیر انداختن استانداردسازی زبان؛ خطر ناسازگاری بین پیادهسازیهای مختلف زبان و در نتیجه کاهش قابلیت انتقال را در پی خواهد داشت. در نتیجه استانداردسازی باید در زمانی صورت گیرد که نه تجربهکافی در مورد آن زبان و بهکارگیری آن در دست نباشد و نه این که آنقدر دیر اقدام شود که شاهد مشکلات ناسازگاری باشیم.
نقش برنامهنویس
با این که مسائل گفته شده در میزان قابلیت انتقال یک برنامه نقش اساسی دارند، اما نقش برنامهنویس و نحوه کدنویسی او را نیز نباید نادیده گرفت. نحوه پیادهسازی یک زبان دست ما نیست که بخواهیم آن را مطابق میل خود تغییر دهیم. اما ما با رعایت برخی نکات و ریزهکاریها میتوانیم در بهبود برنامههای خود تاثیرگذار باشیم.
کمی از کلیگویی به سمت جزئیات میرویم تا این مساله را بهتر درک کرده و بتوانیم آن را در عمل نیز بهکار بگیریم و با تعمیم آن به موارد مشابه، سطح برنامهنویسی خود را ارتقا بخشیم. فرض کنید میخواهیم از یک فایل چندین رکورد چند رکورد را بخوانیم. هنگام خواندن رکوردها، معمولا اشارهگری2 به رکورد جاری در حال خواندن اشاره میکند. حال ممکن است در یک پیادهسازی از زبان بعد از خواندن رکورد جاری، اشارهگر فایل به ابتدای رکورد بعد رفته و منتظر دریافت دستور خواندن یا نوشتن بماند و در پیادهسازی دیگر زبان، اشارهگر فایل زمانی به رکورد بعدی پرش کند که دستور خواندن یا نوشتن را دریافت کرده باشد و در حالت معمول به آخرین رکوردی که خوانده است، اشاره کند.
تاثیر این دو پیادهسازی هنگامی که قرار است چند رکورد پشت سر هم خوانده شده و پردازش شود یکسان است. در غیر اینصورت مواردی وجود دارد که این دو نوع رفتار در بخش دیگر برنامه اثر میگذارد. ضمن این که ممکن است در پیادهسازی دیگر زبان برنامهنویس مجبور باشد اشارهگر فایل را با دستور صریح تغییر دهد و این کار بهطور خودکار صورت نگیرد.
معمولا با نوشتن یک برنامه آزمایشی کوچک میتوان نوع پیادهسازی رفتاری را در یک زبان تشخیص داد و معمولا این خصوصیات در طول برنامهنویسی در خاطر شخص باقی میماند. اما برنامهنویس باید به این نکته توجه داشت باشد که اگر قرار باشد برنامه خود را در یک کامپایلر دیگر از آن زبان یا در سیستمعامل دیگری کامپایل کند، ممکن است حتی اگر با خطایی نیز مواجه نشود، یک اشکال منطقی ظریف در برنامه ظهور کند که معمولا یافتن اینگونه اشکالات زمانگیر و خستهکننده است.
توصیهای که به برنامهنویسان در این زمینه میشود آن است که برای بالا بردن خوانایی برنامه و قابلیت حمل آن، برخی مواردی که به طور منطقی توسط زبان انجام میشود و یا طی عملیاتی در پشت صحنه انجام میشود با دستورات صریح، طوری که در سرعت برنامه تاثیر نداشته باشند، قید کنند. به عنوان مثال برنامهنویسی میداند که متغیر a در شروع یک عملیات باید مقدار صفر داشته باشد. همچنین میتواند نتیجه بگیرد که مقدار a در طول برنامه هنگامی که به شروع عملیات یاد شده میرسد صفر خواهد بود. با این وجود بهتر است به این نتیجهگیری اکتفا نکرده و با یک دستور صریح انتساب صفر به )0a (a= هرگونه شک و شبههای را از میان بردارد. ضمن این که اگر شخص دیگری بخواهد این کد را بخواند، بیتردید میتواند نتیجه بگیرد که در آن نقطه از برنامه مقدار a صفر است.
یا مثلا در مورد دیگر برنامهنویس میداند که اگر یک آرایه3 از اعداد صحیح4 تعریف کند، کامپایلر مقدار هر مولفه آن را بهطور پیشفرض صفر در نظر میگیرد. اما خوب است هنگامی که میخواهد از آن آرایه استفاده کند، با دستورات صریح، به مولفههای آرایه مقدار صفر را نسبت دهد. زیرا اولا به خواننده برنامه میگوید که صفر بودن مقدار در آن نقطه اهمیت دارد و توجه او را به این مساله جلب میکند، ثانیا ممکن است یک پیادهسازی از آن زبان به هنگام تعریف آرایه، آن را مقدار دهی اولیه صفر نکند و از همان مقادیری استفاده کند که در خانههای حافظه قبلا نوشته شده است. در این صورت با کامپایل شدن مجدد آن برنامه در کامپایلر دیگر، یک خطای منطقی بروز میکند. در صورتی که اگر آن دستور انتساب مقدار به مؤلفهها وجود داشت این اشکال رخ نمیداد. در واقع ذکر آن دستور برای کامپایلر اول اضافه و برای کامپایلر دوم ضروری است و ما به خاطر این ضرورت، بهتر است اضافه بودن اولی را بپذیریم. البته گاهی ممکن است این کار باعث کاهش کارایی برنامه شود که در این مورد نیز در آینده صحبت خواهیم کرد.
پینوشتها
Portability. 1
Pointer. 2
Array. 3
Integer. 4
پارسا ستودهنیا
در تپش این هفته، ماجرای فریب و تعرض در پوشش عرفانهای دروغین و رمالی را بررسی کردیم