C++ language updates / old C++ code
-
Hi there, i have a question regarding C++ "language updates", to phrase properly what i want to know: We currently have an external employee that codes C++ Libraries for us, which are used for "drivers" to ensure communication via Ethernet, USB and Bluetooth. Those libraries are currently only available as 32 Bit dll's and therefore created a discussion after we found out that in some cases we would as well need them as 64 Bit. To get to the point, said collegue also mentioned, that those libraries are ensuring a downwards compatibility to run on systems below windows 10 (which is our current limit of support), namingly they run even on Windows XP and probably further down, written with VS 2005 iirc. Since i am .NET developer i can not really grab the necessity for doing so, nor estimate the potential "risks, flaws or performance" related topics comming up with that compatibility. So i want to ask you if my concerns are correct or totally wrong, when it comes to using "very old" C++ instead of modernizing it and only ensuring runtime compatibility to "current" OS'es. I personally feel that, since C++ get's updated every now and then, there must be a reason for doing so, as well as ofc improving the final produce that get's spit out by the compiler if your using newer (not newest) C++ Versions. As a bonus, if someone could take the time to answer this as well, would you suggest, think about or deny switching code parts into C# and .NET which probably could be switched due to framework functionalities where we can rely on the stuff microsoft already has built in there? As a note: We leave aside the fact that nobody else from the team would have hardware to continue coding or even compile this old stuff. In any case, thanks alot for reading and / or answering.
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found"); -
Hi there, i have a question regarding C++ "language updates", to phrase properly what i want to know: We currently have an external employee that codes C++ Libraries for us, which are used for "drivers" to ensure communication via Ethernet, USB and Bluetooth. Those libraries are currently only available as 32 Bit dll's and therefore created a discussion after we found out that in some cases we would as well need them as 64 Bit. To get to the point, said collegue also mentioned, that those libraries are ensuring a downwards compatibility to run on systems below windows 10 (which is our current limit of support), namingly they run even on Windows XP and probably further down, written with VS 2005 iirc. Since i am .NET developer i can not really grab the necessity for doing so, nor estimate the potential "risks, flaws or performance" related topics comming up with that compatibility. So i want to ask you if my concerns are correct or totally wrong, when it comes to using "very old" C++ instead of modernizing it and only ensuring runtime compatibility to "current" OS'es. I personally feel that, since C++ get's updated every now and then, there must be a reason for doing so, as well as ofc improving the final produce that get's spit out by the compiler if your using newer (not newest) C++ Versions. As a bonus, if someone could take the time to answer this as well, would you suggest, think about or deny switching code parts into C# and .NET which probably could be switched due to framework functionalities where we can rely on the stuff microsoft already has built in there? As a note: We leave aside the fact that nobody else from the team would have hardware to continue coding or even compile this old stuff. In any case, thanks alot for reading and / or answering.
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");This is really a broad topic. I am only able to just write down few observations.
C++language updates are not bug-fixes: they improve the language. If you are going to start from scratch a new project then using modernC++is a real advantage. On the other hand, migrating an old big (working) project could be painful. If you need a64bit DLL, you colleague could probably build it without using newestC++features. Maybe he can, at the same time, keep the existing32bit DLL, two builds of the same code. If Microsoft provides me the same functionality my mates code do, by no means I would continue using the latter. Does the compatibility argument applies also to your.NETcode? I mean,DLLcompatibility with oldOSs is useless if you cannot run the application on such systems. My two cents."In testa che avete, Signor di Ceprano?" -- Rigoletto
-
Hi there, i have a question regarding C++ "language updates", to phrase properly what i want to know: We currently have an external employee that codes C++ Libraries for us, which are used for "drivers" to ensure communication via Ethernet, USB and Bluetooth. Those libraries are currently only available as 32 Bit dll's and therefore created a discussion after we found out that in some cases we would as well need them as 64 Bit. To get to the point, said collegue also mentioned, that those libraries are ensuring a downwards compatibility to run on systems below windows 10 (which is our current limit of support), namingly they run even on Windows XP and probably further down, written with VS 2005 iirc. Since i am .NET developer i can not really grab the necessity for doing so, nor estimate the potential "risks, flaws or performance" related topics comming up with that compatibility. So i want to ask you if my concerns are correct or totally wrong, when it comes to using "very old" C++ instead of modernizing it and only ensuring runtime compatibility to "current" OS'es. I personally feel that, since C++ get's updated every now and then, there must be a reason for doing so, as well as ofc improving the final produce that get's spit out by the compiler if your using newer (not newest) C++ Versions. As a bonus, if someone could take the time to answer this as well, would you suggest, think about or deny switching code parts into C# and .NET which probably could be switched due to framework functionalities where we can rely on the stuff microsoft already has built in there? As a note: We leave aside the fact that nobody else from the team would have hardware to continue coding or even compile this old stuff. In any case, thanks alot for reading and / or answering.
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");If you switch to 64 bits, you need to update the whole thing, including external libraries. IMO, it's not worth it to convert to 64 bits unless you have real reasons for it (large datasets, hardware requirements... )
HobbyProggy wrote:
We leave aside the fact that nobody else from the team would have hardware to continue coding or even compile this old stuff.
lol. At that point, it's more a business decision than a technical decision. Your company needs to decide if they want to spend money maintaining old code on old compilers or move everything to a recent compiler and making sure everything is continuously up to date Good luck.
CI/CD = Continuous Impediment/Continuous Despair
-
Hi there, i have a question regarding C++ "language updates", to phrase properly what i want to know: We currently have an external employee that codes C++ Libraries for us, which are used for "drivers" to ensure communication via Ethernet, USB and Bluetooth. Those libraries are currently only available as 32 Bit dll's and therefore created a discussion after we found out that in some cases we would as well need them as 64 Bit. To get to the point, said collegue also mentioned, that those libraries are ensuring a downwards compatibility to run on systems below windows 10 (which is our current limit of support), namingly they run even on Windows XP and probably further down, written with VS 2005 iirc. Since i am .NET developer i can not really grab the necessity for doing so, nor estimate the potential "risks, flaws or performance" related topics comming up with that compatibility. So i want to ask you if my concerns are correct or totally wrong, when it comes to using "very old" C++ instead of modernizing it and only ensuring runtime compatibility to "current" OS'es. I personally feel that, since C++ get's updated every now and then, there must be a reason for doing so, as well as ofc improving the final produce that get's spit out by the compiler if your using newer (not newest) C++ Versions. As a bonus, if someone could take the time to answer this as well, would you suggest, think about or deny switching code parts into C# and .NET which probably could be switched due to framework functionalities where we can rely on the stuff microsoft already has built in there? As a note: We leave aside the fact that nobody else from the team would have hardware to continue coding or even compile this old stuff. In any case, thanks alot for reading and / or answering.
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");As another has pointed out, the changes to C++ are mostly language extensions. For example, before C++-11, there was no
autoor rangedforloops. Some of the language updates do address some defects in the standard, either clarifying the language or addressing a corner case. Two things stand out: 1) going from 32 bit to 64 bit is rarely as simple as just changing the compiler flags. You may find that, particularly if you need to access hardware, you need to adjust data types. For example alongis 4 bytes in 32 bit land, but 8 bytes in 64 bit land, and if you're using structs you may need to adjust padding. 2) You seem to have a "key man" reliance. Worse, the key man is an external entity. Hopefully, you have an escrow arrangement so that in extremis, you're not in the situation where you have to stat from scratch. It's not clear why the libs should need to be compatible with older versions of Windows. One reason might be is that the entity providing the library has other clients that need it. If you're the only client, then it might be time to review the deliverables, and update contracts/expectations accordingly."A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
Hi there, i have a question regarding C++ "language updates", to phrase properly what i want to know: We currently have an external employee that codes C++ Libraries for us, which are used for "drivers" to ensure communication via Ethernet, USB and Bluetooth. Those libraries are currently only available as 32 Bit dll's and therefore created a discussion after we found out that in some cases we would as well need them as 64 Bit. To get to the point, said collegue also mentioned, that those libraries are ensuring a downwards compatibility to run on systems below windows 10 (which is our current limit of support), namingly they run even on Windows XP and probably further down, written with VS 2005 iirc. Since i am .NET developer i can not really grab the necessity for doing so, nor estimate the potential "risks, flaws or performance" related topics comming up with that compatibility. So i want to ask you if my concerns are correct or totally wrong, when it comes to using "very old" C++ instead of modernizing it and only ensuring runtime compatibility to "current" OS'es. I personally feel that, since C++ get's updated every now and then, there must be a reason for doing so, as well as ofc improving the final produce that get's spit out by the compiler if your using newer (not newest) C++ Versions. As a bonus, if someone could take the time to answer this as well, would you suggest, think about or deny switching code parts into C# and .NET which probably could be switched due to framework functionalities where we can rely on the stuff microsoft already has built in there? As a note: We leave aside the fact that nobody else from the team would have hardware to continue coding or even compile this old stuff. In any case, thanks alot for reading and / or answering.
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");HobbyProggy wrote:
to ensure communication via Ethernet, USB and Bluetooth.
As described all of those currently exist without customization. One might also wonder if this custom stuff is secure. Specifically how is be being tested to insure that it is secure and will remain so.
HobbyProggy wrote:
windows 10 (which is our current limit of support)
Windows 10 runs on 64 bit systems but it also runs on 32 bit systems.
HobbyProggy wrote:
We leave aside the fact that nobody else from the team would have hardware to continue coding or even compile this old stuff.
Presumably the company at least has the source code. And yes there are risks to the company in not insuring continuity in case there are problems.
-
This is really a broad topic. I am only able to just write down few observations.
C++language updates are not bug-fixes: they improve the language. If you are going to start from scratch a new project then using modernC++is a real advantage. On the other hand, migrating an old big (working) project could be painful. If you need a64bit DLL, you colleague could probably build it without using newestC++features. Maybe he can, at the same time, keep the existing32bit DLL, two builds of the same code. If Microsoft provides me the same functionality my mates code do, by no means I would continue using the latter. Does the compatibility argument applies also to your.NETcode? I mean,DLLcompatibility with oldOSs is useless if you cannot run the application on such systems. My two cents."In testa che avete, Signor di Ceprano?" -- Rigoletto
Thanks for the answers, that lit up some dark corners for me. His proposal is to do simply convert the necessery stuff for 64 bit aswell so he'll provide both for us, not changing or modernizing anything. That's what i would have guessed, an example given, we have code for BLE communication in such a library, i know that Microsoft API or respectivly .NET has a lot of Code and Features provided for BLE communication. SO my idea was, since he knows both worlds, to take the effort and convert to .NET, at least the things that are possible, he wasn't happy... No, i hope i mentioned it but our application is bound to another external application that standardises things. Therefore we are only supporting Win 10 and 11 because said "Frame Application" is only running on those two. Thanks again for your answer :)
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found"); -
As another has pointed out, the changes to C++ are mostly language extensions. For example, before C++-11, there was no
autoor rangedforloops. Some of the language updates do address some defects in the standard, either clarifying the language or addressing a corner case. Two things stand out: 1) going from 32 bit to 64 bit is rarely as simple as just changing the compiler flags. You may find that, particularly if you need to access hardware, you need to adjust data types. For example alongis 4 bytes in 32 bit land, but 8 bytes in 64 bit land, and if you're using structs you may need to adjust padding. 2) You seem to have a "key man" reliance. Worse, the key man is an external entity. Hopefully, you have an escrow arrangement so that in extremis, you're not in the situation where you have to stat from scratch. It's not clear why the libs should need to be compatible with older versions of Windows. One reason might be is that the entity providing the library has other clients that need it. If you're the only client, then it might be time to review the deliverables, and update contracts/expectations accordingly."A little song, a little dance, a little seltzer down your pants" Chuckles the clown
Thanks for that. Yep, i just started there quite fresh as well but it seems i am, because of the tasks i was assigned to, the one that finally starts to clean up some old things. And yes, it'll be fun if something unexpected happens. I'll keep the last bit in mind and will address this task to my superior.
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found"); -
If you switch to 64 bits, you need to update the whole thing, including external libraries. IMO, it's not worth it to convert to 64 bits unless you have real reasons for it (large datasets, hardware requirements... )
HobbyProggy wrote:
We leave aside the fact that nobody else from the team would have hardware to continue coding or even compile this old stuff.
lol. At that point, it's more a business decision than a technical decision. Your company needs to decide if they want to spend money maintaining old code on old compilers or move everything to a recent compiler and making sure everything is continuously up to date Good luck.
CI/CD = Continuous Impediment/Continuous Despair
Thanks, i may need that :~ To answer your first statement, it is required for us to support 64bit and 32Bit, with .NET it's easy -> Compile for Any CPU and done. I know it's more complicated in C++.
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found"); -
HobbyProggy wrote:
to ensure communication via Ethernet, USB and Bluetooth.
As described all of those currently exist without customization. One might also wonder if this custom stuff is secure. Specifically how is be being tested to insure that it is secure and will remain so.
HobbyProggy wrote:
windows 10 (which is our current limit of support)
Windows 10 runs on 64 bit systems but it also runs on 32 bit systems.
HobbyProggy wrote:
We leave aside the fact that nobody else from the team would have hardware to continue coding or even compile this old stuff.
Presumably the company at least has the source code. And yes there are risks to the company in not insuring continuity in case there are problems.
jschell wrote:
As described all of those currently exist without customization. One might also wonder if this custom stuff is secure. Specifically how is be being tested to insure that it is secure and will remain so.
Yep... Uhm ... exactly one of the first things i was asking when i heard that, on the plus side i was able to read the whole BLE traffic with a sniffer when i was asked to measure and verify time needed for updates over ble.
jschell wrote:
Windows 10 runs on 64 bit systems but it also runs on 32 bit systems.
Yep, i should have mentioned we need both.
jschell wrote:
Presumably the company at least has the source code. And yes there are risks to the company in not insuring continuity in case there are problems.
:~ I am also asking the question because i want to ensure that we will not be screwed if something funny happens. All the info will be used to lay out a plan and strategy to not fall off the edge.
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found"); -
jschell wrote:
As described all of those currently exist without customization. One might also wonder if this custom stuff is secure. Specifically how is be being tested to insure that it is secure and will remain so.
Yep... Uhm ... exactly one of the first things i was asking when i heard that, on the plus side i was able to read the whole BLE traffic with a sniffer when i was asked to measure and verify time needed for updates over ble.
jschell wrote:
Windows 10 runs on 64 bit systems but it also runs on 32 bit systems.
Yep, i should have mentioned we need both.
jschell wrote:
Presumably the company at least has the source code. And yes there are risks to the company in not insuring continuity in case there are problems.
:~ I am also asking the question because i want to ensure that we will not be screwed if something funny happens. All the info will be used to lay out a plan and strategy to not fall off the edge.
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found"); -
Thanks for the answers, that lit up some dark corners for me. His proposal is to do simply convert the necessery stuff for 64 bit aswell so he'll provide both for us, not changing or modernizing anything. That's what i would have guessed, an example given, we have code for BLE communication in such a library, i know that Microsoft API or respectivly .NET has a lot of Code and Features provided for BLE communication. SO my idea was, since he knows both worlds, to take the effort and convert to .NET, at least the things that are possible, he wasn't happy... No, i hope i mentioned it but our application is bound to another external application that standardises things. Therefore we are only supporting Win 10 and 11 because said "Frame Application" is only running on those two. Thanks again for your answer :)
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");