Я учусь в универе, но хочу подучить и уже через полгода-год идти работать. Что мне нужно в первую очередь выучить? Я посмотрела ваканции и такой список создала:Memory management, STL, Multithreading, Software Architecture Design and 3D math. Но я не совсем понимаю что именно нужно например знать под: Memory management или 3D math и т.д.
Буду рада если Вы мне по подробнее раскажете что именно нужно под каждым этим значением.
Всем мир
Уметь ответить на вопрос «Что Вы можете рассказать о 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++ у Львові, і всю ту братію, яка на співбесідах
питала про віртуальні деструктори з конструкторами і прочєє, що до
програмування не має відношення
у них дуже специфічний задротістий моцк, і програми такі ж виходять
дуже довго розбирався в існуючому коді, котрий має тучу класів, має обробляти всі випадки на всьому світі і в космосі теж
топик детектор неосиляторов
перечитайте ще раз мій пост в цілому
ану поясни что для тебя программирование?
Книжка була така
Алгоритмы + Структуры данных = Программы
Саме по цьому і ганяють на співбесідах у Долині, ніхто не питає тих дурниць з віртуальною задротістою мурою, яка не має ніякого відношення до
Книжка по алгоритмам + задрочування Cracking the coding interview + практика на leetcode.com, і НІДЕ у цьому шляху не потрібно тих ужасів C++.
Забув сказати, що мій початковий коммент про нелюбов до C+±ної братії у Львові стосувався ще
а виртуальный деструктор это тебе не структура данных?
захожу на
discuss.leetcode.com/...ave-different-return-type
и шо, хоть и Java но точно такая задротистая мура есть и на C++
тоесть указатель на список указателей на функцию не структура данных?
ну ок. все понятно.
ну тогда я бы посоветовал удалит компилятор со своего компа
Вообщето у статических классов, есть просто список указателей на функции которые называются деструкторы. Простенькая прога на ассемблере после выхода из «маин» просто пробегается по списку, вызывая каждый.
хотелось бы поподробнее услышать про «статические классы» да и вообще про инициализацию/деинициализацию
Скорее всего имелось виду статический объект.
Да. Который не через 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
Проблем со ссылкой не вижу. Или 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, ничего не зная о владеющих указателях и списках инициализации?
Ядро можно и на бреинфаке с асмовыми вставками написать, это не проблема вообще
А как ты на бреинфаке асм вставку сделаешь?
Compiler extension же
А я не понимаю, что в этом удивительного. Брали и писали. Тем более, что для низкоуровневых проектов и чистой сишки обычно хватает, там плюсовые навороты не особо нужны.
Зато я бы посмотрел, как
не зная о владеющих указателях и списках инициализации
люди писали бы фотошоп или какой-нибудь хром.
какой-нибудь хром.
Что не поленились и изобрели 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, механики нет уже давно.
проблема в том что в го угол опережения зажигания прибит гвоздями ровно так как надо одной корпорации
Вообще-то им компьютер рулит. А раньше был рычажок. Кажись на руле. И водила должен был им рулить.
Вторая запись хуже, потому вы сначала создаете объекты, а потом присваиваете им значения.
А в первой записи вы напрямую создаете объекты с нужным значением.
Но в первой грабли, во второй — нет.
грабли для тех кто за годы «программирования» на крестах не поинтересовался как правильно и спрашивает пруфов на форуме
Я просто не использую то, где потенциально могут быть грабли.
Во введении любой фичи типа «сделаем свободнее» есть проблема, что её начнут абьюзить и потребуют ещё больше свободы.
Например, инициализация элементов в любом порядке? А как насчёт её гарантии?
Вот вы в конструкторе записали явное присвоение. А если будет код вида
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-то тут при чём?
Ну а как еще в С++ кошерно проверить условие?
Усатий В'ячеслав
Eugene Nuribekov
Valentin Nechayev
Vitaliy Fedoriv
flyman
Евгений Морковин
Punk Floyd
Dmitry Panfilov
Punk Floyd
Bohdan Petrykiv
Леголас Трандуилович
Andriy Kunitsin
Oleg Aleksandrov
Taras Morozovsky
Sergey Podobry
Platan
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
а жаба крива, до сих пор не научилась работать с 4k мониторами в линухе
Хм, а в чём тут проблема собственно Java?
Или какое-то хардкодед ограничение в Swing?
в OpenJDK 8 / Oracle JDK 9 ніби пофіксили
bugs.openjdk.java.net/browse/JDK-8055212
Наскільки бачу, матлаб з собою фактично OpenJDK і тягне.
wiki.archlinux.org/index.php/Matlab#Java
P.S.
Всі вендори, в т.ч. і Oracle, за основу беруть OpenJDK (+ додають щось своє).
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
Не знаю, дядьку. Кажу ж — попробуй поставити додатково інший 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 на Скале.
Кстати у нас на предидущей работе один студент Майерса начитался и начал ему письма строчить.
«сигнал посылаем — вы шо ето там?
а нас посылают обратно» ©
А можно пруф?
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?
речь шла про инициализаторы в хидере
Вотя про это и говорю, что для программирования на плюсах просто необходимо знать все эти особенности. Поэтому их спрашивать нужно на собеседованиях
Нет. Если ты будешь держать в голове все эти мелкие подробности языка у тебя не останется места для мелких подробностей решаемой задачи.
Поэтому все компании, которые успешно создают программы на С++, обрезают его по самые гланды различными фреймворками и style guides.
Иначе бардак и разруха.
А в Украину сливают все что не совсем успешные компании наплодили.
По собственному опыту — Дейтелы — отличный учебник для начинающего, интересно, есть задания для самостоятельного выполнения. А потом можно в каком-нибудь open-source побыть, попрактиковаться) например, летом можно в GSoC попробовать пойти (Google Summer of Code).
Знание всего, что написано в справочнике с++ Шилдта — это во-первых.
Во-вторых нужно знать требования конкретной компании, это пишут в объявлениях о найме джуниора. И готовиться к каждому собеседованию отдельно.
У меня было с десяток собеседований, все были абсолютно разными. Где-то был упор на знания сетевого программирование, где-то нужны были знания Qt, были собеседования, где мне давали говнокод, который вряд ли кто-то в здравом уме напишет, и спрашивали, какой будет результат.. Но основы с++ знать надо везде.
требования конкретной компании
Любимые головоломки выпендрежника, который будет собеседовать.
Интервью на плюсы, где спрашивают по делу, редки как дожди в Сахаре.
junior C++ это оксюморон. С++ настолько сложен и имеет много нюансов и возможностей «отстрелить себе ногу», что программиста любого уровня можно поймать на незнании чего-нибудь
для собеседования
— прочитать Мейерса и Саттера. потом можно Александреску :-)
— знать зачем нужен виртуальный конструктор :-)
для практики безопасного программирования на C++
-использовать ссылки вместо указателей везде где только можно, если вам не нужно модифицировать адрес
-не создавать утечек памяти и ресурсов
-использовать умные указатели и обертки (см.ниже)
-прежде чем изобретать собственный велосипед, посмотреть нет ли его в Boost
— знать зачем нужен виртуальный конструктор :-)
деструктор
Чел возможно и имел ввиду виртуальный конструктор, только в С++ нет виртуальных конструкторов. В этом смысл вопроса, или надо рассказать про фабричные методы? Но фабричный метод — это не виртуальный конструктор. В рамках С++ это некорректный термин.
Есть паттерн «виртуальный конструктор ».
Тем не менее, спрашивать про «виртуальный конструктор» в С++ некорректно, потому что правильный ответ — его нет в стандарте. А то, что вы называете «виртуальным конструктором» — давно известный паттерн «фабричный метод инициализации».
Именно поэтому, когда речь идет о паттернах, лучше спрашивать «как бы вы сделали...»
Ну вот же ш. +2 этому господину было бы на собеседовании, и С++ знает и про фабричные методы тоже.
UP: +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)
Я давно говорил, что идеологи С++ в прошлом рождении были в прошлом рождении средневековыми богословами. И символика кстати та же.
нормальный вопрос. используя логику, можно ответить даже если не знаешь ответ.
Я так не думаю в таком случае прямой вопрос «а зачем спрашивал?»
Таки да вопрос «на виртуальный конструктор» суть есть один из классических «а угадай что я думаю?» (читай «а угадай насколько я тупой?» и ли надо валить прямо с ходу по ходу завалив в морду для моральной компенсации в т.ч. за других сюда попавших или же ж сделать умное лицо и фигу в кармане и вид якобы тут один умный сами знаете кто).
При наличии хоть какой-либо реальной практики реальных случаев спросить «а как бы вы сделали используя логику (и соотв. имеющиеся знания и опыт) вот в таком реальном приближённом случае?» таких имеется масса грамотному спрашивающему можно их даже записывать по ходу возникновения но когда приходит спрашивающий и в тоне спрашивающего спрашивает «тааак чтобы спросить по плюсам? ну что такое полиморфизм?» (здесь можно подставить «виртуальный конструктор») то это уже прямой признак что на проекте что-то не так и там такой же ж бардак как видно из вопросов по реальным случаям которых нет.
Никакаой игры слов, я спрашивал четко и ясно. «Что лучьше виртуальный деструктор или виртуальный конструктор? И чем они вообще отличаются и для чего нужны, какие у них подводные камни»
Ну что-то ведь кроме того «а расскажи с чем ты работал и какие проблеммы решал» спрашивать то надо? (это я тоже спрашивал если чо, и дальше от рассказанного тему развивал в глубь матчасти) У нас, как и у большинства, то в отличии от бея возможности
И правильный ответ «конструкторов не бывает (здесь зависит от глубины обоих и рассказкать почему) а есть вот такие паттерны которые как бы про это» и всё.
Тот же ж вопрос что и на «люки круглые».
Ну дык как и «виртуальный конструктор» и не конструктор и не виртуальный ))
Вообще дело давно было, я честно говоря уже и не помню задавл ли я именно такой вопрос на собеседовании... возможно я и старался быть чуть мение эксцентрично-провокативным. Такое мог либо на форуме писать либо у джунов спрашивать...
Плохой ответ, потому что прост и очевиден и наверняка не совпадает с той формулировкой, которую заучил интервьюер.
Буст не устарел — устарели отдельные его библиотеки, которые из-за обратной совместимости не выкашиваются. Так-то буст это зоопарк из кучи разных библиотек, и многие из них вполне себе актуальны.
..и многие постепенно становятся частью стандарта!
очень часто даже Seniors сдуваются на вопросе касательно конструирования объектов
для того чтобы человек мог работу работать нужно чтобы он знал хотя бы базовые понятия
Пару вопросов по С++ и любой, в том числе Александреску, сдуется
Самое главное, чтоб Страуструп не сдулся на своей же писанине, через пару месяцев после написания.
вопросы из серии «ты это знаешь/не знаешь» это плохие вопросы, если это касается какой-нибудь редкоиспользуемой особенности языка. они ничего не говорят о способностях кандидата писать хороший код.
я считаю больше толка от вопросов на «подумать» (где можно логически выстроить ответ а не угадать), или «код ревью». это очень хороший вид собеседований.
кандидату дается лист кода с ошибками, нужно провести ревью и их найти (чем больше тем лучше).
вопросы ради шутки типа колодцев и расширяющихся небоскребов тоже годятся. только не следует на основании их делать выводы о кандидате :-)
самая адовая «домашка» у меня была — мне прислали код на VС++ и COM, в котором не работали евенты и я ковырялся несколько дней пока не заставил эту хрень работать. ком это вообще жестокая технология («спасибо» Мелкософту что везде ее пропихивал), мало кто его понимает на 100% и ошибки могут быть очень труднодетектируемые. но я справился. в итоге меня не взяли по другой причине (техническую часть прошел)
в данном случае речь была о работе в США со спонсорством релокации, поэтому с их стороны такой шаг наверное был оправдан. хотя в итоге меня не взяли именно из-за денег (менеджер с их стороны так сказал... типа бюджет выработан, сорри, вы нам нравитесь, но мы не можем вас нанять)
сейчас удаленные собеседования проще решаются — через скайп-конференцию
в данном случае речь была о работе в США
Штатовцы генерируют аццкое количество аццкого говнокода опережают их разве что европейцы со своим социализмом и резкой мультинациональной структурой «европейскости» и соотв. подхода к опенсорсу но если выбирать из двух зол то штаты хотя бы практичнее и в т.ч. в признании заслуг «человек пахал».
ком это вообще жестокая технология («спасибо» Мелкософту что везде ее пропихивал)
А по-моему очень няшная вещица имеющая в т.ч. «виртуальные конструкторы в себе» ))
не отказались.
en.wikipedia.org/...indows_Runtime#Technology
Они сами от нее в итоге отказались
Я тоже так думал но нет.
а по итогу многое сильно усложнила и ухудшила.
А это так вообще нет.
ЗЫ: я удивился но там походу ATL жил и даже MFC жив и пользуется.
Да я знаю я как раз в то время жил ))
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 глянуть какой-нибудь.
Могут спросить линуха или сети.
Вообще областей у плюсов много, и в каждой свои требования.
Для того, чтобы пройти собеседование на Junior C++, достаточно зайти на cppquiz.org и решить там все вопросы. Этого будет достаточно, чтобы понять, что C++ — это плохой язык, это неудобный язык, и это язык, который заставляет тратить время на борьбу с ним вместо решения бизнес-задач. После этого можно будет бросить эту затею и начать учить Java.
Но насчёт собеседования я серьёзно — если вы на cppquiz сможете решать задачи среднего уровня (помеченные жёлтеньким), то собеседование вы, скорее всего, пройдёте. Насчёт пунктов, выписанных вами, можете не переживать — это продукт буйной фантазии рекрутеров, на который обращать внимания не стоит. Ни один интервьювер в здравом уме не станет просить джуна пояснить за программную архитектуру.
Почему же — мне вон после C# плюсы очень даже нравятся, даже при том что в шарпе неудобств меньше чем в Java. Например тот же RAII — просто песня, никакого леса из using блоков и прочих finally.
Что интересно — раньше у меня было такое же мнение, но по мере роста уровня навыков (и улучшения стандартных библиотек/компиляторов) плюсы пугают всё меньше а привлекают всё больше :)
В общем — дело вкуса.
Вот, я тут как раз напомню еще про Haxe :)
Ну, он стал чуть менее уродливым, но да — остается очень нескучным.
Кстати, я в предыдущем коменте начинал писать о том что «по крайней мере на плюсах не просят верстать опостылевший ГУЙ» — пожалуй в этом вся суть :)
Впринципе, даже для «мало кода» плюсам есть чего предложить — лично у меня получается что-то среднее без классов но с использованием STL, слишком уж заманчиво. Конечно, если не считать что «мало» — это 100 строк кода и один буфер с байтиками на входе, тогда да, можно и на сях.
Какая наивность. Такие клоуны еще находятся.
Ну, если устроился на работу в цирк — не стоит удивляться что вокруг клоуны :)
Правда, иногда не сразу понятно цирк это или нет.
гуй — он бывает разный. например во всяких ембеддед телевизорах, и в автомобильных системах с тач-дисплеем
бывает и такой, но это не мешает пилить его на Java например
помнится, в девайсах под QNX все на плюсах . хотя это все упирается в мощность железа, возможно в последних таргетах Джава есть
Ты не поверишь они там в этом месте щас активно QML (читай JS) просувают и HTML5.
в «этом месте» == в HB? :-)
Это в Automotive (и не только) HMI
И слава богу, а то на новых тачках каким то образом оказывается убогий устаревший интерфейс
например?
Например рено талисман 2015 года за 40к евро или хёндэ ионик 2017, мало что карты неактуальные, так и юзабельность уступает банальным гугл мапс. Мерсовский навигатор тоже не впечатлил, всё как на древних планшетах.
не надо читать JS. это совсем не JS хотя и поддерживает JS
вы же в курсе оверхеда JVM?
<Толсто>Не больше, чем оверхед самописных аллокаторов, написанных людьми, которые говорят об оверхеде JVM.
вы хоть сами пониали, что сказали?
т.е. оверхеда у явамашины нет?
Не об этом речь. Джава код мендленнее стареет. Т-е поддерживать джава код, который писался 5 лет
А по поводу применения java для gui в ембедеде. А в чем смысл? На java есть что-то хорошее для рисования гуя?
ну если так подумать то на java вообще мало что хорошего есть, но тем не менее гуй рисуют
я не понял: то плюсы ругают за медленное развитие то пеняют что старый код некому поддерживать
а про гуй на яве это не ко мне. я гуй на Qt/QML пишу
то плюсы ругают за медленное развитие то пеняют что старый код некому поддерживать
Ну, у С++ очень много разных проблем.
Джава тоже медленно развивается. Но там меньше проблем с поддержкой старого кода (При том, что самого старого кода поболее будет). Даже интеграл по плечу старого кода скорее всего больше будет.
я никогда не утверждал, что у плюсов нет проблем, но плюсы плюсов (хехе) с избытком перевешивают недостатки (после того, как начнешь разбираться в плюсах, естественно)
Я считаю, что не перевешивают, просто в некоторых областях пока нет ничего другого вообще, кроме С или С++.
Это в каких таких областях?
Поддержка старого кода написанного на С?
в областях, где софтваре инжинер точно знает что он делает
Т-е в областях, которые ограничены знаниями, которые могут поместится в 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 особо значимых вроде не видел, хотя язык достаточно молод.
Да согласен, очень жаль( На реддите писали, что он вышел уже мертверожденным...
Многие ждут c++20, вроде тоже много всего интересного. Но в освоении язык легче не становится)
основное достоинство C++ — шаблоны . java всегда меня бесила своей избыточностью и необходимостью копи-паста. К счастью Java 8/9 с ламбдами и функциональными интерфейсами стала чуть-чуть ближе к шаблонному программированию. Не совсем шаблоны как в ++, но позволяет писать более краткий «шаблонизированный» код с помощью композиции подставляемых блоков кода
Есть же дженерики.
То не то. Дженерики не позволяют вставлять шаблоны кода, а лямбды позволяют
который заставляет тратить время на борьбу с ним вместо решения бизнес-задач
C++ не для бізнесс задач.
C++ — это плохой язык, это неудобный язык, и это язык, который заставляет тратить время на борьбу
с кем боретесь?
обычно с плюсами борются отмеченные жабаскриптом, которые поверили в светлый мир без менеджеров памяти, остальные просто берут подходясчий фреймворк (кьют например) и решают бизнес задачи
обычно с плюсами борются отмеченные жабаскриптом
Не про меня.
с кем боретесь?
Не с кем, а с чем.
С отсутствием нормальных модулей в 2017 году и вообще с разбиением файлов всего проекта на .cpp и .h, прямо как в
И при всём при этом — да, для некоторых задач лучше С++ ничего нет :) Но это не потому, что С++ хорош, а потому что всё остальное для таких задач ещё хуже.
берут подходясчий фреймворк (кьют например)
Который написан на расширении C++ со своим специальным компилятором.
если вкратце, то да, надо учиться, блиню Зато потом открывается море возможностей
и знание С++ тут будет не самое главное. на многие проблемы и их решение смотришь совершенно по другому
нет в кьют специального компилятора. есть препроцессор, который генерирует чистый С++
почемуто препроцессор си вас не смущает? хотя делает ровно тоже самое
если вкратце, то да, надо учиться, блиню Зато потом открывается море возможностей
Учиться — это замечательно. Я люблю учиться, я хочу учиться! Но когда начинаешь лезть в дебри C++, то становится грустно от того, что приходится попусту расходовать умственные ресурсы — исключительно из-за того, что господа в Комитете не смогли подумать головами сами.
нет в кьют специального компилятора. есть препроцессор, который генерирует чистый С++
Кьютишники сами называют его moc — Meta-Object Compiler. От препроцессора C он отличается тем, что понимает синтаксис класса, а не просто заменяет одни слова на другие.
Энивей, это не очень важно, я упомянул это лишь потому, что Qt в контексте обсуждения несовершенств C++ — это немного непонятно, потому что само существование moc как бы эти несовершенства и подчёркивает.
умственные ресурсы они как мышцы — если ими не пользоваться — они деградируют
я знаю какего нзывают? но по сути ето препроцессор. сишный препроцессор тоже парсит и разбирает структуру кода
Достали этим бредом. Подумать не пробовали, прежде чем его ретранслировать.
если вам не нравиться наш бред, придумайте свой, улучшенный бред
вы слишком буквально восприняли аналогию с мышцей
persen?
Модули там уже как раз есть.
А макросы успешно объявлены абсолютно устаревшими ещё в Effective C++ незапамятно-бородатого года выпуска.
Модули там уже как раз есть.
Вы уверены? Можете дать ссылку?
Потому что по моей информации, есть две несовместимые реализации модулей в MSVC++ и в clang, и если это правда, то в реальных проектах модули появятся лет через
А макросы успешно объявлены абсолютно устаревшими
Что не мешает им присутствовать в исходных кодах практически всех проектов на 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 раз!
Не ходи в С++, там тебе поганому навчать. :)
Навчать не шукати бабл-сортом максимум в масиві.
Это да. Интересно, на вайтишных курсах сей нюанс объясняют?))
Даже сортировку сетью?
Есть бенчмарки?
Маєте на увазі, що не шукати взагалі сортуванням (будь-яким) максимум в масиві?
Ну це вже інше питання, ну і так в такому випадку дерево (max heap) зі зберіганням N найбільших елементів зробить свою справу за K * logN (де К — кількісь елементів масиву), що краще сортування повинно бути (K * logK)
Будь ласка, дуже цікаво подивитись на реалізацію складністю O(1) для загального випадку (сферичного коня у вакуумі)
Не простіше тоді завчасно порахувати результат (N елементів, чи один в початковій умові) швидшим алгоритмом, ніж сортування?
Але, на мою думку, один набір вхідних даних — це не загальний випадок....
Я абсолютно з вами згідний в плані сортування бульбашкою малих масивів і загалом що O (n ^ 2) може бути кращим за O (n) при малих n...
Але на практиці зазвичай і не постає питання швидкодії алгоритму якщо передбачаються малі об’єми даних
Так стандартные библиотечные реализации и так используют сортировку вставками для малых массивов
И да для последних двух пунктов желателен свитер с оленями, борода и любовь к пиву.
+ не боятись роботи із мультиметром, осцилографом, логічним аналізатором, та час від часу паяльником :)
від дим від аспірину провокує страшний кашель, цей спосіб залишив історії :) Рідкий флюс зручніший :)
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»!
А взагалі без вміння писати код це все фігня. Напишіть якийсь тетріс/арканоід. Самі в процесі написання ви станете програмістом.
Memory management: delete, кастомные удалители, shared/weak/unique_ptr, RAII, move semantics...
3D math — вычисления с векторами и матрицами.
memory: ещё аллокаторы, работа с сегментами памяти.
3d: ещё с кватернионами, ну и пожалуй это всё. Всё есть в directx api, или в любом другом.
Коментар порушує правила спільноти і видалений модераторами.
Английский и уметь код писать. Знания теории сильно недостаточно, нужен опыт. И явно посерьёзнее чем у вас по русскому :)
Знания «на троечку», помноженные на опыт «нолик без палочки» — дают шансы трудоустройства угадай какие.
Много чего надо. Область плюсов очень большая — от системного программирования до игр. Поэтому выберите ту часть, которая больше нравится, и по ее вакансиям определите, что требуют.
И еще, плюсы очень сложная штука. Порог вхождения высокий. Кроме языка вам надо будет знать фреймворки и теорию, которые применяются в той области, где вы будите работать. Поэтому хорошо подумайте — стоит ли вам туда впрягаться.
Не стоит. Во-первых, целевые области применения C++ сдуваются, и соответственно спрос падает. Во-вторых, при падающем спросе полно специалистов с опытом >10 лет в C++, и даже более того, с меньшим опытом — ещё надо поискать. В-третьих, в лучшие времена в разработку на C++ барышень не брали, в силу гендерной дискриминации, которая основана на вполне объективных причинах, тем более без опыта.
в лучшие времена в разработку на C++ барышень не брали
какое-то, извините, фэнтези.
причем в каждом предложении
Знаю одну, работала со мной в команде, потом выиграла лотерейный билет в Майкрософт :-) на самом деле среди девчонок много умных в математике, но мало кто идет в чистое программирование — либо в теоретическую науку( аспирантура-доктор-преподавание), либо в декрет :-) . Об этом можно долго дискутировать, кто же в этом виноват — гендерные роли, неравенство, социальное программирование и тд, но ответа почему женщины не делают «это» (подставьте любое занятие где доминируют мужчины) до сих пор нет
Потому что им это не нравиться, не интересно и не хотят.
Результат социального давления.
соответственно спрос падает
То то 10 вакансий все никак не можем закрыть
можно список вопросов?
я когда-то коллекционировал c++ interview questions, правда давно неактуально
ну да, так сразу и спалил все вопросы, а вообще я на собеседованиях бываю редко и вопросы задает второй интервьюер
ScorpZ Lapshov
Denys Senkin
Roman Kulchytskyi
Victor Mikhaylov
Maksym Ganenko
Alex Fogol
Volodymyr Lashko
Dmitry Panfilov
schwarzlichtbezirk
Volodymyr Kuksynok
Denys Poltorak
Andriy Kunitsin
Alexander Vostres
Dmytro Hryppa
Alex Koshterek
Denis
Volodymyr Kuksynok
Vitaliy Fedoriv
Oleh Bliznuk
Vasyl Yosypenko
De Money
Леголас Трандуилович
Anton Kovtun
Олексій Пєніє
375 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів