Dlaczego wybraliście C#?

Jako gratis, int w C# jest obiektem więc możemy zrobić sobie chociażby takie coś, java tak nie potrafi bo ma prymitywy :D:
5.ToString();

Genialne. Przekonaliście mnie. Warto programować w C# :)

neves napisał(a):

Jako gratis, int w C# jest obiektem więc możemy zrobić sobie chociażby takie coś, java tak nie potrafi bo ma prymitywy :D:
5.ToString();

Niestety jest coś takiego jak Kotlin i wszystkie te lata rozwoju C# na nic się zdadzą:
5.toString();

http://ideone.com/WVOiu9

W Groovim i Scali też to działa...

Wibowit napisał(a):

Jak widać da się zapakować inta (prymityw) w obiekt.

Ja nie twierdzę, że się nie da. Ja odnoszę się tylko do systemu typów. W C# jest jeden int, w Javie są dwa.

Panie somekindzie: nie znasz podstaw C# :]

:D :D :D

jarekczek napisał(a):

Genialne. Przekonaliście mnie. Warto programować w C# :)

Nikt tu nikogo do niczego nie przekonuje. Chcesz, to programuj, nie chcesz to nie programuj. Bądź dorosły!

vpiotr napisał(a):

Niestety jest coś takiego jak Kotlin i wszystkie te lata rozwoju C# na nic się zdadzą:

A u was biją murzynów! :D :D :D

Widzę, że dalej nie ogarniacie C#. Przytoczyłem dokumentację Microsoftu, przykłady na inne zachowanie dużych i małych intów w C#, problemy z dużymi intami w C# na StackOverflow, a wy dalej powtarzacie bajeczki jak mantrę że nie ma dużego inta w C#.

Na razie nie mam specjalnie czasu, ale przetłumaczę wam dokumentację Microsoftu:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/boxing-and-unboxing

Boxing is the process of converting a value type to the type object or to any interface type implemented by this value type. When the CLR boxes a value type, it wraps the value inside a System.Object and stores it on the managed heap. Unboxing extracts the value type from the object. Boxing is implicit; unboxing is explicit. The concept of boxing and unboxing underlies the C# unified view of the type system in which a value of any type can be treated as an object.

CLR konwertuje prymitywy (i inne typy wartościowe) na obiekty kiedy tego trzeba czyli np przy rzutowaniu inta na object.

Napiszcie mi której cześci dokumentacji Microsoftu nie rozumiecie.

Ja nie twierdzę, że się nie da. Ja odnoszę się tylko do systemu typów. W C# jest jeden int, w Javie są dwa.

W C# jest widoczny jeden, bo duży int w C# jest ukryty w sensie nie da się bezpośrednio odnieść do klasy dużego inta. Trzeba jednak pamiętać o tym, że istnieje taka klasa i że łatwo (nawet przypadkowo) zapakować inta w obiekt, bo duży int w C# zachowuje się inaczej niż mały int.

Ty trollujesz, czy taki nierozgarnięty jesteś? Nie ma żadnych dużych i małych intów w C#, to że w Javie coś jest zjeb*** dokumentnie, nie znaczy, że w C# też.

https://docs.microsoft.com/pl-pl/dotnet/csharp/language-reference/keywords/int

W C# jest widoczny jeden, bo duży int w C# jest ukryty w sensie nie da się bezpośrednio odnieść do klasy dużego inta.

WTF, że niby nie da się utworzyć instancji System.Int32?
http://ideone.com/jpcx1k

Sam napisałeś, że int i Int32 to to samo i temu nie przeczę. Wytłumacz mi co powstaje po boxingu małego inta w C# i dlaczego unboxing da się zrobić tylko z zapakowanego inta.

int zapakowany w object

No właśnie, A w Javie int zapakowany w Object nazywa się Integer. Więc jaka niby jest różnica?

Duży int jako osobna klasa musi istnieć w C# by można go było rozpakować. Jeszcze raz powtarzam - to, że nie da się dostać z poziomu składni do klasy dużego inta nie oznacza, że go nie ma.

Wibowit napisał(a):

i dlaczego unboxing da się zrobić tylko z zapakowanego inta.

Ehm, unbox_any może zrobić unboxing z niezapakowanego inta XD

Dobra, wiem że wtedy po prostu clr to skipuje wtedy, ale jaki sens by miało robienie unboxingu z niezapakowanego inta?

Co to jest duży i mały int?

@somekind: a jak jest z Optionalami w C#? :)

int w C# to po prostu alias na System.Int32. Z kolei Int32 jest w C# strukturą(typem wartościowym ) dlatego przy rzutowaniu na object konieczny jest boxing bo object odnosi się do typów referencyjnych

A Int32 jest traktowany jako native int w CLR, więc nie jest zwykłą strukturą, weźcie sobie jakiś inny przykład ;Z

Dajcie już spokój biednemu intowi, przecież są chyba ciekawsze zagadnienia w tym języku?

Wibowit napisał(a):

No właśnie, A w Javie int zapakowany w Object nazywa się Integer. Więc jaka niby jest różnica?

Taka, że w przypadku C# internet nie jest pełen pytań o to jak skonwertować jedno do drugiego, bo jakieś API wymaga Integera, a my mamy int albo odwrotnie.
Posiadanie dwóch typów do przechowywania jednego rodzaju wartości jest zawsze konfundujące.

Duży int jako osobna klasa musi istnieć w C# by można go było rozpakować. Jeszcze raz powtarzam - to, że nie da się dostać z poziomu składni do klasy dużego inta nie oznacza, że go nie ma.

Nie oznacza, ale go nie ma. C# ma po prostu inny system typów, z podziałem na wartościowe i referencyjne, a nie prymitywy i obiekty.
Zresztą, int de facto dziedziczy z object w niejawny sposób. Tylko to szczegóły implementacyjne bez znaczenia dla użytkowników języka. Podobnie jak boxing i unboxing, nie pamiętam kiedy i po co miałbym tego ostatnio używać. Ale domyślam się, że w Javie to chyba najważniejsza rzecz, skoro tyle o tym piszecie.

scibi92 napisał(a):

@somekind: a jak jest z Optionalami w C#? :)

https://github.com/nlkl/Optional

A kiedy w Javie będą działające generyki? :P

vpiotr napisał(a):

Dajcie już spokój biednemu intowi, przecież są chyba ciekawsze zagadnienia w tym języku?

Tak w ogóle, to miał być wątek o wyborze języka, no ale fanatycy Javy nie usną jeśli nie udowodnią samym sobie po raz kolejny urojonej supremacji. ;)

scibi92 napisał(a):

@somekind: a jak jest z Optionalami w C#? :)

Ja nie somekind, ale odpowiem. Są.
Struktura System.Nullable<T> plus lukier składniowy w postaci int? x = null;.

Nawiasem, to teraz są dyskusje w celu wprowadzenia domyślnie typów nie-nullowalnych, tylko za bardzo niezbyt wiadomo jak to połączyć z kompatybilnością wsteczną :)

Po tym co zrobili w C#7 to lepiej niech więcej już cukrów składniowych nie robią :[.

Duży int w Javie używany jest głównie dlatego, że w Javie nie da się sparametryzować metody czy klasy generycznej małym intem - powtarzam to n-ty raz. Gdyby w C# też się nie dało to też wstawiliby dużego inta explicite - dla wygody. Obecnie duży int jest w C# schowany, by somekind go przypadkiem nie zobaczył.

Tylko to szczegóły implementacyjne bez znaczenia dla użytkowników języka. Podobnie jak boxing i unboxing, nie pamiętam kiedy i po co miałbym tego ostatnio używać.

A ja podałem linka do StackOverflow gdzie ktoś się naciął na boxingu w C#: https://stackoverflow.com/questions/6205029/comparing-boxed-value-types W "linked" i "related" są kolejne problemy C#-owców z boxingiem.

Ale domyślam się, że w Javie to chyba najważniejsza rzecz, skoro tyle o tym piszecie.

Hmm, a kto o tym pierwszy wspomniał i kto pluje jadem z tego powodu?

Wibowit napisał(a):

A ja podałem linka do StackOverflow gdzie ktoś się naciął na boxingu w C#: https://stackoverflow.com/questions/6205029/comparing-boxed-value-types W "linked" i "related" są kolejne problemy C#-owców z boxingiem.

No tak, gość nie ogarniał boxingu, może nawet nie rozumiał czemu porównywanie referencji nie działa dla typów niereferencyjnych. Ale jaki to ma związek i czego to dowodzi? Javowcy też pytają na SO o boxing.

Hmm, a kto o tym pierwszy wspomniał i kto pluje jadem z tego powodu?

Ty, wczoraj o 23:53.

Wibowit napisał(a):

Duży int w Javie używany jest głównie dlatego, że w Javie nie da się sparametryzować metody czy klasy generycznej małym intem - powtarzam to n-ty raz.

No, a dlaczego nie zrobili od początku jak jest w C#? ;-)

Gdyby w C# też się nie dało to też wstawiliby dużego inta explicite - dla wygody. Obecnie duży int jest w C# schowany, by somekind go przypadkiem nie zobaczył.

Generyków w C# na początku nie było. Pojawiły się w 2.0. I od razu można było je parametryzować intem.

int w C# to alias na System.Int32, o czym już wspomniano. jest to int „mały”, czterobajtowy, nieopakowany.
mimo to można nim parametryzować generyki i odpalać metody jak .ToString().
można inta zrzutować na object, co powoduje boxing. jednocześnie obiekt taki przestaje być zewnętrznie intem, jest tylko bezpłciowym objectem. choć nadal możemy na nim zrobić .ToString() i dostaniemy to samo.

dokładnego odpowiednika javowego java.lang.Integer w C# standardowo nie ma, bo nie ma takiej potrzeby. choć nikt nam nie broni takiej klasy napisać.

co ciekawe, platforma .NET obsługuje bezpośrednio boksowane typy wartościowe (niezdegenerowane do object), tylko ten ficzer nie jest dostępny w C#. dostępny jest za to w C++/CLI, w którym są:

• „mały” int (alias System::Int32)
• boksowany int (zrzutowany na System::Object), a także
• boksowany int^ który zachowuje swą „intowość” a jednocześnie z poziomu C# jest widziany jako object.

Dodam jeszcze, że „parametryzowanie generyka intem” w C# nie powoduje boxowania tego inta, nawet niejawnego, ani związanego z tym narzutu wydajnościowego i pamięciowego. int pozostaje intem.

Spróbuję jeszcze raz, może dotrze. Na przytoczonej przeze mnie dokumentacji Microsoftu https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/boxing-and-unboxing jest napisane:

The concept of boxing and unboxing underlies the C# unified view of the type system in which a value of any type can be treated as an object.

To, że typ wartościowy może być traktowany jako obiekt za pośrednictwem boxingu i unboxingu nie znaczy, że typ wartościowy jest obiektem de facto. Jest to tylko iluzja, "unified view". To "unified view" jest dla przykładu zaimplementowane w Scali - tam też jest jeden typ Int i w zależności od użycia jest małym lub dużym intem - konwersją zajmuje się automatycznie kompilator. Nie znaczy to jednak, że Scala przeskoczyła ograniczenia Javy. Mamy tylko cukier składniowy, bardzo przydatny zresztą.

A kiedy w Javie będą działające generyki? :P

Mam nadzieję, że tego nigdy nie skopiują z C#, bo moim zdaniem jest to totalnie niepotrzebne. Wystarczy możliwość parametryzowania metod i klas generycznych prymitywami i typami wartościowymi - wtedy zresztą popularność dużego inta w Javie mocno by spadła.

Wymazywanie typów w Javie pozwala na efektywną implementację dużo bardziej złożonego systemu typów w Scali niż w Javie czy C#. Jest to bardzo duża zaleta dla ludzi, którzy lubią zaawansowane języki programowania.

https://stackoverflow.com/questions/15081218/higher-kinded-types-why-possible-scala-but-not-f

No, a dlaczego nie zrobili od początku jak jest w C#? ;-)

Bo w momencie wprowadzania generyków C# był niszową zabawką, więc mogli sobie spokojnie zerwać kompatybilność wsteczną. Natomiast w tym samym momencie w Javce było już mnóstwo kodu naklepane i kompatybilność wsteczna była poważnym argumentem.

Równie dobrze, nawiązując do wypowiedzi @Ktos, można zapytać: czemu w C# od początku nie było typów nie-nullowalnych albo czemu teraz tego nie zmienią? Podobny dylemat co przy generykach.

Wibowit napisał(a):

The concept of boxing and unboxing underlies the C# unified view of the type system in which a value of any type can be treated as an object.

To, że typ wartościowy może być traktowany jako obiekt za pośrednictwem boxingu i unboxingu nie znaczy, że typ wartościowy jest obiektem de facto. Jest to tylko iluzja, "unified view". To "unified view" jest dla przykładu zaimplementowane w Scali - tam też jest jeden typ Int i w zależności od użycia jest małym lub dużym intem - konwersją zajmuje się automatycznie kompilator. Nie znaczy to jednak, że Scala przeskoczyła ograniczenia Javy.

tylko że Scala boxuje sobie inty niejawnie kiedy jej trzeba, bo jest to narzucone przez JVM.
w .NET boxing zwykle nie jest potrzebny:

var list = new List<int>();
list.Add(5); // tu nie ma boxingu
int i = list[0]; // tu nie ma unboxingu
string s = i.ToString(); // tu nie ma boxingu

Wracając do tematu; wybrałem C# a nie Javę bo Java była „wolnym oprogramowaniem” w zbyt dosłownym sensie, a IDE pożerały ogromne ilości pamięci. Visual zaś był w porównaniu z takim Eclipse'em lekkim edytorkiem.
Sam język sprawia też wrażenie przyjaźniejszego, mniej obarczonego uporem w rodzaju „nie będzie unsigned - nie bo nie”.
Mniejsza presja na zachowanie zgodności między wersjami pozwala na wprowadzanie do języka elementów których „się nie da” w Javie (tak jak „się nie dało” uniknąć type-erasure)

Ja również za bardzo C# nie wybierałem, został mi narzucony przez jeden z przedmiotów na uczelni. Spodobał mi się język oraz platforma i tak jakoś zostało. Wcześniej myślałem, że pójdę w C++ (w Turbo C++ 2006 też się przyjemnie formatki klepało), całe szczęście sprawy potoczyły się inaczej ;) W międzyczasie, gdy wyszedł Android, miałem też przygodę z Javą - szybko jednak się zakończyła. Miałem wrażenie, że w Javie, w porównaniu z C#, panował straszny burdel (tak nad int i Integer też się pamiętam głowiłem ;) Byłem jednak początkujący, więc wiele spraw pewnie po prostu nie rozumiałem. Zastanawiam się, czy gdybym dzisiaj rozpoczynał przygodę programowaniem i z C#, czy nie odniósłbym podobnego wrażenia jak wtedy z Javą. Jakby nie było C# również bardzo się rozrósł, przydałby by się jakiś C##, który trochę uporządkowałby składnię.

Ja zaczynałem w assemblerze na Commodore C-64, w którym napisałem kilka rzeczy, które rozeszły się po całym świecie, ale było to we wczesnych latach 90-tych, później był assembler na Amidze i C (C++) na Amidze. Strasznie ciężko było mi przestawić się z myślenia assemblerem na myślenie w C++. Na PC bawiłem się w na początku w Delphi, w którym zrobiłem mała bazę pewnych danych dla swojej firmy (nic z tego nie miałem, a jedynie łatwiejszą pracę :) Zresztą nie był to jakiś wielki poważny program ), później była Java (nie jestem programistą, nie mam zamiaru na tym zarabiać, i ciągle tylko się bawię). Wymyśliłem sobie przeglądarkę grafik w Java. Chciałem zrobić drzewo folderów takie, jak jest standardowe w Windowsie (Pulpit na górze, pod nim Mój komputer itd)... Okazało się to nie możliwe. Gdzieś na jakimś forum wyczytałem, że tak sie nie da, bo Java jest przenośna, i na przykład pod Linuksem takie drzewo by nie zadziałało, więc w Java się nie da. A że mam w nosie jakiegoś tam linuksa, wolę mieć drzewo folderów, więc zacząłem w C++. Tu mnie z kolei odrzuciło od tych wskaźników, wskaźników na wskaźniki, operatorów wyłuskania, i wyłuskania z wskaźników i cholera wie z czego jeszcze :) Gdzieś przypadkowo trafiłem na C#. Myślałem wtedy, że to jakiś prosty język skryptowy albo opisowy jak HTML :) Kiedy jednak zacząłem się zagłębiać, coraz bardziej mi się podobał. Rzadko cokolwiek w nim robię, bo w zasadzie prawie wszystko już zrobili inni, ale czasem się bawię, i mi się podoba :)