×Закрыть

Что нужно знать для собеседования на junior C++?

Я учусь в универе, но хочу подучить и уже через полгода-год идти работать. Что мне нужно в первую очередь выучить? Я посмотрела ваканции и такой список создала:Memory management, STL, Multithreading, Software Architecture Design and 3D math. Но я не совсем понимаю что именно нужно например знать под: Memory management или 3D math и т.д.

Буду рада если Вы мне по подробнее раскажете что именно нужно под каждым этим значением.

Всем мир

LinkedIn

Лучшие комментарии пропустить

Тут надо тебе выбирать направление.
Если на галеры, то списки требуемого есть в интернеде. ГА, ТВ и эмбедед там не нужны, но за задолбают O сложность STL, и т.п. бредом с наследованиями, шаблонами.
Если нравиться математика, то в первую очередь требования именно к требуемой математике. Нынче большей частью МЛ, ГА, ТВ, ЦОС, знание языка быстрого прототипирования Питон, Матлав, R (одного из них достаточно) и умения С с классами, чтобы твой код был на С++ достаточно быстр, прост и лаконичен. Очень часто через некоторое время его передают в саппорт чистым программистам.
Если железо, то тут вообще рулит С и иногда С с классами и знания и умения собственно железа и его особенностей. Дрова здесь же, но со знанием внутренностей операционок.

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

Studied Соціологія

А чего вдруг С++ то?

Для того, чтобы пройти собеседование на Junior C++, достаточно зайти на cppquiz.org и решить там все вопросы. Этого будет достаточно, чтобы понять, что C++ — это плохой язык, это неудобный язык, и это язык, который заставляет тратить время на борьбу с ним вместо решения бизнес-задач. После этого можно будет бросить эту затею и начать учить Java.
Но насчёт собеседования я серьёзно — если вы на cppquiz сможете решать задачи среднего уровня (помеченные жёлтеньким), то собеседование вы, скорее всего, пройдёте. Насчёт пунктов, выписанных вами, можете не переживать — это продукт буйной фантазии рекрутеров, на который обращать внимания не стоит. Ни один интервьювер в здравом уме не станет просить джуна пояснить за программную архитектуру.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Уметь ответить на вопрос «Что Вы можете рассказать о printf и cout ?»

Немногим менее года назад эта тема была создана. Теперь время спросить об успехах. Удалось пройти собеседования и устроиться на работу?

так пройшла, але не в ту компанію до якої тоді готувалася) але зрозуміла що мені цікавий гейм дев, тепер UE розбираю

Чтением этого топика навеяно. Как правильно вводить джуна в С++.
1. Читать что-нибудь по Core Java для твердого понимания OOP/D (кстати что ?). Опционально Сэджвика для алгоритмов.
2. Читать Керинигана-Ричи для твердого понимания указателей, адресной арифметики и жизненного цикла динамической памяти.
3. Утвердившемуся в вере неофиту аккуратно скормить виртуальные конструкторы, RTTI, списки инициализации и прочее С++специфичное.

Годится за основу, но надо добавить четвёртый пункт — Rake fields forever (целочисленные переполнения, нарушения алиасинга, и так далее).

Как правильно вводить джуна в С++. 1. Читать что-нибудь по Core Java

Ндаа... симптоматично.
Поздно пить боржоми: потенційний С++ junior після прочитання коментів під даним топіком буде обходити С++ десятою дорогою. :)

И в целом правильно делать :)

яка цьому розумная альтернатіва? ©

так и запишем: для программирования в русте не нужно ничего знать

сідай, Вововча, двійка.
руст альтернатива хрестам.
про те що знать і не знать, для овладєнія рустом, мова не йшла

Вот чим овладівать для хрестов, якщо це разні мови в руслє до 03, 11, 14..17 і 20+ стандарта.

вы всегда с середины читаете?

смотря який контейнер, ДОУ контейнер читаю із послєднєй подсвєченной мєткі (тіпа новоє)

ДОУ контейнер читаю із послєднєй подсвєченной мєткі

заметно

для программирования в русте не нужно ничего знать

така альтенатива теж є — це Go!

теперь их двое и сестра их — Жабба Скрипт

почитав комменти знизу, згадав, як оце я пару місяців тому писав фідбек на розбирання у існуючому коді

цитата

по факту — згадав, чого я не любив C++ у Львові, і всю ту братію, яка на співбесідах
питала про віртуальні деструктори з конструкторами і прочєє, що до
програмування не має відношення
у них дуже специфічний задротістий моцк, і програми такі ж виходять
дуже довго розбирався в існуючому коді, котрий має тучу класів, має обробляти всі випадки на всьому світі і в космосі теж

топик детектор неосиляторов

перечитайте ще раз мій пост в цілому

ану поясни что для тебя программирование?

Книжка була така
Алгоритмы + Структуры данных = Программы

Саме по цьому і ганяють на співбесідах у Долині, ніхто не питає тих дурниць з віртуальною задротістою мурою, яка не має ніякого відношення до 2-х складників.
Книжка по алгоритмам + задрочування Cracking the coding interview + практика на leetcode.com, і НІДЕ у цьому шляху не потрібно тих ужасів C++.

Забув сказати, що мій початковий коммент про нелюбов до C+±ної братії у Львові стосувався ще 90-х — початку 2000-х.

а виртуальный деструктор это тебе не структура данных?

захожу на
discuss.leetcode.com/...​ave-different-return-type
и шо, хоть и Java но точно такая задротистая мура есть и на C++

а виртуальный деструктор это тебе не структура данных?

Просвещайся. ru.wikipedia.org/wiki/Структура_данных

тоесть указатель на список указателей на функцию не структура данных?
ну ок. все понятно.

ну тогда я бы посоветовал удалит компилятор со своего компа

Чем хороши советы, что на советы подобных тебе следует игнорировать.

Вообщето у статических классов, есть просто список указателей на функции которые называются деструкторы. Простенькая прога на ассемблере после выхода из «маин» просто пробегается по списку, вызывая каждый.

хотелось бы поподробнее услышать про «статические классы» да и вообще про инициализацию/деинициализацию

Скорее всего имелось виду статический объект.

Да. Который не через new а просто описывался. (в терминологии я ноль, поскольку сам всему учился).

обычный пример поверхностных знаний, услышалось указатель на функцию, совпало с каким то обрывком знаний про atexit и ответ готов, а то что static в этой ветке никак не упоминается не имеет значения

Ты прекрасно понял, что речь идет о статически созданном объекте, но не мог не блеснуть соплей на солнце. Очень типичное поведение С++ начетчика, которому замороченная терминология намного важнее сути дела.

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

кстати оба почему то looking for relocate

да суть тут понятна, пришли в топик два луддита которые не способны осилить абстракции

Которые этой хренью в свое время увлекались, но переросли.

кстати оба почему то looking for relocate

Именно потому. От нежелания копаться в пахучем творчестве любителей сложных абстракций.

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

В ДВС ничего лишнего. Например долнительных ремней ГРМ и клапанов в неожиданных местах.
С++ — эталон оверинжиниринга, или как метко выразился Кнут — «бароччный язык».

окна в квартире лишние, можно и без них, в пещере же не было

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

а еще про сегменты памяти процесса

это как это «прога» пробегается после выхода из «мэйн»?

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

Нет ничего плохого в том, чтобы не осиливать C++. До недавнего времени осилить C++ не могли даже разработчики компиляторов C++.

Що складного в віртуальних деструкторах і іншій лабуді (за умови адекватного її використання)?

перечитайте ще раз мій пост в цілому

К программированию не имеет отношения да. А вот к программированию на С++ имеет и очень большое. Потому что можно пару дней потратить в попытках понять почему работает неправильно код и только потом случайно обнаружить, что оказывается члены класса инициализируются в том порядке в котором они объявлены, а не в том в котором ты указал в конструкторе в списке инициализации. И это при условии что можно быстро локализировать проблему.

Списки инициализации размером с небольшую заметку в газете — еще один повод задуматься, все ли в консерватории в порядке.

во первых — ц++11
во вторых — «можно этого и не делать...если вас не интересует результат» (ц)

Не 11. В 98/03 тоже был этот подводный камень с порядком инициализации полей класса.

Я б не сказал, что это такой подводный камень.
Есть правило — инициализация полей класса проходит в порядки их объявления в классе, а не в списке инициализации

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

Ви дуже добре думаєте про середньостатичного джуна.

Не згоден. По-моєму, навпаки: багато хто з тих, хто вже сам давно не джун, почав забувати, що означає це поняття.

Джун — повноцінний спеціаліст, який хоч ще і не має достатнього досвіду в серйозному програмуванні, може не дуже добре розуміти предметну область, специфіку роботи в команді та інші важливі речі, проте технології (а особливо основи мови програмування, що використовується на проекті) він вже знає достатньо добре.
Інакше це не джун, а трейні.

Що у джуна питати на співбесіді? «Які проблеми ви вирішували на попередній роботі, з якими труднощами стикалися, які ваші досягнення» і т.д. питати особливого сенсу немає — навряд чи там було щось серйозне. Тому зазвичай саме джунів більше всього ганяють по основам мови програмування, щоб переконатися, що принаймні з цим у нього проблем не буде і дурні запитання будуть виникати вже по проекту, а не по технологіях, про які і так купа інфи доступна у різних джерелах.

Конкретно про дану особливість C++ (конструктори нестатичних полів класу викликаються в порядку оголошення цих полів у класі, а не в порядку їх згадування у списку ініціалізації) чудово розписано у книжках. Точно не згадаю, чи то у Майєрса, чи у Саттера-Александреску, але 100% було. З порадою ніколи не порушувати оригінальний порядок у списках ініціалізації.
Плюс, компіляторам досить легко побачити таке порушення у коді і зазвичай вони видають ворнінг, коли помічають подібну фігню.

достаточно просто на ворнинги обращать внимание

А можно пруф? А то я читал обе версии и чтобы не морочить себе голову, тупо инициализирую все явно в конструкторе.

Спасибо. Писал больше 20 лет, в том числе и на плюсах, умудрился эти грабли обойти.
А нахрена вообще это придумали?
Сложно запретить
A(int x) : b(x), a(b) {}
Почему не писать явно
A(int x)
{
b = x;
a = b;
}
У меня с такой записью проблем никогда не было. Страуструп стадал сложной формой мазохизма? Может он был коммунистом?

Ну тогда как инициализировать ссылку либо константный указатель?
Тем более, если присваивать значения в теле конструктора, то это менее эффективно, по сколько у нас сперва вызовется default c-tor для поля, а потом наша операция присвоения.

Проблем со ссылкой не вижу. Или this в конструкторе отменили?
И уже прочитал. Что new работает не как malloc а как calloc. Коммунистом был страуструп.

Что нам даст this?
И тем более что список инициализации вызывает конструктора по умолчанию, а у ссылок их нет.
Так что кроме списка инициализации инициализировать их нельзя

this дает указатель на класс, для которого только что память выделели.
Остальное не понял: у конструктора есть ссылка хотя бы на самого себя.

кстати вспомнил еще вопрос любят на собеседования спрашивать, что такое ссылка и чем она отличается от указателя?

Уж скажите мне, убогому, чем оно отличается.

При чём здесь this, не очень понятно.
Вот проблема, о которой шла речь:

class Y;

class X
{
private:
Y & ref_y;

public:
X(Y & ref_y_arg) // ???
};

Что нужно написать на месте «???», чтобы проинициализировать ссылку this->ref_y значением ссылки ref_y_arg?
Здесь нужна именно инициализация. Запись ref_y = ref_y_arg в теле конструктора попытается вызвать присваивание одного объекта Y другому, а не присваивание ссылок. Ссылки в C++ в принципе нельзя изменять после создания.

А new работает как new. Похоже это больше на malloc или на calloc — вопрос философский.
Оператор new выделяет правильно выровненный кусок динамической памяти нужного размера для создания объекта требуемого типа, а затем вызывает конструктор этого объекта на этом участке памяти.

malloc или calloc работают совершенно по разному.

Можно поподробнее для тех, кто с чистыми сями работал мало?
Я знаю только то, что malloc не модифицирует содержимое буфера, предоставляя эту заботу программисту, а calloc забивает все биты нулями.
В этом плане первый этап работы оператора new больше похож как раз на malloc. Потому что никаких гарантий забивания нулями эта аллокация не даёт. Зачем, если потом сразу же вызовется конструктор и всё (или почти всё) перетрёт? Лишняя работа же.

Хотя если вы не о классах, а об использовании оператора new для примитивных типов, то да, там есть тонкости: stackoverflow.com/...​nitializes-memory-to-zero

Подробности — для примера чисто прикладные: malloc отработает быстро. calloc может отправить систему в нокдаун и последующий ребут на пол часа.

Да ничего не писать. написать

Y *ref_y;
...

{ и дальше ref_y = ref_y_arg;

Это решит одну проблему, но породит другие. Указатель вместо ссылки будет вызывать ряд вопросов: владеющий он, невладеющий? а если владеющий, то как именно ресурс нужно освобождать в конце? ссылается он на один объект или на массив объектов? если на массив, каков его размер? может ли этот указатель быть нулевым или нет? может ли адрес Y изменяться за время жизни текущего объекта X?

Со ссылкой же всё однозначно (если программист не совсем уж извращенец), а именно: это невладеющая ссылка на единственный объект, не нулевая, её адрес после инициализации измениться не может.

Кроме того, ссылки и const-члены класса — только один пример. Другой из той же оперы: члены класса, которые не имеют default конструктора и обязаны принять какие-то параметры во время создания.
И сюда же необходимость передать аргументы из конструктора производного класса в конструктор базового.

Так что списки инициализации нужны. Да, иногда без них можно обойтись. Иногда нет. Всё зависит от проекта, команды и т.д.
И они не такие страшные, учитывая, что если программист перепутает порядок — любой уважающий себя компилятор сразу выдаст ворнинг на этот счёт.
(Ну, а кто компилит C++ код с минимальным уровнем ворнингов или не читает их, ССЗБ.)

Я вот читаю и одного не понимаю — как люди умудрились наисать linux kernel и nginx, ничего не зная о владеющих указателях и списках инициализации?

Ядро можно и на бреинфаке с асмовыми вставками написать, это не проблема вообще

А как ты на бреинфаке асм вставку сделаешь?

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

Зато я бы посмотрел, как

не зная о владеющих указателях и списках инициализации

люди писали бы фотошоп или какой-нибудь хром.

какой-нибудь хром.

Что не поленились и изобрели Go :)

Вот так и написали — с соответствующими ошибками. Контроль в целом за ядром, конечно, качественный, но в каждом втором редко используемом драйвере оно как минимум «течёт», теряя выделенную память. Всякие use-after-free тоже бывают, статический анализ одно время находил их сотнями. И другие аналогичные ошибки.

А уж сколько было крика по поводу новых GCC с их агрессивными оптимизациями, которые реализовывали undefined behavior там, где раньше было всё типа нормально... сейчас этот период кончился, но было такое, что явно посылали нафиг при любых проблемах работы после GCC 4.4, мол, «мы не всё ещё вычистили». И сейчас сборка обязательно идёт с -fno-strict-aliasing.

И те же владеющие указатели плохо совместимы с некоторыми нынешними специфичными для ядра техниками, как RCU... Rustʼовский народ только-только основные приёмы освоил для простейших случаев (работая в этой проблеме, как ледокол в арктических льдах).

Nginx, кстати, внутри на порядки проще. Там основные проблемы были написать быструю логику работы с HTTP и отработки конфига, а с памятью проблемы далеко не первые.

если raw pointer то однозначно не владеющий, иначе unique_ptr

В идеальном мире да. И сейчас обычно стараются так и писать. Но если проекту много лет, то в легаси-коде часто можно наткнуться на владеющие raw pointer’ы, увы. И отрефакторить такие куски в приемлемые сроки не всегда представляется возможным.

Да, да, команда из однодумцев и без мозговых онанистов. Проект без воплей быстрее, надо было уже вчера. ТЗ не меняется когда уже все сделано. Когда половина разработчиков не увольняется под вопли «вы тут все больные».
Плюсы — для сферической разработки в вакууме. Из личного опыта, кастрированные плюсы в том виде как их увидели создатели QT позволяют пережить «все пропало, гипс снимают». А вот MOTIF не доживает и до попытки релиза.

Обожаю, когда ниасиляторы опускаются до заявлений о «безмозглом онанизме». Как будто знание некоторых нюансов языка, о которых и так на каждом заборе написано, делает человека безмозглым онанистом, сосредоточенным исключительно на дроче тёмных закоулков C++ и неспособным решать прикладные задачи, непосредственно связанные с проектом.
Это смешно. Разобраться в мало-мальски серьёзном проекте (независимо от направления: эмбеддед, десктоп, геймдев или что-то другое) обычно занимает месяцы даже у опытного программиста. А почитать пару книжек Майерса и послушать несколько докладов о хорошем стиле кодинга на C++ с каких-нибудь CppCon можно за пару недель — и с тех пор «грабли» и «подводные камни» не будут казаться таковыми. Было бы желание. Мозгов-то хватит, если человек в принципе смог стать программистом.

Да что ты к онанизму прицепился? Последняя отдушина же.

Если работа идет на процесс, то онанировать можно сколько угодно. А если на результат, то тут уже стоит подумать, а насколько годятся плюсы для современных реалий.

При чём тут мазохизм?
b = x;
это присваивание, а не инициализация. Совершенно разные вещи, которые в некоторых случаях могут дать один результат, а в других нет.

Согласен. Стоит оно тех граблей?

Зависит от проекта, команды и всего остального.
Не нужна возможность инициализировать поля или базовые классы — её можно не использовать, обходясь присваиваниями в теле конструктора. А в некоторых проектах такой возможности может быть тяжко.

Есть определенная иерархия.
Есть языки низкого уровня. Есть высокого.
С, Ассемблер — низкого. И они уже афигенно сложные, потому что приходится понимать архитектуру, как работают разные кеши итд. Каким боком тут плюсы? Он и не низкого и не высокого. Это смесь танка, таврии и феррари.

Всё относительно. Си по сравнению с ассемблером очень даже высокого уровня. Хотя да, на фоне всяких C# или Java определённо язык достаточно низкоуровневый.

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

Так что

Он и не низкого и не высокого.

я бы сказал, что он и низкого, и высокого. Смотря как использовать.
А вот уже как его будут исползьовать — зависит от специфики проекта, квалификации команды, принятого кодстайла и прочих факторов.

Нет. Си и Асм, одного поля ягоды. Разница в одном в асм ты сам пишешь, а в Си — приходится смотреть что компилер нагенерит и править исходники чтобы он нагенерил то что нада.
Джава, Шарп, Го — языки высокого уровня: не нужно думать сколько бит в байте, как работают кеши, как байты памяти расположены, сколько процессоров в системе итд.
Плюсы — уродец. В плане комерческого программизма это лютый свиздец — невозможно разделить ответственности.

Если у вас на проектах

лютый свиздец

и

невозможно разделить ответственности

— задумайтесь, кто в этом виноват. Может всё-таки не скамейка? (bash.im/quote/418579)

Джава, Шарп, Го — языки высокого уровня: не нужно думать сколько бит в байте, как работают кеши, как байты памяти расположены, сколько процессоров в системе итд.

Плюсы тоже, если на них писать определённым образом. Выше уже сказал.

Плюсы — уродец

Распространённое отношение к плюсам в некоторых кругах. Не скажу, что разделяю его.
Но и спорить здесь не о чем, чувство прекрасного — слишком субъективная штука.

Во-во. В машине два водилы. Оба отвечают И за газ И за тормоз. Как распознать в морге кто напортачил?

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

С, сферический в вакууме — простой. И ассемблер, сферический в вакууме — тоже. А вот как доходит до железа, вот и наступает «ой».

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

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

Попробуйте хоть немного посмотреть Го. Там тупо убрали все те «фичи» что позволяют этот весь онанизм.

смотрели, спасибо. Го деградация

Углом опережения зажигания на автомобиле вы тоже до сих пор вручную рулите? Я предпочитаю думать о работе. За рулем это второе по продуктивности место после сортира.

Если уж пошли в ход автомобильные аналогии, то это скорее не управление

Углом опережения зажигания

, а ручное переключение передач.
Многие водители и по сей день предпочитают ездить на механике и им это не особо мешает.

а ручное переключение передач.

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

Но там где нужен результат, к приеру в формуле-1, механики нет уже давно.

проблема в том что в го угол опережения зажигания прибит гвоздями ровно так как надо одной корпорации

Вообще-то им компьютер рулит. А раньше был рычажок. Кажись на руле. И водила должен был им рулить.

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

А в первой записи вы напрямую создаете объекты с нужным значением.

ideone.com/GvAqPF

Но в первой грабли, во второй — нет.

грабли для тех кто за годы «программирования» на крестах не поинтересовался как правильно и спрашивает пруфов на форуме

Я просто не использую то, где потенциально могут быть грабли.

Во введении любой фичи типа «сделаем свободнее» есть проблема, что её начнут абьюзить и потребуют ещё больше свободы.
Например, инициализация элементов в любом порядке? А как насчёт её гарантии?
Вот вы в конструкторе записали явное присвоение. А если будет код вида

A::A(int x) {
  if (одно сложное условие) {
    b = x; a = b;
  }
  if (другое сложное условие) {
    b = x+10; a = x-10;
  }
  if (третье сложное условие) {
    b = x*2; a = x/2;
  }
}

а теперь как проверить, что хоть какая-то инициализация выполняется?

Отдельные компиляторы могли бы дать поблажку в определении условий. Но их авторам тоже облом :)

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

KISS

Ну вот авторы языка так и подходят к вопросу.

А в результате — с примитивными типами особых проблем нет — в крайнем случае уже после превращения в SSA, компилятор поймёт, что инициализация до входа в тело конструктора не нужна — а вот если поле типа со сложным поведением, могут начаться пляски типа предварительной инициализации в корректное, но мёртвое состояние, и последующим реальным оживлением. Как в сказке с двумя типами магической воды.

Идея проверить условия и вызвать конструктор с разными аргументами в голову не приходит?
А то знаете ли не все условия могут быть учтены и согласно заветам вождей придется всталять в конструктор try-catch блок :)

Идея проверить условия и вызвать конструктор с разными аргументами в голову не приходит?

Приходит, и отвергается. Потому что если создаётся объект не по указателю через new, а другими способами, которые создают объект напрямую (да хоть как поле другого объекта) — у тебя такой свободы нет, язык не позволяет.
И если уж ведём разговор в таком стиле — ты сам должен был об этом догадаться ;)

и согласно заветам вождей придется всталять в конструктор try-catch блок :)

try-catch-то тут при чём?

не по указателю через new, а другими способами,

Что мешает создать объект другим способом в блоке if-else?
Создание его в конструкторе другого объекта и зависимость от других полей? Тогда почему бы не создать этот объект на уровень выше и передать, как один из аргументов, а те самые другие поля не передавать? Kiiiiisss

try-catch-то тут при чём?

Ну а как еще в С++ кошерно проверить условие?

 
try {
if (одно сложное условие) {
    b = x; a = b;
  }
  if (другое сложное условие) {
    b = x+10; a = x-10;
  }
  if (третье сложное условие) {
    b = x*2; a = x/2;
  }
 throw <лень проверить>
} 
Тогда почему бы не создать этот объект на уровень выше и передать, как один из аргументов, а те самые другие поля не передавать? Kiiiiisss

Грубое нарушение инкапсуляции и выставление потрохов реализации наружу с тем, чтобы вызвавший мучался (говоря цензурно) с ними? Это никак не KISS, это наоборот.

throw <лень проверить>

Это несерьёзно. Чуть более сложные условия — и твой throw будет просто не на чем запустить.

Мы или требуем гарантии инициализации всех полей и предков от компилятора, или возлагаем это на программиста.
Второй путь тоже встречается (Python). Но первый видим таки чаще (C++, Java, C#, и иже с ними).

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

Грубое нарушение инкапсуляции и выставление потрохов реализации наружу

Если внутренний объект изначально зависит от каких-то внешних условий значит никакой он не внутренний.

Он именно что внутренний. Логика трансляции внешних данных в реализацию — личное дело объекта, в котором это происходит, и не внешним силам это решать.

И если будет 2 (20) разных форматов внешних данных — обьект будет знать о них всех?
Вместо того, чтобы знать о 1 формате, и иметь (Конвертер), который будет уметь этот формат готовить из любых внешних данных.

Теперь притянули за уши какие-то 20 форматов внешних данных, о которых речь не шла в принципе.

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

Если кроме этого требуется принятие еще каких-то решений, значит де-факто там больше одной сущности

Не вижу оснований к такому выводу.

и кто-то наскосячил с абстракцией.

Или реальность оказалась сложнее песочных мечтаний.

Или реальность оказалась сложнее песочных мечтаний.

Реальность оказалась такова, что по настоящему крупных проектов на крестах так и не написали. Либо plain old C, либо переписали все к чертям собачим на Джаве и Решетках.
Именно потому, что вместо того, чтобы поставить защиту от дурака, как это делает любой нормальный инструмент, ему заботливо создают поводы проявить инициативу.

Реальность оказалась такова, что по настоящему крупных проектов на крестах так и не написали.

Слишком толсто, попробуйте тоньше

Блистательная аргументация. Впрочем, как всегда.

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

Аргументация на том же уровне, что и у вас в этом заявлении.

Реальность оказалась такова, что по настоящему крупных проектов на крестах так и не написали.

Тем более, что оно явно ложное.
Фотошоп и другие продукты Adobe не считаются крупными проектами? Хром, фаерфокс и прочие браузеры? MySQL? Autodesk Maya, 3ds Max и прочие софтины для работы с 3D модельками и анимациями? Практически все серьёзные движки AAA-игр?
Ну не знаю. Может, вы и правда работаете на проекте более крупном, чем это всё, и он написан не на крестах. Но это всё ещё не повод для настолько громких заявлений.

Редко перескаюсь с Виндовс миром, могу ошибаться, но когда последний раз устанавливал Фотошоп он попросил у меня NET-фреймворк. Такое же впечатление оставляют и остальные десктопные программы, чьи предыдущие версии делались на VC++.
Игры — да, но не будем же мы их считать примерами настоящего индустриального программирования.

Игры — да, но не будем же мы их считать примерами настоящего индустриального программирования.

Почему?
И почему Файрфокс или Вебкит не считаются по-настоящему крупными проектами?

Скучный Си-с-классами. Никакого тебе «Войны и мира» в конструкторе, шаблонов трехкратной вложенности, зоопарка автопоинтеров и прочих пацанских штучек.
Короче ниасиляторы писали.
github.com/...​ntainerNodeAlgorithms.cpp

Ажно целый файл. Долго искали?

«Папа, а де море?»
Він просто у вашому файлі ж і є. І використовується рівно як казали dou.ua/...​rums/topic/22551/#1249697 у файлі поруч з «вашим» github.com/...​ore/dom/ChildNodeList.cpp наприклад.

Конечно, какие-то места фотошопа (по большей части относящиеся к GUI) могут быть написаны на .NET, не спорю. Но логика там реализована на плюсах.
Sean Parent часто выступает на всяких конференциях, где рассказывает о хороших практиках в современном C++ и подходах, которые они использовали в том числе в реализации фотошопа. До «скучного Си с классами» там ой как далеко.
Здесь, например, показан интересный подход к реализации Undo/Redo операций через shared pointer to const, который они применили в фотошопе: www.youtube.com/watch?v=bIhUE5uUFOA

Реальность оказалась такова, что по настоящему крупных проектов на крестах так и не написали.

Ну почему же? Если тебе не встречались, то это не говорит о том, что их нет. Рейтер вон всю свою фин.математику еще 10 лет назад на плюсы с С перевел, а система у них для финансистов ну совсем не маленькая. Если о либах, то все движки распознавания и синтеза речи на плюсах, аднака, — тоже не простые штуки.
Но в эмбедед плюсы часто не нужны просто, в дровах тоже.

Но вот где плюсам не место — это в гуях, но NET работает только под виндой, а жаба крива, до сих пор не научилась работать с 4k мониторами в линухе. Так что пока кросплатформенный гуй можно только на Qt сделать.

а жаба крива, до сих пор не научилась работать с 4k мониторами в линухе

Хм, а в чём тут проблема собственно Java?
Или какое-то хардкодед ограничение в Swing?

Как в линухе лдя всех жаба приложений поменять размер шрифта. Объяснить, что у меня не 96 DPI, а больше.
GTK, Qt без проблем умеют.
Рылся в инете, но пути не нашел.

И чем мне это поможет?
Матлаб тянет с собой жабу. А переключение его на OpenJDK или другой всегда с подводными камешками.
Лучше бы был какой конфиг для жабы где, чтобы я мог там указать ей DPI.

Наскільки бачу, матлаб з собою фактично OpenJDK і тягне.
wiki.archlinux.org/index.php/Matlab#Java
P.S.
Всі вендори, в т.ч. і Oracle, за основу беруть OpenJDK (+ додають щось своє).

Только не OpenJDK, а Oracle и в виде jar файлов и файлика swing.properties я там не нашел.
А эту ссылку я читал. Там ничего про это нет, но есть вот такое
undocumentedmatlab.com/...​ying-matlab-look-and-feel
Но DPI не меняется.
Или подскажи жаба команду, чтобы его поменять для приложения.

Additionally, any Java applications that use the GTK look&feel style may automatically benefit from the support of HiDPI in the GTK library while the size of the window and other components may match the GTK components which have been enlarged by 2-3x to satisfy the HiDPI requirements.
Де там в матлаб аргументи ком.рядка прописуютья?:
-swing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel

Я это пробовал, но DPI не отрабатывает. Я могу поменять тему, но как шрифт, а еще лучше, как его заставить понять, что у меня не 96 DPI.

Не знаю, дядьку. Кажу ж — попробуй поставити додатково інший JDK, і поміняти шляхи в змінних оточення.
Ну або далі експериментуй: от, GDK_SCALE=2 в .xprofile і т.п. geektimes.ru/post/288030
P.S.
Може, простіше монітор в FullHD переводити при роботі з матлаб ?

Ну почему же? Если тебе не встречались, то это не говорит о том, что их нет. Рейтер вон всю свою фин.математику еще 10 лет назад на плюсы с С перевел

Нет. Я имею в виду Well-known коробочный или серверный софт.
То, что конечно какие-то отдельные сервисы или библиотеки для скоростной обработки данных наисаны на плюсах сомнений не вызывает. Но во-первых их скоуп ограничен, а во вторых их стиль написания огорчит адептов построения маленьких вселенных в конструкторах и деструкторах.

Но в эмбедед плюсы часто не нужны просто, в дровах тоже.

За такое увольняют.

Но вот где плюсам не место — это в гуях,

Еще как место. Окошечная система идеально ложиться на ООП.
Совершенно не зря С++ был королем десктопа в эпоху ранних Windows.

За такое увольняют.

Ну, хз. У меня небольшой опыт в ембедеде. Но плюсов там небыло.
Промышленные датчики для заводов.
Писали код на:
Си, питоне, джаве, скале, ассемблере, ну и на специфичной ноунейм DSL-ине.
С++ небыло ни в каком виде.

Промышленные датчики для заводов.
Писали код на: скале

А вот с этого места подробнее — чертовски интересно.

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

Прикольно. Была подобная задача — сделал через демон на С, который общался с бизнес-логикой на Java через unix-сокет.
По трезвому размышлению этотот случай, где хорошо бы легла boost::asio, но тогда не было времени на эксперименты.
Но скала тоже интересный вариант, спасибо.

интересный вариант

Я впечатлен глубиной мысли, которую вы вложили в эти слова.

Мир разработки — это мир принятия неправильный (неоптимальных) решений, которые решают задачи в условиях неопределенности, нехватки ресурсов, знаний, времени.
И драйвера на скале — не самое ужастное решение, принятое в условии ограниченного времени и ресурсов, которое я видел:)

И драйвера на скале — не самое ужастное решение

А почему сразу ужасное? Вероятно какие-то плюсы в этом были.

Вот у берклевцев замена Verilog на Скале.

Я имею в виду Well-known коробочный или серверный софт.

Это и был серверный софт, причем крутился на туевой хуче серверов с разными осями (солярис, ibm какой-то осью, виндой и редхатом).
Ты просто не представляешь, что такое Рейтер и знаешь их только по новостям, а это хорошо если 1% их бизнеса.

их стиль написания

Стиль был определен Скоттом Майерсом и на мой вопрос моему начальники, почему тут так странно сделано было в одном месте, он дал мне мыло Скотта и сказал общайся с ним.

Кстати у нас на предидущей работе один студент Майерса начитался и начал ему письма строчить.

«сигнал посылаем — вы шо ето там?
а нас посылают обратно» ©

А можно пруф?
12.6.2 Initializing bases and members [class.base.init]
Then, non-static data members are initialized in the order they were declared in the class definition
(again regardless of the order of the mem-initializers).
тупо инициализирую все явно в конструкторе

в теле конструктора?

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

давай усложним:
class A
{
A() = delete;
A(int, int) {}
}
class B
{
B(/*some args*/);
A a;
}
как написать конструктор для B?

речь шла про инициализаторы в хидере

очень опасная практика ориентироваться на порядок инициализации в конструкторе.

Вотя про это и говорю, что для программирования на плюсах просто необходимо знать все эти особенности. Поэтому их спрашивать нужно на собеседованиях

В С++ столько способов поотсреливать себя яйца, что спрашивать уже бессмысленно подобное. И последние компиляторы про это тебе сообщают, типа «ты чё, очень умный?»
Вот тебе ситуация. А последние несколько лет не использовал static, ну не нужна она была и забыл про нее многое. И так со всем остальным в С++. То чем пользуешься последний год, помнишь, затем потиху забывается.
Понадобилось тут написать на pure C немного, оказалось, что очень много чего забыл. На С++ не задумываясь, а на C вспоминал, как оное писать.
Чего стоит перегруженность различными понятиями ключевых слов и в разных местах кода они имеют разный смысл.
Ну знает тот, кого ты собеседуешь про про последовательность инициализации в конструкторе, но забыл про последовательность инициализации глобальных переменных. А разные типы связывания и много еще чего.
С++ уже дорос до той стадии, когда нет в мире человека, что знает его весь со всеми его нюансами.

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

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

А в Украину сливают все что не совсем успешные компании наплодили.

По собственному опыту — Дейтелы — отличный учебник для начинающего, интересно, есть задания для самостоятельного выполнения. А потом можно в каком-нибудь open-source побыть, попрактиковаться) например, летом можно в GSoC попробовать пойти (Google Summer of Code).

Знание всего, что написано в справочнике с++ Шилдта — это во-первых.
Во-вторых нужно знать требования конкретной компании, это пишут в объявлениях о найме джуниора. И готовиться к каждому собеседованию отдельно.
У меня было с десяток собеседований, все были абсолютно разными. Где-то был упор на знания сетевого программирование, где-то нужны были знания Qt, были собеседования, где мне давали говнокод, который вряд ли кто-то в здравом уме напишет, и спрашивали, какой будет результат.. Но основы с++ знать надо везде.

требования конкретной компании

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

junior C++ это оксюморон. С++ настолько сложен и имеет много нюансов и возможностей «отстрелить себе ногу», что программиста любого уровня можно поймать на незнании чего-нибудь

для собеседования
— прочитать Мейерса и Саттера. потом можно Александреску :-)
— знать зачем нужен виртуальный конструктор :-)

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

— знать зачем нужен виртуальный конструктор :-)

деструктор

Вообще-то конструктор чел имел в виду.

Чел возможно и имел ввиду виртуальный конструктор, только в С++ нет виртуальных конструкторов. В этом смысл вопроса, или надо рассказать про фабричные методы? Но фабричный метод — это не виртуальный конструктор. В рамках С++ это некорректный термин.

Есть паттерн «виртуальный конструктор ».

Тем не менее, спрашивать про «виртуальный конструктор» в С++ некорректно, потому что правильный ответ — его нет в стандарте. А то, что вы называете «виртуальным конструктором» — давно известный паттерн «фабричный метод инициализации».

Ну а как еще почесать ЧСВ. Бабы задроту не дают, гопники по шее стучат. Вот и начинает придумывать бред и доставать других таких же как он на собеседовании, чтобы самоутвердиться.

Это вопрос в стиле «угадай, чего я хочу».

Именно поэтому, когда речь идет о паттернах, лучше спрашивать «как бы вы сделали...»

Да. Потому как этими паттернами уже пользовались 15 лет, до того, как 4 кадра их оформили четко в книжке и если эти книжки не читал, то и не ответишь сходу, но вот в своем коде ты их мог использовать еще 20 лет назад.
А вот при четкой постановке задачи чел вполне может этот паттерн нарисовать тебе.

Вообще-то вот.
ru.wikipedia.org/...​д_(шаблон_проектирования

Вот только в английской вике
en.wikipedia.org/...​ki/Factory_method_pattern
о «виртуальном конструкторе» не слышали. Так что это изобретение местных постсовковых укурков с гигантским ЧСВ.

Ну вот же ш. +2 этому господину было бы на собеседовании, и С++ знает и про фабричные методы тоже.

UP: +3 — ещё и на вопросы с подвохом отвечает уверенно.

И −3 вам. Тебе никогда не отказывали после собеседования, что работать у вас не буду в нежном стиле «я нашел уже другую контору»?

Отказывали по разному. И не думаю что из-за вопросов, которые я задавал.

ЗЫ: А ещё я спрашивал иногда «почему вы хотите у нас работать» :)

Ну так в вашей конторе работать большая честь же. Вот тебе и ответ.

Я вообще-то после стандартного ответа на вопрос переводил этоу беседу на тему «а чего ты ищеш и какю работу хотел бы».

Такой же балшит тебе озвучивался про выше, шире, сильнее.

Стандартный ответ на этот вопрос вообще-то «я и не хочу, это вы меня убедите, что бы я захотел».. ну .. как правило в более мягких вариациях. Такого ответа, как ты привел я в жизни от живого человека не встречал.

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

все больше убеждаюсь что про Александреску все говорят но никто не читал.

In the steady state, you already hold pointers or references to polymorphic objects, and you can invoke
member functions against them. Their dynamic type is well known (although the caller might not know it).
However, there are cases when you need to have the same flexibility in creating objects—subject to the
paradox of „virtual constructors.” You need virtual constructors when the information about the object to
be created is inherently dynamic and cannot be used directly with C++ constructs.

Кстати про Александреску и то что он устарел — мысли у человека очень даже глубокие.

А насчет устарел — ну да, потому и ввели всякие вариадик темплейты и все ещё думают про концепции — потому что устарел :)

Устарела реализация, да. Но не идеи. Так что почитать стоит. Но джуниору это большим плюсом вряд ли будет. Среди некоторых собеседующих, возможно, даже наоборот, поскольку некоторые синьоры верят в мем про то, что если человек читал Александреску — он засрёт им весь продакшен код темплейтной мутью без причин.

многое из его идей потащили в стандарт, и например как то не очень актуально уже читать как реализовать лиспоподобный список типов когда есть уже std::tuple

ок, а про то как реализовать собственный алокатор ещё актуально?

читать как реализовать

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

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

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

Именно конструктор. Деструктор это вопрос для джуниоров 😀

И что такое виртуальный конструктор по-вашему? Фабрика? «Виртуальный конструктор» — это некорректный термин в рамках С++.

это паттерн, вполне корректный в рамках С++
stackoverflow.com/...​-idiom-and-factory-design

В стандарте его нет, а если спрашивать паттерн, то лучше спросить «как бы вы сделали ...»

Фактически 3 основных «что первым спросить за плюсы» являются именно паттернами ооп в данном конкретном случае непосредственно реализованными как «нативная» часть самого языка.

Следуя этому вполне можно спросить например «как бы вы реализовали инкапсуляцию?» технически вопрос довольно адекватен (при условии что спрашивающий с одной стороны понимает о чём он спрашивает а с другой при этом не спрашивает о чём-то сугубо своём больном личном) и может рассматриваться например в вопросах размещения в памяти и сериализации/десериализации.

В языках, которые не поддерживают такую функцию из коробки, используют шаблон «абстрактная фабрика».

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

Но, кстати знание этого на порядок важнее знания «фабрики».
И я, например, в С++ очень не люблю когда фабрики в коде, без острой на то необходимости.

как по мне то Александреску устарел

— прочитать Мейерса и Саттера. потом можно Александреску :-)

Не н-н-нада Александреску, особенно джуниору, разве что ту книгу что у них напару с Сатером. Сатера тоже джуниору не обязательно..

— знать зачем нужен виртуальный конструктор :-)

Вот этот вопрос я, кстати, любил задавать на собеседовании...

-не создавать утечек памяти и ресурсов

Спасибо кеп!

-прежде чем изобретать собственный велосипед, посмотреть нет ли его в Boost

Александреску у них устарел, а буст не устарел?

— знать зачем нужен виртуальный конструктор :-)
Вот этот вопрос я, кстати, любил задавать на собеседовании...

А вообще за эту игру слов спрашивающим морды быть надо.

нормальный вопрос. используя логику, можно ответить даже если не знаешь ответ. такие вопросы лучше чем «назовите все функции такого-то АПИ наизусть»

Не ответит, если не читал этого извращенного термина. Выше уже об этом написали.
Хочешь спросить конкретно, спроси про «фабрики».
А то я могу спросить про лошадь, а иметь в виду крокодила.

конструктор — то что создает обьект
виртуальный — полиморфный по типу обьекта
что тут непонятно? сложив одно с другим можно понять что речь о полиморфном создании объекта
я вот сразу допер когда меня спросили

Это называется ребусы загадывать. А кандидат должен их угадать.

Я оговорюсь, если кандидат не угадает этот ребус а просто скажет «что за бред, такого не бывает, это ж не будет минусом».

Но да, это вопросто на самом деле на хорошее знание деталей языка и близкий к «методы такого-то АПИ». Джуниоров я такого не спрашивал по-моему.

Мрак. Ну , каждый сам выбирает работать ему с джунами или спецами.
Если у вас так важны паттерны, то и спрашивается про паттерны, называя их общеупотребимо.

Слушай, ну знать про то зачем виртуальный диструктор нужен С++ програмисту вообще надо? Как ты думаешь?
А про то, что конструктор не бывает виртуальным?

Нет, не надо. Но разумно почитать разок про паттерны, чтобы что новое и достаточно четко описанное найти ну и отложить в голове некоторые стандартные трюки (будешь знать что такое есть и быстро найдешь в гугле и вспомнишь).
Вот тебе аналогичный пример. Когда-то давно, когда еще БПФ все реализовывали сами я делал реализацию на числах Мерсена. Но уже прошло дохренища лет и это всё есть в отлаженных библиотеках. И если у меня про это спросить я ничего не вспомню, а даже простого винограда не вспомню сейчас.
Виртуальный конструктор ты не сделаешь по определению в С++, а если подобное по функциональности нужно, то нужно сначала внимательно почитать и разобраться с паттерном «фабрика». Но если ты его постоянно не пишешь, то забудешь многое и единственный рабочий вариант лезть в гугл и вспоминать.

Теряюсь в догадках — что же можно забыть то в патерне фабрика? Ну.. может я конечно такие вопросы задаю, потому как каждый день его не пишу...

Что можно забыть в винограде — он же элементарен?

Теряюсь в догадках — что же можно забыть то в патерне фабрика?

Ну например попытаться объяснить разницу между абстрактной фабрикой и абстрактным методом.

Угу, а еще в добавок фабричным и шаблонным методами.

виртуальный — полиморфный по типу обьекта

Но поскольку объекта ещё нет то и полиморфизма никакого быть не может и в контексте называть порождающий паттерн (один из) «виртуальным конструктором» только потому что «так ведь других нет» (к) (тм) это несколько исключительно потешить своё того чего тоже нет.

что речь о полиморфном создании объекта

Так в этом же ж и самый цимес что нет никакого «полиморфного создания» есть только делегирование с сокрытием реального типа созданного объекта и неявным его выведением не более того.

Вопрос исключительно «на поговорить» и прямая опасность здесь как я уже сказал «вопрос кто умнее и вопрос кто должен этого не показывать».

Но мы чтим единоначалие (μοναρχία) ; впрочем, не то единоначалие, которое определяется единством лица (и одно, если оно в раздор с самим собой, составит множество), но то, которое составляет равночестность единства, единодушие воли, тождество движения и направления к единому Тех, Которые из Единого (что невозможно в естестве сотворённом), так что Они, хотя различаются по числу, но не разделяются по власти. Поэтому Единица, от начала подвигшаяся в двойственность, остановилась на троичности. И это у нас — Отец, и Сын, и Святой Дух. Отец — родитель и изводитель, рождающий и изводящий бесстрастно, вне времени и бестелесно; Сын — рождённое; Дух — изведённое.
Посему, не выходя из данных нам пределов, вводим Нерождённого, Рождённого и от Отца Исходящего, как говорит в одном месте Сам Бог — Слово (Ин. 15:26)

Я давно говорил, что идеологи С++ в прошлом рождении были в прошлом рождении средневековыми богословами. И символика кстати та же.

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

Я так не думаю в таком случае прямой вопрос «а зачем спрашивал?»

Таки да вопрос «на виртуальный конструктор» суть есть один из классических «а угадай что я думаю?» (читай «а угадай насколько я тупой?» и ли надо валить прямо с ходу по ходу завалив в морду для моральной компенсации в т.ч. за других сюда попавших или же ж сделать умное лицо и фигу в кармане и вид якобы тут один умный сами знаете кто).

При наличии хоть какой-либо реальной практики реальных случаев спросить «а как бы вы сделали используя логику (и соотв. имеющиеся знания и опыт) вот в таком реальном приближённом случае?» таких имеется масса грамотному спрашивающему можно их даже записывать по ходу возникновения но когда приходит спрашивающий и в тоне спрашивающего спрашивает «тааак чтобы спросить по плюсам? ну что такое полиморфизм?» (здесь можно подставить «виртуальный конструктор») то это уже прямой признак что на проекте что-то не так и там такой же ж бардак как видно из вопросов по реальным случаям которых нет.

Никакаой игры слов, я спрашивал четко и ясно. «Что лучьше виртуальный деструктор или виртуальный конструктор? И чем они вообще отличаются и для чего нужны, какие у них подводные камни»

Что? Это вопрос аналогичен вопросу «Что лучше зеленый крокодил или ежик с мягкими иголками?»
Ну хоть ЧСВ почесал?

Ну что-то ведь кроме того «а расскажи с чем ты работал и какие проблеммы решал» спрашивать то надо? (это я тоже спрашивал если чо, и дальше от рассказанного тему развивал в глубь матчасти) У нас, как и у большинства, то в отличии от бея возможности 2-х недельного триала то не было.

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

И правильный ответ «конструкторов не бывает (здесь зависит от глубины обоих и рассказкать почему) а есть вот такие паттерны которые как бы про это» и всё.

Тот же ж вопрос что и на «люки круглые».

И таки они не круглые.

Ну дык как и «виртуальный конструктор» и не конструктор и не виртуальный ))

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

Плохой ответ, потому что прост и очевиден и наверняка не совпадает с той формулировкой, которую заучил интервьюер.

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

..и многие постепенно становятся частью стандарта!

очень часто даже Seniors сдуваются на вопросе касательно конструирования объектов

Пару вопросов по С++ и любой, в том числе Александреску, сдуется. Только зачем? Если берут человека, то работу делать, а не чесать ЧСВ собеседователей.
Достаточно пример с виртуальным наследованием и шаблоном и любой сдуется. Или чего-нибудь из бреда Александреску.

для того чтобы человек мог работу работать нужно чтобы он знал хотя бы базовые понятия

Пару вопросов по С++ и любой, в том числе Александреску, сдуется

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

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

На подумать обычно тоже в стиле «угадай, что я имею в виду».
Я всегда беседовал по прошлой работе, спрашивал с какими сложностями сталкивался, как решал и почему так, а не иначе, как еще можно было.
Ну а джуну домашку, а потом такой же разговор по ней. Мне понравилось давать домашку такую «напиши класс матриц и реализуй многопоточное ее умножение». По этой домашке можно много чего обсуждать, даже если он ее списал. Если списал и во всем разобрался и понимает детали в коде своем и почему сделано так, а не иначе, то вполне можно брать на работу.
А на собеседовании ты просто не поставишь корректно задачу на подумать, будет опущено много важных моментов и человек должен угадать что ты имел в виду.

вопросы ради шутки типа колодцев и расширяющихся небоскребов тоже годятся. только не следует на основании их делать выводы о кандидате :-)

самая адовая «домашка» у меня была — мне прислали код на VС++ и COM, в котором не работали евенты и я ковырялся несколько дней пока не заставил эту хрень работать. ком это вообще жестокая технология («спасибо» Мелкософту что везде ее пропихивал), мало кто его понимает на 100% и ошибки могут быть очень труднодетектируемые. но я справился. в итоге меня не взяли по другой причине (техническую часть прошел)

Я уже давно с тестовыми отправляю лесом. Предлагаю 2 недели поработать авансом удаленно.
За эти две недели не только они на меня посмотрят, но и я на них. А дальше уже будет видно продолжать сотрудничество или нет.

А домашка только для джунов имеет смысл.

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

в данном случае речь была о работе в США со спонсорством релокации, поэтому с их стороны такой шаг наверное был оправдан. хотя в итоге меня не взяли именно из-за денег (менеджер с их стороны так сказал... типа бюджет выработан, сорри, вы нам нравитесь, но мы не можем вас нанять)

сейчас удаленные собеседования проще решаются — через скайп-конференцию

в данном случае речь была о работе в США

Штатовцы генерируют аццкое количество аццкого говнокода опережают их разве что европейцы со своим социализмом и резкой мультинациональной структурой «европейскости» и соотв. подхода к опенсорсу но если выбирать из двух зол то штаты хотя бы практичнее и в т.ч. в признании заслуг «человек пахал».

ком это вообще жестокая технология («спасибо» Мелкософту что везде ее пропихивал)

А по-моему очень няшная вещица имеющая в т.ч. «виртуальные конструкторы в себе» ))

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

Они сами от нее в итоге отказались

Я тоже так думал но нет.

а по итогу многое сильно усложнила и ухудшила.

А это так вообще нет.

ЗЫ: я удивился но там походу ATL жил и даже MFC жив и пользуется.

Да я знаю я как раз в то время жил ))

Вивчала Соціологія у Kyiv National University of Trade and Economics (КНТЕУ)

Непогано.

Memory management

: malloc, calloc, realloc, free, new, emplacement new, delete, unique_ptr, shared_ptr, weak_ptr, custom allocators і конетйнери зі стандартної бібліотеки + циклічний буффер.

3D math

Восновно лінійна алгебра і аналітична геометрія, матриці, вектора.

Вообще — можете писать в Skype: denys.poltorak

3D math

не надо.

Memory management

типы аллокаторов и их свойства, где какой применять, выравнивание туда же.
Еще поспрашивают design patterns и оптимизации. www.agner.org/optimize/optimizing_cpp.pdf
Структуры данных и алгоритмы. О-нотация. Почитать Седжвика.
Многопоточность могут и не спросить — как повезет. Но знать ее полезно. pthread глянуть какой-нибудь.
Могут спросить линуха или сети.

Вообще областей у плюсов много, и в каждой свои требования.

3D math
не надо.

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

Для того, чтобы пройти собеседование на Junior C++, достаточно зайти на cppquiz.org и решить там все вопросы. Этого будет достаточно, чтобы понять, что C++ — это плохой язык, это неудобный язык, и это язык, который заставляет тратить время на борьбу с ним вместо решения бизнес-задач. После этого можно будет бросить эту затею и начать учить Java.
Но насчёт собеседования я серьёзно — если вы на cppquiz сможете решать задачи среднего уровня (помеченные жёлтеньким), то собеседование вы, скорее всего, пройдёте. Насчёт пунктов, выписанных вами, можете не переживать — это продукт буйной фантазии рекрутеров, на который обращать внимания не стоит. Ни один интервьювер в здравом уме не станет просить джуна пояснить за программную архитектуру.

Почему же — мне вон после C# плюсы очень даже нравятся, даже при том что в шарпе неудобств меньше чем в Java. Например тот же RAII — просто песня, никакого леса из using блоков и прочих finally.
Что интересно — раньше у меня было такое же мнение, но по мере роста уровня навыков (и улучшения стандартных библиотек/компиляторов) плюсы пугают всё меньше а привлекают всё больше :)
В общем — дело вкуса.

Вообще-то С++ очень уродливый язык и очень опасный в руках новичка.
Но часто другого выбора нет когда тебе нужно и быстродействие программы и pure С уже неудобен для размера программы.
Но если можно удовлетворить требования более высокоуроневым языком, то лучше воспользоваться им.
Отсюда и спрос в С++ больше на программистов с опытом от 7 лет, а с джунами связываются редко.

Например я считаю, что верхний уровень програмы и ГУЙ должны писаться на шарпе, питоне, жабе и только бутылочные горлышки должны быть написаны на С++ или С. Если кода мало, то лучше С, если много, то без С++ будет сложно.

Вот, я тут как раз напомню еще про Haxe :)

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

Ну, он стал чуть менее уродливым, но да — остается очень нескучным.

Кстати, я в предыдущем коменте начинал писать о том что «по крайней мере на плюсах не просят верстать опостылевший ГУЙ» — пожалуй в этом вся суть :)
Впринципе, даже для «мало кода» плюсам есть чего предложить — лично у меня получается что-то среднее без классов но с использованием STL, слишком уж заманчиво. Конечно, если не считать что «мало» — это 100 строк кода и один буфер с байтиками на входе, тогда да, можно и на сях.

Кстати, я в предыдущем коменте начинал писать о том что «по крайней мере на плюсах не просят верстать опостылевший ГУЙ» — пожалуй в этом вся суть :)

Какая наивность. Такие клоуны еще находятся.

лично у меня получается что-то среднее без классов но с использованием STL, слишком уж заманчиво.

У меня тоже С с классами плюс STL, если есть возможность. Ну очень оное сильно жизнь облегчает. Но тут уже надо быть аккуратным с исключениями и виртуальностью (посему ее применения минимизирую).
Ну функций 10 и 3 структуры и на С нормально, но если больше, уже напряжно становиться. Раздражает закатывание солнца ручками.

Какая наивность. Такие клоуны еще находятся.

Ну, если устроился на работу в цирк — не стоит удивляться что вокруг клоуны :)
Правда, иногда не сразу понятно цирк это или нет.

Правда, иногда не сразу понятно цирк это или нет.

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

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

бывает и такой, но это не мешает пилить его на Java например

помнится, в девайсах под QNX все на плюсах . хотя это все упирается в мощность железа, возможно в последних таргетах Джава есть

Ты не поверишь они там в этом месте щас активно QML (читай JS) просувают и HTML5.

в «этом месте» == в HB? :-)

Это в Automotive (и не только) HMI

И слава богу, а то на новых тачках каким то образом оказывается убогий устаревший интерфейс

Например рено талисман 2015 года за 40к евро или хёндэ ионик 2017, мало что карты неактуальные, так и юзабельность уступает банальным гугл мапс. Мерсовский навигатор тоже не впечатлил, всё как на древних планшетах.

не надо читать JS. это совсем не JS хотя и поддерживает JS

вы же в курсе оверхеда JVM?

<Толсто>Не больше, чем оверхед самописных аллокаторов, написанных людьми, которые говорят об оверхеде JVM.

вы хоть сами пониали, что сказали?
т.е. оверхеда у явамашины нет?

Не об этом речь. Джава код мендленнее стареет. Т-е поддерживать джава код, который писался 5 лет 30-ю разными людьми, из которых с 20ю потеряна связь намного проще, чем С++, или скажем JS. Стиль написания кода у разных людей отличается меньше, за счет чего код гниет медленней.

А по поводу применения java для gui в ембедеде. А в чем смысл? На java есть что-то хорошее для рисования гуя?

ну если так подумать то на java вообще мало что хорошего есть, но тем не менее гуй рисуют

я не понял: то плюсы ругают за медленное развитие то пеняют что старый код некому поддерживать
а про гуй на яве это не ко мне. я гуй на Qt/QML пишу

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

Ну, у С++ очень много разных проблем.
Джава тоже медленно развивается. Но там меньше проблем с поддержкой старого кода (При том, что самого старого кода поболее будет). Даже интеграл по плечу старого кода скорее всего больше будет.

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

Я считаю, что не перевешивают, просто в некоторых областях пока нет ничего другого вообще, кроме С или С++.
Вот у меня была когда-то надежда, что D взлетит, но не взлетел.

Я считаю, что не перевешивают, просто в некоторых областях пока нет ничего другого вообще, кроме С или С++.

Это в каких таких областях?
Поддержка старого кода написанного на С?

в областях, где софтваре инжинер точно знает что он делает

Т-е в областях, которые ограничены знаниями, которые могут поместится в 1 человека?

Эмбедед, математика и всякое низкоуровневое для написания осей, дрова.

Эмбедед

В большинстве случаев да.
Но я сталкивался с ембедедом с применением Java, питона, JS.
Речь идет о ромышленных датчиках для заводов за 11к+ евро.

математика

А еще есть питон, фортран(Да, плохая шутка), Wolfram (Да, я знаю о крупных комерческих проектах в которых его применяют O_O X_X)

дрова

Опять таки. В реальном мире на крупных проектах с огромным финансированием дрова для дорогущих железок вполне могут быть написанными скажем на питоне.
Встречал пример драйверов для дейвайсин, подключаемых через RS-485 написанных на скале (больные извращенцы).

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

А еще метеориты иногда падают, один вон динозавров вынес.
И еще много чего случается всякого разного.

Ну, автомобильная система — это хотя бы не лютый энтерпрайз с несколькими тысячами страниц с (минимум одним) гридом на каждой и заказчиком стоящим в позе «нет, мы не будем это автомагически генерировать — мы, белые господа, желаем смотреть как негры пашут».
Даже на десктоп в виде QT можно было бы посмотреть для разнообразия.
Тем более, у меня нет иллюзий по поводу того что где-то с UI вообще не надо иметь дело, просто пропорции гуйовой работы везде разные — на том же шарпе это «очень много», даже тот же веб-бекенд часто заканчивается какой-нибудь версткой HTML и правкой CSS (это даже не вспоминая о бесконечном CRUD). На плюсах же есть какой-никакой но выбор — если поискать то можно найти что угодно (в том числе и чисто UI конечно же), в то время как на многих языках можно даже не пытаться. Хотя, справедливости ради, я тут говорил с ребятами которые на шарпе пишут серьезные промышленные авиасимуляторы :)

эти все задачи достаточно шаблонны, чтоб написать дженерик код для сервера с CRUD и для гуя с гридом и паттерном MVC (и параметризовать его классами модели данных и прочими) . но конечно гриды со 100+ колонками это адово не столько в плане написания (копи-паст же!), сколько для конечного пользователя

На Qt гуй вполне себе ничего пишется, да и не только гуй, и проекты не сказать чтобы маленькие. Причем реально портабельно. И QtCreator понемногу дорос уже до взрослой IDE, по крайней мере в разы быстрее студии и XCode, по удобству можно спорить но рефакторинг/навигация по коду однозначно лучше в QtCreator. А если включить плагин clang code model, так вообще студия нервно курит, а XCode уважительно посматривает.

Так я и не говорил что гуй на плюсах писать невозможно. Но на плюсах есть что-то кроме этого самого гуя, вот и всё.

В студии нынче вовсю решарпер — там как раз на днях новую пачку clang диагностик с рефакторингами досыпали (вместе с невероятно удобным инспектором, приятно удивил) да и навигация у него своя (от IntelliJ вроде).
Впрочем, даже лет 10 назад использовать студию без плагинов было не принято, так что я бы не спешил со столь радикальными выводами.

что скажете на счет D? понимаю что работу на этом языке врядли найдешь, но хотелось бы услышать мнение от опытного cpp разработчика

D — это рефакторинг С++. Интересный язык, но реальных проектов очень мало. Занимает 30 место в рейтинге TIOBE, что на 13 позиций выше, чем у аргрессивно рекламмируемого Rust.

rust как то не зашел, как по мне слишком переусложнен ИМХО. та и проектов кроме рендер-движка для FF особо значимых вроде не видел, хотя язык достаточно молод.

Ничего. Я с ним дела не имел. Бизнес почему не захотел его юзать. Ну а мне пофиг, могу и на С и С++, если платят.
Сам же по себе язык, пусть и идеальный ничего не значит, если им не пользуются и к нему нет библиотек.

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

Да согласен, очень жаль( На реддите писали, что он вышел уже мертверожденным...

Мне так не кажется. Просто сравни лобби с++ и d.
Сравни насколько развита инфраструктура вокруг С++ и D.
Ну с другой стороны еще пару стандартов С++ и он станет неподъемным монстром. Может тогда и задумаются о замене (хотя вероятнее всего всего будут юзать свои урезанные диалекты С++).

Многие ждут c++20, вроде тоже много всего интересного. Но в освоении язык легче не становится)

основное достоинство C++ — шаблоны . java всегда меня бесила своей избыточностью и необходимостью копи-паста. К счастью Java 8/9 с ламбдами и функциональными интерфейсами стала чуть-чуть ближе к шаблонному программированию. Не совсем шаблоны как в ++, но позволяет писать более краткий «шаблонизированный» код с помощью композиции подставляемых блоков кода

То не то. Дженерики не позволяют вставлять шаблоны кода, а лямбды позволяют

который заставляет тратить время на борьбу с ним вместо решения бизнес-задач

C++ не для бізнесс задач.

C++ — это плохой язык, это неудобный язык, и это язык, который заставляет тратить время на борьбу

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

обычно с плюсами борются отмеченные жабаскриптом

Не про меня.

с кем боретесь?

Не с кем, а с чем.
С отсутствием нормальных модулей в 2017 году и вообще с разбиением файлов всего проекта на .cpp и .h, прямо как в 70-х; с синтаксисом, который компиляторы научились парсить, но не научились нормально сообщать об ошибках, из-за чего пропущенная точка с запятой может вылезти ошибкой через три файла и двести строк спустя, а в макросе ошибку определить практически невозможно; с кучей фич, покрывающими одни и те же юзкейсы (напр., макросы, шаблоны и константы), которые даже не пытались подогнать друг к другу, из-за чего фичи могут неожиданно с треском сломаться, будучи использованными вместе (напр., кросс-ссылки на классы лечатся forward declaration — но только не на подкласс другого класса, потому что на них forward declaration поставить нельзя); с UB и другими подводными камнями на каждом углу, про которые не в курсе даже самые опытные программисты; с l-, r-, x- и pr-values и вообще с абсолютно конченым синтаксисом move semantics (для того, чтобы в полной мере осознать, насколько он конченый, можно посмотреть, как такую же идею можно было бы запилить не через то самое место: ericlengyel.blogspot.nl/...​ut-rvalue-references.html ); ну и вообще с общей безблагодатностью и «магией» изо всех щелей. А память выделять мне не влом, с unique_ptr ничего в этом сложного нет.
И при всём при этом — да, для некоторых задач лучше С++ ничего нет :) Но это не потому, что С++ хорош, а потому что всё остальное для таких задач ещё хуже.

берут подходясчий фреймворк (кьют например)

Который написан на расширении C++ со своим специальным компилятором.

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

есть препроцессор, который генерирует чистый С++

Во-во. А это не просто костыль, а костылище.

почемуто препроцессор си вас не смущает? хотя делает ровно тоже самое

Потому, что в года возникновения С другого варианта не было, а теперь нечто 50 летней давности тянут с собой.
Препроцессор С уродец еще тот.

если вкратце, то да, надо учиться, блиню Зато потом открывается море возможностей

Учиться — это замечательно. Я люблю учиться, я хочу учиться! Но когда начинаешь лезть в дебри C++, то становится грустно от того, что приходится попусту расходовать умственные ресурсы — исключительно из-за того, что господа в Комитете не смогли подумать головами сами.

нет в кьют специального компилятора. есть препроцессор, который генерирует чистый С++

Кьютишники сами называют его moc — Meta-Object Compiler. От препроцессора C он отличается тем, что понимает синтаксис класса, а не просто заменяет одни слова на другие.
Энивей, это не очень важно, я упомянул это лишь потому, что Qt в контексте обсуждения несовершенств C++ — это немного непонятно, потому что само существование moc как бы эти несовершенства и подчёркивает.

умственные ресурсы они как мышцы — если ими не пользоваться — они деградируют
я знаю какего нзывают? но по сути ето препроцессор. сишный препроцессор тоже парсит и разбирает структуру кода

умственные ресурсы они как мышцы — если ими не пользоваться — они деградируют

Достали этим бредом. Подумать не пробовали, прежде чем его ретранслировать.

но по сути ето препроцессор

Так он и есть по сути компилятор — а точнее транслятор, преобразовывает один язык в другой. Разницы не много. Но то, что для С++ сильно желательно требуется многим еще дополнительный препроцессор, то это говорит не в пользу С++.

Достали этим бредом. Подумать не пробовали, прежде чем его ретранслировать.

если вам не нравиться наш бред, придумайте свой, улучшенный бред

Мозг не мышца и работает в корне не подобно ей и обучают его другими методами в корне.

вы слишком буквально восприняли аналогию с мышцей

Потому что это сравнение уже раздражает.

Модули там уже как раз есть.
А макросы успешно объявлены абсолютно устаревшими ещё в Effective C++ незапамятно-бородатого года выпуска.

Модули там уже как раз есть.

Вы уверены? Можете дать ссылку?
Потому что по моей информации, есть две несовместимые реализации модулей в MSVC++ и в clang, и если это правда, то в реальных проектах модули появятся лет через 5-10, а до этого момента мы будем продолжать ставить #include и материться, когда два одинаково названных хидера лежат в разных include directories.

А макросы успешно объявлены абсолютно устаревшими

Что не мешает им присутствовать в исходных кодах практически всех проектов на C++, от Google Test до Unreal Engine. Потому что C++ -ную константу через командную строку компилятору не задать, да и писать

assert(a == b);

веселее, чем

if (a != b) std::cout << «Assertion failed: a == b, » << __FILE__ << «:» << __LINE__;

Учитывая насколько бодро последние пару лет MSVS интегрирует куски clang (да и вообще движется в сторону compliance в MSVC++) то можно надеятся что они как-то сольются в экстазе в обозримом будущем.
В любом случае сегодня всё выглядит пободрее чем лет 10 назад — по крайней мере движение наблюдается.

веселее, чем

Согласен, только вот assert едва ли не лучший возможный пример макроса — текущую строку и имя файла знать надо нечасто. А если не надо — inline и template в помощь.
А банальщина всякая типа внешних констант или каких-то API_EXPORT вставок редко требует какой-то особой отладки в силу относительной простоты.

Впринципе, плюсы есть лютая куча всякого невероятного legacy и backwards compatibility костылей, но именно поэтому они с нами останутся еще надолго :)

Ноуп, модулей нет. Разве что в качестве сырых недотестированных нестандартных расширений отдельных компиляторов. Но в продакшене такое использовать мало кто рискнёт.
Полноценные модули ожидают к C++20. Но не факт, что сделают. Комитет не спешит стандартизировать полезные вещи.

А макросы не были объявлены абсолютно устаревшими, поскольку в некоторых случаях без них не обойтись (кроме как тупо копипастить код, что ещё хуже).
В бородатом Effective C++ советы были не использовать макросы там, где без них обойтись можно. Но советов не использовать их вообще я в этих книгах не припомню.

Мой коментарий уже есть в ветке — их, может, пока «не совсем есть», но даже так ситуация гораздо лучше чем лет надцать назад когда был подвисший TR1 с невнятными перспективами и кучи вендор-специфик радости везде где только можно (и даже там где нельзя). Сейчас я вот колупаю код в визуалстудии и наслаждаюсь сообщениями вида «этот код в clang не соберется, поправь пожалуйста». А если даже майкрософт стал весь такой стандартный и нерасширенный — то это навевает определенные мысли.

И никто и не говорил что макросы вообще совсем не должны использоваться. Более того, я не вижу вообще никаких проблем с макросами вида #define CreateFile CreateFileW — есть, работает, да и хрен с ним. Вопрос же был «ойойой как их больно дебажить» — ну так не надо пихать макросы туда где дебажить надо, ибо

assert едва ли не лучший возможный пример макроса — текущую строку и имя файла знать надо нечасто. А если не надо — inline и template в помощь.

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

Ты про время написания или про время выполнения проги. Вообще-то на С быстрее и написать и с выполнением, если небольшая. Если большая, то таки придется С++ заюзать.

А по времени написания — дольше, чем на С++ писать, наверное только на Перле каком.

Ну что вы, дольше всего писать на ASM, перл довольно лаконичен в специфичных задачах, но также сложен в сопровождении, глаза болят от — $_, @_.

Про время выполнения. Особенно, когда дело доходит до контроля управления памятью, то здесь С++ нет равных. Даже банальную XML прочитать — на Питоне это будет бесконечное выделение/освобождение маленьких кусочков памяти под каждый нод/атрибут. На плюсах этого можно избежать, получив прирост скорости в несколько раз. У меня было несколько проектов на плюсах, когда надо было ускорить работу программы на Питоне. Иногда ускорение доходило до х50-х100 раз!

Не ходи в С++, там тебе поганому навчать. :)

Навчать не шукати бабл-сортом максимум в масиві.

Обгоняет все другие сортировки, если массив у тебя из 7-10 элементов.

Это да. Интересно, на вайтишных курсах сей нюанс объясняют?))

Вообще нормальный программист сначала юзает стандартную библиотечную функцию и только после профилирования и понимания, что тормоза в сортировке начинает писать ее сам.
Ну я современная дурка с O сложностью из непонимания, что значит большое О и о малое.
Я тебе почти любой алгоритм с любой сложность могу переделать на O(1), если у меня памяти на компе достаточно для этого алгоритма.

Даже сортировку сетью?

Есть бенчмарки?

Сам напиши и померяй. Я это понял еще в универе до хрена уже лет назад.

Маєте на увазі, що не шукати взагалі сортуванням (будь-яким) максимум в масиві?

А вот если тебе надо найти n максимальных элементов, то с какого-то n сортировка окажется выгоднее или вообще дерево какой построить.

Ну це вже інше питання, ну і так в такому випадку дерево (max heap) зі зберіганням N найбільших елементів зробить свою справу за K * logN (де К — кількісь елементів масиву), що краще сортування повинно бути (K * logK)

Нет. Ты плохо понимаешь O нотацию. В вики ссылку, думаю не надо давать, сам найдешь.
Я тебе ничего не сказал ни про размер массива, ни про что в нем, ни на каком железе считаться должно.
Ну а в случае сферических требований в вакууме твоего ответа вполне достаточно. Но мы здесь больше инженеры, а не академические ученые, которым физические ограничения не важны.
Еще раз для этого я могу тебе сделать реализацию с O(1) для сферического коня в вакууме.

Будь ласка, дуже цікаво подивитись на реалізацію складністю O(1) для загального випадку (сферичного коня у вакуумі)

Заранее отсортирую массив и буду возвращать тебе за O(1).
Да, сортироваться оно и 100 лет может, но поиск будет за О(1).

Ладно, коль не хотите сами учиться, то расскажу
O(n) = k*n или O(f(n)) = k*f(n). k неизвестен почти всегда и зависит от конкретной реализации на конкретном железе.
Отсюда при малых n O(n^n) может быть быстрее O(n). Но при n стремящемся к бесконечности O(n) быстрее O(n^n).

Не простіше тоді завчасно порахувати результат (N елементів, чи один в початковій умові) швидшим алгоритмом, ніж сортування?
Але, на мою думку, один набір вхідних даних — це не загальний випадок....

А в случае сферической задачи в вакууме лучше всего сферический алгоритм в вакууме.
В конкретном же случае выбор «пузырька» может оказаться эффективнее всех остальных известных алгоритмов сортировки.
dou.ua/...​ign=reply-comment#1245258

Я абсолютно з вами згідний в плані сортування бульбашкою малих масивів і загалом що O (n ^ 2) може бути кращим за O (n) при малих n...
Але на практиці зазвичай і не постає питання швидкодії алгоритму якщо передбачаються малі об’єми даних

Вот я и написал выше, что это фанатизм с O большим происходит из не понимания большинством этой нотации.
Она имеет смысл, когда твоя прога медленная и нужно ее ускорить. Для этого сначала профилируешь, находишь бутылочное горлышко, а потом лезешь в Гугл за поиском более быстрого алгоритма для твоего случая. Если не находишь в гугле, пишешь сам. А это O большое по сути интересны только для академической науки ученым. А нам программистам только в качестве инфы, что вообще есть в мире.

Вот смотри сложение матриц. На GPU O(1), на CPU O(m*n). Но AMD FX 8350 одним ядром рвет ATI HD 6770 как тузик грелку. И всё это спрятано в коэффициенте К.

Так стандартные библиотечные реализации и так используют сортировку вставками для малых массивов

Тут надо тебе выбирать направление.
Если на галеры, то списки требуемого есть в интернеде. ГА, ТВ и эмбедед там не нужны, но за задолбают O сложность STL, и т.п. бредом с наследованиями, шаблонами.
Если нравиться математика, то в первую очередь требования именно к требуемой математике. Нынче большей частью МЛ, ГА, ТВ, ЦОС, знание языка быстрого прототипирования Питон, Матлав, R (одного из них достаточно) и умения С с классами, чтобы твой код был на С++ достаточно быстр, прост и лаконичен. Очень часто через некоторое время его передают в саппорт чистым программистам.
Если железо, то тут вообще рулит С и иногда С с классами и знания и умения собственно железа и его особенностей. Дрова здесь же, но со знанием внутренностей операционок.

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

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

+ не боятись роботи із мультиметром, осцилографом, логічним аналізатором, та час від часу паяльником :)

И всегда иметь пачку аспирина под рукой. И от похмелья поможет и припаять чего.

від дим від аспірину провокує страшний кашель, цей спосіб залишив історії :) Рідкий флюс зручніший :)

Multithreading

для джуниоров очень вкратце. Типа «что такое атомарность и зачем она нужна, и когда без нее есть проблемы».

3D math

 — тоже весьма не всегда (но если в Самсунг, то таки обязательно).
Знать основные алгоритмы и структуры данных (тут уже не вкратце). Вплоть до вопросов «Какая алгоритмическая сложность квиксорта в худшем случае, и как это исправить?», «Как исправить возможный креш тривиального квиксорта из-за переполнения стека на плохих входных данных?», «Упростите написанную функцию со сложности N^2 до как минимум N*logN».
И да, Майерса (книги про С++ в общем и про СТЛ) знать от и до. Всякие там «Поцчему для объекта класса, спроектированного ромбовидным наследованием, нельзя статически кастить указатели, а только динамик-кастом?», «Может ли шаблонный метод класса быть виртуальным, да/нет? А почему да/нет?»
Подозреваю реакцию аудитории в виде замечаний, что эти вопросы для мидлов. Но джуниоров сейчас жучат на собеседованиях не меньше.

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

А вот с кастованием есть хороший вопрос «Допустимо ли в С++ использовать касты в стиле С?».

Ну так задачку дать, и отсеются зубрилы.
Насчет подсознания — скилл толково лаконично объяснять для синьора никто не отменял. А то дадут ему менторить джуна, и начнется.

скилл толково лаконично объяснять для синьора никто не отменял

Объяснить джуну — это одно. Рассказать дурачкам на собеседовании это другое.
Да и не будешь ты джуну лекцию читать, просто скажешь, что так делать нельзя, а нужно так и скажешь джуну «когда у тебя джун будет время порыскаешь в гугле, попробуешь разный код и поймешь почему так». Если джун не идиот, то так и поступит.

я не совсем понимаю что именно нужно например знать под: Memory management или 3D math и т.д.

Те, що знаходить гугол по цьому запиту! Можна додавати C++ до цього запиту! Можна додавати «for job interview», «what should every (C++) programmer should know about», «programming practice», «useful tips about»!

А взагалі без вміння писати код це все фігня. Напишіть якийсь тетріс/арканоід. Самі в процесі написання ви станете програмістом.

Studied Соціологія

А чего вдруг С++ то?

Memory management: delete, кастомные удалители, shared/weak/unique_ptr, RAII, move semantics...
3D math — вычисления с векторами и матрицами.

memory: ещё аллокаторы, работа с сегментами памяти.
3d: ещё с кватернионами, ну и пожалуй это всё. Всё есть в directx api, или в любом другом.

Английский и уметь код писать. Знания теории сильно недостаточно, нужен опыт. И явно посерьёзнее чем у вас по русскому :)

Знания «на троечку», помноженные на опыт «нолик без палочки» — дают шансы трудоустройства угадай какие.

Много чего надо. Область плюсов очень большая — от системного программирования до игр. Поэтому выберите ту часть, которая больше нравится, и по ее вакансиям определите, что требуют.
И еще, плюсы очень сложная штука. Порог вхождения высокий. Кроме языка вам надо будет знать фреймворки и теорию, которые применяются в той области, где вы будите работать. Поэтому хорошо подумайте — стоит ли вам туда впрягаться.

Не стоит. Во-первых, целевые области применения C++ сдуваются, и соответственно спрос падает. Во-вторых, при падающем спросе полно специалистов с опытом >10 лет в C++, и даже более того, с меньшим опытом — ещё надо поискать. В-третьих, в лучшие времена в разработку на C++ барышень не брали, в силу гендерной дискриминации, которая основана на вполне объективных причинах, тем более без опыта.

в лучшие времена в разработку на C++ барышень не брали

какое-то, извините, фэнтези.

причем в каждом предложении

Брали, только редкие барышни в кресты нос совали. Нафиг он им упал.

Знаю одну, работала со мной в команде, потом выиграла лотерейный билет в Майкрософт :-) на самом деле среди девчонок много умных в математике, но мало кто идет в чистое программирование — либо в теоретическую науку( аспирантура-доктор-преподавание), либо в декрет :-) . Об этом можно долго дискутировать, кто же в этом виноват — гендерные роли, неравенство, социальное программирование и тд, но ответа почему женщины не делают «это» (подставьте любое занятие где доминируют мужчины) до сих пор нет

Потому что им это не нравиться, не интересно и не хотят.

девчонок много умных в математике

Только в школе. А вообще меньше, чем мужчин в науке. У них (женщин) мозг по другому работает.

Потому что им это не нравиться, не интересно и не хотят.

Результат социального давления.

Не только еще и эволюции всей.
Современному социуму всего-то 100 лет. До этого и социум сильно отличался. И это около 100000 лет или более.
Современный социум как раза давит в другую сторону — «женщины и мужчины равны и могут выполнять одинаковую работу». И большинству женщин это не нравиться, потому как эволюционно они не под современный социум развивались, как и мужчины, впрочем.

соответственно спрос падает

То то 10 вакансий все никак не можем закрыть

Предполагаю, что вы спрашиваете у всех дурные вопросы. Посему и закрыть не можете.
А может и не хотите закрывать, вам и так хорошо.

можно список вопросов?
я когда-то коллекционировал c++ interview questions, правда давно неактуально

ну да, так сразу и спалил все вопросы, а вообще я на собеседованиях бываю редко и вопросы задает второй интервьюер

Подписаться на комментарии