Re: [dev] include files should never include include files?
Visual studio an gcc can precompile include files. Gcc use is common for c++ compilation, because c++ header parsing is much slower than C. I think you can get some nfo about this looking for gentoo kde ricers ;) On Jan 18, 2010, at 1:18 AM, Anders Andersson wrote: It's good to note that Apple has been putting lots of effort in to the llvm c compiler (clang) because it parsers header files much faster than gcc and the current way Apple does includes is to have one include file that includes everything else you'd ever need. Which is kind of insane. - jessta I don't know about that, my Amiga compiler (SAS/C) could "precompile" headerfiles, and they could be kept resident in RAM until next compile. Even when loading all includes from disk was slow, having one headerfile with all the includes would speed up things when this method was in use. Still. I've never seen the includefile parsing as a bottleneck, compared to actually optimizing the code. // pipe
Re: [dev] include files should never include include files?
> > It's good to note that Apple has been putting lots of effort in to the > llvm c compiler (clang) because it parsers header files much faster > than gcc and the current way Apple does includes is to have one > include file that includes everything else you'd ever need. > Which is kind of insane. > > - jessta I don't know about that, my Amiga compiler (SAS/C) could "precompile" headerfiles, and they could be kept resident in RAM until next compile. Even when loading all includes from disk was slow, having one headerfile with all the includes would speed up things when this method was in use. Still. I've never seen the includefile parsing as a bottleneck, compared to actually optimizing the code. // pipe
Re: [dev] include files should never include include files?
On Mon, Jan 18, 2010 at 02:10:55AM +1100, Jessta wrote: > It's good to note that Apple has been putting lots of effort in to the > llvm c compiler (clang) because it parsers header files much faster > than gcc and the current way Apple does includes is to have one > include file that includes everything else you'd ever need. > Which is kind of insane. > > - jessta > -- > = > http://jessta.id.au > "Carbon.h is a monster: it transitively includes 558 files, 12.3M of code, declares 1 functions, has 2000 struct definitions, 8000 fields, 2 enum constants, etc (see slide 25+ of the [1]clang talk for more information). It is also #include'd into almost every C file in a GUI app on the Mac, so its compile time is very important." Do not want. http://clang.llvm.org/clang_video-07-25-2007.html -- Government is the great fiction through which everybody endeavors to live at the expense of everybody else. pgpZduzERMMpq.pgp Description: PGP signature
Re: [dev] include files should never include include files?
2010/1/17 Anders Andersson : > You won't run in to any problems if you do it right, when you do as > you say. The time it takes to parse the header is probably negligible > compared to the rest of compilation in a modern compiler and a modern > system with disk cache etc. . It's good to note that Apple has been putting lots of effort in to the llvm c compiler (clang) because it parsers header files much faster than gcc and the current way Apple does includes is to have one include file that includes everything else you'd ever need. Which is kind of insane. - jessta -- = http://jessta.id.au
Re: [dev] include files should never include include files?
Odd - my gut reaction seeing the title made me suppose it was for /usability/ reasons. The technical reasons, make sense though. I worked for a company that generated a lot of header files in the course of work (think lots of different #define's for lots of different bit moving and whatnot for lots of different boards). We came up with this structure, basically: all.h parts.h parts/ parts/A.H parts/B.H parts/... other.h other/ all.h would include everything overall, and parts.h would include all of parts/*.h, in those rare times that you needed something like that; also, it was easy to automate generation of these files. 2¢, __armando On Sat, Jan 16, 2010 at 10:41 AM, Joseph Xu wrote: > A little off topic maybe, hope I'll be forgiven ... > > I'm reading Rob Pike's C programming style guide > (http://www.quut.com/c/pikestyle.html), and the last rule says: > > -- > > Simple rule: include files should never include include files. If > instead they state (in comments or implicitly) what files they need to > have included first, the problem of deciding which files to include is > pushed to the user (programmer) but in a way that's easy to handle and > that, by construction, avoids multiple inclusions. Multiple inclusions > are a bane of systems programming. It's not rare to have files included > five or more times to compile a single C source file. The Unix > /usr/include/sys stuff is terrible this way. > > There's a little dance involving #ifdef's that can prevent a file > being read twice, but it's usually done wrong in practice - the #ifdef's > are in the file itself, not the file that includes it. The result is > often thousands of needless lines of code passing through the lexical > analyzer, which is (in good compilers) the most expensive phase. > > Just follow the simple rule. > > -- > > This is a little surprising to me as I'm used to putting includes in > include files all the time. I do use #ifdef header guards, and I've > never really had any problems violating this rule. So my first question > is, has anybody actually ran into problems due to violating this rule? > And secondly, does this rule apply to C++? For example, if I'm defining > a class that std::vector members, I ordinarily add a #include in > the header. > > > Thanks for the advice. > > Joseph > >
Re: [dev] include files should never include include files?
On Sat, Jan 16, 2010 at 10:41:40AM -0500, Joseph Xu wrote: > So my first question is, has anybody actually ran into problems due > to violating this rule? Sometimes there is two headers that depend on some third. First header includes this third and the second header don't (you may forgot to do it cause all compiles anyway). When you include header 2 after header 1 everything is ok, but if you rearrange them code won't compile cause you forgot to include header 3 from header 2. When all includes are in C files it is easy to see if there is no double includes. Also if some #include is missed code won't compile. So you never have more or less #include's than needed.
Re: [dev] include files should never include include files?
> You might not be having problems but he's saying that all that code passing > through the lexical analyser will be slowing the compile down. If you put > the #ifdef in the top file doing the includes then include files will be > opened only the once and not many times. What I did on the Amiga was to add the #ifdefs in my sources as well as in the include files, which permits you to be lazy but enables you to "optimize" whenever I cared for it. Normally I prefer to go for code clarity, because all the #ifdefs in the source is just distracting. Basically, don't worry about it.
Re: [dev] include files should never include include files?
On 16/01/10 15:41, Joseph Xu wrote: This is a little surprising to me as I'm used to putting includes in include files all the time. I do use #ifdef header guards, and I've never really had any problems violating this rule. So my first question is, has anybody actually ran into problems due to violating this rule? And secondly, does this rule apply to C++? For example, if I'm defining a class that std::vector members, I ordinarily add a #include in the header. You might not be having problems but he's saying that all that code passing through the lexical analyser will be slowing the compile down. If you put the #ifdef in the top file doing the includes then include files will be opened only the once and not many times. Jon.
Re: [dev] include files should never include include files?
> Simple rule: include files should never include include files. If > instead they state (in comments or implicitly) what files they need to > have included first, the problem of deciding which files to include is > pushed to the user (programmer) but in a way that's easy to handle and > that, by construction, avoids multiple inclusions. Multiple inclusions > are a bane of systems programming. It's not rare to have files included > five or more times to compile a single C source file. The Unix > /usr/include/sys stuff is terrible this way. > > There's a little dance involving #ifdef's that can prevent a file > being read twice, but it's usually done wrong in practice - the #ifdef's > are in the file itself, not the file that includes it. The result is > often thousands of needless lines of code passing through the lexical > analyzer, which is (in good compilers) the most expensive phase. > > Just follow the simple rule. > > -- > > This is a little surprising to me as I'm used to putting includes in > include files all the time. I do use #ifdef header guards, and I've > never really had any problems violating this rule. So my first question > is, has anybody actually ran into problems due to violating this rule? > And secondly, does this rule apply to C++? For example, if I'm defining > a class that std::vector members, I ordinarily add a #include in > the header. You won't run in to any problems if you do it right, when you do as you say. The time it takes to parse the header is probably negligible compared to the rest of compilation in a modern compiler and a modern system with disk cache etc. At least I've never felt it to be a problem. Back on my Amiga, it could actually take some noticeable time, when the source was on floppies. // pipe
Re: [dev] include files should never include include files?
Of course you did not run into problems. You just wasted your precious processor time on including and parsing header files which you could have easily prevented by following that rule. You might however run into problems when breaking this rule and no #ifdef-guards are present. I'm not sure about C++, but I'd say the rule applys as well. You never compile a header on it's own so you should put all the includes into the C files from the beginning. Surma On Sat, Jan 16, 2010 at 4:41 PM, Joseph Xu wrote: > A little off topic maybe, hope I'll be forgiven ... > > I'm reading Rob Pike's C programming style guide > (http://www.quut.com/c/pikestyle.html), and the last rule says: > > -- > > Simple rule: include files should never include include files. If > instead they state (in comments or implicitly) what files they need to > have included first, the problem of deciding which files to include is > pushed to the user (programmer) but in a way that's easy to handle and > that, by construction, avoids multiple inclusions. Multiple inclusions > are a bane of systems programming. It's not rare to have files included > five or more times to compile a single C source file. The Unix > /usr/include/sys stuff is terrible this way. > > There's a little dance involving #ifdef's that can prevent a file > being read twice, but it's usually done wrong in practice - the #ifdef's > are in the file itself, not the file that includes it. The result is > often thousands of needless lines of code passing through the lexical > analyzer, which is (in good compilers) the most expensive phase. > > Just follow the simple rule. > > -- > > This is a little surprising to me as I'm used to putting includes in > include files all the time. I do use #ifdef header guards, and I've > never really had any problems violating this rule. So my first question > is, has anybody actually ran into problems due to violating this rule? > And secondly, does this rule apply to C++? For example, if I'm defining > a class that std::vector members, I ordinarily add a #include in > the header. > > > Thanks for the advice. > > Joseph > >
[dev] include files should never include include files?
A little off topic maybe, hope I'll be forgiven ... I'm reading Rob Pike's C programming style guide (http://www.quut.com/c/pikestyle.html), and the last rule says: -- Simple rule: include files should never include include files. If instead they state (in comments or implicitly) what files they need to have included first, the problem of deciding which files to include is pushed to the user (programmer) but in a way that's easy to handle and that, by construction, avoids multiple inclusions. Multiple inclusions are a bane of systems programming. It's not rare to have files included five or more times to compile a single C source file. The Unix /usr/include/sys stuff is terrible this way. There's a little dance involving #ifdef's that can prevent a file being read twice, but it's usually done wrong in practice - the #ifdef's are in the file itself, not the file that includes it. The result is often thousands of needless lines of code passing through the lexical analyzer, which is (in good compilers) the most expensive phase. Just follow the simple rule. -- This is a little surprising to me as I'm used to putting includes in include files all the time. I do use #ifdef header guards, and I've never really had any problems violating this rule. So my first question is, has anybody actually ran into problems due to violating this rule? And secondly, does this rule apply to C++? For example, if I'm defining a class that std::vector members, I ordinarily add a #include in the header. Thanks for the advice. Joseph
