Mercury13

А такое будет работать?

inline const char* wtc(const WCHAR *from)
{
  //Используется буффер -- статическая переменная
  static char buf[1024] = { 0 };
  size_t nChars = std::min<size_t>(wcslen(from), 1024 - 1);
  if (!CharToOemBuffW(from, buf, nChars)) {
    cout << GetLastError();
    exit(-1);
  }
  buf[nChars] = 0;
  return buf;
}

Одна сатана. В терминологии одних языков принято parameter, других argument.

#include <iostream>

template <class Body>
void call(const Body& body) {
    body();
};

void test() {
  std::cout << "function" << std::endl;
}

int main() {
  call(test);
  call([]() {
    std::cout << "lambda" << std::endl;
  });
  return 0;
}

Дело в том, что лямбда — это объект неизвестного класса с операцией (). И только так её вызывают.

Смотря в чём задача.
Возможно, нет никаких проблем.
Возможно, удастся вытащить общую функциональность в defines.h.
Возможно, удастся каким-то образом разорвать порочный круг. Например, в ООП это можно делать через интерфейс.

Это значит: вы «сломали» память. Как правило, разыменованием «висячего» указателя или вылетом за пределы массива.

Переменная run ничему не присвоена.

Нужен или массив с запасом (например, на 6 мест), или динамический (например, std::vector).
Си++ — язык достаточно низкого уровня, и сам программист видит, где там память динамически выделяется, а где выделена заранее.

// Защита от повторного включения
#ifndef MAINWINDOW_H
#define MAINWINDOW_H

// Пара include’ов
#include <QWidget>
#include <QMainWindow>

// Определение UI-класса наперёд, чтобы визуальное редактирование не приводило
// к крупным перекомпиляциям
namespace Ui {
class MainWindow;
}

// Собственно класс формы
class MainWindow : public QMainWindow
{
    // Макрос, который добавляет файл в компиляцию MOC’ом,
    // а также реализует пару функций
    Q_OBJECT

public:
    // Конструктор-деструктор.
    // Форма семантически не эквивалентна parent’у,
    // потому конструктор explicit
    explicit MainWindow(QWidget *parent = nullptr);
    ~MainWindow();

// Слоты — фишка Qt, которая обрабатывается MOC’ом
private slots:


private:
    // Указатель на UI (для него в Qt есть ещё одна программа, UIC)
    Ui::MainWindow *ui;
};

// Защита от повторного включения
#endif // MAINWINDOW_H

Что ещё написать?

Определение класса наперёд не мешает писать указатели и ссылки.

Конструктор explicit запрещает неявное преобразование. Explicit имеет смысл, если возможен вызов конструктора с одним параметром. Правило таково: ставь explicit, если твой объект по смыслу не эквивалентен единственному параметру конструктора. Например, Ratio(int x);, но explicit Array(int x);: при построении рационального числа из целого будет полный эквивалент, но при построении массива — нет.

Пробел не isupper.

Расчёт тут идёт в знаковом типе, потому *i + key - 97 < 0

Существует два метода деления с остатком, в x86 встроен тот, где знак остатка равняется знаку делимого (а неполное частное — результат округления к нулю). Именно его впоследствии кодифицировали в Си99. Значит, (*i + key - 97) % 26 < 0

Это значит, что результат преобразования будет меньше 97 = 'a'. Например, 'W'.

Ах да. В Си можно написать (*i + key - 'a') % 26 + 'a'.

Использовать кольцевой буфер. Придётся пописать немного, но на что это нужно и какова будет сложность остальных работ?

typedef struct ttime {
Си, на ++ не нужен typedef.
И используй наконец тэги для кода.

int hours; int minute; int sec;
Странное именование, обычно пишут hour.

struct date {
ttime time;

которая в свою очередь входит в состав структуры Date.

Странно, ведь это не дата, а скорее Clock — часы.

Методы позволяют изменять текущее время

Ну и где тут измерение?

Моя архитектура.
1. Время. Получение времени из системы, сравнение, вывод в консоль.
2. Часы. Хранят последнее время. Команда «tick» — получить время, сравнить с последним, при неравенстве — сохранить новое и вывести его в консоль.
3. Внешний цикл (может быть как в часах, так и снаружи). Часы тикают, делают небольшую задержку и проверяют на нажатие клавиши.
Пять объектов никак не будет, да и Date нужно только в том случае, если вы реально работаете с датой. Я бы, чтобы докинуть количество объектов до нужного, сделал бы дату (date), время (time) и дату-время (stamp).

Для турнира единоборств (для простоты — без весовых категорий).
• Fighter: имя, всякая информация про него вроде города, клуба и титулов.
• Stub: указатель на Fight + enum (Winner/Loser) — откуда берётся участник. Указателя на Fight нет — тогда TBD (то есть не определился).
• Participant: указатель на Fighter + структура stub.
• Fight: номер, два Participant, дата/время, кто победил (0/1), причина победы (ещё не проводился, KO, TKO, по очкам, неявка…)
• Tournament: содержит список боёв и таблицу результатов.

Можно также разорвать кольцо зависимостей, наладив интерфейс FightInfo, сделав в Stub FightInfo*, а не Fight*, и чтобы Fight реализовывал FightInfo.

Дело тут в очерёдности операций.
Сначала вычисляются правые одноместные, потом левые.

Надо (**h)[1] = 0;.

Через сигналы-слоты способа не вижу.
Унаследоваться от QStandardItemModel, присосаться на setModelData.
А ещё лучше унаследоваться от QAbstractTableModel и переопределить все эти data(), flags()…

Вы тут просто не знаете, что такое указатель. А это, грубо говоря, адрес другого объекта в памяти.
Операция new заводит объект в «куче», вызывает конструктор (если таковой есть) и возвращает указатель на него.
И мы можем разыменовать указатель: пройти на тот объект, куда он указывает, и сделать с ним что-то. В Си разыменование — операция ->.

Указатели не на абстрактный класс, а на вполне конкретный, a.

a(int) — не конструктор копирования, а просто конструктор, делающий объект из int’а. Конструктор копирования всегда a(const a&). Отличается от других конструкторов тем, что автоматика его по возможности строит, но не всегда верно. В вашем объекте с одним полем int вполне себе построит без всяких проблем.

Обычный указатель Си никоим образом не знает, есть объект или нет, и кто этот объект уничтожает. У вас это приводит к ошибке «утечка памяти»: теряется указатель на объект, и уже никак его не освободишь. Из-за небольшого размера и линейного характера программы неопасно, но всё-таки.