- ParseParameters
- ReadConfigFile
- ForceSetArg
- SoftSetArg
Includes:
- Introduce an ArgsManager class encapsulating cs_args, mapArgs and mapMultiArgs #9494
From the wrappers newly introduced with ArgsManager, these seem currently the easiest to remove.
Includes:
From the wrappers newly introduced with ArgsManager, these seem currently the easiest to remove.
378 | + mapMultiArgs[str].push_back(strValue); 379 | } 380 | } 381 | 382 | -bool IsArgSet(const std::string& strArg) 383 | +std::vector<std::string> ArgsManager::ArgsAt(const std::string& strArg)
Any reason to not return a const ref?
Also, ArgsAt is a bit of an odd name, perhaps ArgsFor or something (but maybe not worth the effort to redo this)
See #9494 (review) for some reason all your reviews are appearing in #10119 instead of #9494 . Can you make the comments there for other reviewers to get them? Remember after #9494 this PR (#10119) is a single commit (that could be squashed to #9494 or not)
oh -- I didn't understand 'includes' to mean builds on the PR. gotcha
442 | -void ForceSetArg(const std::string& strArg, const std::string& strValue) 443 | +void ArgsManager::ForceSetArg(const std::string& strArg, const std::string& strValue) 444 | { 445 | LOCK(cs_args); 446 | mapArgs[strArg] = strValue; 447 | + mapMultiArgs[strArg].push_back(strValue);
Should this push_back or replace?
I believe push_back, but it's a good point, I am not sure now.
445 | LOCK(cs_args); 446 | mapArgs[strArg] = strValue; 447 | + mapMultiArgs[strArg].push_back(strValue); 448 | } 449 | 450 | +bool IsArgSet(const std::string& strArg)
Is the PR too big if you get rid of these?
The less disruptive to remove are removed in #10119 I'm happy to squash that in #9494 Others are more disruptive to remove, but I'm working on doing it for SoftSetBoolArg and IsArgSet in https://github.com/jtimon/bitcoin/compare/0.14-args-wrappers...jtimon:0.14-args-isargset-wrapper but I'm not sure everybody will like that way of doing it.
130 | @@ -133,6 +131,16 @@ inline bool IsSwitchChar(char c) 131 | #endif 132 | } 133 | 134 | +class ArgsManager 135 | +{ 136 | +protected: 137 | + CCriticalSection cs_args; 138 | + std::map<std::string, std::string> mapArgs; 139 | + std::map<std::string, std::vector<std::string> > mapMultiArgs;
why not use multimap?
I was just using the same that was used before. We can move to multimap, what would be the gain?
No real gain, just slightly simpler (because multi_map is intended to be used I think exactly in this type of case).
I thought it was more for when you wanted the elements on the vector to be ordered in certain way or something. Leaving the same structure seems easier to review, but once encapsulated it is easy to make further improvements to ArgsManager's internal implementation.
utack
Needed rebase.
- ParseParameters
- ReadConfigFile
- ForceSetArg
- SoftSetArg