I think one difference is whether or not the file has to be opened repeatedly, only to discover that it does not need to be processed.
My impression is that some compilers avoid accessing the file repeatedly either because they recognize the physical file location as guarded when doing a search or they might even know a search for the file would find one that has been guarded already. The #pragma once is probably a better way to assure that this works, although the Visual Studio 15 optimizations apparently treat #pragma once and the usual guard mechanism similarly. I think I am over-simplifying the situation, though. Once thing that #pragma once avoids is situations where there is a collision on use of a #define value. - Dennis -----Original Message----- From: Gabriela Gibson [mailto:gabriela.gib...@gmail.com] Sent: Monday, June 8, 2015 11:40 To: dev@corinthia.incubator.apache.org Subject: Re: ODF Restructure I have some q's about the pragma/include stuff. I've been reading http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Header_Files (And as a styleguide in general, wdyt?) And there is something fundamental I don't understand. Since the compiler actually only needs to be informed once about the contents in a header (I am assuming that I understood correctly that it gets simply pasted into the code and is probably stored in a db kind of structure) I am confused as to: 1) why not give the compiler a list of headers at the start. 2) I notice that files I know it already has seen must be included again and again for certain .c files to compile. 3) I also know it's good practice to use a guard like ifndef or pragma once. 4) the is nothing other than placement in a header that makes a declaration local (as in, not known until it has been seen in the total sequence of inclusion) and no way of telling the compiler to forget something. I am assuming that any .c file is akin to { local_scope = ... } so in C that is the only way of making something private. And I think special case of "forward declaration" when I see "extern". So clearly the compiler can work with unknown knowns too. So I'm wondering about all this difficulty and specifically why the guard is needed since the compiler surely could manage a list of which files were seen so far instead of depending on humans here. G On 8 Jun 2015 15:55, "jan i" <j...@apache.org> wrote: > > On 8 June 2015 at 14:58, Peter Kelly <pmke...@apache.org> wrote: > > > On ODFGet vs. ODFTextGet - I would suggest we stick with the latter, as if > > & when we add support for spreadsheets and presentations, we’ll need > > additional, separate methods for those. That is, ODFPresentationGet and > > ODFSheetGet. The same is true of ODFTextConverter - I expect we’d have > > ODFPresentationConverter and ODFSheetConverter as well. > > > > The Word converter is structured the way it is because at the time I wrote > > the code, I was interested only in word processing documents. It was only > > when I brought the code to Apache that it was suggested that Corinthia > > become something that supports presentations and spreadsheets as well. In a > > practical sense, we don’t address either of these at all, and whether > > either of these gets implemented will depend on interest & available > > man/woman-power. But I think it would be good to keep this possibility open > > - in that sense ODFGet by itself doesn’t make sense sense it’s not clear > > what type of document is being dealt with. This is also why the Word > > converter is called as what it is, rather than OOXML (though since coming > > into Apache the directory structure has been put in place to cater for the > > future implementation of OOXML spreadsheets and presentations). > > > I agree with peter lets keep the future open. > > > > > Also one minor comment on coding style - all the existing code uses an > > indentation of 4 spaces, no tabs, and { placed on the same line for > > if/while/switch statements, and on the following line for function > > definitions. I’m not inherently tied to one layout or another, but I think > > we should try to remain consistent with the style already in place. > > > I too do not really mind what we use, but it must be used consistent in the > source, otherwise it becomes a pain to maintain. > > rgds > jan i. > > > > > — > > Dr Peter M. Kelly > > pmke...@apache.org > > > > PGP key: http://www.kellypmk.net/pgp-key < http://www.kellypmk.net/pgp-key> > > (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) > > > > > On 7 Jun 2015, at 7:23 pm, Ian C <i...@amham.net> wrote: > > > > > > Hi Gabriela, > > > > > > attached is a patch that reorganises the ODF world to be more like the > > way Word documents are processed. > > > > > > I changed to the top level from operations to use an ODFGet. Which in > > turn uses an ODFConverter. The heart of the ODFGet function is > > > > > > ODFConverter *converter = > > ODFConverterNew(html,abstractStorage,package,idPrefix); > > > > > > //Get the styles data > > > //CSSSheetRelease(converter->styleSheet); > > > converter->styleSheet = ODFParseStyles(converter); > > > > > > //Convert the content.xml to an html beastie > > > ODFTextGet(converter); > > > > > > char *cssText = CSSSheetCopyCSSText(converter->styleSheet); > > > HTMLAddInternalStyleSheet(converter->html, cssText); > > > HTML_safeIndent(converter->html->docNode,0); > > > > > > Which parses for styles as I did before ( so still needs some work). > > > Then calls an edited ODFTextGet - which is much as it was. > > > > > > The code has just been twisted around to match the structure of the word > > world. > > > > > > Which means I can't help thinking that we could/should abstract out the > > common aspects of converters. > > > > > > It converts the headers.odt document to an html which shows the headers > > ok. > > > I also attached my version of headers.odt since I changed some of the > > styles to try and emphasize their differences. > > > > > > I hope it makes sense to you and that your patch tool can digest it. > > > > > > -- > > > Cheers, > > > > > > Ian C > > > <odfpatch.txt><headers.odt> > > > >
