programming

258 readers

3 users here now

Post about programming, interesting repos, learning to program, etc. Let's try to keep free software posts in the c/libre comm unless the post is about the programming/is to the repo.
Do not doxx yourself by posting a repo that is yours and in any way leads to your personally identifying information. Use reports if necessary to alert mods to a potential doxxing.
Be kind, keep struggle sessions focused on the topic of programming.

founded 2 years ago

MODERATORS

Llituro@hexbear.net

git@hexbear.net

Saoirse@hexbear.net

Global variables, yes or no? (hexbear.net)

submitted 2 weeks ago by zongor@hexbear.net to c/programming@hexbear.net

15 comments fedilink hide all child comments

If they didn’t exist in a language would you be upset? Any obvious things that can’t be done without global variables? I don’t think there is, but I could have missed something. I know that Haskell doesn’t have them and I think some newer ones like V also don’t have them.

you are viewing a single comment's thread
view the rest of the comments

[–] zongor@hexbear.net 8 points 2 weeks ago (1 children)

Global constants make a lot of sense, those could be easily copied to where they need to go at compile time. The issue I’m having is that, if I allow global dynamic variables then it means having to allocate some sort of table or block for the global variables and if they can allocate more at runtime or even worse they try allocating strings or arrays at runtime memory will fragment and become a mess quickly

[–] invalidusernamelol@hexbear.net 4 points 2 weeks ago* (last edited 2 weeks ago)

I will sometimes create a global caching object, but I typically program in Python, so having the cache allocated ahead of time isn't a big deal.

Even so I usually put a limit on the global cache unless I know exactly how big it's gonna be. I have a pretty large automation suite that requires tool scripts to be instantiated, and that initialization for each tool object can take up to 10 seconds. The system that runs the scripts is constantly creating and destroying the tool objects, so I had to cache them and hijack the init method to pull from a global cache or it would take up to a minute for the toolbox to load.

Since the initialized information (database connections and schema maps) is unlikely to change during a session, it was a good tradeoff.

As others said, global constants are totally fine. Especially for anything that requires authentication. I usually assign them on startup by pulling from either a config file or system environment variables.

Python also heavily relies on globals for logging, which is unavoidable if you want to use standard lib and also do logging.