------=_Part_633_682250391.1492867121572
Content-Type: multipart/alternative;
 boundary="----=_Part_634_18239415.1492867121572"

------=_Part_634_18239415.1492867121572
Content-Type: text/plain; charset=UTF-8

I offer for consideration an alternative approach:

https://github.com/wkaras/C-plus-plus-intrusive-container-templates

This approach is more flexible.  Links, rather than being concrete
pointers, are abstract handles.  In particular, links may be array indexes.
 This allows a container to be layered on top of an array, vector or deque
(used in place of a vector for lower-cost resizing).  One advantage of this
is the possibility of moving or persisting the container with byte-by-byte
copying.

The implementation above is not STL-compatible.  If an abstractor member
function throws an exception, the container will not be restored to the
last coherent state.  The AVL tree implementation, because it does not use
tree parent pointers, has "fat" iterators.  This requires the AVL tree
container to be instantiated with an estimate of maximum size.  Raises an
interesting question, which also applies to STL container implementation:
 Does improved copy elision and return value optimization make it
reasonable to switch to "fat" iterators for tree-based containers, and
eliminate parent pointers.  (Note that the AVL delete member function is
non-recursive and does not otherwise dynamically allocate auxiliary memory,
in spite of the lack of parent pointers.)

A version of the AVL tree in this library was used in older versions of
Apple's open source JavaScript interpreter.

I have used these templates, or similar proprietary ones, in embedded
driver code for Passive Optical Network line cards in Ethernet access
switches.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8988f2aa-3493-4d9e-aa9d-6cffda77561b%40isocpp.org.

------=_Part_634_18239415.1492867121572
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I offer for consideration an alternative approach:<div><br=
></div><div>https://github.com/wkaras/C-plus-plus-intrusive-container-templ=
ates<br></div><div><br></div><div>This approach is more flexible. =C2=A0Lin=
ks, rather than being concrete pointers, are abstract handles. =C2=A0In par=
ticular, links may be array indexes. =C2=A0This allows a container to be la=
yered on top of an array, vector or deque (used in place of a vector for lo=
wer-cost resizing). =C2=A0One advantage of this is the possibility of movin=
g or persisting the container with byte-by-byte copying.</div><div><br></di=
v><div>The implementation above is not STL-compatible. =C2=A0If an abstract=
or member function throws an exception, the container will not be restored =
to the last coherent state. =C2=A0The AVL tree implementation, because it d=
oes not use tree parent pointers, has &quot;fat&quot; iterators. =C2=A0This=
 requires the AVL tree container to be instantiated with an estimate of max=
imum size. =C2=A0Raises an interesting question, which also applies to STL =
container implementation: =C2=A0Does improved copy elision and return value=
 optimization make it reasonable to switch to &quot;fat&quot; iterators for=
 tree-based containers, and eliminate parent pointers. =C2=A0(Note that the=
 AVL delete member function is non-recursive and does not otherwise dynamic=
ally allocate auxiliary memory, in spite of the lack of parent pointers.)</=
div><div><br></div><div>A version of the AVL tree in this library was used =
in older versions of Apple&#39;s open source JavaScript interpreter.</div><=
div><br></div><div>I have used these templates, or similar proprietary ones=
, in embedded driver code for Passive Optical Network line cards in Etherne=
t access switches.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8988f2aa-3493-4d9e-aa9d-6cffda77561b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8988f2aa-3493-4d9e-aa9d-6cffda77561b=
%40isocpp.org</a>.<br />

------=_Part_634_18239415.1492867121572--

------=_Part_633_682250391.1492867121572--

.