Работа для junior C++ — реально?

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Маленькая предыстория: учусь в университете на специальность Software Engineering. Перехожу на второй курс. Безумно нравится заниматься всем этим, уделяю максимум свободного времени для изучения ЯП(4-12 часов в день), но в приоритете — С++. Каждый день что-то читаю, смотрю, пишу собственные мини-проекты. Ощутимо дальше ушел, чем мои одногруппники(мнение окружения).

Вот ради интереса зашел на фриланс, плюс какие-то work ua и т.п. чтобы глянуть, сориентироваться, куда/что мне учить дальше и, какие в целом требования для программиста на С++.

Сказать то, что я офигел — не сказать ничего. Работа то есть, да, но я искренне понимаю что человеку вышедшего с универа не светит ЗП в 3000$ да и плюс требования к этой ЗП — зашкаливают(ну здесь вполне логично). А каких-то мини-работ на постоянную, чисто за еду, как говорится, просто нету. А опыта набраться хотелось бы.

Не то, чтобы я в себе неуверен, что не достоин ЗП в 3к$, но откровенно понимаю, что мои проекты, это..МОИ проекты, не реальный, от заказчика. Как я думаю, это не одно и тоже.

Возможно ли найти работу junior C++ developer-у? И где лучше/как её искать(может, я не так ищу)? — первый вопрос

Плюс ко всему — требования. Их много, очень. Где-то требуется boost, где-то сетевое, где-то еще что-то... Но просто с чего начинать учить это всё? Или даже, что СТОИТ учить, а потом нужное — просто подтянуть? — второй вопрос

Очень надеюсь на ваши советы. Заранее спасибо за ваше время.
P.s: я работу не ищу, просто присматриваюсь, смотрю в какую сторону развиваться и т.д.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Коментар порушує правила спільноти і видалений модераторами.

Могу ли я называться Junior если я отлично знаю Стек, Динамические двумерные И так далее массивы, Бинарное дерево и его реализация, хеш таблица, очередь, немного про библиотеку SFML/Network?

кстати если кому нннада спрашивают работать в Саудовскую Аравию $10k в мес обещают надо знать си++ / IBM AIX / Sybase / HSM / RTGS / SWIFT и даже UML кидайте профили LI в личку лучше сразу с номерами телефоном я закину рекрутеру а вдруг профитЪ (нет мне не будет ничего сорри)

commandcenter.blogspot.com/...​s-exponentially-more.html
чому С++ники зробили GO та відштовхувалися від С а не від С++

і вишенка на торт

C++ programmers don’t come to Go because they have fought hard to gain exquisite control of their programming domain, and don’t want to surrender any of it. To them, software isn’t just about getting the job done, it’s about doing it a certain way.

The issue, then, is that Go’s success would contradict their world view.

And we should have realized that from the beginning. People who are excited about C++11’s new features are not going to care about a language that has so much less. Even if, in the end, it offers so much more.

Про що я раніше писав С++, це вже як діагноз.

C++’ники це як

tight coupling

, простіше буде «переписати», а ніж «змінювати».

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

хех, запостю
www.quora.com/...​re-written-mostly-in-C-20

Seeing all these C++98, C++11, C++14, C++17, and C++20 variations on similar concepts in a 20+ million line[3] code base could be instructive. Others might perceive that to be the definition of code hell.

Some code in this theoretical kernel will be just regular if then else statements, plain old function calls, with a smattering of smart pointers and range based loops.

At some point, you will have developers that spent a lot of time in C++17 only to find that an entire cpp file has constexpr next to every keyword.

You will see constexpr if, constexpr try catch, constexpr strings and vectors as well as constinit keyword they have never seen before.

Later, some of the developers will read up on the changes coming after C++20.

Most agree with the C++ creator that new language changes are insane[4].

You end up with 5 different groups of developers:

C++98[5] developers justified doing C-Style[6] C++14[7] in practice
C++17[8] developers fatigued from the switch from C++14 will checkout
C++20[9] developers who see they have become syntax chasers rather than productive coders
Former C developers who once again take up actual C development
Former Java/C# devs who decide to stick with the morass they already know
If the Linux kernel was written in C++20, development would eventually grind to a halt. Eventually, kernel development using C++20 would suffer as follows:

Collapse under the weight of an enlarged custom project style guide
Additional weight from C++ Core Guidelines[10]
More debate on code formatting instead of what to write / implement
Image conscious style development overriding substantive progress

.....
Bjarne Stroustrup, the creator of C++ does see problems with the direction of C++. In an interview last year[18], he said that C++ could be like 17th Century Swedish ship called the Vasa[19]. That ship sunk under its own weight.
.....

Most people don’t know that Linus said he tried C++ way back. It was a horrible outcome. Today, an older, more experienced Linus still says C is the best language for a kernel. Further, he has observed that other languages tend to be slanted towards user applications, GUIs, etc.

Цікаво, як це допоможе juniorC++?

наприклад, не йти в С++ (і потім мені подякувати, можна у $$$)

Таке навряд відпугне. Краще вже ту саму цитату Торвальдса, про об’єктну модель в ++.

то стара, а це пишуть, що попробував знову, вже модерний С++, і знову не сподобалося

п.с.
а об"єктна модель івно-авняне, так як дає tight coupling

Зрозуміло, що не сподобався. Це ж Jav...ой, modern C++.

так отож, що С++ скочується в джаву, про яку пишуть що це «для мазохістів легаці кода»

стільки страдань і попаболі у приплюснутих в комєнтах, але вони це полюбляють, стокгольмський синдром...

в реальной реальности средний реальный плюсовый код в реальном продакшине на плюсах выглядит так github.com/hdmdmm/MetaQueotesTask enjoy пока не удалили

средний реальный плюсовый код

это когда 90% проекта написано на Objective C, в плюсовых хедерах пишут using namespace, а тяжеловесный контейнер std::function мешают в одном коде с низкоуровневейшим чисто-сишным кодом?
В какой же страшной реальной реальности ты живёшь! Хорошо, что я живу в другой.

это когда 90% проекта написано на

у тебя проблемы восприятия и субъективной реальности тоже )) скажем реальная реальность таки да так как ты написал с одним только нюансом что общий продукт на 2 млн строк и соотв «на плюсы» остаётся всего ничего пару сот тысяч строк кода такова реально реальная но тут ты снова таки прав :

Хорошо, что я живу в другой.

именно! ))

у тебя проблемы восприятия и субъективной реальности тоже ))

Нит. Я прекрасно понимаю, что обе наших «реальности» субъективны. Человек, решивший работать на плюсах, в зависимости от разных факторов может попасть как в твою, так и в мою.

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

виглядає на С++ писаний лов-левел мікроконтролерщиком (не ардуінщиком)

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

ЗЫ: впрочем это могут быть аирбасы ))

там в ТЗ може бути написано:
«(re)boot time less then 3 seconds on the sky»

и 3 страницы пилотной инструкции последовательности ребута ))

ну її треба просто вивчити, напам"ять, щоб від зубів відскакувало, а руки самі щолкали тумблерами, на автоматі

В реальной реальности ... есть какойто указатель на класс, который дергается из сетевыхх потоков хендлеров ... про мутексы конечно никто ниче не слышал. Чинится таким вот примерно методом: en.wikibooks.org/...​ms/Execute-Around_Pointer и глобальной заменой Type* на TypePtr. Когда продукт доходит до рабочести — вот все такие затыки подобные нужно вычитывать и переписывать...

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

Я раджу тобі спробувати пройти на стажування на літо в Microsoft, Google або іншу велику компанію (майже всі вони мають такі програми) ось як у мене це було dou.ua/forums/topic/22146

Реферальная программа во многих компаниях работает (так можно найти работу)

Ubisoft периодически проводит набор в какой-то свой внутренний «лягушатник», и там как раз в требованиях плюсы и чистый Си, и 10 уровень на сайте с алгоритмическими задачками-марафонами.

Реалии таковы что на плюсах на всю страну три с полвий ваканции(джуниоров). Будешь вкалывать в два раза больше и в два раза меньше получать того же веб разработчика.

Apriorit майже кожен рік проводить курси і набирає С++ інтернів. Слідкуйте за джуніор дайджестом на dou.

1) Многие начинали работать еще в институте, но при этом надо забивать на пары, поэтому — только с 4-5 курса, когда уже не выгонят.
2) Желательно найти какое-то направление, как уже писали, и им заняться. Посмотреть, что хотят в вакансиях по этому делу, учить, пробовать что-то на нем пописать.
3) Можно не брезговать вакансиями в embedded C — потом легко будет перескочить на С++, да и проекты там бывают интересные.
4) Общие знания: английский, многопоточность, оптимизации, дизайн паттерны, кишки операционок, сети, линукс, Питон.
5) Фриланс начинается после 3-5 лет работы на конторе. Так же как и выезд за границу.
6) До 10 заваленных собеседований не отчаиваться. На каждом собеседовании спрашивать у интервьюера что нужно дочитать или доучить и по какой книжке / библиотеке — причем спрашивать до того, как он вышел из комнаты, потому что потом — не словишь.
7) На Питоне намного быстрее программировать, поэтому «пощупать» технологию может быть быстрее именно с ним.

Возможно ли найти работу junior C++ developer-у? И где лучше/как её искать(может, я не так ищу)? — первый вопрос

Да. Но в больших городах я бы смотрел на стажировки-интернелшепы-буткемпы от больших контор. Глобаллождик и Люксофт такое делали.

Плюс ко всему — требования. Их много, очень. Где-то требуется boost, где-то сетевое, где-то еще что-то... Но просто с чего начинать учить это всё? Или даже, что СТОИТ учить, а потом нужное — просто подтянуть? — второй вопрос

Вот это вот все и учи понемножку.
надо
1. Многопоточность
2. Сетевое
3. современные библиотеки, тот же буст
4. QT сейчас в каждой второй вакансии.
+ Linux очень желательно.

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

Чтоб хорошо программировать на с++ нужно быть уже инженером мидл/синьор грейда со многими базовыми понятиями в голове.

WAT?

Не розумію чому ви зв"язуєте це тільки із C++, а не з усіма мовами програмування. На бидлокодити можна на будь-якій мові програмування незалежно від порогу входження і сеніорності поциента: нестача часу, недоліки архітектури, бажання захопити компоненту/софт під себе і стати незамінним на проекті, etc.

Вот например в нашей галерее была вакансия C++ для самоуправляемых автомобилей, но там сениорские требования

А зарплати такі ж як і вимоги?

А зарплати такі ж як і вимоги?

вот за галеру щас абыдна была ))

ЗЫ: интересно какие именно вымогы вы хотите видеть как уровень «як и вымогы»?

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

Тут сказано те, що сказано. Не сініорські посади, а сініорські вимоги.

Чтоб хорошо программировать на с++ нужно быть уже

не надо «хорошо программировать» надо хорошо грести а это уже совсем другая история ))

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

там как раз наоборот сегодня стиль программирования джунов и выше это «джаваподобный си++» а что там внутри под капотом уже не знает никто впрочем может так оно и надо

Часто С++ используется не в одиночку а в связке с чем-то

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

Каждый раз, когда читаю твои комментарии о современных С++ разработчиках, немного впадаю в ступор. Мы точно с одной планеты?) Слишком уж всё отличается от моего опыта и опыта людей, с которыми я работаю. То ли мне так сильно повезло, то ли тебе так не повезло, то ли я не понимаю что тут вообще происходит и хто здесь.

там как раз наоборот сегодня стиль программирования джунов и выше это «джаваподобный си++» а что там внутри под капотом уже не знает никто впрочем может так оно и надо

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

Например, сохранил кто-то итератор вектора, сделал этому вектору push_back, затем полез к объекту по ранее сохранённому итератору — и тут ой, всё покрешилось. Почему? Нипанятна. А в прошлый раз, когда в векторе было другое количество объектов, оно не крешилось. Как так? И сидит бедный «миддл и выше», обхватив голову руками, плачет. «Говорила мне мама, на джависта иди.»

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

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

Например, сохранил кто-то итератор вектора, сделал этому вектору push_back, затем полез к объекту по ранее сохранённому итератору — и тут ой, всё покрешилось. Почему? Нипанятна. А в прошлый раз, когда в векторе было другое количество объектов, оно не крешилось. Как так? И сидит бедный «миддл и выше», обхватив голову руками, плачет. «Говорила мне мама, на джависта иди.»

на Rust-сіста

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

де саме, на якому компілері, платформі, ... фазі місяця

Как по мне, плюсы подталкивают разработчиков.

до оверінжинірінга

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

шта?

де саме, на якому компілері, платформі, ... фазі місяця

На будь-якому. Деталі типу «коли саме потрібно виконувати реаллокацію» залишаються платформозалежними, але інші принципи — ніт.

до оверінжинірінга

Тільки на твоїй галєрі, де на нормальних розробників немає грошей, тому наймають джунів і продають їх як мідлів/сіньйорів.

шта?

Та!

Деталі типу «коли саме потрібно виконувати реаллокацію» залишаються платформозалежними

OMG

Тільки на твоїй галєрі,

в мене нема галери

на нормальних розробників немає грошей, тому наймають джунів і продають їх як мідлів/сіньйорів

знову «мімо»... приплюснуті: YAGNI ? — «не чули, не знаєм, знати не хочем»

OMG

Не знаєш про std::vector? Ну, якщо він тобі в роботі не потрібен — це окей. У ембеддеда своя специфіка, динамічні аллокації пам’яті досить обмежені. Можна зрозуміти.
Але в такому випадку не бачу сенсу розжовувати тобі той приклад. Я впевнений, що будь-який більш-менш досвідчений програміст на плюсах, який працює на проектах, де використовуються динамічні аллокації і контейнери типу вектора, здатен зрозуміти, про що я казав.

приплюснуті: YAGNI ? — «не чули, не знаєм, знати не хочем»

«Приплюснуті» може й такі. Схоже, що інші на співбесіду на твою не-галеру чомусь не приходять. Може, чимось відштовхує ваша команда хороших плюсовиків, от в результаті ти й отримав таке спотворене враження.
Проте до нормальних C++ девелоперів рівня міддла і вище твої стереотипи відношення не мають. (Згоден, що джуни через брак досвіду оверінжинірити ще можуть, але це у них через рік-два проходить, коли набираються досвіду. Сам таким був на старті кар’єри.)
А зараз я надто лінивий, щоб писати зайвий код, створювати додаткові рівні абстракції, ліпити якісь темплейти і т.д., коли без цього можна обійтися. Якщо вже на другий раз доводиться писати щось дуже схоже на те, що я писав раніше, — от тоді... тоді я тупо дублюю код з мінімальними правками, так. Бо я лінивий :)
І вже коли на третій раз доводиться робити щось надто схоже на попередні два шматки роботи — от тоді вже можна задуматися про створення більш загального рішення.

«Приплюснуті» може й такі. Схоже, що інші на співбесіду на твою не-галеру чомусь не приходять. Може, чимось відштовхує ваша команда хороших плюсовиків, от в результаті ти й отримав таке спотворене враження.

не переймайся, нема в мене галери (пишу вдруге)

Не знаєш про std::vector? Ну, якщо він тобі в роботі не потрібен — це окей.

не зрозумів, що ти хочеш цим сказати

хоча, я догадуюся, що ти натякаєш, що ти і твої колєгі — супер вумні С++
гребці, а де-інде — тупуваті.

не зрозумів, що ти хочеш цим сказати

Це була моя відповідь на

стиль программирования джунов и выше это «джаваподобный си++» а что там внутри под капотом уже не знает никто впрочем может так оно и надо

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

хоча, я догадуюся, що ти натякаєш, що ти і твої колєгі — супер вумні С++
гребці, а де-інде — тупуваті

Не супер. Просто вумні. І ти вумний. І всі інші. Просто кожен вумний в своїй області.
А от на тупуватість інших я не натякав і близько. На звинувачення в чиїйсь тупуватості тут більше була схожа та фраза про «что там внутри под капотом уже не знает никто», з якою я виразив свою незгоду.

все правильно ти написав, але це в «ідеальному світі»,
в реалі «маємо, що маємо» (

«джаваподобный си++»

)
внаслідок розвитоку деградації С++

Схоже, що «реал» у мене і моїх знайомих C++ девелоперів надто сильно відрізняється від «реалу» деяких інших людей. Як раз сьогодні Алекс запостив чергове підтвердження цього: dou.ua/...​ign=reply-comment#1650600

це інша крайність, коли лов-левел С-ника садять писати на Javi C++

Схоже, що «реал» у мене і моїх знайомих C++ девелоперів надто сильно відрізняється від «реалу» деяких інших людей.

манямірок

манямірок

Як скажеш:

Схоже, що реал у мене і моїх знайомих C++ девелоперів надто сильно відрізняється від манямірка деяких інших людей.
внаслідок розвитоку деградації С++

Внаслідок деградації окремих девелоперів, з якими тобі доводилось мати справу. Не мова програмування винна, що до вас ідуть саме такі.

вони не йдуть, їх наймають топи

Тоді так: не мова програмування винна, що сами таких девелоперів до вас наймають топи.

«Других писателей у меня для вас нэт»

Й.В.Сталін

C++ и джуниор как по мне несовместимые понятия.

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

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

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

це уже сеньор

Так.
Я скоріше про те, що джун зазвичай взагалі цих речей не вміє (і на такі скілли з його боку ніхто й не розраховує), сіньйор вже вміє. А міддл десь посередині.
І ось саме такі речі в першу чергу кажуть про «сіньйорність» девелопера, ну й можливо ще якісь дуже специфичні хард скіли — але ніяк не знання базової «крос-платформєнної» частини C++, яку можна прочитати в будь-якому підручнику на 800+ сторінок і зашліфувати Майєрсом. Такий рівень знань плюсів повинен бути і в джуна.

Возможно ли найти работу junior C++ developer-у?

Возможно, плюсы гораздо сложнее различных (.*?)script, джав, котлинов, питонов и прочего, по сему джунотолкучки там поменьше. Другое дело, что всё качество программы ложится на плечи программиста и сломать плюсовый код неосторожным изменением не просто легко, а очень легко и по сему джунов брать иногда экономически не выгодно. По этому ищите не работу а стажировки и интернатуры, там на вас не удут возлагать супернадежд и требований.

Вторая беда, что под C++ понимается широкое множество языков — C++03,11,14,17, а кое где ещё и С. Если писатели библиотеки заморочились с макорсами или шаблонами, это сопоставимо с изобретением ещё одного диалекта, и выучить всё что понавыдумывали не получится, так что наиболее выгодным вариантом будет учить основные вещи

Третья беда — оно тебе надо? Зачем тебе плюсы когда вокруг столько современных и более качественных вещей.

Увы но нет. В с++ же вводятся фичи так чтобы они не разламывали то что было раньше, значит хвост с 80-мохнатого года от С с классами тянется в 2019 год. И что ты не делай, не ломая то что тогда было заложено, не получится. Что именно плохого в предыдущих и текущих стандартах можно расписывать на нескольких сотнях страниц, писать тут их все желания нет.

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

У комитетчиков С++ очень интересные представления о хорошем. В нынешнем С++ больше плохого чем хорошего. Основная беда — отсуствие строго декларируемого, проверяемого компилятором безопасного подмножества языка в котором на грабли наступить нельзя(а такой сделать вполне можно ценой некоторых ограничений в виде лин. типов и других моделей, даже Страуструп об этом говорил). Беды поменьше — нет никакой возможности застраховать себя от стрельбы в ногу (чтобы код для стрельбы в ногу не компилился), надо контроллировать вручную. Нет компайл-тайм рефлексии (и API для работы с AST прямо из языка, и вот вам никаких автокодеков из класса в разные форматы) и компиляторных плагинов. Ну а про громоздкость, неидиоматичность и контринтуитивность можно даже не говорить, это так, мелочи по сравнению со всем остальным.

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

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

так это же ж руст!

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

ще один аргумент плюсовиків (і не тільки) — «руст сирий і не взлетить, так не тратьте куме сили...»

Так уже ж взлетел, много чего написано.

не переконливо, вважають за хіпстерську хайпову мову

хіпстерську

Хипстерства как такового не существет в IT. Существует инертность мышления, риски на внедерние, сырость и. т.д. Но преобладающее это инертность мышления.

Вот это более убедительно? github.com/...​aritytech/parity-ethereum

це не мене переконувати, а закостенілих Сників і С++ників

взлетит как буревестник недавно

хз., он з Копенгагена пишуть, що шукають контракторника на Rust 65..85 ойро\година

чего такой разброс? почти 30%
меня плюсовыми вакансиями задалбывают

я про не зльот раста...

меня плюсовыми вакансиями задалбывают

а по дэньгам шо?

зависит от страны

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

там, навіть, 60к починають стогнати, чур їх, ніщебродів

и шото нормальное? бо я на расте видел только крипту, видать того что на нем есть пару опенсорс проэктов

github.com/NieDzejkob/fake-static
тут безопасного раста подвезли

тут безопасного раста подвезли

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

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

Ну смотри. Вот мне надо создать массив некопируемых объектов с кучей параметров в конструктор.
Попытался поюзать initializer lists из С++11:
chans_{{1, *this, transport_}, {2, *this, transport_}},
В результате все равно пытается вызваться конструктор копирования. А он закрыт, чтобы в других местах объекты не попортить во время работы.
Итого: буду откатываться к старой доброй двухшаговой инициализации из С++98: пустой конструктор + void Init(x, y, z);
Толку от этих всем новых модных стандартов, если нормально не могут создание массивов сделать.

Треба конструктор переміщення додати в клас і все заведеться

А якщо я заблокував усі конструктори копіювання та operator= щоб не побити стек таймерів та вказівники на цей об’єкт? Розблокувати їх заради створення в масиві? А потім десь в іншому місці забуду & в сигнатурі метода, піде копіюваня за значенням (якщо в таймері конструктори копіювання не заблоковані), і буде каша. А якщо в таймері копіювання заблоковане — то все одно не спрацює.
Об’єкт працює з залізом, і не має копіюватись.

Це уже проблеми і обмеження вашої архітектури.

))))
Себто, С++ не призначений для певних архітектур та певних задач?

Звісно не призначений для певних задач. Наприклад писати сайти на C++ я б не став.

Ви ж самі вирішили заборонити переміщення і копіювання об’єктів певного класу і в той же час розкидатися вказівниками на такі стекові об’єкти.

1) Він не стековий, а напівстатичний
2) Як Ви пропонуєте робити таймера в об’єкті, не залишаючи в системі вказівник на нього?

напівстатичний

Як як?

Використовуйте shared_ptr і буде вам щастя.

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

Я писав про move constructor

напівстатичний = виділений в хіпі з тривалістю життя = тривалість життя програми. Себто, створюється на старті й ніколи не знищюється, чи знищується при виході. Надає можливість використання поліморфізму, на відміну від справжніх статичних об’єктів.

shared_ptr

для обёэкта, котрий має існувати в одному екземплярі — цікаве збочення. Все одно не розумію, як таймер має викликать колбек через shared_ptr.

І яка має бути семантика

move constructor

коли вказівник на об’єкт є в системі, і навіть може бути використаний іншим потоком в момент виклику конструктора переміщення.

Поділіться будь-ласка ссилочкою на опис даного підходу. На скільки я зрозумів напівстатичний у вас — цу глобальна змінна яка лежить в heap?!

для обёэкта, котрий має існувати в одному екземплярі — цікаве збочення. Все одно не розумію, як таймер має викликать колбек через shared_ptr.

Ну напишіть свою обгортку поверх вашого об"єкта і хай копіюється скільки завгодно (подивіться на паттерн pimpl).

коли вказівник на об’єкт є в системі, і навіть може бути використаний іншим потоком в момент виклику конструктора переміщення.

Здається у вас є деякі проблеми з порядком ініціалізації, якщо сусідній поток уже може використовувати об"єкт який не готовий до використання

статик, функцию помещаем именно в h файл:

inline Type& mystatic()
{
static Type obj;
return obj;
}

создает 1 раз при первом обращении ...
можно сделать shared_ptr obj и тогда гдето в начале самом

mystatic().reset(new Type(args));

для обёэкта, котрий має існувати в одному екземплярі — цікаве збочення.

сделай unique_ptr

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

Звісно не призначений для певних задач. Наприклад писати сайти на C++ я б не став.

архаизмЪ уже даже на AWS есть фреймворк

Так там все копіюється)
shallow and deep copies

Якщо конструктор копіювання закритий/видалений, то не буде копіюватись.
coliru.stacked-crooked.com/a/42addc03fc787953

Звичайно, я про те, що move не move. Адже це лише концепція рівня мови, для копіювання глибокого(повністю) і не глибокого(смикнути адрес собі).

deep & shallow copy це якраз про копіювання. Наприклад є клас який відкриває файл і працює з ним: shalllow copy буде тоді коли ми просто скопіюємо собі handle відкритого файла і будемо з ним працювати, а при deep copy — ми відкриємо цей же файл і отримаємо свій власний handle на нього.

Чого тоді копіювання адресу на інший шматок пам’яті не є shallow?
(Дивно)

воно і є shallow copy. Нюанс в тому, що переміщення — не копіювання.

Добавить явный конструктор, котоорый принимает

2, *this, transport_

массив описать массивом
const Type chans[] = {};

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

Якщо казати про зручність С++ та якщо казати про контракти — навіщо мені визначати мув конструктор для класа, котрий НІКОЛИ не має переміщатись? Чому нема нормального варіанта просто викликати конструктор з параметрами в масиві? Може, placement new ще запропонуєте? Це через нього можна зробить, але усе це — збочення.

Спасибо. Тупо не понимаю: пример компилится, и если вставить ко мне в исходники — тоже. Когда делаю то же самое со своим классом — не компилится.

Ну значит чет не так в вашем классе. Например, обратите внимание, как я удаляю конструкторы, это обязательно должно быть public. Проверьте const везде, вы передаете *this, для const массива ето должноы быть const this и вызов только const методов.

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

ЗЫ: я нашёл судя по твоему коду ты вероятно юзаешь не «сишный массив» а std::vector и там таки да не компилится

Собственно, вот то, что у меня не компилится cpp.sh/3dsck
Перестало компилиться после наследования.

Ну можно разрешить move, обычно это безопасно:
cpp.sh/7d2df
Хотя, если есть скажем std::atomic — там move удалены, потому что есть несколько видов доступа к памяти. Прийдется явно описывать, под задачу.

Да уже интересно, что это за грабли. Пойду на stackoverflow.
Спасибо, что рассказали — думал, in-place инициализация массива работает только с POD.

В общем, проблема при следующих условиях:
1) Есть класс А с закрытыми конструкторами перемещения и копирования, и виртуальным методом (не POD).
2) Есть класс В, содержащий массив объектов А со списком инициализации в списке инициализации конструктора.

То есть:
class B {A arr_[2];};
В() : arr_{{1}, {3}} {} // не компилится
А arr[2] = {{1}, {3}}; // компилится

Думаю где-то какой-то пункт в стандарте С++ указывает различное поведение для разных методов инициализации массива.

Там тонкость с инициализацие массивов есть, как полей класса.
Скажем поле

Arr a[10]{0} — выставит все нулями, а вот
Arr a[10]{1} — уже не работает, помоему первый элемент станет 1 ...или ваще не скомпилится..
Точнее не помню, помню, что решил не делать массивы-члены класса для себя :)
У меня даже для инита массивов шаблон есть (когда весь массив в 1 значение)

template
void for_each_array(T(&arr)[N], const Pred& func)
{
for (size_t i = 0; i < N; ++i)
func(arr[i], i);
}

template
void init(T(&arr)[N], const T& val)
{
for_each_array(arr, [&val](T & a, auto)
{
a = val;
});
}

Можно заменить массив на std::vector и использовать
B::B()
{
vec.emplace_back(3, 5);
vec.emplace_back(4, 7);
}
— вот это будет что вы хотите — создание элемента без копирования

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

вот так можно:
cpp.sh/8jgfb

но все равно не скомпилируется, ему нуженб будет move конструктор, хотя вызыватся он не будет из-за reserv. Но для компиляции нужен)) — можно засунуть его в приват и зафрендить B

но сути не меняет ты просто делаешь .emplace_back

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

ну это читерство ))

Почему? Просто правильный контейнер ))) Если там последовательный доступ «всех», то можно на list заменить для скорости.
Читерство = это визуалка делает, где у вас вектор скомпилился.

если пользоватся новыми фичами то тогда уже по полной
cpp.sh/6kwq7k
и не спрашивай почему оно компилится

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

И че, ответа нет? :)) ...сорян, у меня тут другой форум флудил в почту — не видел имейла про комент :)

хм прикол у меня это компилиццо ))

VC2017 это компилит надо потыкать палочкой в GCC

GCC действительно не компилит прикол ))

карочи прикол интересный формально тут GCC как раз делает всё правильно «по-честному» а вот VCC делает какой-то trick и вызывает конструкторы в массиве напрямую emplace

но это похоже только одна сторона почему-то в этом месте даже если убрать массив GCC это собрать всё равно не может и требует сперва конструктор по умолчанию для member

прикольная шняга! lil

Ну мове-конструктор нужен, на случай изменения размера вектора. Вот если сделать reserv, то он не вызовится ниразу, но для компиляции таки нужен. На SO предлагают другие контейнеры, типа list — в них «переразмер» не происходит.

неа )) там жопа у gcc конкретно у компалера я уже проверил он только _требует_ конструктор но при этом никак его не вызывает т.е. с вызовами всё ок вызываются только соотв. конструкторы а не то чтобы «сперва по-умолчанию» но при этом для случая если там массив как member он требует наличия move constructor

т.е. не компилится в GCC но если «сделать чтобы кампилилось» то работает одинаково и в GCC и в VCC

Ну мове-конструктор нужен, на случай изменения размера вектора.

там жы ж не вектор даже там именно просто «сишный массив» в этом фишка )) он не может «изменить размер»

Вот в том и дело, что С массивы всегда инициализированы. Ну т.е. в С конструкторов не было — просто память, в С++ — конструктор по умолчанию. Там не может быть элемента, «которого нет». Поэтому и требуется конструктор. Поэтому move семантику изобретали, что раньше оно копировалось.
И вообще, совсем раньше, нельзя было иначе массив объектов создать, чем T(), так что приходилось делать массив указателей и каждый создавать в цикле.

Но все равно мне не понятно, почему массив «не поле класса» создается ок, вот например:
cpp.sh/2arf

нет конечно

и компилятор «студии» тому доказательство

ЗЫ: опять же ж как я и говорю что gcc runtime таки правильно

Но все равно мне не понятно, почему массив «не поле класса» создается ок

дык в этом же ж и фишка у VCC там с этим всё ОК это у GCC траблы

Так не використовуйте ці збочення. У світі ще багато прекрасних мов програмування)))

Покажіть свій код колегам і можливо хтось вам підкаже як вирішити вашу проблему. А тут без коду ми можемо довго спорити як має бути правильно ;)

Так че по результату? Репортить баг на GCC?

З теоретичної т.з. — не знаю, може і дозволено вимагати наявності копіювання в тому випадку. З практичної — якщо вам від цього в роботі полегшає, то пишіть. Тобто, якщо ви зможете витягнути новий gcc через пару місяців і вам все ще буде якось це актуально.

Та я думав може це карму поліпшить.
Новий GCC точно не затягнемо — в нас кросс-компіляція. Та й мені воно не дуже треба — спокійно обхожуся C with classes. Просто спробував поюзать С++11 і зразу граблі.

с std::array и инициализацией сомнительной красивости {{{1,2},{3,4}}} хавают и гцц, и кланг, и мсвц: godbolt.org/z/qC0YCn

У тебя POD, с ним компилится.

Ну смотри. Вот мне надо создать массив некопируемых объектов с кучей параметров в конструктор.
Попытался поюзать initializer lists из С++11:
chans_{{1, *this, transport_}, {2, *this, transport_}},
В результате все равно пытается вызваться конструктор копирования.

Можно пример кода, иллюстрирующий эту проблему? По описанию что-то не могу догнать, что имеется в виду. Какие некопируемые объекты, в какой конструктор...
Попробовал набросать что-то такое, но, судя по всему, это не то godbolt.org/z/w4-7OR

Ааа, ты про сценарий, когда в моём примере вместо обычного массива будет std::vector, чтоб оно дёрнуло конструктор, принимающий std::initializer_list?
godbolt.org/z/FjUbAD

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

An object of type std::initializer_list is a lightweight proxy object that provides access to an array of objects of type const T.

The underlying array is a temporary array of type const T[N], in which each element is copy-initialized (except that narrowing conversions are invalid) from the corresponding element of the original initializer list. The lifetime of the underlying array is the same as any other temporary object, except that initializing an initializer_list object from the array extends the lifetime of the array exactly like binding a reference to a temporary (with the same exceptions, such as for initializing a non-static class member). The underlying array may be allocated in read-only memory.

(en.cppreference.com/...​/utility/initializer_list)

Вот, ещё тут можно почитать статейку на эту тему:
blog.knatten.org/...​rs-of-non-copyable-types
Хотя и цппреференса для понимания данного вопроса более чем достаточно.

Не понимаю, как эти

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

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

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

Собственно cpp.sh/3×2ox
1) Почему компилится:
Test test[2] = {{1, 2}, {3, 4}};
и не компилится
B() : test_{{1, 2}, {3, 4}} {}
2) Почему обе строки компилятся, если в class Test нет виртуальных функций

2. Бо вони POD, звідси вони є aggregate. Якщо є vtable це вже не aggregate і не можна використати aggregate initialization.
„An aggregate is an array or a class (Clause 9) with no user-provided constructors (12.1), no brace-or-equal- initializers for non-static data members (9.2), no private or protected non-static data members (Clause 11), no base classes (Clause 10), and no virtual functions (10.3).” www.open-std.org/...​cs/papers/2013/n3605.html

Тут є

user-provided constructors

та наслідування, здається, не заважає.

Якщо наслідується POD, тоді все норм.

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

А ещё я бы задал вопрос на stackoverflow. Ты ещё не задавал? Если не, то я могу оформить, и потом поделиться здесь ответом.

Мой предыдущий коммент был скорее о моём удивлении, почему подобные проблемы отнимают столько времени. У меня такого пока не происходило. Чтобы я стопорился на бизнесовой задаче из-за непонимания какой-то бизнес-логики или попыток разобраться сложном в легаси коде — да, было. Но именно из-за вредности C++ я пока не застревал. Хз, может везло, может пока опыта мало (коммерческого у меня в сумме лет 5).

Если бы я столкнулся с такой проблемой, то, будучи человеком ленивым, я бы сначала попробовал альтернативные способы написать этот код.
Вот, я попробовал, и минут за 15 нашёл решение: godbolt.org/z/qC0YCn (dou.ua/...​rums/topic/28095/#1650276)

Код изначально был написан по-другому, я решил его упростить)

Понял.

Что насчёт вопроса на стековерфлоу? Ты не спрашивал? Если не, то можно я задам с твоим примером? Ибо самому интересно стало, а рыться в стандарте лень.

Не спрашивал. Если хочешь — задай. Я послезавтра в отпуск.

Запостил: stackoverflow.com/...​-does-such-code-fail-to-c

Мой Velykobrytanian language далеко не пёрфект, но как правило люди меня понимают, так шо ждём-с.

Там еще важно, что у вложенного класса есть виртуальный метод

Да, мне как раз в комментах один чел на это указал, мол, что без виртуального компилится. Я подправил вопрос.

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

Спасибо. Будете баг на GCC писать? Там много мороки.

Вообще, аналогия:
Если в проекте есть модули, которые как-то себя ведут, и очень тяжело (или никто не может) понять, почему это происходит, баг это или фича, и зачем оно так — мы говорим, что проект в плохом состоянии, модули, вероятно, дешевле переписать, чем рефакторить, и какой буратино до такого довел.
Если на то, чтобы понять, поведение ядра языка — баг или фича, и какое правильное поведение в конкретном случае, не достаточно 3 дней 3-4 человек на ДОУ с 5+ лет опыта этого языка у каждого, нужно постить на stackoverflow, там тоже не знают, говорят ставить таг language-lawyer так как обычные люди не понимают, как инициализация массива должна работать, потом приходит эксперт, и говорит, «я считаю, что это баг» — значит, это современный (удобный) развивающийся язык.

Спасибо. Будете баг на GCC писать? Там много мороки.

Не писал раньше таких, но я погуглю. Если не отнимет слишком много времени, то, думаю, напишу.

Со вторым абзацем не совсем согласен. Потому что наш вопрос касался тёмных закоулков языка.
Типы, которые нельзя ни копировать, ни мувать, но при этом представленные не глобальными/статическими переменными/синглтонами — штука довольно редкая. Мне с такими типами ни разу сталкиваться не приходилось: либо класс использовался как что-то глобальное (не в качестве полей другого класса), либо у него был хотя бы мув конструктор.

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

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

У вас доволі складні вимоги. В таких місцях завжди баги будуть. З простими модулями — проблем нема, у вас не було ніяких проблем із тим, щоб таки написати той шматок. У інших мовах у вас не буде стільки фіч, або буду аналогічна кількість багів.

проблема в тому, що ніхто не розуміє, як воно має бути. Себто, фічі настільки неінтуїтивні, що їх не можна відрізнити від багів.

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

Щось мені здається що в Пітоні та Джаві простіше — можна зразу зрозуміти, що має працювати, а що — ні.

Але там ви таке і не зробите. Менше фіч — менше проблем, але і менше ж фіч.

Ця ініціалізація працює коректно не тільки для POD. Вона здатна викликати конструктори майже будь-яких достатньо складних класів, і зазвичай з цим ніяких проблем не трапляється.

Тут проблема була саме у змішуванні в одному класі двох вимог, які надто рідко можна зустріти разом:
1) повна відсутність будь-яких копі- та мув-операцій;
2) створення об’єктів цього класу всередині нестатичного масива в іншому класі.

Зазвичай, якщо вже клас не мувабельний, то його об’єкти або є синглтонами/глобальними, або з ними взаємодіють через поінтери, а не напряму (наприклад, створюючи їх динамічно).

А так, маємо корнер кейс, про який практично ніхто не задумувався — от розробники гцц і помилково зав’язалися на мув конструктор в цьому сценарії, розраховуючи, що в даному випадку він точно буде.

Це як раз випадок динамічного створення складного синглтона (маємо ієрархію великих класів, кожен з них всередині має кілька залізо-залежних компонентів). Фабрика на старті створює конкретний великий клас залежно заліза, котре підключене до системи, а він в конструкторі створює свої компоненти.

Ех( Складно. Якби я працював на вашому проекті і бачив всю картину, а не тільки спрощений приклад коду, — можливо, придумав би якийсь інший спосіб зробити те саме, але без засовування немувабельних об’єктів в масив всередині іншого класу

кожен з них всередині має кілька залізо-залежних компонентів)

А те, які саме компоненти треба створювати, стає відомо лише у рантаймі? Чи це компайл-тайм інфа?

в рантаймі залежно того, що саме втикнуто в USB порт роутера, або що в конфігі написано.
немувабельні об’єкти — це нормальний контракт в стилі KISS коли цей об’єкт десь зареєстрований за вказівником. нащо мувати сінглтон? такий мув є багом, нехай його компілер ловить.

Не зовсім зрозумів. З попередньої переписки я подумав, що (якщо мапити на наш приклад) клас B є тим самим сінглтоном

Це як раз випадок динамічного створення складного синглтона

, а об’єкти класу Test всередині нього — це якісь його частини, які не гріх було б і мувнути.

коли цей об’єкт десь зареєстрований за вказівником. нащо мувати сінглтон?

Так тут мова йде про B чи Test? Чи і про одне, і про інше?

B — це синглтон.

Test — частини, котрі працюють з залізом та підписані на таймера. Вони мультитони (проксі обмежених ресурсів), тому їх не можна копіювати, бо з одним залізом почне працювати кілька об’єктів. Також їх не можна мувати, бо вони підписуються на таймера, і коли таймер спрацює, колбек буде вкликаний за вказівником на метод класа.

Тепер зрозумів.

Тоді й дійсно варіантів небагато. Якби я не нащупав те рішення з std::array, теж думав би про placement new.
Ну а що, майже читабельно (нєт): ideone.com/Zd4rFY

я виніс ініціалізацію Test в окремий метод, котрий викликається в циклі для всіх елементів масиву в конструкторі B. Але для цього не треба С++11

А що, C++11 у вас не доступний?
Бо використання std::array могло б заворкераундити багу компілятора меншими зусиллями, ніж зовнішня ініціалізація.

Доступний, але наразі не використовую. От спробував — наступив на габлі.
STL нема.

З цими конкретними граблями тобі максимально не пощастило :(

STL нема

Що, навіть std::array прикрутити не можна? Це ж не динамічний контейнер. Ніяких аллокацій, ексепшенів і т.д. — просто обгортка над звичайним масивом, що дає йому STL-like інтерфейс.

Та можна, але мені воно все одно — довше буду прикручувати std::array ніж робить Init(), котрий вже працює, і через котрий таке раніше усе робили до initialization lists

Там ще є третя умова — клас не «POD», із явним деструктором (virtual там навіть не треба). Ваш випадок, або близький там мабуть тестився, бо ми ж дрочимо, щоб не було зайвого копіювання.

із явним деструктором (virtual там навіть не треба)

Хм. Дійсно, справа не в тому, що деструктор віртуальний, а в тому, що він взагалі визначений явно. Треба буде оновити опис баги і відписатися на стековерфлоу тому чєлу, що казав «без virtual компілиться».

бо ми ж дрочимо, щоб не було зайвого копіювання

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

на наявність хоча б мув-конструктора компілятор часто розраховує

Це дуже пов’язані речі, я б не робив акцент на мув. Все одно навіть мув — це копіювати пам’ять, це оверхед, Ще там є якісь правила і навіть табличка з ними, що якщо видалений, або явно визначений хоча б копі, то немає мув ітп. І assign з move assign там теж присутній. Якщо вам критично що там автоматом генерується у якому випадку, а що ні, то погугліть це, то макро 100% більше ніж треба. І у вашому прикладі також достатньо залишити лише копі, або лише мув. Це пофіг компілятору, але може будете розумніше виглядати, хоча перевіряючим теж повинно бути пофіг, там достатньо явно усе.

Не знаю, наскільки забагованим має бути компілятор, щоб лізти в копі-конструктор там, де можна обійтися мув (якщо він є).

Є в мене про це страшилка на ніч, може ввечері розповім, яко цікаво. Там ще nothrow присутній та важливий для сюжету. MSVC компілятор був. Практично значення не те шоб було велике тієї страшилки, щоправда.

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

Звичайно, знаю про неї. Але я не про це.
Я мав на увазі, що, коли обидва конструктори однаково доступні (або однаково видалені), компілятор повинен надавати перевагу мув-конструктору скрізь, де це можливо.

І у вашому прикладі також достатньо залишити лише копі

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

але може будете розумніше виглядати

Я надаю перевагу більш явному коду. Краще я напряму напишу, які операції я хочу визначити, а які відалити, ніж буду розраховувати на правила неявної генерації.
Хоча це вже «вкусовщіна» і справа прийнятих код конвеншенів.

хоча перевіряючим теж повинно бути пофіг

Амінь.

Люблю такі страшилки :) Розкажи, як буде час!

Це випадково не про std::vector, який до якоїсь там версії msvc завжди викликав мув-конструктор для релокації своїх елементів (незалежно від того, чи був він noexcept) — таким чином порушуючи гарантію strong exception safety у випадку, коли мув-конструктор якогось елемента таки кинув ексепшен?

про std::vector, який до якоїсь там версії msvc завжди викликав мув-конструктор для релокації своїх елементів (незалежно від того, чи був він noexcept)

Ага, воно! То щоб мув таки був, то зазвичай треба ще й noexcept йому додати не забути.

То щоб мув таки був, то зазвичай треба ще й noexcept йому додати не забути.

Ну, це класичне правило, з багами компілятора не пов’язане. Про нього ще Майєрс писав, царствіє йому... пєнсіонноє.

Якщо у класу є і копі-конструктор, і мув-, то вектор повинен викликати:
— копі-конструктор, якщо мув-конструктор не позначений noexcept;
— мув-конструктор, якщо він noexcept.

І це цілком логічно, тому що стандартна бібліотека при можливості хоче гарантувати нам strong exception safety («якщо операцію не вдалося виконати до кінця, об’єкт повинен залишитися в своєму початковому стані»).
Можна мувнути всі елементи по черзі і бути впевненим, що ніде в середині операції не вилетить ексепшен, — значить муваємо. Нема такої гарантії — значить спочатку створюємо копії елементів, а вже потім видаляємо оригінали.

Звідси й відома порада завжди робити мув-конструктори noexcept, коли є така можливість з точки зору того, що вони роблять під капотом.

Якщо ж у класу є тільки копі-конструктор або тільки мув-конструктор, то він і буде викликатися, адже у вектора не буде вибору. У випадку не-noexcept мув-конструктора за відсутності копі- строгої гарантії не буде, і з цим вже нічого не зробиш.

А на старому майкрософтівському компіляторі (здається, VS 2012 чи 2013), наскільки я пам’ятаю, бага була як раз в тому, що він на noexcept взагалі не дивився. І за наявності мув-конструктора завжди обирав його, навіть якщо той може кинути ексепшен (і відповідно залишити вектор в розламаному стані посеред релокації). Навіть коли поряд був копі-конструктор, який в цьому випадку і потрібно було обрати.

P.S.:
Сподіваюся, до C++20 вони зможуть стандартизувати is_trivially_relocatable (quuxplusone.github.io/...​ng-trivially-relocatable). Офігєнна штука, якою у різних компаніях, де полюбляють писати свої альтернативи std, вже років 15-20 як користуються, — а в стандарт її додати досі не спромоглися.

А ось страшилка від мене. Про тайп_трейти в кастомних імплементаціях «альтернатив std». Випадок з реальної роботи.
stackoverflow.com/a/57591546/2999946
Сорі за криву англійську, мені дуже соромно (ніт).

З макросом, що блокує лише копі-конструктори також не компілиться
// Copy ctor and assignment operator are forbidden
#define DISALLOW_COPY_AND_ASSIGN(name) \
private: \
name(const name&); \
name& operator=(const name&);

Так, я про це ж і написав:

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

Что-то запостил: gcc.gnu.org/...​lla/show_bug.cgi?id=91499
Надеюсь, этого будет достаточно. А то снова расписывать простыню текста, как вчера на стековерфлоу, мне уже лень.

Но именно из-за вредности C++ я пока не застревал

х.з. я постоянно именно этим и занимаюсь ))

не компилится
течёт
ведёт себя странно и не так как ожидалось как ожидалось сказать уже никто не может потому что нет уже те кто ожидали как
не компилится на других компиляторах (вотЪ)
не компилится на новой версии компилятора (+stl boost и ко.)
не компилится с новой чужой либой
компилится но не линкуется
линкуется но «выпадает код»
компилится линкуется но не работает причём вообще но статически собранным работает
...

может пока опыта мало

это да единороги какают бабочками говнокода нигде нет 100% кода написано на 100% плюсах и прочий буллшит ты уже говорил ))

это да единороги какают бабочками говнокода нигде нет 100% кода написано на 100% плюсах и прочий буллшит ты уже говорил ))

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

Я говорил, что я работаю на проектах, где пишут на 100% плюсах. Ибо выбираю ту работу, которая мне по душе. А не чтоб ныть потом, как всё плохо, и обвинять инструменты разработки («виновата скамейка» ©)

Говнокод тоже есть. Найди мне комментарий, где я говорил, будто его нет. Он-то есть — но абсолютно не такой, как приводил в пример ты, утверждая, будто это «средний реальный плюсовый код» (dou.ua/...​95/?reply-comment#1650600)

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

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

не компилится
течёт
ведёт себя странно и не так как ожидалось как ожидалось сказать уже никто не может потому что нет уже те кто ожидали как
не компилится на других компиляторах (вотЪ)
не компилится на новой версии компилятора (+stl boost и ко.)
не компилится с новой чужой либой
компилится но не линкуется
линкуется но «выпадает код»
компилится линкуется но не работает причём вообще но статически собранным работает

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

оооо, це все знакомо, но приплюснуті кажуть, що у них на ПК все працює (компілиться, лінкується, запускається, не тече, не крешиться і т.д.), а ти тупий Сник не можеш портанути на девайс.

бага компилятора )) удоли!

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

пишешь дичь в конкретном случае ты

перечитай свой безумный опус

Коментар порушує правила спільноти і видалений модераторами.

Привет!
Тяжело тебе будет. Все крутые штуки — написаны на чистых сях. А то, что когда-то писали на плюсах в геймдеве уже закрыто юнити и сишарпом.

Все реально: є і компанії, і вакансії, і проекти, і зарплати. Інша справа, що другий курс — це ще зарано, щоб на них претендувати. Я бачив багато студентів першого-другого курсу на позиціях інтернів та трейні — і то реально ще діти. Їм треба пояснювати чому глобальні змінні та goto — це погано і для чого потрібні інтерфейси. Це нормально для інтернів та трейні (це навчальні і часто не оплачувані позиції). Але джун — це вже має бути людина здатна писати реальний код для реального проекту. Нехай простий, нехай під наглядом — але писати власноруч, маючи в голові знання мови програмування, стандартної бібліотеки, цільової ОС, того ж boost тощо.

Я б радив Вам шукати позицію інтерна чи трейні, не вимагаючи зарплати. Це легкий шлях попасти в компанію — а там, якщо зарекомендуєте себе, за 2-3 місяця можна перейти в джуна. Ну, або побачити, що поки що «не тягнеш» і зрозуміти, що потрібно ще вивчити.

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

Идеально, лучше и не придумаешь — то что я искал:) Спасибо!

Я б радив Вам шукати позицію інтерна чи трейні, не вимагаючи зарплати.

Уявляю собі відповіді через пару років на схожі теми: «Рекомендую попрацювати 1-3 роки безкоштовно, а потім уже будуть платити мільйони».

За безкоштовно можна дивитись в сторону open source проектів (дивитись як пишуть люди і можливо контриб"ютити щось), а працювати на лідера ринку без зп — дивно якось.

Робота над опенсорсними проектами дає досвід роботи над опенсорсними проектами. Робота на лідера ринку дає досвід роботи на лідера ринку. Просто треба задати собі запитання чим ти хочеш (і вважаєш за реальне) заробляти гроші через 2-3-5 років — і здобувати саме такий досвід.

1. Яке місто?
2. Другий курс це ще дуже рано і мало. Не повторюй моєї помилки і багатьох інших, не йди працювати так рано. Підтяни базу, алгоритми, матан, дискретку, лінійку, теорвер, електроніку і ще що тебе там будуть вчити і тільки вже потім думай про роботу. Зараз в тебе якраз час вивчити все те, що я описав, потім часу і бажання не буде.
3. З моєї точки зору, найлегший шлях це через стажування в компаніях. Пошукай які є стажування і що вимагають, не дивись на фріланс, то не для джунів.

1. Кривой Рог. Если что, то переехать не проблема
2.Возможно я не так выразился, но работу я сейчас не ищу, а просто присматриваю варианты на будущее, что «светит» мне и к чему стремиться. Я согласен с тем, что вы написали.
3. А где это искать? На сайтах по поиску работы, или...или на доу..или..где?

1. Кривой Рог. Если что, то переехать не проблема

хз чи взагалі є контори в Кривому Розі, налаштовуйтесь на переїзд в Київ, Львів, Харків, ідеально, як на мене, перевестись в Київську чи Львівську політехніку чи ХНУРЕ, хоча це перш за все залежить від вашої життєвої ситуації чи можливо.

2.

Однозначно треба ще рік чи два вчити базу яку написав.

3. А где это искать?

Сайти ТОП50 компаній, якраз вчора вивісили на ДОУ рейтинг, розділ «Кар’єра», як правило, там пишуть.
Рекрутери цих самих компаній. Створіть собі аккаунт на Linkedin, напишіть там, що студент і пододавайте рекрутерів з цих контор.

Всё понял, спасибо вам большое за советы!

Есть компания, специализирующаяся на серьезных проектах на С++ — Apriorit. Ближайшие офисы к вам — в Днепре и Запорожье. У них есть бесплатные курсы по С++ с трудоустройством. Читают сотрудники компании с большим опытом в коммерческих проектах. Попробуйте ;)

Своей одновременной сложностью и простотой. То есть, изначально это кажется неподъемной задачей — выучить данный ЯП, — а потом, немного влившись, ты понимаешь, что можешь сделать многое. Плюс, после С++ появляется понимание того, как основаны некоторые моменты в языках, как механизм «выглядит» под «капотом» (н-р интерпретатор у того же пайтона) и много таких вещей, которые ты просто понимаешь, как реализованы, знаешь слабые стороны итд.
Плюс, язык пустой, скажем так. Имею ввиду, что нет такого большого кол-ва модулей(библиотек), что вот просто ну завались(как у того же пайтона). Тебе множество моментов придется писать самому, иногда даже с весьма низкого уровня, почти с 0 — но в замен ты получаешь отменно работающее приложение, где даже на относительно низком уровне всё написано тобою, а значит если что-то не так, то виноват в этом только ты и никто больше + знаешь где искать проблему/как исправить

Тебе множество моментов придется писать самому, иногда даже с весьма низкого уровня, почти с 0 — но в замен ты получаешь отменно работающее приложение, где даже на относительно низком уровне всё написано тобою, а значит если что-то не так, то виноват в этом только ты и никто больше + знаешь где искать проблему/как исправить

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

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

да, знать как работают вещи — невостребованный скилл в наше время

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

это скорее всего ложное понимание, мне тоже так казалось когда-то, когда я на с++ начинал, все оказывается намного запутаннее

Возможно. А в чём именно запутаннее?

никто не может понять нахера они это все делали если есть плюсы

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

Просто вчити ’ЯП’ так собі затія, хіба лише базу. Щоб знати, як працює ’ЯП’ - теорія компіляторів(книга Дракона) та реверс ++ (Asm)
Всі можливості ++ вам ніколи не будуть потрібні. Краще ДС і алгоритми, разом з операційними та архітектурою. Ну і сферу виберіть.
С++ доволі високорівневий, особливо нові стандарти.

Тебе множество моментов придется писать самому, иногда даже с весьма низкого уровня, почти с 0

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

Здається я знаю відповідь на це запитання: почали викладати цю мову в університеті і в нього вона одразу пішла. А студентам, зазвичай, подобаються ті предмети, які у них виходять. От він і вирішив покопати глибше і, можливо, присвятити цьому своє життя.
Навряд на другому курсі мова йде про порівняльний аналіз мов за легкістю входження, сферами застосування та популярності на ринку. Простий собі «синдром каченяти».
Але робота є, і якщо доведе свої навички до належного рівня, то чому ні? Хоча, не виключено, що до четвертого курсу ще тричі передумає.

Не виключено. Потрібно було поцікавитися наскільки автор «втік» від одногрупників. Хоча, мені здається не далі базової книги по ++.

Після першого курсу — це вже добре. Якщо згадати мене у той час, так я взагалі задовольнявся університетським курсом. Мене б він точно обійшов. Але я не еталон, звісно.

Еталонів немає, лише зв’язок певних ситуацій.
Я взагалі почав лізти в ++ з середини 2 курсу. І збирав багато граблів.
Щоб ефективно їх(та інший ’low’) вивчати потрібна непогана база, тоді і простіше, і швидше. І самі ++ доволі різні, від 98 до 17/20. До кожних свій підхід. З часом все-таки було б краще вибрати свою сферу, і бустати її поки в університеті, а до кінця буде рівень, і рівень непоганий.

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

Начинай присматриваться к фрейму qt

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

Но а почему именно Qt? Не говорю, что это плохо, просто интересно узнать — «почему?»

Это очень продуманный, функциональный фреймворк. Если тебе о чем то говорит, то телеграм написан на нем

Qt достатньо популярний фреймворк. Найчастіше за все, як написали вище, його цінність складає можливість створювати кросплатформений UI (mac, linux, windows, android, ios).

Qt QML часто використовують в automotive проектах (софт для бортового комп’ютера в автомобілі a.k.a. Target).

QML дає змогу достатньо швидко розробляти UI (Є примітиви такі як Itrm, Rectangle, а також уже готові UI компоненти як Button і TextInput). Підтримує вставку JS коду і звісно обмін даними з C++.

Також Qt надає змогу працювати з network, парсити і збирати JSON/XML, працювати з БД і ще багато чого.

При використанні Qt, скоріше за все доведеться і використовувати їхні контейнери (QList, QMap, ...), а вони дещо відрізняються від стандартних std::list, std::map. Наприклад в QList можна зробити так: list[5] — доступ до елемента по індексу (в std::list так зробити не можна).

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

Ага, я понял. Тогда на неделе этим и займусь, спасибо!

Наприклад в QList можна зробити так: list[5] — доступ до елемента по індексу (в std::list так зробити не можна).

тому що він більше як std::vector чим класичний список

QML + JS это худшее, что могло вообще случиться :) В 6 версии обещают сделать их компилироваными, т.е. вновь изобретут виджеты...наконец-то.

никогда, никогда, никогда в кьют контейнерах не обращайтесь для чтения элемента через []

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

облегчает вхождение в плюсы

бугога! lil

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

Он на чистых плюсах, не напишет нормальный интерфейс с формой

А почему? Имеешь ввиду это сложно как для новичка(по типу меня), или больно-моторное дело в целом?

Это не сложно, но очень много времени займет, если делать дизайн на win api. Тебе надо будет абсолютно все, отрабатывать самостоятельно, никакого предпросмотра формы и что из себя она представляет. Когда начнёшь формы делать, если ещё не начал, то всё поймёшь. В qt есть два варианта создания формы, это виджеты, где ты все обрабатываешь на c++, а есть qml, где логика дизайна отделена от языка c++. Хоть второй вариант и кажется удобнее, но телеграм почеме то решили все таки использовать виджеты

С++ не содержит встроенного «гуй». Нужно напрямую работать с ОС АПИ, что ставит крест на кросс-платформе. Т.е. программа становится привязана к ОС. Во избежание такого создан QT, которые детали работы ОС содержит внутри себя. Есть и другие подобные либы, особенно для юниксов. Но КТ самый распространненый.

оо, тут тоже можно искать работу, понял. Спасибо большое!

С++ програміст — це дуже загальне поняття, чим конкретно хочете займатись? Сервери, БД з може блокчейном? Геймдев? 3Д друк? Ембеддед?
А, і тому що ви ще студент — ніхто вас не візьме. Вчить теорію, робіть власні проекти, дрочіть leetcode.com. Тоді після вишу проблем не буде.

Спасибо за совет. Хотел бы пойти в геймдев — в идеале.
Кстати, возможно некорректно выразился, но в данный момент работу я не ищу, а просто присматриваю варианты на будущее, которых я не вижу.

Вчить теорію, робіть власні проекти, дрочіть leetcode.com.

Первое, второе — без проблем:) А по поводу leetcode, это случайно не аналог e-olymp, где нужно считать площадь елки, относительно объема гнома на ней??То вроде что-то похоже...

В Кривому Розі варіанти може і є, але я б не радив їх брати. Не орієнтуйтесь на рівень Кривого Рога.

А по поводу leetcode, это случайно не аналог e-olymp, где нужно считать площадь елки, относительно объема гнома на ней?

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

если геймдев, то есть топ-зверинец в виде Unity(но тут своя версия C# с преферансом и куртизанками), Unreal Engine4(тут плюсы) и Source/CryEngine etc.
Сам имею небольшой опыт «для себя» в Юнити, могу сказать, что скриптинг довольно прост в плане вхождения, но сам процесс разработки в редакторе в одиночку будет напоминать симуляцию человека-оркестра(помимо скриптинга нужно заниматься: общей идеей, левел-дизайном, 3д-моделированием, анимациями, если 2д — то куча дро*илова с 2д-сплайнами, набивка библиотеки префабов для проекта без которой добавление каждого нового супер-марио-ящика с чуть другим поведением будет стопать весь процесс на 1+ часов итд. и это даже без упоминания работы над звуками/музыкой и (пост)эффектами). Но если вдруг автор вдохновился, то на ютубе есть канал Brackeys — там чувак выкладывает степ-бай-степ уроки по созданию разных простеньких игр, плюс англ можно прокачать.

Беруть студентів з руками і ногами. Звісно, є нюанс з очною формою навчання і мотивацією студента. При ТОП аутсорсерах України є свої курси і академії після яких можуть запропонувати веслати в компанії, тому не вводьте автора в оману.

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

В кожному місці є компанія яка приймає C++ початківців, цей пункт треба додати в Конституцію України, якщо б коли починав знав про DOU то і компанію обрав іншу

От ти з якого міста?

Я с Кривого Рога.

В кожному місці є компанія яка приймає C++ початківців

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

Першу роботи вибирають за принципом, йди куди беруть і біжи якщо в першому місяці буде якась муть

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

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