Why do people and companies use more C++ than C?

[MagicPoulp]

C is faster most of the time. C is simpler with less concepts. C has the possibility to be object oriented. C compiles faster. C is the language of OSes and has a better ABI than C++ on all OSes. There is nothing C++ does that cannot be done in C. C makes smaller binaries. One can manage memory in a safe way if one is careful.

OK C++ has libraries on may want to use. But C also has libraries. It is easier to collaborate in a C project due to less crazy style rules.

It is more abstract and details to deal with pointers arithmetic. But after some time it becomes very intuitive. A char* is a simple as a std::string.

I think it is more a culture thing that so many projects and companies choose C++. From a technical point of view and practical point of view, it seems to me C is better.

[arzgi]

Why don't people use assembler? I think that higher level languages have structures that are close to spoken language, and have some functionality, that makes programmers task more easy.

C besides has reputation of some wrong used pointers to halt the used computer completely.

[MagicPoulp]

I have used both C and C++ during thousands of hours. I was professional C developer 3 years, and C++ developer 2 years. So let me give some more facts.

All the C++ containers (vector, list, etc) will perform a small dynamic allocation every time you add one element. This can make the program slower by stalling other threads.

When you store variables inside a class, it can bloat your data structures and take more memory than needed.

The google C++ guide bans exceptions and the pimpl idom. AN example of C+ concepts that can be misused and are therefore banned.

And the facts speak for themselves. nginx, the fatest webserver, is in C not in C++. The Linux kernel is in C. So the benefits of C are well known and documented.

C++ is not that much high level. It is rather medium level. Python and C# are much more high level. The build systems in C++ require lots of skills to manage and change all the time. Automake for C is basically the same since many years.

I think the truth lies in the fact that companies and people want to reduce the abstraction degree in the programming. They think that pointer arithmetic requires too much concentration or skills to avoid mistakes.

I respect your opinion arzgi. Preference is subjective. But in terms of fact, I am not convinced.

Actually, in terms of job market opportunities, companies will use more Java and C# rather than C++. To simplify the work. ANd so they can outsource a part of the development. But it has a cost on performance and product quality.

[neuraleskimo]

I have used both C and C++ during thousands of hours. I was professional C developer 3 years, and C++ developer 2 years. So let me give some more facts.

A bit harsh toward your friend there don't you think? Well, I have been programming in C and C++ for 25 years. I am also a researcher and teacher, so let me give some more facts. See how that works. By the way, I know there are people who can school me on C++. I marvel at their talks and code.

All the C++ containers (vector, list, etc) will perform a small dynamic allocation every time you add one element. This can make the program slower by stalling other threads.

Not quite true. std::vector has a reserve function that you can use to allocate a chuck of memory that you can later fill via calls to emplace_back(), push_back(), etc. When created, std::vector will allocate a small amount of memory (implementation defined) anticipating a few inserts. When that reserve is used, std::vector will reserve more. How much it grows is dependent on the implementation and current size. Having said that, there is one issue with std::vector. When it does allocate, it creates a new memory buffer and copies data. Some implementations, like QVector, use realloc() under the hood to avoid copying. However, in the end, std:vector performs very well.

Also, threads are not really an issue. Certainly not other threads. The reason allocating memory is slow is that it requires an operating system call. This has nothing to do with threads. Having said that, yes, there is some locking in most operating systems when modifying system wide resources, but that isn't an issue here.

When you store variables inside a class, it can bloat your data structures and take more memory than needed.

No. Storage of types in C and C++ are pretty much the same. Most implementations align variables on word boundaries for performance. That is they trade memory access speed for memory size. By the way, there is no difference between a C struct and a C++ struct. Also, in terms of storage there is no difference between a C++ struct and C++ class.

As for the rest of your post, the advantage of C++ is abstractions that collapse when compiled (I stole that insight from someone else). In fact, some C++ code is faster than hand-rolled C code. I can easily demonstrate that. However, does that make C++ better? There are lots of good reasons to not use exceptions. Does that make them universally bad? Of course not. Same for PIMPL.

[neuraleskimo]

Why don't people use assembler? I think that higher level languages have structures that are close to spoken language, and have some functionality, that makes programmers task more easy.

I agree. I hesitate to say the point of C/C++ and friends, or perhaps more correctly, the lesson is that well-crafted abstractions can compile simply and easily into instruction streams that a very experienced human would struggle to beat with assembly. Well-crafted abstractions cost little or (as the C++ committee strives) nothing. You will often hear the term "no cost abstraction" or the phrase "you don't pay for what you don't use." Some languages (e.g., C++) place a premium on no-cost abstractions and some languages do not. In some instances, the no-cost abstractions can be a little more difficult to use. But it isn't a question of better-or-worse/good-or-bad. Also, sometimes the no-cost abstractions extract a heavy compile-time cost. Again, that is neither good or bad. It is the cost of doing business in C++. If you want the performance, then you pay the compile-time cost. This is even more true now with constexpr.

[MagicPoulp]

A bit harsh toward your friend there don't you think?

harsh? My first sentence contains nothing judgmental, only a fact. You cannot be harsh when you give a fact or in that case you are not allowed to talk. I have no intention to school people. I am just interested about this topic. I even said to the guy that I respect his opinion but that I am not convinced by his argument that, like assembly, C is lower level.

What you said about <vector> reserving large chunks does not apply if elements are pointers or if the container is a list and not a vector. STL containers fundamentally use lots of dynamic memory. It is fundamental knowledge. Even if vector reserves large chunks, it still performs dynamic memory. An array on the stack in C does not allocate heap memory. And you have full control how you want to allocate on the heap if you want.

It is also fundamental that the memory allocator can stall other threads if you do many small dynamic memory allocations. If you are making an application that parses data spread over all threads, then you'd better not use STL containers.

By class bloating, I was referring to the OOP practice to have large structs with many variables that are unused just because it looks OOP.

The most common case for which C++ can be faster than C is when optimizing knowing better the types. But all the small layers like exceptions and functions embedded in structs will potentially make things slower. The amount of work to create a vector is huge. Many instructions. Same for smart pointers. Many things are added for this mechanism. If you are a good programmer you can skip smart pointers and be faster.

Only because of smart pointers and because of the syntax, I understand why people and companies prefer C++ over C. But it is more a cultural thing. In practical terms, one can do very good things in C with full control. It is not at all like using assembler and getting slow because being too low level. Of course the level of details can be high in C. But one gets used to it.

If you use gtest, you need to make your functions public and virtual to test them. Quite ugly in my opinion.

There is a lot of hype now for Rust. It is interesting. But I think perfecting oneself in C would achieve more than learning all the many concepts of Rust. But I see this more in solo programming. C may be hard to scale in large projects. I have difficulties to read through the linux kernel source code.

There is still a paradox. For very performance critical applications, companies will chose C++ over C because C++ is more safe. But in raw performance, it would go faster in C. If at wall street in the financial world, an application needs to calculate very quickly the stocks variations. ALl those layers I talked about take time. But they'd rather want the program to be correct than faster.

[neuraleskimo]

A bit harsh toward your friend there don't you think?

harsh? My first sentence contains nothing judgmental, only a fact. You cannot be harsh when you give a fact or in that case you are not allowed to talk. I have no intention to school people. I am just interested about this topic. I even said to the guy that I respect his opinion but that I am not convinced by his argument that, like assembly, C is lower level.

Whether you intended to do so or not, giving the short version of your resume is generally a form of telling people you are superior and telling them to not talk. It also contributes nothing of value to a discussion.

@arzgi gave you very good advice in the form of a question. I then elaborated a bit on her/his advice. Also, in a previous post, I gave you a link to Compiler Explorer. If you combine the advice arzgi and I gave on abstractions with the ability to see REAL assembly code (instead of speculating), I think we can all learn a lot about the issues that concern you.

On the rest of your post, there are a number of suggestions that I can offer; however, it will take me a few days to get to it.

[MagicPoulp]

Whether you intended to do so or not, giving the short version of your resume is generally a form of telling people you are superior and telling them to not talk. It also contributes nothing of value to a discussion.

You see things that I did not say. Read again.

The quality of knowledge of one person depends on experience in the area. A PhD in climatology has more quality knowledge than the first TV driven politician around. Same in programmin.g If you practice a lot, you know more and should not hide that you practiced to know what you are talking about.

Besides, 5 years with C/C++ is not that much. A programmer usually work around 45 years.

[MagicPoulp]

One more example.

In C, it is custom since many years to define constants at the top of the file using macros. It makes the code clear without magic numbers at many places in the file. And it has a slight optimization since it resolves values at compile time.

But most C++ style guides forbid to declare constants using macros.

[neuraleskimo]

One more example.

In C, it is custom since many years to define constants at the top of the file using macros. It makes the code clear without magic numbers at many places in the file. And it has a slight optimization since it resolves values at compile time.

But most C++ style guides forbid to declare constants using macros.

Ok, I have a few spare minutes to give you an example...

Paste the following into compiler explorer:

Code: Select all

#define x 5
const int y = 4;
int z1 = 2 * x * y;

constexpr int f()
{
    return 2 * x + y;
}

int z2 = f();

Experiment a little by changing f() so it uses only x or only y. Also, try removing constexpr.

Using what you see, why do so many style guides recommend avoiding macros?

[neuraleskimo]

I found a few more spare minutes for another example...

Paste the following code into compiler explorer.

Code: Select all

#include <memory>

const size_t array_size = 10;

void f1()
{
    int* ptr = new int[array_size];
    // some code
    delete [] ptr;
}

void f2()
{
    std::unique_ptr<int> ptr {new int[array_size]};
    // some code
}

Smart pointers are another good example of a zero-cost abstraction. If you try this code with Clang 8.0, you will see that f1() is a few instructions larger than f2()! If you try GCC 8.3, you will see that f1() and f2() are exactly the same size.

The connection between the last two examples is that the extra safety introduced by the abstractions has zero cost. Of course that isn't true of all C++ abstractions, but in general C++ strives for zero-cost or low-cost abstractions as much as possible. Put another way, performance and safety DO NOT HAVE to be mutually exclusive.

Here is my challenge to you... Using compiler explorer and the above observation, can you answer some of your questions/objections?

[MagicPoulp]

Yes there are good reasons why C++ guides require certain things. For macros, I was used during many years to put defines at the top of the file, with C, and it made me feel the code is clearer. Then a C++ project and the team forbids me to use defines. Instead we put const variables inside a namespace if it is a string or in the class otherwise. Feels much less clear. And it felt like C++ requires thousands more conventions. And every person has a different taste and opinion.

This debate is not new. But in my opinion, the use of C is neglected for cultural reasons. People then can say they managed to master a language like C++ that has many concepts and that takes many years to learn. But plain old C would work just fine in many cases. Nowadays, I don't think any commercial project would use C unless the hardware requires it or the developers actively prefer C. Open source projects still use C quite a lot. Examples: nginx, gnome, etc.

Does anyone know why is Gnome in C and not in C++? I could not find yet.

https://developer.gnome.org/programming ... le.html.en

The little I found say it will be more portable.

I also found that a few high budget commercial games are in C to boost performance and portability.

[fender0107401]

I use C and C++ a lot. I prefer C++, because it provides more easy way to manage the source codes. For a large project, C++ is a more reasonable choice. Try to consider that you are designing a GUI application. Every window or dialog can be one class.

You should try to write a C++ project and you will find OOP is really and really useful! C only provides "function" but C++ provides "class".

However, everything has its price. <The C Programming Language> is not a heavy book, but <The C++ Programming Language> is thick. So, a C++ programmer needs more time to learn.

[MagicPoulp]

That you prefer C++ because of the class keyword is not enough.

You can make something equivalent to a class in C. There are different alternatives. One is the GObject, another is to use raw function pointers (as simple as a struct with pointers to functions).

https://github.com/zorgnax/gobject-exam ... gaccount.c
https://codereview.stackexchange.com/qu ... ructs-in-c

Besides, object-oriented programming is not always better. There are cases that don't suit. The classes may result in memory fragmentation.

By the way, you should know that gnome the desktop environment is built in C and on GTK that uses GObject. This made me choose Gnome instead of KDE for my new wayland enabled desktop environment.

The apache httpd webserver is in C++. nginx is in C. The latter wins all the benchmarks. And this is because it has no overhead from object-oriented rules.

[MagicPoulp]

This link below is interesting. There are 2 clans depending on preference.

https://softwareengineering.stackexchan ... python-etc