Czy ktoś jeszcze programuje w czystym

Witam wszystkich,

Pytam o to, bo coraz mniej jest osób, którym chce się posiedzieć i napisać naprawdę stabilną aplikację wszyscy lecą na ObjectPascal albo C++ a tam************aplikacje są tak dziurawe, że po ich zakończeniu w systemie pozostaje tyle śmieci...

Z tego co mi wiadomo (chociaż tym się za dużo nie interesuję) to większość jeśli nie wszystkie stacje graficzne (Silicon Graphics) zostały napisane w C.

Aktualnie piszę pakiet aplikacji pod Wina w czystym C i jak się okazuje zajmuje (jak na razie) niecałe 500kB, a projekt jest naprawdę rozbudowany, a jak wiadomo ta wielkość rozkłada się na szybkość i stabilność. Np. jeśli mamy potężny zestaw klas VCL albo MFC i załóżmy (to tylko przykład), że w klasie CObject albo TObject jest błąd (niewielki błąd, np. jakaś własność jest niepoprawnie niszczona) to aplikacja powstała z tych klas to... nadaje się tylko do wyrzucenia... bo wtedy żaden system się nie uchroni przed jej niepoprawnym zamknięciem i utratą danych.

Oczywiście każdy programuje w czym chce i niech tak pozostanie, ale czasem niech pomyśli, że nie zawsze co nowe jest w 100% dobre. Dla mnie C nie potrzeba było rozbudowywać do C++, sam C chodził bardzo dobrze.

Pozdrawiam wszystkich,
kerim

To nie chodzi o to , że ludzie wolą c++ bo jest nowsze od c . Jakiś czas temu przy pisaniu dosyć potęznych programów w C robiło sie troche komplikacji , był problem z rozwiązaniem niektórych złożonych problemów , ogromne problemy z modernizacją i wprowadzaniem zmian . Więc wymyślono programowanie obiektowe , ja uważam , ze programowanie obiektowe jest 1000 razy bardziej wydajne i wygodne od strukturalnego . Raz napiszesz klase wzorcową i korzystasz z niej w każdym programie , zalet jest mnóstwo . Pamiętam jak napisałem niedawno mój pierwszy większy program ( jakieś 8 miechów temu ) , był to wąż w bgi , miał tryb dla 2 graczy , opcje gry z komputerem ( do dzisiaj nikt z nim nie wygrał ;D ) , coraz bardziej ulepszałem tą gre , dodawałem coś i zmieniałem , w końcu kod miał 3000 linii i był w nim tak straszny burdel że głowa boli , a wszystko dlatego że programowałem strukturalnie . Jestem przekonany ze gdybym zrobil to na klasach to nie byloby porównania . Oczywiscie duzy wplyw na balagan mialo to ze dopiero zaczynalem programowac wtedy .
Ja to widze tak , wiekszy projekt pisany strukturalnie i potem zmieniany i uaktualniany , to jak dobudowywanie nowych pięter to powoli walącego sie wierzowca , a gdyby zrobić konstrukcje tego wierzowca obiektowo na klasach , to piętra można by dobudowywac w nieskończoność i zmieniać wszystko bez rzadnej utraty porządku i wydajności .
Oczywiście to wszystko są opinie kogoś kto nie ma zbyt dużego doświadczenia w programowaniu .

1. Prawdopodobieństwo, że ty zrobisz błąd roszerzając istniejące mechanizmy dla własnych potrzeb, jest nieporównywalnie większe, niż to, że taki błąd zostawnie zrobiony w projekcie kompilatora, nad którym pracują dziesiątki ludzi i który jak żaden inny program nie jest sprawdzany tak dokładnie. Prawdopodobieństwo znalezienia błędu u podstaw kompilatora (nie mówię o tych wszystkich dodatkowych modułach) jest bardzo małe, ponieważ od tego oprogramowania zależy działanie milionów innych programów. To zbyt wysoka cena, żeby móc wypuszczać na rynek źle działąjący kompilator. Oczywiście błędy się zdarzają. W każdym programie dłuższym niż 3 linijki, jest błąd :)
2. Chcesz naprawdę mały kod i pewność, że jeżeli wystąpi jakiś bład to będzie wyłącznie z twojej winy? Weź się za assemblera.
3. Wiesz dlaczego informatyki uczą na politechnikach (oprócz uniwerków). Ponieważ informatyka jest dziedziną inżynierską. Program może nie być poprawny dla wszystkich danych wejściowych, ale dla najbardziej prawdopodobnych ma być niezawodny. Most nie musi wytrzymywać każdego obciążenia i każdych warunków atmosferycznych, ale musi być bezpieczny, dla założonych naprężeń. Zwykle nie warto komplikować programu tylko po to, by był poprawny dla każdych danych, a to powodowałoby np. spowolnienie jego działania lub, co aktualnie ma znacznie większe znaczenie, opóźniałoby czas premiery produktu. Narzędzia wizualne nie są dobre dlatego, że umożliwiają stworzyć mały i szybki kod ;-) ale dlatego, że umożliwiają stworzyć program szybko. Języki obiektowe zostały wprowadzone m. in. dlatego, że dziedziczenie znacząco przyspiesza tworzenie oprogramowania.

1. Prawdopodobieństwo, że ty zrobisz błąd roszerzając istniejące mechanizmy dla własnych potrzeb, jest nieporównywalnie większe, niż to, że taki błąd zostanie zrobiony w projekcie kompilatora, nad którym pracują dziesiątki ludzi i który jak żaden inny program nie jest sprawdzany tak dokładnie.

Ale nie pisałem o kompilatorze... pisałem o bibliotekach klas tj. VCL (Borland) i MFC (Microsoft) czy też WŁASNYCH (właśnie) stworzonych dla potrzeb danego programu... Kompilator jak wiadomo musi być bezbłędny, jednak z klasami "doczepionymi" do niego niekoniecznie tak jest. To są tylko moje przypuszczenia, że błąd taki może powstać, ale jeśli jest to może narobić sporego bałagan.

2. Chcesz naprawdę mały kod i pewność, że jeżeli wystąpi jakiś bład to będzie wyłącznie z twojej winy? Weź się za assemblera.

Assembler - czemu nie...? :) Dla mikroprocesorów jest w sam raz! Korzystam z niego zawsze dla tych małych platform sprzętowych... ;)

3. (...) Języki obiektowe zostały wprowadzone m. in. dlatego, że dziedziczenie znacząco przyspiesza tworzenie oprogramowania.

Właśnie! Przyspiesza tworzenie oprogramowania, ale nie zawsze jego uruchamianie...

A teraz pytanko (pytam się tylko z ciekawości): czy ktoś z Was wykorzystał swoją klasę (podstawową tj. np. z pierwszej wersji programu) aby stworzyć nową klasę w oparciu o tą starą wykorzystując dziedziczenie. Czy też było tak, że klasa była rozbudowywana poprzez modyfikację kodów funkcji klasy?

Bezpośrednio do pytania z tematu: TAK. Na przykład ja... :)
Coprawda nie jestem w C dobry (właściwie to dopiero się uczę), ale programowałem w Turbo Pascalu przez jakieś 12 z dotychczasowych 17 lat życia, i naprawdę jest o wiele lepszy (no... z wyjątkami) od Delphi...
Jeśli chodzi o te "wyjątki" to jest jedna rzecz, której mi w TP naprawdę brakowało (właściwie jedyny powód, dla którego piszę w Delphi od czasu do czasu) - obsługi sieci... poza tym i tak wolę tryb tekstowy (nawet pisząc w Delphi ze względu na obsługę sieci piszę w miare możliwości aplikacje konsolowe). Za to w Delphi jest jeden problem... Niby ten windows jest wielozadaniowy, ale już program pod niego napisany, nie może dwóch rzeczy naraz robić... :(

Zarzucasz że aplikacje tworzone obiektowo, nie strukturalnie są duże, pamięciochłonne itp itd..
Czy w dobie procesorób o taktowaniu 3 Ghz, dysków twardych powyżej 40 GB, pamięci RAM sięgającej 512 mega [my mistake] ma to znaczenie??

Zamysłem twórców Buildera czy Delphi było stworzenie środowiska RAD, czyli Rapid Application Development..Budowanie aplikacji z gotowych klocków, nie wnikając w ich strukturę (komponenty)

Nie neguję potrzeby pisania w czystym C, ale jeżeli pracowałbym jako programista i musiałbym wykonać program (nie ważne w czym,byleby spełniał wymogi) to bez wahania użyłbym Delphi or Buildera..i założę się że bym zrobił go szybciej od Ciebie (zakładając że byśmy mieli identyczny poziom wiedzy)..

Tak więc reasumując jestem za Builderem czy Delphi...

(...)Za to w Delphi jest jeden problem... Niby ten windows jest wielozadaniowy, ale już program pod niego napisany, [b]nie może dwóch rzeczy naraz robić... [/b]:(

Poczytaj sobie o wątkach... To nie będziesz mi tu bzdur gadał :)

(...)pamięci RAM sięgającej [b]512 kilo [/b]ma to znaczenie??

512 kilo? Oj, troche mało :)
Przypomniał mi się cytat: "640 KB pamięci powinno wystarczyć każdemu" - Bill Gates, 1981 :)

Koniec z komentowaniem cytatów. Przejdźmy do głównego wątku.
Czy łatwiej jest się połapać w skomplikowanym kodzie bez wykorzystania klas i mechanizmów "wyższych" języków? Weźmy na przykład PHP. Bez wykorzystania klas dostęp do baz danych jest możliwy i bardzo prosty, ale każdy skrypt musi zawierać polecenia otwarcia bazy, z hasłem, nazwą użytkownika itp. Możemy zrobić klasę realizującą połączenie z wpisanymi już bezpośrednio danymi i wyborem bazy na serwerze. I jest znacznie prościej i czytelniej.

[Dopisek] 700 post

Witka,

No wlasnie, komputery sa coraz lepsze, wydajniejsze... a programy rosna i rosna i rosna i chodzą wciaz tak samo... A gdyby byly bardziej zoptymalizowane to i sprzet bylby wystarczajacy, ale... wlasnie taki jest rynek - trzeba tworzyc programy bardziej "powolne" ;) aby klient chcial kupic nowy sprzet... i kolko sie zamyka. ;)

Ja nie narzekam na programowanie strukturalne bardzo latwo i prosto mozna napisac program, nawet rozbudowany i jakos nie mam problemu z jego rozbudowaniem...

A teraz pytanko PO RAZ DRUGI (pytam się tylko z ciekawości): czy ktoś z Was wykorzystał swoją klasę (podstawową tj. np. z pierwszej wersji programu) aby stworzyć nową klasę w oparciu o tą starą wykorzystując dziedziczenie. Czy też było tak, że klasa była rozbudowywana poprzez modyfikację kodów funkcji klasy?

A teraz pytanko PO RAZ DRUGI [- cut -]

Ja nie, ale planuje to zrobić.

Zadam inne pytanie: czy ktoś z Was kiedyś wykorzystał klasę zrobioną przez kogoś innego i ją rozszerzył stosując dziedziczenie, czy raczej zmienił ją samą (np: TForm)??

Ja nie, ale planuje to zrobić.

Ja nie i na razie nie planuję.

Zadam inne pytanie: czy ktoś z Was kiedyś wykorzystał klasę zrobioną przez kogoś innego i ją rozszerzył stosując dziedziczenie, czy raczej zmienił ją samą (np: TForm)??

Oczywiście, że tak. Często to robię, nie koniecznie tworząc nowe komponenty, oddzielne moduły. A jeżeli chodzi osamo TForm, to przecież robi się to automatycznie z każdą nową aplikacją :)

Programowanie obiektowe tylko teoretycznie jest błednym rozwiązanie. tak na prowdę to nie dość iż może być łatwiejsze od standardowego, to na dodatek wystarczy obsłużyć extremalne możliwości (przegladając msdn doszedłem do wniosku że tego jest nie tak dużo, z czego mniej niż 10% ma jakikolwiek wpływ na alpkację). Ogólnie rzecz biorąc aby programy obiektowe były równie szybkie co "czyste" wystarczy dobrze programować. Powodzonka w czystym i obsłudze naprawdę zaawansowanych kombinacji systemowych...

A teraz pytanko PO RAZ DRUGI (pytam się tylko z ciekawości): czy ktoś z Was wykorzystał swoją klasę (podstawową tj. np. z pierwszej wersji programu) aby stworzyć nową klasę w oparciu o tą starą wykorzystując dziedziczenie. Czy też było tak, że klasa była rozbudowywana poprzez modyfikację kodów funkcji klasy?

raczej modyfikowałem kod klasy , ale jestem święcie przekonany , że dziedziczenie w komercyjnych=dużych programach ma ogromne zastosowania , a do tego np w VC++ wszystkie tworzone aplikacje na tym sie opierają .

Oczywiście, że tak. Często to robię, nie koniecznie tworząc nowe komponenty, oddzielne moduły. A jeżeli chodzi osamo TForm, to przecież robi się to automatycznie z każdą nową aplikacją (...)

A czy rozbudowywałeś (tzn. tworzyłeś nową poprzez dziedziczenie) tą automatycznie tworzoną formę po raz drugi??

A czy, jeżeli ktokolwiek z was pisał nową kontrolkę, robił to korzystająć z obiektów i dziedziczenia z TWinControl, czy raczej pisał w 'czystym' WinAPI i tworzył dziesiątki procedur, które już ktoś kiedyś zrobił i z których mógł korzystać?

Ad. pyt. kerima: Raz. I to przez przypadek. Bawiłem się własnością Owner i Parent w Delphi. Tworzyłem nowe okno-kopię starego, którego rodzicem było to, którego było kopią. Potem dorzucałem kolejny przycisk i tworzyłem kolejną kopię tego co było. Ale to tylko dla zabawy :)
Ad. pyt. Vogel'a: Nie jestem samobójcą. Jeżeli mam już pisać w czystym API, to muszę mieć naprawdę ważne powody, żeby rezygnować z wygody Delphi. Ale niedawno czytałem sobie arta o programowaniu obiektowym w asm, więc kto wie...

Dryobates: co do robienia obiektowości w asmie... Od pewnego czasu też noszę się z zamiarem dorobienia bibliotek do na przykład C, emulujących obiektowość :)