Ik vroeg me af wat nou eigenlijk de verschillen zijn in mogelijkheden tussen Delphi 5 en C++ Builder 5. Ze zien er wat betreft GUI precies hetzelfde uit, zelfs de bijgeleverde components zijn precies hetzelfde. Zodoende kom ik tot deze vraag: Wat is het grote(?) voordeel om met C++ Builder 5 te programmeren ipv met Delphi 5
Ja duh dat bedoel ik ook niet, het gaat me om de verschillen in mogelijkheden tussen Delphi 5 en C++ Builder 5.
Demogelijkheid is bij de ene dat je C++ kan gebruiken en bij de andere Pascal..
Die 2 programma's zijn ook maar grafische tools waar je (onder andere) snel een formpje mee kan maken..
Verwijderd
Kom op mensen... als je niets nuttigs te zeggen hebt, plaats dan niets!!
De compiler back-end van D5 en C++ Builder is dezelfde. De VCL (de classlibrary en tevens de basis van Delphi en C++ Builder) is exact dezelfde. De VCL van C++ Builder is dus ook in Object Pascal geschreven. De IDE van Delphi en C++ Builder zijn bijna hetzelfde (verschilt bijv. in compiler opties).
Voor zover ik weet ervaren de meeste mensen Object Pascal (Delphi) als een gemakkelijker te leren taal dan C++ (C++ Builder).
Kortom, technisch gezien zijn het dezelfde producten.
De compiler back-end van D5 en C++ Builder is dezelfde. De VCL (de classlibrary en tevens de basis van Delphi en C++ Builder) is exact dezelfde. De VCL van C++ Builder is dus ook in Object Pascal geschreven. De IDE van Delphi en C++ Builder zijn bijna hetzelfde (verschilt bijv. in compiler opties).
Voor zover ik weet ervaren de meeste mensen Object Pascal (Delphi) als een gemakkelijker te leren taal dan C++ (C++ Builder).
Kortom, technisch gezien zijn het dezelfde producten.
Jah dat zei ik ook al..
Enige verschil is is dat je bij de ene in C++ moet programeren en bij de ander in Pascal
Enige verschil is is dat je bij de ene in C++ moet programeren en bij de ander in Pascal
volgens mij heeft c++ de mogelijkheid om bv. rechtstreeks je pc-poorten aan te spreken, delphi kan dit niet (er zijn natuurlijk wel componenten die dit verhelpen).
c++ is inderdaad moeilijker dan object pascal.
vb.
als je een bepaald geheugengebied reserveerd (array van 10 elementen) kun je in c++ rustig 20 elementen volschrijven zonder er een foutmelding komt, maar je zit dan wel in een geheugengebied te schrijven wat misschien door een andere app gebruikt word.
In Delphi kan dit niet(veel voorkomende foutmelding op school was ' listindex out of bounds', 'k heb er nou nog enge dromen van
)
c++ is inderdaad moeilijker dan object pascal.
vb.
als je een bepaald geheugengebied reserveerd (array van 10 elementen) kun je in c++ rustig 20 elementen volschrijven zonder er een foutmelding komt, maar je zit dan wel in een geheugengebied te schrijven wat misschien door een andere app gebruikt word.
In Delphi kan dit niet(veel voorkomende foutmelding op school was ' listindex out of bounds', 'k heb er nou nog enge dromen van
"I'd change the world but God won't give me the source code"
Bedankt mensen! Hier heb ik tenminste wat aan
Verwijderd
Compoorten aanspreken kan ook wel in delphi, alleen dan heb vaak het probleem dat je de API's in pascal moet gaan gebruiken en dat kan nog wel eens lastig zijn voor mensen..
Er is geen "groot voordeel". Is hetzelfde als vragen wat het voordeel is van Spaans boven Duits ofzoiets. Het zijn gewoon 2 verschillende talen waarmee je in principe dezelfde dingen kunt bereiken, alleen op een iets andere manier. Hangt gewoon van ieder's persoonlijke smaak af. En er is er niet een "beter" dan de andere.
<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>volgens mij heeft c++ de mogelijkheid om bv. rechtstreeks je pc-poorten aan te spreken, delphi kan dit niet[/quote]In Windows kunnen ze het allebei niet. En aangezien Delphi Windows-only is kan Delphi het dus niet nee. 
Maar in bijvoorbeeld Pascal voor DOS kan het prima hoor...<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>als je een bepaald geheugengebied reserveerd (array van 10 elementen) kun je in c++ rustig 20 elementen volschrijven zonder er een foutmelding komt, maar je zit dan wel in een geheugengebied te schrijven wat misschien door een andere app gebruikt word.[/quote]Wederom, dat gaat niet op voor Windows. Je kunt (in principe) niet in geheugengebieden van andere programma's schrijven. Enne... met Delphi kun je ook gewoon naar een willekeurig adres in je geheugen (proberen te
) schrijven hoor. En je kunt ook gewoon range-checking voor arrays uitzetten. (sterker nog, dat staat volgens mij standaard uit)
Maar in bijvoorbeeld Pascal voor DOS kan het prima hoor...<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>als je een bepaald geheugengebied reserveerd (array van 10 elementen) kun je in c++ rustig 20 elementen volschrijven zonder er een foutmelding komt, maar je zit dan wel in een geheugengebied te schrijven wat misschien door een andere app gebruikt word.[/quote]Wederom, dat gaat niet op voor Windows. Je kunt (in principe) niet in geheugengebieden van andere programma's schrijven. Enne... met Delphi kun je ook gewoon naar een willekeurig adres in je geheugen (proberen te
<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Wedden van wel?[/quote]:):):):)
<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Wederom, dat gaat niet op voor Windows. Je kunt (in principe) niet in geheugengebieden van andere programma's schrijven.[/quote]Onder Win32 op Windows 95, 98 en ME kan je wel Windows code in RAM (geladen user DLL's) overschrijven 
Overigens is dit bij array's niet zo relevant. Pascal/Delphi ondersteunt range checking mits je bij de declaratie van het type de geldige range opgeeft. C++ heeft zoiets niet. Als je al over de grens van een array heen schrijft overschrijf je je globale variabelen, stack of heap afhankelijk van waar je je array declareert. Vooral het laatste leidt tot fraaie crashes omdat elk blok op de heap een header heeft die gebruikt wordt voor managen van de heap.
C++ of Pascal? Is een kwestie van persoonlijke voorkeur. C++ is uitgebreider en minder restrictief, maar dat maakt het ook moeilijker. Als je C++ eenmaal onder de knie hebt (neem uitgebreid de tijd) wil je niet meer terug, maar dat wil niet zeggen dat C++ beter is.
Overigens is dit bij array's niet zo relevant. Pascal/Delphi ondersteunt range checking mits je bij de declaratie van het type de geldige range opgeeft. C++ heeft zoiets niet. Als je al over de grens van een array heen schrijft overschrijf je je globale variabelen, stack of heap afhankelijk van waar je je array declareert. Vooral het laatste leidt tot fraaie crashes omdat elk blok op de heap een header heeft die gebruikt wordt voor managen van de heap.
C++ of Pascal? Is een kwestie van persoonlijke voorkeur. C++ is uitgebreider en minder restrictief, maar dat maakt het ook moeilijker. Als je C++ eenmaal onder de knie hebt (neem uitgebreid de tijd) wil je niet meer terug, maar dat wil niet zeggen dat C++ beter is.
Verwijderd
Delphi is gemakkelijker te leren als C++, C bied meer mogelijkheden. Het hangt er ook vanaf wat je met die taal wil doen. Geen enkele taal is een soort van alleslijm. Ik ben uiteindelijk toch bij MS C++ etc. terechtgekomen vanwege de betere integratie met het OS en Office, dit was dan vooral in vergelijk met Delphi. Zeker voor kantoorautomatisering werkt dat beter.
c++ is OO dus,..classen enzo,...overerving en al dat gedoe,....pascal heeft dit niet....
<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>c++ is OO dus,..classen enzo,...overerving en al dat gedoe,....pascal heeft dit niet....[/quote]Maar Delphi is geen Pascal, Delphi is Object Pascal. En die heeft dat wel. (zoals de naam ook al wel deed vermoeden
)<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Onder Win32 op Windows 95, 98 en ME kan je wel Windows code in RAM (geladen user DLL's) overschrijven[/quote]Uhm tja... lekken in Windows daargelaten natuurlijk.
Verwijderd
<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Op 30 oktober 2000 20:19 schreef Onno het volgende:
In Windows kunnen ze het allebei niet. En aangezien Delphi Windows-only is kan Delphi het dus niet nee. [/quote]Borland is anders wel bezig aan een Linux-versie van Delphi (en die beta's doen het al echt goed)
In Windows kunnen ze het allebei niet. En aangezien Delphi Windows-only is kan Delphi het dus niet nee. [/quote]Borland is anders wel bezig aan een Linux-versie van Delphi (en die beta's doen het al echt goed)
Wat zijn pc-poorten?
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.
Verwijderd
C++ builder zuigt aan alle kanten.
Ik heb zelf geen ervaringen met C++ builder 5, maar wel met eerdere versies (project van 3/4 jaar gedraaid).
Je kan duidelijk merken dat het een ondergeschoven kindje van Borland is.
Voordelen van C++ builder:
- Je kan met C++ werken
Nadelen:
- Jou code is C++ maar de VCL is gewoon pascal-code die wordt omgezet naar modules of zo. C++ builder gaat dus stukker C++ aan stukken Delphi knopen. Hierdoor krijg je (waarschijnlijk) altijd wat overhead en rare situaties.
- C++ is case sensative. De IDE van Delphi en van C++ builder niet. Dit leidt tot zeer rare situaties, zoals dat je componenten op je forms niet van bv Image naar image kan hernoemen (Image is in IDE hetzelfde als image) maar dat je hier wel foutmeldingen over krijgt als je de code compileert (kan image niet vinden omdat er Image in de code staat)
- De compiler levert afhankelijk van de compiler settings verschillende functionaliteit. Als ik de project settings wijzigde [opties die niks met code te maken hebben] kwamen er wel of geen excepties en andere foute melding. Ook of je wel of geen gebruik maakt van runtime libraries [is een optie in projecten] zorgt er voor dat er wel of geen excepties optreden.
- Ook merk je gewoon dat het niet het hoofdproduct is van Borland. Constanten die niet gedeclareerd zijn, of wel gedeclareerd zijn in de VCL, maar niet worden herkend.
Het enig knappe stukje werk in heel C++ builder is het deel dat de OO pascalcode omzet naar C achtige objecten.
Als je met een Delphi achtige omgeving wil werken, werk dan gewoon met Delphi.
Wil je met C/C++ werken gan dan voor de Miro$oft variant.
C++ builder is gewoon KUT!
Zoals ik al zei heb ik geen ervaringen met C++ builder 5.0, maar dat zal nog steeds wel net zo brak zijn
Ik heb zelf geen ervaringen met C++ builder 5, maar wel met eerdere versies (project van 3/4 jaar gedraaid).
Je kan duidelijk merken dat het een ondergeschoven kindje van Borland is.
Voordelen van C++ builder:
- Je kan met C++ werken
Nadelen:
- Jou code is C++ maar de VCL is gewoon pascal-code die wordt omgezet naar modules of zo. C++ builder gaat dus stukker C++ aan stukken Delphi knopen. Hierdoor krijg je (waarschijnlijk) altijd wat overhead en rare situaties.
- C++ is case sensative. De IDE van Delphi en van C++ builder niet. Dit leidt tot zeer rare situaties, zoals dat je componenten op je forms niet van bv Image naar image kan hernoemen (Image is in IDE hetzelfde als image) maar dat je hier wel foutmeldingen over krijgt als je de code compileert (kan image niet vinden omdat er Image in de code staat)
- De compiler levert afhankelijk van de compiler settings verschillende functionaliteit. Als ik de project settings wijzigde [opties die niks met code te maken hebben] kwamen er wel of geen excepties en andere foute melding. Ook of je wel of geen gebruik maakt van runtime libraries [is een optie in projecten] zorgt er voor dat er wel of geen excepties optreden.
- Ook merk je gewoon dat het niet het hoofdproduct is van Borland. Constanten die niet gedeclareerd zijn, of wel gedeclareerd zijn in de VCL, maar niet worden herkend.
Het enig knappe stukje werk in heel C++ builder is het deel dat de OO pascalcode omzet naar C achtige objecten.
Als je met een Delphi achtige omgeving wil werken, werk dan gewoon met Delphi.
Wil je met C/C++ werken gan dan voor de Miro$oft variant.
C++ builder is gewoon KUT!
Zoals ik al zei heb ik geen ervaringen met C++ builder 5.0, maar dat zal nog steeds wel net zo brak zijn
Verwijderd
<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Op 29 oktober 2000 17:54 schreef Neman het volgende:
Ze zien er wat betreft GUI precies hetzelfde uit, zelfs de bijgeleverde components zijn precies hetzelfde.[/quote]Dit komt dus doordat de hele VCL nog gewoon pascal is, net zoals de componenten. Er zijn alleen headers files aan toegevoegd.
Ze zien er wat betreft GUI precies hetzelfde uit, zelfs de bijgeleverde components zijn precies hetzelfde.[/quote]Dit komt dus doordat de hele VCL nog gewoon pascal is, net zoals de componenten. Er zijn alleen headers files aan toegevoegd.
Verwijderd
<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Jou code is C++ maar de VCL is gewoon pascal-code die wordt omgezet naar modules of zo. C++ builder gaat dus stukker C++ aan stukken Delphi knopen. Hierdoor krijg je (waarschijnlijk) altijd wat overhead en rare situaties.[/quote]<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Het enig knappe stukje werk in heel C++ builder is het deel dat de OO pascalcode omzet naar C achtige objecten.[/quote]Hmm, ik zal ff wat uitleggen.
Een compiler bestaat uit meerdere delen. Broncode wordt omgezet in intermediate "taal" en deze intermediate code wordt omgezet naar machinecode. Wat ze bij C++ Builder hebben gedaan is gewoon 2 fronts (C++ en Object Pascal) gebruiken die de code omzetten naar dezelfde intermediate "taal". Deze intermediate taal wordt dan omgezet in machinecode. Er ontstaat geen overhead door het gebruiken van twee verschillende talen. Ze hebben alleen wat technische probleempjes op moeten lossen omdat Object Pascal sommige functionaliteiten van C++ niet heeft (zoals multiple inheritance) en andersom. Tevens hebben ze C++ aan moeten passen om events en properties mogelijk te maken.
Ik vind het een erg goede oplossing om de VCL niet te vertalen naar C++ maar gewoon twee talen te ondersteunen. Dit scheelt heel wat werk bij het onderhouden en uitbreiden van de VCL.
Persoonlijk vind ik beide producten verschrikkelijk. Natuurlijk kun je met Delphi snel applicaties maken, maar de ontwikkelomgeving zelf is ZOOOO buggy en de debuggings mogelijkheden zijn werkelijk prehistorisch.
Een compiler bestaat uit meerdere delen. Broncode wordt omgezet in intermediate "taal" en deze intermediate code wordt omgezet naar machinecode. Wat ze bij C++ Builder hebben gedaan is gewoon 2 fronts (C++ en Object Pascal) gebruiken die de code omzetten naar dezelfde intermediate "taal". Deze intermediate taal wordt dan omgezet in machinecode. Er ontstaat geen overhead door het gebruiken van twee verschillende talen. Ze hebben alleen wat technische probleempjes op moeten lossen omdat Object Pascal sommige functionaliteiten van C++ niet heeft (zoals multiple inheritance) en andersom. Tevens hebben ze C++ aan moeten passen om events en properties mogelijk te maken.
Ik vind het een erg goede oplossing om de VCL niet te vertalen naar C++ maar gewoon twee talen te ondersteunen. Dit scheelt heel wat werk bij het onderhouden en uitbreiden van de VCL.
Persoonlijk vind ik beide producten verschrikkelijk. Natuurlijk kun je met Delphi snel applicaties maken, maar de ontwikkelomgeving zelf is ZOOOO buggy en de debuggings mogelijkheden zijn werkelijk prehistorisch.
Lekker gefundeerde kritiek 
- Wat bedoel je met 'buggy'?
- Welke debugopties mis je?
- etc.
Kben benieuwd!
- Wat bedoel je met 'buggy'?
- Welke debugopties mis je?
- etc.
Kben benieuwd!
Verwijderd
<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Lekker gefundeerde kritiek
- Wat bedoel je met 'buggy'?
- Welke debugopties mis je?
- etc.[/quote]Oh, sorry je hebt gelijk.
Buggy:
- de code completion werkt regelmatig niet
- af en toe internal compiler errors die na het opnieuw starten van Delphi spontaan verdwenen zijn
- de inhoud van variabelen wordt regelmatig niet weergegeven
- breakpoints worden regelmatig overgeslagen
- bij een exception geeft de debugger regelmatig de verkeerde regel aan (een functie hoger)
- de ontwikkelomgeving zelf loopt te vaak vast
Debug opties die ik mis:
- edit and continue (breakpoint zetten, als hij daar gestopt is code wijzigen en programma door laten gaan met nieuwe code)
- de inhoud van variabelen moet tijdens het debuggen makkelijker te wijzigen zijn. Momenteel kunnen niet alle soorten variabelen gewijzigd worden.
- Een manier op te controleren of je geheugen vergeten bent vrij te geven (debug-heap dus) en andere handige hulpjes zoals checken of je buiten je stuk geheugen bent gegaan.
- profiling
Ik kan er vast nog wel meer verzinnen, maar dit zijn voor mij genoeg argumenten.
Uiteraard ligt het er aan wat je met Delphi doet of je wel of geen last hebben van deze dingen. Dus opmerkingen zoals: "nou, ik heb er geen last van" hoeven geen tegenargumenten te zijn.
Maar om ff positief af te sluiten, ik vind Delphi wel knap in elkaar zitten.
- Wat bedoel je met 'buggy'?
- Welke debugopties mis je?
- etc.[/quote]Oh, sorry je hebt gelijk.
Buggy:
- de code completion werkt regelmatig niet
- af en toe internal compiler errors die na het opnieuw starten van Delphi spontaan verdwenen zijn
- de inhoud van variabelen wordt regelmatig niet weergegeven
- breakpoints worden regelmatig overgeslagen
- bij een exception geeft de debugger regelmatig de verkeerde regel aan (een functie hoger)
- de ontwikkelomgeving zelf loopt te vaak vast
Debug opties die ik mis:
- edit and continue (breakpoint zetten, als hij daar gestopt is code wijzigen en programma door laten gaan met nieuwe code)
- de inhoud van variabelen moet tijdens het debuggen makkelijker te wijzigen zijn. Momenteel kunnen niet alle soorten variabelen gewijzigd worden.
- Een manier op te controleren of je geheugen vergeten bent vrij te geven (debug-heap dus) en andere handige hulpjes zoals checken of je buiten je stuk geheugen bent gegaan.
- profiling
Ik kan er vast nog wel meer verzinnen, maar dit zijn voor mij genoeg argumenten.
Uiteraard ligt het er aan wat je met Delphi doet of je wel of geen last hebben van deze dingen. Dus opmerkingen zoals: "nou, ik heb er geen last van" hoeven geen tegenargumenten te zijn.
Maar om ff positief af te sluiten, ik vind Delphi wel knap in elkaar zitten.
Verwijderd
<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Op 02 november 2000 23:00 schreef Kurzweil het volgende:
- edit and continue (breakpoint zetten, als hij daar gestopt is code wijzigen en programma door laten gaan met nieuwe code)[/quote]Jij bent dan zeker een Visual Basic programmeur. [Oeps VB & programmeur in één zin zonder ontkenning er in :P]
Volgens mij is het alleen bij interpetted talen [zoals visual basic] het mogelijk om code te wijzigen dan dan weer door te gaan met het programma.
- edit and continue (breakpoint zetten, als hij daar gestopt is code wijzigen en programma door laten gaan met nieuwe code)[/quote]Jij bent dan zeker een Visual Basic programmeur. [Oeps VB & programmeur in één zin zonder ontkenning er in :P]
Volgens mij is het alleen bij interpetted talen [zoals visual basic] het mogelijk om code te wijzigen dan dan weer door te gaan met het programma.
Een aantal van je puntjes zijn correct, een aantal niet helemaal:
- de inhoud van variabelen -kan- soms niet worden weergegevens door compiler optimalisations. Die moet je tijdens het ontwikkelen dan ook uitzetten
- overgeslagen breakpoints heb ik nog -nooit- meegemaakt (Delphi 5), en ik werk zeker 4a5 uur per dag met Delphi.
- Vastlopers in de ontwikkelomgeving evenmin.
- Voor het checken van geheugenleks heb je programma's als BoundsChecker. Dat dit niet standaard wordt aangeboden is wel jammer. Ik weet zelf niet in hoeverre andere talen dit wel hebben.
Verder zitten er idd een aantal kleine foutjes in, maar ja, niets is perfect.. Voor mij zijn er meer dan genoeg positieve punten om niets anders te willen gebruiken. Delphi rulez
(en we zijn weer lekker off-topic aan het gaan
)
- de inhoud van variabelen -kan- soms niet worden weergegevens door compiler optimalisations. Die moet je tijdens het ontwikkelen dan ook uitzetten
- overgeslagen breakpoints heb ik nog -nooit- meegemaakt (Delphi 5), en ik werk zeker 4a5 uur per dag met Delphi.
- Vastlopers in de ontwikkelomgeving evenmin.
- Voor het checken van geheugenleks heb je programma's als BoundsChecker. Dat dit niet standaard wordt aangeboden is wel jammer. Ik weet zelf niet in hoeverre andere talen dit wel hebben.
Verder zitten er idd een aantal kleine foutjes in, maar ja, niets is perfect.. Voor mij zijn er meer dan genoeg positieve punten om niets anders te willen gebruiken. Delphi rulez
(en we zijn weer lekker off-topic aan het gaan
<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>de inhoud van variabelen wordt regelmatig niet weergegeven[/quote]Dan moet je code optimalisaties uitzetten.
Als jij iets bouwt als
var
a:integer;
begin
a:=0
bladiebla, en ik gebruik a lekker nooit meer
end
dan zal die hele a gewoon weggeoptimaliseerd worden. Natuurlijk kun je de waarde ervan dan niet bekijken.<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>-breakpoints worden regelmatig overgeslagen
- bij een exception geeft de debugger regelmatig de verkeerde regel aan (een functie hoger)
- de ontwikkelomgeving zelf loopt te vaak vast[/quote]Met Delphi 5 heb ik hier nog nooit iets van gemerkt. En als je 4 hebt: wel de laatste patches geinstalleerd? Die zijn bij 4 nogal hard nodig geloof ik.
Als jij iets bouwt als
var
a:integer;
begin
a:=0
bladiebla, en ik gebruik a lekker nooit meer
end
dan zal die hele a gewoon weggeoptimaliseerd worden. Natuurlijk kun je de waarde ervan dan niet bekijken.<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>-breakpoints worden regelmatig overgeslagen
- bij een exception geeft de debugger regelmatig de verkeerde regel aan (een functie hoger)
- de ontwikkelomgeving zelf loopt te vaak vast[/quote]Met Delphi 5 heb ik hier nog nooit iets van gemerkt. En als je 4 hebt: wel de laatste patches geinstalleerd? Die zijn bij 4 nogal hard nodig geloof ik.
Verwijderd
<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Jij bent dan zeker een Visual Basic programmeur.[/quote]Niet echt netjes om persoonlijk te gaan worden in een discussie. Maar voor de duidelijkheid, ik heb VB nog nooit aangeraakt.<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>de inhoud van variabelen -kan- soms niet worden weergegevens door compiler optimalisations. Die moet je tijdens het ontwikkelen dan ook uitzetten[/quote]Uiteraard weet ik dat en zet ik optimalisaties uit. Toch krijg je daarna soms de melding dat het niet gelezen kan worden "due to optimizations"..<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>overgeslagen breakpoints heb ik nog -nooit- meegemaakt[/quote]Dat is heel mooi voor je. Ik had er vaak last van bij het werken met varianten, bijvoorbeeld ADO objecten. Toegegeven, dat was wel met Delphi 4 (met alle patches).
Tja, dit zijn mijn ervaringen (en die van enkele ex-collega's) dus meer valt er niet over te zeggen...
Maar nu weten we nogsteeds niet een voordeel van C++ Builder t.o.v. Delphi 5
Tja, dit zijn mijn ervaringen (en die van enkele ex-collega's) dus meer valt er niet over te zeggen...
Maar nu weten we nogsteeds niet een voordeel van C++ Builder t.o.v. Delphi 5
<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Op 03 november 2000 19:54 schreef Kurzweil het volgende:
Niet echt netjes om persoonlijk te gaan worden in een discussie. Maar voor de duidelijkheid, ik heb VB nog nooit aangeraakt.[/quote]Ik had het misschien beter anders kunnen formulieren.. Sorry.<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Maar nu weten we nogsteeds niet een voordeel van C++ Builder t.o.v. Delphi 5 :)[/quote]Simpel.. da is er nie.. behalve dan dat je met C++ kan werken [als dat een voordeel is]
Niet echt netjes om persoonlijk te gaan worden in een discussie. Maar voor de duidelijkheid, ik heb VB nog nooit aangeraakt.[/quote]Ik had het misschien beter anders kunnen formulieren.. Sorry.<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Maar nu weten we nogsteeds niet een voordeel van C++ Builder t.o.v. Delphi 5 :)[/quote]Simpel.. da is er nie.. behalve dan dat je met C++ kan werken [als dat een voordeel is]
Less = more
Pagina: 1