|
|
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
|
|