Pytanie Dlaczego "używanie przestrzeni nazw standardowej" jest uważane za złą praktykę?


Inni mówili mi, że pisanie using namespace std w kodzie jest źle i że powinienem użyć std::cout i std::cin bezpośrednio zamiast tego.

Dlaczego jest using namespace std uważane za złą praktykę? Czy jest on nieskuteczny, czy też ryzykuje deklarowaniem zmiennych niejednoznacznych (zmiennych, które mają taką samą nazwę jak funkcja w std przestrzeń nazw)? Czy wpływa to na wydajność?


2069
2017-09-21 03:08


pochodzenie


Nie zapominaj, że możesz zrobić: "using std :: cout;" co oznacza, że ​​nie musisz wpisywać std :: cout, ale nie wprowadzaj całego obszaru nazw std w tym samym czasie. - Bill
@ płatny frajer google-styleguide.googlecode.com/svn/trunk/... link już nie działa. Wygląda na to, że jest nowy link google.github.io/styleguide/cppguide.html#Other_C++_Elementy - MCG
Szczególnie niekorzystnie jest używać 'using namespace std' w zakresie plików w plikach nagłówkowych. Używanie go w plikach źródłowych (* .cpp) w zakresie plików po uwzględnieniu wszystkich elementów nie jest tak złe, ponieważ jego działanie ogranicza się do pojedynczej jednostki tłumaczeniowej. Jeszcze mniej problematyczne jest używanie go wewnątrz funkcji lub klas, ponieważ jego działanie ogranicza się do funkcji lub zakresu klasy. - sh-
Odradzałbym używać dyrektywy, ale dla określonych przestrzeni nazw std::literals::chrono_literals, Poco::Data:Keywords,Poco::Units i rzeczy, które zajmą się literałami lub sztuczkami czytelności. Ilekroć znajduje się w plikach nagłówkowych lub implementacyjnych. Może to być w porządku w zakresie funkcji, ale oprócz literałów i innych rzeczy, nie jest użyteczne. - Ludovic Zenohate Lagouardette
@Jon: To nie ma nic wspólnego ze std przestrzeni nazw. Mój nacisk został położony na "w zasięgu pliku w plikach nagłówkowych". Aby ująć to jako poradę: Nie używaj "using namespace" (std lub innego) w zasięgu pliku w plikach nagłówkowych. Można go używać w plikach implementacyjnych. Przepraszam za niejednoznaczność. - sh-


Odpowiedzi:


W ogóle nie ma to związku z wydajnością. Ale rozważ to: używasz dwóch bibliotek o nazwach Foo i Bar:

using namespace foo;
using namespace bar;

Wszystko działa dobrze, możesz zadzwonić Blah() od Foo i Quux() z Baru bez problemów. Ale pewnego dnia można uaktualnić do nowej wersji Foo 2.0, która oferuje teraz funkcję o nazwie Quux(). Teraz masz konflikt: zarówno import Foo 2.0, jak i pasek Quux() do twojej globalnej przestrzeni nazw. To zajmie trochę wysiłku, aby naprawić, zwłaszcza jeśli parametry funkcji się zgadzają.

Jeśli używałeś foo::Blah() i bar::Quux(), następnie wprowadzenie foo::Quux() nie byłby żadnym wydarzeniem.


1751
2017-09-21 03:13



Zawsze lubiłem Pythona "importować big_honkin_name jako bhn", więc możesz po prostu użyć "bhn.something" zamiast "big_honkin_name.something" - naprawdę ogranicza pisanie. Czy C ++ ma coś takiego? - paxdiablo
@Pax namespace io = boost :: system plików; - AraK
Myślę, że to przesadne stwierdzenie, że to "jakiś wysiłek, by naprawić". Nie będziesz miał żadnych instancji nowego foo :: Quux, więc po prostu rozróżnij wszystkie obecne zastosowania z prętem :: Quux. - MattyT
Czy którakolwiek rozsądna osoba stworzy bibliotekę z typami, których niekwalifikowana nazwa koliduje z typami standardowymi? - erikkallen
@TomA: Problem z #define jest to, że nie ogranicza się on do przestrzeni nazw, ale depcze całą bazę kodu. Alias ​​przestrzeni nazw jest tym, czego potrzebujesz. - sbi


Zgadzam się ze wszystkim Greg napisał, ale chciałbym dodać: Może nawet gorzej, niż powiedział Greg!

Biblioteka Foo 2.0 może wprowadzić funkcję, Quux()to jednoznacznie lepiej pasuje do niektórych połączeń Quux() niż bar::Quux() twój kod dzwonił przez lata. Potem twoja kod nadal się kompiluje, ale po cichu wywołuje niewłaściwą funkcję i czy Bóg-wie-co. Jest tak źle, jak to się może stać.

Należy pamiętać, że std przestrzeń nazw ma mnóstwo identyfikatorów, z których wiele jest bardzo wspólne (myślę list, sort, string, iteratoritp.), które z dużym prawdopodobieństwem pojawią się także w innym kodzie.

Jeśli uważasz to za mało prawdopodobne: Nie było pytanie zadawane tutaj na Stack Overflow, gdzie prawie dokładnie się to stało (niewłaściwa funkcja wywołana z powodu pominięcia std:: przedrostek) około pół roku po tym, jak podałem tę odpowiedź. Tutaj jest kolejnym, bardziej aktualnym przykładem takiego pytania. To prawdziwy problem.


Oto jeszcze jeden punkt danych: wiele, wiele lat temu również uważałem za irytujące, gdy trzeba było poprzedzać wszystko ze standardowej biblioteki std::. Potem pracowałem w projekcie, w którym na początku zdecydowano, że oba using dyrektywy i deklaracje są zakazane, z wyjątkiem zakresów funkcji. Zgadnij co? Większość z nas zajęło nam bardzo niewiele tygodni, aby przyzwyczaić się do pisania prefiksu, a po kilku tygodniach większość z nas zgodziła się nawet, że to on zrobił kod bardziej czytelny. Jest ku temu powód: Czy podoba ci się krótsza, czy dłuższa proza, jest subiektywna, ale przedrostki obiektywnie dodają klarowności do kodu. Nie tylko kompilator, ale i Ty, łatwiej jest zauważyć, do którego identyfikatora się odwołuje.

W ciągu dekady projekt ten miał kilka milionów linii kodu. Ponieważ te dyskusje powtarzają się raz za razem, kiedyś ciekawiło mnie, jak często (dozwolony) zakres funkcji usingfaktycznie został użyty w projekcie. Poszukałem źródeł i znalazłem tylko jedno lub dwa tuziny miejsc, w których go użyto. Według mnie oznacza to, że po wypróbowaniu programiści nie znajdują std:: wystarczająco bolesne, by stosować dyrektywy nawet raz na 100 kLoC, nawet jeśli pozwolono na użycie.


Konkluzja: Jednoznacznie prefiksowanie wszystkiego nie szkodzi, niewiele się przyzwyczaja i ma obiektywne zalety. W szczególności sprawia, że ​​kod jest łatwiejszy do interpretacji przez kompilator i przez ludzi - a to powinno być głównym celem przy pisaniu kodu.


1152
2017-09-21 09:26



Ma to znaczący wpływ na gęstość kodu, który można spakować w jednej linii. W końcu piszesz swój kod bardzo długo; co zmniejsza czytelność. Osobiście uważam, że krótszy (ale niezbyt krótki) kod wydaje się być bardziej czytelny (ponieważ jest mniej rzeczy do czytania i mniej rzeczy, którymi można się rozproszyć). - Lie Ryan
Zgadnij, że straciłeś dawne czasy, zanim C ++ miał standard string klasa, i na pozór każda biblioteka miała swoją. Powiem ci coś: będziemy pisać dalej nasz kod std::i możesz uruchomić nasz kod grep -v std:: | vim podczas przeglądania. Możesz też nauczyć swojego edytora std:: to słowo kluczowe, które ma być kolorowe tak samo jak kolor tła. Cokolwiek działa. - Mike DeSimone
Nie sądzę std:: jest w ogóle szkodliwy. Niesie bardzo ważne informacje (a mianowicie "cokolwiek przychodzi później jest częścią standardowej biblioteki") i wciąż jest dość krótkim i zwartym prefiksem, najczęściej nie ma problemu, czasami masz kilka linijek kodu gdzie powinieneś odnosić się do konkretnych symboli w std dużo przestrzeni nazw, a następnie using wypowiedź w tym konkretnym zakresie dobrze rozwiązuje problem. Ale w ogólnym przypadku nie jest to hałas, przekazuje cenne informacje dodatkowo do usuwania dwuznaczności. - jalf
Kiedykolwiek widzę std::, Wiem, że to będzie std:: bez konieczności myślenia o tym. Jeśli widzę string lub list lub map sami zastanawiam się trochę. - Mateen Ulhaq
@LieRyan To powodzenia w pisaniu biblioteki geometrii bez namysłu vector, transform lub distance. A to tylko przykłady wiele bardzo popularnych nazw używane w standardowej bibliotece. Sugerowanie, aby nie używać ich ze strachu lub stronniczej opinii na temat funkcji przestrzeni nazw, która jest integralną częścią C ++, jest raczej nieproduktywne. - Christian Rau


Myślę, że źle jest umieścić go w plikach nagłówkowych twoich klas: ponieważ wtedy zmuszasz każdego, kto chce używać twoich klas (włączając w to pliki nagłówkowe), aby był również "użyty" (tj. Widząc wszystko w) w tych innych obszarach nazw. .

Możesz jednak umieścić instrukcję using w swoich (prywatnych) plikach * .cpp.


Uważaj, że niektórzy ludzie nie zgadzają się z moim powiedzeniem "czuję się swobodnie" w ten sposób - ponieważ chociaż instrukcja użycia w pliku cpp jest lepszy niż w nagłówku (ponieważ nie dotyczy osób, które zawierają twój plik nagłówkowy), uważają, że nadal nie jest dobry (ponieważ w zależności od kodu mogłoby to utrudnić implementację klasy). Ten temat FAQ mówi,

Dyrektywa using istnieje dla starszego kodu C ++ i ułatwia przejście do przestrzeni nazw, ale prawdopodobnie nie powinieneś używać go regularnie, przynajmniej nie w swoim nowym kodzie C ++.

Sugeruje dwie alternatywy:

  • Deklaracja użycia:

    using std::cout; // a using-declaration lets you use cout without qualification
    cout << "Values:";
    
  • Przezwycięż to i po prostu wpisz std ::

    std::cout << "Values:";
    

309
2017-09-21 03:22



Nie jest tak źle umieszczać go w pliku .cpp niż w nagłówku, ale problem pozostaje taki sam dla łatwości konserwacji. Ryzykuje, że dwie funkcje o tej samej nazwie będą się kolidować, gdy zmodyfikowany zostanie kod / biblioteka, której używasz, lub standard C ++. - Étienne
Czy próbowałeś tego w ogóle? Ponieważ dyrektywa using namespace nie przeniesie się do innego pliku. (GCC 4.8+) - zackery.fix
@ zackery.fix "propaguje wersję" Apple LLVM w wersji 7.0.2 (clang-700.1.81) using namespace std; od nagłówka do pliku źródłowego, a ja sprawdziłem, że GCC tego nie robi. Tak więc przynajmniej posiadanie dyrektywy "using" w nagłówku jest ryzykowne. - Franklin Yu
Tak, nie używam LLVM lub klang i to nie jest standardowe podejście. - zackery.fix
Naprawdę nie powinieneś mówić ludziom, aby "czuli się swobodnie" przy użyciu std przestrzeni nazw w pliku .cpp. @ Étienne ma rację. - einpoklum


Niedawno złożyłem skargę na temat Visual Studio 2010. Okazało się, że prawie wszystkie pliki źródłowe mają te dwie linie:

using namespace std;
using namespace boost;

Dużo Podnieść funkcje przechodzą do standardu C ++ 0x, a Visual Studio 2010 ma wiele funkcji C ++ 0x, więc nagle te programy nie kompilowały się.

Dlatego unikaj using namespace X; jest formą zabezpieczenia na przyszłość, sposobem upewnienia się, że zmiana w bibliotekach i / lub plikach nagłówkowych w użyciu nie złamie programu.


197
2017-10-28 17:37



To. Zwiększ i std mają los nakładania się - zwłaszcza od C ++ 11. - einpoklum
Zrobiłem to raz i ciężko nauczyłem się lekcji. Teraz nigdy nie używam using poza definicją funkcji i rzadko jej używa using namespace w ogóle. - Ferruccio


Wersja skrócona: nie używaj globalnych deklaracji lub dyrektyw w plikach nagłówkowych. Zachęcamy do korzystania z nich w plikach implementacyjnych. Oto, o czym mają do powiedzenia Herb Sutter i Andrei Alexandrescu Standardy kodowania C ++ (pogrubienie dla podkreślenia jest moje):

Podsumowanie

Używanie przestrzeni nazw jest dla twojej wygody, a nie dla ciebie, aby wyrządzać innym: Nigdy nie pisz deklaracji użycia lub dyrektywy użycia przed dyrektywą #include.

Wniosek: w plikach nagłówkowych nie pisz poziomu przestrzeni nazw przy użyciu dyrektyw lub deklaracji; zamiast tego, jawnie przestrzeń nazw - kwalifikuj wszystkie nazwy. (Druga reguła wynika z pierwszej, ponieważ nagłówki nigdy nie wiedzą, jakie inne nagłówki #include mogą pojawić się po nich.)

Dyskusja

W skrócie: możesz i powinieneś używać przestrzeni nazw używając deklaracji i dyrektyw w plikach implementacyjnych po dyrektywach #include i dobrze się z tym czuć. Pomimo powtarzających się twierdzeń przeciwnych, przestrzeń nazw za pomocą deklaracji i dyrektyw nie jest zła i nie pokonują one celu przestrzeni nazw. Są raczej tym, co sprawia, że ​​przestrzenie nazw są użyteczne.


159
2017-11-03 20:00



Smutne, że to rozsądne przewodnictwo jest tak pochowane pod fałszywymi odpowiedziami. - nyholku
Jeszcze tylko jedna opinia programisty, ale chociaż zgadzam się w 100% ze stwierdzeniem, że to słowo using nigdy nie powinien pojawić się w nagłówku, nie jestem przekonany co do darmowej licencji do umieszczenia using namespace xyz; w dowolnym miejscu w kodzie, zwłaszcza jeśli xyz jest std. używam using std::vector; formularz, ponieważ tylko ciągnie pojedynczy element z przestrzeni nazw do pseudo globalnego zakresu, co prowadzi do znacznie mniejszego ryzyka kolizji. - dgnuff
@Lightness Races in Orbit masz oczywiście prawo do swojej opinii. Byłoby bardziej pomocne, gdyby wystąpiła jakaś próba wyjaśnienia, dlaczego nie zgadzasz się z poradą udzieloną w tej odpowiedzi. Szczególnie interesujące byłoby zrozumienie, o co chodzi w przestrzeni nazw, jeśli "używanie" ich jest złe? Czemu nie nazwać rzeczy std_cout zamiast std :: cout ... twórcy C ++ / namespace musieli mieć jakiś pomysł, kiedy próbowali je utworzyć. - nyholku
@nyholku: Nie ma potrzeby - większość pozostałych odpowiedzi daje te same powody, które chciałbym. Proszę również nie wahaj się zwrócić uwagę na ":)" dołączam do mojego komentarza! I nie powiedziałem, że przestrzenie nazw są złe. - Lightness Races in Orbit
Tak, zauważyłem, że :) ale IMO większość odpowiedzi (które są sprzeczne z tą radą mędrca) są błędne (nie żebym zrobił statystyki, co jest teraz większością). Jeśli zgadzasz się, że przestrzeń nazw jest "niezła", to możesz powiedzieć, gdzie myślisz, że są odpowiednie, jeśli nie zgadzasz się z tą odpowiedzią? - nyholku


Nie należy używać dyrektywy w zasięgu globalnym, szczególnie w nagłówkach. Istnieją jednak sytuacje, w których jest to właściwe nawet w pliku nagłówkowym:

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

To jest lepsze niż wyraźna kwalifikacja (std::sin, std::cos...) ponieważ jest krótszy i ma możliwość pracy z typami zmiennoprzecinkowymi zdefiniowanymi przez użytkownika (poprzez Argument Dependent Lookup).


103
2017-09-21 15:47



Przykro mi, ale zdecydowanie się z tym nie zgadzam. - Billy ONeal
@Billy: Nie ma innego sposobu na wsparcie wywoływania userlib :: cos (userlib :: superint). Każda funkcja ma zastosowanie. - Zan Lynx
@Zan: Oczywiście, że istnieje. using std::cos; , using std::sin, itp. Problem polega jednak na tym, że każdy dobrze zaprojektowany userlib będzie ich mieć sin i cos wewnątrz ich własnej przestrzeni nazw, więc to naprawdę nie pomaga. (Chyba że jest using namespace userlib przed tym szablonem i to jest tak samo złe jak using namespace std - i zakres nie jest ograniczony.) Ponadto jedyną taką funkcją, jaką widzę, jest to, że tak się dzieje swap, aw takich przypadkach polecam właśnie tworzenie szablonowej specjalizacji std::swap i unikanie całego problemu. - Billy ONeal
@BillyONeal: template<typename T> void swap(MyContainer<T>&, MyContainer<T>&) (Nie ma częściowej specjalizacji z szablonem funkcji (FTPS), więc czasami trzeba uciekać się do przeciążania. - sbi
@BillyONeal: Twój (7-krotnie przegłosowany!) Komentarz jest błędny - sytuacja, którą opisujesz dokładnie co ADL został zaprojektowany, aby pokryć. Krótko mówiąc, jeśli x ma jedną lub więcej "powiązanych przestrzeni nazw" (np. jeśli została zdefiniowana w namespace userlib) następnie wszelkie wywołanie funkcji, które wygląda cos(x) będzie do tego spójrz w te przestrzenie nazw - bez każdy using namespace userlib; wcześniej konieczne. Zan Lynx ma rację (a wyszukiwanie nazwy C ++ to bizantyjski ...) - j_random_hacker


Nie używaj go globalnie

Jest uważany za "zły" tylko wtedy, gdy używane globalnie. Bo:

  • Zajmiesz przestrzeń nazw, w której programujesz.
  • Czytelnicy będą mieć trudności ze sprawdzeniem, skąd pochodzi konkretny identyfikator, gdy korzystasz z wielu using namespace xyz.
  • Cokolwiek jest prawdą inny Czytelnicy twojego kodu źródłowego są jeszcze bardziej wiarygodni dla najczęstszych czytelników tego: siebie. Przyjdź za rok lub dwa i przyjrzyj się ...
  • Jeśli tylko mówisz using namespace std możesz nie być świadomy wszystkich rzeczy, które złapiesz - i kiedy dodasz inny #include lub przejdź do nowej wersji C ++, możesz uzyskać konflikty nazw, o których nie wiedziałeś.

Możesz go używać lokalnie

Śmiało i używaj go lokalnie (prawie) swobodnie. To, oczywiście, uniemożliwia powtórzenie std:: - i powtórzenie jest również złe.

Idiom do używania go lokalnie

W C ++ 03 istniał idiom - kod podstawowy - do implementacji a swap funkcja dla twoich zajęć. Zasugerowano, że faktycznie używasz lokalnego using namespace std -- Lub przynajmniej 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(...)`
}

Oto magia:

  • Kompilator wybierze opcję std::swap dla value_, tj. void std::swap(int, int).
  • Jeśli masz przeciążenie void swap(Child&, Child&) wdrożony kompilator wybierze go.
  • Jeśli zrobisz nie mieć to przeciążenie, którego użyje kompilator void std::swap(Child&,Child&) i spróbuj jak najlepiej je zamieniać.

W C ++ 11 nie ma już powodu, aby używać tego wzorca. Implementacja std::swap został zmieniony, aby znaleźć potencjalny przeciążenie i wybrać go.


80
2018-01-18 09:34



"Implementacja std :: swap została zmieniona, aby znaleźć potencjalne przeciążenie i wybrać ją." - Co? Czy jesteś tego pewien? Chociaż prawdą jest, że zapewniamy zwyczaj swap na pierwszym miejscu nie jest już tak ważne w C ++ 11, ponieważ std::swap sam jest bardziej elastyczny (używa semantyki ruchu). Ale std::swap automatyczne wybieranie własnej niestandardowej wymiany, która jest dla mnie całkowicie nowa (i naprawdę nie wierzę w to). - Christian Rau
@ Chrześcijanin Rau Myślę, że tak, tak. Czytam to gdzieś na SO. Zawsze możemy zapytać Howardpowinien wiedzieć. jestem kopanie i kopanie teraz... - towi
Nawet w przypadku wymiany, wyraźniejszy (i na szczęście bardziej powszechny) idiom jest pisanie using std::swap;zamiast using namespace std;. Im bardziej specyficzny idiom ma mniej skutków ubocznych, a tym samym czyni kod łatwiejszym w utrzymaniu. - Adrian McCarthy
Ostatnie zdanie jest błędne. W C ++ 11 Std Swap Two Step został oficjalnie pobłogosławiony jako dobrze sposób zadzwonić swap, i różne inne miejsca w standardzie zostały zmienione, aby powiedzieć, że dzwonią swap w ten sposób (N.B. jak podano powyżej, using std::swap to właściwa droga, nie using namespace std). Ale std::swap sam był zdecydowanie nie zmieniono, aby znaleźć inne swap i użyj go. Gdyby std::swap zostaje wezwany std::swap zostaje wykorzystany. - Jonathan Wakely
Mądrzej byłoby po prostu pisać using std::swap jednak lokalnie, aby zmniejszyć lokalny obszar nazw, jednocześnie tworząc własny kod do dokumentowania. Rzadko interesuje Cię cały obszar nazw standardowych, więc po prostu wybierz części, które Cię interesują. - Lundin


Jeśli zaimportujesz właściwe pliki nagłówkowe, nagle otrzymasz nazwy podobne do hex, left, plus lub count w twoim globalnym zasięgu. Może to być zaskakujące, jeśli nie jesteś tego świadomy std:: zawiera te imiona. Jeśli spróbujesz również użyć tych nazw lokalnie, może to doprowadzić do pewnego zamieszania.

Jeśli wszystkie standardowe pliki znajdują się we własnej przestrzeni nazw, nie musisz się martwić kolizjami nazw z kodem lub innymi bibliotekami.


71
2017-09-21 03:23



+1 nie wspominając distance. nadal wolę nazwy niekwalifikowane, o ile jest to praktycznie możliwe, ponieważ zwiększa to dla mnie czytelność. plus, myślę, że fakt, że zazwyczaj nie kwalifikujemy się do mówienia ustnego i jesteśmy gotowi poświęcić czas na rozwiązywanie ewentualnych niejasności, oznacza, że ​​ma wartość, aby móc zrozumieć, o czym mówi się bez kwalifikacji i zastosować do źródła kod oznacza to, że jest skonstruowany w taki sposób, że jasne jest, o co w tym wszystkim chodzi, nawet bez kwalifikacji. - Cheers and hth. - Alf
Prawdę mówiąc, nie masz większości z nich, jeśli ich nie uwzględniasz <iomanip>. Wciąż, dobra uwaga. - einpoklum


Zgadzam się, że nie powinno się używać go globalnie, ale nie jest tak źle używać lokalnie, jak w namespace. Oto przykład z "Język programowania 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

}

W tym przykładzie rozwiązaliśmy potencjalne konflikty nazw i niejednoznaczności wynikające z ich kompozycji.

Nazwy jawnie tam zadeklarowane (w tym nazwy zadeklarowane przez użycie takich deklaracji jak His_lib::String) mają pierwszeństwo przed nazwami udostępnionymi w innym zakresie za pomocą dyrektywy użytkowej (using namespace Her_lib).


34
2017-08-29 09:44





Doświadczeni programiści wykorzystują cokolwiek, co rozwiązuje ich problemy i unikają wszelkich nowych problemów, i unikają stosowania dyrektyw-nagłówków z tego właśnie powodu.

Doświadczeni programiści starają się również unikać pełnej kwalifikacji nazw w swoich plikach źródłowych. Niewielkim powodem jest to, że nie jest elegancko pisać więcej kodu, gdy mniej kodu jest wystarczające chyba że istnieją uzasadnione powody. Głównym tego powodem jest wyłączenie wyszukiwania zależnego od argumentów (ADL).

Co to jest dobre powody? Czasami programiści wyraźnie chcą wyłączyć ADL, innym razem chcą się ujednoznacznić.

Tak więc są OK:

  1. Dyrektywy użycia funkcji i deklaracje użycia wewnątrz implementacji funkcji
  2. Stosowanie deklaracji źródłowych na poziomie pliku wewnątrz plików źródłowych
  3. (Czasami) dyrektywy użycia dla plików źródłowych

34
2018-03-29 08:10



Zdefiniuj "elegancję". - sbi