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

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

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

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

Alik

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

Да.чот неоч

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

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

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

Тут лучше

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

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

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

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

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

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

Ты хочешь ORM)

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

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

Ты хочешь ORM)

Не хочу)

Почему?

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

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

Почему?

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

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

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

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

Ты любишь 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 в плюсы транслируемый)

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

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

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

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

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

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

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

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

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

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

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

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

так что лол да

https://github.com/wjakob/nanogui чето аж понравилось как выглядит, получше imgui

!! (nanoGUI) тут можно пилить гуй на питоне, и подключать его к плюсам? (на плюсах рендер основной)

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

Ты в итоге решил эту проблему?

какую?

а

Ты в итоге решил эту проблему?

Ну у меня метод для сериализации в данные, которые можно положить в бд в классе находиться

мне не нравится поэтому я и задал вопрос

но лучше не получил ответа

*решения

или не увидел прост

или не увидел прост

ты выбираиш между тем чтобы зделать клас примись с реализацией или отдельный клас умеющий сереализовать твой клас или ещё чота?

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

ты выбираиш между тем чтобы зделать клас примись с реализацией или отдельный клас умеющий сереализовать твой клас или ещё чота?

.

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

3 — прикольно, но лучше не стоит 4 — не гибко Балланс между 1 и 2 — зависит от того, как дальше продукт развиваться будет (ну или вообще заведи ISerializeStrategy, передавай его — больше ынтерпрайза богу скэлабл девелопмент)

ну вообще если выбирать 1 то имхо тру плюсовый вэй это перегрузка оператора <<

без всяких интерфейсов

имхо

Интерфейс стратегии тебе, чтоб потом в разные базы по-разному сериализовать без промежуточных состояний

Но это уже ЫГМ

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

мне нравится 2 и 3

Интерфейс стратегии тебе, чтоб потом в разные базы по-разному сериализовать без промежуточных состояний

ну вот я как-то это и имел в виду

Всем день добрый

Тут есть господа, пишущие научный софт на плюсах?

Тут есть господа, пишущие научный софт на плюсах?

А что?

Тут есть господа, пишущие научный софт на плюсах?

Есть.

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

хрен там

Нужно заняться плюсами для написания софта для квантовых расчётов, я в плюсах 0 и ищу что почитать, с чего начать

Ну, прочти Страуструпа про C++, для начала.

Хотя постой, какие языки уже знаешь?

Шарп

Нет

похожу на троллинг

какие нахрен плюсы

Тут как-то спрашивали про книгу in-depth серии, она вроде была на эту тему

Погодите.

там логика другая машинная

С++