Jag håller på och går en kurs i webbutveckling där vi använder asp.net med vb.net men vart jag än vänder mig för hjälp på nätet så tycker jag alla verkar använda c#.

Nu till min fråga: Finns det några fördelar med c# förutom att man kanske gillar syntaxet bättre?

Anledningarna till att jag funderar på att byta till c# är även att jag dels vill vara så attraktiv som möjligt på arbetsmarknaden och dels att jag gärna skulle vilja ha något som är lite likt i syntaxet java som jag även håller på med litegran.

Hej,

När det gäller vilket språk du ska lära dig så är mitt tips : Lär dig båda! Syntaxen är enkla att lära sig, den mesta tiden kommer du ändå att lägga på att lära dig ramverket och allt runt omkring.

Rent praktiskt så har VB.Net en stor brist just nu, i större projekt så hänger sig utvecklingsmiljön ibland upp till 15-20 sekunder så fort man redigerat och lämnat en rad (när bakgrundskompileringen kickar in). Vi har grymt stora problem med detta i det projekt som jag jobbar med just nu. Frustrerande...Jag är osäker på om alla råkar ut för det eller om det finns omständigheter som gör att det uppstår, men helt klart är att vi inte är ensamma. Jag har stött på många med samma bekymmer i nyhetsgrupper. Så min rekommendation just nu är : Satsa på C#.

Så fort problemet med VB.Net är fixat så återgår jag till rekommendationen : Välj vad du vill, det spelar ingen roll för 95% av alla projekt.

Eller som någon sa i en nyhetsgrupp. "Varken C# eller VB.Net är bäst, för de FINNS INTE! Det enda som finns är IL (Intermediate Language), allt annat är syntaktiskt socker ovanpå IL"...Tror det var Karl E Peterson som sa det...

/Per Hultqvist

nja det är ju inte helt sant.

även om det är en minimal skillnad så har iaf c# pekare, och visst man kanske inte använder det varje dag precis , men ska du göra lite mer hardcore windows api saker så är det väldigt väldigt praktiskt att det finns...

men som sagt ... sysslar man bara med att göra simpla guin och data access så är det ingen större skillnad..

//Roger

Well, det var det jag menade med att för 95% (givetvis är siffran 95 taget ur luften) av programmen så spelar det ingen roll...de sista 5% representeras av de program som kräver pekare eller om man skriver någon slags komponent åt andra programmerare där man vill använda operator overloading el dylikt...men dessa typer av program är absolut i minoritet...

/Per Hultqvist

pekarna i C# funkar inte riktigt som pekare i ahrdcore windows api välrden ... du är fortfarande inne i managed heapen ...

Sen är det en masa nadra skillnader på hur effektivt c# / vb.net kompilatorerna genererar IL kod. Rent generellt blir det effektivare och renare IL av C# kompialtorn

Hmm...jag har svårt att tro att skillnaden på den genererade IL:en skulle vara speciellt stor (iallafall utan att ha sett bevis för det). Har du typ någon länk eller dylikt där man kan läsa mer om detta påstående...

Ta tex inkrementeringssyntaxet (++) som ökar en variabel med ett. Detta syntax har ju kommit till eftersom det oftast finns väldigt effektiva maskinkodsinstruktioner som ökar en minnescells värde med ett. Grejen är att även om VB.Net inte stödjer ++-operatorn så är det inget som hindrar att kompilatorn genererar optimerad kod för detta. Man kan alltså inte (enbart) titta på språkets design när man avgör effektiviteten...undrar om det inte är något liknande som ligger bakom påståendet att C# skulle vara effektivare.

( En parentes :
I själva verket så genereras exakt samma IL-kod av C# och VB.Net när man ökar en variabel med ett oavsett om man skriver i++,i+=1 eller i=i+1. Dock så är overflowcheck default i VB.Net men inte i C# så man måste använda keywordet Checked för att få exakt samma kod :

IL_0006: ldloc.0
IL_0007: ldc.i4.1
IL_0008: add
IL_0009: stloc.0
)

Å andra sidan så kan MS ha lagt mer krut på C# kompilatorn eftersom de antagligen använder den själva betydligt mer än VB-Net kompilatorn...så kanske stämmer det iallafall...äsch jag vet inte...jag har alltid gillat VB.Net och vill alltid försvara det även om jag fattat ett principbeslut att bara programmera C# när jag själva får bestämma (får inte alltid det eftersom jag konsultar :-) så jag kanske har fel :-)

Ärligt talat så låter det lite som en grej som C#-communityt hittat på för att tracka VB-programmerarna som aldrig verkar accepteras av andra programmerare (programspråkrasister? lol) :-)

/Per Hultqvist (som programmerar VB.Net på jobbet och C# hemma)

prova att göra en enkel strängjämförelse i båda språken, eller binda mot ett event...

sök i forumet dessutom, har skickat upp all il för edn ngn gång

Ok, har testat strängjämförelsen i både C# och VB.Net och visst finns det en skillnad. Skillnaden beror på ett par faktorer:

1) VB.Net anropar default MicroSoft.VisualBasic.CompilerService.StringType.StrCmp som tar 3 argument, de två strängarna som ska jämföras samt en boolean . C# anropar String.Equals() som bara tar två strängar, så jämförelsen skevar lite när de anropar tvåolika funktioner med olika funktionalitet. StrCmp kan hantera fallet att tomsträng = Nothing i VB.Net.

2) VB.Net lägger in ett par "NOP" som inte gör någon nytta. En besvikelse måste jag erkänna...

3) Om man i VB.Net anropar samma funktion som C#, dvs String.Equals() så får man exakt samma IL (bortsett från NOP:arna som jag nämnde tidigare) :

If String.Equals(s,"hej") Then....

i stället för :

If s="Hej" Then ...

Jag orkar inte kolla fler exempel utan konstaterar att du antagligen har rätt. C# genererar mer slimmad kod om man använder "default-syntax" men att det antagligen i de flesta fall går att skriva VB.Net kod som är lika slimmad som C# om man konsekvent skriver "ramverkskompatibel" kod, dvs att inte använda Microsoft.VisualBasic-namespacet. Själv undviker jag alltid att göra detta ändå, men det var intressant att få det bekräftat att det gör nytta :-).

/Per Hultqvist

Helt ovetande om syftet med att ha NOP (No OPeration) med i IL-koden så kan jag gissa på att de finns där av två orsaker, nämligen:
1. Precis som i assembler använder man NOP's för att alignera koden så att så många operatorer som möjligt ligger alignerat på ett 32-bitars ord för bästa möjliga prestanda (i avseendet minnesaccesser).
2. NOP fyller också en annan funktion i assembler (som inte är trolig i IL-kod men ändå ett tänkbart alternativ) nämligen att slösa klockcykler för att synkronisera koden så att fler instruktioner kan samköras.

Som sagt detta är gissningar utan någon som helst bas. Andra förklaringar får ni gärna komma med då jag blev nyfiken av den föregående diskussionen.

För att se om det du sa kunde stämma (vilket ju det onekligen gör för assembler) så kollade jag lite närmare på VB:s IL-kod för exemplet ovan. Det finns tre NOP:ar varav en inledande som verkar helt ologisk. NOP nr två förskjuter en instruktion från plats 20 (Hex 14) till 21 (Hex 15) vilket inte heller verkar finnas någon mening med. Jag kan iallafall inte se att de gör någon nytta, och C# genererar ju samma kod fast utan NOP:arna så helt klart är att de inte "måste" vara där....

Någon som vill ge sig på att förklara dessa? Inte för att det är en överdrivet viktig diskussion men ibland är det kul att gå in på detaljerna :-)

<code>
.method private instance void Form1_Load(object sender,
class [mscorlib]System.EventArgs e) cil managed
{
// Code size 25 (0x19)
.maxstack 2
.locals init ([0] string s)
IL_0000: nop
IL_0001: ldstr "per"
IL_0006: stloc.0
IL_0007: ldloc.0
IL_0008: ldstr "Kalle"
IL_000d: call bool [mscorlib]System.String::Equals(string,
string)
IL_0012: brfalse.s IL_0017
IL_0014: nop
IL_0015: br.s IL_0017
IL_0017: nop
IL_0018: ret
} // end of method Form1::Form1_Load

</code>

/Per Hultqvist

använd /optimize flaggan på vb.nert kompilatorn så försvinner alla NOP's

och ja, det finns en teroetisk möjlighet att skriva kod som är lika slimamd i vb.net .. Men att rent praktiskt hålla reda på vad VB.NET gör under ytan och hur C# gör det samma är ngt för grabbar och tjejer utan hobby ... Bättre att kunan använda sig av språksyntaxen direkt och sluta bry sig ...

Måste det vara en win-app för att få NOP'sen? för i console får jag inge sånt.