Skip to content

Conversation

@admo
Copy link
Contributor

@admo admo commented Oct 12, 2024

For Vector or Array of structures the dereference operator of an iterator returns the pointer to the structure. However, IndirectHelper, which is used in the implementation of this operator, is instantiated in the way that the IndirectHelper::Read returns structure by value.

This is because, Vector and Array instantiate IndirectHelper with const T*, but VectorIterator instantiates IndirectHelper with T. There are three IndirectHelper template definition: first for T, second for Offset and the last one for const T*. Those have different IndirectHelper:Read implementations and (more importantly) return type. This is the reason of mismatch in VectorIterator::operator* between return type declaration and what was exactly returned.

That is, for Array<T,...> where T is scalar the VectorIterator is instantiated as VectorIterator<T, T>, dereference operator returns T and its implementation uses IndirectHelper which Read function returns T.
When T is not scalar, then VectorIterator is instantiated as VectorIterator<T, const T *>, dereference operator returns const T * and its implementation uses IndirectHelper which Read function returns T.

The fix is done as follows:

  • implement type trait is_specialization_of_Offset and is_specialization_of_Offset64,
  • change partial specialization of IndirectHelper with const T * that it is instantiated by T and enabled only if T is not scalar and not specialization of Offset or Offset64,
  • remove type differentiation (due to scalar) from Array..

The above makes the IndirectHelper able to correctly instantiate itself basing only on T. Thus, the instantiation in VectorIterator correctly instantiate IndirectHelper::Read function, especially the return type.

It fixes issue #8093.

@github-actions github-actions bot added the c++ label Oct 12, 2024
@github-actions
Copy link
Contributor

This pull request is stale because it has been open 6 months with no activity. Please comment or label not-stale, or this will be closed in 14 days.

@github-actions github-actions bot added the stale label Apr 12, 2025
@admo
Copy link
Contributor Author

admo commented Apr 13, 2025

not-stale

@admo
Copy link
Contributor Author

admo commented Apr 13, 2025

@dbaileychess Please take a look at this change — it’s been open for quite a while 🙂

@github-actions github-actions bot removed the stale label Apr 13, 2025
@admo
Copy link
Contributor Author

admo commented May 17, 2025

@aardappel maye you could take a look?

For Vector or Array of structures the dereference operator of an
iterator returns the pointer to the structure. However, IndirectHelper,
which is used in the implementation of this operator, is instantiated
in the way that the IndirectHelper::Read returns structure by value.

This is because, Vector and Array instantiate IndirectHelper with
const T*, but VectorIterator instantiates IndirectHelper with T. There
are three IndirectHelper template definition: first for T, second for
Offset<T> and the last one for const T*. Those have different
IndirectHelper:Read implementations and (more importantly) return type.
This is the reason of mismatch in VectorIterator::operator* between
return type declaration and what was exactly returned.

That is, for Array<T,...> where T is scalar the VectorIterator is
instantiated as VectorIterator<T, T>, dereference operator returns T
and its implementation uses IndirectHelper<T> which Read function
returns T.
When T is not scalar, then VectorIterator is instantiated as
VectorIterator<T, const T *>, dereference operator returns const T * and
its implementation uses IndirectHelper<T> which Read function returns T.

The fix is done as follows:
* implement type trait is_specialization_of_Offset and
 is_specialization_of_Offset64,
* change partial specialization of IndirectHelper with const T * that
 it is instantiated by T and enabled only if T is not scalar and not
 specialization of Offset or Offset64,
* remove type differentiation (due to scalar) from Array..

The above makes the IndirectHelper able to correctly instantiate itself
basing only on T. Thus, the instantiation in VectorIterator correctly
instantiate IndirectHelper::Read function, especially the return type.
@aardappel
Copy link
Collaborator

Thanks for the fix!

This makes the templates somewhat more convoluted and using newer C++ features, so there is a risk we may be annoying people on older compilers with this.. but lets merge for now and see.

The CI errors are not related to this PR.

@aardappel aardappel merged commit 5822c1c into google:master May 18, 2025
48 of 50 checks passed
@admo admo deleted the fix_issue_8093_2 branch May 18, 2025 19:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants