Станислав Макаров

При этом libpng установлен. Не понимаю, что я делаю не правильно?

Я думаю, include-директория libpng не была передана компилятору, и нужно это сделать.

При этом libpng установлен.

Что вы понимаете под установкой libpng в контексте Windows?)

Для вещественных чисел нет сравнения ==. Есть сравнения (a - b) <= eps. В большинстве случаев так и нужно, т.к. вещественными числами моделируется континуальные величины из реального мира (т.е. те, в которых не обязательно считать с точностью до каждой цифры).

С другой стороны, для денежных расчётов вещественную арифметику использовать нельзя, т.к. деньги в принципе дискретны. Никто не хочет по определению увидеть 4.74999999...$ вместо 4.75$. Для таких расчетов используются decimal-типы (таких типов не в стандартном C++, есть реализованные в виде библиотек).

Она должна превращать такие числа 0.475 в такие 475

Строго говоря, задача поставлена некорректно. Ну или бессмысленно. Такую задачу можно было бы поставить для decimal-типов, которые считаются всегда точно, и количество десятичных цифр в их записи ПРЕДСКАЗУЕМО. А для float у вас будет получаться что-то вроде 4749999999998.

Помимо накопления ошибок, вы еще не забывайте о том, что не все, даже заданные вами в коде, десятичные константы представимы в двоичном виде без потери точности. Например, познакомьтесь с числом 0.13. Можете просто записать его в константу, и тут же вывести на экран.

В общем, добро пожаловать в мир машинной арифметики.

https://en.wikipedia.org/wiki/Floating_point
https://en.wikipedia.org/wiki/Decimal_data_type

Неужели нет какого нибудь более простого способа релиз билда приложения на qt???

Если там правильные DLL (как сказал Ринат Велиахмедов , без суффикса "d") - то вам их надо собрать в одной папке вместе с exe (плюс отдельный разговор о плагинах для платформы). В документации Qt точно был отличный раздел про сборку релиза.. О, вот: https://wiki.qt.io/Deploy_an_Application_on_Windows и doc.qt.io/qt-5/windows-deployment.html

Рабочий вариант для работы с UTF-8 строками (2015-я студия). Не забудьте пересохранить исходник в UTF-8 кодировке.

#include <iostream>
#include <windows.h>

int main()
{
	SetConsoleOutputCP(CP_UTF8);
	auto message = u8"Тест тест";
	wprintf(L"%S", message);
    return 0;
}

На будущее:
1) с юникодом и UTF-8 в частности в Винде есть некоторый гемор по ряду исторических причин (в частности, из-за того что родная юникодная кодировка WinAPI - UTF-16); нужно просто уметь решать эту проблему (если нет желания заниматься разработкой на Linux);
2) это не отменяется того факта, что нужно хорошо знать, что вы вообще делаете. VS - инструмент для работы, особенно это касается C++ проектов, и нужно разобраться с определенными вещами, чтобы им пользоваться. Это я вообще, чтобы вы подход свой поменяли.

Когда их стоит использовать

Умные указатели? - задан сегодня утром.

Нужно ли, например, объявлять массив при помощи std::unique_ptr и т.д.

В большинстве случаев лучше std::array для массивов размера, известного во время компиляции, и std::vector - если размер становится известен только при выполнении программы. Исключение - необходимость взаимодействия с кодом, использующим обычные указатели на массивы (в частности, с Сишным кодом).

и какой из них?

std::unique_ptr подразумевает одного владельца в один момент времени, и переход владения от одного умного указателя к другому (ownership transfer). std::shared_ptr использует подсчет ссылок, чтобы у объекта было несколько владельцев. Объект будет уничтожен, когда последний shared_ptr, указывающий на этот объект, будет уничтожен.

Разумеется, и та и другая стратегия работает только в умных указателях. Если вы скопируете содержимое умного указателя в обычный, и затем объект будет удален умным указателем, то обычный указатель продолжит указывать на тот же адрес в памяти. Это очевидная вещь, но именно на нее все напарываются поначалу.

Отдельно добавлю, что unique_ptr это один из способов моделирования композиции объектов (когда умирает владеющий объект, умирают и те, которыми он владеет), а shared_ptr - агрегации (если владеющий объект умирают, те, которыми он владел, продолжают жить, пока они нужны кому-то еще).

Вы, возможно, еще недостаточно освоили ОО-возможности языка C++. Тогда ваш вопрос более чем логичен.

Видите ли, в языке, где есть какая-либо ОО-модель, неизбежно будут выделяться две категории типов данных - типы данных, экзмепляры которых ведут себя как значения (values), и типы данных, экземпляры которых ведут себя как переменные/объекты (если тут непонятно, опишу подробнее).

Отличительной особенностью объекта с теоретической точки зрения является identity - некий ключ или признак, с помощью которого этот объект уникальным образом идентифицируется. В ОО базах данных в качестве identity используется т.н. OID. В C++ в качестве identity объектов используются указатели. Это удобно, т.к. место объекта в памяти однозначно идентифицирует его (тут как раз и прослеживается тот факт, что объекты в C++ - это суть переменные, изменять состояние которых можно только строго определенным образом).

Хотя язык C++ позволяет в теории работать с любым типом как "по значению", так и посредством указателей, реальные классы обычно проектируются так, чтобы подчеркнуть их семантику значение/объект. Например, для типов которые ведут себя как "значения" пишется конструктор копирования и разрешаются операции присвоения. Для типов-"объектов" наоборот, операция присвоения и конструктор копирования запрещаются. Конечно, ничто не мешает превратить указатель в ссылку и работать по ссылке, однако использование ссылки "прячет" от нас информацию об identity объекта. Например, для сравнения одинаковости двух объектов (если это именно "объекты", а не "значения") достаточно сравнить лишь их identity, в терминах C++ - указатели. Если вы превратили их в ссылки, вам придется использовать операцию взятия адреса: &a == &b, что менее логично и удобно, чем сравнить обычные указатели: a == b. Кроме того, важным отличием указателя является то, что одним из его допустимых значений является nullptr, что также может быть удобным (а может и нет).

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

К сожалению, все несколько сложнее, и вам нужно лучше разобраться, что происходит в обоих случаях.

В C++ жизненный цикл объекта, место и способ его существования определяется кодом, создающим объект. Иными словами, тот код, который ИСПОЛЬЗУЕТ класс, определяет, автоматическая ли будет создана переменная (Example a(..)), или динамическая (new Example(..)). Да, в коде класса можно ограничить использующий код, запретив использование конструктора копирования и оператора присваивания, но изначально дизайн языка подразумевает принятие решения не "создателем" класса/структуры, а её "пользователем".

В C# поведение переменной типа класса/структуры зависит прежде всего от самого класса/структуры. Экземпляры классов, т.е. reference-типов, создаются с динамическим жизненным циклом, и для них работает механизм подсчета ссылок и сборка мусора. Экземпляры структур создаются с автоматическим жизненным циклом, переменные структур хранят значения структур, а не ссылки на них.

Иными словами, выражение new T(...) - это просто унифицированный синтаксис создания экземпляра типа, независимый от природы этого типа. Удобно это или не очень - отдельный разговор, однако в текущем дизайне языка это достаточно логично (особенно в контексте generic-ов). Аналогично, T a - унифицированный синтаксис объявления переменной типа.

Нельзя слепо сравнивать то, что происходит в C# и в C++.

Если 1C хранит данные в SQL, то в общем-то проблем нет, надо только выяснить какая СУБД используется.
Если 1C хранит данные в sdf-ках, то в принципе тоже можно, но я бы не стал открыть этот ящик Пандоры.

Си как язык и экосистема, безусловно, нужны много где. Вопрос в том, нужны ли ВЫ этой экосистеме. Любой специались ценен не только знанием языка, но еще и знанием экосистемы и, самое главное, умением решать задачи, где вышеуказанный язык даёт наибольшую эффектиновсть с точки зрения бизнеса.
Мало кому сегодня нужен человек, знающий PHP, но не знающий ничего о веб-разработке. С Си (да и с C++) то же самое. Чтобы вам давали те задачи, для решения которых имеет смысл использовать именно Си, вам нужно расти как специалист и в других областях. Например, хорошо разбираться в структурах данных. В управлении памятью. В машинной арифметике.
Сравните например, человека, который просто знает, что в языке Си есть тип float, и человека, которому известно, что в Сишный float не запишешь значение 0.13, не потеряв в точности. А также человека, который понимает, почему точность теряется. И еще человека, который знает, что можно предпринять, если все-таки нужно как-то оперировать с десятичными дробями без потери точности.

Этот ответ должен вас мотивировать на рост как IT-специалиста в целом, уделяющего дополнительное внимание принципам работы вычислительной техники и различным низкоуровневым вещам.