एक ही समय में कई नामस्थानों का उपयोग करना आपदा के लिए एक नुस्खा है, लेकिन जस्ट नेमस्पेस std का उपयोग करके और केवल नेमस्पेस std मेरी राय में एक सौदा का बड़ा नहीं है क्योंकि पुनर्वितरण केवल आपके कोड द्वारा ही हो सकता है ...

तो बस उन्हें "int" या "class" जैसे आरक्षित नामों के रूप में कार्य करने पर विचार करें और यही वह है।

लोगों को इसके बारे में इतना गुदा होने से रोकना चाहिए। आपका शिक्षक ठीक साथ था। बस एक नामस्थान का उपयोग करें; नामस्थानों का पहला स्थान उपयोग करने का यह पूरा बिंदु है। आप एक ही समय में एक से अधिक का उपयोग नहीं करना चाहिए। जब तक यह तुम्हारा नहीं है। तो फिर, पुनर्वितरण नहीं होगा।

एक उदाहरण जहां नामस्थान std का उपयोग गिनती की अस्पष्टता के कारण जटिलता त्रुटि को फेंकता है, जो एल्गोरिदम लाइब्रेरी में भी एक फ़ंक्शन है।

#include <iostream>

using namespace std;

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

अनुभवी प्रोग्रामर जो भी अपनी समस्याओं का समाधान करते हैं और जो भी नई समस्याएं पैदा करते हैं, उससे बचते हैं, और वे इस सटीक कारण के लिए हेडर-फ़ाइल-स्तरीय उपयोग-निर्देशों से बचते हैं।

अनुभवी प्रोग्रामर भी अपनी स्रोत फ़ाइलों के अंदर नामों की पूर्ण योग्यता से बचने का प्रयास करते हैं। इसके लिए एक मामूली कारण यह है कि अच्छे कोड होने तक कम कोड पर्याप्त होने पर अधिक कोड लिखना सुरुचिपूर्ण नहीं है । इसके लिए एक प्रमुख कारण तर्क-निर्भर लुकअप (एडीएल) बंद कर रहा है।

ये अच्छे कारण क्या हैं? कभी-कभी प्रोग्रामर स्पष्ट रूप से एडीएल को बंद करना चाहते हैं, अन्य बार वे असंतोष करना चाहते हैं।

तो निम्नलिखित ठीक हैं:

1. कार्यों के कार्यान्वयन के अंदर कार्य-स्तर का उपयोग-निर्देश और उपयोग-घोषणाएं
2. स्रोत फ़ाइलों के अंदर स्रोत-फ़ाइल-स्तर का उपयोग-घोषणाएं
3. (कभी-कभी) स्रोत-फ़ाइल-स्तर का उपयोग-निर्देश

यह एक बुरा अभ्यास है, जिसे अक्सर वैश्विक नामस्थान प्रदूषण के रूप में जाना जाता है। समस्या तब हो सकती है जब एक से अधिक नामस्थान में हस्ताक्षर के साथ एक ही कार्य नाम होता है, तो यह तय करने के लिए संकलक के लिए संदिग्ध होगा कि कौन से कॉल करना है और जब आप अपने फ़ंक्शन कॉल के साथ नामस्थान निर्दिष्ट कर रहे हैं तो यह सब टाला जा सकता है std::cout। उम्मीद है की यह मदद करेगा। :)

1. आपको उन लोगों द्वारा लिखे गए कोड को पढ़ने में सक्षम होना चाहिए जिनके पास अलग शैली और सर्वोत्तम प्रथाओं की राय है।

2. यदि आप केवल कॉउट का उपयोग कर रहे हैं, तो कोई भी उलझन में नहीं आता है। लेकिन जब आपके पास बहुत सारे नामस्थान उड़ते हैं और आप इस कक्षा को देखते हैं और आपको बिल्कुल यकीन नहीं है कि यह क्या करता है, नामस्थान स्पष्ट रूप से टिप्पणी के रूप में कार्य करता है। आप पहली नज़र में देख सकते हैं, 'ओह, यह एक फाइल सिस्टम ऑपरेशन है' या 'नेटवर्क सामान कर रहा है'।

मुझे नहीं लगता कि यह सभी परिस्थितियों में आवश्यक रूप से खराब अभ्यास है, लेकिन जब आप इसका इस्तेमाल करते हैं तो आपको सावधान रहना होगा। यदि आप लाइब्रेरी लिख रहे हैं, तो संभवतः आपको अपनी लाइब्रेरी को अन्य पुस्तकालयों के साथ सिर डालने से रोकने के लिए नामस्थान के साथ स्कोप रिज़ॉल्यूशन ऑपरेटर का उपयोग करना चाहिए। आवेदन स्तर कोड के लिए, मुझे इसके साथ कुछ भी गलत नहीं दिख रहा है।

यह जटिलता के प्रबंधन के बारे में सब कुछ है। नेमस्पेस का उपयोग करना उन चीजों को खींच देगा जो आप नहीं चाहते हैं, और इस प्रकार संभवतः इसे डीबग करना मुश्किल हो जाता है (मैं संभवतः कहता हूं)। सभी जगहों पर std :: का उपयोग करना कठिन है (अधिक पाठ और वह सब)।

पाठ्यक्रमों के लिए घोड़े - अपनी जटिलता का प्रबंधन करें कि आप कैसे कर सकते हैं और सक्षम महसूस कर सकते हैं।

यह बिल्कुल प्रदर्शन से संबंधित नहीं है। लेकिन इस पर विचार करें: आप फू और बार नामक दो पुस्तकालयों का उपयोग कर रहे हैं:

using namespace foo;
using namespace bar;

सबकुछ ठीक काम करता है, आप बिना किसी समस्या के बार से फू और Quux() से Blah() को कॉल कर सकते हैं। लेकिन एक दिन आप Foo 2.0 के एक नए संस्करण में अपग्रेड करते हैं, जो अब Quux() नामक फ़ंक्शन प्रदान करता है। अब आपके पास एक संघर्ष है: आपके वैश्विक नामस्थान में Foo 2.0 और Bar आयात Quux() दोनों। यह ठीक करने के लिए कुछ प्रयास करने जा रहा है, खासकर अगर फ़ंक्शन पैरामीटर मेल खाते हैं।

यदि आपने foo::Blah() और bar::Quux() , तो foo::Quux() का परिचय एक गैर-ईवेंट होता।

विचार करें

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


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

class stringstream {  // uh oh
};

ध्यान दें कि यह एक साधारण उदाहरण है, यदि आपके पास 20 फाइलों के साथ फाइलें हैं और अन्य आयात आपके पास समस्या का पता लगाने के लिए निर्भरता का एक टन होगा। इसके बारे में बदतर बात यह है कि आप संघर्ष की परिभाषाओं के आधार पर अन्य मॉड्यूल में असंबंधित त्रुटियां प्राप्त कर सकते हैं।

यह भयानक नहीं है लेकिन आप हेडर फाइलों या वैश्विक नेमस्पेस में इसका उपयोग न करके अपने आप को सिरदर्द बचाएंगे। शायद यह बहुत सीमित क्षेत्रों में ऐसा करने के लिए ठीक है, लेकिन मुझे यह स्पष्ट करने के लिए अतिरिक्त 5 वर्ण टाइप करने में कोई समस्या नहीं हुई है कि मेरे कार्य कहां से आ रहे हैं।

यदि आप दायां हेडर फाइल आयात करते हैं तो अचानक आपके पास hex , left , plus या आपके वैश्विक दायरे में count है। यह आश्चर्यजनक हो सकता है अगर आपको पता नहीं है कि std:: में इन नाम हैं। यदि आप स्थानीय रूप से इन नामों का उपयोग करने का भी प्रयास करते हैं तो यह काफी भ्रम पैदा कर सकता है।

यदि सभी मानक सामान अपने नामस्थान में हैं तो आपको अपने कोड या अन्य पुस्तकालयों के साथ नाम टकराव के बारे में चिंता करने की ज़रूरत नहीं है।

अपने प्रश्न का उत्तर देने के लिए मैं इसे व्यावहारिक रूप से देखता हूं: बहुत सारे प्रोग्रामर (सभी नहीं) नामस्थान std का आह्वान करते हैं। इसलिए किसी को उन चीज़ों का उपयोग न करने की आदत में होना चाहिए जो नामस्थान std में समान नामों का उपयोग या उपयोग करते हैं। यह एक बड़ा सौदा है, लेकिन संभावित सुसंगत शब्दों और छद्म शब्दों की संख्या की तुलना में इतना अधिक नहीं है जो कड़ाई से बोलने के साथ आ सकता है।

मेरा मतलब वास्तव में ... कह रहा है "इस उपस्थित होने पर भरोसा न करें" बस आपको इस पर भरोसा करने के लिए स्थापित कर रहा है कि वह उपस्थित न हो। आपको लगातार कोड स्निपेट उधार लेने और लगातार मरम्मत करने के मुद्दे होने जा रहे हैं। बस अपने उपयोगकर्ता द्वारा परिभाषित और उधारित सामान को सीमित दायरे में रखें क्योंकि वे होना चाहिए और ग्लोबल्स के साथ बहुत कम होना चाहिए (ईमानदारी से ग्लोबल्स को हमेशा "संकलन, बाद में संवेदना" के उद्देश्यों के लिए अंतिम उपाय होना चाहिए)। वास्तव में मुझे लगता है कि यह आपके शिक्षक से बुरी सलाह है क्योंकि std का उपयोग "cout" और "std :: cout" दोनों के लिए काम करेगा, लेकिन std का उपयोग न केवल "std :: cout" के लिए काम करेगा। आप अपने सभी कोड लिखने के लिए हमेशा भाग्यशाली नहीं होंगे।

नोट: जब तक आप वास्तव में कंपेलरों के काम के बारे में कुछ नहीं सीखते हैं, तब तक दक्षता के मुद्दों पर अधिक ध्यान केंद्रित न करें। थोड़ा सा अनुभव कोडिंग के साथ आपको यह समझने से पहले उन्हें इतना कुछ नहीं सीखना पड़ेगा कि वे कुछ आसान चीज़ों में अच्छे कोड को सामान्य करने में कितने सक्षम हैं। जितना सरल होगा उतना आसान है जैसे आपने सी में पूरी चीज लिखी है। अच्छा कोड उतना ही जटिल है जितना इसे होना चाहिए।

मैं यहां दूसरों से सहमत हूं, लेकिन पठनीयता के बारे में चिंताओं को दूर करना चाहता हूं - आप बस अपनी फ़ाइल, फ़ंक्शन या कक्षा घोषणा के शीर्ष पर टाइपपीफ का उपयोग करके उन सभी से बच सकते हैं।

मैं आमतौर पर इसे अपनी कक्षा घोषणा में उपयोग करता हूं क्योंकि एक वर्ग में विधियों को समान डेटा प्रकारों (सदस्यों) से निपटने के लिए प्रवृत्त किया जाता है और एक टाइपपीफ एक ऐसा नाम असाइन करने का अवसर होता है जो कक्षा के संदर्भ में सार्थक है। यह वास्तव में कक्षा विधियों की परिभाषाओं में पठनीयता की सहायता करता है।

//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;
}

मैं ग्रेग ने लिखा सबकुछ से सहमत हूं, लेकिन मैं जोड़ना चाहता हूं: ग्रेग की तुलना में यह भी बदतर हो सकता है!

लाइब्रेरी फू 2.0 एक फ़ंक्शन, Quux() पेश कर सकता है, जो आपके कुछ कॉल के लिए Quux() को bar::Quux() आपके कोड को वर्षों से बुलाया गया है। फिर आपका कोड अभी भी संकलित करता है , लेकिन यह चुपचाप गलत कार्य कहता है और क्या भगवान जानता है-क्या। यह उतना ही बुरा है जितना चीजें मिल सकती हैं।

ध्यान रखें कि std नेमस्पेस में कई पहचानकर्ता हैं, जिनमें से कई बहुत आम हैं (सोच list , sort , string , iterator इत्यादि) जो अन्य कोड में भी दिखाई देने की संभावना है।

यदि आप इस संभावना पर विचार करते हैं: स्टैक ओवरफ़्लो पर यहां एक प्रश्न पूछा गया था, जहां मैंने यह उत्तर दिया था, तो यह वास्तव में बहुत कुछ हुआ (छोड़ा गया std:: उपसर्ग के कारण गलत फ़ंक्शन)। इस तरह के एक प्रश्न का एक और, हालिया उदाहरण Here है। तो यह एक असली समस्या है।

यहां एक और डेटा बिंदु है: कई साल पहले, मैंने मानक पुस्तकालय से std:: साथ सब कुछ उपसर्ग करने के लिए परेशान किया था। फिर मैंने एक परियोजना में काम किया जहां शुरुआत में फैसला किया गया कि दोनों कार्यक्षेत्रों को छोड़कर निर्देशों और घोषणाओं using प्रतिबंधित कर दिया गया है। अंदाज़ा लगाओ? उपसर्ग लिखने के लिए हमें बहुत कम सप्ताह लग गए, और कुछ और हफ्तों के बाद हम में से अधिकांश ने भी इस बात पर सहमति व्यक्त की कि वास्तव में यह कोड अधिक पठनीय बना दिया गया है। इसके लिए एक कारण है: चाहे आप छोटे या लंबे गद्य पसंद करते हैं, लेकिन उपसर्ग वस्तु को स्पष्ट रूप से कोड में स्पष्टता जोड़ते हैं। न केवल कंपाइलर, बल्कि आपको यह भी देखना आसान लगता है कि कौन सा पहचानकर्ता संदर्भित है।

एक दशक में, उस परियोजना में कोड की कई मिलियन लाइनें बढ़ीं। चूंकि ये चर्चाएं बार-बार आती हैं, मैं एक बार उत्सुक था कि परियोजना में वास्तव में उपयोग किए जाने वाले (अनुमत) फ़ंक्शन-स्कोप using कितना बार किया जाता था। मैंने इसके लिए स्रोतों को grep'd और केवल एक या दो दर्जन स्थानों पाया जहां इसका इस्तेमाल किया गया था। मेरे लिए यह इंगित करता है कि, एक बार कोशिश की जाने के बाद, डेवलपर्स को प्रत्येक 100 केएलओसी के एक बार भी इस्तेमाल होने की अनुमति देने के दौरान निर्देशों का उपयोग करके नियोजित करने के लिए पर्याप्त दर्दनाक नहीं लगता है।

निचली पंक्ति: स्पष्ट रूप से सब कुछ उपसर्ग करने से कोई नुकसान नहीं होता है, इसका उपयोग बहुत कम होता है, और इसका उद्देश्य लाभ होता है। विशेष रूप से, यह संकलक और मानव पाठकों द्वारा कोड को समझना आसान बनाता है - और कोड लिखते समय यह मुख्य लक्ष्य होना चाहिए।

किसी को वैश्विक दायरे पर विशेष रूप से शीर्षकों में निर्देश का उपयोग नहीं करना चाहिए। हालांकि ऐसी स्थितियां हैं जहां हेडर फ़ाइल में भी उचित है:

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 ...) से बेहतर है क्योंकि यह छोटा है और इसमें उपयोगकर्ता परिभाषित फ़्लोटिंग पॉइंट प्रकारों (तर्क आश्रित लुकअप के माध्यम से) के साथ काम करने की क्षमता है।

मेरे अनुभवों से, यदि आपके पास कई पुस्तकालय हैं जो कहते हैं cout, लेकिन एक अलग उद्देश्य के लिए आप गलत का उपयोग कर सकते हैं cout।

उदाहरण के लिए, यदि मैं टाइप करता हूं, using namespace std;और using namespace otherlib;टाइप std::cout(या 'otherlib::cout') के बजाय केवल cout (जो दोनों में होता है) टाइप करता है , तो आप गलत का उपयोग कर सकते हैं और त्रुटियां प्राप्त कर सकते हैं, यह उपयोग करने के लिए और अधिक प्रभावी और कुशल है std::cout।

आपकी कक्षाओं की शीर्षलेख फ़ाइलों में using namespace समस्या यह है कि यह उन सभी को मजबूर करता है जो आपकी कक्षाओं (अपनी शीर्षलेख फ़ाइलों को शामिल करके) का उपयोग करना चाहते हैं ताकि वे 'अन्य' नामों को भी 'उपयोग' (यानी सबकुछ देख सकें)।

हालांकि, आप अपने (निजी) * .cpp फ़ाइलों में एक उपयोग कथन डालने के लिए स्वतंत्र महसूस कर सकते हैं।

सावधान रहें कि कुछ लोग मेरी कहानियों से असहमत हैं "इस तरह मुक्त" - क्योंकि हालांकि एक सीपीपी फ़ाइल में एक उपयोग कथन एक शीर्षलेख से बेहतर है (क्योंकि यह उन लोगों को प्रभावित नहीं करता है जो आपकी हेडर फ़ाइल शामिल करते हैं), उन्हें लगता है कि यह अभी भी है अच्छा नहीं है (क्योंकि कोड के आधार पर यह कक्षा के कार्यान्वयन को और अधिक कठिन बना सकता है)। यह एफएक्यू विषय कहता है,

उपयोगिता निर्देश विरासत सी ++ कोड के लिए मौजूद है और नामस्थानों में संक्रमण को कम करने के लिए है, लेकिन संभवतः आप इसे नियमित रूप से अपने नए सी ++ कोड में नहीं उपयोग करना चाहिए।

एफएक्यू दो विकल्पों का सुझाव देता है:

• एक उपयोग-घोषणा:

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

• बस टाइपिंग std ::

  std::cout << "Values:";
  

कोड देखना अच्छा लगता है और पता है कि यह क्या करता है। अगर मैं std::cout देखता हूं तो मुझे पता है कि यह std लाइब्रेरी का cout स्ट्रीम है। अगर मैं cout देखता हूं तो मुझे नहीं पता। यह std पुस्तकालय की cout धारा हो सकती है। या एक int cout = 0; हो सकता है int cout = 0; एक ही समारोह में दस लाइनें अधिक होती हैं। या उस फ़ाइल में cout नामक एक static चर। यह कुछ भी हो सकता है।

अब एक लाख लाइन कोड बेस लें, जो विशेष रूप से बड़ा नहीं है, और आप एक बग खोज रहे हैं, जिसका अर्थ है कि आप जानते हैं कि इस दस लाख लाइनों में एक पंक्ति है जो ऐसा नहीं करती है जो ऐसा करने के लिए किया जाता है। cout << 1; एक static int नामक cout पढ़ सकता है, इसे बाईं ओर एक तरफ स्थानांतरित कर सकता है, और परिणाम निकाल सकता है। एक बग की तलाश में, मुझे यह जांचना होगा। क्या आप देख सकते हैं कि मैं वास्तव में std::cout को देखना पसंद करता हूं?

यह उन चीजों में से एक है जो वास्तव में एक अच्छा विचार प्रतीत होता है यदि आप एक शिक्षक हैं और कभी भी जीवित रहने के लिए किसी भी कोड को लिखना और बनाए रखना नहीं था। मुझे कोड देखने से प्यार है (1) मुझे पता है कि यह क्या करता है; और, (2) मुझे विश्वास है कि इसे लिखने वाला व्यक्ति जानता था कि यह क्या करता है।

मैं मानता हूं कि इसे वैश्विक रूप से उपयोग नहीं किया जाना चाहिए, लेकिन namespace में स्थानीय रूप से उपयोग करना इतना बुरा नहीं है। "सी ++ प्रोग्रामिंग भाषा" से एक उदाहरण यहां दिया गया है:

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 उपयोग करके घोषित नामों सहित घोषित किया गया His_lib::String ) एक प्रयोग-निर्देश ( using namespace Her_lib ) द्वारा किसी अन्य दायरे में सुलभ किए गए नामों पर प्राथमिकता लेते हैं।

मैं इसे एक बुरा अभ्यास भी मानता हूं। क्यूं कर? सिर्फ एक दिन मैंने सोचा कि नामस्थान का कार्य सामान को विभाजित करना है, इसलिए मुझे इसे सब कुछ एक वैश्विक बैग में फेंकने से खराब नहीं करना चाहिए। हालांकि, अगर मैं अक्सर 'cout' और 'cin' using std::cout; using std::cin; हूं, तो मैं लिखता हूं: using std::cout; using std::cin; using std::cout; using std::cin; सीपीपी फ़ाइल में (कभी भी हेडर फ़ाइल में नहीं है क्योंकि यह #include अंतर्निहित के साथ प्रचारित करता है)। मुझे लगता है कि कोई भी cin कभी भी धारावाहिक या cin का नाम नहीं रखेगा। ;)

नेमस्पेस std का उपयोग कर "क्यों है"; सी ++ में एक बुरा अभ्यास माना जाता है? "

मैंने इसे दूसरी तरफ रखा: 5 अतिरिक्त वर्ण टाइप क्यों कर रहे हैं कुछ लोगों द्वारा बोझिल माना जाता है?

उदाहरण के लिए संख्यात्मक सॉफ़्टवेयर का एक टुकड़ा लिखना, मैं सामान्य "std :: vector" को "वेक्टर" तक काटकर अपने वैश्विक नेमस्पेस को प्रदूषित करने पर विचार क्यों करूं जब "वेक्टर" डोमेन की सबसे महत्वपूर्ण अवधारणाओं में से एक है?

अयोग्य आयातित पहचानकर्ताओं के साथ आपको पहचानकर्ताओं को घोषित करने के लिए grep जैसे बाहरी खोज टूल की आवश्यकता होती है । यह प्रोग्राम शुद्धता के बारे में तर्क कठिन बनाता है।

मैंने हाल ही में Visual Studio 2010 बारे में शिकायत में भाग लिया। यह पता चला कि सभी स्रोत फ़ाइलों में बहुत अधिक इन दो पंक्तियां थीं:

using namespace std;
using namespace boost;

बहुत सारे Boost फीचर्स सी ++ 0 एक्स मानक में जा रहे हैं, और विजुअल स्टूडियो 2010 में बहुत सी सी ++ 0 एक्स फीचर्स हैं, इसलिए अचानक ये प्रोग्राम संकलित नहीं हो रहे थे।

इसलिए, using namespace X; से परहेज using namespace X; भविष्य के प्रूफिंग का एक रूप है, यह सुनिश्चित करने का एक तरीका है कि लाइब्रेरी में परिवर्तन और / या हेडर फाइलें किसी प्रोग्राम को तोड़ने वाली नहीं हैं।

वैश्विक स्तर पर इसका इस्तेमाल न करें

इसे वैश्विक रूप से उपयोग किए जाने पर ही "बुरा" माना जाता है । इसलिये:

• आप उस नेमस्पेस को अव्यवस्थित करते हैं जिसमें आप प्रोग्रामिंग कर रहे हैं।
• जब आप using namespace xyz कई using namespace xyz उपयोग करते हैं, तो पाठकों को यह देखने में कठिनाई होगी कि एक विशेष पहचानकर्ता कहां से आता है।
• आपके स्रोत कोड के अन्य पाठकों के लिए जो कुछ भी सच है, वह इसके सबसे अधिक पाठक के लिए और भी सत्य है: स्वयं। एक या दो साल में वापस आओ और देखो ...
• यदि आप केवल using namespace std करने के बारे में बात करते हैं तो हो सकता है कि आप जो भी सामान लेते हैं, उसके बारे में आपको अवगत न हो - और जब आप कोई अन्य #include या एक नए सी ++ संशोधन में जाते हैं तो आपको नाम विवाद मिल सकते हैं जिनके बारे में आपको पता नहीं था।

आप इसे स्थानीय रूप से उपयोग कर सकते हैं

आगे बढ़ें और इसे स्थानीय रूप से (लगभग) स्वतंत्र रूप से उपयोग करें। यह, ज़ाहिर है, आपको std:: की पुनरावृत्ति से रोकता है - और पुनरावृत्ति भी खराब है।

इसे स्थानीय रूप से उपयोग करने के लिए एक मुहावरे

सी ++ 03 में एक मुहावरे - बॉयलरप्लेट कोड था - आपके वर्गों के लिए एक swap फ़ंक्शन लागू करने के लिए। यह सुझाव दिया गया था कि आप वास्तव में using namespace std स्थानीय 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(...)`
}

यह निम्नलिखित जादू करता है:

• संकलक value_ लिए std::swap चयन करेगा, यानी void std::swap(int, int) ।
• यदि आपके पास एक अधिभार void swap(Child&, Child&) लागू किया गया है तो संकलक इसे चुन देगा।
• यदि आपके पास उस ओवरलोड को नहीं है तो कंपाइलर void std::swap(Child&,Child&) और इन्हें सबसे अच्छा स्वैप करने का प्रयास करेगा।

सी ++ 11 के साथ इस पैटर्न का उपयोग करने का कोई कारण नहीं है। एक संभावित अधिभार खोजने और इसे चुनने के लिए std::swap का कार्यान्वयन बदल दिया गया था।