rPman

В общем случае это сделать невозможно, точно помню с помощью directx (наверняка и opengl/vulkan) можно получить прямой доступ к содержимому экрана или буферам видеокарты.

На stackexchange посоветовали повеситься на события и анализировать память, буквально всю, в т.ч. на наличие хеадеров jpeg/png/....

Т.е.запрет возможен только административными способами.

Одно слово (абривиатура) - VNC.
Это стандарт, одноименное приложение и библиотеки программирования, специально для таких задач, начиная с отправки на удаленный хост скриншотов и заканчивая удаленным управлением.

Для браузера - https://developer.mozilla.org/ru/docs/Web/API/Scre...

Собираете данные обучающей выборки (сотню другую чихов, кашлей, хлопков в ладоши и просто фоновых звуков). Затем, с помощью готовых алгоритмов получаете спектр звука на интервале (2-3 длины типового чиха), и натравливаете на это дело нейронку.

У вас только два варианта - либо кодируйте цветом High Capacity Color Barcode что даст вам примерно пятикратную оптимизацию по площади, либо размещайте код ссылку вместо самого кода, но это не так интересно, само собой.

Не вздумайте сделать глупость и нанести настоящее тату под кожу, те, рисуйте тату сверху с помощью переводных наклеек (точно знаю есть возможность печатать такие на принтере). Интересно и весело вам сейчас и максимум ближайшие несколько лет, а испорченная кожа - это на всю жизнь, так что допускаются только смываемые варианты.

Проблема больше не когда исключение бросать, а когда ловить! В конкретно вашем примере вы должны будете поймать исключение, завершить операцию работы с файлами и продолжить выполнение.

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

Если нет необходимости запускать свои приложения на сервере без интерфейса, т.е. например можно чтобы у вас был открыт браузер, то можно с помощью расширений браузера (или просто инжектить свой скрипт через консоль скрипт, если веб-приложение single page application) то вам хватит приложения на javascript, простого как валеннок.

Например чтобы заполнить поле ввода текстом надо написать что то типа $('css selector контрола').value='блаблабла', кнопку нажать $('...').click( и т.п.)

Достоинство подхода - сервер почти никак не сможет отличить ваше приложение от пользователя (только статистику и поведенческий анализ, та еще задача), и зачастую, небольшие изменения в коде на сервере требуют минимальных исправлений в ваших скриптах автоматизации или даже без, по сравнению с curl подходом (который требует полностью повторять запросы веб страницы к серверу, это обычно сложнее).

Недостаток - веб-браузер требует больше ресурсов для работы (даже headless) на столько что например сотню ботов на одной машине можно уже не потянуть.

Для начала, примите как данность, в linux бинарник - не приложение, приложение - это запись в пакетном менеджере, с настроенными зависимостями.

Вам необходимо кропотливо записать в зависимостях все необходимые библиотеки, скомпилировать с помощью кросскомпиляции, приложение под сразу несколько популярных платформ (i686/x86_64/может быть несколько arm), собрать deb/rpm пакеты, как минимум для нескольких популярных версий операционки (+для эстетов - ebuild) и вот только тогда считать что вы перенесли приложение на другой комп, иначе это геморой конечным пользователям.
p.s. вы как разработчик сможете это сделать без особых проблем, так как ЗНАЕТЕ из чего ваше приложение состоит и чем пользуется.
и да, тестировать все это на собранном минимальном debootstrap образе системы

На текущий момент в России университет имеет смысл не как источник диплома (бумаги, да на ее наличие смотрят, некоторые даже читают первые три слова специальности, чаще смотрят на факультет, если рекрутер сам учился там же) а как место, где есть возможность! научиться учиться.

Выбирайте там, где больше красивых девушек/парней, на свой вкус (если серьезно, посмотрите на количество студентов разных полов в старших курсах), от этого вы можете получить больше чем от выбора специализации. Вам жить в такой компании 5 лет минимум (я знаю студентов, которые парашутируют платно на одном курсе десятилетиями, только чтобы иметь выбор и дальше, но мне кажется там очень запущенный случай)

Не важно что читают вам на лекции, в конечном счете важно чем вы будете заниматься в это же время (понятно, это удобно, если лекции будут совпадать по специальности или даже направлениям с вашей деятельностью), для себя или даже работу найдете. Именно самостоятельно собранные знания могут быть ценнее тех что вам вдалбливали в университете. И да, теоретический фундамент, готовый и на блюдечке на лекциях просто психологически может быть проще воспринимать, чем самостоятельно, когда столько красивых девушек/парней вокруг. А ближе к окончанию у вас может появиться возможность консультироваться с преподавателями на свою тему, поверьте это очень удобно, когда ваше (хобби или работа) занятие совпадает с курсовой/дипломной, это на порядок лучше скучной копипасты (даже если она из методички/книги преподавателя/руководителя).

p.s. первое

У вас проблема не с большими числами, bigint их решит, а большой объем данных, миллионы и миллиарды записей положат вашу базу и создадут охренительные проблемы в будущем
Поэтому сразу закладывайте партиционирование таблиц по интервалам времени, причем не обязательно средствами базы данных, достаточно самим создавать новую таблицу для каждого следующего временного интервала (недели, месяцы - зависит от вашей нагрузки).

почему вы хотите хранить простые линейные логи в БД?
что еще вам нужно делать с данными кроме фильтрации и суммы?

если всетаки храните в базе, то не создавайте индексов на такие поля как объем трафика и url, это наиглупейшая ошибка, во время записи в таблицу заранее считайте необходимые параметры, выделяйте важные данные из url, вычисляйте домен, ip (сегодня он один, завтра другой), собирайте суммы по трафику в отдельной табличке, если нагрузка позволяет, можете по ip считать (или по зонам), в итоге вы будете работать не с сырыми данными, а уже агрегированными и посчитанными, их на порядок меньше и они удобнее для использования.

Для начала вопрос зачем в язык ввели понятие массив, а не остались с указателями - потому что типизация это добро. Т.е. на этапе компиляции можно будет понять, првильные ли переменные были переданы в функцию/метод, а так же можно узнать какой именно метод нужно использовать (методы с одинаковыми именами и разными типами параметров, плюс сюда в копилку темплейты С++)

Соответственно чтобы не передавать весь массив в качестве копии в методы, завели понятие ссылка (она не только к массивам определена, но и к любым объектам)

Практика показала, что в конечном счете сложные и универсальные property/value решения все равно разовьются до кеширования значений в полях рядом (совершенно нормально будет тригерами наполнять полупустые кеш-таблицы с 100500 полей).

Т.е. для скорости вы все равно создадите эти поля (иначе реляционные базы ну оооооооооооочень медленные), но наличие property/value подхода развязывает руки и дает больше возможностей в будущем.

Такое было бы возможно, если бы алгоритм хеширования не был криптостойким (это значит при изменении хотя бы одного бита в исходных данных меняется случайное число битов в хеше, независимо от того, какие именно данные были изменены). Т.е. при разработке криптостойкого алгоритма специально разрабатывают алгоритм, который невозможно вот так 'оптимизировать'.

Вычисления OpenCL бывают разными, одни могут совсем не затрагивать видеопамять (майнинг sha256) — такие почти совсем не будут влиять на работу компьютерных игр, особенно если эти игры не по максимуму используют шейдерные процессоры для разных спецэффектов.

А вот вычисления, требующие доступ к оперативной памяти видеокарты (майнинг scrypt) будут нагружать ее по полной.

Я не знаю, пробовали ли вы этот вариант, основанный на утверждениях:
1. полностью вся карта игрового мира изменяется не сильно
2. обычно карту можно попытаться поделить на зоны или в тупом варианте ячейки (или точнее варианты перемещения между ними), которые так же меняются очень редко и не сильно
Простейший пример: пусть зоны — просто квадратные ячейки внутри простой сетки, размер ячейки сравним со средним размером препятствия на карте.
Более сложный пример: многоугольная область поделена на зоны по границам больших препятствий, и перпендикулярно пересекающие типичные пути движения юнитов (грубо говоря магистрали их движения), такую статистику в процессе игры собрать не сложно, сложнее выбрать размер зоны, как враиант — фиксировать количество таких зон от среднего количества юнитов в игре…
Тогда из соседних ячеек пути перемещения обычно либо в обход через соседние ячейки либо через соединяющую грань между этими двумя.
Размеры ячеек должны быть подобраны таковыми, чтобы вмещать некоторое (не сильно большое) количество препятствий… десятки или сотни.

Заранее просчитываем (и постепенно обновляем по мере изменения мира, это не обязательно делать в реальном времени, хотя тогда будут возможны забавные артефакты в движениях) возможные пути перемещения между такими зонами (каждая грань — список пересекаемых зон возможными путями), а в момент, когда необходим точный путь, просчитываем его только в пределах этих ячеек, добавив в алгоритм поиск точки на грани между ячейками, ближайшей к пути (та еще задачка).

Весь путь считать не актуально, достаточно рассчитывать в пределах 1-2 ячеек вперед (по уже известным вам алгоритмам) и получать ответ, есть ли вообще возможность попасть к цели. Добавить к алгоритму пересчет пути в зависимости от игровых объектов актуальных для расчета коллизий (тут проблема — возможны ли заторы).

Такие ячейки — это аналог памяти юнитов о том, как можно было бы примерно пройти в соответствующую зону.
Добавит даже больше реализма, например поведение при заторах, юнит как бы еще не видит что путь впереди закрыт, но послушно топает, пока не попадет в ячейку с этим затором… тогда возникнет событие что путь достигнуть нельзя… так как меду ячейками вариантов перемещения всегда несколько, это создает не один путь перемещения по ячейкам несколько, соответственно временно помечаем что путь закрыт и выбираем следующий.

Не надо мучиться, напишите на моно простейшее консольное приложение использующее штатный контрол WebBrowser (при запуске под mono используется firefox), и пишите всю логику на javascript, запуская тут же на этой же странице на onload (точнее его аналог события на контроле).
Оно действительно получается очень простым, вся логика влезает в javascript с использованием jquery (его можно грузить в отличный от '$' идентификатор). И при этом запускается такое приложение на любом самом дешевом vps linux.

Я думаю между этим приложением и своим на php обмен сообщениями осилите c простейшими push ajax запросами или даже websocket?

Выбор между с++ и java (добавьте сюда .net c# ) это больше не выбор между языками программирования и синтаксическим сахаром, а выбор между фреймворками (библиотеками) которые идут вместе (или для) с этим языком как 'стандарт по умолчанию'.
Тем более эти языки на столько похожи, они вышли то и одного лона 'старого c++'!

А это значит выбирайте то что вам нравится, но будьте готовы просто выучить еще один фреймворк (и чуть чуть языковых конструкций), ведь программист, не готовый изучать что то новое… слабовато выглядит и заранее обречен на провал.

В winXP я спокойно запускал приложение, сохранив его exe в атрибутах к текстовому файлу, запускается даже из командных bat файлов.
a.txt:b.exe

p.s. Сейчас проверил в win7x64, не получилось вообще прочитать любой поток (хотя данные пишутся и разные утилиты показывают его наличие).

Очень осторожно пишите программы, работа которых может зависеть от установленной локали, встречал людей, которые меняют параметры локали в windows очень причудливым образом.
Везде, где возможна подобная неоднозначность принудительно прописывать параметры локали (как в windows так и в linux).

В данном конкретном случае лучше постараться избежать сохранение и использование текстового представления таких неоднозначных вещей как вещественные числа и даты… первый же запрос в гугл на вашу задачу — сериализация вещественного числа в целочисленном представлении: stackoverflow.com/questions/4733147/portability-of-binary-serialization-of-double-float-type-in-c