Witam, niektórzy (na pewno wielu z was) polecają jako kolejny jezyk programowania po C++ - C. Rozumiałbym przejscie w drugą strone: C --> C++. Ale co jest takiego w C czego nie ma w C++ ?? Np. jądra systemów operacyjnych chyba najczesciej pisane były w C. Dlaczego ?? Przecież C++ umozliwia programowanie OO...
Rozumiem rozległe zalety asemblera ale raczej nie bede w stanie sie go nauczyć. Tzn. nauka jak nauka ale nie wiem czy potrafie zejść na tak "niski poziom" ;-) .
Poznałem Jave ale wracam z powrotem do cpp. Czyli jednak poziom abstrakcji cpp jest dla mnie odpowiedni.
Domyślam sie że C pozwala na szybsze działanie programu ale prosze o wyjasnienie mi w jaki sposob.
Pzdr
0
0
E. Tak, moim zdaniem nauka C++ po C to jest totalny bezsens. Bo jeśli dopiero uczysz się C, to znaczy, ze wcale nie znasz C++.
Programowanie obiektowe jest moim skromnym zdaniem zbędne w przypadki systemów operacyjnych. Obiektowość mi by tam przeszkadzała. STL nie jest wcale taki efektywny, a C jest mimo wszystko szybsze... Ale C++ też ma pełno zalet, podobno ;)
Ja używam jakoś tak zamiennie, zależy do czego.
0
Najważniejszym czynnikiem dlaczego C jest tak popularny jest jego szybkość. Obiektowość ma pełno zalet, jest wygodna itd. ale wolniejsza od programowania strukturalnego. A w systemach operayjnych jedną z ważniejszych cech jest szybkość. To samo się tyczy wszelkich mikrokontrolerów czy systemów wbudowanych, gdzie króluje C.
0
zamknanc temat bo wojna bedzie [diabel]
0
amadeo napisał(a)
Obiektowość ma pełno zalet, jest wygodna itd. ale wolniejsza od programowania strukturalnego.
No ale przecież w cpp mozna programować bez uzycia klas wiec nie rozumiem. Też słyszałem że C jest szybszy i tu pada moje pytanie: dzięki czemu jest szybszy ??
cepa napisał(a)
zamknanc temat bo wojna bedzie [diabel]
Bin Laden to moje drugie ja ;-P
0
Jak znasz C++ to nie musisz się uczyć C. Wystarczy się, że tak powiem ograniczyć.
kita napisał(a)
No ale przecież w cpp mozna programować bez uzycia klas wiec nie rozumiem
Ale po co pisać w C++ bez korzystania z jego obiektowości??? Jak nie potrzebujesz obiektowości to pisz w C.
kita napisał(a)
dzięki czemu jest szybszy ??
Właśnie dla tego, że nie jest obiektowy.
Bez sensu jest pisać w C++ program nie obiektowy i bez korzystania ze standardowej biblioteki, a to wszystko niestety spowalnia działanie programu i jego kompilowanie.
0
No wiesz, z STLa i obiektowosci i tak nie skorzystasz piszac OSa bo musial bys miec zaimplementowane takie rzeczy jak new, delete itepe, sam C++ za Ciebie tego nie zrobi :)
0
Wolverine napisał(a)
No wiesz, z STLa i obiektowosci i tak nie skorzystasz piszac OSa bo musial bys miec zaimplementowane takie rzeczy jak new, delete
Te operatory da się przeciążyć więc tu problemu nie widzę :P Co innego obsługa wyjątków, ale... to można sobie darować ;)
0
amadeo napisał(a)
Najważniejszym czynnikiem dlaczego C jest tak popularny jest jego szybkość. Obiektowość ma pełno zalet, jest wygodna itd. ale wolniejsza od programowania strukturalnego. A w systemach operayjnych jedną z ważniejszych cech jest szybkość. To samo się tyczy wszelkich mikrokontrolerów czy systemów wbudowanych, gdzie króluje C.
[rotfl] tyle powiem - jak kompilator nie zawali sprawy a programista jest dobry to programy obiektowe wcale wolniejsze czy większe nie są. Szczególnie jeżeli o szablony chodzi... temat do kasacji bo wojna będzie. Kiedyś jak byłem młody i głupi tez twierdziłem, że C szybsze i mniejsze od C++ ale po latach pisania w obu i RE doszedłem do innych wniosków. W C tak czy inaczej używa się obiektowości przekazując wskaźniki do struktur itd. Sprawa przedstawia się tak, że 'ręczna' obiektowość nie daje takich możliwości programiście i kompilatorowi. Obiektowość trzeba jednak stosować z umiarem /czytaj VCL/. EOT.
0
deus napisał(a)
Sprawa przedstawia się tak, że 'ręczna' obiektowość nie daje takich możliwości programiście i kompilatorowi. Obiektowość trzeba jednak stosować z umiarem /czytaj VCL/. EOT.
Baa... Na ręcznej obiektowości mogę sobie w czasie działania programu delegacje metod bez problemu przenosić i obiekty morfować w inne ;)
//WOOOOOOOOOOOOOOOOOOOW, Vogel!! Czy to jakiś prima aprylis? :D - M
// o ja ... :) [mf]
0
Ok, dzieki za odpowiedzi - teraz wiem że jesli sie cofać to tylko do asm. :-)
0
E... Po ki logia... Kurde, im więcej języków znasz tym masz większe szanse, abo bardziej zasłany umysł. Tak czy siak z C++ do asm to ciut daleko...
0
kita napisał(a)
Ok, dzieki za odpowiedzi - teraz wiem że jesli sie cofać to tylko do asm. :-)
a pozniej lamenty ze mi sie program sypie bo sie wskaznikow uzywac nie umie, alokowanie pamieci lezy albo zapomina o terminatorach itp...
0
To może ja dorzucę swoje 3 grosze.
C jest starszy od C++, ale jednocześnie C jest podzbiorem C++. Oznacza to że pisząc w C piszemy w wydzielonym kawałku C++.
Problem "co pierwsze do nauki" leży raczej w zakresie materiału. Jeżeli weźmiemy się od razu za C++ to już w góra 3 rozdziale trafimy na jego wysokość Obiekt. Zajmiemy się zgłębianiem tajemnic OOP i przez następne 30 rozdziałów będziemy omawiać różne aspekty tegoż. Jeżeli weźmiemy się za C to od 3 rozdziału zaczniemy zabawę z algorytmami. Napiszemy własnego quicksorta i mergesorta. Zapewne poznamy urok wyszukiwania binarnego itp. W nauce C znacznie większy nacisk kładzie się na poznanie algorytmów, a w nauce C++ na poznanie zasad projektowania i architektury aplikacji.
Co do pytania postawionego przez kita. Program napisany sekwencyjnie jest zawsze szybszy niż napisany obiektowo. Wynika to z tego że obiekt musi być tworzony i dopiero później można z niego korzystać. Jednak przy większych programach obiektowość zaoszczędzi ci ci czas na etapie pisania kodu, jego testowania, wdrożenia i serwisowania. Dużo zależy od skali projektu.
0
zara jakie algorytmy co ma piernik do wiatraka? [???] C i C++ to jezyki zgodze sie ze C mozna zawrzec w C++ ale obiektowosc tez nie ma nic do rzeczy bo programowanie obiektowe jest niezalezne od jezyka i mozna sie w to bawic zarowno w C++ jak i w C tyle ze C++ posiada do tego natywne wsparcie, a co do nauki to nie mieszaj algorytmiki z jezykiem bo algorytmy mozna pisac i tworzyc nie znajac zadnego jezyka programowania a sam jezyk to tylko jedna z wielu technologii...
0
cepa napisał(a)
a pozniej lamenty ze mi sie program sypie bo sie wskaznikow uzywac nie umie, alokowanie pamieci lezy albo zapomina o terminatorach itp...
Popieram!
C++ daje duże możliwości programiście, ale w C nauczysz się skąd to wszystko się bierze. Warto przynajmniej raz napisać sobie tablicę dwuwymiarową, korzystając jedynie ze wskaźników ;-)
0
Wiecie co? Poświęćcie kilka lat na naukę asemblera i piszcie obiektowo w asm - kod będzie szybszy od tego w C jak się postaracie... Mitu, że obiektowość jest wolna raczej nie obalę ale powiem coś innego: większość sądzi, że jak pisanie w assemblerze to tylko DOS tymczasem w asm pisze się znacznie prościej pod windowsem czy linuksem...
Nie C uczy działania procesora\komputera a właśnie asm, dopiero w asm widać jak działają wskaźniki czy operacje na pamięci. Ale bez tego można się obyć w naszych czasach - od czego HLL /C++ czy C to MLL/, w C#, javie czy pythonie nie używa się wskaźników /są może nieliczne wyjątki/, nie dba się o zwalnianie obiektów... Niby każdy programista powinien być po części elektronikiem ale... ostatnio odnoszę wrażenie, że te czasy odchodzą...
0
cepa napisał(a)
a pozniej lamenty ze mi sie program sypie bo sie wskaznikow uzywac nie umie, alokowanie pamieci lezy albo zapomina o terminatorach itp...
Umiem cpp, i wskaźniki także. Może nie wiem jak działają wewnetrzne trybiki komputera ale własnie po to chciałbym w przyszłości nauczyć sie asemblera. Nie rozumiem teraz twojego lamentu...
KoRbI napisał(a)
C++ daje duże możliwości programiście, ale w C nauczysz się skąd to wszystko się bierze.
Niby dzieki czemu ?? Co w C umożliwi mi to ??
Ogólnie chodzi mi o to że poszedłem troszke o level wyżej i poznałem jave. Jej przenośność jak <ort>na razie</ort> do mnie nie trafia bo nie musze pisać programów przenośnych. Wiec teraz chciałbym spróbować iść o poziom niżej wiec spytałem czy warto nawet rozgraniczać C od C++. Pierwsze odpowiedzi jakby 'odradzały' poznawanie C (bynajmniej ja tak to odebrałem) wiec napisalem zdanie podsumowujące że jesli już to asma. I tyle...
0
nie da sie byc programista C++ bez znajomosci C :P bo poki masz stl to ci sie wydaje ze umiesz wszystko ale gorzej jak nagle trzeba bedzie samemu ruszyc glowa i sie zaczna schody...
0
cepa napisał(a)
zara jakie algorytmy co ma piernik do wiatraka? [???]
.....
algorytmiki z jezykiem bo algorytmy mozna pisac i tworzyc nie znajac zadnego jezyka programowania a sam jezyk to tylko jedna z wielu technologii...
Dobra nieprecyzyjnie sie wyraziłem. W C i C++ jest inna metodyka nauczania. Kursy C wbijają ci do głowy podstawy języka, a potem przechodzą do algorytmiki lub metod numerycznych względnie pisania sterowników do elektroniki. W C++ i każdym innym języku umożliwiającym OOP po zapoznaniu się ze składnią przechodzisz do "zagadnień obiektowych" czyli wzorców, architektury czy projektowania procesów biznesowych.
Jest trochę inne podejście. Jak zaczynałem się uczyć na studiach programowania to najpierw zrobiono mi krzywdę ucząc Javy i następnie wysyłając na kurs FORTRANa. Z pierwszego nic nie wyniosłem poza umiejętnością konfiguracji Q1 pod Fedore. Na drugim nauczyłem się podstaw programowania w zakresie, który umożliwił mi późniejszą naukę C++ (w zasadzie obecną) i Javy (już ze zrozumieniem i dobrym rezultatem). Co więcej nie miałem problemów
Możesz się z tym nie zgodzić, ale mam takie dziwne uczucie, że nauka C jest nastawione na trochę inne zagadnienia niż C++ (generalnie OOP).
edit;
@cepa ten ostatni twój post to jest coś o czym też myślałem. Nauka OOP bez znajomości "klasycznego" programowania to dla mnie zbrodnia.
0
ja miałem to szczęście, że najpierw uczyłem się C. dzięki temu łatwiej mi było zrozumieć C++, którego byłem w stanie się nauczyć samemu. z drugiej strony trochę czasu mi zajęło, żeby przestawić się na obiektowe myślenie.
rzeczywiście najpierw warto uczyć się klasycznego podejścia do programowania, a potem dopiero obiektowości. z resztą nie dotyczy to tylko C/C++, ale też Pascal/Delphi i innych.
0
Ja uczyłem się od razu C++ i jakoś problemów ze zrozumieniem go nie miałem ;)
cepa napisał(a)
nie da sie byc programista C++ bez znajomosci C :P bo poki masz stl to ci sie wydaje ze umiesz wszystko ale gorzej jak nagle trzeba bedzie samemu ruszyc glowa i sie zaczna schody...
Nie widzę problemu w napisaniu sobie własnych klas / funkcji jak komuś w stl'u za mało / są kiepskie ;) (np. vector jest bezużyteczny - nadaje się w sumie tylko do trzymania przez wartość klas posiadających i potrzebujących własnych konstruktorów kopiujących i destruktorów, (wywoływanie kk i destruktorów przy wstawianiu i usuwaniu elementów co powoduje całkiem spory narzut) w dodatku odwołujących się przez wskaźniki do własnych zmiennych automatycznych (wywoływanie kk przy realokacji) co jest imho kompletnym bezsensem, nawet jak kto ma takie klasy to raczej nie będzie ich przechowywał przez wartość, tak jak i 'normalnych' klas - narzut przy realokacji praktycznie wymusza przechowywanie ich przez wskaźnik. Z kolei wskaźników (czy też typów wbudowanych / prostych klas) też nie opłaca się przechowywać z powodu narzutu przy wstawianiu i kopiowaniu. :/)
0
Ta dyskusja jest bez sensu..
Jeżeli ktoś jest dobry, nauczy się algorytmiki na każdym języku, a i programowanie obiektowe łyknie bez problemu. Tak samo dla dobrego programisty nie będzie miało znaczenie czego uczył się najpierw i będzie umiał wybrać język który do danego projektu będzie najlepszy.
Takie wasze "C jest szybszy bo coś tam" to też trochę czcza gadanina.. i tak w krytycznym miejscu programu ostateczne słowo będzie miał kompilator a nie programista (o ile programista nie użyje asma, oczywiście). Wątpię aby dzisiejsze kompilatory generowały lepszy (szybszy) kod dla C niż dla C++.
Tak mi się przynajmniej wydaje, jeśli jest inaczej proszę przedstawić jakieś dowody w postaci Benhmarków czy czegoś :P peace
0
Obiektowość jest wolniejsza i to nie jest żaden mit. Prawdą jest również, że i tak algorytm jest najważniejszy. Ale różnice w wydajności między obiektowością a programowaniem strukturalnym wychodzą dopiero przy na prawdę dużych danych. Kiedyś testowałem w C++ goły vector jako stos oraz z nakładką std::stack również oparty na vectorze. Przy milionie danych wejściowych program z interfejsem stack było wolniejszy około 0.5s. To może trochę dziwić bo w SPACJA końcu std::stack jest robiony na szablonie. Różnica niewielkie, zwłaszcza, że milion danych wejściowych to był naprawdę skrajny przypadek, ale nie można mówić, że nie ma kompletnie żadnej różnicy. Oczywiście zalety obiektowości całkowicie rekompensują małą stratę wydajności w zwykłych aplikacjach natomiast w programowaniu OSów każdy takt jest ważny. Do tego obiekty nie przydają się aż tak, skoro i tak działa się na nsikim poziomie.
0
Amen.
// można by tak skończyć, bo sie czytać nie chce
0
Kooba napisał(a)
Takie wasze "C jest szybszy bo coś tam" to też trochę czcza gadanina.. i tak w krytycznym miejscu programu ostateczne słowo będzie miał kompilator a nie programista (o ile programista nie użyje asma, oczywiście). Wątpię aby dzisiejsze kompilatory generowały lepszy (szybszy) kod dla C niż dla C++.
Tutaj Kooba ma rację. Szybkość działania kodu wynikowego zależy od kompilatora, oczywiście algorytmiczne umiejętności programisty tutaj pomijam. Odwiecznym problemem kompilatorów jest to które zmienne przechowywać w rejestrach mikroprocesora i ciągów których instrukcji użyć do określonego zadania. Na tym polu jest jeszcze wiele do zrobienia. Są przypadki że fragment kodu napisanego w C lub C++ da się przyśpieszyć przy pomocy Assemblera nawet kilkakrotnie ( tutaj kompilator nie podskoczy do kodera, dobrodziejstwo naszych neuronów mózgowych i intuicji ). Z założenia programowanie obiektowe daje mniej efektywny kod wynikowy ponieważ metody obiektów muszą być wywoływane w nieco inny, wolniejszy sposób. Ale to tylko drobnostki. Tak więc, czy szybszy kod dają kompilatory C czy C++ to zależy od ekipy która ten kompilator zrobiła. Nie wykluczone że niektóre kompilatory PASCALA mają większy but niż C.
DzieX napisał(a)
Amen.
// można by tak skończyć, bo sie czytać nie chce
Nikt Ci nie każe czytać.
0
Z założenia programowanie obiektowe daje mniej efektywny kod wynikowy ponieważ metody obiektów muszą być wywoływane w nieco inny, wolniejszy sposó
Dowody, dowody! Jak masz jakieś operację na strukturach przez zewnętrzne funkcje a na klasach poprzez metody to dobry kompilator wygeneruje lepszą formę wywołań dla kodu obiektowego... ale co się będę sprzeczał, czekam na dowody...
0
Dowód? Chociażby funkcje wirtualne, które nie mogą być rozwijane w miejscu wywołania. Różnicę widać gdy taka funkcja jest nie za długa i wywołuje się ją wiele razy.
0
[rotfl]... a wskaźniki na funkcje w C możesz rozwijać? Gratuluję fanatyzmu... i krótkowzroczności...
0
[rotfl] No to faktycznie porównanie walnąłeś z tymi wskaźnikami. Radzę się najpierw zastanowić kiedy w programowaniu strukturalnym stosuje się wskaźniki na funkcję a kiedy w programowaniu obiektowym wykorzystuje metody wirtualne. I zadaj sobie pytanie czy te sytuacje się pokrywają.
A kto tu jest fanatykiem, pozostawię ocenę innym użytkownikom...