The following code generates this error:

Write(FileHandle <----ERROR
Parse Error: Expected 2 parameters but only 0 found.

#macro Write (File, Doodle)
  #write (File, Doodle)
#end

#fopen FileHandle "c:\\1.txt" write
Write(FileHandle,1)
#fclose FileHandle

While the following code generates this error:

Write(1, FileHandle <----ERROR
Parse Error: Expected 2 parameters but only 1 found.

#macro Write (Doodle, File)
  #write (File, Doodle)
#end

#fopen FileHandle "c:\\1.txt" write
Write(1, FileHandle)
#fclose FileHandle

My question is: can I pass file handles as parameters to macros, and
if yes, how?


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Peter Popov wrote:
> 
> [...]
> 
> #fopen FileHandle "c:\\1.txt" write
> Write(1, FileHandle)
> #fclose FileHandle
> 
> My question is: can I pass file handles as parameters to macros, and
> if yes, how?
> 

I recently experienced the same problem and i think you can't.  File
handles are different from other identifiers. 

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Tue, 22 Apr 2003 10:55:51 +0200, Christoph Hormann
<chr### [at] gmxde> wrote:

>I recently experienced the same problem and i think you can't.  File
>handles are different from other identifiers. 

Then why can I #undef, #ifdef and #ifndef them? I mean, sure they are
not normal identifiers, you can't assign to them etc. but the fact
that you can't pass them to macros looks to me like an overlooking and
not a design feature.

The docs don't mention it anywhere. What they say is that a macro
parameter is either an RVALUE or an identifier. However, a file handle
*is* in a way an identifier as it a) uniquely identifies a file and b)
you can #ifdef, #ifndef and #undef it. So why the limitation?


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Tue, 22 Apr 2003 12:48:14 +0300, Peter Popov <pet### [at] vipbg> wrote:
> So why the limitation?

I have no idea but I imagine you can workaround it with passing it as string and
Parse_String() macro.

ABX

Post a reply to this message

Peter Popov wrote:
> 
> Then why can I #undef, #ifdef and #ifndef them? I mean, sure they are
> not normal identifiers, you can't assign to them etc. but the fact
> that you can't pass them to macros looks to me like an overlooking and
> not a design feature.

Dunno about #undef but the defined(FileHandle) function checks if the file
has reached the end while reading.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Tue, 22 Apr 2003 11:53:36 +0200, ABX <abx### [at] abxartpl> wrote:

>I have no idea but I imagine you can workaround it with passing it as string and
>Parse_String() macro.

In this case the file handle should be global, which doesn't help
much.

I am rendering an animation. I read the data from a file, calculate an
iteration and write it back to the file. If the file is globally open
(the file handle is globally defined), it can only be open for reading
*or* writing/appending, which doesn't solve my case. The whole thing
is macro-based so the scene is just along the lines of

#include ...
#declare Object=Macro(Parameters)
camera... lights...

As you see, there's no way with this setup (and I *do* want it to be
like that because it's an include I'd like to release) that I can have
the file handle be global.

I consider this a genuine bug, not exactly along the lines of "it's
not working properly" but more like "there's an artificial limitation
which looks like it shouldn't be there".


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

In article <1ev9avov9b6hkd269fm74okpsdfq31kpg1@4ax.com> , Peter Popov 
<pet### [at] vipbg>  wrote:

> My question is: can I pass file handles as parameters to macros, and
> if yes, how?

No, because you cannot make copies of file handles for obvious reasons.

    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

On Tue, 22 Apr 2003 13:16:31 +0200, "Thorsten Froehlich"
<tho### [at] trfde> wrote:

>No, because you cannot make copies of file handles for obvious reasons.

But you can make references to them, right?


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Tue, 22 Apr 2003 13:16:16 +0300, Peter Popov <pet### [at] vipbg> wrote:
> > I have no idea but I imagine you can workaround it with passing it as string and
> > Parse_String() macro.
>
> In this case the file handle should be global, which doesn't help
> much.

You mean this working workaround does not help you ?

  #include "strings.inc"

  #macro Write(File_Handle)
    #write( Parse_String(File_Handle) , "test")
  #end

  #fopen ID1 "test1.txt" write
    Write("ID1")
  #fclose ID1
  #fopen ID2 "test2.txt" write
    Write("ID2")
  #fclose ID2

ABX

Post a reply to this message

On Tue, 22 Apr 2003 13:37:15 +0200, ABX <abx### [at] abxartpl> wrote:

>You mean this working workaround does not help you ?

I have to see. In your case it works. In my case, the file handle is
created within a macro which in turn has to pass it to other macros,
so I have to check the scope with which it is created.

In the meanwhile, I am already rendering with the ugliest workaround
possible -- I played parser and pasted the macro code with the
necessary parameters substituted, heh :)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

In article <3ea5248e$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> > My question is: can I pass file handles as parameters to macros, and
> > if yes, how?
> 
> No, because you cannot make copies of file handles for obvious reasons.

Yes, but macro parameters otherwise appear to be handled as references. 
There shouldn't be any copying necessary, and this would be a very 
useful feature.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

> Yes, but macro parameters otherwise appear to be handled as references.
> There shouldn't be any copying necessary, and this would be a very
> useful feature.

No, parameters can be passed by value or reference, which is for regular
variables determined automatically.  But it cannot be done for file handles
because that would require to support for either copying file handles or
supporting counted references to file handles.

    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:
> supporting counted references to file handles.

  This shouldn't be difficult. At least not in C++.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

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

>> supporting counted references to file handles.
>
>   This shouldn't be difficult. At least not in C++.

Of course, but I don't what to get a load of STL into 3.5. The tiny little
<algorithm> already caused some problems because there are enough completely
outdated compiler installs out there that still use ancient broken pre-ARM
C++ compilers and libraries :-(

    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

In article <3ea7bfb5$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> Of course, but I don't what to get a load of STL into 3.5. The tiny little
> <algorithm> already caused some problems because there are enough completely
> outdated compiler installs out there that still use ancient broken pre-ARM
> C++ compilers and libraries :-(

What do you need the STL for? Reference counting is trivial to 
implement. I'm not sure what use it would be for this though...if a file 
is closed inside a macro, it will still be invalid, even if there are 
still references to it. And how could it be destroyed while in use by a 
macro?

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

> What do you need the STL for? Reference counting is trivial to
> implement.

Yes, reinvent the wheel.  And then try to add it in a clean manner in
POV-Ray.  The problem of not being able to use "real" classes as members of
most data structures makes it a real hassle.  It is about getting a clean
well-working implementation.  It isn't about "Reference counting is trivial
to implement." at all.

> I'm not sure what use it would be for this though...if a file
> is closed inside a macro, it will still be invalid, even if there are
> still references to it. And how could it be destroyed while in use by a
> macro?

It could be closed, couldn't it?  So what happens if you close it inside the
macro and the try to use it after the macro returns?  You run into tons of
problems due to the current structure of the code, and you should have an
idea how many there are given that you have had a look at the source code
before...

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
>> What do you need the STL for? Reference counting is trivial to
>> implement.

> Yes, reinvent the wheel.

  Exactly which part of the STL implements reference counting?

  (Ok, most std::string implementations use the copy-on-write technique,
which is a superset of reference counting, but that's a completely different
story because it's a completely hidden feature which you can't use in any
way yourself. Other than that, I don't think there's reference counting
anywhere in the STL.)

>  And then try to add it in a clean manner in
> POV-Ray.  The problem of not being able to use "real" classes as members of
> most data structures makes it a real hassle.  It is about getting a clean
> well-working implementation.  It isn't about "Reference counting is trivial
> to implement." at all.

  I suppose that since pov4 will be designed from the scratch, it will be
made so that reference counting will be easier to implement (ie. the
"file handle" entity is a class in the first place).


  Reference counting and the copy-on-write technique are quite efficient
ways of improving the performance of a program when well used.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <3ea7fc66$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> > What do you need the STL for? Reference counting is trivial to
> > implement.
> 
> Yes, reinvent the wheel. 

Reference counting is extremely simple...in my opinion, it doesn't come 
under "reinventing the wheel". And if there is no widespread standard 
implementation, rolling your own is better than not doing it at all.


> And then try to add it in a clean manner in POV-Ray. 

This is a bit more difficult...what I'd really like is to dump the 
current file handling completely and start over again, with a new syntax 
and more functionality. To get something I'd call "clean" would require 
pretty extensive changes...something I'd rather start from scratch than 
try to refactor and redesign so much code.


> The problem of not being able to use "real" classes as members of
> most data structures makes it a real hassle.  It is about getting a clean
> well-working implementation.  It isn't about "Reference counting is trivial
> to implement." at all.

Are you talking about problems with allocating instances of those 
classes? Something that causes trouble with the vtables?
It should not be difficult to create a simple reference-counted pointer 
class that hides all the difficulties of using C++ objects in the data 
structures, and which itself doesn't have any problems.


> It could be closed, couldn't it?  So what happens if you close it inside the
> macro and the try to use it after the macro returns?  You run into tons of
> problems due to the current structure of the code, and you should have an
> idea how many there are given that you have had a look at the source code
> before...

I would not use reference counting for that. Closing the file would set 
some validity flag...having a reference does not mean having an open 
file. Attempting to use the file would then give some kind of error.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

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

> > Yes, reinvent the wheel.
> 
>   Exactly which part of the STL implements reference counting?

I thought he was talking about the auto_ptr template, but that 
apparently doesn't use reference counting. I think you're right, there's 
nothing I can find that exposes reference counting.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3ea87a96@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>>> What do you need the STL for? Reference counting is trivial to
>>> implement.
>
>> Yes, reinvent the wheel.
>
>   Exactly which part of the STL implements reference counting?

Those in ISO C++ 200X...

In article <cja### [at] netplexaussieorg> ,
Christopher James Huff <cja### [at] earthlinknet>  wrote:
> Reference counting is extremely simple...in my opinion, it doesn't come
> under "reinventing the wheel". And if there is no widespread standard
> implementation, rolling your own is better than not doing it at all.

There is one, and it will be part of the ISO C++ standard in the very near
future.

One aspect of C++ being an ISO standard is that there is periodic review
required by ISO, and standards are usually withdrawn (formally, they of
course don't disappear) after five years if there is no update.  And
comments suggest WG21 of ISOs JTC1/SC22 made some important progress in
regard to the standard library extensions during its Oxford meeting earlier
this month.  Details should be avilable within a week on their website.

You can check periodically the page
<http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/> and wait for the
"Post-Oxford mailing" link to appear.  It will make available documents that
say what has been accepted.

    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

In article <3ea8def7$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> > Reference counting is extremely simple...in my opinion, it doesn't come
> > under "reinventing the wheel". And if there is no widespread standard
> > implementation, rolling your own is better than not doing it at all.
> There is one, and it will be part of the ISO C++ standard in the very near
> future.

But it isn't part of the current standard (is it?), and won't be 
widespread for a while.


> You can check periodically the page
> <http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/> and wait for the
> "Post-Oxford mailing" link to appear.  It will make available documents that
> say what has been accepted.

Hmm, looks interesting...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

>> > Reference counting is extremely simple...in my opinion, it doesn't come
>> > under "reinventing the wheel". And if there is no widespread standard
>> > implementation, rolling your own is better than not doing it at all.
>> There is one, and it will be part of the ISO C++ standard in the very near
>> future.
>
> But it isn't part of the current standard (is it?), and won't be
> widespread for a while.

No, you missed something important, probably because you over-read it in the
description of shared_ptr: There is a stable working implementation the
proposal is based on.  It is *not* some nice theoretical idea nobody ever
bothered to implement.  Just go and get it at boost.org...

    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

In article <3ea97743@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> No, you missed something important, probably because you over-read it in the
> description of shared_ptr: There is a stable working implementation the
> proposal is based on.  It is *not* some nice theoretical idea nobody ever
> bothered to implement.  Just go and get it at boost.org...

I haven't read any descriptions of shared_ptr. As far as I can tell, it 
is not part of the current standard. I am well aware of the existance of 
good implementations...if one of those is available with an open enough 
license, I see no reason to avoid using it rather than writing a custom 
version. But it isn't part of the current standard, and if/when it is 
standardized, it will take some time to be widely implemented. None of 
this is a good reason for waiting for it to become standardized and 
widely implemented...if anything, it is a reason not to do so.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

> I haven't read any descriptions of shared_ptr. As far as I can tell, it
> is not part of the current standard. I am well aware of the existance of
> good implementations...if one of those is available with an open enough
> license, I see no reason to avoid using it rather than writing a custom
> version.

No, no, no, you still didn't understand the full scope: Read, from top to
bottom these documents...

<http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1431.htm>
<http://www.boost.org/more/lib_guide.htm#License>
<http://www.boost.org/index.htm> (first two paragraphs)
<http://www.boost.org/libs/smart_ptr/> (the implementation)

As you can see, you are looking for complications where there are none. It
is ready for use already, and it will be standard compliant once there is
the new standard out.  Nevertheless, it is as close to the standard as any
implementation can be given that it is the reference implementation ;-)

> But it isn't part of the current standard, and if/when it is
> standardized, it will take some time to be widely implemented. None of
> this is a good reason for waiting for it to become standardized and
> widely implemented...if anything, it is a reason not to do so.

Sorry, you lost me here...

    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

In article <3ea98bfb@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> As you can see, you are looking for complications where there are none. It
> is ready for use already, and it will be standard compliant once there is
> the new standard out.  Nevertheless, it is as close to the standard as any
> implementation can be given that it is the reference implementation ;-)

I'm saying there isn't a complication where you say there is one.


> > But it isn't part of the current standard, and if/when it is
> > standardized, it will take some time to be widely implemented. None of
> > this is a good reason for waiting for it to become standardized and
> > widely implemented...if anything, it is a reason not to do so.
> 
> Sorry, you lost me here...

Better file handling needs reference counting. Current STL doesn't have 
anything to help with reference counting. Future STL standards that may 
are irrelevant, they aren't here yet. There are current implementations 
of what will probably be in the next standard, and a custom version 
would be trivial. Reference counting is no barrier to better file 
handling in the POV-Ray SDL.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

> Reference counting is no barrier to better file
> handling in the POV-Ray SDL.

It is, because you cannot use any clean implementation in POV-Ray as I
pointed out before.

    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