Strategies to upgrade antiquated C and C++ code to some more modern coding practice.
-
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
referenceinstead of passing everything by pointers and useconstas 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
-
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
-
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? :rolleyes:
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.
-
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.
Quote:
do not touch a running system.
Good advice unless it has, or is causing, lots of bugs or hindering development.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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
referenceinstead of passing everything by pointers and useconstas 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
Introducing
constto 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 beenconst." And then giving up after lots of unexpected compile errors or deciding thatmutableshould be used far more sparingly.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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
referenceinstead of passing everything by pointers and useconstas 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
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.
-
Quote:
do not touch a running system.
Good advice unless it has, or is causing, lots of bugs or hindering development.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.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.
-
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
-
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
referenceinstead of passing everything by pointers and useconstas 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
have you measured for memory leaks ? if leaky code my advice replace malloc/free w/ the various smart pointers .
-
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
referenceinstead of passing everything by pointers and useconstas 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
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'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
referenceinstead of passing everything by pointers and useconstas 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
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.
-
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
referenceinstead of passing everything by pointers and useconstas 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
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
-
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
-
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
-
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
referenceinstead of passing everything by pointers and useconstas 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
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. - 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.
-
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
-
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
referenceinstead of passing everything by pointers and useconstas 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
-
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.
"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.
-
Where I work that would be cost prohibitive, because of the amount of V,V & T involved.
~d~
-
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
referenceinstead of passing everything by pointers and useconstas 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
Code does not rot. If it works it works. Only when it has or need to be interfaced with something new, does it need a rewrite. And by then he it may be better to write the function from scratch. Time is life. Are you willing to exchange life, yours or someone else, in order to change something that works for something that may or not work? That said in the rare occasions. Make sure you understand the requirements and don't go into change for the sake on change.Then change what needs to be changed.
