Lol,
Met alle respect ik ontwikkel veel in XSTL, en XSLT is volledig decleratief. Maar de kern van 'decleratief; is dat je iets vooraf definieerd en dat dat verder door een compiler of interpreter afgedwongen wordt.
Ik heb wel degelijk ervaring met talen die 'zelf' geheugen vrijgeven wanneer het hun uitkomt. Bijna alle scripttalen hebben deze 'voorziening' en ik werk hier ook veel mee. En ik kan ook je vertellen hoe laks mensen hiervan gaan programeren en wat voor bugs hierdoor ontstaan. Gelukkig worden deze talen niet voor zware topassing gebruikt. Maar dit excuus gaan niet op voor java en C#!
Wat betreft GC en exceptions is het zo dat de ontwikkelaar in beide gevallen de details zelf moet afhandelen of kennis van de gebruikte objecten moet hebben wanneer hij dit na wil laten.
Ook dit is een probleem, aangezien men niet kan weten of een object onder water nog wat andere resources dan geheugen gebruikt. Dus of de ontwikkelaar moet alles doen wat een taal in C++ automatisch doet. Of hij moet kennis van de interne implementatie hebben van de objecten waarmee hij werkt.
Heeft een ontwikkelaar geen detail kennis over de implentatie van een object (zoals in OO gebruikenlijk, er zijn slechts interfaces) of als hij niet bij ieder object dat hij gebruikt een close method aanroept (zoals M$ adviseert voor .net) dan loop je het risico op onverklaarbare en onrepoduceerbare fouten.
Voorbeeld is een object dat als bijwerking bestanden lockt (implementatie). Als dit object nog niet is vrijgegeven, maar het object is conceptioneel wel uit de scope, dan zal bij een volgende iteratie in een lus dat weer dit bestand probeerd te locken een deadlock of een error ontstaan. Deze deadlock gaat pas over als the GC het eerste object heeft opgeruimt.
Kortom de programeur moet in de praktijk meer details afhandelen en ook nog eens meer kennis van de interne werking van objecten hebben. Dit laaste is nu net wat OO moet voorkomen, dmv abstactie en interfaces.
OO en GC zijn elkaars vijanden wat betreft imperatief programeren! Wat betreft je argument dat het vreemd is dat dit nu allemaal net in de nieuwste generatie talen gebruikt wordt het volgende.
De talen markt en aanverwante tools wordt zuiver gedreven door commerciele belanngen. Dit geld zowel vor java (sun) als voor .net (M$). Beide verdienen goud aan het uitbrengen van hun eigen talen en de daaraan gekoppelde tools en cursussen, etc.
Is C++ perfect? Nee, helemaal niet, maar wat nu in deze 'nieuwe' talen geintroduceerd is plaats on alleen maar verder van een werkende oplossing en niet dichterbij. Een reden waardoor het soms anders kan lijken is doordat er ondertussen zoveel meer herbuikbare code is. Er zijn bijvoorbeeld mensen die een eigen browser maken en alleen maar een IE BRowser control of een form hebben gesleept. Ik bedoel maar, het is allemaal zo moeilijk in te schatten voor mensen! En dus volgen ze allemaal braaf het pad dat door de grote parijen is uitgezet!
Deze dagen hou ik mij vooral bezig met architectuur en ontwikkel ik allen nog maar gelaagd en dus met verschillende talen tegelijkertijd (DHTML, javascript, vbscript, COM, SQL, maar wel gescheiden gelukkig).
Maar ik kun je vertellen dat wat betreft dat transactie gericht denken en gebruik maken van scoping alle talen een puntje kunnen zuigen aan C++. En dit in combinatie met sober OO gebruik levert in mijn ogen dan ook de meest betroubare code op. Niets verstokt dus, maar ik mis die tijd wel ja. Goed mee in de vaart der volkeren en hopen dan M$ en sun er een niet nog grotere puinhoop van gaan maken. Ik vertik het echter om achter iedere nieuwe mode aan te hollen en alles wat ik met zekerheid weet door dom commercieel gebrabbel to laten overschreewen.
Hoeveel jaar programeer ervaring had je ook al weer? Vast niet meer dan 18
Stefan Esser, of e-matters and the PHP.net project, has also unearthed two flaws within MySQL's client library (a heap buffer overflow bug and another glitch that allows crackers to write '\0' to any memory address) that can result in application compromise. [...] Both flaws could allow DoS [Denial of Service] attacks against or arbitrary code execution within anything linked against libmysqlclient, he warns.
.
. Veel gebruikte software op basis van C# of Java ontbreekt echter nog: het gaat vaak om software waar al jaren en ontwikkeld wordt of waarvan men denkt dat men met C#/Java niet aan de performance eisen kan voldoen. Er wordt daarom nog vaak C/C++ gebruikt en deze talen bieden veel ongure constructies en controleren vrij weinig. Er kunnen hierdoor hele rare zaken gebeuren als je niet goed weet waarmee je bezig bent. Uiteraard een beetje goedkoop om de taal de schuld te geven, maar een taal die meehelpt scheelt in ieder geval een stuk.
.
