You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
const std::vector<std::string>& positional() const { return unnamed_params; }
//! Note: std::map[key] would want to create a key if not yet there,
//! so named()[...] would fail, if const! But constness it is... (for consistency).
//! Use the op() and op[] accessors for direct element access!
const std::map<std::string, std::vector<std::string>>& named() const { return named_params; }
It's pretty orthodox to have them always const. I mean it's yours, change it all you want! :) Especially for #54!...
I can imagine use cases where a pristine command-line, safe from tampering, is nice to have, but as soon as you have the modifying methods, the same object is no longer tamper-proof anyway: just having const accessors, too, won't help. ;)
So, just copy your command-line to a const object if you want a safe reference.
Going with non-const only... (You'll get your compilation errors all right when trying to actually use those methods on a const obj.)
-> Err... OK, but then... No... Other const accessors do call these, so I still need the const pairs after all, too... :-/
The text was updated successfully, but these errors were encountered:
xparq
changed the title
Drop const from named() and positional() (or have both)
Drop const from named() and positional() (or have both?)
Nov 5, 2023
xparq
changed the title
Drop const from named() and positional() (or have both?)
Drop const from named() and positional() (or have them both ways?)
Nov 5, 2023
xparq
changed the title
Drop const from named() and positional() (or have them both ways?)
Drop const from named() and positional() (or have it both ways?)
Nov 5, 2023
xparq
changed the title
Drop const from named() and positional() (or have it both ways?)
Drop const from named() and positional() (or have it both ways?)
Nov 5, 2023
It's pretty orthodox to have them always
const
. I mean it's yours, change it all you want! :) Especially for #54!...I can imagine use cases where a pristine command-line, safe from tampering, is nice to have, but as soon as you have the modifying methods, the same object is no longer tamper-proof anyway: just having const accessors, too, won't help. ;)
So, just copy your command-line to a const object if you want a safe reference.
Going with non-const only... (You'll get your compilation errors all right when trying to actually use those methods on a const obj.)
-> Err... OK, but then... No... Other const accessors do call these, so I still need the const pairs after all, too... :-/
The text was updated successfully, but these errors were encountered: