From: Carlo Wood (carlo_at_[hidden])
Date: 2004-08-23 10:27:05
On Mon, Aug 23, 2004 at 09:47:52AM -0500, Patrick Bennett wrote:
> Correct (kind of), but I'd far prefer that std::string be used than for
> some completely new type to be defined.
std::vector<char> comes to mind.
> For users of boost::filesystem, I can't personally think of a time when
> a user would need to iterate the paths or files a character at a time.
Bzzzzt. Everything is always, somewhere, needed :p
I can't think of it either - but the number of times that I thought
something wasn't needed, or when I needed something and the original
author wrote that he thought it would never be needed, are countless.
> Because of UTF-8's nature, even if a user were to search for something
> like '/', it would still work for find's, , etc. UTF-8 maps to
> std::string extremely well.
> I think there is also a fair amount of precendents already set for using
> UTF-8 internally using std::string as the storage mechanism.
People associate a std::string with something printable and will be tempted
to use std::string::c_str() to pass the 'string' to some function.
I think that using a std::string of binary data is not a good idea when
it can contain '\0' in the middle.
> UTF-8 strings don't contain embedded nul's (std::string still works for
> that though), ASCII characters remains ASCII characters, and you can
> tell if you're in the middle of a multi-byte sequence.
Ah - I retract my objection ;).
If UTF-8 is garanteed not to have nul's embedded then there is no
reason not to use std::string for it imho.
-- Carlo Wood <carlo_at_[hidden]>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk