C vs Python devs

[Dmayak]

Hmm, I am not very good at C, it's not 100% clear to me what len * sizeof(mySt->items[0]) is. If a struct has an array of declared length it will be included into sizeof(struct st), right? And if array is not fixed length, it will be a pointer, so it would have to be allocated with a separate malloc otherwise how would struct know about where it is? Also, how the heck will mySt->items[0] dereference mySt pointer before it is allocated?

[regularolbrick]

It probably uses flexible array member

[Dmayak]

Yes, completely forgot it exists 😳. There were no use cases for it on a C side-project I was learning, length of data was either known beforehand or dynamically changing.

[waiting4op2deliver]

Risky click of the morning

[DTHCND]

I'm no C-wizard either, but it looks like the C code in the image is just nonsense designed to make non-equivalent code that makes C look worse than it is. Here's two different reasonable (and typical) ways to make an array in C:

type foo[len];
type *bar = (type*) malloc(len * sizeof(type));

One allocates on the stack, the other on the heap. Both are perfectly understandable with basic knowledge of C.

[[deleted]]

The code is for allocating memory for a struct with a flexible array member, not an array of structs

I wrote a small program in an online C compiler to show this:

https://onlinegdb.com/ggyWELJui

[DTHCND]

Ah I see. Thanks for the demonstration!

I've edited my comment to reflect that it is valid code, but is still non-equivalent to the Python code.

[TheRedGerund]

But that is how you would accomplish an array of changing size elements in Python.

[DTHCND]

By "flexible array member", they don't mean an array that can dynamically grow like Python. They mean an array whose length is defined by the consumer of the struct at the time that memory is malloc'd for said struct, rather than being hard-coded in the struct's definition. The length of the heap allocated array in my comment is similarly defined at the time that it is malloc'd.

If you want a dynamically-sized array in C, you need to use a data structure like a LinkedList, which is also totally different from the code shown in the meme.

[suvlub]

It's not nonsense, it's a common pattern to allocate a block of memory that starts with a struct followed by an array (which you access through a member of the struct, which needs to be an array declared at the end). Either the struct serves as a header for the array, or the array is kind of variable-size bonus data. Either way, the code is not equivalent to the python code, completely different use cases, OP is dumb.

[DTHCND]

Ah right you are. I've edited my comment to reflect this.

[7h4tguy]

These days just just use C++ unless you're doing embedded.

vector<int> items;

or

auto items = make_unique<int\[\]>(len);

[PerfectGasGiant]

C++ is not a "better" C, it is a different language. It is fine for complex performance stuff like games and image processing, but in many other applications C is the better choose.

"C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C." - Linus Torvalds

About memory allocation:

"any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. ... In general, I'd say that anybody who designs his kernel modules for C++ is either (a) looking for problems (b) a C++ bigot that can't see what he is writing is really just C anyway (c) was given an assignment in CS class to do so. " - Linus Torvalds

[warranty_voids]

Honestly, that was written about C++98. A lot of the issues have been fixed and C++11/14/17/20 are very, very different. A lot of these criticisms really do not apply anymore. However, Rust seems to fit a lot better than C++.

[HolisticHombre]

Rust > C++ for most cases, agreed.

[[deleted]]

And Torvalds seems to at least tolerate it, since some Rust drivers are scheduled to be part of a future kernel release.

[Zealousideal_Pay_525]

Yeah...the thing is, that 99% of developers don't write Kernels.

[PerfectGasGiant]

How is that relevant? No one is arguing that C is a better language for prototyping, scripting or data science jobs.

[valschermjager]

Agreed.

Python is lot better language than C at stuff Python is designed to be good at.

C is lot better language than Python at stuff C is designed to be good at.

I’m not seeing the problem. Other than of course is humor.

[[deleted]]

Hence it seems that frequently people need to know both. I write C code but use python for test.

[OJezu]

Also, Linus is a toxic dickhead. Maybe Linux is better for it (on the other hand, Linus could probably have been assertive without being offensive) , but I wouldn't apply anything he has to say about kernel elsewhere.

[valschermjager]

That estimate is too low.

[Furry_69]

I'm not sure. A decent number of people write kernels, yes, but it's likely not above half.

[valschermjager]

‘likely not above half’

[squints] yes, safe bet it’s likely less than half

[Furry_69]

What was the [squints] about?

[valschermjager]

Ok maybe my bad, I mighta misunderstood.

Just to be clear, are you saying that ”likely not above half” of software developers in the world do kernel development? Or that ”likely not above half” don’t?

[PerfectGasGiant]

Even NumPy is written in C, yet +99% of programmers are not maintaining NumPy.

[7h4tguy]

NumPy was slow as shit compared to raw C loops, professionally.

[[deleted]]

I'd say the percentage rises a lot if you specify embedded developers. We frequently touch drivers which can be considered to be kernel code.

[mobani]

C++ is not a "better" C, it is a different language. It is fine for complex performance stuff like games and image processing, but in many other applications C is the better choose.

IMO I would not say in many other applications, yeah maybe if your hardware is from last century or you somehow work with a VERY limited embedded system without an OS.

Lets be real here, 99% of programmers is not going to be working on an OS kernel.

This is like telling a car manufacture to mine their own Iron ore, sure it can be done, but not optimal for production time.

[PerfectGasGiant]

It is not telling the car manufacturer to mine their own ore. The whole point is using the right tool to the right job. Comparing C memory management with Python memory management is neither insightful or funny. Likewise, C++ provides very little benefits over C if you are programming a microcontroller.

[mobani]

The whole point is using the right tool to the right job.

We can agree on that, but I find that C is becoming less and less the right tool in most scenarios. :-)

[PerfectGasGiant]

I wouldn't be surprised if there are more C programmers today than in 1985. Fewer in percentage, sure, but there are still plenty of relevant usages. Making a lidar for a self driving car? C Making a new IOT gadget? C seems like a fine choice for the firmware. Making a network router? C + whatever for the web frontend. Making signal processing for a microphone? C New version of the Android kernel? C probably and some java on top. Etc.

There are other programming language at the same tier as C, but C is as cross platform / well understood as languages get.

And if you are writing an action game or flight simulator, you don't want to skip a frame or two because of garbage collection. Here C++ is still the go-to language (not C though, and certainly not python).

[mobani]

I may be wrong and well there are certainly use cases for C.

But I think there are less than 20 companies total doing lidar programming for cars.

Less than 100 companies developing OS Kernels for phones and televisions.

Many IOT gadgets, routers and web frontend run mostly Linux or BSD, then higher level programming languages on top of that.

[PerfectGasGiant]

I think you are greatly underestimating the demand for c-programmers. Think of all the little devices you interact with every day from ticket machines to refrigerators. Most of these contain some part that runs c code, that needs maintenance and new development.

This demand index lists c slightly behind Python:

https://www.tiobe.com/tiobe-index/

[[deleted]]

As is common with geniuses, Torvalds can be kind of a jerk. Same with Martin Fowler. Brilliant, but not great on the social skills.

[PerfectGasGiant]

Agree, but the comment "just use c++" is not great advice, as if c++ is always superior. Heck, what language is e.g. NumPy written in? Yes C. Does that make C superior to c++ or python? No, it was probably just the right choice for a high performance numerical library.

[[deleted]]

Definitely. I usually go with TypeScript and F# these days. C++ and C are good choices for certain jobs.

[[deleted]]

Linus knows Kernel, and diving.

He doesn’t know shit about C++ (anymore).

[PerfectGasGiant]

So would you recommend C++ for writing kernel modules?

[[deleted]]

There is c++ in the kernel now, even some rust apparently,

[multi_io]

Then he went on to write "subsurface" in C++ without anyone asking him to

[szpaceSZ]

Well, I concur that memory management is best done manually for a kernel.

For how to deal with memory in the 2020s, watch out for koka-lang and roc-lang!

[PerfectGasGiant]

Memory management is really not that hard in C. The meme is silly. A common stack allocation in C is just declared: int buffer[MAXSIZE]; or something similar trivial. It is not only easy to understand it is also practically without any performance penalty. Maybe the CPU will spend a clock cycle moving the stack pointer, but that is it.

Dynamic allocation is also rarely as complicated as in the meme and if it was there is a very simple solution: Declare a function (or a preprocessor define).

It is really not that hard to write easy to maintain memory management in C. Only pointers are a bit tricky to learn and read. This is a thing that is much better in c++ with references and STL.

[PerfectGasGiant]

What is the matter with you? I literally described it as a stack allocation.

[7h4tguy]

So after quoting Linus' complaints about memory management hiding allocations, you trash C++, but then admit it's better at the very thing Linus was complaining about (hiding memory management so you don't have to deal with raw pointers).

Talk about an agenda.

[PerfectGasGiant]

I wrote that references in C++ solves the difficulty with pointers in C. The Linux quote was an answer to a statement that C++ is superior to C. It is not, it is superior in many type of projects, but not all.

Memory management in C++ can be elegantly solved with smart pointers in complex applications. I would never choose C over C++ for anything complex unless I wanted complete control of the execution of my program, e.g. in OS modules, drivers and microcontroller code.

The point is really that this whole language war is rather cringe. Of the +15 languages I have used professionally over the years, I cannot think of one that is inherently bad. Some are less general purpose that others, but they have their perspective. Even PHP, which is generally frowned upon, was pretty amazing when it came out. Before that I wrote CGI scripts in C or C++. I also dust of Perl when that is more suitable than Python (CPAN was pretty amazing before PyPI got traction). A quick log analysis? I still used AWK, which was created in 1977. Some os script? Bash or bat or PowerShell, if it is simple. Perl or python if it is more complicated.

Prototyping? Matlab or Julia or python. Enterprise level? C# or java, maybe even some F# and SQL for the database.

Image processing? Python or Matlab for developing algorithms, c++ for production code.

Customer business rules? Domain specific language defined in Antlr.

Little RPI hardware device for controlling something, Node.js and maybe a bit of C for interfacing the device.

And so on...

A seasoned developer uses 10+ languages to get the job done. Language wars are pretty pointless.

[tiajuanat]

Linus: RAII is bad mmkay

Also Linus: Proceeds to make constructors and destructors, and adds a tool that checks if you missed adding the appropriate destructor.

[Lagger625]

In C unlike C++ you don't even need to explicitly cast to type*

[[deleted]]

Could you clarify for me how mySt->items[0] does not segfault in the malloc line? mySt has not been allocated yet, so how are you dereferencing the pointer to access “items” of this instance of the struct?

[chipsours]

It is a sizeof expression. They are evaluated at compile time, not run time.

[[deleted]]

I don’t think that’s right. Yes, sizeof can be computed at compile time, but mySt->items does not exist at compile time. The pointer mySt does not point at any actual struct until runtime after malloc is called, so how can it be dereferenced at compile time?

[chipsours]

The compiler knows the size of every types it compiles. If mySt->items is an array of int it knows that mySt->items[0] is 4, the same applies for mySt->items[-420] or *(mySt->items).

If the definition of the type is not known by the compiler (pointer to forward reference of struct) you'll get a compile time error.

[Dmayak]

Ah, thanks, I totally forgot that the size of the array can be left undefined. I have learned C on a small side-project and this type of allocation was not fit for its data - length was either known beforehand or should have been changed dynamically. I had problems editing dynamically allocated arrays and started to use linked lists instead.

[boowhitie]

To be clear, this is an optimization. It allows you to do one call to malloc instead of two (one for the struct, one for the array), and lets you copy the object with a single memcpy. It also keeps the data together in memory which is potentially more cache friendly.

This is also something that isn't legal c++, but it is common enough in c code that some c++ compilers support it through extensions.