On Wed, Apr 21, 2021 at 2:22 PM Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > > > > On Wed, 21 Apr 2021, 20:11 Peng Yu, <pengyu.ut@xxxxxxxxx> wrote: >> >> >> >> Is this for windows? Do people use gcc for Windows? > > > > Yes. > >> >> > and 1) it is >> > too error-prone especially on arguments that contain spaces, and 2) it is >> > undesirable to have to >> > place more incompatibility and limitation (e.g. number of bytes in a single command line) just >> > because of the shell being used, but not of GCC itself, and 3) it is indeed very slow if `fork()` is >> >> That is the misconcept I mentioned before. To improve the speeds shell >> scripts should be sourced (then call functions defined in it, which >> can be used many times without much overhead) instead of used as a >> standalone program. The speedup can be 10~100 x depending on the >> situation. > > > So you're suggesting that GCC should replace the gcc and g++ drivers with shell scripts that should be sourced using . rather than executed? I'm not sure how that works be an improvement. I am not suggesting ido the replacement now. I am just saying if I were doing it from scratch, I'd not do everything in C. There is definitely part of the code more suitable in the shell than in C. If the shell code is properly written, it is can save a lot of time than writing C code. But since there is already C code written, it would costly to replace them with shell code. But for learning purposes, shell should be a better choice for learning at least part of what the gcc wrapper covers. > It would probably be possible, but it would not be practical (as mentioned, not all systems that GCC runs on have a good shell). The GCC drivers do a lot more than just launch other processes, so "shell scripts are good for launching other processes" isn't a good enough reason to do it. Also "shell scripts are easier to maintain" is subjective, This is a general conclusion from the first principle. As long as the purpose is to glue things, shell should be by definition better (given the misconceptions that need to avoided when using shell). Also, if bash is used and if you really want to have C-like performance for some time-costly parts, bash builtins can be made, as bash builtins are just shared libraries which are C-like fast by definition. However, if there is anything binary in nature is better to hide them from bash, as bash natively is not good at dealing with binary data. > and unless you've actually worked with the gcc code you are probably not going to convince anybody it would be an improvement. "I haven't looked at this code but it would be better if you completely rewrote it" is not a very persuasive argument. That is not what I am trying to persuade. I am just raising the possibility. I am well aware of any costs of switching the code. -- Regards, Peng
