161–170 of 196 posts
Earlier quoted context omitted.
The naming of LIST_HEAD_INIT and INIT_LIST_HEAD is confusing to me.
Not to mention that they insist on calling every entry of the list a "list head", which makes no sense (hysterical raisins, maybe?). The structure is made of a uniform loop of entries, one of which is used as the actual head & tail, or entry point into the structure.
sounds like
"I build life-size houses out of toothpicks"
I can do that to, but I have no desire to. It's so much easier to just switch to Rust.
Earlier quoted context omitted.
Any established C codebase, for example the kernel or Postgres? Traditionally microcontroller firmwares as well, though those are increasingly friendly to C++, you just have to be careful about allocations as C++ makes it way easier to accidentally allocate than C does.
> Any established C codebase Anecdotally, GCC and GDB successfully (and incrementally) switched to C++ form C in the recent past. The Linux kernel will never do it for ideological reasons of course. I don't know about Postgres.
> Obviously you mean the Linux kernel, specifically.
Or any BSD, or Illumos, or Solaris, or any Unix-derived kernel, or... Even the Windows kernel is in C (or a very cut-down C++).
Earlier quoted context omitted.
Any established C codebase, for example the kernel or Postgres? Traditionally microcontroller firmwares as well, though those are increasingly friendly to C++, you just have to be careful about allocations as C++ makes it way easier to accidentally allocate than C does.
Nothing is stopping you from linking C++ code to Postgres.
Earlier quoted context omitted.
> referring to passed values as distinct from received values. That’s not the distinction being made by those terms. “Parameter” refers to a named variable in a function definition. “Argument” refers to an actual value that’s passed to a function when it’s called. It’s exactly the same as the distinction between variables and values (which you probably see the use for), just applied to the special cases of function s…
Well, I certainly would not interpret the terms that way, but you do you.
> "Parameters are named variables declared as part of a function. They are used to reference the arguments passed into the function."
-- MDN, https://developer.mozilla.org/en-US/docs/Glossary/Parameter
> "A parameter is a special kind of variable used in a function to refer to one of the pieces of data provided as input to the function. These pieces of data are the values of the arguments with which the function is going to be called/invoked."
-- Programming Fundamentals, https://press.rebus.community/programmingfundamentals/chapte...
> "Parameters refer to the variables listed in a function's declaration, defining the input that the function can accept. Arguments, however, are the actual values passed to the function when it is called, filling the parameters during execution."
-- https://www.geeksforgeeks.org/computer-science-fundamentals/...
While you might be tempted to "do you" and use your own idiosyncratic definitions, I advise against it, since it makes it difficult for you to understand what others are saying, and vice versa.
Earlier quoted context omitted.
> referring to passed values as distinct from received values. That’s not the distinction being made by those terms. “Parameter” refers to a named variable in a function definition. “Argument” refers to an actual value that’s passed to a function when it’s called. It’s exactly the same as the distinction between variables and values (which you probably see the use for), just applied to the special cases of function s…
Well, I certainly would not interpret the terms that way, but you do you.
Here's how to do it in D: struct ListNode(T) { ListNode* next; T data; } T!int node; Why suffer the C preprocessor? Using preprocessor macros is like using a hammer for finish carpentry, rather than a nail gun. A nail gun is 10x faster, drives the nail perfectly every time, and no half moon dents in your work.
So nail the architrave with the hammer until the nail is say 1/8" proud, then punch it home.
Earlier quoted context omitted.
This is incorrect. In a function definition, an empty list means it takes no parameters. 6.7.5.3 Function declarators > 14. An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters.
"has no parameters" is not the same as "cannot take arguments". Defining `int main()` does not stop the runtime from passing the usual 3 arguments (typically named argc, argv, envp), it only means that no parameters are bound to those arguments. Technically it's no problem to have a C function ignore its arguments by not binding parameters. Way too many programmers seem to not understand the difference between parame…
In C I guess that's true. In languages more concerned with compile-time rigor, it often isn't. Not a correction, just an observation.
I'm curious what a hashmap looks like with this approach. It's one thing to pass through or hold onto a generic value, but another to perform operations on it. Think computing the hash value or comparing equality of generic keys in a generic hashmap.
I first would question what a user wants to do with a hashmap that uses polymorphic key-values of unknowable type at compile-time. As a thought experiment, you could certainly have users define their own hash and equality functions and attach them to the table-entries themselves. On first thought, that sounds like it would be rife with memory safety issues. At the end of the day, it is all just bytes. You could simpl…
All of Apple's modern platforms use this concept pervasively, because the Objective-C Foundation framework has a common primitive data structure for it (NSDictionary).
Here's how to do it in D: struct ListNode(T) { ListNode* next; T data; } T!int node; Why suffer the C preprocessor? Using preprocessor macros is like using a hammer for finish carpentry, rather than a nail gun. A nail gun is 10x faster, drives the nail perfectly every time, and no half moon dents in your work.
Nah - one would simply use a punch with the hammer. So nail the architrave with the hammer until the nail is say 1/8" proud, then punch it home.