On 08/16/2014 10:17 AM, clipka wrote:
> 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?

ac564f7 was the last time I was able to compile and run OTOTest file 
correctly ... cf1c3fb wouldn't even compile. jumped to af80da4 (the last 
issue #29) commit and it compiled fine but OTOTest file problem showed 
up again

Post a reply to this message