Jag undrar om man i VS.NET kan använda olika språk i ett o samma program? T.ex. VB sköter gränsnittet och C++ till den lite tyngre koden... Jag har inte sett någon info om detta men eftersom de båda bygger på framework så borde det ju gå...

Mvh /Ale

Japp du kan utan problem använda olika språk i ett och samma program.

/Fredrik N

>>T.ex. VB sköter gränsnittet och C++ till den lite tyngre koden
Eftersom allt blir IL kod så BORDE det inte spela så stor roll vilket språk du använder. Det är ju inte enklare/svårare att skriva ett GUI i vb.net än i C#...(vet ej c++.net).
I vs.net måste du väl sen ha ett projekt för varje språk.

För att klargöra lite så är det så att du i VS.NET bara kan ha ett språk per projekt. Men om du vill ha olika delar i olika språk så gör du enklast så att du skapar flera delprojekt i en och samma solution, med ett språk i varje projekt.

Det finns inget i .NET/CLR/IL som hindrar dig från att blanda flera språk i samma assembly (ungefär DLL eller EXE). Om du kompilerar direkt med csc.exe och vbc.exe så kan du skapa objektfiler som du länkar samman på slutet.

Men, följdfrågan blir varför du vill ha olika språk för gränssnitt och "tyngre koden". Att du vill dela upp dem i olika projekt är helt förståligt, men det finns ingen riktigt bra orsak att skriva de olika delarna i olika språk. Du har inte bättre prestanda i Managed C++ eller C# än du har i VB.NET. Tvärtom måste jag säga att Managed C++ nog faktiskt är mindre produktivt än VB.NET eller C#, och det spelar ju också inte när man väljer utvecklingsmiljö.

/Mattias

Jag tänkte så att om man ska använda assembly-kod så brukar man väl göra det i C++? T.ex. om man gör ett stort program i VB.NET o i efterhand kommer på att något måste skrivas i assembly för att få upp fart så kanske man behöver använda C++

Mvh /Ale

Eftersom "assembly" du skulle kunna använda är IL (Intermediate Language), som är .NET's "assembly" spåk så finns det ytterst lite att vinna eftersom samliga kompilatorer (Managed C++, C# eller VB.nET etc etc) alla generar IL med i princip identisk prestanda.. skulle troligen vara små optimeringar du skulle kunna utnyttja.

---
<b>Andreas Håkansson
Student of Software Engineering</b>

Fast just när det gäller C++ så kan man faktiskt skapa native applikationer, dvs riktiga x86 applikationer och inte IL. Fast de fall när man utnyttjar detta av prestandaskäl borde vara ganska få.

De flesta applikationer brukar ha kommunikation med externa system, t.ex. databas. Den tid som ett databasanrop tar, speciellt om man får sidfel och måste ladda från disk, är mycket större än den tid man vanligtvis vinner på assembler optimering.

Tolka mig inte fel nu, riktigt optimerad assembler kod kan säkert vara snabbare än VB6, VB.NET eller Managed C++. Men jag har under mina snart 10 år som utvecklare inte råkat ut för ett fall när man har valt att gå denna väg, man offrar gärna lite prestanda för att få kod som är lätt att utveckla och underhålla.

/Mattias