Am 15.06.2018 um 21:36 schrieb dick balaska:

> Oh, one thing I don't like, but am leaving alone,
> unix/povconfig/syspovconfig.h contains
> 
> #define POV_CPUINFO         CPUInfo::GetFeatures()
> #define POV_CPUINFO_DETAILS CPUInfo::GetDetails()
> #define POV_CPUINFO_H       "cpuid.h"
> 
> and then later used as
> #ifdef POV_CPUINFO_H
> #include POV_CPUINFO_H
> #endif
> 
> 1) The file cpuid.h contains the class CPUInfo. The file should be named
> cpuinfo.h to match the class.

The file `cpuid.h` just /happens/ to define only that one class these
days. The translation unit's main feature is that it provides access to
the CPUID instruction of the x86 architecture, and the name actually
predates the class. It originally started out as a collection of global
functions, which have now been bundled into aforementioned class.

Since it's not a total misnomer, it has never been renamed, in order to
more easily track the file's history.

The moniker CPUInfo, on the other hand, was chosen because other
architectures may provide CPU information in a different manner.

> 2) POV_CPUINFO_H looks a lot like the header marker
> #ifndef POVRAY_CPUID_H
> #define POVRAY_CPUID_H
> used to read includes once. It works because of the misnaming.

No, it would still work without the "misnaming", due to the header
markers having the naming convention `POVRAY_foo_H`, whereas the
compile-time config settings (mostly) have the naming convention
`POV_foo_H`.

I do concede that it does still /look/ a lot like a header marker.

> (My personal style has always been
> #ifndef _POVRAY_CPUID_H_
> #define _POVRAY_CPUID_H_
> )

That's actually very bad practice, as it is technically in violation of
the C++ standard, which reserves to "the implementation" (*) any names
beginning with an underscore followed by an uppercase letter (**).

(* i.e. the compiler and its accompanying standard include files.)

(* Also reserved are any names containing a double underscore, as well
as any names in the global namespace starting with an underscore.)


> 3) The only option for POV_CPUINFO_H is "cpuid.h" ,
> why have it at all? It *is* used as a boolean switch, but wouldn't that
> be better served by a boolean?
> I guess it was envisioned at conception as having different values for
> different architectures, but on the core editions Windows/Linux/(Mac?)
> it is only ever "cpuid.h"

Not only /was/ it envisioned as having different values for different
architectures, it still /is/. We might for instance decide to add
optimized noise implementations for ARM, where `cpuid.h` would indeed be
a misnomer.

Post a reply to this message