Why do you say that? Certain things in a language may increase binary size or something else but at the end of the day these languages all go through most likely the same compiler and should produce a roughly equivalent binary.
They will produce equivalent binaries, but not identical binaries.
For example, GCC's C++ front end will produce a different parse tree for the same C code as the C front end, resulting in a slightly different collection of basic blocks and data flow analysis (obviously, for very trivial examples, it will be identical). The result after all the gimplification and and different middle-end passes and rtl transformations you can end up with a surprisingly different set of generated instructions for the same code fed to gcc and g++. Equivalent, but different.
Nitpick: gcc and g++ are not different frontends but different compiler drivers. They can both invoke the C and C++ frontends (cc1 and cc1plus) and select them based on the file extension unless specified using the -x option. The difference between gcc and g++ is mainly in which libraries are linked by default.
Well, it's true that the different compilers are cc1 and cc1plus, but given most programmers I've run into here in vacuumland have trouble distinguishing between their IDE and their toolchain, expecting them to understand the difference between the actual compiler invoked by the driver depending on a file extension or '-x' switch vs. the different compiler driver that invokes that compiler by default for a given file extension is a bit of a stretch. Even you seem to be confused by the compiler proper (cc1 or cc1plus) and the front end (the part of each compiler that parses the code and builds an internal representation that then gets passed on to the middle end for optimization and the back end for register allocation and instruction generation).
The fact is, the front ends of cc1 and cc1plus will interpret the exact same C code differently to the extent that code containing undefined behaviour will have remarkably different results in the generated instructions. The differences between the cc1 and the cc1plus compilers are not limited to what the compiler driver passes to the linker, they have completely different front ends and only share the middle and back ends.
> Even you seem to be confused by the compiler proper (cc1 or cc1plus) and the front end (the part of each compiler that parses the code and builds an internal representation that then gets passed on to the middle end for optimization and the back end for register allocation and instruction generation).
Sure, the cc1 and cc1plus binaries come with a middle and backend linked in, but what differentiates them is the front end. Not so much for gcc and g++ where both `gcc file.cpp` and `g++ file.cpp` will invoke cc1plus. Not to mention that with LTO cc1 and cc1plus do almost exclusively front end work while everything else happens in lto1 (for both C and C++).
> these languages all go through most likely the same compiler and should produce a roughly equivalent binary
That's not really true. A single compiler may support many languages but that does not mean code written in those languages ends up as the same binary.
My challenge to you is to try to disconnect from HN as much as possible. I logged off for six months last January to detox from the neurotic comments that this place gets and it totally reset my mind. I plan on logging off for another long period of time after I check tomorrow on some Ask HNs I posted.
So it seems that you are sort of talking about a function that is memoizable but not pure. Pure has no mutation of any global state. So hypothetically touching the heap means not pure - if somehow others can see it.
So where do we draw the line? Of course, no real computer implementation of any language is going to be able to generate fundamentally pure code because in the end they're going to be mutating memory (at the very least the program counter).
That's not a very useful distinction, and usually one talks about "purity" at a conceptual level. The language provides a layer of abstraction in which things can be considered pure (or not), even if the underlying implementation e.g. makes optimizations that require mutation. The language is just a guarantee that you can ignore these aspects of its implementation.
I think that is a good point at the end. Pure may be defined in regards to the language. So allocating memory in C may make a function unpure but something other languages may still be pure.
Rolling it over I think vaguely along the idea that marking a function as pure is a contract that tells the compiler that the function and it's call tree ultimately shouldn't modify external state.
A function that allocates memory isn't pure, except perhaps iff it frees that memory either itself or by compiler magic. Then perhaps it is.
