Meadville Space Center
Welcome, Guest. Please login or register.
October 26, 2020, 07:19:28 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  Deprecated CRT
« previous next »
Pages: [1] Print
Author Topic: Deprecated CRT  (Read 5735 times)
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« on: April 15, 2008, 11:57:27 PM »

I know that we are somewhat tied to deprecated CRT functions by Orbiter's API.  There is however no reason why we should allow ourselves to remain tied to them in our own code.  If you want to maintain backwards compatibility with VC6 there is another way (though frankly, at this point, the necessity of such is beyond my comprehension).

I propose a complete cleanup of existing code, and a modification of coding practice for future code to minimize these problems.

The cleanup steps:
  • Replace ALL deprecated methods with up to date counterparts.  This means quit using CRT_SECURE_NO_DEPRECATE where it isn't needed.  In the case of security related functions, this can be done by instead defining _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1.  There is no need to use unsecure methods when the secure ones are just as easy to reach.  I understand that Orbiter API will continue to use the older methods.  That shouldn't cause us to.  The listed macro will use secure methods wherever possible and is completely compatible with C++ 2003+
  • Start using _stricmp (or better yet, strnicmp with the overload macro).  Where we do that, define a macro that, in the case of not bieng 2003 or later, it redefines that as stricmp.  Do this with all deprecated posix methods (though, I think that is the only one at this time).
  • Start coding header files to include their own dependencies, instead of relying on the cpp files to do so for them.  This is a major flaw right now, as our header dependence scheme is somewhat complex, and NOT properly handled by our existing headers.

This is not going to be a small project, but it's one that I think needs to be done.  New features are great and all, but keeping the quality of the code up is also important.  A thousand new features that make it difficult to impossible for people down the road to step in... that's not helping us in the long run.  Header files should be defining includes required for the header file to be included.  They should NOT be defining includes required only by the cpp file.  Each file should be including files it needs, not relying on other files to do that for it.

As to the secure and posix deprecation.  I think that a notice was missed among some people here, we aren't aiming to build a complete simulation out of limited tools, we're aiming to build a complete simulation out of the best tools that are available, and if those tools are secure and updated versions of existing methods, we should be using those, at least in compilers that are capable of it.

I apologize in advance if this is stepping on some toes, but there is only so long that I can, as a semi-pro coder, continue to work with bad programming practices before stepping up and saying something.  For myself, I've had to put the checklist MFD on hold while I approach this flaw.  I cannot bring myself to finish that when everytime I hit compile I get 180 warnings and everytime I make a new cpp file, I have to fight with the include statements until I find the ones that work.

When I have solved these problems, I will finish the checklist MFD code.  If that means we wait another week for a beta release, so be it.  I'm tired of working with these warnings.  I'm especially tired of working with warnings generated by people putting in extra crt_secure_no_deprecate definitions.  I'm cleaning up as many of those as I can, but there are other practices that need to be considered.

Now, all that being said, considering the very radical nature of these changes, I'm not going to just do them.

I posted this with the hope that people will weigh in with their opinions and make themselves heard on this subject, one way or another.  Tschachim, I know this discussion started in the Checklist MFD thread, but it needed it's own thread in my opinion, so I started this one.  I'd like to know people's opinion, and WHY before I go anywhere with this.  If it comes down to using the no deprecate macros, I will accept that, but I'd like to avoid them if possible.  If someone has a problem with cleaning up the headers, let me know.  Otherwise, again, I'll fix them up so they have the proper dependencies.
« Last Edit: April 16, 2008, 12:02:51 AM by lassombra » Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #1 on: April 16, 2008, 08:34:37 AM »

If you want to maintain backwards compatibility with VC6 there is another way (though frankly, at this point, the necessity of such is beyond my comprehension).

Because Orbiter itself is compiled with VC6. There's already one dll in the base installation (a Saturn or Jupiter moon), which was built with VS2003 and that causes a lot of problems for various users, the infamous "black sky" bug for example. But as far as I know Martin is going to switch to VS2005, probably already for the next version, and then I'll stop bothering everybody with VC6...  Wink

EDIT: But I have no problem with some clean up and I just checked the VC6 documentation, it looks like these _strxxx functions are already there, so please go ahead, I'll fix any problems with VC6 on my side. But please also start with / re-convert the 2005 project files to get rid of the "marco redefinition" warnings!

Cheers
Tschachim
« Last Edit: April 16, 2008, 08:53:49 AM by Tschachim » Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #2 on: April 16, 2008, 10:43:29 AM »

Tschachim, I did do the reconvert, the redefinition problems are still there.

Part of the problem is that, with each new compiler comes new quirks.

I'll see what can be done about them.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #3 on: April 16, 2008, 11:00:57 AM »

Tschachim, I did do the reconvert, the redefinition problems are still there.

Ah OK, sorry. In VS2005 this problem was caused by the fact that _CRT_SECURE_NO_DEPRECATE was defined both in the project files and in the code (orbitersdk.h), and throwing it out of the project files solved it. I get only a couple of warnings with VS2005, most of them in the AGC and some in BasicExcel, which would be easy to solve, no CRT warnings at all, so I thought perhaps VS2008 is similar enough. Anyway, I can understand that you don't want to get hundreds of warnings in VS2008 (exactly because of this I changed the now CRT warning free VS2005 stuff)!

Cheers
Tschachim
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #4 on: April 16, 2008, 11:27:04 AM »

Well, in several files it is defined multiple times in the code...  Or at least, it was...

Either way, I think that _CRT_SECURE_NO_DEPRECATE shouldn't be used if it doesn't have to be.  We should be finding our way around it if at all possible.

The _CRT_NOSTDC_NO_DEPRECATE I'm less against, though again, there are some significant enhancements to the methods in the newer versions (otherwise they wouldn't be deprecated, really)  The reason for deprecating and not just enhancing is that most of them need some kind of new argument or different arguments to be the most efficient.

Anyways, I've got the errors down a bit now with only a few changes (no actual code, just headers at this point) and I'll keep working.  I'd like to see all of our warnings go away (if that means we have to specify that a specific warning is not relevant for the code that is throwing it for the agc/ags, then fine.  I had to do that in the checklistController anyways, something about defining a bunch of stuff related to basicexcel and never using any of it).
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #5 on: April 16, 2008, 12:03:42 PM »

Well, a lot of the warnings are gone, mostly using file specific warning ignore messages.  If you are going to be modifying those files, it'd be a good idea to mind those specific warning ignore pragmas.  Perhaps removing them would be the best idea if you are modifying the file, and then, only when you know they are not a problem put them back in as some of these warnings are completely valid warnings, the use of them stemming from the fact that we simply can't use a standard piece of code, we have to use code compatible with all 3 vs versions.

On that note, some of the warnings popping up are linker warnings concerning a default library.

I think I remember seeing those warnings in VS2005 as well.  The thing is, I don't have 2005 installed at the moment, so I don't have an easy way to update those project files.  If someone could update the following 2005 project files to include LIBCMT in the ignore section of the linker options, that'd be great:

LC34
sm
s1c
VAB
LEVA
Saturn1B
LEM
MSS
ML
LRV
Crawler

[EDIT: Never mind on that, it seems that the 2005 files ARE correct, and for some reason, when I converted, it DROPPED the LIBCMT from the ignore listing on  those projects.  It didn't drop them on some others.  Strange, but I'm fixing now.]
« Last Edit: April 16, 2008, 12:10:34 PM by lassombra » Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #6 on: April 16, 2008, 12:57:44 PM »

Ok, we're done to 41 warnings Happy

At this point, all remaining warnings are code related (not header files or anything like that) so I'm going to hold off on fixing them until we have the final call on what to do about the _crt_secure_no_deprecate  If we can pull off not using it, I'd like to.

In the meantime, I'm going to clean up our includes so that header files include their own dependencies.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #7 on: April 17, 2008, 02:25:59 AM »

Ok, I've created a wrapper header file for Orbitersdk.h  I don't want to make changes to Orbitersdk.h as those, obviously, cannot be placed in our source tree.  (Hence the reason tschachim threw in a million and one #pragma commands throughout our code, as Orbitersdk.h is NOT by default compatible with basicexcel in vc6...    Bangs Head)

Anyways, the point of this wrapper is to simply contain a few special defines, pragmas, and such, to make our CRT_SECURE_NO_DEPRECATE problem something we actually work with.

CONCEPT: The following paragraph is not intended to indicate actual changes to coding practice but concept changes:
If you are writing code that NEEDS to deprecate (for VC6 compatibility) please TRY to use the aliases I'm going to be including in Nasspdefs.h.  If there isn't an alias defined, then go ahead and define FOR THAT FILE NASSP_NO_DEPRECATE before calling nassporbitersdk.h...

the nassporbitersdk.h I made implements this already, but please feel free to implement it in other ways if you think it should be done some other way.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #8 on: April 17, 2008, 05:04:08 AM »

Ok, I've created a wrapper header file for Orbitersdk.h  I don't want to make changes to Orbitersdk.h as those, obviously, cannot be placed in our source tree.  (Hence the reason tschachim threw in a million and one #pragma commands throughout our code, as Orbitersdk.h is NOT by default compatible with basicexcel in vc6...    Bangs Head)

Yeah, a wrapper certainly is better than my brute force hack!  Happy

Cheers
Tschachim
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #9 on: April 18, 2008, 03:33:19 PM »

... I've now managed to introduce more warnings than we had to start with...

I fail... Tongue

Anyways, this is turning into a bigger project than I thought it would.

Also, I'm trying to make all the header files self-dependent (so, theoretically, a file could just include it's own header, and go).

That is coming along nicely, so should be done soon enough.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!