C, C++, C# ...

[Gość: Slawek]

... jaka jest róznica pomedzy nimi? I jeszcze ktoś mógłby powiedziec o róznicy
między Unixem a Linuxem :))))))))))))) Dzięki ...

[tiges_wiz]

wszystko znajdziesz na www.google.pl

[Gość: Kokeeno]

W skrócie:
- c - dobry język strukturalny, który pozwalał na tyle samo co pascal, ale: był
ustandaryzowany i wiele rzeczy było łatwiejsze do wykonania (czasem
skompilowany program był szybszy, czasem wolniejszy niż analogiczny w c),
- c++ - to "w zasadzie" c rozszerzony o mechanizmy obiektowości, jest bardziej
restrykcyjny, jeśli chodzi o typizację (ale do ady mu jeszcze daleko), nadal
brakuje wbudowanych w język mechanizmów wielowątkowości,
- si szarp - cóż, taka java, tylko inaczej - framework, wielowątkowość, ale
utrata prędkości wykonywanego programu...

[Gość: fdd-maniak]

> c - dobry język strukturalny, który pozwalał na tyle samo co pascal, ale: był

Że co??? Pokaż mi jakiś skomplikowany program napisany w Pascalu. Ja natomiast
przypomnę, że jądro systemu operacyjnego, z którego korzystasz, zostało napisane
w C.

>ustandaryzowany i wiele rzeczy było łatwiejsze do wykonania (czasem

To raczej Pascal był pomyślany jako prosty język do nauki programowania jako
takiego i do przedstawiania algorytmów.

>skompilowany program był szybszy, czasem wolniejszy niż analogiczny w c),

Raczysz żartować. Kiedyś zakodowałem pewien blok w czystym assemblerze (chodziło
o algorytm rysowania trójkąta) i dla porównania przepisałem ten sam kod w C,
który skompilowałem potem w DJGPP (DOSowa wersja GCC). Efekt? Program w C był
dużo szybszy. DJGPP znacznie lepiej optymalizuje kod niż zrobiłby to koder
programując "ręcznie" w assemblerze. Zestawienie kompilatorów Pascalowych z
kompilatorami C możemy już sobie odpuścić.

[kell99]

wg mnie piekno c wynika z prostoty jezyka. jest to jeden z najprzyjemniejszych
jezykow, programista ma duza kontrole nad programem, co w jezykach obiektowych
czasem jest trudne przy duzej abstrakcji. c dzieki bibliotekom ma tez pewne
elementy obiektow.

c++ to jezyk obiektowy, ktory zachowuje sporo prostoty z c, jednak wiele osob
sadzi, ze poprzez dostep do wskaznikow i spore skomplikowanie niektorych rzeczy
(wzorce) jezyk sie troche zdezaktualizowal (jak na nowoczesny jezyk obiektowy).

c# to microsoftowa kopia javy. skoro nie dalo sie zniszczyc javy poprzez
tworzenie niekompatybilnych z nia wersji, to trzeba bylo zmienic nazwe;) jezyk
ciekawy, ale dostepny tylko dla windows (wg mnie mono i .net to sa 2 rozne
rzeczy, nie wierze, ze microsoft bedzie gral czysto i predzej czy pozniej
pojawia sie grozby patentowe ktore zniszcza mono). programy .net/mono wydaja sie
dosyc "przyciezkawe", zajmuja mase pamieci.

z tych 3ch to osobiscie programista musi dobrze znac c. a dalej to bym sie zajal
java bo 1) platofma calkowicie darmowa, do wyboru sdk albo gjc 2) eclipse i
netbeans to prawie doskonale IDE, .net jest drogie i nie warte by sie pobawic w
programowanie, ew. zostaje mono+linuks

[Gość: ja]

> wg mnie mono i .net to sa 2 rozne
> rzeczy, nie wierze, ze microsoft bedzie gral czysto i predzej czy pozniej
> pojawia sie grozby patentowe ktore zniszcza mono.
Novell nalezy do OIN i Mono jest jednym z projektów które OIN chroni. Z tego co
wiem jedną z zasad obowiązujących w grupie jest, że jeżeli któryś projekt
zostanie zaatakowany pozwami patentowymi czlonkowie OIN moga wykorzystac
wszystkie patenty ktróre posiadają i "odpowiedzieć ogniem"
www.openinventionnetwork.com/press.html
Większość rzeczy zaimplementowanych w Mono związanyc z .NET to rzeczy które
zostały ustandaryzowane przez MS i trudno w tym momencie mówić o jakiś patentach.
www.mono-project.com/ECMA
Z punktu widzenia użytkowników Linuksa rozwój Mono jest ważny bo pozwala szybko
tworzyć(szybciej niż w C/C++) aplikację które dobrze integrują sie z
środowiskiem (GTK# lub QT#).

> programy .net/mono wydaja sie
> dosyc "przyciezkawe", zajmuja mase pamieci.
Java tez do najlzejszych nie nalezy:)

[Gość: anton]

Ten C# zdominuje C++ za kilka lat, czy też MS wymyśli jeszcze coś innego?
A a ta java to trochę ciężkava - 60MB zajmuje nawet mini programik.

[Gość: ja]

> Ten C# zdominuje C++ za kilka lat, czy też MS wymyśli jeszcze coś innego?
Ci co probowali w informatyce przewidywac na kilka lat do przodu pobankrutowali
na dotcomach:). C++ nadal się mocno trzyma i raczej nie zanosi się, że C# miało
mu zagrozic. Przeciez nawet w Viscie malo jest .NETu.

[Gość: marcin_ktos]

Nie tak znowu mało. Wszystko, co będzie pisane pod WinFX (WPF i WCF) będzie
korzystało jednocześnie z .NET. Tak samo pewnie będzie z systemem plików WinFS.
A jak za 10 lat przyjdzie następca Visty, to on już będzie praktycznie cały w
.NET :-)

Gdyby nawet C++ miało zostać wyparte na szerokim rynku przez .NET (czy to w
postaci C#, czy C++.NET czy czegokolwiek innnego) to zawsze zostanie dla niego
jakaś nisza - jak dzisiaj dla COBOL-a czy Pascala :-)

[kell99]

wyparcie c/c++ przez c# to sa bardziej pobozne zyczenia niz rzeczywistowsc.
c# i .net mialo byc bronia przeciwko java/j2ee, a jakos java sie utrzymala,
dalej sie rozwija, kolejne wersje sa coraz ciekawsze.
to raczej straszak na konkurencje. a co do .net w viscie, to pewnie dlatego do
wygodnej pracy na viscie (znanej jako xp sp3;) bedzie potrzebne 1GB ram;)

[user0001]

Według mnie wyparcie C/C++ przez prostrze języki, w programach z graficznym
interfacem użytkownika na platformie winowsowej to kwestia czasu.

Kolejne wersje C# też są coraz ciekawsze. Przygotowywałem ostatnio mały
projekcik w C# (do pracy), i stwierdzam że IDE w wersji 2005 jest niesamowicie
łatwie i intuicyjne.

1GB RAM to nic nadzywczajnego, raptem 370PLN. Tam gdzie aplikacja jest
pisana/przystosowywana pod zamówienie, liczba użytkowników jest mała, bardziej
opłaca się zainwestować mocniejszy sprzęt niż płacić za dodatkowe godziny pracy
konsultanta/wdrożeniowca.

[kell99]

> Według mnie wyparcie C/C++ przez prostrze języki, w programach z graficznym
> interfacem użytkownika na platformie winowsowej to kwestia czasu.
Ale niekoniecznie musi to byc c#. gcj i gtk + glade na eclipse tez dziala
swietnie. Ale co z tego, przy duzych i skomplikowanych rzeczach wychodzi, ze
takie "klikane" programowanie powoduje tylko wiecej bolu glowy niz pozytku.

> 1GB RAM to nic nadzywczajnego, raptem 370PLN. Tam gdzie aplikacja jest
> pisana/przystosowywana pod zamówienie, liczba użytkowników jest mała, bardziej
> opłaca się zainwestować mocniejszy sprzęt niż płacić za dodatkowe godziny pracy
> konsultanta/wdrożeniowca.

Zapomnialem, ze odtwarzacz muzyczny musi na starcie ruszac 150MB, bo musi
zaladowac mase bibliotek;) W tym pewnie przyszlosc. notepad w .net pewnie 1GB
wymagalby na start.
Jezeli mala liczba userow to mozna wcisnac klientowi wyklikana aplikacje ktora
ledwo dziala;) Skad ja to znam.

[user0001]

> Ale co z tego, przy duzych i skomplikowanych rzeczach wychodzi, ze
> takie "klikane" programowanie powoduje tylko wiecej bolu glowy niz pozytku.

Tak, ale przy dużych i skomplikowanych rzeczach istnieje coś takiego jak faza
projektowania, powinna być zachowana separacja logiki biznesowej od warstwy
prezentacji...

Klikalne programowanie to intuicyjne rozwiązanie w trakcie tworzenia UI, nic
więcej...

> Jezeli mala liczba userow to mozna wcisnac klientowi wyklikana aplikacje ktora
> ledwo dziala;) Skad ja to znam.

Mylimy pojęcia, nie piszę o wyklikanej aplikacji, ale o porządnie napisanej
aplikacji w której dobry, czytelny i łatwy w rozbudowie projekt nie został
schowany za implementacją mającą ruszyć na sprzęcie sprzed ośmiu lat. Cytując:
"First make it right, then make it fast."

[kell99]

> Tak, ale przy dużych i skomplikowanych rzeczach istnieje coś takiego jak faza
> projektowania, powinna być zachowana separacja logiki biznesowej od warstwy
> prezentacji...

W teorii to wszystko istnieje;)

> Mylimy pojęcia, nie piszę o wyklikanej aplikacji, ale o porządnie napisanej
> aplikacji w której dobry, czytelny i łatwy w rozbudowie projekt nie został
> schowany za implementacją mającą ruszyć na sprzęcie sprzed ośmiu lat.

Nic nie rozumiem. Co z tego, ze porzadna aplikacja, skoro ta sama aplikacja
napisana w innym jezyku bylaby kilka razy wydajniejsza (pod wzgledem szybkosci i
np zajmowanej pamieci).

[Gość: Kokeeno]

Fajne podejście: aby ułatwić życie programiście masa użytkowników musi wymienić
sprzęt na lepszy... Mnie uczono, że to programista jest dla użytkowników, a nie
odwrotnie...

Swoją drogą duży projekt w c++ to często miliony linii kodu, które dosyć długo
się kompilują przy większych zmianach, ale za to kod jest dużo wydajniejszy...

[Gość: fdd-maniak]

Wcale się nie dziwię, że Vista będzie wymagała 800 MB RAMu. Zmarnujemy cały
potencjał dzisiejszych komputerów na jakieś debilne okienka. I po co ? Na moim
poprzednim komputerze - P133, 24 MB RAM - też odpalałem notatnik i nie wymagał
on setek megabajtów RAMu. Żałosne, co się dzieje.

[user0001]

Kokeeno. Piszemy o zupełnie innym rodzaju projektów.

Masa użytowników, to użytkownicy oprogramowania gotowego, takiego jakie leży na
sklepowych półkach. Tutaj obniżenie wymagań sprzętowych powiększa grupę
potencjalnych użytkowników.

Projekty wymagające dopasowania do konkretnej firmy to zupełnie inna specyfika.
Tutaj dzień pracy projektanta, programisty, czy wdrożeniowca przekłada się
wprost na ostateczną cenę systemu. Dla użytkownika nie ma znaczenia, czy zapłaci
za droższy sprzęt, czy za droższą licencję na stanowisko.

[Gość: Szpaq]

> Raczysz żartować. Kiedyś zakodowałem pewien blok w czystym assemblerze (chodził
> o
> o algorytm rysowania trójkąta) i dla porównania przepisałem ten sam kod w C,
> który skompilowałem potem w DJGPP (DOSowa wersja GCC). Efekt? Program w C był
> dużo szybszy. DJGPP znacznie lepiej optymalizuje kod niż zrobiłby to koder
> programując "ręcznie" w assemblerze. Zestawienie kompilatorów Pascalowych z
> kompilatorami C możemy już sobie odpuścić.

Jak programuje mikrokontroler i zalezy mi na szybkim wykonaniu jakiejs operacji
to robie wtawke w assemblerze reszte programu pisze w C, znajac dokladnie
topologie mikrokontrolera mozna napisac zdecydowanie szybszy i mniejszy program
w assemblerze

[Gość: Kokeeno]

> Że co??? Pokaż mi jakiś skomplikowany program napisany w Pascalu. Ja natomiast
> przypomnę, że jądro systemu operacyjnego, z którego korzystasz, zostało
napisan e w C.
Nie "że co". Swego czasu borlandowski Turbo Pascal pozwalał na dokładnie to
samo co odpowiednik c. Napiszę więcej - wiele programów w tp chodziło szybciej
niż odpowiedniki w c (za pewną cenę, ale tutaj nie będę wchodził w szczegóły).

To że djgpp lepiej zoptymalizował program w c niż Ty w assemblerze nie
najlepiej świadczy o Twoim programie.

C jest ustandaryzowany, w przeciwieństwie do Pascala (za to w tym drugim
trudniej było popełnić takie kaczany, jak można przez nieuwagę w c), dzięki
temu to c nadaje się do pisania przenośnych programów. C ma bogate biblioteki
standardowe - to też jest jego atut.

P.S.
Dobry koder lepiej zoptymalizuje kod niż kompilator (z wielu powodów, ale
przede wszystkim to kwestia umiejętności i wiedzy). Najlepszym sposobem jest
zmuszenie do wyplucia kodu przez kompilator c w assemblerze i sprawdzenie, co
jeszcze można poprawić i nie zepsuć ;o)

[Gość: fdd-maniak]

> Nie "że co". Swego czasu borlandowski Turbo Pascal pozwalał na dokładnie to
> samo co odpowiednik c.

Więc jak wytłumaczyć to, że Pascal ma dziś znaczenie wyłącznie marginalne
(dydaktyka), a C przetrwał i ma się dobrze? btw. większość nowoczesnych języków
programowania ma składnię C-podobną.

> To że djgpp lepiej zoptymalizował program w c niż Ty w assemblerze nie
> najlepiej świadczy o Twoim programie.

Użyłem przykładu z assemblerem, żeby tylko podkreślić wydajność i jakość DJGPP.

> Dobry koder lepiej zoptymalizuje kod niż kompilator (z wielu powodów, ale
> przede wszystkim to kwestia umiejętności i wiedzy). Najlepszym sposobem jest
> zmuszenie do wyplucia kodu przez kompilator c w assemblerze i sprawdzenie, co
> jeszcze można poprawić i nie zepsuć ;o)

DJGPP rozpoczynał wszystkie pętle od adresu podzielnego przez 4 i wiedział
dokładnie jakie instrukcje się parują i w jakiej kolejności je wykonywać. Ja
niestety nie pamiętam co z czym się może sparować i ile taktów to będzie trwać i
dlatego przegrałem z kompilatorem.

[Gość: Kokeeno]

> Więc jak wytłumaczyć to, że Pascal ma dziś znaczenie wyłącznie marginalne
> (dydaktyka), a C przetrwał i ma się dobrze? btw. większość nowoczesnych
języków
> programowania ma składnię C-podobną.
Pascal i C mają podobne składnie - różnią się głównie kluczowymi nazwami i
trochę innym (ale tylko w zapisie) podejściem do wskaźników.
Podstawową zaletą C jest jego standaryzacja - każdy może sobie napisać
kompilator C, bo ma udokumentowane (prawie) wszystkie jego cechy (pewne rzeczy -
jak rozmiar danych są niedookreślone - celowo, np: sizeof(char)<=sizeof(short)
<=sizeof(int)).
W Pascalu NIGDY nie było oficjalnej specyfikacji języka i bibliotek
standardowych - co firma, to inny język. Siła c tkwiła w bardzo rozbudowanych
bibliotekach. W przemyśle nie zwiążesz się z jednym dostawcą kompilatora, który
może Cię olać w dowolnym momencie, czyż nie?

Jeśli chodzi o c++ to standard był przez pewien czas dosyć rozmyty, od kilku
lat jest już znacznie lepiej - ani gcc2.95 ani visual c++ 6.0 nie są
kompilatorami c++ (bo pozwalają/nie pozwalają na pewne konstrukcje które były
nieokreślone, a teraz już są). Właściwie tylko ładując maksymalne restrykcje (-
Wall, ansi-pedantic itp.) można mieć jakąś nadzieję, że pisze się w miarę
poprawny kod (ignorowanie warningów to nie jest dobry styl kodowania).

Jeśli chodzi o Pascala, to Delphi się całkiem nieźle przyjęło (ale bez
rewelacji)...

> Użyłem przykładu z assemblerem, żeby tylko podkreślić wydajność i jakość
DJGPP.
Optymizacje w kompilatorach, to "tylko" zbiór reguł pod konkretne konstrukcje
(rozłożenie w pamięci - każdy kompilator 32 bitowy powinien w ramach ograniczeń
c++ rozłożyć dane na granicy 4 bajtów). Zwykle w wielu sytuacjach można znaleźć
lepsze rozwiązanie (a przynajmniej nie gorsze) niż w c/c++. Tyle, że jest to
czasochłonne (sprawdzenie które instrukcje mogą pójść razem do potoków w
konkretnym procesorze, które skoki źle się odbiją na wydajności predykcji
skoków którego procesora)...

[Gość: mig]

> DJGPP rozpoczynał wszystkie pętle od adresu podzielnego przez 4 i wiedział
> dokładnie jakie instrukcje się parują i w jakiej kolejności je wykonywać. Ja
> niestety nie pamiętam co z czym się może sparować i ile taktów to będzie trwać
> i
> dlatego przegrałem z kompilatorem.

- adres podzielny przez 4 - wystarczy odpowiednio definiować struktury,
- parowanie rozkazów ma małe znaczenie, i różnie to wygląda na różnych procesorach,
- ilości taktów nie musisz znać, ale to że dzielenie trwa dłużej niż mnożenie,
kiedy lepiej użyć float, a kiedy int, mniej operacji = szybciej, dużo porównań =
wolniej, itp. - trzeba to wiedzieć

Kompilator ma małe szanse na wygranie nawet z lekko doświadczonym koderem.

Zobacz sobie jak ten DJGPP optymalizuje zwykłe zaokrąglanie liczb
tak to wygląda w c:
int i, y = ...;
i = 567.0*y + 0.5;