@DMGregory Working though my queue, I ran across an anonymous edit to your answer with the comment 'Code Error'. It looks suspect to me, but I figured maybe just ping you & get your thoughts.
@Pikalek I'd agree the edit does not look correct to my eye. I haven't run the code though, and it's late, so it's entirely possible that I'm missing something obvious.
There is an issue on Unity bugtracker that is directly related to my problem with vector icons: https://issuetracker.unity3d.com/issues/ui-components-eg-image-component-is-no-longer-anti-aliasing-in-game-view-with-screen-space-overlay-canvas > Won't fix
@Pikalek Ah, no, fresh eyes in the morning, there was indeed a typo. < should have been >. Looks like the confusing edit was to get around the restriction on single-character changes.
How do you tell your software what command-line arguments it received? We have a class that distributes each argument to relevant 'Manager' through one of its static value, and once the manager is initialized, it checks that static value and use it to initialize its instance value. This has the advantage of having all of the command line arguments at one place, but this forces us to use a weird pattern relying on static variables.
You need a specialized main function declaration: main(int argc, char* argv[])
argc is the # of command line args - as I recall, the command used to launch the app counts as one of them
argv is an array that holds the string of the command line args
I think you can also do char** argv - not sure if one or the other has become de facto w/ modern C++
Back when I did C++, I had to parse them out by hand. Now days it looks like there is a getopt library to help with it.
If you're asking about getting the command line args from other places in the code, I'm not sure about that. I wouldn't be surprised if there's some sort of hack to do it, but I only familiar with passing them on from main.
Honestly, if possible I would consider copying them to a singleton as the first thing thing done in main & just let what ever code needs them to pull them from the singleton as needed.
@Pikalek yeah, that's the second option I wa considering. Then the #inclues are done the other way around: the "MgrViewer" includes "MgrCmdLinOptions".
Was*
This still leaves an imperfection. Right now, the MgrCmdLineOption has acces to the many Managers (physics, viewing, shadowing, etc), so it can do the "translation" from a string (from argv) or an int to the "target" value (e.g. it can convert "-shadow1" to MgrShadowing::SHADOW_1). Not sure how I'd pull this off with it the other way around.
Hmm I think I have an idea. But I won't implement it because no bang for the buck for now.
Another consideration of pulling the values out of a singleton is that sometimes options override those that have been set before e.g. with "-shadow0 -shadow1", the system should receive "shadow1" and not "shadow0".
@AlexandreVaillancourt One option is to have the singleton act as a glorified global variable. In that case, it only holds the command line args as originally presented & it's up to the calling code to know if it needs to resolved "shadow1" with anything else.
Another option is to turn the singleton into a sort of command line args manager. In that case either directly or indirect it resolves things like "shadow0" vs. "shadow1" and holds the result.
Although in the latter case, I would still have it keep a copy of the args as originally presented at launch for diagnostic purposes.
As for converting "-shadow1" to MgrShadowing::SHADOW_1, I would probably push that which ever manager deals with that.
But as you said, if there's no big payoff for reworking the code, leaving it as is sounds very reasonable.
