කාවැද්දූ පද්ධති සඳහා C ++ සුදුසු ද?

පොදු ප්‍රශ්නයක්, මෙහි සහ වෙනත් තැනක. කාවැද්දූ පද්ධති සඳහා C ++ සුදුසු ද?

ක්ෂුද්‍ර පාලක? RTOS? ටෝස්ටර්? කාවැද්දූ පළාත් සභා?

OOP ක්ෂුද්‍ර පාලක සඳහා ප්‍රයෝජනවත්ද?

C ++ කාර්යක්ෂම වීමට දෘඩාංග වලින් ක්‍රමලේඛකයා ඉවත් කරයිද?

Arduino හි C ++ (ගතික මතක කළමනාකරණය, සැකිලි, ව්‍යතිරේක නොමැතිව) "සැබෑ C ++" ලෙස සැලකිය යුතුද?

(මෙම විකිය මෙම විභව ශුද්ධ යුද්ධය අඩංගු ස්ථානයක් ලෙස සේවය කරනු ඇතැයි අපේක්ෂා කරමු)

ඔව්, කාවැද්දූ පද්ධති සඳහා C ++ තවමත් ප්‍රයෝජනවත් වේ. අනෙක් සියල්ලන්ම පවසා ඇති පරිදි, එය තවමත් පද්ධතිය මත රඳා පවතී, බිට් 8 යූසී වැනි පරිගණකයක් මගේ පොතේ නැතැයි සිතිය හැක. එහි සම්පාදකයෙකු සිටියත් සමහර අය එය කරයි (වෙව්ලයි). බිටු 8 ක ක්ෂුද්‍ර ලෝකයක පවා ඔබ එය "C +" වැනි පරිමාණයකට පරිමාණය කළ විට පවා C ++ භාවිතා කිරීමේ වාසියක් ඇත. "C +" යන්නෙන් මා අදහස් කරන්නේ කුමක්ද? මම අදහස් කළේ නව / මකාදැමීම්, ව්‍යතිරේකයන් වළක්වා ගැනීම, උරුමය සහිත අතථ්‍ය පංති වළක්වා ගැනීම, උරුමය සියල්ලම එකට වළක්වා ගැනීම, සැකිලි සමඟ ඉතා ප්‍රවේශම් වීම, මැක්‍රෝස් වෙනුවට පේළිගත කිරීමේ කාර්යයන් භාවිතා කිරීම සහ constඒ වෙනුවට විචල්‍යයන් භාවිතා කිරීම නොවේ #defines.

මම දැන් දශකයකට වැඩි කාලයක් තිස්සේ සී සහ සී ++ යන දෙවර්ගයේම කාවැද්දූ පද්ධතිවල වැඩ කර ඇති අතර, සී ++ සඳහා මගේ තරුණ උනන්දුව නිසැකවම නැති වී ගොස් ඇත. "සීඊ ක්‍රමලේඛකයින් ඊඊ ලෝකයක වල් වී ගොස් ඇත" යනුවෙන් හැඳින්වීමට කැමති කාවැද්දූ පද්ධතිවල සී ++ හි නරකම දේ මම දැක ඇත්තෙමි. ඇත්ත වශයෙන්ම, එය මගේ සේවාදායකයා සමඟ අනෙක් අය අතර ඇති මෙම එක් කේත පදනම වැඩි දියුණු කිරීම සඳහා මම කටයුතු කරමි.

C ++ හි අන්තරාය වන්නේ එය දෙබිඩි කඩුවක් වැනි ඉතා බලවත් මෙවලමක් වන අතර එය භාෂාවෙන් සහ සාමාන්‍ය ක්‍රමලේඛයෙන් ම උගත් හා විනයගරුක නොවන්නේ නම් ඔබේ අත සහ කකුල කපා දැමිය හැකිය. සී යනු තනි දාර කඩුවකට සමාන ය, නමුත් තවමත් තියුණු ය. C ++ සමඟ ඉතා ඉහළ මට්ටමේ සාරාංශයක් ලබා ගැනීම සහ දිගු කාලීනව අර්ථ විරහිත වන අපැහැදිලි අතුරුමුහුණත් නිර්මාණය කිරීම ඉතා පහසු වන අතර, එයට හේතුව විවිධ භාෂා විශේෂාංග (සැකිලි, OOP, ක්‍රියා පටිපාටිය, RTTI, OOP + සැකිලි, අධි බර පැටවීම, පේළිගත කිරීම).

මම C ++ ගුරු ස්කොට් මේයර්ස් විසින් C ++ හි කාවැද්දූ මෘදුකාංග පිළිබඳ පැය 4 ක සම්මන්ත්‍රණ දෙකක් අවසන් කළෙමි. මා මීට පෙර කවදාවත් නොසිතූ සැකිලි පිළිබඳ යම් යම් කරුණු ඔහු පෙන්වා දුන්නේය. එහි සාරාංශය නම්, ඔබට දැඩි ආරක්‍ෂිත-විවේචනාත්මක කේත අවශ්‍යතා සපුරාලිය යුතු මෘදුකාංගයක මළ කේතයක් තිබිය නොහැක. සැකිලි මඟින් ඔබට මෙය සාක්ෂාත් කර ගත හැකිය, මන්ද සම්පාදකයා විසින් අච්චු ස්ථාපනය කිරීමේදී අවශ්‍ය කේතය පමණක් නිර්මාණය කරයි. කෙසේ වෙතත්, සී හි ඉටු කර ගැනීමට අපහසු මෙම අංගය සඳහා නිවැරදිව සැලසුම් කිරීම සඳහා යමෙකු වඩාත් හොඳින් දැනුවත් විය යුතුය, මන්ද සම්බන්ධකයන් සෑම විටම මළ කේත ප්‍රශස්තිකරණය නොකරයි.

ස්කොට් මේයර්ස් යනු සැකිලි පිළිබඳ ඉතා විශාල යෝජකයෙක් වන අතර ඉන්ලයින් කිරීම යුක්තිසහගත ලෙස භාවිතා කරන අතර, සැකිලි ගැන ගුං හෝ වීම පිළිබඳව මට තවමත් සැකයක් ඇති බව පැවසිය යුතුය. ඒවා හොඳම මෙවලම බවට පත්වන තැනට පමණක් ඒවා යෙදිය යුතු යැයි ඔහු පැවසුවද මම ඔවුන්ගෙන් y ත් වීමට නැඹුරු වෙමි. නිවැරදිව භාවිතා කිරීමට පහසු සහ වැරදි ලෙස භාවිතා කිරීමට අපහසු වන හොඳ අතුරුමුහුණත් සෑදීමට C ++ ඔබට මෙවලම් ලබා දෙන බව ද ඔහු පෙන්වා දෙයි. නැවතත්, එය දුෂ්කර කොටසයි. හොඳම සැලසුම් විසඳුම ලෙස මෙම අංග වඩාත් කාර්යක්ෂමව යොදා ගන්නේ කෙසේදැයි දැන ගැනීමට පෙර යමෙකු C ++ හි ප්‍රවීණතා මට්ටමකට පැමිණිය යුතුය.

OOP සඳහා ද එය එසේම වේ. කාවැද්දූ ලෝකය තුළ, ධාවන කාල බහුමාපකයේ ධාවන කාල පිරිවැය හැසිරවිය හැකිදැයි දැන ගැනීමට සම්පාදකයා කෙළ ගසන්නට යන්නේ කුමන ආකාරයේ කේතයක් දැයි ඔබ දැන සිටිය යුතුය. ඔබේ සැලසුම ඔබගේ නියමිත දිනට සරිලන බව සනාථ කිරීම සඳහා මිනුම් කිරීමට ද ඔබ කැමැත්තෙන් සිටිය යුතුය. එම නව InterruptManager පන්තිය මගේ බාධාකාරී ප්‍රමාදය දිගු කිරීමට යන්නේද? C ට කළ හැකි සම්බන්ධක-කාලීන බහුමාපකය වැනි ඔබේ ගැටළුවට වඩාත් ගැලපෙන වෙනත් බහුඅවයවිකතාවන් ඇත, නමුත් C ++ හට Pimpl සැලසුම් රටාව (Opaque pointer) හරහා කළ හැකිය .

සියල්ලන්ටම කිවහොත්, කාවැද්දූ ලෝකයේ C ++ ට එහි ස්ථානයක් ඇති බව මම කියමි. ඔබට අවශ්‍ය සියල්ලට වෛර කළ හැකි නමුත් එය පහව යන්නේ නැත. එය ඉතා කාර්යක්ෂම ආකාරයකින් ලිවිය හැකි නමුත් සී සමඟ වඩා නිවැරදිව එය කරන්නේ කෙසේදැයි ඉගෙන ගැනීම දුෂ්කර ය. සමහර විට එය ගැටළුවක් විසඳීමේදී සහ සමහර විට වඩා හොඳ අතුරු මුහුණතක් ප්‍රකාශ කිරීමේදී සී ට වඩා හොඳින් ක්‍රියා කළ හැකිය, නමුත් නැවතත්, ඔබට සිදුවිය ඔබ ගැන දැනුවත් වන්න, කෙසේ දැයි ඉගෙන ගැනීමට බිය නොවන්න.

C ++ කාවැද්දූ පද්ධති සඳහා නියත වශයෙන්ම සුදුසු ය. විශේෂිත මයික්‍රොප්‍රොසෙසරයක් භාවිතා කළ යුතුද නැද්ද යන්න පිළිබඳ මගේ මූලික නිර්ණායකය ලෙස මම දැන් හොඳ සංවර්ධන මෙවලම් තිබීම (හෝ එහි lack නතාවය) භාවිතා කරමි.

අඩු සම්පත් පිරිවැයක් ඇති බැවින් කාවැද්දූ පද්ධතිවල භාවිතා කිරීමට සුදුසු C ++ ප්‍රදේශ:

• පංති / ව්‍යුහයන් හොඳින් භාවිතා කිරීමෙන් ගෙන එන මොඩියුලරිටි
• සැකිලි නම් සම්පාදකවරයා ඔවුන් කාර්යක්ෂමව සකස් හොඳ රැකියාවක් කරන්නේ. විවිධ දත්ත වර්ග වලට ඇල්ගොරිතම නැවත භාවිතා කිරීම සඳහා ආකෘති හොඳ මෙවලමකි.

හරි ප්‍රදේශ:

• අතථ්‍ය ශ්‍රිත - මම මීට පෙර සිටිමි, නමුත් සම්පත් පිරිවැය ඉතා කුඩාය (එක් පන්තියකට එක් වස්තුවක්, වස්තුවකට නොව, එක් වස්තුවකට vtable වෙත එක් දර්ශකයක්; අතථ්‍ය ශ්‍රිත ඇමතුමකට එක් විරූපී මෙහෙයුමක්) සහ මෙහි ඇති විශාල වාසිය එනම්, විවිධ වර්ගයේ වස්තු කිහිපයක් අඩංගු අරාවක් ලබා ගැනීමට එය ඔබට ඉඩ සලසයි. මම මෑතකදී මෙය භාවිතා කළේ එක් එක් I2C උපාංගයක් නියෝජනය කරන වස්තු සමූහයක්, එක් එක් වෙනම ක්‍රමවේදයන් ඇත.

භාවිතා නොකළ යුතු ප්‍රදේශ, බොහෝ දුරට කුඩා පද්ධතිවල පිළිගත නොහැකි ධාවන කාල සීමාව නිසා:

• ගතික මතක විබෙදුම - අනෙක් අය මෙය සඳහන් කර ඇත, නමුත් ගතික මතක වෙන් කිරීම භාවිතා නොකිරීමට තවත් වැදගත් හේතුවක් වන්නේ එය කාල වේලාවේ අවිනිශ්චිතතාව නිරූපණය කිරීමයි; කාවැද්දූ පද්ධති භාවිතා කිරීමට බොහෝ හේතු තත්‍ය කාලීන යෙදුම් සඳහා වේ.
• RTTI (ධාවන කාල තොරතුරු ක්‍රියාත්මක කරන්න) - මතක පිරිවැය තරමක් විශාලය
• ව්‍යතිරේක - ක්‍රියාත්මක කිරීමේ වේගය නිසා නිශ්චිත අංක-නැත

ඔව්, කාවැද්දූ පද්ධති සඳහා C ++ නිසැකවම සුදුසු ය. පළමුව C සහ C ++ අතර වෙනස පිළිබඳ වැරදි වැටහීම් කිහිපයක් ඉවත් කරමු:

කාවැද්දූ මයික්‍රෝවක් තුළ, ඔබ කාලය හෝ අවකාශයේ සීමාවන් ගැන සැලකිලිමත් වන්නේ නම් සෑම විටම ඉහළ මට්ටමේ භාෂාවන් පරිස්සමින් භාවිතා කිරීමට ඔබට අවශ්‍ය වනු ඇත. උදාහරණයක් ලෙස, බොහෝ MCUs දර්ශකයන් හොඳින් හසුරුවන්නේ නැත, එම නිසා තොගය භාවිතා කිරීමේදී එය ඉතා අකාර්යක්ෂම වේ. මෙයින් අදහස් කරන්නේ විචල්‍යයන් ශ්‍රිත වෙත යැවීම, අරා සහ දර්ශක භාවිතා කිරීම සහ පුනරාවර්තනය පිළිබඳව ඔබ සැලකිලිමත් විය යුතු බවයි. C වැනි සරල රේඛාවක්:

a[i] = b[j] * c[k];

එම විචල්‍යයන්ගේ ස්වභාවය අනුව පිටු 4 ක පමණ උපදෙස් ජනනය කළ හැකිය.

ඔබ ඕනෑම ඉහළ මට්ටමේ භාෂාවක් භාවිතා කරන විට සහ කාලය හා අවකාශයේ සීමාවන් ගැන ඔබ සැලකිලිමත් වන විට , එම භාෂාවේ සෑම අංගයක්ම ඔබේ MCU හි යන්ත්‍ර උපදෙස් වලට පරිවර්තනය කරන්නේ කෙසේදැයි ඔබ දැනගත යුතුය (අවම වශයෙන් ඔබ භාවිතා කරන සෑම අංගයක්ම). C, C ++, Ada, ඕනෑම දෙයක් සඳහා මෙය සත්‍ය වේ. කුඩා MCU වල කාර්යක්ෂමව පරිවර්තනය නොකරන අංග බොහෝ විට සියලුම භාෂාවල අඩංගු වේ. සුළු දෙයක් සඳහා සම්පාදකයා විසින් උපදෙස් නැවත ලබා නොදෙන බවට වග බලා ගැනීම සඳහා විසුරුවා හැරීමේ ලැයිස්තු නිතරම පරීක්ෂා කරන්න.

කාවැද්දූ MCU සඳහා C සුදුසු ද? ඔව්, ඔබ ජනනය කළ කේතය ගැන විමසිල්ලෙන් සිටින තාක් කල්.
කාවැද්දූ MCU සඳහා C ++ සුදුසු ද? ඔව්, ඔබ ජනනය කළ කේතය ගැන විමසිල්ලෙන් සිටින තාක් කල්.

8-බිට් MCU වල පවා C ++ C ට වඩා හොඳ යැයි මම සිතන්නේ මෙන්න: C ++ සඳහා වැඩි දියුණු කළ සහාය සපයයි:

• දත්ත සැඟවීම
• වඩා ශක්තිමත් ටයිප් කිරීම / පරීක්ෂා කිරීම
• පන්ති භාවිතා කරමින් බහු-පර්යන්ත විනිවිදභාවය
• සැකිලි (සෑම විටම පරිස්සමින් භාවිතා කරන්නේ නම්)
• ආරම්භක ලැයිස්තු
• const

මෙම ලක්ෂණ කිසිවක් සී හි සාමාන්‍ය ලක්ෂණ වලට වඩා බර නැත.

ඔබ බිට් 16 හෝ 32 බිට් MCU දක්වා ගමන් කරන විට, C හි විශාල ලක්ෂණ භාවිතා කිරීම අර්ථවත් කිරීමට පටන් ගනී (තොග, ගොඩවල්, දර්ශක, අරා, මුද්‍රණ යනාදිය) ඒ ආකාරයෙන්ම, වඩා බලවත් MCU මත සුදුසු වේ C ++ හි බර ලක්ෂණ භාවිතා කිරීමට (සිරස්, ගොඩවල්, යොමු කිරීම්, STL, නව / මකන්න).

එබැවින්, PIC16 හි C ++ පිළිබඳ සිතුවිල්ලෙන් වෙව්ලන්නට අවශ්‍ය නැත. ඔබේ භාෂාව සහ MCU නිසි ලෙස ඔබ දන්නේ නම්, ඒ දෙකම effectively ලදායී ලෙස එකට භාවිතා කරන්නේ කෙසේදැයි ඔබ දැන ගනු ඇත.

මෙම විවාද කියවීමට විනෝදජනක බව මට නිතරම පෙනේ. පවතින විවිධ භාෂාවල වාසි සහ අවාසි පිළිබඳ බුද්ධිමය සාකච්ඡාව සඳහා එතරම් දෙයක් නොව, සාමාන්‍යයෙන් කෙනෙකුගේ රැකියාව / පළපුරුද්ද / උනන්දුවක් දක්වන ක්ෂේත්‍රය මත පදනම්ව මාතෘකාව පිළිබඳ ස්ථාවරය ඔබට දැනගත හැකිය. “නොමේරූ ප්‍රශස්තිකරණ” තර්ක සමඟ සීඑස් මේජර්වරුන් සහ නඩත්තු ක්‍රමලේඛකයින් නුත් වම සහ දකුණ උපුටා දක්වයි. සැබෑ ලෝකයේ වැඩ කරන අය කාර්ය සාධනය වැදගත් යැයි සිතන ඔවුන් සියල්ලන්ම පිස්සු යැයි සිතති (මම දෙවන කණ්ඩායමේ සාමාජිකයෙකි සාධාරණ වීමට).

දවස අවසානයේදී, ඔබට සී හෝ සී ++ වලින් විශිෂ්ට මෘදුකාංගයක් සංවර්ධනය කළ හැකිය, නැතහොත් භාෂාව මෙහි ඇතුළත් කරන්න . එය පහළට පැමිණෙන්නේ භාෂාවට නොව සංවර්ධකයාගේ හැකියාවන්ට ය. භාෂාවක ප්‍රවීණයෙකු වීම සාමාන්‍යයෙන් අවශ්‍ය වන්නේ ඔබ ආරම්භ කිරීමට වැරදි භාෂාව තෝරාගෙන දැන් ඔබේ ගැටලුව විසඳීම සඳහා එය යුද්ධ කිරීමට අවශ්‍ය නම් පමණි, බොහෝ අවස්ථාවන්හිදී ඔබට අපැහැදිලි අංග හෝ සම්පාදක වෙත කිමිදිය යුතු එකම අවස්ථාව මෙයයි. ඉලක්කය සපුරා ගැනීමට උපක්‍රම.

"මම X සහ බ්ලා බ්ලා භාෂාව පිළිබඳ විශේෂ expert යෙක්" ලෙස මිනිසුන් මෙම තර්ක ආරම්භ කරන බව මට බොහෝ විට අසන්නට ලැබේ. මම අවංකවම වහාම මෙම පුද්ගලයින් අපකීර්තියට පත් කරමි. ගැටලුව විසඳීමට සහ එය කෙතරම් 'සිසිල්' දැයි පෙන්වීමට ඔවුන්ගේ මෙවලම භාවිතා කිරීමට ඇති ඔවුන්ගේ ආශාවෙන්.

මම බොහෝ විට බලා සිටින්නේ සංවර්ධකයින් පළමුව මෙවලම් කට්ටලයක් තෝරාගෙන එය ඔවුන්ගේ ගැටලුවට දෙවනුව නැමීමට උත්සාහ කරන අතර එය සම්පූර්ණයෙන්ම වැරදියි.

මම වෙනත් පිළිතුරකට අදහස් දැක්වීමේදී සඳහන් කළ පරිදි, මෙම භාෂා යුද්ධ බොහෝ විට බෙදී යන්නේ X භාෂාව ක්‍රමලේඛකයාට වඩාත් ගොළු දේවල් කිරීමට ඉඩ සලසන බවට තර්ක කිරීමට ය. කියවීමට විනෝද වන අතරම, මෙම ප්‍රකාශ සියල්ලම සැබවින්ම අදහස් කරන්නේ ඔබට හොඳ සංවර්ධකයින් බඳවා ගැනීමේ ගැටලුවක් ඇති බවත් නරක සංවර්ධකයින් බඳවා ගැනීම දිගටම කරගෙන යාමෙන් සහ ඔවුන්ට සුළු වශයෙන් කළ හැකි මෙවලම් තෝරා ගැනීමෙන් තත්වයට ආධාර කිරීමට උත්සාහ කරනවාට වඩා එම ගැටළුව කෙලින්ම විසඳිය යුතු බවත්ය. හැකි තරම් හානි.

මගේ මතය අනුව හොඳ සංවර්ධකයින්, එය මෘදුකාංග හෝ දෘඩාංග සංවර්ධනය වේවා, ගැටලුව පර්යේෂණය කරන්න, විසඳුමක් ගෘහ නිර්මාණ ශිල්පියා කර විසඳුම 'හොඳම ආකාරයෙන්' ප්‍රකාශ කිරීමට ඉඩ දෙන මෙවලම් සොයා ගන්න. අවශ්‍ය මෙවලම ඔබ මීට පෙර කිසි දිනෙක භාවිතා නොකළ දෙයක් නම් එය වැදගත් නොවේ, ඔබ ව්‍යාපෘති 3 ක් සඳහා භාෂා / සංවර්ධන මෙවලම් භාවිතා කළ පසු නව එකක් තෝරා ගැනීම ඔබේ සංවර්ධන කාලය කෙරෙහි අවම බලපෑමක් ඇති කළ යුතුය.

ඇත්ත වශයෙන්ම, 'හොඳම ක්‍රමය' යනු ආත්මීය යෙදුමක් වන අතර පර්යේෂණ අවධියේදී එය අර්ථ දැක්විය යුතුය. යමෙකුට ගැටළු රාශියක් සලකා බැලිය යුතුය: කාර්ය සාධනය, ප්‍රකාශන පහසුව, කේත ity නත්වය යනාදිය. හේතුවක් නිසා එම ලැයිස්තුවේ නඩත්තු කිරීමේ හැකියාව මා ඇතුළත් කර නැත, ඔබ තෝරා ගන්නා භාෂාව මට ප්‍රශ්නයක් නොවේ, ඔබ නිසි මෙවලම තෝරාගෙන ගැටලුව තේරුම් ගැනීමට කාලය ගත කර ඇත්නම් මෙය 'නොමිලේ' පැමිණිය යුතුය. කේතය නඩත්තු කිරීමට අපහසු වීම බොහෝ විට වැරදි මෙවලමක් හෝ දුර්වල පද්ධති ව්‍යුහයක් තෝරා ගැනීමේ ප්‍රති result ලයකි, මෙහි ප්‍රති results ලය වන්නේ එය ක්‍රියාත්මක කිරීම සඳහා අවලස්සන අවුල් සහගත අවුලකි.

කිසියම් උනන්දුවක් දක්වන ගැටලුවක් නිර්වචනය නොකර ඕනෑම භාෂාවක් ඉල්ලා සිටීම මෝඩකමකි. වස්තු දිශානත ප්‍රවේශයක් සෑම විටම ක්‍රියාකාරී ප්‍රවේශයකට වඩා හොඳ නොවේ. වස්තු නැඹුරු නිර්මාණ ආදර්ශයකට ඉතා හොඳින් ණය ලබා දෙන ගැටළු කිහිපයක් තිබේ. එසේ නොවන බොහෝ දේ ඇත. මිනිසුන් වාදනය කිරීමෙන් සතුටක් ලබන බව පෙනෙන බොහෝ භාෂා ලක්ෂණ පිළිබඳව එකම ප්‍රකාශයක් කළ හැකිය.

කේතයක් ටයිප් කිරීමේ ගැටලුවක් සඳහා ඔබ ඔබේ කාලයෙන් 20% කට වඩා වැය කරන්නේ නම්, ඔබ බොහෝ විට දුර්වල පද්ධතියක් නිෂ්පාදනය කරයි, නැතහොත් ඉතා දුර්වල සංවර්ධකයින් සිටී (හෝ ඔබ තවමත් ඉගෙන ගන්නවා). ඔබ ඔබේ කාලයෙන් වැඩි කාලයක් ගත කරන්නේ ගැටලුව රූපසටහන් කිරීම සහ යෙදුමේ විවිධ කොටස් අන්තර්ක්‍රියා කරන ආකාරය තීරණය කිරීම සඳහා ය. දක්ෂ සංවර්ධකයින් කණ්ඩායමක් සලකුණු පුවරුවක් සහ විසඳීමට ගැටලුවක් ඇති කාමරයක රැඳී සිටීම සහ ඔවුන්ට පැවසීම ඔවුන්ට කිසිදු කේතයක් ලිවීමට හෝ කිසිදු මෙවලමක් තෝරා ගැනීමට ඉඩ නොදෙන අතර සමස්ත පද්ධතිය සමඟ සැපපහසු වන තුරු ඔවුන්ට එහි ගුණාත්මකභාවය වැඩි දියුණු කිරීමට වැඩි යමක් වනු ඇත. සංවර්ධන කාලය වැඩි දියුණු කිරීම සඳහා සහතික කර ඇති උණුසුම් නව මෙවලමක් තෝරා ගැනීමට වඩා ප්‍රතිදානය සහ වේග සංවර්ධනය. (මගේ තර්කයට ප්‍රතිවිරුද්ධ ධ්‍රැවය සඳහා යොමු කිරීමක් ලෙස සීරීම් සංවර්ධනය දෙස බලන්න)

බොහෝ විට අවාසනාවන්ත යථාර්ථය නම්, බොහෝ ව්‍යාපාරවලට සංවර්ධකයෙකුගේ වටිනාකම මැනිය හැක්කේ ලියා ඇති රේඛා ගණනෙන් හෝ 'ස්පර්ශ්‍ය ප්‍රතිදානය' දැකීමෙන් පමණි. සලකුණු පුවරුවක් සහිත කාමරයක සති 3 ක් produc ලදායිතාවයේ අලාභයක් ලෙස ඔවුහු සලකති. සංවර්ධකයින්ට බොහෝ විට සංවර්ධනයේ 'චින්තන' අවධිය හරහා වේගයෙන් යාමට බල කෙරෙනු ඇත හෝ සමාගම තුළ යම් දේශපාලන ප්‍රශ්නයක් විසින් සකස් කරන ලද මෙවලමක් භාවිතා කිරීමට බල කෙරෙයි, "මගේ ලොක්කාගේ සහෝදරයා අයිබීඑම් සඳහා වැඩ කරයි, එබැවින් අපට ඔවුන්ගේ මෙවලම් පමණක් භාවිතා කළ හැකිය", ඒ ආකාරයේ කුණු . හෝ ඊටත් වඩා නරක නම්, ඔබට නිසි වෙළඳපල පර්යේෂණයක් කිරීමට හැකියාවක් නොමැති නිසා හෝ සංවර්ධන චක්‍රයේ වෙනස්කම්වල බලපෑම තේරුම් නොගන්නා නිසා සමාගමෙන් නිරන්තරයෙන් වෙනස් වන අවශ්‍යතා සමූහයක් ඔබට ලැබේ.

කණගාටුවට කරුණක් නම්, මෙම මාතෘකාව සමඟ තරමක් off ත් වී සිටීම ගැන, මට මෙම මාතෘකාව පිළිබඳ තරමක් ශක්තිමත් මත තිබේ.

ඕනෑම භාෂාවක් කාවැද්දූ පද්ධතියකට සුදුසු විය හැකිය. කාවැද්දූ යන්නෙන් අදහස් කරන්නේ: නොමිලේ භාවිතා කළ හැකි පරිගණකයකට වඩා විශාල උපකරණයක කොටසකි.

(අමාරු) තත්‍ය කාලීන හෝ සීමිත සම්පත් පද්ධතියක් ඉල්ලා සිටින විට ප්‍රශ්නයට වැඩි අදාළත්වයක් ඇත.

තත්‍ය කාලීන පද්ධතියක් සඳහා සී ++ යනු දැඩි කාල සීමාවන් සඳහා ක්‍රමලේඛනය කිරීමේදී තවමත් සුදුසු ඉහළම භාෂාවකි. ගොඩවල් භාවිතය (නිදහස් ක්‍රියාකරු) හැරුණු විට එයට අවිනිශ්චිත ක්‍රියාත්මක කිරීමේ කාලයක් ඇති ඉදිකිරීම් නොමැත, එබැවින් ඔබේ ක්‍රමලේඛය එහි කාල අවශ්‍යතා සපුරාලන්නේ දැයි පරීක්ෂා කළ හැකි අතර තවත් අත්දැකීම් සමඟ ඔබට එය පුරෝකථනය කළ හැකිය. නව ක්‍රියාකරු තවමත් එක් වරක් වෙන් කිරීම සඳහා භාවිතා කළ හැකි වුවද, ගොඩවල් භාවිතය ඇත්ත වශයෙන්ම වළක්වා ගත යුතුය. C ට වඩා C ++ පිරිනමන ඉදිකිරීම් කාවැද්දූ පද්ධතියක හොඳ භාවිතයට ගත හැකිය: OO, ව්‍යතිරේක, සැකිලි.

ඉතා සම්පත් සීමිත පද්ධති සඳහා (8-බිට් චිප්ස්, RAM කිලෝමීටරයකට වඩා අඩු, ඇක්සස් කළ නොහැකි තොගයක් නැත) සම්පූර්ණ සී ++ නුසුදුසු විය හැකිය, නමුත් එය තවමත් 'වඩා හොඳ සී' ලෙස භාවිතා කළ හැකිය.

මම හිතන්නේ අඩා භාවිතා කරනුයේ සමහර ස්ථානවල පමණක් බව පෙනේ. බොහෝ ආකාරවලින් එය පැස්කල් ++ ය, නමුත් ආරම්භයේ සිටම බරපතල අවුල් ජාලයක් වූ භාෂාවක් සමඟ ඉහළට අනුකූල වීමේ බරකින් තොරව. (සංස්කරණය කරන්න: බරපතල අවුල ඇත්ත වශයෙන්ම සී. පැස්කල් ලස්සන නමුත් තරමක් ප්‍රායෝගික නොවන භාෂාවකි.)

============================================= =============

සංස්කරණය කරන්න: මම නව ප්‍රශ්නයට පිළිතුරක් ටයිප් කරමින් සිටියෙමි ("අපි මයික්‍රොකොන්ට්රෝලර් ක්‍රමලේඛනය කරන විට C ++ අවශ්‍ය වන්නේ කුමන අවස්ථා වලදීද?") මෙය වසා දමා වසා දමා ඇති බැවින් මම ලියා ඇති දේ එකතු කරමි:

කිසියම් ක්‍රමලේඛන භාෂාවක් භාවිතා කිරීම සඳහා කිසි විටෙකත් සර්වබලධාරී හේතුවක් නොමැත , නමුත් විශේෂිත තත්වයක් තුළ වැඩි හෝ අඩු බරක් ඇති තර්ක තිබිය හැකිය. "ක්ෂුද්‍ර පාලකයක් සඳහා කිසි විටෙකත් C ++ භාවිතා නොකරන්න" සිට "සැමවිටම C ++ භාවිතා කරන්න" දක්වා පරාසයක ගෙන ඇති ස්ථාන සමඟ මේ පිළිබඳ සාකච්ඡා බොහෝ ස්ථානවල සොයාගත හැකිය. මම අන්තිම ස්ථානය සමඟ වැඩියෙන් සිටිමි. මට තර්ක කිහිපයක් ඉදිරිපත් කළ හැකිය, නමුත් යම් තත්වයක් තුළ (සහ කුමන දිශාවට) ඔවුන් කොපමණ බරක් දරන්නේද යන්න ඔබම තීරණය කළ යුතුය.

• සී ++ සම්පාදකයින් සී සම්පාදකයින්ට වඩා දුර්ලභ ය; සමහර ඉලක්ක සඳහා (නිදසුනක් ලෙස 12 සහ 14 බිට් කෝර් PICs) කිසිසේත් C ++ සම්පාදකයින් නොමැත.
• (හොඳ) සී ++ ක්‍රමලේඛකයින් (හොඳ) සී ක්‍රමලේඛකයන්ට වඩා දුර්ලභ ය, විශේෂයෙන් ඉලෙක්ට්‍රොනික් පිළිබඳ (තරමක්) දැනුමක් ඇති අය අතර.
• C ++ ට වඩා කුඩා පද්ධති සඳහා සුදුසු නොවන ඉදිකිරීම් ඇත (ව්‍යතිරේක, RTTI, ගොඩවල් නිතර භාවිතා කිරීම වැනි).
• C ++ ට C ට වඩා පොහොසත් (සම්මත) පුස්තකාල සමූහයක් ඇත, නමුත් පෙර ලක්ෂ්‍යයේ ප්‍රති consequ ලයක් ලෙස C ++ පුස්තකාල බොහෝ විට කුඩා පද්ධති සඳහා නුසුදුසු අංග භාවිතා කරන අතර එම නිසා කුඩා පද්ධති සඳහා භාවිතා කළ නොහැක.
• C ++ ට C ට වඩා වැඩි ඉදිකිරීම් ඇති අතර එමඟින් ඔබට පාදයට වෙඩි තැබිය හැකිය.
• C ++ ට C ට වඩා වැඩි ඉදිකිරීම් ඇති අතර එමඟින් ඔබටම වෙඩි තැබීම වලක්වා ගත හැකිය (ඔව්, IMO මෙය සහ පෙර දෙකම සත්‍ය වේ).
• C ++ සතුව පොහොසත් වියුක්ත යාන්ත්‍රණයක් ඇත, එබැවින් එය පුස්තකාල සඳහා වඩා හොඳ ක්‍රමලේඛන ක්‍රම සක්‍රීය කරයි.
• C ++ භාෂා ලක්ෂණ (නිදසුනක් ලෙස ඉදිකිරීම්කරුවන් / ඩිස්ට්‍රැක්ටර්ස්, පරිවර්තන කාර්යයන්) මඟින් ජනනය කරන ලද යන්ත්‍රය බැලීමට කේතය හරහා බැලීම වඩාත් අපහසු වන අතර එමඟින් භාෂා ඉදිකිරීමේ අවකාශයේ හා වේලාවේ පිරිවැය.
• C ++ භාෂා සැකැස්ම මඟින් යන්ත්‍ර කේතයට හරියටම පරිවර්තනය කරන්නේ කෙසේද යන්න පිළිබඳව දැනුවත්ව සිටීම අඩු අවශ්‍යතාවයක් ඇති බැවින් ඒවා වඩාත් නිවැරදි ආකාරයෙන් 'නිවැරදි දේ' කරයි.
• සී ++ භාෂා ප්‍රමිතිය වේගයෙන් පරිණාමය වෙමින් පවතින අතර විශාල සම්පාදකයින් (ජීසීසී, ක්ලැන්ග්, මයික්‍රොසොෆ්ට්) විසින් එය වේගයෙන් සම්මත කර ගනී. සී තරමක් විකාර සහගත ලෙස පරිණාමය වෙමින් පවතින අතර සමහර නව අංග (විචල්‍ය අරා) භාවිතා කිරීම බිය උපදවන අතර පසුකාලීන ප්‍රමිතියකින් පවා ආපසු හරවා ඇත. මෙම කරුණ විශේෂයෙන් සිත්ගන්නා කරුණක් වන්නේ විවිධ පුද්ගලයින් එය ප්‍රතිවිරුද්ධ ස්ථානවලට සහාය දැක්වීම සඳහා භාවිතා කිරීමයි.
• සී ++ නිසැකවම සී ට වඩා තියුණු මෙවලමකි. අලංකාර මූර්තියක් සෑදීම සඳහා එවැනි මෙවලමක් භාවිතා කිරීමට ඔබේ ක්‍රමලේඛකයින් (හෝ ඔබම) විශ්වාස කරනවාද, නැතහොත් ඔවුන් තමන්ටම රිදවන බවට ඔබ බිය වන අතර අඩු ලස්සන නමුත් අඩු අවදානම් සහිත නිෂ්පාදනයක් සඳහා ඔබ පදිංචි වනු ඇත්ද? ? (මගේ මූර්ති ගුරුවරයා වරක් මට පැවසූ පරිදි, මොට මෙවලම් සමහර අවස්ථාවල තියුණු ඒවාට වඩා භයානක විය හැකි බව මට මතකය .)

මගේ බ්ලොග් අඩවියේ කුඩා පද්ධතිවල (++ ක්ෂුද්‍ර පාලක) C ++ භාවිතා කිරීම පිළිබඳ ලියවිලි තිබේ.

මගේ අත්දැකීම් අනුව, C ++ සාමාන්‍යයෙන් කුඩා කාවැද්දූ පද්ධති වලට නොගැලපේ. එයින් මා අදහස් කරන්නේ, මයික්‍රොකොන්ට්රෝලර් සහ ඕඑස්-අඩු උපාංග.

බොහෝ C ++ OOP ශිල්පීය ක්‍රම ගතික මතක වෙන් කිරීම මත රඳා පවතී. මෙය බොහෝ විට කුඩා පද්ධති වල නොමැත.

එස්ටීඑල් සහ බූස්ට් සැබවින්ම සී ++ හි බලය පෙන්නුම් කරයි, දෙකම අඩිපාරේ විශාල ය.

C ++ මඟින් ක්‍රමලේඛකයාට යන්ත්‍රය වියුක්ත කිරීමට දිරිගන්වයි, එහිදී සීමිත පද්ධති වලදී එය වැලඳ ගත යුතුය.

පසුගිය වසරේ මම වාණිජ දුරස්ථ ඩෙස්ක්ටොප් නිෂ්පාදනයක් ජංගම දුරකථන වෙත ගෙන ගියෙමි. එය C ++ වලින් ලියා ඇති අතර එය වින්ඩෝස්, ලිනක්ස් සහ ඕඑස්එක්ස් මත ධාවනය විය. නමුත් එය STL, ගතික මතකය සහ C ++ ව්‍යතිරේක මත දැඩි ලෙස රඳා පැවතුනි. වින්සීඊ, සිම්බියන් සහ ඕඑස්-අඩු පරිසරයන්හි එය නැවත ලබා ගැනීම සඳහා සී නැවත ලිවීම වඩාත් සුදුසුම විකල්පය විය.

හිස් ලෝහ හා සම්පත් සීමා සහිත පද්ධති පිළිබඳ C ++ පිළිබඳ මෙම සාකච්ඡාවට තාපයට වඩා වැඩි ආලෝකයක් එක් කිරීමට මම බලාපොරොත්තු වෙමි.

C ++ හි ගැටළු:

• ව්‍යතිරේකයන් විශේෂයෙන් RAM ගැටළුවක් වන බැවින් අවශ්‍ය “හදිසි බෆරය” (මතකයෙන් බැහැරව නිදසුනක් ලෙස) පවතින RAM වලට වඩා විශාල විය හැකි අතර එය නිසැකවම ක්ෂුද්‍ර පාලක සඳහා නාස්තියකි. වැඩි විස්තර සඳහා n4049 සහ n4234 බලන්න . ඒවා ක්‍රියා විරහිත කළ යුතුය (එය දැනට නිශ්චිතව දක්වා නැති හැසිරීමකි, එබැවින් වග බලා ගන්න සහ කවදාවත් විසි නොකරන්න). SG14 මේ සඳහා වඩා හොඳ ක්‍රම පිළිබඳව දැනට කටයුතු කරමින් සිටී.

• RTTI කිසි විටෙකත් පොදු කාර්යයට වටින්නේ නැත, එය නිවා දැමිය යුතුය

• විශාල නිදොස් කිරීම් ගොඩනැගීම, මෙය සම්භාව්‍ය ඩෙස්ක්ටොප් සංවර්ධනයේ ගැටලුවක් නොවූවත්, නිදොස් කිරීම චිපයට නොගැලපේ නම් එය ගැටළුවක් විය හැකිය. ගැටළුව පැන නගින්නේ සැකසූ කේතය හෝ පැහැදිලි කිරීම සඳහා එකතු කරන ලද අතිරේක ක්‍රියාකාරී ඇමතුම් මගිනි. මෙම අමතර ක්‍රියාකාරී ඇමතුම් ප්‍රශස්තිකරුවා විසින් නැවත ඉවත් කරනු ඇති අතර අමතර පැහැදිලිකම හෝ නම්‍යතාවය විශාල වාසියක් වනු ඇත, කෙසේ වෙතත් නිදොස් කිරීමේ දී මෙය ගැටළුවක් විය හැකිය.

• ගොඩවල් වෙන් කිරීම. එස්ටීඑල් විසින් අභිරුචි විබෙදන්නන් භාවිතා කිරීමට ඉඩ දී ඇතත් මෙය බොහෝ ක්‍රමලේඛකයින් සඳහා සංකීර්ණ විය හැකිය. ගොඩවල් වෙන් කිරීම නිර්ණය කළ නොහැකි ය (එනම් දෘ real තථ්‍ය කාලය නොවේ) සහ ඛණ්ඩනය වීම පරීක්ෂණයේදී වැඩ කර තිබියදීත් අනපේක්ෂිත මතක තත්වයන්ගෙන් සිදුවිය හැකිය. නිදහස් අවකාශය සහ විවිධ ප්‍රමාණයන් පිළිබඳ තොරතුරු දැනගැනීම සඳහා ගොඩට අවශ්‍ය පොත් තැබීම කුඩා වස්තූන් සමඟ ගැටළුවක් විය හැකිය. සාමාන්‍යයෙන් සංචිත වෙන් කිරීම භාවිතා කිරීම වඩා හොඳය (සී සහ සී ++ යන දෙකින්ම) නමුත් මෙය සංචිතය භාවිතා කිරීමට පමණක් භාවිතා කරන සී ++ ක්‍රමලේඛකයන්ට අසාමාන්‍ය විය හැකිය.

• ධාවන බහුඅවයවිකතාව සහ වෙනත් වක්‍ර ඇමතුම් සාමාන්‍යයෙන් විශාල කාර්ය සාධනයක් වන අතර, ගැටළුව සාමාන්‍යයෙන් වැඩි වන්නේ ප්‍රශස්තකරණයට ඒවා ලබා ගැනීමට සහ ලිපිනයට පැනීමට වඩා වැඩි යමක් දැක ගත නොහැකි බැවිනි. C සහ C ++ වල මෙම හේතුව නිසා වක්‍ර ඇමතුම් වළක්වා ගත යුතු අතර C ++ හි මෙන් ඔවුන් සංස්කෘතිය තුළ වඩාත් මුල් බැසගෙන ඇත (සහ අනෙකුත් වසම්වල එය බෙහෙවින් ප්‍රයෝජනවත් වේ).

• ක්ලිබ් සමඟ ව්‍යංගයෙන් සම්බන්ධ වීම ගැටළු සහගත විය හැකිය. ක්ලිබ් ගැටළු C ++ කාණ්ඩයට අයත් බව ප්‍රතිවිරුද්ධ විය හැකි නමුත් ගැටළුව පැන නගින්නේ සමගාමී පරිසරයන්හි සම්පත් ව්‍යංගයෙන් බෙදා ගැනීමෙනි (බෙදාගැනීම C හි වඩාත් පැහැදිලිව පෙනේ). පොදු නිව් ලිබ් ක්‍රියාවට නැංවීම බොහෝ විට සාමාන්‍යයෙන් යූසී වල අවශ්‍ය නොවන බොහෝ පිපිරීම් වලට ඇද දමයි, අනෙක් අතට නිව් ලිබ්නානෝ නැවත නොපැමිණෙන බැවින් එයට ප්‍රවේශය අනුක්‍රමික කළ යුතුය (මෙහි අති විශාල කිරීම). මෙය සී සඳහා ද ගැටළුවක් වන නමුත් ප්‍රවේශය වඩාත් පැහැදිලිය. රීතියක් ලෙස යමෙකු මූලික වශයෙන් අයිඑස්ආර් සන්දර්භය තුළ නාම අවකාශයේ සිට කිසිවක් භාවිතා නොකළ යුතුය, එය කෙසේ හෝ ක්ලිබ් වලින් තත්වයට පිවිසෙන්නේ නැති බව ඔබට විශ්වාස නම් මිස (දෝෂයක් හෝ ගොඩවල්). මැලෝක් සහ නොමිලේ ප්‍රවේශය සමමුහුර්ත කිරීම සඳහා ඔබ නව සහ අභිබවා යෑමට නූල් භාවිතා කරන්නේ නම් එය වැදගත් වේ.

අවසාන වශයෙන් C ++ ට යම් ගැටළු ඇති නමුත් ඒවා සියල්ලම නිවැරදි කළ හැකි හෝ වළක්වා ගත හැකිය.

දැන් සී සඳහා, මෙහි ගැටලුව ඉහළ පිළිවෙලකි. සංයුක්ත වේලාවේදී මට ප්‍රශස්තිකරණය කිරීමට හෝ වෙනස්වීම් පරීක්ෂා කිරීමට හැකි වන පරිදි දේවල් සාරාංශ කිරීමට සී හි සින්ටැක්ටික් හැකියාව මට නැත. එම නිසා පරිශීලකයා ඒවා භාවිතා කිරීම සඳහා ඒවා ක්‍රියා කරන්නේ කෙසේදැයි දැන ගැනීමට අවශ්‍ය නොවන පරිදි මට නිසි ලෙස සම්බන්ධ කර ගත නොහැකි අතර මගේ බොහෝ දෝෂ හඳුනාගැනීම ක්‍රියාත්මක වන්නේ වේලාවටය (එය ප්‍රමාද වී ඇතිවා පමණක් නොව පිරිවැයද එකතු කරයි). C හි සාමාන්‍ය විය හැකි එකම ක්‍රමය දත්ත හරහා වන අතර, මම ආකෘති පත්‍රයක් printf හෝ scanf වෙත යොමු කරමි. නිවැරදි දත්ත සම්මත කිරීමේදී න්‍යායාත්මකව කළ හැකි විකල්ප කිහිපයක් මා භාවිතා නොකරන බව සම්පාදකයාට ඔප්පු කිරීම තරමක් අපහසු වන අතර එයින් අදහස් කරන්නේ විභව මළ කේත උත්පාදනය සහ ප්‍රශස්තිකරණ විභවය නැතිවීමයි.

මම මෙහි ජරාවාස කුණාටුවක් මුදාහරින බව මම දනිමි, නමුත් බිට් 32 මයික්‍රොකොන්ට්රෝලර් පිළිබඳ මගේ අත්දැකීම නම් ඇපල් ගෙඩියක ඇපල් හා සී හා සී ++ සංසන්දනය විශේෂ experts යන් විසින් ලියන ලද්දකි (සී ++ හි ඉතා ඉහළ සැකැස්මක් ඇති පරිදි) සී ++ වඩාත් කාර්යක්ෂම භාෂාව වන විගසම ඕනෑම දෙයක් කිසිසේත්ම සාමාන්‍ය විය යුතුය (ඕනෑම පුස්තකාලයක මෙන්) ඒවා සාමාන්‍ය නොවන අවස්ථාවන්හිදී සමාන වේ. නවකයකුට C ++ හි විශේෂ library පුස්තකාල ක්‍රියාත්මක කරන්නෙකුගේ විශේෂ ise දැනුම ලබා ගැනීම පහසුය.

ඒ අතරම ඇත්ත වශයෙන්ම මට වැරදි දත්ත යැවිය නොහැකි කාර්යයන් ස්වල්පයක් ඇත, ආදානය යනු int එකක් නොව, somethingමා විසින් int භාවිතා කිරීමේ ක්‍රමයක් ලෙස භාවිතා කරන විට, එය ලබා ගැනීමේ විභවයක් ඇත වැරදියි ('යමක්' වෙනුවට අවලංගු අගයක් හෝ 'වෙනත් දෙයක්' ලබා දෙන්න). C හි මගේ එකම ක්‍රමය පරිශීලකයා වැරදියට ඇත්දැයි පරීක්ෂා කිරීමේ ක්‍රමය ක්‍රියාත්මක වේ. සී ++ හි මට සමහර චෙක්පත් සිදු කිරීමේ හැකියාව ඇත, සියලු චෙක්පත් නොව සමහර චෙක්පත් නොමිලේ සම්පාදනය කරන වේලාවේදී.

දවස අවසානයේදී සී කණ්ඩායමක් බොහෝ විට එහි දුර්වලම ක්‍රමලේඛකයා තරම් බලවත් වන අතර එහි ප්‍රති code ලයක් ලෙස ලැබෙන කේතයේ ප්‍රතිලාභයට 1 ගුණක හෝ කාර්ය සාධන ද .ුවමක් ඇත. මා මෙයින් අදහස් කරන්නේ එය එක්කෝ අද්විතීය නිර්මාණ තීරණ වල අද්විතීය පරිසරයක එක් හා එකම අද්විතීය රැකියාවක් සඳහා ඉහළ කාර්ය සාධනයක් හෝ බහු පරිසරයක භාවිතා කිරීමට තරම් සාමාන්‍යය (වෙනත් ක්ෂුද්‍ර පාලක, වෙනත් මතක කළමනාකරණ උපාය, වෙනත් ප්‍රමාද එදිරිව. ප්‍රතිදාන වෙළඳ ලකුණු ආදිය.) නමුත් ආවේනික කාර්ය සාධන පිරිවැයක් ඇත.

C ++ හි විශේෂ experts යින් විසින් දේවල් සංයුක්ත කර ගත හැකි අතර බොහෝ කේත පරිසරය තුළ කාල කේත උත්පාදනය නිශ්චිත කර්තව්‍යයට අනුවර්තනය වන අතර ස්ථිතික පරීක්ෂාව මඟින් ශුන්‍ය පිරිවැයකින් මෝඩ දේවල් කිරීමෙන් පරිශීලකයින් වළක්වයි. මෙහිදී අපට ජනක වීම සහ වේගවත් වීම අතර වෙළඳාමේ අඩු අගයක් ඇති අතර අවසානයේ පිරිවැය හා එදිරිව ප්‍රතිලාභ දෘෂ්ටි කෝණයෙන් වඩා ක්‍රියාකාරී, ආරක්ෂිත සහ වඩා tive ලදායී භාෂාවකි.

කාවැද්දීම සඳහා හොඳ C ++ පුස්තකාලවල තවමත් විශාල හිඟයක් පවතින බව වලංගු විවේචනයක් වන අතර, මෙය C ++ සම්පාදකයෙකු මත වැඩිපුරම C භාවිතා කිරීම සඳහා ප්‍රායෝගික තීරණ ගැනීමට හේතු වේ. ව්‍යාපෘතියක C පමණක් භාවිතා කිරීමේ තීරණ අත්‍යවශ්‍යයෙන්ම දෘෂ්ටිවාදාත්මකව මෙහෙයවනු ලබන අතර, උරුමයේ සහාය අවශ්‍යතාවයෙන් හෝ C ++ හි කළ හැකි නමුත් තෝරා නොගත් මෝඩ දේවල් සමූහයකින් වැළකී සිටීමට කණ්ඩායම විනයගරුක නොවන බව පිළිගැනීම. ඒ සමඟම C හි ආරක්ෂා කළ නොහැකි නමුත් C ++ වලින් කළ හැකි වඩා විශාල මෝඩ දේවල් කිසිවක් නොකිරීමට තරම් විනයගරුක විය.

මගේ පසුබිම: පැරණි බෙල් ලැබ් ක්‍රමලේඛකයින් යටතේ පාසල් පුහුණුවෙන් බැහැරව; වසර 3 ක් සේවය කරමින්, 2 උපාධි අපේක්ෂක පර්යේෂණ ව්‍යාපෘතියේ; VB.NET හි දත්ත ලබා ගැනීම / ක්‍රියාවලි පාලනය. VB6 හි ව්‍යවසාය දත්ත සමුදා යෙදුමක වැඩ කිරීම සඳහා වසර 1.5 ක් ගත කළේය. දැනට 2GB ආචයනය, 512MB RAM, 500MHz x86 CPU සහිත කාවැද්දූ PC සඳහා ව්‍යාපෘතියේ වැඩ කරමින් සිටී ; අයිපීසී යාන්ත්‍රණයක් සමඟ සී ++ හි සමගාමීව ලියා ඇති යෙදුම් කිහිපයක්. ඔව්, මම තරුණයි.

මගේ මතය: මා ඉහත ලියා ඇති පරිසරය අනුව C ++ effectively ලදායී ලෙස ක්‍රියා කළ හැකි යැයි මම සිතමි . පිළිගත හැකි කරුණක් නම්, තථ්‍ය කාලීන කාර්ය සාධනය මා සිටින යෙදුමට අවශ්‍යතාවයක් නොවන අතර සමහර කාවැද්දූ යෙදුම්වල එය ගැටළුවක් විය හැකිය. නමුත් මම ඉගෙන ගත් දේවල් මෙන්න:

• C ++ C ට වඩා මූලික වශයෙන් වෙනස් වේ (එනම්, C / C ++ නොමැත). වලංගු C සෑම දෙයක්ම වලංගු C ++ වන අතර, C ++ ඉතා වෙනස් භාෂාවක් වන අතර ඕනෑම තත්වයක් තුළ එය effectively ලදායී ලෙස භාවිතා කිරීම සඳහා C ++ නොව C ++ හි ක්‍රමලේඛනය කරන්නේ කෙසේදැයි ඉගෙන ගත යුතුය . C ++ හි, ඔබට වස්තු-නැඹුරුවකින් වැඩසටහන්ගත කළ යුතුය, ක්‍රියාපටිපාටියෙන් නොවේ, සහ දෙමුහුන් නොවේ (විශාල පන්ති විශාල කාර්යයන් සහිත). පොදුවේ ගත් කල, ඔබ කාර්යයන් කිහිපයක් සහිත කුඩා පන්ති සෑදීම කෙරෙහි අවධානය යොමු කළ යුතු අතර, සියලු කුඩා පංති එකට එකතු කර විශාල විසඳුමක් බවට පත් කළ යුතුය. මගේ සහායකයෙක් මට පැහැදිලි කළේ මම ක්‍රමානුකූලව වස්තූන් තුළ ක්‍රමලේඛනය කිරීමට පුරුදුව සිටි බවත් එය විශාල අවුලක් බවත් එය නඩත්තු කිරීමට අපහසු බවත්ය. මම වඩාත් වස්තු-නැඹුරු ශිල්පීය ක්‍රම භාවිතා කිරීමට පටන් ගත් විට, මගේ කේතයේ නඩත්තු කිරීමේ හැකියාව / කියවීමේ හැකියාව ඉහළ ගොස් ඇති බව මට පෙනී ගියේය.

• C ++ කියවීම / නඩත්තු කිරීම පහසු කිරීම සඳහා කේතය සරල කිරීමට මාර්ගයක් සැපයිය හැකි වස්තු-නැඹුරු සංවර්ධනයේ ස්වරූපයෙන් අමතර විශේෂාංග සපයයි . අවංකවම, OOP සිදු කිරීමේදී කාර්ය සාධනය / අභ්‍යවකාශ කාර්යක්ෂමතාව වැඩි දියුණු කිරීම සඳහා බොහෝ දේ ඇතැයි මම නොසිතමි. නමුත් මම හිතන්නේ OOP යනු සංකීර්ණ ගැටළුවක් කුඩා කැබලිවලට බෙදීමට උපකාරී වන තාක්‍ෂණයකි. නොසලකා හැරිය යුතු මෙම ක්‍රියාවලියේ අංගයක් වන කේතය මත වැඩ කරන පුද්ගලයින්ට එය ප්‍රයෝජනවත් වේ.

• C ++ ට එරෙහි බොහෝ තර්ක මූලික වශයෙන් ගතික මතක වෙන් කිරීම සමඟ සම්බන්ධ වේ. සී ට ද මෙම ගැටලුව ඇත. ගතික මතකය භාවිතා නොකර ඔබට වස්තු දිශානත යෙදුමක් ලිවිය හැකිය, නමුත් වස්තූන් භාවිතා කිරීමේ එක් වාසියක් නම් ඔබට මේවා පහසුවෙන් ගතික ආකාරයකින් වෙන් කළ හැකිය. C හි මෙන්, මතක කාන්දු වීම අවම කිරීම සඳහා දත්ත කළමනාකරණය කරන්නේ කෙසේද යන්න පිළිබඳව ඔබ සැලකිලිමත් විය යුතුය, නමුත් RAII තාක්‍ෂණය C ++ වලින් මෙය සරල කරයි (ගතික මතකය ස්වයංක්‍රීයව වස්තූන් තුළට කොටු කිරීමෙන් ස්වයංක්‍රීයව විනාශ කරන්න). සමහර යෙදුම් වල, සෑම මතක ස්ථානයක්ම ගණන් කරන විට, මෙය කළමනාකරණය කිරීමට තරම් වල් සහ ලොම් විය හැකිය.

සංස්කරණය කරන්න:

• WRT "Arduino C ++" ප්‍රශ්නය : ගතික මතක කළමනාකරණයකින් තොරව C ++ තවමත් ප්‍රයෝජනවත් විය හැකි යැයි මම තර්ක කරමි . ඔබට ඔබේ කේතය වස්තූන් ලෙස සංවිධානය කළ හැකි අතර, එම වස්තු ඔබේ යෙදුම තුළ විවිධ ස්ථානවලට ස්ථානගත කළ හැකිය, ඇමතුම් ආපසු ලබා ගැනීමේ අතුරුමුහුණත් යනාදිය. තොගය තවමත් වස්තූන් සමඟ ප්‍රයෝජනවත් වේ. මම පිළිගනිමි - මම කිසි විටෙකත් Arduino සඳහා එබඳු කාවැද්දූ යෙදුමක් ලියා නැත, එබැවින් මගේ ප්‍රකාශය පිටුපස මට කිසිදු සාක්ෂියක් නොමැත. ඉදිරියට එන ව්‍යාපෘතියක Arduino සංවර්ධනයක් කිරීමට මට අවස්ථා කිහිපයක් තිබේ - මගේ ඉල්ලීම එහි දී පරීක්ෂා කළ හැකිය.

ඔව්, C ++ සමඟ ඇති ගැටළුව වන්නේ කේතයේ අඩිපාර වැඩි කිරීමයි.

සමහර පද්ධති වලදී ඔබ බයිට් ගණන් කරන අතර, එවැනි අවස්ථාවකදී ඔබේ පද්ධතිවල සීමාවට ආසන්නව ධාවනය කිරීමේ පිරිවැය පිළිගැනීමට සිදුවනු ඇත.

එහෙත්, සී හි පවා, හොඳින් සැලසුම් කරන ලද පද්ධතියක් සඳහා ඔබ සියල්ල සංවෘතව තබා ගත යුතුය. හොඳින් සැලසුම් කරන ලද පද්ධති දුෂ්කර වන අතර C ++ ක්‍රමලේඛකයන්ට ඉතා ව්‍යුහාත්මක හා පාලිත සංවර්ධන ක්‍රමයක් සඳහා ස්ථානයක් ලබා දෙයි. OOP ඉගෙන ගැනීමට පිරිවැයක් ඇති අතර, ඔබට එයට මාරුවීමට අවශ්‍ය නම් ඔබ එය බොහෝ දුරට පිළිගනී. බොහෝ අවස්ථාවන්හිදී කළමනාකාරිත්වය C සමඟ ඉදිරියට යන අතර පිරිවැය නොගෙවනු ඇත, මන්ද ස්විචයක ප්‍රති results ල මැනීම දුෂ්කර බැවින් tivity ලදායිතාව වැඩි කරයි. කාවැද්දූ පද්ධති ගුරු ජැක් ගැන්ස්ලේගේ ලිපියක් ඔබට මෙහි දැක ගත හැකිය .

ගතික මතක කළමනාකරණය යක්ෂයා ය. ඇත්ත වශයෙන්ම නොවේ, යක්ෂයා ස්වයංක්‍රීය මාර්ගයකි, පරිගණකයක ගතික මතක කළමනාකරණය විශිෂ්ට ලෙස ක්‍රියා කරයි, නමුත් අවම වශයෙන් සෑම සති කිහිපයකට වරක් පරිගණකයක් නැවත ආරම්භ කිරීමට ඔබට අපේක්ෂා කළ හැකිය. කාවැද්දූ පද්ධතියක් වසර 5 ක් අඛණ්ඩව ක්‍රියාත්මක වන විට ගතික මතක කළමනාකරණයට සැබවින්ම ඉස්කුරුප්පු කළ හැකි අතර එය අසාර්ථක වීමට පටන් ගනී. ගැන්ස්ල් සිය ලිපියේ සිරස් සහ ගොඩවල් වැනි දේවල් සාකච්ඡා කරයි.

C ++ හි ගැටළු ඇතිවීමට හා බොහෝ සම්පත් භාවිතා කිරීමට වැඩි ඉඩක් ඇත, ගතික මතක කළමනාකරණය සහ සැකිලි ඉවත් කිරීම C ++ හි අඩිපාර C හි අඩිපාරට සමීපව තබා ගැනීමට විශාල පියවර වේ. මෙය තවමත් C ++ ය, ඔබට ගතික අවශ්‍ය නොවේ මතක කළමනාකරණය හෝ හොඳ C ++ ලිවීමට සැකිලි. ඔවුන් ව්‍යතිරේකයන් ඉවත් කළ බව මා දැන සිටියේ නැත, මගේ කේතයේ ව්‍යතිරේකයන් මම නිකුතුවේදී ඉවත් කරන වැදගත් කොටසක් ලෙස සලකමි, නමුත් එම අවස්ථාව දක්වා භාවිතා කරන්න. ක්ෂේත්‍ර පරීක්ෂණයේදී ව්‍යතිරේකයක් හසු වී ඇති බව මට දැනුම් දීම සඳහා ව්‍යතිරේකයන් පණිවිඩ ජනනය කළ හැකිය.

මම හිතුවේ ලිනස් ටොවල්ඩ්ස්ගේ මෙම සී-විරෝධී රැන්ට් එක රසවත් බවයි.

C ++ හි නිරපේක්ෂ නරකම අංගයක් වන්නේ එය බොහෝ දේ සන්දර්භය මත රඳා පවතින ආකාරයයි - එයින් අදහස් වන්නේ ඔබ කේතය දෙස බලන විට, දේශීය දර්ශනයක් සිදුවන්නේ කුමක් දැයි දැන ගැනීමට ප්‍රමාණවත් සන්දර්භයක් ලබා දෙන බවයි.

ඔහු කතා කරන්නේ කාවැද්දූ පද්ධති ලෝකය ගැන නොව ලිනක්ස් කර්නල් සංවර්ධනය ගැන ය. මට නම්, අදාළත්වය මෙයින් පැමිණේ: C ++ ට විශාල සන්දර්භයක් අවබෝධ කර ගැනීම අවශ්‍ය වන අතර, මට වස්තු සැකිලි සමූහයක් භාවිතා කිරීමට ඉගෙන ගත හැකිය, මාස කිහිපයකින් කේතය යාවත්කාලීන කිරීමට සිදු වූ විට ඒවා මතක තබා ගැනීමට මා විශ්වාස නොකරමි.

(අනෙක් අතට, මම දැනට කාවැද්දූ උපාංගයක් මත වැඩ කරන්නේ පයිතන් (C ++ නොව එකම OOP ආදර්ශය භාවිතා කරමින්) හරියටම එම ගැටලුව ඇති වනු ඇත.මගේ ආරක්ෂාව සඳහා, එය PC ලෙස හැඳින්වීමට තරම් බලවත් කාවැද්දූ පද්ධතියකි. අවුරුදු 10 කට පෙර.)

වෙනත් පිළිතුරු වාසි සහ අවාසි සහ තීරණ ගැනීමේ සාධක සඳහා හොඳ අවස්ථාවක් ලබා දී ඇතැයි මම සිතමි, එබැවින් මම සාරාංශ කොට අදහස් කිහිපයක් එකතු කිරීමට කැමැත්තෙමි.

කුඩා ක්ෂුද්‍ර පාලක සඳහා (8-බිට්), ක්‍රමයක් නැත. ඔබ ඉල්ලා සිටින්නේ ඔබට රිදවන ලෙසයි, කිසිදු වාසියක් නොමැති අතර ඔබ ඕනෑවට වඩා සම්පත් අත්හරිනු ඇත.

හොඳ මෙහෙයුම් පද්ධතියක් ඇති ඉහළ මට්ටමේ මයික්‍රොකොන්ට්රෝලර් සඳහා (උදා: RAM සහ ගබඩා කිරීම සඳහා 32-බිට්, 10s හෝ 100 MB) එය හොඳින් ගැලපෙන අතර, මම නිර්දේශ කරමි.

ඉතින් ප්‍රශ්නය: සීමාව කොහේද?

මම නිශ්චිතවම නොදනිමි, නමුත් වරක් මම C ++ හි 1 MB RAM සහ 1 MB ආචයනයක් සහිත 16-බිට් uC සඳහා පද්ධතියක් සංවර්ධනය කළෙමි, පසුව එය පසුතැවීම සඳහා පමණි. ඔව්, එය ක්‍රියාත්මක විය, නමුත් මා සතුව තිබූ අමතර වැඩ එය වටින්නේ නැත. මට එය යෝග්‍ය කිරීමට සිදු විය, ව්‍යතිරේක වැනි දේ කාන්දුවීම් ඇති නොවන බවට වග බලා ගන්න (OS + RTL සහාය තරමක් දෝෂ සහිත සහ විශ්වාස කළ නොහැකි විය). තවද, OO යෙදුමක් සාමාන්‍යයෙන් කුඩා ප්‍රතිපාදන රාශියක් සිදු කරයි.

එම අත්දැකීම අනුව, මම අනාගත ව්‍යාපෘති සඳහා C ++ තෝරා ගන්නේ අවම වශයෙන් 16-බිට් පද්ධතිවල පමණක් වන අතර අවම වශයෙන් 16 MB වත් RAM සහ ගබඩා කිරීම සඳහා තෝරා ගනිමි. එය අත්තනෝමතික සීමාවක් වන අතර, බොහෝ විට යෙදුම් වර්ගය, කේතීකරණ ශෛලීන් සහ මෝඩකම් වැනි දේ අනුව වෙනස් වේ. නමුත් අවවාද අනුව, මම ඒ හා සමාන ප්‍රවේශයක් නිර්දේශ කරමි.

කාවැද්දූ පද්ධති සඳහා ප්‍රයෝජනවත් වන C ++ හි සමහර අංග තිබේ. ව්‍යතිරේක වැනි තවත් ඒවා තිබේ, ඒවා මිල අධික විය හැකි අතර ඒවායේ පිරිවැය සැමවිටම නොපෙනේ.

මගේ බේබද්දන් සිටියේ නම්, ලෝක දෙකෙහිම හොඳම දේ ඒකාබද්ධ කරන ජනප්‍රිය භාෂාවක් ඇති අතර භාෂා දෙකෙහිම නොමැති සමහර අංග ඇතුළත් විය; සමහර වෙළෙන්දන්ට එවැනි විශේෂාංග කිහිපයක් ඇතුළත් වේ, නමුත් ප්‍රමිතීන් නොමැත. මම දැකීමට කැමති කරුණු කිහිපයක්:

1. ව්‍යතිරේකය ජාවා වැනි තව ටිකක් හැසිරවීම, එහිදී ව්‍යතිරේකයන් විසි කිරීමට හෝ කාන්දු විය හැකි කාර්යයන් ප්‍රකාශ කළ යුතුය. එවැනි ප්‍රකාශයන් සඳහා වන අවශ්‍යතාවයක් ක්‍රමලේඛන දෘෂ්ටිකෝණයකින් තරමක් කරදරකාරී විය හැකි නමුත්, එය සාර්ථක වුවහොත් අත්තනෝමතික පූර්ණ සංඛ්‍යාවක් ආපසු ලබා දිය හැකි අවස්ථා වලදී කේතයේ පැහැදිලි බව වැඩි දියුණු කරයි. බොහෝ වේදිකාවලට මෙය මිල අඩු ලෙස කේතයෙන් හැසිරවිය හැක. උදා: ලේඛනයේ ප්‍රතිලාභ අගය සහ රැගෙන යාමේ ධජයේ සාර්ථක / අසාර්ථක ඇඟවීම්.
2. ස්ථිතික හා පේළිගත කාර්යයන් පමණක් අධික ලෙස පැටවීම; මගේ අවබෝධය නම්, සී සඳහා වන ප්‍රමිති ආයතන, නම හැසිරවීමේ අවශ්‍යතාවය වළක්වා ගැනීම සඳහා ක්‍රියාකාරී බර පැටවීම වළක්වා ඇති බවයි. ස්ථිතික හා පේළිගත කාර්යයන් අධික ලෙස පැටවීමට ඉඩ දීමෙන් එම ගැටළුව මඟහරවා ගත හැකි අතර බාහිර කාර්යයන් අධික ලෙස පැටවීමේ ප්‍රතිලාභයෙන් 99.9% ක් ලබා දෙනු ඇත (.h ලිපිගොනු වලට වෙනස් ලෙස නම් කරන ලද බාහිර කාර්යයන් අනුව පේළිගත බර පැටවීම අර්ථ දැක්විය හැකි බැවින්)
3. අත්තනෝමතික හෝ විශේෂිත සම්පාදක-කාල-විසඳිය හැකි නියත පරාමිති අගයන් සඳහා අධි බර පැටවීම. කිසියම් නියත අගයක් සමඟ සම්මත වූ විට සමහර කාර්යයන් ඉතා කාර්යක්ෂමව පේළිගත කළ හැකි නමුත් විචල්‍යයක් පසු කළ හොත් එය ඉතා දුර්වල ලෙස පේළි කරයි. අගය නියත නම් ප්‍රශස්තිකරණය විය හැකි වෙනත් කාල කේතය එය එසේ නොවේ නම් අශුභවාදී විය හැකිය. උදාහරණයක් වශයෙන්:

   inline void copy_uint32s (uint32_t * dest, const uint32_t * src, __is_const int n)
   {
     (n <= 0) ආපසු නම්;
     වෙනත් නම් (n == 1) {dest [0] = src [0];}
     වෙනත් නම් (n == 2) {dest [0] = src [0]; dest [1] = src [1];}
     else if (n == 3) {dest [0] = src [0]; dest [1] = src [1]; dest [2] = src [2];}
     else if (n == 4) {dest [0] = src [0]; dest [1] = src [1]; dest [2] = src [2]; dest [3] = src [3];}
     else memcpy ((void *) dest, (const void *) src, n * sizeof (* src));
   }
   

   සම්පාදනය කරන වේලාවේදී 'n' ඇගයීමට ලක් කළ හැකි නම්, ඉහත කේතය memcpy සඳහා වන ඇමතුමකට වඩා කාර්යක්ෂම වනු ඇත, නමුත් සම්පාදනය කරන වේලාවේදී 'n' තක්සේරු කළ නොහැකි නම්, ජනනය කරන ලද කේතය හුදෙක් කේතයට වඩා විශාල හා මන්දගාමී වනු ඇත. memcpy ලෙස හැඳින්වේ.

C ++ හි කාවැද්දූ-පමණක් අනුවාදයක් සඳහා C ++ හි පියා එතරම් උනන්දුවක් නොදක්වන බව මම දනිමි, නමුත් C භාවිතා කිරීමෙන් පමණක් සැලකිය යුතු දියුණුවක් ලබා දිය හැකි යැයි මම සිතමි.

ඉහත සඳහන් ඕනෑම දෙයක් ඕනෑම ප්‍රමිතියක් සඳහා සලකා බලනු ඇත්දැයි ඕනෑම අයෙක් දන්නවාද?

C ++ යනු එක් ක්‍රමලේඛන භාෂාවකි:

අ) එය “වඩා හොඳ” සී ආ) එය වස්තු නැඹුරු භාෂාවක් ඇ) එය සාමාන්‍ය වැඩසටහන් ලිවීමට අපට ඉඩ සලසන භාෂාවකි

මෙම සියලු අංගයන් වෙන වෙනම භාවිතා කළ හැකි වුවද, ඒවා තුනම එකවර භාවිතා කරන විට හොඳම ප්‍රති results ල ලබා ගත හැකිය. එසේ වුවද, ඔබ ඒවායින් එකක් පමණක් තෝරා ගැනීමට තෝරා ගන්නේ නම් කාවැද්දූ මෘදුකාංගයේ ගුණාත්මකභාවය ඉහළ යනු ඇත.

a) එය “වඩා හොඳ” සී

සී ++ යනු ශක්තිමත් ටයිප් කළ භාෂාවකි; සී ට වඩා ශක්තිමත්. ඔබේ වැඩසටහන් මෙම අංගයෙන් ප්‍රතිලාභ ලබයි.

සමහර අය දර්ශකයන්ට බිය වෙති. C ++ හි යොමු කිරීම් ඇතුළත් වේ. අධික ලෙස පටවන ලද කාර්යයන්.

කීමට වටිනවා: මෙම ලක්ෂණ කිසිවක් විශාල හෝ මන්දගාමී වැඩසටහන් වලට භාජනය නොවීය.

ආ) එය වස්තු නැඹුරු භාෂාවකි

මයික්‍රොකොන්ට්රෝලර්වල යන්ත්රය වියුක්ත කිරීම හොඳ අදහසක් නොවන බව යමෙක් මෙම ලිපියෙන් පැවසීය. වැරදි! අප සියල්ලන්ම, කාවැද්දූ ඉංජිනේරුවන්, සෑම විටම යන්ත්‍රය වියුක්ත කර ඇත, අනෙක් සින්ටැක්ස් සමඟ සී ++ ය. මෙම තර්කය සමඟ මා දකින ගැටළුව නම් සමහර ක්‍රමලේඛකයින් වස්තූන් ගැන සිතීමට භාවිතා නොකිරීමයි, ඒ ආකාරයෙන් ඔවුන් OOP හි ප්‍රතිලාභ නොදකිති.

ඔබ මයික්‍රොකොන්ට්රෝලර්ගේ පර්යන්තයක් භාවිතා කිරීමට සුදානම් වන සෑම විටම උපාංග ධාවකයේ ස්වරූපයෙන් (ඔබෙන් හෝ තෙවන පාර්ශවයකින්) පර්යන්තය වියුක්ත කර ඇති බව පෙනේ. මා කලින් කී පරිදි, ඊළඟ උදාහරණයෙන් පෙන්නුම් කරන පරිදි (NXP LPC1114 උදාහරණයකින් කෙලින්ම ගත්) එම ධාවක සී සින්ටැක්ස් භාවිතා කරයි:

/ * TICKRATE_HZ හි ගැලපීම සහ බාධා කිරීම සඳහා ටයිමර් සැකසුම * /

Chip_TIMER_Reset (LPC_TIMER32_0);

Chip_TIMER_MatchEnableInt (LPC_TIMER32_0, 1);

Chip_TIMER_SetMatch (LPC_TIMER32_0, 1, (timerFreq / TICKRATE_HZ2));

Chip_TIMER_ResetOnMatchEnable (LPC_TIMER32_0, 1);

Chip_TIMER_ සක්‍රීය කරන්න (LPC_TIMER32_0);

ඔබ සාරාංශය දකිනවාද? එබැවින්, එකම අරමුණක් සඳහා C ++ භාවිතා කරන විට, ශුන්‍ය පිරිවැයකින් C ++ හි වියුක්ත කිරීම සහ සංවෘත කිරීමේ යාන්ත්‍රණය හරහා සාරාංශය ඊළඟ මට්ටමට ගෙන එනු ලැබේ!

ඇ) එය සාමාන්‍ය වැඩසටහන් ලිවීමට අපට ඉඩ සලසන භාෂාවකි

සාමාන්‍ය වැඩසටහන් අච්චු හරහා සාක්ෂාත් කරගනු ලබන අතර, අපගේ වැඩසටහන් සඳහා සැකිලි සඳහා කිසිදු පිරිවැයක් නොමැත.

ඊට අමතරව, ස්ථිතික බහුමාපකය සැකිලි සමඟ සාක්ෂාත් කරගනු ලැබේ.

අතථ්‍ය ක්‍රම, RTTI සහ ව්‍යතිරේක.

අතථ්‍ය ක්‍රම භාවිතා කිරීමේදී සම්මුතියක් තිබේ: වඩා හොඳ මෘදුකාංග එදිරිව කාර්ය සාධනයේ යම් ද penalty ුවමක්. කෙසේ වෙතත්, අතථ්‍ය වගුවක් (ක්‍රියාකාරී දර්ශක සමූහයක්) භාවිතයෙන් ගතික බන්ධනය ක්‍රියාත්මක කිරීමට ඉඩ ඇති බව මතක තබා ගන්න. මම C හි බොහෝ වාර ගණනක් එය කර ඇත (නිතිපතා වුවද), එබැවින් අතථ්‍ය ක්‍රම භාවිතා කිරීමේ අඩුපාඩු මා දකින්නේ නැත. තවද, C ++ හි අථත්ය ක්රම වඩාත් අලංකාර වේ.

අවසාන වශයෙන්, RTTI සහ ව්‍යතිරේක පිළිබඳ උපදෙස්: කාවැද්දූ පද්ධතිවල ඒවා භාවිතා නොකරන්න. ඒවායින් වළකින්න !!

මගේ පසුබිම, කාවැද්දූ (mcu, pc, unix, other), තථ්‍ය කාලය. ආරක්ෂාව ඉතා වැදගත්. මම කලින් සේවා යෝජකයෙකු එස්.ටී.එල්. මම තවදුරටත් එය නොකරමි.

සමහර ගිනි අන්තර්ගතය

කාවැද්දූ පද්ධති සඳහා C ++ සුදුසු ද?

මෙහ්. සී ++ යනු ලිවීමට වේදනාවක් සහ නඩත්තු කිරීමට වේදනාවක්. C + වර්ග කිරීම හරි ය (සමහර විශේෂාංග භාවිතා නොකරන්න)

මයික්‍රොකොන්ට්රෝලර් වල සී ++? RTOS? ටෝස්ටර්? කාවැද්දූ පළාත් සභා?

නැවතත් මම කියනවා මෙහ්. C + එතරම් නරක නැත, නමුත් ADA අඩු වේදනාකාරී වේ (එය ඇත්ත වශයෙන්ම යමක් පවසයි). ඔබ මා වැනි වාසනාවන්ත නම්, ඔබට ජාවා කාවැද්දීමට සිදුවේ. පරීක්ෂා කරන ලද අරාව ප්‍රවේශය සහ දර්ශක අංක ගණිතය ඉතා විශ්වාසදායක කේතයක් සඳහා යොදා නොගනී. කාවැද්දූ ජාවා හි කසළ එකතු කරන්නන් ඉහළම ප්‍රමුඛතාවයක් නොමැති අතර, විෂය පථය මතකය සහ වස්තු නැවත භාවිතා කිරීම ඇත, එබැවින් හොඳින් සැලසුම් කරන ලද කේතයක් GC නොමැතිව සදහටම ක්‍රියාත්මක විය හැකිය.

OOP ක්ෂුද්‍ර පාලක සඳහා ප්‍රයෝජනවත්ද?

ෂුවර්. UART යනු වස්තුවකි ..... DMAC යනු වස්තුවකි ...

වස්තු රාජ්‍ය යන්ත්‍ර ඉතා පහසුය.

C ++ කාර්යක්ෂම වීමට දෘඩාංග වලින් ක්‍රමලේඛකයා ඉවත් කරයිද?

එය PDP-11 නොවේ නම්, C ඔබේ CPU නොවේ. සී ++ මුලින් සී හි පෙර සැකසුම් යන්ත්‍රයක් වූ අතර ඒටී ඇන්ඩ් ටී හි සිටියදී මන්දගාමී සිමියුලා අනුකරණයන් තිබීම ගැන බර්න් ස්ට්‍රෝස්ට්‍රප් සිනාසෙනු ඇත. C ++ ඔබේ CPU නොවේ.

ජාවා බයිට් කේත ධාවනය කරන MCU එකක් ලබා ගන්න. ජාවා හි වැඩසටහන. සී කොල්ලන්ට හිනා වෙන්න.

Arduino හි C ++ (ගතික මතක කළමනාකරණය, සැකිලි, ව්‍යතිරේක නොමැතිව) "සැබෑ C ++" ලෙස සැලකිය යුතුද?

නෑ. MCU සඳහා සියලුම අවජාතක C සම්පාදකයින් මෙන්.

ඉදිරියට, කාවැද්දූ ජාවා හෝ කාවැද්දූ ADA ප්‍රමිතිගත කර ඇත (ඊෂ්); අනෙක් සියල්ල ශෝකය.

කාවැද්දූ පද්ධති සැලසුම් කර ඇත්තේ බහු කාර්යයන් සඳහා පොදු කාර්ය පරිගණකයක් නොව යම් නිශ්චිත කාර්යයක් කිරීමට ය. කාවැද්දූ පද්ධතියක් යනු පරිගණක දෘඩාංග හා මෘදුකාංගවල එකතුවකි. සී යනු සියලු නූතන භාෂාවල මවයි. එය පහත් මට්ටමේ නමුත් පූර්ණ භාෂාවක් වන අතර සියලු ආකාරයේ දෘඩාංග සමඟ කටයුතු කරයි. එබැවින් සී / සී ++ යනු කාවැද්දූ පද්ධතිය සඳහා මෘදුකාංග සංවර්ධනය කිරීම සඳහා ප්‍රශස්ත තේරීමක් වන අතර එය සෑම කාවැද්දූ පද්ධතියක් සඳහාම පූර්ණ ලෙස භාවිතා කරයි .අපි දන්නා පරිදි සී සංවර්ධනය වෙමින් පවතින භාෂාවකි. මෙහෙයුම් පද්ධතිය යුනික්ස් සී හි ලියා ඇත .එසේම සාර්ථක මෘදුකාංග සංවර්ධනය බොහෝ විට දී ඇති ව්‍යාපෘතියක් සඳහා හොඳම භාෂාව තෝරා ගැනීම නිසා, සී / සී ++ භාෂාව 8-බිට් සහ 64-බිට් ප්‍රොසෙසර සඳහා සුදුසු බව ඔප්පු වී තිබීම පුදුමයට කරුණකි. ; බයිට්, කිලෝබයිට් සහ මෙගාබයිට් මතකය සහිත පද්ධති වල. C ට ප්‍රොසෙසර-ස්වාධීනත්වයේ වාසිය ඇත, විශේෂිත ප්‍රොසෙසර් ගෘහ නිර්මාණ ශිල්පයේ විස්තර මත නොව ඇල්ගොරිතම සහ යෙදුම් කෙරෙහි අවධානය යොමු කිරීමට ක්‍රමලේඛකයන්ට ඉඩ සලසයි. කෙසේ වෙතත්, මෙම වාසි බොහොමයක් වෙනත් ඉහළ මට්ටමේ භාෂාවන්ට සමානව අදාළ වේ. නමුත් වෙනත් භාෂා බොහෝ දුරට අසමත් වී ඇති තැන සී / සී ++ සාර්ථක වී තිබේද?

<rant>

මම හිතන්නේ සී ++ යනු මුලින් ම කපටි භාෂාවකි. ඔබට OOP භාවිතා කිරීමට අවශ්‍ය නම්, ජාවා වැඩසටහන් ලියන්න. O ++ පරාමිතීන් බලාත්මක කිරීමට C ++ කිසිවක් නොකරයි, මන්ද සෘජු මතක ප්‍රවේශය ඔබේ (ab) භාවිතයට සම්පූර්ණයෙන්ම බලපාන බැවිනි.

ඔබට MCU එකක් තිබේ නම්, ඔබ බොහෝ විට කතා කරන්නේ 100kB ට අඩු ෆ්ලෑෂ් මතකයක් ගැන ය. මතකය වියුක්ත කරන භාෂාවක ක්‍රමලේඛනය කිරීමට ඔබට අවශ්‍යය: මම විචල්‍යයක් හෝ අරාවක් ප්‍රකාශ කරන විට එයට මතකය, කාල සීමාව ලැබේ; malloc (C ++ හි "නව" මූල පදය) කාවැද්දූ මෘදුකාංග භාවිතා කිරීම තහනම් කළ යුතුය, සමහර විට දුර්ලභ අවස්ථාවන්හිදී වැඩසටහන් ආරම්භයේදී එක් ඇමතුමක් හැර.

නිරය, කාවැද්දූ ක්‍රමලේඛනයේ සී ප්‍රමාණවත් තරම් අඩු මට්ටමක නොමැති අවස්ථා තිබේ, තවද ඔබ රෙජිස්ටාර් සඳහා විචල්‍යයන් වෙන් කිරීම වැනි දේ කළ යුතු අතර ඔබේ බාධාකාරී සේවා පිළිවෙත් (අයිඑස්ආර්) දැඩි කිරීම සඳහා පේළිගත එකලස් කිරීම ලියන්න. "වාෂ්පශීලී" වැනි වචන තේරුම් ගැනීමට ඉතා වැදගත් වේ. ඔබ ට මතක හැසිරවීමේ ඔබේ කාලය වැය ටිකක් නොවේ මට්ටමින්, වස්තුව මට්ටම.

ඇත්ත වශයෙන්ම ඒවාට වඩා දේවල් සරල යැයි සිතීමට ඔබ රැවටීමට ඔබ කැමති ඇයි?

</rant>