MgmZog

контроллеры умеют сильно битые сектора убирать из обслуживания, но делают это лишь тогда когда его заставят

Это всё сказки, повествующие о программах, которые переразмечают бедблоки. На деле, если вы заглянете в спецификацию AHCI, то не обнаружите там ничего подобного. Нет таких команд в протоколе. Контроллер должен сам об этом позаботится. Если на диске появились бедблоки (не просто запись в S.M.A.R.T., а именно нечитаемые области), то это означает лишь то, что резервная область закончена и переразмечать сектора уже некуда.

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

Но если вас не смущает скорая смерть диска и потеря данных, то да, такие файловые системы есть. Например ext4. mkfs.ext4 имеет параметр -l, после которого можно указать файл, сгенерированный программой badblocks. Так же mkfs.ext4 может сама проверить диск перед созданием файловой системы. Битые сектора будут игнорироваться.

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

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

Классика жанра - запись в неинициализированный указатель.

Читайте учебник по указателям лучше.

double *cm никуда не указывает. Чтобы указывала, нужно присвоить. Например, так.

double* cm=new double.

Программно:
https://support.microsoft.com/en-en/kb/259697

Из командной строки:
https://msdn.microsoft.com/en-us/library/windows/h...
Качаете, устанавливаете (нужен только tools), запускаете devcon rescan

Из какой книжки накопипастили куски? Сообщение в гугл вводили? Переводить пытались?
Английским по белому написано - вы пытаетесь использовать фичи из C++11, а компилятору об этом не сказали.
И даже решение написано - опцию нужно добавить.

Закрыта однозначно!
Кулеры обеспечивают ЗАДАННЫЙ циркулирующий поток воздуха, при открытой же - они циркулируют тепло вокруг системника хаотичным образом.

1. По стандарту C++, всякая функция, которая что-то возвращает, должна содержать return. Иначе - неопределенное поведение, так как компилятор не сможет сгенерировать правильный эпилог.
2. Пролог и эпилог должен генерировать кто-то один.
3. Некоторые особо дурные компиляторы умеют отключать генерирование пролога и эпилога. Напимер, VC++ это делает при помощи __declspec(naked).

Вывод:
Либо вы выключаете пролог/эпилог и пишите на ассемблере всю функцию, включая пролог и эпилог.
Либо вы пишите только ВСТАВКИ, и не выносите мозг компилятору, перекашивая ему стек. (В начале и в конце вставки стек должен быть прежним).

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

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

В данном конкретном случае инициализации нулями можно сделать так:
memset(map, 0, sizeof(map));

Если map -- массив POD-объектов, а инициализация нетривиальная, можно скопировать эталонный массив с помощью memcpy:

Map(){
    static const map_init[20][20] = {
        ...
    };
    memcpy(map, map_init, sizeof(map));
  }

В противном случае -- любым другим "объектным" способом -- std::copy, циклом, как угодно.

Начиная с С++11 можно проинициализировать массив в списке инициализации конструктора, вне зависимости от того, POD поле или нет, например так:

Map(): map{{1, 2, 3, 4, 5, ...}, {21, 22, 23, 24, 25, ...}, ...} {
  }