Dvvarreyn

Скомпилируйте код. И посмотрите, какие ошибки выдаст компилятор. По моему мнению, ошибок просто не будет, код правильный.
То, что вывидите — это глюки среды.
Если ошибки будут, то опубликуйте полностью код, как код, а не как картинку. Ну и ошибки.
Сейчас понять, что у вас происходит и воспроизвести в принципе невозможно из-за кастомного инклудника.

1. Любой стандартный линуксовый дистрибутив притаскивает с собой всё для полноценной работы. Винда при самостоятельной установке — голая бесполезная система (ну ок, есть браузер, солитёр и медиаплеер). На ноутбуки производители накатывают утилиты первой необходимости, но в самоустановленной win10 нет даже смотрелки фотографий. Кучу мелкого софта нужно доставлять. pdf, текстовые процессоры, архиваторы — вот этого всего на винде из коробки нет. Большая часть кодеков в 10-ке вроде бы стала прилетать самостоятельно, долгое время их тоже надо было ставить руками (угу, т.е. было так, что плеер есть, а смотреть ничего кроме wmv он толком не может).

2. Отсутствие репозиториев. MS Store — помойка. Если Google Play содержит много хлама, но там есть правильные программы, то в MS Store нет даже Steam'a, не говоря про всякие полезные утилиты тип winzip и пр. Но поиск вам, конечно, выдаст кучу китайского adware с релевантными названиями. Фактически весь софт надо искать в междусетьях, качать бинари (благо они совместимы см. пункт 5) из недостоверных источников и ставить ручками (кстати, понятие автоматической установки правильных версий зависимостей винде не знакомо), зачастую потом ручками же и обновлять. И именно этот процесс приводит к заражению виндовых машин вирусами (или как минимум adware) даже у прожжённых айтишников.
Т.е. на винде рекомендуется сначала поставить антивирь с активной защитой, и только потом можно ставить остальной софт. Почему MS до сих пор не осилила сделать нормальный магазин, я отказываюсь понимать. Этот пункт для меня является самым острым подводным камнем.

3. Драйвера. Под линухом вы легко может понять, что у вас за устройства. Но может не найти драйвера. По виндой, всё наоборот. Вы, скорее всего, найдёт драйвер, но понять, что у вас за устройства система часто не может. Хотя в 10ке вроде бы это полечили, при недавней переустановке в кое-то веке не пришлось рассказывать системе, что у меня за материнская плата.

4. В обычном режиме Администратор не имеет полного доступа к системе. Это у линуксоидов вызывает культурный шок. Чтобы получить полный доступ, нужно перезагружаться в спец. режиме (есть вроде бы альтернативный хак, как повысить себе уровень привилегий на работающей системе, но он одной мышкой точно не делается).

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

6. Винда различает порты usb. Если переткнуть устройство в другой usb, винда будет считать его новым устройством. Но это обычно мелочь, если вы не занимаетесь отладкой устройств по usb и не фиксирует буквы (ну да, у вас будут буквы вместо произвольных точек монтирования, хотя точки монтирования тоже где-то есть) для внешних дисков.

7. Линух легко читает виндовые разделы. Винда с линксовыми работает сильно хуже.

8. Сильно меньшая доступность документации по тонкой настройке системы, которая в целом тюнится так же хорошо, как линукс.

9. В линуксе вы может использовать gui и console равноправно. В винде, в общем, будет только gui. powershell достаточно удобен, но софта, работающего в консоле почти нет. В частности, при разработке, в линуксе я запускаю IDE для того, чтобы как-то улучшить разработку, в винде нормально разрабатывать можно только в IDE.

10. Sym, hard линки. Считайте, что в винде их у вас не будет. Но система будет подсовывать вам алиасы некоторых ваших директорий в некоторых ситуациях.

В питоне используется Global Interpreter Lock, и поэтому там нет эффективной параллельной многопоточности.
Питонячую многопоточность можно использовать только для организации всяких контролирующих потоков.
Для распараллеливания нужно использовать multiprocessing.

Чтение из файла не распараллеливается (по крайне мере, на одной машине, а на разных не будет потоков), так как файл не является данным со случайным доступом.
Раскидывание чтения между потоками приводит в питоне к квадратичному алгоритму, вместо линейного. Отсюда и замедление.

Я бы порекомендовал выбрать более разумную задачу для распараллеливания. И дальше начать с разбора примера

import multiprocessing 

def proc(a):
  <…>
  return something

pool = multiprocessing.Pool(3) # ну может 4. 

result = pool.map(proc, list(range(100)))

Скорее всего, не запущена служба Ext2Fsd.
Tools Menu->Service Management->Start.
Если после попытки запустить выдаётся сообщение, что could not start, то, возможно, мешает проверка подлинности драйверов. По крайне мере, у меня так было. Отключил, заработало. На свой страх и риск.

В конструкции extern "C" "C" — это не язык Cи, а способ передачи аргументов и адреса возврата.
Один и тот же язык может выдавать разный код вызова функций.
Возможность связывания определяется не языком, а тем как определена вызываемая функция и настойками компилятора.
Без специальных указаний компиляторы Cи далеко не всегда выдают для функций код, соответствующий стандарту передачи аргументов, необходимого для extern "C".

Предположения:

• оператор & не перегружен.
  
• Вывод в поток не определён для объекта .n_Name каким-то фантасмагорическим образом.
  

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

constructor_and_d_and_c::constructor_and_d_and_c(const constructor_and_d_and_c* c)

В объекте может быть несколько полей данных. Адрес первого поля и объекта обычно совпадают.

& в теле функции означает взятие адреса. Код
cout << &c;
выдаст адрес объекта.

Код
cout << &c.n_Name;
выдаст адрес поля, и, возможно, он совпадёт с адресом c.

Судя по тому, что происходит. n_Name — это адрес памяти, которая выделяется для размещения строки. Не совсем понятно, зачем так сделано, можно было сделать полем класса строку напрямую, а не адрес на неё. Но так или иначе, у переменной содержащей адрес, тоже есть адрес.
Поэтому
cout << c.n_Name;
выдаёт какой-то адрес. Но это не адрес объекта с или поля c.n_Name. Это адрес динамически выделенной памяти под строку.

n_Name = new string(*(c.n_Name));
По адресу строки с помощью * получаем объект-строку, далее создаём новую строку, адрес пишем в n_Name.

Отсутствие драйверов для wifi карты под винду.

По крайне мере, у меня переход произошёл именно так.

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

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

Вероятней всего львиную долю весят деинсталяторы обновлений в скрытых папках вида $NtUninstallKB...
И их, если не планируется делать откат, можно удалять.

mkdir -p ~/.local/bin
cd ~/.local/bin
ln -s /usr/bin/python2.7 python 
export PATH=~/.local/bin/:$PATH

Я не знаю транслита и не видел курса по нему, а английский можно выучить. (здесь я, наверное, немого лукавлю, но и программист тот вряд ли совсем уже не знает английского)

Я читаю транслит гораздо медленней, чем английский. (и это чистая правда, транслит читаю по слогам, мне проще незнакомые романские языки читать, чем транслит)

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

Названия ключевых слов и прочего в языке программирования на английском, и английские же названия переменных и функций сморятся более эстетично foreach object in list: validate(object), чем рунглиш.

# sudo apt-get install python-pycurl

или python3-pycurl вместо python-pycurl, если нужно под третью змею.

Не зная названия ВУЗа и программ, совсем точно сказать сложно, но скорей всего, если вы хотите программировать, то надо идти на прикладную математику.
При желании в этом случае программистской практики, задач, которые нужно будет решать программными средствами будет сколько угодно, кроме того будет теоретическая основа по численным методам, сложности и т.п., что важно знать для программистов, которые кодят интересные вещи.
На прикладную информатику стоит идти, если вы планируете быть аналитиком в ИТ, т.е. проектировать информационные системы, внедрять, сопровождать, оценивать, закупать ПО, руководить ;) и т.п.

Да, ведутся, прямо по коридору, направо, палата номер 6.

Пока нет никаких физических предпосылок для возможности передать вещество со скоростями сопоставимыми со скоростью света.

Передача полной информации о состояние материи человека и воссоздание этого состояния в другой точке из готовой материи требует каналов информации и энергий, каких у нас даже близко нет.

Проще мозг человека в компьютер запихнуть и забыть по тело, чем тело телепортировать.

А обязательно именно docx парсить?
Сохранить в csv и считать c помощью питоносвого csv парсера не будет быстрей?