[Alg] Slechtste programmeervoorbeelden deel 3

[ValHallASW]

Anoniem: 42901 schreef op donderdag 16 augustus 2007 @ 16:35:
Kom ik net dit tegen...

C++:

if (x)
    if (y)
        if (z)
        {
            // Uiteindelijke code
        }

Dit kan wel degelijk nut hebben als y en z functies zijn die veel tijd kosten. De volgorde van uitvoering bij een and is - in ieder geval bij C/C++ - niet strikt gedefinieerd, waardoor bovenstaande code vele malen sneller kan zijn dan

C++:

if ( x() && y() && z() ) {}

zeker als je compiler bij een dergelijke constructie van rechts naar links werkt en al helemaal als x() en y() vaak false opleveren.

[Woy]

Ik dacht dat de evaluatie volgorde van condities in een if statement gewoon gegarandeerd word in c++. Bij een function call is inderdaad niet gedefineerd in welke volgorde ze uitgevoerd worden waardoor je met het volgende nooit weet welke i waar meegegeven wordt

C++:

myFunc( i, i++ );

[Robtimus]

rwb schreef op vrijdag 31 augustus 2007 @ 08:09:
Ik dacht dat de evaluatie volgorde van condities in een if statement gewoon gegarandeerd word in c++.

Inderdaad, wat is anders het nut van de shortcut (lazy) logical operators?

[.oisyn]

ValHallASW schreef op vrijdag 31 augustus 2007 @ 01:32:
[...]

Dit kan wel degelijk nut hebben als y en z functies zijn die veel tijd kosten. De volgorde van uitvoering bij een and is - in ieder geval bij C/C++ - niet strikt gedefinieerd, waardoor bovenstaande code vele malen sneller kan zijn dan

Sorry, maar totale onzin. && en || doen aan short-circuiting, waarbij de lhs wordt geevalueerd vóór de rhs (waarbij de uitkomst van de lhs mogelijk ervoor zorgt dat de rhs niet eens meer geevalueerd hoeft te worden). Daarom werkt dit gewoon fatsoenlijk:

C++:

void DoeIets(MyClass * ptr)
{
    if (ptr && ptr->DoeIets())
        DoeIetsAnders();
    else
        DoeLekkerNiets();
}

Zoals in alle vergelijkbare talen (C, C#, Java, VB, PHP, JS, Python, ...)

[ Voor 18% gewijzigd door .oisyn op 31-08-2007 11:08 ]

[kenneth]

VB, dat dacht je maar!
Om in VB.NET toch shortcircuiting te kunnen gebruiken hebben ze juist de keywords AndAlso en OrElse toegevoegd. Nee, echt

[BasieP]

kenneth schreef op vrijdag 31 augustus 2007 @ 11:12:
VB, dat dacht je maar!
Om in VB.NET toch shortcircuiting te kunnen gebruiken hebben ze juist de keywords AndAlso en OrElse toegevoegd. Nee, echt

true, niet alle talen doen aan Short-circuit_evaluation
zie ook:
http://en.wikipedia.org/wiki/Short-circuit_evaluation
http://en.wikipedia.org/wiki/Category:Programming_evaluation

btw,
in vb(.net) hebben ze ook een iif, wat vergelijkbaar is met de shorthand
a = b?c:d;

Nadeel is dat omdat vb(.net) niet aan sce doet dat zowel c als d moeten evalueren.
dus dit kan niet:

Visual Basic .NET:

a = iif(b.length > 0, b(0), nothing)

[ Voor 32% gewijzigd door BasieP op 31-08-2007 11:22 ]

[kenneth]

BasieP schreef op vrijdag 31 augustus 2007 @ 11:17:
[...]

true

Toen hield ik op met lezen.

[BasieP]

kenneth schreef op vrijdag 31 augustus 2007 @ 11:22:
[...]
Toen hield ik op met lezen.

en bedankt voor je nuttige bijdrage
(wat moet je nou met zo'n reactie?)

[kenneth]

lazy evaluation ... ik zie "true" staan en hou op met lezen ... 't was een grapje

[gorgi_19]

iif stamt nog uit de oude VB6 tijd;
Bedoel je iets als:

Visual Basic .NET:

If b.lenght > 0 THEN a = b(0) ELSE a = Nothing

[Woy]

kenneth schreef op vrijdag 31 augustus 2007 @ 11:12:
VB, dat dacht je maar!
Om in VB.NET toch shortcircuiting te kunnen gebruiken hebben ze juist de keywords AndAlso en OrElse toegevoegd. Nee, echt

Dan is "And" dus gewoon de binaire operator? of niet?

Op zich is dat nog niet zo vreemd. Welke keywords er gebruikt worden is natuurlijk niet echt heel erg interessant.

[ValHallASW]

.oisyn schreef op vrijdag 31 augustus 2007 @ 11:06:
[...]

Sorry, maar totale onzin. && en || doen aan short-circuiting, waarbij de lhs wordt geevalueerd vóór de rhs (waarbij de uitkomst van de lhs mogelijk ervoor zorgt dat de rhs niet eens meer geevalueerd hoeft te worden).

Ik was inderdaad in de war met de evaluation bij functies, en ik dacht dus dat de volgorde bij && en || niet gedefinieerd was. Dan nog kan het voor de duidelijkheid zinvol zijn meerdere ifs op te nemen, maar het nut wordt inderdaad een stuk minder

[BasieP]

gorgi_19 schreef op vrijdag 31 augustus 2007 @ 11:30:
iif stamt nog uit de oude VB6 tijd;
Bedoel je iets als:

Visual Basic .NET:

If b.lenght > 0 THEN a = b(0) ELSE a = Nothing

nou ik bedoelde gewoon iif, omdat dit een functie is, en geen native taal ding, worden zowel de true part als de false part ge-evalueerd ongeacht het resultaat van de conditie.

In jouw geval if/then/else wordt gewoon alleen 'then' of alleen 'else' geevalueerd, afhankelijk van de conditie.

wat wel veel voorkomt in vb is bijv zoiets:

Visual Basic .NET:

if not a is nothing And a.size > 0 then ....

Waarbij hij niet lazy is, en dus bij a.size een exception geeft. (daar is die andalso dus voor)

[.oisyn]

BasieP schreef op vrijdag 31 augustus 2007 @ 11:17:
[...]

true, niet alle talen doen aan Short-circuit_evaluation
zie ook:
http://en.wikipedia.org/wiki/Short-circuit_evaluation

Pff C++ stond er niet eens bij, 'k heb 'm geadd

[Grijze Vos]

Ik meen me te herinneren dat Object Pascal (Delphi) ook een cand en cor had voor shortcircuiting. Kan zijn dat in nieuwere versies dit standaard is geworden.

[Icelus]

BasieP schreef op vrijdag 31 augustus 2007 @ 11:23:
[...]

en bedankt voor je nuttige bijdrage
(wat moet je nou met zo'n reactie?)

Short circuit reading?

[Robtimus]

Wat dacht je van deze:

Java:

private static void blockIndefinitely()
{
    while(true)
    {
        try
        {
            Thread.sleep(100L);
        }
        catch(Exception exception) { }
    }
}

Allereerst: een catch-all zonder body

Ten tweede: elke 100ms wordt deze thread wakker, om vervolgens weer keihard in slaap te vallen. Ik zie het al gebeuren, 's nachts elke 10 minuten:
Iemand: WAKKER WORDEN!!!
* Robtimus : Huh? Wat is er?
Iemand: Ga maar lekker slapen.

Ik zou gek worden en die persoon flink in elkaar beuken.

[Grijze Vos]

Wat is het nut van die functie?

[Anoniem: 178962]

@IceManX:

"Hey Bert, slaap je al?"

[Robtimus]

Grijze Vos schreef op vrijdag 31 augustus 2007 @ 13:49:
Wat is het nut van die functie?

De functie naam zegt het toch al? Blokkeer voor altijd.

Op zich al erg genoeg dat ze een hele thread willen laten deadlocken, maar doe het dan wat efficienter. Bv zo:

Java:

Object o = new Object();
while (true)
{
    synchronized (o)
    {
        try
        {
            o.wait();
        }
        catch (InterruptedException e)
        {
            // at least LOG the freaking exception!
        }
    }
}

1) Geen catch all maar alleen de exception die gecaught MOET worden.
2) doe iets met die exception, al is het maar loggen
3) blocken dmv synchronisatie. Zolang er geen andere thread notify() of notifyAll() op dat object roept blijft hij wachten. Aangezien geen andere thread een reference naar dat object heeft gebeurt dat dus nooit. Alleen door de thread te interrupten kun je uit die o.wait() komen, hence the loop.

Op deze manier wordt de thread niet tenminste elke keer weer geactiveerd.


Dit prachtige stukje code komt trouwens uit een professioneel pakket dat wij gebruiken. Ditzelfde pakket krijgt het voor elkaar om, zodra je een mailtje van 10MB opent, het geheugengebruik met zo'n 180MB te laten toenemen. Sluit je het mailtje dan wordt dat geheugen niet vrijgegeven, en als je hetzelfde mailtje nog een keer opent neemt het programma gewoon nog meer geheugen in beslag.

Needless to say dat het regelmatig voorkomt dat er OutOfMemoryErrors worden gethrowd wanneer je grote emails opent.

[Anoniem: 178962]

Een geheugenlek in Java, dat is toch een hele prestatie

[Anoniem: 43565]

Anoniem: 178962 schreef op vrijdag 31 augustus 2007 @ 20:11:
Een geheugenlek in Java, dat is toch een hele prestatie

De JVM gaat pas geheugen opruimen als het de limiet van het beschikbare geheugen nadert (of wanneer het zich te pletter verveelt).
Het kan dus zijn dat de JVM zich nergens druk over maakt omdat er nog 100 MB vrij geheugen is. Als je dan vervolgens een instantie aanmaakt wat 200 MB nodig heeft dan kan het best misgaan.

[ Voor 4% gewijzigd door Anoniem: 43565 op 31-08-2007 20:15 ]

[.oisyn]

Anoniem: 178962 schreef op vrijdag 31 augustus 2007 @ 20:11:
Een geheugenlek in Java, dat is toch een hele prestatie

Niet zo moeilijk, gewoon een kwestie van (globale) referenties niet op null zetten . Dat kan ingewikkelder zijn dan het klinkt, andere systemen (zoals de GUI) kunnen ook indirect referenties hebben naar jouw objecten, en dan worden die dingen dus nooit opgeruimd.

[Anoniem: 14829]

gorgi_19 schreef op vrijdag 31 augustus 2007 @ 11:30:
iif stamt nog uit de oude VB6 tijd;

iif (immediate if) stamt voor zover ik weet van nog veel verder terug. Clipper Autumn '86 had 't al, net als FoxBase 2.0. En 't zou me niet verbazen dat er voor die tijd ook wel andere talen waren die die constructie kenden.

[Anoniem: 14829]

Grijze Vos schreef op vrijdag 31 augustus 2007 @ 12:21:
Ik meen me te herinneren dat Object Pascal (Delphi) ook een cand en cor had voor shortcircuiting. Kan zijn dat in nieuwere versies dit standaard is geworden.

Shortcircuiting is bij Delphi al vanaf versie 1 default, maar kan nu nog steeds met een compiler directive uitgezet worden. Waarom je dat overigens ooit zou willen is een 2e...

[Robtimus]

Anoniem: 14829 schreef op vrijdag 31 augustus 2007 @ 22:15:
[...]

Shortcircuiting is bij Delphi al vanaf versie 1 default, maar kan nu nog steeds met een compiler directive uitgezet worden. Waarom je dat overigens ooit zou willen is een 2e...

Omdat het soms belangrijk is dat allebei de operands geevalueerd worden. Vooral met functies met bijwerkingen kan dat belangrijk zijn.

Tuurlijk zou je allebei de functies kunnen aanroepen en dan hun return waarde opslaan, maar programmeurs zijn vaak lui

Vergelijk:

Java:

boolean b1 = doSomethingImportant();
boolean b2 = doSomethingElseImportant();
if (!b1 || !b2)
{
    System.out.println("One of the important functions has failed");
}

Java:

if (!doSomethingImportant() | !doSomethingElseImportant())
{
    System.out.println("One of the important functions has failed");
}

Minder goed leesbaar, maar minder typewerk plus 2 minder stack variabelen.

[Anoniem: 43565]

laatmaar

[ Voor 102% gewijzigd door Anoniem: 43565 op 01-09-2007 14:36 ]

[Anoniem: 224515]

Java:

if (!doSomethingImportant() | !doSomethingElseImportant())
{
    System.out.println("One of the important functions has failed");
}

Minder goed leesbaar, maar minder typewerk plus 2 minder stack variabelen.

Moet daar geen | bij? ( if (!doSomethingImportant() || !doSomethingElseImportant()) )

[MNeMoNiCS]

IceManX schreef op zaterdag 01 september 2007 @ 13:05:
[...]

Minder goed leesbaar, maar minder typewerk plus 2 minder stack variabelen.

Ik denk dat de JAVA VM verstandig genoeg is om de waarde van de 2 boolean variabelen gewoon in CPU registers op te slaan. Zulk soort optimalisaties zijn derhalve vaak af te raden.

[Anoniem: 43565]

^^ dat betwijfel ik, je kan er iig niet van uit gaan. Hoe dan ook ligt helemaal niemand er wakker van hoeveel geheugen een gemiddelde applicatie nou gebruikt. Snellere pc's zijn er voor het gemak van de ontwikkelaar, niet voor de consument

Anoniem: 224515 schreef op zaterdag 01 september 2007 @ 14:55:
[...]


Moet daar geen | bij? ( if (!doSomethingImportant() || !doSomethingElseImportant()) )

Nee, dat dacht ik eerst ook even, maar dat is niet hetzelfde.

bij twee keer | wordt het tweede niet meer uitgevoerd als het eerste op True evalueert. De conditie is dan immers toch al waar. Wil je echter dat de tweede functie ook geëvalueert wordt, ongeacht de uitkomst van de eerste functie (bijvoorbeeld omdat je dan dingen print of in de database zet die moeten gebeuren) dan moet je dus maar één | symbool gebruiken.

[ Voor 16% gewijzigd door Anoniem: 43565 op 01-09-2007 15:01 ]

[.oisyn]

Werkt dat dan? Worden de booleans niet eerst gepromoveerd tot int, waardoor je een error krijgt aangezien de expression in de if geen boolean oplevert?

En dat van die variabelen, dat maakt dus écht geen zak uit .

[Anoniem: 224515]

Nee, dat dacht ik eerst ook even, maar dat is niet hetzelfde.

bij twee keer | wordt het tweede niet meer uitgevoerd als het eerste op True evalueert. De conditie is dan immers toch al waar. Wil je echter dat de tweede functie ook geëvalueert wordt, ongeacht de uitkomst van de eerste functie (bijvoorbeeld omdat je dan dingen print of in de database zet die moeten gebeuren) dan moet je dus maar één | symbool gebruiken.

K, ik kan geen java
Maar moeten bij een '|' dan ook allebei de waardes true zijn ( Zelfde als &&? ) of gebeurt er iets in de functie maar hoeft er daarna nog steeds maar een true te geven?

//Edit:

O, de langere code die hetzelfde zou doen had || Dus wellicht toch een typefout?

//Edit2:
@beneden me, ty nu snap ik het

[ Voor 9% gewijzigd door Anoniem: 224515 op 01-09-2007 16:20 ]

[Alex)]

De standaardwerkwijze is zo:
if ( voorwaarde1 || voorwaarde2 )

Als voorwaarde1 true retourneert, wordt voorwaarde2 niet eens meer geëvalueerd (kortsluitingsevaluatie), als je dat wél wilt schrijf je:
if ( voorwaarde1 | voorwaarde2 )

Dan voert hij het allebei uit en afhankelijk van die resultaten (true false / false true / true true) zal hij de code binnen de if-structuur uitvoeren.

[PrisonerOfPain]

.oisyn schreef op zaterdag 01 september 2007 @ 15:38:
Werkt dat dan? Worden de booleans niet eerst gepromoveerd tot int, waardoor je een error krijgt aangezien de expression in de if geen boolean oplevert?

Nee, |, ^ en & werken op zowel integers als op booleans.

[.oisyn]

Ah ok. De ^ is natuurlijk een beetje dubbelop, != doet precies hetzelfde

[Anoniem: 14829]

Alex) schreef op zaterdag 01 september 2007 @ 15:57:
De standaardwerkwijze is zo:
if ( voorwaarde1 || voorwaarde2 )

Als voorwaarde1 true retourneert, wordt voorwaarde2 niet eens meer geëvalueerd (kortsluitingsevaluatie), als je dat wél wilt schrijf je:
if ( voorwaarde1 | voorwaarde2 )

Klinkt als misbruik maken van bitwise or. Zal best werken, maar daar is '|' niet voor bedoeld.
En niemand kan je garanderen dat 't in nieuwe versies van de VM ook nog zal werken...

[ValHallASW]

Voor een bitwise or zal je toch echt beide waardes moeten weten, dus ik kan je garanderen dat in nieuwere VM versies nog steeds beide functies uitgevoerd worden. En een bitwise or/and levert voor booleans altijd hetzelfde op als de 'gewone' or/and. Het enige wat theoretisch problemen op zou kunnen gaan leveren (maar dat gaat het niet) is de impliciete cast van bool naar int.

[Robtimus]

Anoniem: 14829 schreef op zaterdag 01 september 2007 @ 17:54:
[...]
Klinkt als misbruik maken van bitwise or. Zal best werken, maar daar is '|' niet voor bedoeld.
En niemand kan je garanderen dat 't in nieuwe versies van de VM ook nog zal werken...

Alleen kent Java een expliciet boolean type, met zijn eigen operators. Dat deze lijken op integer bitwise operators kan dus erg verwarrend zijn voor de C(++) programmeurs, maar het zijn conceptioneel gezien totaal andere operators.

Natuurlijk kan het zijn dat dit geimplementeerd wordt dmv integers en integer bitwise operators, maar dat is afhankelijk van de JVM implementatie.

[JKVA]

IceManX schreef op zondag 02 september 2007 @ 15:14:
[...]

Alleen kent Java een expliciet boolean type, met zijn eigen operators. Dat deze lijken op integer bitwise operators kan dus erg verwarrend zijn voor de C(++) programmeurs, maar het zijn conceptioneel gezien totaal andere operators.

Natuurlijk kan het zijn dat dit geimplementeerd wordt dmv integers en integer bitwise operators, maar dat is afhankelijk van de JVM implementatie.

True, ik zat ook al te zoeken in de JLS (Java spec) maar kon het zo snel ff niet vinden.

Het is iig zo dat ze in de certificeringsboekjes het gewoon als normaal Java gebruik zien en niet als hacken/misbruik.

[PrisonerOfPain]

Anoniem: 14829 schreef op zaterdag 01 september 2007 @ 17:54:
[...]
Klinkt als misbruik maken van bitwise or. Zal best werken, maar daar is '|' niet voor bedoeld.
En niemand kan je garanderen dat 't in nieuwe versies van de VM ook nog zal werken...

quote: http://java.sun.com/docs/..._edition/html/15.doc.html

15.21.2 Boolean Logical Operators &, ^, and |

When both operands of a &, ^, or | operator are of type boolean, then the type of the bitwise operator expression is boolean.
For &, the result value is true if both operand values are true; otherwise, the result is false.

For ^, the result value is true if the operand values are different; otherwise, the result is false.

For |, the result value is false if both operand values are false; otherwise, the result is true.

[roy-t]

* roy-t is ook weer bezig:

C#:

class Camera
    {
 
        //variabeltjes        
        private Camera()
        {
            //dit is de constructor
        }
    }

vind de fout

[.oisyn]

Ik zie alleen vage indenting van de buitenste accolades, maar dat is subjectief.

Als je doelt op de private constructor, daar zijn best goede redenen voor. Niemand mag een instantie van Camera maken, alleen Camera zelf. Je zou dus een static create functie kunnen maken.

[Robtimus]

Ik ben niet bekend met C#, maar het enige opmerkelijke dat ik zie is de private constructor. Dat hoeft alleen niet per se fout te zijn als je andere manieren hebt om instances te krijgen, zoals static methods. Het hele singleton pattern vertrouwt op niet-public constructors.

[roy-t]

Hmm daar had ik niet aangedacht, ik had slechts de fout:

code:

Error   1   'xxxx.Camera.Camera()' is inaccessible due to its protection level  C:\Documents and Settings\xxxx\Mijn documenten\Visual Studio 2005\Projects\xxxx\xxxx\xxxx\Game1.cs  48  26  xxxx

in mijn hoofd, ik had nog niet nagedacht over singletons (waar ik eigenlijk nog nooit mee bezig ben geweest.)

En hmm ik had er ook nooit over nagedacht dat een class zijn eigen class spawned hmm leuk dit OO programeren! *ratje krijgt weer ideetjes*

Anyways ik ga weer bezig met whatever ik bezig was

[Anoniem: 43565]

therat10430 schreef op maandag 10 september 2007 @ 21:39:
Hmm daar had ik niet aangedacht, ik had slechts de fout:

code:

Error   1   'xxxx.Camera.Camera()' is inaccessible due to its protection level  C:\Documents and Settings\xxxx\Mijn documenten\Visual Studio 2005\Projects\xxxx\xxxx\xxxx\Game1.cs  48  26  xxxx

in mijn hoofd, ik had nog niet nagedacht over singletons (waar ik eigenlijk nog nooit mee bezig ben geweest.)

En hmm ik had er ook nooit over nagedacht dat een class zijn eigen class spawned hmm leuk dit OO programeren! *ratje krijgt weer ideetjes*

Anyways ik ga weer bezig met whatever ik bezig was

Naast Singleton zou je ook kunnen kijken naar het Factory pattern. Die doet niet veel anders. Singleton zorgt er met een static functie voor dat er altijd maar één instantie bestaat, factory maakt al gelang naar status of whatever een instantie van een toepasselijk subtype (zonder dat jij hoeft te weten welk subtype dat is). Op Factory zijn nog wel wat varianten overigens.

[Anoniem: 230709]

Een mooi moment bij het doornemen van code van een ex-collega:

PHP:

$mijnarray
$teller=0;

foreach ($mijnarray as $temp)
{
  $teller++;
}

[Crayne]

Hoe moet je anders bepalen hoe groot de array is?

[Woy]

Crayne schreef op dinsdag 11 september 2007 @ 11:35:
Hoe moet je anders bepalen hoe groot de array is?

Bedoel je dat als grap of meen je het?

PHP:

sizeof($array);

[Crayne]

rwb schreef op dinsdag 11 september 2007 @ 11:38:
[...]

Bedoel je dat als grap of meen je het?

rwb schreef op dinsdag 11 september 2007 @ 11:38:

PHP:

sizeof($array);

Je vind sizeof() intuïtiever werken dan count()?

[Not Pingu]

Crayne schreef op dinsdag 11 september 2007 @ 11:45:

Je vind sizeof() intuïtiever werken dan count()?

Nou ben ik geen PHP'er maar als ik dan in de PHP Manual lees:

sizeof

This function is an alias of: count().

...dan zakt me de broek wel even af dat je daar uberhaupt al een discussie over kunt hebben.

[Crayne]

Not Pingu schreef op dinsdag 11 september 2007 @ 12:01:
[...]
...dan zakt me de broek wel even af dat je daar uberhaupt al een discussie over kunt hebben.

Discussie? *blinkety-fucking-blink* Waar?

[Woy]

Crayne schreef op dinsdag 11 september 2007 @ 11:45:
[...]

[...]
Je vind sizeof() intuïtiever werken dan count()?

Tja ik ben geen php-er dus gebruik beide eigenlijk liever niet

[Voutloos]

Tja, ik gebruik toch liever de primaire functienaam ipv een alias.

edit:
ah, dat verklaart het.

[ Voor 20% gewijzigd door Voutloos op 11-09-2007 12:31 ]

[FragFrog]

Crayne schreef op dinsdag 11 september 2007 @ 11:35:
Hoe moet je anders bepalen hoe groot de array is?

Op zich in andere talen wel een valide punt natuurlijk.. Lang leve PHP's simpliciteit

Overigens, die private constructor zou een E_WARNING level fout opleveren in PHP.. Been there, done that, got the T-shirt...

Ligt waarschijnlijk ook een beetje aan de evolutie van PHP, tot voor PHP5 waren classes eigenlijk niets anders dan veredelde functies en was een call naar een class gelijk aan een call naar zijn constructor - ergo, bij een class call roep je ook altijd zelf de constructor aan dus moet'ie wel public zijn.

[ Voor 31% gewijzigd door FragFrog op 11-09-2007 12:46 ]

[Anoniem: 26306]

Not Pingu schreef op dinsdag 11 september 2007 @ 12:01:

...dan zakt me de broek wel even af dat je daar uberhaupt al een discussie over kunt hebben.

Programmeer je weleens in C? Lekker verwarrend toch?

[Woy]

Anoniem: 26306 schreef op dinsdag 11 september 2007 @ 12:49:
[...]

Programmeer je weleens in C? Lekker verwarrend toch?

In c zijn arrays toch meestal 4 lang

[.oisyn]

Anoniem: 26306 schreef op dinsdag 11 september 2007 @ 12:49:
[...]

Programmeer je weleens in C? Lekker verwarrend toch?

In C en C++ is het ook heel verwarrend. Althans, het werkt logisch, maar meestal niet intuitief aangezien beginners er altijd over struikelen.

C++:

int * myArray = new int[12];
int aantalElementen = sizeof(myArray);

En zich dan afvragen waarom het antwoord van rwb inderdaad juist is.

[Paul C]

PHP:

function getartistid($artist) {
    $sql = 'SELECT `artistid` FROM `artists` WHERE `artistname` = \'' 
            . mysql_real_escape_string($artist)
            . '\' LIMIT 0, 1';
    $searchresult = mysql_query($sql);
    if(mysql_num_rows($searchresult) != 1) {
        insertartist($artist);
        $searchresult = mysql_query($sql);
    }
    list($id) = mysql_fetch_row($searchresult);
    return($id[0]);
}

Na wat schuiven met de code pakte ik dit stuk code na een half jaar weer op. Duurde even voor ik doorhad waarom mijn relationele database zo moeilijk deed...

[.oisyn]

Regel 10 en 11? En volgens mij vergeet je je resultsets te closen

[ Voor 63% gewijzigd door .oisyn op 13-09-2007 11:29 ]

[Voutloos]

list() en dan alsnog het element pakken, lekker hoor.

Overigens vind ik het ook enigszins een wtf dat als een artist niet gevonden wordt dat hij meteen maar ge-insert moet worden, dat is toch wel een neveneffect dat heel erg duidelijk gedocumenteerd mag zijn.

[Tanuki]

.oisyn schreef op donderdag 13 september 2007 @ 11:28:
Regel 10 en 11? En volgens mij vergeet je je resultsets te closen

Dat wordt automatisch gedaan aan het einde van het script.

[.oisyn]

Wat niet betekent dat je het geen aandacht hoeft te geven. Ten eerste scheelt het geheugengebruik (zeker bij grotere queries, maar in dit voorbeeld valt dat natuurlijk wel mee), en ten tweede is het gewoon netjes. Die functie lekt nu gewoon geheugen. Als iemand om een of andere reden besluit een miljoen keer die functie aan te roepen ben je de sjaak.

[ Voor 37% gewijzigd door .oisyn op 13-09-2007 12:17 ]

[Paul C]

Voutloos had het idd goed. Het probleem is dat strings in PHP arrays van Char zijn, dus dit is prima code, maar het zal zo nooit een ID hoger dan 9 retourneren.

Dat er meteen inserartist() word gecalled is eigenlijk best logisch. Deze functie is namelijk alleen voor gebruik bij het inserten van een artiest, als je wilt selecten, dan moet je gewoon joinen en er is geen enkele andere reden waarom je het artist ID zou willen weten.

Het result closen is opzich wel een good practice, maar in dit geval niet echt heel nuttig. De query resulteert slechts in een enkele smallint, tegen de tijd dat dat substantiële hoeveelheden geheugen gaat bezetten zit ik al lang met andere problemen!

[FragFrog]

.oisyn schreef op donderdag 13 september 2007 @ 12:14:
Wat niet betekent dat je het geen aandacht hoeft te geven. Ten eerste scheelt het geheugengebruik (zeker bij grotere queries, maar in dit voorbeeld valt dat natuurlijk wel mee), en ten tweede is het gewoon netjes. Die functie lekt nu gewoon geheugen. Als iemand om een of andere reden besluit een miljoen keer die functie aan te roepen ben je de sjaak.

Afaik wordt een resultset automatisch weggegooid bij het aanroepen van een nieuwe query in PHP. Ergo, als iemand een miljoen keer die functie aanroept is er nog steeds niets aan de hand.

Staat trouwens ook gewoon in de handleiding

Enige reden om resultset te clearen is als je meerdere databaseobjecten naast elkaar aanroept die elk een enorme resultset hebben, maar dan heb je het wel over extreem uitzonderlijke situaties - sowieso zijn er maar heel weinig situaties waarin je veel gegevens uit je database moet halen, er is tenslotte een limiet aan hoeveel data een gebruiker kan verwerken, vaak heb je dan dus ook gewoon iets stoms gedaan als bijvoorbeeld binaire data in je database gooien voordat je resultsets echt te groot worden.

[ Voor 23% gewijzigd door FragFrog op 14-09-2007 15:25 ]

[.oisyn]

pcmadman schreef op vrijdag 14 september 2007 @ 15:09:
Voutloos had het idd goed.

En ik, hence mijn hint naar die twee regels. Ik eis erkenning voor mijn werk!

[Janoz]

@pcmadman: Het gaat niet alleen om het geheugengebruik van de resultset. Er is vaak ook een maximaal aantal aan resutlsets of connecties die tegelijkertijd kunnen bestaan.

@fragfrog: Een resultset wordt zeker niet weggegooid bij de volgende aanroep. Anders zouden dingen als:

code:

rs = query(..)
while rs.hasRecords(){
  andere query met gegevens uit huidige rs
}

niet werken.

@.oisyn: Niet zo zeuren. Gewoon erkennen dat je hem niet had gezien

[ Voor 8% gewijzigd door Janoz op 14-09-2007 15:31 ]

[.oisyn]

FragFrog schreef op vrijdag 14 september 2007 @ 15:15:
[...]

Afaik wordt een resultset automatisch weggegooid bij het aanroepen van een nieuwe query in PHP.
Ergo, als iemand een miljoen keer die functie aanroept is er nog steeds niets aan de hand.

Onjuist.

Staat trouwens ook gewoon in de handleiding

Ten eerste is wat hier staat is anders dan datgene wat je net beweerde, ten tweede slaat dit op resources in het algemeen, en jij weet niet of de mysql-lib zelf ook nog referenties heeft naar die resource. De mysq_free_result() functie zelf zegt er namelijk niets over - die zegt slechts dat resources ook worden vrijgegeven aan het eind van het script (en dus niet als alle referenties vanuit het script ernaar opgeruimd zijn)

Enige reden om resultset te clearen is als je meerdere databaseobjecten naast elkaar aanroept die elk een enorme resultset hebben

Nee, er is nog een reden, en die heb ik al genoemd: het is gewoon netjes dat je je zaakjes achter je reet opruimt . En dat geldt ook gewoon voor garbage collected platforms als Java en .Net

[ Voor 3% gewijzigd door .oisyn op 14-09-2007 15:43 ]

[Paul C]

@.oisyn:
Ik dacht dat je daarmee doelde op het ontbreken van die close, maar idd, jij had het ook goed gezien!

@Janoz:
Impliciet verwacht die functie natuurlijk een werkende database connectie, dus het callen van deze functie zal nooit een extra connectie opleveren.
En is het niet gewoon zo dat PHP die resource weggooid aan het einde van de functie, want scope ervan is toch alleen binnen de functie?

quote: http://nl3.php.net/manual/en/language.types.resource.php

Freeing resources

Due to the reference-counting system introduced with PHP 4's Zend Engine, it is automatically detected when a resource is no longer referred to (just like Java). When this is the case, all resources that were in use for this resource are made free by the garbage collector. For this reason, it is rarely ever necessary to free the memory manually by using some free_result function.

[Voutloos]

Een extension of library kan dus ook references bewaren.

En opruimen is natuurlijk in principe netjes, maar bij het gros van de php scripts maakt het stiekem geen bal uit.

[ Voor 3% gewijzigd door Voutloos op 14-09-2007 15:54 ]

[FragFrog]

Janoz schreef op vrijdag 14 september 2007 @ 15:30:
@fragfrog: Een resultset wordt zeker niet weggegooid bij de volgende aanroep. Anders zouden dingen als:

code:

rs = query(..)
while rs.hasRecords(){
  andere query met gegevens uit huidige rs
}

niet werken.

Sorry, je hebt natuurlijk gelijk als je met losse calls naar je database werkt. Ben kennelijk te gewend geraakt aan m'n databaseclass die bij een nieuwe query call op dezelfde instance wel netjes de oude resultset weggooid

.oisyn schreef op vrijdag 14 september 2007 @ 15:42:
Onjuist.
[..]
Ten eerste is wat hier staat is anders dan datgene wat je net beweerde, ten tweede slaat dit op resources in het algemeen, en jij weet niet of de mysql-lib zelf ook nog referenties heeft naar die resource. De mysq_free_result() functie zelf zegt er namelijk niets over - die zegt slechts dat resources ook worden vrijgegeven aan het eind van het script (en dus niet als alle referenties vanuit het script ernaar opgeruimd zijn)

Daar ga ik eigenlijk wel vanuit though. Als je result reference niet meer bestaat (wat gebeurt bij het afsluiten van je functie) hoort de resultset zelf ook gewoon te verdwijnen - wat dus wel degelijk in die link vermeld wordt. Het zou me zeer verbazen als dat niet gebeurd eigenlijk, dat het niet bij mysql_free_result staat is logisch - er zijn immers ook genoeg mensen die een mysql resultset in global scope gebruiken en dan wordt'ie immers pas opgeruimt na het einde van je scriptexecutie.

Maargoed, meten is weten, ik zal zo even kijken of het effect heeft in de praktijk

//edit
Een simpel scriptje:

PHP:

require_once('db.inc.php');
require_once('config.inc.php');

function callDatabase() {
  $dbase = new forumDbase;
  $query = mysql_query("SELECT om_name FROM om_menu", $dbase -> instance);
  $result = mysql_fetch_assoc($query);
}

callDatabase();

echo memory_get_usage() . "<br />";


for($i = 0; $i < 10; $i++) {
  callDatabase();
}

echo memory_get_usage() . "<br />";

for($i = 0; $i < 10000; $i++) {
  callDatabase();
}

echo memory_get_usage() . "<br />";

Met als resultaat:

102048
102208
102208

Met andere woorden, je kan tienduizend keer een database call doen zonder dat je geheugengebruik ook maar een byte stijgt.

//edit2
Ter controle ook nog met mysql_free_result:

PHP:

function callDatabase() {
  $dbase = new forumDbase;
  $query = mysql_query("SELECT om_name FROM om_menu", $dbase -> instance);
  $result = mysql_fetch_assoc($query);
  mysql_free_result($query);
}

102296
102456
102456

Met andere woorden, het geheugengebruik stijgt door het gebruik van mysql_free_result!

[ Voor 24% gewijzigd door FragFrog op 14-09-2007 16:08 ]

[.oisyn]

FragFrog schreef op vrijdag 14 september 2007 @ 15:59:
Daar ga ik eigenlijk wel vanuit though.

Ik zei dat het er niet bij stond he, niet dat ik beweer dat het ook daadwerkelijk niet gebeurt

Het zou me zeer verbazen als dat niet gebeurd eigenlijk, dat het niet bij mysql_free_result staat is logisch - er zijn immers ook genoeg mensen die een mysql resultset in global scope gebruiken en dan wordt'ie immers pas opgeruimt na het einde van je scriptexecutie.

Ook niet helemaal waar. Als je de result variabele een nieuwe waarde toekent (bijv. van die van een nieuwe query), dan zou ie dus ook opgeruimd moeten worden. Dat lijkt me toch wel reden om het erin te zetten.

Maargoed, meten is weten, ik zal zo even kijken of het effect heeft in de praktijk

Interessant idd . Maar ongeacht de uitkomst van dat experiment blijf ik bij m'n punt dat het netjes is om 'm af te sluiten

.edit: En voer nu eens elke keer een andere query uit ipv de hele tijd dezelfde?

Met andere woorden, het geheugengebruik stijgt door het gebruik van mysql_free_result!

Sorry maar die conclusie slaat nergens op. Dat is pure causaliteit. Waarschijnlijker is dat de parsetree van het script groter is geworden door de extra call naar mysql_free_result (ik noem maar wat). De omgeving van het experiment is veranderd, dus je kunt uit de resultaten niet concluderen dat puur door de call naar mysql_free_result() het geheugengebruik toeneemt. Probeer het zo eens:

PHP:

$freeResult = true;
function callDatabase()
{ 
  global $freeResult;

  $dbase = new forumDbase; 
  $query = mysql_query("SELECT om_name FROM om_menu", $dbase -> instance); 
  $result = mysql_fetch_assoc($query); 

  if ($freeResult)
    mysql_free_result($query); 
}

En doe dan de test 2 keer, een keer met $freeResult op false, en daarna met $freeResult op true.

Ter vergelijking:

code:

$a = 0;

echo memory_get_usage();

Output: 15536

code:

$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;
$a = 0;


echo memory_get_usage();

Output: 18168

We mogen denk ik wel aannemen dat de oude waarde van $a niet gealloceerd blijft op een of andere manier

[ Voor 42% gewijzigd door .oisyn op 14-09-2007 16:14 ]

[FragFrog]

.oisyn schreef op vrijdag 14 september 2007 @ 16:05:
.edit: En voer nu eens elke keer een andere query uit ipv de hele tijd dezelfde?

U vraagt, wij draaien

PHP:

require_once('db.inc.php');
require_once('config.inc.php');

function callDatabase($i) {
  $dbase = new forumDbase;
  $query = mysql_query("SELECT om_name, ".$i." as iterator FROM om_menu", $dbase -> instance);
  $result = mysql_fetch_assoc($query);
  mysql_free_result($query);
}

callDatabase();

echo memory_get_usage() . "<br />";

for($i = 0; $i < 10; $i++) {
  callDatabase($i);
}

echo memory_get_usage() . "<br />";

for($i = 0; $i < 10000; $i++) {
  callDatabase($i);
}

echo memory_get_usage() . "<br />";

Resultaat:

Met free_result:

102616
103144
103144

Zonder free_result:

102384
102912
102912

Ik denk dat de resultaten wel voor zich spreken

//edit
Natuurlijk stijgt het geheugenverbruik door mysql_free_result alleen doordat er een extra call is, dat ontken ik ook niet. Feit is alleen dat, in tegenstelling tot wat je eerder beweerde, 10.000 keer dezelfde functie aanroepen totaal geen effect heeft op het geheugenverbruik en dat mysql_free_result ook geen positief effect erop heeft (integendeel). Ik blijf dus bij mijn punt dat mysql_free_result wel degelijk overbodig is in bijna alle gevallen

[ Voor 19% gewijzigd door FragFrog op 14-09-2007 16:16 ]

[.oisyn]

Zie mijn edit

[FragFrog]

Zie die van mij

Overigens, ik ben all-for netjes coden. Ik erger me ook dood aan mensen die strings zonder quotes vergelijken 'omdat het toch wel werkt' of ob_start aanroepen omdat andes hun sessies niet werken, just to name something. Maar handmatig je database resultsets gaan opschonen terwijl er een prima werkende garbagecollector drijft wat mij betrefd het punt wat te ver door

[ Voor 91% gewijzigd door FragFrog op 14-09-2007 16:21 ]

[.oisyn]

Probeer het trouwens nog eens met memory_get_usage(true). Voor hetzelfde geldt gebruikt de mysql lib geen emalloc() (wat waarschijnlijk is; hij linkt namelijk gewoon met de standaard C mysql lib, die dat zeker weten niet doet)

[Voutloos]

.oisyn schreef op vrijdag 14 september 2007 @ 16:20:
Probeer het trouwens nog eens met memory_get_usage(true).

Dat vroeg ik me ook al af, en ik heb het al geprobeerd. Maar het maakt alsnog niet uit.

Voor de compleetheid zou je het ook met mysqli moeten proberen, want die versie gaat iets anders met resources en links om.

offtopic:
topic splitsing klinkt ook als een plan.

[ Voor 26% gewijzigd door Voutloos op 14-09-2007 16:23 ]

[FragFrog]

.oisyn schreef op vrijdag 14 september 2007 @ 16:20:
Probeer het trouwens nog eens met memory_get_usage(true). Voor hetzelfde geldt gebruikt de mysql lib geen emalloc() (wat waarschijnlijk is; hij linkt namelijk gewoon met de standaard C mysql lib, die dat zeker weten niet doet)

Zonder free_result:

262144
262144
262144

Met free_result:

262144
262144
262144

Ongetwijfeld omdat er gewoon een blok geheugen wordt vrijgemaakt wat in beide gevallen niet overschreden wordt En, as usual, geen positief effect van free_result

[.oisyn]

Hmm, het vage is, ik krijg hele andere resultaten:

PHP:

mysql_connect("localhost", "***", "***");
mysql_select_db("***");

function callDB($i)
{
    $r = mysql_query("SELECT * FROM f_posts");
    $result = mysql_fetch_row($r);
}

echo memory_get_usage(true), "<br>";

for ($i = 0; $i < 10; $i++)
    callDB($i);

echo memory_get_usage(true), "<br>";

for ($i = 0; $i < 1000; $i++)
    callDB($i);

echo memory_get_usage(true), "<br>";

Output:

23008
24728
40408

Ik gebruik PHP 4.4.4

.edit: nevermind. Het komt door PHP's stringbewerking. Ik had de query iets versimpeld naar "SELECT $i", dat gaf hetzelfde resultaat. Echter, als ik "SELECT " . $i deed, dan bleef het geheugengebruik wel constant

[ Voor 17% gewijzigd door .oisyn op 14-09-2007 16:32 ]

[remco_k]

Zo even dit topic wat nieuw leven inblazen met mijn recentste 'blunder' die me toch al snel een kwartier aan zoeken heeft gekost:

C++:

void __fastcall TMyClass::setWaitForSomething(bool ABool)
{
    cbWaitForSomething->Checked=true;
}

Dusss...

[Woy]

remco_k schreef op donderdag 20 september 2007 @ 11:35:
Zo even dit topic wat nieuw leven inblazen met mijn recentste 'blunder' die me toch al snel een kwartier aan zoeken heeft gekost:

C++:

void __fastcall TMyClass::setWaitForSomething(bool ABool)
{
    cbWaitForSomething->Checked=true;
}

Dusss...

Handig zo'n parameter

[daniëlpunt]

FragFrog schreef op dinsdag 11 september 2007 @ 12:41:
[...]

Op zich in andere talen wel een valide punt natuurlijk.. Lang leve PHP's simpliciteit

Overigens, die private constructor zou een E_WARNING level fout opleveren in PHP.. Been there, done that, got the T-shirt...

Ligt waarschijnlijk ook een beetje aan de evolutie van PHP, tot voor PHP5 waren classes eigenlijk niets anders dan veredelde functies en was een call naar een class gelijk aan een call naar zijn constructor - ergo, bij een class call roep je ook altijd zelf de constructor aan dus moet'ie wel public zijn.

Weet je het zeker?

In PHP5 krijg ik gewoon een Fatal error:

PHP:

class Foo {
    private function Foo() {
        echo 'gaat dit goed?';
    }
}

$f = new Foo();
// Output:
// Fatal error: Call to private Foo::foo() from ...

En in PHP4 had je geen access modifiers, daar was gewoon alles public.

[Creepy]

Java:

String shortDescription = description.substring(0,500);

En bovenstaande dus zonder lengte checks ervoor......... en ondertussen afvragen waar die Exception vandaan komt als description korter is dan 501 tekens.....

[Johnny Goodbye]

ook een lekkkere instinker in PHP

PHP:

  for  ($i=0;$i<10;$I++) {...}

en maar afvragen waarom hij doorgaat na 10x

[Woy]

Johnny Goodbye schreef op vrijdag 21 september 2007 @ 11:58:
ook een lekkkere instinker in PHP

PHP:

  for  ($i=0;$i<10;$I++) {...}

en maar afvragen waarom hij doorgaat na 10x

Krijg je daar niet een warning op dat je een un-initialized variable gebruikt? Of initializeerd php hem automagisch op 0?

[Icelus]

rwb schreef op vrijdag 21 september 2007 @ 12:09:
[...]

Krijg je daar niet een warning op dat je een un-initialized variable gebruikt? Of initializeerd php hem automagisch op 0?

Als een variabele nog niet geïnitialiseerd is wordt ie aangemaakt en op null gezet.

[Voutloos]

En afhankelijk van je error reporting level krijg je de bijbehorende notice te zien.

[Johnny Goodbye]

Voutloos schreef op vrijdag 21 september 2007 @ 12:25:
En afhankelijk van je error reporting level krijg je de bijbehorende notice te zien.

die kreeg ik ook wel maar ik stond wel even raar te kijken

[Kixtart]

Toen ik net begon te programmeren had ik dit weleens:

C:

 
for (i=0;i<100;i++) 
{
  for(j=0;j<100;i++)
  {
  }
} 

En maar afvragen waarom het fout gaat. Verschil tussen i en j is niet zo duidelijk

[flowerp]

Icelus schreef op vrijdag 21 september 2007 @ 12:19:
[...]
Als een variabele nog niet geïnitialiseerd is wordt ie aangemaakt en op null gezet.

Handige feature zeg...

(De eerste versies van C hadden ook zo'n 'feature' maar vanwege de vele, vele problemen die dit opleverde is dit in latere versies afgeschaft. Vreemd dat een modernere programmeer taal zo'n bad practice uit het verleden weer gewoon overneemt.)

[Erkens]

flowerp schreef op zaterdag 22 september 2007 @ 00:10:
Handige feature zeg...

(De eerste versies van C hadden ook zo'n 'feature' maar vanwege de vele, vele problemen die dit opleverde is dit in latere versies afgeschaft. Vreemd dat een modernere programmeer taal zo'n bad practice uit het verleden weer gewoon overneemt.)

tja, als je de error melding negeert...

Notice: Undefined variable: I in /var/www/htdocs/bla/test.php on line 3

...dan ligt het toch echt aan jezelf.

[flowerp]

Erkens schreef op zaterdag 22 september 2007 @ 00:33:
[...]
tja, als je de error melding negeert...

Dat is geen error, maar een notice of te wel een warning. Een fatal error lijkt me beter op z'n plaats hier eigenlijk. Die zijn iets moeilijker te negeren

[Icelus]

flowerp schreef op zaterdag 22 september 2007 @ 00:10:
[...]


Handige feature zeg...

(De eerste versies van C hadden ook zo'n 'feature' maar vanwege de vele, vele problemen die dit opleverde is dit in latere versies afgeschaft. Vreemd dat een modernere programmeer taal zo'n bad practice uit het verleden weer gewoon overneemt.)

PHP is ooit opgezet als simpele scripttaal. Declareren van variabelen zou inderdaad mooier/beter geweest zijn.

[ValHallASW]

Het declareren van variabelen staat totaal los van deze 'feature': dit is het zelf initaliseren van een variabele als deze niet bestaat. In python hoef je ook niet te declareren, maar je een niet-bestaande variabele aanspreken zal je niet lukken.
PHP initialiseert 'm trouwens niet op NULL, maar op de naam van de variabele: als je de variabele blaat gebruikt dan krijgt 'ie de waarde 'blaat':

probeer maar eens:

PHP:

<?php
echo blaat;

Bij C lijkt het standaard initialiseren op NULL me trouwens niet zo'n probleem, omdat je daar toch de variabelen declareert?

[ Voor 12% gewijzigd door ValHallASW op 22-09-2007 13:12 ]

[OnTracK]

Dat is geen variabele, dat is een constante. En die leveren inderdaad hun eigen naam op als je ze niet gedefinieerd hebt (en een mooie warning).

[ValHallASW]

Er, whoops, ik zit te slapen... ik heb een hekel aan prefixes... het doet me altijd denken aan de string$'s uit basic (en het is vrij zinloos; een functie is toch even hard gewoon een object? )

PHP:

<?php
$l = 5+$k;
echo $l;

dan maar? Daar komt inderdaad 5 uit

[ Voor 16% gewijzigd door ValHallASW op 22-09-2007 13:33 ]

[Anoniem: 26306]

ValHallASW schreef op zaterdag 22 september 2007 @ 13:11:

PHP initialiseert 'm trouwens niet op NULL, maar op de naam van de variabele: als je de variabele blaat gebruikt dan krijgt 'ie de waarde 'blaat':

PHP:

var_dump ( $nonexistent );

Resultaat:
Notice: Undefined variable: nonexistent in ... on line ...
NULL

probeer maar eens:

PHP:

<?php
echo blaat;

Daar probeer je blaat als een constante te gebruiken. En bij een constante krijg je:

PHP:

var_dump ( nonexistent );

Resultaat:
Notice: Use of undefined constant nonexistent - assumed 'nonexistent' in ... on line ...
string(11) "nonexistent"

Kortom, een variabele is iets heel anders dan een constante, maar bij allebei krijg je een hele degelijke notice. Als je die als programmeur niet ziet, ben je een prutser, want wie ontwikkelt er nou met onderdrukte notices? Dat is vragen om bugs.

Bij C lijkt het standaard initialiseren op NULL me trouwens niet zo'n probleem, omdat je daar toch de variabelen declareert?

Dat ligt eraan hè? Als je iets initialiseert met NULL, en je gebruikt het daarna verkeerd, heb je toch echt een segmentation fault.

[ValHallASW]

Anoniem: 26306 schreef op zaterdag 22 september 2007 @ 13:32:
Dat ligt eraan hè? Als je iets initialiseert met NULL, en je gebruikt het daarna verkeerd, heb je toch echt een segmentation fault.

Ja, en anders dan staat er in wat er toevallig nog in het geheugen stond... dat is een handigere inhoud wil je zeggen? Het enige nadeel wat ik kan bedenken is dat je makkelijk de fout in kunt gaan als je er vanuit gaat dat de variabele op NULL geinitialiseerd wordt... wordt vervelend bij een andere compiler

[Voutloos]

flowerp schreef op zaterdag 22 september 2007 @ 12:28:
[...]
Dat is geen error, maar een notice of te wel een warning. Een fatal error lijkt me beter op z'n plaats hier eigenlijk. Die zijn iets moeilijker te negeren

Het is op zich prima als feature te gebruiken. Of het een nette stijl is om dat te doen is een tweede. Verder moet je gewoon altijd devven met een enigszins kritische error_reporting level.

Maar goed, dit is het slechte programmeervoorbeelden topic, niet het 'grote-verkondig-maar-hoe-onbekend-je-bent-met-de-'features'-van-PHP'-topic.

[H!GHGuY]

Deze week bug gevonden in onze software

Heb de voorbeeldcode wat geabstraheerd:

C++:

class CSomething
{
  public:
    CSomething* Clone();
    void SetValue(ULONG Value);
// Veel meer
}
typedef boost::shared_ptr<CSomething> PSomething;

void CSomeClass::SetSomething(PSomething& Something)
{
   m_pSomething = PSomething(Something->Clone());
   Something->SetValue(this->GetValue());
}

All repeat after me: premature optimization is ...

De boosdoener (Clone) was natuurlijk slechts recent toegevoegd, maar zelfs dan moet je je member gebruiken ipv de parameter.

[flowerp]

ValHallASW schreef op zaterdag 22 september 2007 @ 13:11:
Bij C lijkt het standaard initialiseren op NULL me trouwens niet zo'n probleem, omdat je daar toch de variabelen declareert?

Nou, in de hele oude versies van C werd een niet gedeclareerde variabele automatisch als een int gezien , die dan waarschijnlijk op 0 werd geïnitialiseerd.

Dus iets als het volgende was mogelijk:

C:

foo = 10; // geen decl. wel init.

printf ( "De waarde van foo is %d", foo );

bar++; // geen decl. geen init.

printf ( "De waarde van bar is %d", bar );

Ik heb dit niet getest btw, maar zo herinner ik het me.

Dat dit ok zou zijn omdat de compiler een warning gaf is natuurlijke dikke onzin. De hele vroege C compiler gaven namelijk ook al warnings als je dit probeerde. Omdat C enorm veel gebruikt werd en er dus enorm veel ervaring kwam op het gebied van wat wel en niet werkte, hebben ze dit in een latere versie van C verboden. Het leverde gewoon -te veel- problemen op.

Maar goed, dit is het slechte programmeervoorbeelden topic, niet het 'grote-verkondig-maar-hoe-onbekend-je-bent-met-de-'features'-van-PHP'-topic.

Uhm, maar het -is- toch een slecht programmeervoorbeeld om variabelen niet te declareren en te initialiseren? Als je dat nu nog steeds doet dan heb je weinig geleerd van de 40+ jaar dat men nu al aan software development doet.