Does anyone use build counters in their code?
I never did but I wanted to start and this is the one I came up with:
EDIT: Optimized slightlyCode: QB64: [Select]
Hi keybone,The _integer64 is there in case there ever if a time that it needs to be that big.... Just in case as unlikely as it would ever be, because i would rather waste 3 bytes then ever have to change it. Its future-proof.
2 comments (due to my ignorance of build numbers)
1. Wow! when I look at the unsigned _integer64 type you assigned to the function, expecting allot of builds?
2. Assuming you want to automate the call to buildCount~&&, when would that happen?
Actually, it seems that it would have to be called manually, so it would depend on human perfection to remember to update the number with a call, hmm...?
I think I am assuming these build counts are for bas file development? I could be completely off track.
Now I am wondering if the usefulness is worth the effort?
For me, when a bas file reaches a certain level of satisfaction, I bak it with date and time.
Am I completely off track with what build number is?
as far as usefulness goes, to each their own, its not really worth even thinking about, you might think its not useful but another person will...
Hi keybone,Quoteas far as usefulness goes, to each their own, its not really worth even thinking about, you might think its not useful but another person will...
Usually, if I don't see something as useful but ask, the person gives me a clue as to how they would use it, and then (usually) things makes sense to me.
It is very much worth it to me to see how the other person is thinking, I might learn something that comes in useful later on... who knows?
I confess I am still in dark as to how you would use this count? Is this counting code run every time you run the bas file or are running from a bas project manager file that oversees a bunch of bas and other files.
If these questions and comments are annoying, forget about it, my aim is to understand NOT annoy.
Thanks Keybone for going over it again, I've got it now (I think) what you are calling builds, I would call runs and now I understand the maximum type integer allowed. :D Ha! in a day I'd blunder my way to version 1 if that's 1000 runs.
Yes, Steve that is an interesting idea. Not sure I'd want to see that number? ;-))
I believe version numbers should be something that evolves consciously and the owner of the software should be able to judge when to change it. Automating the process sounds irresponsible.
I believe version numbers should be something that evolves consciously and the owner of the software should be able to judge when to change it. Automating the process sounds irresponsible.
Not really, if you think about it as two different things: version number vs. build number. Heck, even QB64 does something similar now, with version 1.0/1.1/1.2 and repository build 88/89/90... The programmer could still set a version number for their program, which would be completely separate from the automated build number.
I believe version numbers should be something that evolves consciously and the owner of the software should be able to judge when to change it. Automating the process sounds irresponsible.
I was thinking about this, and version numbers seem like they'd be something simple the precompiler could be expanded to handle easily enough.
$AUTOVER:ON|OFF <---- new precompiler flag which sets an internal variable. Run and compile and all it'd need do is increment that variable and self-edit that line to reflect the change.
Compile once, with the flag set, and it'd automatically become $AUTOVER:ON 1. Compile again and it becomes $AUTOVER:ON 2...
(Of course, if the flag was set off, it wouldn't alter or increment that variable.)
Tie that variable in as a set constant and then you can use it however you need in your program, such as: PRINT "Current build number #"; _VER
Should be a simple enough type fix, and it's one I'd do for us, if there'd be enough interest in that type of functionality.