Code Cleanup

Development directions, tasks, and features being actively implemented or pursued by the development team.

Code Cleanup

Postby Roy » Thu Sep 19, 2019 10:18 am

I've started a little bit of code cleanup.
A few modest objectives:
- get rid of IDE warnings (clang?)
- get rid of make warnings
- refactor code to modern C++ standards 14/17
- write a few unit tests
- maybe a mock or two
- when compilers add modules support, refactor to use modules

For example, I refactored the following:
Code: Select all
unsigned long length = static_cast<unsigned long>(f.Size());
                if (length > 0) {
                    char *temp = static_cast<char*>(malloc( length+1));
                    temp[length] = '\0';
                    f.Read( temp, length );
                    bool  end  = true;
                    for (int i = static_cast<int>(length-1); i >= 0; i--) {
                        if (temp[i] == '\r' || temp[i] == '\n')
                            temp[i] = (end ? '\0' : '_');
                        else if (temp[i] == '\0' || temp[i] == ' ' || temp[i] == '\t')
                            temp[i] = (end ? '\0' : '_');
                        else
                            end = false;
                    }
                    *res = (temp);
                    free( temp );
                }
                f.Close();


to the following:
Code: Select all
const auto size = static_cast<const unsigned long>(f.Size());
                if(size > 0) {
                    vector<char> file(size, 0);
                    auto filePointer = reinterpret_cast<char*>(&file[0]);
                    f.Read(filePointer, size);
                    auto end = true;

                    for (auto it = file.rbegin(); it != file.rend(); ++it) {
                        switch(*it) {
                        case '\r':
                        case '\n':
                        case '\0':
                        case '\t':
                        case ' ':
                            *it = end ? '\0' : '_';
                            break;
                        default: end = false;
                        }
                    }
                }

                f.Close();


I understand the dev team is somewhat unavailable, but would like some input on whether this is welcome and any inputs they may have.
I can also fork the project, if the devs don't feel comfortable giving me access to the repository.

Roy
Roy
Star Pilot
Star Pilot
 
Posts: 7
Topics: 2
Joined: Thu Sep 12, 2019 2:54 pm

Share On:

Share on Facebook Facebook Share on Twitter Twitter Share on Digg Digg

Re: Code Cleanup

Postby loki1950 » Thu Sep 19, 2019 3:18 pm

It's not somewhat unavailable they most have moved on the project founders all have PhD's and the tenured positions that go with them so have no time for us at all.I will have to really look at what I can do re: GitHub not sure what prerogatives I have as I did not start it though was invited to join which I did.As for klauss who was the most active he's a cryptographer so is always busy with work.If you want to fork it's your call BTW the graphics code is also way out of date.

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
User avatar
loki1950
The Shepherd
 
Posts: 5753
Topics: 52
Joined: Fri May 13, 2005 1:37 pm
Location: Ottawa

Re: Code Cleanup

Postby the_mtn_who_glides » Thu Oct 03, 2019 11:09 am

@Roy, I can only speak for myself, but I would be glad to have those changes merged into the main Vega Strike repo on GitHub.

How about going with C++14? I think this will strike a good balance between new features and backwards compatibility with slightly older Linux distros, etc.

Thoughts?
the_mtn_who_glides
Trader
Trader
 
Posts: 22
Topics: 2
Joined: Thu Aug 29, 2019 7:07 am

Re: Code Cleanup

Postby Roy » Mon Oct 07, 2019 1:24 pm

Obviously, had I waited a few days, I would have forked from github and not gone this route. However, the purpose was always for this fork to be a temporary thing - a way to gain knowledge of the code and and mercilessly cut with a machete without waiting for pull requests. I don't know how much you've looked at the code but it is challenging from an encapsulation point of view. It's very hard to make a change without breaking 50 other things.

If I can get anything of value developed (e.g. better upgrade code) I'll offer to remerge the code. The biggest obstacle to collaboration right now is that I have an overall code architecture in my head but can't use a second person without a lot more overhead then I can afford right now. I'm doing this after a full day in the office and time is at a premium.

If you are looking for something to do that wouldn't collide with my efforts, I suggest you take a look at either ogre or python. These are real tasks with real value (not grinding code cleanup), really interesting and something people here would appreciate. Leave boost alone. I just compiled with 1.67 without any changes to the code.

Regarding C++20/17 support, I think it would run fine on older machines. After all, the result should be x86 machine code. I think the problem is the libraries and supporting older machines is a real trade off between readable and correct code and reaching a wider base. I guess will figure this when we get to it.
Roy
Star Pilot
Star Pilot
 
Posts: 7
Topics: 2
Joined: Thu Sep 12, 2019 2:54 pm

Re: Code Cleanup

Postby loki1950 » Mon Oct 07, 2019 3:32 pm

Re: older machines has anyone seen a distro that is still supporting 32-bit. @Roy please work your way but do consider us a resource we maybe forced to upgrade Python to 3.0 but that will a major job as a minimal Python stub must be embedded into the main engine as it is the engine itself that runs the Python scripts not the system installed Python.I may not be a C++ coder but I am fairly well up on our source tree structure.Any effort to use Ogre will need major restructuring see the the Ogre branches ATM we do have an issue with an API change that broke mesher our cmd line mesh conversion tool two possible solutions drop conversion to .mesh(Ogre 3d mesh format) or update that function within mesher.

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
User avatar
loki1950
The Shepherd
 
Posts: 5753
Topics: 52
Joined: Fri May 13, 2005 1:37 pm
Location: Ottawa

Re: Code Cleanup

Postby Roy » Tue Oct 08, 2019 1:36 pm

Re: older machines - this is a confusing subject, so let me expand on it and apologies if you knew all this. 32/64 bit means a couple of things. The first is CPU but IIRC, 64 bit x86 always support 32 bit as well. Next comes the OS. You can have 32bit windows on a 64 bit CPU. Finally, there's the code you compile. On windows you can see two 'Program Files' folders. Even if this is an issue, we simply recompile for i386 (32bit) and it should work.
The problem with older machines is that the libraries are held in place and not upgraded. When libraries evolve, the API's change. That means the code get filled with all sorts of #ifdef directives and other ugly stuff. If you start upgrading libraries, you could wind up with a slower machine. It used to be a real issue but not sure how relevant it still is. More of an issue for Macs maybe.
I'm intentionally staying away from Ogre, the graphics engine and python. I'm focusing right now on units code. So far, it's not going well :)
Roy
Star Pilot
Star Pilot
 
Posts: 7
Topics: 2
Joined: Thu Sep 12, 2019 2:54 pm



Return to Engine Development

Who is online

Users browsing this forum: No registered users and 2 guests

cron