C#: hvorfor c#?

[bergetun]

Jeg har programmert en del C og Java og har nettopp begynt aa programmere litt i C# i mono og jeg synes faktisk C# virker som ett fantastisk bra programmerings spraak.

 

Men ikke kom aa si at C# IKKE er en ripp off av Java for det er det.

De har proevd aa forbedre en del i forhold til java og har til en viss grad klart aa gjoere det.

[Manfred]

Er det agurktid selv på forumet siden alle driver og fisker opp forferdelig gamle tråder?

 

å kalle C# en rip-off er litt drøyt... Du kan si det om J#, men ikke C#... hva baserer du utsagnet ditt på, egentlig?

[Tr1llobite]

C# kjører på en "just-in-time" sak, akkurat som java, ja... det kompileres til en egen kode som kjøres på en "virituell maskin".

 

i XP SP 2 vil .net rammeverket ligge inne som standard, og .net i longhorn vil være en enorm forbedring i forhold til .net framework 1.1 som ligger ute nå. gled dere

Kvir meg...

[Oracel]

Det er vel ikke så vanskelig å se at C# har hatt Java som modell, og også at C# og .Net tar sikte på å utkonkurrere Java. Å tro og mene noe annet vil være naivt. Hva Microsofts (sjefs)utviklere sier om saken ville jeg tatt med en klype salt; det er klart man ikke vil innrømme at inspirasjonen hovedsaklig har kommet fra en konkurrent, tror ikke noen ville gjort det.

 

Det blir brukt argumenter både når det gjelder ytelse, plattform(u)avhengighet, og syntaktiske forskjeller/likheter. Når det gjelder dette så har jeg i tidligere innlegg påpekt at Java's syntax hovedsaklig er basert på C/C++, og dette gjelder fortsatt. Studerer man oppbygningen av metode-hoder, konstruktører, tokens (paranteser, curly brackets, square brackets, operatører, og betydningen til disse), osv, så ser man at det er mildest talt klare likheter mellom C/C++ og Java. Sammenlign med f.eks. Pascal, BASIC, og diverse andre språklige digresjoner hvis dere vil se syntaktiske annerledesland-språk.

 

I tillegg har C# støtte for assembly-directives, ihvertfall i MS' inkarnasjon av dette språket, jeg har ikke studert hvorvidt dette er standard C#. Vil legge til i samme åndedrag at C# IKKE er en av MS' kreasjoner, dette er et åpent ikke-proprietært språk på linje med C/C++ (i kontrast til Java).

 

API-messig er Java og C# også ganske like, forskjellene ligger hovedsaklig i plasseringene i API'et. C# er generelt litt mer avvikende fra den smale OOP-sti i forhold til Java da noen datastrukturer blir behandlet "spesielt". F.eks. blir en hashtabell behandlet/abstrahert som et assosiativt fleksibelt array i C#, mens Java benytter konsise tilgangsmetoder. Collections og hashtabeller er bare ett av flere eksempel.

 

Ytelsesmessig ligger Java kilometervis foran C#, og millimetervis bak optimisert native kode, for å snakke i metaforer.

[GeirGrusom]

Hvor tar du dette fra?

 

API-messig er Java og C# også ganske like, forskjellene ligger hovedsaklig i plasseringene i API'et. C# er generelt litt mer avvikende fra den smale OOP-sti i forhold til Java da noen datastrukturer blir behandlet "spesielt". F.eks. blir en hashtabell behandlet/abstrahert som et assosiativt fleksibelt array i C#, mens Java benytter konsise tilgangsmetoder. Collections og hashtabeller er bare ett av flere eksempel.

 

Du kan programmere .NET i mer eller mindre det språket du vil, det som følger med Visual Studio .NET for .NET er:

C++.NET

Visual Basic.NET

C#

J#

 

Etter det de sa på .NET Developers Conference så vil Eiffel.NET også etter hvert komme ut (dette er også diskutert i SQL Server Magazine)

 

I tillegg har C# støtte for assembly-directives, ihvertfall i MS' inkarnasjon av dette språket, jeg har ikke studert hvorvidt dette er standard C#. Vil legge til i samme åndedrag at C# IKKE er en av MS' kreasjoner, dette er et åpent ikke-proprietært språk på linje med C/C++ (i kontrast til Java).

 

Jeg har ikke hørt om noen assembly funksjon i C#, men jeg vet det er støtte for pekere der (hvis du deklarer funksjonen med unsafe)

 

Ytelsesmessig ligger Java kilometervis foran C#, og millimetervis bak optimisert native kode, for å snakke i metaforer.

C# blir gjort om til native code når du starter programmet,

dette blir gjort av Frameworket som ligger på maskinen.

C#->CLR Code->Native Code

Java->Java Byte Code->Virtual Machine

 

Det er ingen Virtual Machine i .NET

[Oracel]

GeirGrusom, har vanskelig for å forstå hvor du vil med den første paragrafen din; jeg har ikke diskutert hvilke språk som MS' utviklingsverktøy kan kompilere for .Net. Vil gjøre GeirGrusom oppmerksom på at jeg differensierer klart mellom C# som språk og .Net som plattform i mitt innlegg.

 

Når det gjelder assembly attributes (beklager at jeg ordla meg feil i mitt forrige innlegg) finner du en god beskrivelse her.

 

Videre tar du feil når du sier at .Net ikke har en virtual machine, i noe oversatt forstand. Java's implementasjon av en virtual machine heter JRE. .Net har en ekvivalent til en JRE som heter CLR (Common Language Runtime). CLR er IKKE, og jeg vil gjerne understreke dette siden du tilsynelatende ikke har forstått dette konseptet, det samme som java bytecode. .Net's ekvivalenter til bytecode er så langt MSIL (Microsoft) og CIL (Mono), hvor "IL" normalt betyr "Intermediate Language", nærmere bestemt en bytecode ekvivalent. En god forklaring på hvordan kjøring av programmer i .Net foregår finner du her.

 

Så jo, Java og .Net programmer kjøres begge på en "virtual machine", i den forstand at Java kaller det JRE, mens .Net kaller det CLR. Utover dette er det selvsagt forskjeller, men det overordnede konseptet er fortsatt det samme. Håper dette ga deg en bedre forståelse av dette emnet.

[CronoMan]

Neidu, Oracel, jeg tror du tar litt feil, Microsoft sin CLR er ikke det samme som Javas ByteCode idet hele tatt. CLR er et bytecode-aktig språk som ligger i binærfilene til .NET programmer, og som blir kompilert av .NET framework første gangen det blir kjørt på en ny datamaskin. Og dette gjør at .NET er primært native code, og ikke direkte avhengig av noen som oversetter for den.

[Oracel]

Tydelig at CronoMan ikke har undersøkt dette teamet til tross for at jeg til og med la ved en svært godt forklarende link i mitt forrige innlegg. Velger å henvise CronoMan til http://www.csharpfriends.com/Articles/getA...x?articleID=227.

 

Her er noen sentrale sitater:

 

To enable the runtime to provide these services, language compilers are required to compile source code into an intermediate language code. All.NET languages (such as Visual Basic .NET, Visual C++ .NET, Visual J# .NET, and of course Visual C#.NET), which aspire to use the CLR services compile (commandprompt>csc <filename>. cs) to something, called Portable Executable (PE). PE is a collection of Microsoft Intermediate Language Code (MSIL) and Metadata.

 

Videre en forklaring på hva MSIL er:

 

MSIL is a CPU-independent set of instructions and Meta data is the data that describes to the runtime the types, members and references in the code.

 

MSIL includes instructions for loading, storing, initializing and calling methods on objects as well as instructions for arithmetic and logical operations, control flow, exception handling.  All components developed on .NET carry information (metadata) about the components and resources they were built against. The runtime uses this information to ensure that your component or application has the specified versions of everything it needs.

 

Ringer det en bjelle? Når det gjelder CLR:

 

The stub program starts the CLR just-in-time (JIT) compiler, which compiles the MSIL program code to native Win32 code that can be run on the system.

 

Vil påpeke at også Java benytter seg av JIT. Håper dette ga deg en forståelse av at prinsippene er de samme både for .Net og Java. Mener nå at øvrig kommentar er unødvendig.

[exchange]

which aspire to use the CLR services compile (commandprompt>csc <filename>. cs) to something, called Portable Executable (PE). PE is a collection of Microsoft Intermediate Language Code (MSIL) and Metadata.

 

nei, dette er ikke riktig. Når du kompilerer et .net språk får du en managed modul som er enten en .exe eller .dll. En eller flere relaterte moduler kalles en assembly,

 

en managed module inneholder 4 komponenter:

 

En windows pe header, som alle windows apps har.

 

.NET framework fil header, start punktet for appen (main)og runtime versjon som modulen ble kompilert mot, og pekere til metadata.

 

Metadata, beskriver hvilke typer som selve modulen inneholder og typer i refererende moduler

 

MSIL: managed kode produsert av kompileren

 

-----------

PE header inneholder flere felt, og et av de viktigste, forteller hvor i koden oset skal hoppe til, når man loader appen. Problemet med en managed modul er at den ikke inneholder native machine kode, og derfor må PE header inneholde en JMP instruksjon til _CorExeMain i McCoreEE.dll (til runtimen), som lastes inn i minnet.

Denne får info om hvor il ligger og kopilerer fortløpende (jit)

 

I Xp og server 2003, har man gjort visse endringer. Her vet oset at det er snakk om en managed module og loader runtimen direkte, uten steget innom JMP instruksjonen.

[GeirGrusom]

PE (Portable Executable) er det vanlige .exe file formatet

 

en PE header består igjen av tre deler:

Header

COFF header

Optional header

 

PE header inneholder flere felt, og et av de viktigste, forteller hvor i koden oset skal hoppe til, når man loader appen. Problemet med en managed modul er at den ikke inneholder native machine kode, og derfor må PE header inneholde en JMP instruksjon til _CorExeMain i McCoreEE.dll (til runtimen), som lastes inn i minnet.

Denne får info om hvor il ligger og kopilerer fortløpende (jit)

 

En managed module kan inneholde unmanaged kode

[exchange]

Det er ingen Virtual Machine i .NET

 

jo selvfølgelig er det det.

CLR er analog til JVM

[exchange]

En managed module kan inneholde unmanaged kode

 

nei det er ikke unmanaged code i en modul.

clr jobber mot assemblyer(gruppering av en eller flere moduler)

 

du har følgende metoder for å bruke unmanaged code.

 

1. managed code kan calle unmanaged funksjon i en dll via P/invoke

2. managed code kan bruke en com komponent

3. unmanaged code kan bruke en managed type

 

du kan også bruker /clr switchen i c++ kompileren, koden vil bli managed men ikke data( forsatt være data typer uten metadata assosiert mot dem)

[søppel4]

Jeg vet ikke om dere er klar over det, men denne forvirringen er en del av Microsoft sin strategi.

 

Forvirring skaper sau(hu)er, og sauer er lette å forme. Dette er det Bush gjør (+ redsel), og det Sun gjorde for noen år siden med Java.

 

Ta [insert programminglanguage here] for det det er. Undersøk det grunnleggende også. Ikke vær naive - ikke stol på det overfladiske, eller det som skjer på overflaten uten at det grunnleggende gjør at det ikke ser ut som "magi".

[Manfred]

Er du paranoid eller noe?

[GeirGrusom]

The Visual C++ compiler translates data, pointers, exceptions, and instruction flow between managed and unmanaged contexts automatically and transparently. This process allows managed code to interoperate seamlessly with unmanaged C++ code.

 

You are given control over what data and code should be managed. This feature is supported by the ability to choose whether each class and function is managed or unmanaged. This flexibility is needed, because some types of code or data perform better in an unmanaged environment. However, managed code typically offers enhanced developer productivity because of features such as garbage collection and managed class libraries.

 

Dete er bare sprøyt altså?

eller mener du at en assembly kan inneholde unmanaged og managed moduler, så hvis jeg i C++ skriver

__nogc class UnmanagedClass
{
 public:
 void MyFunction(void);
};
public __gc class ManagedClass
{
 void MyFunction(void)
 {
   UnmanagedClass c = new UnmanagedClass;
   c.MyFunction();
   delete c;
 }
};

Så vil alt dette bli unmanaged?

eller delt i to moduler?

Endret 19. mars 2005 av GeirGrusom

[Format71]

Må bare si at det irriterer meg at Delphi aldri blir nevnt i kranglene om hvilket språk c# og .net har stjelt mest fra. .net framework er veldig inspirert av delphis bibliotek, noe som er helt naturlig da det er samme mann som har spesifisert begge.

 

-Vegar

[GeirGrusom]

Delphi er Pascal, mens C# og Java har C/C++ syntaks, dessuten har ikke .NET framework eller Java noe til felles med Delphi(i virkemåte)

 

Men om bibliotekene til .NET og Delphi har samme oppbygning kan vel kanskje stemme, har bare brukt Turbo Pascal før, og ikke delphi så jeg vet ikke.

[j000rn]

"Må bare si at det irriterer meg at Delphi aldri blir nevnt i kranglene om hvilket språk c# og .net har stjelt mest fra"

 

Har det så mye å si hvilket språk/framework .Net har stjålet fra? Er det ikke bare positivt at de har "stjålet" ting fra flere steder og tatt det beste derfra?

 

Og alle programmeringsspråk har stjålet idéer fra andre steder. Eller trodde dere Pascal og Java var en total ny idé hvor alt var unikt da de ble lansert?

 

----

 

Fordelene med C# som jeg syntes er viktige:

* Utviklingsmiljø (VS.Net)

* Mye mer ryddig og lesbar kode enn noe annet språk jeg har vært borti (særlig VB(.Net) og Pascal/Delphi)

* Ryddig Framework klasser. Kanskje litt smak og behag, men finner alt jeg "leter etter" i .Net med en gang mens Java og Delphi virker rotete.

* Mulighet for å lage alle typer applikasjoner i ett og samme miljø, f.eks. console, windows app, services, webapplikasjoner, webservices, "wap" sider/mobile web applications, etc.

* Mulighet for å kjøre på Linux (mono)

* Reflection er genialt i forhold til Java.

* Selvfølgelig bra "kommunikasjon" mot andre M$ produkter (SQL Server, Windows selv (System.Diagnostics), Message Queue, etc).

* At .Net framework "følger med" Windows, mens f.eks. Java må lastes ned og installeres. Evt. at man kan fortelle kunder at de må kjøre Windows Update istedenfor å geleide dem gjennom (ukjente for kunden) sun.com og laste ned (også ukjent for kunden) Java...

* Bra støttet av Microsoft. F.eks. kommer vel DirectX med nesten bare eksempler for .Net nå?

 

I tillegg har jeg aldri hatt (store) problemer med .Net applikasjoner. Særlig Java applikasjoner har jeg nesten gitt opp å kjøre på min maskin da de ofte kræsjer eller bruker alt for mye cpu. Har jobbet med noen veldig enkle server applikasjoner med minimal trafikk i java som over lengre tid har stått og brukt 100% cpu. Etter å ha konvertert dem til .Net er det ikke lenger merkbart at de kjører og har aldri kræsjet. Dette er også fra flere leverandører (ene er Telenor) som har kjørt på flere servere med samme resultat... (bør kanskje heller skylde på dårlige programmerere/kode, men da jeg ser disse problemene med java applikasjoner til stadighet så blir jeg litt "fordomsfull").

[A!1]

Det er mange som nevner mono som et alternativ til MS VS.NET her... Har noen av dere prøvd mono? Hvor modent er 1.1.6 (som kom 31.03.05)? Det ser jo ut som den kan kompilere både C# 1.0 (VS.NET 2003) og noe C# 2.0 (VS.NET 2005) kode ut fra hjemmesiden.

 

Stemmer dette? Kan jeg f.eks. bare kopiere et prosjekt jeg har fra VS.NET over i Linux og mono og kompilere dersom jeg bare har brukt ting som ligger under namespace "System"?

[j000rn]

Trenger ikke rekompilere det på linux boksen engang. Holder å bare kopiere over aspx/exe/dll filer og kjøre ivei

 

Men noen få unntak selvfølgelig. Programmer som bruker veldig windows spesifike funksjoner (api-kall f.eks.) vil ikke virke. I tillegg er linux case-sensitivt og har ikke samme katalogstruktur som windows. Men dette sier jeg jo igrunn selv. Jeg har ikke hatt noe problemer med å flytte over .Net applikasjoner til Mono ihvertfall...

 

Ang. kompilerting så trenger du ikke bare bruke System namespacet heller, men andre references du bruker må være ".Net kompatible" (se paragraf over) for å få kjørt programmet ditt på Linux (selv om du sikkert fortsatt får kompilert).