Mercury13

UPD. Теперь понял, о чём вы. В таком виде нельзя.

Скажем прямо: данная конструкция работает только если выходные дни в начале или конце недели. Если в середине — придётся расширять алгоритмы, да и труднолокализуема (языковые строки одновременно служат техническими ключами).

Заводим три переменных: firstDay, lastDay, workHours. Поначалу они пустые строки.
Проходимся по всем элементам.
• Если рабочие часы совпадают с workHours — перезаписываем lastDay, и всё.
• А если нет — проводим функцию dump, перезаписываем все три.
После цикла принудительно проводим dump.

Как должна работать функция dump.
• Если workHours пусто — ничего не делаем.
• Если результирующая строка непуста — добавляем разделитель.
• В зависимости от того, совпадают ли firstDay и lastDay, добавляем «Пн» или «Пн-Пт».
• Ну и, наконец, добавляем рабочие часы.

1. Любой поток данных реального времени (в том числе сетевое соединение) содержит буферы ввода-вывода, где данные передерживаются, пока принимающая сторона не будет готова их принять. В общем, при подсоединении выделить память, при отключении вернуть её.
2. Открытие соединения происходит в три этапа: «превед-медвед-готов». Есть такое понятие, как «полуоткрытое соединение»: на инициирующей стороне мы послали «превед», но не получили «медвед». На принимающей — послали «медвед», но не услышали «готов». Количество полуоткрытых соединений общее на всю систему и обычно велико, но тоже может исчерпаться.
3. Любая передача через сеть не мгновенна. Соединение с нашей стороны будет считаться открытым, когда в сеть ушло «готов», так что если пинг 100 мс — то вот спустя 100 мс соединение и будет открыто.
4. Процедура логина (ну и рукопожатие TLS, если таковой используется) задействует сильную криптографию, которая тоже медленна. А в TLS есть и своя тройка «превед-медвед-готов».
5. При закрытии соединения компьютер также пытается послать пакет «я закрываюсь».
6. Анти-DDoS’овские меры, наконец.

Кода нет даже игрушечного, и гарантированно не скажешь. Я вижу три возможных причины.
1. Либо не прописан конструктор копирования или операции присваивания (а с деструктором всё в порядке). Указатели продолжают обращаться к освобождённой памяти, и по какому-то счастливому совпадению первый элемент совпадает.
2. Либо конфликт имён: fn — параметр конструктора и fn — внутреннее поле.
3. У вас тут закомментированное srand(time(NULL));. Я не знаю, что в функции random_at_most, но если там srand — перенеси его в другое место. Процессор работает в миллион раз быстрее, чем таймер. «Хочешь, чтобы было случайнее», а будут повторы.

sz = strlen(szPath);
Ну чему, блин, равняется sz?

Return value

If the function succeeds, the return value is the length of the string that is copied to the buffer, in characters, not including the terminating null character. If the buffer is too small to hold the module name, the string is truncated to nSize characters including the terminating null character, the function returns nSize, and the function sets the last error to ERROR_INSUFFICIENT_BUFFER.

Вот оттуда надо брать длину. А не из strlen неинициализированной памяти.

И идеалом было бы заложиться на пути длиннее MAX_PATH.

Рейтинг: рассчитывается по своим формулам и никак не стандартизируешь.
Покупки: на это бэк-энд не нужен (хотя при желании можно тянуть информацию со своего сервера, а не с API покупок).
Так что бэк-энд будет небольшой, ибо 99% работы на клиенте, но будет.

Добавлю от себя.

Сейчас вирусы на ассемблере пишут редко, и этому есть две причины.
1. Сложная полезная вредная нагрузка: загрузка чего-то через Интернет, сетевые эксплойты, дистанционное управление.
2. Сложный формат PE, крайне редкий обмен софтом, цифровые подписи на критических файлах и UAC. Потому встраиваться в файлы тяжело и малопродуктивно. UPD — существует немало «вирусов-спутников», но цифровые подписи на критических файлах и UAC не пробить и им.

Эксплойту с внедрением кода нужно небольшое тело, и его пишут на ассемблере или Visual C. А если это обычный EXE/DLL — то на языке, для которого в ОС гарантированно есть runtime-среда. В основном Visual C и .NET старых версий.

Вирусы, эксплуатирующие ошибки в runtime-средах (JS-движках, Java, .NET) — разумеется, на языке среды (JS/Java/C#). Если ошибка предполагает внедрение кода — см. выше.

UPD2. Я не писал вируса, но как бы я его заставил работать?

Прошёлся бы по дискам. Создал бы скрытую папку с микрософтоподобным именем и потихонечку бы шифровал в неё файлы. Вдруг в момент Икс я переименовываю исходные файлы в ту самую папку, затираю пару килобайт начала, переименовываю скрытые на их место и вывожу: ваш компутер зашифрован! Если человек мешкает — затираю остатки файлов, а потом и удаляю их.

Остаётся придумать, как этот вирус протащить на компьютер жертвы и как прикинуться легитимной программой. Простейший вариант, по-моему — прикинуться сайтом программ, в каждую поместить вирус и сделать активное SEO. Что будет, когда попадусь — не знаю. А прикинуться программой — придумаю какую-нибудь службу-технотуфту от Microsoft. Хотя настоящие вирусописатели покупают на чёрном рынке эксплойты, я с этим делом не знаком.

Разобрать по цифрам и сделать.
Положительное число разбирают по цифрам так.

while (n != 0) {
  digit = n % 10;  // делай с этой цифрой что хочешь
  n /= 10;
}

Куда пустить цифры и как сделать поправки на нули и отрицательные — думай сам.

IpAddress & Mask = IpAddr
(при условии, что IP гарантированно настоящий и не надо узнавать, это настоящий адрес или один из сервисных, связанных с сетью)
Возможно — я не знаю, каких размеров таблица — БД держат в таком виде ради индексирования.

Задача, как ни странно, нетривиальна.
Какой возможен процент, чтобы округление дало 6,21? От 6,205 до 6,215%.
Минимальное число — 10319 * 6,205 / 100 = 640,29
Максимальное — 10319 * 6,215 / 100 = 641,32
Ответ однозначен, 641 человек.

Будь округление более грубым — например, 6,2% — тогда было бы от 635 до 644.

В Си можно — 0123 = 123₈. Но зачем оно тебе?
Обычно число в любой позиционной системе счисления — 10-й, 8-й, 16-й — записывается в строчку. И я говорю не «перевод из 10-й системы в 8-ю», а «перевод из родной системы в восьмеричную» — потому что не важно, какая система родная, главное, что мы в ней умеем выполнять арифметические операции.

Интерфейсы в Delphi отвечают за две малосвязанных вещи.
1. Множественное наследование. Об этом уже рассказали до меня, повторяться не буду.
2. Подсчёт ссылок (для этого реализатор должен корректно поддерживать _AddRef и _Release, но это уже другой вопрос, и подходящая реализация есть в TInterfacedObject).
Связано это с тем, что Delphi должен был поддерживать Microsoft COM, а там автоматическое управление через подсчёт ссылок.
Так что интерфейсы часто приплетают только потому, что удобно работать с подсчётом ссылок.

Вот, например, моя библиотека (обёртка cURL для Delphi) под названием curl4delphi: https://github.com/Mercury13/curl4delphi
На что тут ICurl? А на то, что это объект с подсчётом ссылок, и для него не надо вызывать деструктор. Пропадает последняя ссылка — объект исчезает. Вот и всё.
Из-за автодеструкторов, «киллер-фичи» Си++, я в Си++ так не поступал бы.

PHP изначально задумывался скриптовым языком — языком процедурного программирования с динамической типизацией и возможностью вписать пару строк, не оформляя тело. Таким он и остаётся поныне, с вкраплениями ОО. Немного функциональщины, конечно, есть, но это не делает PHP — как, впрочем, Java или C++ — настоящим функциональным языком.

Служба может работать, даже если ни один пользователь не прилогинен к системе. Или если прилогинены двое (например, один оставил комп с работающим клиентом, подлогинился второй). Потому придётся переделать архитектуру службы — например, передавать настройки при установке связи клиента со службой.

void Wid::test() {
    vector<string> stp;
    stp.push_back(text->toPlainText().toStdString());
    // В stp одна штука
    sort(stp.begin(),stp.end());
    // Ну что ей будет, этой штуке?
    stp.erase(unique(stp.begin(),stp.end()),stp.end());
    // unique даст end; поведение vector при этом не определено.
    ofstream filesave(pp);
    copy(stp.begin(),stp.end(), ostream_iterator<string>(filesave,"\n"));
}