🚀 go-pugleaf

Frans Bouma <perseus@xs4all.nl> wrote:
>     Vergelijk eens 2 stukken code die een COM object implementeren die
>     een stored procedure in een Oracle database aanroepen en het resultaat
>     in een disconnected recordset teruggeven. In VB is dat een regel of
>     20, in C++ een veelvoud, EN met veel macro's om de COM problematiek
>     mbt pointers/references etc binnen de perken te houden (je kunt alles
>     zelf programmeren, ben je nog langer bezig). 

Sorry, maar toevallig is dat nu inderdaad iets wat ik al heb moeten
programmeren (hoewel de target nu geen oracle database was, maar iets
anders). En je voorbeeld is vals.

1. Het feit dat je COM slechts met veel gezever en inderdaad hopen
macro's kan benaderen is op rekening te schrijven van het 
framework en _niet_ van de taal. Er is geen enkele reden waarom een
component technologie niet geabstraheerd zou kunnen worden in een
eenvoudige en snel te gebruiken C++ standaardtaalelementen.
Daar zijn trouwens voorbeelden van.

2. Je vergelijkt de taal C++ met de volledige implementatie + ide + api
van VB. Dat is appelen met peren. Als je de moeite had gedaan om ook
voor C++ even je Visual C++ open te trekken had je gemerkt dat bijna
alle 'lastige' code waar jij klaagt gegenereerd wordt.

>     De snelheid zal ong. even hoog liggen van de 2 objects. Welke taal
>     kies je dan? Juist, de taal die je het beste ligt. Mensen met gedegen
>     COM/ADO kennis in C++ zullen daarin sneller de spullen maken dan inVB
>     en vice versa. 

Kortom : heel je post om te zeggen dat het eigenlijk helemaal geen voordeel
oplevert om in VB te gaan werken?

cu bart