Nightmare A, обычно нужно как-то особенно исхитриться, чтобы символы стандартной библиотеки stdc++ не нашлись. Тут на этапе компиляции был сгенерирован референс с именем, которого не нашлось в библиотеке.
Я с std::string никогда проблем не имел, но глядя на ответ ниже и немного подумав могу предположить, что где-то в коде может быть попытка проинициализировать строку не из string и даже не из char*, а из long. Это так не работает. Можноо было бы по-C-шному взять sprintf, но более провославно использовать ostream.
WSGlebKavash, это уж точно не решается перепиской какого-то школьного сисадмина на каком-то уютном сайтике в интернетах.
Никогда его туда не добавят, так как российский государственный УЦ никогда не докажет, что он независим от государства. Все УЦ в браузерах и операционных системах длительное время доказывали, что они надёжны, безопасны и не выпишут ни одного неправомерного сертификата никому, особенно товарищу майору.
Более того, любой УЦ, который попадается на нарушениях, тут же попадёт в список отзыва. И дальше огромный вопрос, примут ли его обратно.
Лет 5 назад кто-то из УЦ (забыл кто именно) попался на выдаче какому-то из клиентов сертификата с правом подписи других сертификатов. Поднялся большой скандал, и сертификат УЦ быстро был отозван, ему пришлось срочно доказывать, что меры приняты и больше такого не повторится, ну и новый корневой сертификат делать.
С российским УЦ - даже если их вдруг примут, после первой же оплошности их выкинут и вряд ли примут обратно. А даже если примут - то только с новым чистым незапятнанным сертификатом. Который опять выкинут при следующей же оплошности.
А зная наши власти, довольно очевидно, что они быстро создадут сертификат под сайт ютуба или Навального. Так что я категорически рекомендую НИКОГДА И НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ не использовать этот сертификат никогда и нигде. Это просто опасно.
Markus_Frilance, в Instagram можно принимать по API входящие direct-сообщения и отвечать на них. А спамить по своей иницитиве (когда пользователь не писал входящего к тебе) нельзя. Это обычное условие этого и некоторых других API (например, Viber Bot примерно такой же подход предлагает).
uRoot, для получения таких данных надо парсить кучу сайтов в интернетах, всё это анализировать и обрабатывать. Всё это требует огромных ресурсов и денег, поэтому неудивительно, что качественные решения часто продаются за приличные суммы.
aristosarseno, а теперь представь себе, сколько удовольствия получают те, кто читает этот вопрос с мобильника. Впрочем, с компа она тоже по вертикали дофига места занимает. И вообще, почитай правила сайта.
szQocks, если очень надо ходить в базу в докере, ничто не мешает опубликовать порт с базой в докер-контейнере так, чтобы с него можно было ходить с рабочего места. Например, через VPN к промышленному контуру. Доступы тоже можно ограничить по желанию как угодно.
Если просмотр только с приставкой и нет варианта смотреть с компа, то имеется ненулевой шанс, что видеопоток будет шифрованным (необязательно на всех каналах). Впрочем, и программа для компа может уметь шифровать трафик.
Вадим Алиев, я присоединяюсь к советам ставить нормальную систему под этот дистриб и уже в неё доставить (или даже скомпилировать) нужный софт. Кали сам по себе довольно экзотический, плюс экзотическая архитектура - эту гремучую смесь ты будешь разглючивать очень долго, особенно если мало опыта.
Можно делать специфических клиентов отдельными ветками и новые фичи мерджить в них явно либо прям переносом кода с отдельными коммитами (а то и в отдельной репе), но придётся регулярно воевать с конфликтами, и вообще это плохой путь. Но некоторые так делают, в том числе не только по историческим причинам, но и потому, что доработки под некоторых клиентов могут быть настолько объёмны, что тянут на отдельный проект, содержать который в рамках всеобщего универсального проекта может быть крайне сложно. Например, для моего работодателя разработчик в систему учёта заявок с нуля написал интеграцию с почтой под наших хотелки, основательно вкрученную в ядро всей системы.
Но в целом если хочется сделать хорошо, то лучше выделять ядро, а отдельный функционал выносить в включаемые фичи, в подключаемые модули, в кастомные хуки итд итп. Также в некоторых случаях может помочь создание переиспользуемых библиотек. Например, если есть несколько клиентов с различными почтовыми интеграциями, то вместо написания супермодуля по работе с почтой или нескольких огромных модулей сделать отдельную библиотеку, скрывающую сложные вопросы работы с почтой (приём, отправка, авторизация, SMTP/POP3/IMAP/TLS/etc, формирование писем, их парсинг итд, с ООП, конечно), а сами модули сделать лёгкими и компактными, использующими эту библиотеку.
Можно посмотреть как делают другие. Даже Битрикс (при всей обоснованной критике его громоздкости и технологической отсталости) написан так, что дополнительный функционал в нём делается не ковырянием в ядре, а модулями, компонентами, кастомными темами итд итп.
bfardaad, каждая синхронная операция с базой полностью блокирует бота. Делается запрос 30 секунд? Вот все эти 30 секунд бот вообще не будет реагировать.
Я с std::string никогда проблем не имел, но глядя на ответ ниже и немного подумав могу предположить, что где-то в коде может быть попытка проинициализировать строку не из string и даже не из char*, а из long. Это так не работает. Можноо было бы по-C-шному взять sprintf, но более провославно использовать ostream.