Pour obtenir une clé
d'essai remplissez le formulaire ci-dessous
Demandez des tariffs
Nouvelle licence
Renouvellement de licence
--Sélectionnez la devise--
USD
EUR
RUB
* En cliquant sur ce bouton, vous acceptez notre politique de confidentialité

Free PVS-Studio license for Microsoft MVP specialists
To get the licence for your open-source project, please fill out this form
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

I am interested to try it on the platforms:
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

Votre message a été envoyé.

Nous vous répondrons à


Si vous n'avez toujours pas reçu de réponse, vérifiez votre dossier
Spam/Junk et cliquez sur le bouton "Not Spam".
De cette façon, vous ne manquerez la réponse de notre équipe.

>
>
>
How to spot C and C++ developers by the…

How to spot C and C++ developers by their code

12 Mai 2022
Author:

We happen to write code for IoT stuff related to electricity, like car charging stations. Since hardware resources are usually sufficient, our main goal is not to save on every byte possible. Our main goal is safe and readable code. That's why our project developers work on Embedded Linux. They also use C++ in its modern version (C++17) as a main language and can't stop thinking about the new features from C++20 and newer (wait, did somebody say Rust?).

0946_C_Cpp_developers_difference/image1.webp

We published and translated this article with the copyright holder's permission. The author is Kirill Ovchinnikov (kirill.ovchinn@gmail.com). The article was originally published on Habr.

0946_C_Cpp_developers_difference/image2.webp

Sometimes we need to ship new projects on the same platform with the same processes, and we reuse many existing components. In this case, we are looking for new developers, more precisely — C++ developers. However, pure C is still in demand for embedded systems, and C developers are the ones who try for C++ developer positions. The logic is simple: the languages are quite similar and almost backward-compatible; the base syntax is the same. Besides, if the developers heard something about OOP, then they think they know the base and can easily learn C++ in 21 day. That's why they BS their way through the interview with "Yeah, I worked with C++". They hope to start writing on "C with classes" and succeed. But the new team already has a couple of such ex-C developers. What we need is a hardcore C++ developer who would cheerfully implement best practices and set junior teammates on the path of righteousness during code review.

0946_C_Cpp_developers_difference/image3.webp

Yes, C and C++ languages look similar. However, the more you know about these languages, the more you realize that they differ. As a result, you can easily distinguish a C developer from a C++ developer during an interview or review. Our team has created a list of signs that give out a C developer trying for a C++ developer position. If we see such signs, we start a more serious conversation like "why did you write the code this way?" So, here are the signs that you're talking to a developer who writes code on "C with classes":

  • Uses <stdint.h>, <string.h>, <stdio.h> instead of <cstdint>, <cstring>, <cstdio>;
  • Uses malloc() and free() except for designated places (like custom allocators);
  • Uses manual memory management with new and delete, instead of RAII and smart pointers;
  • Uses char* strings and <string.h> functions instead of std::string and std::string_view (the only exception is string constants via constexpr). Uses functions from <time.h> instead of std::chrono. Uses atoi() instead of stoi(). Uses functions from <stdio.h> instead of std::filesystem and IO streams. Uses <pthread.h> instead of std::thread;
  • Uses #define macros or void* pointers instead of templates. C developers use them when it is necessary to implement an algorithm or container independent of the data type it operates with;
  • Uses #define instead of const and constexpr to declare constants;
  • Uses C-style arrays instead of std::array;
  • Uses NULL instead of nullptr;
  • Uses (type)something instead of static_cast<type>(something);
  • Uses simple pointers to functions instead of std::function;
  • Uses enum instead of enum class even for simple enumerations;
  • Does not use const when declaring a function that does not change the state of objects. Forgets explicit for constructors; forgets virtual for destructors :)
  • Declares all class members as public when developing in OOP style;
  • If they need to return several different values from a function (for example, the result of work and/or an error code), then they return one of them via return, and the other by pointer or by a non-constant reference – instead of using std::optional, std::pair/std::tuple (especially good when paired with structured binding) or simply returning struct;
  • Always writes struct in the type name when declaring a new variable with a struct type. Or vice versa, when declaring a new structure writes typedef struct instead of just struct;
  • Does not use namespaces when structuring code;
  • Uses union instead of std::variant (by the way, you can't use union for a typing pun either, it violates the active member rule);
  • Writes implementations of commonly used algorithms (foreach, transform, find_if, sort, lower_bound, etc.) manually even if they are in <algorithm>;
  • Writes verbose constructions instead of range-based for during a simple iteration through the elements of the container; does not use auto and using in verbose type constructions;

A few additions from the comments:

  • Uses bit fields instead of std::bitset;
  • Uses C libraries directly without an abstraction layer above it;
  • Has a lot of includes in the header files that could be avoided (incomplete class).

If you are a hardcore C++ developer, and when reading this list, you have a burning disagreement with some of these points — that's great, then you really are a hardcore C++ developer. And for the rest of you, perhaps, I'll note that there are exceptions for many of the described situations. Everything depends on the specific situation. For example:

  • you may have a lot of contact with pure C libraries;
  • the project can use an ancient toolchain that knows only C++98. Truth be told, when working in such projects, you need to demand a huge paycheck and a hazard pay. My advice: don't take these tasks at all :);
  • you use Qt that has its own ownership model and uses new everywhere;
  • std::string is not suitable when you can't work with dynamic memory (although, here it's possible to come up with something interesting with custom allocators);
  • abstractions leak sooner or later: you won't be able to create std::fstream from an existing and open posix file descriptor (although some stdlib implementations can do this). By means of <thread> you won't be able to prioritize a thread, and much more;

After all, these are special cases. If a person can competently justify the use or non-use of a particular language construct or API, then this already speaks about his skills and should be taken as a plus.

Comments (0)

Next comments
Unicorn with delicious cookie
Nous utilisons des cookies pour améliorer votre expérience de navigation. En savoir plus
Accepter