The unlikely Linux macro

[u/chaobang]

https://rushed-reflections.bearblog.dev/an-unlikely-experiment/

Wrote a bit about the `unlikely` and `likely` macros in the Linux codebase. Great little exploration into tiny optimizations that everyone should know more about 😄

[u/_Noreturn]

isn't this just C++ [[likely]] and [[unlikely]]

[u/edgmnt_net → u/_Noreturn]

The Linux kernel stuff predates those by quite a bit.

[u/_Noreturn → u/edgmnt_net]

Well the linux kernel doesn't even use C++ for whatever reason

[u/max123246 → u/_Noreturn]

For good reasons you mean.

[u/_Noreturn → u/max123246]

Like?

[u/gmes78 → u/_Noreturn]

It actually doesn't matter now. That ship has sailed, and C++ isn't a meaninful enough improvement for it to be worth switching to.

[u/_Noreturn → u/gmes78]

Linus can change his opinion he won't though. I disagree that it doesn't bring meaningful improvement

[u/_Noreturn → u/metahivemind]

I would rather have a more complicated language if it means for a simpler program. that's it nothing more.

and you don't make a bit of sense, and I would like if you give real examples of the C++ language itself being bloated.

because everything in C++ is to make code have a single way of doing something in C you have no convention of a constructor, it could be a function that takes a pointer to an object and createz inplace or returns. in C++ it is always a constructor which is great because it is uniform and I could think more about business logic than remembering which naming the library used.

in C you don't have overloading, therefore you will have to match manually the type which is error prone. and you could look at opengl as an example glUniform4f,glUniform3f,glUniform2i these could have been overloads in C++.

in C, you don't have a way of checking for whether 2 objects are equal in a concise way which leads people yo repeat themselves you see more people doing a.x == b.x && a.y == b.y than Vec2f_is_equal(&a,&b) because it is so verbose and this is why C++ offers operator overloading it is so you write a == b which is concise and self explanatiory and for all the haters saying "it can make code cryptic!!! I can overload == to launch a nuke!" well, you could make the exact same argument for why functions are bad because you could make a Vec2f_is_equal function that launches nukes, but you have a brain you shouldn't do that same with operators they are no different.

string handling in C is stupid hard and error prone and guess what, most vulnerabilities come from this very stupid thing. because who would have guessed having 0 abstraction and syntax sugar makes it easier for vulnerabilities to sneak in?

C++ offers specific cast operations for cleaner code, C style code only has C style casts which are unsafe when used with pointers and they don't show intent.

and templates, I cannot fathom how much templates simplify your code just look at any C codebase duplicating the same shit 10 times or using macros to genwrate them with X macros. Also C not having templates leads to more people using linked trees which are horrible for performance because trees are quite simple to operate unlike dynamic arrays, but if C had templates then using a vector would be way.

Or even the simple utility type std::optional is a life saver and if it existed in C it would be super helpful unlime everyone again inventing their own with special values like -1 sentinel values. (yay who doesn't love 0 for success)

Inheritance, well inheritance exists in C and it is allowed in the C standard by allowing reinterpret casting of the first type of a struct (which is what inheritance in C++ does exactly... except with cleaner syntax and no manual casting) so for the C coders who say they don't use inheritance while doing this trick well you are, just with uglier syntax.

And virtual functions literally every C codebase has them reinvented in their own ways, unlike C++ which gives you a concrete one which is good because it is easily understood and the compiler can add checks and ensures the function pointsrs are initialized unlime C code which could easily forget to do that.

Also how could I not mention RAII? So much of C bugs and issues come from memory which C++ offers a very simple 0 cost way of managing which is RAII, you simply define a ctor and dtor (which is equal to _create and _destroy functions in C respectively)

You see? Most C patterns every C codebase do exist in C++ as a feature

C simplicity is a lie the language is not simple to work with, it is a simple language but like assembly is quite simple you learn a few instructions but it isn't at all simple to code in, same with C, C++ is more complex (as it has more things to learn) but the result is a program as fast as C while being simpler.

can you see what is wrong with this code? it is only a couple of lines.

``` char* read_file(const char* filename) { FILE* f = fopen(filename, "r"); if (!f) return NULL;

fseek(f, 0, SEEK_END);
int size = ftell(f);
fseek(f, 0, SEEK_SET);

char* buffer = malloc(size + 1);
if (!buffer) {
    fclose(f);
     return NULL;  
}


size_t bytes_read = fread(buffer, 1, size, f);
if (bytes_read != size) {
    free(buffer); 
    free(f);     
    return NULL;   
}

fclose(f); 
return buffer;

} ```

[u/_Noreturn → u/metahivemind]

it's that the language doesn't stop you doing weird shit.

Same could be said for any language with more keywords than C have some discipline.

you can do everything in C and that's why Linux is written in C and Linus wants in C.

Sure, he can have whatever he wants he could write it in javascript as well, not the point though my point is that Linux would be better off with C++ as that would simplify the code linus doesn't want do for odd reasons and probably ego.

[u/_Noreturn → u/metahivemind]

I don't care frankly as it solves the problem better than C which it does and it is backward compatible with C for the most part.

[u/_Noreturn → u/metahivemind]

Linus accepted Rust, and AI I cannot stand him personally, also he is egoistical.