|
|
|
|
|
|
by lmm
3684 days ago
|
|
|
> In my opinion this only shift the problem from coding clean code to handling hundreds or thousands of simple and small source files. This will make much more complicated to handle a large project because everything is scattered in such an extend that a developer spend more time searching thru the include list of files than understanding what the code is actually doing. I've worked on a number of very large codebases and that simply isn't my experience. If code is easy to understand it tends to make good use of the domain language and therefore also be easy to search. > Implementing complex functionality is going to be a nightmare The opposite, in my experience. The only maintainable way to implement complex functionality is to break it into small pieces. > everything is going to be merged in a single translation unit anyway. That's the compiler's business. I don't care one way or the other about its implementation details. |
|
|
Actually, you do- for at least several reasons.
1. If the runtime or compiler were to have problems with interdependencies.
2. If the compiled code that will actually be executed or the application or service itself across cores, processors, VMs, geography at runtime takes longer to run because of its compiler implementation, that might make it more expensive or too slow for your needs or to compete.
3. There may be a security flaw in the compiler, e.g. https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...
4. The compiler may have a bug or problem prohibiting you from finishing your code in a timely manner, e.g. https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Cross_002dCompi... or http://www.securitycurrent.com/en/writers/paul-robertson/mot...
5. The compiler may lack other required functionality or features.