رفتن به مطلب
جامعه‌ی برنامه‌نویسان مُدرن ایران

برنامه نویسی

  • نوشته‌
    17
  • دیدگاه
    8
  • مشاهده
    2,109

مشارکت‌کنندگان این وبلاگ

درباره این وبلاگ

نوشته‌های این وبلاگ

 

فرق بین کامپایل استاتیک و داینامیک

فرق بین کامپایل استاتیک و داینامیک قبل از اینکه فرق بین ایستا (استاتیک) - Static و پویا (داینامیک) - Dynamic را بدانیم لازم است در رابطه با چرخه‌ی زندگی نوشتن یک برنامه و اجرای آن آشنا شویم. هر برنامه برای اولین بار توسط یک محیط توسعه (Editor) یا IDE توسط برنامه‌نویسان انتخاب و به صورت فایل متنی قابل ویرایش می‌باشد. سپس فایل متنی که شامل کد‌های نوشته شده توسط برنامه‌نویس تحت زبان برنامه‌نویسی مانند C، C++ و غیره... می‌باشد توسط کامپایلر به کد شیء ای تبدیل می‌شود که ماشین بتواند آن را درک کرده و اجرا کند. برنامه ای که ما می‌نویسیم ممکن است به عنوان یک مورد توسط دیگر برنامه ها یا کتابخانه‌هایی از برنامه ها مورد استفاده قرار بگیرد برقراری ارتباط (پیوند‌کردن - لینکر) یا همان لینک کردن پروسه‌ای است که برای اجرای موفقیت آمیز برنامه‌های نوشته شده ما بکار می‌رود؛ برقراری ارتباط بین ایستا و پویا دو پروسه‌ای از جمع‌آوری و ترکیب فایل‌های شیء‌های مختلفی است که به منظور ایجاد یک فایل اجرایی می‌باشند. در این بخش ما تصمیم بر این داریم تا تفاوت بین آن ها را با جزئیات مورد بررسی قرار دهیم. عمل پیوند یا ترکیب در زمان کامپایل انجام شود، در واقع زمانی که کد منبع به زبان ماشین ترجمه می‌شود، در زمان بارگذاری، زمانی که برنامه در داخله حافظه بارگذاری می‌شود، و حتی زمان اجرای آن توسط برنامه صورت می‌گیرد این عمل زمان پیوند و یا ترکیب (اتصال) است. در نهایت این فرآیند توسط برنامه ای اجرا می شود که به آن لینکر - پیوند دهنده (ترکیب کننده) می‌گویند. اتصال دهنده ها به عنوان ویرایستار لینک نیز معرفی می‌شوند. لینک شدن (پیوند شدن) به آخرین مرحله از کامپایل می‌گویند. در زبان علمی اصطلاح لینکر یا Linker معروف است اما در زبان فارسی بهترین گزینه مربوطه را می‌توان با عنوان اتصال دهنده، پیوند دهنده، ترکیب کننده نام برد. همه آن ها نشانگر یک هدف به منظور ترکیب اشیاء با یکدیگر هستند که در مرحله کامپایل صورت می‌گیرد. پس از ایجاد پیوند در برنامه، برای اجرای آن برنامه باید داخل حافظه منتقل شود. در انجام این کار باید آدرس هایی برای اجرای داده ها و دستور العمل ها اختصاص یابد. به طور خلاصه روند زیر می‌تواند به عنوان چرخه زندگی یک برنامه خلاصه شود (نوشتن - لینک کردن - بارگذاری - اجرا) فرق بین کامپایل استاتیک و داینامیک در زیر تفاوت های عمده ارتباط بین استاتیک و داینامیک آورده شده است : استاتیک  ارتباط به روش استاتیک فرآیندی است که تمامی ماژول‌ها و کتابخانه‌های برنامه در فایل اجرایی نهایی کپی می‌شوند. این روش توسط لینکر در مرحله آخر کامپایل انجام می‌شود. اتصال دهنده - لینکر طبق روال ترکیبی کتابخانه ها را با کد برنامه و همراه مراجع - منابع خارجی ترکیب کرده و برای تولید یک بارگذاری مناسب در حافظه آماده سازی می‌کند. زمانی که برنامه بار‌گذاری می‌شود، سیستم عامل محلی را در حافظه به صورت یک فایل اجرایی که شامل کد‌های اجرایی و داده ها می‌باشد مشخص می‌کند. ارتباط به شیوه‌ی استاتیک توسط برنامه‌ای با نام لینکر انجام می‌شود که در آخرین مرحله فرآیند کامپایل یک برنامه صورت می‌گیرد. لینکر‌ها نیز به عنوان ویرایشگر پیوند نیز عنوان می‌شوند. فایل های استاتیک به طور قابل توجهی دارای اندازه بسیار بزرگی هستند زیرا برنامه های خارجی و کتابخانه های لینک شده همه در یکجا و در فایل نهایی اجرایی جمع آوری شده‌اند. در اتصال استاتیک اگر هر یک از برنامه های خارجی تغییر کرده باشد باید آن ها دوباره کامپایل شوند و مجددا عمل اتصال صورت گیرد در غیر اینصورت هیچ تغییری در به روز رسانی های مرتبط با فایل اجرایی مشاهده نخواهد شد. برنامه‌های استاتیکی زمان بارگذاری ثابتی در هر بار اجرای برنامه در حافظه را در نظر می‌گیرند. و زمانی که برای بارگذاری طول می کشد ثابت است. برنامه‌هایی که از کتابخانه‌های استاتیکی استفاده می‌کنند معمولاً سریعتر از برنامه‌هایی هستند که کتابخانه‌‌ی آن‌ها به صورت پویا می‌باشد. در برنامه های استاتیکی، تمامی کد ها شامل یک فایل اجرایی می‌باشند. بنابراین، آن‌ها هرگز در برنامه هایی که دارای مشکلاتی هستند اجرا نخواهند شد. داینامیک در ارتباط پویا نام کتابخانه های خارجی (کتابخانه‌های به اشتراک گذاری شده) در فایل اجرایی نهایی قرار داده شده‌اند نه خود کتابخانه. در حالی که ارتباط واقعی در زمان اجرا در هر دو فایل در حافظه قرار می‌گیرند. اتصال پویا این اجازه را می‌دهند تا برنامه های متعددی به صورت یک ماژول کپی شده و قابل اجرا مورد استفاده قرار بگیرد. اتصال پویا بر خلاف اتصال استاتیک در زمان اجرا توسط سیستم عامل انجام می‌شود. در اتصال پویا فقط یک نسخه از کتابخانه به اشتراک گذاری شده در حافظه نگه‌داری می‌شود. این به طور قابل توجهی اندازه برنامه های اجرایی را کاهش می‌دهد، در نتیجه صرفحه جویی در حافظه و فضای دیسک صورت خواهد گرفت. در اتصال پویا بر خلاف اتصال استاتیک نیازی به کامپایل کامل پروژه نمی‌باشد در صورتی که لازم باشد تغییراتی در هر یک از فایل‌ها صورت بگیرد تنها کافی است آن را کامپایل و در کنار برنامه قرار دهید. این یکی از بزرگترین مزیت‌های کامپایل داینامیکی می‌باشد. در اتصال پویا زمان بارگذاری برنامه در حافظه ممکن است کاهش یابد. این در صورتی است که کتابخانه های مشترک در حافظه بارگذاری شده‌اند. برنامه‌هایی که از کتابخانه های مشترک استفاده می‌کنند معمولا کندتر از برنامه هایی هستند که از کتابخانه های استاتیکی استفاده می‌کنند. برنامه‌های پویا وابسته به داشتن کتابخانه‌های سازگار هستند. اگر کتابخانه تغییر یابد (برای مثال، یک کامپایلر جدید منتشر شود ممکن است کتابخانه را تغییر دهد)، در این صورت ممکن است برنامه مجدداً تحت کتابخانه جدید باز نویسی و به‌روز رسانی شوند. اگر کتابخانه از روی سیستم حذف شود، برنامه‌ای که وابسته آن کتابخانه می‌باشد دیگر کار نخواهد کرد. در ادامه شما می‌توانید در مورد مراحل کامپایل یک برنامه مراجعه کنید:  
 

آشنایی با سرویس میزبانی صفحات گیت هاب (Github Pages)

سلام وقت بخیر, گیت هاب پیج گیتهاب پیج یک سرویس میزبانی وب است که توسط Github اراعه شده است که با استفاده از آن می توانید حتی صفحاتی Static را در پلتفرم وب میزبانی کنید و حتی ابزار هایی مانند Jekyll را می توانید روی این بستر (Github Pages) پیاده و اجرا کنید که در قسمت های آینده در مورد آن توضیح خواهم داد. میزبانی وب سایت هایی که بر پایه Github Pages هستند بصورت رایگان هست و دیگر نیازی به دامین, هاست و سرور وجود ندارد. حساب های گیت هاب تمام حساب هایی که در سایت گیت هاب وجود دارند دو نوع هستند. حساب کاربری و شخصی حساب سازمانی (تیم) بطور مثال : حساب هایی مانند: Kambiz-Asadzadeh (Kambiz Asadzadeh), BaseMax (Max Base), ccoreghaesm (Ghasem Ramezani), HamedMasafi (Hamed Masafi)  همگی حساب های فرد و شخصی هستند. و حساب هایی مانند : Microsoft · GitHub,  Google · GitHub,  TeamSnap · GitHub,  iOSTREAM · GitHub  .حساب هایی سازمانی (تیم) هستند هر حساب کاربری و شخصی این قابلیت را دارد تا بتواند یک حساب سازمانی ایجاد کند. ایجاد حساب سازمانی (تیم) برای ایجاد کردن یک حساب سازمانی, بعد از عضویت و ایجاد یک حساب کاربری در Github و وارد شدن به حساب کاربریتان, به اینجا مراجعه کنید تا یک سازمان جدیدی ایجاد کنید.   گیت هاب پیج به موضوع اصلی برمیگردیم. تا کنون در مورد انواع حساب ها توضیح داده ایم. حال در نظر داشته باشید که هر حساب کاربری (عادی یا سازمانی) این قابلیت را دارد تا بتواند یک میزبانی برای خودش رزرو کند. در حالت پیشفرض میزبانی ها بصورت رایگان بر روی دامین GitHub Pages قرار دارند، با اینحال بطور مثال اگر شما یک حساب (شخصی یا سازمانی) بنام test456 دارید می‌توانید میزبانی خود را بر روی دامین http://test456.github.io فعال کنید. آزمایشگاه و انجام بصورت عملی در حال حاظر من خودم یک سازمان (تیم) بنام MaxFork با آدرس Max Fork · GitHub در اختیار دارم. می خواهم یک میزبانی وب جدید روی این حساب ایجاد کنم. گزینه New را لمس کنید و یک مخزن جدید (پروژه) ایجاد کنید. دقت کنید که نام پروژه اهمیت دارد را آدرس میزبانی که مد نظرمان هست وارد می کنیم. بطور مثال : MaxFork.Github.io محتوای Description اختیاری است و می توانید هر چه میخواهید وارد کنید. چون بعدا هم امکان ویرایش کردن آن برایتان وجود ندارد. نوع پروژه را می توانید Public یا Private تنظیم کنید. با توجه به اینکه حساب های اکثر افراد معمولی هست گمان میکنم امکان تنظیم کردن از نوع Private برای آنها همراه با میزبانی وب وجود نداشته باشد. بنابراین Public را انتخاب کنید.  پیاده کردن یک فایل README برای مخزن اختیاری است و می توانید آنرا ایجاد کنید. همچنین تصمیم شما در مورد انتخاب لایسنس نیز آزادانه است و می توانید خودتان شخصا در مورد آن فکر و تصمیم بگیرید. برای امتحان می توانید فایلی بنام index.html را با یک محتوای آزمایشی ایجاد کنید. در حال حاظر وب سایتی با آدرس https://maxfork.github.io در دسترس وجود دارد و محتوایی را که در فایل نوشته ایم را نشان می دهد.   در انتهای بخش Settings در قسمت GitHub Pages می توانید وضعیت میزبانی را بررسی کنید. در قسمت ذکر شده می توانید قالب های از قبل تعریف شده را مشاهده و انتخاب کنید. همچنین امکان تنظیم Custom domain برای میزبانی را هم دارید.   همچنین می توانید فایل های دیگری نیز مانند test.html همراه با پوشه و مسیردهی ایجاد کنید. بطور مثال اکنون ما فایل new.html را در شاخه اصلی مخزن ایجاد کردیم که در آدرس زیر قابل دسترس است: https://maxfork.github.io/new.html فایلی بنام _config.yml از قبل تعریف شده است که می توانید بصورت دستی هم ایجاد کنید که در آن نام قالب / تنظیمات / پلاگین و ماژول هایی را که نیاز دارید می توانید تعریف کنید. در قسمت های بعدی در مورد Static بیشتر توضیح خواهم داد، پیشنهاد می‌کنم در مورد Textile و Markdown هم مطالعه کنید.   سپاس سید علی محمدیه

Seyyed Ali Mohammadiye

Seyyed Ali Mohammadiye

 

آغازی طوفانی برای پیاده سازی یک پیام رسان ساده بر پایه ++C

با سلام وقت بخیر, در این مطلب میخواهیم در مورد روش کارکرد پیام رسان ها بیشتر بدانیم و با یکدیگر کد یک پیام رسان ساده را پیاده و بررسی کنیم.  طرز کار کرد پیام رسان در نظر داشته باشید که هر پیام رسانی که بر ساختار ها پیاده شده باشد از دو قسمت تشکیل شده است. نرم افزار اصلی برای مدیریت درخواست ها (سرور) نرم افزار برای کاربران (کاربر) به نرم افزار اولی سمت SERVER خواهیم گفت و به بعدی سمت CLIENT خواهیم گفت. روم یا تالار گفتگو ما تنها یک اتاق برای گفتگو در نظر میگیریم و هر کاربری که به سرور متصل شود را در همان تالار اضافه خواهیم کرد. تالار های گفتگو صرفا برای تقکیک سازی ارسال و دریافت ها و محدود کردن بازه ی کاربران مورد نظر... (ممکن است یک کاربر در چند اتاق بطور همزمان باشد.) سیستم های پیام رسان پیشرفته تر مانند تلگرام و ... تالار های زیادی را شامل می شوند. (هر کاربر خودش در کانال و گروه های مختلفی عضو است که هر کدام از آنها یک کانال متفاوت محسوب می شوند.) * دقت شود که منظور از کانال صرفا یک اتاق یا تالار گفتگو است و منظور کانال ارتباطی و پروتکل نیست. نرم افزار اصلی نرم افزار اصلی وظیفه دارد تا تمام کاربرانی که وارد تالار شده اند را به یاد داشته باشد و هر لحظه اماده دریافت درخواست هایی از طرف کاربرانش باشد. و پیام هایی را که از کاربران دریافت می کند برای تمامی کاربران دیگر هم ارسال کند که بسته به خلاقیت و نیاز می تواند هر یک از این بخش ها متفاوت طراحی شود. نرم افزار اصلی باید از قبل اجرا شده باشد. تا کاربران دیگر با استفاده از نرم افزار مخصوص به خودشان بتوانند به سرور متصل شوند و ارسال و دریافت داشته باشند. در نظر داشته باشید که اگر در نرم افزار اصلی اختلالی پیش بیایید و متوقف بشوند. قطا برای تمام کاربران مشکل پیش می آید. مگر اینکه از پایگاه های داده ی داخلی استفاده کرده باشند. (با خلاقیت می توان به گونه های متفاوتی چنین ساختاری را پیاده کرد) نرم افزار کاربران این نرم افزار جذاب ترین بخش است چرا تمام قابلیت هایی را که در اختیار کاربر قرار می دهیم را مستقیما طراحی می کنیم. در نظر داشته باشید که هر چیزی که در این نرم افزار طراحی می شود باید در نرم افزار اصلی پشتیبانی شوند... بنابراین اگر این دو بخش توسط دو فرد یا دو گروه مجزا طراحی می شوند آنها باید توسط داکیومنت ها و جلساتی به نظرات مشابه ای رسیده باشند. (اگرچه اینها تخصص و وظیفه ی تحلیلگر سیستم است! نه بطور همزمان وظیفه توسعه دهنده و برنامه نویس نرم افزار) پیاده سازی یک نمونه اکنون در نظر داریم تا با استفاده از ساختار کتابخانه BoostAsio پروژه ای را با نام BoostAsioChat ایجاد کنیم که در آن می خواهیم یک پیام رسان با حداقل ترین امکانات پایه طراحی کنیم که بیشتر جنبه شخصی و تفریحی دارد. زیرا از ساختار های استاندارد و ایمن و کاربری کاملا بدور است! (می توانید خودتان توسعه دهید و آنرا جالب تر بسازید)   ساختار نرم افزار اصلی و سرور را به این صورت تعریف می کنیم : typedef deque<message> messageQueue; class participant { public: virtual ~participant() {} virtual void deliver(const message& messageItem) = 0; }; typedef shared_ptr<participant> participantPointer; class room { public: void join(participantPointer participant); void deliver(const message& messageItem); void leave(participantPointer participant); private: messageQueue messageRecents; enum { max = 200 }; set<participantPointer> participants; }; class session : public participant, public enable_shared_from_this<session> { public: session(tcp::socket socket, room& room) : socket(move(socket)), room_(room); void start(); void deliver(const message& messageItem); private: void readHeader(); void readBody(); void write(); tcp::socket socket; room& room_; message messageItem; messageQueue Messages; }; class server { public: server(boost::asio::io_context& io_context, const tcp::endpoint& endpoint) : acceptor(io_context, endpoint); private: void do_accept(); tcp::acceptor acceptor; room room_; }; int main(int argc, char* argv[]); ساختار نرم افزار کاربر را هم به این صورت تعریف می کنیم : typedef deque<message> messageQueue; class client { public: client(boost::asio::io_context& context, const tcp::resolver::results_type& endpoints) : context(context), socket(context); void write(const message& messageItem); void close(); private: void connect(const tcp::resolver::results_type& endpoints); void readHeader(); void readBody(); void write(); boost::asio::io_context& context; tcp::socket socket; message readMessage; messageQueue writeMessage; }; int main(int argc, char* argv[]);   در نظر داریم تا در این پروژه از thread ها نیز استفاده کنیم... در مورد این مفهوم ها می توانید بصورت مجزا تحقیق کنید. بنابراین روش کامپایل این پروژه به این صورت خواهد بود :   $ g++ client.cpp -lpthread -o client $ g++ Server.cpp -lpthread -o server   آزمایش همانطور که گفته شد در ابتدا نرم افزار اصلی و سرور باید اجرا شود. در اینجا ما تمام ارتباطات شبکه را بر روی یک سیستم در شبکه داخلی برقرار خواهیم کرد... پس نگرانی در مورد ساختار های درونی شبکه و آی پی / دی ان اس / دامین نخواهیم داشت. بنابراین ای پی را می توانید ای پی داخلی یا  localhost  در نظر بگیرید. برای آزمایش پورت فرضی 4000 را در نظر میگیریم و نرم افزار اصلی را روی این پورت اجرا میکنیم :   $ ./server 4000 در این مرحله متوجه می شوید که نرم افزار اصلی با موفقیت اجرا شده است و همچنان اجرا مانده است. بله درست است... نرم افزار اصلی هر لحظه باید منتظر دستور کاربران باشد. اگر لحظه ای برای نرم افزار اصلی اختلالی پیش آید نخواهد توانست دستورات کاربران را انجام یا پاسخ دهد. بنابراین این پردازش را قطع نکنید و اجازه دهید تا نرم افزار اصلی اجرا بماند. در محیط دیگری نرم افزار سمت کاربر را نیز اجرا کنید. این نرم افزار را می توانید به تعداد دلخواه وارد کنید. (همانطور که ممکن است 6 نفر همزمان به سرور متصل باشند / یا ممکن است هیچ فردی به سرور متصل نشوند)   ابتدا یک کاربری را به سرور با پورت 4000 و شبکه داخلی وصل می کنیم :   $ ./client localhost 4000 first user: you can type message here... حال در محیط دیگری با کاربر جدیدی نیز وارد می شویم : $ ./client localhost 4000 second user: you can type message here... در این پروژه نمونه از کاربران نام کاربری یا نام نمی پرسیم.. و صرفا وقتی وارد محیط گفتگو می شوند... یا زمانی که به سرور متصل می شوند منتظر هستیم تا انها پیامی را بنویسند... هر پیامی را که بنویسند به سرور ارسال می شود و سرور وظیفه دارد تا آنرا برای تمام کاربران بفرستد. و این روند درون یک حلقه بی نهایت تکرار می شوند. پس این ارتباط دو طرفه خواهد بود و هم کاربران برای سرور اطلاعات ارسال می کنند و هم سرور برای کاربران اطلاعات ارسال خواهد کرد. در نظر داشته باشید که کاربر اول می تواند پیامی را بنویسد و به کاربران دیگر ارسال شود. ممکن است کاربر سومی اصلا تصمیمی به نوشتن پیام نداشته باشد و صرفا تمایل به خواندن پیام دیگران داشته باشند. و این کاملا اختیاری است. و ما کاربران را اجباری نمیکنیم. اگرچه شما می توانید با خلاقیت خودتان اینها را با متغییر های کمکی و دستورات شرطی پیاده کنید. کد ها برای پیام ها یک ساختار در نظر میگیریم و بصورت مشترک در هر دو نرم افزار استفاده خواهیم کرد... بنابراین اینرا در هدر پیاده خواهیم کرد. هدر پیام : (message.hpp) #ifndef message_HPP #define message_HPP #include <cstdio> #include <cstdlib> #include <cstring> using namespace std; class message { public: enum { headerLength = 4 }; enum { maxBodyLength = 512 }; message() : bodyLength_(0) { } const char* data() const { return data_; } char* data() { return data_; } size_t length() const { return headerLength + bodyLength_; } const char* body() const { return data_ + headerLength; } char* body() { return data_ + headerLength; } size_t bodyLength() const { return bodyLength_; } void bodyLength(size_t new_length) { bodyLength_ = new_length; if(bodyLength_ > maxBodyLength) bodyLength_ = maxBodyLength; } bool decodeHeader() { char header[headerLength + 1] = ""; strncat(header, data_, headerLength); bodyLength_ = atoi(header); if(bodyLength_ > maxBodyLength) { bodyLength_ = 0; return false; } return true; } void encodeHeader() { char header[headerLength + 1] = ""; sprintf(header, "%4d", static_cast<int>(bodyLength_)); memcpy(data_, header, headerLength); } private: char data_[headerLength + maxBodyLength]; size_t bodyLength_; }; #endif نرم افزار اصلی و سرور : (server.cpp) #include <iostream> #include <cstdlib> #include <deque> #include <memory> #include <list> #include <set> #include <utility> #include <boost/asio.hpp> #include "message.hpp" using boost::asio::ip::tcp; using namespace std; typedef deque<message> messageQueue; class participant { public: virtual ~participant() {} virtual void deliver(const message& messageItem) = 0; }; typedef shared_ptr<participant> participantPointer; class room { public: void join(participantPointer participant) { participants.insert(participant); for(auto messageItem: messageRecents) participant->deliver(messageItem); } void deliver(const message& messageItem) { messageRecents.push_back(messageItem); while(messageRecents.size() > max) messageRecents.pop_front(); for(auto participant: participants) participant->deliver(messageItem); } void leave(participantPointer participant) { participants.erase(participant); } private: messageQueue messageRecents; enum { max = 200 }; set<participantPointer> participants; }; class session : public participant, public enable_shared_from_this<session> { public: session(tcp::socket socket, room& room) : socket(move(socket)), room_(room) { } void start() { room_.join(shared_from_this()); readHeader(); } void deliver(const message& messageItem) { bool write_in_progress = !Messages.empty(); Messages.push_back(messageItem); if(!write_in_progress) { write(); } } private: void readHeader() { auto self(shared_from_this()); boost::asio::async_read(socket, boost::asio::buffer(messageItem.data(), message::headerLength), [this, self](boost::system::error_code ec, size_t) { if(!ec && messageItem.decodeHeader()) { readBody(); } else { room_.leave(shared_from_this()); } }); } void readBody() { auto self(shared_from_this()); boost::asio::async_read(socket, boost::asio::buffer(messageItem.body(), messageItem.bodyLength()), [this, self](boost::system::error_code ec, size_t) { if(!ec) { room_.deliver(messageItem); readHeader(); } else { room_.leave(shared_from_this()); } }); } void write() { auto self(shared_from_this()); boost::asio::async_write(socket, boost::asio::buffer(Messages.front().data(), Messages.front().length()), [this, self](boost::system::error_code ec, size_t) { if(!ec) { Messages.pop_front(); if(!Messages.empty()) { write(); } } else { room_.leave(shared_from_this()); } }); } tcp::socket socket; room& room_; message messageItem; messageQueue Messages; }; class server { public: server(boost::asio::io_context& io_context, const tcp::endpoint& endpoint) : acceptor(io_context, endpoint) { do_accept(); } private: void do_accept() { acceptor.async_accept([this](boost::system::error_code ec, tcp::socket socket) { if(!ec) { make_shared<session>(move(socket), room_)->start(); } do_accept(); }); } tcp::acceptor acceptor; room room_; }; int main(int argc, char* argv[]) { try { if(argc < 2) { cerr << "Usage: server <port> [<port> ...]\n"; return 1; } boost::asio::io_context io_context; list<server> servers; for(int i = 1; i < argc; ++i) { tcp::endpoint endpoint(tcp::v4(), atoi(argv[i])); servers.emplace_back(io_context, endpoint); } io_context.run(); } catch (exception& e) { cerr << "Exception: " << e.what() << "\n"; } return 0; } نرم افزار دوم و سمت کاربر : (client.cpp) #include <iostream> #include <thread> #include <cstdlib> #include <deque> #include <boost/asio.hpp> #include "message.hpp" using boost::asio::ip::tcp; using namespace std; typedef deque<message> messageQueue; class client { public: client(boost::asio::io_context& context, const tcp::resolver::results_type& endpoints) : context(context), socket(context) { connect(endpoints); } void write(const message& messageItem) { boost::asio::post(context, [this, messageItem]() { bool write_in_progress = !writeMessage.empty(); writeMessage.push_back(messageItem); if(!write_in_progress) { write(); } }); } void close() { boost::asio::post(context, [this]() { socket.close(); }); } private: void connect(const tcp::resolver::results_type& endpoints) { boost::asio::async_connect(socket, endpoints, [this](boost::system::error_code ec, tcp::endpoint) { if(!ec) { readHeader(); } }); } void readHeader() { boost::asio::async_read(socket, boost::asio::buffer(readMessage.data(), message::headerLength), [this](boost::system::error_code ec, size_t) { if(!ec && readMessage.decodeHeader()) { readBody(); } else { socket.close(); } }); } void readBody() { boost::asio::async_read(socket, boost::asio::buffer(readMessage.body(), readMessage.bodyLength()), [this](boost::system::error_code ec, size_t) { if(!ec) { cout.write(readMessage.body(), readMessage.bodyLength()); cout << "\n"; readHeader(); } else { socket.close(); } }); } void write() { boost::asio::async_write(socket, boost::asio::buffer(writeMessage.front().data(), writeMessage.front().length()), [this](boost::system::error_code ec, size_t) { if(!ec) { writeMessage.pop_front(); if(!writeMessage.empty()) { write(); } } else { socket.close(); } }); } boost::asio::io_context& context; tcp::socket socket; message readMessage; messageQueue writeMessage; }; int main(int argc, char* argv[]) { try { if(argc != 3) { cerr << "Usage: client <host> <port>\n"; return 1; } boost::asio::io_context context; tcp::resolver resolver(context); auto endpoints = resolver.resolve(argv[1], argv[2]); client c(context, endpoints); thread t([&context](){ context.run(); }); char line[message::maxBodyLength + 1]; while(cin.getline(line, message::maxBodyLength + 1)) { message messageItem; messageItem.bodyLength(strlen(line)); memcpy(messageItem.body(), line, messageItem.bodyLength()); messageItem.encodeHeader(); c.write(messageItem); } c.close(); t.join(); } catch (exception& e) { cerr << "Exception: " << e.what() << "\n"; } return 0; }    این پروژه آزمایشی بصورت رایگان و اوپن سورس در اینترنت بخصوص اینجا وجود دارد و می توانید آنرا مستقیما بصورت کامل دانلود کنید.    با تشکر, سید علی محمدیه

Seyyed Ali Mohammadiye

Seyyed Ali Mohammadiye

 

استفاده از MD

زبان نشانه‌گذاری Markdown یا به اختصار MD همانند زبان HTML برای طراحی قالب متن استفاده می‌شود. به گمانم که قبلاً نمونه‌های زیادی را تحت عنوان README.md شنیده‌باشید. مانند نمونهٔ زیر : استفاده از این قالب بسیار ساده‌ است، حال بخشی از نحوهٔ نگارش فایل‌های MD را می‌گوییم.  برای نوشتن سر‌نویس‌ها (Header) : Header1 ======= # Header1 ## Header2 ### Header3 برای "خط‌جدید" (NewLine) از دو کاراکتر Space در انتهای هر پاراگراف استفاده می‌کنیم و یا از دو/n (توسط کلید ReturenKey) استفاده می‌کنیم :  first line. second line. ویژگی‌های متن : _italic_ or *italic* __bold__ or **bold** `monospace` نوشن یک بلاک کد : ```<Language-Name> // And Write Code Here ``` ```c int main (int argc, char **argv, char **envp){ /* some code here */ return EXIT_SUCCESS; } ``` or indent your code by four space: int main (int argc, char **argv, char **envp){ /* some code here */ return EXIT_SUCCESS; } انواع لیست‌ها : Bullet List: * One Option * Another Option Numbered List: 1. Free Software 2. GNU/Linux Todo List: - [x] it's done. - [ ] working on it. نوشتن پیوند‌ها : [GNU/Linux](www.kernel.org) ![Image](https://en.wikipedia.org/wiki/File:Qt_logo_2016.svg) استفاده از حالت "نقل‌قول" : > for using blockquoting in md files. استفاده از جداول : Prorgamming Language | It's God ? ---------------------|------------ C | Very GOD C++ | It's God Python | :(   خروجی تمام نمونه‌های بالا : استفاده از قالب‌های گفته شده، بستگی به پیاده‌سازی موتور رندر ویرایشگری دارد که شما از آن استفاده می‌کنید، چرا که ممکن است تمام قابلیت‌ها را پیاده‌سازی نکرده‌باشد. موفق‌وپیروز باشید. 🌺
 

عیب‌یابی، دیباگ‌کردن با GNU Debugger

بارها بوده که برنامه‌‌ای را نوشته‌ایم، روند کامپایل و اجرا به خوبی و خوشی انجام می‌شود. امّا در مرحلهٔ اجرای برنامه، خروجی‌های نامناسبی پدیدار می‌شود. که متأسفانه چیزی نیستند که ما می‌خواهیم. خب برای حل این مشکل دو راه پیش‌رو می‌باشد : بازبینی کد و انجام تست برای یافتن محل مشکل. استفاده از ابزارهای خطایابی (Debugging). بازبینی کد و انجام تست برای یافتن محل مشکل برای این‌کار فریورک‌ها و کتابخانه‌های زیادی موجود می‌باشد، مثلاً کتابخانهٔ تست‌نویسی (Test Case) به اسم Catch2. کار با این کتاخانه بسیار آسان است. برای مثال تابع زیر را در نظر داشته‌باشید : unsigned int Factorial( unsigned int number ) { return number <= 1 ? number : Factorial(number-1)*number; } ما می‌خواهیم بدانیم که آیا این تابع خروجی مناسب را دارد یا خیر، درصورتی‌که از catch2 استفاده می‌کنید، کافیست که طبق راهنمای README.md هدرفایل catch.cpp را دریافت و به برنامهٔ خود اضافه کنید : #define CATCH_CONFIG_MAIN // This tells Catch to provide a main() - only do this in one cpp file #include "catch.hpp" unsigned int Factorial( unsigned int number ) { return number <= 1 ? number : Factorial(number-1)*number; } TEST_CASE( "Factorials are computed", "[factorial]" ) { REQUIRE( Factorial(1) == 1 ); REQUIRE( Factorial(2) == 2 ); REQUIRE( Factorial(3) == 6 ); REQUIRE( Factorial(10) == 3628800 ); } و بهصورت نمونهٔ کد بالا از catch2 استفاده می‌کنیم. طبق اسناد با تعریف ماکروی CATCH_CONFIG_MAIN ما یک تابع main توسط خود catch2 تعریف می‌کنیم. و کافیه که فقط این سورس را کامپایل و اجرا کنیم : $> g++ -o catch2Test main.cpp $> $> ./catch2Test =============================================================================== All tests passed (4 assertions in 1 test case) و خب مسلماً درصورتی‌که خطایی باشد در این آزمایشات معلوم می‌گردد،‌ فریمورک‌های دیگری مانند Google Test نیز موجود می‌باشد.   استفاده از ابزارهای خطایابی (Debugging) در این روش شما برنامهٔ خود را تحت برنامهٔ دیگری اجرا و اقدام به خطایابی می‌کنید، یکی از برنامه‌های خطایابی معروف و آزاد، برنامهٔ GNU Debugger می‌باشد. از این برنامه برای خطایابی در زبان‌های  : Ada Assembly C ++C D Fortran Go Objective-C OpenCL Modula-2 Pascal Rust استفاده می‌شود. برای نصب می‌توانید از مدیربستهٔ سیستم‌عامل خود استفاده کنید : $> apt install gdb gdb-doc و یا اینکه از این پیوند برنامه را دریافت و اقدام به کامپایل/نصب آن کنید. نکته : دقت کنید که همیشه نباید حتماً خطایی در برنامه باشد تا اقدام به خطایابی کنیم، گاهی هم نیاز است که روند کار برنامه را به این روش با استفاده از ابزارهای مشابه پی‌گیری کنیم. (In fact: reverse engineering) حال اقدام به Debug کردن این برنامهٔ کوتاه می‌نماییم : #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h> static int data = 0x02A; int main (void){ int stack = 0x2FF; pid_t pid; switch (pid = fork()){ case -1: perror("pid = fork()"); exit(EXIT_FAILURE); case 0: data |= 0x02B; stack &= data; break; } fprintf(stdout, "[%s]\v [PID=%ld] [data=%d] [stack=%d].\n", (pid == 0) ? "child" : "parent", (long) getpid(), data, stack); exit(EXIT_SUCCESS); } قبل‌از اینکه برنامه‌ای را برای دیباگ‌ کردن داخل GDB استفاده کنیم،‌ نیاز است که برای کمک به این روند اطلاعاتی مانند مکان Source Code برنامه را به فایل باینری خود اضافه کنیم. برای اینکار کافیست که از فلگ -g یا -ggdb یا -g3 استفاده کنیم. این پیوند را برای اطلاعات بیشتر مطالعه کنید. به این‌صورت برنامه را کامپایل و برای دیباگ کردن آماده می‌کنیم : $> gcc -o output -ggdb main.c توجه کنید که سورس برنامه را از مکانش تغییر ندهید. حال برنامهٔ gdb را با نوشتن اسم gdb در shell فراخوانی می‌کنیم : $> gdb GNU gdb (Debian 8.2.1-2) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) برای اینکه فایل باینری را باز کنیم باید از دستور file استفاده کنیم. همچنین می‌توانیم به این‌صورت نیز برنامهٔ gdb را به همراه فایل باینری خود اجرا نماییم : $> gdb output خب،‌ در این قسمت می‌توانیم با استفاده از دستور run برنامهٔ خودمان را اجرا کنیم و درصورتی‌که نیاز باشد آرگومان‌هایی را نیز ارسال کنیم. وقتی دستور run‌ را وارد می‌کنیم برنامهٔ ما اجرا می‌شود و خاتمه میابد. زمانی‌که نیاز داریم روند اجرای برنامه در نقطه‌های مشخصی متوقف شود باید از ‌Break Point استفاده کنیم. برای قرار دادن Break Point در خط‌های مختلف برنامه از دستور break به اضافهٔ شمارهٔ خط سورس برنامه استفاده می‌کنیم.  برای اینکار بد نیست که اطلاعاتی نیز درمورد سورس‌کد خود داشته‌باشیم مثلاً همزمان بتوانیم سورس را نیز مشاهده کنیم، درصورتی‌که از ادیتور Emacs استفاده می‌کنید می‌توانید M+x را زده و gdb را اجرا کنید. که یک بافر در سمت چپ برای شما باز می‌کند (درصورتی‌که دکمه‌های Ctrl + X و Ctrl + 3 را زده باشید). در غیر این‌صورت به دو روش دیگر می‌توانید سورس خود را هنگام دیباگ مشاهده کنید، در روش اوّل استفاده از دستور list به اضافهٔ دو آرگومان می‌باشد : آرگومان اوّل مشخص کنندهٔ خط شروع است، و آرگومان دوّم مشخص کننده خط پایان هست. مثلاً با فراخوانی list 2, 10 از خط دو تا ده را نمایش می‌دهد : (gdb) list 2, 10 2 #include <stdlib.h> 3 #include <sys/types.h> 4 #include <unistd.h> 5 6 static int data = 0x02A; 7 8 int 9 main (void){ 10 int stack = 0x2FF; می‌توانید فقط یک آرگومان ارسال کنید، که به اندازه ی مقدار متغیر listsize که پیشفرض ده می‌باشد (می‌توانید با استفاده از دستور set مقدار را تغییر دهید) را نمایش می‌دهد : (gdb) list 2 1 #include <stdio.h> 2 #include <stdlib.h> 3 #include <sys/types.h> 4 #include <unistd.h> 5 6 static int data = 0x02A; 7 8 int 9 main (void){ 10 int stack = 0x2FF; حالات دیگه‌ای هم دارد که می‌توانید با وارد کردن help list  متوجه شوید. امّا روش بهتری (روش دوّم) نیز برای دیدن سورس برنامه به همراه دیباگ کردن وجود دارد،‌ می‌توانید از رابط TUI استفاده کنید. برای استفاده از این رابط دکمه‌های Ctrl + X و Ctrl + A یا < وارد کرده و ReturnKey (یا همان Enter) را بزنید. در این قسمت شما به راحتی می‌توانید هم سورس برنامهٔ خودتان را ببینید و هم برنامه را دیباگ کنید. با یک‌بار اجرا کردن برنامه توسط دستور run سورس برنامه‌ٔ شما بارگذاری می‌شود. برویم به سراغ Break Point گذاشتن، برای مثال ما می‌خواهیم یک Break Point بر سر خط ۱۰ و ۱۳ بگذاریم : (gdb) break 11 Breakpoint 1 at 0x555555555185: file main.c, line 13. (gdb) break 10 Breakpoint 2 at 0x55555555517e: file main.c, line 10. (gdb) دوباره برنامه را با وارد کردن دستور run اجرا می‌کنیم، تا اجرای برنامه این‌بار در برخورد با اوّلین Break Point متوقف شود : در این توقف، ما می‌توانیم با استفاده از دستور print محتویات متغیرهارا مشاهده کنیم : (gdb) print data $1 = 42 (gdb) print stack $2 = 21845 دستور print قابلیت‌های جالبی دارد : (gdb) print 12 / 2 $1 = 6 (gdb) print sizeof(int) $2 = 4 (gdb) print &data $3 = (int *) 0x4a60f0 <data> (gdb) مقادیری که به ترتیب در سمت چپ شماره‌گذاری شده‌اند درواقع اسم متغیرهایی هستنند که خروجی در آن قرار گرفته است : (gdb) print $1 $4 = 42 (gdb) print $4 $5 = 42 (gdb) همچنین با استفاده از دستور delete می‌توانیم یک Break Point را حذف کنیم. برای ادامه دادن به روند اجرای برنامه تا Break Point  بعدی از دستور continue و برای رفتن به خط بعدی از دستور next استفاده می‌کنیم.بعد از اجرای دستور next دقت کنید سریعاً به خط 23 رفته و فراخوانی تابع سیستمی fork() را رها می‌کند. به خاطر اینکه دستور next کاری به توابعی که فراخوانی کرده‌اید، در اینجا فراخوان سیستمی fork() ، ندارد و دستورات سورس شما را ادامه می‌دهد؛ امّا درصورتی‌که از step یا stepi استفاده بکنید وارد دستورات شده و دستورات توابع شما را پیمایش می‌کند: (gdb) next [child] [PID=563] [data=43] [stack=43]. [Detaching after fork from child process 563] (gdb) نکته : رابط TUI زیاد قوی نمی‌باشد،‌ لذا درصورتی‌که خروجی چاپ شود تنظیمات صفحه نمایش را به هم می‌زد می‌توانید با زدن Ctrl + L خروجی‌های اضافه را از بین ببرید. برای دیباگ کردن یک fork() می‌توانید مقدار follow-fork-mode را ویرایش کنید : (gdb) set follow-fork-mode child (gdb) run Starting program: /tmp/output Breakpoint 2, main () at main.c:10 (gdb) next Breakpoint 1, main () at main.c:13 (gdb) step [Attaching after process 2387 fork to child process 2403] [New inferior 2 (process 2403)] [Detaching after fork from parent process 2387] [Inferior 1 (process 2387) detached] [Switching to process 2403] main () at main.c:13 (gdb) همچنین با استفاده از دستور disassemble می‌توانید سورس اسمبلی یکی تابع را مشاهده کنید : (gdb) disassmble main Dump of assembler code for function main: 0x0000000000401b4d <+0>: push %rbp 0x0000000000401b4e <+1>: mov %rsp,%rbp 0x0000000000401b51 <+4>: push %rbx 0x0000000000401b52 <+5>: sub $0x18,%rsp => 0x0000000000401b56 <+9>: movl $0x2ff,-0x14(%rbp) 0x0000000000401b5d <+16>: callq 0x43c9b0 <fork> 0x0000000000401b62 <+21>: mov %eax,-0x18(%rbp) 0x0000000000401b65 <+24>: cmpl $0xffffffff,-0x18(%rbp) 0x0000000000401b69 <+28>: je 0x401b73 <main+38> 0x0000000000401b6b <+30>: cmpl $0x0,-0x18(%rbp) 0x0000000000401b6f <+34>: je 0x401b89 <main+60> 0x0000000000401b71 <+36>: jmp 0x401ba2 <main+85> 0x0000000000401b73 <+38>: lea 0x7c48e(%rip),%rdi # 0x47e008 0x0000000000401b7a <+45>: callq 0x408bd0 <perror> 0x0000000000401b7f <+50>: mov $0x1,%edi 0x0000000000401b84 <+55>: callq 0x408010 <exit> 0x0000000000401b89 <+60>: mov 0xa4561(%rip),%eax # 0x4a60f0 <da --Type <RET> for more, q to quit, c to continue without paging-- لینک منبع را برای ادامهٔ داستان دنبال کنید :). موفق و پیروز باشید.🌺
 

کتابخانهٔ Zlib

چندی پیش یکی از دوستان درمورد کتابخانهٔ zlib از من سوأل پرسیده بود که جالب شد برایم تا نگاهی بکنم. zlib یک کتابخانهٔ فشرده‌سازی بر اساس الگوریتم DEFLATE هست که خود این الگوریتم تلفیقی از LZ77 و الگوریتم Huffman هست و عمل فشرده‌سازی‌درحافظه را انجام می‌دهد، اطلاعات بیشتر درمورد اینا خواستید از این‌جا استفاده کنید. این کتابخانه یک قسمت مهم از پلتفرم‌های معروفی همچون GNU/Linux , iOS و.. هست. تستی که با این کتابخانه انجام دادم واقعاً برایم جالب بود، یک فایل متنی ۶۰۰ مگابایتی را به ۱۲۱ مگابایت رسوند در مدّت زمان خیلی کوتاهی با یک پردازندهٔ Intel(R) Core(TM) i7 CPU M 620. خب بریم یک تست بکنیم. اوّل سورس برنامه را از این قسمت بارگیری کنید : https://www.zlib.net/ توضیحات مفصل را می‌خواید می‌توانید از این‌قسمت استفاده کنید. امّا من از یک‌مثال استفاده می‌کنم، بعد از اینکه سورس‌کد را دانلود کردید کافیه که از حالت فشرده خارجش کنید و وارد دایرکتوری مربوطه‌اش بشید. برای کامپایل شما نیاز به : GCC GNU Make دارید، اگر نمی‌دانید GNU Make چی هست، می‌توانید در این‌قسمت با GNU Make آشنا بشید. خب اگر ابتدا برنامهٔ make را داخل دایرکتوری فراخوانی کنید پیغام زیر را نمایش میدهد : Please use ./configure first. Thank you. که مؤدبانه خواهش می‌کند اوّل اسکریپت configure را اجرا کنیم، بعد از اجرای این اسکریپت چک‌های لازم انجام می‌شود و بعد می‌توانید make را اجرا کنید تا کتابخانه‌‌های مورد نظر ساخته بشود. بعد اتمام کار، ما فقط نیاز به Shared lib ها و Header File مربوطه داریم. (درصورتی‌که نمی‌دانید Shared Lib چیست، می‌توانید در این‌قسمت با نحوهٔ‌کار/ساخت آن آشنا شوید). پس بهتر است یک دایرکتوری به اسم lib در ساختار دایرکتوری پروژهٔ خودمان درست کنیم و به این‌صورت عمل کنیم : zlib-1.2.11$> mkdir ../zlibTEST/lib zlib-1.2.11$> mv libz*so* ../zlibTEST/lib renamed 'libz.so' -> '../zlibTEST/lib/libz.so' renamed 'libz.so.1' -> '../zlibTEST/lib/libz.so.1' renamed 'libz.so.1.2.11' -> '../zlibTEST/lib/libz.so.1.2.11' zlib-1.2.11$> mv zlib.h ../zlibTEST/header renamed 'zlib.h' -> '../zlibTEST/header/zlib.h' در این قسمت، اوّل ما خارج‌از دایرکتوری zlib داخل یک دایرکتوری دیگر که پروژهٔ ما درآن قرار دارد یک دایرکتوری به اسم lib ساختیم که shared lib و header file مربوطه را درآن قرار دهیم. سپس تمام فایل‌هایی که به اسم 'libz*so*' هستند را به آن دایرکتوری انتقال دادیم؛ سه فایل قرار دارد که دو تا از آنها به libz.so.1.2.11 لینک شده‌اند.  خب بریم سروقت تست خودمان. اوّل از همه نیاز به هدرفایل‌های مربوطه داریم : #include <stdio.h> #include <string.h> #include <assert.h> #include "zlib.h" کتابخانهٔ zlib از ثابت CHUNK برای مقداردهی Buffer خودش استفاده می‌کنه، و ما نیاز داریم که این ثابت را تعریف کنیم : #define CHUNK 251904 هرچی مقدار بیشتر باشه سیستم کارآمد تر هست، داخل خود اسناد گفته که بهتره از 256k استفاده کنیم درصورتی‌که مقدار حافظهٔ موردنیاز رو داریم. حالا باید تابع Compressing خودمان را با استفاده از کتابخانهٔ zlib پیاده کنیم. ما اسم این تابع را compressing میزاریم، این تابع دو stream دریافت می‌کند که یکی ورودی و یکی خروجی می‌باشد. یک ورودی دیگر تابع سطح فشرده‌سازی هست که در ادامه بحث می‌کنیم : int compressing (FILE *source, FILE *dest, int level); خروجی‌‍ه تابع می‌تواند این موارد باشد : - Z_OK = 0 - Z_STREAM_END = 1 - Z_NEED_DICT = 2 - Z_ERRNO = -1 - Z_STREAM_ERROR = -2 - Z_DATA_ERROR = -3 - Z_MEM_ERROR = -4 - Z_BUF_ERROR = -5 - Z_VERSION_ERROR = -6 از اسامی تقریباً مشخص هست که چه مفهومی دارند و نیازی به توضیح نیست. حال نیاز هست که یک سری متغیر‌های‌محلی که فقط مورد استفادهٔ خود تابع هست را داخل تابع تعریف کنیم : int return_; int flush; int have; z_stream stream; unsigned char input[CHUNK]; unsigned char output[CHUNK]; متغیر اوّل که از اسم‌‍ش مشخص هست، برای مشخص کردن مقداربازگشتی از تابع هست، و متغیر دوّم برای مشخص کردن وضعیّت flushing برای یکی از توابع zlib هست. متغیر سوّم مقدار اطلاعاتی هست که از یکی از توابع zlib به اسم deflate() بر می‌گردد. متغیر چهارم هم از نوع یک ساختار داخلیه zlib می‌باشد : typedef struct z_stream_s { z_const Bytef *next_in; /* next input byte */ uInt avail_in; /* number of bytes available at next_in */ uLong total_in; /* total number of input bytes read so far */ Bytef *next_out; /* next output byte will go here */ uInt avail_out; /* remaining free space at next_out */ uLong total_out; /* total number of bytes output so far */ z_const char *msg; /* last error message, NULL if no error */ struct internal_state FAR *state; /* not visible by applications */ alloc_func zalloc; /* used to allocate the internal state */ free_func zfree; /* used to free the internal state */ voidpf opaque; /* private data object passed to zalloc and zfree */ int data_type; /* best guess about the data type: binary or text for deflate, or the decoding state for inflate */ uLong adler; /* Adler-32 or CRC-32 value of the uncompressed data */ uLong reserved; /* reserved for future use */ } z_stream; توضیحات‌‍َش داده شده داخل خودzlib.h که این ساختار به چه شکلی هست و هر مقدار برای چه کاری هست. و دو متغیر بعدی بافرهای ورودی و خروجی‌ما می‌باشد. کتابخانهٔ zlib از روش تخصیص‌حافظهٔ به خصوص خود استفاده می‌کند، از این رو باید ساختاری که ساخته‌ایم را با استفاده از تابع deflateInit() مقداردهی کنیم، قبل از مقداردهی باید یک‌سری مقادیر را طبق گفتهٔ مستندات برابر Z_NULL قرار بدهیم : stream.zalloc = Z_NULL; stream.zfree = Z_NULL; stream.opaque = Z_NULL; return_ = deflateInit(&stream, *level); if (return_ != Z_OK) return return_; در اینجا مقدار level می‌تواند چیزی بین -1 تا 9 باشد، هرچه مقدار کم‌تر باشد سرعت فشرده‌سازی بالاتر است و مقدارفشرده‌سازی کم‌تر. مقدار صفر هیچ فشرده‌سازی‌ای انجام نمی‌شود و صرفاً یک فایل با فرمت zlib درست می‌شود. ماکروی Z_DEFAULT_COMPRESSION برابر با -1 هست که سرعت و فشره‌سازی خوبی را فراهم کند.  در تست قبلی خودم مقدار را برابر Z_DEFAULT_COMPRESSION گذاشتم و این‌بار می‌خواهم برابر ۹ بگذارم. خب حالا باید بریم سراغ فشرده‌سازی، در این قسمت ما یکdo-while می‌نویسیم که جریان‌ورودی را تا EOF (انتهای فایل) بخواند : do{ stream.avail_in = fread(input, 1, CHUNK, source); if (ferror(source)){ deflateEnd(&stream); return Z_ERRNO; } flush = feof(source) ? Z_FINISH : Z_NO_FLUSH; stream.next_in = input; * خب برای دوستانی که با توابع کار با Streamها در سی آشنا هستند، پیشنهاد می‌کنم که این قسمت رو یه‌کمی ازش گذر کنند. اوّل ما از تابع fread استفاده کردیم، این تابع به این‌صورت در فایل stdio.h تعریف شده است : size_t fread( void *restrict buffer, size_t size, size_t count, FILE *restrict stream ); و کاری که می‌کند این است که اوّل یک اشاره‌گر به جایی که باید داده‌‌های خوانده شده ذخیره بشوند می‌گیرید که اینجا ما آرایهٔ input را می‌دهیم، سپس اندازهٔ هر داده‌ای که قرار است خوانده بشود را دریافت می‌کند که یک بایت است هر کاراکتر، آرگومان بعدی مقداری است که باید از Stream خوانده شود که ما به اندازهٔ CHUNKتا می‌خواهیم :). آرگومان آخری نیز که مشخص‌هست. جریانی است که باید داده‌ها خوانده شود. این تابع مقدار داده‌هایی را که با موفقیت خوانده‌است را برمی‌گرداند. که ما آن را در stream.avail_in نگه‌داری می‌کنیم. سپس باید Stream را چک کنیم که خطایی رخ نداده باشد. درصورتی‌که این تابع مقداری غیراز صفر برگرداند مشخص است که خطایی رخ نداده. و درصورتی‌که خطایی رخ داده‌باشد با استفاده از delfateEnd() جریان را پایان می‌دهیم.  و در انتها باید بررسی کنیم که آیا جریان‌ما به EOF (پایان فایل) رسیده‌است یا خیر. که اینکار با استفاده از تابع feof() در هدرفایل stdio.h صورت می‌گیرد. درصورتی‌که پایان‌فایل رسیده باشد مقداری غیر از صفر این تابع بر می‌گرداند. در انتها طبق گفتهٔ مستندات باید اشاره‌گری به داده‌های خوانده شده در next_in قرار بگیرد. که ما اینکار را در خط آخر انجام داده‌ایم. خب در این‌قسمت که ما داده‌ها را از جریان ورودی خواندیم نیاز هست که با استفاده از تابع deflate() عمل فشرده‌سازی را انجام دهیم. این تابع داخل یک حلقهٔ do-while دیگر فراخوانی می‌شود. و تا انتهای داده‌های خوانده شده ادامه می‌دهیم : do{ stream.avail_out = CHUNK; stream.next_out = output; مقدار فضای output‌ما که برای deflate() تهیه شده است توسط avail_out به بایت مشخص می‌‌شود و next_out اشاره‌گری به آن جریان خروجی می‌باشد که در اینجا آرایهٔ output می‌باشد.  خب حالا ما باید تابع فشرده‌سازی deflate() را فراخوانی کنیم. این تابع به اندازهٔ avail_in بایت از next_in پردازش می‌کند و به اندازهٔ avail_out بایت در next_out می‌نویسد. که اینجا مقادیر avail_out/in ما برابر با CHUNK می‌باشد و next_out/in ما به  آرایه‌های input و output اشاره‌ می‌کند. این حلقهٔ داخلی‌که درست کردیم تضمین می‌کند که تمام داده‌های خوانده‌شده پردازش و نوشته می‌شوند. ورودی‌های تابع deflate() یک اشاره‌گر به ساختار z_stream می‌باشد (همان متغیر stream خودمان) و یک ورودی دیگر که مشخص می‌کند وضعیت و چگونگی flush کردن داده‌ها در output. تابع deflate() تا زمانی‌که مقدار ورودی flush state برابر Z_NO_FLUSH باشد ادامه می‌دهد و وقتی‌که مقدار flush state برابر Z_FINISH تابع deflate() کار را تمام می‌‌کند. این قسمت برای افرادی هست که می‌خواهند کارهای خاصی با این تابع انجام دهند که بدین منظور بهتر است مستندات فنی کتابخانه را مطالعه کنند. return_ = deflate(&stream, flush); assert(return_ != Z_STREAM_ERROR); در اینجا ما با استفاده از ماکروی assert که در هدرفایل assert.h تعریف شده است یک شرط می‌گذاریم که درصورتی‌که آن شرط حاصل‌‍ش برابر صفر باشد مقادیری را در stderr چاپ و با استفاده از abort() برنامه را خاتمه می‌دهد. خب حالا باید مشخص کنیم که تابع ‌deflate() در آخرین فراخوانی چه مقدار خروجی تولید کرده‌است و چه مقدار باقی‌مانده است. و مقادیر تولید شده را داخل جریان خروجی می‌نویسیم : have = CHUNK - stream.avail_out; if (fwrite(output, 1, have, dest) != have || ferror(dest)) { deflateEnd (&stream); return Z_ERRNO; } در اینجا ما با استفاده از تابع fwrite (که ورودی‌های آن مشابه fread می‌باشند) مقدار تولید شده را داخل جریان خروجی می‌نویسیم. این تابع باید تعداد مقادیری که با موفقیت نوشته شده‌اند را به بایت بر گرداند. پس بررسی می‌کنیم که اگر برابر با have نبود یا اینکه برای جریان dest خطایی رخ داده است. برنامه را خاتمه دهد. تابع deflate() تا جایی که بتواند به کارخود ادامه می‌دهد و زمانی که دیگر داده‌ای برای پردازش نداشته‌باشد مقدار avail_out برابر صفر قرار می‌گیرد و مقدار Z_BUF_ERROR را بر می‌گرداند. و ما می‌توانیم از حلقهٔ داخلی خارج شویم : } while (stream.avail_out == 0); assert(stream.avail_in == 0); خب ما با بررسی متغیر flsuh می‌توانیم وضعیت پایان فایل را متوجه بشویم، درصورتی‌که مقدار این متغیر برابر Z_FINISH باشد کار ما تمام شده‌است و می‌توانیم از حلقه خارج شویم : } while (flush != Z_FINISH); assert(return_ == Z_STREAM_END); و در انتها کافی است که حافظه‌ای که دریافت شده آزاد شود، و مقدار Z_OK از تابع برگرداننده شود : deflateEnd(&stream); return Z_OK; }   خب تابع compress ما به اتمام رسید، حال باید بریم سروقت تابع decompress،‌ این تابع شباهت بسیار زیادی به تابع قبلی دارد : int decompress (FILE *source, FILE *dest); و حالا متغیر‌های‌محلی را دوباره تعریف می‌کنم، اینجا دیگر نیازی به متغیر flush نیست چرا که خود توابع zlib پایان کار را مشخص می‌کنند : { int return_; unsigned have; z_stream stream; unsigned char input[CHUNK]; unsigned char output[CHUNK]; و حال نیاز هست که زمینهٔ تخصیص حافظه را فراهم کنیم : stream.zalloc = Z_NULL; stream.zfree = Z_NULL; stream.opaque = Z_NULL; stream.avail_in = 0; stream.next_in = Z_NULL; return_ = inflateInit(&stream); if (return_ != Z_OK) return return_; اینجا مقدار avail_in برابر صفر و مقدار next_in برابر Z_NULL قرار می‌گیرد تا مشخص شود که هیچ ورودی فراهم نشده است. حالا باید حلقهٔ معروف خودمان را درست کنیم و با استفاده از تابع inflate() اقدام به Decompressing کنیم : do { stream.avail_in = fread(input, 1, CHUNK, source); if (ferror(source)){ inflateEnd(&stream); return Z_ERRNO; } if (stream.avail_in == 0) break; stream.next_in = input; خب با توجه به توضیحات تابع قبلی این دستورات نیز عملکردشان مشخص است. حال باید حلقهٔ‌داخلی را بنویسیم : do { stream.avail_out = CHUNK; stream.next_out = output; حال باید تابع inflate() را برای عمل Decompressing فراخوانی کنیم، دیگر اینجا نیازی  به مشخص کردن flush state نداریم چرا که خود zlib به طور خودکار مدیریت می‌کند. تنها چیزی که مهم است، خروجی تابع inflate() می‌باشد که درصورتی‌که برابر Z_DATA_ERROR باشد به معنی این‌است که در داده‌های فشرده‌شده مشکلی وجود دارد. و خروجی دیگر Z_MEM_ERROR می‌باشد که مشخص‌کنندهٔ مشکلی در زمان حافظه‌گیری برای inflate() می‌باشد : return_ = inflate(&stream, Z_NO_FLUSH); assert(return_ != Z_STREAM_ERROR); switch (return_){ case Z_NEED_DICT: return_ = Z_DATA_ERROR; case Z_DATA_ERROR: case Z_MEM_ERROR: inflateEnd(&stream); return return_; } در اینجا خروجی تابع را بررسی کرده و درصورتی‌که خطایی باشد جریان برنامه را خاتمه می‌دهیم.   و انتهای حلقه : have = CHUNK - stream.avail_out; if (fwrite(output, 1, have, dest) != have || ferror(dest)) { inflateEnd(&stream); return Z_ERRNO; } } while (stream.avail_out == 0); و زمانی‌که خروجی‌‍ه inflate() برابر Z_STREAM_END باشد، یعنی اینکه دیگر کار تمام شده و داده‌ای برای پردازش نمی‌باشد : } while (return_ != Z_STREAM_END); تا این قسمت دیگر کار استخراج به پایان رسیده‌ است . و کار تابع decompress را تمام می‌کنیم : inflateEnd(&stream); return (return_ == Z_STREAM_END) ? Z_OK : Z_DATA_ERROR; }   خب تمام شد !. ما دوتابع compress و decompress که مستقیم از zlib استفاده می‌کنند را به پایان رساندیم. حال بیاید از آنها استفاده کنیم. در وهلهٔ اوّل نیاز است که تابعی داشته‌باشیم تا خروجی این توابع را برای ما مدیریت کنند : void zlibError(int return_) { fprintf(stderr, "ZLIB ERROR: "); switch (return_) { case Z_ERRNO: if (ferror(stdin)) fprintf(stderr, "ERROR READING stdin.\n"); if (ferror(stdout)) fprintf(stderr, "ERROR WRITING stdout.\n"); break; case Z_STREAM_ERROR: fprintf(stderr, "INVALID COMPRESSION LEVEL.\n"); break; case Z_DATA_ERROR: fprintf(stderr, "INVALID OR INCOMPLETE deflate() DATA.\n"); break; case Z_MEM_ERROR: fprintf(stderr, "OUT OF MEMORY.\n"); break; case Z_VERSION_ERROR: fprintf(stderr, "zlib VERSION MISMATCH.\n"); } } و حال تابع main برنامهٔ ما : int main(int argc, char **argv) { int return_; if (argc == 1) { return_ = compress(stdin, stdout, 9); if (return_ != Z_OK) zlibError(return_); return return_; } else if (argc == 2 && strcmp(argv[1], "-d") == 0) { return_ = decompress(stdin, stdout); if (return_ != Z_OK) zlibError(return_); return return_; } else { fprintf(stderr, "zlib Usage: PROGRAMM [-d] < SOURCE > DEST\n"); return EXIT_FAILURE; } return EXIT_FAILURE; } و برای کامپایل باید موقعیت کتابخانهٔ zlib را مشخص کنیم : $> gcc main.c -L. -lz -O3 -o zlib خب حالا بیاید با هم این برنامه را اجرا کنیم :). قبل از اجرا نیاز است که ما یک فایل حجیم داشته‌باشیم، برای اینکار کافیه که به این‌صورت یکی درست کنیم : $> yes "iostram.ir" > huge.file بهتر از بعد از چند ثانیه با استفاده از Ctrl + C برنامه را خاتمه دهید، برای من بعد از ۱۱ ثانیه برنامهٔ yes فایلی به اندازهٔ ۶۲۹ مگابایت، محتوی iostream.ir درست کرد. حالا بریم برای فشرده‌سازی  : $> time ./zlib < huge.file > huge.file.comp real 0m13.560s user 0m5.785s sys 0m0.375s من این برنامه با استفاده از برنامهٔ time اجرا کردم تا زمان مصرفی را مشاهده کنم، که بعد از ۱۳ ثانیه به اتمام رسید. حال بیاید بیبنیم حجم خروجی چقدر است ! $> ls -ltrh total 631M -rw-r--r-- 1 ghasem ghasem 94K Jan 15 2017 zlib.h -rwxr-xr-x 1 ghasem ghasem 119K May 10 10:59 libz.so.1.2.11 lrwxrwxrwx 1 ghasem ghasem 14 May 10 10:59 libz.so.1 -> libz.so.1.2.11 lrwxrwxrwx 1 ghasem ghasem 14 May 10 10:59 libz.so -> libz.so.1.2.11 -rw-r--r-- 1 ghasem ghasem 3.5K May 10 14:39 main.c -rwxr-xr-x 1 ghasem ghasem 18K May 10 14:40 output -rwxr-xr-x 1 ghasem ghasem 18K May 10 14:46 zlib -rw-r--r-- 1 ghasem ghasem 629M May 10 14:46 huge.file -rw-r--r-- 1 ghasem ghasem 1.3M May 10 14:47 huge.file.comp واقعاً عالی بود. حجم فایل خروجی برابر با 1.3 مگابایت است. یعنی یک مگابایت و ۳۰۰ کیوبایت. حال بیاید از حالت فشرده خارج کنیم فایل را : $> time ./zlib -d < huge.file.comp > huge.file.dcomp real 0m12.556s user 0m0.818s sys 0m0.472s بعد از تنها ۱۳ ثانیه یک فایل ۶۲۹ مگابایتی برایمان درست کرد. که عیناً برابر فایل اوّلی می‌باشد. باور نمی‌کنید ؟ خب بیاید sha1sum آنها برررسی کنیم : $> sha1sum huge.file 3c02d5bd13b91f0e663d63d11ee33a2e71126615 huge.file $> sha1sum huge.file > huge.file.sha1 $> sha1sum huge.file.dcomp > huge.file.dcomp.sha1 $> cat huge*.sha1 3c02d5bd13b91f0e663d63d11ee33a2e71126615 huge.file.dcomp 3c02d5bd13b91f0e663d63d11ee33a2e71126615 huge.file سورس کامل برنامه را از این‌قسمت می‌توانید بارگیری کنید.   - موفق‌وپیروز باشید 🌺

قاسم رمضانی منش

قاسم رمضانی منش

 

کتابخانه‌های استاتیک و داینامیک (پویا)

توضیحات موردنیاز، قبلاً در این‌پیوند داده شده. حال بیاید ببینیم در عمل چگونه‌است ؟ Static Library یا کتابخانه‌های استاتیک :         معمولاً تحت عنوان Archives هم شناخته می‌شوند، یک Static Library شامل مجموعه‌ای از Object-Fileها هست. Object-Fileها سورس‌های کامپایل‌ شدهٔ ما به زبان‌ماشین هستند. این فایل‌ها قابل اجرا نیستند چراکه هنوز کتابخانه‌های موردنیازشان Link نشده. برای کامپایل به‌صورت Object-File از فلگ -c استفاده می‌کنیم : $> cc -c func.c $> cc -c main.c $> cc *.o -o output در اینجا ما سورس‌کدهای func.c و main.c را فقط کامپایل کردیم و بعد (در خط سوّم) Object-Fileها را به کامپایلرمان دادیم تا عمل لینک کردن کتابخانه‌ها و خروجی‌نهایی را تولید کند. برای ساخت Static Library ما از Object-File‌ها به همراه برنامهٔ ar استفاده می‌کنیم، به این‌صورت که اوّل Object-Fileها را تولید می‌کنیم : $> cc -c func1.c $> cc -c func2.c و حالا یک کتابخانه متشکل از Object-Fileها برای ساخت Static-Libraryمان خروجی می‌گیریم : $> ar rcs libfunc.a func1.o func1.o خب ! در این قسمت دو نکتهٔ کوچک و مهم وجود دارد : فایل‌هایی که با استفاده از فلگ -c کامپایل می‌کنید، خروجی‌حاصل فایلی با همان نام فایل ورودی به همراه پسوند .o می‌باشد. اسم کتابخانهٔ شما باید به‌صورت lib*.(a|os) باشد. و این‌چیزی هست که Linker به دنبال آن برای لینک‌کردن می‌گردد. برای کتابخانه‌های‌استاتیک ما از پسوند .a استفاده می‌کنیم و برای کتابخانه‌های‌داینامیک از .so . حال برای استفاده از این کتابخانه‌ما نیاز به دوکار کوچک داریم هنگام کامپایل نهایی داریم : $> cc main.c -L. -lfunc -o output فلگ -L برای مشخص کردن دایرکتوری‌ای که کتابخانهٔ ما در آن قرار دارد استفاده می‌شود. (میدانیم که در UNIX هر دایرکتوری دارای دو لینک می‌باشد؛ یک . (dot) که اشاره به دایرکتوری جاری دارد و.. (dot-dot) که اشاره به دایرکتوری-پدر (parent-directory یا دایرکتوری بالایی دارد). فلگ -l برای مشخص کردن اسم کتابخانهٔ ما استفاده می‌شود، دیدید که ما فقط اسم func را آوردیم، چرا که خود تصور می‌کند اوّل اسم فایل lib و پسوند آن .a یا .so می‌باشد. یک نمونهٔ عملی را می‌توانید از این‌قسمت امتحان کنید : در این مثال از GNU Make استفاده شده است، درصورتی‌که آشنایی ندارید می‌توانید از این‌قسمت با GNU Make آشنا بشوید. امّا نکته‌ای که قابل ذکر هست : در این‌جا شما فقط کتابخانه‌ای که خودتان نوشتید را به‌صورت Static لینک کردید، کتابخانه‌هایی مثل glibc به‌صورت خودکار درحالت Dynamic لینک می‌شوند.   Shared Library یا کتابخانه‌ داینامیک :         در این روش بازهم ما نیاز به Object-Fileهای سورس‌کد‌ها داریم، با تفاوت اینکه باید فلگ -fPIC یا -fpic را اضافه کنیم که به معنی Position-independent Code می‌باشد؛ می‌دانید که Shared Libraryها یک‌بار فقط در حافظه بارگذاری می‌شوند از این رو نیاز است که سورس‌کدماشینی که تولید می‌شوند وابسته به این نباشد که در جای به خصوصی از حافظه بارگذاری شود. خب Object-Fileها را به صورت PIC کامپایل می‌کنیم : $> cc -c -fPIC add.c $> cc -c -fPIC sub.c حال باید کتابخانهٔ‌اشتراکی خود را با استفاده از فلگ -shared ایجاد کنیم : $> cc -shared add.o sub.o -o libmat.so در اینجا ما از فلگ -shared استفاده کردیم و Object-Fileهای تولیدشده را به عنوان ورودی وارد کرده‌ایم. و حالا می‌توانیم از shared library خودمان استفاده کنیم : $> cc main.c -o output -L. -lmath حال بیاید برنامه را اجرا کنیم : $> ./output ./output: error while loading shared libraries: libmat.so: cannot open shared object file: No such file or directory چرا ؟ به خاطر اینکه linker در آدرس‌های تعریف شده به دنبال کتابخانهٔ‌اشتراکی libmat.so می‌گردد. راه‌های مختلفی برای مشخص کردن مسیر کتابخانهٔ خودمان وجود دارد.  انتقال کتابخانهٔ خود به آدرس /usr/lib دستکاری LD_LIBRARY_PATH  ... راه‌های مختلف را می‌توانید از لینک‌های زیر دنبال کنید : https://renenyffenegger.ch/notes/development/languages/C-C-plus-plus/GCC/create-libraries/index https://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html موفق‌وپیروز باشید 🌺.  

قاسم رمضانی منش

قاسم رمضانی منش

 

چگونه روند پیشرفت پروژه را کنترل کنیم ؟ کنترل‌ورژن یا Git چیست ؟

فایل‌ها/تغییرات پروژه را چطوری کنترل کنیم ؟ در وهلهٔ اوّل شاید بگید چه نیازیه ؟ خب برنامه رو می‌نویسیم و میریم دیگه !. درسته برنامه‌اتون را می‌نویسید و می‌روید؛ امّا به کجا چنین شتابان ؟ آیا همیشه برنامهٔ شما کوچک‌خواهد بود ؟ آیا قراره برنامهٔ شما در صد خط تمام بشه ؟ یا اینکه کلاً قصد توسعه‌اش رو دیگه ندارید ؟ خب شاید یکی دیگه داشت :). فرض کنید برنامهٔ‌تان را نوشتید : void parsing(int argc, char **argv){ top = 0; for (unsigned i=1; i < (unsigned)argc; i+=2){ listArgs[top].name = argv[i]; listArgs[top].value = argv[i+1]; top++; } } خب، برنامه‌کار می‌کنه و میرید و یک هفته‌ٔ دیگه میاید و مثلاً خط : top = 0; را حذف می‌کنید. و برنامه در اجرای اوّل درست کار می‌کنه؛ پیش‌خودتون می‌گید خب چه نیازی بود، الکی ماهم کد نوشتیم :). امّا بعداً در اجراهای متوالی برنامه شروع می‌کنه به دادن خروجی‌های نامتعارف. اینجاس که باید ساعت‌ها وقت بزارید و بگردید ببینید آخرین‌بار چه چیزی رو تغییر دادید و کدوم فایل را ویرایش کردید. کار مسخره‌ و اعصاب‌خورد کنی میشه، درسته ؟. امّا برای مدیریت این دَنگٌ‌وفَنگ‌ها می‌تونید از سیستم‌های‌مدیریتپروژه‌ استفاده بکنید. مثل Git حالا اینکه چرا گیت ؟ به خاطر اینکه راحت‌ترینه و بهترینه. چرا ؟ چون امتحانش را پس داده، پروژهٔ بزرگ "کرنل‌لینوکس" را داره مدیریت می‌کنه. حالا بیاید ببینیم اگه ما ازت گیت (git) استفاده می‌کردیم، چطوری می‌توانستیم بفهمیم که چه بلایی سر کد آمده : ۱- اوّل گزارشات را چک می‌کنم، تا ببینم آخرین گزارشی که از تغییرات ذخیره کردم چه بوده ؟: $> git log commit bb513a5f9ec429222de03afa690e7fa5d2fbdf6e (HEAD -> master) Author: Ghasem Ramezani <g1999ramezani@gmail.com> Date: Sun May 5 00:05:22 2019 +0430 create a bug commit ab176fa8a282a74e6badfc285c0986bc66ee6b7d (origin/master, origin/HEAD) Author: Ghasem Ramezani <g1999ramezani@gmail.com> Date: Sat May 4 10:40:32 2019 +0430 make `top` to be 0 at first of parsing() function and make class storage of listArgs to be `extern` and getOption() function return "NULL" on Failure. خب فهمیدم که آخرین تغییرم با عنوان create a bug ثبت شده، حالا باید از شناسه‌اش استفاده کنم. ۲- تغییراتی که در آن گزارش ثبت شده است را مشاهده می‌کنم. : $> git show bb513a5f9ec429222de03afa690e7fa5d2fbdf6e commit bb513a5f9ec429222de03afa690e7fa5d2fbdf6e (HEAD -> master) Author: Ghasem Ramezani <g1999ramezani@gmail.com> Date: Sun May 5 00:05:22 2019 +0430 create a bug diff --git a/source/arg.c b/source/arg.c index c776ff2..a75c91d 100644 --- a/source/arg.c +++ b/source/arg.c @@ -7,7 +7,6 @@ unsigned top=0; struct ARGS listArgs[MAX_ARG]; void parsing(int argc, char **argv){ - top = 0; for (unsigned i=1; i < (unsigned)argc; i+=2){ listArgs[top].name = argv[i]; listArgs[top].value = argv[i+1];   دیدی به چه سادگی توانستیم تغییری که دادیم را پیدا کنیم ؟ البته این انتهای ماجرا نیست ! الآن که متوجه شدیم در کدام گزارش‌ما خراب‌کاری کردیم؛ کافیه که تغییرات را به گزارش قبل از خراب‌کاری برگردانیم : $> git reset --hard ab176fa8a282a74e6badfc285c0986bc66ee6b7d البته قابل ذکره که ما اینجا تنها داخل این گزارش فقط یک تغییر داشتیم، مسلماً کار می‌تونه کمی پیچیده‌تر بشه اگه تغییرات زیاد باشن، که همیشه هستن 🙂.   چگونه با گیت (git) کار کنیم ؟ بسیار ساده، مسلماً اوّل نیاز دارید که این برنامه را نصب کنید. این برنامه به طور پیش‌فرض در سیستم‌عاملتون نصب نیست. کافیه که از مدیربستهٔ سیستم‌عاملتون کمک بگیرید، مثلاً برای Debian - Ubuntu - Ubuntu Mint به این‌صورت کار تمام می‌شود : $ apt install git حالا بعد از نصب، نیاز دارید که مشخصاتتان را ثبت کنید، دقت کنید که تمام توضیحاتی که بنده می‌دهم را می‌توانید به‌صورت کامل‌تر از سایت گیت (git) دنبال کنید. $> git config --global user.name "Ghasem Ramezani" $> git config --global user.email "g1999ramezani@gmail.com" $> git config --global core.editor emacs دو مورد اوّل که واضح هستن، امّا مورد آخر دل‌بخواه خودتان هست، زمانی‌که نیاز باشه گیت (git) ویرایشگرمتنی را جهت ویرایش‌باز بکند باید بداند که کدام ویرایشگر مورد علاقهٔ شماست. می‌توانید هر برنامه‌ای را قرار بدهید. امّا دقت کنید که بهترین ویرایشگر‌ها می‌توانند Vim, Emacs, Notepad++ باشند؛ فایل این تنظیمات را می‌توانید از این مسیرها دنبال کنید : User Space : ~/.gitconfig System Wide: /etc/gitconfig   ساخت مخازن (repository) خب حالا که نصب/پیکربندی انجام شد، کافیه که مخزن (repository) خودمان را راه‌اندازی کنیم. یک پروژهٔ جدید درست کنید و گیت (git) را مقداردهی (Initialize) کنید : $> mkdir project ; cd project $> git init ما یک دایرکتوری به اسم project درست کردیم، و مخزن (repository) خودمان را با دستور git init راه‌اندازی کردیم، یک سری فایل‌هایی گیت (git) برای ما داخل آن دایرکتوری با اسم .git درست کرده.   تغییراتی‌که نیاز رو انجام میدیم، مثلاً در وهلهٔ اوّل دایرکتوری‌ها و فایل‌های پروژه را راه‌اندازی می‌کنیم : $> mkdir header source build object $> touch header/arg.h source/arg.c Makefile $> tree . ├── build ├── Makefile ├── header │   └── arg.c ├── object └── source └── arg.h 4 directories, 3 files $> اگه درمورد Makefile نمی‌دانید، می‌توانید از اینجا با GNU Make و Makefile آشنا بشید. الآن بد نیست که خروجی دستور git status را ببینیم تا توضیحاتی در این‌باره بدیم (این دستور، وضعیت‌جاری مخزنمان را نشان می‌دهد) : $> git status On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) Makefile header/ source/ nothing added to commit but untracked files present (use "git add" to track) عکس زیر را مشاهده‌کنید تا توضیح‌بهتری بدم : فایل‌های شما داخل گیت (git) دارای حالات‌های مختلفی‌هستن، به طورکلّی یا شناخته‌شدن‌اند (tracked) یا ناشناخته‌اند (untracked)؛ فایل‌ها/دایرکتوری‌هایی که ما بعد از مقدار‌‌دهی مخزن‌مان ساختیم، در حالت ناشناخته (untracked) هستند. که خود گیت (git) هم همین‌را به ما گفته‌است : Untracked files: (use "git add <file>..." to include in what will be committed) برای اینکه شناخته‌شده (tracked) بشند، باید آنها را به صحنه (stage) ببریم. برای اینکار خود گیت گفته‌است که باید چه کرد که می‌توانیم به دوصورت انجام دهیم : $> git add Makefile source header $> git add -A خب  حالا دوباره خروجی git status را نگاه می‌کنیم : $> git status On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: Makefile new file: header/arg.c new file: source/arg.h الآن فایل‌های ما به stage رفتند، و آمادهٔ این‌هستند که گزارش‌ (commit) بشوند. دقت کنید که Git از خِیر دایرکتوری‌های خالی می‌گذرد. حالا کافیه‌که ما تغییراتی که دادیم را گزارش کنیم، که با دستور git commit به دوصورت انجام می‌شود : $> git commit $> git commit -m "My Message" در حالت‌اوّل، گیت ادیتور پیش‌فرضتان را باز می‌کند و از شما می‌خواهد که یک توضیح‌کوتاه درمورد تغییراتی‌که داده‌اید بنویسید، در حالت‌دوّم، شما مستقیم توضیح‌کوتاه خود را وارد می‌کنید. حال دوباره برگردیم و خروجی دستور git status را ببینیم : $> git status On branch master nothing to commit, working tree clean خیلی‌هم عالی، این نشان دهندهٔ این‌است که ماهیچ فایل ناشناخته (َUntracked) یا دستکاری‌شده (Modified) یا درصحنه (Stage) نداریم. هنگامی‌که تغییراتی را در فایل‌های شناخته‌شده (Tracked) بدید، آن فایل از حالت دستکاری‌نشده (Unmodified) به حالت دستکاری‌شده (Modified) درمیاید، که نیاز است شما تغییرات را درصورت‌نیاز وارد صحنه (Stage) کنید و بعد گزارش‌کنید (Commit). حال تغییراتی‌اعمال می‌کنیم، و مراحل‌مورد نیاز تا درصحنه (Stage) بردن‌فایل‌ها انجام می‌دهیم : $> git add -A $> git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: Makefile modified: header/arg.h modified: source/arg.c امّا شاید شما نخواید که مثلاً Makefile گزارش‌‍ش با مابقیه فایل‌ها یکی باشه، و نیاز دارید که از Stage بیرون بیاریدش؛ دقّت کنید خود Git هم راهنمایی‌ کرده که باید چه‌کار کرد : $> git reset HEAD Makefile $> git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: header/arg.h modified: source/arg.c Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: Makefile و حالا می‌توانید به راحتی گزارش فایل‌های خودتان را برای header/arg.h و source/arg.c بنویسید : $> git commit -m "Done With Print() Function"   فایل .gitignore بیاید تا make را اجرا کنیم (درصورتی‌که با GNU Make آشنا نیستید، برای آشنایی این‌قسمت را مطالعه کنید) : $> git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: Makefile Untracked files: (use "git add <file>..." to include in what will be committed) build/ object/ no changes added to commit (use "git add" and/or "git commit -a") اینجا دایرکتوری‌های build و object هم اضافه شدند،امّا ما نیازی نداریم که Git این دایرکتوری‌ها را مدیریت کند، پس کافیه که یک فایل به اسم .gitignore‌ درست کنیم. و فایل‌ها و دایرکتوری‌هایی که نمی‌خواهیم Git آنها را دنبال کند را در آن ذکر کنیم : $> echo -e "/build/*\n/object/*" > .gitignore $> cat .gitignore /build/* /object/ $> git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: Makefile Untracked files: (use "git add <file>..." to include in what will be committed) .gitignore no changes added to commit (use "git add" and/or "git commit -a") و مشاهده می‌کنید که دیگر Git اخطاری برای دایرکتوری‌های build‌ و object نداد.   خب دوستان،امیدوارم دلیل اهمیّت Git و کلاً برنامه‌های کنترل‌ورژن را درک‌کرده باشید؛ امّا شرمنده، دنیای Git بزرگ‌تر از آنچه هست که من بخوام خلاصه‌ای از هر قسمت را در یک پست باز‌گو کنم؛ شدیداً پیشنهاد می‌کنم که این‌کتاب را برای فراگیری هرچه بهتر Git‌ بخوانید. - موفق و پیروز باشید. 🌺

قاسم رمضانی منش

قاسم رمضانی منش

 

بیلد سیستم یا Make چیست ؟

خب ! Build System چیست ؟ تمام برنامه‌هایی که می‌نویسیم، معمولاً یک main.c دارند که نقطهٔ‌شروع (start point) برنامهٔ‌ما هست. آیا همیشه همین یک فایله ؟ آیا همیشه نیازه که به یک‌صورت برنامه‌ را کامپایل کنیم ؟ خب مسلماً جواب "نه" هست. چرا که ممکنه برنامهٔ شما دارای ده‌ها فایل داشته‌باشه، و نیاز داشته‌باشید که هر فایل رو به صورت‌خاصی با فلگ‌های خاصی کامپایل‌کنید. اینجاس که "بیلد سیستم‌"ها وارد کار میشوند.  به احتمال زیاد نمونه‌های زیادی مشاهده کردید که وقتی یک سورسی‌را (source) از مخازن آنلاین گیت، مثل گیت‌هاب یا گیت‌لب دریافت می‌کنید در فایل‌ راهنما (README.md) در بخش Build نوشته که وارد دایرکتوری بشید و دستور make و بعد make install را وارد کنید، دقیقاً کاری که می‌کنید اینکه برنامهٔ GNU Make را صدا می‌زنید که فایل تنظیمات رو از دایرکتوری جاری بخواند و دستورات تعیین شده رو انجام بده، این دستورات در فایلی به نام Makefile‌ نوشته میشود.   نصب کردن GNU Make این برنامه معمولاً روی تمام سیستم‌عامل‌های معقول مثل GNU/Linux یا اقوام BSD نصب هست، درصورتی‌که نبود می‌توانید با استفاده از مدیربسته‌ٔ سیستم‌عاملتون اقدام به نصب کنید، مثلاً برای نصب روی سیستم‌عامل Debian - Ubuntu - Ubuntu Mint می‌توانید به این‌صورت عمل کنید : $> apt install make   چه کنیم با GNU Make ؟ اوّل از همه باید یک برنامه‌ای داشته‌باشیم که بخوایم براش Build System تعیین کنیم و دستورات Makefile‍‍ش رو بنویسیم. یک نمونهٔ ساده کد چند تکه‌ای را می‌توانید از این‌قسمت دریافت کنید. ما سه فایل arg.c/arg.h و main.c را به این‌صورت داریم (یک ساختار معقول) : . ├── build ├── obj └── src ├── arg.c ├── arg.h └── main.c خب حالا ما باید Makefile خودمان را داخل دایرکتوری ریشه درست کنیم، قبلاً هم گفتم : "برنامهٔ GNU Make به دنبال فایلی به اسم Makefile یا GNUmakefile یا makefile می‌گرده". در Makefile می‌توانیم‌ما قوانین (rule) برای ساخته شدن چیزی و متغیر‌هایی تعریف کنیم. اینجا من توضیحات خلاصه‌ای را می‌گویم، باقی‌ماندهٔ مطالب را باید از مستندات‌رسمی GNU Make یا راهنمای سریع دنبال کنید. هر قوانین‌‍ای که تعریف می‌کنیم دارای این ساختار هست : نیازها : هدف‌ها دستورات مثلاً ما می‌خواهیم که برنامهٔ‌کامپایل شدهٔ‌مان، با اسم args در دایرکتوری build/ قرار بگیره. اینجا "هدف"ما میشه build/args و نیازما هم فایل‌های کامپایل‌ شدهٔ arg.c و main.c هست. اوه ! یک هدف دیگه‌هم پیدا شد؛ الآن هدف دوّم‌ما فایل‌های کامپایل شدهٔ obj/arg.o و obj/main.o هست و نیازمان هم سورس‌های این فایل‌ها یعنی src/arg.h و src/arg.c و src/main.c. خب خیلی زیاد شدن، بهتره که از آخر شروع کنیم و نیازهایمان را برطرف کنیم، اوّلین نیاز فایل‌های کامپایل‌شده هستن : obj/main.o obj/arg.o : src/main.c src/arg.c src/arg.h gcc -c -o obj/main.o src/main.c gcc -c -o obj/arg.o src/arg.o *  نکته : سعی نکنید دستورات Makefile را از منطقهٔ کد کپی نکنید، کمی تلاش کنید و بنویسید. خب قبول دارم خیلی زیاد و زشت شد، بیاید این قانون (rule) را به دو تیکه قسمت کنیم : obj/arg.o : src/arg.c src/arg.h gcc -c -o obj/arg.o src/arg.c obj/main.o : src/main.c gcc -c -o obj/main.o src/main.c اگر تا انتها متن ادامه بدید حتماً کوتاه‌ترم خواهد شد :). خب؛ object fileها یا همان فایل‌های کامپایل شده‌‍‌یمان را به دست‌آوردیم. حالا باید قانون (rule) نیاز اوّلمان را بنویسیم، چه چیزی نیاز داشتیم ‌؟ فایل کامپایل شدهٔ build/args که نیاز به object fileها داشت، حالا object fileها را داریم و باید نیاز هدفمان را برطرف کنیم : build/args : obj/main.o obj/arg.o gcc -o build/args obj/main.o obj/arg.o obj/arg.o : src/arg.c src/arg.h gcc -c -o obj/arg.o src/arg.c obj/main.o : src/main.c gcc -c -o obj/main.o src/main.c تمام شد. ما دستورات Build System خودمان را به زبان برنامهٔ GNU Make نوشتیم؛ حالا کافیه که فقط وارد دایرکتوری‌ای که فایل Makefile هست بشیم و از ترمینال برنامهٔ make را فراخوانی کنیم : $> make gcc -c -o obj/main.o src/main.c gcc -c -o obj/arg.o src/arg.c gcc -o build/args obj/main.o obj/arg.o حالا می‌توانیم برنامهٔ خودمان را اجرا کنیم : $> build/args -name Ghasem -family Ramezani Input Name is [Ghasem] Input Family is [Ramezani] دقّت کرده باشید ما توی نوشتن Makefileمان نیازمندی‌هارو یکی بالاتر از دیگری نوشتیم. چرا ؟ به خاطر اینکه GNU Make میاد از اوّل فایل شروع می‌کنه و قوانین (rules)ها را اجرا می‌کنه. بزارید با یک مثال نشان بدم. Makefile زیر را مدنظرتون داشته‌باشید : obj/arg.o : src/arg.c src/arg.h gcc -c -o obj/arg.o src/arg.c obj/main.o : src/main.c gcc -c -o obj/main.o src/main.c build/args : obj/main.o obj/arg.o gcc -o build/args obj/main.o obj/arg.o ما نیاز اصلی خودمان را آخرین قانون (rule) نوشتیم. حالا برنامهٔ make را اجرا می‌کنیم تا رفتارَش را بهتر متوجه بشیم : $> make gcc -c -o obj/arg.o src/arg.c دیدید ؟ خیلی ساده برخورد کرد، اوّلین قانون (rule) را نگاه کرد تنها نیازمندیش فایل‌های src/arg.c و src/arg.v بودن که وابسته به چیزی نبودند و هدفشان را تأمین کردند. اگر بخواهیم باقی قوانین (rules) را فراخوانی کنیم، باید صراحتاً مشخص کنیم : $> make obj/main.o gcc -c -o obj/main.o src/main.c $> make build/args gcc -o build/args obj/main.o obj/arg.o خب دیگه امیدوارم دلیل اینکه‌ما نیازمندی اصلیه خودمان را اوّلین قانون (rule) قرار دادیم را متوجه شده باشید. وقتی make به نیازمندیه obj/arg.o و obj/main.o برای تأمین build/args برمی‌خوره ادامهٔ قوانین را پیمایش می‌کنه تا نیازمندی‌ها را برطرف کنه. (اگر گیج شدید احتمالاً، پیشنهاد می‌کنم همین‌ موارد را روی کاغذ کشیده و قسمت : نیازمندی‌ها و هدف‌ها و دستورات هر قانون را مشخص کنید.) می‌توانیم قوانینی (rules) تعریف کنیم برای کارهای خاصی، مثلاً همان make install، یعنی قانون install را فراخوانی کن؛ حالا ما قانون clean را برای حذف کردن فایل‌های کامپایل‌شده می‌نویسیم : clean : yes | rm -vf build/* obj/* البته باید در اینجا نکته‌ای را هم حواسمان باشد، باید به GNU Make بگوییم که قانون clean ، یک قانون الکی‌هست، و با یک "هدف" اشتباه نشود. به این‌صورت قانون را ویرایش می‌کنیم : .PHONY : clean clean : yes | rm -vf build/* obj/* نگرانی‌ای هم دربارهٔ Wildcard ها نداشته‌باشید، GNU Make دستتون را باز گذاشته :). متغیرها در GNU Make مسلماً هرجا سخنی از متغیر‌است، سر و کلهٔ راحتی‌کار (و تا حدودی پیچیدگی) پیدا می‌شود. ما می‌توانیم متغیرهم داخل Makefile خودمان داشته‌باشیم. مثلاً فرض کنید که نیاز دارید تمام سورس‌کدها با کامپایل clang و سطح‌بهینه‌سازیه 3 کامپایل بشند. نیازی نیست‌که هربار اینارو تایپ کنیم. کافیه براشون متغیرتعریف کنیم : CC = clang OP = -O3 OBJECT = obj/main.o obj/arg.o ARGS = src/arg.c src/arg.h build/args : $(OBJECT) $(CC) $(OP) -o build/args $(OBJECT) obj/arg.o : $(ARGS) $(CC) $(OP) -c -o obj/arg.o src/arg.c obj/main.o : src/main.c $(CC) $(OP) -c -o obj/main.o src/main.c clean : yes | rm -vf build/* obj/* متغیرهای به خصوصی نیز در GNU Make تعریف شده‌اند که می‌توانند کار مارا بسیار راحت‌تر کنند،‌ برای مثال می‌توانیم قانون object file‌ها را به اینصورت بازنویسی کنیم : obj/%.o : src/%.c $(CC) $(OP) -c -o $@ $? برای اطلاعات بیشتر به راهنمای‌سریع GNU Make مراجعه کنید.   یادداشت‌ها یا Code Comments برای استفاده از قابلیت Comment گذاری در کد، کافیه که اوّل خط خودتون از کاراکتر # استفاده کنید.     خب دوستان، سعی کردم کلیّات مبحث را بگم؛ ابزار Make قابلیت‌های بسیار زیادی داره که حتماً باید خودتون مطالعه کنید. مثلاً خواستید Makefile شما یک Makefile دیگه را صدا بزنه، یا حتیٰ دستورات شرطی اجرا بکند و یا از همه مهم‌تر بر اساس معماری پلتفرم شما عملیات کامپایل را انجام بده و ... . - موفق‌وپیروز باشید. 🌺

قاسم رمضانی منش

قاسم رمضانی منش

 

امنیت در نرم افزارهای تولید شده با زبان ++C - ادامه

ادامه مقاله امنیت در نرم افزارهای تولید شده با زبان ++C به یک شی cv-qualified  توسط یک شی cv-unqualified دسترسی پیدا نکنید! به برنامه زیر توجه کنید، یک روش با شرایط ثابت، که برای ذخیره سازی پنهان نتایج ناشی از دورانداختن شرایط ثابت مذکور تلاش میکند، فراخوانی میشود. به دلیل آنکه کلاس S به عنوان یک ثابت اعلام شده است. تغییر ناگهانی و جهش مقدار پنهان ذخیره شده، منجر به بروز رفتار نامشخص میگردد. #include <iostream> class S{ private: int cachedValue; int compute_value() const; // expensive public: S() : cachedValue(0) {} int get_value() const{ if (!cachedValue){ const_cast<S *>(this)->cachedValue = compute_value(); } return cachedValue; } }; void f(){ const S s; std::cout << s.get_value() << std::endl; } اکنون برای رفع این مشکل کافی است که نوع متغیر عضو کلاس را به صورت mutable تعریف نماییم. #include <iostream> class S{ private: mutable int cachedValue; int compute_value() const; // expensive public: S() : cachedValue(0) {} int get_value() const{ if (!cachedValue){ cachedValue = compute_value(); } return cachedValue; } }; void f(){ const S s; std::cout << s.get_value() << std::endl; }   نباید یک شی لاندا بیشتر از اشیایی رجوع شده به خود، عمر کند! این امکان وجود دارد که عبارت لاندا، اشیای دارای مدت زمان ذخیره سازی خودکاری را از مجموعههای ازحوزه های پیوسته حوزه ی دسترسی، برای استفاده در بدنه ی تابع، رصد و دریافت کند. ممکن است این رصد به صورت صریح و از طریق مشخص کردن شی در capture-list لاندا، یا به صورت ضمنی و با استفاده از capture-default و ارجاع به شی در بدنه ی تابع لاندا صورت پذیرد. هنگامی که یک شی به وسیله ی کپی رصد میشود، شی لاندا شاملیک عضو داده ای غیرایستای بدون نام خواهد شد، که مقدار اولیه برابر با مقدار شی مورد رصد است. طولعمر عضو داده ای غیرایستا نیز برابر با طول عمر شی لاندا خواهد بود. با این وجود، هنگامیکه یک شیتوسط مرجع رصد می شود، طول عمر مورد ارجاع به طول عمر شی لاندا گره نخورده است. بنابراین هنگامیکه یک شی لاندا از شی مورد ارجاع و رصد خود بیشتر عمر کند، مادامیکه شی مورد ارجاع و رصد در دسترس است، اجرای عملگر فراخوانی تابع شی لاندا منجر به بروز رفتار نامشخص میشود.بنابراین، شی لاندا نباید طول عمری بیشتر از شی مورد ارجاع و رصد خود داشته باشد. به مثال زیر توجه نمایید، یک مرجع لاندا، یک متغیر محلی را از یک لاندای بیرونی رصد میکند. با این وجود، طولعمر این لاندای داخلی بیشتر از لاندای بیرونی و متغیرهای محلی خودکار تعریف شده ی آن است. هنگامیکه شی لاندای داخلی در ()f اجرا میشود، رفتار نامشخصی روی خواهد داد. auto g(int val){ auto outer = [val]{ int i = val; auto inner = [&]{ i += 30; return i; }; return inner; }; return outer(); } void f(){ auto fn = g(12); int j = fn(); } برای رفع این اشکال کافی است که لاندای inner متغیر i را نه از طریق ارجاع بلکه از طریق کپی رصد نماید. auto g(int val){ auto outer = [val]{ int i = val; //auto inner = [=] () mutable { //OR auto inner = [i]{ i += 30; return i; }; return inner; }; return outer(); } void f(){ auto fn = g(12); int j = fn(); }   زمانی که عملگر new را سربارگذاری میکنید حتما باید عملگر delete را هم سربارگذاری نمایید به برنامه زیر توجه نمایید،  #include <Windows.h> #include <new> void *operator new(std::size_t size) noexcept(false){ // Private, expandable heap. static HANDLE h = ::HeapCreate(0, 0, 0); if (h){ return ::HeapAlloc(h, 0, size); } throw std::bad_alloc(); } // No corresponding global delete operator defined. در صورتی که هیچ کلاس کمکی برای سربار گذاری در نظر نگرفته باشید قطعا نمی توانید از عملگر delete بر روی حافظه رزرو شده توسط این تابع استفاده کنید. بنابراین بهتره از یک کلاس پوشاننده استفاده کنیم.. #include <Windows.h> #include <new> class HeapAllocator{ private: static HANDLE h; static bool init; public: static void *alloc(std::size_t size) noexcept(false){ if(!init){ h = ::HeapCreate(0, 0, 0); // Private, expandable heap. init = true; } if(h){ return ::HeapAlloc(h, 0, size); } throw std::bad_alloc(); } static void dealloc(void *ptr) noexcept{ if (h){ (void)::HeapFree(h, 0, ptr); } } }; HANDLE HeapAllocator::h = nullptr; bool HeapAllocator::init = false; void *operator new(std::size_t size) noexcept(false){ return HeapAllocator::alloc(size); } void operator delete(void *ptr) noexcept{ return HeapAllocator::dealloc(ptr); }  

فرهاد شیری

فرهاد شیری

 

معرفی Permission Control System SDK برای ASP.NET MVC

مکانیسم Role Management در ASP.NET Identity کمبودهای بسیاری دارد، از جمله اینکه جهت مشخص کردن سطح دسترسی، نام Role ها میبایست در صفت Authorize نوشته شده و Hard Code شود. این بدان معناست که برای انجام هر گونه تغییر در کنترل دسترسی مجبور خواهید بود سورس برنامه تان را دستکاری کنید. همچنین، عدم وجود امکانی برای ویرایش کاربران و Role ها، کار کردن با این مکانیسم را مشکل می کند. در راستای حل این مشکلات و کمبودها، ما یک کیت توسعه نرم افزار (SDK) به نام Permission Control System طراحی و ارائه کرده ایم. با استفاده از این SDK نیاز نیست هیچ چیزی را در برنامه جهت مدیریت دسترسی Hard Code کنید، تمام امکانات مدیریتی Dynamic است! پس از فعال کردن این SDK، هر Controller یا Action ای که به پروژه تان اضافه کنید پس از اجرای بعدی برنامه به صورت خودکار در صفحه Role Manager ظاهر خواهد شد و می توانید انتخاب کنید که کدام گروه از کاربران به چه Action ای بر حسب Role شان دسترسی خواهند داشت. آموزش کامل ویدئویی این SDK نیز با تشریح کد آن به صورت خط به خط برنامه در همین پکیج ارائه شده است. علاوه بر آموزش اجزاء SDK، موارد زیر نیز در آموزش ویدئویی ارائه شده است: آموزش کامل ASP.NET Identity با تشریح کامل کدها روش تغییر نام جداول و ستونهای ایجاد شده توسط مکانیسم Identity طراحی و پیاده سازی سیستم رمز یک بار مصرف (OTP) جهت لاگین به سیستم ایجاد و استفاده از Attribute ها ایجاد و استفاده از Global Filter ها برای کنترل دسترسی ایجاد و استفاده از HTML Helper ها لینک صفحه مربوط به SDK و آموزش ویدئویی https://github.com/delphiassistant/permission_control_system   لطفا نظرات و پیشنهادات خود درباره بهبود این SDK را در پاسخ این نوشته ارسال کنید.   با تقدیم احترام،
مهدی کرامتی.

مهدی کرامتی

مهدی کرامتی

 

استفاده از تکنیک بازتاب در ++C با کتابخانه RTTR

با سلام  هدف از تدوین این مقاله نحوه استفاده از مفاهیم بازتاب (Reflection)  در نرم افزار های تولید شده با استفاده از زبان ++C می باشد. همانطور که می دانید کامپایلرهای++C به صورت پیش فرض از مفاهیم بازتاب که در پلت فرم های مدیریت شده مانند #C و Java  وجود دارد پشتیبانی نمیکند. که البته بحث بر سر اینکه چرا توسعه دهندگان استانداردهای ++C از چنین تکنیک هایی استفاده نمیکنند خارج از حوصله این مقاله هست و البته جستجوی مقالات زیادی که راجع به این بخش وجود دارد را هم به خود شما خواننده محترم می سپارم. کتابخانه RTTR چه مکانیزمی دارد؟ RTTR به معنای بازتاب نوع زمان اجرا است. این قابلیت یک برنامه کامپیوتری را برای درک و تغییر یک شی در زمان اجرا توضیح می دهد.  هدف از این کتابخانه ارائه راه ساده و بصری برای استفاده از انعکاس در C++ است. این کتابخانه  برنامهنویس را قادر می سازد از انعکاس در برنامه خود استفاده کند. به این معناست که برنامه می تواند یک شی را در زمان اجرا ببیند که چه نوع خواص، متد ها یا سازنده هایی آن را تشکیل می دهد. تصور کنید زمانی که یک اتصال دایمی دشوار اما همچنین پویا بین ماژول های نرم افزاری مورد نیاز است. موارد اصلی استفاده از بازتاب برای مثال سریال سازی اشیاء، ایجاد UI، اتصال به زبان های برنامه نویسی دلخواه ، ارتباطات شبکه ، کلاسهای ORM برای کار با دیتابیس ها می باشد. نحوه استفاده از این کتابخانه  رجیستر کردن کلاس ها خواص، متدها و سازنده های خود را در فایل های منبع خود ثبت کنید. تنظیم رابط کلاس فقط زمانی لازم است که از ارث بری استفاده شود. #include <rttr/registration> using namespace rttr; struct MyStruct { MyStruct() {}; void func(double) {}; int data; };  RTTR_REGISTRATION { registration::class_<MyStruct>("MyStruct") .constructor<>() .property("data", &MyStruct::data) .method("func", &MyStruct::func); } استفاده از تکرار گرها در بازتاب با نوع شی شما می توانید از اعضای قبلا ثبت شده خود پرس و جو کنید. البته شامل تمامی کلاسهای پایه قبلا ثبت شده نیز خواهد شد. type t = type::get<MyStruct>(); for (auto& prop : t.get_properties()) std::cout << "name: " << prop.get_name() << std::endl; for (auto& meth : t.get_methods()) std::cout << "name: " << meth.get_name() << std::endl; استفاده از نوع Constructor برای ساخت اشیاء در زمان اجرا. از طریق نوع شی یا شیء سازنده می توانید نمونه هایی از نوع خود را ایجاد کنید. type t = type::get_by_name("MyStruct"); variant var = t.create(); // will invoke the previously registered ctor constructor ctor = t.get_constructor(); // 2nd way with the constructor class var = ctor.invoke(); std::cout << var.get_type().get_name(); // prints 'MyStruct' استفاده از متدهای دسترسی در بازتاب  به راحتی می توانید در زمان اجرا با بازتاب به فیلدهای عضو کلاس دسترسی داشته باشید. MyStruct obj; property prop = type::get(obj).get_property("data"); prop.set_value(obj, 23);  variant var_prop = prop.get_value(obj); std::cout << var_prop.to_int(); // prints '23' فراخوانی متدها در زمان اجرا
فراخوانی یک متد مستقیم است.همچنین ممکن است از شی مورد استفاده برای فراخوانی یک متد استفاده شود. MyStruct obj; method meth = type::get(obj).get_method("func"); meth.invoke(obj, 42.0); variant var = type::get(obj).create(); meth.invoke(var, 42.0); برای کسب اطلاعات بیشتر می توانید درباره مفاهیم بازتاب در برنامه نویسی های شی گرا مطالعه داشته باشید.

فرهاد شیری

فرهاد شیری

 

امنیت در نرم افزارهای تولید شده با زبان ++C

با توجه به اهمیت امنیت نرم افزار، شرکت های بزرگ دنیا به ارائه راهکارهایی چون طراحی زبان ها و محیط های برنامه نویسی و مفسر و مترجم هایی با قابلیت های کنترل امنیتی بر روی سیستم عامل و بسیاری از راهکارهای دیگر پرداخته اند اما با توجه به عدم توانایی راهکارها در کنترل تمامی موارد امنیتی، عدم امکان پیاده سازی راهکارهای امنیتی بر روی برخی ساختارها، ایجاد محدودیت برای دسترسی به برخی منابع و امکانات و مشکلات کوچک و بزرگ دیگر برنامه نویسی یک برنامه به صورت ایمن بهترین راهکار برای محافظت از یک برنامه است. یکی از زبان هایی که در کنار محبوبیت در میان برنامه نویسان، همیشه یکی از زبان های پر بحث در برنامه نویسی ایمن بوده است، خانواده زبان های C به خصوص ++C است. در این زبان ها عمده مدیریت منابع به برنامه نویس واگذار شده که در صورت عدم مدیریت درست آن ها، آسیب پذیری های مختلفی رخ می دهد. بهترین راهکار برای جلوگیری از بروز آسیب پذیری نرم افزارها، برنامه نویسی پدافندی و ایمن آن نرم افزار از ابتداست. دراین مستندات، باتوجه به جامعیت و کاربرد فراوان زبان ++C درکنار محبوبیت، مباحث ونکات اساسی در برنامه نویسی پدافندی و ایمن این زبان مطرح شده و انواع آسیب پذیری و شیوه جلوگیری از بروز آن ها و رفع آن ها در صورت بروز، توضیح داده می شود. همچنین سعی می شود تا راهکارهای ارائه شده تا حد امکان قابل پیاده سازی در زبان C نیز باشند. با توجه به گستردگی ابزارهای برنامه نویسی این زبان و وجود کامپایلرهای مختلف، زبان معیاری برای این مستند مدنظر قرار گرفته شده است و ساختار ارائه شده مربوط به ابزار یا کامپایلر خاصی نیست اما بنا بر نیاز مثال هایی در کنار زبان معیار از ابزارهایی خاص نیز ارائه می گردد. رفتار تعریف نشده ممکن است شامل مختل شدن عملکرد برنامه(Crash) خروجی نامربوط و غلط، بروز آسیب پذیری های نرم افزاری و موارد دیگر می باشد. وجود رفتار نامتعارف در یک برنامه نه تنها امنیت خود آن برنامه ، بلکه ممکن است امنیت سیستم عامل، شبکه را نیز به خظر بیندازد. جلوگیری از بروز رفتارهای تعریف نشده و مقابله با آن ها از مباحث مهم برنامه نویسی تدافعی و ایمن است. توابع بدون آرگومان برای تعریف یک تابع بدون آرگومان باید از کلمه کلیدی void در زمان تعریف تابع استفاده نمایید.با این کار تزریق کد توسط هکرها را مختل می کنید.   int getValue(void) { return 1; } اعداد تصادفی در صورت نیاز به اعداد تصادفی از تابع ()rand استفاده نکنید به این علت که خروجی این تابع در تکرارهای بالا دچار تکرار می شود. بهتراست از تابع ()srand استفاده کنید می توانید برای آن seed تعریف کنید تا احتمال تکرار را به حداقل برسانید. در ویندوز هم می توانید از تابع ()CryptGenRandom استفاده کنید و در لینوکس هم تابع ()random و تابع ()srandom استفاده نمایید. #include <windows.h> #include <wincrypt.h> #include <iostream> int main(void) { HCRYPTPROV hcp; CryptAcquireContext(&prov, NULL, NULL, PROV_RSA_FULL, 0); long int li = 0; CryptGenRandom(hcp, sizeof(li), (BYTE *)&li); printf("Random number is -> %ld\n", li); return 0; } عدم استفاده از تابع بازگشتی جهت مقدار دهی اولیه به آرایه ای با کلاس حافظه استاتیک در مثال زیر زمان ساخته شدن و مقدار دهی اولیه آرایه cache تابع fact مجددا فراخوانی شده واین عمل به دلیل ایستا بودن آرایه باعث بروز رفتار تعریف نشده و خطا خواهد شد. #include <stdexcept> int fact(int i) noexcept(false) { if (i < 0) { throw std::domain_error("i must be >=0"); } static const int cache[] = { fact (0), fact(1), fact(2), fact(3), fact(4), fact (5), fact (6), fact(7), fact(8), fact(9), fact(10), fact (11), fact (12), fact(13), fact(14), fact(15), fact(16) }; if (i < (sizeof(cache) / sizeof(int))) { return cache[i]; } return i > 0 ? i * fact (i - 1) : 1; } حال برای رفع این اشکال طبق نمونه کد زیر آرایه را بدون استفاده initializer list با استفاده از یک متغیر ثابت که تعداد عضو های آرایه را معین میکند تعریف شده است و ازآنجا که کامپایلر آرایه های از جنس کلاس حافظه استاتیک را خود با عدد 0 مقداردهی میکند دیگر یک آرایه از قبل پر شده نخواهیم داشت و در مرحله با استفاده از تکنیک lazy به هر یک از عضوهای آرایه مقدار مناسب را با استفاده از تابع بازگشتی مقدار دهی خواهیم کرد. #include <stdexcept> const int arraySize = 17 int fact(int i) noexcept(false) { if (i < 0) { throw std::domain_error("i must be >=0"); } static int cache[arraySize]; if (i < (sizeof(cache) / sizeof(int))) { if (0 == cache[i]) { cache[i] = i > 0 ? i * fact(i - 1) : 1; } return cache[i]; } return i > 0 ? i * fact(i - 1) : 1; } الحاق مضاعف هدر فایل ها الحاق مضاعف زمانی رخ می دهد که یک هدر دو ویا چند بار به برنامه اضافه شوند. در مثال زیر در کلاس c هدرهای a , b الحاق می شوند در حالی که در کلاس b هم هدر a الحاق شده است که الحاق مضاعف رخ داده است. //a.h struct a { int membe }; //b.h #include "a.h" //c.c #include "a.h" #include "b.h" برای جلوگیری از این الحاق های مضاعف می توانید از روش زیر استفاده نمایید //a.h #ifdef A_H #define A_H struct a { int member; }; #endif ویا می توانید از دستور pragma استفاده کنید البته این دستور جز دستورات استاندارد ++c / c نمی باشد ولی اکثر کامپایلرها این دستور را اجرا میکنند. //a.h #pragma once struct a { int member; }; رمزنگاری اصولی جهت رمزنگاری داده های حساس در برنامه های خود می توانید از کتابخانه ++Crypto وهمچنین کتابخانه libcrypto از OpenSSL نیز استفاده نمایید. رمز نگاری به چند دسته اصلی تقسیم می شود: 1- رمزنگاری درهم سازHash که میتوان به الگوریتم های MD6 , MD5 , SHA-1,SHA-0 اشاره کرد. 2- رمزنگاری با کلید متقارن که می توان به الگوریتم های RC4 , AES , DES , 3DES اشاره کرد. 3- رمزنگاری با کلید عمومی نا متقارن که می توان به الگوریتم های RSA , DSA , DSS اشاره کرد. 4- کد گذاری دودویی به متن که می توان به الگوریتم های Base32 , Base58 , Base64 ,Base85 اشاره کرد. مدیریت مقدار و نوع داده ها و مقدار دهی اولیه در مثال زیر متغیر هایی تعریف شده اند که مقدار اولیه ندارند (البته درست است که در برخی از کامپایلرها این متغیرها را مقدار دهی خواهند کرد، ولی توجه داشته باشید که تکنیک های برنامه نویسی تدافعی جدای از امکانات کامپایلر می باشد) int main (void) { int a; float b; char c; bool d; return 0; } اکنون مشاهده میکنید که بعد از اجرای برنامه چه مقدار هایی در متغیرها ذخیره شده است. پس بنابراین مقدار دهی اولیه متغیرها یا باید برحسب نیاز در همان ابتدا تعریف صورت گیرد یا در صورت عدم نیاز به وجود مقدار اولیه خاص، مقدار دهی با استفاده از تابع همان نوع داده انجام خواهد شد. int main (void) { int a = int(); float b = float(); char c = char(); bool d = bool(); return 0; } و بعد از اجرا به این صورت خواهد بود مقدار دهی اولیه به آرایه ها int main (void) { int a[5]; float b[5]; char c[5]; bool d[5]; return 0; } که بعد از اجرا بدین صورت خواهد بود... و برای رفع این اشکال باید همیشه آرایه ها را مقدار دهی اولیه نمایید. int main (void) { int a[5] = {}; float b[5] = {}; char c[5] = {}; bool d[5] = {}; return 0; } وبعد از مقدار دهی اولیه به آرایه ها خواهیم داشت ... ادامه خواهد داشت این مقاله...  

فرهاد شیری

فرهاد شیری

 

اسکریپتینگ در ++C

کامپایلر Cling یک مترجم تعاملی برای سی‌پلاس‌پلاس است، این مترجم تحت بالاترین کتابخانه‌های Clang و LLVM ساخته شده است. در واقع از آن‌جایی که کامپایلر Clang از آخرین ویژگی‌ها و استاندارد‌های زبان سی‌پلاس‌پلاس پشتیبانی می‌کند، Cling اجازه می‌دهد تا توسعه‌دهندگان اسکریپت‌های خود را با استفاده از C و C++ بنویسند. اگر شما به طور مستقیم مترجم را اجرا کنید، یک محیط زنده برای آغاز برنامه نویسی با سی‌پلاس‌پلاس را خواهید داشت که به عنوان بخشی از استاندارد نحو سی و سی‌پلاس‌پلاس به شمار می‌آید. همچنین می‌توانید دیگر دستورات را با نقطه‌ی "." آغاز در اختیار داشته باشید. وقتی از مترجم تعاملی استفاده می‌کنید، می‌توانید کد زیر را بنویسید: #include <stdio.h> printf("hello world\n"); همانطور که می‌بینید نیازی نیست تا در مورد حوزه‌ی دامنه‌ها نگران باشید؛ کافی است شما تابع مورد نظر خود را صدا بزنید. اگر قصد شما این است که از Cling به عنوان یک مترجم برای ساخت اسکریپت‌ها استفاده کنید، باید همه چیز را در داخل یک تابع قرار دهید.چرا که نقطه‌ی ورود به اسکریپت به طور پیش‌فرض همانند نام فایل می‌باشد. می‌توان آن را برای صدا زدن دیگر توابع سفارشی سازی کرد. بنابراین مثال قبل می‌توانید به شکل زیر تغییر کند: #include <stdio.h> void _01_hello_world() { printf("foo\n"); } یک نسخه‌ی دیگر در قالب سی‌پلاس‌پلاس #include <iostream> void _02_hello_world() { std::cout << "Hello world" << std::endl; } مثال‌ها کاملاً ساده هستند، اما آن‌ها به شما نشان می‌دهند که چگونه باید شروع کنید. در مورد کیوت چطور؟ #include <QtWidgets/qapplication.h> #include <QtWidgets/qpushbutton.h> void _03_basic_qt() { int argc = 0; QApplication app(argc, nullptr); QPushButton button("Hello world"); QObject::connect(&button, &QPushButton::pressed, &app, &QApplication::quit); button.show(); app.exec(); } اما توجه داشته باشید که کد قبلی کار نخواهد کرد، شما باید برخی از پارامتر‌های سفارشی را در Cling مشخص کنید. cling -I/usr/include/x86_64-linux-gnu/qt5 -fPIC -lQt5Widgets 03_basic_qt.cpp شما می‌توانید Cling را برای خودتان بر اساس آن چیزی که برای اسکریپت خود نیاز دارید سفارشی سازی کنید. همچنین شما می‌توانید Cling را به عنوان یک کتابخانه در اپلیکیشن‌های خود آورده و از سی‌پلاس‌پلاس به عنوان زبان برنامه‌نویسی استفاده کنید. این پُست در آینده ادامه خواهد داشت. 🙂
 

شرکت Ceemple کامپایلر Zapcc خود را تحت مجوز منبع باز منتشر کرد

درباره‌ی کامپایلر Zapcc کامپایلر Zapcc یک کامپایلر بر پایه Clang است که با هدف کامپایل‌های سریعتر طراحی شده است. این کامپایلر با استفاده از حافظه نهان (Cache) و استفاده از معماری سرویس‌گیرنده-سرویس‌دهنده پیاده سازی شده است که یک کامپایلر مدرن و جدیدی به شما می‌آید که برای اهداف زیر ساخته شده است: ساخت سریع: تسریع در جمع آوری‌های قابل توجه برای هدرهایی که دارای قالب‌های سنگین در سی پلاس پلاس می‌باشند مانند LLVM، WebKit، ScyllaDB بر پایه Clang/LLVM: این کامپایلر بر پایخ Clang و اغلب بر ساس آخرین SVN به روز رسانی شده است. پشتیبانی کامل از لینوکس: در حال حاضر این کامپایلر از لینوکس x64 و ویندوز x64 با MinGW-w64 به صورت آزمایشی پشتیبانی می‌کند. جایگزینی: جایگزینی برای Clang و GCC و پشتیبانی از تمامی سیستم‌های ساخت (Build Systems) . مجوز‌ها این پروژه منبع باز تحت مجوز LLVM از (University of Illinois/NCSA) می‌باشد. ساخت (Building) پیش نیازها و فرآیند ساخت همانند LLVM می‌باشد. git clone https://github.com/yrnkrn/zapcc.git llvm mkdir build cd build cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_WARNINGS=OFF ../llvm ninja اجرا و آزمایش ninja check-all استفاده نحو دستورات Zapcc همانند دستورات Clang می‌باشد. از بین بردن سرور Zapcc pkill zapcc این دستور جهت از بین بردن سرور Zapcc برای آزاد سازی حافظه یا جایگزینی با سیستم تازه ساخته شده Zappc استفاده شود. جهت اطلاعات بیشتر به این بخش مراجعه کنید. لینک منبع بر روی گیت‌هاب
 

شش دلیلی که باید نسخه نگاری را کنترل کنید

برای بسیاری از توسعه دهندگان نرم افزار کار کردن بدون کنترل نسخه غیر قابل تصور است. فواید کنترل و پیگیری تاریخچه تغییرات کدها برای درک کردن دنیای توسعه نرم افزار بسیار بالاست. با توجه به این نباید از نتایج به دست آمده از تحقیق انجام شده توسط DevOps که استفاده از تاریخه کدها بسیار بالاست شگفت زده شد. اما پرسیدن در مورد کنترل نسخه دیتابیس موضوع دیگری است. تنها ۵۸ ٪ از کسانی که در این تحقیق شرکت کرده اند گفته اند که کنترل نسخه دیتابیسشان را رصد می‌کنند. البته به طریقی این قابل درک است که چرا کنترل نسخه برای مدت بسیار زیادی بر روی دیتابیس انجام نمی پذیرفت. اما اکنون زمان این رسیده است که دیگر تیم‌ها بتوانند بر روی دیتابیس کار کنند. اگر شما هنوز کنترل نسخه برای دیتابیس خود انجام نداده اید ما در اینجا دلایلی آورده ایم که اینکار برای شما بسیار حیاطی می‌باشد: به راحتی می‌توانید تغییرات کدها را با تیمتان به اشتراک بگذارید
کنارهم قرار دادن دیتابیس کد‌ها با سیستم کنترل نسخه کار کردن اعضای تیم بر روی کدهای دیتابیس و مسئولیت پذیری آن‌ها را بر روی کارهایشان بیشتر می‌کند. توانایی به اشتراک گذاردن مداوم و مدیریت تغییرات برای تیم های که در کنار هم کار نمی کنند بسیار حیاتی است. به وسیله  SQL Sourse Control   اعضای می توانند بر روی یک دیتابیس به اشتراک گذارده شده و یا هر کدام بر روی یک دیتابیس LOCAL که یک کپی از نسخه اصلی است کار کنند. با افزودن ویژگی‌هایی مانند object locking شما می می‌توانید از تداخل های احتمالی جلوگیری کنید و کار را بدون تداخل جلو ببرید. از نحوه توسعه نمای بهتری به دست خواهید آورد:
سیستم کنترل نسخه برای شما یک نمای کلی از توسعه کلی کاری که انجام می‌دهید نشان می‌دهد. کنترل نسخه برای شما تاریخچه تغییرات را نشان می‌دهد و به راحتی با سیستم های کنترلی و پیگیری کار ‌می‌کند. به طور مثال SQL Source Control به شما اجازه همگام سازی وظایف دیتابیس را با Mircosoft Team Foundation Server work item ها می‌دهد و به وسیله آن به راحتی می توانید جریان کار را کنترل کنید. به شما توانایی Rollback و بازگشتن به ورژن قبلی دیتابیس را می‌دهد.
در حالی که شما همواره یک استراتژی Backup مناسب دارید. استفاده از کنترل نسخه برای دیتابیس یک مکانیزم برای back up  گرفتن از SQL کدهای شما در اختیارتان قرار می‌دهد. با استفاده از SQL Source Control کار کردن و بازگرداندن نسخه های قبلی بسیار آسان و ساده هستند. حسابرسی و خوانایی کدها را ساده‌تر می کند
تغییر ورژن کنترل،‌اولین قدم برای آماده سازی خوانایی کدها و یک قدم ضروری برای بهتر کردن حسابرسی و مدیریت ریسک می‌باشد. حسابرسی صحیح نیازمند یک سازماندهی برای کلیه تغییران بر روی دیتابیس می‌باشد و آن نیازمند جزییان برای دسترسی است. با استفاده از SQL Source Control شما می‌توانید نسخه کامل تاریخچه دیتابیس و یا database object را دسترسی داشته باشید و ببینید که چه کسی تغییرات را ایجاد کرده است، چه زمانی آنها را انجام داده است و چرا. پایه ریزی برای Database Automation
داشتن یک نسخه از دیتابیس مدیریت تغییرات را ساده تر می‌کند. پردازش‌های پیچیده اتوماتیک‌تر و تکرارپذیرتر می‌شوند و تغییرات نیز قابل پیش‌بینی می‌گردند. استفاده از کدی که در داخل SQL Source Control به عنوان پایه ساختن و تست های DLM Automation را اتوماتیک می‌کند و این بدین معنی است که مسائل سریع‌تر پیدا می‌شوند و کدی با کیفیت بالاتر تولید و منتشر می‌گردد. همگام‌سازی دیتابیس و تغییرات کد‌های نرم‌افزار
داشتن یک دیتابیس با کنترل نسخه دقیقا در کنار اپلیکیشن تغییرات کد‌های دیتاییس و اپلیکیشن را همگام می‌کند. شما همواره خواهید دانست که چه نسخه‌ای از کد بر روی چه ورژنی از نرم‌افزار قرار داده شده است. این به شما کمک می‌کند تا انجام پروژه به صورت تیمی را بسیار ساده‌تر کنید، اثربخشی کار را بالاتر ببرید و مشکلات را سریع تر برطرف کنید. SQL Source Control که به سیستم های کنترل نسخه مانند TFS, Git, Subversion متصل شود تغییرات کدها را ذخیره می‌کند. خلاصه:
در حالی که این مساله صحیح است که کنترل نسخه همواره به دست نمی‌اید، اما در دسترس بودن ابزارهایی مانند SQL Source Control به این معنی است که دیگر دلیلی برای بعضی از شرکت‌ها که این کار انجام می‌دهند نباشد. اگر شما یکی از ۴۲ ٪ هستید که تا اکنون این کار برای دیتابیس خودتان انجام نداده اید، شاید این ۶ دلیل بالا بتواند نظر شما را عوض کند.
 

چه کسانی Full-Stack Developer هستند

برنامه‌نویس تنها در این عنوان خلاصه نمی‌شود و لازم است بدانید که برنامه‌نویسان در چند دسته متفاوت وجود دارند که برخی از آن ها به صورت Back-End و برخی Front-End فعالیت می‌کنند. در کل به کسانی که توانایی برنامه‌نویس در بخش Back-End را دارند به آن‌ها Back-End Developer می‌گویند. همچنین برنامه‌نویسانی که توانایی توسعه در بخش طراحی رابط‌کاربری و تجربه‌کاربری را با عنوان Front-End دارند Front-End Developer می‌گویند. در نظر داشته باشید که توسعه‌دهندگان و طراحان بخش تجربه‌‌کاربری (UX) و رابط‌کاربری (UI) خود وظایفی در سمت طراحی یک محصول را دارند که به خودی خود می‌توانند به عنوان توسعه‌دهنده‌ی فرانت‌اِند محسوب شوند اما ممکن است زمینه‌ی اجرایی آن‌ها با محیط‌های توسعه که شامل کد‌نویسی هستند نباشد! بنابراین شاخه‌ای از حوزه‌ی توسعه در نرم‌افزار کامپیوتر وجود دارد که می‌تواند با ترکیب دانش طراحی و کد‌نویسی و تسلط کامل بر این دو حوزه به صورت ترکیبی با دانش و توانایی بسیار بالا عنوان شود که به آن فول‌اِستک می‌گویند. البته فول‌اِستک ابعاد مختلفِ خود را دارد، برای مثال ممکن است یک توسعه‌دهنده‌ی فول‌اِستک تنها در پلتفرم اندروید توانایی طراحی و کد‌نویسی را به صورت همزمان و بدون نیاز به یار تیمی خود داشته باشد. اما در اصل توسعه‌دهنده‌های با تجربه با سابقه‌ی بالا که توانایی مدیریتی پروژه و توسعه‌ی آن‌ها را دارند از نوع فول‌اِستک تمام عیار محسوب می‌شوند که در ادامه به ویژگی‌های آن‌ها اشاره شده است. یک برنامه‌نویس حرفه‌ای یا همان فول‌اِستک می‌بایست مهارت‌های زیر را داشته باشد: مسلط به زبان‌های برنامه‌نویسی پایه آشنایی با UX و UI و مباحث مرتبط با هر یک از آن‌ها مدیریت پروژه بر روی پلتفرم‌های مختلف توانایی کنترل کیفیت محصول توانایی کار با انواع فناوری‌ها و کتابخانه‌ها توانایی کار با انواع دیتابیس و مدیریت آن‌ها هک و امنیت بهینه سازی موتور‌های جستجو آشنایی و توانایی درک و مدیریت کامپایلر‌ها و مفسر‌ها درک نیاز‌های کاربران در محصول (UX) آشنایی با سیستم عامل‌های مختلف آشنایی و توانایی تولید محصول به صورت چند-سکویی (Cross-Platform) آشنایی با شبکه و پیکربندی آن برای محصول آشنایی با مدیریت سرور و هاستینگ آشنایی با سیستم‌های مدیریتی و مجازی مانند VM آشنایی با سخت افزار آشنایی با رابط های برنامه نویسی API‌ها آشنایی با انواع محیط‌های توسعه و موارد دیگر که در یک پروژه از صفر تا صد می‌توان به آن‌ها نیاز پیدا کرد.  برنامه‌نویسان Full-Stack Developer به تنهایی می‌تواند درتولید و توسعه یک محصول موثر باشد و زمانی که با مشکلی مواجه شوند نمی‌گوید من آن را بلد نیستم، بلکه حتماً آن را حل خواهند کرد. به طور کلی کسب مهارت در سطح بالا در حد یک توسعه‌‌ دهنده فول‌اِستک بسیار سخت است اما نباید بگوییم که غیر ممکن است، در صورتی که چنین تعریفی برای یک توسعه‌دهنده‌ی فول‌استک در نظر بگیریم، بدون اغراق باید گفت تعداد اندکی از این برنامه‌نویسان موجود است که بتوانیم چنین لقبی را به آن‌ها اختصاص بدهیم بنابراین چنین برنامه‌نویسانی بسیار ارزشمند هستند لذا به خوبی می‌دانند یک نرم افزار چگونه طراحی‌ می‌شود و توانایی این را دارند از صفر تا صد یک نرم‌افزار را طراحی و روانه بازار کنند. علاوه بر این توسعه دهنده Full-Stack کسی است که واژگانی مانند نبود، نمی‌شه، امکان نداره، نمی‌توم، کار من نیست و ... را بر زبان نمی‌آورند و اگر هم چیزی را ندانند تمام تلاش خود را می‌کنند تا بدون نیاز به کمک شخصی دیگر آن را حل کنند. این نوع توسعه‌‌دهنده‌ها بسیار با ارزش و مهم هستند، و نکته جالب اینجاست که آن‌ها سال‌ها تلاش کرده‌اند و مسلماً به تنهایی صاحب کسب‌و‌کار خود بوده و در انتخاب اول برای کسی کار نمی‌کنند. برای توسعه دهنده‌ی فول‌اِستک فرقی نمی‌کند محصول تحت چه پلتفرمی باشد، او می‌تواند تحت دسکتاپ، وب، موبایل و دیگر پلتفرم ها آن را تولید کند.
×