Boost logo

Boost :

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2022-08-24 14:59:27


On Tue, Aug 23, 2022 at 12:08 PM Alan de Freitas via Boost
<boost_at_[hidden]> wrote:
>
> >
> > Ok, I'm convinced. I am still not convinced that the containers that
> > maintain these invariants should be lazy. That still seems weird to
>
> me. If they own the data, and are regular types, they should probably
> > be eager. The larger issue to me is that they have a subset of the
> > expected STL API.
>
>
> Yes. If I understand the discussion correctly, the container that maintains
> the invariant is not lazy but the documentation could probably be better at
> explaining some other things.
> It's the urls::url that maintains the invariants and owns the data in
>
> url u( "ldap:local:userdb/8675309" );
> u.remove_scheme();
> (u == "local%3a/8675309");
>
> The urls::segment and urls::params views are just references to part of
> this urls::url. The invariants belong to the url.
> They are helpers to operate on the urls::url segments and parameters at an
> individual level, while the underlying urls::url adjusts itself to keep the
> invariants:
>
> url u( "" );
> u.set_path("//index.htm");
> (u == "/.//index.htm");
>
> url u( "" );
> u.is_absolute(true);
> u.segments().append({"", "index.htm"});
> (u == "/.//index.htm");
>
> So the eager urls::url is the one maintaining the invariants, but the
> segment or parameter views are a better way to operate on the URL when
> dealing with individual subcomponents.
> Thus, the functions are not exactly a subset of the STL because the
> operations are ensuring the invariants of the underlying url remain valid.
> (The names "segments" and "params" might be a little confusing because it
> sounds like it owns the data. Some other review has recommended
> mutable_segments_view/mutable_params_view.)

This seems to be the heart of the matter. I expect params to be a
real flat_map or map or sorted vec, and it's not. If my expectation
is wrong because of the lack of a _view suffix in the name, that's
fine -- but please add that to make things clear. However, the _view
suffix in std C++ is used exclusively for immutable types, so maybe
something else is indicated, like _facade or some variation of span.

Zach


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk