From: Miro Jurisic (macdev_at_[hidden])
Date: 2004-10-22 12:10:27
In article <uis92u4hg.fsf_at_[hidden]>,
David Abrahams <dave_at_[hidden]> wrote:
> "Erik Wien" <wien_at_[hidden]> writes:
> > "Miro Jurisic" <macdev_at_[hidden]> wrote in message news:macdev-
> >> I am not sure I buy this. I think that if you want to have
> >> unchecked Unicode data, you should use a vector<char*_t>. Unicode
> >> strings have well-defined invariants with respect to
> >> canonicalization and well-formedness, and I think that the a
> >> Unicode string abstraction should enforce those invariants.
> >> Having intermediate states that are invalid and a final state that
> >> is valid is not a feature, it's a bug. It's a silent failure that I
> >> want to know about.
> > Amen. ;)
> How is this different from the situation with filesystem::path, where
> eager checking has turned out to be painful for a broad spectrum of
I am not familiar with the problem in boost::fs so I can't comment on that
specifically, but I can comment in a more general sense. I think we can safely
1. There is an invariant that is valuable in some problem domains
2. There may be some problem domains in which it is valuable to sidestep that
boost::fs, as far as I understand it, ran into the problem that it was
impossible to sidestep the invariant.
My position is not that we should prohibit people from manipulating Unicode
strings in a manner that does not maintain well-formedness. My position is that
we should permit use of Unicode strings that guarantees well-formedness.
I haven't taken the time to figure out how to do that (if I had the time, I
would not be discussing how Erik could do this, I'd be writing a proposal myself
I come from a problem domain in which an abstraction which guarantees
well-formedness has more value, but I am not looking for an answer that
satisfies me and nobody else.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk