открываем багтрекер https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=gcc%20c%2B%2B и печалимся (или радуемся в зависимости от религиозных воззрений)

Нужен баг, который не позволит собрать новый код с багфиксом.

Нужен баг, который не позволит собрать новый код с багфиксом.

рабочие места сохраняем?)

олимпиадников отправлять на разработку компиляторов!

ссылка на разрабтку компилятора в сибирь

ссылка на разрабтку компилятора в сибирь

интеллы разве не покинули просторы необъятной?

ничего не знаю

всем привет

здарова

Привет

Dwaine "Rock" Johnson уже гей? Ооо

Это прям так важно в плюсоконфе, да.

Лучше плюсов вбрось.

Пока кто-то находит один баг, другие находят тысячи)

EMI-based Compiler Testing http://web.cs.ucdavis.edu/~su/emi-project/

какие есть опенсорс проекты на плюсах где можно было поковырять и возможно покомиттить? мб кто-то работает над каким-то и он мог рассказать про него?

какие есть опенсорс проекты на плюсах где можно было поковырять и возможно покомиттить? мб кто-то работает над каким-то и он мог рассказать про него?

https://github.com/tiny-dnn/tiny-dnn/

какие есть опенсорс проекты на плюсах где можно было поковырять и возможно покомиттить? мб кто-то работает над каким-то и он мог рассказать про него?

https://github.com/boostorg/

спс посмотрю

Личкрафты советуют, как правило(

https://github.com/0xd34df00d/leechcraft

Какой клиент телеги?

https://github.com/boostorg/

а где issues?

Очевидно, тут https://svn.boost.org/trac/boost/report

https://github.com/tiny-dnn/tiny-dnn/

могу в личку поспрашивать?

ого)

могу в личку поспрашивать?

да

минст уже давно не показатель особенно 98%

лучше NNVM в mxnet пилить

минст уже давно не показатель особенно 98%

Точность от фреймворка не зависит)

Точность от фреймворка не зависит)

Ну и значение бесполезое

Ох да, баги с 2011го (( https://svn.boost.org/trac/boost/ticket/5563

Точность от фреймворка не зависит)

А так-то: фреймворки могут различные алгоритмические отличия иметь. Кто HFN на первых итерациях запустит, кто dropout вариационным сделает, кто по предобучению отличается

А так-то: фреймворки могут различные алгоритмические отличия иметь. Кто HFN на первых итерациях запустит, кто dropout вариационным сделает, кто по предобучению отличается

Ну обычно если какой-то алгоритм показывает значительно лучшие результаты, то все его впиливают. А если нет - то сравнивать на одном датасете бесполезно

На CPU?

Ну, там, где нет GPU.

Например, небольшой сервис для разбора капч.

Пообучали, работает, збс.

Для не шибко большого буизнеса самое норм решение.

Зачем GPU, если есть FPGA/ASIC😌

И чо?)

Меж тем баг в GCC https://akrzemi1.wordpress.com/2017/04/27/a-serious-bug-in-gcc/

говнище то еще кстати

Утечки памяти в валидных прогах.

Ну вон гугл инференс на ASIC делает

У нас лежит 3 или 4. Студенты страдали от багов)

Ваще харэ оффтопить, ну.

Зачем GPU, если есть FPGA/ASIC😌

чтобы быть королём ланпати)

а ты что в бусте делал？

есть наработки？

По поводу бага https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 А вот в clang нет такой шняги

круто. посмотрю. а.много задач？

поспрашиваю потом ченить)

но учитывая что я с бустом не работал надо хоть посмотреть что там)

Можешь в двух словах пример привести? Какого рода задача.

Полностью с нуля? Какие требования?

Есть два метода void id(uint64_t _val_) { this->id_ = _val_; } void id(uint64_t&& _val_) { this->id_ = _val_; } Компилятор ругается error: call of overloaded ‘id(int)’ is ambiguous obj.id(1); ^ Как ему явно дать понять, какой использовать?

проще с нуля))

Есть два метода void id(uint64_t _val_) { this->id_ = _val_; } void id(uint64_t&& _val_) { this->id_ = _val_; } Компилятор ругается error: call of overloaded ‘id(int)’ is ambiguous obj.id(1); ^ Как ему явно дать понять, какой использовать?

Или для примитивных типов это вообще не работает?

а чуть конкретнее все-таки требования можно?

Есть два метода void id(uint64_t _val_) { this->id_ = _val_; } void id(uint64_t&& _val_) { this->id_ = _val_; } Компилятор ругается error: call of overloaded ‘id(int)’ is ambiguous obj.id(1); ^ Как ему явно дать понять, какой использовать?

Кастовать, но зачем на примитивах мув?

Кастовать, но зачем на примитивах мув?

Это сгенеренный код (генератор поправить не могу). Кастовать во что?

std::move

ничеси задачка

Есть два метода void id(uint64_t _val_) { this->id_ = _val_; } void id(uint64_t&& _val_) { this->id_ = _val_; } Компилятор ругается error: call of overloaded ‘id(int)’ is ambiguous obj.id(1); ^ Как ему явно дать понять, какой использовать?

А если первый превратить в void id( const uint64_t& _val_ ) ?

А если первый превратить в void id( const uint64_t& _val_ ) ?

Не могу превратить, это генерированный не мной код

Ну тогда вызывай так

std::move(1) тоже не помог. сделал просто временную переменную (это один раз делается)

obj.id(1ull);

obj.id(1ull);

тоже самое

Блин, как оно так генерит не const T& то ( ._.)

тогда остался один способ, который точно сработает

uint64_t a = 1; id( a );

😂😂😂😂

uint64_t a = 1; id( a );

так и сделал

Ну говно, конечно, но раз код класса неприкосновенный, то страдай )

Блин, как оно так генерит не const T& то ( ._.)

const T& генерит только для сложных типов.

Если бы просто const добавляло, тогда всё должно было бы и без ссылки работать

Или нет, не знаю, лучше не слушать меня )

кстати, плюсовики. У меня вопрос. Допустим есть какой-то класс, который используется в бизнес-логики приложения и в какой-то момент допустим должен сохраняться в бд. Какой подход лучше? 1. Добавить этому классу метод для сериализации в конкретное представление нужное для конкретной бд 2. Добавить этому классу метод для сериализации в промежуточный тип данных 3. Отнаследоваться от этого класса, единственной задачей потомка будет сериализоваться в конкретную бд 4. Сделать сериализатор, который будет знать о внутреннем представлении класса(?) и сериализовать его ?