TheNewAndy

If you wanted portability you would use either long or int_least32_t for your example. On a platform that doesn't have a 32-bit type (E.g. a 24-bit DSP) the C99 standard doesn't require that int32_t exists.

I don't see the problem if you end up with a type that is larger than what you asked for, because (assuming signed arithmetic) it was undefined to overflow anyway.

One obvious benefit for a header only library is that it suppresses the warning you get when a static function isn't used.

Not really a shell one liner, but ctrl+r (a readline command to do an incremental search backwards through history) is something that has been present on every shell I've used for decades without realising it, One day I decided to take the time to read all the magic readline commands because I wanted a way to quickly edit the N-th argument of a command with lots of arguments, and there were way too many of them. There were so many commands that I had no hope of remembering them all, but I figured I could just remember a few useful ones - and ctrl+r was one of them (ctrl+w and alt+b were the other two)

More to the letter of the question, I use "cd -" frequently, "ps -e | grep some_process_i_would_like_the_pid_for", and while I don't use it frequently, I didn't know about "ssh-copy-id" for a long time, and would do it manually with a text editor in the past. Sorry if they are not sufficiently fancy - but for things to get used day to day for me, they will need to be short and sweet.

Perhaps I am wrong, but the videos on this channel seem to have scripts that seem like they are very much AI written.

I watched this video a week or so ago, and a few more on the channel because they were promising to answer other interesting questions (interesting for me at least).

However, it seemed like there was something off with all the content. The best explanation I have for it is that it is AI generated scripts (I recall a real lack of coherence in the video about which side you put the fuel door on a car), so I just stopped watching.

I'd be curious if anyone else has a similar feeling or a better way of expressing it, because I am not feeling very eloquent here.

The game was 2d, and I just used the stuff in SDL_render.h for doing the graphics.

SDL2 has input stuff built in, so that is easy.

I didn't need networking for my game, so I didn't have it, but networking is not particularly difficult to do cross platform (I'm assuming iOS lets you just use the "normal" sockets API?)

I also used SDL2 for the sound stuff, which was mostly playing back prerecorded things, but also a little bit of stuff synthesized on the fly.

If you just want to write C and are ok linking to stuff that is in other languages, then I used SDL2 for my game which I wrote in C and is on the app store. It was a very pleasant experience, and if I were doing an iOS thing again, I would likely do something similar.

I think I had one objective C file in there for calling a library function I needed, but otherwise I just wrote C code.

If you believed the pointers didn't alias and they actually did then you replaced slow incorrect code with fast incorrect code

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.

"Never" is a big call.

In this specific case, your tool requires a web browser (though I'm assuming that there is a non-web browser form of what is being sold here). Maybe you are in a situation where you only have terminal access to the machine.

Maybe you are on your phone just browsing github looking for a library to use

I'm sure people can continue to imagine more examples. It is entirely possible that we have different experiences of projects and teams.

That's an interesting assertion, but not one that matches the experience I've had.

It is one of those things that sounds "obviously true", but in practice I've found that it doesn't really live up to the promise. As a concrete example of this, having a plain text header file as documentation tends to mean that when people are reading it, if they spot a mistake or see that something isn't documented that should be documented, they are much more likely to fix it than if the documentation is displayed in a "prettier" form like HTML.

The problem with header files that aren't "well-written" tends to be that the actual content you are looking for isn't in there, and no amount of language tooling can actually fix that (and can be an impediment towards fixing it).

Personally, I'm happy to just let a Sufficiently Advanced Compiler do link time optimizations to deal with that level of optimization and either take the hit, or make more things public while that compiler doesn't exist.

Let the header files be written for people to read first, and only if there is actually a big performance issue, and the problem is the interface do you need to revisit it (and I'm not just saying this - I will frequently and happily go back and modify interfaces to allow for less data movement etc, but most of the time it really isn't important).

I think you are probably right to disagree with me though - I think I should have said that it is more of a limitation on how object files work, rather than how machines work. Object files aren't the only way things can work.

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 exactly what you get if you open a well written header file in any old text editor.

I used to be a big fan of doxygen etc, but for the stuff I've worked on, I've found that "pretty" documentation is way less important than "useful" documentation, and that the reformatting done by these tools tends to lead towards worse documentation with the people I have worked with ("Oh, I need to make sure every function argument has documentation, so I will just reword the name of the argument"). Since moving away from doxygen I have stopped seeing this behaviour from people - I haven't tried to get a really good explanation as to why, but the quality of documentation has definitely improved, and my (unproven) theory is that keeping the presentation as plain as possible means that the focus turns to the content.

I don't know if rust doc suffers the same issues, but the tooling you are mentioning just seems to add an extra step (depending on how you count steps I suppose, you could perhaps say it is the same number of steps...) and provide no obvious benefit to me (and it does provide the obvious downside that it is harder to edit documentation when you are reading it in the form you are suggesting).

But with all these things, different projects and teams and problem domains will probably tend towards having things that work better or worse.

Right, but as soon as you have private stuff in your header file, that is leaking implementation details. Yes it is kind of true that these are compile time checked to make sure that people don't do the wrong thing, but it is still an implementation detail that is leaking.

It comes down to a cost benefit thing - is the cost of poorer readability worth it for mitigating the risk of people doing the wrong thing? My experience says no, other people's experience says yes. Probably we are working on different problems and with different teams.

You will be pleased to know that you are not the only one who does this.

I previously went down the rabbit hole of fancy unit test frameworks, and after a while I realised that they didn't really win much and settled on something almost identical to what you have (my PRINT_RUN macro has a different name, and requires the () to be passed in - and I only ever write it if the time to run all the tests is more than a second or so, just to make it really convenient to point the finger of blame).

The thing that I do which are potentially looked upon poorly by other people are:

1) I will happily #include a .c file that is being unit tested so I can call static functions in it (I will only #include a single .c file)

2) I do a tiny preprocessor dance before I #include <assert.h> to make sure NDEBUG is not defined (in case someone builds in a "release mode" which disables asserts)