C ++ D ට වඩා හොඳින් කරන්නේ කුමක්ද?

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

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

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

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

ඩී නිර්මාණය කර ඇත්තේ ඉතා දක්ෂ C ++ ක්‍රමලේඛකයින් ( වෝල්ටර් බ්‍රයිට් සහ ඇන්ඩ්‍රි ඇලෙක්සැන්ඩ්‍රෙස්කු , ඩී ප්‍රජාවේ සහාය ඇතිව) සී ++ හි ඇති බොහෝ ගැටලු නිරාකරණය කිරීම සඳහා ය, නමුත් ඇත්ත වශයෙන්ම වඩා හොඳ නොවූ යමක් තිබේද? ඔහුට යමක් මග හැරුණාද? වඩා හොඳ විසඳුමක් නොවේ යැයි ඔබ සිතන දෙයක්?

ඒ වගේම, මම ඔයවගෙ කතා බව සටහන් ඩී 2.0 නොව ඩී 1.0 .

D ++ ට වඩා C ++ "කරන" බොහෝ දේ මෙටා දේවල් වේ: C ++ සතුව වඩා හොඳ සම්පාදකයින්, වඩා හොඳ මෙවලම්, වඩා පරිණත පුස්තකාල, වැඩි බැඳීම්, වැඩි විශේෂ experts යන්, වැඩි නිබන්ධන ආදිය ඇත. මූලික වශයෙන් එය ඔබ සතු සියලු බාහිර දේවලට වඩා වැඩි වැඩියෙන් ඇත වඩා පරිණත භාෂාවකින් බලාපොරොත්තු වනු ඇත. මෙය කළ නොහැකි ය.

භාෂාව සම්බන්ධයෙන් ගත් කල, මගේ මතය අනුව C ++ D ට වඩා හොඳින් කරන දේවල් කිහිපයක් තිබේ. තවත් බොහෝ දේ ඇත, නමුත් මෙන්න මගේ හිස මුදුනේ සිට ලැයිස්තු ගත කළ හැකි කිහිපයක්:

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

මට දෝෂාරෝපණය කර ඇති තවත් ගැටළුවක් වන්නේ තාර්කික සං const ටක නොමැතිකමයි (එනම් mutableC ++ හි නැත ). නූල්-ආරක්‍ෂිත කේතයක් ලිවීම සඳහා මෙය ඉතා සුදුසු ය, නමුත් නියත වස්තූන් තුළ කම්මැලි සම්බන්ධතාවයක් ඇති කිරීම දුෂ්කර (කළ නොහැකි ද?) කරයි (පළමු ඇමතුමේ දී ආපසු ලබා දුන් අගය ගොඩනංවන හා හැඹිලිගත කරන ලද 'ලබා ගන්න' ශ්‍රිතයක් ගැන සිතන්න).

අවසාන වශයෙන්, මේ පවතින ගැටලු දී, මම (වර්ගය ක්රමයේ අනෙකුත් කොහොමද කියන එක ගැන හිතලයි pure, sharedආදිය,) භාෂාවෙන් අන් සියල්ල සමග අන්තර් ක්රියා කරනු ඇත ඔවුන් භාවිතා කරන ඇත වරක්. සම්මත පුස්තකාලය (ෆොබොස්) දැනට ඩී හි උසස් වර්ගයේ පද්ධතිය භාවිතා කරන්නේ ඉතා අල්ප වශයෙනි, එබැවින් එය ආතතිය යටතේ පවතින්නේද යන ප්‍රශ්නය සාධාරණ යැයි මම සිතමි. මම සැක සහිත, නමුත් ශුභවාදී ය.

C ++ සතුව යම් ආකාරයක පද්ධති ඉන්නන් ඇති බව සලකන්න (උදා: සංක්‍රාන්ති නොවන නියතය, අවශ්‍ය iteratorමෙන්ම const_iterator) එය තරමක් අවලස්සන කරයි, නමුත් C ++ වර්ගයේ පද්ධතිය කොටස් වශයෙන් ටිකක් වැරදියි, නමුත් එය D වැනි වැඩ කිරීමෙන් ඔබව වළක්වන්නේ නැත. සමහර විට එසේ කරයි.

සංස්කරණය කරන්න: පැහැදිලි කිරීම සඳහා, C ++ වඩා හොඳ කල්පනාකාරී ආකාරයේ පද්ධතියක් ඇති බව මම විශ්වාස කරමි - අවශ්‍යයෙන්ම වඩා හොඳ එකක් නොවේ - එය අර්ථවත් නම්. අත්‍යවශ්‍යයෙන්ම, DI හි හැඟෙන්නේ C ++ හි නොමැති එහි වර්ගයේ පද්ධතියේ සියලුම අංග භාවිතා කිරීමේ අවදානමක් ඇති බවයි.

ඩී සමහර විට ටිකක් පහසු
ය. ඔබ බොහෝ විට සී ++ ගැන අසා ඇති එක් විවේචනයක් නම්, එය ඔබෙන් පහත් මට්ටමේ ගැටළු කිහිපයක් සඟවයි. උදා: සරල පැවරුම් වැනි a = b;පරිවර්තන ක්‍රියාකරුවන් ඇමතීම, අධි බර පැවරුම් ක්‍රියාකරුවන් ඇමතීම වැනි බොහෝ දේ කළ හැකිය. කේතයෙන් බැලීමට අපහසුය. සමහර අය මේකට කැමතියි, සමහර අය කැමති නැහැ. කවර ක්රමයක්, ඩී එය වඩාත් නරක අතට (වඩා හොඳ?) නිසා වැනි දේවල් ය opDispatch, @property, opApply, lazyඔබ බලාපොරොත්තු නොවන දේවල් බවට අහිංසක බලා කේතය වෙනස් කිරීමට හැකියාව තිබෙන අතර.

මෙය පෞද්ගලිකව විශාල ප්‍රශ්නයක් යැයි මම නොසිතමි, නමුත් සමහරුන්ට මෙය වළක්වා ගත හැකිය.

D ට කසළ එකතු කිරීම අවශ්‍ය වේ.
මෙය මතභේදාත්මක ලෙස දැකිය හැක්කේ GC නොමැතිව D ධාවනය කළ හැකි බැවිනි. කෙසේ වෙතත්, එය කළ හැකි නිසා එය ප්‍රායෝගික යැයි අදහස් නොකෙරේ. GC නොමැතිව, ඔබට D හි බොහෝ අංග අහිමි වන අතර, සම්මත පුස්තකාලය භාවිතා කිරීම බිම් බෝම්බයක ඇවිදීම හා සමාන වේ (මතකය වෙන් කරන්නේ කුමන කාර්යයන් දැයි දන්නේ කවුද?). පුද්ගලිකව, මම සිතන්නේ GC නොමැතිව D භාවිතා කිරීම මුළුමනින්ම ප්‍රායෝගික නොවන අතර, ඔබ GCs හි රසිකයෙක් නොවේ නම් (මා වැනි) එවිට මෙය තරමක් දුරට කල් දැමිය හැකිය.

D හි විකාර අරා අර්ථ දැක්වීම් මතකය වෙන් කරන්න
මෙය මගේ සුරතල් සතෙකි:

int[3] a = [1, 2, 3]; // in D, this allocates then copies
int a[3] = {1, 2, 3}; // in C++, this doesn't allocate

පෙනෙන විදිහට, ඩී හි වෙන් කිරීම වළක්වා ගැනීම සඳහා, ඔබ කළ යුත්තේ:

static const int[3] staticA = [1, 2, 3]; // in data segment
int[3] a = staticA; // non-allocating copy

මෙම කුඩා 'ඔබේ පිටුපස' ප්‍රතිපාදන මගේ පෙර කරුණු දෙක සඳහා හොඳ උදාහරණ වේ.

සංස්කරණය කරන්න: මෙය දන්නා ප්‍රශ්නයක් බව සලකන්න.
සංස්කරණය කරන්න: මෙය දැන් සවි කර ඇත. වෙන් කිරීමක් සිදු නොවේ.

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

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

විශාල වශයෙන්, C ++ (සහ එයින් මා අදහස් කරන්නේ C ++ 2011) D ට වඩා හොඳ වන්නේ කුමක් දැයි විමසීම ස්වයං පරස්පර විරෝධී ය, “ඔබේ නිවස පිරිසිදු කිරීම සඳහා ඔබ වෘත්තිකයෙකුට ගෙවන්නේ නම්, ඔවුන් පිටවන ස්ථාන මොනවාද? පෙරට වඩා අපිරිසිදු ද? ඩී ++ ට කළ නොහැකි දේ C ++ ට කළ හැකි වුවත්, එය සෑම විටම මට සහ වෝල්ටර්ට උගුරේ අමාරුවකි, එබැවින් අර්ථ දැක්වීම අනුව C ++ ට කළ හැකි කිසිවක් නැත.

භාෂා නිර්මාණයේදී කලාතුරකින් වටහා ගත හැකි එක් දෙයක් නම් (ඇත්ත වශයෙන්ම සමහරක් කිරීමට වාසනාව ඇත්තේ ස්වල්ප දෙනෙකුට), එය පෙනෙන්නට වඩා බලහත්කාරයෙන් සිදු නොවූ දෝෂයන් අඩු වීමයි. අපගෙන් බොහෝ දෙනෙක් භාෂා භාවිතා කරන්නන් කිසියම් ඉදිකිරීමක් හෝ වෙනත් දෙයක් දෙස බලා "ඊව්! මෙය එතරම් වැරදියි! ඔවුන් සිතුවේ කුමක්ද?" කාරණයේ සත්‍යය නම්, භාෂාවක බොහෝ අමුතු අවස්ථාවන් මූලික තීරණ කිහිපයකින් පසුව ඇති අතර ඒවා සියල්ලම හොඳ සහ ප්‍රියජනක නමුත් මූලික වශයෙන් තරඟකාරී හෝ එකිනෙකට පරස්පර විරෝධී වේ (උදා: මොඩියුලරිටි සහ කාර්යක්ෂමතාව, ආතතිය සහ පාලනය යනාදිය).

මේ සියල්ල මනසේ තබාගෙන, මට සිතිය හැකි කරුණු කිහිපයක් මම ගණනය කරමි, ඒ වගේම ඩී තේරීම වෙනත්, ඉහළ මට්ටමේ, ප්‍ර ter ප්තියක් ඉටුකිරීමේ ආශාවෙන් උපුටා ගන්නා ආකාරය මම විස්තර කරමි.

1. D උපකල්පනය කරන්නේ සියලු වස්තූන් චලනය කළ හැකි බවයි. මෙය C ++ වෙත සුළු මෝස්තරයක් තබයි, විශේෂයෙන් අභ්‍යන්තර දර්ශක භාවිතා කරන, එනම් පන්තියක් තුළම දර්ශක අඩංගු වේ. . සමස්ත පිටපත් ඉදිකිරීමේ චිත්ත ධෛර්යය සහ අගය යොමු කිරීමේ අංගය මුළුමනින්ම වෙනස් වේ.

2. D නොපැහැදිලි-ස්ත්‍රී-පුරුෂ වර්ග අනුමත නොකරයි (ඒවා වටිනාකම හෝ යොමු වර්ගද යන්න තීරණය කළ නොහැක). එවැනි මෝස්තර සී ++ වලින් ඒකමතිකව මග හැරී ඇති අතර සෑම විටම පාහේ වැරදියි, නමුත් සමහර ඒවා තාක්‍ෂණිකව නිවැරදි ය. අපි මෙම තේරීම සිදු කළේ එය බොහෝ දුරට වැරදි කේතයට ඉඩ නොදෙන නිසා සහ ප්‍රතිනිර්මාණය කළ හැකි ඉතා සුළු භාගයක් පමණි. එය හොඳ වෙළඳාමක් බව අපි විශ්වාස කරමු.

3. ඩී බහු මූල ධූරාවලිය අනුමත නොකරයි. මෙහි පෙර පෝස්ටරයක් ​​මෙම විශේෂිත මාතෘකාව පිළිබඳව බෙහෙවින් උද්දීපනය වූ නමුත් මෙය හොඳින් පාගා දැමූ භූමියක් වන අතර සියල්ලන්ටම පොදු මූලයක් ඇති ධූරාවලියන්ට වඩා මූල රහිත ධූරාවලීන්ගෙන් පැහැදිලි වාසියක් නොමැත.

4. D හි ඔබට උදා. විසි කළ හැකි වස්තුවක් ඔබ විසි කළ යුතුය. D හි කිසිදු තත්වයක් වඩා හොඳ නැත, නමුත්, D ++ ට කළ නොහැකි එක දෙයක් C ++ ට කළ හැකිය.

5. C ++ හි සංවෘත කිරීමේ ඒකකය පන්තියකි. D හි එය මොඩියුලයකි (එනම් ගොනුව). වෝල්ටර් මෙම තීරණය ගත්තේ හේතු දෙකක් නිසාය: ස්වාභාවිකවම පද්ධති ආරක්ෂණ අර්ථකථන ගොනු කිරීම සඳහා සිතියම් ගත කිරීම සහ "මිතුරා" සඳහා ඇති අවශ්‍යතාවය මග හැරීම. මෙම තේරීම ඩී හි සමස්ත මොඩියුලරිටි සැලසුම තුළ ඉතා හොඳින් ඒකාබද්ධ වේ. C ++ හා සමාන වන පරිදි දේවල් වෙනස් කළ හැකි නමුත් එය දේවල් බල කරයි; C ++ හි සංවෘත විෂය පථ තේරීම් හොඳ වන්නේ C ++ හි භෞතික නිර්මාණය සඳහා පමණි.

කුඩා දේවල් එකක් හෝ දෙකක් තිබිය හැකිය, නමුත් සමස්තයක් වශයෙන් එය එසේ විය යුතුය.

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

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

1. D's නිසා const අධිෂ්ඨාන පූර්වකව වන අතර, භාෂාව නිසා පරමාණු හා අණුවල පැවැත්ම , එය C ++ 's වඩා බෙහෙවින් ශක්තිමත් සහතික කර constඩී නොකරන හා එහි අරුත වන්නේ, නො හැකි වී mutable. එයට තාර්කික සංයුක්තයක් තිබිය නොහැක . ඉතින්, ඔබට D හි const පද්ධතියෙන් විශාල වාසියක් ලැබේ, නමුත් සමහර අවස්ථාවන්හිදී, ඔබට constC ++ හි ඇති ආකාරයටම භාවිතා කළ නොහැක .

2. D සතුව ඇත්තේ එක් වාත්තු ක්‍රියාකරුවෙකු වන අතර C ++ සතුව 4 ඇත (5 ඔබ C කාස්ට් ක්‍රියාකරු ගණන් කළහොත්). මෙය සාමාන්‍ය කාරණයේදී ඩී හි වාත්තු සමඟ කටයුතු කිරීම පහසු කරයි, නමුත් ඇත්ත වශයෙන්ම ඔබටconst_cast සහ එහි සහෝදරයින්ට ලබා දෙන අමතර සංකූලතා / ප්‍රතිලාභ අවශ්‍ය විට එය ගැටළු සහගත වේ. නමුත් ඩී ඇත්ත වශයෙන්ම ඔබට සී ++ වාත්තු ක්‍රියාත්මක කිරීමට සැකිලි භාවිතා කළ හැකි තරම් බලවත් ය, එබැවින් ඔබට ඒවා සැබවින්ම අවශ්‍ය නම් ඔබට ඒවා ලබා ගත හැකිය (තවද ඒවා යම් අවස්ථාවක දී ඩී හි සම්මත පුස්තකාලයේ පවා අවසන් විය හැකිය).

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

4. D's මොඩියුලය පද්ධති (නොවේ සඳහන් කිරීමට, C ++ හි #includes වඩා පිරිසිදුයි මාර්ගය වේගවත් සම්පාදනය දී), නමුත් එය මොඩියුල තමන් ඔබ්බට namespacing ඕනෑම ආකාරයක තොර ය. එබැවින්, ඔබට මොඩියුලයක් තුළ නාම අවකාශයක් අවශ්‍ය නම්, ඔබට ජාවා මාර්ගයට ගොස් පන්තියක හෝ ව්‍යුහයක ස්ථිතික කාර්යයන් භාවිතා කළ යුතුය. එය ක්‍රියාත්මක වේ, නමුත් ඔබට සැබවින්ම නාම අවකාශය අවශ්‍ය නම්, එය පැහැදිලිවම සැබෑ නාම අවකාශය තරම් පිරිසිදු නොවේ. කෙසේ වෙතත්, බොහෝ අවස්ථාවන්හීදී, මොඩියුලයන් විසින්ම ඔබට ලබා දෙන නාම අවකාශය ඕනෑ තරම් තිබේ (ඇත්ත වශයෙන්ම ගැටුම් වැනි දේවල් සම්බන්ධයෙන් එය නවීනයි).

5. ජාවා සහ සී # මෙන්, ඩීට බහු උරුමයට වඩා තනි උරුමයක් ඇත, නමුත් ජාවා සහ සී # මෙන් නොව, සී ++ හි බහු උරුමය ඇති සියලුම ගැටළු වලින් තොරව එකම බලපෑමක් ලබා ගැනීමට එය ඔබට අපූරු ක්‍රම කිහිපයක් ලබා දෙයි (සහ සී ++ හි බහු උරුමය ඉතා අවුල් සහගත විය හැකිය විටෙක). D ට අතුරුමුහුණත් ඇතිවා පමණක් නොව, එයට නූල් මික්සින් , අච්චු මික්සින් සහ අන්වර්ථය ඇත. ඉතින්, අවසාන ප්‍රති result ලය වඩා බලවත් වන අතර C ++ හි බහුවිධ උරුමයට ඇති සියලුම ගැටලු නොමැත.

6. C # ට සමානව, D ව්‍යුහයන් සහ පන්ති වෙන් කරයි. පංති යනු උරුමයක් ඇති සහ ව්‍යුත්පන්න කර ඇති යොමු වර්ග වන Objectඅතර, ව්‍යුහයන් උරුමයෙන් තොරව වටිනාකම් වර්ග වේ. මෙම වෙන්වීම හොඳ සහ නරක යන දෙකම විය හැකිය. එය C ++ හි ඇති සම්භාව්‍ය පෙති කැපීමේ ගැටලුවෙන් මිදෙන අතර එය බහුමාමක යැයි සිතිය හැකි වර්ග වලින් සැබවින්ම වටිනාකමින් යුත් වර්ග වෙන් කිරීමට උපකාරී වේ, නමුත් මුලදී, අවම වශයෙන් මෙම වෙනස C ++ ක්‍රමලේඛකයෙකුට කරදරයක් විය හැකිය. අවසානයේදී, එයින් වාසි ගණනාවක් ඇත, නමුත් එය ඔබේ වර්ග සමඟ තරමක් වෙනස් ලෙස කටයුතු කිරීමට බල කරයි.

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

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

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

ඩී, භාෂාවක් ලෙස, සී ++ ට වඩා බොහෝ ආකාරවලින් දියුණු වේ, සාමාන්‍යයෙන් ඩී වෛෂයිකව වඩා හොඳ යැයි මම සිතමි.

1. D හි කොන්දේසි සහිත සම්පාදනයක් ඇත. මම C ++ හි ක්‍රමලේඛනය කරන විට නිතර නිතර මග හැරෙන එක් අංගයකි මෙය. C ++ එය එකතු කරන්නේ නම්, අච්චු වැනි දේවල් සම්බන්ධයෙන් සී ++ වේගයෙන් හා සීමාවෙන් වැඩි දියුණු වේ.

2. D හි සංයුක්ත කාල පරාවර්තනයක් ඇත.

3. විචල්‍යයන් පෙරනිමියෙන් නූල්-දේශීය වන නමුත් sharedඔබට ඒවා අවශ්‍ය නම් විය හැකිය. මෙය සී ++ ට වඩා නූල් සමඟ ගනුදෙනු කිරීම වඩා පිරිසිදු කරයි. ඔබට සම්පූර්ණ පාලනය ඇත. ඔබට භාවිතා කළ හැකි immutableහා පණිවිඩයක් පසුකර නූල් අතර සන්නිවේදනය කිරීමට නම්, හෝ ඔබ විසින් විචල්යයන් කළ හැකි sharedසහ mutexes හා සෞඛ්ය තත්වය විචල්යයන් සමග එය C ++ මාර්ගය කරන්න. සමමුහුර්තකරණය (C # සහ ජාවා වලට සමාන) හඳුන්වාදීමත් සමඟ එය C ++ ට වඩා වැඩි දියුණු වේ. ඒ නිසා, D's නිගමනයට තත්වය දුර වඩා හොඳ C ++ 's වඩා.

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

5. ඩී බිල්ට් කොන්ත්‍රාත් ක්‍රමලේඛනය ඇත.

6. ඩී තුළ ඒකක පරීක්ෂණ රාමුවක් ඇත.

7. ඩී string(යූටීඑෆ් -8), wstring(යූටීඑෆ් -16) සහ dstring(යූටීඑෆ් -32) සමඟ යුනිකෝඩ් සඳහා සහය දක්වයි . එය යුනිකෝඩ් සමඟ කටයුතු කිරීම පහසු කරයි. ඔබට stringයුනිකෝඩ් ගැන සාමාන්‍යයෙන් කරදර වීමට අවශ්‍ය නැතිනම් ඔබට එය කළ හැකිය - යුනිකෝඩ්හි මූලික කරුණු පිළිබඳ යම් අවබෝධයක් සමහර සම්මත පුස්තකාල ක්‍රියාකාරකම් සඳහා උපකාරී වේ.

8. ඩී හි ක්‍රියාකරු අධි බර පැටවීම සී ++ ට වඩා බෙහෙවින් යහපත් වන අතර එකවර බහුවිධ ක්‍රියාකරුවන් අධික ලෙස පැටවීම සඳහා එක් ශ්‍රිතයක් භාවිතා කිරීමට ඔබට ඉඩ සලසයි. මෙයට ප්‍රධාන නිදසුනක් නම්, ඔබට මූලික ගණිත ක්‍රියාකරුවන් අධික ලෙස පැටවීමට අවශ්‍ය වූ විට සහ ඒවා ක්‍රියාත්මක කිරීම ක්‍රියාකරුට සමාන ඉතිරියක් වේ. නූල් මික්සින් එය සුළඟක් බවට පත් කරයි, ඒ සියල්ල සඳහා ඔබට සරල, ක්‍රියාකාරී අර්ථ දැක්වීමක් ලබා දේ.

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

මට ඉදිරියට යන්න පුළුවන්. ඩී සපයන බොහෝ වැඩිදියුණු කිරීම් කුඩා දේවල් වේ ( thisඉදිකිරීම්කරුවන්ගේ නම් භාවිතා කිරීම හෝ අර්ධ සළකුණක් ඔවුන්ගේ මුළු සිරුරම ඇති ප්‍රකාශ හෝ ලූප් සිරුරු නම් අවසර නොදීම වැනි), නමුත් ඒවායින් සමහරක් විශාල වන අතර ඔබ ඒ සියල්ල එකතු කළ විට එය සඳහා වර්ගයන් බොහෝ වඩා හොඳ වැඩසටහන් අත්දැකීම්. C ++ 0x හි D හි ඇති සමහර අංග (උදා: autoසහ ලැම්බඩස්) එකතු කරයි, නමුත් එහි සියලු වැඩිදියුණු කිරීම් සමඟ වුවද, D ට වඩා භාෂාවක් ලෙස C ++ ගැන වෛෂයිකව වඩා හොඳ බොහෝ දේ තවමත් නොපවතී.

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

එබැවින්, මෙම ප්රශ්නයට කෙටි පිළිතුර "ඉතා අල්ප" යැයි මම සිතමි. D, භාෂාවක් ලෙස, සාමාන්‍යයෙන් C ++ ට වඩා උසස් ය.

RAII සහ තොග මතක භාවිතය

ඩී 2.0 මඟින් RAII තොගය මත සිදුවීමට ඉඩ නොදේ scope.

ඔබට ඩී හි අගය-ආකාරයේ උරුමයක් කළ නොහැක, එමඟින් ඕනෑම ආකාරයක RAII සඳහා ගොඩවල් වෙන් කිරීමක් කිරීමට බල කරයි.
එනම්, ඔබ භාවිතා නොකරන්නේ නම් emplace, නමුත් එය භාවිතා කිරීම ඉතා වේදනාකාරී වේ, මන්ද ඔබට මතකය අතින් වෙන් කළ යුතු බැවිනි. ( emplaceඩී හි භාවිතා කිරීම මට තවම ප්‍රායෝගික නැත .)

C ++ ඔබට වාචිකව සිටීමට බල කිරීම වඩා හොඳය. ඔබ අනුමාන කිරීමට හෝ වාචිකභාවයට කැමතිද යන්න මත පදනම්ව මෙය ඔබේ ඇස් වලට වඩා හොඳ හෝ නරක විය හැකිය.

C ++ හි ධාවන කාල මතක සටහන් සසඳා බලන්න :

template <typename ReturnType, typename... Args>
function<ReturnType (Args...)> memoize(function<ReturnType (Args...)> func)
{
    map<tuple<Args...>, ReturnType> cache;
    return ([=](Args... args) mutable {
            tuple<Args...> t(args...);
            return cache.find(t) == cache.end()
                ? cache[t] : cache[t] = func(args...);
    });
}

D හි එකම දේ සමඟ:

auto memoize(F)(F func)
{
    alias ParameterTypeTuple!F Args;
    ReturnType!F[Tuple!Args] cache;
    return (Args args)
    {
        auto key = tuple(args);
        return key in cache ? cache[key] : (cache[key] = func(args));
    };
}

නිදසුනක් ලෙස, template <typename ReturnType, typename... Args>එදිරිව (F), Args...එදිරිව Args, args...එදිරිව argsයනාදිය සමඟ ඇති අතිරේක වාචිකතාව සැලකිල්ලට ගන්න .
වඩා හොඳ හෝ නරක නම්, සී ++ වඩාත් වාචික වේ.

ඇත්ත වශයෙන්ම, ඔබට මෙය D හි ද කළ හැකිය:

template memoize(Return, Args...)
{
    Return delegate(Args) memoize(Return delegate(Args) func)
    {
        Return[Tuple!Args] cache;
        return delegate(Args args)
        {
            auto key = tuple(args);
            return key in cache ? cache[key] : (cache[key] = func(args));
        };
    }
}

ඒවා බොහෝ දුරට සමාන බව පෙනේ, නමුත් එවිට මෙය අවශ්‍ය වනු ඇත delegate, නමුත් මුල් පිටපත පිළිගත හැකි ඕනෑම වස්තුවක් පිළිගත්තේය . (C ++ 0x අනුවාදය සඳහා අවශ්යstd::function නිසා හෝ ආකාරයෙන්, වස්තුව, එය සිය යෙදවුම් වඩාත් විස්ථරාත්මක හා තද වේ ... ඔබ verbosity, නරක වගේ නම්, ඔබ නැති නම් යහපත් විය හැකි.)

මම ඩී ගැන වැඩි යමක් නොදනිමි, නමුත් මා දන්නා බොහෝ සී ++ ක්‍රමලේඛකයින් එයට බෙහෙවින් අකමැති වන අතර, මම පෞද්ගලිකව එකඟ විය යුතුය- මම ඩී පෙනුමට කැමති නැති අතර වඩාත් සමීප එකක් නොගනු ඇත.

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

කුඩා පර්යේෂණයක් කර එය අත්හදා බැලූ පුද්ගලයන් කිහිප දෙනෙකු සමඟ කතා කරන විට මා දුටු කරුණු කිහිපයක් මෙන්න:

ඒකාබද්ධ වර්ගයේ ධූරාවලිය. C ++ භාවිතා කරන්නන් උරුමය භාවිතා කරන්නේ ඉතා කලාතුරකිනි, බොහෝ C ++ ක්‍රමලේඛකයින් සංයුතියට වැඩි කැමැත්තක් දක්වයි, සහ වර්ග සම්බන්ධ කළ යුත්තේ උරුමය හරහා පමණි. එසේ කිරීමට හොඳ හේතුවක් තිබේ නම් පමණි. වස්තුව පිළිබඳ සංකල්පය සෑම වර්ගයක්ම සම්බන්ධ කිරීමෙන් මෙම මූලධර්මය දැඩි ලෙස උල්ලං lates නය කරයි. ඊට අමතරව, එය C ++ හි මූලික මූලධර්මවලින් එකක් උල්ලං ting නය කරයි- ඔබ භාවිතා කරන්නේ ඔබට අවශ්‍ය දේ පමණි. වස්තුවෙන් උරුම වීම පිළිබඳ තේරීමක් ලබා නොදීම සහ ඒ සමඟ යන පිරිවැය, ක්‍රමලේඛකයාට තම වැඩසටහන පාලනය කිරීමට අනුව භාෂාවක් ලෙස C ++ නියෝජනය කරන දෙයට වඩා දැඩි ලෙස විරුද්ධ වේ.

කාර්යයන් සහ නියෝජිතයින්ගේ ගැටළු ගැන මම අසා ඇත්තෙමි. පෙනෙන විදිහට, ඩී හි ක්‍රියාකාරීත්වයන් සහ නියෝජිතයන් යන දෙකම ධාවන කාල ඇමතුම් කළ හැකි ශ්‍රිත වර්ග ලෙස ඇති අතර ඒවා එක හා සමාන නොවන නමුත් ඒවා එකිනෙකට හුවමාරු කළ හැකි හෝ ... යමක් තිබේද? මගේ මිතුරා ඔවුන් සමඟ ගැටලු කිහිපයක් ඇති කළේය. මෙය නියත වශයෙන්ම C ++ වෙතින් පහත හෙලීමකි, එය දැන් ඇති std::functionඅතර ඔබ අවසන් කර ඇත.

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

එවිට තවත් කරුණු කිහිපයක් තිබේ. උදාහරණයක් ලෙස, විකිපීඩියා ප්‍රවේශය කියවන්න.

import std.metastrings;
pragma(msg, Format!("7! = %s", fact_7));
pragma(msg, Format!("9! = %s", fact_9));

printfgetsපැරණි සී ස්ටෑන්ඩර්ඩ් පුස්තකාලය වැනි විශාල ගැටළු ඇති එකම පවුල තුළ මෙතෙක් සැලසුම් කර ඇති වඩාත්ම ආරක්‍ෂිත කාර්යයන්ගෙන් එකකි . ඔබ එය Stack Overflow හි සොයන්නේ නම්, එය වැරදි ලෙස භාවිතා කිරීම සම්බන්ධ බොහෝ ප්‍රශ්න ඔබට හමුවනු ඇත. මූලික වශයෙන්, DRY උල්ලංprintf violation නය කිරීමකි- ඔබ ආකෘතියේ නූල් වර්ගය ලබා දෙන අතර, ඔබ එය තර්කයක් දෙන විට එය නැවත ලබා දෙයි. DRY උල්ලං violation නය කිරීමක් නම්, ඔබ එය වැරදියට තේරුම් ගන්නේ නම්, ඉතා නරක දේ සිදුවනු ඇත- කියන්න, ඔබ යතුරු ලියනය 16-බිටු නිඛිලයක සිට බිටු 32 දක්වා වෙනස් කළහොත්. එය කිසිසේත් දීර් able කළ නොහැකිය- සෑම කෙනෙකුම තමන්ගේම ආකෘති පිරිවිතරයන් නිර්මාණය කළහොත් කුමක් සිදුවේදැයි සිතා බලන්න. C ++ හි අයෝස්ට්‍රීම් මන්දගාමී විය හැකි අතර, ඔවුන්ගේ ක්‍රියාකරු තෝරා ගැනීම විශාලතම නොවිය හැකි අතර, ඔවුන්ගේ අතුරු මුහුණත වැඩ භාවිතා කළ හැකි නමුත් ඒවා මූලික වශයෙන් ආරක්ෂිත බව සහතික කර ඇති අතර DRY උල්ලං is නය නොවන අතර ඒවා පහසුවෙන් දීර්. කළ හැකිය. මෙය කිව හැකි දෙයක් නොවේ printf.

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

තවත් උදාහරණයක් වන්නේ stringසහ wstring. C ++ හි දැනටමත් ඒවා අතර පරිවර්තනය වීමට සිදුවීම තරමක් වේදනාකාරී වන අතර මෙම පුස්තකාලය යුනිකෝඩ් සඳහා සහය දක්වයි, මෙම පැරණි C පුස්තකාලය පමණක් භාවිතා කරයි const char*, ඔබට අවශ්‍ය නූල් තර්ක වර්ගය අනුව එකම ශ්‍රිතයේ විවිධ අනුවාදයන් ලිවීමට සිදුවේ. උදාහරණයක් ලෙස, වින්ඩෝස් ශීර්ෂයන්, ඔබේම කේතයට බොහෝ විට බාධා කළ හැකි ගැටළුව සමඟ සාර්ථකව කටයුතු කිරීම සඳහා අතිශයින්ම කුපිත කරන මැක්‍රෝස් ඇත. dstringමිශ්‍රණයට එකතු කිරීමෙන් තත්වය තවත් නරක අතට හැරෙනු ඇත, දැන් නූල් වර්ග දෙකක් වෙනුවට, ඔබට තුනක් කළමනාකරණය කළ යුතුය. නූල් වර්ග එකකට වඩා තිබීම නඩත්තු වේදනාවන් වැඩි කිරීමටත්, නූල් සමඟ කටයුතු කරන පුනරාවර්තන කේත හඳුන්වා දීමටත් හේතු වේ.

ස්කොට් මේයර්ස් මෙසේ ලියයි.

D යනු නවීන මෘදුකාංග සංවර්ධනයේ අභියෝගයන්ට මුහුණ දීම සඳහා ක්‍රමලේඛකයන්ට උපකාර කිරීම සඳහා ගොඩනගා ඇති ක්‍රමලේඛන භාෂාවකි. එය සිදු කරනුයේ නිරවද්‍ය අතුරුමුහුණත් හරහා අන්තර් සම්බන්ධිත මොඩියුලයන් පෝෂණය කිරීමෙනි, තදින් ඒකාබද්ධ වූ ක්‍රමලේඛන පරාමිතීන්ගේ සම්මේලනය, භාෂාව බලාත්මක කරන ලද නූල් හුදකලා කිරීම, මොඩියුලර් වර්ගයේ ආරක්ෂාව, කාර්යක්ෂම මතක ආකෘතියක් සහ තවත් දේ.

භාෂාව බලාත්මක කරන ලද නූල් හුදකලා වීම වැඩි නොවේ. C ++ ක්‍රමලේඛකයින් ඔවුන්ගේ වැඩසටහන් පිළිබඳ පූර්ණ පාලනයක් අපේක්ෂා කරන අතර යමක් බල කරන භාෂාව අනිවාර්යයෙන්ම වෛද්‍යවරයා නියෝග කළ දේ නොවේ.

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

ඊට අමතරව, ඔබට යම් ප්‍රතීකයක් අපේක්ෂා කළ හැකිය. D හි කසළ එකතු කිරීමක් ඇති අතර, C ++ ක්‍රමලේඛකයින් ජාවා සහ සී # වැනි භාෂාවන් සමඟ සම්බන්ධ වන අතර ඒවා දර්ශනවාදයට තරමක් directly ජුව විරුද්ධ වන අතර සින්ටැක්ටික් සමානකම් ද ඒවා මතකයට නංවනු ඇත. මෙය අනිවාර්යයෙන්ම වෛෂයිකව යුක්ති සහගත නොවේ, නමුත් එය නිසැකවම සැලකිල්ලට ගත යුතු දෙයකි.

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

මේ දේවල් මතුපිට ගැටළු පමණක් වුවද, මතුපිටින් ඩී ඇත්ත වශයෙන්ම සී ++ මෙන් නොපෙනීම බොහෝ සී ++ ක්‍රමලේඛකයින් ඩී වෙත සංක්‍රමණය නොවීමට හොඳ හේතුවක් විය හැකි බව මට හොඳටම විශ්වාසයි. සමහර විට ඩී වඩා හොඳ රැකියා ප්‍රචාරණයක් කළ යුතුය.

C ++ හි මා අගය කරන එක් දෙයක් නම්, ශ්‍රිත තර්කයක් හෝ ප්‍රතිලාභ අගයක් දර්ශකයක් වෙනුවට C ++ යොමු කිරීමක් ලෙස ලේඛනගත කිරීමේ හැකියාවයි null.

ඩී අනුවාදය:

class A { int i; }

int foo(A a) {
    return a.i; // Will crash if a is null
}

int main() {
    A bar = null;
    // Do something, forgetting to set bar in all
    // branches until finally ending up at:
    return foo(bar);
}

සී ++ අනුවාදය:

class A { int i; };

int foo(A& a) {
    return a.i; // Will probably not crash since
                // C++ references are less likely
                // to be null.
}

int main() {
    A* bar = null;
    // Do something, forgetting to set bar in all
    // branches until finally ending up at:
    // Hm.. I have to dereference the bar-pointer
    // here, otherwise it wont compile.  Lets add
    // a check for null before.
    if (bar)
        return foo(*bar);
    return 0;
}

සාධාරණ Aවීමට නම්, ඩී බවට පත් කිරීමෙන් structසහ foo()-ආරක්ෂය a ලෙස සලකුණු කිරීමෙන් ඔබට C ++ ට ඉතා සමීප විය හැකිය ref(පන්ති යනු යොමු වර්ග සහ ව්‍යුහයන් C හි අගය වර්ග වේ, C # ට සමාන වේ).

NonNullableඒ වෙනුවට ඩී සම්මත පුස්තකාල ඉදිකිරීමක් ලෙස පන්ති සඳහා අච්චුවක් නිර්මාණය කිරීමේ සැලසුමක් ඇතැයි මම විශ්වාස කරමි . එසේ වුවද , Type&සසඳන විට එහි සංක්ෂිප්තතාවයට මම කැමතියි NonNullable(Type), සහ සුපුරුදු පරිදි ශුන්‍ය නොවන දේට කැමැත්තෙමි (වැනි යමක් විදැහුම් කිරීම Typeසහ Nullable(Type)). නමුත් ඩී සඳහා එය වෙනස් කිරීමට ප්‍රමාද වැඩියි, මම දැන් මාතෘකාවෙන් බැහැරව සිටිමි.

ඩී ++ ට වඩා සී ++ “වඩා හොඳ” කරන වැදගත්ම දෙය වන්නේ උරුම පුස්තකාල සමඟ අන්තර් සම්බන්ධ වීමයි. විවිධ ත්‍රිමාණ එන්ජින්, ඕපන් සීඑල් සහ සමානව. D අළුත් බැවින්, එය තෝරා ගැනීමට වඩා අඩු පුස්තකාල ප්‍රමාණයක් ඇත.

C ++ සහ D අතර ඇති තවත් වැදගත් වෙනසක් නම්, C ++ සතුව මූල්‍යමය වශයෙන් ස්වාධීන වෙළෙන්දන් කිහිප දෙනෙකු සිටින නමුත් 2014 වන විට D හි ඇත්තේ ප්‍රායෝගිකව එක් අයෙකු පමණි , එය නිර්මාණය කළ 2-පුද්ගලයින් කණ්ඩායමයි. ව්යාපෘති කිසි විටෙකත් තාක්‍ෂණය, සංරචක මත රඳා නොපවතින බව පවසන "දෙවන මූලාශ්ර මූලධර්මය" එකම, තනි, විකුණුම්කරුවෙකු පමණක් ඇති මෘදුකාංග සඳහා පවා තබා ඇති බව සිත්ගන්නා කරුණකි .

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

ජාවා හි ඉතිහාසය පෙන්නුම් කරන්නේ, තාක්‍ෂණයක, මේ අවස්ථාවේ දී, ජාවා සතුව කදිම, නමුත් තනි, මූල්‍යකරුවෙකු සිටියත්, විශාල ආයතනික පරිශීලක පදනමක් නොසලකා, තාක්‍ෂණය අත්‍යවශ්‍යයෙන්ම ඉවත ලන බවට විශාල අවදානමක් පවතින බවයි. EC "විධායක කමිටුව" යන්නෙන් අදහස් කරන Apache මෘදුකාංග පදනමේ උපුටා දැක්වීමක් :

ඔරකල් විසින් EC ට ජාවා SE 7 පිරිවිතර ඉල්ලීමක් සහ ස්වයං පරස්පර විරෝධී බලපත්‍රයක් ලබා දී ඇති අතර පිරිවිතරයේ ස්වාධීන ක්‍රියාත්මක කිරීම් දැඩි ලෙස සීමා කිරීම සහ වඩාත් වැදගත් ලෙස පිරිවිතරයේ ස්වාධීන විවෘත මූලාශ්‍ර ක්‍රියාත්මක කිරීම තහනම් කිරීම.

Note තිහාසික සටහනක් ලෙස, HTML5 WebGL සංවර්ධනය වීමට වසර ගණනාවකට පෙර ජාවා ඇප්ලෙට් වල දෘඩාංග ත්‍රිමාණ කැන්වස් වේගවත් කළ බව පැවසිය හැකිය. ජාවා ප්‍රජා ව්‍යාපෘතියක් වූයේ නම් ජාවා ඇප්ලෙට් ආරම්භක වේග ගැටළුව විසඳා ගත හැකි නමුත් ජාවා හි එකම මූල්‍යකරුවා වන සන් මයික්‍රො සිස්ටම්ස් හි විධායකයින්ට ජාවා ක්‍රියාත්මක කිරීම නිවැරදි කිරීමට තරම් වැදගත් නොවීය. අවසාන ප්‍රති result ලය: ජාවා GUI රාමුවල (ස්විං, ආදිය) “දුප්පත් මිනිසාගේ අනුරුවක්” ලෙස බහු වෙළෙන්දන් විසින් HTML5 කැන්වස්. සේවාදායක පැත්තේ පයිතන් ක්‍රමලේඛන භාෂාවට ජාවා පොරොන්දු වූ වාසි ඇත: දෘඩාංග නොසලකා සෑම සේවාදායකයකම වරක් ලියන්න, පයිතන් යෙදුම යන්ත්‍ර කේතයට සම්පාදනය කර නොමැති නම්. පයිතන් ජාවා තරම් පැරණි / තරුණ ය, නමුත් ජාවා මෙන් නොව එය '

සාරාංශය:

නිෂ්පාදන භාවිතය සඳහා තාක්‍ෂණය තක්සේරු කිරීමේදී, තාක්ෂණයන්හි වැදගත්ම ගුණාංග වන්නේ එය සංවර්ධනය කරන පුද්ගලයින්, සමාජ ක්‍රියාවලිය, සංවර්ධනය සිදුවන ස්ථානය සහ මූල්‍යමය වශයෙන් ස්වාධීන සංවර්ධන කණ්ඩායම් සංඛ්‍යාවයි.

තාක්‍ෂණය T2 ට වඩා T1 තාක්‍ෂණය භාවිතා කිරීම වඩා වාසිදායකද යන්න රඳා පවතින්නේ තාක්ෂණයන්හි වෙළෙන්දන් මත වන අතර T2 ට වඩා ලාභදායී ලෙස ව්‍යාපෘති සම්බන්ධ ගැටළු විසඳීමට T1 ඉඩ දෙයිද යන්න. උදාහරණයක් ලෙස, තනි සැපයුම්කරු ප්‍රශ්නය නොසලකා හරිනු ලැබුවහොත්, තොරතුරු පද්ධති සඳහා ජාවා සී ++ ට වඩා “වඩා හොඳ” තාක්‍ෂණයක් වනු ඇත, මන්ද ජාවා ද්විමය නව දෘඩාංග සඳහා යෙදවීමේදී නැවත එකතු කිරීම අවශ්‍ය නොවන අතර මතක කළමනාකරණය හා සම්බන්ධ මෘදුකාංග සංවර්ධන වැඩ ප්‍රමාණය ජාවා සඳහා එය C ++ ට වඩා කුඩා වේ. මුල සිටම සංවර්ධනය කරන ලද ව්‍යාපෘති, උදා: වෙනත් පුස්තකාල මත රඳා නොපවතින ව්‍යාපෘති, C ++ ට වඩා D හි සංවර්ධනය කිරීම සඳහා ලාභදායී විය හැකි නමුත්, අනෙක් අතට, C ++ හි එක් වෙළෙන්දෙකුට වඩා ඇති අතර එබැවින් දිගු කාලීනව අවදානම් අඩුය . (ජාවා උදාහරණය, ​​සන් මයික්‍රො සිස්ටම්ස් පාහේ හොඳින් තිබූ තැන,

සමහර C ++ සීමාවන්ට හැකි විසඳුමක්

C ++ හි සමහර සීමාවන්ට කළ හැකි එක් විසඳුමක් නම් නිර්මාණ රටාවක් භාවිතා කිරීමයි, එහිදී ආරම්භක කර්තව්‍යය කැබලිවලට ගෙන ගොස් කෑලි "වර්ග කර ඇත" (වර්ගීකරණය, පොකුරු, බෙදීම්, වෙනත් ලස්සන වචන-සඳහා- එකම දේ) පන්ති 2 කට: මතක ප්‍රවේශ රටාවන් ප්‍රදේශයට ඉඩ නොදෙන තාර්කික සම්බන්ධ කාර්යයන් පාලනය කරන්න; සං signal ා සැකසුම් වැනි කාර්යයන් , ප්‍රදේශය පහසුවෙන් ළඟා කර ගත හැකිය. සං like ා සැකසුම් “වැනි” කාර්යයන් සාපේක්ෂව සරල කොන්සෝල වැඩසටහන් සමූහයක් ලෙස ක්‍රියාත්මක කළ හැකිය. පාලන තාර්කික සම්බන්ධ කාර්යයන් සියල්ලම රූබි හෝ පයිතන් හෝ වෙනත් ආකාරයකින් ලියා ඇති තනි ස්ක්‍රිප්ට් එකකට තබා ඇත, එහිදී මෘදුකාංග සංවර්ධන සුවපහසුව වේගයට වඩා වැඩි ප්‍රමුඛතාවයක් ඇත.

මෙහෙයුම් පද්ධති ක්‍රියාවලීන් අතර මිල අධික මෙහෙයුම් පද්ධති ක්‍රියාවලිය ආරම්භ කිරීම සහ දත්ත පිටපත් කිරීම වලක්වා ගැනීම සඳහා, කුඩා C ++ කොන්සෝල යෙදුම් සමූහය තනි C ++ වැඩසටහනක් ලෙස ක්‍රියාත්මක කළ හැකි අතර එය රූබි / පයිතන් / යනාදිය විසින් "සර්වට්ලට්" ලෙස ආරම්භ කරනු ලැබේ. ස්ක්‍රිප්ට්. රූබි / පයිතන් / යනාදිය. පිටපත පිටවීමට පෙර සේවාදායකය වසා දමයි. "සර්වට්ලට්" සහ රූබි / පයිතන් / යනාදිය අතර සන්නිවේදනය. ස්ක්‍රිප්ට් සිදුවන්නේ ලිනක්ස් නම් නළය හෝ ඒ හා සමාන යාන්ත්‍රණයක් හරහා ය.

ආරම්භක කර්තව්‍යය ඉහත සඳහන් පංති 2 ට වර්ගීකරණය කළ හැකි කැබලිවලට පහසුවෙන් බෙදීමට ණය නොදුන්නේ නම්, උත්සාහ කළ යුතු දෙයක් නම් ආරම්භක කාර්යය වෙනස් වන පරිදි ගැටළුව නැවත වාක්‍ය ඛණ්ඩනය කිරීමයි.