[VB6->VC++] Overstappen naar VC++, of toch VB.Net / C#? *

[iznogood]

Ik ben al jaren bezig met het programmeren in Visual Basic ( vooral programmeren van windows apps ). Nu loop ik steeds vaker tegen de limitaties van VB aan en heb ik besloten over te gaan stappen naar VC++. Over de grondbeginselen van het programmeren mbv MFC kan ik weinig vinden op internet, zijn hier goede online tutorials voor ? Ik heb al een tijd geprogrammeerd in CPP/PHP, maar ik heb nog wel moeite met het maken van Windows apps... wat moet ik hier over weten ?

Wat zijn verder de voordelen van VCPP boven VB ? Bij vb kan ik bijvoorbeeld internet controls, winsock controls enz invoegen, is dit ook zo eenvoudig mogelijk met vc++ ?

Is het verder verstandig om over te stappen naar .net ? wat zijn de voordelen hiervan boven vc++ 6?

[whoami]

Ik zou overstappen naar VB.NET of naar C# als ik van jou was.
Het verschil tussen VB6 en .NET zal niet zo groot zijn als het verschil tussen VB6 en VC++.
In VC++ moet je nl. niet denken dat je op eenzelfde manier een GUI in elkaar zult kunnen klikken als in VB6. In .NET heb je die mogelijkheid wel.
Daarbij komt nog eens dat je in .NET in een managed omgeving werkt, moet je niet zoveel rekening houden met geheugenbeheer, heb je meer faciliteiten om security in te bouwen, en je hebt de beschikking over een zeer uitgebreid framework.

Daarnaast is MFC eigenlijk een framework die -afaik- niet meer doorontwikkeld wordt. MS heeft besloten om volledig voor .NET te gaan, dus, als ik van jou was, en jij wilt verder doen met de ontwikkeling van windows applicaties, dan zou ik ook voor .NET gaan.
(Ook in .NET kan je met C++ werken, als je dat perse zou willen).

[iznogood]

whoami schreef op dinsdag 22 maart 2005 @ 08:49:
Ik zou overstappen naar VB.NET of naar C# als ik van jou was.
Het verschil tussen VB6 en .NET zal niet zo groot zijn als het verschil tussen VB6 en VC++.
In VC++ moet je nl. niet denken dat je op eenzelfde manier een GUI in elkaar zult kunnen klikken als in VB6. In .NET heb je die mogelijkheid wel.
Daarbij komt nog eens dat je in .NET in een managed omgeving werkt, moet je niet zoveel rekening houden met geheugenbeheer, heb je meer faciliteiten om security in te bouwen, en je hebt de beschikking over een zeer uitgebreid framework.

Daarnaast is MFC eigenlijk een framework die -afaik- niet meer doorontwikkeld wordt. MS heeft besloten om volledig voor .NET te gaan, dus, als ik van jou was, en jij wilt verder doen met de ontwikkeling van windows applicaties, dan zou ik ook voor .NET gaan.
(Ook in .NET kan je met C++ werken, als je dat perse zou willen).

De bedoeling is eigenlijk om gebruik te maken van een groter geheugen ( 64MB+ ) en de codesnelheid van cpp. Ik denk niet dat VB.Net mij dat kan bieden. Ook word ik simpel van dat gesubclass... wat met de messages in CPP makkelijker te ondervangen is ? Wat zijn de CPP mogelijkheden binnen .net ? Is het hier wel makkelijker geworden om een GUI te maken ?

Waarom raad je me in eerste instantie zo af om in het vervolg apps te gaan ontwikkelen met cpp ?

[ Voor 4% gewijzigd door iznogood op 22-03-2005 09:00 ]

[edeboeck]

De bedoeling is eigenlijk om gebruik te maken van een groter geheugen ( 64MB+ ) en de codesnelheid van cpp. Ik denk niet dat VB.Net mij dat kan bieden.

Volgens cijfers die Microsoft zelf verspreid heeft, zou VB.Net sneller zijn dan CPP (maar weliswaar trager dan C++.Net, wat zelf trager is dan C#.Net)

[whoami]

In .NET kan je ook gebruik maken van een 'groter geheugen', en in VC++ kan je evengoed code schrijven die traag is.
.NET applicaties zullen wel een performance hit hebben, maar als je geen games of real-time app's oid wilt schrijven, zal je daar niet bijster veel van merken.
(Geheugen-allocatie in .NET is zelfs sneller dan geheugen allocatie in een niet managed omgeving).

Trouwens, wat bedoel je met 'dat gesubclass' ?

PS: wat is er belangrijker, die kleine performance hit, of de snelheid waarmee je zult kunnen ontwikkelen eens je ermee weg bent ?

[ Voor 22% gewijzigd door whoami op 22-03-2005 09:09 ]

[whoami]

edeboeck schreef op dinsdag 22 maart 2005 @ 09:07:
[...]


Volgens cijfers die Microsoft zelf verspreid heeft, zou VB.Net sneller zijn dan CPP (maar weliswaar trager dan C++.Net, wat zelf trager is dan C#.Net)

Heb je hier een link van ?

[farlane]

edeboeck schreef op dinsdag 22 maart 2005 @ 09:07:
Volgens cijfers die Microsoft zelf verspreid heeft, zou VB.Net sneller zijn dan CPP (maar weliswaar trager dan C++.Net, wat zelf trager is dan C#.Net)

Bollox

[iznogood]

edeboeck schreef op dinsdag 22 maart 2005 @ 09:07:
[...]


Volgens cijfers die Microsoft zelf verspreid heeft, zou VB.Net sneller zijn dan CPP (maar weliswaar trager dan C++.Net, wat zelf trager is dan C#.Net)

Dus C#.net of vb.net zou ik dan tussen moetten kiezen? Hoe groot is dit snelheidsverschil, of is dit niet aan te tonen?

Hoe is de integratie van directx9 in vb.net? En hoe zit het met de limitaties van vb.net tov c#.net in het algemeen?

In .NET kan je ook gebruik maken van een 'groter geheugen', en in VC++ kan je evengoed code schrijven die traag is.
.NET applicaties zullen wel een performance hit hebben, maar als je geen games of real-time app's oid wilt schrijven, zal je daar niet bijster veel van merken.
(Geheugen-allocatie in .NET is zelfs sneller dan geheugen allocatie in een niet managed omgeving).

Trouwens, wat bedoel je met 'dat gesubclass' ?

PS: wat is er belangrijker, die kleine performance hit, of de snelheid waarmee je zult kunnen ontwikkelen eens je ermee weg bent ?

Met dat gesubclas bedoel ik het opvangen van window messages en hier een bewerking op uit te voeren. In Vb6 vind ik dat nogal omslachtig gaan.

Voor mij weegt de ontwikkeltijd erg zwaar, zo lang ik maar geen snelheidsproblemen krijg doordat ik voor de verkeerde prog. taal heb gekozen.

[ Voor 46% gewijzigd door iznogood op 22-03-2005 09:15 ]

[whoami]

farlane schreef op dinsdag 22 maart 2005 @ 09:10:
[...]


Bollox

Dat dacht ik zelf ook; aangezien VB.NET en C# naar dezelfde IL compileren, gebruik maken van dezelfde CLR, etc.... is het imo hoogst onwaarschijnlijk dat C# sneller zou zijn dan VB.NET en vice versa.

[iznogood]

whoami schreef op dinsdag 22 maart 2005 @ 09:13:
[...]


Dat dacht ik zelf ook; aangezien VB.NET en C# naar dezelfde IL compileren, gebruik maken van dezelfde CLR, etc.... is het imo hoogst onwaarschijnlijk dat C# sneller zou zijn dan VB.NET en vice versa.

Dus als je niet zou kijken naar de efficientie van de code zijn C# en VB.Net even snel ?

[farlane]

iznogood schreef op dinsdag 22 maart 2005 @ 08:58:
Waarom raad je me in eerste instantie zo af om in het vervolg apps te gaan ontwikkelen met cpp ?

Waarom probeer je niet gewoon eens een appje in elkaar te draaien met VC++. Zowel in VS.Net als in VS 6 kun je native ( non managed ) C++ executables maken. ( Of een van de gratis IDE's die te downloaden zijn )

Het werken met COM componenten ( ActiveX / OCX en die pruttel ) is wat minder handig in VC++:Het is er simpelweg niet voor gebouwd.

Het kan wel, en de IDE zal een wrapper voor je genereren die je kunt gebruiken om het component aan te spreken maar handig is anders.

Nee, de echte kracht van C++ komt pas los als je afziet van die constructies met ***IQueryInterfaceFromUnknownPropertySinkMarshallingSomething, maar gewoon een simpele dll gebruikt.
Of, om je Winsock voorbeeld erbij te halen, een van de vele gratis frameworks. Of je bouwt zelf een winsock appje door simpelweg zelf winsock aan te spreken.

Er gaat een wereld voor je open, en als je van leren houdt is het hartstikke leuk.

[farlane]

iznogood schreef op dinsdag 22 maart 2005 @ 09:17:
[...]

Dus als je niet zou kijken naar de efficientie van de code zijn C# en VB.Net even snel ?

Ja, maar altijd langzamer dan C++. punt

[iznogood]

farlane schreef op dinsdag 22 maart 2005 @ 09:19:
[...]

Er gaat een wereld voor je open, en als je van leren houdt is het hartstikke leuk.

Got it! Ik ben functies uit DLL bestanden meestal uit de weg gegaan. Ik zal er eens mee gaan stoeien Verder lijkt me dan de overstap naar VB.net een logische keuze. Bedankt voor de reacties.

[Verwijderd]

iznogood schreef op dinsdag 22 maart 2005 @ 09:17:
Waarom raad je me in eerste instantie zo af om in het vervolg apps te gaan ontwikkelen met cpp ?

C++ is een flink stuk gecompliceerder dan C# of VB.NET. Wel is het zo dat C++ een veel universelere taal is dan VB.NET en C#. Met kennis van C++ kun je multiplatform gaan ontwikkelen, met Microsofts eigen talen is dat een stuk lastiger. Ook bestaan er voor C++ vele libraries met functies die niet zo 1,2,3 beschikbaar zijn in andere talen. Tot slot, VB.NET en C# vereisen het .NET framework op de client. Op dit moment is dat bij heel veel gebruikers niet het geval zodat je programma daar niet werkt zonder dat ze ook het framework mee installeren. Met C++ kun je native windows 32 bits applicaties schrijven.Alles hangt dus sterk af van wat je wilt doen. Wel zou ik eigenlijk sowieso naar een .NET taal overstappen, Visual Studio 6 is ondertussen wel erg gedateerd.
De MFC zou ik trouwens zo snel mogelijk vergeten. Die is redelijk achterhaalt door .NET

Dus als je niet zou kijken naar de efficientie van de code zijn C# en VB.Net even snel ?

Dit hoeft natuurlijk niet.Bij C# en VB.Net is de programmacode niet altijd precies hetzelfde. Maar zelfs als je precies dezelfde code door twee verschillende compilers naar precies hetzelfde platform laat compileren ontstaan er snelheidsverschillen. Vandaar dat een hoop bedrijven de intel C++ compiler gebruikten als vervanging van de standaard MS C++ compiler in Visual Studio 6. De intel versie leverde snellere programma's op. Als dus de C# compiler betere code genereert als de VB.NET compiler zul je snelheidsverschillen zien, ook al leveren beide soortgelijke CLR code op.

[whoami]

Differences in IL between VB.NET and C#

Wat ik vreemd vind, is dat het in VB.NET blijkbaar mogelijk is om een method te maken die een waarde moet returnen, maar dat je dan in de uiteindelijke implementatie van die method gewoon niets returned ?

[gorgi_19]

even titel ietsje opgepoetst.

[gorgi_19]

whoami schreef op dinsdag 22 maart 2005 @ 09:56:
Differences in IL between VB.NET and C#

Wat ik vreemd vind, is dat het in VB.NET blijkbaar mogelijk is om een method te maken die een waarde moet returnen, maar dat je dan in de uiteindelijke implementatie van die method gewoon niets returned ?

Bedoel je iets als:

Visual Basic .NET:

Public Function Melp() as Integer

    Dim a as Integer = 5

End function

?

Impliciet returned hij dan Nothing

[ Voor 4% gewijzigd door gorgi_19 op 22-03-2005 10:00 ]

[whoami]

Ja; als ik goed gekeken heb in het artikel dat ik hier gepost heb, blijkt dit mogelijk te zijn.

gorgi_19 schreef op dinsdag 22 maart 2005 @ 10:00:
[...]


Impliciet returned hij dan Nothing

Dat is gewoon ranzig.

[ Voor 50% gewijzigd door whoami op 22-03-2005 10:01 ]

[gorgi_19]

Hij returned niets; dus krijg je de "Object reference not set to an instance of an object" foutmelding.

[whoami]

gorgi_19 schreef op dinsdag 22 maart 2005 @ 10:03:
Hij returned niets; dus krijg je de "Object reference not set to an instance of an object" foutmelding.

Ik vind dat ie dat gewoon niet zou mogen toelaten; de compiler zou moeten mekkeren omdat er niets expliciet gereturned wordt.

[iznogood]

whoami schreef op dinsdag 22 maart 2005 @ 10:05:
[...]


Ik vind dat ie dat gewoon niet zou mogen toelaten; de compiler zou moeten mekkeren omdat er niets expliciet gereturned wordt.

Kun je de function wel als een procedure gebruiken

[whoami]

iznogood schreef op dinsdag 22 maart 2005 @ 10:08:
[...]

Kun je de function wel als een procedure gebruiken

Dat kan je ook als die function expliciet iets returned.
Trouwens, als dat de bedoeling is, dan moet je een procedure maken. (In C# een void method).

[ Voor 18% gewijzigd door whoami op 22-03-2005 10:12 ]

[eghie]

Ik heb hier wel een vergelijking in snelheid tussen Visual C++ 7 en C#. Ik weet alleen niet niet meer waar ik hem vandaan had.

http://members.lycos.nl/eghie/cppvscsharp.htm

een quote uit de link:

The strange thing is that the Visual C# App is much faster than the C++ App.
( 1.5 secs per set for the C# App and 1.9 secs per set for the C++ App )

Mischien heeft hier iemand er wel wat aan.

[sebastius]

Ik ben zelf ook bezig met 'migreren' naar VB.NET en ik kan één ding er over zeggen: DOEN! Er zijn zoveel dingen ontieglijk veel handiger en duidelijker geworden. Het is best even een leercurve (de grootste overstap sinds ze van GW-Basic naar Visual Basic gingen), maar het uiteindelijke resultaat is wel een serieuze taal die je ook gewoon serieuze taken kunt geven.

[gorgi_19]

whoami schreef op dinsdag 22 maart 2005 @ 10:12:
[...]


Dat kan je ook als die function expliciet iets returned.
Trouwens, als dat de bedoeling is, dan moet je een procedure maken. (In C# een void method).

Klopt; de C# compiler is iets stricter

Visual Basic .NET:

Private Sub Melp()

    ' Lap code
    Exit Sub

    Dim a As Integer = 5

End Sub

VB.Net doet dit zonder warnings; C# geeft een unreachable code warning aan.

[curry684]

farlane schreef op dinsdag 22 maart 2005 @ 09:20:
[...]

Ja, maar altijd langzamer dan C++. punt

Herstel: "Altijd langzamer dan C++ geschreven door iemand met verstand van zaken, tig jaar ervaring en een gezond stel hersenen". Brakke C++ is zowat per definitie trager dan brakke C# omdat je nu eenmaal meer code hebt voor hetzelfde en dus meer kunt verknallen Daarnaast leunt C++ veel meer op je algoritmische en programmeertechnische inzichten waar .NET veel meer standaardoplossingen levert die in het merendeel van de gevallen een goede performance leveren. Voor de laatste paar procent zul je altijd uit moeten wijken naar C++ though.

The strange thing is that the Visual C# App is much faster than the C++ App.
( 1.5 secs per set for the C# App and 1.9 secs per set for the C++ App )

Dan moeten ze die C++ app niet door iemand laten schrijven die net "Teach yourself Visual C++ 4 in 24 hours" met moeite doorgeploegd is.

Zie ook C++ vraagje voor een geniaal voorbeeld van wat goede en slechte C++ voor wereld van verschil maken.

[Verwijderd]

Option Strict On is niet zo strict als ik dacht.

Op dit moment ben ik (als VB6 programmeur) bezig om VB.NET te leren. Het boek waar ik in bezig ben is:
Programming Microsoft Visual Basic.NET 2003
Francesco Balena
(op Amazon.com staat een uitgebreide review)

De overgang van VB6 naar VB.NET is idd groot, het is handig als je ook wat C++ kan.

[curry684]

gorgi_19 schreef op dinsdag 22 maart 2005 @ 10:36:
[...]

VB.Net doet dit zonder warnings; C# geeft een unreachable code warning aan.

Punt in dit geval is echter dat de C# compiler wel een dikke vette error geeft op deze functie:

C#:

public int NotReturning()
{
    Console.WriteLine("Melp!");
}

error CS0161: 'Test.Test.NotReturning()': not all code paths return a value

Ik vind het nogal kwalijk dat VB.NET dat blijkbaar niet doet omdat het een basaal mechanisme is om de integriteit van je code te garanderen. Als je zonodig null/nothing wil teruggeven doe je dat maar expliciet.

[gorgi_19]

Visual Basic .NET:

     Public Function NotReturning() As Integer

            Console.Write("melp")

        End Function

geen enkel probleem
Netjes: nee, dat zeker niet.

[MSalters]

curry684 schreef op dinsdag 22 maart 2005 @ 11:23:
[...]
Dan moeten ze die C++ app niet door iemand laten schrijven die net "Teach yourself Visual C++ 4 in 24 hours" met moeite doorgeploegd is.

Als je de thread in kwestie leest, dan zie je dat het een register allocation probleem was in VC7.0. De Intel C++ compiler dook 30% onder de C# tijd. Maar inderdaad is de code niet hoogstaand.

[farlane]

curry684 schreef op dinsdag 22 maart 2005 @ 11:23:
Herstel: "Altijd langzamer dan C++ geschreven door iemand met verstand van zaken, tig jaar ervaring en een gezond stel hersenen".

Hmmm, dat stuk had ik er inderdaad beter bij kunnen zetten.

[farlane]

curry684 schreef op dinsdag 22 maart 2005 @ 11:28:
Ik vind het nogal kwalijk dat VB.NET dat blijkbaar niet doet omdat het een basaal mechanisme is om de integriteit van je code te garanderen. Als je zonodig null/nothing wil teruggeven doe je dat maar expliciet.

Ik vermoed dat het een 'feature' is om VB6 code makkelijker te laten vertalen naar VB.NET. Die versie had die eigenschap namenlijk ook.

[madwizard]

curry684 schreef op dinsdag 22 maart 2005 @ 11:23:
Herstel: "Altijd langzamer dan C++ geschreven door iemand met verstand van zaken, tig jaar ervaring en een gezond stel hersenen". Brakke C++ is zowat per definitie trager dan brakke C# omdat je nu eenmaal meer code hebt voor hetzelfde en dus meer kunt verknallen Daarnaast leunt C++ veel meer op je algoritmische en programmeertechnische inzichten waar .NET veel meer standaardoplossingen levert die in het merendeel van de gevallen een goede performance leveren. Voor de laatste paar procent zul je altijd uit moeten wijken naar C++ though.

Hoewel ik het er mee eens ben is er nog wel iets waar C# (en alle .NET talen) een voordeel uit kunnen halen. C++ wordt over het algemeen naar machinecode gecompileerd, maar op x86 zijn er een redelijk aantal verschillende processoren en sommige optimalisaties werken beter op de ene dan op andere. Meestal wordt er dan code gegenereerd die op zo'n beetje alles goed draait (blended in VC zeg maar), omdat het op meerdere processoren moet draaien. .NET talen worden naar IL gecompileerd, en pas op de computer van de gebruiker naar machinecode omgezet. Op dat moment weet je wel exact welke processor gebruikt wordt en kunnen specifieke optimalisaties gebruikt worden. Uiteraard kun je veel C++ compilers ook specifieke code laten genereren maar dan zou je voor alle processoren een aparte versie van je programma moeten uitbrengen en dat doet vrijwel niemand. Ook weet ik niet in hoeverre hier echt gebruik van gemaakt wordt door de .NET runtime.

[Verwijderd]

[b][message=23025927,noline]curry684 schreef op dinsdag 22 maart 2005 @ 11:28
Ik vind het nogal kwalijk dat VB.NET dat blijkbaar niet doet omdat het een basaal mechanisme is om de integriteit van je code te garanderen. Als je zonodig null/nothing wil teruggeven doe je dat maar expliciet.

In VB6 zit het ook niet, je moet gewoon zelf opletten

[whoami]

Verwijderd schreef op dinsdag 22 maart 2005 @ 13:20:
[...]

In VB6 zit het ook niet, je moet gewoon zelf opletten

Dat is geen reden om diezelfde ranzigheid in VB.NET te steken. Dat het in VB6 zit, en daarom ook in VB.NET is een non-argument.
Het is gewoon een ranzig feit, en iets dat door de compiler zou moeten afgevangen worden. Het kan veel ellende voorkomen.

[riezebosch]

Maar VB.NET ondersteund wel weer default arguments voor functions (itt C#)?

[gorgi_19]

riezebosch schreef op dinsdag 22 maart 2005 @ 14:02:
Maar VB.NET ondersteund wel weer default arguments voor functions (itt C#)?

Als je dat echt wil, kan je met method overloading gaan werken.

[riezebosch]

Dat wordt idd ook als alternatief aangedragen

[Verwijderd]

whoami schreef op dinsdag 22 maart 2005 @ 13:25:
[...]


Dat is geen reden om diezelfde ranzigheid in VB.NET te steken. Dat het in VB6 zit, en daarom ook in VB.NET is een non-argument.
Het is gewoon een ranzig feit, en iets dat door de compiler zou moeten afgevangen worden. Het kan veel ellende voorkomen.

Ik wou alleen maar zeggen dat het in meerdere programmeertalen niet door de compiler is afgevangen. Het zou idd beter zijn als het wel in VB.NET zou zitten, daarom had ik ook verwacht dat als je Option Strict On heb staat, de compiler het ook gewoon af zou vangen.

Als VB6 programmeur zou ik, vooral als je geen C++ of Java ervaring hebt, overstappen naar VB.NET en niet naar C#. Doordat C# en VB.NET gebruik maken van het .NET framework kan je er even veel in. En wat betreft snelheid zal het ook niet veel uitmaken, alleen bij enorme hoeveelheden data. Als je gewoon win32 applicatie wilt blijven maken, dus zonder .NET framework, dan is C++ de enige optie, maar als je geen C++ ervaring hebt zal het wel even duren voordat je dat onder de knie hebt.