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

Реализация нечёткого поиска

Реализация нечёткого поиска

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

Есть два метода 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); ^ Как ему явно дать понять, какой использовать?

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

Если не с нуля, то молодцом будешь

Всякие agrep же есть

Всякие agrep же есть

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

You are welcome)))

Есть два метода 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); ^ Как ему явно дать понять, какой использовать?

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

You are welcome)))

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

Есть два метода 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

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

Подобие std::search, только нечёткий поиск. Какие именно требованя? это разработка с нуля - придумывай, что хочешь, лишь бы в буст это приняли

я эту тему только чуток копал - расстояния понаписывал всякие, которые пригодится могут потом. Я сильно занят поиском

Я могу дать задачу, и тебе хватит на пару месяцев минимум

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

Есть два метода 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. Сделать сериализатор, который будет знать о внутреннем представлении класса(?) и сериализовать его ?

сделать промежуточный слой (тот же REST) и не затрагивать аспекты диалекта в прикладном коде от слова ВООБЩЕ

Добавить к нему реализацию интерфейса DbSeriarizable

Добавить к нему реализацию интерфейса DbSeriarizable

т.е. класс будет уметь сам себя сериализовывать и мы притащим зависимость в виде конкретных классов, которые используются для формирования данных для бд?

Alik

т.е. класс будет уметь сам себя сериализовывать и мы притащим зависимость в виде конкретных классов, которые используются для формирования данных для бд?

Да.чот неоч

сделать промежуточный слой (тот же REST) и не затрагивать аспекты диалекта в прикладном коде от слова ВООБЩЕ

т.е. класс умеет сериализовать себя в промежуточный формат?

сделать промежуточный слой (тот же REST) и не затрагивать аспекты диалекта в прикладном коде от слова ВООБЩЕ

Тут лучше

т.е. класс умеет сериализовать себя в промежуточный формат?

ну, как вариант

а чем 4 вариант плох?

если сделать его friend

вообще никаких зависимостей

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

Ты хочешь ORM)

вообще никаких зависимостей

Фриенд костыль

Ты хочешь ORM)

Не хочу)

Почему?

Фриенд костыль

тогда без friend добавь метод для экспорта нужных данных

Почему?

Да просто ненужно както

В общем. Надо добавить реализациб интерфейса, как я предлагал, и этот метод будет предоставлять метод serialize с вхолным параметром-обёрткой над тем хранилищем, в которое ты хочешь что-то сохранить.

пока писал, вспомнил об этом: https://ru.m.wikipedia.org/wiki/Хранитель_(шаблон_проектирования)

ERROR: S client not available

Тут еще вакансии привалили

Ты любишь C++, пользуешься Linux, умеешь готовить git, тяготеешь к embedded разработке и хочешь разрабатывать продукт, которым пользуются миллионы людей? Нам нужны толковые девелоперы, для разработки midleware для ТВ-приставок крупнейшего спутникового оператора Восточной Европы. В твои обязанности будет входить: - Разработка и поддержка существующего ПО. - Интеграция ПО на новые аппаратные платформы. От тебя нам требуется: - Отличное знание С++ (желательно с опытом промышленного программирования). - Уменее пользоваться Linux и git. - Способность самостоятельно решать поставленные задачи. - Ответственность, коммуникабельность. - Креативность и инициативность так же поощряются. Мы предлагаем тебе: - Оформление согласно ТК РФ с соблюдением всех социальных норм. - Гибкий график работы. - Адекватную стабильную заработную плату с регулярно стимулирующими работу премиями. - Интересные задачи, в рамках крупного проекта. - Комфортные условия в офисе в бизнес-центре в паре минут от ст. м. Выборгская. - Повышение квалификации на профильных курсах, семинарах и пр. - Финансовая поддержка в значимых событиях, премии за стаж работы и другие корпоративные бонусы. - Заграничные командировки. Наш сайт: http://gs-labs.ru/ За подробностями в лс @kenny1847 #вакансия #cpp #embedded #linux #спб #Питер #gslabs

еее, щас бы вакансию без вилки

Обычно в такие вакансии фигачат в требования ffmpeg, live555, mpegts, tcp, udp и т.д. Даже как-то странно видеть вакансию на ПО для тв-приставок без этого списка.

не знаешь ты TS, ну и что тебе мешает быть хорошим инженером, не весь же скоуп задач на dvb висит

ну а если и надо - открыл стандарт и посмотрел, что он говорит

ну а если и надо - открыл стандарт и посмотрел, что он говорит

Так и делаю

никто наизусть стандартов не помнит

А зачем еще в приставках плюсы? Только сеть и медиа. В качестве интерфейса там браузер с API на js обычно.

А зачем еще в приставках плюсы? Только сеть и медиа. В качестве интерфейса там браузер с API на js обычно.

такой UI это медленно от слова пиздец же

собстна любой андроидный бокс, все эти коробки люто тормознутые, хотя железки там отличныые

В смарт тв та же срань.

у нас самописный qml в плюсы транслируемый)

А через что рисуется, если не секрет?

зависит от платформы, где-то софтверно, где-то аппаратный рендеринг

где-то directFB, где-то OpenGLES

я на самом деле особо этим делом не интересовался)

я на самом деле особо этим делом не интересовался)

если люди написали и оно работает, зачем лезть в это)) Правильно

ну у каждого своя кухня, проект большой, оно работает)

https://www.youtube.com/watch?v=hjdOJqXbagI&feature=youtu.be

А зачем еще в приставках плюсы? Только сеть и медиа. В качестве интерфейса там браузер с API на js обычно.

ну там у них на сайте вакансия: Team Lead/ Ведущий JavaScript программист Проект: участие в разработке интерфейса для цифровой приставки нового поколения. Отличительной особенностью которой является возможность выхода в интернет и принципиально новая программная платформа.

так что лол да