Tak.
C++ jest praktycznym narzędziem. Nie jest doskonały, ale jest przydatny.
W świecie oprogramowania przemysłowego C++ jest postrzegany jako solidne, dojrzałe, podstawowe narzędzie. Rozpowszechnione wsparcie "branżowe" stawia C++ w bardzo dobrej sytuacji w ujęciu całościowej perspektywy biznesowej.
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Nie.
C++ nie był zprojektowany żeby zademonstrować jak wygląda doskonały język zorientowny obiektowo. Został zaprojektowany jako praktyczne narzędzie do rozwiązywania autentycznych problemów. Ma kilka wad, ale jdynym miejcem gdzie można przy czymś grzebać aż stanie się doskonałe jest czysto akademicka lokalizacja. A to nie było celem C++.
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Techiki obiektowo-orientowane są obecnie najlepszym sposobem jaki znamy na pisanie dużych, kompleksowych aplikacji i systemów.
OO hype: branża oprogramowania "zawodzi" w starciu z żądaniem na duże, kompleksowe systemy oprogramowania. Ale ten "zawód" związany jest z naszym sukcesem: nasz sukces sprawił, że użytkownicy pytają o więcej. Niestety stworzyliśmy rynek tak chłonny, że the "structured" analysis, design i techniki programowania nie mogły go zaspokoić. To wymaga od nas stworzenia lepszego paradygmatu.
C++ jest językiem programowania zorientowanym obiektowo. C++ może być także jak tradycyjny język programowania ("jako lepszy C"). Jednakże jeśli użyjesz go "jako lepszego C" nie oczekuj korzyści jakie daje programowanie OO.
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
To pytanie generuje o wiele, wiele więcej ciepła niż światła. Proszę przeczytaj kilka poniższych zdań zanim wyślesz na Usenet jakiś wariant tego pytania.
W 99% przypadków, wybór języka programowania jest zdominowany przez kryteria biznesowe, nie przez kryteria techniczne. Rzeczy, które naprawdę się liczą to rzeczy takie jak dostępność odpowiedniego środowiska programowania [ang. programming environment] dla komputera programisty, dostępność środowisk uruchomieniowych dla komputerów wdrażających, licencjonowanie/legalność środowisk wykonawczych i/lub środowisk programowania, dostępność wyspecjalizowanych programistów, dostępność serwisów konsultingowych, i corporate culture/politics. Te biznesowe rozważania generalnie odgrywają o wiele większą rolę niż wydajność kompilatora, wydajność uruchomieniowa, pisanie statyczne vs. dynamiczne, wiązanie statyczne vs. dynamiczne, etc.
Każdy kto argumentuje wyższość jednego języka nad innym z czysto technicznego punktu widzenia (ten, kto ignoruje dominujące zagadnienia biznesowe) przedstawia siebie jako jakiegoś techie weenie, i nie zasługuje na to żeby go słuchać.
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Bardzo dużo firm i instytucji rządowych. Bardzo dużo.
Duża liczba programistów (i dzięki temu duża infrastruktura wsparcia technicznego, obejmującego sprzedawców, narzędzia, nauczanie, etc.) jest jednym z kilku kluczowych możliwości jakie oferuje C++.
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Firmy z powodzeniem stosują standardowe "branżowe krótkie kursy," gdzie uniwersytecki kurs semestralny jest skompresowany do postaci 40 godzin w ciągu jednego tygodnia. Ale niezależnie od tego gdzie się uczysz upewnij się że kursy zawierają jakiś element praktyczny, gdyż większość ludzi najlepiej uczy się wtedy, gdy ma do rozwiązania konkretny problem. Ale nawet jeśli przejdą najlepszy możliwy trening, nie będą jeszcze gotowi.
Żeby stać się "opłacalnym" w OO/C++ potrzeba sześć do dwunastu miesięcy. Mniej jeśli programista ma łatwy dostęp do "lokalnego" ciała ekspertów, więcej jeśli nie dysponuje dobrą biblioteką klas ogólnego zastosowania. Żeby stać się jednym z takich ekspertów, którzy mogą być mentorami dla innych, potrzeba około trzech lat.
Niektórym ludziom nigdy się to nie udaje. Ty też nie masz szans, chyba że chcesz się uczyć i masz odrobinę samozaparcia. Żeby spełnić minimum, musisz być zdolnym do przyznania że się pomyliłeś. Minimum samozaparcia to chęć poświęcenia swojego wolnego czasu - (o wiele łatwiej jest nauczyć się paru nowych rzeczy niż od razy zmieniać swoją mentalność [np. zmienić swój sposób myślenia; zmienić swoje poczucie dobra; to change your mental model of the world of technology]).
Dwie rzeczy, które powinieneś zrobić:
Dwie rzeczy, których nie powinieneś robić:
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Oto kilka zalet OO/C++ patrząc z tej perspektywy:
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Tak!
Bez funkcji wirtualnych, C++ nie byłby zorientowany obiektowo. Przeciążanie operatorów i nie-"wirtualne" member functions są wspaniałe, ale są także, mimo wszystko, tylko syntaktycznym cukrem for the more typical C notion of passing a pointer to a struct to a function. Biblioteka standardowa zawiera wiele szablonów ilustrujących "podstawowe" techniki programowania, które są również świetne, ale funckje "wirtualne" są nadal w sercu obiektowo orientowanego programowania przy użyciu C++.
>Patrząc z perspektywy biznesu, nie ma potrzeby przerzucać się z czystego C do C++ bez "wirtualnych" funkcji (zignorujemy programowanie ogólne i bibliotekę standardową w tym faq). Ludzie często myślą że jest duża różnica pomiędzy C i nie-OO C++, ale bez OO, ta różnica nie jest wystarczająca by usprawiedliwić koszta szkoleń programistów, nowych narzędzi, etc. Innymi słowy, jeśli miałbym udzielić rady menadżerowi odnośnie czy zmieniać C na nie-OO C++ (np. zmienić języki ale nie założenia), prawdopodobnie odradziłbym takie działanie, chyba że byłoby to wynikiem problemów zorientowanych narzędziowo. Z perspektywy biznesu OO może pomóc uczynić systemy rozszerzalne i łatwo przystosowalne, ale z drugiej strony składnia klas C++ bez OO wcale nie musi redukować kosztów utrzymania, a napewno znacząco powiększy koszty szkoleń.
Linijka poniżej: C++ bez "wirtualnych" nie jest OO. Programowanie z klasami ale bez dynamicznego wiązania nazywa się "object based", nie "object oriented". Pozbywanie się "wirtualnych" funkcji jest równoznaczne z pozbywaniem się OO. Wszystko co ci pozostaje to programowanie object-based, podobne do oryginalnego języka Ada (BTW nowy Ada oferuje raczej czyste programowanie OO zamiast zwykłego object-based).
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Ogólnie: Wiązanie dynamiczne ulepsza ponowne użycie kodu, pozwalając staremu wywoływać nowy.
Zanim pojawiło się OO, reużycie było znakomite przez umożliwienie nowemu kodowi na wywołanie kodu starszego. Na przykład programista mógł napisać kawałek kodu, który wywoływał kod reużywalny, taki jak printf().
Z OO, reużycie możliwe jest w drugą stronę - stary kod wywołuje nowy kod. Dla przykładu: programista może napisać kawałek kodu, który jest wywoływany przez szkielet programu napisany przez prapradziadka programisty. Nie ma potrzeby zmieniać kodu prapradziadka. Nie ma nawet potrzeby ponownej jego kompilacji. Nawet jeśli wszystko czym dysponujesz jest plik obiektowy, a źródło napisane przez dziadka zaginęło 25 lat temu, ten antyczny obiekt wywoła nowe rozszerzenie bez żadnego sprzeciwu.
To jest rozszerzalność, i to jest OO.
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Prawie.
C++ jest tak zbliżony do pełnej kompatybilności z C jak to tylko możliwe, ale nic poza tym. W praktyce, najistotniejszszą różnicą jest to, że C++ wymaga prototypów, i to że f() deklaruje funkcję bez argumentów (w C funkcja deklarowana przez f() może otrzymać dowolną liczbę parametrów dowolnych typów).
Równocześnie są też bardzo subtelne różnice, jak np. sizeof('x') odpowiada sizeof(char) w C++ i sizeof(int) w C. Also, C++ puts structure "tags" in the same namespace as other names, whereas C requires an explicit struct (e.g., the typedef struct Fred Fred; technique still works, but is redundant in C++).
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Tak.
Standard C++ został sfinalizowany i zaadoptowany przez ISO (International Organization for Standardization) jak również przez kilka narodowych organizacji ds. standardów, takich jak ANSI (The American National Standards Institute), BSI (The British Standards Institute), DIN (The German National Standards Organization). Standard ISO został zatwierdzony przez jawne głosowanie 14 listopada 1997.
Komitet ANSI C++ nazywa się "X3J16". Grupa ISO C++ nosi nazwę called "WG21". Główni gracze w opracowaniu standardów ANSI/ISO C++ to: reprezentanci Australii, Kanady, Danii, Francji, Niemiec, Irlandii, Japonii, Holandii, Nowej Zelandii, Szwecji, Wielkiej Bytanii i USA, razem z przedstawicielami z około stu firm i wielu zainteresowanych osób prywatnych. Z firm warto wymienić: AT&T, Ericsson, Digital, Borland, Hewlett Packard, IBM, Mentor Graphics, Microsoft, Silicon Graphics, Sun Microsystems, Siemens. Po około ośmiu latach pracy ten standard jest teraz kompletny. 14 liastopada 1997 standard został zatwierdzony w jawnym głosowaniu przez państwa, które miały swoich przedstawicieli w Morristown.
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Są przynajmniej trzy sposoby na zdobycie "miękkiej" kopii tego dokumentu:
Notka: Dokument z ISO jest ponad 10 razy droższy niż ten z ANSI, jednakże techniczna zawartość jest taka sama. Dokument z ISO ma inną stronę tytułową, ale zawartość nadal pozostaje identyczna z tą z ANSI. Proszę nie pytaj mnie dlaczego ISO pobiera tak dużą opłatę za tą samą rzecz; to decyzja ISO; musisz pytać ich dział publikacji/sprzedaży.
Są przynajmniej dwa sposoby na zdobycie "twardej" kopii tego dokumentu:
Są dwa inne, potencjalnie interesujące (i darmowe), dokumenty które możesz chcieć zobaczyć:
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Ta odpowiedź jest przede wszystkim przeznaczona dla osób nie-w-temacie, pełniących jakieś kierownicze stanowiska, które chcą dobrze wypełnić swój obowiązek rekrutacji nowych pracowników. Jeśli jesteś programistą C++, który wybiera się na taką rozmowę, i nurkujesz w tym FAQ z nadzieją na znalezienie przykładowych pytań, które mogą ci zadać, i tym samy chcesz uniknąć prawdiwej nauki C++ - wstydź się: poświęć czas na stanie się technicznie kompetentnym to nie będziesz musiał próbować "oszukiwać" sobie drogi przez życie!
Wracając do osób nie-w-temacie: widocznie jesteś uprawniony do osądzenia jak dobrze kandydat "pasuje" do profilu twojej firmy. Jednakże wokół jest wystarczająco dużo szarlatanów, wannabes'ów, i pozerów. Aby zdemaskować kogoś takiego powinieneś skorzystać z pomocy kogoś, kto dobrze orientuje się w temacie. Dużo firm sparzyło się na zatrudnianiu miłych ale nieudolnych gości — ludzi, którzy byli inkompetentni, pomimo faktu, iż znali odpowiedzi na kilka niezrozumiałych pytań. Jedyny sposób na dekonspirację takich pozerów to działanie do spólki z kimś, kto potrafi zadać odpowiednie pytania z technicznej strony. Raczej nie uda ci się to samemu. Nawet jeśli dam ci tuzin podchwytliwych pytań nie wykurzysz złych chłopców.
Your technical sidekick might not be (and often isn't) qualified to judge the candidate on personality or soft skills, so please don't abdicate your role as the final arbiter in the decision making process. But please don't think you can ask a half dozen C++ questions and have the slightest clue if the candidate really knows what they're talking about from a technical perspective.
Podsumowując, jeśli jesteś wystarczająco "techniczny" do preczytania C++ FAQ, możesz wykopać tutaj wiele dobrych pytań do rozmowy kwalifikacyjnej. FAQ zawiera dużo perełek, które pomogą ci oddzielić ziarno od plew. FAQ skupia się na tym co programiści powinni robić, przeciwstawiając zaledwie to co kompilator pozwoli im zrobić. Są rzeczy które mogą być, ale ni powwinny być robione w C++. FAQ pomaga ludziom oddzielić te dwie rzeczy.
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Oznacza to, że such-in-such jest czymś czego powinieneś unikać przez większość czasu, ale nie czymś, czego powinieneś unikać cały czas. Innymi słowy - jest to zło, ale w sensie "mniejsze zło", czyli używane jak już naprawdę nie ma wyjścia. To żart, oki? Nie traktuj tego zbyt poważnie.
Prawdziwym celem tego zwrotu ("Ah ha, powiesz, tak naprawdę jest ukryty cel!"; masz rację: jest) jest otrząsnąć nowych programistów C++ ze starego sposobu myślenia. Na przykład programiści C, nowi w C++ często używają wskaźników, tablic i/lub #define częściej niż powinni. FAQ wylicza te wszystkie "złe rzeczy" by popchnąć nowych programistów C++ we właściwym kierunku. Celem takich powiedzonek jak "wskaźniki są złe" jest przekonać nowych programistów C++, że C++ naprawdę nie jest "taki jak C z wyjątkiem tych śmiesznych // komentarzy."
Dobra, teraz poważnie. Nie sugeruję, iż makra, tablice czy wskaźniki powinno stawiać się na równi z morderstwem czy porwaniem. No, może wskaźniki. (Tylko żartowałem!) Tak więc nie wariuj zbytni na punkcie słówka "zło": ono celowo brzmi tak ostro. I nie szukaj precyzyjnej technicznej definicji kiedy coś jest "złe" a kiedy nie: nie ma takiej.
Jeszcze jedno: rzeczy z etykietką "zło" (makra, tablice, wskaźniki, etc.) nie są zawsze złe w każdej sytuacji. Gdy są złem najmniejszym używaj ich!
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
Oczywiście że będziesz!
Nie ma jednej uniwersalnej reguły. Weź marker i na pisz na wewnętrzej stronie swoich okularów: Pisanie Programów Jest Podejmowaniem Decyzji. Innymi słowy, w programowaniu jest bardzo mało reguł "nigdy..." i "zawsze..." — reguł, które można stosować bez zastanowienia — reguł, które sprawdzają się w każdej sytuacji. [Jak mawia babcia z reklamy: Jak coś jest do wszystkiego to jest do niczego! - przyp. tłum.]
Mówiąc po angielsku [a może po polsku? ;) - przyp. tłum.], będziesz musiał podejmować decyzje, a jakośc twoich decyzji zaważy na wartości twojego programowania z punktu widzenia biznesu. Czasem będziesz musiał wybierać pomiedzy tuzinem złych opcji. Kiedy do tego dojdzie, pozostaje mieć nadzieje, że udało ci się wybraćnajmniejsze zło spośród alternatyw.
So you will end up using approaches and techniques labeled as "evil." Jeśli to nie jest zbyt komfortowe, spróbuj traktować słowo "zło" jako "najbardziej niepożądane" (but don't quit your day job to become an author: milquetoast terms like that put people to sleep :-)
[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]
E-mail the author
[ C++ FAQ Lite
| Spis treści
| Skorowidz
| O autorze
| ©
| Pobierz swoją własną kopię ]
Ostatnia aktualizacja Jun 17, 2002
Wersja
polska: 0.1h Oct 3, 2003