c # - Kunne klare kode (specifikt .NET) nogensinde blive 'uhåndteret'?

Indlæg af Hanne Mølgaard Plasc

Problem



For nylig talte jeg med en af ​​mine venner, der havde startet en C ++-klasse for et par måneder siden (hans første eksponering for programmering). Vi kom ind på emnet C # og .NET generelt, og han gjorde mig opmærksom på, at han følte at det var 'dømt' for alle de almindeligt anførte problemer (lav hastighed, breakable bytecode osv.). Jeg var enig med ham i alle disse spørgsmål, men jeg holdt tilbage med at sige, at det var dømt, kun fordi jeg følte det med tiden kunne sprog som C # i stedet blive native kode (hvis Microsoft valgte at ændre implementeringen af ​​.NET fra en bytecode, JIT runtime miljø til en, der kompilerer direkte til native kode som dit C ++ program gør).


Mit spørgsmål er, er jeg ude til frokost her? Jeg mener, det kan tage meget arbejde (og det kan bryde for mange ting), men der er ikke nogen form for magisk barriere, der forhindrer C # -koden i at blive compileret indbygget (hvis man ville gøre det), right? Der var en tid hvor C ++ blev betragtet som et meget højt niveau sprog (som det stadig er, men ikke så meget som tidligere), men nu er det grundstenen (sammen med C) for Microsofts oprindelige API'er. Ideen om at. NET kunne en dag være på samme niveau som C ++ i den henseende synes det kun at være et spørgsmål om tid og kræfter for mig, ikke noget grundlæggende fejl i sprogets design.


REDIGER : Jeg skal tilføje, at hvis indbygget compilering af .NET er muligt, hvorfor vælger Microsoft ikke at gå den rute? Hvorfor har de valgt JIT bytecode path?

Bedste reference


Java bruger bytecode. C #, mens det bruger IL som et mellemliggende trin, har altid samlet til indbygget kode. IL tolkes aldrig direkte til udførelse som Java bytecode er. Du kan endda pre-compilere IL før distribution, hvis du virkelig vil (hint: ydeevne er normalt bedre i det lange løb hvis du ikke gør det).


Tanken om at C # er langsom er latterlig. Nogle af komponenterne winforms er langsomt, men hvis du ved hvad du gør C # selv er et meget hurtigt sprog. I denne dag og alder kommer det alligevel algoritmen alligevel, sprogvalg vundet ' t hjælpe dig, hvis du implementerer en dårlig boble sortering. Hvis C # hjælper dig med at bruge mere effektive algoritmer fra et højere niveau (og i min erfaring gør det generelt), der vil trumfere nogen af ​​de andre hastighedsproblemer.





Baseret på din redigering vil jeg også gerne forklare den (typiske) kompileringssti igen.


C # er kompileret til IL. Denne IL er distribueret til lokale maskiner. En bruger kører programmet, og det pågældende program er derefter JIT-kompileret til native kode for den pågældende maskine en gang . Næste gang brugeren kører programmet på den pågældende maskine, kører de en fuldt indbygget app. Der er også en JIT optimizer, der kan mudrede ting lidt, men det er det generelle billede.


Grunden til at du gør det på denne måde er at give enkelte maskiner mulighed for at lave kompileringstidsoptimeringer, der passer til den pågældende maskine. Du ender med hurtigere kode i gennemsnit end hvis du distribuerede den samme fuldt udarbejdede app til alle.





Hvad angår dekompilering:


Den første ting at bemærke er, at du kan pre-kompilere til native kode før distribution, hvis du virkelig vil. På dette tidspunkt er du tæt på det samme niveau som om du havde distribueret en indbygget app. Det vil dog ikke stoppe en bestemt person.


Det misforstår også stort set økonomien ved spil. Ja, det kan måske være, at nogen måske omvendt-gør dit arbejde. Men det går ud fra, at hele værdien af ​​appen er i teknologien. Det er meget almindeligt, at en programmør overgår værdien af ​​koden og undervurderer udførelsen af ​​ produktet : interface design, marketing, forbindelse til brugere og løbende innovation. Hvis du gør alt Den rigtige, lidt ekstra konkurrence vil hjælpe dig så meget som det gør ondt ved at opbygge efterspørgslen på dit marked. Hvis du gør det forkert, vil du gemme din algoritme ikke for at spare dig.


Hvis du er mere bekymret for din app, der vises på warez-websteder, er du endnu mere misforstået. Det kommer alligevel op. En meget bedre strategi er at engagere dem.





I øjeblikket er den største hindring for adoption (imo), at den omfordelbare ramme er blevet mammut i størrelse. Forhåbentlig vil de adressere det i en relativt nær udgivelse.

Andre referencer 1


Foreslår du, at den kendsgerning, at C # er styret kode er et design fejl ??

Andre referencer 2


C # kan indbygges nationalt ved hjælp af værktøj som NGEN, og MONO (open source. Net framework) holdet har udviklet fuld AOT (før tid) kompilering, der tillader c # at køre på IPhone. Imidlertid er fuld kompilering culbersome, fordi det ødelægger kompatibilitet på tværs af platformen, og nogle maskinspecifikke optimeringer kan ikke gøres. Det er dog også vigtigt at bemærke, at .net ikke er et fortolket sprog, men et JIT (just in time) kompileret sprog, hvilket betyder, at det kører indfødt på maskinen.

Andre referencer 3


fyr, fyi, du kan altid kompilere dine c # samlinger i indfødte billeder ved hjælp af ngen.exe


og foreslår du .net er fejlbehæftet design? det var .net, der bragte tilbage ms tilbage i spillet fra deres crappy vb 5, vb 6, com dage. det var en af ​​deres største spil


java gør de samme ting - så foreslår du også java er en fejltagelse?


reg. store leverandører - vær opmærksom på .net har været enormt vellykket på tværs af virksomheder af alle størrelser (bortset fra de open source guys - intet galt med det). Alle disse virksomheder har foretaget betydelige investeringer i .net-rammen.


og at sammenligne c # hastighed med c ++ er en skør idé ifølge mig. giver c + + + + + + + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +


og du kan altid forvirre dine forsamlinger, hvis du er så paranoid om dekompilering


det handler ikke om c ++ v/s c #, administreret v/s unmanaged. begge er lige så gode og lige så magtfulde i deres egne domæner

Andre referencer 4


C # kunne kompileres nationalt, men det er usandsynligt, at base klassebiblioteket nogensinde vil gå der. På forsiden ser jeg ikke meget ud til at gå videre end JIT.

Andre referencer 5


Det kunne bestemt, men det virkelige spørgsmål er hvorfor? Jeg mener sikkert, det kan være langsomt, men det meste af tiden er der store forskelle i ydeevne, der kommer ned på designproblemerne (forkerte algoritmer, thread contention, hogging ressourcer osv.) I stedet for problemer med sproget. Med hensyn til 'breakable' bytecode ser det ikke ud til at være en stor bekymring for de fleste virksomheder, i betragtning af adoptionshastigheder.


Hvad det virkelig kommer ned på er, hvad er det bedste værktøj til jobbet? For nogle er det C ++; for andre, Java; for andre, C #, eller Python eller Erlang.

Andre referencer 6


Doomed? På grund af formodede præstationsproblemer?
Hvad med at sammenligne prisen på:



  • programmørens time

  • hardwarekomponenter



Hvis du har præstationsproblemer med applikationer, er det meget billigere for kun at købe dig selv bedre hardware i forhold til de fordele du taber ved at skifte fra et højere abstraktionssprog til en lavere (og jeg don ' Jeg har ikke noget mod C ++, jeg har været en C ++-udvikler i lang tid).


Hvad med at sammenligne vedligeholdelsesproblemer, når man forsøger at finde hukommelseslækage i C ++-kode i forhold til affaldssamlet C # -kode?


'Hardware er billig, programmører er dyre': http://www.codinghorror.com/blog/archives/001198.html[2]