[alg] slechtste prog voorbeelden.

[Olaf van der Spek]

Paul Nieuwkamp schreef op zondag 15 mei 2005 @ 14:28:
Als je een getal als boolean kunt gebruiken geeft dat toch aan dat een boolean een (subset van) een getal is,

Nee. Het geeft aan dat er een functie/mapping bestaat van getal -> boolean. Stel dat je een (complexe) class hebt (C++ voorbeeld) die je ook als boolean kunt gebruiken, dan maakt dat een boolean toch ook geen (subset van) die class?

ie er zit iets in die boolean waardoor je het met een getal kunt vergelijken?

Ofwel dat, of je bent iets totaal aan het verkrachten. Ja je kunt een kam ook gebruiken als hamer, maar dat is dus een ranzige oplossing. Als je een spijker in de muur wilt slaan moet je daarvoor een hamer gebruiken en geen kam, en als je wilt weten of een pointer nil is moet je daarop testen en geen boolean gebruiken -> ranzig gebruik van de mogelijkheden.

Als je aanneemt dat de taal zorgvuldig is ontworpen dan hebben de ontwerpers die optie er expliciet in gezet. Ofwel om backwards compatibility of bijvoorbeeld toch omdat ze het geen ranzige constructie vinden.

Nu loop je te mierenneuken over mijn aanname van het implementatiedetail pointer = getal. Stel: pointer = getal. Hoe wilde je het dan doen? Schijnbaar is in jouw programmeertaal ergens afgesproken dat nil gelijkstaat aan false, want anders zou je niet (succesvol) een boolean operator kunnen gebruiken op iets van het type pointer.

Gelijk staan 'werkt' twee kanten op. In dit geval klopt dat misschien, maar in het algemeen niet. nil als false gebruiken vind ik ok, false als nil gebruiken niet. Neem bijvoorbeeld true. 1 -> true, 2 -> true, 3 -> true, maar true -> ?

Wat denk je zelf? if (nil = false) then echo "Ze zijn gelijk", dat is immers waar je schijnbaar met !P op aan het testen bent.

[...]
Met !P ofwel de inverse van P zou je zomaar kunnen bedoelen: De pointer naar het adres waarvan alle bitjes precies andersom staan dan in P..

Zou kunnen ja. In C++ heb je daar ~ voor (! is een logische operatie, ~ bitwise).

Dat iemand bij het ontwikkelen van de programmeertaal heeft besloten dat dat je een pointer kunt evalueren als boolean door op dat moment die pointer te vergelijken met nil is helemaal niet vanzelfsprekend, je zou net zo goed kunnen vergelijken met 1 van de andere 4 miljard mogelijke waarden.

Dat vind ik helemaal niet 'net zo' goed. Vergelijken met nil doe ik in elk programma. Vergelijken met een bepaald adres niet. Bovendien is het omdraaien van bitjes weer een implementatie detail.

'Vroeger' (in Turbo Pascal) was een (far) pointer trouwens een combinatie van twee getallen.

Door !P te gebruiken beschouw je op dat moment P als boolean, waardoor hij van 4 miljard mogelijkheden er opeens nog maar 2 heeft, en is het aan de programmeur om maar in de specificaties van de programmeertaal om op te zoeken welke 3,999,999,998 mogelijkheden weg zijn gevallen.
Een pointer is geen boolean en dus vind ik !P ranzig.

P <> nil heeft toch ook maar twee mogelijkheden?
Ik beschouw !P inderdaad als boolean dan ja, maar P niet.

[ Voor 4% gewijzigd door Olaf van der Spek op 15-05-2005 16:00 ]

[Paul]

OlafvdSpek schreef op zondag 15 mei 2005 @ 15:57:
[...]

Nee. Het geeft aan dat er een functie/mapping bestaat van getal -> boolean. Stel dat je een (complexe) class hebt (C++ voorbeeld) die je ook als boolean kunt gebruiken, dan maakt dat een boolean toch ook geen (subset van) die class?

Nee, maar dan heb m.i. toch echt zelf iets geimplementeerd waardoor je aan de klasse een true of een false kunt hangen en hebben je gebruikers van die klasse maar te gokken wat dat is.

nil als false gebruiken vind ik ok

Daarover verschillen we van mening. Het betekend allebei iets anders

false als nil gebruiken niet

Is het ook niet

Neem bijvoorbeeld true. 1 -> true, 2 -> true, 3 -> true, maar true -> ?

Wat weer een implementatiedetail is van een taal waarbij ik gok dat 0 false moet zijn en de rest true. Als dan tevens de constante nil is gedefineerd als een getal met waarde 0 dan kun je inderdaad !P doen.
Je zit dan wel dmv implementatiedetails de waarden van je variabele te vergelijken met iets wat in een andere subklasse met dezelfde superklasse maar een compleet andere symantische betekenis toevallig dezelfde waarde heeft.

P <> nil heeft toch ook maar twee mogelijkheden?
Ik beschouw !P inderdaad als boolean dan ja, maar P niet.

P <> nil is een vergelijking tussen 2 dingen van het type pointer, en uit een vergelijking komt altijd een boolean rollen.
Door !P te gebruiken pas je een boolean operator toe op iets van het type Pointer, waardoor je Pointer in wezen cast naar een boolean, een cast waarbij een hoop informatie verloren gaat. Aangezien je het verder nergens gebruikt of terugcast of zo zal je compiler er niet over zeuren maar je bent daar mijns inziens P wel degelijk aan het ge/misbruiken als een boolean

[Guldan]

Johnny schreef op zondag 15 mei 2005 @ 14:54:
Wat me opvalt is dat in veel van deze voorbeelden veel Nederlandse bestandsnamen, commentaar en code wordt gebruikt, doen jullie dat in het echt ook?

Ik vind het namelijk vaak nogal ranzig om Nederlands te gebruiken in een op Engels gebaseerde programmeertaal.

Veel van mijn klasgenoten doen dat ook, ze vinden dat ze goed bezigf zijn omdat ze hun klassenamen netjes met hoofdletters beginnen, maarvervolgens geven ze al die klassen, methoden en variablen en commentaar een boeren-klompen-Nederlandse naam.

euh kijk dat verschilt. Mits ik iets programmeer wat in een engelse omgeving gebruik zou worden dan zou ik commentaar en alles ook in het engels doen. Klassenamen methoden etc. Schrijf ik iets voor mijzelf waarvan de kans zeer klein is dat een engelstalig persoon die code zou moeten gebruiken dan doe ik het netjes in het nederlands. Het gaat bij een beetje om wie de code zou kunnen gebruiken.
sowieso zou ik geen boerenklompen namen geven. Variablen moeten een duidelijke naam hebben de rest van je programma ook.

[ Voor 6% gewijzigd door Guldan op 15-05-2005 17:24 ]

[Olaf van der Spek]

Paul Nieuwkamp schreef op zondag 15 mei 2005 @ 16:44:
Nee, maar dan heb m.i. toch echt zelf iets geimplementeerd waardoor je aan de klasse een true of een false kunt hangen en hebben je gebruikers van die klasse maar te gokken wat dat is.

Inderdaad. Maar dat maakt bool er toch nog geen subset van?

Wat weer een implementatiedetail is van een taal waarbij ik gok dat 0 false moet zijn en de rest true.

Het was een voorbeeld om aan te geven dat 'gelijk staan aan' niet hetzelfde is als 'er bestaat een functie/mapping tussen'.

P <> nil is een vergelijking tussen 2 dingen van het type pointer, en uit een vergelijking komt altijd een boolean rollen.
Door !P te gebruiken pas je een boolean operator toe op iets van het type Pointer, waardoor je Pointer in wezen cast naar een boolean, een cast waarbij een hoop informatie verloren gaat. Aangezien je het verder nergens gebruikt of terugcast of zo zal je compiler er niet over zeuren maar je bent daar mijns inziens P wel degelijk aan het ge/misbruiken als een boolean

Jij vindt deze impliciete cast dus niet kunnen. Andere impliciete casts wel?

[ Voor 28% gewijzigd door Olaf van der Spek op 15-05-2005 17:42 ]

[Paul]

OlafvdSpek schreef op zondag 15 mei 2005 @ 17:39:
[...]

Inderdaad. Maar dat maakt bool er toch nog geen subset van?

Daar was ik in mijn vorige post inderdaad ook al vanaf gestapt

Jij vindt deze impliciete cast dus niet kunnen. Andere impliciete casts wel?

De enige impliciete casts die ik zo ken zijn de diverse simpele types naar een string in Java, en daar heb ik geen problemen mee

[Verwijderd]

whoami schreef op donderdag 21 augustus 2003 @ 19:14:
[...]


Ik snap het niet hoor. Een sequence zorgt er toch voor dat je altijd een unique value hebt. Dus die value kan nooit 2x voorkomen.
Maar die gast gaat wel zelf zijn integriteit mogelijk gaan vernaggelen door met die select max() te gaan prutsen.
Djeez. Vage gasten.

Als ik me niet vergis kan het resultaat van een Sequence al eens de mist ingaan, mits het nodige handmatige geklooi om de boel absoluut zeker te kunnen verbrodden.
Als ik via TOAD manueel records invoeg 'eist' hij dat ik reeds een ID meegeef (of ik verwacht nu een goeie TOAD tip, een van de redenen voor deze reply ).
Als ik daarna (enkele dagen/weken later, in de testomgeving natuurlijk) via de applicatie wat test en een EJBException krijg zit je ongelooflijk lang te zoeken terwijl een gewone tweede poging zou passeren.

Wat die PL/SQL zou moeten doen is eerder de sequence updaten (en wat ik zou moeten doen voor een insert is ook de sequence.nextval gebruiken ipv handmatig een ID ingeven natuurlijk )

[flowerp]

OlafvdSpek schreef op zondag 15 mei 2005 @ 15:57:
[...]
Nee. Het geeft aan dat er een functie/mapping bestaat van getal -> boolean. Stel dat je een (complexe) class hebt (C++ voorbeeld) die je ook als boolean kunt gebruiken, dan maakt dat een boolean toch ook geen (subset van) die class?

Technisch gezien heb je natuurlijk gelijk Olaf, maar waar het in dit topic over gaat is toch een beetje style kwesties. Dingen werken wel, maar hoeven niet perse 'mooi' te zijn. Wat je met operator ! en een pointer doet is gebruik maken van een implementatie detail. In dit geval is dit detail wel vastgelegd in de standaard, maar het blijft een detail wat min of meer toevallig klopt.

Kijk maar even mee:

1) Je wilt weten of een pointer wel of niet naar een geldig address address wijst.
2) 'toevallig' is afgesproken dat het allereerste address ( nr. 0 ) nooit geldig is.
3) 'toevallig' is afgesproken dat integers (met in het bijzonder geval 0) naar een pointer gecast kan worden.
4) Operator ! werkt zonder overloading op booleans
5) 'toevallig' is afgesproken dat een integer met waarde 0 impliciet naar false gecast kan worden en alle andere getallen naar true.

Door deze samenhang van toevalligheden kun je ! gebruiken om een pointer op NULL te testen.

Echter, puristen stellen dat ! een logische operator moet zijn en niks anders. if ( !(expr) )is dus equivalent aan if ( expr == false ) en zou je ook altijd zo moeten lezen. Je moet toch toegeven dat if ( ptr == false ) een tikkeltje vreemd is. Je wilt dit ook helemaal niet weten, je wilt weten of ie NULL is of niet.

Nu kun je stellen, een ptr kan 2 toestanden: geldig of niet geldig, en dat past perfect binnen een boolean. Echter, NULL is maar 1 van de ongeldige toestanden. Een niet NULL kan net zo goed ongeldig zijn. Daarom is if ( ptr == NULL ) een stuk duidelijker en explicieter: je geeft precies aan wat je wil testen, en maakt geen gebruik van het feit dat integers naar pointer gecast kunnen worden etc.

In de volgende C++ versie zal de integer 0 als NULL pointer deprecated worden en vervangen worden door 'nullptr'. Testen op NULL zal dan gebeuren door iets als if ( ptr == nullptr ). Gebruik maken van het ! truukje zal dan eigenlijk ook een deprecated smaakje hebben.

Je ziet in tenminste nog een plek dat operator ! misbruikt wordt in C++. Voor het openen van een file met een iostream. ios::operator! is daar gedefineerd als gelijk aan de member function fail. Als je dan iets leest als if (!fout). Wat is het dan?

1) if ( fout == false )
2) if ( fout == null )
3) if ( fout.fail() == true )

Natuurlijk kun je dit wel weer uit de context halen, maar het verslechterd de readability behoorlijk.

[Olaf van der Spek]

flowerp schreef op zondag 15 mei 2005 @ 23:41:
Wat je met operator ! en een pointer doet is gebruik maken van een implementatie detail. In dit geval is dit detail wel vastgelegd in de standaard, maar het blijft een detail wat min of meer toevallig klopt.

Kijk maar even mee:

1) Je wilt weten of een pointer wel of niet naar een geldig address address wijst.
2) 'toevallig' is afgesproken dat het allereerste address ( nr. 0 ) nooit geldig is.
3) 'toevallig' is afgesproken dat integers (met in het bijzonder geval 0) naar een pointer gecast kan worden.

Eh, in C++ kun je een integer helemaal niet naar een pointer casten (behalve met reinterpret_cast, maar daar kan alles mee). Alleen 0 kun je casten.
Dat het 'toevallig' goed uitkomt betekent niet dat de compiler in het geval het niet toevallig zou uitkomen geen complexere cast zou kunnen doen.
Stel dat een bepaalde hardware architectuur een bit van de pointer gebruikt voor NULL vs niet-NULL. Dan kan de compiler dat bit gebruiken bij de cast naar bool.

4) Operator ! werkt zonder overloading op booleans
5) 'toevallig' is afgesproken dat een integer met waarde 0 impliciet naar false gecast kan worden en alle andere getallen naar true.

Waarom zou de cast pointer -> bool via integer lopen?

Door deze samenhang van toevalligheden kun je ! gebruiken om een pointer op NULL te testen.

Echter, puristen stellen dat ! een logische operator moet zijn en niks anders. if ( !(expr) )is dus equivalent aan if ( expr == false ) en zou je ook altijd zo moeten lezen. Je moet toch toegeven dat if ( ptr == false ) een tikkeltje vreemd is. Je wilt dit ook helemaal niet weten, je wilt weten of ie NULL is of niet.

Nu kun je stellen, een ptr kan 2 toestanden: geldig of niet geldig, en dat past perfect binnen een boolean. Echter, NULL is maar 1 van de ongeldige toestanden. Een niet NULL kan net zo goed ongeldig zijn. Daarom is if ( ptr == NULL ) een stuk duidelijker en explicieter: je geeft precies aan wat je wil testen, en maakt geen gebruik van het feit dat integers naar pointer gecast kunnen worden etc.

Als een niet NULL pointer ongeldig is en je daarop nog zou moeten testen dan zit er natuurlijk wel een bug in je code.

In de volgende C++ versie zal de integer 0 als NULL pointer deprecated worden en vervangen worden door 'nullptr'. Testen op NULL zal dan gebeuren door iets als if ( ptr == nullptr ). Gebruik maken van het ! truukje zal dan eigenlijk ook een deprecated smaakje hebben.

Je ziet in tenminste nog een plek dat operator ! misbruikt wordt in C++. Voor het openen van een file met een iostream. ios::operator! is daar gedefineerd als gelijk aan de member function fail. Als je dan iets leest als if (!fout). Wat is het dan?

1) if ( fout == false )
2) if ( fout == null )
3) if ( fout.fail() == true )

Natuurlijk kun je dit wel weer uit de context halen, maar het verslechterd de readability behoorlijk.

1 en 3 lijkt mij.

Maar in het algemeen vind ik vooral in wat complexere expressies de korte versies (zonder != NULL of != 0) veel handiger. De tweede versie dan natuurlijk voor integer -> bool.

[ Voor 4% gewijzigd door Olaf van der Spek op 16-05-2005 00:27 ]

[flowerp]

OlafvdSpek schreef op maandag 16 mei 2005 @ 00:24:
Waarom zou de cast pointer -> bool via integer lopen?

Omdat nergens in de standaard staat dat pointer (impliciet) naar bool gecast wordt. Ook het speciale 0 geval niet.

Als een niet NULL pointer ongeldig is en je daarop nog zou moeten testen dan zit er natuurlijk wel een bug in je code.

Sure maar het gaat om de uitdrukking van de programmeur. Met ! geef je aan dat je test op 1 van de 2 toestanden: waar/niet waar. Met == null geef je expliciet aan dat je test op een bepaalde toestand, te weten de speciale null toestand.

Met == null ben je explicieter, duidelijker en beter leesbaar.

Hou je van cryptische, moeilijk leesbare code, gebruik dan veel !; vooral leuk icm pointers ophogen en testen op \0 aan het einde van een string. Vooral leuk als je een oude verstokte C programmeur ben. In C++ is het eigenlijk de bedoeling dat je wat higher-level bezig bent. De C inheritance zit daarbij alleen maar in de weg. Dat je bv char* -kunt- gebruiken wil niet zeggen dat je dat altijd -moet-. std::string is een veel beter alternatief. Icm met de iterators hoef je dan ook niet op \0 te checken.

Zo moet je operator ! icm null pointers ook zien.

Het is oude style die uit C komt. Met de komst van nullptr geeft zelfs het C++ standard comittee aan dat ze liever zien dat je == nullptr schrijft. (null is ook maar een hack, aangezien dit een macro voor 0 is). Ook kun je dan veel makkelijker naar C/C++ afgeleide talen switchen als Java of C#. In beide is !ptr geen geldige expressie.

[Olaf van der Spek]

flowerp schreef op maandag 16 mei 2005 @ 12:52:
Omdat nergens in de standaard staat dat pointer (impliciet) naar bool gecast wordt. Ook het speciale 0 geval niet.

En waarom zou er dan via een integer 'gecast' worden?

Het is oude style die uit C komt. Met de komst van nullptr geeft zelfs het C++ standard comittee aan dat ze liever zien dat je == nullptr schrijft.

Eh, waarom?
nullptr is er (in de eerste plaats) om problemen met 0, NULL en (void*)0 te voorkomen. Waarom zou het comittee dan ineens ook liever zien dat je == nullptr schrijft?

[ Voor 40% gewijzigd door Olaf van der Spek op 16-05-2005 13:37 ]

[flowerp]

OlafvdSpek schreef op maandag 16 mei 2005 @ 13:18:
[...]
En waarom zou er dan via een integer 'gecast' worden?

Omdat bv via struct { int foo; int bar; } casten niet zo zinnig is.

Eh, waarom?
nullptr is er (in de eerste plaats) om problemen met 0, NULL en (void*)0 te voorkomen. Waarom zou het comittee dan ineens ook liever zien dat je == nullptr schrijft?

Omdat je duidelijker en sneller twee keer een nullptr met elkaar vergelijkt. Als ptr null is dan vergelijk je steeds meer: nullptr == nullptr. Dit is veel efficienter als nullptr.operator!() aanroepen.

[Olaf van der Spek]

flowerp schreef op maandag 16 mei 2005 @ 14:39:
Omdat bv via struct { int foo; int bar; } casten niet zo zinnig is.

Dat betekent nog steeds niet dat het via een integer gaat.

Omdat je duidelijker en sneller twee keer een nullptr met elkaar vergelijkt. Als ptr null is dan vergelijk je steeds meer: nullptr == nullptr. Dit is veel efficienter als nullptr.operator!() aanroepen.

Over dat soort issues laat ik de compiler/optimizer zich zorgen maken.

[Soultaker]

flowerp schreef op zondag 15 mei 2005 @ 23:41:
2) 'toevallig' is afgesproken dat het allereerste address ( nr. 0 ) nooit geldig is.
3) 'toevallig' is afgesproken dat integers (met in het bijzonder geval 0) naar een pointer gecast kan worden.

Dat is eigenlijk niet eens zo; er is zoiets als een null-pointer (en die kun je construeren door het getal 0 naar een pointer te converteren) maar dat dat een pointer is die naar adres 0 verwijst hoeft helemaal niet zo te zijn.

Het is trouwens wel een aardige vraag hoe je op een portable manier dan een pointer naar adres 0 zou kunnen krijgen (daar wil nog wel eens wat interessante data staan, zoals een interrupt vector ofzoiets). Je zou dan dus (char*)0 ofzo willen schrijven, maar eigenlijk kan dat dus niet, want dat is dan een null-pointer. (In de praktijk zijn dit soort dingen al zo platformafhankelijk dat je je hier niet zoveel zorgen over maakt en ervan uitgaat dat je wéét hoe de compiler pointers representeert.)

Verder is het inderdaad een vraag over hoe breed operatoren geïmplementeerd kunnen worden (werkt operator! alleen op booleans of ook op andere typen?) en hoeveel impliciete/expliciete conversies je wil toestaan. Tja, daar kun je lang over lullen natuurlijk, maar smaken verschillen.

Zelf vind ik if(p) totaal niet onduidelijk, maar ik ben ook wel heel wat C/C++ gewend. Het leest voor mij als: 'als p geldig is, dan ..., anders ...'.

[flowerp]

OlafvdSpek schreef op maandag 16 mei 2005 @ 15:19:
[...]
Dat betekent nog steeds dat het via een integer gaat.

Uhm, dan zijn we het toch eens?

Over dat soort issues laat ik de compiler/optimizer zich zorgen maken.

Ik vraag me overigens af hoe dit gaat werken. Compile-time weet de compiler helemaal niet of een pointer een bare pointer is of een nullptr.

Stel:

C++:

void bar( char* foo ) {

   if ( !foo ) {
      std::cout << "null pointer" << endl;
   }
}

int main() {
   int check = 0;
   std::cin >> check;

   if ( check == 0 ) {
      bar ( 0 );
   }
   else {
      bar ( std::nullptr ); // std::nullptr is a guess to how nullptr will be specified of course
   }
}

Hoe gaat de compiler nu bepalen dat de code voor bar omgezet moet gaan worden in foo == nullptr ?

[Soultaker]

Lees mijn vorige post (hier direct boven) ook nog eens.

De compiler heeft een bepaalde representatie van een nullpointer. Als integer 0 of std::nullptr naar een pointer wordt geconverteerd (zoals bij de call naar functie bar) dan komt in argument foo dus een speciale waarde te staan die 'm identificeert als null-pointer. (Op x86 is dat gewoon het getal 0, in principe, maar dat in het algemeen is dat een interne zaak van de compiler.)

Vervolgens gebruik je de !-operator die op een boolean werkt; daarvoor moet de waarde van foo eerst omgezet worden in een boolean, waarbij de speciale null-pointer waarde simpelweg false wordt en elke andere waarde true. (En gangbare compilers op de x86 hoeven dan niets speciaals te doen en kunnen foo gewoon als integer behandelen, als de null-pointer toch al als 0 in het geheugen wordt gerepresenteert).

Dat op de x86 de integer 0 in het geheugen overeenkomt met de bijbehorende null-pointer is min of meer toevallig (niet helemaal natuurlijk ), maar het gaat bijvoorbeeld al niet meer op als je een gesegmenteerd memory model gebruikt (de x86 ondersteund dat ook i.c.m. 32-bits offsets, al ken ik geen besturingssysteem wat dat feitelijk ondersteund).

edit:
Oh ja, het is echt onzin om te stellen dat (!ptr) minder efficïent is dan (ptr == 0) of (ptr == std::null) (of juist andersom); zelfs de meest basic compiler herkent dit als equivalente expressies en genereert er equivalente code voor. Hoe je het schrijft is dus puur een kwestie van smaak.

[ Voor 30% gewijzigd door Soultaker op 16-05-2005 17:17 ]

[Olaf van der Spek]

flowerp schreef op maandag 16 mei 2005 @ 16:56:
Uhm, dan zijn we het toch eens?

Nee, ik was het woord 'niet' vergeten.

[flowerp]

OlafvdSpek schreef op maandag 16 mei 2005 @ 17:16:
[...]

Nee, ik was het woord 'niet' vergeten.

En ik was het woord "nog steeds niet" vergeten.

[flowerp]

Soultaker schreef op maandag 16 mei 2005 @ 17:12:
edit:
Oh ja, het is echt onzin om te stellen dat (!ptr) minder efficïent is dan (ptr == 0) of (ptr == std::null) (of juist andersom); zelfs de meest basic compiler herkent dit als equivalente expressies en genereert er equivalente code voor. Hoe je het schrijft is dus puur een kwestie van smaak.

Niet helemaal in het geval van nullptr. Ik snap dat je er snel overheen leest (ze lijken nogal op elkaar), maar ik bedoel dus niet de null die een macro is voor 0.

nullptr is een globaal en const object. Als je hierop operator! loslaat, dan zeg je niet nullptr == false, maar nullptr.operator!(). In het geval van == 0 zal operator== overloaded worden, etc.

Bij dergelijke vergelijkingen doe je dus een function call. Bij ptr == nullptr hoeft de compiler niet de funtion call te genereren, maar kunnen direct de adresen vergeleken worden. Natuurlijk zit je dan nog wel met je compatibiliteit met null pointers die door 0 worden gerepresenteerd. Ik 'neem aan' dat de compiler in de praktijk iets zal genereren als ptr == nullptr || ptr == null.

Maar mischien dat de nieuwere compilers ook wel voor elke logische operator op een pointer dezelfde code sequence gaan genereren. Operator! is natuurlijk niet virtual gedefineerd op een bare pointer, dus bij naderinzien kan die function call die ik eerder noemde helemaal niet.

[whoami]

code:

Convert.ToBoolean (0);

ipv gewoon false te schrijven.

[OkkE]

Volgens mij is dit niet echt het beste voorbeeld van gebruik van functies..

JavaScript:

<script language="JavaScript" type="text/JavaScript">
<!--
function aanligging(id){
    document.getElementById('ligging').style.backgroundColor='#101585';
    }
function uitligging(id){
    document.getElementById('ligging').style.backgroundColor='#A9112A';
    }
function aaninfo(id){
    document.getElementById('info').style.backgroundColor='#101585';
    }
function uitinfo(id){
    document.getElementById('info').style.backgroundColor='#A9112A';
    }
function aanlinks(id){
    document.getElementById('links').style.backgroundColor='#101585';
    }
function uitlinks(id){
    document.getElementById('links').style.backgroundColor='#A9112A';
    }
// Enz... enz... enz...
//-->
</script>

[ Voor 49% gewijzigd door OkkE op 18-05-2005 11:41 . Reden: Eventjes ietsjes ingekort :) ]

[Verwijderd]

Iemand vroeg waarom dit niet werkte:

while(malloc(1000) != 0)
{
geheugen =+ 1000;
}

cout << "Er is nog " << geheugen << " bytes aan geheugen vrij!";

[Soultaker]

Hmm, dat werkt toch wel een klein beetje, aangenomen dat je meteen daarna je proces afsluit? Niet dat het getal dat je krijgt echt zinnig is, maar het is een maat van hoeveel geheugen een proces ongeveer kan alloceren. (Of doelde je op de =+ ipv. +=?)

[ Voor 34% gewijzigd door Soultaker op 18-05-2005 19:07 ]

[MSalters]

Werkt zolang cout << geen malloc gebruikt

[Olaf van der Spek]

Die =+ is inderdaad wel leuk.
En als je geluk hebt is er voor cout nog net genoeg geheugen vrij om te werken.

Veel apps werken trouwens niet meer lekker als het geheugen op is.
Is er geen optie in Windows om de app die het meeste geheugen gebruikt te killen als er geen geheugen meer over is?

[ Voor 25% gewijzigd door Olaf van der Spek op 19-05-2005 13:39 ]

[dotcode]

Het moet zijn:
Er was nog .... geheugen vrij voor mijn app.

Vrijgeven zal niet meer gaan ...

Misschien moet je ook in k gaan praten, je teller zal wel te klein zijn....

[ Voor 29% gewijzigd door dotcode op 19-05-2005 13:56 ]

[Olaf van der Spek]

dotcode schreef op donderdag 19 mei 2005 @ 13:55:
Misschien moet je ook in k gaan praten, je teller zal wel te klein zijn....

Nee hoor, die teller komt niet verder dan 1000.

[Nielsz]

PHP:

  function decodedateinput($selectName)
  {
    $Y =  $selectName."Year";
    $M =  $selectName."Month";
    $D =  $selectName."Day";
    $H =  $selectName."Hour";
    $m =  $selectName."Minute";
    global $$Y, $$M, $$D, $$H, $$m;
    return str_pad($$Y, 4, "0", STR_PAD_LEFT)."-". str_pad($$M, 2, "0", STR_PAD_LEFT)."-".str_pad($$D, 2, "0", STR_PAD_LEFT). " " . str_pad($$H, 2, "0", STR_PAD_LEFT) . ":" . str_pad($$m, 2, "0", STR_PAD_LEFT) . ":00";
  }

wtf echt

[LuCarD]

Nielsz schreef op donderdag 19 mei 2005 @ 14:05:

PHP:

  function decodedateinput($selectName)
  {
    $Y =  $selectName."Year";
    $M =  $selectName."Month";
    $D =  $selectName."Day";
    $H =  $selectName."Hour";
    $m =  $selectName."Minute";
    global $$Y, $$M, $$D, $$H, $$m;
    return str_pad($$Y, 4, "0", STR_PAD_LEFT)."-". str_pad($$M, 2, "0", STR_PAD_LEFT)."-".str_pad($$D, 2, "0", STR_PAD_LEFT). " " . str_pad($$H, 2, "0", STR_PAD_LEFT) . ":" . str_pad($$m, 2, "0", STR_PAD_LEFT) . ":00";
  }

wtf echt

Dit is toch gewoon logisch? je krijgt waarschijnlijk van je form ( dropdown?) 5 variablen terug, deze hebben allemaal de naam $selectName "Year", etc. En deze wil hij in een standaard formaat terug, waarschijnlijk voor de database?

Ik zou het ook zo doen....

[Glimi]

LuCarD schreef op donderdag 19 mei 2005 @ 14:41:
[..]
Ik zou het ook zo doen....

Die str_pad zou ik in ieder geval al vervangen hebben door een sprintf.

[Erkens]

LuCarD schreef op donderdag 19 mei 2005 @ 14:41:
[...]


Dit is toch gewoon logisch? je krijgt waarschijnlijk van je form ( dropdown?) 5 variablen terug, deze hebben allemaal de naam $selectName "Year", etc. En deze wil hij in een standaard formaat terug, waarschijnlijk voor de database?

Ik zou het ook zo doen....

ten eerste zou ik een array gebruiken, maar vooral _geen_ global variabele variabelen
ik moest echt 3x kijken voor ik door had wat daar gebeurde

[Nielsz]

Variabelen niet via argumenten maar via globals doen. En dan geen gewone globals, maar $$globals, oftewel globale variabele variabelen. Ofzo

[4of9]

kwam ik tegen in code van een ander bedrijf dat ik moet debuggen:

Visual Basic:

If Doc.engineEdit Then
  retval = True
  retval = False
Else
  retval = False
End If

[ Voor 11% gewijzigd door 4of9 op 19-05-2005 16:50 ]

[jelmervos]

En dat was een bug, of is die code ook echt zo bedoeld?

[riezebosch]

4of9 schreef op donderdag 19 mei 2005 @ 16:50:
kwam ik tegen in code van een ander bedrijf dat ik moet debuggen:

Visual Basic:

If Doc.engineEdit Then
  retval = True
  retval = False
Else
  retval = False
End If

Lijkt me trouwens foutje in de highlighting van GoT dat ie "True" groen en "False" blauw weergeeft?

[Paul]

4of9 schreef op donderdag 19 mei 2005 @ 16:50:
kwam ik tegen in code van een ander bedrijf dat ik moet debuggen:

Visual Basic:

If Doc.engineEdit Then
  retval = True
  retval = False
Else
  retval = False
End If

Het is dat het VB-code is, maar in Delphi zou het kunnen. Dan moet retval een property van een klasse zijn waar een set-procedure aan hangt die iets uitvoerd als er True meegegeven wordt.
Blijft het toch ranzig, want schijnbaar is die code niet op een andere manier te bereiken maar moet die vaker uitgevoerd worden dan alleen wanneer retval True wordt, namelijk ook als Doc.engineEdit op dat moment nog true is Dan zou het dus eigenlijk:

Delphi:

if Doc.EngineEdit then
  Voer_Code_Uit_Die_Ook_In_retval_Setter_Staat; 
  // of eigenlijk, in deze implementatie _staat_ hij daar niet maar wordt 
  // er wel aangeroepen als ze het goed doen
retval := false;

moeten zijn.

Ik heb op deze manier ook wel eens bugjes in 3rd party componenten op moeten lossen. Zie daar maar achter te komen... En uiteraard heb je dan de source niet dus krijg je dingen als achter elkaar true en vervolgens false zetten.
Daar moet vervolgens wel een hoop commentaar omheen, anders wordt het de volgende review weer vrolijk geschrapt

Edit @ hieronder: Zo goed ken ik VB niet

[Robtimus]

Paul Nieuwkamp schreef op donderdag 19 mei 2005 @ 17:27:
Het is dat het VB-code is, maar in Delphi zou het kunnen. Dan moet retval een property van een klasse zijn waar een set-procedure aan hangt die iets uitvoerd als er True meegegeven wordt.

Kan in VB ook:

Visual Basic:

Public Property Let Prop(ByVal value As String)
    ' Do stuff with value; possibly do other stuff
End Property

Maar blijft ranzig idd als het alleen zo te bereiken is.

[Bob]

Ons (3 studenten) allereertse prog-project; een RTS in modula-2, zou hier bijna in zijn geheel passen , maar bij dit stuk schaamde ik me laatst toch erg toen ik het terugzag:

code:

IF xx < VAL(INTEGER,prevposx)+1 THEN
    IF VAL(INTEGER,prevposx) < xx+35 THEN
        IF yy < VAL(INTEGER,prevposy)+1 THEN
            IF VAL(INTEGER,prevposy) < yy+35 THEN
                DrawSavedBitmap(20*(VAL(INTEGER,prevposx)+1-xx)-19, 20*(VAL(INTEGER,prevposy)+1-yy)-19, bitmapID[0]);
                Rectangle ((prevposx-xx)*20+1, (prevposy-yy)*20, (prevposx-xx)*20+22, (prevposy-yy)*20+21, 14,FALSE);
            END;
        END;
    END;
END;

Met AND zou dat uiteraard lichtjes properder zijn, maar in feite, komt dat voor de compiler niet op hetzelfde neer? IMO gaat het dan toch niet sneller uitvoerbaar zijn.

[H!GHGuY]

Bob_A schreef op maandag 23 mei 2005 @ 00:10:
Ons (3 studenten) allereertse prog-project; een RTS in modula-2, zou hier bijna in zijn geheel passen , maar bij dit stuk schaamde ik me laatst toch erg toen ik het terugzag:

code:

IF xx < VAL(INTEGER,prevposx)+1 THEN
    IF VAL(INTEGER,prevposx) < xx+35 THEN
        IF yy < VAL(INTEGER,prevposy)+1 THEN
            IF VAL(INTEGER,prevposy) < yy+35 THEN
                DrawSavedBitmap(20*(VAL(INTEGER,prevposx)+1-xx)-19, 20*(VAL(INTEGER,prevposy)+1-yy)-19, bitmapID[0]);
                Rectangle ((prevposx-xx)*20+1, (prevposy-yy)*20, (prevposx-xx)*20+22, (prevposy-yy)*20+21, 14,FALSE);
            END;
        END;
    END;
END;

Met AND zou dat uiteraard lichtjes properder zijn, maar in feite, komt dat voor de compiler niet op hetzelfde neer? IMO gaat het dan toch niet sneller uitvoerbaar zijn.

een goeie compiler optimaliseert dat idd...
maar soms vind ik het toch duidelijker om

C++:

if (a < b)
{
  if (b < c)
  {
    doeIets;
  }
}
else // a >=b
{
  if (a<c)
  {
    doeIets2;
  }
}

te schrijven ipv

C++:

if (a < b && b < c)
{
  doeIets;
}
else if (a >= b && a < c)
{
  doeIets2;
}

zeker als de kans dat je if-statements nog uitgebreider zullen worden, of als het algo zelf redelijk groot wordt, vind ik het eerste duidelijker te volgen. bovendien is het 1ste voorbeeld net 1 vergelijking sneller dan het 2de

[RobIII]

HIGHGuY schreef op maandag 23 mei 2005 @ 10:40:
bovendien is het 1ste voorbeeld net 1 vergelijking sneller dan het 2de

Uhm, niet als je compiler (of taal zeg maar, want niet alle talen (VB6 ) ondersteunen het) statement shortcuts gebruikt (dus als de eerste evaluatie false is, hoeft de tweede niet eens meer uitgevoerd te worden).

JavaScript:

<script language="JavaScript">
    if (confirm('Vraag a') && confirm('Vraag b')) {
        alert('Joehoe!');
    }

</script>

Beantwoord je vraag a met "ok" dan krijg je vraag b, anders vraagt 'ie er niet eens om...

[edit]
Grappig... Mijn RssReader (1.0.88) komt nu met een confirm "vraag a" pop-up als ik dit topic open

[ Voor 61% gewijzigd door RobIII op 23-05-2005 11:14 ]

[Olaf van der Spek]

RobIII schreef op maandag 23 mei 2005 @ 11:09:
[edit]
Grappig... Mijn RssReader (1.0.88) komt nu met een confirm "vraag a" pop-up als ik dit topic open

Hmm, paste de relevante code van die reader ook maar in dit topic dan.

[RobIII]

OlafvdSpek schreef op maandag 23 mei 2005 @ 11:17:
[...]

Hmm, paste de relevante code van die reader ook maar in dit topic dan.

Zie het code block
Ah ik snap je
Nee, zo bedoel ik "mijn" RssReader niet De RssReader is niet van "mij" maar ik gebruik hem....

Ik ben al een BUG melding aan 't maken

Is al opgelost

[ Voor 47% gewijzigd door RobIII op 23-05-2005 14:17 ]

[Sh0ckTr00per]

Ik kan het niet laten dit fraaie staaltje Foxpro code even te tonen..

code:

LParameters tnAflID, tnObjID

IF tnAflID > 0
  llBegin = .T.
ELSE
  llScan = .T.
ENDIF

IF tnObjID = 0 AND llScan 

ENDIF

Ik heb even alleen de structuur meegenomen voor het voorbeeld. Handig is in foxpro dat je variabelen niet hoeft te declareren..

[kenneth]

HIGHGuY schreef op maandag 23 mei 2005 @ 10:40:
een goeie compiler optimaliseert dat idd...

Lazy evaluation is taalafhankelijk, het zou wat zijn als dat compiler-afhankelijk is ...

... en opeens bekruipt me het gevoel dat er vast compilers zijn die het toch nog anders doen dan de specificatie

[mulder]

Sommige werken met oogkleppen op:

Visual Basic:

Select Case cInt(TRIM(m_ReturnCode))
    Case "01", "1":

[RobIII]

Kwam toevallig dit filmpje tegen (over hoe Pointers werken) bij Stanford University:
http://cslibrary.stanford.edu/104/
(Overigens verder wel correct, maar vond 'm wel leuk en wou er geen nieuw topic over openen).

[Verwijderd]

Haha, for this trick I need my magic wand of dereferencing

[dingstje]

Ben net de code van een collega studente beetje aan 't bekijken, en dit is toch wel een fraai stukje van de manier waarop men tegenwoordig leert programmeren...

Het komt uit een tooltje waarbij je een getal moet raden (leren werken met structuren en random numbers dus), dit is wat ze ervan bakte:

code:

...
intVerschil = intInput - intGetal
...
Loop Until intVerschil = 0

Met andere woorden, in plaats van te loopen tot intGetal = intInput, loopt ze tot het verschil van die twee getallen 0 is. Het werkt natuurlijk, maar...

[Verwijderd]

kenneth schreef op woensdag 25 mei 2005 @ 11:45:
[...]
Lazy evaluation is taalafhankelijk, het zou wat zijn als dat compiler-afhankelijk is ...

... en opeens bekruipt me het gevoel dat er vast compilers zijn die het toch nog anders doen dan de specificatie

Nee hoor, een compiler zou het nooit anders doen. Doet ie dat wel, dan is het een bug of een beta versie v/d compiler. Iha kan je altijd van lazy evaluation uitgaan als je taal dat specificeerd.

Wat nog wel eens voor verassingen kan zorgen (en waar beginners in kunnen trappen) is het feit dat in bijvoorbeeld C++ de evaluatie van parameters in functies niet vasstaat.

Bv:

[code=c++)

myfunc( globalSomething(), globalSomethingNext() );

[/code]

Een beginner wil nog wel eens denken dat globalSomething() wordt aangeroepen VOOR globalSomethingNext(), maar dat is niet zo. Dit is compiler afhankelijk. Als beide functies dus met de globale staat rommelen (of de class member data als myfunc een member function is), dan kan dit wel eens voor verassingen zorgen.

[Olaf van der Spek]

Verwijderd schreef op woensdag 25 mei 2005 @ 21:03:
Wat nog wel eens voor verassingen kan zorgen (en waar beginners in kunnen trappen) is het feit dat in bijvoorbeeld C++ de evaluatie van parameters in functies niet vasstaat.

Iets soortgelijkt had ik ook wel eens gedaan:

C++:

*w++ = 1;
*w++ = *w++ = *w++ = *w++ = *w++ = *w++ = 0;
*w++ = 2;

[ Voor 3% gewijzigd door Olaf van der Spek op 25-05-2005 21:45 ]

[Verwijderd]

OlafvdSpek schreef op woensdag 25 mei 2005 @ 21:45:
[...]
Iets soortgelijkt had ik ook wel eens gedaan:

En natuurlijk ook tenminste 1 keer bij het tentamen van programmeer methoden

[Erkens]

dingstje schreef op woensdag 25 mei 2005 @ 16:35:
Met andere woorden, in plaats van te loopen tot intGetal = intInput, loopt ze tot het verschil van die twee getallen 0 is. Het werkt natuurlijk, maar...

mja, dat kan handig zijn als je dat verschil nog nodig heb op andere punten binnen die loop. Ook met het oog op eventuele toekomstige uitbreidingen kan het handig zijn als je dan nog een keer dat verschil nodig hebt, scheelt weer een keer uitrekenen

[H!GHGuY]

RobIII schreef op maandag 23 mei 2005 @ 11:09:
[...]

Uhm, niet als je compiler (of taal zeg maar, want niet alle talen (VB6 ) ondersteunen het) statement shortcuts gebruikt (dus als de eerste evaluatie false is, hoeft de tweede niet eens meer uitgevoerd te worden).

JavaScript:

<script language="JavaScript">
    if (confirm('Vraag a') && confirm('Vraag b')) {
        alert('Joehoe!');
    }

</script>

Beantwoord je vraag a met "ok" dan krijg je vraag b, anders vraagt 'ie er niet eens om...

[edit]
Grappig... Mijn RssReader (1.0.88) komt nu met een confirm "vraag a" pop-up als ik dit topic open

ik had et niet op lazy evaluation:
als a >= b dan worden in de eerste if 1 of 2 vergelijkingen (afh van de taal) gedaan.
en dan wordt in de else-if nogmaals gecontroleerd of a > b en dat is een vergelijking te veel.

overigens kun je in vb6 wel lazy evaluation maken door het eerste codevoorbeeld van me te gebruiken.

kenneth schreef op woensdag 25 mei 2005 @ 11:45:
[...]
Lazy evaluation is taalafhankelijk, het zou wat zijn als dat compiler-afhankelijk is ...

... en opeens bekruipt me het gevoel dat er vast compilers zijn die het toch nog anders doen dan de specificatie

eigenlijk is die vorm al geoptimaliseerd..
want in assemblycode is een reeks if's niet meer als het aantal vergelijkingen + het aantal voorwaardelijke sprongen (evt nog in de structuur van de EN en OF operators)

dus

code:

if (a!=0) jump nietabnul
if (b!=0) jump nietabnul
doe iets
jump naabnul
nietabnul::
doe iets
naabnul:
doe verder

is vergelijkbaar met

C++:

if (a!=0 && b != 0)
  doe iets;
else
  doe iets;
doe verder

[ Voor 42% gewijzigd door H!GHGuY op 25-05-2005 23:12 ]

[Olaf van der Spek]

Verwijderd schreef op woensdag 25 mei 2005 @ 22:26:
En natuurlijk ook tenminste 1 keer bij het tentamen van programmeer methoden

Nee, daar kwam gzip niet in voor.

[vriesdude]

Ik ben zelf ook schuldig aan het schrijven van ranzige code..
Ik beheer sinds aantal jaren PHP, nu gebruik ik het voor profesionele doeleinden, aan het begin ook ..

Ik heb toen een site gemaakt die nog steeds goed bezocht wordt, maar niet meer onder mijn beheer staat. Daarin zit een shoutbox (scrollende tekst in een iframe waarin uses troep kunnen posten).
Tevens heeft dat ding de mogelijkheid om smillie's te gebruiken.. In plaats van een array aan te maken met alle smillie's las ik alle smillie's uit met een query, elke smillie ze eigen query.. 50 smillies houdt dus in 50 query's. Niet echt bevoordelijk voor de performance met soms toch wel een redelijk bezoekersaantal gelijktijdig (50 GB dataverkeer in een maand).

Tevens heb ik ook ooit zo een forum geschreven (elke post en elk gegeven een eigen query...).. Dat heb ik wel helemaal herschreven.

Ik heb ook een webmail gemaakt die ooit mail ophaalde van 1 pop box (we hadden maar 1 box) en deze mail in een database gooide. Vervolgens met een php pagina een webmail geschreven voor 500 studenten). Kwa performance was het leuk totdat er duizenden mails met bijlage's inzaten....

[MaxxRide]

Mijn eerste post. Kwam deze vandaag tegen in een applicatie:

JavaScript:

 if(Diff > maxDiff) {....
      }
      else{
       if (Diff > maxDiff) maxDiff = Diff;
}

Volg jij ehm nog?

[ Voor 4% gewijzigd door MaxxRide op 26-05-2005 13:34 ]

[pjvandesande]

Ik kwam deze een tijdje terug al tegen:

C#:

for(int i = 0; i < 2; i++)
{
      if(i == 0)
      {
            CheckForUpdates();
      }
      else
      {
            DownloadUpdate();
      }
}

[ Voor 4% gewijzigd door pjvandesande op 26-05-2005 14:04 . Reden: typo ]

[kenneth]

Vooral die assignment in het if-statement is 'n leuke

[riezebosch]

kenneth schreef op donderdag 26 mei 2005 @ 13:56:
Vooral die assignment in het if-statement is 'n leuke

Ook al zat die er zelf niet in was ie leuk, want zo te zien is het gewoon de bedoeling dat beide statements achter elkaar uitgevoerd worden

[Suepahfly]

Ooit een "hele nette" functie geschreven om een array index te sorteren en asciotive(?) key te verwijderen. Zag er ongeveer zo uit:

PHP:

function(arraySort(&$array))
{
    foreach($array => $key as $value)
    {
        if(!is_numeric($key)
            unset($array($key));
    }

    $array = implode(":|:", $array);
    $array = explode(":|:", $array);

    return $array;
}

[pjvandesande]

kenneth schreef op donderdag 26 mei 2005 @ 13:56:
Vooral die assignment in het if-statement is 'n leuke

Dat was weer mijn verkrachting, ik moet de programmeur die dit schreef niet belagelijk gaan maken

riezebosch schreef op donderdag 26 mei 2005 @ 13:59:
[...]


Ook al zat die er zelf niet in was ie leuk, want zo te zien is het gewoon de bedoeling dat beide statements achter elkaar uitgevoerd worden

Dit was inderdaad zijn enige bedoeling.

[ Voor 39% gewijzigd door pjvandesande op 26-05-2005 14:31 ]

[RobIII]

code:

<script language="JavaScript">
    <!--
        function OpenPartnerlogin(){
            window.open('https://ssl.somecompany.nl/partnerlogin/?login=true','','width=770,height=480,resizable=1,scrollbars=1');
        }
        function OpenAanvraag(){
            window.open('https://ssl.somecompany.nl/partnerlogin?option=partner_password','','width=770,height=480,resizable=1,scrollbars=1');
        }
        function OpenNieuwepartner(){
            window.open('https://ssl.somecompany.nl/partnerlogin?option=partner_form','','width=770,height=480,resizable=1,scrollbars=1');
        }
        function OpenVoorwaarden(){
            window.open('http://www.website.somecompany.nl/templates/algvoorw.htm','','width=770,height=480,resizable=1,scrollbars=1');
        }
    // -->
</script>
<script language="JavaScript">
    <!--
        function openpartnerlogin(){
            window.open('https://ssl.somecompany.nl/partnerlogin/?login=true','','width=770,height=480,resizable=1,scrollbars=1');
        }
        function openaanvraag(){
            window.open('https://ssl.somecompany.nl/partnerlogin?option=partner_password','','width=770,height=480,resizable=1,scrollbars=1');
        }
        function opennieuwepartner(){
            window.open('https://ssl.somecompany.nl/partnerlogin?option=partner_form','','width=770,height=480,resizable=1,scrollbars=1');
        }
        function openvoorwaarden(){
            window.open('http://www.website.somecompany.nl/templates/algvoorw.htm','','width=770,height=480,resizable=1,scrollbars=1');
        }
    // -->
</script>

Ik heb de bedrijfsnaam vervangen door "somecompany"

"Daarom hebben ze dus functies uitgevonden! AHA Nu snap ik het. Laat ik dan voor iedere URL een functie maken!" Nog nooit gehoord van parameters
"En dan doe ik ze meteen 1 keer MeT hOoFdLeTtErS en 1 keer zonder"

Ik weet niet wat die "programmeur" voor opleiding heeft gedaan, maar het zal wel duur zijn geweest

[ Voor 60% gewijzigd door RobIII op 26-05-2005 16:02 ]

[Verwijderd]

OlafvdSpek schreef op woensdag 25 mei 2005 @ 23:19:
[...]
Nee, daar kwam gzip niet in voor.

Maar wel die opgave waarbij je oa rekening moet houden met het feit dat de volgorde van expressie evaluatie in function parameters niet vaststaat. (Sorry jongens, dit is eigenlijk erg offtopic )

[Verwijderd]

MaxxRide schreef op donderdag 26 mei 2005 @ 13:34:
Mijn eerste post. Kwam deze vandaag tegen in een applicatie:

JavaScript:

 if(Diff > maxDiff) {....
      }
      else{
       if (Diff > maxDiff) maxDiff = Diff;
}

Volg jij ehm nog?

Lach. Dit kom je heel erg vaak tegen. Ik heb zelf een paar jaar C++ opgaves nagekeken (ook die van Olafvdspek ), en kwam vaak van dit soort dingen tegen. In het algemeen checked men vaak op dingen die vanwege eerdere testen al lang al bekend zijn. Het herhalen van een exacte dezelfde test is wel erg lomp. Eerder zie je iets van:

C++:

if ( c > 10 ) {
   // code ...
  if ( c != 0 ) {
      // something...
  }
}

[mosymuis]

Gevonden in de code van het almachtige Marktplaats, de site van 225 miljoen. Bij het plaatsen van een advertentie:

JavaScript:

switch(elementType) {
  (...)

  case 'file':
    if( sourceElement.checked ) alert( 'blaaaaat' );
}

Vaagheid alom; hoe kan een file input field gechecked zijn? Inderdaad, en waarom maak je er dan een onzinnige alert voor?

[pjonk]

Ik kom nogal eens wat rukke VB6 code tegen, met constructies als deze:

code:

Do While True
  rs.MovePrevious
  If rs.BOF Then GoTo End_GivePrevious
  If Boolean Then
    If Boolean2 Then Exit Do
  Else
    Exit Do
  End If
Loop

End_GivePrevious:

[Verwijderd]

mosymuis schreef op donderdag 26 mei 2005 @ 16:31:
Gevonden in de code van het almachtige Marktplaats, de site van 225 miljoen. Bij het plaatsen van een advertentie:

JavaScript:

switch(elementType) {
  (...)

  case 'file':
    if( sourceElement.checked ) alert( 'blaaaaat' );
}

Vaagheid alom; hoe kan een file input field gechecked zijn? Inderdaad, en waarom maak je er dan een onzinnige alert voor?

Idd. Vaak zijn het gewoon wat try-outs van code die er in zijn blijven zitten. Vergeet niet dat niet iedereen het principe van unit testen kent. Impliciet doen ze wel aan unit testen, maar zetten dit gewoon zo in de code. Refactoren doet ook lang niet iedereen: zo lang het werk, werkt het. Dat de code een steeds onbegrijpbare brei wordt gaat totaal lang sommigen heen. Eigenlijk ook wel logisch: veel mensen werken maar een korte tijd op een project (geld al helemaal voor stagiares), noodzaak om op lange termijn te denken is er helemaal niet.

[Verwijderd]

Gisteren nog toen ik in php controles aan het inbouwen was voor verstuurde formuliergegevens, stond er op een gegeven moment iets als:

code:

if(!ereg('^.....$', $_POST['formulierinput']))
{
//het klopt niet...
code;
}

Resultaat van een aantal keer denken "hoewel die string moet kunnen" en "die ook" tot uiteindelijk de enige voorwaarde was dat

code:

strlen($_POST['formulierinput']) == 5)

maar ja, waarom makkelijk doen...

[ Voor 8% gewijzigd door Verwijderd op 26-05-2005 19:58 ]

[Verwijderd]

questa schreef op donderdag 26 mei 2005 @ 13:47:
Ik kwam deze een tijdje terug al tegen:

C#:

for(int i = 0; i < 2; i++)
{
      if(i == 0)
      {
            CheckForUpdates();
      }
      else
      {
            DownloadUpdate();
      }
}

Mwah, bij deze kan ik me nog voorstellen dat de programmeur ooit begonnen was met een ingewikkelde constructie waar er wel echt gelooped werd. En dat hij vervolgens door trial-and-error het geheel tot een eenvoudiger iets heeft teruggebracht, alleen toen over het hoofd heeft gezien dat het zo best wel dom overkomt

Of iemand anders die hij niet zo mag moest verder met de code en hij wilde het wat moeilijker leesbaar maken. Zeg nou zelf:

code:

CheckForUpdates();
DownloadUpdate();

is toch ook veeeeeeel te makkelijk?

[Verwijderd]

Verwijderd schreef op donderdag 26 mei 2005 @ 18:38:
[...]


Idd. Vaak zijn het gewoon wat try-outs van code die er in zijn blijven zitten. Vergeet niet dat niet iedereen het principe van unit testen kent. Impliciet doen ze wel aan unit testen, maar zetten dit gewoon zo in de code. Refactoren doet ook lang niet iedereen: zo lang het werk, werkt het. Dat de code een steeds onbegrijpbare brei wordt gaat totaal lang sommigen heen. Eigenlijk ook wel logisch: veel mensen werken maar een korte tijd op een project (geld al helemaal voor stagiares), noodzaak om op lange termijn te denken is er helemaal niet.

Maar Alert('blaaaaaaat') is wel heeeeel erg fout voor een site die voor 225 miljoen is verkocht!!

[RobIII]

Verwijderd schreef op vrijdag 27 mei 2005 @ 11:02:
[...]


Maar Alert('blaaaaaaat') is wel heeeeel erg fout voor een site die voor 225 miljoen is verkocht!!

Waarschijnlijk hebben ze die 225 miljoen niet neergeteld voor de code, maar voor het concept/de klanten enz.

[Verwijderd]

Ik had een keer een collega, die een access dbje moest synchroniseren met een andere db...

het waren maar 2 tabellen die hij moest bekijken in de ene, en de entries in de andere zetten..

Hoeveel connecties heeft een mens daarvoor nodig ? Ik zeg twee...

Hij had er 5... beetje vreemd.. bovendien duurde het ook een uur voordat het gesynchroniseerd was.. Dus ik de code nakijken, en wat deed die flap nou:

Hij haalde alle data op, om daarna de rij 1, colom 1 terug te geven.. wilde hij 1,2.. haalde hij weer alles op uit de db...

Ja daag zo werkt dat niet he...

[LuCarD]

Verwijderd schreef op vrijdag 27 mei 2005 @ 13:21:
Ik had een keer een collega, die een access dbje moest synchroniseren met een andere db...

het waren maar 2 tabellen die hij moest bekijken in de ene, en de entries in de andere zetten..

Hoeveel connecties heeft een mens daarvoor nodig ? Ik zeg twee...

Hij had er 5... beetje vreemd.. bovendien duurde het ook een uur voordat het gesynchroniseerd was.. Dus ik de code nakijken, en wat deed die flap nou:

Hij haalde alle data op, om daarna de rij 1, colom 1 terug te geven.. wilde hij 1,2.. haalde hij weer alles op uit de db...

Ja daag zo werkt dat niet he...

Zoiets hadden we ook bij ons een geoutsourcede applicatie. Daar hadden we een aantal zeer uitgebreide view, met subselects, join en wat berekeningen en ongeveer 100 velden Elke keer als het programma een ander veld nodig had dan werd de query op nieuw gedaan.

code:

//ongeveer zo
Loop door alle veldnamen heen 
  select veldnaam from dure view
  doe wat met de data
next

En dan nog de hardware de schuld geven van slecht performance...

[Verwijderd]

LuCarD schreef op vrijdag 27 mei 2005 @ 13:35:
[...]


Zoiets hadden we ook bij ons een geoutsourcede applicatie. Daar hadden we een aantal zeer uitgebreide view, met subselects, join en wat berekeningen en ongeveer 100 velden Elke keer als het programma een ander veld nodig had dan werd de query op nieuw gedaan.

code:

//ongeveer zo
Loop door alle veldnamen heen 
  select veldnaam from dure view
  doe wat met de data
next

En dan nog de hardware de schuld geven van slecht performance...

Hahaha... typisch is dat he ... en je maar afvragen waarom 20 entries een uur nodig hebben

[Verwijderd]

Wat ook een aardige WTF was:

Op een project waar ik tijd geleden op zat had men de gewoonte om alle business logica die je maar kon bedenken gewoon zo rechtstreeks als java en SQL in de JSP pagina's te zetten. Werkelijk ongelooflijk, er zat zowat geen enkele java class in dat hele project van mischien wel 100.000 regels! Ik kreeg de opdracht iets toe te voegen waarvoor ik bepaalde business logica moest aanroepen. Werd me doodleuk verteld dat de benodigde code op pagina die en die stond ergens rond het midden. WTF!?

Ik: "Hoe moet ik dat dan gaan aanroepen?"
Hun: "Nou euhh... Wat denk je zelf? Gewoon copy-pasten wat je nodig hebt naar je eigen pagina!"



En toen ik voorzichtig probeerde uit te leggen dat je je zo in je eigen wielen rijdt ook nog het commentaar krijgen dat ik als Drs'je die altijd veels te complexe architecturen willen niet moest zeuren want zo was het allemaal veel makkelijker. In het bedrijfsleven hadden ze geen tijd voor academisch geneuzel en was tijd geld. (en dan vervolgens wel 3 weken naar een bug zoeken die je met een meer heldere opzet in mischien een half uurtje had gevonden).

[ Voor 3% gewijzigd door Verwijderd op 30-05-2005 21:11 ]

[Michali]

Verwijderd schreef op maandag 30 mei 2005 @ 21:10:
Wat ook een aardige WTF was:
....

Dit is de naam van het topic echt waardig. Aan zo'n project wil je toch niet werken, wat een amateurs, ongeloofelijk.

[mosymuis]

Het stagebedrijf waar ik werk, heeft door de jaren heen een opmerkelijke tactiek bedacht om de database server bezig te houden.

In hun ASP/MSSQL applicatie draaien ze een lege INSERT met, in een van de kolommen, een unieke key op een tabel, zodra iemand een nieuw item wil aanmaken. Vervolgens volgt er een SELECT op basis van die key, om het ID uit te lezen. Direct daarna komt er een UPDATE overheen om de unieke key uit te wissen. Op dat punt krijgt de bezoeker een wijzig pagina te zien (SELECT), die is aangeroepen met het ID. Na het invullen van het formulier volgt er nog eens een UPDATE. Kortom, vijf queries waar er één voldoende zou zijn geweest. Bovendien blijven er telkens lege records achter, mocht de bezoeker het aanmaken van een nieuw item afbreken.

[Sjaaky]

RobIII schreef op donderdag 26 mei 2005 @ 15:49:
"Daarom hebben ze dus functies uitgevonden! AHA Nu snap ik het. Laat ik dan voor iedere URL een functie maken!" Nog nooit gehoord van parameters
"En dan doe ik ze meteen 1 keer MeT hOoFdLeTtErS en 1 keer zonder"

Met en zonder hoofdletters is idd een WTF.
Maar als die methodes vanuit verschillende locaties worden opgeroepen is het best wel nuttig. Op het moment dat je een url wilt wijzigen hoef je dat maar op 1 plaats te doen. Uiteraard zou je er ook een constante voor kunnen gebruiken, maar dat geeft extra code bij de aanroeper. Bovendien abstraheer je een niveautje. Je praat niet meer javascript termen, maar in termen van je eigen applicatie.

[RobIII]

Sjaaky schreef op maandag 27 juni 2005 @ 23:31:
[...]


Met en zonder hoofdletters is idd een WTF.
Maar als die methodes vanuit verschillende locaties worden opgeroepen is het best wel nuttig. Op het moment dat je een url wilt wijzigen hoef je dat maar op 1 plaats te doen. Uiteraard zou je er ook een constante voor kunnen gebruiken, maar dat geeft extra code bij de aanroeper. Bovendien abstraheer je een niveautje. Je praat niet meer javascript termen, maar in termen van je eigen applicatie.

En toch vind ik het een WTF

[RHE123]

Ik was daarnet even naar school om een project van mij zelf te laten zien aan een conrector/begeleider bij ons op school. Hij liet mij toen ook een heel goed voorbeeld van slecht programmeren zien. Het gaat om een update script voor een programma dat op veel scholen gebruikt word. In pseudo code doet het script ongeveer dit:

code:

if (not find help.tar) { //Controleer of de oude file bestaat...
    exit;
}

copy new_help.tar help.tar; //Overschrijf de oude met de nieuwe file

pak help.tar uit;
overige code;

if (find help.tar) { //Als help.tar bestaat
    rm help.tar; //Verwijder help.tar
}

Bij de volgende update loopt het script dus weer fijn vast op de eerste controle! Deze fout zit er nu al meerdere versies in, over testen gesproken...

[Verwijderd]

Mwah, das dus niet echt slecht programmeren, maar zoals je zelf zegt, gebrek aan testen.

De code zelf doet waarschijnlijk niet echt iets raars, alleen de volgorde van de stappen klopt niet.

Waarschijnlijk werden al die stappen van die update proces een voor een geprogd, maar toen veranderde ergens halverwege het ontwerp voor de update proces lijkt me.

Als je het toch over de code wilt hebben dan zou ik gewoon die check of die bestand bestaat EN de verwijder code verwijderen, ipv alleen de laatste stap verwijderen, waar jij op doelt?

[RHE123]

Verwijderd schreef op woensdag 29 juni 2005 @ 01:30:

Dat lijkt mij ook de beste oplossing ja, ik vind het wel stom dat deze fout er nu al meerdere versies inzit, ondanks klachten...

[Robtimus]

*schopje*

2 weken geleden werd ik, aan het begin van mijn vakantie, opgebeld omdat een geautomatiseerd script 13000 emailtjes had zitten versturen. Na enig speurwerk kwam ik erachter:
Het script slaapt vanaf half 5 's middags tot half 9 de volgende dag, en het was die dag heel toevallig 31-07. Hoe ik dat "volgende dag" had geimplementeerd (in VB)?

Visual Basic:

dNextDay = CDate(Format("yyyy-mm", Now) & "-" & CStr(Day(Now) + 1))

En ja, het script viel nogal over die 32 juli
Vandaag teruggekomen van vakantie en maar snel overgestapt op DateAdd...

offtopic:
Ik wist al dat het niet meer zou voorkomen tot 31-8 dus ik heb het inderdaad niet snel opgelost; vakantie ging toch eventjes voor

[Maasluip]

Zo te zien is dit VB, daar wordt datum/tijd als een double gezien met de datum in het integer deel. Wat let je om dNextDay = dNextDay + 1 te doen?

[LuCarD]

Geschreven door een collega uit India:

Visual Basic:

Public Function GetNextWorkingDate(pDate As Date) As String
'This loops until a valid working day is found
CheckAgain:
    
    If CheckHoliday(pDate) = True Then
        pDate = DateAdd("d", 1, pDate)
        GoTo CheckAgain
    Else
        GetNextWorkingDate = pDate
    End If

End Function

Maar ze waren er zelf niet helemaal tevreden over dus ze hebben hem herschreven naar het volgende.

Visual Basic:

Private Function GetNextWorkingDay(pCurrentDate As Date) As Date
Dim NextDate As Date
Dim tmprs As ADODB.Recordset
NextDate = pCurrentDate
While True
    NextDate = NextDate + 1
    'MsgBox Left(UCase(WeekdayName(Weekday(NextDate))), 3)
    
    'CHANGED BY ***** ON 5-5-01 TO AVOID WEEKEND CONFLICT ACCORDING TO THE REGIONAL SETTINGS OF THE EOD USER
    If Left(UCase(WeekdayName(Weekday(NextDate, vbSunday), , vbSunday)), 3) <> UCase(SysParam.WEEKEND_1) _
        And Left(UCase(WeekdayName(Weekday(NextDate, vbSunday), , vbSunday)), 3) <> UCase(SysParam.WEEKEND_2) _
        And Left(UCase(WeekdayName(Weekday(NextDate, vbSunday), , vbSunday)), 3) <> "ZON" _
        And Left(UCase(WeekdayName(Weekday(NextDate, vbSunday), , vbSunday)), 3) <> "ZAT" Then

        Set tmprs = CBCon.Execute("SELECT * FROM HOLIDAY WHERE HOLIDAY_DATE = '" & NextDate & "'")
        If tmprs.RecordCount = 0 Then
            GetNextWorkingDay = NextDate
            Exit Function
        End If
    End If
Wend
End Function

Beide functie staan nog wel in de source code. Want ja misschien wil je de oude functie nog gebruiken?

[ Voor 9% gewijzigd door LuCarD op 15-08-2005 15:02 ]

[LuCarD]

RobIII schreef op maandag 15 augustus 2005 @ 15:01:
[...]

VB kent gewoon een Date datatype (hoewel dat onderhuids natuurlijk anders is). Je zou, als alternatief, ook met DateSerial kunnen werken, hoewel DateAdd wel een aardige is in dit geval.


[...]

Dude, die is wel een vermelding op thedailywtf.com waard

Dan blijf ik bezig. De hele source code staat vol met dit soort geniale code. Of vage database constructie's

Wat dacht je van een tabel met 1 rij en maar 62 verschillende velden?

[NMe]

LuCarD schreef op maandag 15 augustus 2005 @ 15:21:
Wat dacht je van een tabel met 1 rij en maar 62 verschillende velden?

Laat me raden...settings? En die tabel verandert zowat elke nieuwe release van vorm?

[kenneth]

LuCarD schreef op maandag 15 augustus 2005 @ 15:21:

Wat dacht je van een tabel met 1 rij en maar 62 verschillende velden?

Bekend
Ik heb het gelukkig niet gemaakt Maar wel vervangen door een key/value-settingstabel

[Verwijderd]

Java:

try
{
  URL url = new URL(s);
  DataInputStream dis = new
    DataInputStream(new BufferedInputStream(url.openStream()));
  byte b;
  int i = 0;
  while (i == 0)
  {
    b = dis.readByte();
    System.out.print((char)b);
  }
  System.out.println(\"\");
}

catch(java.io.EOFException e)
{
  System.out.println(s+\" success\");
}

Uit de while lus spingen met een exceptie (als 'normale' terminatie van de lus)...

[ Voor 33% gewijzigd door Verwijderd op 15-08-2005 15:43 ]

[Nick_S]

En ook nog een aparte integer gebruiken ipv. de toch al zo foute while (true).

[kenneth]

Die writeline die expliciet "success" roept maakt het dubbel zo erg

[PrisonerOfPain]

Verwijderd schreef op maandag 15 augustus 2005 @ 15:40:
Uit de while lus spingen met een exceptie (als 'normale' terminatie van de lus)...

Was het niet zo dat in python er standaard zo met iterators om werd gegaan?

[.oisyn]

Nick_S schreef op maandag 15 augustus 2005 @ 15:43:
En ook nog een aparte integer gebruiken ipv. de toch al zo foute while (true).

Daarom juist, iemand heeft 'm vast verteld dat een while(true) fout is

[JaWi]

Verwijderd schreef op maandag 15 augustus 2005 @ 15:40:
Uit de while lus spingen met een exceptie (als 'normale' terminatie van de lus)...

Hmm, * JaWi heeft ooit eens gelezen dat dit een van de 'betere' optimalisatie-truukjes is voor Java... Maar, ik geef toe, netjes is anders en het had best er wel even bijgeschreven mogen worden!

edit:
Even gegoogled naar betreffende artikeltje en gevonden!

[ Voor 17% gewijzigd door JaWi op 15-08-2005 16:02 ]

[Michali]

JaWi schreef op maandag 15 augustus 2005 @ 15:59:
[...]


Hmm, * JaWi heeft ooit eens gelezen dat dit een van de 'betere' optimalisatie-truukjes is voor Java... Maar, ik geef toe, netjes is anders en het had best er wel even bijgeschreven mogen worden!

edit:
Even gegoogled naar betreffende artikeltje en gevonden!

In alle gevallen of alleen bij het inlezen van een stream? Lijkt me sterk dat het in normale gevallen sneller is dan een simpele controle met een break.

Ik zou het iig nooit gebruiken, behalve als je echt duidelijke resultaten hebt van een profiler die aangeeft dat in een bepaalde loop de performance bottleneck zit.

[ Voor 15% gewijzigd door Michali op 15-08-2005 16:07 ]

[kenneth]

Exception misbruik (execption = uit-zon-de-ring ) vind ik wel een zodanig grote zonde, dat ik hem niet zou misbruiken voor optimalisatie.

[PrisonerOfPain]

kenneth schreef op maandag 15 augustus 2005 @ 16:10:
Exception misbruik (execption = uit-zon-de-ring ) vind ik wel een zodanig grote zonde, dat ik hem niet zou misbruiken voor optimalisatie.

Als je allemaal tekens verwacht, en die houden er ineens mee op (EOF) valt er dan niet te spreken over een uit-zon-de-ring?

[jelmervos]

JaWi schreef op maandag 15 augustus 2005 @ 15:59:
[...]

edit:
Even gegoogled naar betreffende artikeltje en gevonden!

Daar staat ook:

Attention: This technique will make your loops more performant in many cases, but I think this is a very bad coding style. It is harder to read and debug the sourcecode. You never realy know the point of termination of the loop. It is also worde to maintain this loop. I suggest to avoid this optimization.

[kenneth]

@PrisonerOfPain:

Er zijn oneindige datastreams, maar ik denk dat 99% van de datastreams eindig is

[ Voor 11% gewijzigd door kenneth op 15-08-2005 16:29 ]

[Michali]

PrisonerOfPain schreef op maandag 15 augustus 2005 @ 16:16:
[...]


Als je allemaal tekens verwacht, en die houden er ineens mee op (EOF) valt er dan niet te spreken over een uit-zon-de-ring?

Nee, want het einde verwacht je ook. Het is geen imo geen uitzondering op de normale executie van de code. (vrijwel) iedere reeks tekens heeft een einde.

edit:
shit, veel te laat

[ Voor 5% gewijzigd door Michali op 15-08-2005 16:36 ]

[Radiant]

Tijdje geleden kwam ik dit (of iets wat erop leek, het is snel vervangen) tegen in een stuk encryptie code:

C++:

bool fBlaat = true;
...
if ( fBlaat ) // this is always true?