megorit

Предполагается, что proga.exe находится по пути на диске C, если ваша папка Folder находится по другому пути, измените путь до папки Folder.

#include <cstdlib>

int main() {

	std::system("start C:\\Folder\\proga.exe");

	return 0;
}

stackoverflow(EN) - How to execute another exe from a C++ program in W...

что такое звук

Начало здесь.

картинка это набор пикселей расположенных по координатам и состоящих из RGB (255,255,255 это белый )

1 секунда двухканального звука оцифрованного на 48000 Гц с 16-битной точностью это, например, 48000 пар знаковых 16-битных целых чисел. Если все эти числа равны, то это одна секунда тишины. А если первое число в i-й паре равно 32767 * sin(440 * 2 * Pi * i / 48000), а второе -- 0, то это одна секунда ноты ля первой октавы в левом канале.

Превратить звуковую дорожку в график , научиться работать со звуком , чистить его

Продолжать поиски здесь.

Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.

Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницами а PHP просто расширяет возможности и того и другого.

GET запрос используется чтобы получить данные а POST чтобы отправить. (Напоминаю что технически они работают одинаково).

Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами GET запроса они представлены в формате 'ключ'='значение' и в качестве разделителя используется знак амперсанда (&)
Пример:
GET /index.php?name=Андрей&surname=Галкин
это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
3. $_POST заполняется другим способом. содержимое этого массива заполняется из "заголовков запроса". То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.

Чаще всего пост запрос используется в формах (для отправки данных).

Например у нас есть форма для входа 2 поля логин и пароль.

Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.

А вот если бы мы указали методом POST то мы бы получили следующий запрос:
POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.

Теперь другая ситуация например форма поиска. Мы вводим текст и получаем страницу с результатами. Вот тут уместнее GET форма. потому что нам было бы удобно сразу иметь ссылку на результат поиска, то есть добавить в строку запроса можно выразится "Публичные параметры", которыми можно поделиться. И как результат в строке браузера будет конкретная ссылка на текущую страницу. Мы можем ее скопировать, и разместить где-нибудь, или например скинуть другу. И получить при переходе одну и ту же страницу. А не просить других людей зайти на сайт и в поиск вбить определенную фразу чтобы получить необходимую страницу.

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

И еще одна хорошая новость их можно комбинировать, например
POST /index.php?page=login (login=Андрей&password=123) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.

Во первых:
RDP != VNC, TeamViewer - так как RDP работает в отдельной сессии.
На одном сервере может быть несколько подключений под RDP, они не видят экранов друг друга, их клавишы/мышь передаются независимо, у каждого в свою сессию.

Во вторых:

http передавать, например команды, нажатые клавиши и т.д. через JSON, картинки типа рабочий стол в png/jpg. Зачем для этого использовать отдельный протокол?

http - протокол нижнего уровня.
Если вы поверх него каким то образом собираетесь передавать клавишы и пр. - вам нужно будет придумать поверх http свой протокол

В третьих:
http текстовый протокол, не бинарный. Он довольно много передает лишней информации.
Для того чтобы обеспечить комфортную работу через сеть, чтобы нажал кнопку и увидел отзыв - лишние звенья в передаче данных ни к чему.

В четвертых:
http не очень хорош как протокол оперативного двустороннего обмена (что и вызвало появление WebSocket).

В пятых:

Team Viewer - http

Это не так

В шестых:

Зачем они используют разные протоколы?

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

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

А вообще:

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

Бэкенд - Python. Это нормально. Универсальный вариант отдаёт по запросу данные и не парится с тем, как они буду визуализированы. REST, GraphQL, SOAP и т.д.

Фронтэнд, работая на стороне клиента, визуализирует получаемые данные для пользователя. Тут возможна как нативная отрисовка, так и опосредованная (к примеру через браузер).
Фронтэнд пишется отдельно от бэка. Инструмент - любой подходящий.
Для отрисовки через браузер (вот, сайт Тостера, к примеру) надо написать клиента на HTML/CSS/JS. Он будет загружаться в браузер и рисовать его средствами.
Для нативной отрисовки - любая соответствующая системе либа. Хоть MFC в Винде (хотя это уже некромансия - сейчас .NET-библиотеки в фаворе), хоть Carbon (или что там сейчас на Маке?).
Из линуковых нативных (они же - кроссплатформенные) подойдут GTK, Qt, FLTK и разные надстройки над ними. WxWidget тот же...
Это я ещё не трогаю тему мобильных устройств...

Поэтому если не хочется учить разные языки, а ограничиться Python, то фронт на нём МОЖНО писать. Есть биндинги к GTK и Qt. Есть WxPython. Для мобилок можно погрузиться в дивный и чудный мир Kivy (хотя это, скорее, кроссплатформенное решение - работать будет и на десктопах). BeeWare тоже интересно развивается.

Но если подразумевается написание именно web-клиента, то изучение JS займет меньше времени, чем бесплодные попытки использовать неподходящий инструмент.

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

В случае с трассировкой лучей, за логарифм нет реализации вообще - ибо у невыпуклого многоугольника может быть O(n) пересечений с лучем (представьте себе пилу).

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

За логарифм есть решение через бинарный поиск.
Разбейте пространство на вертикальные колонны всеми x координатами всех вершин многоугольника. Внутри каждой из них будет проходить четное количество сторон. Составьте для каждой стороны уравнение и отсортируйте их по высоте.

При запросе, сначала бинпоиском найдите, в какой колонне лежит точка. Потом еще одним бинпоиском найдите, между какими из двух прямых лежит точка. Тут сравнения будут уже непросто чисел, а надо будет подставлять точку в уравнения прямых и смотреть, лежит ли точка выше или ниже. Если точка лежит так, что выше ее (и ниже) нечетное количество прямых - то точка внутри.

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

Может этот совет будет лишним, но на мой взгляд:

с учетом "… всегда крутился в айти, ...........": тогда с логикой по идее должно быть все в порядке.
(математика построена на логике и памяти, пусть не точно, но понимать принципы — обязательно )

1. Берем обычные школьные учебники, читаем, разбираемся, записываем проблемные места
2. Это касается всех старших классов
3. По проблемным местам проходим с помощью знающих товарищей ( или репититоров как писали ранее)
4. Возвращаемся к п. 1.
5. Если не помогло — меняем п. 3 и идем на него…
6. Если опять плохо — тут сказать сложно ( то-ли п. 3 плохой, то-ли не стоит связываться.
Тут вам решать…

А в принципе, школьная математика для «всегда крутился в айти» не может в нормальных условиях создать проблем. Больше уверенности в себе, больше настойчивости.

В результате вы добьетесь своей цели.

PS:

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

Вышка это не значит ВСЕ ЗНАТЬ — это умение работать с литературой (и важно: знать что это возможно технически).

Я понимаю что вопрос стоит по «поступить\сдать», но простите за банальность… вопрос цели…

Ошибка не там где вы указали, а в теге tls-crypt.
Какая версия openvpn на клиенте? tls-crypt появился только в версии 2.4
Используйте tls-auth.

Строковый литерал " ab " находится в особом сегменте данных, который (если процессор и ОС позволяют) только для чтения. А память сегмента данных освободить и сделать «кучей» нельзя.

Если предположить, что текст " ab " находится в «куче» — эта самая куча является сложной структурой данных и память выделяется с выравниванием. Потому функция realloc может (но не обязана) отдать конец или приделать память к концу. Отдать начало будет сложнее, и ни одна известная мне библиотека функций на это не способна.

Кроме того, Си++ придумал объект string_view именно для этого — чтобы передавать строки в функцию, абстрагируясь от выделения памяти и даже от оконечного нуля. Потому у string_view нет функции c_str().

Разумеется, вы можете сделать что-то вроде

char* str2 = str + 2;
str2[2] = '\0';
// А str оставь, уничтожать как-то придётся

Разумеется, если str находится в куче. Сегмент с литералами, напоминаю, только для чтения, и в ОС вроде DOS, где менять можно, такая замена может вызвать нехорошие побочки.

Компьютер - свойства - защита системы - восстановить.
Откатывает на любую из сохраненных точек восстановления.
По умолчанию точки создаются только при некоторых системных событиях вроде установки программ и обновлений. Можно вручную делать, или в планировщик задачу добавлять.
На пользовательские данные не влияет.

Все по классике:
1) 3 нормальная форма
2) join

добавьте пробел после [