Mercury13

Можно, только синхронно. Используй TThread.Synchronize. Код пишется с листа, не уверен, что действующий.

procedure TMyThread.SyncCreateMemo;
begin
 Memo:=TMemo.Create(Form6);
  Memo.Parent:=Form6;
  Memo.Left:=50;
  Memo.Top:=50;
  Memo.Width:=250;
  Memo.Height:=100;
  Memo.Text:='Мама я родился!';
end;

procedure TMyThread.Execute;
begin
  Synchronize(SyncCreateMemo);
end;

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

procedure TForm6.WmCreateMemo; // message WM_CREATEMEMO = WM_USER + 1
begin
 Memo:=TMemo.Create(Form6);
  Memo.Parent:=Self;
  Memo.Left:=50;
  Memo.Top:=50;
  Memo.Width:=250;
  Memo.Height:=100;
  Memo.Text:='Мама я родился!';
end;

procedure TMyThread.Execute;
begin
  PostMessage(Form6.Handle, WM_CREATEMEMO, 0, 0);
end;

Заполнять наш редактор тоже можно путём PostMessage, но тут тоже будьте осторожны: сообщения-то выполнятся по порядку, но никто не знает, до окончания потока или нет. Бывает и такое, что два сообщения ушли в очередь, но ещё не обработались. В общем, будьте предельно осторожны с временем жизни объекта.

1. Разобраться, в какой кодировке работает сервер (обычно UTF-8).
2. Для путей — провести преобразование (Utf8Encode вроде). Не забудь, что Delphi 7 «из коробки» неюникодная.
3. Для доменных имён — закодировать в PunyCode. Это уже сам как-то — думаю, есть библиотеки, но точно не в коробке.

docs.oracle.com/javase/6/docs/api/java/awt/Desktop.html

Как работает, не проверял.

ДЛЯ ВВОДА-ВЫВОДА: Он читает информацию большими кусками и хранит эти куски в памяти.
Служит для ускорения доступа, если на самом-самом высоком уровне файл надо читать по одному байту или символу, а на самом-самом низком (например, жёсткий диск) эффективнее это делать блоками по 4K.

У читателей flush (если таковой есть; у BufferedReader, например, его нет) служит для потоков реального времени: клавиатуры, коммуникационных портов и прочего. Всё, что накопилось в буфере, сбрасывается, и считается, что на момент T поток пуст.

Писатели, естественно, пишут данные не сразу, а когда буфер заполнится, и авария программы или перебой электричества эти данные похѣритъ. Для них команда flush физически записывает накопленные данные.

ДЛЯ КАРТИНОК: Картинка хранится не в «аппаратно-эффективном» виде, а в таком, чтобы пользователь мог её относительно просто менять.

Если для боя с боссом нужно 0 очков — выводим 0.
Если все миссии в сумме дают <K очков — выводим «Нельзя».
А если нет — ничего пока не вижу, кроме продвинутого перебора.

Сортируем миссии по соотношению «очки/время». Главное — правильно отсечь перебор: например, каждый раз линейно экстраполируем по соотношению «очки/время» лучшей доступной миссии: удастся вписаться или нет? Смотрим на сумму «хвоста»: можно ли вообще, просуммировав «хвост», получить K?

int N, K;
Mission missions[100];
int bestTime = std::numeric_limits<int>::max();

bool recurse(int firstMission, int currPoints, int currTime)
{
    if (currTime >= bestTime)
        return false;
    if (currPoints >= K) {
        bestTime = currTime;
        return false;
    }
    if (firstMission >= N)
        return true;

    int remPoints = K - currPoints;

    for (int i = firstMission; i <= N; ++i) {
        bool isFirst = (i == firstMission);
        const Mission& im = missions[i];
        if (currPoints + im.tailPoints < K)           // tailPoints = сумма очков по хвосту от missions[i] до конца
            return isFirst;
        float wantedTime = currTime + remPoints * im.ratio;    // ratio = (float)m.time / m.points;
        if (wantedTime >= bestTime)
            return isFirst;
        if (recurse(i + 1, currPoints + im.points, currTime + im.time))
            return isFirst;
    }
    return false;
}

Миссии, как и раньше, отсортированы по ratio по возрастанию.

И последняя моя идея, в разы ускорившая перебор, такова. Рекурсивная функция возвращает true, если весь разрешённый «хвост» безнадёжен и в нём искать больше нечего. Это происходит при таких условиях.
1. Хвост пуст.
2. Хвоста недостаточно, чтобы получить K очков.
3. Простейшая экстраполяция по 1-й миссии провалилась.
4. Уже первый рекурсивный вызов говорит: хвост безнадёжен.

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

После того, как отработает тело деструктора, для всех полей объекта автоматически вызываются деструкторы, в обратном порядке.
У int и double деструкторы нулевые — но другие-то и не нужны.

В каких случаях надо писать деструктор самим…
1. Мы владеем каким-то ресурсом, но штатный деструктор его не уничтожает.
• Простой (не умный) указатель и выделенная память — это хорошо описал sitev_ru .
• Объект-блокировщик, например, мьютекса (мьютекс — примитив межпоточной синхронизации, не дающий зайти в определённые участки кода одновременно двум потокам).

class Mutex {
public:
  void enter();
  void leave();
}

class Lock {
public:
  Lock(Mutex& aMutex) : mutex(aMutex) { mutex.enter(); }
  ~Lock() { mutex.leave(); }
private:
  Mutex& mutex;
}

…
Mutex mutex;
{ Lock lock(mutex);
  // всё, что здесь, выполняется внутри мьютекса.
  // Даже если выпадет авария, из мьютекса корректно выйдем.
}

2. Сложный порядок уничтожения. Односвязный список из std::unique_ptr будет работать и так, со штатным деструктором, но это чревато переполнением стека.
3. Сложная структура владения, и при уничтожении надо автоматически отобрать объект у владельцев. По-чёрному используется в оконных фреймворках на манер VCL и Qt. Удаляем компонент — он автоматически отбирается у владельца.

По опыту: если структуры данных выносить в отдельный объект (ну и использовать STL, где можно), 80% объектов Си++ будут с автоматическим деструктором.

ЗЫ. По результатам прикидочных подсчётов в живом проекте, ≈150 файлов (реально файлов 219, но не все наши собственные; библиотечные деструкторы не учитывал).
• Классов с настоящим деструктором — около 30. Большей частью системные (W32Cs — быстрый мьютекс Win32) или структуры памяти (Array1d, например). Из них в собственно проекте (не в личной библиотеке программиста) — три (!): один связан с автовладением чужой библиотекой XLSX, два — с фоновыми потоками.
• Интерфейсов с пустым виртуальным деструктором — порядка 40.
• И ещё деструкторы, автоматически добавленные Qt — по числу форм, ровно 20.
• И единицы пустых деструкторов, добавленных по желанию левой пятки линкера.

char * a = "hello!";
Для указателя a — разумеется, на стеке.
Строка, на которую он смотрит, "hello",— строковый литерал. Для него память изначально, при пуске программы выделена в сегменте данных. Освобождать не надо. На многих платформах — хоть на это рассчитывать не надо — этот сегмент защищается от записи и при попытке туда записать AV.

3) Использование инициализации списком для структур (POD) с уже прединициализированными полями:

Это C++11. Хорошее дело. MinGW поддерживал, пока стандарт ещё вырабатывался. MSVC начал было, да бросил и довёл до конца аж в 2015!!

1) Разное содержимое одних и тех же хедеров

Не выбивается из стандарта.

2) MSVC спокойно компилирует нечто вроде

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

но при этом не компилирует код, если не-void функция не возвращает значение

Хорошая диагностика, но это лишь warning, а не error. Компилятору трудно знать, возможен ли тот или иной путь исполнения кода.