Geek Answers Handbook

C ++ Directory Restructuring

I have the source code for about 500 files in about 10 directories. I need to reorganize the directory structure - this includes changing the directory hierarchy or renaming some directories.

I am using svn version control. There are two ways to refactor: saving the svn history (using the svn move command), and the other without saving. I think that refactoring that preserves the svn history is much simpler using the eclipse CDT and SVN plugin (visual studio is not suitable for directory restructuring at all).

But right now, since the code is not released, we have the opportunity not to save the story.

However, the challenge remains to change the include directives for header files wherever they are included. I am thinking of writing a small script using python - it gets a map from the current file name to the new file name and renames it where necessary (using something like sed). Has anyone done such directory refactoring? Do you know about good related tools?

+6
c ++ refactoring
source share
3 answers

If you need to rewrite #include to do this, you did it wrong. Change all of your #includes to use a very simple directory structure at two levels in depth and only using the second level to organize around architecture or OS dependencies (e.g. sys/types.h ).

Then modify your make files to use -I include paths.

Voila. You won’t have to crack the code again for this, and the compilation will explode instantly if something goes wrong.

As for part of the story, it’s personally easier for me to start cleaning when doing this kind of thing; archive the old one, create a new v2 repository, go from there. Counter-regulation is when there are many changes in the history of changes or many open problems with existing code.

Oh, and you have good tests, and you don’t do this with the release right away, right?

+3
source share

I would keep the story, even if it requires a little extra time. There is great value in reading commit logs and understanding why function X is written in a weird way, or that it really is a mistake at a time, because it was written by Oliver, who always makes mistakes.

An argument against saving history can be made for the following users:

  • Your code can have embarrassing things, such as profanity and the struggle between developers.
  • you don’t need a history of fixing your code, because it will not change or will not be saved in the future

I did some directory refactoring, like last year, on our code base. If your code is reasonably structured at the beginning, you can do about 75-90% of the work using scripts written in your chosen language (I used Perl). In my case, we moved from a set of files to one large directory, to a number of subdirectories, depending on the namespaces. So, the file that declared the class protocols :: serialization :: SerializerBase was located in src / protocols / serialization / SerializerBase. Mapping from the old name to the new name was trivial, so doing a search and replacing with #includes in every source file in the tree was trivial, although that was a big change. There were some strange edge cases that we had to fix manually, but it was much better than either doing everything manually or writing our own C ++ parser.

+2
source share

Hacking a shell script to perform svn moves is trivial. In tcsh, this is foreach F ($ FILES) ... end to configure a set of files. Perl and Python offer the best utility.

It really is worth keeping a story. Especially when trying to track some kind of exotic mistake. Those who do not learn from history are doomed to repeat this, or some kind of trash ...

As for changing all the files ... The other day there was a similar question:

https://stackoverflow.com/questions/573430/ with-include-header-path-change-windows-on-linux / 573531 # 573531

+2
source share

More articles:


All Articles