Ken Smith wrote:
> the mechanism that MySQL++ uses to build queries
> effectively converts all the variables to strings.
Yes, as does virtually every other SQL-based system. Elevating the
abstraction layer from platform-specific binary data to plain old text
is one of the reasons SQL has taken over the world. There have been
efforts to define cross-platform binary data formats (XDR and ASN.1 come
to mind) but they remain relatively obscure.
> I'm at the mercy of
> setprecision if I want to preserve the original number.
Well, yes, but MySQL++ sets the precision to the largest value that
preserves all the digits. With a 64-bit float ("double"), that's 17
digits. If you're really running into roundoff or precision issues by
losing something down in the 17th digit, you either shouldn't be using
floating point in the first place, or you're using the wrong scale for
This really isn't a MySQL++ issue. It's an FP issue.
> It's critical
> for my work that the original data is not massaged in any way.
When you use FP, you lose precision at the lowest digits all the time.
The question is whether it actually matters. You can say you need
absolute fidelity, but you also say you're dealing with scientific data;
I'd bet your data source doesn't actually give you 17 reliable digits of
precision. A I've heard of some experiments having precision down in
the part-per-trillion range, 5 orders of magnitude bigger than the loss
of data at the last digit in a 64-bit float.
If I'm wrong, please, I'd love to hear what instrument you're using that
gives you 17 accurate digits in its measurements. Sounds awesome.
> Is there a MySQL++ equivalent that facilitates movement of C++ types
> into MySQL types without running it through ostream manipulators?
SSQLS may gain this facility someday, but not until after SSQLSv2 is
released, as part of MySQL++ 3.1. The main reason to do it would be
speed, rather than preservation of precision, and even that's of