VB even snel als C ???

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.

woensdag 19 september 2001 16:49

Acties:

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!!!

woensdag 19 september 2001 16:53

Acties:

Verwijderd

Waar is de vb port dan curry?

woensdag 19 september 2001 18:17

Acties:

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.

woensdag 19 september 2001 18:19

Acties:

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)

woensdag 19 september 2001 18:26

Acties:

Verwijderd

Op woensdag 19 september 2001 18:17 schreef curry684 een VB-Bash:

* curry684 is now known as PacMan684 *hap*hap*hap*hap*hap*

woensdag 19 september 2001 18:33

Acties:

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...

woensdag 19 september 2001 19:20

Acties:

iznogood

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

woensdag 19 september 2001 20:09

Acties:

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".

woensdag 19 september 2001 20:14

Acties:

mbravenboer

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

woensdag 19 september 2001 20:15

Acties:

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!

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...

woensdag 19 september 2001 20:18

Acties:

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.

woensdag 19 september 2001 20:58

Acties:

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...

woensdag 19 september 2001 21:07

Acties:

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...

woensdag 19 september 2001 23:21

Acties:

Verwijderd

Hmmz dit boeltje maar es nieuw leven in blazen..

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.

woensdag 19 september 2001 23:31

Acties:

marcelk

Op woensdag 19 september 2001 23:21 schreef Yarvieh het volgende:
Hmmz dit boeltje maar es nieuw leven in blazen..
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.

woensdag 19 september 2001 23:41

Acties:

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.

woensdag 19 september 2001 23:53

Acties:

left part of the evil twins

Over bugs in BCB gesproken, probeer deze eens in debugbuild:

code:

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....

donderdag 20 september 2001 02:52

Acties:

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.)

donderdag 20 september 2001 09:11

Acties:

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

donderdag 20 september 2001 09:30

Acties:

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?

donderdag 20 september 2001 10:12

Acties:

Verwijderd

Op donderdag 20 september 2001 09:30 schreef Infinity het volgende:
er mist dus een { na if.
Of is dit gewoon een typo?

Nee, die "}" hoort bij de for()

Veel leukere bug in VC++:

code:

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).

donderdag 20 september 2001 11:13

Acties:

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

donderdag 20 september 2001 11:19

Acties:

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:

int main()
{
  int j = 20;
  for (int i=0;i<j-5;i++)
  {
     printf("%d\n", i);
  }
  return 0;
}

donderdag 20 september 2001 12:04

Acties:

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

donderdag 20 september 2001 12:05

Acties:

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

donderdag 20 september 2001 12:08

Acties:

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.

donderdag 20 september 2001 12:42

Acties:

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

donderdag 20 september 2001 13:16

Acties:

donderdag 20 september 2001 13:23

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

Acties:

donderdag 20 september 2001 13:46

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

Acties:

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

Exact expert nodig?

donderdag 20 september 2001 13:53

Acties:

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

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

donderdag 20 september 2001 13:56

Acties:

donderdag 20 september 2001 13:57

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

Acties:

donderdag 20 september 2001 13:59

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.

Acties:

Verwijderd

Op donderdag 20 september 2001 13:56 schreef warp het volgende:
UNIX

Zitten altijd wel wat platform afhangkelijke assembly dingen in.. next?

donderdag 20 september 2001 14:00

Acties:

donderdag 20 september 2001 14:07

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.

Acties:

Primal

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."

donderdag 20 september 2001 14:09

Acties:

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!

donderdag 20 september 2001 14:10

Acties:

donderdag 20 september 2001 14:14

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

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

Acties:

donderdag 20 september 2001 14:21

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

"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

Acties:

donderdag 20 september 2001 14:37

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

Acties:

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.

donderdag 20 september 2001 14:40

Acties:

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

donderdag 20 september 2001 14:46

Acties:

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.

donderdag 20 september 2001 14:56

Acties:

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 .

donderdag 20 september 2001 14:59

Acties:

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).

donderdag 20 september 2001 15:02

Acties:

tomato

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...

donderdag 20 september 2001 15:12

Acties:

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.

donderdag 20 september 2001 15:15

Acties:

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:

__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?

donderdag 20 september 2001 15:20

Acties:

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.

donderdag 20 september 2001 15:21

Acties:

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

donderdag 20 september 2001 15:27

Acties:

donderdag 20 september 2001 15:34

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

Acties:

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....

donderdag 20 september 2001 16:03

Acties:

donderdag 20 september 2001 16:14

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?

Acties:

donderdag 20 september 2001 19:17

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.

Acties:

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

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).

donderdag 20 september 2001 19:24

Acties:

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

(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

)

donderdag 20 september 2001 19:27

Acties:

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.

vrijdag 21 september 2001 12:56

Acties:

vrijdag 21 september 2001 13:33

Volle rebuilds als in alle C++ files opnieuw compileren, zelfs als ze die header niet gebruiken?

Acties:

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

vrijdag 21 september 2001 15:16

Acties:

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

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 )

Joh.

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

vrijdag 21 september 2001 15:23

Acties:

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

vrijdag 21 september 2001 19:06

Acties:

vrijdag 21 september 2001 19:23

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.

Acties:

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...

vrijdag 21 september 2001 23:19

Acties:

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 .

zaterdag 22 september 2001 01:13

Acties:

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?

zaterdag 22 september 2001 01:28

Acties:

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?

zaterdag 22 september 2001 01:48

Acties:

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...

zaterdag 22 september 2001 12:17

Acties:

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)

zaterdag 22 september 2001 12:27

Acties:

zaterdag 22 september 2001 12:31

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.

Acties:

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

zaterdag 22 september 2001 21:14

Acties:

farlane

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.

zaterdag 22 september 2001 21:44

Acties:

Verwijderd

Op zaterdag 22 september 2001 21:14 schreef farlane het volgende:
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.

Alle andere punten heb je redelijk (helemaal eigenlijk) gelijk in,deze functionaliteit is vrij gemakkelijk te realiseren door je logica in classes te verpakken, goed je hebt niet de class features die je gewent bent uit c++ zoals inheritance ed. maar het is toch nog net genoeg om de scheiding tussen je gui en je logica te kunnen maken.
(en ze hebben het allemaal goed gemaakt in vb.net)

zaterdag 22 september 2001 23:08

Acties:

left part of the evil twins

Op zaterdag 22 september 2001 12:17 schreef beelzebubu het volgende:
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)

Dus wat jou betreft mag het grafische gedeelte van de IDE de context van een wijziging wel snappen (als in syntax-highlighting) maar het functionele gedeelte niet? Commentaar maakt nooit functioneel verschil...

En VC++ houdt ook constant voor de code completion bij welke variabelen/types er in de includes staan gedefinieerd, waarom zou ie die kennis niet andersom mogen gebruiken om te constateren dat een file een bepaalde variabele/type niet gebruikt?

Kijk een class-wijziging moet altijd recompilen omdat het bijna onmogelijk is te voorspellen of ie ergens geaggregeerd of gesubclassed wordt, maar een waarde toevoegen aan een enum (niet wijzigen dus) is imho geen valide reden tot full recompile.

zaterdag 22 september 2001 23:10

Acties:

left part of the evil twins

Op zaterdag 22 september 2001 21:44 schreef Yarvieh het volgende:
[...]
(en ze hebben het allemaal goed gemaakt in vb.net)

Alleen jammer dat het 100% niet backwards-compatible is en je er dus nog geen k*t aan hebt.

zaterdag 22 september 2001 23:26

Acties:

Verwijderd

Op zaterdag 22 september 2001 23:10 schreef curry684 het volgende:
Alleen jammer dat het 100% niet backwards-compatible is en je er dus nog geen k*t aan hebt.

Mja true true, maar we zijn het er beide over eens dat de huidige vb (versie 5/6) niet echt een mooie programmeer taal is, maken ze er wat moois van, ga je zeuren dat het niet backwards compatible is met well ermz..*crap*

zaterdag 22 september 2001 23:51

Acties:

Verwijderd

Op zaterdag 22 september 2001 23:08 schreef curry684 het volgende:

[..]

Dus wat jou betreft mag het grafische gedeelte van de IDE de context van een wijziging wel snappen (als in syntax-highlighting) maar het functionele gedeelte niet? Commentaar maakt nooit functioneel verschil...

En VC++ houdt ook constant voor de code completion bij welke variabelen/types er in de includes staan gedefinieerd, waarom zou ie die kennis niet andersom mogen gebruiken om te constateren dat een file een bepaalde variabele/type niet gebruikt?

Kijk een class-wijziging moet altijd recompilen omdat het bijna onmogelijk is te voorspellen of ie ergens geaggregeerd of gesubclassed wordt, maar een waarde toevoegen aan een enum (niet wijzigen dus) is imho geen valide reden tot full recompile.

Ja... heb je misschien wel gelijk in.....

Maar het is allemaal zo buggevoelig, lijkt me, met indirecte verwijzingen tussen bestanden enzo..... Ik weet niet in hoeverre VC++ deze indirecte verwijzingen allemaal begrijpt..... Wat jij ook al noemde over subclasses enzo. En dat lijkt mij zeer irritant en onvindbaar als op die manier "bugs" in je programma komen. Veiligheid voor alles zou ik zeggen (met een naief hoofd en weinig ervaring in grote projecten

)

Zal wel beetje conservatisme van mij zijn (ik gebruik meestal in linux gewoon vi of nedit ofzo, geen echte geavanceerde grafische IDE ofzo)...

zondag 23 september 2001 00:17

Acties:

left part of the evil twins

Op zaterdag 22 september 2001 23:26 schreef Yarvieh het volgende:
Mja true true, maar we zijn het er beide over eens dat de huidige vb (versie 5/6) niet echt een mooie programmeer taal is, maken ze er wat moois van, ga je zeuren dat het niet backwards compatible is met well ermz..*crap*

Daar hebben MS en Intel toch copyright op, het GIGO(tm) concept? (Garbage In Garbage Out

)

Een P-3 zou ook minstens dubbel zo snel kunnen zijn als ie niet een superset van de instructieset van de 8068 zou gebruiken (een Itanium is niet voor niets zo retesnel op custom-written code). En WinXP had ook een stuk kleiner en sneller kunnen zijn als je er niet alle Win32 bagger uit 1995 nog op kon draaien

zondag 23 september 2001 00:20

Acties:

left part of the evil twins

Op zaterdag 22 september 2001 23:51 schreef beelzebubu het volgende:
(met een naief hoofd en weinig ervaring in grote projecten )

Ik zou een stuk minder roken als ik niet na iedere header-change 10-20 minuten moest wachten op een recompile... ga MS en Borland denk ik maar eens aanklagen voor 7,5 miljard dollar wegens poging tot moord