[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Killing off boost::fs
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] Killing off boost::fs |
Date: |
Mon, 1 Aug 2005 01:18:41 -0700 |
User-agent: |
Mutt/1.5.9i |
On Mon, Aug 01, 2005 at 08:13:22AM +0200, Richard Levitte - VMS Whacker wrote:
> In message <address@hidden> on Fri, 29 Jul 2005 20:49:33 -0700, Nathaniel
> Smith <address@hidden> said:
> njs> - one should not be able to instantiate a file_path directly.
> njs> Instead there should be two constructors; one that takes (and
> njs> requires) an already-normalized path, and one that takes an
> njs> unnormalized path and normalizes it. Doing this allows us to
> njs> be more secure, and probably also faster, when dealing with
> njs> important contexts (e.g., parsing revisions) where we _know_
> njs> that the path should be normalized already.
>
> I assume that in this case, you're not talking about the constructor
> methods, but about separate functions. Otherwise, I don't quite
> understand what you mean with "not be able to instantiate a file_path
> directly".
Yeah, I'm thinking something like
class file_path {
private:
file_path(std::string const & s);
friend file_path file_path_from_normalized_string(std::string const &);
friend file_path file_path_from_unnormalized_string(std::string const &);
};
Those names can obviously use shortening... the point is that each
call should be explicit about what it expects.
> Speaking of normalised and not normalised, can't we simply assume that
> all paths we get as input aren't normalised?
Input from the user, yes. But there are other strings -- for
instance, those encountered when parsing a revision, or manifest
-- that should be normalized, and it should be an error if they are
not. Plus, maybe this would give speed improvements, verifying the
paths in manifests is slow.
> BTW, I assume that with "normalised", you're talking about removal of
> ../ when possible, tilde-expansion, compression of a sequence of / to
> one /, things like that.
Possibly also utf8 conversion; definitely also conversion of \ to / on
windows, ...
> njs> - it might also make sense to have these constructors take care
> njs> of the prefixing required to deal with calling monotone in a
> njs> subdirectory
>
> So basically, you want the notion of the top of a work directory tree.
Yeah.
> njs> - the bookkeeping_path constructor should require an
> njs> already-normalized path that begins "MT/", since we always
> njs> generate these internally anyway.
> njs> - system_path (maybe needs a better name?) should always be
> njs> absolutified and tilde-expanded, and otherwise do not need to
> njs> be verified.
>
> Do we want any path to be tilde-expanded, or just the system_path?
Just system_path, I think; though possibly ~ should just be disallowed
in other paths... basically, one can think ~foo as being like /foo,
it's an absolute path.
> njs> We don't need many actual operations on these:
> njs> - write file
> njs> - read file
>
> Uhm, just a small thing here; there already is iostream, so I'm going
> to assume you really mean "open", or possibly even just method that
> returns a localised string that represents the path to be used with
> normal iostream operations and whatnot. Actual writing and reading
> should be left to iostream, IMHO.
Oh, sure -- or some other IO library (crypto libraries tend to come
with these). But there should be a monotone function that does this,
is all.
-- Nathaniel
--
"But in Middle-earth, the distinct accusative case disappeared from
the speech of the Noldor (such things happen when you are busy
fighting Orcs, Balrogs, and Dragons)."