আরও ভাল পারফরম্যান্স পেতে এম্বেড থাকা সফ্টওয়্যারটির জন্য ফাংশনগুলি লেখার সময় সেরা পদ্ধতির কী? [বন্ধ]

13

বন্ধ । এই প্রশ্নটি মতামত ভিত্তিক । এটি বর্তমানে উত্তর গ্রহণ করছে না।

এই প্রশ্নটি উন্নত করতে চান? প্রশ্নটি আপডেট করুন যাতে পোস্টটি সম্পাদনা করে সত্য এবং উদ্ধৃতি দিয়ে উত্তর দেওয়া যায় ।

2 বছর আগে বন্ধ ।

আমি মাইক্রোকন্ট্রোলারদের জন্য কয়েকটি গ্রন্থাগার দেখেছি এবং তাদের ফাংশনগুলি একবারে একটি কাজ করে। উদাহরণস্বরূপ, এর মতো কিছু:

void setCLK()
{
    // Code to set the clock
}

void setConfig()
{
    // Code to set the config
}

void setSomethingElse()
{
   // 1 line code to write something to a register.
}

তারপরে অন্যান্য ক্রিয়াকলাপগুলি আসুন যা এই 1 লাইন কোডটি অন্য উদ্দেশ্যে পরিবেশন করতে একটি ফাংশনযুক্ত ব্যবহার করে। উদাহরণ স্বরূপ:

void initModule()
{
   setCLK();
   setConfig();
   setSomethingElse();
}

আমি নিশ্চিত নই, তবে আমি বিশ্বাস করি যে এই সময়টি কোনও ফাংশন বলা বা বের হওয়ার সময় প্রতি ঝাঁকুনিতে আরও কল তৈরি করা এবং ফিরতি ঠিকানাগুলি স্ট্যাক করার ওভারহেড তৈরি করা হবে। এবং এটি প্রোগ্রামটি ধীরে ধীরে কাজ করবে?

আমি অনুসন্ধান করেছি এবং সর্বত্র তারা বলেছে যে প্রোগ্রামিংয়ের থাম্ব নিয়মটি হ'ল কোনও ফাংশনটিতে কেবল একটি কাজ সম্পাদন করা উচিত।

সুতরাং আমি যদি সরাসরি কোনও ইনসিমোডুল ফাংশন মডিউলটি লিখি যা ঘড়িটি সেট করে, কিছু পছন্দসই কনফিগারেশন যুক্ত করে এবং ফাংশনগুলি কল না করেই অন্য কিছু করে। এম্বেড থাকা সফ্টওয়্যারটি লেখার সময় এটি কী খারাপ দৃষ্টিভঙ্গি?

সম্পাদনা 2:

দেখে মনে হচ্ছে অনেক লোক এই প্রশ্নটি বুঝতে পেরেছে যেন আমি কোনও প্রোগ্রামকে অনুকূলিত করার চেষ্টা করছি। না, আমার করার ইচ্ছা নেই । আমি কম্পাইলারটি এটি করতে দিচ্ছি, কারণ এটি আমার চেয়ে ভাল সর্বদা (আমি আশা করি না!) হতে চলেছে।
কিছু উদাহরণ শুরু করার কোডকে উপস্থাপন করে এমন একটি উদাহরণ বেছে নেওয়ার জন্য আমার উপর সমস্ত দোষ । প্রারম্ভিককরণের উদ্দেশ্যে করা ফাংশন কল সম্পর্কে প্রশ্নের কোনও উদ্দেশ্য নেই। আমার প্রশ্নটি হ'ল কোনও নির্দিষ্ট কাজকে মাল্টি-লাইনের ছোট ফাংশনগুলিতে বিভক্ত করা ( সুতরাং লাইনটি প্রশ্নের বাইরে নয় ) কোনও নেস্টেড ফাংশন ছাড়াই দীর্ঘ ফাংশনটি লেখার কোনও সুবিধা আছে?

দয়া করে @ জঙ্কের উত্তরে সংজ্ঞায়িত পাঠযোগ্যতা বিবেচনা করুন ।

microcontroller c

— MaNyYaCk
সূত্র

28

আপনি খুব নিখুঁত (অপমান হিসাবে বোঝানো হয়নি) যদি আপনি বিশ্বাস করেন যে কোনও যুক্তিসঙ্গত সংকলক অন্ধভাবে কোডকে বাইনারিগুলিতে লিখিত হিসাবে পরিণত করবে। বেশিরভাগ আধুনিক সংকলকগুলি যখন কোনও রুটিন আরও ভালভাবে অন্তর্ভুক্ত হয় তখন এটি সনাক্ত করতে বেশ ভাল এবং এমনকি যখন কোনও রেজিস্টার বনাম র্যাম অবস্থান ব্যবহার করা উচিত তখন একটি ভেরিয়েবল রাখা যায়। অপ্টিমাইজেশনের দুটি নিয়ম অনুসরণ করুন: 1) অপ্টিমাইজ করবেন না। 2) এখনও অপ্টিমাইজ করবেন না । আপনার কোডটি পঠনযোগ্য এবং রক্ষণাবেক্ষণযোগ্য করুন এবং একটি কার্যনির্বাহী সিস্টেমের প্রোফাইলিংয়ের পরে কেবল অনুকূলিতকরণের জন্য দেখুন।

— akohlsmith

10

@akohlsmith আইআইআরসি অপ্টিমাইজেশনের তিনটি নিয়ম হ'ল : 1) না! 2) না আসলেই না! 3) অপ্টিমাইজ প্রথম প্রোফাইল, তারপর এবং শুধুমাত্র তারপর আপনি অবশ্যই - Michael_A._Jackson

— esoterik

3

কেবল মনে রাখবেন যে "অকালীন অপটিমাইজেশন হ'ল প্রোগ্রামিংয়ে সমস্ত মন্দ (বা এর বেশিরভাগ অংশের মূল)" - নুথ

— মাওগ বলেছেন মনিকা পুনরুদ্ধার করুন

1

@ মাওগ: অপারেটিভ শব্দটির অকাল রয়েছে । (সেই কাগজের পরবর্তী অনুচ্ছেদে যেমন ব্যাখ্যা করা হয়েছে। আক্ষরিক অর্থেই পরবর্তী বাক্য: "তবুও আমাদের সেই সমালোচনামূলক 3% তে আমাদের সুযোগগুলি পাস করা উচিত নয়।") আপনার প্রয়োজন ততক্ষণ অনুকূলিত হবেন না - আপনি ধীর পাবে না আপনার প্রোফাইলের জন্য কিছু রয়েছে ততক্ষণে বিটগুলি - তবে হতাশায় জড়িত হবেন না, উদাহরণস্বরূপ কাজের জন্য স্পষ্টত ভুল সরঞ্জাম ব্যবহার করে।

— সিএইচও

1

@ মাউগ আমি জানি না কেন আমি কেন অপ্টিমাইজেশান সম্পর্কিত উত্তর / প্রতিক্রিয়া পেয়েছি, যেহেতু আমি কখনই শব্দটির কথা উল্লেখ করি নি এবং আমি এটি করার ইচ্ছা করি। আরও ভাল পারফরম্যান্স অর্জনের জন্য এম্বেডড প্রোগ্রামিংয়ে ফাংশনগুলি কীভাবে লিখবেন সে সম্পর্কে প্রশ্ন আরও অনেক বেশি।

— MaNyYaaCk

28

যুক্তিযুক্তভাবে, আপনার উদাহরণে পারফরম্যান্সটি বিবেচনা করবে না, কারণ কোডটি একবার স্টার্টআপে একবার চালানো হয়।

থাম্বের একটি নিয়ম আমি ব্যবহার করি: আপনার কোডটি যতটা সম্ভব পঠনযোগ্য লিখুন এবং কেবলমাত্র অনুকূলিতকরণ শুরু করুন যদি আপনি লক্ষ্য করেন যে আপনার সংকলকটি এর যাদুটি সঠিকভাবে করছে না।

কোনও আইএসআর-তে ফাংশন কলের দাম স্টোরেজ এবং সময়সীমার ক্ষেত্রে প্রারম্ভকালে কোনও ফাংশন কলের সমান হতে পারে। তবে, আইএসআর চলাকালীন সময়ের প্রয়োজনীয়তাগুলি আরও অনেক সমালোচনামূলক হতে পারে।

তদ্ব্যতীত, অন্যদের দ্বারা ইতিমধ্যে লক্ষ্য করা গেছে, কোনও ফাংশন কলের দাম (এবং 'দামের অর্থ) প্ল্যাটফর্ম, সংকলক, সংকলক অপ্টিমাইজেশন সেটিং এবং অ্যাপ্লিকেশনগুলির প্রয়োজনীয়তার দ্বারা পৃথক হয়। একটি 8051 এবং একটি কর্টেক্স-এম 7 এবং একটি পেসমেকার এবং একটি হালকা স্যুইচ এর মধ্যে একটি বিশাল পার্থক্য থাকবে।

— Lanting
সূত্র

6

আইএমও দ্বিতীয় অনুচ্ছেদে গা bold় এবং শীর্ষে থাকা উচিত। ব্যাটে ডানদিকে সঠিক অ্যালগরিদম এবং ডেটা স্ট্রাকচার বেছে নেওয়ার ক্ষেত্রে কোনও ভুল নেই, তবে ফাংশন কল ওভারহেড সম্পর্কে চিন্তিত হওয়া অবধি যদি না আপনি সনাক্ত করেন যে এটি একটি সত্যিকারের বাধা অবশ্যই অকালীন অপটিমাইজেশন, এবং এড়ানো উচিত নয়।

— ফান্ড মনিকার লসুইট

11

আমি ভাবার কোনও সুবিধা নেই (তবে নীচে জেসনসকে দ্রষ্টব্য দেখুন), কোনও ফাংশন বা সাবরুটিন হিসাবে কোডের একটি লাইন মোড়ানো। সম্ভবত আপনি এই ফাংশনটির নাম "পঠনযোগ্য" রাখতে পারেন। তবে আপনি ঠিক পাশাপাশি লাইন মন্তব্য করতে পারেন। এবং যেহেতু কোনও ফাংশনে কোডের একটি লাইন মোড়ানোর জন্য কোড মেমোরি, স্ট্যাক স্পেস এবং কার্যকর করার সময় লাগে আমার কাছে মনে হয় এটি বেশিরভাগই পাল্টা-উত্পাদনশীল। একটি শিক্ষণ পরিস্থিতিতে? এটি কিছু অর্থ হতে পারে। তবে এটি নির্ভর করে শিক্ষার্থীদের ক্লাস, তাদের প্রস্তুতি আগে, পাঠ্যক্রম এবং শিক্ষকের উপর। বেশিরভাগ ক্ষেত্রে, আমি মনে করি এটি একটি ভাল ধারণা নয়। তবে এটাই আমার মতামত।

যা আমাদের নীচের লাইনে নিয়ে আসে। আপনার বিস্তৃত প্রশ্ন ক্ষেত্রটি কয়েক দশক ধরে, কিছু বিতর্কের বিষয় এবং আজও কিছু বিতর্কের বিষয় হয়ে দাঁড়িয়েছে। সুতরাং, কমপক্ষে আমি আপনার প্রশ্নটি পড়ার সাথে সাথে এটি আমার কাছে একটি মতামত ভিত্তিক প্রশ্ন বলে মনে হয়েছে (যেমনটি আপনি এটি জিজ্ঞাসা করেছিলেন))

এটিকে মতামত-ভিত্তিক হওয়া থেকে দূরে সরিয়ে নেওয়া যেতে পারে, যদি আপনি পরিস্থিতি সম্পর্কে আরও বিশদ হন এবং আপনি যে লক্ষ্যগুলি প্রাথমিক হিসাবে ধরেছিলেন তা সাবধানতার সাথে বর্ণনা করে। আপনি আপনার পরিমাপের সরঞ্জামগুলি যত ভাল নির্ধারণ করবেন, উত্তরগুলি তত বেশি উদ্দেশ্য হতে পারে।

বিস্তৃতভাবে বলতে গেলে, যে কোনও কোডিংয়ের জন্য আপনি নিম্নলিখিতটি করতে চান । (নীচের জন্য, আমি ধরে নেব যে আমরা লক্ষ্যগুলি অর্জন করে এমন সমস্ত পদ্ধতির সাথে তুলনা করছি vious স্পষ্টতই, যে কোনও কোড প্রয়োজনীয় কাজ সম্পাদন করতে ব্যর্থ হয় এমন কোডের চেয়ে খারাপ এটি কোড লিখিতভাবে নির্বিশেষে সফল হয়।)

আপনার পদ্ধতির বিষয়ে সামঞ্জস্য বজায় রাখুন, যাতে আপনার কোড পড়ার অন্য কোনওটি কীভাবে আপনি আপনার কোডিং প্রক্রিয়াটির কাছে যান তার বোঝার বিকাশ করতে পারে। অসঙ্গত হওয়া সম্ভবত সবচেয়ে খারাপ অপরাধ। এটি কেবল অন্যের পক্ষেই অসুবিধা সৃষ্টি করে না, বরং কয়েক বছর পরে কোডটিতে ফিরে আসা আপনার পক্ষে কঠিন করে তোলে।
সম্ভাব্য ডিগ্রীতে, চেষ্টা করে জিনিসগুলি সাজিয়ে রাখুন যাতে অর্ডার বিবেচনা না করেই বিভিন্ন কার্যকরী বিভাগের সূচনা করা যায়। যেখানে অর্ডিংয়ের প্রয়োজন হয়, যদি এটি দুটি অত্যন্ত সম্পর্কিত সাব-ফাংশনগুলির কাছাকাছি সংযোগের কারণে হয় , তবে উভয়ের জন্য একটি একক সূচনা বিবেচনা করুন যাতে কোনও ক্ষতি না করেই এটি পুনরায় সাজানো যায়। যদি এটি সম্ভব না হয় তবে প্রারম্ভিক ক্রমটির প্রয়োজনীয় আদেশটি নথি করুন।
সম্ভব হলে ঠিক এক জায়গায় জ্ঞানকে গুটিয়ে নিন । কনস্ট্যান্টগুলি কোডের সমস্ত জায়গায় নকল করা উচিত নয়। কিছু পরিবর্তনশীলগুলির জন্য সমাধান করা সমীকরণগুলি কেবলমাত্র একটি জায়গায় উপস্থিত থাকতে হবে। ইত্যাদি। যদি আপনি নিজেকে বিভিন্ন স্থানে কিছু প্রয়োজনীয় আচরণ সম্পাদন করে এমন কিছু লাইন সেট করে অনুলিপি এবং আটকানো দেখতে পান তবে সেই জ্ঞানকে এক জায়গায় ক্যাপচার করার জন্য এবং যেখানে প্রয়োজন সেখানে এটি ব্যবহার করার উপায় বিবেচনা করুন। উদাহরণস্বরূপ, আপনার যদি গাছের কাঠামো থাকে যা অবশ্যই একটি নির্দিষ্ট উপায়ে চলতে হবে, নাআপনার গাছের নোডগুলির মধ্য দিয়ে লুপ করা দরকার যেখানে এবং প্রতিটি জায়গায় ট্রি-ওয়াকিং কোডটি প্রতিলিপি করুন। পরিবর্তে, গাছের হাঁটার পদ্ধতিটি এক জায়গায় ক্যাপচার করুন এবং এটি ব্যবহার করুন। এইভাবে, যদি গাছের পরিবর্তন হয় এবং হাঁটার পদ্ধতি পরিবর্তিত হয় তবে আপনার উদ্বেগের জন্য কেবলমাত্র একটি জায়গা রয়েছে এবং বাকী সমস্ত কোড "ঠিক ঠিক কাজ করে।"
যদি আপনি আপনার রুটিনগুলি সমস্ত বিশাল কাগজের ফ্ল্যাট শিটের উপরে ছড়িয়ে দেন, তীরগুলি অন্য রুটিন দ্বারা ডেকে আনা হয় সেগুলি সংযুক্ত করে, আপনি কোনও অ্যাপ্লিকেশনটিতে দেখবেন সেখানে প্রচুর এবং প্রচুর তীরযুক্ত রুটিনের "ক্লাস্টার" থাকবে any নিজেদের মধ্যে কিন্তু গোষ্ঠীর বাইরে কেবল কয়েকটি তীর। সুতরাং ঘনিষ্ঠভাবে মিলিত রুটিনগুলির ঘনিষ্ঠভাবে মিলিত রুটিনগুলির এবং অন্যান্য গ্রুপগুলির মধ্যে আলগাভাবে সংযুক্ত সংযোগগুলির প্রাকৃতিক সীমানা থাকবে । আপনার কোডটিকে মডিউলগুলিতে সংগঠিত করতে এই সত্যটি ব্যবহার করুন। এটি আপনার কোডের আপাত জটিলতা যথেষ্ট পরিমাণে সীমাবদ্ধ করবে।

উপরের সমস্ত কোডিং সম্পর্কে সাধারণভাবে সত্য। আমি প্যারামিটারগুলির ব্যবহার, স্থানীয় বা স্ট্যাটিক গ্লোবাল ভেরিয়েবল ইত্যাদির বিষয়ে আলোচনা করিনি কারণ এর কারণ হ'ল এম্বেড করা প্রোগ্রামিংয়ের জন্য অ্যাপ্লিকেশন স্পেসটি প্রায়শই চরম এবং অত্যন্ত তাৎপর্যপূর্ণ নতুন প্রতিবন্ধকতা রাখে এবং প্রতিটি এম্বেডযুক্ত অ্যাপ্লিকেশন নিয়ে আলোচনা না করে এগুলি সব নিয়ে আলোচনা করা অসম্ভব। এবং যে এখানে যাই হোক না কেন।

এই সীমাবদ্ধতাগুলি এর যে কোনও (এবং আরও) হতে পারে:

গুরুতর ব্যয়ের সীমাবদ্ধতার জন্য মিনিস্কুল র‌্যাম সহ অত্যন্ত আদিম এমসিইউ প্রয়োজন এবং প্রায় আই / ও পিন-কাউন্ট নেই। এগুলির জন্য, সম্পূর্ণ নতুন নিয়ম প্রযোজ্য। উদাহরণস্বরূপ, আপনাকে কোড কোড লিখতে হতে পারে কারণ সেখানে কোডের বেশি জায়গা নেই code আপনাকে কেবলমাত্র স্থিতিশীল ভেরিয়েবলগুলি ব্যবহার করতে হতে পারে কারণ স্থানীয় ভেরিয়েবলগুলির ব্যবহার খুব ব্যয়বহুল এবং সময় সাপেক্ষ। আপনাকে সাব্রুটাইনগুলির অত্যধিক ব্যবহার এড়াতে হবে কারণ (উদাহরণস্বরূপ, কিছু মাইক্রোচিপ পিআইসি অংশ) কেবলমাত্র 4 টি হার্ডওয়্যার রেজিস্টার রয়েছে যাতে সাব্রোটিনের ফেরতের ঠিকানাগুলি সংরক্ষণ করতে হয়। সুতরাং আপনার কোডটি নাটকীয়ভাবে "সমতল" করতে হতে পারে। প্রভৃতি
গুরুতর সীমাবদ্ধতার জন্য সতর্কতার সাথে কোড তৈরির প্রয়োজন এমসিইউর বেশিরভাগটি শুরু এবং বন্ধ করে দেওয়া এবং পূর্ণ গতিতে চলার সময় কোডের প্রয়োগের সময় গুরুতর সীমাবদ্ধতা স্থাপন করা। আবার এর জন্য কিছু সময় সমাবেশের কোডিংয়ের প্রয়োজন হতে পারে require
গুরুতর সময় প্রয়োজন। উদাহরণস্বরূপ, এমন সময় আছে যেখানে আমি নিশ্চিত করেছিলাম যে ওপেন-ড্রেন 0 সংক্রমণকে ঠিক একই সংখ্যার চক্রটি 1 সংক্রমণ হিসাবে গ্রহণ করতে হয়েছিল। এবং এই একই লাইনের নমুনাটিও সম্পাদন করতে হয়েছিল এই সময়ের সাথে সঠিক আপেক্ষিক পর্যায়ে। এর অর্থ হ'ল সি এখানে ব্যবহার করা যাবে না। এই গ্যারান্টিটি তৈরি করার একমাত্র সম্ভাব্য উপায় হ'ল সাবধানে অ্যাসেম্বলি কোডটি তৈরি করা। (এবং তারপরেও সবসময় সমস্ত ALU ডিজাইনে থাকে না))

ইত্যাদি। (লাইফ-ক্রিটিকাল ইনস্ট্রুমেন্টাল জন্য ওয়্যারিং কোডের নিজস্ব একটি পুরো বিশ্ব রয়েছে))

এখানে আপশটটি হ'ল এম্বেড করা কোডিং প্রায়শই কিছু অবাধ-মুক্ত নয়, যেখানে আপনি কোনও ওয়ার্কস্টেশনে আপনার পছন্দ মতো কোড করতে পারেন। বিভিন্ন সময়ে খুব কঠিন সীমাবদ্ধতার জন্য প্রায়শই তীব্র, প্রতিযোগিতামূলক কারণ রয়েছে। এবং এগুলি আরও প্রচলিত এবং স্টক উত্তরের বিরুদ্ধে দৃ strongly়তার সাথে তর্ক করতে পারে ।

পঠনযোগ্যতা সম্পর্কে, আমি দেখতে পেলাম যে কোডটি যদি ধারাবাহিকভাবে লেখা হয় তবে আমি এটি পড়তে শিখতে পারি। এবং যেখানে কোড অবলম্বন করার ইচ্ছাকৃত প্রচেষ্টা নেই। সত্যিকারের অনেক বেশি প্রয়োজন নেই।

পঠনযোগ্য কোডটি বেশ দক্ষ হতে পারে এবং এটি ইতিমধ্যে উল্লিখিত উপরের সমস্ত প্রয়োজনীয়তা পূরণ করতে পারে । মূল কথাটি হ'ল আপনি যে কোডটি লিখেছেন তার প্রতিটি লাইন বিধানসভা বা মেশিন স্তরে কী উত্পন্ন করে তা আপনি পুরোপুরি বুঝতে পেরেছেন। সি ++ এখানে প্রোগ্রামারের উপর মারাত্মক বোঝা ফেলেছে কারণ অনেকগুলি পরিস্থিতি রয়েছে যেখানে সি ++ কোডের অভিন্ন স্নিপেটগুলি আসলে মেশিন কোডের বিভিন্ন স্নিপেটগুলি উত্পন্ন করে যার বিস্তৃত পারফরম্যান্স রয়েছে। তবে সি, সাধারণত বেশিরভাগ ক্ষেত্রেই একটি ভাষা "আপনি যা দেখেন তা হ'ল" is সুতরাং এটি যে ক্ষেত্রে নিরাপদ।

জেসনস প্রতি সম্পাদনা করুন:

আমি ১৯8৮ সাল থেকে সি এবং সি ++ প্রায় 1987 সাল থেকে ব্যবহার করছি এবং মেইনফ্রেম, মিনি কম্পিউটার এবং এম্বেড এম্বেডেড উভয় ক্ষেত্রেই উভয় ব্যবহার করার অভিজ্ঞতা পেয়েছি।

জেসন একটি সংশোধক হিসাবে 'ইনলাইন' ব্যবহার সম্পর্কে একটি মন্তব্য নিয়ে আসে। (আমার দৃষ্টিতে এটি তুলনামূলকভাবে "নতুন" সামর্থ্য কারণ এটি আমার জীবনের অর্ধেক বা তার বেশি সি এবং সি ++ ব্যবহার করে কেবল উপস্থিত ছিল না)) ইনলাইন ফাংশনগুলির ব্যবহার আসলে এই জাতীয় কলগুলি করতে পারে (এমনকি একটি লাইনের জন্যও) কোড) বেশ ব্যবহারিক। সংকলক প্রয়োগ করতে পারে এমন টাইপিংয়ের কারণে ম্যাক্রো ব্যবহার করার চেয়ে এটি আরও বেশি ভাল, যেখানে সম্ভব।

তবে সীমাবদ্ধতাও রয়েছে। প্রথমটি হ'ল আপনি "ইঙ্গিতটি নিতে" সংকলকের উপর নির্ভর করতে পারবেন না। এটা হতে পারে বা নাও হতে পারে. এবং ইঙ্গিতটি না নেওয়ার ভাল কারণ রয়েছে। (একটি সুস্পষ্ট উদাহরণের জন্য, যদি ফাংশনের ঠিকানা নেওয়া হয় তবে এটির জন্য ফাংশনটি ইনস্ট্যান্টেশন এবং কলটি করার জন্য ঠিকানা ব্যবহারের প্রয়োজন ... একটি কল প্রয়োজন then তখন কোডটি ইনলাইন করা যায় না)) রয়েছে অন্যান্য কারণ হিসাবে। সংকলকগুলির বিভিন্ন ধরণের মানদণ্ড থাকতে পারে যার মাধ্যমে তারা কীভাবে ইঙ্গিতটি পরিচালনা করতে পারে তা বিচার করে। এবং প্রোগ্রামার হিসাবে, এর অর্থ আপনার অবশ্যই হবেসংকলকটির সেই দিকটি সম্পর্কে জানতে কিছুটা সময় ব্যয় করুন অথবা অন্যথায় আপনি ত্রুটিযুক্ত ধারণাগুলির ভিত্তিতে সিদ্ধান্ত নিতে পারেন। সুতরাং এটি কোডের লেখক এবং যে কোনও পাঠক এবং কোডটি অন্য কোনও সংকলকটিতে পোর্ট করার পরিকল্পনা করছে এমন উভয়কেই বোঝা যুক্ত করে।

এছাড়াও, সি এবং সি ++ সংকলক পৃথক সংকলন সমর্থন করে। এর অর্থ হ'ল তারা প্রকল্পের জন্য অন্য কোনও সম্পর্কিত কোড সংকলন না করে সি বা সি ++ কোডের এক টুকরা সংকলন করতে পারবেন। কোডটি ইনলাইন করার জন্য, সংকলকটি অন্যথায় এটি করতে পারে তা ধরে নিয়েই এটির কেবলমাত্র "সুযোগ" হিসাবে ঘোষণা থাকতে হবে না তবে এটির সংজ্ঞাও থাকতে হবে। সাধারণত, প্রোগ্রামাররা যদি তারা 'ইনলাইন' ব্যবহার করে থাকে তবে বিষয়টি নিশ্চিত হওয়ার জন্য কাজ করবে। তবে ভুলগুলি ক্রাইপ করা সহজ।

সাধারণভাবে, আমি যেখানে আমি এটি উপযুক্ত বলে মনে করি সেখানে ইনলাইন ব্যবহার করি, তখন আমি ধরেই নিয়েছি যে আমি এটির উপর নির্ভর করতে পারি না। যদি পারফরম্যান্স একটি উল্লেখযোগ্য প্রয়োজনীয়তা হয় এবং আমি মনে করি যে ওপি ইতিমধ্যে স্পষ্টভাবে লিখে ফেলেছে যে তারা যখন আরও "কার্যকরী" পথে যায় তখন একটি উল্লেখযোগ্য পারফরম্যান্স হিট হয়েছিল, তবে আমি অবশ্যই কোডিং অনুশীলন হিসাবে ইনলাইনে নির্ভর করা এড়াতে পছন্দ করব এবং পরিবর্তে কিছুটা ভিন্ন, তবে লিখন কোডের সম্পূর্ণ সুসংগত প্যাটার্ন অনুসরণ করবে।

পৃথক সংকলন পদক্ষেপের জন্য 'ইনলাইন' এবং সংজ্ঞাগুলি "সুযোগ" সম্পর্কে একটি চূড়ান্ত নোট। লিঙ্কিং পর্যায়ে কাজটি সম্পাদন করা সম্ভব (সর্বদা নির্ভরযোগ্য নয়)। কোনও লিঙ্কারকে 'ইনলাইন' অনুরোধগুলিতে কাজ করার অনুমতি দেওয়ার জন্য যদি কেবল কোনও সি / সি ++ সংকলক অবজেক্ট ফাইলগুলিতে পর্যাপ্ত বিবরণ দেয় তবে এটি ঘটতে পারে। আমি ব্যক্তিগতভাবে কোনও লিঙ্কার সিস্টেম (মাইক্রোসফ্টের বাইরে) এর অভিজ্ঞতা লাভ করি নি যা এই ক্ষমতাটিকে সমর্থন করে। তবে তা ঘটতে পারে। আবার, এটির উপর নির্ভর করা উচিত কিনা তা নির্ভর করবে পরিস্থিতির উপর। তবে আমি সাধারণত ধরে নিই যে এটি লিঙ্কারের উপরে চালিত হয়নি, যদি না আমি ভাল প্রমাণের ভিত্তিতে অন্যথায় জানি না। এবং যদি আমি এটির উপর নির্ভর করি তবে এটি একটি বিশিষ্ট জায়গায় নথিভুক্ত করা হবে।

সি ++

আগ্রহী ব্যক্তিদের জন্য, এম্বেড থাকা অ্যাপ্লিকেশনগুলির কোডিংয়ের সময় আমি কেন প্রস্তুত থাকব তার জন্য এখন কেন আমি সি ++ সম্পর্কে মোটামুটি সতর্ক থাকি তার একটি উদাহরণ এখানে। আমি এমন কিছু পদ টস করব যা আমার মনে হয় যে সমস্ত এম্বেড থাকা সি ++ প্রোগ্রামারকে শীতল জানা দরকার :

আংশিক টেম্পলেট বিশেষীকরণ
vtables
ভার্চুয়াল বেস অবজেক্ট
অ্যাক্টিভেশন ফ্রেম
অ্যাক্টিভেশন ফ্রেম উন্মুক্ত
কনস্ট্রাক্টরগুলিতে স্মার্ট পয়েন্টার ব্যবহার এবং কেন
রিটার্ন মান অপ্টিমাইজেশন

এটি কেবল একটি সংক্ষিপ্ত তালিকা। আপনি যদি এই শর্তাদি সম্পর্কে ইতিমধ্যে সবকিছু জানেন না এবং কেন আমি সেগুলি তালিকাভুক্ত করেছি (এবং আরও অনেকগুলি আমি এখানে তালিকাবদ্ধ করিনি) তবে আমি এম্বেডযুক্ত কাজের জন্য সি ++ ব্যবহারের বিরুদ্ধে পরামর্শ দেব, যদি না এটি প্রকল্পের বিকল্প না হয় unless ।

আসুন কেবল একটি স্বাদ পেতে সি ++ ব্যতিক্রম শব্দার্থবিজ্ঞানগুলিতে এক ঝলক দেখি।

$A$ $B$

$A$

   .
   .
   foo ();
   String s;
   foo ();
   .
   .

$A$

$B$

সি ++ সংকলক foo () এ প্রথম কলটি দেখেছে এবং foo () ব্যতিক্রম ছুঁড়ে ফেললে কেবলমাত্র একটি সাধারণ অ্যাক্টিভেশন ফ্রেমটিকে আনইন্ডাইন্ড হতে দেয়। অন্য কথায়, সি ++ সংকলক জানেন যে ব্যতিক্রম হ্যান্ডলিংয়ের সাথে জড়িত ফ্রেম আনওয়াইন্ড প্রক্রিয়া সমর্থন করার জন্য এই মুহুর্তে কোনও অতিরিক্ত কোডের প্রয়োজন নেই।

তবে একবার স্ট্রিং গুলি তৈরি হয়ে গেলে, সি ++ সংকলক জানে যে কোনও ফ্রেম খুলে দেওয়ার অনুমতি দেওয়ার আগে এটি সঠিকভাবে ধ্বংস করতে হবে, যদি পরে কোনও ব্যতিক্রম ঘটে। সুতরাং foo () এর দ্বিতীয় কলটি প্রথম থেকে শব্দার্থগতভাবে পৃথক। যদি foo () এর 2 র্থ কলটি একটি ব্যতিক্রম ছোঁড়ে (যা এটি করতে পারে বা না পারে), সাধারণ ফ্রেমটি উন্মুক্ত না হওয়ার আগে সংকলকটিতে অবশ্যই স্ট্রিংয়ের ধ্বংসটি পরিচালনা করার জন্য নকশাকৃত কোড স্থাপন করা উচিত। এটি foo () এ প্রথম কল করার জন্য প্রয়োজনীয় কোডের চেয়ে আলাদা ।

( এই সমস্যাটি সীমাবদ্ধ করতে সহায়তার জন্য সি ++ এ অতিরিক্ত সজ্জা যুক্ত করা সম্ভব But তবে বাস্তব কথাটি হ'ল সি ++ ব্যবহারকারী প্রোগ্রামারদের অবশ্যই তাদের প্রতিটি কোডের কোডের লাইন সম্পর্কে আরও সচেতন হতে হবে))

সি এর ম্যালোক থেকে ভিন্ন, সি ++ এর নতুন ব্যবহার যখন এটি কাঁচা মেমরি বরাদ্দ করতে পারে না তখন সিগন্যাল করতে ব্যতিক্রম ব্যবহার করে। সুতরাং 'গতিশীল_কাস্ট' করবে। (স্ট্রস্ট্রুপের তৃতীয় সংস্করণ, সি ++ প্রোগ্রামিং ল্যাঙ্গুয়েজ, সি ++ এর মান ব্যতিক্রমগুলির জন্য পৃষ্ঠা 384 এবং 385 দেখুন See) সংকলকরা এই আচরণটি অক্ষম করার অনুমতি দিতে পারে। তবে সাধারণভাবে উত্পন্ন কোডটিতে সঠিকভাবে গঠিত ব্যতিক্রম হ্যান্ডলিং প্রলোগগুলি এবং এপিওলোগগুলির কারণে আপনি কিছুটা ওভারহেড ব্যয় করতে পারেন, এমনকি যখন ব্যতিক্রমগুলি প্রকৃতপক্ষে সঞ্চালিত হয় না এবং এমনকি যখন ফাংশনটি সংকলন করা হয় তখন বাস্তবে কোনও ব্যতিক্রম হ্যান্ডলিং ব্লক না থাকে। (স্ট্রাস্ট্রাপ প্রকাশ্যে এ নিয়ে শোক প্রকাশ করেছে।)

আংশিক টেম্পলেট বিশেষীকরণ ছাড়া (সমস্ত সি ++ সংকলক এটি সমর্থন করে না), টেমপ্লেটগুলির ব্যবহার এম্বেডড প্রোগ্রামিংয়ের জন্য দুর্যোগের বানান করতে পারে। এটি ছাড়াই কোড ব্লুম একটি মারাত্মক ঝুঁকি যা একটি ফ্ল্যাশ-এ একটি ক্ষুদ্র-স্মৃতি এমবেডেড প্রকল্পকে হত্যা করতে পারে।

যখন কোনও সি ++ ফাংশন কোনও অবজেক্ট ফেরত দেয় একটি নামবিহীন সংকলক অস্থায়ী তৈরি এবং ধ্বংস হয়। কিছু সি ++ সংকলক কার্যকর কোড সরবরাহ করতে পারে যদি কোনও অবজেক্ট কনস্ট্রাক্টর স্থানীয় অবজেক্টের পরিবর্তে রিটার্ন স্টেটমেন্টে ব্যবহার করা হয় তবে একটি বস্তুর দ্বারা নির্মাণ ও ধ্বংসের প্রয়োজনীয়তা হ্রাস করে। তবে প্রতিটি সংকলক এটি করে না এবং অনেক সি ++ প্রোগ্রামার এমনকি এই "রিটার্ন মান অপ্টিমাইজেশন" সম্পর্কে অবগত নয়।

একটি একক প্যারামিটার ধরণের সাথে কোনও অবজেক্ট কনস্ট্রাক্টর সরবরাহ করা সি ++ কম্পাইলারের সাথে প্রোগ্রামারের কাছে সম্পূর্ণ অপ্রত্যাশিত উপায়ে দুটি ধরণের রূপান্তর পথ সন্ধান করতে পারে। এই ধরণের "স্মার্ট" আচরণ সি এর অংশ নয়

একটি বেস ধরণ নির্দিষ্ট করে একটি ক্যাচ ক্লজটি একটি ছোঁড়া der ব্যতিক্রম দুর্দশার একটি অসাধারণ উত্স নয় (যখন আপনি মনে করেন আপনি নিজের এম্বেডড কোডটিতে ব্যতিক্রমও বহন করতে পারেন))

সি ++ সংকলকগুলি অনিচ্ছাকৃত ফলাফল সহ স্বয়ংক্রিয়ভাবে আপনার জন্য কন্সট্রাক্টর, ডেস্ট্রাক্টর, কপি কনস্ট্রাক্টর এবং এসাইনমেন্ট অপারেটর তৈরি করতে পারে। এটির বিশদ সহ সুবিধা পেতে সময় লাগে।

বেস অবজেক্টগুলির অ্যারে গ্রহণ করে কোনও ফাংশনে ডারেক্টেড অবজেক্টের অ্যারেগুলি পাস করা, খুব কমই সংকলক সতর্কতা উত্পন্ন করে তবে প্রায়শই সবসময় ভুল আচরণের ফল পাওয়া যায়।

যেহেতু সি ++ অবজেক্ট কনস্ট্রাক্টারে একটি ব্যতিক্রম ঘটে তখন আংশিকভাবে নির্মিত বস্তুর ধ্বংসকারীকে ডাকে না, কনস্ট্রাক্টরের ব্যতিক্রমগুলি পরিচালনা করা সাধারণত "স্মার্ট পয়েন্টার" নির্দেশ দেয় যাতে গ্যারান্টির জন্য কনস্ট্রাক্টরের নির্মিত টুকরাগুলি যথাযথভাবে ধ্বংস হয়ে যায় যদি সেখানে কোনও ব্যতিক্রম ঘটে থাকে। । (স্ট্র্যাস্ট্রপ, পৃষ্ঠা ৩7 36 এবং ৩8৮ দেখুন।) সি ++ তে ভাল ক্লাস লেখার ক্ষেত্রে এটি একটি সাধারণ সমস্যা, তবে অবশ্যই সিটিতে এড়ানো হয়েছে কারণ সিতে নির্মাণ ও ধ্বংসের শব্দার্থক শব্দটি নেই, নির্মাণ পরিচালনা করার জন্য যথাযথ কোড লেখা কোনও অবজেক্টের মধ্যে সাবওবজেক্টগুলির অর্থ কোড লিখনের কোড যা অবশ্যই সি ++ এ এই অনন্য অর্থসূচক সমস্যার সাথে লড়াই করতে হবে; অন্য কথায় "চারপাশে লেখার জন্য" সি ++ শব্দার্থিক আচরণ।

সি ++ অবজেক্ট পরামিতিগুলিতে পাস করা বস্তুগুলি অনুলিপি করতে পারে। উদাহরণস্বরূপ, নিম্নলিখিত টুকরাগুলিতে, "আরএ (এক্স)" কল করুন; সি ++ সংকলক প্যারামিটার পি এর জন্য কনস্ট্রাক্টরকে অনুরোধ করতে পারে, তারপরে কপি কন্সট্রাক্টরকে অবজেক্ট এক্সকে প্যারামিটার পিতে স্থানান্তর করতে কল করতে পারে, তারপরে ফাংশন আরএর রিটার্ন অবজেক্টের (একটি নামবিহীন অস্থায়ী) জন্য অন্য নির্মাণকারী অবশ্যই কোনটি প্যারামিটার থেকে অনুলিপি পি। সবচেয়ে খারাপটি, ক্লাস এ এর নিজস্ব অবজেক্টগুলি রয়েছে যার নির্মাণ প্রয়োজন, এটি বিপর্যয়করভাবে দূরবীণ করতে পারে। (এসি প্রোগ্রামার এই আবর্জনাটির বেশিরভাগ অংশ এড়াতে পারবেন, হাত অনুকূলকরণের কারণে সি প্রোগ্রামারগুলির হাতে এমন সিন্ট্যাক্স নেই এবং একবারে সমস্ত বিবরণ প্রকাশ করতে হবে))

    class A {...};
    A rA (A p) { return p; }
    // .....
    { A x; rA(x); }

অবশেষে সি প্রোগ্রামারদের জন্য একটি সংক্ষিপ্ত নোট। লংজ্যাম্প () এর সি ++ তে পোর্টেবল আচরণ নেই। (কিছু সি প্রোগ্রামার এটিকে এক ধরণের "ব্যতিক্রম" প্রক্রিয়া হিসাবে ব্যবহার করে)) কিছু সি ++ সংকলক আসলে লংজ্যাম্পটি নেওয়ার সময় জিনিসগুলি পরিষ্কার করার জন্য সেট আপ করার চেষ্টা করবে, তবে সেই আচরণটি সি ++ এ বহনযোগ্য নয়। যদি সংকলকটি নির্মাণকৃত অবজেক্টগুলি পরিষ্কার করে দেয় তবে এটি বহনযোগ্য নয়। সংকলক যদি সেগুলি পরিষ্কার না করে তবে লংজ্যাম্পের ফলে কোডটি নির্মাণকৃত সামগ্রীর সুযোগ ছেড়ে দিলে এবং আচরণটি অবৈধ হলে অবজেক্টগুলি ধ্বংস হয় না। (যদি foo () এ লংজ্যাম্পের ব্যবহার কোনও সুযোগ না ফেলে থাকে তবে আচরণটি ভাল হতে পারে)) সি এম্বেড হওয়া প্রোগ্রামাররা এটি প্রায়শই ব্যবহার করেন না তবে তাদের ব্যবহার করার আগে তাদের এই বিষয়গুলি সম্পর্কে নিজেদের সচেতন করা উচিত।

— jonk
সূত্র

4

শুধুমাত্র একবার ব্যবহৃত এই জাতীয় ফাংশন ফাংশন কল হিসাবে কখনই সংকলিত হয় না, কোডটি কেবল কোনও কল ছাড়াই সেখানে রাখা হয়।

— ডোরিয়ান

6

@ ডরিয়ান - আপনার মন্তব্য নির্দিষ্ট সংকলকগুলির জন্য নির্দিষ্ট পরিস্থিতিতে সঠিক হতে পারে। যদি ফাংশনটি ফাইলের মধ্যে স্থিতিশীল থাকে তবে কম্পাইলারের কাছে কোডটি ইনলাইন করার বিকল্প রয়েছে । যদি এটি বাহ্যিকভাবে দৃশ্যমান হয়, এমনকি যদি এটি কখনই প্রকৃতপক্ষে বলা হয় না, তবে ফাংশনটি কল করার জন্য একটি উপায় থাকতে হবে।

— uɐɪ

1

@ জোঁক - অন্য একটি কৌশল যা আপনি উত্তরের উত্তরে উল্লেখ করেননি তা হ'ল সরল ম্যাক্রো ফাংশনগুলি লিখুন যা প্রারম্ভিককরণ বা কনফিগারেশনটি প্রসারিত ইনলাইন কোড হিসাবে সম্পাদন করে। এটি বিশেষত খুব ছোট প্রসেসরের ক্ষেত্রে দরকারী যেখানে র্যাম / স্ট্যাক / ফাংশন কল গভীরতা সীমিত।

— uɐɪ

@ .ouɐɪ হ্যাঁ, আমি সি-তে ম্যাক্রোগুলি নিয়ে আলোচনা করতে মিস করলাম সেগুলি সি ++ এ অবমূল্যায়িত হয়েছে, তবে সেই পয়েন্টে আলোচনাটি দরকারী হতে পারে। আমি এটি সম্বোধন করতে পারি, যদি আমি এটি সম্পর্কে কিছু লিখতে দরকারী মনে করি।

— জান্নাত

1

@ জংক - আপনার প্রথম বাক্যটির সাথে আমি সম্পূর্ণ একমত নই। উদাহরণস্বরূপ, যেমন inline static void turnOnFan(void) { PORTAbits &= ~(1<<8); }অসংখ্য স্থানে ডাকা হয়, তা হ'ল এক নিখুঁত প্রার্থী।

— জেসন এস

8

1) প্রথমে পাঠযোগ্যতা এবং রক্ষণাবেক্ষণের জন্য কোড। যে কোনও কোডবেসের সবচেয়ে গুরুত্বপূর্ণ দিকটি হ'ল এটি সুসংগঠিত। সুন্দরভাবে লেখা সফ্টওয়্যারটিতে ত্রুটি কম থাকে। আপনার কয়েক সপ্তাহ / মাস / বছর পরিবর্তন করতে হবে এবং আপনার কোডটি পড়তে ভাল লাগলে এটি প্রচুর পরিমাণে সহায়তা করে। অথবা হতে পারে অন্য কাউকে পরিবর্তন করতে হবে।

2) কোড সঞ্চালন যা একবার রান করে খুব বেশি গুরুত্ব দেয় না। শৈলীর জন্য যত্ন, না পারফরম্যান্স

3) এমনকি টাইট লুপগুলিতে কোডও প্রথম এবং সর্বাগ্রে সঠিক হওয়া দরকার। আপনি যদি পারফরম্যান্স সমস্যার মুখোমুখি হন, তবে কোডটি সঠিক হয়ে গেলে অনুকূলিত করুন।

4) আপনার যদি অনুকূলিতকরণ প্রয়োজন হয়, আপনাকে পরিমাপ করতে হবে! আপনি ভাবছেন বা কেউ আপনাকে বলে যে static inlineএটি কম্পাইলারের কাছে কেবল একটি পরামর্শ ation সংকলকটি কী করে তা আপনাকে একবার দেখে নিতে হবে। ইনলাইনিংয়ের পারফরম্যান্স উন্নতি হয়েছে কিনা তাও আপনাকে মাপতে হবে। এম্বেড থাকা সিস্টেমে আপনাকে কোডের আকারও পরিমাপ করতে হয়, যেহেতু কোড মেমরিটি সাধারণত বেশ সীমাবদ্ধ থাকে। এটি হল সবচেয়ে গুরুত্বপূর্ণ নিয়ম যা অনুমানের কাজ থেকে প্রকৌশলকে পৃথক করে। আপনি যদি এটি পরিমাপ না করেন তবে এটি কোনও লাভ হয়নি। ইঞ্জিনিয়ারিং পরিমাপ করছে। বিজ্ঞান এটি লিখছে;)

— Crazor
সূত্র

2

আপনার অন্যথায় দুর্দান্ত পোস্টটি নিয়ে আমার একমাত্র সমালোচনা হচ্ছে পয়েন্ট 2)। এটি সত্য যে প্রারম্ভিককরণের কোডের পারফরম্যান্স অপ্রাসঙ্গিক - তবে এম্বেডযুক্ত পরিবেশে আকারটি গুরুত্বপূর্ণ হয়ে উঠতে পারে। (তবে এটি পয়েন্ট 1টিকে ওভাররাইড করে না; আপনার যখন প্রয়োজন তখন আকারের জন্য অনুকূলকরণ শুরু করুন - এবং এর আগে নয়)

— মার্টিন বোনার মনিকাকে

2

প্রারম্ভিককরণের কোডের সম্পাদনা প্রথমে অপ্রাসঙ্গিক হতে পারে। আপনি যখন লো-পাওয়ার মোড যুক্ত করেন এবং ওয়েকআপ ইভেন্টটি পরিচালনা করতে দ্রুত পুনরুদ্ধার করতে চান, তখন এটি প্রাসঙ্গিক হয়ে ওঠে।

— বেরেন্দি -

5

যখন কোনও ফাংশনটি কেবলমাত্র এক জায়গায় ডাকা হয় (এমনকি অন্যান্য ফাংশনের অভ্যন্তরেও) কম্পাইলার সবসময় কোডটিকে সেই স্থানে ফাংশনটি কল করার পরিবর্তে সেই জায়গায় রেখে দেয়। যদি ফাংশনটিকে অনেক জায়গায় ডাকা হয় তবে তার চেয়ে কমপক্ষে কোড আকারের দৃষ্টিকোণ থেকে কোনও ফাংশনটি ব্যবহার করা বোধগম্য হয়।

সংকলনের পরে কোডটির পরিবর্তে একাধিক কল আসবে না পঠনযোগ্যতা আরও উন্নত হবে।

এছাড়াও আপনি উদাহরণস্বরূপ একই লাইব্রেরিতে ADC init কোডটি মূল সি ফাইলটিতে নয় অন্যান্য এডিসি ফাংশন সহ পেতে চাইবেন।

অনেক সংকলক আপনাকে গতি বা কোড আকারের জন্য বিভিন্ন স্তরের অপ্টিমাইজেশান নির্দিষ্ট করতে মঞ্জুরি দেয়, সুতরাং আপনার যদি অনেক জায়গায় একটি ছোট ফাংশন বলা হয় তবে ফাংশনটি "ইনলাইনড" হবে, কল করার পরিবর্তে সেখানে অনুলিপি করা হবে।

গতির জন্য অপ্টিমাইজেশন যতগুলি স্থানে এটি ফাংশনগুলিকে ইনলাইন করবে, কোড আকারের অপ্টিমাইজেশনটি ফাংশনটিকে কল করবে, তবে, যখন কোনও ফাংশন কেবল আপনার জায়গায় যেমন একটি জায়গায় ডাকা হয় তখন এটি সর্বদা "ইনলাইনড" থাকবে।

এর মতো কোড:

function_used_just_once{
   code blah blah;
}
main{
  codeblah;
  function_used_just_once();
  code blah blah blah;
{

এটি সংকলন করবে:

main{
 code blah;
 code blah blah;
 code blah blah blah;
}

কোন কল ব্যবহার না করে।

এবং আপনার প্রশ্নের উত্তর, আপনার উদাহরণ বা অনুরূপ, কোডের পঠনযোগ্যতা কার্য সম্পাদনকে প্রভাবিত করে না, গতি বা কোড আকারে কিছুই প্রচুর নয়। কেবল কোডটি পঠনযোগ্য করে তোলার জন্য একাধিক কল ব্যবহার করা সাধারণ, শেষদিকে এগুলি একটি ইনলাইন কোড হিসাবে মেনে চলবে।

উপরের বিবৃতিগুলি মাইক্রোচিপ এক্সসিএক্সএক্স ফ্রি সংস্করণের মতো পঙ্গু ফ্রি সংস্করণ সংকলকগুলির উদ্দেশ্যে কার্যকর নয় তা নির্দিষ্ট করার জন্য আপডেট করুন। এই ধরণের ফাংশন কলগুলি মাইক্রোচিপের জন্য প্রদত্ত সংস্করণটি কতটা ভাল তা দেখানোর জন্য একটি সোনার খনি এবং আপনি এটি সংকলন করলে আপনি সিএম কোডে যতটা কল পেয়েছেন ঠিক তেমনই ASM এ পাবেন।

এছাড়াও এটি বোবা প্রোগ্রামারদের পক্ষে নয় যা কোনও ইনলাইড ফাংশনে পয়েন্টার ব্যবহারের প্রত্যাশা করে।

এটি ইলেকট্রনিক্স বিভাগ, সাধারণ সি সি ++ বা প্রোগ্রামিং বিভাগ নয়, প্রশ্নটি মাইক্রোকন্ট্রোলার প্রোগ্রামিং সম্পর্কিত যেখানে কোনও শালীন সংকলক ডিফল্টরূপে উপরের অপ্টিমাইজেশনটি করবে।

সুতরাং দয়া করে ডাউনভোটিং বন্ধ করুন কারণ বিরল, অস্বাভাবিক ক্ষেত্রে এটি সত্য নাও হতে পারে।

— ডরিয়ান
সূত্র

15

কোড ইনলাইন হয়ে উঠুক বা না হয় কোনও সংকলক বিক্রেতা বাস্তবায়ন নির্দিষ্ট সমস্যা; এমনকি ইনলাইন কীওয়ার্ড ব্যবহার করা ইনলাইন কোডের গ্যারান্টি দেয় না । এটি সংকলকটির জন্য একটি ইঙ্গিত। অবশ্যই ভাল সংকলকগুলি সেগুলি সম্পর্কে তাদের জানা থাকলে কেবল একবার ব্যবহৃত ফাংশনগুলিকে ইনলাইন করবে। যদিও কোনও "উদ্বায়ী" অবধি যদি সুযোগে থাকে তবে এটি সাধারণত তা করবে না।

— পিটার স্মিথ

9

এই উত্তর ঠিক সত্য নয়। @ পিটারস্মিথ যেমনটি বলেছেন, এবং সি ভাষার স্পেসিফিকেশন অনুসারে, সংকলকটির কাছে কোডটি ইনলাইন করার বিকল্প রয়েছে তবে তা নাও হতে পারে এবং অনেক ক্ষেত্রে তা করবে না। পৃথিবীতে অনেকগুলি বিভিন্ন টার্গেট প্রসেসরের জন্য অনেকগুলি পৃথক সংকলক রয়েছে যে এই উত্তরে কম্বল স্টেটমেন্টটি সাজিয়ে তোলে এবং ধরে নেওয়া হয় যে সমস্ত সংকলক যখন কেবলমাত্র টেকনেবল না হয়ে যাওয়ার বিকল্প পাবেন তখন কোডটি ইনলাইন রাখবে।

— uɐɪ

2

@ .ouɐɪ আপনি এমন বিরল ক্ষেত্রে নির্দেশ করছেন যেখানে সম্ভব নয় এবং প্রথমে কোনও ফাংশন না ডাকলে খারাপ ধারণা হবে। ওপি কর্তৃক প্রদত্ত সাধারণ উদাহরণটিতে কলটি ব্যবহার করার জন্য আমি এতক্ষণ কোনও সংকলক কখনও দেখিনি।

— ডোরিয়ান

6

এই ফাংশনগুলিকে কেবল একবার ডাকা হয় এমন ক্ষেত্রে, ফাংশন কলটিকে অপ্টিমাইজ করা খুব অ-ইস্যু। সিস্টেমটিকে কি সেটআপের সময় প্রতিটি ঘড়ির চক্রের পিছনে ফিরে ফিরে ফিরে আসা দরকার? যেমনটি কোথাও অপ্টিমাইজেশনের ক্ষেত্রে রয়েছে - পঠনযোগ্য কোডটি লিখুন এবং কেবল প্রোফাইলিং যদি এটির প্রয়োজনীয়তা দেখায় তবে অনুকূলিত করুন ।

— বাল্ড্রিক 18

5

@ এসএমএলটাররা এখানে কম্পাইলারটি কী শেষ করে তা নিয়ে আমি উদ্বিগ্ন নই - প্রোগ্রামার এটির কাছে কীভাবে আসে more প্রশ্নের মধ্যে যেমনটি আছে তেমনভাবে আরম্ভ হয় না বা তুচ্ছ পারফরম্যান্সও শুরু হয়।

— বাল্ড্রিক 18

2

প্রথমত, এর চেয়ে ভাল বা খারাপ কিছু নেই; এটা সব মতামত বিষয়। আপনি খুব সঠিক যে এটি অকার্যকর। এটি অপ্টিমাইজ করা যেতে পারে বা না; এটা নির্ভর করে. সাধারণত আপনি পৃথক ফাইল / ডিরেক্টরিতে এই ধরণের ফাংশন, ঘড়ি, জিপিআইও, টাইমার ইত্যাদি দেখতে পাবেন। সংকলকগণ সাধারণত এই শূন্যস্থানগুলি পেরিয়ে অপ্টিমাইজ করতে সক্ষম হননি। এমন একটি আছে যা আমি জানি তবে এই জাতীয় সামগ্রীর জন্য ব্যাপকভাবে ব্যবহৃত হয় না।

ফাইল:

void dummy (unsigned int);

void setCLK()
{
    // Code to set the clock
    dummy(5);
}

void setConfig()
{
    // Code to set the configuration
    dummy(6);
}

void setSomethingElse()
{
   // 1 line code to write something to a register.
    dummy(7);
}

void initModule()
{
   setCLK();
   setConfig();
   setSomethingElse();
}

প্রদর্শনের উদ্দেশ্যে লক্ষ্য এবং সংকলক বাছাই করা।

Disassembly of section .text:

00000000 <setCLK>:
   0:    e92d4010     push    {r4, lr}
   4:    e3a00005     mov    r0, #5
   8:    ebfffffe     bl    0 <dummy>
   c:    e8bd4010     pop    {r4, lr}
  10:    e12fff1e     bx    lr

00000014 <setConfig>:
  14:    e92d4010     push    {r4, lr}
  18:    e3a00006     mov    r0, #6
  1c:    ebfffffe     bl    0 <dummy>
  20:    e8bd4010     pop    {r4, lr}
  24:    e12fff1e     bx    lr

00000028 <setSomethingElse>:
  28:    e92d4010     push    {r4, lr}
  2c:    e3a00007     mov    r0, #7
  30:    ebfffffe     bl    0 <dummy>
  34:    e8bd4010     pop    {r4, lr}
  38:    e12fff1e     bx    lr

0000003c <initModule>:
  3c:    e92d4010     push    {r4, lr}
  40:    e3a00005     mov    r0, #5
  44:    ebfffffe     bl    0 <dummy>
  48:    e3a00006     mov    r0, #6
  4c:    ebfffffe     bl    0 <dummy>
  50:    e3a00007     mov    r0, #7
  54:    ebfffffe     bl    0 <dummy>
  58:    e8bd4010     pop    {r4, lr}
  5c:    e12fff1e     bx    lr

এখানে বেশিরভাগ উত্তরই আপনাকে বলছে যে আপনি নির্দোষ এবং এটি সমস্ত অনুকূলিত হয়ে যায় এবং কার্যগুলি সরিয়ে ফেলা হয়। ঠিক আছে, তারা ডিফল্টরূপে বিশ্বব্যাপী সংজ্ঞায়িত হওয়ায় এগুলি সরানো হয় না। এই একটি ফাইলের বাইরে প্রয়োজন না হলে আমরা সেগুলি সরিয়ে ফেলতে পারি।

void dummy (unsigned int);

static void setCLK()
{
    // Code to set the clock
    dummy(5);
}

static void setConfig()
{
    // Code to set the configuration
    dummy(6);
}

static void setSomethingElse()
{
   // 1 line code to write something to a register.
    dummy(7);
}

void initModule()
{
   setCLK();
   setConfig();
   setSomethingElse();
}

তারা linedুকে পড়েছে এখন সেগুলি সরান।

Disassembly of section .text:

00000000 <initModule>:
   0:    e92d4010     push    {r4, lr}
   4:    e3a00005     mov    r0, #5
   8:    ebfffffe     bl    0 <dummy>
   c:    e3a00006     mov    r0, #6
  10:    ebfffffe     bl    0 <dummy>
  14:    e3a00007     mov    r0, #7
  18:    ebfffffe     bl    0 <dummy>
  1c:    e8bd4010     pop    {r4, lr}
  20:    e12fff1e     bx    lr

তবে বাস্তবতা হ'ল আপনি যখন চিপ বিক্রেতা বা বিএসপি লাইব্রেরি গ্রহণ করেন,

Disassembly of section .text:

00000000 <_start>:
   0:    e3a0d902     mov    sp, #32768    ; 0x8000
   4:    eb000010     bl    4c <initModule>
   8:    eafffffe     b    8 <_start+0x8>

0000000c <dummy>:
   c:    e12fff1e     bx    lr

00000010 <setCLK>:
  10:    e92d4010     push    {r4, lr}
  14:    e3a00005     mov    r0, #5
  18:    ebfffffb     bl    c <dummy>
  1c:    e8bd4010     pop    {r4, lr}
  20:    e12fff1e     bx    lr

00000024 <setConfig>:
  24:    e92d4010     push    {r4, lr}
  28:    e3a00006     mov    r0, #6
  2c:    ebfffff6     bl    c <dummy>
  30:    e8bd4010     pop    {r4, lr}
  34:    e12fff1e     bx    lr

00000038 <setSomethingElse>:
  38:    e92d4010     push    {r4, lr}
  3c:    e3a00007     mov    r0, #7
  40:    ebfffff1     bl    c <dummy>
  44:    e8bd4010     pop    {r4, lr}
  48:    e12fff1e     bx    lr

0000004c <initModule>:
  4c:    e92d4010     push    {r4, lr}
  50:    ebffffee     bl    10 <setCLK>
  54:    ebfffff2     bl    24 <setConfig>
  58:    ebfffff6     bl    38 <setSomethingElse>
  5c:    e8bd4010     pop    {r4, lr}
  60:    e12fff1e     bx    lr

আপনি সম্ভবত স্পষ্টভাবে ওভারহেড যুক্ত করা শুরু করতে যাচ্ছেন যার পারফরম্যান্স এবং স্পেসের জন্য লক্ষণীয় ব্যয় রয়েছে। প্রতিটি ফাংশনটি কতটা ছোট তার উপর নির্ভর করে প্রত্যেকের কয়েক থেকে পাঁচ ভাগ।

কেন যেভাবেই করা হচ্ছে? এর কয়েকটি হ'ল নিয়মসমূহের সেট যা অধ্যাপকরা গ্রেডিং কোডকে আরও সহজ করে তোলা শেখাতে পারেন। কোনও পৃষ্ঠায় ফাংশন অবশ্যই মাপসই করা উচিত (আপনি যখন কাগজের উপর দিয়ে নিজের কাজটি মুদ্রণ করেছিলেন) ফিরে আসবেন না, এটি করবেন না, তা করবেন না ইত্যাদি ইত্যাদি বিভিন্ন লক্ষ্যমাত্রার জন্য সাধারণ নামের পাঠাগার তৈরি করা। আপনার যদি মাইক্রো কন্ট্রোলারদের কয়েক পরিবার থাকে, যার মধ্যে কিছু অংশ পেরিফেরিয়াল এবং কিছু না ভাগ করে নিতে পারে, তিন বা চারটি বিভিন্ন ইউআআরটি স্বাদগুলি পরিবারের মধ্যে মিশে যায়, বিভিন্ন জিপিআইও, এসপিআই কন্ট্রোলার ইত্যাদি etc. আপনার জেনেরিক gpio_init () ফাংশন থাকতে পারে, get_timer_count () ইত্যাদি পাওয়া যায় এবং বিভিন্ন পেরিফেরিয়ালগুলির জন্য সেই বিমূর্ততা পুনরায় ব্যবহার করুন।

এটি বেশিরভাগ রক্ষণযোগ্যতা এবং কিছু সম্ভাব্য পাঠযোগ্যতার সাথে সফ্টওয়্যার ডিজাইনের ক্ষেত্রে পরিণত হয়। রক্ষণাবেক্ষণ, পাঠযোগ্যতা এবং কর্মক্ষমতা আপনার সমস্ত কিছুই থাকতে পারে না; আপনি একবারে কেবল এক বা দুটি বাছাই করতে পারবেন, তিনটিই নয়।

এটি অনেকটা একটি মতামত ভিত্তিক প্রশ্ন এবং উপরেরটি এটি যেতে পারে এমন তিনটি প্রধান উপায় দেখায়। সর্বোত্তম পথটি কী তা সম্পর্কে কঠোরভাবে মতামত। সব কাজ কি এক ফাংশনে করছে? একটি মতামত ভিত্তিক প্রশ্ন, কিছু লোকেরা পারফরম্যান্সের জন্য ঝুঁকেন, কেউ কেউ মডুলারালিটি এবং তাদের পাঠযোগ্যতার সংস্করণকে সেরা হিসাবে সংজ্ঞায়িত করেন। প্রচুর ভাবার্থকে পঠনযোগ্যতা বলার সাথে আকর্ষণীয় বিষয়টি অত্যন্ত বেদনাদায়ক; আপনার একবারে 50-10,000 ফাইল খোলা আছে কোডটি "দেখতে" এবং কোনওভাবে কী চলছে তা দেখার জন্য নির্বাহের ক্রিয়াকলাপগুলিকে রৈখিকভাবে দেখার চেষ্টা করুন। আমি দেখতে পেলাম যে পাঠযোগ্যতার বিপরীত, তবে অন্যরা এটি পঠনযোগ্য বলে মনে করে যেহেতু প্রতিটি আইটেমটি স্ক্রিন / সম্পাদক উইন্ডোতে ফিট হয় এবং তারা ডাকা ফাংশনগুলি মুখস্থ করে এবং / অথবা এমন কোনও সম্পাদক থাকতে পারে যা এতে পপ এবং আউট হয়ে যায় একটি প্রকল্পের মধ্যে প্রতিটি ফাংশন।

আপনি বিভিন্ন সমাধান দেখলে এটি অন্য একটি বড় কারণ। পাঠ্য সম্পাদক, আইডিই, ইত্যাদি খুব ব্যক্তিগত, এবং এটি vi বনাম Emacs ছাড়িয়ে যায়। প্রোগ্রামিং দক্ষতা, আপনি যে সরঞ্জামটি ব্যবহার করছেন তার সাথে যদি আপনি আরামদায়ক এবং দক্ষ হন তবে প্রতিদিন / মাসের লাইনগুলি উপরে যায়। এই সরঞ্জামটির বৈশিষ্ট্যগুলি ইচ্ছাকৃতভাবে ইচ্ছাকৃতভাবে ঝুঁকতে পারে বা ঝুঁকতে পারে না কীভাবে সেই সরঞ্জামটির অনুরাগীরা কোড লেখেন। এবং ফলস্বরূপ যদি কোনও ব্যক্তি এই লাইব্রেরিগুলি লেখেন তবে প্রকল্পটি কিছুটা হলেও এই অভ্যাসগুলি প্রতিফলিত করে। যদিও এটি একটি দল, লিড বিকাশকারী বা বসের অভ্যাস / পছন্দগুলি দলের বাকি অংশে বাধ্য করা যেতে পারে।

কোডিং স্ট্যান্ডার্ডগুলিতে যার মধ্যে অনেকগুলি ব্যক্তিগত পছন্দ রয়েছে যার মধ্যে অনেকগুলি ব্যক্তিগত পছন্দ রয়েছে, আবার খুব ধার্মিক ভি বনাম ইম্যাকস, ট্যাব বনাম ফাঁকা স্থানগুলি, বন্ধনীগুলি কীভাবে রেখাযুক্ত করা হয় ইত্যাদি ইত্যাদি এবং গ্রন্থাগারগুলি কীভাবে কিছুটা নকশাকৃত হয়েছে তা এইগুলি খোলায়।

আপনার কীভাবে আপনার লেখা উচিত? তবে আপনি চান, যদি এটি কার্যকর হয় তবে সত্যিই কোনও ভুল উত্তর নেই। খারাপ বা ঝুঁকিপূর্ণ কোড অবশ্যই আছে, তবে আপনি যদি এটি রচনা করেন তবে এটি প্রয়োজন হিসাবে এটি বজায় রাখতে পারেন, এটি আপনার নকশার লক্ষ্যগুলি পূরণ করে, পাঠযোগ্যতা এবং কিছুটা রক্ষণাবেক্ষণকে ছেড়ে দেয় যদি পারফরম্যান্স গুরুত্বপূর্ণ হয়, বা তদ্বিপরীত। আপনি কি সংক্ষিপ্ত পরিবর্তনশীল নামগুলি পছন্দ করেন যাতে একটি একক কোড লাইন সম্পাদক উইন্ডোর প্রস্থের সাথে খাপ খায়? বা বিভ্রান্তি এড়াতে দীর্ঘ মাত্রায় বর্ণনামূলক নামগুলি পড়ে তবে পঠনযোগ্যতা হ্রাস পায় কারণ আপনি কোনও পৃষ্ঠায় একটি লাইন পেতে পারেন না; এখন এটি দৃশ্যমানভাবে ভেঙে গেছে, প্রবাহের সাথে গোলযোগ করছে।

আপনি প্রথমবার ব্যাটে কোনও হোম রান করতে যাচ্ছেন না। আপনার স্টাইলটিকে সত্যই সংজ্ঞায়িত করতে কয়েক দশক সময় লাগতে পারে / উচিত। একই সময়ে, সেই সময়ের সাথে আপনার স্টাইলটি পরিবর্তিত হতে পারে, কিছুক্ষণ একদিকে ঝুঁকতে থাকে, তারপরে অন্য দিকে ঝুঁকে থাকে।

আপনি প্রচুর অপ্টিমাইজ করবেন না, কখনই অনুকূলিত হন না এবং অকাল-অপ্টিমাইজেশন শুনতে পাচ্ছেন hear তবে যেমন দেখানো হয়েছে, শুরু থেকেই এর মতো নকশাগুলি পারফরম্যান্সের সমস্যা তৈরি করে, তারপরে আপনি শুরু থেকে পুনরায় নকশা সম্পাদন করার চেয়ে সমস্যাটি সমাধান করার জন্য হ্যাকগুলি দেখতে শুরু করেন। আমি সম্মত হয়েছি যে পরিস্থিতি রয়েছে, একটি একক ফাংশন কয়েক লাইনের কোড যা আপনি কম্পাইলার অন্যথায় কী করতে চলেছে তার ভয়ের ভিত্তিতে সংকলকটি হেরফের করার জন্য কঠোর চেষ্টা করতে পারেন (অভিজ্ঞতার সাথে নোট করুন যে এই ধরণের কোডিংটি সহজ এবং প্রাকৃতিক হয়ে ওঠে, সংকলক কীভাবে কোডটি সংকলন করতে চলেছে তা জেনে আপনি লেখার ক্ষেত্রে অনুকূলকরণ), তারপরে আক্রমণ করার আগে আপনি নিশ্চিত করতে চান যে চক্র চুরিকারী আসলেই কোথায়।

কিছুটা হলেও ব্যবহারকারীর জন্য আপনার কোডটিও ডিজাইন করতে হবে। এটি যদি আপনার প্রকল্প হয় তবে আপনি একমাত্র বিকাশকারী; এটি আপনি যা চান আপনি যদি উপহার দিতে বা বিক্রয় করার জন্য কোনও গ্রন্থাগার তৈরি করার চেষ্টা করছেন, আপনি সম্ভবত আপনার কোডটিকে অন্যান্য সমস্ত লাইব্রেরির মতো দেখতে চান, ক্ষুদ্র ফাংশন, দীর্ঘ ফাংশন নাম এবং দীর্ঘ ভেরিয়েবলের নাম সহ কয়েক হাজার থেকে কয়েক হাজার ফাইল। পাঠযোগ্যতার সমস্যা এবং কার্য সম্পাদনের সমস্যা সত্ত্বেও, আইএমও আপনি আরও লোকেরা এই কোডটি ব্যবহার করতে সক্ষম হবেন।

— old_timer
সূত্র

4

সত্যি? আপনি জিজ্ঞাসা করতে পারেন "কোন লক্ষ্য" এবং "কিছু সংকলক" আপনি কি ব্যবহার করেন?

— ডোরিয়ান

এটি আমার কাছে 32/64 বিট এআরএম 8 এর মতো দেখাচ্ছে, সম্ভবত কোনও রাস্পবেরি পিআই থেকে তখন একটি সাধারণ মাইক্রোকন্ট্রোলার। প্রশ্নটিতে প্রথম বাক্যটি পড়েছেন?

— ডোরিয়ান

ঠিক আছে, সংকলক অব্যবহৃত গ্লোবাল ফাংশন সরিয়ে দেয় না, তবে লিঙ্কারটি করে। যদি এটি কনফিগার করা হয় এবং সঠিকভাবে ব্যবহার করা হয় তবে তারা এক্সিকিউটেবলের মধ্যে প্রদর্শিত হবে না।

— বেরেন্ডি -

যদি কেউ ভাবছেন যে কোন সংকলক ফাইল শূন্যস্থানগুলি পেরিয়ে অনুকূল করতে পারে: আইএআর সংকলকগুলি বহু ফাইল সংকলন সমর্থন করে (তারা এটিকে এটি বলে) এটি ক্রস ফাইল অপ্টিমাইজেশনের অনুমতি দেয়। আপনি যদি এতে সমস্ত সি / সিপিপি ফাইল একসাথে ফেলে দেন তবে আপনি একটি এক্সিকিউটেবলের সাথে শেষ করবেন যার মধ্যে একটি ফাংশন রয়েছে: মূল। পারফরম্যান্স সুবিধাগুলি বেশ গভীর হতে পারে।

— আর্সেনাল

3

@ আর্সেনাল অবশ্যই জিসিসি সঠিকভাবে বলা হলেও সংকলন ইউনিট জুড়ে ইনলাইনিং সমর্থন করে। Gcc.gnu.org/onlinesocs/gcc/Optimize-Options.html দেখুন এবং -ফ্ল্টো বিকল্পটি সন্ধান করুন।

— পিটার -

1

খুব সাধারণ নিয়ম - সংকলকটি আপনার চেয়ে ভাল অনুকূল করতে পারে। অবশ্যই, যদি আপনি খুব লুপ নিবিড় জিনিসগুলি করেন তবে ব্যতিক্রম রয়েছে তবে সামগ্রিকভাবে আপনি যদি গতি বা কোড আকারের জন্য ভাল অপ্টিমাইজেশন চান তবে আপনার সংকলকটি বুদ্ধিমানের সাথে চয়ন করুন।

— ডার্ক ব্রুয়ের
সূত্র

দুঃখের বিষয় এটি বেশিরভাগ প্রোগ্রামারদের ক্ষেত্রেই সত্য।

— ডোরিয়ান

0

এটি আপনার কোডিংয়ের নিজস্ব স্টাইলের উপর নির্ভর করে। একটি সাধারণ নিয়ম যেটি বাইরে রয়েছে তা হ'ল, চলক নামগুলির পাশাপাশি ফাংশনগুলির নামগুলি যথাসম্ভব স্পষ্ট এবং স্ব-ব্যাখ্যাযোগ্য হওয়া উচিত। আপনি কোনও ফাংশনে যত বেশি সাব-কল বা কোড লাইন রেখেছেন, সেই ফাংশনের জন্য একটি পরিষ্কার টাস্ক সংজ্ঞায়িত করা তত বেশি কঠিন। আপনার উদাহরণে আপনার একটি ফাংশন রয়েছে initModule()যা স্টাফ আরম্ভ করে এবং উপ-রুটিনগুলিতে কল করে যা পরে ঘড়িটি সেট করে বা কনফিগারেশন সেট করে । আপনি কেবল ফাংশনটির নাম পড়ে তা বলতে পারেন। আপনি যদি সাবউরটাইনগুলি থেকে সমস্ত কোড আপনার initModule()সরাসরি রাখেন তবে ফাংশনটি আসলে কী করে তা কম স্পষ্ট হয়। তবে প্রায়শই এটি কেবল একটি গাইডলাইন।

— ধর্মযাজক
সূত্র

ধন্যবাদ তোমার উত্তরের জন্য. পারফরম্যান্সের জন্য প্রয়োজন হলে আমি স্টাইল পরিবর্তন করতে পারি তবে এখানে প্রশ্নটি হচ্ছে কোডটির পঠনযোগ্যতা কার্য সম্পাদনকে প্রভাবিত করে?

— MaNyYaakk

একটি ফাংশন কল একটি কল বা জেএমপি কমান্ডের ফলশ্রুতিতে আসে তবে এটি আমার মতে সম্পদের তুচ্ছ ত্যাগ। আপনি যদি ডিজাইনের নিদর্শনগুলি ব্যবহার করেন তবে আপনি কখনও কখনও আসল কোডটি স্নিপ করে পৌঁছানোর আগে ফাংশন কলগুলির কয়েক ডজন স্তর দিয়ে শেষ করেন।

— po.pe

@Humpawumpa - আপনি র্যাম তারপর ফাংশন কল এক ডজন স্তর শুধুমাত্র 256 বা 64 বাইট সঙ্গে একটি মাইক্রোকন্ট্রোলার লেখার হয়, একটি তুচ্ছ বলিদান নয় এটা শুধু সম্ভব নয়

— uɐɪ

হ্যাঁ, তবে এটি দুটি চূড়ান্ত ... সাধারণত আপনার 256 বাইটের বেশি রয়েছে এবং আশা করা যায় যে এক ডজনেরও কম স্তর ব্যবহার করছেন।

— po.pe

0

যদি কোনও ফাংশন সত্যিই খুব ছোট একটি জিনিস করে তবে এটি তৈরির বিষয়টি বিবেচনা করুন static inline।

এটি সি ফাইলের পরিবর্তে একটি শিরোনাম ফাইলে যুক্ত করুন এবং static inlineএটি সংজ্ঞায়িত করতে শব্দগুলি ব্যবহার করুন :

static inline void setCLK()
{
    //code to set the clock
}

এখন, যদি ফাংশনটি আরও দীর্ঘ হয় যেমন 3 লাইনের বেশি হয় static inlineতবে এটি এ .c ফাইলটিতে এড়ানো এবং যুক্ত করা ভাল ধারণা হতে পারে । সর্বোপরি, এম্বেড থাকা সিস্টেমে মেমরি সীমিত থাকে এবং আপনি কোডের আকার খুব বেশি বাড়াতে চান না।

এছাড়াও, আপনি যদি ফাংশনটি সংজ্ঞায়িত করেন file1.cএবং এটি থেকে ব্যবহার করেন file2.cতবে সংকলক স্বয়ংক্রিয়ভাবে এটিকে ইনলাইন করবে না। তবে, আপনি যদি এটি file1.hকোনও static inlineফাংশন হিসাবে সংজ্ঞায়িত করেন তবে সম্ভাবনাগুলি আপনার সংকলকটি এটির সাথে যুক্ত lines

এই static inlineফাংশনগুলি উচ্চ-পারফরম্যান্স প্রোগ্রামিংয়ে অত্যন্ত কার্যকর। আমি তাদের প্রায়শই তিনজনেরও বেশি ফ্যাক্টর দ্বারা কোডের কার্য সম্পাদন বাড়িয়ে দেখতে পেয়েছি।

— juhist
সূত্র

"যেমন 3 লাইনের বেশি হওয়া" - লাইন গণনার সাথে এর কোনও যোগসূত্র নেই; ইনলাইনিং ব্যয়ের সাথে এটি করার মতো সমস্ত কিছুই রয়েছে। আমি একটি ২০-লাইনের ফাংশন লিখতে পারি যা ইনলাইনিংয়ের জন্য উপযুক্ত, এবং একটি 3-লাইন ফাংশন যা ইনলাইনিংয়ের জন্য ভয়ঙ্কর (যেমন ফাংশনএ () যা ফাংশনবি () কে 3 বার কল করে, ফাংশনবি () যা ফাংশনসি () কে 3 বার কল করে এবং অন্যান্য স্তরের কয়েক)।

— জেসন এস

এছাড়াও, আপনি যদি ফাংশনটি সংজ্ঞায়িত করেন file1.cএবং এটি থেকে ব্যবহার করেন file2.cতবে সংকলক স্বয়ংক্রিয়ভাবে এটিকে ইনলাইন করবে না। মিথ্যা । যেমন -fltoজিসিসি বা ঝনঝনায় দেখুন।

— বেরেন্ডি -

0

মাইক্রোকন্ট্রোলারদের জন্য দক্ষ এবং নির্ভরযোগ্য কোড লেখার চেষ্টা করার সাথে একটি অসুবিধা হ'ল কোড সংকলক-নির্দিষ্ট নির্দেশাবলী ব্যবহার না করে বা অনেকগুলি অপ্টিমাইজেশন অক্ষম না করলে কিছু সংকলক নির্ভরযোগ্যভাবে কিছু শব্দার্থবিজ্ঞান পরিচালনা করতে পারে না।

উদাহরণস্বরূপ, যদি কোনও বাধা সেবার রুটিন সহ [একটি টাইমার টিক বা যা কিছু চালিত] সহ একটি সিঙ্গল কোর সিস্টেম থাকে:

volatile uint32_t *magic_write_ptr,magic_write_count;
void handle_interrupt(void)
{
  if (magic_write_count)
  {
    magic_write_count--;
    send_data(*magic_write_ptr++)
  }
}

ব্যাকগ্রাউন্ড রাইটিং ক্রিয়াকলাপ শুরু করার জন্য ফাংশনগুলি লেখা বা এটি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করা উচিত:

void wait_for_background_write(void)
{
  while(magic_write_count)
    ;
}
void start_background_write(uint32_t *dat, uint32_t count)
{
  wait_for_background_write();
  background_write_ptr = dat;
  background_write_count = count;
}

এবং তারপরে এই জাতীয় কোডটি ব্যবহার করে:

uint32_t buff[16];

... write first set of data into buff
start_background_write(buff, 16);
... do some stuff unrelated to buff
wait_for_background_write();

... write second set of data into buff
start_background_write(buff, 16);
... etc.

দুর্ভাগ্যক্রমে, সম্পূর্ণ অপ্টিমাইজেশান সক্ষম করার সাথে সাথে, জিসিসি বা ক্ল্যাংয়ের মতো একটি "চতুর" সংকলক সিদ্ধান্ত নেবে যে কোনও লেখার প্রথম সেটটি প্রোগ্রামের পর্যবেক্ষণে কোনও প্রভাব ফেলতে পারে এবং এগুলি অপ্টিমাইজ করা যায় way মানসম্পন্ন সংকলকগুলির মতো iccএটি করার প্রবণতা কম থাকে যদি কোনও বিঘ্ন সেট করার এবং সমাপ্তির অপেক্ষার কাজটিতে উদ্বোধনী লেখাগুলি এবং উদ্বোধনী পাঠ উভয়ই জড়িত থাকে (তবে এখানে যেমন রয়েছে) তবে প্ল্যাটফর্মটি iccএম্বেড থাকা সিস্টেমগুলির জন্য এত জনপ্রিয় নয়।

স্ট্যান্ডার্ডটি ইচ্ছাকৃতভাবে-বাস্তবায়নের মানের বিষয়গুলি উপেক্ষা করে, এটি নির্ধারণ করে যে উপরোক্ত নির্মাণটি পরিচালনা করতে পারে এমন বেশ কয়েকটি যুক্তিসঙ্গত উপায় রয়েছে:

উচ্চ-শেষ নম্বর ক্রাঞ্চিংয়ের মতো ক্ষেত্রগুলির জন্য একচেটিয়াভাবে উদ্দেশ্যে করা একটি মানের বাস্তবায়ন যুক্তিসঙ্গতভাবে প্রত্যাশা করতে পারে যে এই জাতীয় ক্ষেত্রগুলির জন্য লিখিত কোডটি উপরের মতো কনস্ট্রাক্টগুলি ধারণ করবে না।
একটি মানের বাস্তবায়ন সমস্ত অ্যাক্সেসগুলিকে volatileঅবজেক্টগুলিতে এমন আচরণ করতে পারে যেহেতু তারা এমন ক্রিয়াকে ট্রিগার করতে পারে যা বাইরের বিশ্বের কাছে দৃশ্যমান কোনও বস্তু অ্যাক্সেস করতে পারে।
এম্বেড থাকা সিস্টেমগুলির ব্যবহারের উদ্দেশ্যে একটি সাধারণ তবে শালীন মানের প্রয়োগগুলি সমস্ত কলগুলিকে "ইনলাইন" চিহ্নিত না করে এমন আচরণ করতে পারে যেহেতু তারা বাইরের বিশ্বের কাছে প্রকাশিত কোনও বস্তু অ্যাক্সেস করতে পারে, এমনকি যদি এটি volatile# তে বর্ণিত হিসাবে আচরণ করে না if 2।

মান বাস্তবায়নের জন্য উপরোক্ত পদ্ধতিগুলির মধ্যে কোনটি সবচেয়ে উপযুক্ত হবে, বা কোনও "বিশেষ" উদ্দেশ্যে কার্যকরভাবে ব্যবহারযোগ্য হতে পারে "মেনে চলা" বাস্তবায়ন পর্যাপ্ত-ভাল মানের হওয়া দরকার তা বোঝাতে কোনও স্ট্যান্ডার্ড চেষ্টা করে না। ফলস্বরূপ, কিছু সংকলক যেমন জিসিসি বা ক্ল্যাংয়ের কার্যকরভাবে প্রয়োজন যে কোনও কোড এই প্যাটার্নটি ব্যবহার করতে চাইলে অবশ্যই অনেকগুলি অপ্টিমাইজেশন অক্ষম করে সংকলন করতে হবে।

কিছু ক্ষেত্রে, আই / ও ফাংশনগুলি একটি পৃথক সংকলন ইউনিটে রয়েছে এবং একটি সংকলকের বাইরের বিশ্বের কাছে প্রকাশিত হয়েছে এমন কোনও নির্বিচারে উপসেট অ্যাক্সেস করতে পারে বলে ধরে নেওয়া ছাড়া তাদের কোনও বিকল্প থাকবে না - কোড-অফ-অশুভ পদ্ধতি যা জিসিসি এবং বিড়ম্বনার সাথে নির্ভরযোগ্যভাবে কাজ করবে। এই জাতীয় ক্ষেত্রে, তবে লক্ষ্যটি অহেতুক ফাংশন কলের অতিরিক্ত ব্যয় এড়াতে নয়, বরং প্রয়োজনীয় শব্দার্থবিজ্ঞানের বিনিময়ে হওয়া উচিত-অহেতুক খরচ গ্রহণ করা।

— supercat
সূত্র

"I / O ফাংশনগুলি একটি পৃথক সংকলন ইউনিটে রয়েছে তা নিশ্চিত করে" ... এইগুলির মতো অপ্টিমাইজেশন সমস্যাগুলি প্রতিরোধের একটি নিশ্চিত আগুনের উপায় নয়। কমপক্ষে এলএলভিএম এবং আমি বিশ্বাস করি যে জিসিসি অনেক ক্ষেত্রে পুরো প্রোগ্রামের অপ্টিমাইজেশন সম্পাদন করবে, সুতরাং আপনার আইও ফাংশনগুলি একটি পৃথক সংকলনের ইউনিটে থাকলেও ইনলাইন করার সিদ্ধান্ত নিতে পারে।

— জুলে

@ জুলস: এম্বেডেড সফ্টওয়্যার লেখার জন্য সমস্ত বাস্তবায়ন উপযুক্ত নয়। পুরো প্রোগ্রামটির অপ্টিমাইজেশন অক্ষম করা সেই উদ্দেশ্যে জিসিসি বা ঝনঝনিকে বাধ্য করার পক্ষে সবচেয়ে কম ব্যয়বহুল উপায় হতে পারে সেই উদ্দেশ্যে উপযুক্ত মানের বাস্তবায়ন হিসাবে আচরণ করতে।

— সুপারক্যাট

@ জুলেস: এম্বেড করা বা সিস্টেম প্রোগ্রামিংয়ের উদ্দেশ্যে তৈরি উচ্চ-মানের বাস্তবায়নটি সম্পূর্ণ-প্রোগ্রাম অপটিমাইজেশন সম্পূর্ণরূপে অক্ষম না করেই সে উদ্দেশ্যে উপযুক্ত শব্দার্থকগুলি রাখতে কনফিগার করা উচিত (উদাহরণস্বরূপ volatileঅ্যাক্সেসগুলি চিকিত্সার বিকল্প হিসাবে যেমন তারা সম্ভাব্যভাবে ট্রিগার করতে পারে) অন্যান্য বস্তুগুলিতে নির্বিচারে অ্যাক্সেস করে), তবে যে কারণেই হোক না কেন জিসিসি এবং ঝনঝন বরং বাস্তবায়নের মানটিকে অকার্যকর ফ্যাশনে আচরণের আমন্ত্রণ হিসাবে বিবেচনা করবে।

— সুপারক্যাট

1

এমনকি "সর্বোচ্চ মানের" প্রয়োগগুলি বগি কোডটি ঠিক করবে না। যদি buffএটি ঘোষণা volatileনা করা হয় তবে এটি একটি অস্থায়ী পরিবর্তনশীল হিসাবে বিবেচিত হবে না, এতে অ্যাক্সেসগুলি পুনরায় সাজানো বা সম্পূর্ণরূপে অনুকূলিত করা যেতে পারে যদি আপাতদৃষ্টিতে পরে ব্যবহার না করা হয়। নিয়মটি সহজ: সমস্ত প্রোগ্রামের প্রবাহের বাইরে যে সমস্ত ভেরিয়েবল অ্যাক্সেস করা যায় সেগুলি চিহ্নিত করুন (সংকলক দেখেছেন) হিসাবে volatile। বিষয়বস্তু করছেন buffএকটি ইন্টারাপ্ট হ্যান্ডলার অ্যাক্সেস? হ্যাঁ. তাহলে তা হওয়া উচিত volatile।

— বেরেন্দি -

@ বেরেন্ডি: সংকলকগণ স্ট্যান্ডার্ডের যা প্রয়োজন তার বাইরে গ্যারান্টি সরবরাহ করতে পারে এবং মান সংকলকরা এটি করবে। এম্বেড থাকা সিস্টেমগুলির ব্যবহারের জন্য একটি মানের ফ্রিস্ট্যান্ডিং বাস্তবায়ন প্রোগ্রামারদেরকে মিটেক্স কনস্ট্রাক্টগুলি সংশ্লেষিত করার অনুমতি দেবে, যা কোডটি কী করে তা মূলত করে। যখন magic_write_countশূন্য হয়, স্টোরেজটি মূল-লাইনের মালিকানাধীন। এটি যখন শূন্য নয়, তখন এটি বাধাপ্রাপ্ত হ্যান্ডলারের মালিকানাধীন। মেকিং buffউদ্বায়ী করতে হবে যে প্রতি ফাংশন যে কোন জায়গায় পরিচালনা করে উপরে এটি ব্যবহার volatile-qualified পয়েন্টার, যা অপ্টিমাইজেশান অনেক বেশী একটি কম্পাইলার থাকার চেয়ে দুর্বল হবে ...

— supercat