Mercury13

Это невозможно, мэн волен ввести в консоль что угодно.
Но ваша задача как программиста — каким-то образом не допустить некорректного ввода. То ли вывести ошибку, то ли самостийно округлить, то ли потребовать повторный ввод… Вы уж сами думайте, что требуется именно от вашей программы.
Условие «кончается на 5» эквивалентно  «не делится на 10, но делится на 5».

• 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. extern "C" — говорит, что функцию НЕ надо «козявить» на манер Си++, кодируя в имени её параметры наподобие h(int) → _Z1hi. Используется для доступа из Си++ к функциям, которые скомпилированы другим компилятором (Паскалем, Си…), а также для всяких там функций, которым надо дать фиксированное имя — например, функций DLL.

2. __declspec(dllimport). Это нужно для доступа к функциям DLL: линкер будет брать функции прямо из DLL, без создания *.lib или *.a (как минимум MinGW так работает). Языки, сильно привязанные к определённой ОС (например, Delphi) могут создавать свои ключевые слова для доступа, например, к DLL или COM.

procedure DoSomething(x : integer); cdecl;  external 'something.dll';

Застандартизированный Си вынуждает полагаться на ключевые слова, начинающиеся с двух подчерков.

void* используется как указатель на сырые байтовые данные, не имеющие конкретного типа.
Обычно это используется…
1. В чтении-записи в файлы и на устройства, когда мы можем писать туда абсолютно любые типы.
2. В «многоликих» функциях, которые могут принимать данные разных типов (malloc/calloc, часть функций WinAPI и ODBC).
3. Как дескриптор — указатель, который запрещается разыменовывать. В Си для этого также часто используют указатель на недоопределённый тип, в Паскале с другими правилами эквивалентности типов — на пустой record. Но только пока не появится очередная многоликая функция вроде CloseHandle.
4. Для обеспечения т.н. замыкания — передачи callback’у контекста, откуда была вызвана функция, вызвавшая callback.

BOOL WINAPI EnumWindows(
  _In_ WNDENUMPROC lpEnumFunc,
  _In_ LPARAM      lParam
);

BOOL CALLBACK EnumWindowsProc(
  _In_ HWND   hwnd,
  _In_ LPARAM lParam
);

Вот этот LPARAM, который обычно определяется как какой-то указатель, и есть замыкание. Функция EnumWindows обещает передать его в функцию lpEnumFunc без изменений.
(В Си++ для этого также используют виртуальные интерфейсы, но такой метод, сами понимаете, языкозависим и не годится для межъязыкового API.)

Что происходит на стороне функции? Одно из двух (считаем, функция написана на ЯВУ).
1. Либо вызывается некая функция устройства, которая говорит: «записать 100 байт», и дальше уже работает железо.
2. Либо мы преобразуем void* в нужный нам тип и работаем с ним.

Типы указателям дают по трём причинам.
1. Вы забыли про операцию «разыменовать указатель». Чтобы его разыменовать, он должен иметь тип!
2. Чтобы не ошибаться и не переприсвоить несовместимые указатели.
3. Для полиморфизма — в Си++, давая delete x, мы даже можем не хранить, сколько байтов в блоке, поскольку мы знаем длину типа. (Есть ещё и виртуальные классы, но это другой вопрос.)

На x86 оба они — макроопределения для нестандартного соглашения вызова __stdcall.
На ARM они ничего не делают.

Соглашение вызова — это…
• как на уровне регистров мы вызываем функцию;
• кто подчищает стек за вызывающим;
• кто отвечает за восстановление регистров, если они менялись (или есть риск, что они менялись).

stdcall — вызов через стек, справа налево, за очистку стека отвечает функция, результат в eax (rax), функция отвечает за восстановление сегментных регистров, esp и ebp, программа за остальные.

На ARM используется соглашение cdecl. То же самое, но за очистку стека отвечает программа (что там на ARM с регистрами, я не в курсе).

Абстрактные классы делят на интерфейсы и частично реализованные. Грань между ними такова:
• Интерфейс не имеет данных.
• У интерфейса все неабстрактные виртуальные методы представляют собой или эталонное поведение, или самую частую реализацию. В обоих случаях, если что, их надо не расширять, а переписывать с нуля.

Так вот, для интерфейсов таких конструкторов, разумеется, не нужно.

Например, между абстрактным потоком и файлом Win32 может быть такая иерархия: Stream → HandleStream → File. Stream — интерфейс, даже если там есть что-то типа

// virtual
unsigned long long Stream::remainder() const { return size() - pos(); }

HandleStream содержит уже данные (дескриптор Win32), и это уже частично реализованный класс, который крутится вокруг этого дескриптора: в деструкторе вызов CloseHandle, конструктор может принимать дескриптор, полученный каким-то «левым» образом.

HandleStream::HandleStream(HANDLE aHandle) : fHandle(aHandle) {}
HandleStream::~HandleStream() { close(); }

void HandleStream::close()
{
  if (Handle != INVALID_HANDLE)  { // не помню, как там эта константа в Win32
    CloseHandle(fHandle);
    fHandle = INVALID_HANDLE;
  }
}

Вот в таких полуреализованных классах, разумеется, конструктор может инициализировать те данные, которые там есть.

Перед нами структура данных под названием «односвязный список». У каждого элемента ссылка на следующий, у всей очереди ссылка на голову (front) и иногда на хвост (rear).

Для чего нужна проверка на заполненность — непонятно, ведь ёмкость списка не ограничена и единственный способ убедиться, что очередь полна — завести память под новый элемент. Выпадает авария std::bad_alloc — значит, памяти не хватило. Если только для каких-то прикладных нужд: так, в StarCraft очередь на строительство пять юнитов, и точка. (Есть другой тип очереди, т.н. циклическая очередь — вон там ограничено.)

Как работает enqueue: создаём новый элемент, следующий за ним — nullptr. Если очередь пуста, направляем на него front и rear. В противном случае пристраиваем его за тем, на который «смотрит» rear, и перенаправляем rear. Таким образом, «направляем rear» можно вынести за скобки, а остальные два исполнить в зависимости от пустоты очереди.

В крайне-крайне редких случаях, когда вы пишете редактируемый пользовательский интерфейс. Например, в ERP.
Разумеется, QUiLiader под капотом есть всегда, но среднему программисту он ни к чему.

Ваш код коряв (и пишет за пределы буфера, если в потоке действительно окажется 2048 байт) но нуль-терминированные строки отрабатывает правильно.

TCP работает сплошным потоком, и если вы послали в сокет нечто ещё, кроме «123123», он считает весь поток до 2048 байт и, разумеется, строки не совпадут: с одной строны «123123», с другой, например, «123123qwe».

Вам надо своими силами разбивать TCP-поток на сообщения — например, тем самым нулевым символом, CR или двумя/четырьмя байтами длины пакета.

Вы наладили операцию String << ostream → ostream. Надо наоборот, ostream << string → ostream.

Такую операцию можно наладить только за пределами класса (возможно, как friend).