Dodaj do ulubionych

C, C++, C# ...

IP: *.neoplus.adsl.tpnet.pl 29.03.06, 12:11
... jaka jest róznica pomedzy nimi? I jeszcze ktoś mógłby powiedziec o róznicy
między Unixem a Linuxem :))))))))))))) Dzięki ...
Obserwuj wątek
    • Gość: Kokeeno Re: C, C++, C# ... IP: *.crowley.pl 29.03.06, 13:34
      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 Re: C, C++, C# ... IP: *.wroclaw.dialog.net.pl 29.03.06, 19:56
        > 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 Re: C, C++, C# ... 29.03.06, 20:14
          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 Re: C, C++, C# ... IP: *.ip.WRO.Korbank.PL 29.03.06, 20:53
            > 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ść: ja Re: C, C++, C# ... IP: *.ip.WRO.Korbank.PL 29.03.06, 21:13
              > 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 Re: C, C++, C# ... IP: *.pronet.lublin.pl 30.03.06, 10:58
                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 Re: C, C++, C# ... 30.03.06, 15:36
                  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 Re: C, C++, C# ... 30.03.06, 17:06
                    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 Re: C, C++, C# ... 30.03.06, 18:59
                      > 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 Re: C, C++, C# ... 31.03.06, 08:10
                        > 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 Re: C, C++, C# ... 31.03.06, 16:04
                          > 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 Re: C, C++, C# ... IP: *.crowley.pl 31.03.06, 08:06
                      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...
                      • user0001 Re: C, C++, C# ... 31.03.06, 13:13
                        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 Re: C, C++, C# ... IP: 195.116.211.* 29.03.06, 21:22
          > 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 Re: C, C++, C# ... IP: *.crowley.pl 30.03.06, 08:41
          > Ż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 Re: C, C++, C# ... IP: *.wroclaw.dialog.net.pl 30.03.06, 14:31
            > 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 Re: C, C++, C# ... IP: *.crowley.pl 30.03.06, 16:16
              > 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 Re: C, C++, C# ... IP: *.neoplus.adsl.tpnet.pl 30.03.06, 21:16
              > 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;

Nie pamiętasz hasła

lub ?

 

Nie masz jeszcze konta? Zarejestruj się

Nakarm Pajacyka