جستجو در تالارهای گفتگو
در حال نمایش نتایج برای برچسب های 'ساختار'.
4 نتیجه پیدا شد
-
با سلام. بنده خروجی کد اسمبلی تولید شده Struct و Class را بررسی کردم ظاهرا که خروجی یکسانی دارند ! آیا واقعا دیگر تفاوتی بین کلمهکلیدی struct و class در سیپلاسپلاس نیست ؟ struct.cpp struct AnotherType{ public : int StructType; }; int main(){ AnotherType Object; return 0; } class.cpp class AnotherType{ public : int ClassType; }; int main(){ AnotherType Object; return 0; } و خروجی های اسمبلی تولید شده : struct.cpp [ghasem@clibcore test]$ g++ -S struct.cpp -o Struct && cat Struct .file "struct.cpp" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 movl $0, %eax popq %rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (GNU) 8.2.1 20181105 (Red Hat 8.2.1-5)" .section .note.GNU-stack,"",@progbits class.cpp [ghasem@clibcore test]$ g++ -S class.cpp -o Class && cat Class .file "class.cpp" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 movl $0, %eax popq %rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (GNU) 8.2.1 20181105 (Red Hat 8.2.1-5)" .section .note.GNU-stack,"",@progbits و برای اطمینان خروجی حاصل از دستور diff Struct Class : [ghasem@clibcore test]$ diff Struct Class 1c1 < .file "struct.cpp" --- > .file "class.cpp"
- 1 پاسخ
-
- سیپلاسپلاس
- ساختار
- (و 5 مورد دیگر)
-
کامبیز اسدزاده یک موضوع را ارسال کرد در <span class="ipsBadge ipsBadge_pill" style="background-color: #e62f3d; color: #ffffff;" >برنامه نویسی در C و ++C</span>
مراحل ساخت برنامه در زبان سیپلاسپلاس پیش نویس ۰.۶ قبل از هر چیز به اینفوگرافی زیر توجه کنید که مراحل ساخت برنامه در سیپلاسپلاس را نشان میدهد. مقدمهای بر همگردانی (کامپایل) و اتصال (لینک کردن) این سند مرور مختصری در رابطه با مراحل را برای شما فراهم میکند تا به شما در درک دستورات مختلف برای تبدیل و اجرای برنامهٔ خودتان کمک کند. تبدیل مجموعهای از فایلهای منبع و هدر در سیپلاسپلاس به یک فایل خروجی و اجرایی در چندین گام (به طور معمول در چهار گام) پیشپردازنده (Preprocessors)، کامپایل و گردآوری (Compilation)، اسمبلر (Assmbler) و پیوند دهنده (Linker) تقسیم میشود. قبل از هر چیز اگر در محیط توسعهٔ Qt Creator داخل فایل .pro مقدار زیر را وارد کنید، تا بتوانید فایلهای ساخته شدهٔ موقت در زمان کامپایل را مشاهده کنید. QMAKE_CXXFLAGS += -save-temps این دستور اجازهٔ آن را خواهد داد تا فایلهایی با پسوند .ii و .s در شاخهٔ بیلد پروژه تولید شوند که در ادامه به آنها اشاره شده است. تعریف پیشپردازنده پیشپردازندهها (Preprocessors) درواقع دستوراتی هستند که اجازه میدهند تا کامپایلر قبل از آغاز کردن مراحل کامپایل دستوراتی را دریافت کند. پیشپردازندهها توسط هشتگ (#) مشخص میشوند این نماد در سی++ مشخص میکند که دستور فوق از نوع پیشپردازنده میباشد که نتیجهٔ آن در قالب ماکرو (Macro) در دسترس خواهد بود. برای مثال ماکروی __DATE__ توسط پیشپردازندهها از قبل تعریف شده است که مقدار تاریخ و زمان را بازگشت میدهد. بنابراین هرکجا که از آن استفاده شود کامپایلر آن را جایگزین متن خواهد کرد. در شکل زیر مرحلهای که از پیشپردازندهها استفاده میشود آمده است: پیشپردازنده، کامپایل (گردآوری کردن)، لینک (پیوند کردن) و ساخت برنامه اجرایی فرایند تبدیل مجموعهای از فایلهای متنی هِدر و سورس سی++ را «ساخت» یا همان Building میگویند. از آنجایی که ممکن است کُد پروژه در بسیاری از فایلها هدر و سورس سی++ توسعه و گسترش یابدمراحل ساخت در چند گام کوچک صورت میگیرد. یکی از رایجترین موارد در مراحل گردآوری (ترجمهٔ یک کد سیپلاسپلاس به دستورالعملهای قابل فهم ماشین) است. اما گامهای دیگری نیز وجود دارد، پیشپردازنده و لینک (پیوندها) این بخش به طور خلاصه توضیح میدهد که چه اتفاقی در هر یک از مراحل رُخ میدهد. یک کامپایلر یک برنامهٔ خاص است که پردازش اظهارات (دستورات) نوشته شده در یک زبان برنامهنویسی خاص را به یک زبان ماشین که قابل فهم برای پردازنده میباشد تبدیل کند. به طور معمول یک برنامهنویس با استفاده از یک ویرایشگر که به محیط توسعهٔ یکپارچهٔ نرمافزار (IDE) مشهور است توسط زبان برنامهنویسی مانند ++C دستورات (اظهارات) را مینویسد. فایل ایجاد شده با نام (filename.cpp در زبان برنامهنویسی سیپلاسپلاس) شامل محتوایی است که معمولاً به عنوان دستورات برنامهنویسی سطح بالا نامیده میشود. سپس برنامهنویس کامپایلرِ مناسب برای زبان برنامهنویسی مانند سی++ را اجرا میکند و نام فایلهایی که حاوی دستورات هستند را برای کامپایل مشخص میکند که این انتخاب و مشخص سازی توسط IDE به راحتی قابل مدیریت است. پس از آن، کار کامپایلر این است که فایلهای منبع .cpp را جمع آوری کرده و پیشپردازندهها را بررسی کند تا دستورات احتمالی را اجرا نماید که نتیجهٔ این مرحله در فایلی با پسوند .ii ر قالب filename.ii تولید میشود که در این فرایند نیز خط به خط کُدهای موجود در آنها را بررسی میکند تا خطاهای احتمالی نحو (سینتکس - Syntax) بررسی میشود و آنها را به طور ترتیبی به دستورالعملهای سطح ماشین تبدیل کند. توجه داشته باشید که هر نوع پردازندهٔ کامپیوتر دارای مجموعهای از دستورالعملهایِ ماشین خودش است. بنابراین کامپایلر تنها برای سی++ نیست، بلکه برای اهداف و مقاصد خاص هر پلتفرم است. پس کدهایی که توسط پیشپردازنده سیپلاسپلاس به زبان اسمبلی برای معماری مورد نظر در پلتفرم مقصدترجمه شدهاند نتایج آن در فایلی با پسوند .ss در قالب filename.ss قابل نمایش هستند که در حالت عادی قابل رویت نیست. توجه داشته باشید که باید در این مرحله باید مشخص شود برنامه قرار است توسط چه نوع پردازندهای تحتِ چه نوع معماری مونتاژ (اسمبل) شود. برای مثال پردازندهها با انواع معماریهای مختلف وجود دارند که برخی از آنها به صورت x86-x64، x64، ARMv7، aarch64 غیره ... میباشند. شکل یک (کامپایل یک فایل منبع ++C) مرحلهٔ سوم را در نظر داشته باشید که عمل کامپایل فایل سیپلاسپلاس در دو مرحله قبلی یک فایل اجرایی را تولید نمیکند. برنامهای که توصیف شده است، احتمالاً توابعی را در رابطهای برنامهنویسی (API) و یا توابع ریاضی یا توابع مرتبط با I/O را فراخوانی کند که ممکن است شامل فایلهای هدر مانند iostream یا fstream و حتی ماژولهای دیگری که در زبان تعبیه شدهاند را داشته باشد که فایل تولید شده توسط کامپایلر در این مرحله یک فایل شیء نامیده میشود که با پسوند .o به صورت filename.o تولید خواهد شد که علاوه بر دستورالعملهای تبدیل شده به کد ماشین، شامل توابع و دستورالعملهای خارجی نیز میباشد. هرچند در این مرحله دستورات تبدیل به دستورالعملهای قابل فهم توسط پردازنده شدهاند اما فعلاً قابل اجرا نیستند چرا که باید این توابع خارجی افزوده شده را به آن لینک کرد که در مرحلهٔ بعد یعنی مرحلهٔ چهارم اتفاق میافتد. در نهایت مرحلهٔ چهارم فایل با پسوند .o که شامل کدهای تولید شده توسط کامپایلر به زبان ماشین است که پردازندهها میتوانند این دستورات را درک کنند که همراه با کدهای تولید شدهٔ هر کتابخانهٔ دیگری که مورد نیاز است توسط لینکر (لینک شده) و در نهایت جهت تولید یک فایل اجرایی مورد استفاده قرار میگیرند که نوع آن فایل از نوع اجرایی یا در واقع Executable File خواهد بود. شرح کامل فرایند ساخت فایل اجرایی اکثر پروژهها دارای مجموعهای از فایلهای هدر سی++ هستند، که امکان ماژولار شدن در آن را فراهم میکند و مجموعهای از آن میتواند به عنوان بخشهای کوچکی از برنامه محسوب شوند. برای ساخت چنین پروژههایی هر فایل سیپلاسپلاس باید کامپایل شود و سپس فایلهای ساخته شده در قالب شیء (آبجکت) باید همراه توابع و کتابخانههای دیگر لینک (پیوند) شوند. البته هر گام از مراحل کامپایل شامل یک مرحله پیشپردازنده است که دستورالعمل # عمل تغییرات و اصلاحیهها را در فایل متن اعمال میکند. شکل زیر فرایند ساخت چند فایل به صورت همزمان را نشان میدهد: در ادامهٔ این مقاله، مطلبی مرتبط با تنظیمات بیشتر از کامپایلر آمده است که میتوانید آن را مورد مطالعه قرار دهید. -
کامبیز اسدزاده یک موضوع را ارسال کرد در <span class="ipsBadge ipsBadge_pill" style="background-color: #e62f3d; color: #ffffff;" >برنامه نویسی در C و ++C</span>
همانطور که میدانید، در سیپلاسپلاس برای ساخت یک کلاس انتزاعی (در قالب یک ساختار) یا همان Interface تحت کلمات کلیدی virtual امکانپذیر است. به طور کلی کلاسی که متُدهای آن به صورت مجازی اعلان میشوند و شامل هیچ تعریف قبلی نیستند به عنوان کلاس انتزاعی (Abstract) یاد میشوند. برای مثال کلاس زیر را در نظر بگیرید: class Person { public: Person(); virtual ~Person(); virtual void print() = 0; //... }; کلاس Person به عنوان یک کلاس انتزاعی تعریف شد است. چرا که اعضای این کلاس فقط اعلان شده اند و به تنهایی هیچ کاری یا واکنشی را نسبت به خود ندارند. کلمهٔ کلیدی virtual برای تعریف یک تابع از نوع مجازی ضروری است و اَصل پلئومورفیسم (چند ریختی / چند شکلی) را دربر دارد. در اصل اگر قرار باشد کلاسی بنویسید که مربوط به یک ماشین باشد (هر ماشین چه از نوع زمینی، چه از نوع صنعتی، و چه از نوعهای دیگر) دارای کلید استارت (روشن/خاموش)، دارای قدرت موتور و یک سری ویژگیهایی است که ممکن است در هر یک از آنها یکسان و یا متفاوت عمل کند. برای این منظور بهتر است کلاسی به صورت انتزاعی پیاده سازی شده و سپس در هر بخش هر یک از متدها را نسبت به نیاز سفارشی سازی کنیم. فرض میکنیم که نیاز است در یک بازی کلاسی برای دریافت اطلاعات یک خودرو، هواپیمای جنگنده و یا غیره... ایجاد شود. کلاس انتزاعی ما درای ویژگیهای ثابت غیر قابل توسعه و ویژگیهایی دارای قابلیت بازتعریف (جهت توسعه توسط کاربر) را فراهم کرده ایم. به مثال زیر دقت کنید: class Machine { public: Machine() {} virtual ~Machine() {} enum class Start {ON, OFF}; virtual bool start(const Start &start) const final { return true; } virtual std::string name(const std::string &nameValue) const final { return nameValue; } virtual int gears(const int &gears) const final { return gears; }; virtual int power(const int &powerValue) const { return powerValue; } virtual int cylinders(const int &totalValue) const final { return totalValue; } virtual int length(const int &lengthValue) const final { return lengthValue; } virtual int width(const int &widthValue) const final { return widthValue; } virtual std::string engineType() const = 0; }; class Porsche : public Machine { public: enum class EngineType { eSuper, eJuniur, e64, e356, e550, e911 }; enum class Color { White, Black, Red, Blue, Green }; Porsche(EngineType type) { etype = type; } ~Porsche() {} std::string color(const Porsche::Color &colorValue) const { switch (colorValue) { case Color::Black : eColor = "Black"; break; case Color::White : eColor = "White"; break; case Color::Blue : eColor = "Blue"; break; case Color::Red : eColor = "Red"; break; case Color::Green : eColor = "Green"; break; } return eColor; }; std::string engineType() const override { switch (etype) { case EngineType::eSuper : eTypeResult = "Super"; break; case EngineType::eJuniur : eTypeResult = "Juniur"; break; case EngineType::e64 : eTypeResult = "64"; break; case EngineType::e356 : eTypeResult = "356"; break; case EngineType::e550 : eTypeResult = "550"; break; case EngineType::e911 : eTypeResult = "911 Turbo"; break; } return eTypeResult; } private: EngineType etype; mutable std::string eTypeResult; mutable std::string eColor; }; class Aircraft : public Machine { public: enum class EngineType { e2SI, e3W, eAce, eSaturn}; Aircraft(EngineType type) { etype = type; } ~Aircraft() {} int power(const int &powerValue) const override { return powerValue; } std::string engineType() const override { switch (etype) { case EngineType::e2SI : eTypeResult = "2SI"; break; case EngineType::e3W : eTypeResult = "3W"; break; case EngineType::eAce : eTypeResult = "ACE"; break; case EngineType::eSaturn : eTypeResult = "Saturn AL-31 Series"; break; } return eTypeResult; } private: EngineType etype; mutable std::string eTypeResult; }; کلاس Machine دارای مشخصههایی از نوع سطح دسترسی final و pure میباشد که توابع از نوع دسترسی final یک بار برای تمامی کلاسهای ماشینها تعریف شده و توابع pure برای توسعه در نظر گرفته شده اند. در ادامه ما کلاسی برای خودروی Porsche و کلاسی را برای هواپیمای جنگنده Aircraft در نظر گرفتهایم که دارای ویژگیهای اختصاصی باز تعریف شده تحت نامهای engineType و غیره میباشد. تابع اول برای مشخص سازی نوع موتور ماشین (برای خودرو و هواپیما) و تابع بعدی برای مشخص سازی نوع کد رنگ پیاده سازی شده است. دقت کنید که تابع engineType از کلاس والد مشتق و باز توسعه یافته است که توسط کلمهٔ کلیدی override مشخص شده است. این کلمه به کامپایلر اعلان میکند که تابع تعریف شده دقیقاً همان تابع تعریف شده در کلاس والد است (با همان پارامتر و همان نام و همان نوع) در صورتی که این کلمه استفاده نشود تابع باز تعریف شده توسط کامپایلر خطا گرفته خواهد شد. این کلمه کلیدی برای هشدار به کاربری است که قرار است بر اساس کلاس والد کلاس مخصوص خود را توسعه دهد و صرفاً جهت اطلاع رسانی توسط کامپایلر به کاربر مورد استفاده قرار میگیرد. توابع از نوع دسترسی final توابعی هستند که کاربر به هیچ عنوان نمیتواند آنها را دستکاری و باز توسعه دهد. برای مثال تابع name به دلیل اینکه نام در تمامی ماشینها از نوع و ورودی یکسانی برخوردار هستند به صورت ثابت تعریف شده است تا کاربر نتواند این ساختار را به هم بزند. زمانی از final استفاده کنید که قرار نباشد ساختار اصلی متدی از کلاس مشتق شده تغییر یابد. همانطور که مشخص است در کلاس پایه ما توابعی را به صورت ثابت تعریف کرده ایم که نیازی نباشد توسعه دهنده مجدداً ساختاری را تولید کند که ممکن نیست خارج از این قالب باشد. حال وقتی قرار باشد وضعیت روشن بودن یا خاموش بودن یک خودرو را بررسی کنیم کافی است متد start را صدا بزنیم، این خاصیت در هواپیمای جنگنده هم وجود دارد بنابراین در هر دوی آنها یکسان است. اما ممکن است برخی از ویژگیها متفاوت باشد. برای مثال قدرت موتور یک خودرو با یک هواپیمای جندگنده یکسان نیست اما ساختار کلاس آنها مسلماً یکی است. بنابراین کافی است از کلاس Machine مشتق گرفته و در کلاس خودرو و هواپیمای جنگنده آنها را به آن صورتی که نیاز داریم باز تعریف (توسعه) دهیم. نتیجهٔ بر اساس نیازی که از کلاس والد داشتهایم به صورت زیر خواهد بود: Car Start Status : 1 Name : Cayman Engine Type : 911 Turbo Total Gears : 8 Power : 6300 Rpm Total Cylinders : 6 Color : Red Width : 1939 mm Length : 4855 mm Aircraft Start Status : 1 Name : Su 35 Engine Type : Saturn AL-31 Series روشی که در مورد آن توضیح دادیم، در پیاده سازی انواع پروژههای بزرگ و پیچیده (در صنعت بازیسازی، نرمافزارهای یکپارچه و غیره...) کاربرد بسیاری دارید. به عنوان مثال یک موتور بازی سازی پیشرفته و یا کتابخانهها و فریمورکهای توسعه محصول از چنین ویژگیهایی برخوردار میباشند. این پُست ممکن است بهروز رسانی شود.? -
با سلام و خسته نباشید. چندتا سوال داشتم که بعد سرچ در گوگل به پاسخ کامل و جامعی نرسیدم ، امیدوارم اینجا به جواب برسم. به فرض مثال شما یک پروژه برنامه نویسی تحویل میگیرد. پروژه باید توسط زبان برنامه نویسی c++ ساخته شود. ( با این فرض که پروژه در آینده باید توسعه یابد یعنی اصول نگه داری هم باید لحاظ کنید). به چه نحوی باید ساختار برنامه تعیین شود؟ آیا از کل به جز باید عمل کرد یا بالکعس؟! پیاده سازی پروژه باید به چه شکلی باشد ؟! آیا نحوه پیاده سازی با نگه داری (جهت توسعه در آینده ) رابطه تنگاتنگ دارد؟ آیا واقعا هزینه نگه داری برای توسعه یک پروژه از ساخت پروژه بیشتر هزینه خواهد برد؟ ممنون خواهم شد اگر کامل و جامع راهنمایی کنید.
- 4 پاسخ
-
- پیاده سازی
- اصول تفکر
-
(و 3 مورد دیگر)
برچسب زده شده با :