Add front and back to list,vector, deque and array containers

[HGuillemet]

Add front() and back() to the containers that support them.
This is for convenience only, since front() should be equivalent to begin().access(), so feel free to reject it.

[saudet]

This is for convenience only, since front() should be equivalent to begin().access(), so feel free to reject it.

Right, so generate methods like these instead just like for push_back() and pop_back():

"public " + valueType.annotations + valueType.javaName + " front() { return begin().access(); }\n"
"public " + valueType.annotations + valueType.javaName + " back() { return rbegin().access(); }\n"

That only works if we can assume rbegin() is always available, so maybe just do front() for now if you don't need back(). It looks like std::prev() is the way to go for that, but it's only available since C++11 and may not work with all custom templates either anyway.

[saudet]

Oh, it looks like std::prev() just loops over all elements until it reaches the end:
https://en.cppreference.com/w/cpp/iterator/advance
Please do that here as well.

[HGuillemet]

I understand that you'd like to have the option to define containers that follow some model (like std::vector) but don't have all the standard API of this model. For instance some "vector" templates that don't implement front(). Right ?

In this case we'd probably not try to implement non-essential API like front and back in Java, since the best-suited implementation can vary. As you said, back could be implemented as rbegin().access(), or get(size()-1) or end().prev(), etc... That choice may be important for long structures.

I was mainly thinking that users would like an easy way to get a pointer to the underlying arrays for continuous array-like structures. But begin().access() or get(0) is fine.

So let's give up this idea ? Or only implement front ?

[saudet]

Yes, using get() sounds like a better idea, for both front() and back().

[HGuillemet]

... if we have a long index.

What about this last commit ?

[saudet]

Seems to be working well. We could remove the annotations from valueType.javaName though.

[saudet]

It would be nice to have those that uses get() be put just before the get() function. It also makes more sense to have it generated next to the get() function it uses anyway. The one that uses the iterator, before insert() would be nicer I think.