Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "c++ cpp workplace recruitment"
Ok c++ professionals out there, I need your opinion on this:
I've only written c++ as a hobby and never in a professional capacity. That other day I noticed that we have a new c++ de developer at the office of which my first impression wasn't the greatest. He started off with complaining about having to help people out a lot (which is very odd as he was brought in to support one of our other developers who isn't as well versed in c++). This triggered me slightly and I decided to look into some of the PRs this guy was reviewing (to see what kind of stuff he had to support with and if it warranted his complaints).
It turns out it was the usual beginner mistakes of overusing raw pointers/deletes and things like not using various other STL containers. I noticed a couple of other issues in the PR that I thought should be addressed early in the projects life cycle, such as perhaps introduce a PCH as a lot of system header includes we're sprinkled everywhere to which our new c++ developer replies "what is pch?". I of course reply what it is and it's use, but I still get the impression that he's never heard of this concept. He also had opinions that we should always use shared_ptr as both return and argument types for any public api method that returns or takes a pointer. This is a real-time audio app, so I countered that with "maybe it's not always a good idea as it will introduce overhead due to the number of times certain methods are called and also might introduce ABI compability issues as its a public api.". Essentially my point was "let's be pragmatic and not religiously enforce certain things".
Does this sound alarming to any of you professional c++ developers or am I just being silly here?9