Это вторая и последняя часть моей шпаргалки по аббревиатурам, которые стоит знать C++ разработчику. С++ здесь упомянут только потому, что шпаргалку я составил в первую очередь для себя, а я как раз-таки C++ разработчик.

На самом деле в этой части собраны понятия, область применения которых не ограничена C++. Так что подборка может быть интересна более широкой аудитории.

Когда-то я собеседовался на должность C++ разработчика в одну приличную и даже известную контору. Опыт у меня тогда уже кое-какой был, я даже назывался ведущим разработчиком у тогдашнего своего работодателя. Но на вопросы о том, знаком ли я такими вещами, как DRY, KISS, YAGNI, NIH, раз за разом мне приходилось отвечать «Нет».

Собеседование я с треском провалил, конечно. Но упомянутые аббревиатуры потом загуглил и запомнил. По мере чтения тематических статей и книг, подготовок к собеседованиям и просто общения с коллегами я узнавал больше новых вещей, забывал их, снова гуглил и разбирался. Пару месяцев назад кто-то из коллег небрежно упомянул в рабочем чате IIFE в контексте C++. Я, как тот дед в анекдоте, чуть с печки не свалился и опять полез в гугл.

В 2017-2018 годах я искал работу в Европе и нашел в Нидерландах (про это можно прочитать здесь). Летом 2018-го мы с женой постепенно перебрались из Подмосковья в пригород Эйндховена и более-менее обустроились там (это описано здесь).



С тех пор прошел год. С одной стороны — немного, а другой — достаточно, чтобы поделиться своими опытом и наблюдениями. Делюсь под катом.

Ружье Бондарчука Ипотека все еще есть, но я про нее ничего не расскажу :)

Итак, за примерно год (май 2017 — февраль 2018) я, программист C++, нашел-таки работу в Европе. Я десятки раз откликался на вакансии в Англии, Ирландии, Швеции, Нидерландах и даже в Португалии. Я раз двадцать беседовал по телефону, скайпу и прочим системам видео связи с рекрутерами, и несколько меньше — с техническими специалистами. Я ездил в Осло, в Эйндховен и три раза в Лондон на финальные интервью. Все это подробно описано здесь. В итоге я получил один оффер и принял его.



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

Но всегда можно самому себе создать сложности. Что я и сделал, чем затянул свой переезд еще на месяц. Если интересно почитать о хлопотах (нет, не сильно приятных) связанных с переездом IT семьи в Западную Европу — добро пожаловать под кат.

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



В общем, если вам интересен рассказ о том, как C++ программист из Подмосковья искал работу в Европе, желательно в Великобритании, а нашел-таки в Нидерландах, переехал туда сам и привез жену, все это с непогашенной ипотекой в России и с небольшими приключениями — добро пожаловать под кат.

Вообще я C++ программист. Ну так получилось. Подавляющее большинство коммерческого кода, который я написал за свою карьеру, — это именно C++. Мне не очень нравится такой сильный перекос моего личного опыта в сторону одного языка, и я стараюсь не упускать возможности написать что-нибудь на другом языке. И мой текущий работодатель внезапно такую возможность предоставил: я взялся сделать одну не самую тривиальную утилиту на Java. Выбор языка реализации был сделан по историческим причинам, да я и не возражал. Java так Java, чем менее мне знакомо — тем лучше.

Помимо прочего возникла у меня довольно простая задача: единожды сформировать некий набор логически связанных данных и передать его некоему потребителю. Потребителей может быть несколько, и согласно принципу инкапсуляции передающий код (производитель) понятия не имеет, что там внутри и что оно может сделать с исходными данными. Но производителю надо, чтобы каждый потребитель получил одни и те же данные. Делать копии и отдавать их мне не хотелось. Значит, надо как-то лишить потребителей возможности изменять переданные им данные.

Началось все, как водится, с ошибки. Я первый раз работал с Java Native Interface и делал в C++ части обертку над функцией, создающей Java объект. Эта функция — CallVoidMethod — вариативна, т.е. помимо указателя на среду JNI, указателя на тип создаваемого объекта и идентификатора вызываемого метода (в данном случае конструктора), она принимает произвольное число других аргументов. Что логично, т.к. эти другие аргументы передаются вызываемому методу на стороне Java, а методы могут быть разные, с разным числом аргументов любых типов.

Соответственно и свою обертку я тоже сделал вариативной. Для передачи произвольного числа аргументов в CallVoidMethod использовал va_list, потому что по-другому в данном случае никак. Да, так и отправил va_list в CallVoidMethod. И уронил JVM банальным segmentation fault.

За 2 часа я успел перепробовать несколько версий JVM, от 8-ой до 11-ой, потому что: во-первых это мой первый опыт с JVM, и в этом вопросе я StackOverflow доверял больше, чем себе, а во-вторых кто-то на StackOverflow посоветовал в таком случае использовать не OpenJDK, а OracleJDK, и не 8, а 10. И лишь потом я наконец заметил, что помимо вариативной CallVoidMethod есть CallVoidMethodV, которая произвольное число аргументов принимает через va_list.

Что мне больше всего не понравилось в этой истории, так это то, что я не сразу заметил разницу между эллипсисом (многоточием) и va_list. А заметив, не смог объяснить себе, в чем принципиальное отличие. Значит, надо разобраться и с эллипсисом, и с va_list, и (поскольку речь все-таки о C++) с вариативными шаблонами.