MWEdit
- This topic has 328 replies, 2 voices, and was last updated 1 day, 5 hours ago by
.
-
Yep, changing the include order fixed it. Going to need to fix the rest of the places where it shows up. Give me a bit.
We’ll want to fix things up at some point to make sure that we don’t run into this problem again. The fix isn’t pretty but it’s a temporary solution until the refactoring is further along.
We’ll want to move the string functions to
common/dl_str.has they use symbols from that file.common/dl_base.hcannot include that file becausecommon/dl_str.hrequires symbols fromcommon/dl_base.hin order to function. I guess I could include it at the very end ofcommon/dl_base.h, though. Essentially, the work on the includes has exposed a couple of circular dependencies that were already in the code. This will take some time to fix. Messy, messy, messy.I’ll update the community threads when I get the chance
Okay, community threads have been updated 🙂
Got more details on the syntax highlighting bug that was mentioned in issue 10. Went ahead and added the screenshot and post link to help us keep track of it. It should get fixed when we overhaul the GUI 🙂
Okay, I just finished moving the macros from
common/dl_base.hto the proper files. Now I need to go through the entire codebase and correct all of the includes, making sure everything is where it needs to be.This is a downside to making heavy use of the preprocessor: it can cause conflicts due to how compilers work.
- The preprocessor runs, doing full text replacement in the order that things appear
- The compiler runs, converting everything into an AST and object code
- Code is linked together into a single unit
Ultimately, we’ll want to pare things down to limit the potential for bugs in the future. I don’t have an issue on the tracker but I did mention it sometime last year in the thread, it just hasn’t made it over to GitHub yet. Will get it added at some point.
I also need to go through and remove the boolean macros and swap them out for
bool,true, andfalse. Going to take a bit as the UI makes heavy use the macrosI’ve added a note about examining the icons as there seems to be several duplicates.
.icofiles can handle the PNG type but we’ll also want to see what’s supported by Linux and the GUI toolkit. It’s probably something that needs to wait.Still fixing up the circular dependencies and boolean types. Slowly making progress but progress is progress.
Playing around with the
cppcheckconfiguration some and this is what I’ve currently got for the settings:
cppcheck --enable=all -I . --inconclusive --language=c++ --library=mfc --library=microsoft_atl --output-file=cppcheck.log --platform=win64 --quiet .
I’m currently unsure about--cppcheck-build-dirbut it may be useful as well with--cppcheck-build-dir=.It doesn’t seem as though
cppchecksupports config files, which would be nice as we’ll need to ultimately run it against multiple platform configurations but that can be fixed by adding shell scripts to the repository if we feel that it would be helpful.--enable=allturns on all of the checks, including the ones not turned on by default-I .tells it to look for the include paths relative to the root directory--inconclusivetells it to turn on additional checks that it can’t necessarily confirm (useful for catching functions that use different parameters in the declaration and defintion)--language=c++ensures that headers are being parsed as C++ instead of C, which is important as sometimes very little C++ is used in headers so C is detected instead--library=mfcand--library=microsoft_atltells it to load the configuration files for dealing with MFC and the ATL stuff.--output-file=cppcheck.logsaves the run to a log file to make it easier to sift through--platform=win64tells it to load the configuration for Windows (which, as we know, differs from other, more standard compliant platforms) and to check to make sure everything is 64-bit compliant--quiettells it not to report anything in the terminal
I’ll update the threads soon with a progress update 🙂
All sub-records have their data blocks as global scope with the classes having to go back and forth. We may want to change that at some point to having class-based scope. Will need evaluation.
I don’t see a reason for them to be globals as the values will change for each sub-record in play so it all sounds rather inefficient but we’ll get there.
Working on the clean up. Several things are being caught so I’m fixing the stuff I missed. Some of the newer 64-bit functions are different so I’ve updated the variables for those as well. I’ve temporarily used
unsigned long longbut we’ll want to switch tostd::uint64_tonce we update the formatting strings, which will need to be done all at once as they’re different from the older form.I don’t think those functions are used anyways but I’m updating them just in case. I’ll make a tracker note to check for 64-bit compatibility to reduce the likelihood of an out of range issue
Once it starts building again, I can merge it back to the main repository and we can go from there. 🙂
We’re more than likely going to need to run cppcheck multiple times as more stuff will be caught as we fix other things. For example, removing unused functions will cause other functions that were only being used in those to be marked as unused. It should catch most things in the initial pass, though.
We’ll want to update the build files to tell MSVC not to enable warnings for system header files. See: https://learn.microsoft.com/en-us/cpp/build/reference/external-external-headers-diagnostics?view=msvc-170
GCC and CLang handle this better and don’t issue them for system headers by default.
I also need to update the build files to mark some libraries as system headers. Will get there, still trying to get the code-base building. Sorting through more error logs at the moment.
Some of the files are complaining about a lack of forward declarations for classes they use even though we’re including the headers that set up the classes. We’ll definitely need to figure out why these errors are occurring but I’m re-adding the forward declarations for now, temporarily, until we figure it out. I suspect it may have something to do with the over use of macros but I’m not entirely sure.
Thus far, the complaints about the lack of classes being declared are from files where I removed the forward declarations.
Edit:
Looking it over, it looks like it may be due to the classes they need also needing them so more circular dependencies. Not much we can really do about that, I’m afraid, other than forward declarations. At least, I think so. Best I can do is just add them where the compiler complains, I guess.
We can probably ignore the part of the macros messing it up as it doesn’t appear to be case in this instance. Not to say they aren’t problematic, though.
- You must be logged in to reply to this topic.