[ELF] Use std::string references when processing options

[dmantipov]

Prefer std::string & when calling and processing the result of add_dashes(), thus saving a few calls to std::string copy constructor.

Signed-off-by: Dmitry Antipov [email protected]

[rui314]

We don't need to optimize the code in this file, so conservatively copy strings is fine. Generally, we should avoid optimizing code until it is proven to be a bottleneck.

[LowLevelMahn]

but they can be made const std::string& - that would makes it also clear that they do not change inside and they would not copy, or? does that really fall under "premature optimization"?

[rui314]

In terms of performance, that doesn't make any measurable difference in this case. So it's more like a personal preference, and I feel conservatively copying strings is at least just as clear than passing a const reference.

[jonesmz]

Bottlenecks not withstanding, wouldn't you want to use std::string_view, over a non-const lvalue-reference anyway?

[rui314]

In general, we prefer std::string_view, but I guess there was a reason to use std::string here. For example, you can't concatenate std::string_view with operator+.