Toon posts:

VB even snel als C ???

Pagina: 1 2 Laatste
Acties:
  • 714 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
Ok, naar aanleiding van een uitspraak van een leraar van een vriend van mij, besloot ik om de snelheid tussen VB en C++ eens te meten. Ik heb twee hele simpele programmaatjes gemaakt die priemgetallen filteren. Bij het uitvoeren kwam ik tot heel verrassende resultaten die mij, als fervent C'er, toch wel even deden opkijken:

* VB in de IDE is heeeeeel traag: +- 30 sec. voor het proggie (had ik verwacht)
* Een VB "gecompilede" exe: +- 8 sec
* C++ Code, release build, zonder pointers: +- 7 sec
* C++ Code, release build, met pointers: +- 8 sec.

Dus: Hoe komt het dat de code zonder pointers sneller is dan die met, en vooral, waarom is VB bijna even snel als C ?
Dat is toch niet echt normaal ?

ziehier de gebruikte code
van VB
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Option Explicit
Private Declare Function GetTickCount Lib "kernel32" () As Long
Sub Main()
Const MAX_NUMBERS As Long = 10000000
Dim uiGetallen(0 To MAX_NUMBERS) As Long
Dim x As Long
Dim y As Long

Dim tijd As Long
tijd = GetTickCount()
x = 0
For x = 0 To MAX_NUMBERS
   uiGetallen(x) = x
Next
'    // (* Filter de boel eruit *)
x = 2
For x = 2 To MAX_NUMBERS
    If uiGetallen(x) <> 0 Then
      ' // (* Filter alle veelvouden eruit *)
      For y = x + x To MAX_NUMBERS Step x
        uiGetallen(y) = 0
      Next
    End If
Next
MsgBox GetTickCount() - tijd

End Sub

en van C
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
#include <stdio.h>
#include <conio.h>
#include <windows.h>
#include <malloc.h>

/* priemgetallenzeef */
#define MAX_NUMBERS 10000000 
void noptrs();
void ptrs();
void main()
{
    int c;
    printf( "Press 1 for no pointers code, 2 for pointers code, 0 to exit, anything else to crash\n" );
    while ( ( c = getche() ) != '0' )
    {
        printf("\n" );
        if (c =='1')
            noptrs();
        else if (c=='2')
            ptrs();
        else
            printf("dit boeit niet\n" );
        printf("\n" );
    }
}
void noptrs()
{
    unsigned long *uiGetallen = ( unsigned long*) malloc( sizeof( unsigned long) * MAX_NUMBERS);
    unsigned long x;
    unsigned long t;

    t = GetTickCount();

    for ( x = 0; x < MAX_NUMBERS; x++ )
        uiGetallen[x] = x;

    // (* Filter de boel eruit *)
    for ( x = 2; x < MAX_NUMBERS; x++ )
    {
        if ( uiGetallen[x] != 0 )
        {
            // (* Filter alle veelvouden eruit *)
            for ( int y = x+x; y < MAX_NUMBERS; y+=x )
                uiGetallen[y] = 0;
        }
    }

    printf( "%lu", GetTickCount() - t );

    getche();
    
    free(uiGetallen );
}


void ptrs()
{
    unsigned long *uiGetallen = ( unsigned long*) malloc( sizeof( unsigned long) * MAX_NUMBERS);
    unsigned long *x = new unsigned long;
    unsigned long *y = new unsigned long;
    unsigned long t;

    t = GetTickCount();
    
    for ( *x = 0; *x < MAX_NUMBERS; (*x)++ )
        *(uiGetallen + *x) = *x;

    // (* Filter de boel eruit *)
    for ( *x = 2; *x < MAX_NUMBERS; (*x)++ )
    {
        if ( *(uiGetallen+*x) )
        {
            // (* Filter alle veelvouden eruit *)
            for (*y = (*x)*2; *y < MAX_NUMBERS; *y+=*x )
                *(uiGetallen+*y) = 0;
        }
    }
    printf( "%lu", GetTickCount() - t );

    getche();
    
    free(uiGetallen );
    delete x;
    delete y;
}

Ik weet dat GetTickCount niet de beste manier is om performance te meten, maar had geen zin om iets anders te bedenken.
Mijn excuses voor het slordige programmeerwerk ;)

  • Pc123
  • Registratie: Oktober 2000
  • Laatst online: 21-09 22:10
Interessant :)

Logisch natuurlijk dat VB IDE langzaam is, want dat wordt niet native gecompiled.

Maar hoe heb je trouwens dat VB progje gecompiled? Misschien ook leuk om te testen wat het verschil is als je overflow checks e.d. uit zet, zal ook wat sneller worden.

  • Basszje
  • Registratie: Augustus 2000
  • Laatst online: 11:01

Basszje

Reisvaap!]

Vaag? Ik dacht dat VB altijd veeeeel langzamer was?

Misschien ligt het bij VB aan bep. bottle necks?
hum?

hier nog een Artikeltje over de performance.
En daar liggen ze ook niet echt veel uit elkaar :?

Beware of listening to the imposter; you are undone if you once forget that the fruits of the earth belong to us all, and the earth itself to nobody.


Verwijderd

Topicstarter
Het VB progje is idd gecompiled, maar het is dus de bedoeling om aan te tonen dat C sneller is, zoals het hoort. (Ik wil nl. niet dat die leraar gelijk krijgt ;) )
Kan iemand misschien een poging doen tot het optimaliseren van de C code :?

  • Phuncz
  • Registratie: December 2000
  • Niet online

Phuncz

ico_sphere by Matthew Divito

Ja, ik ben die 'vriend' :)

Effe nog wat info:

2 geteste PC's:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
AMD K6-266:
-----------

 - VB in IDE:                +- 30 sec
 - compiled VB exe:          +- 8 sec
 - compiled C++ exe, no pointers:   +- 7 sec
 - compiled C++ exe, with pointers: +- 8 sec

AMD Duron 700:
--------------

 - VB in IDE:                /
 - compiled VB exe:          +- 5 sec
 - compiled C++ exe, no pointers:   +- 5 sec
 - compiled C++ exe, with pointers: /

Allebei draaiend op Win2K SP2.

edit:

typo's

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Java (direct vertaald uit C++ voorbeeld):
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public class Test
{
    public static void main(String[] ps)
    {
        final int MAX = 10000000;
        final int[] numbers = new int[MAX];
        int x;
        int y;

        long millis = System.currentTimeMillis();

        for(x=0;x < MAX;x++)
        {
            numbers[x] = x;
        }

        for(x = 2; x < MAX; x++)
        {
            if(numbers[x] != 0)
            {
                for (y = x+x; y < MAX; y+=x )
                {
                    numbers[y] = 0;
                }
            }
        }
        System.out.println("Milli seconds: " + (System.currentTimeMillis() - millis));
    }
}

Milli seconds: 3351

Is Java nu sneller dan C(++) en VB? Nee.

Deze bench-mark is ten eerste al onzinnig. Je moet bovendien geen talen op snelheid vergelijken, maar de manier waarop ze uitgevoerd en gecompileerd worden. Daar houd je in ieder geval al wel iets rekening mee :) .

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


  • marcusk
  • Registratie: Februari 2001
  • Laatst online: 26-09-2023
* VB in de IDE is heeeeeel traag: +- 30 sec. voor het proggie (had ik verwacht)
* Een VB "gecompilede" exe: +- 8 sec
* C++ Code, release build, zonder pointers: +- 7 sec
* C++ Code, release build, met pointers: +- 8 sec.

Dus: Hoe komt het dat de code zonder pointers sneller is dan die met [...]?
Waarom verwacht je dat pointers hier snelheidswinst zouden opleveren? In dit geval hebben ze geen enkel nut :)

Waarom VB in dit geval bijna even snel is als C++ weet ik niet, maar het zal natuurlijk ook liggen aan het soort programma wat je test, dus je kunt na deze test niet concluderen dat VB bijna even snel is ofzo (stel je voor ;))

  • marcusk
  • Registratie: Februari 2001
  • Laatst online: 26-09-2023
dubbel

Verwijderd

Op dinsdag 18 september 2001 22:49 schreef SpHeaRe het volgende:
Het VB progje is idd gecompiled, maar het is dus de bedoeling om aan te tonen dat C sneller is, zoals het hoort. (Ik wil nl. niet dat die leraar gelijk krijgt ;) )
Ermmm... Waarom had je gedacht dat VB in dit geval langzamer zou zijn dan C? Dit soort rechttoe-rechtaan rekenwerk valt prima om te zetten in machinecode, en dat is dan ook wat beide compilers doen. En hoe beroerd ik 't ook vind, VB doet dat tegenwoordig bepaald niet slecht... :)
Pas wanneer je met ActiveX etc. te maken krijgt wordt VB wat langzamer, omdat 'ie altijd via de IDispatch interface werkt i.p.v. rechtstreeks via de IUnknown afgeleide.

Maar zelfs dat verschil is met de huidige machines vrijwel niet te merken. Blijft alleen een aantal beperkingen in VB die je in bv. VC++, BC++ en Delphi niet hebt (goede class inheritance, bv.), maar afgezien daarvan is 't een heel volwaardige programmeeromgeving.

Ik blijf 't alleen een lelijke taal vinden, maar da's puur persoonlijk... :)

  • marcusk
  • Registratie: Februari 2001
  • Laatst online: 26-09-2023
[topic=213889/1/35]
Maak dat voor de gein eens in VB :D

  • Dawai
  • Registratie: December 2000
  • Laatst online: 08-07 23:56

Dawai

HERiTAGE CHESS CREW

Op dinsdag 18 september 2001 23:21 schreef marcusk het volgende:
[topic=213889/1/35]
Maak dat voor de gein eens in VB :D
msg = Replace(msg, "a", "c")
>:)

Programmer: red-eyed, mumbling mammal capable of conversing with inanimate objects.


  • Dawai
  • Registratie: December 2000
  • Laatst online: 08-07 23:56

Dawai

HERiTAGE CHESS CREW

Ow ja, een hele tijd geleden heb ik eens met iemand een algo om priemgetallen te berekenen vergeleken, een versie in VB en een versie in assembler. Het scheelde bijna niets... VB heeft gewoon een "traag imago" wegens vroegere versies die niet native konden compilen, en grote runtimes enzo, maar voor gewoon rekenwerk is het best nog snel.

Programmer: red-eyed, mumbling mammal capable of conversing with inanimate objects.


Verwijderd

Op dinsdag 18 september 2001 23:29 schreef Dawai het volgende:

[..]

msg = Replace(msg, "a", "c")
>:)
ohjee..... benchmark coming up >:)

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 21-09 12:16

.oisyn

Moderator Devschuur®

Demotivational Speaker

hoor ik daar benchmark? :P

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


  • Dawai
  • Registratie: December 2000
  • Laatst online: 08-07 23:56

Dawai

HERiTAGE CHESS CREW

offtopic:
http://users.pandora.be/dawai/prime.zip

Dit is een later geoptimaliseerde versie van de assembler-versie, voor het geval je veel priemgetallen nodig hebt >:)

Programmer: red-eyed, mumbling mammal capable of conversing with inanimate objects.


  • Killemov
  • Registratie: Januari 2000
  • Laatst online: 11-09 10:38

Killemov

Ik zoek nog een mooi icooi =)

Benchmark? Benchmark? Waar? Waar! ... Waar is Curry als je 'm nodig hebt. :)

Hey ... maar dan heb je ook wat!


Verwijderd

Voor de liefhebbers van optimalisatie:

In Java-code is het voor de snelheid zeer bevorderlijk de regel:

numbers[y] = 0;

te vervangen door:

if (numbers[y]!=0) { numbers[y]=0; }

Processingtijd (met eerder genoemd java-algoritme, voor 10.000.000 getallen) gaat van 5.1 naar 3.2 sec op mijn Duron-933MHz...

Ik neem aan dat het in de andere talen ook werkt (er zijn vast wel tweakers die dit ff willen testen, ben ook wel nieuwsgierig maar sinds ik met Java bezig ben ga ik echt geen VB of C meer op m'n compu installeren ;) ).

Tja, het ziet er wat knullig uit zo'n regel, alsof je net met programmeren begint ;) , maar vanwege cache issues is het slim om alleen dan te schrijven naar het geheugen als het echt nodig is, het lezen heeft een veel lagere performance-penalty. Bovendien moet er zowieso gelezen worden, dus daar ontkomen we nooit aan...
Maar wat schrijven betreft: omdat er niet al te veel priemgetallen zijn, en het aantal ook afneemt naarmate de getallen hoger worden, bevat de array op den duur voornamelijk nullen, en door de conditional uit genoemde code wordt in het meest voorkomende geval alleen gelezen en niet nutteloos geschreven...

PS Java rulez!

PPS Compile in Java met de -O optie als je aan het performance-optimizen bent, en gebruik de profile optie om te kijken waar je het beste kunt beginnen te optimizen!

PPPS Jammer dat de computers tegenwoordig zo snel zijn, daardoor is er weinig behoefte meer aan dit soort hersen-gymnastiek ;(

PPPPS Er zijn nog wel meer truukjes mogelijk want dit algoritme zuigt maar ik ga nu :Z
Maar als ik 't goed snap ('t is al laat): die array kan toch ook boolean-array zijn, want de index geeft al aan om welk (priem)getal 't gaat? Dan wordt 't hier (weer met dezelfde write-only-when-neccessary-truuk if(booleans[y]){booleans[y]=false;}) slechts 2.6 seconden, hehehe! :P

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Volgens mij doet de -O optie tegenwoordig niets meer...

Ik heb het ff veranderd en het werkte inderdaad goed ja!
Met de if eromheen zat ik op 2855 ms.

Met de boolean oplossing:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class Test2
{
    public static void main(String[] ps)
    {
        final int MAX = 10000000;
        final boolean[] numbers = new boolean[MAX];
        int x;
        int y;

        long millis = System.currentTimeMillis();

        for(x=0;x < MAX;x++)
        {
            numbers[x] = true;
        }

        for(x = 2; x < MAX; x++)
        {
            if(numbers[x])
            {
                for (y = x+x; y < MAX; y+=x )
                {
                    if(numbers[y])
                    {
                        numbers[y] = false;
                    }
                }
            }
        }

        System.out.println("Milli seconds: " + (System.currentTimeMillis() - millis));
    }
}

Milli seconds: 1829 >:) .

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Het valt me trouwens op dat Java het toch wel verrassend snel doet. De range-checks bij arrays worden toch gezien als een grote vertragende factor. Iemand een mening hierover?

Bij dit enorme array-werk is er niets aan de hand. Ik ben wel benieuwd wat een vergelijkbare C implementatie nu doet met het versnelde algoritme.

Het definaliseren van de array heeft trouwens geen effect op de performance.

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Verwijderd

Welke compiler heb je gebruikt de MS c++ compiler is namelijk erg langzaam.

Beter is de Intel compiler.

  • bartvb
  • Registratie: Oktober 1999
  • Laatst online: 21-09 17:01
Om even terug te komen op de originele 'benchmark'...

IMO is ie niet veel waard >:)
Ten eerste is je tijdwaarneming crap (afronden op seconden als je 7 seconde meet? hmm).. Verder dien je experimenten een aantal keer te herhalen.

Wat me meer stoort is de code die gebruikt heeft. Of ja, het programmeer problmeen eigenlijk.

Wat je hier doet is kijken hoe snel een progje wat if constructs uit kan voeren in een loopje. Meer niet.

Alle programmeertalen zijn helemaal ziek geoptimaliseerd op if's en die simpele loopjes..

Het wordt pas interessant als je wat meer 'real life' dingen gaat gebruiken, fijne API calls, wat gemeuk met objecten, dat soort spul..

Het filteren van priemgetallen is leuk om de snelheid van je processor te testen maar om te kijken welke taal sneller is? Hmm..

En 7 seconde is echt te weinig, laat het dan voor een minuut lopen ofzo ;)

Verwijderd

De tijd dat visual basic PCode genereerde is al lang voorbij. De laatste versie (vanaf 5) gebruiken dacht ik zelfs de visual c++ compiler. Even snel van de MSDN website:
"Build fast, native-code applications and components that use the same world-class compiler technology as in the Microsoft Visual C++® development system. Applications can be optimized for speed and size and in many other ways to improve performance even more."
Promopraat maar het scheelt dus niet veel.

Verwijderd

Tja, als je op die manier in C met pointers werkt, dan wordt het natuurlijk nooit sneller dan met indexen :)
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
void ptrs(void) {
  unsigned long *uiGetallen= ( unsigned long*) malloc(
             sizeof( unsigned long) * MAX_NUMBERS);
  unsigned long *getalEnd= uiGetallen + MAX_NUMBERS;
  unsigned long x;
  unsigned long *y;
  unsigned long t;

  t= GetTickCount();

  for(x= 2; x < MAX_NUMBERS; ++x)
    uiGetallen[x]= x;  /* hier is indexing sneller */

  for(x= 2; x < MAX_NUMBERS; ++x) { /* hier ook */
    if(uiGetallen[x]) {
    for(y= &uiGetallen[x + x]; y < getalEnd; y+= x)
      *y= 0;
    }
  }

  printf( "%lu", GetTickCount() - t );
  getche();
    
  free(uiGetallen);
}

<edit>herschreven</edit>

  • Primal
  • Registratie: Augustus 2001
  • Laatst online: 11-09 14:32
Dit 'programmaatje' is inderdaad veel te recht-toe-recht-aan om verschillen in performance te meten.

Wil je bovendien een 'echte' benchmark doen, dan moet je de programma's (of liever gezegd de functies -> check wat de cache doet) vele malen achter elkaar laten executeren. Op die manier kun je veel beter verschillen meten.

En by-the-way, werken met pointers wil niet altijd zeggen: snelheidswinst. Het moet natuurlijk wel functioneel gebruikt worden!! ;)

"The fastest code, is the code that is never called."


Verwijderd

Topicstarter
Op woensdag 19 september 2001 01:10 schreef bartvb het volgende:
Om even terug te komen op de originele 'benchmark'...

IMO is ie niet veel waard >:)
Ten eerste is je tijdwaarneming crap (afronden op seconden als je 7 seconde meet? hmm).. Verder dien je experimenten een aantal keer te herhalen.
heb ik gedaan, en als je de code doorneemt, zie je ook dat ie niet op de seconde afrond, maar naar de milliseconden kijkt.
En ja, ik geef toe dat het een slechte benchmark is, maar het was het eerste wat in me opkwam en eerlijk gezegd had ik totaal niet verwacht dat VB bijna even snel zou zijn, zelfs op zo'n crappy algoritme.

Verwijderd

Topicstarter
Dus misschien een ideetje voor alle proggers hier?

Schrijf een programma dat het snelheidsverschil tussen twee talen aantoont op een "goede" manier


Mijn poging is dus al vrij mislukt :+

ps. Is de Intel C++ compiler niet enkel sneller op Intel pc's, omdat die programma's speciaal voor die intructiesets geoptimaliseerd ?

  • Phuncz
  • Registratie: December 2000
  • Niet online

Phuncz

ico_sphere by Matthew Divito

Is de Intel C++ compiler niet enkel sneller op Intel pc's, omdat die programma's speciaal voor die intructiesets geoptimaliseerd ?
Zal toch niet VEEL uitmaken, aangezien er ook al SSE instructies in Athlons wordt gebakken tegenwoordig. Zal toch wel iets uitmaken. Beste is dat de proggies niet worden uitgevoerd met MPEG encoding of 3D Studio MAX renderings in de achtergrond :)

Anders heb je nogal serieus uiteenlopende resultaten op dezelfde procs. Ik geef me al op voor te testen. Ik stel voor dat iedreen bij de genomen test zijn processor en draaiende OS beschrijven, zodat het een duidelijke bench wordt. Denk niet dat een Pentium 233 en AMD K6 233 evensnel gaan rekenen als een PIII 1GHz en een Atlon 1GHz.

Nu nog de progies :)

Verwijderd

Wat wel duidelijk is, is dat optimalisatie van een stuk code de snelheid enorm beinvloed (met wat gesleutel aan het eerder genoemde priem-algoritme ging de processing-tijd bij mij van 5.1 sec terug naar 1.5 sec in Java, zie thread over priemgetallen berekenen in Java) en daaruit blijkt dus maar weer eens dat het nogal riskant is talen te vergelijken met alleen zo'n lullig testje... 't is maar net wat een bepaalde taal of compiler goed aankan, en hoe de programmeur z'n statements in elkaar heeft gezet...

Maar treur niet, de professionele benchmark-makers bakken er ook een zooitje van, het is namelijk onmogelijk compleet en eerlijk te testen.

Toch is dat volgens mij de enige weg om nog een beetje een vergelijk te kunnen maken: probeer een identiek probleem op beide platforms zo geoptimaliseerd mogelijk te implementeren, daarmee vergelijk je tenminste de (on)mogelijkheden van de taal; zonder optimalisaties hangt het teveel van het toeval af hoe snel een stuk code kan worden uitgevoerd.

In de praktijk zie je trouwens steeds meer dat de snelheid er eigenlijk steeds minder toe doet, maar dat de kwaliteit van de ontwikkelaar (die slimme keuzes weet te maken en onderhoudbare code produceert) en de mogelijkheden van de taal een steeds belangrijker rol spelen; als performance uiteindelijk een probleem blijkt te zijn, hoeft er slechts een sneller systeem te worden aangeschaft en de problemen zijn opgelost :)

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Ik weet dat GetTickCount niet de beste manier is om performance te meten, maar had geen zin om iets anders te bedenken.
Well duh, kijk dan in deze thread voor echte benchmark code ;)
Mijn excuses voor het slordige programmeerwerk ;)
Echt optimaal is het niet opgebouwd nee... maar de resultaten verbazen me niet echt: je bent hier puur integer stampwerk aan het doen op een heel laag niveau. En lowlevel stampwerk laat zich nu eenmaal in iedere taal heel makkelijk naar duidelijke ASM vertalen.

Ga maar eens voor de lol een complexe tree opzetten met 1000 virtual classes met RTTI en zie VB enkele keren langzamer zijn.

Professionele website nodig?


  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op dinsdag 18 september 2001 23:50 schreef Killemov het volgende:
Benchmark? Benchmark? Waar? Waar! ... Waar is Curry als je 'm nodig hebt. :)
Daarom heb ik die code nou net gisteravond gepost, zodat jullie ook zonder mij kunnen benchen!!! :z

Professionele website nodig?


Verwijderd

Waar is de vb port dan curry? >:)

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op woensdag 19 september 2001 16:53 schreef Yarvieh het volgende:
Waar is de vb port dan curry? >:)
VB is een taal waar je om moet lachen terwijl je in een echte omgeving stabiele snelle applicaties maakt, je moet er niet in proberen te programmeren. Helaas snappen sommige mensen dat concept niet helemaal. ;)

Professionele website nodig?


  • D2k
  • Registratie: Januari 2001
  • Laatst online: 31-08 10:19

D2k

Op woensdag 19 september 2001 18:17 schreef curry684 het volgende:

[..]

VB is een taal waar je om moet lachen terwijl je in een echte omgeving stabiele snelle applicaties maakt, je moet er niet in proberen te programmeren. Helaas snappen sommige mensen dat concept niet helemaal. ;)
oooeeeeeeee
-1 flame :)

* D2k agrees of course met curry >:)

Doet iets met Cloud (MS/IBM)


Verwijderd

Op woensdag 19 september 2001 18:17 schreef curry684 een VB-Bash:
* curry684 is now known as PacMan684 *hap*hap*hap*hap*hap* >:)

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op woensdag 19 september 2001 18:26 schreef Yarvieh het volgende:
* curry684 is now known as PacMan684 *hap*hap*hap*hap*hap* >:)
;)

Ik wachtte eigenlijk totdat iemand ECHT zou happen maar ik denk dat jullie de kans daarop al verpest hebben... >:)

Professionele website nodig?


  • iznogood
  • Registratie: September 2001
  • Niet online
Op woensdag 19 september 2001 18:17 schreef curry684 het volgende:

[..]

VB is een taal waar je om moet lachen terwijl je in een echte omgeving stabiele snelle applicaties maakt, je moet er niet in proberen te programmeren. Helaas snappen sommige mensen dat concept niet helemaal. ;)
Zei de man die met veel pijn en moeite c heeft geleerd en er nog niks van kan.

Just as Good


Verwijderd

Topicstarter
VB is een taal waar je om moet lachen terwijl je in een echte omgeving stabiele snelle applicaties maakt, je moet er niet in proberen te programmeren. Helaas snappen sommige mensen dat concept niet helemaal.
I agree volledig, C geniet ook mijn voorkeur, maar helaas wordt op verschillende scholen lessen VB gegeven (en sommige leerlingen snappen er nog niks van, dus C zou al helemaal 'over the top' zijn). Bovendien wordt VB vaak gekozen omdat de leerkrachten zelf te incompetent zijn om een echte programmeertaal te begrijpen. VB hebben ze waarschijnlijk zelf al maanden op zitten studeren eer ze doorhadden wat een variabele nu precies is... En de leerkrachten die het doorhebben, durven dus beweren dat VB sneller is dan C. En dat wilde ik weerleggen met mijn crappy "benchmark".

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
en sommige leerlingen snappen er nog niks van, dus C zou al helemaal 'over the top' zijn
Dat vraag ik mij af. Ik denk dat een logische en consequente taal makkelijker te leren is. Regelmatig zie ik hier op GoT vragen langskomen die er duidelijk op wijzen dat mensen in een niet logische en consequente taal aan het werk zijn.

Talen als C, C++, Java, C#, Turbo Pascal zijn door hun duidelijke structuur denk ik beter te bevatten dan VB.

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op woensdag 19 september 2001 19:20 schreef iznogood het volgende:
Zei de man die met veel pijn en moeite c heeft geleerd en er nog niks van kan.
Hee valt me tegen dat er nog iemand zo stom is te happen nadat Yarvieh en D2K de grap verklapt hadden! :Y)

En nog een slechte flame ook, deze is niet eens '-1 flame' waard maar gewoon '-1 overbodig'. In een goede flame geef je in ieder geval argumenten, bij voorkeur fout, om een stomme stelling te onderbouwen, maar deze gozer kan het niet eens opbrengen met een paar belabberde argumenten te komen :'(

Heeft er toevallig iemand een link naar een goede online flamecursus voor iznogood?

[edit]
Jeminee laat maar zitten hij is zelfs te lame om onder z'n eigen naam te flamen en heeft de moeite genomen om helemaal een nieuwe user te reggen voor een brakke flame... :?

Professionele website nodig?


Verwijderd

Topicstarter
Op woensdag 19 september 2001 20:14 schreef mbravenboer het volgende:

[..]

Dat vraag ik mij af. Ik denk dat een logische en consequente taal makkelijker te leren is. Regelmatig zie ik hier op GoT vragen langskomen die er duidelijk op wijzen dat mensen in een niet logische en consequente taal aan het werk zijn.

Talen als C, C++, Java, C#, Turbo Pascal zijn door hun duidelijke structuur denk ik beter te bevatten dan VB.
Pascal is ontstaan uit educatieve doeleinden. Dus IMO is pascal een tal om mee te leren proggen, en dan over te stappen op C, Java, whatever.
VB is ontstaan uit BASIC (waar ik vroeger mee ben begonnen te proggen) en eerlijk gezegd, is deze taal idd geen goede basis tot gestructureerd programmeren.

Verwijderd

Op woensdag 19 september 2001 20:18 schreef SpHeaRe het volgende:

[..]

Pascal is ontstaan uit educatieve doeleinden. Dus IMO is pascal een tal om mee te leren proggen, en dan over te stappen op C, Java, whatever.
Auw! :'(
Inderdaad, Pascal is een prima taal om mee te leren programmeren. Maar met de mogelijkheden en performance van bv. Delphi / Kylix zie ik niet zo snel een reden om daarna over te stappen naar C++ of Java, behalve om je blikveld te verbreden.

OK, ze draaien op wat meer platforms (understatement, ik weet 't... :)), maar verder? Ik kan ondertussen vrij aardig overweg met beide talen, maar als ik op een gegeven moment m'n mouwen op moet stropen, pak ik toch altijd weer Delphi. Doodgewoon omdat ik die taal 't beste ken, en een taal is zo goed als degene die erin programmeert...

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op woensdag 19 september 2001 20:58 schreef Afterlife het volgende:
Inderdaad, Pascal is een prima taal om mee te leren programmeren. Maar met de mogelijkheden en performance van bv. Delphi / Kylix zie ik niet zo snel een reden om daarna over te stappen naar C++ of Java, behalve om je blikveld te verbreden.
In tegenstelling tot wat je impliceert draait Delphi niet op Pascal, maar op Borland's eigen versie van Pascal waar ze support voor OOP in hebben gestopt, vandaar ook Object Pascal ;) Het leuke aan Delphi volgt hier meteen uit: de overstap naar C++ is knap klein omdat je in principe al met een stapel OOP-kennis begint.

Het enige argument voor VB wat ik vaak hoor is dat je er zo makkelijk en snel in kunt prototypen, nou dat is je reinste stierenpoep want de snelheid waarmee je prototyped is vrijwel compleet afhankelijk van je ervaring met de omgeving. Ik heb in C++Builder sneller een volledige GUI in mekaar geklopt dan de meeste VB'ers in hun eigen taal... :*

Professionele website nodig?


Verwijderd

Hmmz dit boeltje maar es nieuw leven in blazen.. :Y)

C/C++ is lekker wou je zeggen,!? Al dat ge-etter met pointers en memory leaks doordat je die shit die je allemaal zelf bij moet houden en om dan nog maar te zwijgen over ranzige buffer overflows en meuk die weigerd te compileren omdat je LibTroep-0.1.53p11 geinstalled hebt staan ipv LibTroep0.1.53p13.En natuurlijk prototyped een vb'er stukken sneller dan een C fratser, de vb-er start VB op en alles wat ie nodig heeft is right at his finger tips hij kan direct beginnen.De C(++) programmeur mag beginnen met allerlei ranzige windowhandlers en weet ik het wat voor elende te gaan schrijven voordat ie ook maar *iets* op het scherm krijgt, of ze moeten dat oh zo geweldige MFC gaan gebruiken waar de gemiddelde C/C++'er zelf al een graf hekel aan heeft.. kortom.. een VB-er ontwikkeld zoveel praktisher beter en sneller dan welke c of c++ programeur dan ook.

  • marcelk
  • Registratie: December 2000
  • Niet online
Op woensdag 19 september 2001 23:21 schreef Yarvieh het volgende:
Hmmz dit boeltje maar es nieuw leven in blazen.. :Y)
De C(++) programmeur mag beginnen met allerlei ranzige windowhandlers en weet ik het wat voor elende te gaan schrijven voordat ie ook maar *iets* op het scherm krijgt, of ze moeten dat oh zo geweldige MFC gaan gebruiken waar de gemiddelde C/C++'er zelf al een graf hekel aan heeft.. kortom.. een VB-er ontwikkeld zoveel praktisher beter en sneller dan welke c of c++ programeur dan ook.
Niet als je C++ Builder gebruikt.

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op woensdag 19 september 2001 23:31 schreef marcelk het volgende:
Niet als je C++ Builder gebruikt.
Alsof je daar altijd gelukkig van wordt... moet je voor de lol eens proberen om Excel_2k.h, Word_2k.h en PowerPoint_2k.h in EEN cpp-file binnen te trekken (access violation in compiler). Ik moet 2 keer per dag verplicht rebooten op m'n werk omdat ik libs van 300Mb bouw, en na een paar uur heeft BCB.exe dan ongeveer 300-350Mb geheugen VAST IN GEBRUIK. Ik ben ondertussen gewend aan willekeurige compilererrors die verholpen zijn zodra je de build nog een keer start. Ik ben eraan gewend dat ie ALLE FUCKING FILES gaat recompilen zodra je een spatie toevoegt in een header, en dat dat een minuut of 20 duurt op een P3-550 met 256Mb RAM. Als je zo stom bent om background compile aan te laten staan duurt het 3 kwartier. Ter vergelijking VC++ doet een full rebuild van dat project onder de 10 minuten met background compile ENABLED. En gaat pas volledig rebuilden zodra je echt fundamentele wijzigingen in de headers gooit (een enum veranderen slikt ie vaak zonder full rebuild).

Ja daar wordt ik altijd onverdeeld gelukkig van.

Professionele website nodig?


  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Over bugs in BCB gesproken, probeer deze eens in debugbuild:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
bool Func(int &i)
{
for(i = 0; i != 10; i++)
  {
  bool Blah = false;
  if(Blah)
    break;     // <--- ZET HIER EEN BREAKPOINT
  }
return true;
}

int main()
{
int     Integer;
bool    Result = Func(Integer);
return 0;
}

Mag jij mij langzaam uitleggen waarom dat breakpoint 10 keer geraakt wordt....

Professionele website nodig?


Verwijderd

Op woensdag 19 september 2001 23:53 schreef curry684 het volgende:
Mag jij mij langzaam uitleggen waarom dat breakpoint 10 keer geraakt wordt....
Hmm, challenge :) Als je die bool Blah = false; buiten de for-loop haalt, wordt hij dan nog 10x geraakt?

Anders is het verklaarbaar: zonder optimizing wordt die invariant niet buiten de loop geplaatst, en door zijn in de loop locale scope wordt hij dan elke keer opnieuw geinitialiseerd en getest. (Dit is natuurlijk geen correct gedrag maar het is verklaarbaar. Het rare is dat dat break statement blijkbaar niet werkt.)

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op donderdag 20 september 2001 02:52 schreef mietje het volgende:
Hmm, challenge :) Als je die bool Blah = false; buiten de for-loop haalt, wordt hij dan nog 10x geraakt?
Nee ;) Als je die parameter voor de for-loop niet by-ref binnengooit ook niet... ik weet niet waarom ie dit doet in dit specifieke geval maar het is wel knap. Hij loopt namelijk dus wel de hele loop af inderdaad.

VC++ heeft hier geen last van overigens.
(Dit is natuurlijk geen correct gedrag maar het is verklaarbaar. Het rare is dat dat break statement blijkbaar niet werkt.)
Verklaarbaar ja, verdedigbaar nee :)

Professionele website nodig?


Verwijderd

Op woensdag 19 september 2001 23:53 schreef curry684 het volgende:
Over bugs in BCB gesproken, probeer deze eens in debugbuild:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
bool Func(int &i)
{
for(i = 0; i != 10; i++)
  {
  bool Blah = false;
  if(Blah)
    break;     // <--- ZET HIER EEN BREAKPOINT
  }
return true;
}

int main()
{
int     Integer;
bool    Result = Func(Integer);
return 0;
}

Mag jij mij langzaam uitleggen waarom dat breakpoint 10 keer geraakt wordt....
Om even mee te doen in de discussie, Zelf kan ik al een aantal jaer VB. Dit is makkelijk te gebruiken en dus opzich niks mis mee om wat kleinere applicatie's te maken.
Op school hebben we nu java, en krijg ik straks C++.

Ik denk dat mijn kennis toch wel dus danig is dat ik weet waarom die 10x break raakt of niet helemaal gecompileerd wordt: er staat:
bool Blah = false;
if(Blah)
break; // <--- ZET HIER EEN BREAKPOINT
}
moet dit niet zijn:
bool Blah = false;
if(Blah) {
break; // <--- ZET HIER EEN BREAKPOINT
}

er mist dus een { na if.
Of is dit gewoon een typo? :P

Verwijderd

Op donderdag 20 september 2001 09:30 schreef Infinity het volgende:
er mist dus een { na if.
Of is dit gewoon een typo? :P
Nee, die "}" hoort bij de for() :)

Veel leukere bug in VC++:
code:
1
2
3
4
5
6
7
8
9
int main()
{
  int j = 20;
  for (int i=0;i<j-5;i++)
  {
     printf("%d\n", i);
  }
  return 0;
}

Nu moet iemand mij toch eens uitleggen waarom deze miljard keer een getal op het scherm print (als je j-5 verandert in 15 doet ie het wel goed, dan weet je alvast waar de fout zat).

Verwijderd

Topicstarter
Op donderdag 20 september 2001 10:12 schreef beelzebubu het volgende:
Veel leukere bug in VC++:
code:
1
2
3
4
5
6
7
8
9
int main()
{
  int j = 20;
  for (int i=0;i<j-5;i++)
  {
     printf("%d\n", i);
  }
  return 0;
}

Nu moet iemand mij toch eens uitleggen waarom deze miljard keer een getal op het scherm print (als je j-5 verandert in 15 doet ie het wel goed, dan weet je alvast waar de fout zat).
Een pure gok: prioriteitsregels? Doet ie t wel als je haakjes om de (j-5) zet ? :?
Gelijk ik zei: gokje, geen zin om het nu te testen :)

Verwijderd

Topicstarter
Heb het toch maar even getest :+
Raar hoor, maar bij mij (VC 6.0 Enterprise, gn service packs) loopt je originele code perfect hoor !
Loopt mooi van 1 - 15. Geen bugs te bekennen...
code:
1
2
3
4
5
6
7
8
9
int main()
{
  int j = 20;
  for (int i=0;i<j-5;i++)
  {
     printf("%d\n", i);
  }
  return 0;
}

Verwijderd

Op woensdag 19 september 2001 20:15 schreef curry684 het volgende:
En nog een slechte flame ook, deze is niet eens '-1 flame' waard maar gewoon '-1 overbodig'. In een goede flame geef je in ieder geval argumenten, bij voorkeur fout, om een stomme stelling te onderbouwen, maar deze gozer kan het niet eens opbrengen met een paar belabberde argumenten te komen :'(
Waarom zou hij ook? Jij vindt het kennelijk 'grappig' om te zeuren, dan net te doen alsof je het niet meende, maar even later geef je toch aan dat je het wel degelijk meende (in een andere posting).
Heeft er toevallig iemand een link naar een goede online flamecursus voor iznogood?
[edit]
Jeminee laat maar zitten hij is zelfs te lame om onder z'n eigen naam te flamen en heeft de moeite genomen om helemaal een nieuwe user te reggen voor een brakke flame... :?
Heeft iemand een teiltje voor me, zodat ik mn braaksel kwijt kan, wat spontaan naar boven kwam bij ALWEER een trutterige overbodige dombo-posting van Curry :r

Verwijderd

Op donderdag 20 september 2001 11:13 schreef SpHeaRe het volgende:

[..]

Een pure gok: prioriteitsregels? Doet ie t wel als je haakjes om de (j-5) zet ? :?
Gelijk ik zei: gokje, geen zin om het nu te testen :)
Klopt, dat is de bug ook volgens mij :)

Zal in nieuwere versies wel gefixt zijn.... Maar als je geen koffie hebt gehad kun je uren zoeken naar zo'n domme fout |:( :P

Verwijderd

Op woensdag 19 september 2001 21:07 schreef curry684 het volgende:
In tegenstelling tot wat je impliceert draait Delphi niet op Pascal, maar op Borland's eigen versie van Pascal waar ze support voor OOP in hebben gestopt, vandaar ook Object Pascal ;) Het leuke aan Delphi volgt hier meteen uit: de overstap naar C++ is knap klein omdat je in principe al met een stapel OOP-kennis begint.
Lullige is alleen dat je dan niet ver komt. Of wil je beweren dat je meteen alle kennis omtrent hoe je gui's WERKEND krijgt in VC++ bv ook distilleert uit je delphi ervaring? dacht het toch niet. Verder begin ik maar niet over de wijde kloof tussen Wirth talen en algol based talen.
Het enige argument voor VB wat ik vaak hoor is dat je er zo makkelijk en snel in kunt prototypen, nou dat is je reinste stierenpoep want de snelheid waarmee je prototyped is vrijwel compleet afhankelijk van je ervaring met de omgeving. Ik heb in C++Builder sneller een volledige GUI in mekaar geklopt dan de meeste VB'ers in hun eigen taal... :*
Feit blijft wel dat jij in BC++ veel meer moet typen dan de VB-er in zijn omgeving. Nu kan jouw typesnelheid hoog zijn, maar in VB bouw je snellere werkbare gui's. En bv ook sneller COM components die met databases moeten praten, een van de sterke kanten van VB. Uiteraard kan jij dat veeeeel sneller in jouw C++ omgeving, maar iedereen die EN veel in VB EN veel in C++ programmeert weet dat dat onzin is.

En nu vort terug in je hok, troll.

Verwijderd

Op donderdag 20 september 2001 12:08 schreef Otis het volgende:
Feit blijft wel dat jij in BC++ veel meer moet typen dan de VB-er in zijn omgeving. Nu kan jouw typesnelheid hoog zijn, maar in VB bouw je snellere werkbare gui's. En bv ook sneller COM components die met databases moeten praten, een van de sterke kanten van VB. Uiteraard kan jij dat veeeeel sneller in jouw C++ omgeving, maar iedereen die EN veel in VB EN veel in C++ programmeert weet dat dat onzin is.
Zonder me in een troll-discussie te willen mengen....

Meer typewerk betekent niet automatisch slomer (om te schrijven) - logica in een taal enzo kan een hoop schelen. Minder typewerk betekent over het algemeen ook dat je sneller tegen de limitaties van een taal aanloopt.

Bovendien vond ik dat window-buildertje in VC++ toch wel dermate handig dat ik binnen enkele minuten een applicatie window had. Alleen nog de onderliggende code (messge-handling enzo) schrijven en je bent er. Zelfde als VB, toch :?

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 21-09 18:16

Creepy

Tactical Espionage Splatterer

Feit blijft wel dat jij in BC++ veel meer moet typen dan de VB-er in zijn omgeving. Nu kan jouw typesnelheid hoog zijn, maar in VB bouw je snellere werkbare gui's. En bv ook sneller COM components die met databases moeten praten, een van de sterke kanten van VB. Uiteraard kan jij dat veeeeel sneller in jouw C++ omgeving, maar iedereen die EN veel in VB EN veel in C++ programmeert weet dat dat onzin is.
BC++???? De enige BC++ die ik ken is borland C++ BUILDER. Donder een ttable, tdatasource en een tdbgrid op een form.. BAM... kant en klare database applicatie.. Wat nou een component schrijven om een DB te benaderen.. klik klik en klaar :)

Je hebt het hiero over het vergelijken van ontwikkelomgevingen, niet van talen. Als je mensen terug in hun hok wilt stoppen.. doe het dan goed :) (of maak geen tikfouten als je VC++ bedoelt!) :)

Als je puur in VC++ (V als in Visual) bezig bent heb je denk ik gelijk, maar kijk eerst es naar de IDE van BC++ (B als in Borland). Daar hang je ook supersnel compleet werkende GUI's mee in elkaar. Of dat nou wel of niet sneller gaat dan de IDE van VB hangt volgens mij alleen af van de kennis die de persoon van de IDE van VB en BC++ heeft.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


  • warp
  • Registratie: Januari 2000
  • Niet online
Op woensdag 19 september 2001 23:21 schreef Yarvieh het volgende:
kortom.. een VB-er ontwikkeld zoveel praktisher beter en sneller dan welke c of c++ programeur dan ook.
Laat jij het eerste OS maar eens zien dan dat geheel in VB is geschreven :P

  • Crazy D
  • Registratie: Augustus 2000
  • Laatst online: 07:51

Crazy D

I think we should take a look.

Op donderdag 20 september 2001 13:16 schreef Creepy het volgende:
BC++???? De enige BC++ die ik ken is borland C++ BUILDER. Donder een ttable, tdatasource en een tdbgrid op een form.. BAM... kant en klare database applicatie.. Wat nou een component schrijven om een DB te benaderen.. klik klik en klaar :)
En dan nog klagen dat VB programmeurs alleen met componentjes kunnen slepen :P

Exact expert nodig?


Verwijderd

Op donderdag 20 september 2001 13:23 schreef warp het volgende:
Laat jij het eerste OS maar eens zien dan dat geheel in VB is geschreven :P
Laat jij het eerste OS maar eens zien wat *GEHEEL* in C geschreven is.

  • warp
  • Registratie: Januari 2000
  • Niet online
Op donderdag 20 september 2001 13:53 schreef Yarvieh het volgende:

Laat jij het eerste OS maar eens zien wat *GEHEEL* in C geschreven is.
UNIX :P

  • warp
  • Registratie: Januari 2000
  • Niet online
Op donderdag 20 september 2001 13:53 schreef Yarvieh het volgende:

[..]

Laat jij de eerste OS maar eens zien wat *GEHEEL* in C geschreven is.
Sterker nog, laat jij de eerste OS source-code maar eens zien dat uberhaubt VB (of basic) bevat.

Verwijderd

Op donderdag 20 september 2001 13:56 schreef warp het volgende:
UNIX :P
Zitten altijd wel wat platform afhangkelijke assembly dingen in.. next?

  • warp
  • Registratie: Januari 2000
  • Niet online
Op donderdag 20 september 2001 13:59 schreef Yarvieh het volgende:
Zitten altijd wel wat platform afhangkelijke assembly dingen in.. next?
Nope, U gaat niet door voor de koelkast.

Het originele UNIX OS was geheel in C geschreven.

  • Primal
  • Registratie: Augustus 2001
  • Laatst online: 11-09 14:32
Op donderdag 20 september 2001 13:53 schreef Yarvieh het volgende:

[..]

Laat jij het eerste OS maar eens zien wat *GEHEEL* in C geschreven is.
Ok, C en assembler dan: WinNT :)

Ik geef zelf de (zeer) sterke voorkeur aan C/C++, maar ben nu bezig met een cursus (opleiding binnen het bedrijf) van VB. Het is wel een grappige omgeving, met veel zeer snelle klik-klak-klaar functies. Dat moet ik ze wel nageven. Toch ondervind ik het probleem dat er veel door VB/VB Runtime voor jou gedaan wordt. Sommige zaken zijn niet handig! Bv.: functie aanroep zonder 'call' waarbij je 1 referentie-parameter doorgeeft. Wat doet VB dan? "Oh die haakjes om de parameter zijn prioriteitshaken, dus laat ik van die referentie-parameter, maar een 'by value' parameter maken. :? Wel zo handig.". Ok ok, als je het weet ... Maar als je altijd in een taal als C/C++ hebt geprogrammeerd, dan is dit raar en onverwacht.

Ik geef de voorkeur toch aan het zelf uitzoeken/ontwikkelen van code. Inderdaad, indien het snel moet, je hebt niet veel tijd, dan is het een mooie oplossing. Wil je echt weten wat je eigenlijk aan het doen bent, bv: schrijven van een DLL, ontwikkelen van een COM-object, ontwerpen van classes (dus de onderliggende 'hardcore'-techniek). Dan raad ik je aan in ieder geval niet in VB te gaan programmeren, maar gewoon lekker in C/C++ (zoals ik het doe) :) :).

"The fastest code, is the code that is never called."


  • Gerco
  • Registratie: Mei 2000
  • Laatst online: 21-09 21:55

Gerco

Professional Newbie

Op donderdag 20 september 2001 14:00 schreef warp het volgende:
Het originele UNIX OS was geheel in C geschreven.
Lijkt me lastig booten, zonder bootsector. >:)

Een bootsector krijg je ECHT niet in C voor elkaar hoor, enne __asm { blaat }; telt niet :)

- "Als ik zou willen dat je het begreep, legde ik het wel beter uit!" | All number systems are base 10!


  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 21-09 18:16

Creepy

Tactical Espionage Splatterer

Op donderdag 20 september 2001 13:46 schreef Crazy_D het volgende:

[..]

En dan nog klagen dat VB programmeurs alleen met componentjes kunnen slepen :P
Whahaha :)

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 21-09 18:16

Creepy

Tactical Espionage Splatterer

Op donderdag 20 september 2001 14:09 schreef Gerco het volgende:

[..]

Lijkt me lastig booten, zonder bootsector. >:)

Een bootsector krijg je ECHT niet in C voor elkaar hoor, enne __asm { blaat }; telt niet :)
Een simpele bootsector in C? Waarom zou dat niet kunnen? Wordt toch gecompileerd naar ASM, en dan naar machine code, dus kan HEEL goed!!!

het eerste UNIX OS is GEHEEL geschreven in C. C is speciaal voor dat doel ontwikkeld (lees es wat dingen van Kernighan en Richie.. of zoek ze ff op op internet)

Maar feitelijk gezien is er geen 1 OS zonder ASM geschreven, aangezien elke compiler (java uitgezonder) eerst naar ASM omzet en dan assembleert naar machinecode :P

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


  • warp
  • Registratie: Januari 2000
  • Niet online
Op donderdag 20 september 2001 14:14 schreef Creepy het volgende:

het eerste UNIX OS is GEHEEL geschreven in C. C is speciaal voor dat doel ontwikkeld (lees es wat dingen van Kernighan en Richie.. of zoek ze ff op op internet)
Gelukkig zijn er hier ook mensen die wel weten waar ze het over hebben ;)

  • Sjonny
  • Registratie: Maart 2001
  • Laatst online: 08:06

Sjonny

Fratser

dan ben ik toch wel benieuwd met welke compiler ze dat bouwen, en hoe die init code van dat systeem eruit ziet..

The problem is in the part of your brain that handles intelligence.


Verwijderd

Op donderdag 20 september 2001 13:53 schreef Yarvieh het volgende:

[..]

Laat jij het eerste OS maar eens zien wat *GEHEEL* in C geschreven is.
atheos, puur 100% C++

Nu een VB OS svp >:)

  • Sjonny
  • Registratie: Maart 2001
  • Laatst online: 08:06

Sjonny

Fratser

wauw .. ik wil die compiler wel eens zien die uit c(++) statements mijn intel cpu in protected mode gooit. oh, en die code ook ...
en zoals Gerco schreef: __asm { blaat; } geldt niet.

The problem is in the part of your brain that handles intelligence.


Verwijderd

ff die malloc uit je C++ proggie slopen dat zorgt dat het traag is ...

gewoon ff een arraytje declareren ...

long uiGetallen[pMAxnumbeRs]

GOOD LUCK .

Verwijderd

Op donderdag 20 september 2001 14:46 schreef Sjonny het volgende:
wauw .. ik wil die compiler wel eens zien die uit c(++) statements mijn intel cpu in protected mode gooit. oh, en die code ook ...
en zoals Gerco schreef: __asm { blaat; } geldt niet.
de compiler maakt er zelf natuurlijk ASM van....

Voor de code raad ik je aan op http://www.kernel.org de welbekende linux kernel te downloaden. Atheos zit op http://www.atheos.com (geloof ik).

  • tomato
  • Registratie: November 1999
  • Niet online
Op donderdag 20 september 2001 14:59 schreef beelzebubu het volgende:
Atheos zit op http://www.atheos.com (geloof ik).
http://www.atheos.cx maar die lijkt down te zijn hiervandaan...

Verwijderd

Op donderdag 20 september 2001 13:16 schreef Creepy het volgende:
[..]
BC++???? De enige BC++ die ik ken is borland C++ BUILDER. Donder een ttable, tdatasource en een tdbgrid op een form.. BAM... kant en klare database applicatie.. Wat nou een component schrijven om een DB te benaderen.. klik klik en klaar :)
Ja met MFC ook (ong ;)). Ik doelde op COM components, die bv achter je website zitten in MTS/COM+. 2-tier database appjes maken is wel leuk ter demo van een RAD, maar niet nuttig, daar zelden een database echt per client wordt geleverd (men zit veelal in een grote, centrale database te poeren)
Je hebt het hiero over het vergelijken van ontwikkelomgevingen, niet van talen. Als je mensen terug in hun hok wilt stoppen.. doe het dan goed :) (of maak geen tikfouten als je VC++ bedoelt!) :)
Als je puur in VC++ (V als in Visual) bezig bent heb je denk ik gelijk, maar kijk eerst es naar de IDE van BC++ (B als in Borland). Daar hang je ook supersnel compleet werkende GUI's mee in elkaar. Of dat nou wel of niet sneller gaat dan de IDE van VB hangt volgens mij alleen af van de kennis die de persoon van de IDE van VB en BC++ heeft.
C++ Builder heeft meer RAD mogelijkheden dan VC++, weet niet of het VB benaderd, maar dat zal niet zoveel uitmaken idd. Een werkende gui is echter wat anders dan wat controls sleuren en pleuren. Validation, control flow etc, zijn toch dingen die je in C++ op een wat lower level moet programmeren, niet direct complexer, maar wel meer tikwerk.

Ik reageerde wellicht wat geirriteerd, maar ik kots zolangzamerhand op die vermeende hoogmoed van sommigen die kennelijk wordt ontleend aan het gebruik van een taal anders dan bv VB. Het boeit nl. geen zak welke taal je gebruikt, als het maar de taal is die je in staat stelt de beste software ('beste' als in best passend bij de gestelde specs en wensen (zowel klant als leverancier) te bouwen. En als dat T-SQL is dan gebruik je dat. Is dat VB dan gebruik je dat. Is dat C++ dan gebruik je dat. Op dit moment bouw ik mn custom installer voor database scripts in C++ (ivm SQL-DMO execution), de com objects in VB, de stored procs in T-SQL en de gui in ASP met XSL. Lekker belangrijk dat C++ kennelijk meer status geeft.

Een afgeronde opleiding, dat geeft status.

  • Korben
  • Registratie: Januari 2001
  • Laatst online: 14-11-2025

Korben

() => {};

Op donderdag 20 september 2001 14:46 schreef Sjonny het volgende:
wauw .. ik wil die compiler wel eens zien die uit c(++) statements mijn intel cpu in protected mode gooit. oh, en die code ook ...
en zoals Gerco schreef: __asm { blaat; } geldt niet.
Zoals beelzebubu al schreef... Atheos is compleet in C++ geschreven. Je zult toch asm moeten gebruiken. Ik weet zeker dat dit:
code:
1
2
3
4
__asm
{
  asm asm asm ....
}

Sneller is dan dit:
code:
1
2
// bvb...
outportb(0x220, 'a');

Omdat outportb allemaal checks nog uitvoerd (bmw). Bij asm kun je gewoon zonder checks allerlei shit uitvoeren. En bovendien is, intern, outportb() ook asm.

.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?


Verwijderd

Op donderdag 20 september 2001 12:42 schreef beelzebubu het volgende:
[..]
Zonder me in een troll-discussie te willen mengen....

Meer typewerk betekent niet automatisch slomer (om te schrijven) - logica in een taal enzo kan een hoop schelen. Minder typewerk betekent over het algemeen ook dat je sneller tegen de limitaties van een taal aanloopt.
Dat klopt. Maar veel talen, zoook VB, zijn niet beperkt in hun expressiekracht doordat ze met minder typen volstaan, maar doordat, wanneer je meer wilt, MEER moet typen dan je anders zou verwachten.

Een applicatie bouwen in VC++ met MFC of een applicatie bouwen in VB lijkt in eerste instantie niet zo'n groot verschil uit te maken. Echter in MFC ben je wel veroordeeld tot het op een lager niveau werken met gegevens die vanuit de gui de business logic ingeduwd wordt en vice versa er volgens de andere weg uitgetrokken wordt en de gui ingeduwd wordt. Dit kost typewerk, waarbij je in VB volstaat tot enkele regels code, moet je in VC++ met bv MFC nogal wat meer tikken, ookal ken je het framework, ookal heb je smartpointers voor je com tlb's.
Bovendien vond ik dat window-buildertje in VC++ toch wel dermate handig dat ik binnen enkele minuten een applicatie window had. Alleen nog de onderliggende code (messge-handling enzo) schrijven en je bent er. Zelfde als VB, toch :?
niet helemaal :) Alleen al het gekloot om data te converteren van BSTR's naar CStrings naar _bstr_t's naar _variant_t 's blabla om van framework specifieke zaken (zoals de gui ondersteunende vars in MFC bv) naar parameters voor COM objects (bv ADO components).... Dingen die VB bv standaard voor je regelt. En die kosten niet noemenswaardige tijd.

Verwijderd

Op donderdag 20 september 2001 14:00 schreef warp het volgende:
[..]
Nope, U gaat niet door voor de koelkast.
Het originele UNIX OS was geheel in C geschreven.
Klopt, Ritchie heeft C zelfs speciaal voor dit doel ontworpen :)

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 21-09 18:16

Creepy

Tactical Espionage Splatterer

Ik reageerde wellicht wat geirriteerd, maar ik kots zolangzamerhand op die vermeende hoogmoed van sommigen die kennelijk wordt ontleend aan het gebruik van een taal anders dan bv VB. Het boeit nl. geen zak welke taal je gebruikt, als het maar de taal is die je in staat stelt de beste software ('beste' als in best passend bij de gestelde specs en wensen (zowel klant als leverancier) te bouwen. En als dat T-SQL is dan gebruik je dat. Is dat VB dan gebruik je dat. Is dat C++ dan gebruik je dat. Op dit moment bouw ik mn custom installer voor database scripts in C++ (ivm SQL-DMO execution), de com objects in VB, de stored procs in T-SQL en de gui in ASP met XSL. Lekker belangrijk dat C++ kennelijk meer status geeft.

Een afgeronde opleiding, dat geeft status.
"Think first, act later." Kijk. nou doe je je ondertitel eer aan!

Het maakt idd geen zak uit in welke taal je progt, je pakt de taal die jou het handigst lijkt voor datgene dat je moet maken! En status van programeertalen... pff... er zijn inderdaad mensen die denken dat bepaalde talen meer status hebben dan de andere... pff... rot op! Ik heb meer respect voor een goede VB programmeur dan voor iemand die loopt aan te rotzooien in welke andere taal dan ook (overduidelijke memory leaks, objecten aanmaken en niet destroyen etc.).

Of iemand een goede programmeur is hang ECHT niet af van de taal. En of een taal wel of niet goed is hangt ook niet af van de programmeur.

En nog ff over de snelheidsvergelijking van C en VB. Er zijn benchmarks te schrijven die C sneller laten lijken, en er zijn er te schrijven die VB sneller laten lijken. Tegenwoordig zijn de compilers zo goed (ja, die van VB ook, als je dat een compiler kunt noemen) dat de verschillen bijna niet merkbaar zijn.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


Verwijderd

Op donderdag 20 september 2001 15:20 schreef Otis het volgende:
niet helemaal :) Alleen al het gekloot om data te converteren van BSTR's naar CStrings naar _bstr_t's naar _variant_t 's blabla om van framework specifieke zaken (zoals de gui ondersteunende vars in MFC bv) naar parameters voor COM objects (bv ADO components).... Dingen die VB bv standaard voor je regelt. En die kosten niet noemenswaardige tijd.
Echter, is dat een tekortkoming in C++ of een tekortkoming in de win32 API :?

Ik geef je groot gelijk hoor, ik heb me hier ook aan geirriteerd, maar dit is mijns inziens niet zozeer een (V)C++ mankement alswel een win32 mankement. Voor hetzelfde geld regelnde VC++ het ook voor je of VB ook niet.... Het is gewoon de hoeveelheid automatische functies die MS erin heeft gestoken....

Wat dat betrefd loopt VB misschien wel voor op (V)C++, maargoed, nogmaals, dat heeft niks met C++ als taal te maken, evenmin als met VB als taal. In principe zou in een goede (win32) api helemaal geen 50 verschillende string objecten mogen bestaan.... |:(

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Op woensdag 19 september 2001 23:41 schreef curry684 het volgende:
Ter vergelijking VC++ doet een full rebuild van dat project onder de 10 minuten met background compile ENABLED. En gaat pas volledig rebuilden zodra je echt fundamentele wijzigingen in de headers gooit (een enum veranderen slikt ie vaak zonder full rebuild).

Ja daar wordt ik altijd onverdeeld gelukkig van.
Welke versie van VC is dat?

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Op donderdag 20 september 2001 14:09 schreef Gerco het volgende:

[..]

Lijkt me lastig booten, zonder bootsector. >:)

Een bootsector krijg je ECHT niet in C voor elkaar hoor, enne __asm { blaat }; telt niet :)
Oh ja? Wat dacht je van het in ROM hebben van de kernel?
Heb je geen bootsector voor nodig.

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op donderdag 20 september 2001 12:04 schreef Otis het volgende:
Waarom zou hij ook? Jij vindt het kennelijk 'grappig' om te zeuren, dan net te doen alsof je het niet meende, maar even later geef je toch aan dat je het wel degelijk meende (in een andere posting).
Ik heb helemaal niet gedaan alsof ik het niet meende, je zou je eigen motto 'think first act later' wel iets letterlijker in de praktijk mogen brengen en eerst goed lezen voordat je op verstuur drukt.
Heeft iemand een teiltje voor me, zodat ik mn braaksel kwijt kan, wat spontaan naar boven kwam bij ALWEER een trutterige overbodige dombo-posting van Curry :r
Goh je hebt de flamecursus beter gelezen dan die gozer die zonodig een nieuwe user aan moest maken voor 1 brakke flame, maar het blijft geschreeuw in de ruimte zonder uberhaupt een poging tot solide argumenten (of aanleiding).

Ik raad je aan voor dit soort domme postings een aparte account te maken waar geen crew-titel achter je naam staat zodat mensen wat meer respect voor jou en de rest van de crew houden (tenzij Iznogood van jou is natuurlijk).

Professionele website nodig?


  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op donderdag 20 september 2001 15:12 schreef Otis het volgende:
...

Een afgeronde opleiding, dat geeft status.
ROFL!!! :) :) :)

Ik hoop dat deze schop richting mij was bedoeld, want dan was het eindelijke een fantastische flame na je geneuzel in de posts ervoor :P

(voor de mensen, wellicht ook Otis, die geen idee hebben waar ik het nu over heb: ja je kunt in mijn profile met wat moeite teruglezen dat ik de moeite niet heb genomen een vervolgopleiding af te maken :7 )

Professionele website nodig?


  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op donderdag 20 september 2001 16:03 schreef OlafvdSpek het volgende:
Welke versie van VC is dat?
VC6 laat soms cpp's met rust als je in een header die er wordt binnengetrokken dingen verandert waarvan ie weet dat ze in die cpp niet direct of indirect worden gebruikt. Andere keren besluit ie wel tot een full rebuild, ik weet niet waarop ie dat besluit baseert. Borland doet consequent volle rebuilds.

Professionele website nodig?


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Volle rebuilds als in alle C++ files opnieuw compileren, zelfs als ze die header niet gebruiken?

Verwijderd

Op vrijdag 21 september 2001 12:56 schreef OlafvdSpek het volgende:
Volle rebuilds als in alle C++ files opnieuw compileren, zelfs als ze die header niet gebruiken?
header1.h
code:
1
2
#include <header2.h>
[...]

header2.h
code:
1
2
int global_variable;
[...]

bla.c:
code:
1
2
#include <header1.h>
[...]

Nu verander ik header2.h, die niet in bla.c is ge-#include, dus hoef ik nu bla.c niet te hercompileren :?

Goede oplossing: als je een header verandert, alles hercompileren. Voorkomt een boel onoplosbare/vage problemen :)

Verwijderd

Op donderdag 20 september 2001 19:24 schreef curry684 het volgende:

[..]

ROFL!!! :) :) :)

Ik hoop dat deze schop richting mij was bedoeld, want dan was het eindelijke een fantastische flame na je geneuzel in de posts ervoor :P
Flamen hoef je mij niet te leren, QBasic freubelaar :)
(voor de mensen, wellicht ook Otis, die geen idee hebben waar ik het nu over heb: ja je kunt in mijn profile met wat moeite teruglezen dat ik de moeite niet heb genomen een vervolgopleiding af te maken :7 )
Joh.

Ik hoef geen ander account aan te maken om tegengas te geven op jouw sproeipoepargumenten, waarom zou ik?

Verwijderd

Op vrijdag 21 september 2001 13:33 schreef beelzebubu het volgende:

[..]

header1.h
code:
1
2
#include <header2.h>
[...]

header2.h
code:
1
2
int global_variable;
[...]

bla.c:
code:
1
2
#include <header1.h>
[...]

Nu verander ik header2.h, die niet in bla.c is ge-#include, dus hoef ik nu bla.c niet te hercompileren :?
Klopt.
Include alleen includefiles in .h files indien je een definitie van een type nodig hebt bij je definities in DIE .h file. In jouw geval hoef je header2 niet in header1 te includen. Gebruik je een definitie gedefinieerd in header2 in bla.c dan moet je header2 in bla.c includen en niet in header1.
Goede oplossing: als je een header verandert, alles hercompileren. Voorkomt een boel onoplosbare/vage problemen :)
Nou, in kleine projecties is dat wel aardig, maar in grote projects zoals mozilla of staroffice, ga jij niet alles meer hercompileren na het veranderen van 1 header :)

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Op vrijdag 21 september 2001 13:33 schreef beelzebubu het volgende:

[..]

header1.h
code:
1
2
#include <header2.h>
[...]

header2.h
code:
1
2
int global_variable;
[...]

bla.c:
code:
1
2
#include <header1.h>
[...]

Nu verander ik header2.h, die niet in bla.c is ge-#include, dus hoef ik nu bla.c niet te hercompileren :?

Goede oplossing: als je een header verandert, alles hercompileren. Voorkomt een boel onoplosbare/vage problemen :)
Jawel, bla.c is namelijk (indirect) afhankelijk van header2.h, dus gewoon recompilen. VC++ doet dit volgens mij goed.

En complete builds zijn op langzamere machines zelfs voor niet zo grote projecten vervelend.

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op vrijdag 21 september 2001 12:56 schreef OlafvdSpek het volgende:
Volle rebuilds als in alle C++ files opnieuw compileren, zelfs als ze die header niet gebruiken?
Sorry, ik bedoel met full rebuild 'alle dependent files'. Ik heb wel eens (zelden overigens) verbaasd gekeken hoe VC een file niet recompilede nadat ik in een van z'n headers enkel wat commentaar had veranderd (de essentie dus niet). Jammer genoeg is ie niet echt consequent hierin... :(

Professionele website nodig?


Verwijderd

Die vergelijking VB <-> C/C++ is een beetje krom omdat-ie nogal van je OS afhangt. Zo'n C programmatje is misschien veel sneller onder *NIX dan onder Windoze... Eerlijk gezegd denk ik dat VB _TRAAAAGGG_ is .

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op vrijdag 21 september 2001 23:19 schreef 4of10 het volgende:
Die vergelijking VB <-> C/C++ is een beetje krom omdat-ie nogal van je OS afhangt. Zo'n C programmatje is misschien veel sneller onder *NIX dan onder Windoze... Eerlijk gezegd denk ik dat VB _TRAAAAGGG_ is .
Onder welk ander OS dan Windows wou je dat VB programma tegen een C/C++ programma uitzetten dan? :? :? :?

Professionele website nodig?


Verwijderd

Op zaterdag 22 september 2001 01:13 schreef curry684 het volgende:

[..]

Onder welk ander OS dan Windows wou je dat VB programma tegen een C/C++ programma uitzetten dan? :? :? :?
De snelheid tussen VB en C. Dat is dus de snelheid tussen VB en C onder Windows met een bepaalde compiler. VB en C 'meten' is sowieso vaag. Hangt dat niet van de compiler af? Van je platform?

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 04-09 14:38

curry684

left part of the evil twins

Op zaterdag 22 september 2001 01:28 schreef 4of10 het volgende:
De snelheid tussen VB en C. Dat is dus de snelheid tussen VB en C onder Windows met een bepaalde compiler. VB en C 'meten' is sowieso vaag. Hangt dat niet van de compiler af? Van je platform?
Ik bedoelde dat VB onder Windows en C/C++ onder Linux/Unix/BeOS/AmigaOS vergelijken per definitie unfair is omdat je onderliggende overhead van kernel, memory management implementaties, GUI-systemen, drivers etc. niet kunt vergelijken.

Dus zul je aan een C++ compiler onder Windows moeten, en dan wordt dat automagisch Borland of MSVC++. Die maken onderling al weinig snelheidsverschillen, en voor zover ze er al zijn wordt dat vanzelf weggecompenseerd zodra je een echt representatief (dwz. groot) programma probeert te vergelijken tussen de omgevingen. Er zijn nu eenmaal geen 300 manieren om een for-loop te compilen of te optimizen.

Eindconclusie zal wel zijn dat brakke C++ hoogstens fractioneel sneller zal zijn dan VB (if at all), en dat goed uitgedachte en gedesignde C++ als een raket voor VB uitspringt. De potentie is er, je moet 'm alleen realiseren. Op een groter project dan die test uit de eerste post hierboven dan wel...

Professionele website nodig?


Verwijderd

Op vrijdag 21 september 2001 19:06 schreef OlafvdSpek het volgende:

[..]

Jawel, bla.c is namelijk (indirect) afhankelijk van header2.h, dus gewoon recompilen. VC++ doet dit volgens mij goed.

En complete builds zijn op langzamere machines zelfs voor niet zo grote projecten vervelend.
Met "alles" bedoel ik alle directe en indirecte dependent files.

Wat curry dus zegt over "ik verander een comment en hij wordt niet gehercompileerd" is natuurlijk leuk maar vindt ik eigenlijk al niet kunnen, een IDE hoort dat verschil nauwelijks/niet te zien (is ook weer voor bugs vatbaar - en die zijn uiteraard zeeeeeeeeeeeer irritant)

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Op zaterdag 22 september 2001 12:17 schreef beelzebubu het volgende:

[..]

Met "alles" bedoel ik alle directe en indirecte dependent files.

Wat curry dus zegt over "ik verander een comment en hij wordt niet gehercompileerd" is natuurlijk leuk maar vindt ik eigenlijk al niet kunnen, een IDE hoort dat verschil nauwelijks/niet te zien (is ook weer voor bugs vatbaar - en die zijn uiteraard zeeeeeeeeeeeer irritant)
Waarom zou een IDE dat niet horen te zien? Het lijkt me dat in de toekomst dit soort incremental compilen/linken veel meer voor gaat komen. Zelfs functie level recompilen/linken zie ik nog wel gebeuren.

  • jopiek
  • Registratie: September 2000
  • Laatst online: 21-08 19:56

jopiek

Tja... 'ns ff denken.

er is ook een gewone c++ compiler van borland trouwens hoor... naast C++ Builder...

tenzij je net als mij ff met M$ code bezig zit roelt Borland C++ (Builder) boven VB en VC++ (delphi trouwens ook ;)

Cogito Ergo Credo


  • farlane
  • Registratie: Maart 2000
  • Laatst online: 20-09 16:35
Naar mijn idee heeft VB niet de intentie om sneller te zijn dan C. Het heeft een ander toepassingsgebied als c, namelijk de 'simpele' gui appliciaties. Snelheid is daar niet _erg_ belangrijk.

Al het 'echte' werk, ( threads, communicatie, i/o, database access, weet ik het wat voor een onderwerp ) wordt nog steeds opgelost met een taal anders dan VB.

Punt is wel dat door de opzet van de taal VB (als die er al is ;) ), het een ongelooflijke knoeiboel wordt als je meer dan 2 paginas code hebt. Bovendien is het loskoppelen van de functionaliteit van je user interface praktisch onmogelijk.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

Pagina: 1 2 Laatste