C++ a C# - różnice

0
somekind napisał(a)

C# to język będący pod względem składni i mechanizmów miksem Javy, C, Delphi i pewno paru innych. Został wymyślony jako flagowy język dla microsoftowej platformy .NET

Niby jest flagowy, ale w takim razie dlaczego zdecydowana większość video tutoriali na stronach Microsoftu (msdn i asp.net) jest zrobiona pod Visual Basica.NET, a do C# są podane co najwyżej jedynie kody źródłowe programów z tutoriali? Jedynie chyba tylko Bob Tabor robi tutoriale w obu tych językach programowania.

deus. napisał(a)

Może dlatego, że assembler nie jest przeznaczony do takiego sobie klepania... I nie narzekaj, x86 jest banalny w porównaniu z tym co np. na Itanium masz.

Banalny to był assembler Motoroli ;)

Krolik napisał(a)

Poza tym w C# 3.0 są pewne nowości jak choćby typy anonimowe czy rachunek lambda, które nie występują w C++ i w Javie.

Typy/klasy anonimowe to akurat w Javie są od więcej niż 10 lat. C# miał delegaty i teraz chyba zauważyli, że klasy anonimowe Javy to jednak coś więcej.

Racja. Chodziło mi o Lambdę, ale że w pośpiechu pisałem, to takie dziwne zdanie mi wyszło ;)
Dzięki za sprostowanie.

0
wujekstalin napisał(a)

Robster - od tego są makra .if w takim fasmie/masmie. Ręczne pisanie porównań ma sens tylko jak chcemy maksymalnie zoptymalizować kod w danym miejscu...
Pisanie w assemblerze sensu oczywiście nie ma, ale zakładam, że się po prostu uczysz.

Dokładnie. Ja przyjąłem sobie taką filozofię, że nie ma sensu na czas obecny uczyć się jakiegoś języka na "full" bo pracę rozpocznę za jakieś 2-3 lata więc dużo może się zmienić, dlatego łapię się wszystkiego po trochę, tak by mieć rozeznanie.
A samego Asemblera nie zacząłem się uczyć z własnej woli, bo mam taki wymóg na uczelni, ale jak już zacząłem to się bawię.

0

Niby jest flagowy, ale w takim razie dlaczego zdecydowana większość video tutoriali na stronach Microsoftu (msdn i asp.net) jest zrobiona pod Visual Basica.NET,

Bo gdyby nie to, nikt by juz nie pamietal ze istnieje cos takiego jak VisualBasic .NET

0

othello, mylisz się - dla starego ASP podstawowym językiem był VBScript, naturalnym jest użycie VB.NET dla ASP.NET, jest więc powód do pamiętania. Akurat w Polsce VB nigdy nie był popularny...

0
deus. napisał(a)
Krolik napisał(a)

Scala jest lepiej zaprojektowana od obu z nich a zarazem oferuje znacznie więcej (i większy fun z programowania).

Tja, i oddzielne klasy reprezentujące n-elementowe krotki - Tuple0, Tuple1, Tuple2, Tuple3, Tuple4, Tuple5, Tuple6, Tuple7, Tuple8, Tuple9, Tuple10, Tuple11, Tuple12, Tuple13, Tuple14, Tuple15, Tuple16, Tuple17, Tuple18, Tuple19, Tuple20, Tuple21, Tuple22 czy tak samo oddzielne klasy reprezentujące funkcje o n-argumentach Function0, Function1, Function2, Function3, Function4, Function5, Function6, Function7, Function8, Function9, Function10, Function11, Function12, Function13, Function14, Function15, Function16, Function17, Function18, Function19, Function20, Function21, Function22.

Wspaniały design języka...

W C++ i C# miałbyś ten sam problem. Tyle, że żaden z nich nie ma krotek, więc nie ma o czym mówić (Boost dodaje krotki w bardzo podobny sposób - przez zdefiniowanie wielkiego template'u z wieloma parametrami, których część jest po prostu domyślna). Żeby to działało inaczej, musiałbyś mieć "variadic templates", a to dopiero w kolejnym standardzie języka C++, na który chyba jeszcze trochę poczekamy. W C# nawet nie planują. I chyba dobrze, bo wzorce są jedną z bardziej złożonych rzeczy - bilans mógłby wyjść ujemny (dodawanie do języka rzeczy, które są rzadko przydatne a łatwo o nadużycia, jest IMHO błędem).

0

Oj, wiem wiem, ale Scala pod każdym względem stara się być bardziej zaawansowana niż wszystko inne i nie iść na kompromisy, to bodaj jedyne takie rozwiązanie w całym języku.

0

Są duże szanse, że takie rzeczy poprawią do czasu, jak Scala stanie sie popularna. Ale variadic templates nie jest rzeczą, którą można sobie tak dodać do języka bez głębszego przemyślenia.

Z jednej strony życzę jej twórom, aby Scala stała się drugim głównym obok Javy językiem na JVM, ale z drugiej strony jak to twierdzą goście od Haskella "avoid success by all means" - odniesienie sukcesu przez język często zamyka możliwości poprawiania projektu i sensownego dodawania nowych rzeczy. Java to odczuła bardzo mocno już przy zmianie wersji 1.4 na 5. A C++ jest w sumie całe przykładem na to, jak konieczność zachowania wstecznej kompatybilności (tu z C) zepsuła projekt języka.

0
_Krolik napisał(a)

A C++ jest w sumie całe przykładem na to, jak konieczność zachowania wstecznej kompatybilności (tu z C) zepsuła projekt języka.

Oczywiście masz rację, ale to jest jasne dopiero teraz z perspektywy czasu. Był taki długi okres(za długi) w którym C był uważany za jedyny słuszny język programowania, było wiele bardziej zakorzeniony w głowach programistów niż jakikolwiek język dzisiaj. Jeżeli stworzony by został język który nie miałby z nim nic wspólnego najprawdopodobniej nie przyjąłbym się, w końcu C++ nie był pierwszym językiem obiektowym ale pierwszym który zaczął być szeroko stosowany. Musiała powstać technologia która zapewniłaby w miarę łagodne "przejście" między C a językami które mamy teraz (java, C#), C++ był swoistą odpowiedzią na zapotrzebowanie w TAMTYCH CZASACH. Dlatego moim zdaniem nie ma co się rozwodzić jaki to C++ jest be, tak po prostu musiało być ;)

0

@several, pełna racja. Ale z drugiej strony w TYCH CZASACH cały czas spotykam się z gośćmi, którzy nauczyli się C++ na uczelni i później uważają, że jest to jedyny język, który rozwiązuje wszystkie problemy tego świata i jak programujesz w czymś co ma GC to jesteś cienias, bo nie umiesz zarządzać ręcznie pamięcią i optymalizować programów arytmetyką wskaźnikową ;)

A tak swoją drogą wczoraj miałem zabawną sytuację:
Rozmawiamy sobie z kolegą właśnie o wadach i zaletach programowania w takich "akademickich językach" funkcyjnych i funkcyjno-obiektowych i nagle wchodzi dr P., i pyta o jakim języku rozmawiamy.
Ja: O Scali
On: A co to jest?
Ja: Taki nowy język obiektowo-funkcyjny działający na JVM, podobny nieco do Javy, ale o znacznie większych możliwościach w zakresie programowania funkcyjnego, no wiesz w przeciwieństwie do Javy ma te wszystkie lambdy, kontynuacje, ....
On: A co to jest programowanie funkcyjne?
Ja i kumpel: [szczena nam opadła, a po chwili wyjaśniliśmy po krótce podstawowe założenia]
On: To jak nie można modyfikować wartości zmiennych, to to kiepskie jakieś jest...

Ten gość ma doktorat z informatyki i to na jednej z lepszych polskich uczelni! Rozumiem, że można nie lubić / nie rozumieć tego paradygmatu, ale gdzie on się uchował, że tego nie słyszał? [rotfl]

0

Gdzie się uchował? Na uczelni i tak to wymagane nie jest, potem tylko siedział w swoim koffanym programowaniu imperatywnym. Pierwsza piątka najpopularniejszych języków nawet koło rachunku lambda nie stała.

0

To przypomina mi się nie dawno jak rozmawiałem z kolegą o Erlangu.
Do rozmowy przyłączył się jeden gość (akurat mówiliśmy o współbieżności w Erlangu) - gość stwierdził że słaby ten Erlang, prawdziwa współbieżność to semafory i pamięć współdzielona :]

0
Krolik napisał(a)

Ten gość ma doktorat z informatyki

Pisałem już na forum o gościu, który ma doktorat po WAT i nie wie, że po przerwaniu obwodu szeregowego żaden odbiornik nie działa. Doktorat z informatyki, to nie jest jakiś wielki wyczyn, nieraz wystarczy wiedzieć, komu się nadstawić, a kto woli z połykiem. A jak się ma tatusia profesora, to można dostać mimo problemów na maturze.
Mam znajomego doktora od mechaniki silników. Habilitacji nie będzie robił, mimo że liczbą publikacji przewyższa resztę swojego wydziału. Dlatego, bo nie jest posłuszny i nie dadzą mu szans. A jego nieposłuszeństwo polega np. na tym, że nie pozwala oblać na obronie studenta, tylko dlatego, że ten komuś tam kiedyś podpadł.

i to na jednej z lepszych polskich uczelni!

Jak to lepszych? Przecież wszystkie są najlepsze, wystarczy informatory poczytać. To jak z proszkami do prania.
A tak naprawdę, to co jest lepsze - trąd czy syfilis?
Bo moim zdaniem, próby wybrania lepszego, gdy do wyboru są tylko złe rzeczy, to jakiś chory absurd.

Weźmy dla przykładu Elkę...
Na I semestrze programowania profesor mówi, że dobry, profesjonalny programista pisze 10 linijek kodu dziennie. Prowadzi wykład z podstaw C (mniej materiału niż na Wikibooks) i głównie mówi o tym, że fotografia analogowa jest lepsza od cyfrowej.
Zajęcia z podstaw miernictwa - przychodzi student, który pierwszy raz w życiu widzi oscyloskop, najpierw pisze wejściówkę, na której wymagana jest od niego pełna wiedza, nie tylko o sprzęcie, ale także o tym, co będzie robił na zajęciach. Nie zaliczy wejściówki, to automatycznie nie ma po co zostawać na laborkach. A potem 4h siedzi i nie mierzy, tylko próbuje napisać sprawozdanie, którego wnioski będą takie, jak wymagane przez prowadzących - kompletnie bez zrozumienia tematu, tego co się dzieje i jak działa - pełna improwizacja.
Mam kumpla na mechatronice. Jako pracę inżynierską chce zrobić robota balansującego - prowadzący seminaria nie chce się zgodzić, bo to "za trudne". Dlaczego? Bo w pustym, doktorskim łbie nie mieści się fakt, że lepiej zbudować robota wyposażonego w czujniki położenia i oprogramowanie sterujące silnikami, które ciągle będą korygować jego pozycję, niż równoważyć obciążenia w klasycznym robocie. Nie mieści się, bo w latach siedemdziesiątych tak się przecież nie robiło!
Jaki sens mają takie uczelnie i taka edukacja? To jest tylko męcząca zabawa w "naukę".

0

Nie chce mi się czytać poprzednich postów więc napiszę tylko jakie są różnice.

C#:

  • Korzysta z platformy .NET.
  • Produkt Microsoftu
  • Korzysta CHYBA tylko z kompilatora Microsoft.
  • Jest wieloplatformowy.

C++:

  • Język do ogólnego przeznaczenia (gry, programy, silniki, etc)
  • Jest wieloplatformowy.
  • Twórcą C++ jest Duńczyk Bjarne Stroustrup.
  • C++/CLI - rozszerzona wersja C++ wzbogacona o platformę .NET.
  • Dużo kompilatorów do tego języka.

Jeżeli nie wiesz, którego języka się uczyć to zacznij od C++.

Pozdrawiam

0

igorx2 wiem jak się programuje w C++, tyle że jest to raczej etap średnio-zaawansowany i to jeszcze w początkowym stadium ^^ Chciałem po prostu wiedzieć, czy C# jest pewnego typu kontynuacją C++ i jeśli chce się być "na bieżąco" trzeba "zarzucić" kontynuację nauki C++ i uaktualnić wiedzę o C#.
Ale z tego co zrozumiałem, są to dwa różne języki i żadna kontynuacja nie ma tutaj miejsca.

Dzięki panowie za wszystkie informacje, były dla mnie bardzo przydatne :]

0

C# choć najpopularniejszy to tylko jeden z języków NET. W tej platformie całość bazuje na CLI (Common Language Infrastructure)

  • kompilowany do języka pośredniego CIL (podobnie jak Java), a następnie z tego języka kompilowany do natywnego kodu podczas uruchamiania
  • common type system - m.in. dzięki temu można tworzyć moduły w różnych językach, tj. każdy język CIL obsługuje takie same typy. W efekcie można napisać jeden moduł w C# drugi w VB.NET, trzeci w IronPython itp i będą ze sobą działać bez problemu.
  • automatyczne zarządzanie pamięcią (garbage collector) - wbrew pozorom bardzo szybkie
  • w razie czego możliwość użycia kodu unsafe (w tym operacje na wskaźnikach)
  • wieloplatformowy np. dzięki Mono (M$ wypuścił swego czasu część kodów źródłowych NET) - Windows, Linux, BSD, MacOS X, Solaris
  • łatwe kompilowanie pod 64 bity, dla typowo zarządzanej aplikacji nie ma znaczenia czy będzie działać w trybie 32 czy 64 bitowym.
  • ładny, przejrzysty kod, bardzo wygodny język
  • jeśli pisałeś w Delphi to znajdziesz wiele podobieństw jak właściwości klas (properties)

pod Windows masz darmowe Visual Studio C# Express lub SharpDevelop. Pod inne systemy masz MonoDevelop (obsługuje również Windows). Sam pracuje pod Windowsem na VS, a pod Linuksem na MD nad jednym projektem i nie ma żadnego problemu.

0

gacek999 poruszyłeś temat, który mnie od dawna intrygował, a zawsze zapominałem o niego zapytać, dlatego zrobię mały offtop.

Z tego co słyszałem większości aplikacji nie robi różnicy czy działają na 64 czy 32 bit systemach i na tych nowych nie działają one nawet trochę szybciej. Po prostu dopisują sobie te 32 zera na początek i wszystko odbywa się po staremu.
Znaczyłoby to, że dopiero teraz powstają (powoli) aplikacje, które wykorzystywałyby te dodatkowe 32 bit w jakiś sensowny sposób?

0

Najważniejszym powodem wprowadzenia procesorów 64 bitowych było zwiększenie ilości adresowanej pamięci. Jak wiadomo standardowa aplikacja 32 bitowa może zaadresować tylko 2 GB. Wskaźniki 64 bitowe dają dużo większe pole do popisu jeśli chodzi o pamięć. Windows pod x64 pozwala teoretycznie zaalokować 8 TB.
Jeśli chodzi o prędkość to 64 bitowe aplikacje działają szybciej tylko gdy przetwarzamy duże ilości danych. Dzieje się to przez to, że procesor może przetworzyć więcej danych naraz.

0

Jednym słowem przewagą 64bit systemów jest możliwość pracy na większej ilości okienek (choćby przez fakt zwiększenia ilości pamięci RAM) oraz przyśpieszenie pracy w "profesjonalnych" aplikacjach (np. do renderowania grafiki-pomijając już całkiem inne podzespoły).?
Ale programy pokroju Photoshopa też chyba będą szybciej działały ze względu na większą ilość pamięci cache w procesorze (podobno dużo od niej zależy w produktach Adobe).

0
Robster napisał(a)

Jednym słowem przewagą 64bit systemów jest możliwość pracy na większej ilości okienek (choćby przez fakt zwiększenia ilości pamięci RAM) oraz przyśpieszenie pracy w "profesjonalnych" aplikacjach (np. do renderowania grafiki-pomijając już całkiem inne podzespoły).?

Tak, chodzi o aplikacje, które wymagają dużych ilości pamięci m.in. serwery.

Robster napisał(a)

Ale programy pokroju Photoshopa też chyba będą szybciej działały ze względu na większą ilość pamięci cache w procesorze (podobno dużo od niej zależy w produktach Adobe).

Możliwe, ale tego nie jestem pewien. Jeśli tak, to przecież 32 bitowe procki też się różnią cachem.

0

Ja bym powiedział, że 64 bitowe aplikacje będą chodziły nawet wolniej, właśnie przez większą pamięciożerność (dłuższe wskaźniki) i szybsze zapychanie cache. Pytanie do siedzących w .NET - czy .NET ma kompresję 64 bitowych wskaźników? Coś takiego jak ma Java "compressed Oops". Podobno w niektórych sytuacjach nieźle to przyspiesza.

http://wikis.sun.com/display/HotSpotInternals/CompressedOops</url>

0
gacek999 napisał(a)
Robster napisał(a)

Jednym słowem przewagą 64bit systemów jest możliwość pracy na większej ilości okienek (choćby przez fakt zwiększenia ilości pamięci RAM) oraz przyśpieszenie pracy w "profesjonalnych" aplikacjach (np. do renderowania grafiki-pomijając już całkiem inne podzespoły).?

Tak, chodzi o aplikacje, które wymagają dużych ilości pamięci m.in. serwery.

Robster napisał(a)

Ale programy pokroju Photoshopa też chyba będą szybciej działały ze względu na większą ilość pamięci cache w procesorze (podobno dużo od niej zależy w produktach Adobe).

Możliwe, ale tego nie jestem pewien. Jeśli tak, to przecież 32 bitowe procki też się różnią cachem.

gacek999 dziękuję za wyjaśnienie wszystkiego ^^

0
Krolik napisał(a)

Pytanie do siedzących w .NET - czy .NET ma kompresję 64 bitowych wskaźników?

Nigdy o czymś takim nie słyszałem, ale zważywszy na to, że kod CIL jest kompilowany do natywnego kodu to raczej używa normalnych systemowych wskaźników.

0

Trochę w temacie: Why C++ Sucks

Autor dość dosadnie to ujął:

C++ sucks because it is a mis-designed pile of crap.

0

Ja Wam powiem dlaczego C++ ssie - bo w nim jest MFC... gorsza ośmiornica niż PHP, od 8h tylko klnę na każdy możliwy element tego cudu techniki. Sam design C++ taki zły nie jest, jest wiele gorzej zaprojektowanych języków... C++ tylko utrudnia i komplikuje połowę tego co może być proste i logiczne. Taka Scala (niby dla potężnych możliwości) miejscami przebija stopniem skomplikowania C++.

Faktem też jest, że do C++ można próbować wcisnąć Smalltalka, ale temu pajacowi z M$ co to na taki właśnie pomysł wpadł najchętniej wcisnąłbym w dupę płyty z Visualem (szczególnie, że w tym momencie muszę na VC++6 pracować)...

Mam wrażenie, że w C++ z MFC przez kilka godzin napisałem mniej sensownego kodu niż w pół godziny w C#, m.in. przez wyjebistość MFC i samego C++.

Jak dla mnie główną różnicą pomiędzy C# a C++ jest brak MFC w tym pierwszym. Druga różnica - C++ to na tyle spieprzony język, że można w nim było stworzyć MFC...

0

O tak, uzywanie MFC boli.... ja wole juz WinApi. Prawdą jest, że MFC to chyba najbardziej pokręcona biblioteka gui jaka powstała w C++ i w dodatku jeszcze płatna

0

Taka Scala (niby dla potężnych możliwości) miejscami przebija stopniem skomplikowania C++.

Poczekajmy na C++0x [diabel]
Hmm, własciwie to już C++1x jeśli to było dziesiętnie, albo C++0x7DA, jeśli heksadecymalnie.

Prawdą jest, że MFC to chyba najbardziej pokręcona biblioteka gui jaka powstała w C++ i w dodatku jeszcze płatna

Nie wiem, czy standardowe biblioteki do tworzenia GUI pod Symbianem tego nie przebijają...

1 użytkowników online, w tym zalogowanych: 0, gości: 1