Portál AbcLinuxu, 26. května 2024 00:14
predcasem jsem objevil ve svem kodu chybu... teda neda se rict, ze bych ji nejak objevil... o tom, ze je tam problem jsem vedel, uz kdyz jsem to psal. a neda se rict, ze by to byla chyba, protoze ten program funguje bez problemu a i pres urcite snahy se mne tu chybu nepodarilo presvedcit, aby se chovala jako chyba.
#define INT (1)
#define FLOAT (2)
struct object {
int type;
union {
int num_int;
float num_float;
} value;
};
#define get_number(x) (x.type == INT ? x.value.num_int : x.value.num_float)
int main(int argc, char ** argv)
{
struct object foo, bar;
foo.type = argc; /* INT */
foo.value.num_int = 42;
bar.type = argc + 1; /* FLOAT */
bar.value.num_float = 42.0;
printf("%s\n", get_number(foo) == get_number(bar) ? "Wow, it works" : "Oops");
return 0;
}
jako ve vsech podobnych soutezich, vitez vyhrava cokoladu! (z lidlu za tri padesat) ;-]
argc je tam kvuli tomu, aby prekladac nevedel co tam bude za typ.
Tiskni
Sdílej:
3.9.2007 00:23
mkoubik | skóre: 5
| blog: lorem_ipsum
| Praha 8 - Bohnice
To, že tu režii u pythonu nevidíš, ještě neznamená, že neexistuje... I python si za běhu musí někde pamatovat, co těch N bytů na dané adrese v ten který okamžik vlastně je. A režii při konverzi typů má jakbysmet.
Nehlede na to, ze takova struktura zabira v pameti misto za oba typy + rezije.Je to union, takže nezabírá místo za oba typy, ale jenom za ten větší.
get_number(foo) = 42
get_number(bar) = 42.0
printf("%s\n", 42 == 42.0 ? "Wow, it works" : "Oops");
#define INT (1)
#define FLOAT (2)
struct object {
int type;
union {
int num_int;
float num_float;
} value;
};
#define get_number(x) (x.type == INT ? x.value.num_int : x.value.num_float)
int main(int argc, char ** argv)
{
struct object foo, bar;
foo.type = argc; /* INT */
foo.value.num_int = 22133335;
bar.type = argc + 1; /* FLOAT */
bar.value.num_float = 22133325.0;
printf("%s\n", get_number(foo) == get_number(bar) ? "Wow, it works" : "Oops");
return 0;
}
$ make bug
cc bug.c -o bug
bug.c: In function ‘main’:
bug.c:23: warning: incompatible implicit declaration of built-in function ‘printf’
$ ./bug
Oops
)
#define get_number(x) (x.type == INT ? x.value.num_int : x.value.num_float)toto makro vrati vzdy stejny typ, takze vrati bud vzdy int, nebo float (vraceny typ tedy neni zavisly na
x.type a ani z logiky veci nemuze byt, hodnota je vzdy prevedena)
double.
get_number(foo) = 42.0 get_number(bar) = 42.0
int main(int argc, char ** argv)
{
struct object foo, bar;
foo.type = argc; /* INT */
foo.value.num_int = 13133325;
bar.type = argc + 1; /* FLOAT */
bar.value.num_float = 13133325.0;
printf("%s\n", get_number(foo) == get_number(bar) ? "Wow, it works" : "$
printf("%d %f\n", get_number(foo), get_number(bar));
printf("%f %f\n", get_number(foo), get_number(bar));
return 0;
}
$ ./bug
Wow, it works
14 13133325.000000
13133325.000000 13133325.000000
[martin@dione buga]$ ./buga Wow, it works 0 0.000000 42.000000 42.000000Zkoušel jsem to kompilovat s gcc ještě na dvou jiných strojích(AMD64 a někaký MIPS) a tam je ten druhý parametr správně … že by bug mého gcc? ;)
Já bych řekl, že je to zcela korektní program, který otestuje, zda (double)42 == (double)42.0F.
3.9.2007 11:12
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Profesiální programátor nejsem, ale pamatuju, že dvě reálná čísla nelze porovnávat ... vzhledem k reprezentaci dat v počítači ... takže taky čekam na vyjevení pravdy svaté
Může se totiž velice snadno stát, že dva výrazy, které v opravdových reálných číslech dají identický výsledek, ve floating-point reprezentaci dají výsledky maličko jiné, jelikož se zaokrouhlovací chyby zkombinují různě.
Pokud máte zaokrouhlovací chyby pod kontrolou, může být porovnávání floatů na rovnost bezpečné. Jako třeba v našem případě: (double)42 == (double)42.F by neplatilo jen tehdy, kdyby float neměl dostatek přesnosti na zcela přesnou reprezentaci čtyřicetdvojky, a to není pravda. [Tedy úplně striktně vzato, z normy to neplyne, ale sotva existuje stroj, který by používal takové floaty.]
Proč by to nemohl vědět? On přece ví, že foo.value.num_int je typu int a foo.value.num_float typu float, protože jste mu to tak nadeklarovat. Takže tam máte podmíněný výraz, kde je jeden operand int a druhý float, proto se vám podle standardních pravidel oba konvertují na double a výsledek je double. Je to přesně totéž, jako když napíšete
int i = 1; float f = 0.5; result = i + f;
kde proměnná result bude nějakého číselného typu.
Makro nic nevrací, to není inline funkce. Makro vyhodnotí už preprocesor a překladač místo něj zpracovává výsledek expanze. Takže přes všechnu mlhu to není nic jiného, než kdybyste napsal
int i = 42; float f = 42.0; if ((b : i : f) == (!b : i : f)) ...
Protože druhý a třetí operand operátoru ?: jsou různé, provede se implicitní typová konverze obou na double, stejně jako kdybyste tam místo 'b : i : f' měl třeba 'i + f'. Takže nakonec jde jen o to, zda platí
((double) 42) == ((double) 42.0)
Což podle platformy a překladače někde platit může a jinde ne.
b ? i : f', b je nějaká proměnná typu int.
3.9.2007 22:53
michich | skóre: 51
| blog: ohrivane_parky
Väčšina operátorov vykonáva koverzie a produkuje typy výsledkow podobným spôsobom. Tento postup budeme nazývať obvyklé aritmetické konverzie.
- Naprv sa kažký operand typu
charaleboshortkonvertuje nainta každý operandfloatsa konvertuje nadouble.- Potom ak je niektorý z operandov typu
double, druhý sa konvertuje nadoublea výsledok je typudouble.- ...
(Programovací jazyk C, 2. vydanie, Alfa 1989, příloha A, sekce 6.6)
Ale co jsem se díval do aktuální ISO specifikace, podle ní by to v tomto případě měl opravdu být float. Kam to ten svět spěje, když už člověk nemůže věřit ani autorům jazyka… :-)
printf("%d %f\n", get_number(foo), get_number(bar));a pak to takto přeložit:
[martin@dione buga]$ gcc -std=c99 -pedantic -Wall buga.c -o buga buga.c: In function ‘main’: buga.c:28: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘double’ [martin@dione buga]$Je tam z té chybové hlášky pěkně vidět, zě se mi to přetypovalo na double…
).
double.
Mozna by to chtelo zkusit neco jineho nez printf:
printf("1:%d 2:%d 3:%d\n", 1.1f, 1);
Prvni dve cilsa budou nesmysly, ale to treti bude 1, protoze float jako variabilni parametr se vzdy prevede na double (takze jeho velikost obsadi ty prvni 2 parametry u platforem kde double=8 a int=4)
#include <iostream>
template<typename T>
struct test
{
static const bool is_float = false;
};
template<>
struct test<float>
{
static const bool is_float = true;
};
template<typename T>
bool is_float(T)
{
return test<T>::is_float;
}
#define INT (1)
#define FLOAT (2)
struct object {
int type;
union {
int num_int;
float num_float;
} value;
};
#define get_number(x) (x.type == INT ? x.value.num_int : x.value.num_float)
int main(int argc, char ** argv)
{
struct object foo, bar;
foo.type = argc; /* INT */
foo.value.num_int = 42;
bar.type = argc + 1; /* FLOAT */
bar.value.num_float = 42.0;
std::cout << ( is_float(get_number(foo)) ? "Ano\n" : "Ne\n" );
return 0;
}
V tom draftu ISO/IEC 9899, který jsem našel na webu, je to sekce 6.5.15. Podstatné pasáže:
One of the following shall hold for the second and third operands:
- both operands have arithmetic type;
- ...
...
If both the second and third operands have arithmetic type, the result type that would be determined by the usual arithmetic conversions, were they applied to those two operands, is the type of the result.
protoze java v takovem pripade rve chybu, ze neco takoveho je hodne hloupy napadJste si jist? Nezkousel jsem to, ale podle tohoto odkazu bych rekl, ze to dopadne stejne jako v c/c++.
true ? 1 : 1f typ float.
public static void main(String[] args) {
Float f = new Float(42.0f);
Integer i = new Integer(42);
System.out.println(true ? f : i);
}
gcj: error: Incompatible type for '?:'. Can't convert 'java.lang.Float' to 'java.lang.Integer'.
ja uz jsem na to prave jednou narazil v prave v jave a divil jsem se proc to v C proslo...
Float f = new Float(42.0f); Integer i = new Integer(42); Number x = true ? f : i;nebo
float f = true ? 1 : 1f;
float f = 16777216.0;
int i = 16777216;
printf("%d\n%d\n%d %f\n", f == i, ++f == ++i, i, f);
staci? vystup je:
1 1 16777217 16777216.000000
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.