Documenting something I see for whoever might trip over it later.

I've been working toward a cut down *nix only 'povray'. We today have 
precomp.h and precomp.ccp files which look to be trying to precompile 
common c/c++ headers for faster developer compiles. As set up this 
mechanism does not work for *nix compiles. We get an 'empty' precomp.o 
in each directory which is more or less harmless except for a little 
compile time and...

Supposing the precomp.h and precomp.ccp mechanism does work with windows 
compiles, it might explain why, back when Christoph added the user 
defined camera for the ODS camera work we hit that *nix only issue with 
abs() not resolving to fabs(). I've since had this itch we might have 
floating about similar *nix particular exposures due header inclusion 
order(1).

Bill P.

(1) - Potentially where, in the code, not using std::<function> 
namespace names.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Documenting something I see for whoever might trip over it later.
>
> I've been working toward a cut down *nix only 'povray'. We today have
> precomp.h and precomp.ccp files ... I've since had this itch we might have
> floating about similar *nix particular exposures due header inclusion
> order(1).
>
> Bill P.
>
> (1) - Potentially where, in the code, not using std::<function>
> namespace names.

pardon my ignorance but would that problem not .. disappear if, instead of
importing, all names were given fully qualified?  (ie with namespace)


regards, jr.

Post a reply to this message

On 3/20/20 6:25 AM, jr wrote:
...
>> precomp.h and precomp.ccp files ... I've since had this itch we might have
>> floating about similar *nix particular exposures due header inclusion
>> order(1).
...
>> (1) - Potentially where, in the code, not using std::<function>
>> namespace names.
> 
> pardon my ignorance but would that problem not .. disappear if, instead of
> importing, all names were given fully qualified?  (ie with namespace)
> 
Yep, fully qualified everywhere would close the exposure I think. 
Christoph was making changes in that direction - though his work might 
have been driven more by header re-work than my *nix specific worry.

Converting explicit std::<?>abs uses to std::abs and the like probably 
good to do too with care. Occasionally the aim might be to force certain 
input types / or to do indirect type conversions via a more specific 
function working on and returning certain types.

Bill P.

Post a reply to this message