4 ms·
Tangent: this sort of thing can be implemented without any change to libc++ (the runtime). Updates to compiler versions are sometimes postponed by users with b
by mkoubaa 2y ago
Tangent: this sort of thing can be implemented without any change to libc++ (the runtime). Updates to compiler versions are sometimes postponed by users with big codebases that treat a libc++ change as something major.
Why don't we see gcc or clang or msvc back porting stuff like this to an older version with a sort of future tag. It's normal to see __future__ in the python ecosystem, for instance.
- tart-lemonade 2y agoIf a codebase is fragile enough that libc++ changes have to be assumed breaking until proven otherwise, why take the risk? Presumably the application already has a "standard" way of formatting strings. If it ain't broke yada yada
- mkoubaa 2y agoIt's not about assumed breaking, it's that when you upgrade libc++ you can become incompatible at runtime with your distro or any other number of libraries outside your control in ways that are difficult to detect
- pjmlp 2y agoBecause C++, just like C, Ada, Cobol, Fortran, Modula-2, Pascal is an ISO driven language. Whereas Python language evolution is driven by whatever CPython reference implementation does. Compilers are free to do whatever they want, but then that code isn't portable.
- mkoubaa 2y agoThis is also true about #pragma once But it became a de facto standard at some point. thank you for the clarification. You are 100% right about the general difference. I didn't consider the level of "confidence" python has in directing it's own evolution that I don't detect in the C++ committee
- pklausler 2y ago> Compilers are free to do whatever they want, but then that code isn't portable. At a practical level, this is no different from Fortran, “ISO driven” or not.