This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Switching to C++ by default in 4.8

On Sat, Apr 14, 2012 at 5:08 PM, Robert Dewar <> wrote:
> On 4/13/2012 9:15 PM, Chiheng Xu wrote:
>> So, I can say, most of the GCC source code is in large files.
>> And this also hold for language front-ends.
> I see nothing inherently desirable about having all small files.
> For example, in GNAT, yes, some files are large, sem_ch3 (semantic
> analysis for chapter 3 stuff which includes all of type handling)
> is large (over 20,000 lines 750KB, but nothing would be gained
> (and something would be lost) by trying to split this file up.
> As long as all your tools can handle large files nicely, and
> as long as the internal organization of the large file is
> clean and clear, I see no problem.

Actually, I only partially agree with you on this. And I didn't say
smaller is necessarily better.
But normally, high cohesion and low coupling code tend not be large.
Normally large files tend to export only few highly related entry
points. Most of the functions in large file are sub-routines(directly
or indirectly) of the entry points. The functions can be divided into
several groups or layers, each group or layer can form a conceptual
sub-module. I often see GCC developer divide functions in large file
into sub-modules by prefix them with sub-module specific prefix and
group them together.  This is good,  but not enough. If the functions
in sub-modules are put in separate files,  then the code will be more
manageable than not doing so. This is because the
interfaces/boundaries between sub-modules are more clear, and the code
have higher cohesion and lower coupling.

Chiheng Xu

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]