`vector_algorithms.cpp`: split into multiple translation units or otherwise enhance file navigation?

[AlexGuteniev]

vector_algorithms.cpp grew to about 6000 lines. That's about a half of <algoirthms> size. Out of separately compiled files it stands out, with only xcharconv_ryu_tables.cpp exceeding it.

The navigation became somewhat inconvenient, especially with a lot of unnamed namespaces, each containing its own functions set:

Do we want to do something about it?

We can:

• Do nothing
• Split vector_algorithms.cpp into multiple files
• Fuse all unnamed namespaces into one
• Do something diffrerent

[jovibor]

• Fuse all unnamed namespaces into one

Or create new namespace for all these methods, for convenience. Something like std::__vecalgos, if it's possible.

[StephanTLavavej]

I would prefer to avoid splitting up the file - that interferes with history, makes the STL take longer to build, and makes it somewhat harder to see commonality.

However, since we're gathering so many different implementations, I think it would be an improvement to create more grouping by introducing separate namespaces for each family of support functions, within the unnamed namespace (which continues to make it clear that these are never used by anything outside).

Basically, I don't think that large files are inherently problematic, but "who uses what" is more important to keep clear.

[AlexGuteniev]

However, since we're gathering so many different implementations, I think it would be an improvement to create more grouping by introducing separate namespaces for each family of support functions, within the unnamed namespace (which continues to make it clear that these are never used by anything outside).

Sounds good! The only issue I see is increased indentation. Will we accept it or resist it somehow?

[StephanTLavavej]

I wouldn't worry about it.

[AlexGuteniev]

Ok, it is actionable now.

It would be a good idea to do when no other PRs changing vector_algorithms.cpp are there.
But possibly can combine with other minor cleanups, like missed const or inconsistently present _CSTD.

[AlexGuteniev]

__std_bitset_from_string / __std_bitset_to_string captured in that screenshot too looking like a good example of what should be done.

I would rename them though to _Bitset_from_string / _Bitset_to_string to make them shorter, and add other namespaces like this.

[AlexGuteniev]

The problem that I see with IDE navigation is not code problem, it is IDE problem; see DevCom-10889095

Still namespaces would help for the reason Stephan T. Lavavej (@StephanTLavavej) mentioned.