shg napisał(a):
> > Nadaje sie jak najbardziej.
>
> Ale jakoś bardziej mi się tu widzi C, czy asembler.
Użycie C++ nie oznacza wcale, że złożoność systemu musi wzrosnąć.
> Zresztą poniekąd architektura i API systemu będą związane z
> językiem w jakim został napisany, można napisać OS tak, że
> będzie do C++ przystosowany i w tym języku będzie się go
> programowało łatwiej niż w C.
Cały windowsowy COM (tak więc również i DirectX) opera się na C++ I jakoś nie ma większych problemów z używaniem tegoż w językach innych niż c++.
> Mi odpowiada styl AmigaOS, czyli lekki system, pisany bardziej
> pod kątem C/asm, ale to w sumie takie moje "zboczenie" w
> kierunku minimalizacji wszystkiego co się da,
Odpowiada Ci styl AmigaOS i nie lubisz c++ wraz z jego obiektowością? Czas spojrzeć na AmigaOS z nieco innej strony...
Spójrz na dowolną Amigową bibliotekę. Każda z nich implementuje pewien z góry określony interfejs - struct Library wraz z jego czterema wirtualnymi metodami: LibOpen, LibClose, LibExpunge, LibExtFunc. Każda z bibliotek rozszerza tenże interfejs o swoje własne metody i każda jest inna. Mimo to, posiadając wskaźnik na bazę dowolnej biblioteki możesz ją potraktować jak obiekt implementujący interfejs biblioteki, i wywołać cztery metowy w interfejsie zdefiniowane.
Jak wywołuje się funkcje biblioteczne? W rejestrze A6 umieszczasz wskaźnik na bazę biblioteki, w pozostałych rejestrach przekazujesz ewentualne parametry. Następnie wykonujesz skok w odpowiednie miejsce tablicy wektorów. Czym to się różni od pobrania adresu metody wirtualnej z vtable i wykonania metody?
Biblioteka -> Obiekt
Funkcja biblioteczna -> Metoda wirtualna obiektu
Tablica wektorów -> vtable, tablica metod wirtualnych
Rejestr A6 -> wskaźnik this.
Popatrz na strukturę Device. Można ją nazwać interfejsem dziedziczącym interfejs Library i definiującym dwie nowe metody wirtualne: BeginIO i AbortIO.
Co ze strukturą Node? To dosyć proste opakowanie obiektu pozwalające na zapakowanie obiektów do uniwersalnego kontenera - listy dwukierunkowej ze strażnikiem (struct List). Czy poniższa konstrukcja:
struct Library {
struct Node ln_Node;
...
jest aż tak odmienna od:
class Library : public Node {
...
? struct Node jest uniwersalnym i prostym narzędziem. Niestety, ponieważ C nie jest językiem obiektowym, co chwila pojawia się potencjalnie niebezpieczne rzutowanie typu Node na bardziej złożone typy danych.
> > Moglbys rozwinac te mysl? Brzmi intrygujaco tyle ze
> niepodparta zadnym logicznym argumentem jest calkiem
> bezsensowna.
>
> A tak jakoś wydaje mi się, że w systemie operacyjnym nie ma za
> bardzo miejsca na wykorzystanie "ficzerów" C++, przeciążania
> operatorów, template'ów, czy skomplikowanego dziedziczenia
> razem z całym bagażem konstruktorów, destruktorów i
> przechwytywania wyjątków.
Oczywiście nikt nikogo nie zmusza do wykorzystania C++ w pełni. Równie dobrze może to być po prostu "C z klasami". Chociaż z drugiej strony...? Niektóre struktury trzeba przed użyciem zainicjalizować. Ot chociażby struct List. Ponieważ inicjalizacja konieczna jest zawsze, mogłaby być wykonana w konstruktorze. Niestety takowego brak ;)
Odnosnie dziedziczenia napisałem już powyżej ;)
> W C++ wyglądało by to na przykład tak,
[...]
> (pewnie jest jakiś atrybyt
inline, nie wiem, nie używam
> C++)
W zasadzie to załatwia całą dyskusję ;)
> >> Zresztą chyba żaden kompilator nie wykorzystuje potencjału,
> jaki daje C++ jeśli chodzi o optymalizację
>
> >Co masz na mysli?
>
> Właściwie to powinienem był napisać "nie wykorzystuje w
> pełni".
> A mam na myśli między innymi ostatnie zdanie w poprzednim
> akapicie.
Nietrafione było ;) Ale możemy na ten temat podyskutować :)
> Chodzi mi o to że engine optymalizacji jest po prostu
> niekompletny, przynajmniej w gcc i to nie tylko w C++, ale i w
> C zdarzało mi się,
Tutaj mówisz o niedociągnięciu w kompilatorze C. Mimo, iż można je ekstrapolować na C++ nie podałeś żadnego konkretnego przykładu udowadniającego słuszność zgłoszonej przez Ciebie tezy.
> I taki przykład paskudny przykład, nie wiem, czemu, ale
> kompilacja aMule (napisanego w C++) pod gcc (Linux)
> potrzebowała grubo ponad 260MB miejsca na dysku,
kompilacja z włączonym debugiem, tudzież dodanie "--enable-final" przy wywołaniu configure potrafi nieść za sobą takie konsekwencje.
> 16MB. Szybkość kompilacji to po prostu masakra, przez tyle
> czasu, ile straciłem na kompilację aMule skompilowałbym ze 3
> razy kernela.
Twój przykład dotyczył czasu kompilacji programu w C++ i nie nadaje się na dowód twojej tezy, mówiącej że program w C++ będzie generalnie wolniejszy. Idąc twoim tropem trzeba by było powiedzieć, że programy w pascalu będą biły C na głowę pod względem szybkości, bo fpc kompiluje paskalowe programy dosłownie w mgnieniu oka.
> (np. ostatnio pod DirectX, którego API jest w zasadzie zrobione
> pod kątem C++, a raczej programowania obiektowego w ogóle).
Jego API, jak i cały COM, to czyste, lekko ograniczone C++ (tylko metody wirtualne, jednokrotne dziedziczenie, interfejsy do obiektów będące czysto wirtualnymi klasami C++). Jak widzisz, da się tego używać bezstresowo w C.
> Częściowo bierze się to z tąd, że lubię wiedzieć co dokładnie
> robi procesor, takie "analityczne" podejście do programowania.
Może podniesie Cię troche na duchu to, że przez wiele wiele lat programowałem tylko i wyłącznie w assemblerze, gardząc wszelkimi innymi językami.
PS. Taka mała uwaga. Spora część programistów żyje w błednym przekonaniu, że C++ jest wolniejsze niż C, że binarki będą większe, że C++ się do pisania systemów operacyjnych nie nadaje. A co potem mamy? Systemy operacyjne których autorzy tworzą sobie na siłe zręby obiektowości w całkiem nieobiektowych językach (AmigaOS i Linux starają się być obiektowe). Tracą na tym gmatwając kod źródłowy i czyniąc go mniej czytelnym, a nie zyskują przy tym nic poza samą obiektowością - to samo mogli by zrobić w C++. Tak samo wydajny kod, mniej skomplikowana składnia.