|
StarNamer@work wrote: I definitely think the Pfizer vaccination has more side effects as I had the AstraZeneca one before and had no side effects at all.
Of course, it could just be that I getting old... 
Not sure who's the older one between the two of us, but I had the initial Pfizer (BioNTech) shot and all the boosters since and didn't have any side effects, beside a bit of a sore upper arm for a couple of hours, but that was to be expected...
|
|
|
|
|
I know feeling awful like that sucks, but here's the positive side of it: it indicates you have a robust immune system.
I've been dealing with lymphoma for over 7 years now, and the worst aspect of the type I have is that it knocks my white count down, down, down. After not reacting to the 1st 2 shots and 2 boosters, the oncologist ordered a special blood test that revealed no antibodies. She explained that my crappy immune system just didn't react to the vaccines.
Given your reaction, it's likely you now have LOTS of antibodies
|
|
|
|
|
I think you are right, I just wish it wouldn't get quite so enthusiastic 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I'm deep into some antiquated C and C++ code (some here would say antediluvian )
I'd like to start instructing my team to clean up code as they go.
We have ton of low level libraries that cannot be easily updated (time and budget concerns)
And from what I can see, they work.
Do you know of any documents and/or white papers that discuss this particular topic ?
For now, I'm telling people to use reference instead of passing everything by pointers and use const as much as possible.
To at least indicate code intent.
I can't even use STL (string and vector) at this point. 
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Maximilien wrote: We have ton of low level libraries that cannot be easily updated (time and budget concerns)
And from what I can see, they work.
Then... the classic: do not touch a running system.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
(I have the source)
I could probably go in and wreak havok !!  
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Quote: do not touch a running system.
Good advice unless it has, or is causing, lots of bugs or hindering development.
|
|
|
|
|
Greg Utas wrote: Good advice unless it has, or is causing, lots of bugs or hindering development.
I agree with that specially the second part, but (big but) only if you have someone that knows what is going in the underwears... if not, leave it running and replace it by something new, taking care that the new is covering the same functionality before replacing and having a good backup (just in case).
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I don't see any bigger problems, as long you do not need to switch from 32 to 64 bit and there is pointer arithmetics involved in the code
Btw. 'const ref' vs. 'const pointers', I think it makes no big difference, but I can be wrong.
|
|
|
|
|
It's still a 32bit application.
The way I see it, we'll update to 128bit version before 64bit.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Update or re-write it? 
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Introducing const to a system that didn't use it, or used it haphazardly because some developers never bothered, can be quite the exercise. It's like trying to pull a shirt out of a dryer--the chain reaction can be quite messy. I've even gone down that rathole in code that I've written. "Hmm, this should probably have been const." And then giving up after lots of unexpected compile errors or deciding that mutable should be used far more sparingly.
|
|
|
|
|
You can't compartmentalize parts of it?
If you could then you create a different project/build and create a library from just that. Then the rest of the code uses that library (not the code.)
For maintenance you then decide whether to update the library (nothing else) or not. The API layer to the library would remain exactly the same during the primary update. You might update the API layer after that to make it more consistent.
|
|
|
|
|
Probably, but with difficulty.
I'm also trying to instill some modern techniques to the team without everyone going bonkers.
I'm looking for basic things that we need to do codewize to go forward into more modern ways of coding.
There's also the cost/benefit that I need to take into account and demonstrate that to the higher authorities at some point.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
have you measured for memory leaks ? if leaky code my advice replace malloc/free w/ the various smart pointers .
|
|
|
|
|
I am also working in an old C++ MFC project that was developed in the late 90's. I am using Reshaper from JetBrains. It gives a lot of suggestions when looking at old C++ code. Adding a 'const' shows up a lot. It includes a lot of suggestions to use the newer memory/string functions that require providing the buffer size. I don't take all of it's suggestions since the code is very reliable.
|
|
|
|
|
I have done this many times, doing it now for my current company. Old C code from the early 90s written to run on another OS (embedded) tweaked and tweaked into unmaintainability extreme.
At the end of each phase the programming should produce exactly the same output/changes.
My description here is for C, what I am working on now; it will work for any language(s).
Phase 1 - find and deal with global variables. This is a judgement call as some things are properly global, some are just laziness on the part of some programmer. One tactic, make a structure, move them there to get them all organized. Refer to the globals only as part of the structure and pass only pointers to the structure. Control, you want to get control of the globals or at least make it clear where they are getting changed.
In C/C++ a function that gets the structure read only will be "const", if it changes a value then not const, get it?
Phase 2 - find duplicate (or near duplicate) code and create functions or subs to perform. Replace this code with calls. I call this "mining functions', you are digging them out of the code. Repeat till there are not more easy targets to mine. You can repeat this later in the process.
Phase 3 - now look for unexecutable code - in large systems there will often be some. In the system I am working on now there were subs that never get called, functions that got called but the return values were ignored or tossed away. These really were changing global variables - that would be discovered in Phase 2, right?
Phase 4 - look for bad algorithms and processes. for loops, while loops are the first targets.
Repeat until you've done enough.
Each phase makes it easier to see what to do int the next.
|
|
|
|
|
Thanks.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
"some are just laziness on the part of some programmer"
your post is excellent advice and I suspect you have scars
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Michael Feathers wrote a great book "Working with Legacy Code" for exactly this.
Step 1: wrap anything you are going to change in tests so you know what it does now and can ensure it continues to do that after your changes...
Step 2...whatever is necessary to fix problems you are having.
The strangler fig pattern can be helpful - gradually wrap/replace sections until the whole codebase has been replaced, like a strangler fig strangling a tree.
Ian
|
|
|
|
|
Thanks for the book reference.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
yeah, what he said. I was lazy and didn't bother to scroll to the bottom.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Changing pointers to references may have very interesting consequences. Before I'd be making API changes like that, I would want a solid set of test cases to prove I hadn't broken anything.
<sigh> - glancing at project on new laptop with 20 year old mfc code and limited comments.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Where I work that would be cost prohibitive, because of the amount of V,V & T involved.
~d~
|
|
|
|
|
ah yes IVV. The best job I despised.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
