Warren Young wrote:
> We had implicit conversion from stringish types to Date, DateTime and
> Time in v2, but it conflicted with the SSQLS extensions in v3.
> With the SSQLS stuff in place, even the most innocent code would end
> up causing an ambiguous conversion error. I never did analyze it
> fully, but I believe it's due to the fact that with String and
> SQLTypeAdapter each offering the compiler so many conversion options
> and so many MySQL++ classes taking or returning these types, it's easy
> to end up giving the compiler all the rope it needs to hang itself,
> allowing conversion from anything to anything. C++ can't cope with
> that, due to the compile-time predictability requirements of its
> static type system.
> If you want to see it yourself, remove the 'explicit' from the ctors
> in these classes, then watch MySQL++ blow up. Er, I mean, asplode.
> We may restore these implicit conversion ctors in v4, if SSQLS v2
> fixes the core problem, but for now, we have to live with it.
I know what you mean. I got hit several months ago by an insidious bug
where, I'd accidently gotten some arguments in the wrong order or
something similar and rather than complain that it couldn't cast a bool
to the type it was expecting, g++ figured int was close enough, and
called the constructor with 1 or 0. Frankly I cannot imagine why; bools
are not numbers. That's the whole reason the type exists. I'm pretty
sure the Microsoft compiler didn't do this sort of thing. Putting an
explicit constructor for bool, which does nothing because the class was
a date-time class where a bool doesn't make sense, fixed it, but
figuring out what was going on in the first place was non-trivial.