As in the title, I'm making a small bank app simulator in ncurses, and I've been trying to make some wrappers for ncurses stuff so it's less manual but I've hit a big challenge with init_pair and COLOR_PAIR stuff, I have a wrapper for WINDOW objects so I don't have to allocate and deallocate them manually but what if I want to pass the color pair of given window at the wrapper's construction? since every color pair is identified by a global number defined in init_pair I can't just init the pair in the constructor because if I use a number that's already used it will retroactively change colors of different already created windows and I just can't seem to figure out a nice, sleek way of handling it
#Getting rid or working around global mutable state in ncurses TUI program
10 messages · Page 1 of 1 (latest)
When your question is answered use !solved to mark the question as resolved.
Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question run !howto ask.
Can you not just make a global counter to ensure you never use the same value twice?
I read that you get 32k values, so you'll probably not run out unless you generate colors in a loop.
I could just make a counter like that and increment it every time I construct an object of the wrapper type but that honestly feels very iffy, I know that interactions between C and C++ sometimes just have to have rough edges like that but I just wanted to ask if a cleaner solution is possible
What would you consider cleaner?
You could keep an object around for the color that remembers its number and add it to a free list upon destruction, ready to be reused. I don't think that is an improvement unless you run out of numbers.
The perfect solution would obviously be getting rid of the global color pair identifiers tracker but I'm pretty sure that's not possible without rewriting ncurses
That kinda seems ok, if I allocate a window every time a user clicks a new window in the gui, and I let multiple users use the same resources as I planned at the beginning I actually might run out of numbers, thanks for the idea
@quartz bloom Has your question been resolved? If so, run !solved :)