POV-Ray : Newsgroups : povray.beta-test : master branch issue 29 linux compilation errors : Re: master branch issue 29 linux compilation errors Server Time
28 Apr 2024 15:24:29 EDT (-0400)
  Re: master branch issue 29 linux compilation errors  
From: clipka
Date: 30 Jun 2014 13:20:32
Message: <53b19c60$1@news.povray.org>
Am 30.06.2014 18:06, schrieb Le_Forgeron:

> * "return GenericPigmentBlendMapPtr(NULL);" might compile better as
> "return GenericPigmentBlendMapPtr()" (calling the constructor of
> shared_ptr without argument, making a shared_ptr to nullptr.
> (otherwise, IIRC, NULL is taken as the argument for the constructor of T
> in shared_ptr<T>)
>
> (I'm more familiar with C++11 std::shared_ptr<T>, so I might be wrong
> when applied to C++03 & boost . when I need fresh instanced value,
> std::make_shared<T>(params for T's constructor...) is my friend)

Technically you're right in that the NULL is not required, but you're 
wrong on the details: The shared_ptr<T> constructor does /not/ pass its 
arguments to a constructor of T; in fact, it never even constructs an 
instance of T at all. Instead, it takes a /pointer/ to an 
already-created instance of T as an argument (with NULL being a valid 
parameter as well). To construct a T without make_shared (which is not 
available in TR1), you have to invoke:

     shared_ptr<T>(new T(params for T's constructor...));

As for using "return shared_ptr<T>()" instead of "return 
shared_ptr<T>(NULL)", note that those pieces of code should never be 
called in the first place anyway (they all follow either an 
"assert(false)" or an "Error(...)"), and the only reason they even exist 
is to satisfy compilers ("all control paths must return a value"). I 
prefer to go for code clarity there and leave the "NULL" parameter in.


Post a reply to this message

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