If you have a counter that gets incremented through multiple functions, is it better to use a global counter or pointer counter? They both work just curious which is better and why.
My work is mostly on commercial apps now. No more code goes to professors so if it works, it usually ships. This doesn't mean I'm lazy or won't make a choice about long term support but it also means if we can't tell a difference, then that code is committed and locked down.
We found we had to lock down since a few team members were diving into working areas without a reason other than they thought they could optimize or refactor. For the current group, it's all about the money. We upset those that don't like locked down code that isn't formatted the way they like. In fact we lost a team member that wanted to open closed areas just to beautify the code. Nope, not happening. Working code, tested code, committed and done.
Do take a read of this post: https://www.daniweb.com/community-center/threads/517865/excellent-article-on-the-current-state-of-software
Now we do watch out for piggy or slow areas as well as code that others can't figure out how it works.
They are both, when you come down to it, the same not very good way to do this. The counter does not have to be a global (or a pointer) and it shouldn't be a global (or a pointer) because there are too many ways for the value to get stepped on. What I would do is to make the counter a class, a simple class, that has at least three methods: increment, read value, and reset. The counter itself would be an instance variable of the class. You also might want to think about concurrency, that is, what if two threads call the class at the same time? Check into semaphores. It might not be a problem you have to worry about but I think it is a problem you have to at least think about.
Using a class also gives you a chance to find out who is diddling with the counter. You can set a breakpoint in the class and then look at the call stack.
My personal preference would be to use a global (and document it well). It's the most straightforward and simplest way. Creating a class for a simple counter or throwing pointers around helter-skelter just muddies things up. If you wanbt an analogy, purists say that you should never ever use a goto or have multiple returns in a sub, however, sometimes using a goto or a multiple return can be the clearest way to program something, to wit (forgive the vb syntax, my C is a little rusty)
Private Sub MySub(parameter list) if some conbdition then exit sub if some other condition then exit sub if some third condition then exit sub actual useful code End Sub
You get the idea. Rather than have a bunch of nested ifs, just put all the "don'ts" at the top. This would likely cost you points on a class assignment but I think most maintenance programmers (I was one for 30 years) would thank you.