Random Acts of Senseless Violence - Jack Womack. See https://reactormag.com/randomacts/ for a great review by Jo Walton (also a great scifi author who deserves more attention).
Beat me to it: I was going to post a link to the 8-Bit Guy's video as well.
There are, I believe, various versions available and if you just want something to learn and write BASIC programs on it's difficult to imagine a better place to start because it boots directly into a BASIC prompt, just like 8-bit microcomputers from the 80s.
From that page, "use ++g instead of g++ (it’s faster)"
I've seen people say this a repeatedly when talking about "embedded" environments, but never understood why - won't it end up compiling to the same thing either way?
'a++' (postfix) and '++a' (prefix) have slightly different meanings in terms of return values. Postfix will return the value of 'a' before the increment, while prefix will return 'a' after the increment operation.
In a simple compiler, you would store the previous value of 'a' in the case of postfix in case you need to assign it. This results in a superfluous store instruction in most cases.
Of course, a smarter compiler could see the lack of assignment and throw away the store instruction during an optimization pass.
I’ve used crappy compilers where there’s essentially no optimisation, and moderately complex expressions produce absurd code, so if you want reasonable output, you end up writing the assembly you want in the notation of the higher-level language, like:
/* a = (b * 2) + 1 */
a = b; /* mov a, b */
a <<= 1; /* shl a, 1 */
a |= 1; /* or a, 1 */
In a moderately sophisticated compiler, yes they should be the same thing.
The difference in the two is that the latter has to produce the original value, presumably by keeping it in a temporary variable. A compiler which looks at all the code in a function when optimising, rather than just blindly emitting code for each individual operation, will see that the value is not needed, and delete the temporary.
I guess cc65 is a bit more basic. Compilers for more unusual embedded environments are often a bit more basic, hence the general advice for the embedded context.
I think you could probably fix the compiler for this trivial case in the time it takes you to write down the advice though.
I'd argue you regardless you should write what you mean
If you mean "increment g" then write "++g"
If you mean "temp = g; increment g; return g" then write "g++"
It doesn't really matter that the compiler may optimize out the "temp". If you're writing "g++" you're indicating you want the value before it's been incremented.
If you're not using the value you can't “want it”. There is only one sane way to interpret the following two expressions statements (in C), and it is that they are equal.
They said 'if you're not using the value', and you've presented an example where they are using the value, so you're criticism doesn't apply in the case they're talking about.
First of all, I don't agree that code like that is stupid regardless of circumstances. Any programmer worth his salt understands that condition perfectly well without having to think about it.
However, it's an altogether different situation to the one I wrote about, given that the value of the incrementing expression is specifically used in that case.
I think in C the temporary will be optimized away.
I keep meaning to test this in C++. I presume that it would for fundamental types, but wouldn't be able to be objects, because the side effects of that operation could be in another module. I use ++i for C++ iterators for that reason, and the habit tends to spill over to C.
I have a meta-proposal. Random westerners are a terrible source of ideas - you should talk to people from developing countries and if possible go there. The local knowledge will be 100x more useful than anything we can come up with.
Its would be kind of like rich politicians from privileged background deciding how the rest of the unwashed masses should live their lives. Oh, wait...
Slightly self-promotion, but you can get a variety of old perl sources at http://www.etla.org/retroperl/ (collected by someone non-me, I can't remember who though)
I had thought someone had done a perl 1 release that built on modern systems, but on a quick hunt I can't find it.
