[C++] Nut van Coercion

[curry684]

C++:

void Test(bool p_Fiets)
{
}

void main()
{
int  l_Index = 684;
Test(&l_Index);
}

[curry684]

Voor de duidelijkheid: dit compileert onder VAX/VMS probleemloos. Ik wil graag zien of andere omgevingen dit slikken en zo nee wat voor errors/warnings eruitkomen. Onderbouwing uit de C/C++ standaard mag erbij

[Glimi]

Ik zal het ff testen op BCB4 hier/W32. Het lijkt me echter wel dat het kan. Ik zie gewoon een geldige coercion staan.

[edit] Idd geen problemen met BCB4 hier. Zelfs geen warning

[ Voor 22% gewijzigd door Glimi op 24-06-2003 11:14 ]

[drm]

Ik vind dat je minstens een waarschuwing moet krijgen.

* drm probeert gcc even

edit:

gcc vindt 't alleen een probleem dat je main() als void hebt gedeclareerd, maar verder niks...

dat betekent dat je een int * dus ook kan casten naar een bool, als ik het goed begrijp, want dat is dan toch feitelijk wat er gebeurt? (impliciet)

Opzich is het dan zo gek niet...

edit:

gcc 3.2.2 en 2.9.6 tested btw

[ Voor 69% gewijzigd door drm op 24-06-2003 11:32 ]

[ACM]

Is een 'bool' niet min of meer een "typedef bool int;" ?
En een pointer is ook vrijwel hetzelfde als een int (ok, _ietsje_ anders )

Dus technisch is het correct. Ik ben wel met je eens dat een pointer naar een int iets anders is dan een bool en dat het dus niet zou mogen.
Dit imho wel: Test(100); maar die pointer naar de int maakt het wat lastiger

[Glimi]

Nou int* niet specefiek hoor, gewoon een geheugenadres, dus elke * zou kunnen. Als dat ding niet op 0 of NULL staat, dan wordt daar gewoon coercion (impliciete typeconversie) overheen gegooit.

Mjah, dat vind ik _echt_ een groot nadeel van coercion. Het maakt het typesysteem onnodig zwak en ingewikkeld voor wat suiker. Er liggen zelfs hele regels vast van hoe de volgorde van coercion geprobeerd moet worden.

[curry684]

Ik vind het achterlijk dat een willekeurige * zich blijkbaar impliciet laat casten naar een bool. Een bool kan nl. impliciet naar een int, en dus zou je alle typesafety in principe kwijt zijn.

Wij hadden hier dus een enorme bug op basis van een call naar functie X met een 'const &UUID' als param. Class UUID heeft een constructor 'bool p_Create = false'. Er werd een pointer naar een parameter struct aan X meegegeven, die vervolgens probleemloos als bool in de default constructor van UUID werd geramd... dat zijn nog eens bugs...

[Glimi]

Ik zal ome Stroustrup er ff op naslaan voor je (of ICQ/mail MSalter, die kent dat uit z'n kop)

[Glimi]

Ah gevonden:

quote: Stroustrup C.6.2.5

Boolean conversies
Pointers, integrale waarden en floating-pointwaarden kunnen impliciet worden geconverteerd naar bool( par. 4.2). Een waarde die ongelijk is aan null wordt naar true converteerd; de waarde null wordt naar false converteerd. Bijvoorbeeld:

C++:

void f( int*p, int i) {
   
   bool is_not_zero = p; // true als p!=0
   bool b2 = i;          // true als i!=0
}

[curry684]

Achterlijke shit imho

[.oisyn]

Om te testen of iets wel of niet mag: http://www.comeaucomputing.com/tryitout

En ja, pointers kunnen impliciet naar bool geconverteerd worden. Je moet immers kunnen testen of iets NULL is of niet door simpelweg te schrijven: if (ptr) { ... }. Het is zelfs zo dat als je een void * operator overload in een klasse, en je gebruikt de ! operator op die klasse, dat die void * operator dan aangeroepen wordt

[.oisyn]

ACM schreef op 24 June 2003 @ 11:38:
Is een 'bool' niet min of meer een "typedef bool int;"

nee, en het is ook niet min of meer een "enum bool { false, true };"

En een pointer is ook vrijwel hetzelfde als een int (ok, _ietsje_ anders )

er bestaat geen implicit conversion van int naar pointer en weer terug... daar heb je reinterpret_cast voor

Dus technisch is het correct. Ik ben wel met je eens dat een pointer naar een int iets anders is dan een bool en dat het dus niet zou mogen.
Dit imho wel: Test(100); maar die pointer naar de int maakt het wat lastiger

je kunt natuurlijk net zo hard if (100) doen als if (ptr), dus ik zie het probleem niet

4.12 - Boolean conversions [conv.bool]
-1- An rvalue of arithmetic, enumeration, pointer, or pointer to member type can be converted to an rvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true.

[ Voor 17% gewijzigd door .oisyn op 24-06-2003 13:22 ]

[ACM]

.oisyn schreef op 24 juni 2003 @ 12:58:
En ja, pointers kunnen impliciet naar bool geconverteerd worden. Je moet immers kunnen testen of iets NULL is of niet door simpelweg te schrijven: if (ptr) { ... }.

Moet

In java kan men het ook zonder... Daar doen ze gewoon if(object == null), waarom moet men in C(++) nou weer zo lui zijn?

[.oisyn]

curry684 schreef op 24 June 2003 @ 12:04:
Ik vind het achterlijk dat een willekeurige * zich blijkbaar impliciet laat casten naar een bool. Een bool kan nl. impliciet naar een int, en dus zou je alle typesafety in principe kwijt zijn.

ik snap je niet helemaal...
een pointer kan impliciet naar bool, en een bool kan impliciet naar int, maar een pointer kan niet impliciet naar int (ook niet impliciet via die bool conversie)
Noch kan een bool impliciet naar een pointer

Wij hadden hier dus een enorme bug op basis van een call naar functie X met een 'const &UUID' als param. Class UUID heeft een constructor 'bool p_Create = false'. Er werd een pointer naar een parameter struct aan X meegegeven, die vervolgens probleemloos als bool in de default constructor van UUID werd geramd... dat zijn nog eens bugs...

Je bedoelt zoiets?

C++:

struct UUID
{
    UUID (bool bla = false) { }
};

struct Params;
void X (const UUID & uuid);



void func (Params * p)
{
    X (p); // je wilt hier een compile-error, maar het compiled prima?
}

Je zou die UUID natuurlijk als explicit kunnen definieren, dan kan ie niet uit een bool parameter geconstruct worden:

C++:

struct UUID
{
    explicit UUID (bool bla = false) { }
};

en hop, daar is je compile error:

code:

"ComeauTest.c", line 13: error: no suitable constructor exists to convert from
          "Params *" to "UUID"
      X (p);

[.oisyn]

ACM schreef op 24 June 2003 @ 13:32:
[...]

Moet

In java kan men het ook zonder... Daar doen ze gewoon if(object == null), waarom moet men in C(++) nou weer zo lui zijn?

in java kun je ook niet schrijven

Java:

int i = 34;
if (i) { }

en ja, dat zuigt. Wat is er mis met implicit conversions van pointers naar bool? Ik vind het heerlijk dat je kunt doen:

C++:

void func (void * ptr = NULL)
{
    if (!ptr)
    {
    }
    else
    {
    }
}

En zeg asjeblieft niets over java, want daar zijn de bitwise operators niet gedefinieerd voor byte, short en char, terwijl de bijbehorende assignment operatoren wel bestaan

Java:

byte a, b, c;

a = b & c; // error: can't implicitely convert int to bool
a &= b; // geen error

[curry684]

ik snap je niet helemaal...
een pointer kan impliciet naar bool, en een bool kan impliciet naar int, maar een pointer kan niet impliciet naar int (ook niet impliciet via die bool conversie)

Wat gewoon stom is want de compiler hoort een pad van 2 impliciete conversies te ontdekken en uit te voeren.

Die explicit had ik wel bedacht maar door een hersenkronkel met dat de enige parameter een default value heeft dacht ik dat die niet lekker zou gaan... onzin natuurlijk

[ACM]

.oisyn schreef op 24 June 2003 @ 13:35:
in java kun je ook niet schrijven

Java:

int i = 34;
if (i) { }

En?
Wat maakt de 0 zo bijzonder dat ie een andere behandeling mag krijgen dan de 1 of -1?

en ja, dat zuigt.

Want?

Wat is er mis met implicit conversions van pointers naar bool? Ik vind het heerlijk dat je kunt doen:

Het laat allerlei ranzige conversies toe voor zaken waar helemaal geen geldige operaties meer op uitgevoerd worden?
Zie het voorbeeld van Curry. Als hij een boolean verwacht, waarom mag er dan een pointer meegegeven worden

C++:

void func (void * ptr = NULL)
{
    if (!ptr)
    {
    }
    else
    {
    }
}

In java doe je dat gewoon zo:

Java:

void func()
{
 // null versie
}

void func(Object x)
{
 // niet null versi
}

En zeg asjeblieft niets over java, want daar zijn de bitwise operators niet gedefinieerd voor byte, short en char, terwijl de bijbehorende assignment operatoren wel bestaan

Dus omdat de bitwise operators anders zijn dan jij verwacht mogen we niet eens meer over java praten op andere gebieden

Java:

byte a, b, c;

a = b & c; // error: can't implicitely convert int to bool
a &= b; // geen error

Ah...
Waarom krijg ik dan bij deze geen errors?

Java:

class Test
{
        public int main(String[] argv)
        {
                byte b = (byte)0, c = (byte)0;
                int a;

                a = b & c;
                return 0;
        }
}

edit:

andere code genomen

[ Voor 10% gewijzigd door ACM op 24-06-2003 13:54 ]

[whoami]

.oisyn schreef op 24 juni 2003 @ 13:35:
[...]


in java kun je ook niet schrijven

Java:

int i = 34;
if (i) { }

en ja, dat zuigt. Wat is er mis met implicit conversions van pointers naar bool? Ik vind het heerlijk dat je kunt doen

Dat zuigt? Nee, dat vind ik niet. Gewoon een kwestie van gewoonte.
Java en C# laten dergelijke constructie niet toe, en eigenlijk vind ik dat niet erg. Zo'n constructie leest imho niet zo lekker vind ik tov van de Java/C# versie.

[.oisyn]

ACM schreef op 24 juni 2003 @ 13:51:
[...]

En?
Wat maakt de 0 zo bijzonder dat ie een andere behandeling mag krijgen dan de 1 of -1?

Dat stamt af van C, waar er nog geen boolean type was. Desalniettemin vind ik het behoorlijk lekker coden om niet steeds die == of != erbij te typen. Bovendien was het originele ontwerp van C++ om enigzins backwards compatible te zijn met C.

Overigens heb je in Java geen pointers, dus is het vrij logisch dat die referenties naar classes ook niet impliciet naar bool geconverteerd kunnen worden

Het laat allerlei ranzige conversies toe voor zaken waar helemaal geen geldige operaties meer op uitgevoerd worden?
Zie het voorbeeld van Curry. Als hij een boolean verwacht, waarom mag er dan een pointer meegegeven worden

Waarom is het 'probleem' van curry ook echt een probleem? Als je bijvoorbeeld 23 meegeeft dan werkt het ook. En dat terwijl er een bool wordt verwacht. Dat is dan ook onjuist volgens jouwzelfde redenering

In java doe je dat gewoon zo:

Ja ook zoiets, het missen van default arguments. Heb ik hier op mijn stage ook nog een paar dagen op zitten schelden omdat ik 5 varianten van dezelfde functie moest maken

Dus omdat de bitwise operators anders zijn dan jij verwacht mogen we niet eens meer over java praten op andere gebieden

ik wilde er alleen maar mee aangeven dat java het niet per definitie bij het juiste eind heeft

Ah...
Waarom krijg ik dan bij deze geen errors?

Zie ICQ, omdat je assigned aan een int, omdat operator & (byte, byte) niet gedefinieerd is, waardoor operator & (int, int) wordt aangeroepen, en ja, die heeft als resultaat een int.
En het kromme is nou juist dat de and-assignment wel gedefinieerd is

[.oisyn]

curry684 schreef op 24 June 2003 @ 13:48:
[...]

Wat gewoon stom is want de compiler hoort een pad van 2 impliciete conversies te ontdekken en uit te voeren.

helemaal niet, de C++ compiler doet nu eenmaal niet aan backtracking. Dit werkt tenslotte ook niet:

C++:

struct A { };
struct B { operator A (); };
struct C { operator B (); };

// C kan dus naar B, en B kan weer naar A

void func (const A &);

int main ()
{
    C c;
    func (c);
}

Zou wat worden als dat wel zo was, je zit zelf al af te geven op die implicit conversions, kun je nagaan hoe het zou zijn als de compiler dmv backtracking al die conversies zelf uitvindt (met alle ambigu'e gevolgen van dien)

[ACM]

DC -> P&W

[Glimi]

Yay ik ga me ook hier in mengen

curry684 schreef op 24 June 2003 @ 13:48:
Wat gewoon stom is want de compiler hoort een pad van 2 impliciete conversies te ontdekken en uit te voeren.

Nou dat is _juist_ de reden dat impliciete conversies een pain in the ass zijn. Welke conversie moet geprobeerd worden op het operand in welke volgorde, zodat uiteindelijk het juiste type gevonden wordt. Op een gegeven ogenblik wordt het echt lekker ingewikkeld hoor Mede hierdoor wordt je type-systeem gelijk zwakker, wat we in dit geval goed zien. Waarom kunnen we opeens een pointer in een bool proppen, alleen omwille een handjevol suiker

Dat is ook de reden dat Java het niet toestaat en er alleen intern coercion gedefinieerd is op bepaald aritmische operatoren en primieven

.oisyn schreef op 24 June 2003 @ 13:35:
En zeg asjeblieft niets over java, want daar zijn de bitwise operators niet gedefinieerd voor byte, short en char, terwijl de bijbehorende assignment operatoren wel bestaan

Java:

byte a, b, c;

a = b & c; // error: can't implicitely convert int to bool
a &= b; // geen error

Dat vind ik ook een beetje raar, maar & en | worden uitgevoerd op int's. b en c worden dus eerst ge'coercioned naar een int en daarna uitgevoerd. Dat men het vervolgens met &= anders doet, vind ik op z'n minst _erg_ slordig.

ACM schreef op 24 June 2003 @ 13:51:
Het laat allerlei ranzige conversies toe voor zaken waar helemaal geen geldige operaties meer op uitgevoerd worden?
Zie het voorbeeld van Curry. Als hij een boolean verwacht, waarom mag er dan een pointer meegegeven worden

Het is een doortrekking van de byte -> int -> long conversies die ook automatisch worden gedaan. In C/C++ moet je nou eenmaal alles kunnen controleren, dus dit hebben ze ook controleerbaar gemaakt itt wat java doet.

In java doe je dat gewoon zo:

Java:

void func()
{
 // null versie
}

void func(Object x)
{
 // niet null versie
}

Dat wist ik niet? Volgens mij niet... ff testen

Java:

import java.io.*;

public class Bla {

    public static void main( String args[] ) {

        String s = null;
        woei( s );
    }

    public static void woei( ) {

        System.out.println( "Nu in de no-parm versie" );
    }

    public static void woei( String s ) {

        System.out.println( "Nu in de string versie" );
    }
}

Geef mij als output "Nu in de string versie". Hij ziet null toch echt als object hoor? Ook als ik woei( null ) doe krijg ik de string versie.

We moeten ons trouwens al helemaal niet gaan concentreren op de Java <-> C++ verschillen, aangezien java geen impliciete conversie toestaat
Verder is een if( ptr) waardevoller in C++ omdat me toch opvalt dat men daar vaker met pointer berekeningen en null waardes bezig is (waar in Java null vaak niet als geldige waarde gezien wordt)
Hmmmz dit zou wel een leuk P&W topic kunnen worden. Naam kan bijv zijn 'Impliciete casting zuigt aars'
*edit* hij staat er al

[.oisyn]

Glimi schreef op 24 June 2003 @ 14:32:
We moeten ons trouwens al helemaal niet gaan concentreren op de Java <-> C++ verschillen, aangezien java geen impliciete conversie toestaat

* kuch *
nee, want dit werkt tenslotte ook niet

Java:

void func (int i)
{
}

void func2 ()
{
    byte b = 2;
    func (b);
}

[Gerco]

Ik ben het grotendeels eens met "Impliciete conversie zuigt aars", maar dan voornamelijk van deze in Visual Basic beruchte constructie:

Visual Basic .NET:

 Debug.Print "1" + 1

Dit is "11" of 2, afhankelijk van de stand van de maan ofzo, maar dit is persoonlijk het vreselijkste voorbeeld van impliciete conversie wat ik ooit gezien heb.

Verder ben ik het volledig eens met de stelling "int -> bool of ptr -> bool is fout". In C++ is er een "echt" bool datatype gekomen, behandel dat dan ook als een echt datatype en niet als een typedef.

[ Voor 10% gewijzigd door Gerco op 24-06-2003 15:08 ]

[gorgi_19]

Gerco schreef op 24 juni 2003 @ 15:07:
Ik ben het grotendeels eens met "Impliciete conversie zuigt aars", maar dan voornamelijk van deze in Visual Basic beruchte constructie:

Visual Basic .NET:

 Debug.Print "1" + 1

Dit is "11" of 2, afhankelijk van de stand van de maan ofzo, maar dit is persoonlijk het vreselijkste voorbeeld van impliciete conversie wat ik ooit gezien heb.

Mede daarom hebben ze ook & ingevoerd voor strings, afaik. VB gaat echter ook steeds meer over naar een expliciete conversie, getuige het bestaan van option strict in VB.Net (een nog strengere vorm dan Option Explicit)

Logisch zou ik vinden:

Visual Basic .NET:

 Debug.Print "1" + 1

levert 2 op en

Visual Basic .NET:

 Debug.Print "1" & 1

levert 11 op.

Echter, ik denk dat als ze nu bij een aantal talen impliciete conversie af gaan schaffen of verbieden, een hoop applicaties niet meer gaan werken..

[Glimi]

.oisyn schreef op 24 June 2003 @ 14:57:
* kuch *
nee, want dit werkt tenslotte ook niet

Zeg crew-flapdrol van het eerste uur als jij nou eens de hele post leest en ziet dat ik daarvoor stel dat:

Dat is ook de reden dat Java het niet toestaat en er alleen intern coercion gedefinieerd is op bepaald aritmische operatoren en primieven

dan had je ook wel kunnen zien dat ik daar user defined coercion en alle niet 'upcastende' coercions mee bedoel
Dat ik het wat cru'tjes neerzet ala, maar die post was al zo lang

_{En ik moet ook es leren niet op oisyn in te gaan}

[.oisyn]

Gerco schreef op 24 juni 2003 @ 15:07:
In C++ is er een "echt" bool datatype gekomen, behandel dat dan ook als een echt datatype en niet als een typedef.

.oisyn schreef op 24 juni 2003 @ 13:20:

---

ACM: Is een 'bool' niet min of meer een "typedef bool int;"

---

nee, en het is ook niet min of meer een "enum bool { false, true };"

bool is een eigen type, met eigen conversies. Dit is niet voor niets een aparte clausule in de standaard:

4.12 - Boolean conversions [conv.bool]
-1- An rvalue of arithmetic, enumeration, pointer, or pointer to member type can be converted to an rvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true.

De reden voor die conversie? Waarschijnlijk backwards compatibility met C. Bovendien werkt het gewoon lekker.

Wat C++ imho echter wel mist is een apart null type. Dat wordt nu nog aangegeven met een int, wat weer tot de nodige problemen leidt:

C++:

void func (int);
void func (void *);

int main ()
{
    func (0);
    func (NULL);
}

zoek de fout

[.oisyn]

Glimi schreef op 24 June 2003 @ 15:13:
Zeg crew-flapdrol van het eerste uur als jij nou eens de hele post leest en ziet dat ik daarvoor stel dat:

tuurlijk niet, ik las alleen het gedeelte waarin je mij quotte, en het stuk dat erna kwam. Dat ervoor sloeg niet op mij en is voor mij dus ook niet belangrijk

[curry684]

Gerco: die constructie zou in C++ hoogstwaarschijnlijk failen met een 'ambiguity error' omdat het 1 stap is om van een int een string te maken, en vice versa ook. Ik ga er van uit dat het iig directe typeconversies zijn en er geen lelijke omwegen gemaakt hoeven worden, maar zelfs dan nog zou het in ieder geval consequent hetzelfde resultaat opleveren.

[Soultaker]

Ik moet zeggen dat ik de strengere regels van Java eigenlijk veel prettiger vind. Ten eerste leest if(x == null) of if(y != 0) best prettig (er is direct duidelijk wat je conditie nu eigenlijk inhoudt) en ten tweede hoef je je nooit meer af te vragen of er misschien een onbedoelde conversie optreedt (zoals in het voorbeeld waar de topic starter tegenaan liep). Ik vind verder dat een Booleaanse variabele niets met getalletjes te maken heeft (al worden ze intern zo gerepresenteerd) en het is dus onzin dat je zo'n bool heen en weer kan converteren; het is gewoon een apart type dat geen deel uit maakt van het numerieke systeem.

Ik kan het het ontwerp van C++ niet aanrekenen, want het is duidelijk dat die impliciete conversies toegestaan zijn om de backward compatibility met C te behouden.

Overigens vind ik het in Java ook prettig dat je een waarde niet naar een data type met minder precisie kunt converteren zonder cast (van double naar float of van long naar int, bijvoorbeeld). Wel weer jammer dat de Java API dan weer stompzinnige methoden kent als getChar() die een int retourneert, terwijl je daar als gewone gebruiker gewoon een char uit wilt krijgen (ja, ik weet het, daar past EOF niet in). Door zulke constructies wordt zo'n mooie feature weer een onnodige last; beetje jammer dus.

[ACM]

Ik vind dit wel een mooie reden waarom het slecht is

C:

void main()
{
        int i = -1;
        while(i--);
}

acm $ gcc test.c
acm $ time ./a.out

real    0m24.750s
user    0m21.960s
sys     0m0.150s

acm $ gcc-3.2 -march=athlon-tbird -O3 test.c
acm $ time ./a.out

real    0m11.193s
user    0m10.200s
sys     0m0.050s

acm $ gcc-3.2 -march=athlon-tbird -O9 -funroll-loops test.c
acm $ time ./a.out

real    0m2.637s
user    0m2.530s
sys     0m0.060s

Zelfs met de maximale optimalisaties van gcc-3.2 weet de c-compiler je fout niet efficient weg te optimaliseren
En dat ie ruwweg 4miljard iteraties te veel doet... ach

(waarbij ik die while als een shortcut voor while(i-- > 0) bedoel overigens )

[ Voor 6% gewijzigd door ACM op 24-06-2003 16:10 ]

[.oisyn]

Soultaker schreef op 24 juni 2003 @ 16:03:
Overigens vind ik het in Java ook prettig dat je een waarde niet naar een data type met minder precisie kunt converteren zonder cast (van double naar float of van long naar int, bijvoorbeeld).

dat kan in C++ ook niet

ACM schreef op 24 juni 2003 @ 16:05:
Ik vind dit wel een mooie reden waarom het slecht is

C:

void main()
{
        int i = -1;
        while(i--);
}

Dat is zonder implicit conversion naar bool niet anders:

C:

void main()
{
        int i = -1;
        while(i-- != 0);
}

.edit: edit ie net z'n post

(waarbij ik die while als een shortcut voor while(i-- > 0) bedoel overigens )

Aha, maar dan is het dus een fout van de programmeur, want een if (i) is niet hetzelfde als een if (i > 0)

Daar zit een essentieel verschil, waar de impliciete conversie naar bool niets mee te maken heeft

[ Voor 21% gewijzigd door .oisyn op 24-06-2003 16:11 ]

[ACM]

.oisyn schreef op 24 June 2003 @ 16:10:
Dat is zonder implicit conversion naar bool niet anders:

C:

void main()
{
        int i = -1;
        while(i-- != 0);
}

Zie mijn edit en ik denk dat iemand sneller de fout zal zien als er while(i-- != 0) staat dan while(i--)

.oisyn schreef op 24 June 2003 @ 16:10:
.edit: edit ie net z'n post

[...]


Aha, maar dan is het dus een fout van de programmeur, want een if (i) is niet hetzelfde als een if (i > 0)

Daar zit een essentieel verschil, waar de impliciete conversie naar bool niets mee te maken heeft

Dat klopt, maar ik heb het idee dat de impliciete conversie het wel uitnodigd op zo'n manier fout te doen.

[ Voor 41% gewijzigd door ACM op 24-06-2003 16:14 ]

[curry684]

Over cast-loos converteren van variabelen naar minder precisie zei oisyn:

dat kan in C++ ook niet

En jij vindt een 64-bits pointer impliciet downcasten naar een boolean die per definitie 2 waardes bevat geen 'automatische conversie waarbij precisie verloren gaat'?!?

[.oisyn]

ACM schreef op 24 juni 2003 @ 16:11:
Dat klopt, maar ik heb het idee dat de impliciete conversie het wel uitnodigd op zo'n manier fout te doen.

mja, dat idee heb ik dus weer niet
Ik zie een if zonder test ook daadwerkelijk als een test op 0, en niet een test voor groter dan 0 of iets anders

Ik zou een dergelijke constructie daar sowieso nooit gebruiken, ook de expliciete != 0 niet, want dat is vragen om moeilijkheden

Als je moet programmeren dat iets moet gebeuren zolang een waarde groter dan 0 is, kun je het natuurlijk zo bouwen dat ie stopt zodra ie 0 is. Beter is natuurlijk ook gewoon te programmeren dat ie doorgaat zolang ie groter dan 0 is

[Glimi]

.oisyn schreef op 24 June 2003 @ 16:10:
dat kan in C++ ook niet

C++:

char func( double d ) {

        char z = d;
        return z;
}

int main(int argc, char* argv[])
{
        char p = func( 30.0 );
        return 0;
}

No problem hier.

[ Voor 4% gewijzigd door Glimi op 24-06-2003 16:21 ]

[curry684]

Ter illustratie van die laatste post: voorspel output van dit programma:

C++:

#include <stdio.h> 

void Test(bool p_Fiets)
{
printf("%d %d\n", p_Fiets, (int)p_Fiets);
}

int main() 
{ 
int   A = 684;
Test(&A);
return 0; 
}

[whoami]

1 684 ?

[ Voor 46% gewijzigd door whoami op 24-06-2003 16:23 ]

[Glimi]

curry684 schreef op 24 June 2003 @ 16:20:
Ter illustratie van die laatste post: voorspel output van dit programma:

C++:

#include <stdio.h> 

void Test(bool p_Fiets)
{
printf("%d %d\n", p_Fiets, (int)p_Fiets);
}

int main() 
{ 
int   A = 684;
Test(&A);
return 0; 
}

Non -tested:
1 1\n denk ik.
[edit] Oeh, wat heb ik gewonnen! Tell me

[ Voor 6% gewijzigd door Glimi op 24-06-2003 16:26 ]

[.oisyn]

curry684 schreef op 24 June 2003 @ 16:18:
En jij vindt een 64-bits pointer impliciet downcasten naar een boolean die per definitie 2 waardes bevat geen 'automatische conversie waarbij precisie verloren gaat'?!?

Zie jij een conversie naar boolean als iets integers dan? Ik niet. Een boolean is geen arithmetic type, en het hele precisie verhaal is derhalve niet relevant.

Je moet de conversie naar boolean zien als een test of de waarde 0 is of niet, niet meer en niet minder.

Van int naar char gaat er precisie verloren ja, maar dat zijn ook beide rekenwaardes. Bool past helemaal niet in het rijtje char -> short -> int -> long -> float -> double

Of was jouw UUID ook een representatie van het type bool die je als argument kon geven?

[ Voor 7% gewijzigd door .oisyn op 24-06-2003 16:24 ]

[ACM]

.oisyn schreef op 24 June 2003 @ 16:24:
Bool past helemaal niet in het rijtje char -> short -> int -> long -> float -> double

Wat dus nou precies de reden is dat er geen automatische conversie zou moeten zijn

[.oisyn]

Glimi schreef op 24 juni 2003 @ 16:20:
No problem hier.

hmm idd, dan ben ik in de war met VC++ die altijd keurig een warning geeft

[Glimi]

.oisyn schreef op 24 June 2003 @ 16:27:
hmm idd, dan ben ik in de war met VC++ die altijd keurig een warning geeft

Een warning zegt niet dat het niet kan
[/wijsneus]

[curry684]

Zie jij een conversie naar boolean als iets integers dan? Ik niet. Een boolean is geen arithmetic type, en het hele precisie verhaal is derhalve niet relevant.

Sja je moet wel kiezen he. Of het zijn related types en er gaat dus precisie verloren, of het zijn unrelated types en er zou nooit een implicit conversion op plaats mogen vinden.

[curry684]

ps. glimi: niet gewonnen, \n is een newline en wordt dus niet uitgeprint whoami is gewoon een prutz0r die eens te mee bewijst dat ie z'n mond moet houden in C++ topics

[.oisyn]

curry684 schreef op 24 June 2003 @ 16:20:
Ter illustratie van die laatste post: voorspel output van dit programma:

C++:

#include <stdio.h> 

void Test(bool p_Fiets)
{
printf("%d %d\n", p_Fiets, (int)p_Fiets);
}

int main() 
{ 
int   A = 684;
Test(&A);
return 0; 
}

slecht voorbeeld, printf maakt gebruik van de ellipsis, en derhalve worden alle integral types geconverteerd naar int (of long?) en alle floating point types geconverteerd naar double.
De 2 parameters hebben dan ook geen verschil, beide worden gecast naar int/long

Als je bool zou zien als integral type met 2 waarden, 0 en 1, dan zal een conversie van double 0.3 naar bool false opleveren. Echter levert het true op. Het is dan ook totaal geen representatie van een waarde in een ander systeem

[.oisyn]

curry684 schreef op 24 June 2003 @ 16:31:
[...]

Sja je moet wel kiezen he. Of het zijn related types en er gaat dus precisie verloren, of het zijn unrelated types en er zou nooit een implicit conversion op plaats mogen vinden.

wat dus gedaan is om backward compatible te zijn met C, en ik persoonlijk vind het wel handig. Oh wacht, dat zei ik geloof ik aan de begin van de thread al
Maar ik had al aangegeven dat ik uberhaupt fout zat over het feit dat C++ wel of geen implicit conversions toestaat van types naar types met een lagere precizie

[ Voor 15% gewijzigd door .oisyn op 24-06-2003 16:38 ]

[.oisyn]

Glimi schreef op 24 juni 2003 @ 16:30:
[...]

Een warning zegt niet dat het niet kan
[/wijsneus]

VC++ geeft wel meer warnings waar het errors moeten zijn, dus dat zegt natuurlijk ook weer helemaal niets

[whoami]

curry684 schreef op 24 June 2003 @ 16:33:
ps. glimi: niet gewonnen, \n is een newline en wordt dus niet uitgeprint whoami is gewoon een prutz0r die eens te mee bewijst dat ie z'n mond moet houden in C++ topics

Nietes, ik had ook eerst 1 1, maar ik zag dan dat Glimi dat ook had, en ik wou iets unieks.
Vandaar heb ik het dus gewijzigd. Ik wou nl. de enige winnaar zijn, en ik was bereid om daarvoor een risico te nemen.

Trouwens, ook hier geldt vrijheid van meningsuiting.

en nu verder ontopic

[Glimi]

.oisyn schreef op 24 June 2003 @ 16:36:
VC++ geeft wel meer warnings waar het errors moeten zijn, dus dat zegt natuurlijk ook weer helemaal niets

Maar dat ik die code uit Stroustrup haal, zegt wel wat . Moment ik quote even het hele stuk:

quote: Stroustrup C.6.2

De basistypen kunnen op een verbijsterende hoeveelheid manieren naar elkaar worden geconverteerd. Naar mijn mening zijn er te veel conversies toegestaan. Bijvoorbeeld : [insert double to char code here]
Bij het schrijven van programmacode moet u er altijd naar streven om ongedefinieerd gedrag te voorkomen en om conversies te vermijden waarmee stilzwijgend informatie verloren gaat. Compilers kunnen voor veel dubieuze conversies waarschuwen. Gelukkig doen veel compilers dat ook.

[MSalters]

Impliciete conversies zuigen echt heel hard. Het aantal keren dat ik verrast ben door het resultaat van zoiets simpels als (a<b) . Het probleem: in C moeten de types hetzelfde zijn, en als een van de twee signed is, en de andere unsigned, dan kun je dus soms gekke resultaten. Ikzelf heb de regel dat ik in een mixed-type comparison altijd zelf de cast doe. Dat is niet alleen makkelijker voor mij, maar ook voor diegene na me.

[hobbit_be]

Soultaker schreef op 24 June 2003 @ 16:03:
Wel weer jammer dat de Java API dan weer stompzinnige methoden kent als getChar() die een int retourneert, terwijl je daar als gewone gebruiker gewoon een char uit wilt krijgen (ja, ik weet het, daar past EOF niet in). Door zulke constructies wordt zo'n mooie feature weer een onnodige last; beetje jammer dus.

Nou ik ben vandaag de hele godganse dag in de weer geweest om met Java iets met 'unsigned' bytes (en bits) te doen - je ziet de bui al hangen - moest gewoon int's gebruiken en vandaar dat een write(int a) met als doc: writes BYTE to stream. Soms is het echt een kluchttaal (geef me 1 voorbeeld waarom signed / unsigned er niet bij zouden mogen zitten) ... Nu goed twerkt maar veel te veel moeite gekost. Verplichte casts vind ik wel dik in orde.

offtopic:
had het nodig om een Flash MX Swf file direct te generen om zo het 'legaal' te kunnen gebruiken

[Orphix]

[hk]


[/hk]