News for hackers. Stuff that matters.
Re:Looking at Assembly Code with GDB by Akronymus on Wednesday June 29, 2022 @04:51AM (#31917817)
> Keeping everything the same, if you can rewrite your code so that it generates fewer instructions, it should be faster.

Not necessarily. Sometimes those additional instructions allow you to vectorize loops through eliminating the need for one loop iteration to depend on the previous one. For example: https://stackoverflow.com/questions/72306573/why-does-this-c...

Re:Looking at Assembly Code with GDB by khoobid_shoma on Tuesday June 28, 2022 @08:49PM (#31915132)
> "Let us consider the following C++ code:"

But, C code is shown. I do not get why people tend to avoid using C name.

Re:Looking at Assembly Code with GDB by shric on Tuesday June 28, 2022 @10:41PM (#31915857)
If it's compiled with a C++ compiler as C++ then it's C++ code. In this example the meaning is the same but some "C code" will produce different results depending on whether you compile it as C or C++.
Re:Looking at Assembly Code with GDB by anitil on Tuesday June 28, 2022 @09:25PM (#31915382)
It's compiled with a C++ compiler ('_Z2f2i' in the disassembly) and the function name is 'f.cpp', so I suppose it's in the 'C is a subset of C++' part of C.
Re:Looking at Assembly Code with GDB by khoobid_shoma on Wednesday June 29, 2022 @07:32PM (#31927036)
Still that's C code. Code is an input to the compiler. So, I would not call the code differently just because later a C++ comiler is used. In C++ code, we expect C++ specific features be used.