In article <3c55c4e9@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Do you mean that povray reads the #included file even though it's inside
> an #if block which is just being skipped?-o

How could it know that the #if block ends at the end of the file without
looking through the whole file?

Or is there a user-mind-reading interface I missed?  If so, I didn't
implement it! ;-)


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: How could it know that the #if block ends at the end of the file without
: looking through the whole file?

  I think that it would be fair to _assume_ that block starts and ends are
always located in the same file. This probably will not break any logical
SDL script and is a very rational standard limitation to make.
  The big advantage of this is, of course, speed. If we are skipping a block
of code, we don't need to read any possible #includes in this block because
the specs say that there can't be anything interesting in the include anyways.

  I don't see any advantage of supporting the feature that, for example,
an #if starts in one file and the correspondent #end is in another file
(of course you could invent lots of artificial examples, but I don't think
there is any real useful example).

  The C preprocessor makes this assumption and it works just fine.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3c55b94d@news.povray.org: 

> In article <3c55a741@news.povray.org> , Warp <war### [at] tagpovrayorg> 
> wrote: 
> 
>> : It actually would increase parse time.
>>
>>   Then use a trick sometimes used in C/C++. Instead of:
> 
> Which is exactly what increases parse time!  The POV-Ray parser still
> turns everything into tokens, only to ignore it - keep in mind the
> parser and what looks like a preprocessor is actually more or less
> *one* step, so it isn't very fast.

The parser would probably do something a little more intellegent if the 
standard include files were not included directly but by wrappers, e.g. 
rename colors.inc to something else and create a new colors.inc with the 
following code:

#ifndef(Colors_Inc_Temp)
    	#declare Colors_Inc_Temp = version;
    	#version 3.5;
   	#include "realColors.inc"
    	#version Colors_Inc_Temp;
#else

I doubt it's worth the effort to do this, however...

Post a reply to this message

In article <3c55d9f1@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> Thorsten Froehlich <tho### [at] trfde> wrote:
> : How could it know that the #if block ends at the end of the file without
> : looking through the whole file?
> 
>   I think that it would be fair to _assume_ that block starts and ends are
> always located in the same file. This probably will not break any logical
> SDL script and is a very rational standard limitation to make.

As far as I know, the POV SDL *does* make this assumption. You missed 
his point...there is no way of knowing the end of the block is at the 
end of the file. It has to search to find the matching #end, and it has 
to do this starting forward from the #if statement. You can't even 
search backwards from the end of the file, you will mess up if you have 
multiple #if statements in series, and you can't just stop at the first 
#end, or you mess up nested statements.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
: As far as I know, the POV SDL *does* make this assumption. You missed 
: his point...there is no way of knowing the end of the block is at the 
: end of the file. It has to search to find the matching #end, and it has 
: to do this starting forward from the #if statement.

  Sorry, but I don't understand. What's the problem with this?
  Of course it searches for the #end correspondent to the #if. So? If, when
it encounters the #include command, it does not actually include the given
file, I don't see any problem here. The behaviour is exactly what I meant.

  Perhaps my point was not clear. Let me profundize:

  The usual way of "speeding up" parsing and avoiding multiple declaration
of things is to put lines like these in the include file:

// Beginning of the file
#ifndef _INCLUDE_FILE_1_
#declare _INCLUDE_FILE_1_ = yes;

(contents of the include file)

#end
// End of the include file

  Suppose that was "IncFile1.inc".
  Also suppose that we have another include file named "IncFile2.inc" which
needs the above one and thus includes it.
  Now, if "IncFile2.inc" does this in the usual way, ie:

#include "IncFile1.inc"

and "IncFile1.inc" was already read somewhere earlier, then this is slow, as
povray has to parse the entire "IncFile1.inc" file.
  However, what we do in "IncFile2.inc" instead, is this:

#ifndef _INCLUDE_FILE_1_
  #include "IncFile1.inc"
#end

  If "IncFile1.inc" has already been included somewhere earlier and povray
just skips that #include command and doesn't actually read the contents
of "IncFile1.inc", then it's much faster.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Sorry, I thought you were talking about what it does now. It doesn't 
process the #includes any more than it has to in order to figure out it 
isn't an #end. Modifying the actual #include statements would be 
possible, of course, just messier looking.

I personally don't think the parse time is that much of a problem...my 
scenes all spend more time in loops and macros than in parsing includes.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3c560a2b@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>
> #ifndef _INCLUDE_FILE_1_
>   #include "IncFile1.inc"
> #end

But this isn't how you do it in C/C++ header files...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

>   I think that it would be fair to _assume_ that block starts and ends are
> always located in the same file. This probably will not break any logical
> SDL script and is a very rational standard limitation to make.
>   The big advantage of this is, of course, speed. If we are skipping a
block
> of code, we don't need to read any possible #includes in this block
because
> the specs say that there can't be anything interesting in the include
anyways.
>
>   I don't see any advantage of supporting the feature that, for example,
> an #if starts in one file and the correspondent #end is in another file
> (of course you could invent lots of artificial examples, but I don't think
> there is any real useful example).

I have written such a script and it's very useful! It's not #if and #end,
but { and }. I think it's not a big difference.


#include "part1.inc"   //Camera, lights etc. and...
//an union is started!

---Write your object---

#include "part2.inc"   //The union is modified and ended

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
:> #ifndef _INCLUDE_FILE_1_
:>   #include "IncFile1.inc"
:> #end

: But this isn't how you do it in C/C++ header files...

  I know, but it's a (less) known way of speeding up parsing in C/C++.
  It's not something significant in small and mid-sized projects, but I have
heard stories about *HUGE* projects, which take several days to just compile,
where using this trick speeded up the parsing greatly.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message