Actually, this also sounds like a problem of deserializing the container.
This is also a problem with the library as a whole for a lot of people
coming from scripting language backgrounds.
If std::map could be serialized directly, this would afford certainty of
O(n) efficiency.
OTOH, library implementations may differ, and this would also mean the
standard for the library itself would need to be extended to handle data
interchange. AKA standard over-the-wire ABI.

On Thu, Oct 26, 2023 at 8:20 PM magfr via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 2023-10-27 03:23, Smith, Jim via Std-Proposals wrote:
> > Yes, I do mean the nodes of a data structure, for example, left or
> > right node of a binary tree.
> >
> > So for example, if I wanted std::map to use my tree structure
> > implementation certain features would be expected in my implementation
> > that would allow std::map to use it, like a way to iterate over the
> > nodes using accessible members and so on. That's what I meant by
> > expected features.
> >
> > This would allow customization and additional features to be added by
> > the developer and still use the standard library interface in code.
>
> This sounds wierd.
>
> The iteration and node structure is what typically defines the standard
> containers and provides their guarantees.
>
> I believe I have seen some mentions of explicit separation of storage
> and algorithm for containers but I lack a reference for it.
>
> If you just want better names for elements of a map you can use the
> transparant comparator support in std::set (since c++14) to achieve
> that.
>
> struct element {
> int key;
> int value;
> };
> struct element_compare {
> typedef void is_transparent;
> bool cmp(int a, int b) { return a < b; }
> bool operator()(int a, int b) { return cmp(a, b); }
> bool operator()(int a, const element& b) { return cmp(a, b.key); }
> bool operator()(const element& a, int b) { return cmp(a.key, b); }
> bool operator()(const element& a, const element& b) { return
> cmp(a.key, b.key); }
> };
>
> std::set<element, element_compare> mine;
>
> /MF
>
> >
> > -- James S.
> >
> >
> > ------- Original Message -------
> > On Monday, September 18th, 2023 at 2:28 PM, Jason McKesson via
> > Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> >
> >> On Mon, Sep 18, 2023 at 1:52 PM Smith, Jim via Std-Proposals
> >> std-proposals_at_[hidden] wrote:
> >>
> >> > Hi All,
> >> >
> >> > I would like to simply pass my data structure to its std c++
> equivalent and have it construct from the given item or node.
> >> >
> >> > For example:
> >> >
> >> > auto& m = get_my_map();
> >> > ...
> >> >
> >> > // Using type deduction here for m instead of passing to template
> would be
> >> > std::map<int, std::string> m_map(m->node);
> >> >
> >> > so I'm proposing a constructor for the standard data structures that
> will take a node type from a given structure and use it to construct itself
> using existing nodes and expected features of the node type.
> >> >
> >> > Only the range constructors appear to be similar.
> >>
> >>
> >> It is unclear to me what exactly you mean here. When you say "node
> >> type", do you mean the actual `std::map::node_type` type? Or do you
> >> mean "node type" in the vernacular sense of the term (some kind of
> >> data structure with pointers to the other "nodes" in a graph of some
> >> kind)?
> >>
> >> If it's the former, your request doesn't really make sense. The only
> >> "expected features" of a `node_type` object are the ability to modify
> >> both the key and value of the stored object and the ability to inject
> >> it into a compatible container. There is no iteration functionality
> >> that would allow it to get any "existing nodes" from a `node_type`.
> >>
> >> And if it's the latter, then you need to be more specific as to what
> >> the "expected features" of this interface are intended to be.
> >> --
> >> Std-Proposals mailing list
> >> Std-Proposals_at_[hidden]
> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>