POV-Ray : Newsgroups : povray.off-topic : Job Interview : Re: Job Interview Server Time
29 Jul 2024 06:18:40 EDT (-0400)
  Re: Job Interview  
From: Le Forgeron
Date: 5 Mar 2012 03:33:13
Message: <4f547a49$1@news.povray.org>
Le 05/03/2012 01:10, Darren New a écrit :
> On 3/4/2012 14:33, Warp wrote:
>>          return mData[index];
> 
> Given the previous discussion, I'm betting this is the error Warp was
> talking about - returning the address of a variable that gets disposed
> when this object gets disposed. It's basically the same bug - scopes
> exceeding lifetimes.  I'm amused that Ada actually prevents this bug
> unless you explicitly say "Yes, yes, I'm intentionally assigning a value
> to a pointer whose lifetime is shorter than that of the pointer."
> 

I doubt it a bit. It would be at worst an issue with the
copy-constructor of Value_t (if any), but I would think (maybe wrongly)
that due to the prototype of the function (returning a reference to
Value_t), the mData[index] is actually the real reference (compiler
handling the issue of &/* for us here).

One real bug is when used with the following code:

int foobar()
{
 Array<int> foo(3);
 foo[0] = 3;
 foo[1] = 7;
 foo[2] = 0;
 {
 Array<int> bar(foo); // get a copy of foo
 bar[2] = bar[1] + bar[0]; // no problem, it's 3+7
 }
 foo[2] += foo[1] * foo[0];     // you might crash here already
 return foo[2];     // these result is going to be surprising sometime
}                   // you definitely have a problem with glibc here!

Same kind of issue might happen if you provide Array<> to methods by
values without const (hence needed some copy-constructor... and the call
to the destructor for the intermediate objects)

-- 
A good Manager will take you
through the forest, no mater what.
A Leader will take time to climb on a
Tree and say 'This is the wrong forest'.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.