Mercury13

• std::string — как правило, если не указано противное.

• QString, AnsiString/UnicodeString и прочие — в соответствующих фреймворках, обычно очень близко к интерфейсным функциям.

• char* — практически не используется в реальном коде. В основном для оптимизации, если есть собственное управление памятью. Довелось как-то в собственном разборщике XML (работает в 2,5 раза медленнее рекордсмена, pugixml. Зато даже это в разы быстрее Excel’я, пространства имён «из коробки», расход памяти мизерный и программирование простейшее.)
Зато по-чёрному используется его const-аналог.

• const char*. Это может быть одинокий const char* + нуль-терминированная строка, или указатель+длина, или указатель на начало + указатель за конец.
1. Если ожидается, что в функцию будем передавать строковый литерал.

void writeEnum(st::Stream& st, int value, const char* names[]) {}

enum class Letter { A, B, C, …, Z, NN };
const char* natoNames[static_cast<int>(Letter::NN)] = { "alpha", "bravo", "charlie", … };
writeEnum(someStream, static_cast<int>(Letter::E), natoName);

2. Если операцию со строкой можно произвести «на месте», не заводя новую память: (trim, как известно,— обрезка пробелов в начале и конце)
void trim(const char*& beg, const char*& end);

3. Если структура данных паразитирует на чужих строках, не заводя своей памяти. Особенно если конструкция строк неизвестна (например, при передаче данных из плагина в плагин).
struct ParasiteString { const char *beg, *end; };

4. В библиотеках, если они реально настолько компактные, что нет нужды обязательно подключать жирный STL.

• char[] — только как оптимизация, когда предельная длина строки известна и невелика.

wchar_t* myFtos(double value, wchar_t* buf, const FloatFormat& format) {}

wchar_t buf[100];
myFtos(100.500, buf, FloatFormat::NICE);

Простой способ (говорят, что есть глюки!)

import QtQuick 2.9
import QtQuick.Window 2.2

Window {
    visible: true
    width: 640
    height: 480
    title: qsTr("Hello World")
    flags: Qt.Window | Qt.FramelessWindowHint   // <<<<<<

    Text {
        id: text1
        x: 77
        y: 59
        text: qsTr("Test!!!")
        font.pixelSize: 12
    }
}

Сложный описал Александр Таратин, и в нём эти глюки решены.

Первое — это include собственного заголовка, то есть искать его в рабочем каталоге, в дополнение к стандартным каталогам компилятора.

#include <file>
This variant is used for system header files. It searches for a file named file in a standard list of system directories. You can prepend directories to this list with the -I option (see Invocation).

#include "file"
This variant is used for header files of your own program. It searches for a file named file first in the directory containing the current file, then in the quote directories and then the same directories used for <file>. You can prepend directories to the list of quote directories with the -iquote option.

1. Найти «в лоб» НОД и похѣрить его.
2. Найти «в лоб» НОК и отправить его туда же.
Повторяю, обе функции крайне неэффективны, а их результат идёт в никуда. Как только управление пересечёт точку с запятой, переменная исчезнет.

Вот и положите этот libmingwex-0.dll в каталог с программой. Всё в порядке, программа скомпилировалась, остаётся пустить.
Если такое случается при запуске компилятора — что-то с компилятором, и переустановить надо ЕГО.
(Покопался по интернету, завтра проверю на работе свежие версии MinGW)

Есть вычитание близких чисел? Какие-нибудь циклы вроде СЛАУ больших порядков и решения дифуров? Знакопеременные ряды? Если нет, можно писать, что вклад машинной арифметики в точность алгоритма незначителен.
А если есть, нужно исследовать, кто и как может многократно усилить ошибки округления.
Ради эксперимента можно также сравнить результаты во float и double.

Пример алгоритма, который аналитически устойчив, а вычислительно — нет: e^−x «в лоб» при достаточно больших x. Связан он с тем самым вычитанием близких чисел: промежуточные члены ряды могут быть достаточно большие, а в результате выходит 0,0…01.

UPD. Вот такую книжку нашёл: info.alnam.ru/book_clm.php?id=26

УРОВЕНЬ 1. ПРОГРАММНОЕ РИСОВАНИЕ. В экстремальном случае — программист сам рисует элементы управления, как на Canvas’е. Его опустим. Так, например, поступают в разработке игр, когда элементов мало, и они должны быть предельно стилизованы. Но и в таком случае лучше делать библиотеку объектов.

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

УРОВЕНЬ 2. ОБЪЕКТНАЯ БИБЛИОТЕКА. Часто ОС и/или система программирования имеют свою библиотеку элементов управления. В таком случае получается что-то типа.

program HomeMadeForm;

uses
  Vcl.Forms, Vcl.StdCtrls;

{$R *.res}

var
  fm : TForm;
  bt : TButton;

begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True;

  fm := TForm.Create(nil);
  fm.Width := 400;
  fm.Height := 200;
  fm.Caption := 'Test';

  bt := TButton.Create(fm);
  bt.Parent := fm;
  bt.Caption := 'Go!';
  bt.Left := 150;
  bt.Top := 80;

  fm.ShowModal;
  fm.Free;
end.

УРОВЕНЬ 3. ВИЗУАЛЬНОЕ РИСОВАНИЕ. Наконец, существуют механизмы рисования форм: Qt Widgets, Qt Quick, VCL, WxWidgets, Windows Forms… В таком случае программист просто рисует форму, а про механизмы конструирования-позиционирования не думает. Создал форму, на неё поставил кнопку, к кнопке приделал событие OnClick — и вот уже при нажатии кнопки вызывается событие.


Существуют и HTML-подобные механизмы. Например, элементы HTML есть в Apache Cordova, обеих разновидностях Qt. Используют их, потому как удобно, но механизмы разбора HTML довольно сложны и потому не везде есть.

start "32-bit" cmd /c 2.bat