Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Obvious things C should do

digitalmars.com

Post reply on HN
Print view View original

171–180 of 310 posts

Re: Obvious things C should do

#171

Post by TheNewAndy »

kouteiheika wrote: post #138
TheNewAndy wrote: post #113

Earlier quoted context omitted.

This is probably something where it comes down to preference and familiarity. I would much prefer a simple text file for documentation that I can grep, open in my text editor, modify easily without switching context (oh, I should have been more explicit in the documentation I wrote - let me just fix that now), etc. All the features you mentioned "nice interface, fully searchable API interface, whole public API" are e…

> All the features you mentioned "nice interface, fully searchable API interface, whole public API" are exactly what you get if you open a well written header file in any old text editor. No, you can't, and it's not even close. You have a header file that's 2000 lines of code, and you have a function which uses type X. You want to see the definition of type X. How do you quickly jump to its definition with your "any…

Thanks for the constructive example of the rust doc.

I am not making things up when I say that the very first question I had about how to use this module, either is not answered, or I couldn't find the answer. That question was "what regular expression syntax is supported?". This is such a fundamental question, yet there is no answer provided.

As a preference thing, I don't really like examples in APIs (it is supposed to be a reference in my opinion) and I find them to be mostly noise.

> Why would I want to edit the documentation of an external library I'm consuming when I'm reading it? And even if I do then the effort to make a PR changing those docs pales in comparison to the effort it takes to open the original source code with the docs and edit it.

Right, this is possibly where our experiences differ. I'm frequently pulling in loads of code, some of which I've written, some of which other people have written, and when I pull in code to a project I take ownership of it. Doesn't matter who wrote it - if it is in my project, then I'm going to make sure it is up to the standards I expect. A lot of the time, the code is stuff I've written anyway, which means that when I come back in a few months time and go to use it, I find that things that seemed obvious at the time might not be so obvious, and a simple comment can completely fix it. Sometimes it is a comment and a code change ("wouldn't it be nice if this function handled edge case X nicely? I'll just go in there and fix it").

The distinction between external and internal that you have looks pretty different to me, and that could just be why we have different opinions.

Re: Obvious things C should do

#172

Post by Brian_K_White »

kouteiheika wrote: post #157
jmb99 wrote: post #140

Earlier quoted context omitted.

> The "what if you don't have the tool" situation never happens in case of Rust. So it’s built into GitLab and GitHub? BitBucket? How easy is it to use on windows (i.e. is it is easy as opening a .h in notepad and reading it)? How easy is it to use from a command line environment with vim or emacs bindings? I could go on. “Never” is doing a lot of heavy lifting in your assertion. I shouldn’t have to install a toolcha…

> So it’s built into GitLab and GitHub? BitBucket? No. It's built into the toolchain which every Rust developer has installed. > How easy is it to use on windows (i.e. is it is easy as opening a .h in notepad and reading it)? A easy as on Linux or macOS from my experience. > How easy is it to use from a command line environment with vim or emacs bindings? Not sure I understand the question; use how exactly? You eithe…

I don't understand how you don't understand the order of magnitude difference in flexibility, utility, availability, etc between needing to run a specific executable vs merely opening a text file in any way.

"you always have the exe" is just not even remotely a valid argument.

Re: Obvious things C should do

#174

Post by xigoi »

panic wrote: post #112
kouteiheika wrote: post #99

Earlier quoted context omitted.

> Header 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). I always found this argument baffling, because the way some other language solve this problem is with tooling, which is a much better way to do it in my opinion. Take Ru…

As someone who likes C header files, I enjoy manually maintaining them. Designing the interface separately from the implementation feels good to me, and a well-structured .h file is nicer to read than any auto-generated docs I've encountered.

The problem is that you have to write the interface not only separately grom the implementation, but together with the implementation as well, which leads to duplication of information;

Re: Obvious things C should do

#175

Post by chikere232 »

WalterBright wrote: post #111
ryukoposting wrote: post #84

Earlier quoted context omitted.

> D users have found it to be immensely useful anyway. I think you're focused on something that D programmers found helpful, rather than focusing squarely on the needs of C programmers. C and D are both good languages. Their use cases can overlap, but frequently don't. >=70% of the code I write for work is C, as I'm an embedded firmware dev. C meets the very particular needs of bare-metal development, a use case that…

> your own example of defining an enum value That is hardly the only place that has a constant-expression in the grammar. (BTW, D enums can also be floats, and even string literals!) You could use CTFE to initialize const floating point globals. static_assert also takes a constant-expression. > There's just a boatload of gotchas. The D community has 17 years experience with it. It remains an indispensable feature. As…

Not to take away from the possible usefulness of constant functions, but it's amusing that the article example of `sum(5,6)` would work great in C if written as 5 + 6, or done as the equivalent macro

Re: Obvious things C should do

#177

Post by hawski »

kouteiheika wrote: post #138
TheNewAndy wrote: post #113

Earlier quoted context omitted.

This is probably something where it comes down to preference and familiarity. I would much prefer a simple text file for documentation that I can grep, open in my text editor, modify easily without switching context (oh, I should have been more explicit in the documentation I wrote - let me just fix that now), etc. All the features you mentioned "nice interface, fully searchable API interface, whole public API" are e…

> All the features you mentioned "nice interface, fully searchable API interface, whole public API" are exactly what you get if you open a well written header file in any old text editor. No, you can't, and it's not even close. You have a header file that's 2000 lines of code, and you have a function which uses type X. You want to see the definition of type X. How do you quickly jump to its definition with your "any…

Depending on coding style you could just do something like this:

  ^struct whatever

Re: Obvious things C should do

#178

Post by reanimus »

TheNewAndy wrote: post #171
kouteiheika wrote: post #138

Earlier quoted context omitted.

> All the features you mentioned "nice interface, fully searchable API interface, whole public API" are exactly what you get if you open a well written header file in any old text editor. No, you can't, and it's not even close. You have a header file that's 2000 lines of code, and you have a function which uses type X. You want to see the definition of type X. How do you quickly jump to its definition with your "any…

Thanks for the constructive example of the rust doc. I am not making things up when I say that the very first question I had about how to use this module, either is not answered, or I couldn't find the answer. That question was "what regular expression syntax is supported?". This is such a fundamental question, yet there is no answer provided. As a preference thing, I don't really like examples in APIs (it is suppose…

> I am not making things up when I say that the very first question I had about how to use this module, either is not answered, or I couldn't find the answer. That question was "what regular expression syntax is supported?". This is such a fundamental question, yet there is no answer provided.

The main page for the documentation answers that question: https://docs.rs/regex/1.11.1/regex/index.html

It even says "If you just want API documentation, then skip to the Regex type", which is what you were linked to before.

Re: Obvious things C should do

#179

Post by tczMUFlmoNk »

omoikane wrote: post #110
kstenerud wrote: post #94

Compile time unit tests are as bad of an idea as "unused import/variable/result" errors (rather than warnings). They're "nanny features" that take control away from the developer and inevitably cause you to jump through bureaucratic hoops just to get your work done. These kinds of build-failing tests are great for your "I think I'm finished now" build, but not for your "I'm in the middle of something" builds (which a…

Maybe these compile time tests are more like `static_assert`, which is valuable for catching incompatible uses of library functions. Pretty good idea in my opinion.

The article is literally talking about `_Static_assert`, yes. It's used in the code examples and described in the text.

Re: Obvious things C should do

#180

Post by James_K »

I feel that much of the point of C is that it's easy to implement. Substantially increasing its scope doesn't seem like the best idea. Perhaps they could do something akin to Scheme and have a "small" and "large" version of the specification.
Post reply on HN