Alexander "SonnySlave"
Было
ссылку в меня кинешь?
Alexander "SonnySlave"
я только одно нашёл, но оно почему-то мертво
🦥Alex Fails
Alexander "SonnySlave"
кинь линк
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3965.html
🦥Alex Fails
Спс
Berkus
всем похуй конечно, юникод и юникод, но сопровождаемость страдала
🦥Alex Fails
🐙 Antony
Там уже Саша перехватил инициативу... скооперируйтесь, если что - я помогу
🦥Alex Fails
Как там его пингануть..
Alexander "SonnySlave"
меня? 😊
🐙 Antony
Его
Whadislove
Хай ребята
Есть кто посоветует литературу по алгоритмам чтоли?
Whadislove
Ибо беда с ними(
Anonymous
Anonymous
Anonymous
Whadislove
Пасибо
Roman
Кто-нибудь в 17х плюсах понимает? Вот наткнулся на такое: https://stackoverflow.com/questions/48594693/auto-template-parameters-g-7-3-vs-clang-6-0-which-compiler-is-correct
Roman
foo<1u> и foo<1> это разные типы или один и тот же
Roman
Причём оба компилятора в дебаг информацию пишут foo<1> в обоих случаях
Berkus
ну 1u это unsigned int 1, а 1 это int
Berkus
- от unsigned это вроде бы UB, так что оба правы по идее
Roman
ну там ключевое decltype
Berkus
но то что в гцц вдруг обычный инт оказался unsigned это косяк гцц
Roman
Я тоже так думаю
Roman
Но как я понмаю поймать такое можно было только в С++17
Roman
Но оба компиляора генерят одинаковый тип для обоих переменных в debug info
Roman
Поэтому если например тип полиморфный, то GDB неправильно его определяет
Berkus
Roman
Roman
Они всегда были, в 98 уже
Roman
но нельзя специализнуть шаблон типом non-type template параметра
Roman
Afaik
Roman
Или можно?
Berkus
Berkus
Roman
Или можно?
А нет, можно ;) Все-таки нельзя: ambiguous partial specializations
Berkus
Berkus
Восьмой гцц например выдает
-10 4294967286
Berkus
так что эта бага уже поправлена
Roman
Ох.. восьмой gcc )
Roman
Последний же 7.3?
Berkus
ну HEAD revision
Berkus
то что БУДЕТ зарелизено следующим короч
Roman
Написал бы ответ на stackoverlow, я бы его заасептил
Berkus
ну я в коммент засунул, давай ответом сделаю
Berkus
Roman
Меня в данный момент больше беспокоит эта https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932
Roman
Там в комментариях они как бы пришли к выводу что это проблема GDB
Roman
Но теперь очевидно что это проблема GCC
Roman
Надо проверить debuginfo из gcc 8, может тоже исправили
Berkus
ну похоже все таки в гцц это беда, попробуй собрать дебагинфу последним гцц из HEAD
Berkus
потому что я практически на 146% уверен что DWARF формат не менялся ради этого изменения в гцц
Berkus
это их генерация дебаг инфо страдает
Berkus
лишний гвоздь в пользу шланга
Roman
clang генерит то же самое в дебагинфо
Roman
сейчас напишу пример
Berkus
Berkus
давай пример, поковыряем
Roman
#include <iostream>
struct base {
virtual void print() = 0;
};
template< auto IVAL>
struct foo : base {
decltype(IVAL) x = -IVAL;
void print() override {std::cout << x << std::endl; }
};
int main()
{
base * fu = new foo<10u>();
base * fi = new foo<10>();
fu->print();
fi->print();
return 0;
}
Roman
поставь брейкпойнт на return 0
Roman
и посмотри значения fu и fi в отладчике
Roman
лучше поменять местами
base * fi = new foo<10>();
base * fu = new foo<10u>();
Roman
в общем собираю gcc из транка )
Berkus
(lldb) p fi
(foo<10> *) $0 = 0x0000000100300080
(lldb) p fu
(base *) $1 = 0x00000001003000b0
(lldb) p *fi
(base) $2 = {}
(lldb) p *fu
(base) $3 = {}
Roman
чем собирал?
Berkus
чем собирал?
λ g++ —version
Configured with: —prefix=/Applications/Xcode.app/Contents/Developer/usr —with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/c++/4.2.1
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Roman
Clang 6:
(gdb) p *fi
$2 = (foo<10>) {<base> = {_vptr$base = 0x400d38 <vtable for foo<10>+16>}, x = 4294967286}
(gdb) p *fu
warning: RTTI symbol not found for class 'foo<10u>'
$3 = warning: RTTI symbol not found for class 'foo<10u>'
warning: RTTI symbol not found for class 'foo<10u>'
{_vptr$base = 0x400db0 <vtable for foo<10u>+16>}
Berkus
это получается по версии clang 5.0 +- патчи
Roman
Ладно, мне спать пора
Berkus
Roman
Напишу в мэйллит кланга
Roman
свежий gcc завтра попробую