[C++/Alg] Over booleans en integers

[Paul]

Modbreak:

Dit topic is afgesplitst van [alg] Slechtste programmeervoorbeelden deel 2.

Vaan Banaan schreef op donderdag 11 januari 2007 @ 16:27:
Volgens mij is het: Als dat (wel) 0 is doe iets, anders iets anders.

Ik vind het sowieso bezopen dat de not-operator op een integer gewoon werkt . Nu ja, dat niet zozeer, je kunt er bijvoorbeeld alle bitjes mee omflippen, maar (en dat is dus de hoofdbezopenheid) dat die (of: een) integer vervolgens een geldige boolean is?

Dat de enum (false, true, FileNotFound) intern aan een integer hangt (ofzo) kan, maar nu moet je maar gaan onthouden of true nu 1 of 0 was en andersom om nog maar te zwijgen over de elende die je op je hals haalt als je booleans met elkaar gaat vergelijken.

[ Voor 6% gewijzigd door een moderator op 12-01-2007 03:05 ]

[.oisyn]

Paul Nieuwkamp schreef op donderdag 11 januari 2007 @ 17:06:
Nu ja, dat niet zozeer, je kunt er bijvoorbeeld alle bitjes mee omflippen,

Daar heb je de ~ voor, niet de ! . De oorzaak zit 'm in het feit dat alle primitives impliciet converteerbaar zijn naar bool (wat gewoon != 0 betekent)

Dat de enum (false, true, FileNotFound) intern aan een integer hangt (ofzo) kan

Nee kan niet, false en true zijn geen geldige enum values omdat dat reserved words zijn . Dat klinkt flauw, maar dat maakt de enum { False, True, FileNotFound } niet anders dan de enum { State1, State2, State3 }, en ben je sowieso dom als je daar een imliciete bool conversie op los laat . Je zal dus altijd moeten checken met == en !=. Je hoeft dus ook niet te onthouden wat 0 was.

Of:

C++:

class MyEnum
{
public:
    enum enum_t { True, False, FileNotFound };
    MyEnum(enum_t v) : m_value(v) { }
    operator == (MyEnum other) const { return m_value == other.m_value; }
    operator != (MyEnum other) const { return !(*this == other) };
    operator bool() const { return m_value == True; }

private:
    enum_t m_value;
};

C++09 gaat waarschijnlijk stricte enums ondersteunen: http://www.open-std.org/j...ocs/papers/2004/n1579.pdf, juist omdat bovenstaande workaround zo omslachtig is.

[ Voor 24% gewijzigd door .oisyn op 11-01-2007 18:22 ]

[Paul]

.oisyn schreef op donderdag 11 januari 2007 @ 18:07:
Daar heb je de ~ voor, niet de !

True. Offeuh, 1. Of was het 0?

De oorzaak zit 'm in het feit dat alle primitives impliciet converteerbaar zijn naar bool (wat gewoon != 0 betekent)

En dat kaart ik juist aan Welke stoned designer heeft dat gemaakt Dan krijg je dus constructies als if (integer) { }

Nee kan niet, false en true zijn geen geldige enum values omdat dat reserved words zijn

Ik bedoelde ook niet zozeer een user (developer)-defined enum, maar meer de interne verwerking van die reserved words. De FileNotFound was een poging tot humor, inderdaad van TDWTF

Jaap-Jan schreef op donderdag 11 januari 2007 @ 18:43:
En in de reacties kunnen sommige mensen al niet eens het verschil zien tussen het doorgeven van een reference by value (oftewel van de reference word een kopie gemaakt en dus gewoon call by value) aan een functie en een call by reference

Het enige verschil dat ik kan verzinnen tussen "call by reference" en "call by een-kopie-van-die-reference" is dat als je de waarde van die kopie van die reference veranderd, dat de originele pointer nog steeds naar het oude object wijst (waardoor het origineel dus een dangling pointer wordt als je de kopie-van-die-reference vrijgeeft en er iets anders op new't, wat dus op zijn beurt weer een geheugenlek oplevert als je het niet vrijgeeft in die functie), dus ook ik zal wel weer iets missen
Wat is het practische nut ervan?

[ Voor 38% gewijzigd door Paul op 11-01-2007 19:31 ]

[Soultaker]

Paul Nieuwkamp schreef op donderdag 11 januari 2007 @ 18:51:
En dat kaart ik juist aan Welke stoned designer heeft dat gemaakt Dan krijg je dus constructies als if (integer) { }

Dat komt natuurlijk omdat C/C++ ontstaan is als een 'portable assembler'; processoren hebben zelden een apart boolean type, en conditionele instructies werken dan met 0-of-niet-nul.

Als je een conditionele expressie als if(i) { .. } in C/C++ gewoon leest als if(i != 0) { .. } dan is het niet meer zo raar. Als je bovendien gebruikt dat 'true' geconverteerd wordt naar 1, en false naar 0, dan kun je leuke expressies als deze schrijven:

C:

// integer-deling afronden naar boven
c = a/b + (bool)(a%b);

Maar dat zul jij wel weer raar vinden.

[PrisonerOfPain]

Paul Nieuwkamp schreef op donderdag 11 januari 2007 @ 18:51:
True. Offeuh, 1. Of was het 0?

Geen vreemde vraag, dit verschilt namelijk wel eens

code:

Dexter:~ Home$ /usr/bin/true
Dexter:~ Home$ echo $?
0
Dexter:~ Home$ /usr/bin/false
Dexter:~ Home$ echo $?
1
Dexter:~ Home$ php -r 'echo true, "\n", (int)false, "\n";'
1
0

[ Voor 8% gewijzigd door PrisonerOfPain op 11-01-2007 20:08 ]

[Paul]

Soultaker schreef op donderdag 11 januari 2007 @ 19:37:
Maar dat zul jij wel weer raar vinden.

Dat ziet er inderdaad nogal vaag uit Dat je van een integer kunt zeggen of hij true of false is, okee, maar een (vanuit een int gecaste) boolean optellen bij een integer?
Het komt mij eerder over als het misbruiken van een exposed implementatiedetail dan als goede, solide code en ziet eruit als premature optimization

Daar mogen wat mij betreft nog een regel of 3 commentaar extra bij

...en toen veranderde in C(huidig++) de definitie van true en false...

[Soultaker]

PrisonerOfPain schreef op donderdag 11 januari 2007 @ 20:01:
Geen vreemde vraag, dit verschilt namelijk wel eens

Visual Basic is ook mooi; False wordt 0 en True wordt -1!

[Robtimus]

Soultaker schreef op donderdag 11 januari 2007 @ 19:37:
dat 'true' geconverteerd wordt naar 1, en false naar 0

Dat is ook zo vreemd eigenlijk.

Dat false naar 0 geconverteerd wordt, ok, prima.
Maar voor true zie ik een veel betere integer waarde: -1.

Bekijk het maar eens binair.
false = 0 = 0x00000000
De negatie daarvan is 0x11111111 = -1. Dat maakt -1 een goede kandidaat voor true.
Ik meen dat in VB6 dit ook daadwerkelijk geldt. Was voor mij toen ook wel een verrassing

Al met al kun je beter de volgende regel opstellen:
false komt overeen met == 0
true komt overeen met != 0

En dan heb je nog OS processen waarbij een output van 0 opeens succesvol betekent...

edit:
Wat POP en SoulTaker dus zeggen

[ Voor 3% gewijzigd door Robtimus op 11-01-2007 21:31 ]

[Soultaker]

Paul Nieuwkamp schreef op donderdag 11 januari 2007 @ 21:09:
Dat ziet er inderdaad nogal vaag uit Dat je van een integer kunt zeggen of hij true of false is, okee, maar een (vanuit een int gecaste) boolean optellen bij een integer?
Het komt mij eerder over als het misbruiken van een exposed implementatiedetail dan als goede, solide code en ziet eruit als premature optimization

Je moet mijn expressie meer lezen als "c is a/b, en als er een rest is, plus 1".

Er zijn wel problemen met negatieve getallen, maar daar staat tegenover dat je geen last hebt van overflow wat je wel zou hebben met een expressie als (a + b - 1)/b. Voor positieve/unsigned getallen is het dus een prima methode, voor negatieve getallen moet je sowieso goed nadenken wat je precies wil dat er gebeurt (ronden naar 0 toe, of van 0 af?).

...en toen veranderde in C(huidig++) de definitie van true en false...

Wat kan er veranderen? De interne waarde van true en false is nu al niet gespecificeerd, maar wel is gespecificeerd dat 0/niet-0 geconverteerd wordt naar false/true, en dat false/true geconverteerd wordt naar 0/1. Dat is geen implementatiedetail, maar een harde garantie van de standaard. Als ze de standaard wijzigen zodat dat niet meer geldt dan werkt het niet meer, maar dan is het ook een fundamenteel andere taal geworden.

[ Voor 25% gewijzigd door Soultaker op 11-01-2007 21:33 ]

[Soultaker]

IceManX schreef op donderdag 11 januari 2007 @ 21:30:
Maar voor true zie ik een veel betere integer waarde: -1.

Bekijk het maar eens binair.
false = 0 = 0x00000000
De negatie daarvan is 0x11111111 = -1. Dat maakt -1 een goede kandidaat voor true.

Dat geldt alleen als je uitgaat van 2's complement notatie van signed integers. Zelfs Visual Basic definieert het niet zo (ze stellen dat true geconverteerd wordt naar integer -1, niet naar intern 0xffff ofzoiets). En waarom is dit eigenlijk fundamenteel logischer dan true=1?

Verder is het wel handig om boolean waarden als indices in een array te kunnen gebruiken:

C:

int table[2][2][2];
int foo(bool a, bool b, bool c) {
    return table[a][b][c];
}

Als true -1 is, werkt dit aanzienlijk minder makkelijk.

[.oisyn]

Paul Nieuwkamp schreef op donderdag 11 januari 2007 @ 21:09:
...en toen veranderde in C(huidig++) de definitie van true en false...

Will never happen. Dat breekt namelijk alle huidige code.

[.oisyn]

Soultaker schreef op donderdag 11 januari 2007 @ 21:45:
Als true -1 is, werkt dit aanzienlijk minder makkelijk.

Nou ontzettend

C:

int table[2][2][2];
int foo(bool a, bool b, bool c) {
    return table[-a][-b][-c];
}

[Verwijderd]

(...)
Verder is het wel handig om boolean waarden als indices in een array te kunnen gebruiken:

Maar je kunt -1 ook als array index gebruiken hoor:

C:

#include <stdio.h>

void main(){
  char a[] = " hallo";
  char* b = a + 1;
  putc( b[-1], stdout );
}

Het is misschien ziek, maar het werkt wel

[.oisyn]

Waarom ziek? Het is goedgedefinieerd door de standaard.

[Soultaker]

Verwijderd schreef op vrijdag 12 januari 2007 @ 00:01:
Maar je kunt -1 ook als array index gebruiken hoor:

C:

#include <stdio.h>

void main(){
  char a[] = " hallo";
  char* b = a + 1;
  putc( b[-1], stdout );
}

Weet ik, maar als ik handmatig multidimensionale arrays moet gaan zitten adjusten, wordt ik daar niet vrolijk van... Als we dan toch aan het hacken zijn vind ik 'm zo leuker:

C:

putc(-1[b], stdout);

.oisyn schreef op donderdag 11 januari 2007 @ 22:36:
Nou ontzettend

C:

int table[2][2][2];
int foo(bool a, bool b, bool c) {
    return table[-a][-b][-c];
}

Ok, point taken. Ik zat zelf aan table[1 + a][1 + b][1 + c] te denken (maar dan worden de waarden voor true en false in de table omgewisseld). Het voordeel hiervan is wel dat de compiler die optellingen at-compiletime kan verwerken in de pointer naar table, wat runtime overhead voorkomt. (Of zijn er ook LEA-instructies met negatieve offsets?)

Overigens valt 0/-1 ook nog wel te verdedigen als je bool als een 1-bit signed integer ziet. (En 0/1 correspondeert dan met met een 1-bit unsigned integer).

[ Voor 30% gewijzigd door Soultaker op 12-01-2007 02:59 ]

[NMe]

Een eigen topic lijkt me wat handiger voor deze discussie, dus bij deze.

[ Voor 16% gewijzigd door NMe op 12-01-2007 03:06 ]

[Verwijderd]

Ik ben pas net C++ aan het leren, dus veel snap ik niet. Mischien is wat ik hier wil toevoegen wel zinloos. Please kick me then

Ik weet wel dat je als je in SQL Enum gaat gebruiken 0,1. Dan moet je ´0´ gebruiken als je iets wel doen met die enum. (Ik werk zelf nooit met enum dus ik weet niet of dit basic is )

Overgens kan het wel eens irritant zijn met PHP. Als je een 0 hebt in een variable, maar met opzet. En later moet je er mee werken (isset() gaf dacht ik FALSE) kan dat wel eens een probleempje geven.

[Voutloos]

Verwijderd schreef op vrijdag 12 januari 2007 @ 08:35:
Ik weet wel dat je als je in SQL Enum gaat gebruiken 0,1. Dan moet je ´0´ gebruiken als je iets wel doen met die enum. (Ik werk zelf nooit met enum dus ik weet niet of dit basic is )

Een enum kan je zien als een set van strings. Overigens hebben de verschillende waarden ook een numerieke index, en op deze index wordt bijvoorbeeld gesorteerd (oa in mysql). Als je dus een ENUM('c', 'b', 'a') hebt en je sorteert op dieKolom ASC, komen de records met 'c' eerst.

Overgens kan het wel eens irritant zijn met PHP. Als je een 0 hebt in een variable, maar met opzet. En later moet je er mee werken (isset() gaf dacht ik FALSE) kan dat wel eens een probleempje geven.

Nope. isset() is juist daarvoor. Enige uitzondering is wanneer de variabele null is, maar met null wil je over het algemeen niet werken.

[XWB]

[b][message=27291090,noline]Overgens kan het wel eens irritant zijn met PHP. Als je een 0 hebt in een variable, maar met opzet. En later moet je er mee werken (isset() gaf dacht ik FALSE) kan dat wel eens een probleempje geven.

Geen problemen, je moet gewoon correct controleren.

PHP:

$v = 0;
$z = '';

var_dump ( $v == false  );
var_dump ( $z == false );

Dit zal een true geven, omdat php 0 en lege strings ook als false behandeld (lege arrays ook, vind ik persoonlijk niet logisch). Maar zo moet je niet gaan checken omdat $v een integer is en de conditie true of false verwacht.

Dus ofwel met een ander getal controleren:

PHP:

$v = 0;

var_dump ( $v == 0 );
var_dump ( $v > 0 );

Ofwel de types controleren:

PHP:

$v = 0;

var_dump ( $v === 0 ); // true
var_dump ( $v === '0' ); // false

Zelfde voor bools:

PHP:

$v = true;

var_dump ( $v === true );
var_dump ( $v === false );

== true of false gebruik ik nooit. Alsook isset () gebruik ik zelden, variabelen altijd mooi initialiseren

[PrisonerOfPain]

Hacku schreef op vrijdag 12 januari 2007 @ 23:07:
Alsook isset () gebruik ik zelden, variabelen altijd mooi initialiseren

Meestal is 't wel handig bij array indices die ook geen null mogen zijn. (Anders kun je beter array_key_exists gebruiken).

[.oisyn]

Hacku schreef op vrijdag 12 januari 2007 @ 23:07:
Dit zal een true geven, omdat php 0 en lege strings ook als false behandeld

Elke string dat geen getal is ziet hij als false.

PHP:

$a = 'aap';
if ($a)
    echo '$a is blijkbaar true';

[PrisonerOfPain]

.oisyn schreef op zaterdag 13 januari 2007 @ 03:02:
Elke string dat geen getal is ziet hij als false.

Volgens de documentatie is enkel "" en "0" gelijk aan false. Voor de rest is alles gelijk aan true, 'aap' zoals in jou voorbeeld dus ook.

code:

Dexter:~ Home$ php -r 'if("aap") echo "Aap is true\n";'
Aap is true
Dexter:~ Home$ php -r 'if("9" == true) echo "9 is true\n";'
9 is true
Dexter:~ Home$ php -r 'if("0" == false) echo "0 is false\n";'
0 is false

http://nl2.php.net/manual...age.types.boolean.casting

[ Voor 13% gewijzigd door PrisonerOfPain op 13-01-2007 10:53 ]

[.oisyn]

Ja stom, ik vergiste me (had het nog wel getest, maar ik interpreteerde de uitkomst verkeerd om ). Een vergelijking met een (int)0 of (float)0.0 geeft wel true.

PHP:

$a = "aap";
if ($a == 0)
    echo "a == 0";

Best krom eigenlijk: 0 == false, "aap" == true, maar ook "aap" == 0

[ Voor 97% gewijzigd door .oisyn op 14-01-2007 01:58 ]

[JeRa]

.oisyn schreef op zondag 14 januari 2007 @ 01:54:
Best krom eigenlijk: 0 == false, "aap" == true, maar ook "aap" == 0

Dat is niet krom, dat is gedefiniëerd en zeer goed te verklaren door de castregels na te lopen. Bij "0 == false" wordt een integer naar boolean gecast (0 -> false), bij "aap == true" wordt een string naar boolean gecast (aap -> (strlen(aap) > 0) -> true), bij "aap == 0" wordt een string naar integer gecast (aap -> bevat geen getallen -> 0). Het lijkt voor jou misschien krom omdat de ==-operator niet hetzelfde doet als in de meeste andere talen in C/C++ vind er door de compiler een typecheck plaats op het moment dat je == doet, en om datzelfde gedrag in PHP te krijgen moet je === gebruiken in plaats van ==.

[ Voor 18% gewijzigd door JeRa op 14-01-2007 02:06 ]

[.oisyn]

JeRa schreef op zondag 14 januari 2007 @ 02:04:
[...]

Dat is niet krom, dat is gedefiniëerd en zeer goed te verklaren door de castregels na te lopen.

Die cast-regels zijn krom. Waarom "aap"==0, dat is compleet onbruikbaar in een script en het gaat elke keer weer mis.
Jouw enige argument voor het niet krom zijn is "omdat PHP het zo definieert". Ja, zo ken ik er ook nog wel een paar . "aap" is geen nummer, dus ook geen 0. Het feit dat 0 is gekozen voor een niet-converteerbare string is volledig arbitrair - ze hadden net zo goed 123 als uitkomst kunnen nemen. En had jij het dan nog steeds logisch gevonden? Weak danwel strong typing heeft hier niets mee te maken, wat ze imho hadden moeten doen als een van de twee operanden een int is en de ander een string, eerst kijken of die string naar een int te converteren is, en dan de vergelijking doen. Zo niet, dan is het sowieso false. Javascript doet het bijvoorbeeld ook zo

JavaScript:

if ("aap" == 0)
    alert("\"aap\" == 0");
else
    alert("\"aap\" != 0");

if ("23" == 23)  // om te laten zien dat er wel een conversie plaats vindt.
    alert("\"23\" == 23");
else
    alert("\"23\" != 23");

[ Voor 49% gewijzigd door .oisyn op 14-01-2007 02:18 ]

[JeRa]

.oisyn schreef op zondag 14 januari 2007 @ 02:08:
[...]

Die cast-regels zijn krom. Waarom "aap"==0, dat is compleet onbruikbaar in een script en het gaat elke keer weer mis.

Het gaat inderdaad mis als je een string met een integer gaat vergelijken. Dat PHP die mogelijkheid biedt is een ander verhaal.

Jouw enige argument voor het niet krom zijn is "omdat PHP het zo definieert". Ja, zo ken ik er ook nog wel een paar .

Ik ook

.oisyn schreef op vrijdag 12 januari 2007 @ 00:44:
Waarom ziek? Het is goedgedefinieerd door de standaard.

"aap" is geen nummer, dus ook geen 0. Het feit dat 0 is gekozen voor een niet-converteerbare string is volledig arbitrair - ze hadden net zo goed 123 als uitkomst kunnen nemen. En had jij het dan nog steeds logisch gevonden? Weak danwel strong typing heeft hier niets mee te maken, wat ze imho hadden moeten doen als een van de twee operanden een int is en de ander een string, eerst kijken of die string naar een int te converteren is, en dan de vergelijking doen. Zo niet, dan is het sowieso false.

Tja, zoals eerder gezegd gaat het ergens al fout als je variabelen van verschillende typen met elkaar gaat vergelijken. Ga je dat toch doen dan forceert PHP in een vergelijking het hoogste type (string > integer > boolean) naar het laagste type, en de typen zijn zo gedefiniëerd dat dit altijd kan. Vervolgens wordt er vergeleken en dat in het achterhoofd houdend kom je altijd goed uit, ongeacht of dat logisch voor irrationele vergelijkingen is of niet

[.oisyn]

JeRa schreef op zondag 14 januari 2007 @ 02:16:
Ik ook

[...]

Ik hoop niet dat dat een serieuze reactie is en dat je zelf ook wel begrijpt dat deze situaties compleet niet vergelijkbaar zijn. Wellicht was mijn woordkeuze onhandig, maar ook wiskundig houdt het stand:

a[i] => *(a + i) => *(i + a) => i[a]
Of i nou positief of negatief is, het blijft een optelling bij een pointer. En niemand zegt dat een pointer per se naar het begin van een array moet wijzen.

[.oisyn]

JeRa schreef op zondag 14 januari 2007 @ 02:16:
Ga je dat toch doen dan forceert PHP in een vergelijking het hoogste type (string > integer > boolean) naar het laagste type, en de typen zijn zo gedefiniëerd dat dit altijd kan.

Daar is niets mis mee, zie mijn javascript voorbeeld. Zo kan het dus ook. De wiskunde-regel b==a && c!=a => b!=c houdt dan gewoon stand.

[JeRa]

.oisyn schreef op zondag 14 januari 2007 @ 02:08:
[...]

En had jij het dan nog steeds logisch gevonden? Weak danwel strong typing heeft hier niets mee te maken, wat ze imho hadden moeten doen als een van de twee operanden een int is en de ander een string, eerst kijken of die string naar een int te converteren is, en dan de vergelijking doen. Zo niet, dan is het sowieso false. Javascript doet het bijvoorbeeld ook zo

-knip-

Is "javascript doet het ook zo" je enige argumentatie om aan te tonen dat het minder 'krom' is? Ik vind het nog steeds niet krom, ik weet precies wat PHP met variabelen doet en hou daar rekening mee - net zoals in Javascript, C, of Cobol wat dat betreft. "aap" == 0 en "21 apen" == 21 vind ik absoluut niet krom, en mijn argumentatie komt ook niet verder dan 'PHP definiëert dat zo en ik weet dat'.

[JeRa]

.oisyn schreef op zondag 14 januari 2007 @ 02:27:
[...]

Daar is niets mis mee, zie mijn javascript voorbeeld. Zo kan het dus ook. De wiskunde-regel b==a && c!=a => b!=c houdt dan gewoon stand.

Dan gaat het dus om de manier waarop variabelen worden 'gedegrade'?

[.oisyn]

JeRa schreef op zondag 14 januari 2007 @ 02:27:
[...]

Is "javascript doet het ook zo" je enige argumentatie om aan te tonen dat het minder 'krom' is?

Nee, en het is zelfs geen argument, maar een voorbeeld om aan te geven dat omdat PHP een conversie op de variabelen toelaat dat niet hoeft te impliceren dat er dan ook per se een int-waarde aan een ongeldige string toegekend hoeft te worden.

ik weet precies wat PHP met variabelen doet en hou daar rekening mee - net zoals in Javascript, C, of Cobol wat dat betreft.

Ik weet ook wat het doet, maar daardoor hoef ik het nog niet eens te zijn met de design-keuzes van de taal. In C++ zijn er ook wel dingen waar ik het niet mee eens ben (0 voor het initialiseren van een pointer bijvoorbeeld, gelukkig hebben ze dat zelf ook al ingezien).

Ik probeer hier een design-kwestie aan te kaarten, een antwoord als "php doet dat nou eenmaal zo" is dan natuurlijk nogal een dooddoener.

"aap" == 0 en "21 apen" == 21 vind ik absoluut niet krom

waarom niet?

[ Voor 7% gewijzigd door .oisyn op 14-01-2007 02:34 ]

[JeRa]

.oisyn schreef op zondag 14 januari 2007 @ 02:31:

[...]

waarom niet?

Omdat ik de gekozen string->integer conversie op zichzelf staand een goede keuze vind, en verder toch alleen maar === en !== gebruik in mijn vergelijkingen waardoor ik nooit tegen eerder genoemde problemen oploop

[.oisyn]

JeRa schreef op zondag 14 januari 2007 @ 02:35:
Omdat ik de gekozen string->integer conversie op zichzelf staand een goede keuze vind

Dát bedoelde ik nou precies met "waarom" . Waarom vind je het een goede keuze? Ik vind het geen goede keuze omdat "aap" geen getal is. 0 is wel een getal. Dat je dan bij een cast-naar int per se een antwoord moet hebben is begrijpelijk, maar dan zou je altijd nog expliciet kunnen casten zodat de 2 operanden voor een == van hetzelfde type zijn (en de == dus niet zelf de conversie hoeft te proberen)

en verder toch alleen maar === en !== gebruik in mijn vergelijkingen waardoor ik nooit tegen eerder genoemde problemen oploop

Hoe ga jij dan om met user-input dat een getal voor moet stellen?

[ Voor 47% gewijzigd door .oisyn op 14-01-2007 02:41 ]

[JeRa]

.oisyn schreef op zondag 14 januari 2007 @ 02:38:
[...]

Dát bedoelde ik nou precies met "waarom" . Waarom vind je het een goede keuze? Ik vind het geen goede keuze omdat "aap" geen getal is. 0 is wel een getal. Dat je dan bij een cast-naar int per se een antwoord moet hebben is begrijpelijk, maar dan zou je altijd nog expliciet kunnen casten zodat de 2 operanden voor een == van hetzelfde type zijn (en de == dus niet zelf de conversie hoeft te proberen)

Het idee achter == in PHP is dat de twee zijden van de vergelijking niet van hetzelfde type hoeven te zijn als je daar geen rekening mee houdt gaat het gewoon fout, en dat is geen designfout maar een gebruikersfout. Alles wat jij graag anders zag is gewoon geïmplementeerd in de ===-operator, dus ik snap niet echt waar het probleem ligt.

[...]

Hoe ga jij dan om met user-input dat een getal voor moet stellen?

User input krijg je bijna altijd als string binnen (bijvoorbeeld van de webserver) en die behandel ik dan ook als string door er eerst een regex op los te laten die controleert of het iets is dat ik verwacht en zo ja, dan converteer ik het naar het juiste type. en weer terug [ontopic].

[.oisyn]

JeRa schreef op zondag 14 januari 2007 @ 02:47:
[...]

Het idee achter == in PHP is dat de twee zijden van de vergelijking niet van hetzelfde type hoeven te zijn

Ik heb niet het idee dat je echt lees wat ik zeg, want ik zeg ook helemaal niet dat dat een fout iets is. Mijn idee, in pseudo-php:

PHP:

function operator==(int $a, string $b)
{
    if (!is_numeric($b))
        return false;
    else
        return $a == (int)$b;
}

if (0 == "aap")
    echo "deze output zul je nooit moeten krijgen";

// en om het oude PHP gedrag te krijgen, mocht je dat willen:
if (0 == (int)"aap")
    echo "deze output zul je wel krijgen";

Nogmaals, waarom vind jij dat "aap" gelijk moet zijn aan 0? Dat "0" gelijk moet zijn aan een 0 is natuurlijk logisch.
nu ga ik trouwens naar bed, morgen weer een dag

[ Voor 47% gewijzigd door .oisyn op 14-01-2007 03:07 ]

[Soultaker]

De conversie van string naar int wordt gedaan door atoi() of iets equivalents. Zo vreemd is dat toch niet? Waarom mag dat alleen zo werken bij een expliciete conversie?

Ok, impliciete conversie van strings is een ontwerpkeuze, die soms vervelende gevolgen heeft, maar als je niet klaagt dat atoi("aap") == 0, waarom dan wel dat in php "aap" == 0?

[ Voor 53% gewijzigd door Soultaker op 14-01-2007 03:15 ]

[JeRa]

.oisyn schreef op zondag 14 januari 2007 @ 02:55:
[...]

Nogmaals, waarom vind jij dat "aap" gelijk moet zijn aan 0?

Dat vind ik helemaal niet. Ik vind dat wanneer je "aap" met de ==-operator vergelijkt met 0, je moet beseffen dat je eigenlijk zegt: "zijn de twee waardes gebaseerd op het laagste type gelijk?" en dat conversie plaatsvindt zoals in de post hierboven wordt beschreven

Als je mij vraagt of "aap" gelijk moet zijn aan 0 in PHP, dan zeg ik nee. En dat klopt ook met PHP:

code:

if ('aap' === 0)
{
    echo 'nimmer';
}

[.oisyn]

Soultaker schreef op zondag 14 januari 2007 @ 03:14:
maar als je niet klaagt dat atoi("aap") == 0

Zou niet zo mogen zijn, maar er is nou eenmaal geen andere mogelijkheid in PHP (evenals in C natuurlijk, wat de reden is dat atoi 0 teruggeeft).

[ Voor 12% gewijzigd door .oisyn op 14-01-2007 11:29 ]

[Robtimus]

Wat ik me afvraag: waarom wordt bij een vergelijking tussen string en integer de string geconverteerd naar integer, en niet andersom?
"aap" == 0 zou dan worden "aap" == "0" wat dus false is.

De reden voor deze conversie is dat je (IMO) zou moeten converteren naar het meest brede type. Als je dan bedenkt dat zowat alles te converteren is naar een string is dat dan de meest logische keuze.

Er zijn trouwens wel meer typen denkbaar waarnaar geconverteerd kan worden:
- integer: "aap" == 0 wordt 0 == 0 dus true
- boolean: "aap" == 0 wordt true == false dus false
- string: "aap" == 0 wordt "aap" == "0" dus false

Waarom wordt hier dan juist de enige oplossing gekozen die true oplevert?

[XWB]

.oisyn schreef op zondag 14 januari 2007 @ 02:55:
[...]

Ik heb niet het idee dat je echt lees wat ik zeg, want ik zeg ook helemaal niet dat dat een fout iets is. Mijn idee, in pseudo-php:

PHP:

function operator==(int $a, string $b)
{
    if (!is_numeric($b))
        return false;
    else
        return $a == (int)$b;
}

if (0 == "aap")
    echo "deze output zul je nooit moeten krijgen";

// en om het oude PHP gedrag te krijgen, mocht je dat willen:
if (0 == (int)"aap")
    echo "deze output zul je wel krijgen";

Nogmaals, waarom vind jij dat "aap" gelijk moet zijn aan 0? Dat "0" gelijk moet zijn aan een 0 is natuurlijk logisch.
nu ga ik trouwens naar bed, morgen weer een dag

Probeer voor de grap dit eens uit

PHP:

$t = '1 dit is een string';

var_dump ( (int) $t == 1  );

Dat kan op zich nog gevaarlijk zijn als je daarmee controles doet.

PHP:

$userInput = '1 string';

if ( (int) $userInput > 0 )
{
    // doe iets
}

[ Voor 8% gewijzigd door XWB op 15-01-2007 15:11 ]

[.oisyn]

Hacku schreef op maandag 15 januari 2007 @ 15:08:
Probeer voor de grap dit eens uit

I know . is_numeric() geeft voor zo'n string gelukkig wel false.

JeRa schreef op zondag 14 januari 2007 @ 05:06:
Als je mij vraagt of "aap" gelijk moet zijn aan 0 in PHP, dan zeg ik nee. En dat klopt ook met PHP:

code:

if ('aap' === 0)
{
    echo 'nimmer';
}

Als je mij vraagt of 0.0 gelijk moet zijn aan 0, dan zeg ik ja. Toch zegt PHP nee:

PHP:

if (0.0 === 0)
    echo 'altijd';

Dus het gebruik van === is lang niet altijd een uitkomst (en als je toch altijd === wilt gebruiken, gebruik dan ook een strong-typed taal). Zeker als je gaat zitten delen, dan is je uitkomst de ene keer een int en de andere keer een float .

[ Voor 15% gewijzigd door .oisyn op 15-01-2007 16:24 ]

[XWB]

is_numeric() geeft voor zo'n string gelukkig wel false.

Yep en intval() maakt er toch 0 van.

Als je mij vraagt of 0.0 gelijk moet zijn aan 0, dan zeg ik ja. Toch zegt PHP nee:

Dat is ook niet juist, met === vergelijk je de types. Dus een float en een int en dat geeft inderdaad false.

PHP:

if (0.0 == 0)
    echo 'altijd';

[.oisyn]

Kijk even naar de reactie waar ik op reageerde.