Filozofia inżynierii: Bjarne Stroustrup, abstrakcja bez narzutu

Najważniejsze wnioski

• Abstrakcja bez narzutu. Stroustrup zbudował C++, by skończyć z fałszywym wyborem między czytelnym kodem a szybkością na poziomie sprzętu — wersja ekspresyjna i wersja ręcznie dopracowana powinny kompilować się do tego samego kodu maszynowego.
• Zasada zerowego narzutu. „Za to, czego nie używasz, nie płacisz; a tego, czego używasz, nie napisałbyś ręcznie ani odrobinę lepiej” — to reguła, którą musi przejść każda funkcja C++.
• RAII czyni to namacalnym. Powiązanie czasu życia zasobu z obiektem na stosie daje deterministyczne, bezpieczne wobec wyjątków sprzątanie bez odśmiecacza pamięci — wzorzec, który Rust przejął później niemal w całości.
• Nie zostawiaj miejsca poniżej. C++ musi pozostać językiem najwyższego poziomu, między którym a krzemem nie ma nic poza asemblerem, bo inaczej jego miejsce zająłby język niższego poziomu.

Zasada

„Za to, czego nie używasz, nie płacisz. A dalej: tego, czego używasz, nie napisałbyś ręcznie ani odrobinę lepiej.” — Bjarne Stroustrup, zasada zerowego narzutu¹

To zdanie jest najważniejszym zdaniem w programowaniu systemowym i niesie ze sobą dwie obietnice. Pierwsza połowa mówi, że abstrakcja musi być darmowa w punkcie nie-użycia: sięgnij po funkcję, a coś cię to kosztuje; zignoruj ją, a nie kosztuje cię nic — ani bajta pamięci, ani jednego cyklu w czasie wykonania. Druga połowa to trudniejsza obietnica: kiedy naprawdę używasz abstrakcji, kompilator musi wyprodukować kod maszynowy co najmniej tak dobry jak ten, który kompetentny programista napisałby ręcznie dla dokładnie tego zadania. Wektor, który w trybie wydania niczego nie sprawdza pod kątem granic. Inteligentny wskaźnik kompilujący się do gołego wskaźnika. Iterator, który znika, zamieniając się w surową pętlę. Klarowność jest darmowa.

Większość języków wymusza kompromis. Dostaje się albo wersję wysokiego poziomu, ekspresyjną, lecz powolną, albo schodzi się na niski poziom — szybki, lecz nieczytelny — i całe rzemiosło sprowadza się do wyboru, który ból zaakceptować danego dnia. Cała kariera Stroustrupa jest odmową przyjęcia tego kompromisu. Odczuł go osobiście: jako doktorant pokochał abstrakcje Simuli, ale uznał je za zbyt wolne do prawdziwej pracy, a pokochał szybkość BCPL, lecz uznał ją za zbyt niskopoziomową, by zbudować w niej cokolwiek dużego.² C++ istnieje, ponieważ Stroustrup uznał, że nie powinno się musieć wybierać. Wydajność i abstrakcja nie były przeciwstawnymi pokrętłami do wyważenia; miały przychodzić razem, w tej samej linijce kodu.

To przekonanie jest tym samym, które leży u podstaw tezy, że wydajność nie jest funkcją, którą się dodaje, lecz właściwością, której nie wolno utracić. Abstrakcja o zerowym narzucie nie jest szybką rzeczą zbudowaną na powolnym języku. Jest klarowną rzeczą, którą kompilator ściera z powrotem dokładnie do tego, co napisałoby się ręcznie, tak że nigdy nie płaci się za klarowność. „Lubię, gdy mój kod jest elegancki i wydajny” — powiedział kiedyś — a słowem, które ma znaczenie, jest owo i. Nienawidzi konieczności wyboru między jednym a drugim.³

Kontekst

Bjarne Stroustrup urodził się 30 grudnia 1950 roku w Aarhus w Danii.⁴ Studiował matematykę i informatykę na Uniwersytecie w Aarhus, a następnie wyjechał do Anglii na doktorat w Laboratorium Komputerowym Uniwersytetu Cambridge, który ukończył w 1979 roku. Jego rozprawa — „Communication and control in distributed computer systems” — dotyczyła tego, jak rozdzielić pracę systemu operacyjnego po sieci komputerów.⁴

Aby zbadać ten problem, musiał zbudować symulator, a pierwszą wersję napisał w Simuli, norweskim języku (zaprojektowanym przez Ole-Johana Dahla i Kristena Nygaarda), który wprowadził świat w klasy i obiekty. Stroustrup go pokochał. Abstrakcje klas w Simuli pozwoliły mu uporządkować duży, zawiły program tak, jak zorganizowany był problem, a nie tak, jak zbudowana była maszyna — a sam program był przyjemnością w pisaniu i w zmienianiu. Potem spróbował uruchomić go na pełną skalę i abstrakcje załamały się pod ciężarem własnego kosztu. Implementacja była zbyt wolna, by miała praktyczny sens. Przepisał symulator w BCPL, okrojonym języku systemowym, i odzyskał szybkość — ale BCPL był tak niskopoziomowy, że budowanie w nim czegokolwiek dużego było udręką.² Ten gwałtowny kontrast był raną formującą. Użył języka ekspresyjnego i zapłacił za to wydajnością, potem użył języka szybkiego i zapłacił za to wszystkim innym. Żadne z tych rozwiązań nie było do przyjęcia. Obie połowy powinny być możliwe jednocześnie.

Z tym żalem trafił do Bell Labs w New Jersey w 1979 roku, gdzie ponownie stanął przed problemem systemów rozproszonych: analizą ruchu jądra UNIX-a w sieci. Pamiętając Cambridge, postanowił dodać organizującą moc Simuli do języka C — już szybkiego i bliskiego sprzętowi, języka systemowego UNIX-a — nie rezygnując z ani odrobiny szybkości C.⁴⁵ Wynik nazwał „C with Classes”. W 1983 roku jego kolega Rick Mascitti zaproponował nazwę C++, operator inkrementacji zastosowany do samego C: kolejne C, o jedno lepsze, z tą samą maszyną pod spodem.⁵

Dzieło

Od C with Classes do C++: lepsze C, które nic nie kosztuje

Pierwszy ruch (1979–1983) był rozmyślnie skromny i dokładnie trafny. Wziąć C — już szybkie, już odwzorowujące się bezpośrednio na sprzęt, już będące językiem systemowym, któremu ludzie ufali — i dodać rzeczy, których Simula nauczyła go pragnąć: klasy, lepszą kontrolę typów, abstrakcję danych.⁵ Co kluczowe, dodał je jako warstwę, za którą programiści C nie musieli płacić. Program w C nadal był poprawnym programem w C++. Struktura, która nie korzystała z żadnej nowej funkcji, kompilowała się do tych samych bajtów co zawsze. Nowa moc była opcjonalna, a jej użycie kosztowało tylko tyle, ile kosztowałby równoważny, ręcznie napisany kod w C. To zasada zerowego narzutu w zalążku, obecna jeszcze zanim Stroustrup nadał jej nazwę: nie obciążaj podatkiem tych, którzy z funkcji nie korzystają, i nie pozwól, by funkcja generowała gorszy kod, niż napisaliby sami.

Język udokumentował i ustabilizował w książce The C++ Programming Language (1985), która uczyniła go powszechnie dostępnym, a potem przez dziesięciolecia bronił jego rdzenia poprzez projekt każdej późniejszej funkcji.⁴

Zasada zerowego narzutu

Zasada zerowego narzutu to idea nośna, reguła, względem której mierzona jest każda funkcja C++. Stroustrup formułuje ją w dwóch częściach: „Za to, czego nie używasz, nie płacisz (czasem ani pamięcią), a dalej: tego, czego używasz, nie napisałbyś ręcznie ani odrobinę lepiej.”¹ Pierwszy człon to polityka podatkowa — żadna funkcja nie może nakładać kosztu na kod, który z niej nie korzysta. Drugi to poprzeczka jakości — funkcja, której naprawdę używasz, musi kompilować się do kodu nie gorszego, niż staranny programista wyprodukowałby ręcznie dla tego konkretnego zadania. Szablony, constexpr, semantyka przenoszenia oraz kontenery i algorytmy biblioteki standardowej — wszystko to zaprojektowano tak, by tę zasadę uszanować; dwa słynne wyjątki, informacja o typach w czasie wykonania i wyjątki, to dokładnie te dwie funkcje, dla których kompilatory oferują przełączniki do ich wyłączenia, właśnie dlatego że naginają regułę.⁶

Nagrodą jest coś, co brzmi niemożliwie, dopóki nie zobaczy się asemblera: sposób ekspresyjny i sposób ręcznie dopracowany produkują ten sam kod maszynowy.

Ta tożsamość — ekspresyjność i ręczne dopracowanie zlewające się w jeden wynik — sprawia, że zasada jest moralna w równym stopniu co techniczna. Odbiera inżynierowi standardową wymówkę. Gdyby klarowność była naprawdę kosztowna, można by usprawiedliwić pisanie brzydkiej, szybkiej wersji „bo to musi być szybkie”. Zakład Stroustrupa polega na tym, że ta wymówka jest zwykle kłamstwem — że dobrze zaprojektowana abstrakcja pozwala mieć wersję czytelną oraz szybką, ponieważ to ta sama wersja. Koszt zapłacono raz, przez projektanta języka, tak by nigdy więcej nie płacił go programista.

RAII i deterministyczne zasoby

Zasada potrzebowała mechanizmu na najbardziej zagmatwaną część programowania systemowego: zasoby, które trzeba pozyskać, a potem niezawodnie zwolnić — pamięć, pliki, blokady, gniazda. Odśmiecanie pamięci odpowiada na to, rezygnując z determinizmu: sprzątanie następuje kiedyś, według harmonogramu odśmiecacza, co jest nie do przyjęcia dla blokady czy uchwytu pliku. Odpowiedź Stroustrupa, którą nazwał RAII — Resource Acquisition Is Initialization — wiąże czas życia zasobu z czasem życia obiektu na stosie.⁷ Zasób pozyskuje się w konstruktorze; zwalnia się go w destruktorze; a ponieważ C++ gwarantuje, że destruktor obiektu na stosie uruchamia się w chwili opuszczenia zakresu — normalnie lub poprzez wyjątek, w odwrotnej kolejności względem konstrukcji — zasób zostaje zwolniony dokładnie wtedy, gdy powinien, deterministycznie, bez odśmiecacza i bez ręcznego free, o którym można zapomnieć.⁷

RAII to urzeczywistniony zerowy narzut. Wywołanie destruktora to kod, który i tak trzeba by było napisać ręcznie; język po prostu gwarantuje, że nie da się o nim zapomnieć. Dostaje się automatyczne, bezpieczne wobec wyjątków, deterministyczne sprzątanie i nie płaci się nic ponad to, co zapłaciłoby się, kodując sprzątanie ręcznie. To wzorzec C++, który języki późniejsze — Rust najwyraźniej — przejęły niemal w całości.

Standaryzacja i „nie zostawiaj miejsca dla języka niższego poziomu”

Stroustrup nie zatrzymał C++ jako osobistego projektu. Zaniósł go do komitetu standaryzacyjnego — ANSI od 1989 roku, ISO od 1991 — i zasiadał w nim przez dziesięciolecia, przewodnicząc Grupie Roboczej ds. Ewolucji, tak by C++ był stabilnym, niezależnym od dostawcy standardem, a nie dialektem jednej firmy.⁴ I dał komitetowi regułę konstytucyjną, zaczerpniętą z jego zasad projektowych w The Design and Evolution of C++: „Nie zostawiaj miejsca dla języka niższego poziomu niż C++ (z wyjątkiem asemblera).”⁸ Rozumowanie jest precyzyjne — gdyby dało się napisać wydajniejszy kod w jakimś języku pomiędzy C++ a gołym sprzętem, to ów język stałby się preferowanym językiem systemowym, a C++ utraciłby rację bytu.⁸ By pozostać żywotnym, C++ musi zachować bezpośredni dostęp C do sprzętu, jego kontrolę nad układem danych oraz typy prymitywne odwzorowujące się jeden do jednego na maszynę.⁸ Między abstrakcją a krzemem nie powinno znajdować się nic poza asemblerem. Zasada zerowego narzutu, ujęta jako granica konkurencyjna: bądź językiem najwyższego poziomu, który mimo to niczego nie pozostawia na stole.

Metoda

Metoda to jeden zakład — klarowność i szybkość są tym samym, jeśli zaprojektuje się abstrakcję poprawnie — egzekwowany jako zestaw twardych reguł.

Mierz każdą funkcję względem zerowego narzutu. Żadna funkcja nie może obciążać podatkiem kodu, który z niej nie korzysta, i żadna funkcja nie może generować kodu gorszego niż ręcznie napisany odpowiednik. To bramka, którą przez czterdzieści lat musiał przejść każdy dodatek do C++.¹⁶

Ufaj programiście i pozostań wieloparadygmatowy. C++ wspiera style proceduralny, obiektowy, generyczny i funkcyjny, ponieważ Stroustrup odmówił decydowania za ciebie, jak masz uporządkować swój problem. Język daje narzędzia i zakłada, że znasz swoją dziedzinę lepiej niż projektant języka.⁶

Odwzorowuj się bezpośrednio na sprzęt. Zachowaj odpowiedniość jeden do jednego z C między typami prymitywnymi, układem danych a maszyną. Abstrakcja siedzi na krzemie, a nie nad środowiskiem wykonawczym, które go ukrywa.⁸

Spraw, by sprzątanie było deterministyczne, a nie odroczone. RAII wiąże czas życia zasobu z czasem życia obiektu, tak że zwolnienie następuje w znanej chwili, bezpiecznie wobec wyjątków, bez odśmiecacza pamięci i bez niczego, o czym trzeba by pamiętać, by zwolnić.⁷

Ustabilizuj go otwarcie. Przekaż język międzynarodowemu komitetowi standaryzacyjnemu, zamiast nim władać, tak by C++ był trwałym standardem publicznym i żaden pojedynczy dostawca nie mógł go rozszczepić.⁴

Łańcuch wpływów

Kto go ukształtował

Ole-Johan Dahl i Kristen Nygaard, poprzez Simulę. Simula nauczyła Stroustrupa, do czego służy abstrakcja — pozwala, by program był ustrukturyzowany tak, jak ustrukturyzowany jest problem — a jej powolność nauczyła go drugiej połowy lekcji: że abstrakcja jest bezwartościowa, jeśli nie stać cię na to, by jej użyć. C++ to próba zachowania daru Simuli przy niepłaceniu żadnego z jej kosztów. (Wpływ bezpośredni, formujący)

BCPL oraz kultura programowania systemowego wokół C i UNIX-a. BCPL dał mu kontrastujący ból — surową szybkość bez możliwości uporządkowania czegokolwiek dużego — a C, język UNIX-a w Bell Labs, dał mu szybki, odwzorowany na sprzęt fundament, na którym mógł zbudować C++ na wierzchu, zamiast w jego miejsce.²⁵ (Wpływ bezpośredni)

Bell Labs. Ta sama instytucja, która wydała C i UNIX-a, dała Stroustrupowi problem systemów rozproszonych, od którego zaczęło się „C with Classes”, oraz kulturę badawczą, która pozwoliła mu spędzić lata na dopracowywaniu języka. (Wpływ formujący)

Kogo ukształtował on

Infrastruktura świata działa na jego języku. Systemy operacyjne, przeglądarki, bazy danych, silniki gier, kompilatory, systemy transakcji wysokiej częstotliwości, oprogramowanie sterujące marsjańskich łazików — krytyczny dla wydajności rdzeń współczesnej informatyki jest nieproporcjonalnie często napisany w C++. Praca niewielu inżynierów jest aż tak nośna.

Ruch abstrakcji o zerowym koszcie. Zasada Stroustrupa, przemianowana na „zero-cost abstractions”, stała się jawnym celem założycielskim Rusta, który przejął RAII (jako własność i Drop), deterministyczne niszczenie oraz regułę, że konstrukcje wysokiego poziomu muszą kompilować się do optymalnego kodu maszynowego. Języki takie jak D i Carbon wywodzą się z tej samej linii. Idea, że nie powinno się płacić za klarowność, jest dziś głównym nurtem — i jest jego.⁶

Nić przewodnia

John Carmack chce, by pętla wewnętrzna wykonywała najmniej pracy, na jaką pozwala fizyka — „prędkość światła jest do bani”, maszyna rządzona przez twarde ograniczenia, każdy zmarnowany cykl to wybór. Stroustrup wręcza Carmackowi narzędzia do napisania tej pętli czytelnie: abstrakcja o zerowym narzucie jest obietnicą, że wersja klarowna i wersja najbliższa sprzętowi to ten sam kod maszynowy, tak że nigdy nie trzeba wybierać. Tam gdzie Barbara Liskov dała abstrakcji jej teorię — abstrakcję danych, kontrakt, który typ jest winien swoim użytkownikom, linię od Simuli do CLU głoszącą, że „należy programować względem tego, co rzecz robi, a nie jak działa” — Stroustrup nadał tej teorii ciało, którego uruchomienie nic nie kosztuje. A tam gdzie Alan Kay wyobrażał sobie obiekty jako małe komputery przekazujące sobie komunikaty, rozmowę o późnym wiązaniu, toczącą się w czasie wykonania, Stroustrup poszedł drogą przeciwną do tego samego słowa: jego obiekty rozstrzygane są w czasie kompilacji i rozpuszczają się w gołym kodzie maszynowym, OOP jako narzędzie organizujące o zerowym narzucie, a nie żywa magistrala komunikatów. To samo słownictwo, dwie filozofie — jedna optymalizuje pod kątem elastyczności, druga pod kątem rachunku w czasie wykonania. (Pomost serii)

Co z tego biorę dla siebie

Lekcja, którą zachowuję, brzmi: „ekspresyjny albo szybki” to niemal zawsze fałszywy wybór, który narzuca ci zły projekt. Kiedy przyłapuję się na pisaniu brzydkiej wersji „bo to musi być szybkie”, zasada Stroustrupa staje się oskarżeniem: to nie jest prawo informatyki, to porażka w znalezieniu abstrakcji, która sama z siebie kompiluje się do szybkiej rzeczy. Praca polega na tym, by zaprojektować wersję klarowną tak dobrze, że maszyna wyprodukuje z niej kod optymalny — by zapłacić koszt raz, w projekcie, tak by nigdy nie płacono go ponownie w każdej linijce, która z niego korzysta. To ten sam standard co jakość jako jedyna zmienna: pytanie nigdy nie brzmi „czy stać mnie na to, by uczynić to klarownym?”, lecz „dlaczego moja abstrakcja tak przecieka, że klarowność cokolwiek kosztuje?”.

W świecie, w którym buduję teraz — agenci, pętle narzędziowe, systemy AI — pokusa jest przeciwieństwem zerowego narzutu: nakładaj otoczkę na otoczkę, połknij wywołanie modelu, by zatuszować powolną ścieżkę, pozwól, by każda wygodna abstrakcja po cichu dokładała opóźnienie, którego nikt nie mierzy. Ruch w stylu Stroustrupa polega na żądaniu, by wygodny interfejs kompilował się do tego wydajnego — by czysty API i szybka ścieżka były tą samą ścieżką, z kosztem zapłaconym w projekcie lokalnego mechanizmu agenta, a nie naliczanym każdemu wywołaniu, które przez niego przepływa. To przekonanie — że smak jest systemem technicznym, wobec którego można postawić twardą regułę, a nie nastrojem, który się deklaruje — jest nicią przewodnią od symulatora z 1979 roku, który działał zbyt wolno, do mechanizmu agenta z 2026 roku, który zbyt wolny być nie powinien.

FAQ

Na czym polega filozofia inżynierska Bjarnego Stroustrupa?

Przekonaniem Stroustrupa jest to, że nigdy nie powinno się musieć wybierać między ekspresyjnym, wysokopoziomowym kodem a wydajnością na poziomie sprzętu. Zbudował C++ na zasadzie zerowego narzutu: funkcja języka musi nic nie kosztować, gdy się jej nie używa, a gdy się jej używa, musi kompilować się do kodu nie gorszego, niż napisałoby się ręcznie dla tego zadania.¹ Połączył to z zaufaniem do programisty (C++ jest rozmyślnie wieloparadygmatowy), bezpośrednim odwzorowaniem na sprzęt, deterministycznym zarządzaniem zasobami poprzez RAII oraz ustabilizowaniem języka jako otwartego standardu ISO, zamiast władania nim.⁴⁶⁷

Czym jest zasada zerowego narzutu?

To reguła, którą Stroustrup formułuje w dwóch częściach: „Za to, czego nie używasz, nie płacisz (czasem ani pamięcią), a dalej: tego, czego używasz, nie napisałbyś ręcznie ani odrobinę lepiej.”¹ Pierwsza połowa oznacza, że nieużywana funkcja nie nakłada żadnego kosztu w czasie wykonania ani w pamięci; druga oznacza, że funkcja, której się używa, generuje kod co najmniej tak dobry, jak napisałby ręcznie kompetentny programista. To bramka, którą musi przejść każda funkcja C++. Dwie funkcje, które ją naginają — informacja o typach w czasie wykonania i wyjątki — to dokładnie te dwie, które większość kompilatorów pozwala wyłączyć.⁶ To dzięki tej zasadzie abstrakcja C++ taka jak inteligentny wskaźnik czy iterator może kompilować się do tego samego kodu maszynowego co surowa, ręcznie dopracowana wersja.

Czym jest RAII i dlaczego Stroustrup je wymyślił?

RAII — Resource Acquisition Is Initialization — to wzorzec C++, nazwany przez Stroustrupa, który wiąże czas życia zasobu z czasem życia obiektu na stosie: zasób pozyskuje się w konstruktorze obiektu, a zwalnia w jego destruktorze.⁷ Ponieważ C++ gwarantuje, że destruktor obiektu na stosie uruchamia się w chwili opuszczenia zakresu — niezależnie od tego, czy funkcja zwraca normalnie, czy wyjątek rozwija stos — zasoby takie jak pamięć, pliki, blokady i gniazda zwalniane są deterministycznie, w znanej chwili, bez odśmiecacza pamięci i bez niczego, co trzeba by zwalniać ręcznie. Daje to automatyczne, bezpieczne wobec wyjątków sprzątanie przy zerowym narzucie, a Rust przejął je później niemal w całości jako własność i Drop.⁷

Dlaczego Stroustrup stworzył C++ i skąd się ono wzięło?

Pisząc swój doktorat w Cambridge o systemach rozproszonych (ukończony w 1979 roku), Stroustrup zbudował symulator w Simuli i pokochał jej abstrakcje klas, ale uznał ją za zbyt wolną na pełną skalę; przepisał go w BCPL, który był szybki, lecz zbyt niskopoziomowy, by zbudować w nim cokolwiek dużego.² Żaden z tych kompromisów nie był do przyjęcia, więc w Bell Labs — mierząc się z problemem analizy jądra UNIX-a w sieci — postanowił dodać organizującą moc Simuli do C, nie tracąc szybkości C. Nazwał to „C with Classes” (1979); jego kolega Rick Mascitti zaproponował nazwę C++ w 1983 roku.⁴⁵ W 2018 roku National Academy of Engineering przyznała mu Nagrodę Charlesa Starka Drapera — najwyższe amerykańskie wyróżnienie inżynierskie, nagrodę w wysokości 500 000 dolarów, często nazywaną inżynierskim Noblem — za pracę nad projektem i implementacją języka programowania C++.⁹

Źródła