Earlier quoted context omitted.
I have my own list of things that could "easily" be added to C, but I'd rather them not to be.
You get them anyway in the form of extensions.
Thanks, but no thanks.
Obvious things C should do
71–80 of 310 posts
Re: Obvious things C should do
#72Header files are one of the things I miss the most about languages that aren't C. Having a very clear distinction between public and private, and interface and implementation is one of my favourite things about C code (at least the way I write it).
Being able to just read through a library's .h files to know how to use it is really nice. Typically, my .h files don't really look like my .c files because all the documentation for how to use the thing lives in the .h file (and isn't duplicated in the .c file). It would be entirely possible to put this documentation into the .c file, but it makes reading the interface much less pleasant for someone using it.
Re: Obvious things C should do
#73Header files are one of the things I miss the most about languages that aren't C. Having a very clear distinction between public and private, and interface and implementation is one of my favourite things about C code (at least the way I write it). Being able to just read through a library's .h files to know how to use it is really nice. Typically, my .h files don't really look like my .c files because all the docume…
Some other languages have equivalents (OCaml comes to mind), but usually they’re less necessary
Re: Obvious things C should do
#74> the compiler only knows about what lexically precedes it. […] it drives programmers to lay out the declarations backwards. The leaf functions come first, and the global interface functions are last. It’s like reading a newspaper article from the bottom up. It makes no sense. Defining functions on a “bottom-up” order like this is common even in languages like Python which allow forward references. [0] Is that just a…
You're confused. There are no forward references in python. It's simply that identifiers in the body of a function aren't resolved until the function itself is executed (if ever) and at the point everything in the module scope has been defined. You can test this yourself by just putting any name into a body and loading the module.
> identifiers in the body of a function aren't resolved until the function itself is executed (if ever) and at the point everything in the module scope has been defined
Yes, so within a function you can refer to things that are defined later in the module. Isn't that's a "forward reference", even if the details are slightly different from how they work in D?
Re: Obvious things C should do
#75While the author has WAY more knowledge/experience than me on this and so I wonder how he would solve the following issues: Evaluating Constant Expressions - This seems really complicated...if you're working within a translation unit, thats much simplified, but then you're much more limited in what you can do without repeating a lot of code. I wonder how the author solves this. Compile Time Unit Tests - This is alrea…
Every other language does seems to not require header file/forward declarations. I don't understand the backlash against that. Are modern C compilers actually still single pass?
A bit of an aside but I was poking around in the SPIR-V spec yesterday and they can do forward references because the call site contains all the information to determine the function parameter types. Just thought it was interesting and not really something I had thought about before.
Re: Obvious things C should do
#76Earlier quoted context omitted.
As the article writes, that forces the private leaf functions to be at the top, with the public interface at the end of the file. The normal way is the public interface at the top, and the implementation "below the fold", so to speak. > topological order You are correct. But its the reverse topological order, which is not the most readable ordering. One doesn't read a newspaper article starting at the bottom.
Maybe it’s because I’m primarily a mathematician, but I like building complex stuff up from primitives and having the most important results at the end.
Perhaps the difference is having algorithm in your head and just putting it into code, versus only knowing the top level work to be done and implementing the needed operations later.
If I am writing some kind of service, I would write the main public functions first, using undefined functions in their bodies as needed. Then I would implement those functions below.
Re: Obvious things C should do
#77Earlier quoted context omitted.
You're confused. There are no forward references in python. It's simply that identifiers in the body of a function aren't resolved until the function itself is executed (if ever) and at the point everything in the module scope has been defined. You can test this yourself by just putting any name into a body and loading the module.
> identifiers in the body of a function aren't resolved until the function itself is executed (if ever) and at the point everything in the module scope has been defined Yes, so within a function you can refer to things that are defined later in the module. Isn't that's a "forward reference", even if the details are slightly different from how they work in D?
[flagged]
Re: Obvious things C should do
#78Earlier quoted context omitted.
If I'm not mistaken, the treatment of forward declarations proposed in the article actually breaks the C standard, which would be a rather pressing concern. As far as I am aware, that is the reason why things are the way they are right now in C land. (In the past, there were more legitimate concerns on the ease of implementation. Nowadays, as the article points out, they are pretty moot, other than having to keep bac…
How does it break the C Standard? > how to deal with functions that may not terminate or take rather long to execute Control-C, the same as when running any executable that shouldn't be taking that long. It doesn't solve the halting problem :-/
So a single typo DDoSes the entire Red Hat buildbot fleet?
Re: Obvious things C should do
#79I write unit tests for my C code all that time. It's not difficult if you use a good build system and if you are willing to stomach some boilerplate. Here is one test from my "test suite" for my npy library:
void
test_load_uint8() {
npy_arr *arr = npy_load("tests/npy/uint8.npy");
assert(arr->n_dims == 1);
assert(arr->dims[0] == 100);
assert(arr->type == 'u');
npy_free(arr);
}
int
main(int argc, char *argv[]) {
PRINT_RUN(test_load_uint8);
...
}
Re: Obvious things C should do
#80I'm not a c programmer, but having unit tests automatically run at compile time seems odd. If i wanted to run tests at the same time as compiling i would put that in the makefile.