Уважаемые специалисты, подскажите пожалуйста могу ли я претендовать на должность Junior C++ с такими знаниями, как в моем проекте:
github.com/Bigstorm20008/CrazyTank3
Я учусь самостоятельно, поэтому подсказать и оценить некому.
Заранее спасибо.
Если кому интересно, то со второй попытки таки взяли меня на работу) Всем спасибо) Вы мне добавили уверенности))) Завтра первый рабочий день)))
Что за компания? Какая вилка по зп? Как проходило и что спрашивали на собеседовании?
Ребят, похоже на вброс, вы обратили внимание сколько топиккастеру лет???
Пофиг. Но, неужели 100?
35) А что это будет сильной проблемой? На первом собеседовании мне ничего не говорили по этому поводу)
Будет. У большинства собеседующих до сих пор дурь в башке, что после
Так что готовься к получению отказов и по возрасту, хоть прямо тебе об этом и не скажут.
Понятно.... Печально.... Ну что ж буду пробовать...
Рассчитывай, что тебе будет сложнее, чем 25 летнему, но у вас есть достаточно и приличных контор, где на возраст и подобное не обращают внимания.
это Украина, забей
Ну я пока особо не расстроился, отказов-то ведро еще не получил) Буду надеяться, что все получится) я оптимист)
не получится — всегда можно завести трактор
И не нужно расстраиваться.Отказ одной компании－не показатель.В городах－миллионниках шансов больше оффер получить.
Так и планирую). Вот сейчас в последние теплые деньки свожу ребенка на море, потом отправлю ее в
Тс, как успехи?
Советую переделать резюме на Middle, и просить $2K, так успехов больше будет.
Пруф-линк: dou.ua/...orums/topic/12167/#619255
Вот отправил ребенка в школу, и делаю задание на Junior). Скоро будет известно возьмут или нет со второй попытки)
Вероятнее всего не возьмут. Еще попыток
Не сработает. У него нет опыта на конторах — посему посчитают вруном и откажут сразу же.
Врать правильно и хорошо, но только не лично мне — так думаю 100% людей.
Имхо, чувак явно Миддл. Смысл себя позиционировать как джун с таким кодом??
Ну до миддла мне кажется я врядли дотягиваю) Я ведь совсем без опыта, да и на джуна меня уже не взяли при первой попытке)
Блин, не увидел что ты с Николаева, там возможно другая коньюктура на рынке
Да у нас тут вообще только Senior C++ берут, с новичками не хотят заморачиваться)
Ты бы еще в селе Кукуево С++ искал. Вариант у тебя один понаехать в Киевы, Львовы или на крайняк Харьковы.
))Да вот пытался в Одессу понаехать. Они были против)))
У тебя таких попыток еще
А ты предполагал, что к тебе очередь из работодателей выстроиться, как только код на гитхабе выложишь? Более того, тебе этот код на собеседовании будет помогать, но только после того, как презентовать его научишься.
да нет)) я слышал, что устроиться довольно тяжело.... Вот сейчас прочувствую)))
Ну как бы вайтишников сейчас много и на первую работы устроиться сложнее, чем
Но не думай, что дальше всё просто будет. Те же собеседования придурочные.
Найдешь сейчас первую, через-год сменишь с повышением зарплаты и будешь называть себя мидлом.
Если рассматриваете переезд,укажите в резюме готовность к релокейту в том же djinni.com, либо на Линкедине.
Да к переезду готов) Спасибо, укажу, я просто недавно начал использовать эти сервисы для поиска работы. Еще не успел все заполнить как следует.
Почитайте на djinni рекомендации,как джунам заполнять профиль＋нормально указывать в пожеланиях к работодателю ,например,помощь в релокейте итд. Успехов)
Дотягиваешь. половина сеньоров и мидлов в местном программинге и так не умеют.
Но, если у тебя 0 лет стажа, то ты таки джун.
Хотя мне кажется, что если я смог таких результатов добиться самостоятельно, то смогу добиться гораздо большего, если будет наставник и будет на кого равнятся)
то смогу добиться гораздо большего, если будет наставник и будет на кого равнятся
С си/"плюсами" всё зависит от конкретного проекта. Есть проекты, где «плюсы» не пользуют вообще. В других проектах пользуют урезанную версию плюсов (98 стандарта), без исключений, стл, буста, с кучей ограничений по темплитам, итп. В иных проектах используют лишь новейшие стандарты, с бустом, итп.
В общем, куда попадёшь...
Ну насколько я понял, сейчас многие возвращаются к плюсам. Да и сам язык продолжает развиваться. Ну и после плюсов легче выучить другие) Я параллельно читал про C++/CLI. Он вроде достаточно сильно похож на C#. Правда пока не пробовал писать на нем особо. К C++ сильно прикипел. Люблю сложности)))
C++/CLI
Не рекомендую смысла никакого нет. При наличии C# смысл сразу заниматься последним он «прямо ближе» к .NET.
Ну это я вроде понял, просто в ознакомительных целя пробегал главы по С++/CLI
Айвор Хортон — Visual C++ 2010. Полный курс (Программистам от программистов) — 2011
сейчас многие возвращаются к плюсам.
Нет. Просто в конкретных проектах свои ограничения, в том числе и по языкам и их вариациям.
Не нужен тебе наставник. Просто устраивайся на работы и набивай руку и стаж.
Зачем на бумажке, есть же топкодер, хакерранк и ко. Там и соревнования на время проведут, и рейтинг посчитают.
Первая попытка найти работу — мимо( Засыпался на задачках в скайпе. Тестовое задание выполнил, а техническое собеседование не прошел(. Рыл в интернете — думал, что будут вопросы, а оказалось не так... Теперь расстроен( После этих задачек я думаю у проверяющих сложилось впечатление, что писал не я.... Вообщем первый блин комом)
Прохождение собеседований — отдельный навык и не сильно связанный с работой и твоими навыками и знаниями.
Собеседования — это такой танец токующих на току.
Трішки переглянув код. Зараз до джунів дуже великі вимоги. На трейні спокійно взяв би з таким проектом. А на джуна потрібно було ще пройти співбесіду.
Напишу свої зауваження.
1. Замість складної конструкції:
std::vector<Direction> checkedDirections;
checkedDirections.reserve(directionCount);
checkedDirections.push_back(direction_);
Можна простіше
std::vector<Direction> checkedDirections = { direction_ };
2. В одному і тому ж файлі то є this-> для доступу до локальних членів, то ні. Вибрати один стиль.
3. Definition пустих конструкторів і деструкторів в cpp файлах не потрібні. Краще використати = default;. Навіть більше, якщо деструктор не віртуальний, то навіть не треба його оголошувати.
4. Потрібно користуватись статичними аналізаторами коду: Cppcheck, ReSharper C++, clang тощо. Наприклад, змінна bool directionFound = false; в EnemyTank.cpp не використовується і її можна спокійно видалити.
5. Не потрібно перевіряти змінну на nullptr перед її видаленням.
Замість
if (input_ != nullptr)
{
delete input_;
input_ = nullptr;
}
можна спокійно писати
delete input_;
input_ = nullptr;
А краще взагалі не використовувати голі вказівники. Лише smart.
6. Англійська неідеальна. Можна поставити spell checker плагіни і перевіряти код. «foundedObject» — «foundObject».
7. Для релізів exe файлів в GitHub є окрема фіча «Releases».
8. Назви комітів у Git повинні бути осмисленими. Коміти — це найкраща історія та документація проекту.
спасибо за Ваши замечания, приму к сведению. Я же учусь самостоятельно, поэтому многого еще не знаю, на многое могу не обратить внимание. Как в книжках написано так и стараюсь делать. Исправлять меня некому. Вот выложил тут чтоб послушать критику и оценить свои знания
послушать критику
...и критику на критику :)
Для рев’ю кода є сайти codereview.stackexchange.com
5 замечание особенно хорошее. Более 20 лет на С++ пишу и всё одна периодически грешу этим.
Хотя и вреда и пользы от такой проверки 0. Но мне кажется, что современные компиляторы при включении оптимизации выкинут её за бессмысленностью.
но ведь если попытаться удалить нулевой указатель — вылетит ошибка?
Нет не вылетит delete и delete[] безопасные к нулевым указателям.
И хорошо, что напомнил новичку. Важно ему не путать delete и delete[].
Нет. Это корректное поведение delete.
в книжка вроде написано всегда проверять, правда там if(input_){ do somesing()) как-то так
Зависит от ресурса. delete для NULL корректен всегда. А вот для мусора вызвать delete получишь «системное исключение» — в винде одно в линухе другое.
«Це знають ще у яслах малі діти, що лучше перебдіть, ніж недобдіти» ©
Відразу кидається в очі if (isReadyToFire() == true) { ... }. Пишуть же простіше if (isReadyToFire()) { ... }.
нет
мало того: if (true == isReadyToFire())
Пічалька тоді, якщо так прийнято на проекті.
печалька, если НЕ принято
код должен быть читаемым
код должен быть фулпруф
Можливо, геймдев-проекти не писав.
Скажу, що в clang і кількох відомих open source проектах, які читав, такого коду не зустрічав.
Так хіба в C прийнято, тому що там немає bool.
Дядя шутит никто так не пишет.
Так хіба в C прийнято, тому що там немає bool.
Но чисто теоретически таки да есть проекты в который свой BOOL и чисто технически он может и не быть TRUE = 1 FALSE = 0 ну или вот такие конструкции:
Дмитрий Ткачук
Oleg Kotok
Oleg Kotok
Viktor Chyzhdzenka
Евгения Невская
Oleksandr Redko
if (True(_something_)) { ...
А вообще это показывает практику кривости проекта и значит там кроме этих «кастомных условий» будет ещё вагон и маленькая тележка «палок говна велосипедов и костылей». Причём не только в коде. Я проверял. ))
Дядя шутит никто так не пишет
дядя ни разу не шутит
Пишут
if (true == _something_) { ...
? а ну ок но тут уже словами классика «а каждый больной больной по своему» (к) (тм)
думал, не нужно обьяснять причины этого, но, видимо, ошибся
Причин может быть миллион угадать какая именно случится в каждом конкретном случае никак нельзя можно только гадать.
Какая причина этого была у вас?
С точки зрения переносимости (portability) полезно. А если переносимость пофиг — зачем заморачиваться с с/с++ ?
С точки зрения переносимости джава рулит! ))
ЗЫ: а почему с точки зрения переносимости полезно?
Ни хрена она не рулит. С HiDPI до сих пор не разобрались. В каждом проекте на жабе свое уникальное решение для оного.
Да вы батенька тролль знатный! ))
Так правду ж пишу. В одних продуктах на жабе сами разрабы научились HiDPI корректно поддерживать (таких единицы в мире), в других шаманство предлагают (таких чуть больше, чем первых), в третьих до сих пор не научились (этих процентов 90) и только исправив их код, шрифты нормальные увидишь.
Для кучи языков гуевая часть или либы умеют HiDPI, а в жабе все еще в начале
Для кучи языков гуевая часть или либы умеют HiDPI, а в жабе все еще в начале2000-х многие
Если честно я не слышал чтобы «для кучи языков» вообще GUI были а джава так она же ж для суровых корпоративных приложений какой ещё там HiDPI? Там где HiDPI там GUI на айфонах ))
Только куча спецов успела наделать профессионально софта на Жабе, наслушавшись сказок про ее кроссплатформенность.
На уровне без сторонних либ С уделывает все языки по кроссплатформенности.
потому, что легко написать (something = true) (защита от дурака)
и ясно-понятно (в т.ч и компилятору), что something это булеан
я думал, что это настолько очевидные вещи, не требующие какойто дополнительной аргументации
я думал, что это настолько очевидные вещи, не требующие какойто дополнительной аргументации
)) в том-то и дело что я понимаю что вы не понимаете о чём вообще речь но конкретно здесь ну ок имеет смысл писать:
if (true == _something_) { ...
Вопрос зачем вообще писать (true == ...)?
И тогда и продолжение следоватально везде где только есть true/false следует писать так же? В частности надо полагать то же самое следует делать в частях логического выражения:
if (true == (_something_1_) && true == (_something_2_) && ...) { ...
А также при возврате параметров при передаче параметров и при присваивании / инициализации:
... bool is_something = true == _something_; DoSomethingElse(true == is_something); return true == is_something;
Или это уже не обязательно? Если не обязательно то почему в одном случае следует писать а в других случаях нет?
Вступлю немножко в ваш спор)
вроде как так правильно из того code style что я читал...
bool isSomething = какое-то условие;
if(isSomething == true){
делаем что-то
}
else{
делаем что-то другое
}
Не пиши так. Это индусский стиль.
Но для отладки я часто юзаю такой трюк bool do_somethink = false
if (do_somethink)
{
ля-ля-ля
}
Это часто удобнее, чем #ifdef.
Хотя если порыть в интернете, то вроде и так и так пишут...
Вопрос зачем вообще писать (true == ...)?
читабельность
я об этом почти неделю назад сказал: dou.ua/...rums/topic/24705/#1397290
но нет, же надо ткнуть лицом. ну ок
и кто тут чего не понимает?
2топикстартер: вам, конечно, выбирать, как и что писать. лично я ник чему не принуждаю. свою точку зрения и аргументы я привел
детский лепет, типа «так никто не пишет» оставим для баталий в форумах типа ру.ос.кмп
читабельность
ок принято именно про это я и сказал:
А вообще это показывает практику кривости проекта и значит там кроме этих «кастомных условий» будет ещё вагон и маленькая тележка «палок говна велосипедов и костылей». Причём не только в коде. Я проверял. ))
Так хіба в C прийнято, тому що там немає bool.
Там есть _Bool
Там — это где? В каком стандарте и в каких хидерах какого компилятора?
В 99 стандарте добавили.
Для всех остальных — #include <stdbool.h>
Вижуалстудия до 2012й не умела C99, его реализовали только для поддержки C++11 (который базируется на C99)
ну я когда-то тоже так писал, потом почитал code style и там была рекомендация писать именно так и обрабатывать исключения последними.
Так цих code style є 100500 в C++. Як прийнято в команді або проекті, так і краще писати.
Внешне код выглядит аккуратно. Пользоваться С++ в общем умеешь.
Так что позиция джун-мидл-сеньор определяется только твоим стажем работы и твоей «наглостью».
А вот твой действительный уровень часто связан еще с предметной областью и опытом в ней.
Ну и хочу тебя поддержать. Твой джуниорский код приятнее, чем сеньорский в tensorflow от гугла. Про OpenCV и не говорю, там еще тот ужас (такого наворотили, что не могут уже поддерживать С интерфейс).
Читать твой легче.
Спасибо, за Ваши отзывы и советы) Очень приятно)
чем сеньорский в tensorflow от гугла. Про OpenCV и не говорю
Есть мнение что там пишут «типа знающие си/си++» (к) (тм) но «не программисты» ))
ЗЫ: я проверял. ))
Их понять можно. В голову всё не влазит. Я вот тоже кучу всего и не запоминаю, а у гугла спрашиваю по С++.
В V8, например, хороший код, на мой вкус. Довольно просто разобраться, что к чему.
За Гугл болеешь? Мой пост был к тому, что даже у так называемых сеньоров код бывает еще то дерьмо, у ТС же код читать можно.
вы только в стл не заглядывайте
Это не буст, в стл еще более ни менее прилично.
Дмитрий, если GameDev интересен, в Одесском офисе Nordcurrent открыта вакансия Junior C++ developer можете направить информацию о себе на почту: jobs-ua@nordcurrent.com
Здравствуйте, Ольга. Извините, что не ответил вчера. Возил ребенка в аквапарк). Конечно меня интересует gamedev. Игры я очень люблю, хотя их программирование считается наиболее сложным. Да и то, что Вы находитесь в Одессе мне идеально подходит. Только вот не нашел описания вакансии. Актуально еще?
Дмитрий, добрый день! Описание вакансии тут www.work.ua/jobs/3270230/
Если предложение интересно, жду Ваше резюме и могу направить Вам ТЗ )
Ольга Диунова
HR менеджер Nordcurrent Odessa
+38 066 998 69 90
skype: Nordcurrent Odessa
jobs-ua@nordcurrent.com
www.nordcurrent.com
Советую, при поиске работы рассматривай не только гейм-дев. Сейчас много где опять требуется математику на С++ писать. Питоны хороши, но только для пилотных проектов. В продакте все в плюсы переносят большую часть — железо-то уже достигло предела, а большие кластера не всегда финансово разумны.
Looked into some files. Imo, seems Ok for the first job in C++.
I would recommend:
- Learning more about data structures and algorithms, e.g. this is a good specialization — www.coursera.org/...ata-structures-algorithms
- Learning Linux. Udemy has a lot of courses or of course YouTube. At least basic commands: find, grep, etc
- Learning Python, e.g. could be useful for system component tests but not only
- Reading www.amazon.com/...ays-Improve/dp/1491903996 and similar ones
- Also this guy has got good videos about C++ www.youtube.com/...anTheProgrammer/playlists
- Being willing to relocate
Also:
1. Add tests, e.g. use github.com/google/googletest and github.com/google/googlemock . To merge new functionality to a project, tests are a must-have
2. new GameController — use std::unique_ptr
3. std::cout << “Could not set control handler” << std::endl; — use std::cerr for such prints
4. BOOL and TRUE — inventing new bool type or it’s from some lib?
5. WorldObserver — virtual destructor is missing in abstract class
6. WorldObserver::WorldObserver() {} — could be replaced just by WorldObserver() = default
7. std::vector> vectorOfEntities ; ... void addEntity(const std::shared_ptr& gameObject); — why is std::shraed_ptr passed by reference and previously by value? And probably smart pointer is not needed at all and simply creating objects on stack and returning const reference would suffice; std::vector> seems overkill
8. World::~World() { actor_.reset(); vectorOfEntities_.clear(); } — dctor of those objects will do that job, and you can just make it = default;
9. objects::GameObject* const findEntityAtPoint — I would replace pointer by smart pointer or better reference
10. class World : public ObservableWorld — It seems that World is more general but you are inheriting from more specific world, I would change names
11. [&](const std::shared_ptr gameObject) — if you have too long lambda, from C++14 you can use auto for params
12. findObjectInRectbyId implementation in World.cpp seems too large, another function could be extracted
13. std::vector> createWall — factories should return std::unique_ptr. It can be converted to std::shared_ptr but not vice versa
14. return std::move(wall); — std::move here is not needed
15. namespace objects ? Sounds like namespace everything
16. should not methods in StatesConstans be static?
17. static std::shared_ptr getInstance(); — I’d return const reference and std::shared_ptr is overkill; we have got static there
18. explicit Point(const int& xPos, const int& yPos) — pass by value, passing int by value will be faster than passing int by reference; copy of 4 bytes outperforms going to the reference variable and then dereferencing it to get its value
19. You apply std::move to Point but you also define dctor for Point and not move ctors — i.stack.imgur.com/Zz2yJ.png
20. Use CMake or something similar
Ого!!! Спасибо огромное. Какая большая работа была проделана Вами, еще и с объяснениями и ссылками.
Переехать конечно готов, у меня в городе ловить нечего(
Блин спасибо еще раз) Столько полезных замечаний) Некоторые ошибки прямо совсем глупые)
Sorry my English is not very well, and i don`t know if you understand russian.
I will try to unswer in English. Thank you for your work was done.
I have got a lot of useful remarks and your explanations. Хотя судя по имени Вы русский знаете)
18. explicit Point(const int& xPos, const int& yPos) — pass by value, passing int by value will be faster than passing int by reference; copy of 4 bytes outperforms going to the reference variable and then dereferencing it to get its value
Это микрооптимизация. Но обычно такое не передают по ссылкам, а по значению — оно в регистр помещается. Но, если у тебя шаблон, то таки ссылка лучше.
Ну и я детально не смотрел, но по ревью выше, почитай еще раз про конструкторы и деструкторы в С++. Похоже в этой части ты пока плывешь.
И не забывай, что половина моментов в этом ревью для новых компиляторов и стандартов. В большой части проектов еще даже на С++11.
Сам факт того, що вмієш писати код на плюсах це ок, але саме для того аби зайняти вакансію, може знадобитись багато чого.
Дуже залежить від проекту, але скоріше за все, запитають ще англійську, досвід з лінуксом і т.д. Тобто треба розглядати кожну окрему контору і вакансію окремо, хто що шукає.
английский я знаю более-менее, правда только в чтении практика была, пока изучал) Разговорный не очень, надо подтягивать
Власне скілл проходження співбесіди(особливо, якщо говорити про розмову англійською), чітко і однозначно відповідати на питання, це, нажаль, те на що мало звертають увагу кандидати, але іноді це відіграє вирішальну роль. Тому я радив би при підготовці окрім C++ core, STL, алгоритмів і структур даних ще підтянути скіл «говоріння».
По коду ничего не скажу — не сишник, но ввали силы в английский. Что такое более менее в твоём понимании я не знаю, но на проекте в 90% случаев ты общаешься с кем-то со стороны заказчика, так что могут быть кейсы, когда возьмут человека на джуна с меньшими знаниями программирования, но с большими знаниями английского
Не слушай ты их. Если идешь на джуна, того что написал хватит с головой. Есть хитрожопые конторы, которые хотят получить мидла, по цене джуна. Ну так оно тебе надо туда идти? Английский уровень — работа с доками — все!! Джуны не общаются с заказчиками, для этого есть, кто по старше. Ну а потом подтянешь все, что тебе тут наговорили. Рассылай резюме и удачи.
На уровне чтения — легко. По-крайней мере много информации я получал на MSDN, а там много всего на английском. Спасибо за совет. Я тоже думаю, что новичку врядли доверят общение с заказчиком. А по поводу компаний к сожалению у нас всегда хотят как минимум 3 в 1( И это не только в IT
а вот с линуксом опыта нет совсем( только Windows. Есть небольшие знания в RDBMS SqlServer и Transact-Sql. Как раз перед этим проектом занимался, на гите есть
Это не айс. Найди видео курсы lpic-1 и послушай чтобы иметь общее понимание концепций.
Если не полезешь в ядро, но там больше С, чем С++, то за
Просто старайся писать сразу кросплатформенно, а платформозависимые части выносить в отдельный слой (функции, классы-обертки поверх платформозависимого).
Просто поставь рядом с виндой линух и собери свой проект там, полазь в дебаге, поотлаживай и считай, что опыт прикладного (не системного) программиста в линухе у тебя есть.
Для системы сборки кросплатформенной СМаке сейчас неплох.
Перестань это никак не для джуна совет ))
Да ну. По-моему сразу приучает к определенному порядку и мышлению.
Слона надо есть по кусочку (к) (тм)
Но кусочки правильнее отрезать от правильных мест.
helpers::RandomEngine* engineInstance = nullptr;
const auto randomEngine = engineInstance->getInstance();
выглядит странновато, даже с учетом что getInstance static
ну и куча других мелких вопросов, но в целом не плохо
Ох, про Миколаїв хз, а от у Києві чи Львові можна було б.
Да в Николаеве только GlobalLogic, и там С++ не в тренде( Нужно искать в другом городе
Если вы вызываете reserve, то можно сразу на middle :)
P.s. если хотите использовать этот проект в резюме, то добавьте комментарии.
ну это врядли))) хоть бы джуниором где-то взяли)
поверьте, куча сеньоров не понимают, что это такое и зачем.
Хреновые вам встречались сеньоры :(
Там, где я работал (кроме самой первой работы, которая была не в IT-компании), любой джуниор понимал такую базовую вещь.
Другое дело, что иногда люди могли забывать вызвать reserve. Или забИвать, если место явно не перформанс-критикал и уж точно этот резёрв там ни на что не повлияет по факту.
Но знали буквально все.
На миддла можешь претендовать, если знаешь про boost::small_vector (или аналоги) и понимаешь, почему такая вещь в некоторых случаях будет работать заметно быстрее, чем std::vector с резёрвом =^__^=
На миддла можешь претендовать, если знаешь про boost::small_vector (или аналоги) и понимаешь, почему такая вещь в некоторых случаях будет работать заметно быстрее, чем std::vector с резёрвом =^__^=
По моему нескромному опыту такие вещи не только 146% лишние но и более того 146% за такими «миддлами знающими про маленький пипектор» (к) (тм) ещё разгребать и выгребать. Я проверял.
ЗЫ: если вдруг случается «надо сделать маленький пипектор на месте вектора» это значит что там уже пробой в архитектуре и понимании что и зачем оно в более глобальном и вообще в любом смысле делалось.
Опять эти синьоры, путающие знающих людей с дебилами из-за своего нескромного опыта (к) (тм). За свои 20+ лет опыта встретили одного дурачка, который без разбору лепил вещи, куда не надо, только потому, что он о них недавно прочитал, — и решили, что все, кто об этих вещах знают, будут поступать так же.
Это не логика синьора, это даже не логика джуниора. Это всякое отсутствие логики.
Нужна фича — используйте. Не нужна — не используйте. Всё просто.
На смолл векторах весь LLVM построен, если что. И в геймдеве они очень популярны.
Там все дураки, один вы умный? Что-то слабо мне в это верится.
Не говоря уже о том, что данная small size оптимизация — вещь куда более глобальная и распространённая, чем какой-то там «пипектор». В той же стандартной библиотеке плюсов на ней строятся как минимум std::string и std::function.
И нормальный человек (неважно, миддл он, джун или синьор), если он новичок на проекте, сначала спросит, стоит ли применять такую штуковину, а затем уже — при получении положительного ответа — будет её лепить в код.
Да и код ревью никто не отменял.
Или на ваших проектах, где вы «проверяли», творился такой бардак, что в репозиторий гадили все кому не лень и это никем не контролировалось? Ну так сами виноваты, что так процессы поставили. И что наняли настолько непрофессиональных людей, не умеющих работать в команде.
Или на ваших проектах, где вы «проверяли», творился такой бардак, что в репозиторий гадили все кому не лень и это никем не контролировалось? Ну так сами виноваты, что так процессы поставили. И что наняли настолько непрофессиональных людей, не умеющих работать в команде.
А это и есть реальные проекты там пони не какают бабочками там кого набрали те и срут других нет.
Я тоже работал на реальных проектах. И пока что, кроме моей самой первой работы, я попадал туда, где коммиты мониторились опытными синьорами и проводилось код ревью. Если джун, миддл или недавно нанятый синьор написал что-то не то — ему об этом говорят и он вносит правки в соответствии с замечаниями.
Если на ваших проектах такого не было — не значит, что такого нет нигде. «У меня нет машины, следовательно, машин не существует» — логика, сами понимаете, такая себе.
Если джун, миддл или недавно нанятый синьор написал что-то не то — ему об этом говорят и он вносит правки в соответствии с замечаниями.
А если «что-то не то написал» давно нанятый архитектор?
И пока что, кроме моей самой первой работы, я попадал туда, где коммиты мониторились опытными синьорами и проводилось код ревью.
=>
«У меня нет машины, следовательно, машин не существует»
Скучно )) таки уровень как иллюстрация да именно такой как я написал с реальными людями с какими приходится работать.
А если «что-то не то написал» давно нанятый архитектор?
Сейчас мы говорили о «миддлах, знающих про маленький пипектор (к) (тм)», а не о давно нанятых архитекторах.
Если архитектор на проекте творит дичь... Что ж. Всё плохо.
=>
Ноуп, это не «=>». Я никогда не утверждал, что раз я не попадал на проекты с бардаком, значит таковых не существует.
Если архитектор на проекте творит дичь... Что ж. Всё плохо.
Все творят дичь. Так есть. Думать об этом «хорошо или плохо» здоровья не хватит. Я проверял.
Я никогда не утверждал, что раз я не попадал на проекты с бардаком, значит таковых не существует.
Фишка здесь в том что «ты утверждал на проекты попадал» с позиции чувака с опытом 3 лет выступая перед чуваков с опытом в 23 лет у которого среди прочего в т.ч. на проектах таких чуваков «с опытом 3 лет и пипектором» в среднем есть больше 1 и соотв. разных и с одной стороны конечно можно накричать можно избить можно уволить но см. п.п. «так есть» и соотв. так или иначе чуваки же ж работают и других нет приходится как-то изворачиваться и прокладываться между «желали странного пипектора» и тем что на проекте буста нет и что внедрение буста это такой супер-мега-вообще чейнж который надо будет протягивать полгода через 8+ «верхних инстанций» а даже если он и есть «маленький пипектор» вполне служит достаточным чейнжем чтобы его «зарубил на ревью» тот самый «архитектор сверху» и с ним нельзя спорить потому что он решает бабло а вот со мной получается можно и таки все эти «с опытом 3 лет и пипектором» таки и спорят что собственно непосредственно прямо сейчас делаешь и ты )) и это тоже среди прочего точно такая же ж реальность реальных проектов см. п.п. «так есть».
Там всё просто хотя таки да обобщая опыт таки реально всё начинается с «маленького пипектора» и таки реально «маленький пипектор» служит прямым указателем на то что и всё остальное будет «как обычно творят дичь».
Я проверял. ))
Все творят дичь.
Мы о разных степенях «дичи» говорим. Я не применяю нетипичные для проекта технологии, не проконсультировавшись при этом с синьорами/архитекторами и не обсудив с ними, насколько нам это нужно.
Фишка здесь в том что «ты утверждал на проекты попадал» с позиции чувака с опытом 3 лет выступая перед чуваков с опытом в 23 лет у которого среди прочего в т.ч. на проектах таких чуваков «с опытом 3 лет и пипектором» в среднем есть больше 1 и соотв. разных и с одной стороны конечно можно накричать можно избить можно уволить но см. п.п. «так есть» и соотв. так или иначе чуваки же ж работают и других нет приходится как-то изворачиваться и прокладываться между «желали странного пипектора» и тем что на проекте буста нет и что внедрение буста это такой супер-мега-вообще чейнж который надо будет протягивать полгода через 8+ «верхних инстанций» а даже если он и есть «маленький пипектор» вполне служит достаточным чейнжем чтобы его «зарубил на ревью» тот самый «архитектор сверху» и с ним нельзя спорить потому что он решает бабло а вот со мной получается можно и таки все эти «с опытом 3 лет и пипектором» таки и спорят что собственно непосредственно прямо сейчас делаешь и ты )) и это тоже среди прочего точно такая же ж реальность реальных проектов см. п.п. «так есть».
Эту часть не осилил, сори. Почему ты не используешь запятые и не разделяешь текст на предложения? Это как читать неотформатированный код. Разобраться можно, но не быстро и уж точно не бесплатно.
обобщая опыт таки реально всё начинается с «маленького пипектора» и таки реально «маленький пипектор» служит прямым указателем на то что и всё остальное будет «как обычно творят дичь»
Обобщая твой
Я категорически не согласен, что всё начинается с «маленького пипектора». Если человек знает о таком — ему это только в плюс.
А дичь начинается с некомпетентности нанятого разработчика, который мало того что знает про «пипектор», так ещё и суёт его без спроса куда не надо, и не считает нужным обсуждать такие вещи с коллегами. Тут не его «избыточные» знания виноваты, а его неумение/нежелание работать в команде и/или завышенное ЧСВ.
Почему ты не используешь запятые и не разделяешь текст на предложения?
и уж точно не бесплатно.
Моё «небесплатно» $100 в час а твоё? )) Ты имеешь в виду «небесплатно» якобы это нужно мне? )) ты точно в этом месте не практикуешь то самое «завышенное чсв»?
Я под твои умозаключения не попадаю никак, поэтому меня это и возмутило, когда всех под одну гребёнку без разбору.
Утомил =>
завышенное ЧСВ.
нетипичные для проекта технологии, не проконсультировавшись при этом с синьорами/архитекторами и не обсудив с ними, насколько нам это нужно.
Нинасколько. Ты не на том уровне чтобы «консультировать синьоров/архитекторов насколько им это нужно». И всё.
ЗЫ: но «пипектор» тут об двух концах потому как «маленький пипектор» может быть и чаще и бывает ещё и у «синьоров/архитекторов» и тогда вот они говорят «ой а у меня тут маленький пипектор как здорово было бы б применить его на нашем проекте!» (к) (тм) и начинают совать свой маленький пипектор везде на каждом код-ревью «ой а посмотри вот у меня маленький пипектор возьми его и сделать с ним хорошо» (к) (тм)
Просто ты встрял в спор изначально выступая именнно с позиции
Опять эти синьоры, путающие знающих людей с дебилами из-за своего нескромного опыта (к) (тм). За свои 20+ лет опыта встретили одного дурачка
А те самые «путающие знающих с дебилами» они «из-за своего нескромного опыта» просто знают уже что дебилы все и что нет никакого «встретили одного» а как в том классическом анекдоте «да их тут тысячи тысячи!» (к) (тм)
Разница только в том что «за свои 20+ лет опыта» это смотрится исключительно как «ну это нормально» и «о маленький пипектор значит надо ожидать чего-то такого ещё и смотреть внимательно чтобы за недосмотром не пропустить потому как опыт говорит что будет больно». Речь конкретно об этом.
Это работает я проверял. ))
ЗЫ: вот прямо сейчас на одном проекте boost привязан только потому что у boost::thread есть interrupt() / interruption_point() хотя код этот последних тех самых 20+ лет исполняется исключительно на
И это только одна «крутая фича» одна из вот смотри здесь же ж в тредике есть «крутая фича стиля кода if (true == _something_) и таких «крутых фичей» не счесть.
Фишечка же ж ещё и в том что они не пишут LLVM )) просто у них «маленький пипектор» и это означает именно то а вовсе не то что «они пишут LLVM».
Я проверял. ))
Writing style
Я могу в плюсах перестать делать отступы и назвать это coding style :)
ты точно в этом месте не практикуешь то самое «завышенное чсв»?
Не думаю так. Но тут уже вопрос относительный, и явно лежащий вне изначальной темы про пипекторы.
Я говорил про завышенное ЧСВ в контексте работы. Когда миддл приходит на проект и говорит: «все эти синьоришки — дураки! не используют смолл пипекторы потому что не представляют, насколько это круто! ща я втихаря, не спрашивая их жалкое мнение, закоммичу им пипектор за щеку, они увидят этот приятный сюрприз и признают мой гений! а заодно з/п мне поднимут и массажистку для чресел в знак благодарности приведут!»
Ты не на том уровне чтобы «консультировать синьоров/архитекторов насколько им это нужно». И всё.
Не тебе решать, на том я уровне или не на том. Опять судишь рабочие процессы исключительно по своим проектам и применяешь ко мне свои умозаключения вида «на моём опыте было так — значит и с тобой должно быть так».
Синьоры/архитекторы, которые вели со мной диалоги на тему использования чего-либо в коде, так не считают, потому что у меня с ними всегда получался конструктивный диалог, без срачей и прочей фигни. Иногда они давали добро на реализацию моей идеи, выслушав мои аргументы. А иногда объясняли мне, почему эта идея плохая в случае с нашим проектом — что позволяло мне с какой-то стороны лучше понять специфику проекта и стать более эффективным в своей работе.
Я тебя удивлю: даже когда я был джуном, синьоры ко мне приходили с вопросами по C++ и не стыдились этого. Потому что человек может то словить трудночитаемую ошибку в каких-то темплейтах, то случайно написать most vexing parse и удивиться, почему переменная не создаётся, то ещё на какие-то плюсовые грабли наткнуться. Синьор чаще думает о более «глобальных» вещах о проекте, технические нюансы редко встречающихся кусков C++ он уже может помнить не так хорошо, как джуны/миддлы.
Плюсы я знал хорошо уже тогда, поэтому помогал — и ничего зазорного никто в этом не видел.
Всё потому, что они синдромом «я начальник, ты дурак» не страдали, вот и всё.
Если у вас на проектах отношения между сотрудниками были такие — опять же, это ваше дело, но не стоит думать что все работают по такому же принципу.
«о маленький пипектор значит надо ожидать чего-то такого ещё и смотреть внимательно чтобы за недосмотром не пропустить потому как опыт говорит что будет больно»
Давай не будем смешивать две принципиально разные вещи.
1) Когда человек в обход архитекторам/коллегам/здравому смыслу взял и закоммитил этот «пипектор», ни с кем не советуясь (и когда раньше данная фича нигде в проекте не использовалась).
2) Когда человек только сказал, что знает о такой вещи, и не более того.
Я говорил о ситуации (2). Если только по такой фразе ты сразу делаешь вывод, что этот человек будет гадить, — это неправильно. Может в статистическом смысле и оправдано (хотя слабо верится), но ко всем уж точно не применимо. Поэтому я и встрял в спор.
В бытие джуном меня задолбало доказывать синьорам, что я не собираюсь перевести весь их код на темплейты с policy-based design’ом и втихаря это закоммитить тёмной-тёмной ночью, когда все спят, злобно хихикая и потирая потные ручонки, только потому что я — о, ужас! — обмолвился, что прочитал книгу Александреску. Ведь когда-то у них работал джун, прочитавший эту книгу, и он творил такую фигню. Это так глупо.
Фишечка же ж ещё и в том что они не пишут LLVM ))
Я тоже не пишу LLVM. Поэтому на нынешней работе за почти полтора года смолл вектор пока использовать не доводилось ни разу. Хотя знал о нём прекрасно всё это время, и коллегам интересующимся рассказывал.
Может, когда-нибудь в процессе профайлинга, если придётся улучшать перформанс, обнаружится место, которое можно будет соптимизировать смолл_вектором — и тогда мы его подключим (буст у нас давно доступен, так что это будет несложно). Но пока что такого не случалось.
А вот в геймдеве, где я успел немного поработать до этого, тема со смолл векторами очень популярна. Так что не одним LLVM’ом.
Я могу в плюсах перестать делать отступы и назвать это coding style :)
Можешь более того даже переводы строк не есть обязательны чай не недоязыкпитон какой.
Не тебе решать, на том я уровне или не на том.
Почему? А кому?
Я тебя удивлю: даже когда я был джуном, синьоры ко мне приходили с вопросами по C++ и не стыдились этого.
А ну ок. Я всё завидую просто.
Можешь более того даже переводы строк не есть обязательны.
Могу. Просто читать будет неудобно. Потому и сравнение такое.
Почему? А кому?
Архитекторам и девелоперам из команды, с которой я непосредственно работаю.
boost::small_vector
на куче собеседований на синьорию такого не спрашивали нигде))
ну я вроде как пытался писать самодокументированный код
замечательно. вот открыл я случайным образом файл — думаете у меня будет время втыкать, как вы там его используете? я не говорил, что нужны комментарии в каждой функции. но хотя бы написать, зачем нужен класс было бы неплохо, мне так кажется.
Не нужно. Хочешь доку — юзай doxygen.
А ТС разумно было бы в стиле доксиджена комментов в важных местах повесить.
значить ти не був на проекті де пишуть самодокументований код, без коментів
Да нормальный код у тебя с большего.
Только разберись еще с make, cmake, doxygen, как инструментами. В работе полезно.
А к синьорству снова станет понятно, что reserve чаще не нужен, чем нужен. Вне критических мест он обычно он ничего не решает, а во внутреннем цикле будет только все тормозить, т.к. амортизированная алгоритмическая сложность реаллокации в vector обычно намного меньше, чем сложность цикла.
при чем тут алгоритмическая сложность? при частых реаллоках основная проблема — фрагментация памяти
Ну а с частым reserve фрагментация лучше не будет (а с редким — не важно). Алгоритмическая сложность при том, что постоянно изменяя размер вектора, реаллокацию c рантайм задержками мы вызываем достаточно редко. То есть не будет реаллока на каждый чих. Обычно на каждое удвоение размера, но не обязательно. А дергая reserve где-то внутри, точно лучше не будет. А снаружи ничего не выигрываем.
Это просто помимо того факта, что это premature optimization, где бы сначала померять.
UPD: www.quora.com/...-Assume-default-allocator про amortized constant time of push_back.
суть резерв, что его звать нужно один раз за весть лайфтайм аппы. иначе, да, алгоритм преаллокации как правило умнее
один раз за весть лайфтайм аппы
имхо маленькое утрочнение «за весь лайфтайм вектора» потому как если вдруг есть вектор у которого лайфтайм равен всему лайфтайму аппы и который делает reserve(...) то там уже всё криво задумано изначально. Я проверял. ))
хм. можно пример?
Пример того что я так не делаю? А ну ок вот пример того что я так не делаю:
nop
— видите? Я так не делаю.
Dummkopfhysterischeprogrammiererin
уровень аргументации: dou.ua/...rums/topic/24705/#1400343
шах и мат.
P.s. что и требовалось доказать.
в течении года, полтора по
Не знаю, уже второй месяц на договорах сижу
Ну может если появится пишите, если к тому времени не найду ничего... По крайней мере я все-равно продолжу самообучение)
да тут я нарушил правило где выделяешь память там и удаляешь. Хотел переделать и забыл. В функцию приходит обычный указатель, выделенный при помощи new (processEvent) и только после проверки сохраняется в умном указателе
Да я потом досмотрел — регистр переменной иной (вот, кстати, сбивает столку без ИДЕ) ... в принципе все верно вышло, но не логично нифига. Используйте std::shared_ptr, почему нет? В самом классе GameState запретите создание 2х копий (синглтон) и все.
Можно еще создавать сам объект класса вызовом статик метода его, который вернет шаредптр, а конструктор в приват. Таким макаром — вы точно можете отслеживать не создание второй копии из самого класса. Вообще это и есть идея ООП, если класс не хочет 2 копии, вот он и не должен позволят их делать. А внешние (к этому классу внешние) условности только мешают.
ммм GameState абстрактный класс
Я не копал, как он там у вас называется. Преположил логичное название. Пускай потомок определит, что нужно. Хотя в таком варианте, будет несколько излишне дублировано — в каждом потомке определять создание. Можно было бы завернуть простенький «создаватель» (фабрика) — шаблон, который френд всей этой иерархии (ну и желательно, там же описан рядышком).
Лучше не удалять ручками вообще. И не выделять сырым new без крайней необходимости.
Помимо прочих проблем, вы ещё и жертвуете exception safety с таким подходом: если между вызовом new и заворачиванием указателя в смарт поинтер вылетит эксепшен, память утечёт.
Выделяйте изначально через std::make_unique или std::make_shared (смотря какой смарт поинтер вам нужен) и не парьтесь.
Если шарить владение объектом ни с кем другим не нужно, и нет нужды в weak ссылках на него (способных проверять, жив он ещё или нет) — предпочитайте unique_ptr. Шаред_поинтерами часто злоупотребляют не по делу и переплачивают за неиспользуемые вещи.
Именно. Просто рассылай резюме и займись плотнее английским, он очень часто нужен и не только в варианте читать.
На джуниора точно можно претендовать. Только аккуратнее с зарплатными ожиданиями, а то нынче некоторые джуны без коммерческого опыта просят больше 1к$ потому что айти, трустори
Да мне много не надо) Хотя бы ворваться и опыта набраться) Все-таки когда спросить не у кого, намного сложнее. А там уже я смогу проявить себя)
В целом, неплохо, но я бы поработал над:
1. Осмысленностью коммитов (об этом уже написали, но все же): делать коммиты меньше, каждый коммит должен фиксировать одно изменение (максимум — несколько небольших, но связанных между собой), которое можно понять и просмотреть за пару минут.
2. Описанием проекта/комментариями. Если уж выкладываешь проект на github, позаботься о том, чтобы людям не нужно было судорожно тыкать в файлики с исходниками с целью понять, о чем проект. Сделай нормальный README.md: о чем проект, какие нужны зависимости, какая версия компилятора, etc. Если у проекта есть какой-то минимальный GUI (пусть и консольный), вставь в README.md пару скриншотов.
3. Понятной процедурой сборки проекта: напиши Makefile, опиши процесс сборки в README.md.
4. Структурой проекта: распихай сорс файлы по папкам, в идеале на верхнем уровне вообще не должно быть исходников.
Спасибо, буду исправлять и дополнять) Я первый раз просто спрашиваю мнение других, до этого все сам изучал и делал как придумалось)
Ещё в Readme нужно вставить инструкцию о том, какую минимальную последовательность действий выполнить, чтоб всё собрать, запустить, и посмотреть что из себя проект представляет. Кроме того, не помешает выложить скомпилированный релиз, по возможности без увязок на какие-то компоненты, требующие дополнительной установки. То есть, по крайней мере со статической линковкой RTL.
Кроме того, не помешает выложить скомпилированный релиз, по возможности без увязок на какие-то компоненты, требующие дополнительной установки. То есть, по крайней мере со статической линковкой RTL.
Не нужно. Достаточно четко описать процедуру сборки. Примеров на гитхабе полно.
Только не советовал бы ему заморачиваться раньше времени в автотулами. Лучше сразу Смаке — он удобнее и понятнее автотулов.
Всмысле нужно еще подтягивать знания?
На C++ на сегодняшний день уже пейсать нечего, последние игры что писались на C++ были года 3 назад, под windows phone. Сейчас Microsoft к сожалению болт забила на мобильный рынок, и даже там акцент принудительно был смещён в сторону дот нета. Что там ещё? Писать ядро нового игрового движка на C++ ты врядли будешь.
Просто вложены силы уже в C++... Не хочется бросать да и нравится мне))) Хочу прийти к логическому окончанию и устроиться на работу)
На C++ на сегодняшний день уже пейсать нечего
омг
омг
Это точно, всем оставшимся разработчикам С++ на сегодняшний день уже за тридцатник как минимум.
поэтому нечего писать? логика...
уже за тридцатник
А вот и не угадал!
Траль, ухади!
git ужасен, учись делать небольшие коммиты и поддерживать чистоту в репозитории (не включать бинарники, локальные файлы конфигураций, ...)
Как можно нормально сделать ревью коммита Release. Showing  193 changed files with 1,285 additions and 583 deletions я не представляю. Думай о тех, кто будет читать твой код.
Чел учился. Это все нормально.
как для евро-джуниора — норм
для украинского джуниора — конечно все плохо. ни тебе ангуляра ни вуй (или как там его еще)
ни тебе ангуляра ни вуй
Во-во, даже спринга завалящего нет :)
spring just around the corner:
pics.me.me/...d-the-corner-25884430.png
Не сомневаюсь, просто интересует мнение других. Может посоветуют что-то, укажут на ошибки заранее перед собеседованием или выполнением тестового задания
А що, буває такий рівень знань, що не сумніваєшся?
А я всегда сомневаюсь в том, что написал.
Yuriy Pavlenko
Viktor Chyzhdzenka
Alex Syrotenko
Ольга Диунова
Andrii
Ювженко Денис
Dmitry Panfilov
Serhiy Serbin
Valeriy Zamarayev
Женя Ходос
Oleksiy Zakharov
Dmitry Danevskyi
schwarzlichtbezirk
Andrew Sevastianov
Vlad Stelmahovsky
Dmitry Bugay
Олексій Пєніє
Alexander Lisovets
211 комментариев
Добавить комментарий Подписаться на комментарииОтписаться от комментариев