[artikel] Testen.nl

[riezebosch]

Vond op Testen.nl een artikel wat me nogal deed scrikken Dingen hierin beweerd gaan namelijk nogal in tegen het, bij mijn weten, heersende programmeursdenken.

• Taal irrelevant mbt aantal fouten per 1000 regels code
• Kleine componenten niet minder fouten. Ook niet beter voor hergebruik, en hergebruik al helemaal niet beter voor minder fouten...

Verder best interessant artikel om te lezen, doe er je voordeel mee

edit:

Met name het afkraken van "mijn" C++ deed me erg pijn

[ Voor 8% gewijzigd door riezebosch op 15-09-2004 14:58 ]

[.oisyn]

Het is echt ongelooflijk dom om de besturing van een kernreactor te programmeren in een taal als C++, iets wat nu echt gebeurt

Ik vind dit een beetje bullshit, ik ben benieuwd in welke taal het dan wel geprogrammeerd had moeten worden (ik bedoel hiermee niet dat C++ de enige taal is waarin het kan, maar eerder dat het bij andere talen niet veel anders zal zijn dan bij C++). Zeker voor kernreactor software pas je dingen als unit-testing e.d. toe, en maak je veel gebruik van veel controle voor bijvoorbeeld het accessen van een element in een array (door de array te wrappen in een class, of door std::vector aan te passen oid)

Het is sowieso wat dubbel, want verderop zegt ie weer dat het niet boeit welke taal je kiest. Weer verderop gaat ie verder over C++

"Ik heb twintig Britse banken ondervraagd over hun software-ontwikkeling. Het bleek dat ze stuk voor stuk in C++ gaan ontwikkelen. Gevraagd naar de reden voor de overstap gaf men als belangrijkste motivatie dat het de wens was van de ontwikkelaars. Ervaring in C++ stond goed op hun c.v.." Volgens Hatton is C++ een taal die niemand meer doorgrondt. "De commissie die zich bezighoudt met de standaard kwam enkele weken geleden bijeen in Londen en ik verzeker u, niemand van die mensen weet meer hoe de taal exact werk. De specificaties zijn inmiddels aangegroeid tot een stapel papier van tien centimeter hoog. Het is volgens mij veel belangrijker om vloeiend een bepaalde taal te beheersen, dan steeds weer nieuwe talen aan te leren. Vergeet niet: goede ingenieurs zijn conservatief."

Dude, wat wil je nou, zijn fouten nou wél afhankelijk van de taal of niet

[ Voor 45% gewijzigd door .oisyn op 15-09-2004 15:35 ]

[Verwijderd]

Bij het opdelen van een systeem in een groot aantal kleine componenten zal het hergebruik van code binnen een applicatie toenemen. Men gaat dan uit van de veronderstelling dat bij meer hergebruik het aantal fouten afneemt. Mis. Het tegenovergestelde effect kan worden bereikt, omdat in de kleine componenten juist meer fouten voorkomen.

Dus als je bepaalde functionaliteit meerdere malen gebruikt, mag je daar geen functies o.i.d. van maken omdat daar foutjes in kunnen zitten die bij iedere functieaanroep tot bugs kunnen leiden? Goed, wat mij betreft paste je dezelfde code 100 keer in main(), maar ga niet zeuren als er dan 'n foutje in zat en je mag alles met de hand aanpassen

[EfBe]

Ironie: het artikel in firefox bekijken levert fouten op in de plaatjes van de site. Kennelijk vonden ze het niet zo nodig de site te TESTEN.

[Kevinp]

Verwijderd schreef op 15 september 2004 @ 15:32:
[...]


Dus als je bepaalde functionaliteit meerdere malen gebruikt, mag je daar geen functies o.i.d. van maken omdat daar foutjes in kunnen zitten die bij iedere functieaanroep tot bugs kunnen leiden? Goed, wat mij betreft paste je dezelfde code 100 keer in main(), maar ga niet zeuren als er dan 'n foutje in zat en je mag alles met de hand aanpassen

Lijkt me ook raar, de functie kan natuurlijk ook gewoon goed zijn, ga ik vanuit als je iets gaat gebruiken voor 100 keer in je programma. En dan is er geen probleem

[Verwijderd]

Jah, ik vind 't ook een vrij loos en slecht onderbouwd artikel.

Dit is er eentje om uit te printen en dan in de prullenmand te gooien (of beter, de papierversnipperaar).

Maar wat wil je, hij is "consultant" enzo, en dan moet je met dat soort uitspraken komen...

[PowerSp00n]

EfBe schreef op 15 september 2004 @ 15:36:
Ironie: het artikel in firefox bekijken levert fouten op in de plaatjes van de site. Kennelijk vonden ze het niet zo nodig de site te TESTEN.

Hier geen problemen hoor...

[jan-marten]

Beetje raar bericht wel. Die meneer gaat Windows 95 met Linux vergelijken. Dat is als appels met peren vergelijken.

Ik moet wel toegeven dat code-safe programmeren moet leren. Toen ik het volgende stukje las van PHPFreakz moest ik me ook een paar keer achter het oor krabben hoe je een pagina kunt hacken.
Zoiets zal ook wel voor talen als C, C++, VB en java gelden neem ik dan aan.

[Grijze Vos]

Vreemd artikel. In 2004 testen we Windows 95, en Mac OS (welke precies?), en waarmee wordt het vergeleken? Nergens mee. Slechte journalistiek.

Linux een freeware Unix-variant noemen? Praat dan op zn minst over een bepaalde distro, 'linux' an sich zegt geen fluit.

OO 'het nieuwe ding'? Nou, op de universiteit zijn we voornamelijk gefocused op Component-based ontwikkelen. Dat gaat net weer een stap verder. (als ik zo de rest van het artikel lees hoop ik toch dat de schrijver, en de geinterviewde niet die twee dingen voor hetzelfde aanzien.)

Uit de studie bleek bovendien dat de kosten voor onderhoud, zoals het verwijderen van fouten, nadat de software is opgeleverd (gewoonlijk goed voor 40 procent van de softwarekosten in de totale levenscyclus) voor het in C++ geschreven systeem bijna 300 procent hoger lagen dan voor het systeem geschreven in C. Andere studies bevestigen dit beeld.

Dat lijkt me onzin, goed gedocumenteerde afgeschermde componenten en classes zijn veel makkelijker te onderhouden. Feit is wel dat 90% van de mensen in de industrie die zooi gewoon niet fatsoenlijk in elkaar kunnen zetten. Kan ermee te maken hebben dat het merendeel van die 90% geen informatica opleiding (maar wiskunde of electro) heeft gevolgd, hopeloos achterligt op de huidige gang van zaken, en alle know-how zelf fout heeft aangeleerd.

Onder programmeurs heerst een hardnekkig bijgeloof dat het opdelen van een systeem in een groot aantal uiterst kleine componenten de beste softwaresystemen oplevert. Een reeks studies wijst uit dat dit volstrekt onjuist is. De onderzoeken werden uitgevoerd bij talen als Ada, C, C++, Pascal, Fortran 77 en zelfs diverse assemblers.

Ik quote de Fortran webpage:

While Fortran 90 is not a full object-oriented language it can directly support many of the important concepts of such languages including abstract data types, encapsulation, function overloading, and classes. Other concepts, such as inheritance and dynamic dispatching, are not supported directly, but can be emulated.

Hoe wil je component-based werken als je niet eens fatsoenlijke inheritance kan implementeren.

Component-based programmeren in assemblers onderzoeken? Knappe jongen als je magic-number-time assembly weet te "componententizeren".

Wie bestaande componenten wil gebruiken in een nieuw te ontwikkelen systeem loopt grote risico's. Uit ervaring blijkt dat licht aangepaste, oude softwarecomponenten meer problemen opleveren dan volledig nieuw ontwikkelde componenten. Het hergebruik van bestaande, goedwerkende componenten, is bijvoorbeeld verantwoordelijk voor de desastreuze softwarefout die de lancering van de Ariane 5 liet mislukken. Het probleem was verrassend simpel. De programmeurs namen een getal, beschreven in het 64-bits drijvende-kommaformaat, en lasten dat getal in op een plek waar alleen 16 bits integer-getallen (integer is een geheel getal) ingevuld mochten worden.

Dat is dus een slechte documentatie van die component geweest.

Om even te quoten uit de sheets van Component Based Software Engineering:

"A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only."

Als ze zich daaraan hadden gehouden, dan was het perfect mogelijk geweest om componenten te re-usen. Die programmeurs daar zijn dus gewoon onkundig. (Verder hebben ze zeker nog nooit van typechecking en unit-testing gehoord ofzo.)

Grotendeels grote onzin dus.

(Over dat C++, hij heeft enigszins een punt, maar uiteraard kun je je bij "missioncritical" zaken ook beperken in de mogelijkheden van de taal die je gebruikt.

[ Voor 3% gewijzigd door Grijze Vos op 15-09-2004 15:58 ]

[Verwijderd]

Tja, er staan zoveel spelfouten in het artikel dat je het al bijna niet meer serieus kan nemen.

Maar goed, inhoudelijk.

Hij zegt dat het beter is om nieuwe componenten te ontwikkelen dan oude te hergebruiken. Dit staat weer haaks op het idee om componenten zo vaak mogelijk te testen en er zo fouten uit te halen. Immers een component dat goed functioneerde in een vorige applicatie en waarvan de fouten al zijn op gespoord zal minder fouten bevatten dan een nieuw geschreven component.

Ook zijn de voorbeelden die hij gebruikt achterhaald en hammer op het idee dat sommige mensen van software hebben. Steeds maar Windows 95. Windows 95 is afgeschreven. Hij had beter Windows XP kunnen gebruiken. Dan waren zijn vergelijkingen nog van deze tijd geweest.

Ook zegt hij dat C++ een doom-scenario taal is omdat niemand meer precies weet waar het begint en waar het eindigt. Wie zegt dat je alles wat C++ te bieden heeft moet gebruiken? Het is juist een voordeel, programmeurs kunnen zich specialiseren in het gebied waarmee zij werken, en de andere onderdelen aan andere specialisten overlaten. Hierdoor worden zij in feite gedwongen om niet alles te willen kunnen.

Uit zijn aangehaalde onderzoeken blijkt dat het aantal fouten in n-regels code nauwelijks is afgenomen. Maar programmeurs worden al lang niet meer uit betaald aan de hand van geschreven regels code doordat de complexiteit van software ook groter wordt. Het is toch op z'n allerminst knap als je kunt zeggen dat er steeds meer regels code overal worden toegepast, de complexiteit ervan toeneemt, maar het aantaal fouten niet, het is zelfs licht afgenomen.

Overigens kan iedereen commentaar leveren, de waarde van het artikel neemt nog verder af doordat de schrijver ervan het laat afweten om concreet met suggesties of alternatieven te komen.

[pinockio]

code:

The page cannot be displayed 
There are too many people accessing the Web site at this time.

Slashgotted! Leek me wel interessant om te lezen eigenlijk.

[Grijze Vos]

Grappig om te zien dat Philip en ik ongeveer hetzelfde opschrijven in dezelfde tijd.

[NMe]

Dit artikel moet je niet lezen, maar als pleepapier gebruiken. Zijn stellingen worden onderbouwd met loze onderzoeken (althans, er wordt niet bepaald vaak verteld welk onderzoek of wie dat onderzoek gedaan heeft), en hij spreekt zichzelf continu tegen (zie .oisyn). Als een taal niet uitmaakt, waarom kraak je dan C++ af?
Mijn indruk is dat de geinterviewde een programmeur is van de oude garde, voor wie OOP en component based programmeren te vaag zijn. Hij komt in elk geval erg gefrustreerd over. Ik hoop niet dat veel mensen dit artikel lezen en het voor waar aannemen, want dan zijn de rapen gaar.

[the_stickie]

Er is teveel software of wat? Moeten we dan voor elk aparaat nieuwe chips gaan ontwikkelen? Daar gaan zeker geen fouten inzitten

[RwD]

Hmm, het stomme is dat ik altijd gedacht heb dat de programmeur de fouten maakt en niet de programmeertaal.

Als je een goede programmeur (waarschijnlijk met opleiding, met ervaring) naast een willekeurige andere programmeur zet lijkt het mij dat het percentage fouten van de tweede ook hoger zullen liggen. Ongerelateerd aan de programmeertaal.

Wel gerelateerd aan de programmeertaal is welke fouten gemaakt kunnen worden. Ik kan me voorstellen dat je in Delphi andere fouten kunt maken dan in <vul zelf maar in>...

Gek dat niemand dit nog gezegd heeft

[Verwijderd]

Sowieso vind ik het bullshit dat je een systeem moet opdelen met als doel het zo klein mogelijk maken van de componentjes. Het systeem moet gewoon logisch opgedeeld zijn. DaarNA kun jij bijvoorbeeld door naar het aantal regels in een functie/procedure/methode kijken of het waarschijnlijk is dat deze opdeling goed is gemaakt. Zo zijn er stemmen binnen software engineering die zeggen dat een methode met meer dan 20 regels waarschijnlijk beter opgesplitst had kunnen worden (uitzonderingen daargelaten natuurlijk), maar dan waarschijnlijk meer om onderhoudbaarheid te behouden.

[hier stond geblaat]

[ Voor 24% gewijzigd door Verwijderd op 15-09-2004 16:28 ]

[riezebosch]

Joooo, heerlijk reacties Wat hij ook vergeet is dat ie aan de ene kant Linux aanprijst voor z'n weinige crashes, maar aan de andere kant vergeet dat Linux totaal (toch?) in C/C++ is geprogrammeerd

Daarom zei ik ook: doe er je voordeel mee. Misschien ga je wat bewuster programmeren

Wat me trouwens ook opviel is dat er staat dat er recent van zijn hand het boek Safer C verscheen... Als ik op amazon.com kijk zie ik dat het boek al in 1995 uitgekomen is

[ Voor 25% gewijzigd door riezebosch op 15-09-2004 16:32 ]

[NMe]

riezebosch schreef op 15 september 2004 @ 16:26:
Joooo, heerlijk reacties Wat hij ook vergeet is dat ie aan de ene kant Linux aanprijst voor z'n weinige crashes, maar aan de andere kant vergeet dat Linux totaal (toch?) in C/C++ is geprogrammeerd

offtopic:
Voornamelijk, niet geheel. Volgens mij kun je moeilijk een kernel schrijven zonder assembly.

[Soultaker]

riezebosch schreef op 15 september 2004 @ 16:26:
Joooo, heerlijk reacties Wat hij ook vergeet is dat ie aan de ene kant Linux aanprijst voor z'n weinige crashes, maar aan de andere kant vergeet dat Linux totaal (toch?) in C/C++ is geprogrammeerd

Alle gangbare besturingssystemen zijn geschreven in C (UNIX, Linux, Windows, ongetwijfeld Mac OS-X, hoewel daar wel wat Objective-C tussen zou kunnen zitten).

C is wel een stuk eenvoudigere taal dan C++. Toch is goede code schrijven in C++ naar mijn mening makkelijker dan C, juist omdat C++ heel veel mogelijkheden biedt om praktische problemen met een taalconstructie op te lossen. In C moet je het in dat soort situaties van conventies en 'best practices' hebben en dat geeft naar mijn idee een grotere kans op fouten, omdat de programmeur die zelf consistent moet toepassen.

Ik zal het artikel eens doorlezen; ik ben benieuwd of C er beter vanaf komt dan C++. Als zowel C en C++ er als slechte talen uitkomen, dan denk ik dat de auteur gewoon nog nooit aan een zinnig project gewerkt heeft. Beide talen zijn ontzettend praktisch en hoewel ze allebei verre van perfect zijn, zijn ze in heel veel situaties de meest geschikte optie die voorhanden is.

[Verwijderd]

RwD schreef op 15 september 2004 @ 16:22:
Hmm, het stomme is dat ik altijd gedacht heb dat de programmeur de fouten maakt en niet de programmeertaal.

Als je een goede programmeur (waarschijnlijk met opleiding, met ervaring) naast een willekeurige andere programmeur zet lijkt het mij dat het percentage fouten van de tweede ook hoger zullen liggen. Ongerelateerd aan de programmeertaal.

Wel gerelateerd aan de programmeertaal is welke fouten gemaakt kunnen worden. Ik kan me voorstellen dat je in Delphi andere fouten kunt maken dan in <vul zelf maar in>...

Gek dat niemand dit nog gezegd heeft

Ben het met je eens. Fouten in kritieke systemen voorkom je trouwens ook niet door een of andere superprogrammeertaal te kiezen maar door het hele systeem met formele methoden de specificeren en analyseren en dan n.a.v. die specificatie te programmeren, in wat voor taal dan ook. Ben er zelf geen aanhanger van ( kutwerk ) maar heb tijdens de colleges wel degelijk opgepikt dat het nuttig en zelfs essentieel kan zijn

[ Voor 4% gewijzigd door Verwijderd op 15-09-2004 16:34 ]

[unclero]

riezebosch schreef op 15 september 2004 @ 16:26:
Joooo, heerlijk reacties Wat hij ook vergeet is dat ie aan de ene kant Linux aanprijst voor z'n weinige crashes, maar aan de andere kant vergeet dat Linux totaal (toch?) in C/C++ is geprogrammeerd

C ja... geen C++ .

[Flydude]

Als je de link naar het originele artikel in de Computable volgt kom je bij een artikel uit 1997.

Als het hele verhaal überhaupt wat aantoont is het vooral dat testen.nl ernstig verouderde artikelen plaatst.

Of dat de TS een oud artikel als nieuw presenteert, dat kan natuurlijk ook.

[Sybr_E-N]

Ben ik nou zo gek of eeehh

En heel recent voorbeeld zijn de huidige problemen bij het Russische ruimtestation Mir.

Datum van bericht is "04 August 2004"

Totver ik weet is die Mir allang verdwenen en zweeft er een ISS in de ruimte.

Ik zie nergens enige bronvermelding naar al die grote onderzoeken, dit 'artikel' komt bij mij over als een 'uit de grote duim gezogen '-verhaal.

[Arx]

Kernel is in C geschreven en niet in C++.

Ik ben het met de schrijver eens dat je echte mission critical software niet in C++ moet maken en dat komt door dezelfde reden waarom de kernel niet in C++ is geschreven: het is niet meer te voorspellen welk gedrag het vertoond in het geheugen wat bij C nog wel mogelijk is. Dit komt door de verhoogde complexiteit van C++. En als het niet meer te voorspellen is, is garantie geven ook onmogelijk.

Voor de rest is het een vrij slecht artikel.

Overigens: De ontploffing van de Arriane rakket is veroorzaakt door verkeerde baan berekeningen van de rakket. Toen dit niet meer te corrigeren was heeft de rakket zichzelf opgeblazen.

[RwD]

Ik had ook sterk de indruk bij alles wat ik las dat het een oud artikel was, vooral de weigering om modernere OS-en te noemen...

[Not Pingu]

Hatton: "Als je voor Linux schrijft ben je verplicht je broncode openbaar te maken. Iedereen kan dus inspecteren wat je doet. Daarom is het voor een Linux-ontwikkelaar (die daar overigens niets voor ontvangt, Linux is freeware, AM) zijn eer te na om fouten af te leveren. De broncode wordt vooraf nauwlettend geïnspecteerd door anderen.

Correct me if I'm wrong, maar je kunt ook gewoon closed source en commerciele software schrijven voor Linux. Dit is dus totale onzin.
En de rest van het artikel imho ook.

[ Voor 6% gewijzigd door Not Pingu op 15-09-2004 16:42 ]

[Soultaker]

Arx schreef op 15 september 2004 @ 16:36:
Ik ben het met de schrijver eens dat je echte mission critical software niet in C++ moet maken en dat komt door dezelfde reden waarom de kernel niet in C++ is geschreven: het is niet meer te voorspellen welk gedrag het vertoond in het geheugen wat bij C nog wel mogelijk is. Dit komt door de verhoogde complexiteit van C++. En als het niet meer te voorspellen is, is garantie geven ook onmogelijk.

Dat is echt onzin. Je kunt in C net zo min garanties geven over de eigenschappen van allocators als in C++. Ik denk dat de voornaamste reden om een kernel in C te schrijven is om zo compatible mogelijk te zijn.

De minimale overhead van C is natuurlijk ook fijn; C++ is op zichzelf nauwelijks minder efficiënt dan C, maar het stimuleert het gebruik van paradigma's die minder efficiënte code op kunnen leveren.

[Janoz]

Arx schreef op 15 september 2004 @ 16:36:
Overigens: De ontploffing van de Arriane rakket is veroorzaakt door verkeerde baan berekeningen van de rakket. Toen dit niet meer te corrigeren was heeft de rakket zichzelf opgeblazen.

offtopic:
Het ontploffen van de eerste Arriane 5 (Wat al vele jaren terug is trouwens) had wel degelijk te maken met onjuiste software. De Arriane 5 raket versnelde sneller dan de Arriane 4. Bij de 4 paste deze versnellings waarde nog wel in 16 bit, maar bij de Ariane 5 niet meer. Doordat de stuurcomputer hierdoor erg vreemde waardes binnen kreeg is hij er maar mee opgehouden. Hetzelfde ging op voor het backup systeem wat zich ook maar uitschakelde. Maar dan nog ligt jou verklaring dichter bij de (bij mij bekende) werkelijkheid dan die van de geinterviewde .

[sig69]

Om zijn stelling te bewijzen dat software steeds slechter wordt, heeft Les Hatton over een periode van meerdere jaren bijgehouden hoe vaak hij fouten tegenkwam op zijn diverse computersystemen. Telkens als een computer vastliep, legde hij dat vast.

Ik zal eens aan mijn baas voorleggen om software zo te testen.. Wat is dit nou voor manier van testen? Als ik een windows 95 bak installeer en in de hoek zet, en een andere installeer en helemaal volprop met diverse meuk en troep dan heb ik die echt wel eerder vast dan die 95 bak. Wat een onzin artikel...

Edit: wat ik dus bedoel te zeggen is dat als je een beetje verstandig met je pc'tje omgaat dat ding gewoon draait als een trein en vastlopen nergens voor nodig is.

[ Voor 13% gewijzigd door sig69 op 15-09-2004 16:58 ]

[Grijze Vos]

Arx schreef op 15 september 2004 @ 16:36:
Kernel is in C geschreven en niet in C++.

Ik ben het met de schrijver eens dat je echte mission critical software niet in C++ moet maken en dat komt door dezelfde reden waarom de kernel niet in C++ is geschreven: het is niet meer te voorspellen welk gedrag het vertoond in het geheugen wat bij C nog wel mogelijk is. Dit komt door de verhoogde complexiteit van C++. En als het niet meer te voorspellen is, is garantie geven ook onmogelijk.

Als jij van een gegeven C++ compiler de correctheid van bepaalde instructies hebt bewezen is er niks mis mee om die dingen te gebruiken als code hoor.

Even goed wil je in een space shuttle ook liever een 486 gebruiken dan een P4 met hyperthreading en de hele meuk, omdat het voor die laatste veel moeilijker is om de correctheid aan te tonen. En tja, als je speelt met miljarden aan investeringen, wil je meestal je correctheid toch wel bewezen zien.

[Arx]

Grijze Vos schreef op 15 september 2004 @ 17:06:
[...]

Als jij van een gegeven C++ compiler de correctheid van bepaalde instructies hebt bewezen is er niks mis mee om die dingen te gebruiken als code hoor.

Even goed wil je in een space shuttle ook liever een 486 gebruiken dan een P4 met hyperthreading en de hele meuk, omdat het voor die laatste veel moeilijker is om de correctheid aan te tonen. En tja, als je speelt met miljarden aan investeringen, wil je meestal je correctheid toch wel bewezen zien.

Het gaat ook niet over de correctheid van de functies maar meer over de allocatie van geheugen. C++ laat simpel weg veel meer toe en doet dat "achter je rug" om, terwijl in C dit veel stricter is waardoor het voorspelbaar is.

@SoulTaker:
Je kunt trouwens wel degelijk voorspellen wat je uitkomst is van je C programma in het geheugen, met C++ echt niet.

@Janoz:
Je hebt gelijk maar ik schreef het even heel simpel op. Arriane vernietigde zichzelf. Je zou er niet aan moeten denken als hij naar beneden heel komt.

[Zoijar]

Arx schreef op 15 september 2004 @ 19:49:
Het gaat ook niet over de correctheid van de functies maar meer over de allocatie van geheugen. C++ laat simpel weg veel meer toe en doet dat "achter je rug" om, terwijl in C dit veel stricter is waardoor het voorspelbaar is.

@SoulTaker:
Je kunt trouwens wel degelijk voorspellen wat je uitkomst is van je C programma in het geheugen, met C++ echt niet.

Geef eens een voorbeeld dan? Je wilt toch niet zeggen dat geheugen beheer in C ook duidelijker is heh? Want dat is in vergelijk met goed C++ een drama. Verder, wat gebeurt er dan achter je rug om? Alleen dtor calls, maar dat weet je. Ik heb liever een programma in C++ met een stack guard object, zodat je heap object ook na een exception goed vrijgegeven wordt bv. Dan iets in C met ruwe pointers, en signals erdoorheen enzo.

Op het artikel, ik snap niet dat C++ altijd zo afgekraakt moet worden. Dat komt alleen maar omdat sommige mensen de taal niet helemaal begrijpen. Zij willen dan graag dat niemand het begrijpt. Maar dat is helemaal niet zo, de meeste goede programmeurs begrijpen de taal heel degelijk. Het is weer dom napraten van het feit dat sommige zeggen dat bijna niemand alle ins en outs kent. Maar die hoef je in principe helemaal niet te weten, als je het toch niet gebruikt.

[HunterPro]

wat een on-ge-lo-fe-lijk slecht geschreven artikel zeg. Rare vertalingen, aparte zinsnedes en tegensprekingen van eerder gegeven informatie die als feit werd aangemerkt.

[Arx]

Zoijar schreef op 15 september 2004 @ 20:08:
[...]

Geef eens een voorbeeld dan? Je wilt toch niet zeggen dat geheugen beheer in C ook duidelijker is heh? Want dat is in vergelijk met goed C++ een drama. Verder, wat gebeurt er dan achter je rug om? Alleen dtor calls, maar dat weet je. Ik heb liever een programma in C++ met een stack guard object, zodat je heap object ook na een exception goed vrijgegeven wordt bv. Dan iets in C met ruwe pointers, en signals erdoorheen enzo.

...

Hahaha, het is geen Java hoor met je stackguard!! Met C++ heb je nog steeds last van memory leaks als je verzuimd je net gemaakte struct / class te vernietigen. Schijnbaar heb je van C geen kaas gegeten want het is inderdaad duidelijker mede door de strictheid van c die bij c++ ontbreekt. Wat zijn ruwe pointers???

Anyway, toch denk ik dat c++ niet goed voor mission critical situaties is.

[ Voor 5% gewijzigd door Arx op 15-09-2004 20:41 ]

[Verwijderd]

OMG
http://www.testen.nl/article_read.asp

code:

Microsoft JET Database Engine error '80040e14'

Syntax error (missing operator) in query expression 'ARTICLE_ID ='.

/article_read.asp, line 59

Over fouten gesproken

[Verwijderd]

Gewoon idnummer bijzetten en foutje weg.

De maker heeft dat fout niet gemaakt, maar hij heeft echter geen doorlinking ingezet als je geen idnummer achterzet.

Trouwens, Global (hoe heet ie ook alweer)op enabled zetten is onveilig, wist je dat?

[Verwijderd]

Verwijderd schreef op 15 september 2004 @ 20:50:
Gewoon idnummer bijzetten en foutje weg.

De maker heeft dat fout niet gemaakt, maar hij heeft echter geen doorlinking ingezet als je geen idnummer achterzet.

Trouwens, Global (hoe heet ie ook alweer)op enabled zetten is onveilig, wist je dat?

Het is toch fout dat het niet afgevangen wordt, dat is mijn punt. De oplossing is echter simpel.

[Verwijderd]

Verwijderd schreef op 15 september 2004 @ 20:52:
Het is toch fout dat het niet afgevangen wordt, dat is mijn punt. De oplossing is echter simpel.

Fout is een groot woord. Ik vind een 404 ook niet mooi om te zien maar dat is ook niet fout. Als de eigenaar van de site vindt dat het genoeg is dat correcte (en op de site zelf staande) links een correcte pagina op leveren dan is het goed...

* fladder is het er wel mee eens dat het onprofessioneel staat

[ Voor 7% gewijzigd door Verwijderd op 15-09-2004 20:56 ]

[Creepy]

Arx schreef op 15 september 2004 @ 20:40:
[...]


Hahaha, het is geen Java hoor met je stackguard!! Met C++ heb je nog steeds last van memory leaks als je verzuimd je net gemaakte struct / class te vernietigen. Schijnbaar heb je van C geen kaas gegeten want het is inderdaad duidelijker mede door de strictheid van c die bij c++ ontbreekt. Wat zijn ruwe pointers???

Anyway, toch denk ik dat c++ niet goed voor mission critical situaties is.

Zie ook http://www.google.nl/sear...2B&btnG=Google+zoeken&lr=


En vertel je me nu dat je C qua geheugenbeheer makkelijker vindt? Gegoogel met *chars e.d. t.o.v. van een std::string is makkelijker? De zoveelste implementatie van een linked list (met ruwe pointers) is makkelijker dan een std::list o.i.d.?
Voor de programmeur is geheugenbeheer in C++ er mijn inziens beter op geworden.

[Zoijar]

Arx schreef op 15 september 2004 @ 20:40:
Hahaha, het is geen Java hoor met je stackguard!! Met C++ heb je nog steeds last van memory leaks als je verzuimd je net gemaakte struct / class te vernietigen. Schijnbaar heb je van C geen kaas gegeten want het is inderdaad duidelijker mede door de strictheid van c die bij c++ ontbreekt. Wat zijn ruwe pointers???

Anyway, toch denk ik dat c++ niet goed voor mission critical situaties is.

Uhhhm Ik ben met stomheid geslagen, wat ik hier nou weer op moet zeggen Mensen als jij schrijven dus juist dit soort artikelen Eerst even beweren dat ik zeker geen gelijk kan hebben, om vervolgens even te vragen waar ik het eigenlijk over heb, hehe

Dit bedoelde ik dus:

C++:

class MyClass {
// stuff...
   void doStuff() {
      throw std::logic_error("you're foobar! method not supported.")
  }
};

void foo() {
   typedef std::auto_ptr<MyClass> MyClassPtr;
   MyClassPtr obj(new MyClass(...));

   // obj will be correctly freed after the exception resolves and it goes out of scope   
   obj->doStuff();

  // obj is destroyed/freed here when it goes out of scope
}

In C gaat dat je een stuk meer moeite kosten.
(Maar laten we hier anders niet te ver op doorgaan; daar ging de discussie niet over, specifieke gevallen)

[ Voor 31% gewijzigd door Zoijar op 15-09-2004 21:45 ]

[alienfruit]

Overigens hebben de makers van compilers liever niet dat je de compiler gebruikt voor kerncentrale software

Licensie van Borland C++

13.2 Hazardous Uses. The Product is not intended for use in connection with any application requiring fail-safe performance such as the operation of nuclear power facilities, air traffic control or navigation systems, weapons control systems, life support systems, or any other system whose failure could lead to injury, death, environmental damage or mass destruction. You agree that Borland will have no liability of any nature, and you are solely responsible, for any expense, loss, injury or damage incurred as a result of such use of the Product.

[riezebosch]

Haha, die vind ik écht sterk!

[we_are_borg]

Grijze Vos schreef op 15 september 2004 @ 17:06:
[...]

Als jij van een gegeven C++ compiler de correctheid van bepaalde instructies hebt bewezen is er niks mis mee om die dingen te gebruiken als code hoor.

Even goed wil je in een space shuttle ook liever een 486 gebruiken dan een P4 met hyperthreading en de hele meuk, omdat het voor die laatste veel moeilijker is om de correctheid aan te tonen. En tja, als je speelt met miljarden aan investeringen, wil je meestal je correctheid toch wel bewezen zien.

Heb toen een article gelezen in een Amiga magazine dat de shuttle op 386 computers draait en dat er maar een handvol mensen waren die software en instructies mochten schrijven. Dit werd gedaan om fouten te voorkomen in de software. Ik weet niet of dit nog is of dat er nu veel meer mensen software en instructies schrijven voor de Shuttle. Ook stond in de magazine dat mensen die in aanmerking kwamen eerst een interne opleiding krijgen hoe alles werkte in de shuttle.

[.oisyn]

Arx schreef op 15 september 2004 @ 20:40:
[...]


Hahaha, het is geen Java hoor met je stackguard!! Met C++ heb je nog steeds last van memory leaks als je verzuimd je net gemaakte struct / class te vernietigen. Schijnbaar heb je van C geen kaas gegeten want het is inderdaad duidelijker mede door de strictheid van c die bij c++ ontbreekt. Wat zijn ruwe pointers???

Anyway, toch denk ik dat c++ niet goed voor mission critical situaties is.

Zeg dude, kijk voortaan eerst eens naar iemand's post history voordat je begint te blaten dat iemand er geen verstand van heeft. Juist bij mensen die je niet kent moet je dat niet zeggen, want zoals je zelf alweer hebt aangetoond kun je er vaak niet verder vanaf zitten. Ik ga maar verder niet inhoudelijk op je post in, heeft toch weinig nut als je denkt dat de mensen hier er geen verstand van hebben, terwijl ze dat overduidelijk wel hebben. Een discussie van niveau lijkt me met jou dan ook niet mogelijk

Hier nog een leuke quote voor je:

"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind"

[ Voor 12% gewijzigd door .oisyn op 16-09-2004 00:27 ]

[.oisyn]

alienfruit schreef op 15 september 2004 @ 22:34:
Overigens hebben de makers van compilers liever niet dat je de compiler gebruikt voor kerncentrale software

Nou ja het is niet dat ze het liever niet willen, het is meer dat ze niet in willen staan voor de risico's die het met zich mee brengt (want er kan natuurlijk altijd een bugje in de compiler zitten die net in die software boven water komt, en dan hang je als mensen moeilijk gaan doen. Misschien niet zozeer rechtmatig, maar je reputatie raakt wel beschadigd)

[curry684]

Arx schreef op 15 september 2004 @ 20:40:
[...]

Hahaha, het is geen Java hoor met je stackguard!! Met C++ heb je nog steeds last van memory leaks als je verzuimd je net gemaakte struct / class te vernietigen.

Daarom gebruikt een goede C++ developer alleen stack-based classes of smart pointers. Pointer-based development is C-style development, dat heeft juist weinig van doen met C++. Een op-en-top C++ programma zie je letterlijk geen sterretje in terug.

Schijnbaar heb je van C geen kaas gegeten want het is inderdaad duidelijker mede door de strictheid van c die bij c++ ontbreekt.

C++ is strikt, C niet. De keywords hierbij zijn 'type safety' en in mindere mate 'exceptions', 'constructors' en 'destructors'.

Wat zijn ruwe pointers???

Tja

Anyway, toch denk ik dat c++ niet goed voor mission critical situaties is.

Ik zal het m'n contacts bij TSMC doorgeven die al 10 jaar lang op dezelfde C++ software draaien voor hun 24/7 fabrieksautomatisering, zonder ook maar 1 minuut unplanned downtime. Andere collega van me ontwikkelt trouwens de C++ frameworks waar Philips Medical Systems al z'n medische apparatuur zoals MRI-scanners mee aanstuurt, ik zal het hem ook even melden.

[Soultaker]

curry684 schreef op 16 september 2004 @ 00:46:
C++ is strikt, C niet. De keywords hierbij zijn 'type safety' en in mindere mate 'exceptions', 'constructors' en 'destructors'.

Nah, C++ is niet fundamenteel 'stricter' dan C, naar mijn idee. Er zijn een aantal restricties toegevoegd (wat strengere conversies enzo) maar in het algemeen is C++ gewoon backward compatible.

[curry684]

Soultaker schreef op 16 september 2004 @ 01:23:
[...]

Nah, C++ is niet fundamenteel 'stricter' dan C, naar mijn idee. Er zijn een aantal restricties toegevoegd (wat strengere conversies enzo) maar in het algemeen is C++ gewoon backward compatible.

Euj?

C++:

MyStruct* Pietje = malloc(sizeof(MyStruct));

Het feit dat dit in C++ niet mag en in C wel lijkt me toch wel een aardig stukje 'fundamenteel strikter'

[Anders]

Hoe komt het dan dat een besturingssysteem als Linux van een zo uitzonderlijke kwaliteit is? Hatton: "Als je voor Linux schrijft ben je verplicht je broncode openbaar te maken. Iedereen kan dus inspecteren wat je doet. Daarom is het voor een Linux-ontwikkelaar (die daar overigens niets voor ontvangt, Linux is freeware, AM) zijn eer te na om fouten af te leveren. De broncode wordt vooraf nauwlettend geïnspecteerd door anderen.

Dat lijkt me een vrij zwak argument. Veel sterker is het argument dat bij Microsoft en consorten op alles een strakke deadline zit i.vm. de gehele corporate bedrijfsvoering (marketing, concurrentie, wachtende afnemers etc etc). Het moet nou eenmaal af zijn op dag x, met stress en fouten als gevolg. De Open Source community kent die druk niet of nauwelijks en dat scheelt enorm.

Dat hele aspect van tijd en deadlines wordt door de heer Mulder in het geheel niet beschreven, waardoor een artikel over fouten in software en hoe ze te voorkomen al nauwelijks serieus te nemen is.

[alienfruit]

Nou ja het is niet dat ze het liever niet willen, het is meer dat ze niet in willen staan voor de risico's die het met zich mee brengt (want er kan natuurlijk altijd een bugje in de compiler zitten die net in die software boven water komt, en dan hang je als mensen moeilijk gaan doen. Misschien niet zozeer rechtmatig, maar je reputatie raakt wel beschadigd)

Ja, dat snap ik ook wel, maar toch Overigens dit natuurlijk bij alle software hetzelfde . Ik denk dat het schrijven van software van dingen als kerncentrales toch iets zwaarder is dan wat de meeste mensen hier doen. Vooral gezien de mogelijke gevolgen fouten in de software hebben, lijkt mij dat het een langdurig proces is van testen etc.

[EfBe]

curry684 schreef op 16 september 2004 @ 01:30:
[...]

Euj?

C++:

MyStruct* Pietje = malloc(sizeof(MyStruct));

Het feit dat dit in C++ niet mag en in C wel lijkt me toch wel een aardig stukje 'fundamenteel strikter'

VC++ vreet dit gewoon hoor.

(oh wacht, je moet natuurlijk casten)...

[ Voor 9% gewijzigd door EfBe op 16-09-2004 09:54 ]

[Verwijderd]

curry684 schreef op 16 september 2004 @ 00:46:

Daarom gebruikt een goede C++ developer alleen stack-based classes of smart pointers.

Een probleem met alles op de stack alloceren is dat de stack (natuurlijk) veel kleiner is dan de heap. Sommige C++ compilers hebben een switch om de stack size te verhogen, maar het is niet gegarandeerd dat een compiler dat kan, of dat een gegeven compiler het op alle platformen kan.

Typische gevallen waar je een stack overflow kunt verwachtten zijn met name het alloceren van grote arrays op de stack. Dit wordt nog eens extra versterkt als de elementen van zo'n array classes zijn met veel in-line gealloceerde data members.

Zoals curry al zegt, heb je ook nog smart pointers. Deze kunnen een variable stack semantics geven terwijl ie toch heap gealloceerd is.

[Zoijar]

EfBe schreef op 16 september 2004 @ 09:53:
(oh wacht, je moet natuurlijk casten)...

En daar is C++ ook iets stricter in geworden, je moet specifiek opgeven wat voor cast het is: static_cast(), reinterpret_cast(), const_cast() etc.

[EfBe]

Verwijderd schreef op 16 september 2004 @ 09:55:
Een probleem met alles op de stack alloceren is dat de stack (natuurlijk) veel kleiner is dan de heap. Sommige C++ compilers hebben een switch om de stack size te verhogen, maar het is niet gegarandeerd dat een compiler dat kan, of dat een gegeven compiler het op alle platformen kan.

Typische gevallen waar je een stack overflow kunt verwachtten zijn met name het alloceren van grote arrays op de stack. Dit wordt nog eens extra versterkt als de elementen van zo'n array classes zijn met veel in-line gealloceerde data members.

Zoals curry al zegt, heb je ook nog smart pointers. Deze kunnen een variable stack semantics geven terwijl ie toch heap gealloceerd is.

Dit lezende moet ik wel concluderen dat wanneer je opties op moet geven voor goed verloop van de execute van de code, je deze dus ook kunt vergeten en het dus niet goed werkt in sommige gevallen(!). Ik begrijp dat sommige mensen het lekker vinden op een laag niveau met de plek van waar iets gealloceerd wordt bezig te zijn, maar ikzelf zie het meer als hinderlijk geneuzel dan practisch nut: allocatie op de stack, heap, main mem.... is dat niet de taak voor de API / compiler die je gebruikt? Je houdt je toch ook niet bezig met byte alignment in een struct (oja, sommigen wel natuurlijk) of wel dan?

[Verwijderd]

Grappige is toch wel dat bedrijven met echt grote software niet proberen alle fouten uit hun code te verwijderen. Die gaan uit van uit dat code per definitie tussen de 3 en de 7 fouten per 1000 regels code bevat. En daarvan uitgaande hebben ze veelal twee aanpakken: error detection & recovery enerzijds en proberen de hoeveelheid code te reduceren anderszijds.

Uiteraard gaat dit niet op voor echte kritische systemen, maar wel interessant om even in je achterhoofd te houde: code bevat nou eenmaal fouten en misschien is het wel interessanter om na te gaan hoe je met fouten omgaat dan (hopeloos) te proberen de fouten eruit te krijgen.

[Soultaker]

curry684 schreef op 16 september 2004 @ 01:30:
Euj?

C++:

MyStruct* Pietje = malloc(sizeof(MyStruct));

Het feit dat dit in C++ niet mag en in C wel lijkt me toch wel een aardig stukje 'fundamenteel strikter'

Dit zijn precies de punten waar ik aan dacht. Het zal wel aan mijn beleving liggen, maar ik vind dit dus niet zo'n verschil maken in de praktijk. Overigens geven de meeste C compilers hier wel een warning voor, vandaar dat ik dit soort conversies altijd expliciet maak met een cast.

Met 'fundamenteel stricter' zat ik eigenlijk te denken aan trucjes die in C wel werken en in C++ niet meer. Die zijn er bijna niet, of ze zijn zo exotisch dat je ze toch al nooit had moeten gebruiken. Een paar casts toevoegen is eigenlijk wel het meeste wat je moet doen om C code onder een C++ compiler te laten draaien.

Zoijar schreef op 16 september 2004 @ 12:02:
En daar is C++ ook iets stricter in geworden, je moet specifiek opgeven wat voor cast het is: static_cast(), reinterpret_cast(), const_cast() etc.

Die casting operators mag je gebruiken, maar je kan als vastgeroeste C-programmeur ook C-style casts gebruiken zonder die restricties. Dat is naar mijn mening ook de charme van C++; je kunt een stijl toepassen die geschikt is voor de situatie. C++ is inderdaad complex, maar niet zonder goede redenen.

[ Voor 32% gewijzigd door Soultaker op 16-09-2004 12:44 ]

[curry684]

EfBe schreef op 16 september 2004 @ 12:29:
[...]

Ik begrijp dat sommige mensen het lekker vinden op een laag niveau met de plek van waar iets gealloceerd wordt bezig te zijn, maar ikzelf zie het meer als hinderlijk geneuzel dan practisch nut: allocatie op de stack, heap, main mem.... is dat niet de taak voor de API / compiler die je gebruikt?

Nee, de API en de compiler hebben daar an sich niets mee van doen. Door de C++ compiler te gebruiken neem je zelf verantwoordelijkheid voor de diepste krochten van geheugenbeheer, dat mag de compiler je niet eens afnemen als ie enigszins aan de standaarden wil voldoen. Als je geen enkele gedachte aan geheugen wil hoeven spenderen pak je een Java of C# compiler, die zijn ongeveer verplicht je niet aan memory management te laten denken

Oftewel: het gebruiken van C++ is een afweging tussen benodigde kracht en de resulterende complexiteit van de code. Soms is C# of Java een alternatief, soms niet, en de kunst van de goede programmeur is om dat onderscheid correcte te beoordelen.

Je houdt je toch ook niet bezig met byte alignment in een struct (oja, sommigen wel natuurlijk) of wel dan?

Nou heb ik wel een paar cross-platform netwerkapplicaties moeten bouwen, en daarbij was ik toch verdomd blij dat ik dat wel deed

[ Voor 11% gewijzigd door curry684 op 16-09-2004 12:53 ]

[Verwijderd]

Verwijderd schreef op 16 september 2004 @ 12:36:
Uiteraard gaat dit niet op voor echte kritische systemen, maar wel interessant om even in je achterhoofd te houde: code bevat nou eenmaal fouten en misschien is het wel interessanter om na te gaan hoe je met fouten omgaat dan (hopeloos) te proberen de fouten eruit te krijgen.

Ik heb zelf absoluut geen ervaring met mission critical systemen, maar ik heb wel eens gehoord dat in dergelijke omgevingen ze hetzelfde stukje code door verschillende teams laten maken. Alleen de interface staat vast en wordt gecommuniceerd, maar de teams hebben geen enkele comunnicatie onderling kwa implementatie.

Runtime worden de modules van alle teams tegelijk gedraait, met dezelfde input. De output van alle modules wordt met elkaar vergeleken. Als er een module is die een andere output geeft wordt een critical warning gegeven, maar als een meerderheid het over de output eens is gaat het systeem wel door. Overigens is het ook een fout als een module er te lang over doet (dus er komen ook nog eens hard-real time requirements bij). Anders zou het eenvoudig weg blijven hangen van een module het systeem mogelijk alsnog op z'n knieen brengen.

[Verwijderd]

curry684 schreef op 16 september 2004 @ 12:52:
Als je geen enkele gedachte aan geheugen wil hoeven spenderen pak je een Java of C# compiler, die zijn ongeveer verplicht je niet aan memory management te laten denken

Je bedoelt het natuurlijk goed, maar voor alle duidelijkheid: Ook bij GC talen moet je aa memory management denken. In het eenvoudigste geval heb je nog steeds te maken met een eindige hoeveelheid geheugen, dus moet je uberhaupt rekening mee houden dat je niet oneindig alloceert. Dit is eigenlijk triviaal, maar valt toch onder memory management.


_{Bij de Sun Java virtual machine speelt dit overigens extra, omdat deze default een hele lage maximum hoeveelheid memory mogen alloceren. In tegenstelling tot normale systeem processen die net zoveel geheugen mogen alloceren als je virtual memory hebt, mag de sun JVM default maar maximaal 64MB alloceren (in de huidige versies), of je nou 512Mb of 4Gig in je machine hebt. Een simpele -Xmx switch verhelpt dit wel, maar dat kun je niet voorschrijven voor applicaties die anderen maken met jouw classes. M.a.w. practisch gezien heeft Java een 64MB limiet.}


Ten tweede moet je bij GC talen wel erom denken dat je van objecten waar je klaar mee bent geen references meer bewaart. Deze vorm van memory leaking is een sub-classe van de memory leaks die je onder C++ kunt hebben. Het komt minder vaak voor, maar het speelt wel zeer zeker een rol. Gerelateerd hieraan is dat je in scopes met een lange life-time, soms references expliciet op null moet zetten omdat het te lang duurt voor de scope afgelopen is. Objecten staan dan onnodig lang in het geheugen wat alsnog tot memory problemen kan leiden.

Voorts heb je nog een groot aantal tuning mogelijkheden voor de JVM GC, en heb je zelfs een aantal verschillende GC's waar je uit kunt kiezen. Tevens heb je ook voor Java profilers waarmee je heel gedetaileerd je memory kunt monitoren, bijvoorbeeld om memory leaks te vinden (jprofiler, etc).

[MSalters]

Ik mag hopen voor alle mensen in Rotterdam en omgeving dat C++ geschikt is voor safety-critical code - de Maeslant kering in de Nieuwe Waterweg draait op C++.

Het artikel is overigens stokoud; de meeting in Londen was in 1997. Dat is geen compleet excuus: De stelling dat alle talen even goed zijn, omdat ze even veel fouten per 1000 regels veroorzaken, gaat volledig voorbij aan het feit dat je in moderne talen veel minder regels code nodig hebt voor dezelfde functie. Het aantal fouten per eenheid van functionaliteit neemt dus wel degelijk af. De belangrijkste oorzaak daarvoor is een goede set libraries.

[.oisyn]

Verwijderd schreef op 16 september 2004 @ 09:55:
Typische gevallen waar je een stack overflow kunt verwachtten zijn met name het alloceren van grote arrays op de stack. Dit wordt nog eens extra versterkt als de elementen van zo'n array classes zijn met veel in-line gealloceerde data members.

Maar wie doet dat nou? De arrays die ik op de stack alloceer zijn van die kleine temporaries met een paar elementen, bijvoorbeeld omdat WaitForMultipleObjects z'n lijst met handels nou eenmaal in een array verwacht. Dat zijn geen arrays met duizenden elementen, eerder een stuk of 5 ofzo. Daarnaast zijn dit soort arrays niet dynamisch, waardoor je als je dat nodig hebt sowieso al kijkt naar std::vector

[Verwijderd]

.oisyn schreef op 16 september 2004 @ 17:23:
[...]

Maar wie doet dat nou?

Tsja, wie doet dat nou?

* Henk denkt terug aan de keer dat ie het deed en zijn applicatie perfect runde onder linux x86 maar meteen crashte op een solaris sparc bak

Er werd gezegd dat goede C++ programmeurs bijna alleen maar op de stack alloceren of met smartpointers werken. Dat is zeker correct, maar zo zonder meer zou een beginnende mee lezende programmeur het mischien verkeerd opvatten.

[gorgi_19]

Modbreak:

Net een heleboel reacties even getrashed. Deze gingen over de kwaliteit van de site waar het artikel over ging, waar je reacties op die site kon hebben en meer offtopic zaken.

Gaarne weer ontopic over het artikel zelf. Voor degenen die het nog niet wisten; het artikel stamt uit 1997

[ Voor 96% gewijzigd door gorgi_19 op 17-09-2004 16:52 ]

[Grijze Vos]

we_are_borg schreef op 15 september 2004 @ 22:54:
[...]


Heb toen een article gelezen in een Amiga magazine dat de shuttle op 386 computers draait en dat er maar een handvol mensen waren die software en instructies mochten schrijven. Dit werd gedaan om fouten te voorkomen in de software. Ik weet niet of dit nog is of dat er nu veel meer mensen software en instructies schrijven voor de Shuttle. Ook stond in de magazine dat mensen die in aanmerking kwamen eerst een interne opleiding krijgen hoe alles werkte in de shuttle.

Zou best wel eens kunnen kloppen. Iets van 5 jaar geleden draaiden ze nog steeds me t486's, omdat die qua bewijsbaarheid het beste te doen zijn.

Arx schreef op 15 september 2004 @ 19:49:
[...]

Het gaat ook niet over de correctheid van de functies maar meer over de allocatie van geheugen. C++ laat simpel weg veel meer toe en doet dat "achter je rug" om, terwijl in C dit veel stricter is waardoor het voorspelbaar is.

En waarom wordt de allocatie in C++ dan als 'slecht' bestempeld? Juist, omdat het de correctheid niet ten goede komt. Bij missioncritical systemen is het juist functioneren (= correct functioneren) van de software van het hoogste belang.