Евгений Шатунов

Все уже изучено

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

https://docs.microsoft.com/en-us/previous-versions...
По ссылке видно, что функция URLDownloadToFileW объявлена в Urlmon.h и определена в Urlmon.dll.
Т.к. ошибка на стадии линковки, то компиляция прошла успешно, а значит Urlmon.h так или иначе подключается в процессе компиляции. Но Urlmon.lib не добавлена в опции линковки, из-за чего и возникает ошибка.

p[size + size] = 7

Запись за границу массива - это Неопределенное поведение, которое в данном случае выражается в краше программы.

Ну гарантированный улет за границу массива вот тут i < zoo.size() + 1
Что тут делает +1?

Потому что буст не весь наглухо шаблонный, есть откомпилированные либы, которые надо явно линковать. Как конкретно линковать - зависит от конкретной системы сборки.

https://docs.microsoft.com/ru-ru/cpp/c-runtime-lib...

Например можно использовать для этого сам Word, если вас это устраивает. Все продукты MS Office являются COM/ActiveX объектами. Это можно использовать в своей программе на каком угодно языке, умеющем в COM/ActiveX. С++ это умеет. Из коробки это умеют еще и JacaScript и VBScript, так что может вам и плюсы не нужны.

Константный вектор. Можно вызывать только константные методы, переприсваивать или как-то изменять нельзя.

Но откуда тут вообще может быть непонимание? В C++ никогда нельзя менять, на что ссылаются ссылки. const/не const может быть только то, на что оно ссылается.

Edit: изначально я тут некорректно назвал это константной ссылкой, но по хорошему, оно называется ссылка на константу.

А что вы шлете на сервер, не пробовали задуматься?
Если проследить:

HTTP/1.0
Host: domain.com
Content-Type: application/x-www-form-urlencoded
Content-Length:

Первая строчка не смущает? А Content-Length?

Ну и send(s, sendbuf, sizeof(sendbuf), 0); - почему sizeof? 1024 байта с кучей 0x00 хотите послать несчастному серверу?

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

Это скорее всего макросы, определенные где-то в заголовочных файлах. Поищите поиском по "#define _CMDINP" по исходникам библиотеки.

Скорее всего _CMDIMP для компилятора микрософт преобразовывается в __declspec( dllimport ). Для gcc макрос не определен.
_CMDAPI это видимо что-то вроде stdcall или cdecl, т.е. соглашения о вызовах.

Это какие-то макросы. В нормальных IDE можно ткнуть в непонятное и сделать Go To Definition и посмотреть, что это такое.

Такие макросы обычно появляются у всяких кроссплатформенных штуковин с динамической линковкой - когда нужно учесть особенности разных компиляторов и ОС.

Приведите всё сообщение компилятора целиком. В нем однозначно написано, какой конструктор он ищет. Кажется, внимательно посмотрев на него вы заметите, что компилятору нужен конструктор с const String&, когда как у вас определен только String&.

Если вы делите целые числа (short, int, long), то на компьютере вы в принципе не можете получить число с плавающей точкой в результате, т.к. выполняете целочисленное деление.
Кроме того в процессоре целочисленное деление на ноль обычно вызывает аппаратное исключение. Оно может передаваться в приложение, может не передаваться, тут уже особенности платформы, runtime и т.п. Можете поэкспериментировать.

Деление на ноль чисел с плавающей точкой стандартно дает в результате NaN - это не число (Not a Number). Любые дальнейшие операции с NaN будут давать в результате NaN.
Современная стандартная библиотека позволяет настроить поведение так, что бы при делении на ноль чисел с плавающей точкой так же выбрасывалось исключение (std::fesetexceptflag()).

Если вы хотите получить какое-то число близкое к нулю - реализуйте деление так как считаете нужным.

Деление на целочисленный 0 невозможно, происходит авария «деление на 0».

В процессорах, которые делят 2w:w → w, эта авария происходит и в других случаях. Скажем, если слово — это две десятичных цифры, то 1000:2 даст ошибку: 500 не укладывается в эти две цифры. В Си++, который умеет делить только w/w, такое сделать можно только на ассемблере.

Деление конечного на дробный 0.0 даёт ±∞ — особое «число», которое больше/меньше любого конечного.
Деление 0.0/0.0 даёт NaN (not a number, не-число).

Откуда вы взяли мантиссу 1,87235 — я не знаю. Минимальное денормализованное число в float 1.4e−45, в double 4.9e−324. Почему так мало знаков — да потому что погрешность у таких чисел ±100%: меньше только 0, а следующее вдвое больше.

UPD. В редко используемом и очень медленном extended (= long double) есть что-то похожее — 1.9e−4951.

Память под статический массив выделяется на стеке. При выходе из области видимости стек очищается и память под массивом освобождается автоматически (не нужна операция освобождения памяти, операция есть, но о ней позаботится компилятор самостоятельно).

Память для динамического массива выделяется в динамической памяти (в куче) (new[]). Когда массив становится не нужным память должна быть освобождена (delete[]), иначе произойдет утечка памяти.

В связи с вышеизложенными принципиальными отличиями, есть несколько следствий:
1. Имя статического массива это не указатель. Это можно понять например сравнив, что возвращает sizeoff() для статического массива и для динамического. Хотя в некоторых ситуациях компилятор ведет себя так, как будто имя статического массива это указатель, например: можно передать имя статического массива в функцию, принимающую указатель.
2. У динамического массива нет имени. Операция new[] возвращает указатель. Имя есть у указателя.
3. Внимание! Оба варианта массивов имеют фиксированный размер. Изменять его нельзя!
То что в std::vector вы можете укладывать кучу элементов постепенно, не указывая нигде предварительного размера является следствием того, что std::vector скрывает от вас всю работу, которую он при этом делает. При добавлении нового элемента, для которого нет места, он выделяет память для нового массива большего размера, копирует старый массив в новый, удаляет старый массив, добавляет новый элемент. Если идет интенсивная работа с push_back(), то это может ОООЧЕНЬ дорого стоить. std::vector - это удобно, но необходимо всегда помнить, за счет чего достигается это удобство. std::vector - это не динамический массив - это обертка над ним для более удобной работы с динамическим массивом.

В языке Си (C99) есть такая штука как Variable Length Array (VLA) - это статический массив с изменяемым размером. Т.е. вы можете, например, в функции объявить int arr[N], где N будет передаваться в функцию как параметр.
В стандарте С++ VLA нет! Но, например, тот же gcc с опциями по умолчанию разрешает его использования в С++ проектах. С опциями, заставляющими gcc более жестко следовать стандарту, он может запрещать использовать VLA в С++ проектах. Но не рассчитывайте, что все компиляторы будут так делать. Например микрософтовский компилятор в принципе не умеет в VLA (хотя я уже пару лет не проверял это).
VLA может показаться классной штукой.
Но, например, в ядре Линукс в свое время проводили целую компанию по выпиливанию VLA из исходников. Торвальдс высказывался негативно про VLA. Все это при желании можно нагуглить.
Стоит помнить, что размер стека ограничен, а VLA то же выделяется на стеке. Кроме того выделение памяти для обычного статического массива это просто увеличение счетчика стека на константу (и все, одна операция сложения регистра с константой, а компилятор одной операцией выделяет память для всех переменных в текущей области видимости). С VLA все сложнее с выделением и удалением. Так же sizeof() для обычного статического массива это операция времени компиляции (при выполнении будет уже заранее известная константа), для VLA - это полноценный вызов функции.