මම ලියන බව වෙනත් අය විසින් ප්රකාශ කර තියෙනවා using namespace std;කේතය වැරදි වන අතර, මම භාවිතා කළ යුතු බව std::coutහා std::cinඒ වෙනුවට සෘජුව.

using namespace std;නරක පුරුද්දක් ලෙස සලකන්නේ ඇයි ? එය අකාර්යක්ෂමද? නැතහොත් අපැහැදිලි විචල්‍යයන් ( stdනාම අවකාශයේ ශ්‍රිතයක් ලෙස එකම නම බෙදා ගන්නා විචල්‍යයන්) ප්‍රකාශ කිරීමේ අවදානමක් තිබේද? එය කාර්ය සාධනයට බලපාන්නේද?

මෙය කිසිසේත්ම කාර්ය සාධනය හා සම්බන්ධ නොවේ. නමුත් මෙය සලකා බලන්න: ඔබ භාවිතා කරන්නේ Foo සහ Bar නමින් පුස්තකාල දෙකක්:

using namespace foo;
using namespace bar;

සෑම දෙයක්ම හොඳින් ක්‍රියාත්මක වන අතර ඔබට කිසිදු ගැටළුවක් නොමැතිව Blah()Foo සහ Quux()Bar වෙතින් ඇමතිය හැකිය . නමුත් එක් දිනක් ඔබ Foo 2.0 හි නව සංස්කරණයක් වෙත උත්ශ්‍රේණිගත කරයි, එය දැන් නමින් ශ්‍රිතයක් ඉදිරිපත් කරයි Quux(). දැන් ඔබට ගැටුමක් ඇති වී තිබේ: Foo 2.0 සහ Bar යන දෙකම Quux()ඔබගේ ගෝලීය නාම අවකාශයට ආනයනය කරයි. මෙය නිවැරදි කිරීමට යම් උත්සාහයක් ගනු ඇත, විශේෂයෙන් ක්‍රියාකාරී පරාමිතීන් ගැලපෙන්නේ නම්.

ඔබ භාවිතා කර ඇත්නම් foo::Blah()සහ bar::Quux()හඳුන්වාදීම foo::Quux()සිදුවීමක් නොවන එකක් වනු ඇත.

ග්‍රෙග් ලියූ සෑම දෙයක් සමඟම මම එකඟ වෙමි , නමුත් මම එකතු කිරීමට කැමතියි: එය ග්‍රෙග් පැවසූවාට වඩා නරක අතට හැරෙනු ඇත!

පුස්තකාලය ෆූ 2.0 උත්සවයකට හඳුන්වා දිය හැකි, Quux()ඒ සඳහා ඔබේ ඇමතුම් කිහිපයක් සඳහා පරිද්දෙන් තේරුම නිශ්චිතවම වඩා හොඳ තරගය Quux()වඩා bar::Quux()වසර සඳහා කැඳවුම් ඔබගේ කේතය. එවිට ඔබේ කේතය තවමත් සම්පාදනය කරයි , නමුත් එය නිහ ly ව වැරදි ක්‍රියාකාරිත්වය ලෙස හඳුන්වන අතර දෙවියන් දන්නා දේ කරයි. එය දේවල් ලබා ගත හැකි තරම් නරක ය.

බව මතක තබා ගන්න stdනාමඅවකාශයෙහි වන බොහෝ හඳුනා ටොන් ඇත ඉතා පොදු අය (හිතන්නේ list, sort, string, iteratorද, අනෙකුත් කේතය පෙනී වීමට ඉඩ ඇති වන, ආදිය).

ඔබ මෙය කළ නොහැක්කක් ලෙස සලකන්නේ නම්: මම මෙම පිළිතුර ලබා දී වසර භාගයකට පමණ පසු මෙය හරියටම හරියටම සිදු වූ තැනක් (අතහැර දැමූ උපසර්ගය හේතුවෙන් වැරදි ශ්‍රිතයක් ) ඇසීයstd:: . මෙන්න එවැනි ප්‍රශ්නයකට තවත් මෑත උදාහරණයකි. එබැවින් මෙය සැබෑ ගැටළුවකි.

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

දශකයක් තුළ, එම ව්‍යාපෘතියේ කේත පේළි මිලියන කිහිපයක් දක්වා වර්ධනය විය. මෙම සාකච්ඡා නැවත නැවතත් මතුවන හෙයින්, ව්‍යාපෘතියේ (අවසර ලත්) ක්‍රියාකාරී විෂය පථය usingසත්‍ය වශයෙන්ම කොපමණ වාර ගණනක් භාවිතා කර ඇත්දැයි මට වරක් කුතුහලයක් ඇති විය. මම ඒ සඳහා මූලාශ්‍ර ග්‍රහණය කර ගත් අතර එය භාවිතා කළ ස්ථාන දුසිමක් හෝ දෙකක් පමණක් සොයා ගතිමි. මට මෙයින් ඇඟවෙන්නේ, වරක් උත්සාහ කළ විට, සංවර්ධකයින්ට std::සෑම 100 kLoC භාවිතා කිරීමට අවසර දී ඇති ස්ථානයකදී පවා විධානයන් භාවිතා කිරීමට තරම් වේදනාකාරී නොවන බවයි.

නිගමනය: සෑම දෙයක්ම පැහැදිලිව උපසර්ග කිරීමෙන් කිසිදු හානියක් සිදු නොවේ, පුරුදු වීමට ඉතා අල්පය, වෛෂයික වාසි ඇත. විශේෂයෙන්, එය කේතය සම්පාදකයා සහ මිනිස් පා readers කයින් විසින් අර්ථ නිරූපණය කිරීම පහසු කරයි - සහ කේතය ලිවීමේදී එය ප්‍රධාන ඉලක්කය විය යුතුය.

using namespaceඔබේ පංතිවල ශීර්ෂ ලිපිගොනු දැමීමේ ගැටළුව නම්, එය ඔබේ පන්ති භාවිතා කිරීමට කැමති ඕනෑම කෙනෙකුට (ඔබේ ශීර්ෂ ලිපිගොනු ඇතුළත් කිරීමෙන්) අනෙක් නාම අවකාශයන් 'භාවිතා කිරීමට' (එනම් සියල්ල දැකීමට) බල කරයි.

කෙසේ වෙතත්, ඔබේ (පුද්ගලික) * .cpp ලිපිගොනු වල භාවිතා කිරීමේ ප්‍රකාශයක් තැබීමට ඔබට නිදහස තිබේ.

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

උරුමය C ++ කේතය සඳහා සහ නාම අවකාශයන් වෙත මාරුවීම පහසු කිරීම සඳහා භාවිතා කිරීමේ විධානය පවතී, නමුත් ඔබ බොහෝ විට එය නිතිපතා භාවිතා නොකළ යුතුය, අවම වශයෙන් ඔබේ නව C ++ කේතයේ නොවේ.

නිති අසන පැන විකල්ප දෙකක් යෝජනා කරයි:

• භාවිත ප්‍රකාශයක්:

  using std::cout; // a using-declaration lets you use cout without qualification
  cout << "Values:";

• Std :: ටයිප් කරන්න

  std::cout << "Values:";

මම මෑතකදී විෂුවල් ස්ටුඩියෝ 2010 පිළිබඳ පැමිණිල්ලක් ඉදිරිපත් කළෙමි . සියලු මූලාශ්‍ර ලිපිගොනු වල මෙම පේළි දෙක ඇති බව පෙනේ:

using namespace std;
using namespace boost;

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

එමනිසා, මග හැරීම using namespace X;යනු අනාගත-සනාථ කිරීමේ ආකාරයකි , භාවිතයේ ඇති පුස්තකාල සහ / හෝ ශීර්ෂ ලිපිගොනු වල වෙනසක් සහතික කිරීමට ක්‍රමයක් වැඩසටහනක් බිඳ නොදමනු ඇත.

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

සාරාංශය

නාම අවකාශය භාවිතා කිරීම ඔබේ පහසුව සඳහා මිස අන් අයට බලපෑම් කිරීමට නොවේ: # ඇතුළත් කිරීමේ නියෝගයකට පෙර කිසි විටෙක භාවිතා කිරීමේ ප්‍රකාශයක් හෝ භාවිතා කිරීමේ නියෝගයක් ලියන්න එපා.

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

සාකච්ඡා

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

කිසිවෙකු usingගෝලීය විෂය පථයේ, විශේෂයෙන් ශීර්ෂ පා in වල විධානය භාවිතා නොකළ යුතුය . කෙසේ වෙතත්, ශීර්ෂ ගොනුවක පවා එය සුදුසු අවස්ථා තිබේ:

template <typename FloatType> inline
FloatType compute_something(FloatType x)
{
    using namespace std; // No problem since scope is limited
    return exp(x) * (sin(x) - cos(x * 2) + sin(x * 3) - cos(x * 4));
}

මෙය පැහැදිලි සුදුසුකම් ( std::sin, std::cos...) ට වඩා හොඳය , මන්ද එය කෙටි වන අතර පරිශීලක අර්ථ දක්වන ලද පාවෙන ලක්ෂ්‍ය වර්ග සමඟ වැඩ කිරීමේ හැකියාව ඇත ( තර්ක මත යැපෙන විමසුම (ADL) හරහා).

එය ගෝලීයව භාවිතා නොකරන්න

එය "නරක" ලෙස සලකනු ලබන්නේ ගෝලීයව භාවිතා කරන විට පමණි . නිසා:

• ඔබ ක්‍රමලේඛනය කරන නාම අවකාශය අවුල් කරයි.
• ඔබ බොහෝ දේ භාවිතා කරන විට, විශේෂිත හඳුනාගැනීමක් පැමිණෙන්නේ කොතැනින් දැයි පා ers කයන්ට අපහසු වනු ඇත using namespace xyz.
• ඔබේ මූලාශ්‍ර කේතයේ වෙනත් පා readers කයින් සඳහා සත්‍යය කුමක් වුවත් එය නිතර කියවන අයට ඊටත් වඩා සත්‍ය වේ: ඔබම. වසරකින් හෝ දෙකකින් නැවත පැමිණ බලන්න ...
• ඔබ ඔබ ගැන පමණක් කතා කරන්නේ නම්, ඔබ using namespace stdඅල්ලා ගන්නා සියලු දේ ගැන නොදැන සිටිය හැකිය - තවද ඔබ තවත් එකක් එකතු කරන විට #includeහෝ නව C ++ සංශෝධනයකට ගිය විට ඔබ නොදැන සිටි නාම ගැටුම් ඔබට ලැබෙනු ඇත.

ඔබට එය දේශීයව භාවිතා කළ හැකිය

ඉදිරියට ගොස් එය දේශීයව (පාහේ) නිදහසේ භාවිතා කරන්න. ඇත්ත වශයෙන්ම, මෙය නැවත නැවත කිරීමෙන් වළක්වයි std::- පුනරාවර්තනය ද නරක ය.

එය දේශීයව භාවිතා කිරීම සඳහා මෝඩකමක්

C ++ 03 හි swapඔබේ පන්ති සඳහා ශ්‍රිතයක් ක්‍රියාත්මක කිරීම සඳහා idiom - boilerplate කේතයක් තිබුණි . ඔබ සැබවින්ම දේශීය using namespace std- හෝ අවම වශයෙන් using std::swap:

class Thing {
    int    value_;
    Child  child_;
public:
    // ...
    friend void swap(Thing &a, Thing &b);
};
void swap(Thing &a, Thing &b) {
    using namespace std;      // make `std::swap` available
    // swap all members
    swap(a.value_, b.value_); // `std::stwap(int, int)`
    swap(a.child_, b.child_); // `swap(Child&,Child&)` or `std::swap(...)`
}

මෙය පහත දැක්වෙන මැජික් කරයි:

• සම්පාදකවරයා තෝරාගන්නවා ඇත std::swapසඳහා value_, එනම්, void std::swap(int, int).
• ඔබ වැඩිපුර පැටවීමක් void swap(Child&, Child&)ක්‍රියාත්මක කර ඇත්නම් සම්පාදකයා එය තෝරා ගනු ඇත.
• ඔබ නම් නොවේ බව අධි බර ඇති සම්පාදකවරයා භාවිතා කරනු ඇත void std::swap(Child&,Child&)මෙම හුවමාරු එහි හොඳම උත්සාහ කරන්න.

C ++ 11 සමඟ මෙම රටාව තවදුරටත් භාවිතා කිරීමට හේතුවක් නැත. std::swapවිභව අධි බරක් සොයාගෙන එය තෝරා ගැනීම සඳහා ක්‍රියාත්මක කිරීම වෙනස් කරන ලදි.

ඔබ නිවැරදි ශීර්ෂ ගොනු ආනයනය නම්, ඔබ හදිසියේ වගේ නම් ඇති hex, left, plusහෝ countඔබේ ගෝලීය විෂය පථය තුල. මෙම std::නම් අඩංගු බව ඔබ නොදන්නේ නම් මෙය පුදුමයට කරුණක් විය හැකිය . ඔබ මෙම නම් දේශීයව භාවිතා කිරීමට උත්සාහ කළහොත් එය යම් ව්‍යාකූලත්වයක් ඇති කළ හැකිය.

සියලුම සම්මත දේවල් එහි නාම අවකාශයේ තිබේ නම්, ඔබේ කේතය හෝ වෙනත් පුස්තකාල සමඟ නම ගැටීම ගැන කරදර විය යුතු නැත.

තවත් හේතුවක් නම් පුදුමය.

මම දැක්කොත් cout << blah, std::cout << blahමම හිතන්නේ වෙනුවට : මේ coutමොකක්ද? එය සාමාන්‍ය coutදෙයක්ද? එය විශේෂ දෙයක්ද?

පළපුරුදු ක්‍රමලේඛකයින් ඔවුන්ගේ ගැටළු විසඳන ඕනෑම දෙයක් භාවිතා කරන අතර නව ගැටලු ඇති කරන ඕනෑම දෙයකින් වැළකී සිටින අතර, මෙම නිශ්චිත හේතුව නිසා ඔවුන් ශීර්ෂ-ගොනු මට්ටමේ භාවිතයන් මඟහරවා ගනී.

පළපුරුදු ක්‍රමලේඛකයින් ඔවුන්ගේ මූලාශ්‍ර ලිපිගොනු තුළ නම් සම්පූර්ණ සුදුසුකම් වලින් වැළකී සිටීමට උත්සාහ කරයි. මේ සඳහා සුළු හේතුවක් වන්නේ හොඳ හේතු නොමැති නම් අඩු කේත ප්‍රමාණවත් වන විට වැඩි කේතයක් ලිවීම අලංකාර නොවීමයි . මේ සඳහා ප්‍රධාන හේතුවක් වන්නේ තර්ක මත යැපෙන විමසුම (ADL) අක්‍රිය කිරීමයි.

මෙම හොඳ හේතු මොනවාද? සමහර විට ක්‍රමලේඛකයන්ට පැහැදිලිවම ADL ක්‍රියා විරහිත කිරීමට අවශ්‍ය වේ.

එබැවින් පහත සඳහන් දෑ හරි ය:

1. ශ්‍රිත ක්‍රියාත්මක කිරීමේදී ඇතුළත මට්ටමේ ක්‍රියාකාරීත්ව-විධානයන් සහ ප්‍රකාශන භාවිතා කිරීම
2. මූලාශ්‍ර ලිපිගොනු තුළ ප්‍රකාශන භාවිතා කිරීම
3. (සමහර විට) මූලාශ්‍ර-ගොනු මට්ටමේ භාවිතා කරමින්-විධානයන්

එය ගෝලීයව භාවිතා නොකළ යුතු බවට මම එකඟ වෙමි, නමුත් a හි මෙන් දේශීයව භාවිතා කිරීම එතරම් නපුරු නොවේ namespace. මෙන්න "C ++ ක්‍රමලේඛන භාෂාව" වෙතින් උදාහරණයක් :

namespace My_lib {

    using namespace His_lib; // Everything from His_lib
    using namespace Her_lib; // Everything from Her_lib

    using His_lib::String; // Resolve potential clash in favor of His_lib
    using Her_lib::Vector; // Resolve potential clash in favor of Her_lib

}

මෙම උදාහරණයේ දී, ඒවායේ සංයුතියෙන් පැන නගින විභව නාම ගැටුම් සහ අවිනිශ්චිතතාවයන් අපි විසඳා ගත්තෙමු.

එහි පැහැදිලිව ප්‍රකාශයට පත් කර ඇති නම් (භාවිතා කිරීම වැනි ප්‍රකාශයන් මගින් ප්‍රකාශයට පත් කරන ලද නම් ඇතුළුව His_lib::String) වෙනත් විෂය පථයකට ප්‍රවේශ විය හැකි නම් වලට වඩා ප්‍රමුඛතාවය ගනී using namespace Her_lib.

මම එය නරක පුරුද්දක් ලෙස ද සලකමි. මන්ද? එක් දිනක් මම සිතුවේ නාම අවකාශයක කාර්යය වන්නේ දේවල් බෙදීමයි, එබැවින් සෑම දෙයක්ම එක ගෝලීය බෑගයකට විසි කිරීමෙන් එය නරක් නොවිය යුතුය.

කෙසේ වෙතත්, මම බොහෝ විට 'cout' සහ 'cin' භාවිතා කරන්නේ නම්, මම ලියන්නේ: using std::cout; using std::cin;.cpp ගොනුවේ (කිසි විටෙකත් ශීර්ෂ ගොනුවේ එය ප්‍රචාරය නොවන විට #include). මම කිසි කෙනෙකුට සිහිකල්පනාව මෙතෙක් ඇළ නම් කරයි කියලා coutහෝ cin. ;)

කේතය දැක එය කරන දේ දැන ගැනීම සතුටක්. මා දුටුවහොත් එය පුස්තකාලයේ ධාරාව std::coutබව මම දනිමි . මම දැක්කොත් මම දන්නේ නැහැ. එය පුස්තකාලයේ ධාරාව විය හැකිය . නැතහොත් එකම ශ්‍රිතයේ පේළි දහයක් ඉහළින් තිබිය හැකිය . නැතහොත් එම ගොනුවේ නම් කර ඇති විචල්‍යයකි . එය ඕනෑම දෙයක් විය හැකිය.coutstdcoutcoutstdint cout = 0;staticcout

දැන් මිලියනයක රේඛා කේත පදනමක් ගන්න, එය විශේෂයෙන් විශාල නොවන අතර, ඔබ දෝෂයක් සොයමින් සිටී, එයින් අදහස් කරන්නේ මෙම පේළි මිලියනය තුළ එක් පේළියක් ඇති බව ඔබ දන්නා බවත් එය කළ යුතු දේ නොකරන බවත්ය. නමක් cout << 1;කියවා එය වමට මාරුවිය හැකි අතර ප්‍රති .ලය ඉවත දැමිය හැකිය . දෝෂයක් සොයමින්, මට එය පරීක්ෂා කිරීමට සිදුවේ. මම ඇත්තටම දැකීමට කැමති ආකාරය ඔබට දැක ගත හැකිද ?static intcoutstd::cout

ඔබ ගුරුවරයෙකු නම් සහ ජීවත්වීම සඳහා කිසිඳු කේතයක් ලිවීමට හා නඩත්තු කිරීමට අවශ්‍ය නොවූයේ නම් එය හොඳ අදහසක් ලෙස පෙනේ. (1) එය කරන්නේ කුමක්දැයි මම දනිමි. සහ, (2) එය ලියන පුද්ගලයා එය කරන්නේ කුමක්දැයි දැන සිටි බව මට විශ්වාසයි.

මේ සියල්ල සංකීර්ණත්වය කළමනාකරණය කිරීමයි. නාම අවකාශය භාවිතා කිරීමෙන් ඔබට අවශ්‍ය නොවන දේ ඇද ගත හැකි අතර එමඟින් නිදොස් කිරීම අපහසු වනු ඇත (මම සමහර විට කියමි). Std :: භාවිතා කිරීම සෑම තැනකම කියවීමට අපහසුය (වැඩි පෙළ සහ ඒ සියල්ල).

පා courses මාලා සඳහා අශ්වයන් - ඔබට කළ හැකි හා හැකි යැයි හැඟෙන ආකාරය ඔබේ සංකීර්ණතාව කළමනාකරණය කරන්න.

සලකා බලන්න

// myHeader.h
#include <sstream>
using namespace std;


// someoneElses.cpp/h
#include "myHeader.h"

class stringstream {  // Uh oh
};

මෙය සරල උදාහරණයක් බව සලකන්න. ඇතුළත් කිරීම් සහ වෙනත් ආනයන 20 ක් සහිත ලිපිගොනු ඔබ සතුව ඇත්නම්, ගැටළුව හඳුනා ගැනීම සඳහා ඔබට යැපීම් ටොන් ගණනක් ඇත. එහි ඇති භයානකම දෙය නම් ගැටුම් ඇති කරන නිර්වචන මත පදනම්ව ඔබට වෙනත් මොඩියුලවල සම්බන්ධයක් නැති දෝෂ ලබා ගත හැකිය.

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

1. ඔබට වඩා වෙනස් ශෛලියක් සහ හොඳ පුරුදු අදහස් ඇති පුද්ගලයින් විසින් ලියන ලද කේත කියවීමට ඔබට හැකියාව තිබිය යුතුය.

2. ඔබ පමණක් භාවිතා කරන්නේ නම් cout, කිසිවෙකු ව්‍යාකූල නොවනු ඇත. නමුත් ඔබට නාම අවකාශයන් විශාල ප්‍රමාණයක් පියාසර කර ඇති අතර ඔබ මෙම පංතිය දකින අතර එය කරන්නේ කුමක්දැයි ඔබට හරියටම විශ්වාස නැත. ඔබට බැලූ බැල්මට "ඔහ්, මෙය ගොනු පද්ධති මෙහෙයුමක්" හෝ "එය ජාල දේවල් කරයි".

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

එබැවින් ඒවා "int" හෝ "class" වැනි වෙන් කළ නම් ලෙස සලකන්න.

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

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

පංතියේ ක්‍රමවේදයන් සමාන දත්ත වර්ග (සාමාජිකයන්) සමඟ කටයුතු කිරීමට නැඹුරු වන බැවින් මම සාමාන්‍යයෙන් එය මගේ පන්ති ප්‍රකාශනයේ භාවිතා කරමි. ටයිප්ඩෙෆ් යනු පන්තියේ සන්දර්භය තුළ අර්ථවත් නමක් ලබා දීමට අවස්ථාවකි. මෙය ඇත්ත වශයෙන්ම පන්ති ක්‍රමවල අර්ථ දැක්වීම් කියවීමේ හැකියාව සඳහා උපකාරී වේ.

// Header
class File
{
   typedef std::vector<std::string> Lines;
   Lines ReadLines();
}

සහ ක්‍රියාත්මක කිරීමේදී:

// .cpp
Lines File::ReadLines()
{
    Lines lines;
    // Get them...
    return lines;
}

විරුද්ධ ලෙස:

// .cpp
vector<string> File::ReadLines()
{
    vector<string> lines;
    // Get them...
    return lines;
}

හෝ:

// .cpp
std::vector<std::string> File::ReadLines()
{
    std::vector<std::string> lines;
    // Get them...
    return lines;
}

උත්සුකය පැහැදිලි කිරීම සඳහා ස්ථිර උදාහරණයක්. ඔබට පුස්තකාල දෙකක් ඇති තත්වයක් ඇතැයි සිතන්න, fooසහ barඑක් එක් ඒවායේ නම් අවකාශය ඇත:

namespace foo {
    void a(float) { /* Does something */ }
}

namespace bar {
    ...
}

දැන් අපි කියමු ඔබ ඔබේම වැඩසටහනේ පහත පරිදි භාවිතා කරන බව fooසහ barඑකට:

using namespace foo;
using namespace bar;

void main() {
    a(42);
}

මේ අවස්ථාවේදී සියල්ල හොඳයි. ඔබ ඔබේ වැඩසටහන ක්‍රියාත්මක කරන විට එය 'යමක් කරයි'. නමුත් පසුව ඔබ යාවත්කාලීන barකර එය වෙනස් වී ඇති බව කියමු:

namespace bar {
    void a(float) { /* Does something completely different */ }
}

මෙම අවස්ථාවේදී ඔබට සම්පාදක දෝෂයක් ලැබෙනු ඇත:

using namespace foo;
using namespace bar;

void main() {
    a(42);  // error: call to 'a' is ambiguous, should be foo::a(42)
}

එබැවින් 'අ' යන්නෙන් අදහස් කරන බව පැහැදිලි කිරීම සඳහා ඔබ යම් නඩත්තු කිරීමක් කළ යුතුය foo::a. එය නුසුදුසු ය, නමුත් වාසනාවකට එය ඉතා පහසු ය ( සම්පාදකයා අපැහැදිලි යැයි සලකුණු කරන foo::සියලු ඇමතුම් ඉදිරියේ එක් කරන්න a).

නමුත් මේ වෙනුවට පෙනීම වෙනුවට තීරුව වෙනස් වූ විකල්ප අවස්ථාවක් ගැන සිතන්න:

namespace bar {
    void a(int) { /* Does something completely different */ }
}

මෙම අවස්ථාවෙහිදී ඔබගේ ඇමතුම a(42)හදිසියේම බැඳී bar::aඇති foo::aඅතර ඒ වෙනුවට 'යමක්' කරනවා වෙනුවට එය 'සම්පූර්ණයෙන්ම වෙනස් දෙයක්' කරයි. සම්පාදක අනතුරු ඇඟවීමක් හෝ කිසිවක් නැත. ඔබේ වැඩසටහන නිහ ly ව පෙරට වඩා වෙනස් දෙයක් කිරීමට පටන් ගනී.

ඔබ නාම අවකාශයක් භාවිතා කරන විට ඔබ මෙවැනි තත්වයක් අවදානමට ලක් කරයි, ඒ නිසා මිනිසුන්ට නාම අවකාශ භාවිතා කිරීම අපහසු වේ. නාම අවකාශයක වැඩි වැඩියෙන් ගැටුම් ඇතිවීමේ අවදානම වැඩි වන stdබැවින් අනෙක් නාම අවකාශයන්ට වඩා නාම අවකාශය (එම නාම අවකාශයේ ඇති දේවල් ගණන නිසා) භාවිතා කිරීම මිනිසුන්ට වඩාත් අපහසු විය හැකිය .

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

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

namespace Mylib{
    template<class T> class Stack{ /* ... */ };
    // ...
}

namespace Yourlib{
    class Stack{ /* ... */ };
    // ...
}

void f(int max) {
    Mylib::Stack<int> s1(max); // Use my stack
    Yourlib::Stack    s2(max); // Use your stack
    // ...
}

නාම අවකාශයේ නමක් පුනරාවර්තනය කිරීම පා readers කයන්ට මෙන්ම ලේඛකයින්ට ද අවධානය වෙනතකට යොමු කළ හැකිය. එහි ප්‍රති, ලයක් වශයෙන්, නිශ්චිත නාම අවකාශයකින් නම් පැහැදිලි සුදුසුකම් නොමැතිව ලබා ගත හැකි බව සඳහන් කළ හැකිය. උදාහරණයක් වශයෙන්:

void f(int max) {
    using namespace Mylib; // Make names from Mylib accessible
    Stack<int> s1(max); // Use my stack
    Yourlib::Stack s2(max); // Use your stack
    // ...
}

විවිධ පුස්තකාල කළමනාකරණය සහ කේතයේ විවිධ අනුවාදයන් කළමනාකරණය කිරීම සඳහා නාම අවකාශයන් ප්‍රබල මෙවලමක් සපයයි. විශේෂයෙන්, ඔවුන් ස්ථානීය නොවන නමකට යොමු කිරීම කෙතරම් පැහැදිලිද යන්න ක්‍රමලේඛක විකල්ප ඉදිරිපත් කරයි.

මූලාශ්‍රය: බර්න් ස්ට්‍රෝස්ට්‍රප් විසින් සී ++ ක්‍රමලේඛන භාෂාව පිළිබඳ දළ විශ්ලේෂණයක්

using namespace stdගණනය කිරීමේ අපැහැදිලි බව නිසා සම්පාදක දෝෂයක් විසි කරන උදාහරණයක් , එය ඇල්ගොරිතම පුස්තකාලයේ ශ්‍රිතයකි.

#include <iostream>

using namespace std;

int count = 1;
int main() {
    cout << count << endl;
}

එය ඔබගේ මෘදුකාංග හෝ ව්‍යාපෘති ක්‍රියාකාරිත්වය නරක අතට හරවන්නේ නැත. ඔබේ ප්‍රභව කේතයේ ආරම්භයේ දී නාම අවකාශය ඇතුළත් කිරීම නරක නැත. using namespace stdඋපදෙස් ඇතුළත් කිරීම ඔබේ අවශ්‍යතා සහ ඔබ මෘදුකාංගය හෝ ව්‍යාපෘතිය සංවර්ධනය කරන ආකාරය අනුව වෙනස් වේ.

මෙම namespace stdC ++ සම්මත කාර්යයන් හා විචල්යයන් අන්තර්ගත වේ. ඔබ බොහෝ විට C ++ සම්මත ශ්‍රිත භාවිතා කරන විට මෙම නාම අවකාශය ප්‍රයෝජනවත් වේ.

මෙම පිටුවේ සඳහන් පරිදි :

නාම අවකාශය භාවිතා කරන ප්‍රකාශය සාමාන්‍යයෙන් නරක පුරුද්දක් ලෙස සැලකේ. මෙම ප්‍රකාශයට විකල්පය නම්, අප වර්ගයක් ප්‍රකාශ කරන සෑම අවස්ථාවකම විෂය පථ ක්‍රියාකරු (: :) භාවිතා කරමින් හඳුනාගැනීමේ නාම අවකාශය නියම කිරීමයි.

මෙම මතය බලන්න :

ඔබ නාම අවකාශය අධික ලෙස භාවිතා කරන විට සහ කිසිවක් ගැටෙන්නේ නැති බව නිසැකවම දැන ගන්නා විට ඔබේ මූලාශ්‍ර ගොනුවේ "නාම අවකාශය භාවිතා කිරීම" භාවිතා කිරීමේ කිසිදු ගැටළුවක් නොමැත.

සමහර අය පවසා using namespace stdඇත්තේ ඔබේ මූලාශ්‍ර ලිපිගොනු තුළට ඇතුළත් කිරීම නරක පුරුද්දක් බැවින් ඔබ එම නාම අවකාශයේ සිට සියලු කාර්යයන් සහ විචල්‍යයන් ඉල්ලා සිටින බවයි. නව ශ්‍රිතයක් එකම නමක් සහිත වෙනත් ශ්‍රිතයක් ලෙස අර්ථ දැක්වීමට ඔබ කැමති විට, ඔබ namespace stdශ්‍රිතය අධික ලෙස පටවන අතර එය සම්පාදනය කිරීම හෝ ක්‍රියාත්මක කිරීම හේතුවෙන් ගැටළු ඇති කළ හැකිය. එය ඔබ අපේක්ෂා කළ පරිදි සම්පාදනය හෝ ක්‍රියාත්මක නොකරනු ඇත.

මෙම පිටුවේ සඳහන් පරිදි :

මෙම ප්‍රකාශය std :: යතුරු ලියනය කිරීමෙන් අපව ගලවා ගත්තද, අපි පන්තියේ හෝ අවකාශයේ නාම අවකාශයේ අර්ථ දක්වා ඇති වර්ගයකට ප්‍රවේශ වීමට කැමති සෑම අවස්ථාවකම, එය වැඩසටහනේ වත්මන් නාම අවකාශයට ආනයනය කරයි. මෙය එතරම් හොඳ දෙයක් නොවන්නේ මන්දැයි තේරුම් ගැනීමට අපි උදාහරණ කිහිපයක් බලමු

...

දැන් සංවර්ධනයේ පසුකාලීන අවධියේදී, “foo” නමින් සමහර පුස්තකාලයක අභිරුචිකරණය කර ඇති තවත් කෝට් අනුවාදයක් භාවිතා කිරීමට අපි කැමැත්තෙමු (උදාහරණයක් ලෙස)

...

අවිනිශ්චිතතාවයක් ඇති ආකාරය සැලකිල්ලට ගන්න, කෝට් පෙන්වා දෙන්නේ කුමන පුස්තකාලයටද? සම්පාදකයා විසින් මෙය හඳුනාගෙන වැඩසටහන සම්පාදනය නොකරයි. නරකම අවස්ථාවෙහිදී, වැඩසටහන තවමත් සම්පාදනය කළ හැකි නමුත් වැරදි ශ්‍රිතය ලෙස හැඳින්විය හැක, මන්ද හඳුනාගැනීමේ යන්ත්‍රය අයත් වන්නේ කුමන නාම අවකාශයටද යන්න අප කිසි විටෙකත් නිශ්චිතව දක්වා නැත.

සෑම තත්වයක් යටතේම එය අනිවාර්යයෙන්ම නරක පුරුද්දක් යැයි මම නොසිතමි, නමුත් ඔබ එය භාවිතා කරන විට ප්‍රවේශම් විය යුතුය. ඔබ පුස්තකාලයක් ලියන්නේ නම්, ඔබේ පුස්තකාලය වෙනත් පුස්තකාල සමඟ හිස ගසා දැමීමෙන් වළක්වා ගැනීමට නම් අවකාශය සහිත විෂය පථ විභේදන ක්‍රියාකරුවන් භාවිතා කළ යුතුය. යෙදුම් මට්ටමේ කේතය සඳහා, එහි කිසිදු වරදක් මා දකින්නේ නැත.

"ඇයි 'නාම අවකාශය භාවිතා කරන්නේ?' C ++ හි නරක පුරුද්දක් ලෙස සලකනවාද?

මම එය අනෙක් පැත්තට තැබුවෙමි: අමතර අක්ෂර පහක් ටයිප් කිරීම සමහරුන් විසින් කරදරකාරී ලෙස සලකන්නේ ඇයි?

උදා: සංඛ්‍යාත්මක මෘදුකාංගයක් ලිවීම සලකා බලන්න. වසමේ වැදගත්ම සංකල්පවලින් එකක් වන “දෛශිකය” වන විට සාමාන්‍ය “std :: vector” “දෛශිකය” දක්වා අඩු කිරීමෙන් මගේ ගෝලීය නාම අවකාශය දූෂණය කිරීම ගැන මා සිතන්නේ ඇයි?

මම අන් අය සමඟ එකඟ වෙමි - එය ඉල්ලා සිටින්නේ නාම ගැටුම්, අවිනිශ්චිතතාවයන් සහ පසුව කාරණය නම් එය අඩු පැහැදිලිය. භාවිතය මට දැකිය හැකි අතර using, මගේ පෞද්ගලික මනාපය එය සීමා කිරීමයි. තවත් සමහරු පෙන්වා දුන් දේ මම තරයේ සලකා බලමි.

ඔබට තරමක් පොදු නමක් විය හැකි ශ්‍රිත නාමයක් සොයා ගැනීමට අවශ්‍ය නම්, නමුත් ඔබට එය සොයා ගැනීමට අවශ්‍ය වන්නේ stdනාම අවකාශයේ පමණි (හෝ ආපසු හැරවීම - ඔබට අවශ්‍ය වන්නේ නාම අවකාශයේ , නාම අවකාශයේ , නැති සියලුම ඇමතුම් වෙනස් කිරීමටය , ...), එසේ නම් ඔබ මෙය කිරීමට යෝජනා කරන්නේ කෙසේද?stdX

ඔබට එය කිරීමට වැඩසටහනක් ලිවිය හැකිය, නමුත් ඔබේ ව්‍යාපෘතිය නඩත්තු කිරීම සඳහා වැඩසටහනක් ලිවීමට වඩා ඔබේ ව්‍යාපෘතියේ වැඩ කිරීම සඳහා කාලය ගත කිරීම වඩා හොඳ නොවේද?

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

ඉහත කාරණය හා අනෙක් අය පෙන්වා දෙන දෙයට එය තරමක් සම්බන්ධ වුවත් තවත් එක් දෙයක් තිබේ. මෙය නරක පුරුද්දක් විය හැකි නමුත්, සමහර විට මම std::nameසම්මත පුස්තකාල අනුවාදය සහ වැඩසටහන් විශේෂිත ක්‍රියාත්මක කිරීම සඳහා නම වෙන් කරමි. ඔව්, ඇත්ත වශයෙන්ම මෙය ඔබට දෂ්ට කළ හැකි අතර ඔබව තදින් දෂ්ට කළ හැකිය, නමුත් මේ සියල්ල මුල සිටම මා මෙම ව්‍යාපෘතිය මුල සිටම ආරම්භ කළ අතර ඒ සඳහා ඇති එකම ක්‍රමලේඛකයා මමය. උදාහරණය: මම එය අධික ලෙස පටවා std::stringඅමතන්නෙමි string. මට ප්‍රයෝජනවත් එකතු කිරීම් තිබේ. මගේ සී සහ යුනික්ස් (+ ලිනක්ස්) කුඩා අකුරු සඳහා ඇති නැඹුරුව නිසා මම එය අර්ධ වශයෙන් කළෙමි.

ඊට අමතරව, ඔබට නාම අවකාශ අන්වර්ථයන් තිබිය හැකිය. යොමු නොකල හැකි ප්‍රයෝජනවත් තැනක් සඳහා උදාහරණයක් මෙහි දැක්වේ. මම C ++ 11 ප්‍රමිතිය සහ විශේෂයෙන් libstdc ++ සමඟ භාවිතා කරමි. හොඳයි, එයට සම්පූර්ණ std::regexසහාය නැත. නිසැකවම, එය සම්පාදනය කරයි, නමුත් එය ක්‍රමලේඛකයාගේ අවසානයෙහි දෝෂයක් ලෙස එය ව්‍යතිරේකයක් විසි කරයි. නමුත් එය ක්‍රියාත්මක කිරීමේ lack නතාවයයි.

ඉතින් මෙන්න මම එය විසඳූ ආකාරය. Boost’s regex ස්ථාපනය කර එය සම්බන්ධ කරන්න. ඉන්පසු, මම පහත සඳහන් දේ කරන්නේ libstdc ++ එය මුළුමනින්ම ක්‍රියාත්මක කර ඇති විට, මට අවශ්‍ය වන්නේ මෙම කොටස ඉවත් කිරීම පමණක් වන අතර කේතය එලෙසම පවතී:

namespace std
{
    using boost::regex;
    using boost::regex_error;
    using boost::regex_replace;
    using boost::regex_search;
    using boost::regex_match;
    using boost::smatch;
    namespace regex_constants = boost::regex_constants;
}

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

යමක් පැහැදිලි කර ගැනීම සඳහා: එස්.ටී.එල්. හි හිතාමතාම හා වඩාත් නිශ්චිතවම වෙනුවට පන්තියක නමක් භාවිතා කිරීම හොඳ අදහසක් යැයි මම නොසිතමි . 'ස්ට්‍රිං' අදහසට මා අකමැති වූ නිසා, මට නම්, ව්‍යතිරේකය (මෙහි පළමු, ඉහළ හෝ දෙවන නොසලකා හරින්න, ඔබට අවශ්‍ය නම් ද pun ුවම් කරන්න).

එය එසේ වුවත්, මම තවමත් C කෙරෙහි ඉතා පක්ෂග්‍රාහී වන අතර C ++ ට පක්ෂග්‍රාහීව සිටිමි. අමතර තොරතුරු, මා වැඩ කරන බොහෝ දේ සී වලට වඩා ගැළපේ (නමුත් එය හොඳ ව්‍යායාමයක් සහ මා බවට පත් කර ගැනීමට හොඳ ක්‍රමයක් විය. වෙනත් භාෂාවක් ඉගෙන ගන්න සහ ආ. වස්තුව / පන්ති / යනාදිය කෙරෙහි අඩු පක්ෂග්‍රාහී නොවීමට උත්සාහ කරන්න. අඩු සංවෘත මනසක් ඇති, අඩු අහංකාර සහ වැඩි පිළිගැනීමක් ලෙස.). එහෙත් වේ ප්රයෝජනවත් සමහර දැනටමත් යෝජනා දේ: නියත වශයෙන්ම මා ලැයිස්තුව (? එය තරමක් Generic බලපත්රය යටතේ අවසර ලබා ඇත, එය නොවේ) ආකාරයක (එකම දෙයක්) මට කරන්න නම් නම ගැටුමක් ඇති වන බව දෙක නම් කිරීමට භාවිතා කරන්නේ, සහ using namespace std;, එසේ ඒ සඳහා මම වඩාත් කැමති නිශ්චිත, පාලනයෙන් සහ එය සම්මත භාවිතයක් වීමට අදහස් කරන්නේ නම් මට එය නියම කළ යුතු බව දැන සිටීම. සරලව කිවහොත්: උපකල්පනය කිරීමට අවසර නැත.

බූස්ට්ගේ රීජෙක්ස් කොටස බවට පත් කිරීම සඳහා std. අනාගත ඒකාබද්ධතාවය සඳහා මම එය කරන අතර - නැවතත්, මෙය සම්පූර්ණයෙන්ම පක්ෂග්‍රාහී බව මම පිළිගනිමි - එය තරම් කැත යැයි මම නොසිතමි boost::regex:: .... ඇත්ත වශයෙන්ම, එය මට තවත් දෙයක්. C ++ හි බොහෝ දේ ඇත, මට තවමත් පෙනුම සහ ක්‍රමවේදයන් සම්පූර්ණයෙන් පිළිගැනීමට නොමැත (තවත් උදාහරණයක්: විචල්ය සැකිලි එදිරිව var තර්ක [මම පිළිගත්තද විචල්‍ය ආකෘති ඉතා ප්‍රයෝජනවත් බව!]). මා පිළිගන්නා අය පවා එය දුෂ්කර වූ අතර මට තවමත් ඔවුන් සමඟ ගැටළු තිබේ.

මගේ අත්දැකීම් වලින්, ඔබ පවසන පුස්තකාල කිහිපයක් තිබේ නම් cout, නමුත් වෙනත් අරමුණක් සඳහා ඔබට වැරදි භාවිතා කළ හැකිය cout.

උදාහරණයක් ලෙස, මම ටයිප් නම්, using namespace std;හා using namespace otherlib;සාධාරණ ටයිප් cout(දෙකම විය සිදු වන), වඩා std::cout(හෝ 'otherlib::cout'), ඔබ වැරදි එකක් භාවිතා කරන්න, සහ වැරදි ලබා ගන්න. එය භාවිතා කිරීමට වඩා effective ලදායී හා කාර්යක්ෂම වේ std::cout.

නුසුදුසු ආනයනික හඳුනාගැනීම් සමඟ , හඳුනාගැනීම් ප්‍රකාශ කරන්නේ කොතැනදැයි සොයා ගැනීමට ඔබට grep වැනි බාහිර සෙවුම් මෙවලම් අවශ්‍ය වේ. මෙය ක්‍රමලේඛ නිරවද්‍යතාවය පිළිබඳ තර්ක කිරීම දුෂ්කර කරයි.

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

මෙය නරක පුරුද්දකි, එය බොහෝ විට ගෝලීය නාම අවකාශ දූෂණය ලෙස හැඳින්වේ. එක් නාම අවකාශයකට වඩා වැඩි ගණනක් එකම ක්‍රියාකාරී නාමයක් අත්සන සහිතව ඇති විට ගැටළු ඇතිවිය හැක, එවිට සම්පාදකයාට කුමන ඇමතුමක් ලබා දිය යුතුද යන්න තීරණය කිරීම අපැහැදිලි වන අතර ඔබේ ක්‍රියාකාරී ඇමතුම වැනි නම් අවකාශය ඔබ සඳහන් කරන විට මේ සියල්ල වළක්වා ගත හැකිය std::cout. මෙය උපකාරී වේ යැයි සිතමි. :)

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

මම කිව්වේ ඇත්තටම ... "මේ පැමිණීම මත විශ්වාසය නොතබන්න" යැයි පැවසීම යනු එය නොපැවතීම මත රඳා සිටීමට ඔබව සැකසීමයි. ඔබට නිරන්තරයෙන් කේත ස්නිපෙට් ණයට ගැනීම සහ ඒවා නිරන්තරයෙන් අලුත්වැඩියා කිරීම වැනි ගැටළු ඇති වේ. ඔබගේ පරිශීලකයා විසින් නිර්වචනය කරන ලද සහ ණයට ගත් දේවල් සීමිත පරාසයක තබාගෙන ඒවා ගෝලීයව නොසලකා හරින්න (අවංකවම ග්ලෝබල් සෑම විටම පාහේ "දැන් සම්පාදනය කරන්න, පසුව සනීපාරක්ෂාව" අරමුණු සඳහා අවසාන උත්සාහය විය යුතුය). ඇත්ත වශයෙන්ම මම සිතන්නේ එය ඔබේ ගුරුවරයාගේ නරක උපදෙසක් වන නිසා std භාවිතා කිරීම "cout" සහ "std :: cout" යන දෙකටම වැඩ කරන නමුත් std භාවිතා නොකිරීම "std :: cout" සඳහා පමණක් ක්‍රියාත්මක වේ. ඔබේම කේතයක් ලිවීමට ඔබ සැමවිටම වාසනාවන්ත නොවනු ඇත.

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