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