POV-Ray : Newsgroups : povray.binaries.images : unexplained : Re: unexplained Server Time
6 Oct 2024 06:23:04 EDT (-0400)
  Re: unexplained  
From: clipka
Date: 16 Aug 2014 10:17:28
Message: <53ef67f8$1@news.povray.org>
Am 16.08.2014 12:49, schrieb James Holsenback:
> On 08/13/2014 07:28 AM, clipka wrote:
>> Am 13.08.2014 12:11, schrieb James Holsenback:
>>
>>>>> narrowed a bit further ... this hash works fine:
>>>>> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>>>>>
>>>>>
>>>> ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I
>>>> think that's considerable less territory to cover.
>>>
>>> this hash ac564f7231f2b05b461a3a03fe6b9ed21b845c5a is the last working
>>> commit (compiles and runs OTOTest.pov properly)
>>>
>>> broken @ cf1c3fbedb33802bd431acac43ce41db55fa87b8 ... doesn't even
>>> compile ./base/safemath.h is belching errors all over the place
>>
>> Ah, yes, that one... that's part of GitHub issue #29. It'll need
>> replacing of "numeric_limits" with "std::numeric_limits" (and then
>> probably some more fixes).
>
> have you been able to (or are you even going to) look into why the
> implementation (re-factoring???) of this construct isn't compatible with
> my compiler (that's what appears to be happening) since you can't
> confirm on your end.

The "numeric_limits" in the global namespace (i.e. without "std::") 
isn't compatible with your compiler because it's not ISO C++. MS Visual 
C++ does support it, but other compilers (or, more precisely, the 
respective <limits> header file) may not.

Prior to that change, there was a statement "using namespace std;" which 
effectively says, "everything in namespace std should also be available 
in the current namespace", or, in other words, "std:: can be omitted 
everywhere". It had to be dropped because with some compilers it caused 
name conflicts between implementations of the shared_ptr class from 
different sources (boost, tr1 and C++11).

> it /really/ appears that this (OTOTest file) got broken @
> cf1c3fbedb33802bd431acac43ce41db55fa87b8 and that the issue #29 commits
> just cleaned up the implementation so i could at least compile.

I wouldn't expect the issue #29 commits to do anything else. They're 
just there to use less ambiguous language constructs to satisfy some 
compilers that are less forgiving than MS Visual C++.

If I understand you correctly, you're saying that with issue #29 fixes 
in place commit 7502593 works while cf1c3fb doesn't. Is that right?


Post a reply to this message

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