- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
#include <inttypes.h>
auto a(auto b) __attribute__ ((noinline));
auto a(auto b)
{
return b*1.5;
}
double test1(double in)
{
return a(in);
}
uint64_t test2(uint64_t in)
{
return a(in);
}
/*
https://godbolt.org/z/6ZQAnv
auto a<double>(double):
mulsd xmm0, QWORD PTR .LC0[rip]
ret
test1(double):
jmp auto a<double>(double)
auto a<unsigned long>(unsigned long):
test rdi, rdi
js .L5
pxor xmm0, xmm0
cvtsi2sd xmm0, rdi
mulsd xmm0, QWORD PTR .LC0[rip] # хули ты мне плавучего питуха в xmm0 возвращаешь?
ret
.L5:
mov rax, rdi
and edi, 1
pxor xmm0, xmm0
shr rax
or rax, rdi
cvtsi2sd xmm0, rax
addsd xmm0, xmm0
mulsd xmm0, QWORD PTR .LC0[rip]
ret
test2(unsigned long):
sub rsp, 8
call auto a<unsigned long>(unsigned long)
movsd xmm1, QWORD PTR .LC1[rip]
comisd xmm0, xmm1
jnb .L8
cvttsd2si rax, xmm0 # ну нахуй тут надо double в uint64_t конвертить
add rsp, 8 # почему это не делается в auto a<unsigned long>(unsigned long)
ret
.L8:
subsd xmm0, xmm1
add rsp, 8
cvttsd2si rax, xmm0
btc rax, 63
ret
.LC0:
.long 0
.long 1073217536
.LC1:
.long 0
.long 1138753536
*/
Follow us!
Тут по идее нужно конструировать крестошаблоны.
Или это говно относится только к принимаемым аргументам? Почему оно не подстраивает это auto по то, куда присваивается результат вызова функции?
1) auto b подстраивается под тип принимаемого аргумента. Если b типа int, то создаётся auto a(int b); если b типа double, то создаётся auto a(double b).
2) b*1.5 подстраивается под тип выражения. Произведение произвольного числа на double (а 1.5 по умолчанию double) скорее всего будет double. Если нужен целый результат, то нужно писать b*3/2 или вызывать функцию округления.
Теперь всё логично.
Кстати, b*3/2 может быть целым? В Паскале, в Бейсике и в Питоне для целочисленного деления отдельный оператор (соответственно div, \ и //), а в сишке нет.
И ещё в каких-нибудь случаях результат может быть float или long double?
Правда, только для 5.3 и 5.4. Для других версий, вероятно, расширение operator придётся портировать.
бойсовые плавучие питухи
Лол в tcc unsigned float, unsigned double и unsigned long double собираются без ошибки.
типа вот 984798.0f + 73087 + 1998726.0 + 20836LL будет считаться как (((984734598.0f + 73087) + 1998726.0) + 20836LL) или как (984734598.0f + 73087) + (1998726.0 + 20836LL) или может быть как-нибудь так (73087 + 20836LL) + (984734598.0f + 1998726.0) ?
N4659, §4.6, 8
То есть выражение будет считать так, чтобы результат был полностью эквивалентен «(((984734598.0f + 73087) + 1998726.0) + 20836LL)».
Именно.
> куда присваивается результат
Потому что крестоблядская типизация никогда так не умела. auto на возвращаемом типе тупо берёт тип от выражения, которое ты написал в return.
Но не всегда вмещает их сумму...
Тупо (petooh + koorochka + tseeplyonok)/3 может вызвать переполнение и результат окажется по модулю кококококого-нибудь числа.
Так что язык Ада умеет «выводить» и наоборот, но в нём, в отличие от крестов, нельзя смешивать разные типы.
Но это слишком сложная и неочевидная оптимизация, да и к тому же плавучий питух может иначе посчитать
З.Ы. А, блин, дабл нельзя двигать :(
auto mul1_5(auto a) { return a + a/2; }