'd' can be (and often is) an approximation because there's no
1-to-1 mapping between base-10 floating point values (which is
what you write in your C++ source code) and base-2 floating
point values, which is what most systems use internally.
Any actual value is exact in itself, but can be an approximation
of some other value outside the system. (In physical systems,
this is always the case, independantly of the representation;
all measurements are inprecise to a certain degree.)
I'm not too sure what the original poster is trying to do. He
said something about whether a "decimal" has a double, which
sounds to me whether, given a decimal x, the value 2*x exists.
Which, of course, doesn't make sense. But as Alf said, using
floating point to evaluate "decimal" characteristics just isn't
going to work---comparison for equality or not. Floating point
doesn't have the characteristics of a decimal, and is not a good
abstraction for the set of "decimal" numbers (whatever that
means---I've always understood decimal as refering to a
representation, and not a set of numbers).
Thus when you give a value of the former type to that
function, the compiler will convert it (at compile time)
internally to a value of the latter type, and these two values
may not be equal, hence 'd' may be just an approximation of
the original value in the source code.
But what is the original value. In the funtion above, the
original value *is* d.
Hence x/d and d*10.0 will also be approximations.
Approximations of what? Saying that something is an
approximation supposes that there is an exact value which is
being approximated. In the function, the only "exact values" I
can see are 1.0 and 10.0, both of which are exactly
representable in all of the floating point formats I know.
Of course, the original poster doubtlessly had something in
mind, and d (and the other calculated values) are likely just
approximations of that something. But until he tells us what,
we can only guess.
(It just occurs to me that what he's asking might be simply
whether a given decimal has an exact representation as a double.
In which case, the solution is to convert it, and see if you
need to round the final results. In other words, you have to
work with the original decimal format.)