corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: ODF Restructure
Date Mon, 08 Jun 2015 20:50:00 GMT
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.gibson@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" <jani@apache.org> wrote:
>
> On 8 June 2015 at 14:58, Peter Kelly <pmkelly@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
> > pmkelly@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 <ian@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>
> >
> >


Mime
View raw message