Domykanie klas i metod

W teorii dziedziczenie to niezbyt skomplikowana relacja między klasami, ale w praktyce potrzeba czasem niestandardowych rozwiązań. Niekiedy bowiem możliwość rozszerzenia hierarchii klas w nieskończoność nie jest wcale pożądana. Zazwyczaj chodzi tu o względy projektowe, rzadziej o efektywność.
Pytanie brzmi: czy można jakoś zabezpieczyć konkretną klasę przed dziedziczeniem (czyli zabronić w tworzenia opartych o nią klas pochodnych)?

W C# i Javie jest to możliwe za pomocą specjalnych słów kluczowych – odpowiednio sealed (‘zapieczętowany’) i final. Wystarczy opatrzyć nimi definicję klasy, by kompilator odmówił skompilowania kodu, który wykorzystywałby taką klasę jako bazową:

Modyfikatory sealed/final można też stosować do metod wirtualnych. W tym przypadku sprawiają one, że dana metoda wirtualna nie może być nadpisywana w klasach pochodnych. Chwilowo nie przychodzi mi do głowy żaden pomysł na pokazanie przydatności takiego triku, ale zapewne takowy przykład istnieje :)

W C++ nie mamy rzecz jasna wspomnianych słów kluczowych (ani żadnych, które działałyby podobnie), ale istnieje sposób na zabezpieczenie klasy przed dziedziczeniem. Jest on jednak brzydki. A nawet bardzo brzydki. Mimo to zaprezentuję go.
Jak to często bywa w takich sytuacjach, sztuczka polega na kreatywnym wykorzystaniu pewnego mechanizmu językowego unikalnego dla C++, który generalnie służy do czegoś zupełnie innego. Tutaj chodzi o dziedziczenie wirtualne – a dokładniej o to, że wirtualna klasa bazowa musi być bezpośrednio inicjalizowana przez każdą klasę pochodną; nawet tą w setnym pokoleniu niżej. Do tego dodać należy jeszcze prywatne konstruktory i deklarację przyjaźni, a następnie zamieszać i doprawić do smaku, by ostatecznie upichcić coś w tym stylu:

Klasa pomocnicza CFoo_Lock ma prywatny konstruktor domyślny, więc generalnie nie może być on wywoływany. W szczególności nie może być on wywołany przez konstruktor CBar – a jest to konieczne, gdyż CFoo_Lock jest wirtualną klasą bazową i musi być zainicjalizowana bezpośrednio przez dowolną klasę pochodną (nawet niebezpośrednio pochodną). Dlatego też próba dziedziczenia CFoo skończy się błędem mówiącym o braku dostępu do prywatnego konstruktora CFoo_Lock.
Dlaczego zatem CFoo działa? To już zasługa deklaracji przyjaźni umieszczonej w klasie-blokadzie. Przyjaźń międzyklasowa nie jest jednak dziedziczna, więc nasza blokada odmawia dostępu do prywatnych składowych (czyli konstruktorów) klasom pochodnym CFoo. Dzięki temu (i niuansom dziedziczenia wirtualnego) cały ten trik działa.

To rozwiązanie można naturalnie uczynić bardziej automatycznym – wystarczy zaprząc do pracy szablony i preprocesor, by uzyskać prawie to samo co sealed/final w C#/Javie. Trudno będzie jednak uznać to kombinowanie za eleganckie.
Wygląda więc na to, że najlepszym sposobem na zabezpieczenie klasy przed dziedziczeniem w C++, to po prostu… pokazać na nią palcem (tj. komentarzem) i powiedzieć “Nie dziedzicz mnie!”. No i mieć nadzieję, że ktoś nas posłucha.

Okno na pingwina

Czasami przydaje się posiadanie więcej niż jednego operacyjnego na jednym komputerze. Jeżeli oba używają tego samego systemu plików, to zwykle nie ma problemu z wymianą danych.

A co zrobić, jeżeli tak nie jest – czyli na przykład chcemy dostać się z poziomu Linuxa do plików używanych w Windows lub odwrotnie? W jedną stronę jest łatwo: większość dystrybucji Linuxa obsługuje przynajmniej odczytywanie z partycji NTFS, a niektóre automatycznie montują znalezione woluminy, które korzystają z tego systemu plików.
Jeżeli zaś chodzi o operację odwrotną, to naturalne Windows nie patrzy tak przychylnie na inny system operacyjny. Wbudowana w okienka obsługa różnych systemów plików nie obejmuje ext2 i ext3, czyli tych używanych w ogromnej większości Linuksów. Tutaj mogą pomóc tylko zewnętrzne narzędzia.

Jednym z nim jest Ext2 IFS. Ma on tę zaletę, że działa jak sterownik, a nie np. wtyczka do Eksploratora, Total Commandera czy innego menedżera plików. Dzięki temu podmontowane partycje linuksowe są widoczne w całym systemie.

Można z nich korzystać właściwie tak samo jak z dysków NTFS, czyli odczytywać i zapisywać pliki, katalogi, zmieniać etykiety woluminów, itp. Nie trzeba też kopiować plików tam i z powrotem, aby je modyfikować.

Sam nie używam Linuksa zbyt często, ale taki sterownik jest bardzo wygodny. Chociaż prawdopodobnie dostęp do partycji ext3 z Windows sprawia, że Linuksa uruchamiam nawet jeszcze rzadziej niż wcześniej ;)

System GUI #6 – Pole wyboru i przycisk opcji

Zwykłe przyciski (buttons) można tylko wciskać jak guziki na monitorze lub klawisze na klawiaturze. Wydawałoby się, że nie mają one wiele wspólnego z bardziej zaawansowanymi elementami interfejsu: polami wyboru (checkboxes) czy przyciskami opcji (radio buttons).
Te pierwsze to proste przełączniki: mogą być zaznaczone lub nie, swój stan zmieniają po kliknięciu i zazwyczaj odwzorowane są na jakieś funkcje programu, które mogą być włączane i wyłączane. Te drugie oferują z kolei wybór z większej liczby wariantów, z których tylko jeden może być aktywny w danej chwili. Z punktu widzenia użytkownika największa różnica polega jednak na tym, że pola wyboru mają obok etykiet tekstowych kwadraciki, zaś przyciski opcji – kółka :)

Podobieństwo tych dwóch kontrolek do zwykłych przycisków polega na tym, że w identyczny sposób reagują na zdarzenia od myszy – czyli przede wszystkim kliknięcia. Podobieństwo okazało się na tyle duże, że sensowne okazało się połączenie wszystkich tych trzech rodzajów kontrolek wspólną klasą bazową. Nie lubię nadużywania dziedziczenia, ale akurat tutaj rozciągnięcie hierarchii klas wydaje się rozsądne.

Z tych trzech typów kontrolek prawdopodobnie najbardziej interesujący jest przycisk opcji, czyli ten z kółeczkiem :) Trzeba bowiem zastanowić się, w jaki sposób zrealizować grupowanie tych obiektów w zestawy, w ramach których tylko jeden radio button może być zaznaczony. Spotkałem tutaj dwa rozwiązania:

• Wprowadzenie specjalnej kontrolki-kontenera nazywanej zwykle RadioGroup. Kontener ten może zawierać tylko przyciski opcji, które wówczas nawet nie muszą być samodzielnymi kontrolkami (ale cały czas powinny oczywiście sprawiać takie wrażenie). Taka ‘grupa radiowa’ jako pojemnik może, ale nie musi być widoczna na ekranie. Przy takim rozwiązaniu spełniony jest zawsze warunek, że spośród wszystkich przycisków opcji będących bezpośrednio zawartych w jakimkolwiek kontenerze (RadioGroup lub innym) zaznaczony jest tylko jeden.
  Ten wariant występuje na przykład w bibliotece VCL (Delphi).
• Dodanie do radio buttona właściwości określającej grupę przycisków, jak choćby jej nazwa (napis) lub indeks (liczba). Wtedy należy zapewnić, że zaznaczenie będzie unikalne w ramach przycisków z tego samego kontenera oraz z tej samej grupy.
  To rozwiązanie występuje w Windows Forms.

Ostatecznie zdecydowałem się na wariant drugi. Z punktu widzenia implementacji najważniejszego elementu – czyli dbania o to, by tylko jedna opcja była zaznaczona – oba rozwiązania są bardzo podobne. Tak czy owak trzeba zawsze najpierw odznaczyć wszystkie przyciski, a potem zaznaczyć ten kliknięty. Jest to przy tym jedna z tych sytuacji, w których bardzo ułatwia życie przeklinany operator rzutowania dynamic_cast :]

Rzut okiem na Second Life

Podobno dzisiejszy świat cierpi na ogromny deficyt prawdziwej rzeczywistości, a zdecydowany nadmiar tej wirtualnej – i to już od kilkudziesięciu lat. Tak przynajmniej twierdził zmarły kilka miesięcy temu francuski socjolog Jean Baudrillard. Co więcej, odróżnienie owej prawdziwej rzeczywistości od symulacji już dawno przestało być możliwe. Cóż, filozofowie nigdy nie byli zbytnimi optymistami :)
Osobiście nie mam na przykład najmniejszego problemu z rozdzieleniem przynajmniej jednego rodzaju wirtualnej rzeczywistości od ‘prawdziwego’ świata (cokolwiek to znaczy). A niektórzy, jak ostatnio lubią donosić media, mają z tym pewien problem…

Nietrudno się domyślić, co mam na myśli. Zgadza się, chodzi o to.. coś (chwilowo nie mam dobrego określenia) o nazwie Second Life. Usłyszeć można o tym dość często, zwłaszcza wtedy gdy jakaś mniej lub bardziej znana firma tudzież instytucja poszerza swoją działalność o obecność w tym wirtualnym świecie. W nazywaniu SL światem nie ma zresztą żadnej przesady, skoro jego twórcy podają, że obecnie gości on już ponad 9 milionów użytkowników (choć tylko półtora miliona aktywnych, tj. takich, którzy zalogowali się w ciągu ostatnich dwóch miesięcy).
Pomyślałem więc, że warto chociaż sprawdzić, co w trawie piszczy… Bezpośrednim powodem był aczkolwiek ten wątek na forum Warsztatu. Tym aspektem, który został w nim poruszony, zajmę się jednak nieco później.

Zacznijmy więc od początku. Dołączenie do społeczności Second Life nie jest trudne i przypomina tworzenie konta w każdej typowej grze MMO. Pewnym odstępstwem od standardu jest jedynie konieczność podania imienia dla swojej postaci i wyboru jednego z kilkudziesięciu dostępnych nazwisk. Potem zabieramy się oczywiście za ściąganie klienta – i tu spotkała mnie pierwsza niespodzianka.
Słyszałem oczywiście o tak zachwalanej dowolności w kreowaniu świata SL przez jego mieszkańców. Sądziłem jednak, że jest ona albo ograniczona do pewnego zestawu elementów (modele, tekstury), albo że przynajmniej istnieje jakiś “zestaw podstawowy”. Nic z tych rzeczy: sam klient zajmuje tylko trochę ponad 30MB, więc wszystko jest po prostu na bieżąco ściągane w czasie rzeczywistym. Sprawia to, że klient zużywa każdy wolny megabit łącza, jaki dostanie do dyspozycji. I mówienie o megabitach bynajmniej nie jest przypadkiem.
A skoro zacząłem do spraw technicznych, to wypada też wspomnieć o tym, co widać z wierzchu i trochę głębiej. Jakość grafiki w Second Life wydaje się być rachunkiem płaconym za tę dowolność tworzenia wszystkiego przez wszystkich. Plasuje się ona mniej więcej na poziomie trzeciej części Grand Theft Auto i straszy zarówno klockowatymi modelami, jak i niską rozdzielczością tekstur – że o jakości oświetlenia nie wspomnę.
Muszę jednak pochwalić interfejs programu, i to zarówno jeśli chodzi o jego wygląd (prosty ale bardzo przyjemny), jak i funkcjonalność. Okna zachowują się dokładnie tak, jak w każdym porządnym systemie operacyjnym, a intuicyjne dodatki w rodzaju przeciągania i opuszczania są solidnie zaimplementowane. Może całość nie ma on uroku zakładek z Office 2007, ale dobrze spełnia swoją funkcję.

Nowi użytkownicy SL zaczynają w rejonie zwanym Orientation Island i ich pierwszym zadaniem jest… ukończenie kilku tutoriali. Większość z nich dotyczy poruszania się – służą do tego strzałki lub klasyczny WSAD, można też prowadzić pojazdy (w dość prymitywny sposób), a nawet swobodnie latać. Można też nauczyć się interakcji z obiektami w świecie, działania czata oraz gestów, a także zmiany wyglądu swojej postaci (czyli tzw. awatara). Te ostatnie są bardzo szerokie i możliwe do wykonania w każdej chwili.
Po ukończeniu samouczków otrzymujemy klucz i możemy teleportować się na drugą z wysp dla początkujących, czyli Help Island. Tam z kolei możemy dowiedzieć się co nieco o sposobach na tworzenie własnego kawałka wirtualnego świata, co obejmuje na przykład kreację nowych obiektów i sterowanie ich zachowaniem za pomocą skryptów. Można też zrobić “zakupy” w specjalnym sklepie, gdzie wszystko jest za darmo, co pozwala chociażby na zmianę domyślnego stroju. Walutą w Second Life są linden dolary (L$), które można wymieniać na te amerykańskie w jedną i drugą stronę. Obecny kurs to około 270 wirtualnych dolarów za jeden prawdziwy. Taka możliwość jest bardzo zachęcająca, jako że nie dostajemy nic na start – nasze konto z początku świeci pustkami.

Po zakończeniu zabawy na Help Island możemy wreszcie dostać się do właściwego świata SL. Trudno powiedzieć o nim cokolwiek konkretnego w jednym zdaniu. Na pierwszy rzut oka wygląda on trochę jak sen wykreowany przez nie do końca normalny umysł. Brakuje tu jakiegokolwiek śladu zorganizowania; można by go określić jako jedną wielką samowolkę “budowlaną”. Jest to zapewne skutkiem faktu, że większość parceli gruntu ma tu właścicieli, a prawo własności jest święte i oznacza wolność postawienia właściwie czegokolwiek gdziekolwiek. Zwłaszcza, że nie trzeba się przejmować takimi błahostkami jak np. prawa fizyki :) Własność pozwala też na ograniczenie innym dostępu do swojej działki, lecz na szczęście większość właścicieli nie korzysta z tego prawa.
W ten sposób, dzięki zbiorowej wyobraźni swoich mieszkańców (zasilanej wirtualnymi i prawdziwymi dolarami), powstaje i funkcjonuje świat tej… tego…

No właśnie – czym w zasadzie jest Second Life? Widać w nim pewne podobieństwa do gier MMORPG, zwłaszcza gdy rozwiniemy ostatnie trzy litery skrótu – Role Playing Game. Nie bardzo jednak pasuje do rzeczywistego punktu nacisku tych gier, czyli rozwoju postaci. W SL nie zdobywa się przecież doświadczenia ani nie wykonuje ustalonych z góry zadań. Tutaj świat tworzą sami “gracze”, którzy wchodzą ze sobą w interakcje, więc to raczej pierwsze trzy litery (Massive Multiplayer Online) mają tutaj większe znaczenie. Można przyjąć, że to coś w rodzaju wieloosobowej, sieciowej wersji The Sims. Albo po prostu gra, w której aspekt społeczny i ekonomiczny został tak rozbudowany, że nie zostało już miejsca na nic innego.
Ostatecznie wyszedł z tego po prostu niewyobrażalnie rozbudowany czat. Nic więc dziwnego, że Second Life okazał się dla wielu bardzo uzależniający. W końcu to właśnie komunikacja z innymi graczami połączona z rywalizacją i stawianiem czoła kolejnym wyzwaniom jest tym, co najsilniej utrzymuje przy klasycznych MMORPGach. Dodatkowo w SL żaden z tych elementów nie jest narzucony z góry, a określenie iż “ten świat żyje” nabiera tam zupełnie nowego znaczenia.

Przynajmniej teoretycznie. W praktyce Second Life wydało mi się śmiertelnie nudne i jednocześnie trochę niepoważne. Jest naturalnie prawie pewne, że zdołałem tylko liznąć powierzchnię tego cukierka, nie mając większego pojęcia o tym, co mógłbym znaleźć w środku.
Lecz prawdę mówiąc, wcale nie mam ochoty szukać i rozpoczynać swojego własnego Drugiego Życia. Tym bardziej, że w moim przypadku musiałoby by ono być już trzecie lub czwarte ;]

Z życia moderatora

Funkcjonowanie dużego i otwartego community – takiego jak forum Warsztatu – wymaga zawsze istnienia pewnych zasad, nawet jeśli byłyby one niepisane. Zebranie ich w formie osobnego dokumentu, na przykład regulaminu, nadaje im większą rangę i przede wszystkim stanowi jasną podstawę dla działań służb porządkowych; w przypadku forum są to oczywiście moderatorzy.

Decyzje (“wyroki” ;)) przez nich wydawane są rzecz jasna zawsze w pewien sposób subiektywne. Najprawdopodobniej nie ma bowiem dobrej metody na radzenie sobie z najbardziej powszechnym naruszeniem regulaminu forum, czyli tzw. lamerskimi wątkami. Są one zazwyczaj zakładane przez osoby dopiero co pojawiające się w społeczności i bywa, że równie szybko z niej znikające :)
Co robić z takimi wypryskami radosnej i mało zachwycającej twórczości? Rozwiązań jest przynajmniej kilka, wśród którym można wymienić:

• Usunięcie problematycznego wątku, ewentualnie z powiadomieniem autora. Zaletą jest fakt, że wątek przestaje straszyć innych użytkowników :) Wadą jest to, że skutek może okazać się odwrotny do zamierzonego i powodować eskalację niepożądanych zachowań. Poza tym trzeba przyznać, że takie szafowanie przyciskiem Delete jest bądź co bądź odrobinę nieeleganckie.
• Zablokowanie wątku, poprzedzone odpowiednim komentarzem wyjaśniającym, w jaki sposób narusza on regulamin i/lub inne zasady panujące na forum. Dzięki temu można utworzyć przykład złego zachowania, klarownie pokazujący jego skutki. Wiadomo jednak, że nadmiar złych przykładów szkodzi. Po jakimś czasie może się też okazać, iż sensowne i wartościowe wątki są gęsto przedzielone tymi, które nie powinny się pojawić. Utrudnia to korzystanie z forum i jest nieco irytujące.
• Przeniesienie wątku do specjalnego, wydzielonego działu “złych przykładów”. To wyjście obecnie powszechnie stosujemy na forum Warsztatu, gdzie istnieje specjalnie do tego stworzony Poprawczak. Lądujące tam tematy są automatycznie blokowane i zwykli użytkownicy nie mogą się już w nich wypowiadać. Autor potraktowanego tak wątku może jednak go poprawić i wówczas może on wrócić w poprzednie miejsce. Jest to aczkolwiek czysta teoria, bo jakoś ciężko mi sobie przypomnieć jakikolwiek przypadek takiej korekty :)

Te trzy metody mają jedną wadę: są metodami siłowymi i wymagają interwencji owych służb porządkowych. Innym wyjściem jest prosta zasada Don’t feed the trolls, czyli zwyczajne… ignorowanie. Praktyka ta wywodzi się jeszcze z czasów, gdy najpopularniejszą formą komunikacji “ogłoszeniowej” były grupy i listy dyskusyjne. W myśl tej reguły, wątek lub post, który w rażący sposób nie narusza zasad netykiety (czyli nie zawiera np. treści obraźliwych), a jedynie obniża poziom dyskusji – mówiąc wprost: jest lamerski – powinien zostać zwyczajnie zignorowany. Wówczas umrze on śmiercią naturalną, a community będzie niejako regulowało się samo.
Widać już, że to dość utopijne. Im społeczność jest większa i bardziej zróżnicowana, tym ciężej o taką jednomyślną postawę. Dodam jeszcze do tego swoją osobistą refleksję: w czasach panowania tak modnego hasła Web 2.0, zakładającego współtworzenie serwisów przez odwiedzających i nawyk komentowania wszystkiego przez wszystkich, powstrzymywanie się od wypowiedzi jest coraz trudniejsze i rzadsze. Także dlatego troll zawsze zostanie w końcu nakarmiony i będzie grasował dopóty, dopóki jakiś moderator go nie ustrzeli :)

Szczęśliwego nowego roku… szkolnego

Początek września to czas, w którym dużo się dzieje i dużo jest do zrobienia. Liście przestają się trzymać drzew, więc służby oczyszczania miasta mają co robić. Telewizje wprowadzają nowe ramówki, więc ich – nieliczni i wciąż ubywający – widzowie też mają co robić (i oglądać). Aha, no i oczywiście rozpoczyna się nowy rok szkolny, więc i uczniowie, i ich rodzice, i nauczyciele znów mają co robić.
Aczkolwiek jeśli chodzi o to ostatnie wydarzenie, to już od paru miesięcy wszyscy mieli się nad czym zastanawiać. Dylemat dotyczy głównie osobliwej i narzuconej odgórnie ‘mody’ na tzw. stroje jednolite. To oczywiście tylko jeden element wątpliwej jakości spuścizny po poprzednim ministrze edukacji, o którym napisano już jednak tyle, że chyba nie trzeba nic więcej dodawać :)

Na całe szczęście jako student już od trzech lat jestem całkowicie odporny na wszelkie pomysły osób zasiadających na tym stanowisku. I chociaż po drodze musiałem przetrwać inne “ciekawe” zmiany, jak choćby wprowadzenie gimnazjów czy nową maturę, wydaje mi się, że były one o wiele łatwiejsze do przełknięcia niż to, co jest serwowane uczniom w tym roku.
Wszystkim zmuszonym dzisiaj do marszu do szkół życzę więc powodzenia, a reszcie kształcących się – udanego ostatniego miesiąca wakacji :)

Bolączki C++ #2 – Pakietowanie kodu

W czasach panowania języków proceduralnych i strukturalnych – jak C czy Pascal – możliwości ukrywania i ochrony kodu przed niepowołaną zmianą były, delikatnie mówiąc, słabe. Wszystkie funkcje, pola i struktury były dostępne na zewnątrz i tylko dzięki programistycznej kurtuazji (i czytaniu dokumentacji technicznej, o ile istniała) zawdzięczało się poprawne działanie kodu.
Sytuacja poprawiła się wraz z językami obiektowymi, takimi jak C++. Mamy już klasy, których składniki mogą być określone jako publiczne, chronione (protected) albo prywatne. Jeżeli tylko odpowiednio oznaczymy składowe należące do implementacji, nikt niepowołany nie będzie miał do nich dostępu zwyczajnymi środkami.
Od tego czasu świat poszedł jednak do przodu pod względem technik organizacji kodu. Nowsze języki programowania – jak Java, C# czy Python – posiadają wbudowane mechanizmy pakietów (zwanych w .NET złożeniami – assemblies). Dzięki nim można grupować klasy wykonujące wspólne zadania i zapewniać dostęp do wybranych składowych wszystkich klasom z danego pakietu. W precyzyjnym określaniu widoczności celuje zwłaszcza C#.

W C++ teoretycznie mamy dość podobne możliwości, oferowane przez kilka osobnych mechanizmów językowych. Czymś co zdaje się najbardziej przypominać pakiety lub złożenia są przestrzenie nazw (namespaces). Ich przeznaczeniem jest przede wszystkich jednak zabezpieczenie przed dublowaniem i niejednoznacznością nazw. Na przykład klasa string z STL jest zawarta w przestrzeni std i dzięki temu nie będzie pomylona z jakąś inną klasą łańcuchów znakowych o tej samej nazwie.
Jednak przestrzenie nazw to bardzo ułomny sposób pakietowania. Elementy jednej przestrzeni (klasy, funkcje) domyślnie są dla siebie tak samo obce, jak te należące do różnych przestrzeni. Można to oczywiście zmienić, korzystając z deklaracji przyjaźni; wymaga to jednak znajomości wszystkich tych “przyjaciół” – czyli odpowiednich deklaracji zapowiadających – co jest bardzo niewygodne. Naturalnie można powiedzieć, że wtedy przynajmniej wiemy, kto nas “podgląda”. Lecz co z tego, skoro w takim zaprzyjaźnianiu stosować można wyłącznie zasadę wszystko albo nic: klasa/funkcja będzie widziała albo wszystko składowe, albo tylko publiczne (domyślnie). Bez pokrętnych sztuczek nie da się udostępnić pewnych składników tylko w ramach “pakietu”.

Całkiem osobną kwestią jest też to, jak mechanizm przestrzeni nazw współpracuje z tą zakałą C++, czyli plikami nagłówkowymi i dyrektywą #include. W nowszym językach wystarcza instrukcja podobnej do tej:

żeby jednocześnie zadeklarować użycie pakietu i uchronić się przed koniecznością używania kwalifikowanych nazw (w tym przypadku np. ListBox zamiast System.Windows.Forms.ListBox). W C++ potrzebujemy do tego dwóch dyrektyw:

i niby wszystko byłoby w porządku. Problem w tym, że wielce inteligentny mechanizm plików nagłówkowych oraz #include sprawia, że nazw niekwalifikowanych możemy używać praktycznie tylko w plikach *.cpp. Gdyby bowiem umieścić using namespace w nagłówku, to instrukcja ta zostałaby bezmyślnie powielona we wszystkich plikach, które ten nagłówek dołączają. A wtedy przestrzeń nazw nie spełniałaby nawet tej najprymitywniejszej funkcji, czyli ochrony przed wieloznacznością powtarzających się nazw.

Tak naprawdę to same przestrzenie nazw nie są złe. Nawet same pliki nagłówkowe z C++ nie byłyby aż tak bardzo złe, gdyby ich zadaniem nie było tylko ułatwianie życia kompilatorowi. Dopiero połączenie tych dwóch rzeczy sprawia, że zdecydowanie odechciewa się używać którejkolwiek z nich ;P
Istnieje jednak pewien optymistyczny akcent. Jeśli kiedykolwiek zostanie zniesiony w C++ podział na dwa rodzaje plików z kodem, wówczas i przestrzenie nazw będą musiały się przekształcić w coś podobnego do pakietów Javy czy złożeń z .NET. Podobnie jest w drugą stronę: jeżeli C++ dorobi się mechanizmu pakietów, wtedy pliki nagłówkowe i dyrektywa #include nie będą miały wielkiego sensu. Wypada więc tylko kibicować Komitetowi Standaryzacyjnemu w wykonaniu tego pierwszego kroku, bo drugi prawdopodobnie zrobią siłą rozpędu :)