I have a large C++ code base that contains a couple of functions for error logging that I'm planning to rewrite, defined as follows;
void LogError(ErrorLevel elvl,LPCTSTR Format,...); // Literal version
void LogError(ErrorLevel elvl,UINT ResourceID,...); // Resource version
I'm planning to rewrite these as a single function
void LogError(ErrNo No,...);
ErrNo in this case is will be an enum, used to look up the rest of the error details from an external file. While I'm using and love Visual Assist, it doesn't appear to be up to this kind of thing. I'm thinking the easiest way to carry out this refactor is to write a small program that uses the results of a search output to find all the occurences of this function, e.g.
c:\cpp\common\Atlas\Comps\LSADJUST.cpp
LSAFormNormalEquations (174): LogError(elvl_Error,IDS_WINWRN0058,i+1,TravObs.setup_no,TravObs.round_no
LSAFormNormalEquations (180): LogError(elvl_Error,IDS_WINWRN0059,i+1,TravObs.setup_no,TravObs.round_no
LSAFormNormalEquations (186): LogError(elvl_Error,IDS_WINWRN0060,i+1,TravObs.setup_no,TravObs.round_no
c:\cpp\common\Atlas\Comps\LSADJUSTZ.CPP
LSAFormNormalEquationsZ (45): LogError(elvl_Note,_T("Adjusting heights by least squares"));
c:\cpp\Win32\Atlas\Section\OptmizeSectionVolumes.cpp
OnSectionOptimizeVolumes (239): LogError(elvl_Note,"Shifted section at chainage %0.1lf by %0.3lf",Graph.c1,Offset);
and then parse and modify the source. Are there any other tools that could simplify this task for me? If looked at a related question which suggets there isn't much out there. I don't mind spending a small amount for a reasonably easy to use tool, but don't have the time or budget for anything more than this.
If you were using Unix, using sed to edit all your source-code might handle most of the changes. You would have to complete some of the changes by hand. I have used this technique in the past.
Searching around for something light weight that met my needs drew a blank, and learning SED while worthwhile would have been a fair amount of work for something that did not quite solve my problem. I ended up writing my own tool to carry out the refactor needed on a seperate copy of the code base until I was happy that it was doing exactly what I needed. This involved taking the output from Visual Assists find all references option, and use it to refactor the code base. I'd post the code, but as it stands is pretty awful and would be liable to fail under a different code base. The general problem can be better stated as something like this
For a C++ code base, find every occurence of function fn taking parameters a,b,...n
Remove the occurence of fn from the source file
Extract the parameters as text variables
Add a few more variables such as instance number, source file name, etc...
At the point where fn was removed, write a formatted string that can include available variables
Append similar formatted strings to one or more external files (e.g. resource files etc...)
I'm guessing the above functionality would be easy enough to implement for someone who is already parsing the source, and will pass a link to this question to Whole Tomato as an enhancement suggestion.
Edit: For anyone interested, there's some follow up on the VA forum here.
Related
I would like to be able to automatically process a file with a regular expression and perform a more or less arbitrary action on the match contents. For my most recent need I would like to be able to find every instance of Grid.Row="some int" in a xaml file and increment that row number by one whenever it is larger than X. Yes, for this particular example even though this is legacy code the better approach would be to restructure so this same problem does not need a hack solution the next time around. However, I have encountered the need to do this sort of thing more than once, so I'll ask anyway.
Do any of you know of tools that already exist that would let me do something like this before I go write something simple myself? I googled around for a bit but didn't see anything besides basic regex tools.
Thanks.
I gather that nothing like this exists from the lack of feedback. I built a quick javascript app to fit my needs. If I have time to make it flexible enough I'll update this answer with a github link. I've started using it to do things like start every word with its correct lowercase letter, split camelcase into words for documentation, etc. Really surprised nothing official exists yet.
Thanks anyway.
The problem is as follows: I'm writing a brute-force decrypter to crack some supersecret code (it's a contest, not a crime), which turned out to be impossible: just too many nodes in the tree that needs to be searched. To overcome this problem, I thought it might be helpful to check the intermediate 'solutions' to see if they produce (parts of) sentences. For example, I might get something like: "jvabaosajbgasgav..." or "lookslikeitsworking....". The first clearly is gibberish and in that case it wouldn't make any sense to continue cracking the code. The second one can easily be identified by eye as a valid English sentence.
I'm not planning on writing my own spell/grammar checker, so I thought it might be possible to call the spell checker from an open source project like OpenOffice or LibreOffice. I checked the openoffice.org website but I couldn't really find out what to do next. Like, how can I link against their libraries? Are these libraries in the SDK? What functions can I use?
The program I'm writing is in pure C, so I probably need to write a wrapper to call their C++ member-functions, right?
Any help is much appreciated!
I believe you'd be vastly more successful integrating with something written with such integration in mind, like the Aspell library.
I am working on documenting a new and expanded Lua API for the game Bitfighter (http://bitfighter.org). Our Lua object model is a subset of the C++ object model, and the methods exposed to Lua that I need to document are a subset of the methods available in C++. I want to document only the items relevant to Lua, and ignore the rest.
For example, the object BfObject is the root of all the Lua objects, but is itself in the middle of the C++ object tree. BfObject has about 40 C++ methods, of which about 10 are relevant to Lua scripters. I wish to have our documentation show BfObject as the root object, and show only those 10 relevant methods. We would also need to show its children objects in a way that made the inheritance of methods clear.
For the moment we can assume that all the code is written in C++.
One idea would be to somehow mark the objects we want to document in a way that a system such as doxygen would know what to look at and ignore the rest. Another would be to preprocess the C++ code in such a way as to delete all the non-relevant bits, and document what remains with something like doxygen. (I actually got pretty far with this approach using luadoc, but could not find a way to make luadoc show object hierarchy.)
One thing that might prove helpful is that every Lua object class is registered in a consistent manner, along with its parent class.
There are a growing number of games out there that use Lua for scripting, and many of them have decent documentation. Does anyone have a good suggestion on how to produce it?
PS To clarify, I'm happy to use any tool that will do the job -- doxygen and luadoc are just examples that I am somewhat familiar with.
I have found a solution, which, while not ideal, works pretty well. I cobbled together a Perl script which rips through all the Bitfighter source code and produces a second set of "fake" source that contains only the elements I want. I can then run this secondary source through Doxygen and get a result that is 95% of what I'm looking for.
I'm declaring victory.
One advantage of this approach is that I can document the code in a "natural" way, and don't need to worry about marking what's in and what's out. The script is smart enough to figure it out from the code structure.
If anyone is interested, the Perl script is available in the Bitfighter source archive at https://code.google.com/p/bitfighter/source/browse/luadoc.pl. It is only about 80% complete, and is missing a few very important items (such as properly displaying function args), but the structure is there, and I am satisfied the process will work. The script will improve with time.
The (very preliminary) results of the process can be seen at http://bitfighter.org/luadocs/index.html. The templates have hardly been modified, so it has a very "stock" look, but it shows that things more-or-less work.
Since some commenters have suggested that it is impossible to generate good documentation with Doxygen, I should note that almost none of our inline docs have been added yet. To get a sense of what they will look like, see the Teleporter class. It's not super good, but I think it does refute the notion that Doxygen always produces useless docs.
My major regret at this point is that my solution is really a one-off and does not address what I think is a growing need in the community. Perhaps at some point we'll standardize on a way of merging C++ and Lua and the task of creating a generalized documentation tool will be more manageable.
PS You can see what the markup in the original source files looks like... see https://code.google.com/p/bitfighter/source/browse/zap/teleporter.cpp, and search for #luaclass
Exclude either by namespace (could be class as well) of your C++ code, but not the lua code
EXCLUDE_SYMBOLS = myhier_cpp::*
in the doxygen config file or cherry pick what to exclude by using
/// #cond
class aaa {
...
...
}
/// #endcond
in your c++ code.
I personally think that separating by namespace is better since it reflects the separation in code + documentation, which leads to a namespace based scheme for separation of pure c++ from lua bindings.
Separating via exclusion is probably the most targeted approach but that would involve an extra tool to parse the code, mark up relevant lua parts and add the exclusion to the code. (Additionally you could also render special info like graphs separately with this markup and add them via an Image to your documentation, at least that's easy to do with Doxygen.). Since there has to be some kind of indication of lua code, the markup is probably not too difficult to derive.
Another solution is to use LDoc. It also allows you to write C++ comments, which will be parsed by LDoc and included into the documentation.
An advantage is that you can just the same tool to document your lua code as well. A drawback is that the project seems to be unmaintained. It may also not be possible to document complex object hierarchies, like the questioner mentioned.
I forked it myself for some small adjustments regarding c++. Have a look here.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
C++ code dependency / call-graph “viewer”?
I am working on a huge C++ code base and currently I am stuck with the problem of modularizing my code. I have to divide my code into separate independent modules.
One approach I can think of is to generate the dependency graph and then do a higher level categorization. Other approach is to start with a entry point (some function abc()) and generating a function call tree whose each node will contain the name of the file in which that function resides. Thereafter I can use some script to extract those functions into separate modules.
My question is, is there any tool that can help me do this task? Has anybody faced such a problem earlier. Or can you suggest any approach to achieve the same?
First level of modularization - and I hope you already have done that - is structuring your code in classes. If your code is merely a collection of functions - i.e., C plus some syntactic suggar - then it's high time to rewrite your code, because no amount of dependency-graph-building will save you from maintenance hell.
If you have classes, modularizing should be a matter of finding classes that closely work together (like Customer, Order and Invoice) and separate them from classes that are only losely coupled with them (like Employer or Facility). Then take it from there.
Modularizing code is something that requires, first and foremost, thought. No automatic procedure is a replacement for that. Actually, from what little you wrote, I would fear that any automated process would make things worse, because apparently there has been too little thought invested in this project already. I.e., you wrote 1 million lines of code without thinking about modularization, and now you want modularization to happen while still not actually thinking about it. You are heading for epic fail.
To get some overview doxygen might help. But you have to play around a little with the doxyfile settings to generate dependency graps and if your Code base is huge you should disable dynamic stuff from the generated methods.
Doxygen can create include, inheritance, call and caller graphs using graphviz.
Here are simple examples but it also works for bigger ones.
But doxygen will only give you an overview and no refactoring capabilities.
I regularly use "Understand for C/C++" to investigate these kind of dependencies.
If the code base is really huge and you start your modularization from scratch, you might want to look at some other tools, like:
Cytoscape (which can take the output of "Understand for C/C++" to visualize the dependencies
Lattix
It sounds like you are looking for a refactoring tool. Try taking a look at the answers on this question: Is there a working C++ refactoring tool?
One method will be a bit long but what you can do is to remove a method and compile to find dependencies and than group the decadencies into one component. Although this does not resolve your issue fully but it is an approach to start off with.
I work with a guy who prefers to name his member variables using the mCamelCase convention, for example: mSomeVar or mSomeOtherVar. I can't stand this format. I prefer the m_camelCase convetion, for example: m_someVar or m_someOtherVar. We drive each other mad looking at each other's code.
Now we've added a new guy to the team and he prefers no prefix at all. Since we use svn, we were thinking we could develop an svn script that renames member variables on the fly when you download the code form the server. This way everyone can get the member variables named whatever they want.
Does anyone have any example svn scripts that can do this sort of thing? I've seen scripts that change comment headers but we need something that includes a C++ processor.
Sounds like a recipe for disaster. In order to get this to work you'd need to decide on a repository wide standard, where every file uses the same variable naming conventions. If you can do that, why not just have everyone code like that?! The important thing about conventions is not which convention you use but that everyone actually uses the same convention!
Find someone with seniority to make the call (or pull rank, if you can), everyone else will just have to suck it up.
I'll assume you want to change the style for research purposes, and the question is simply hypothetical. Joel S. seems to think that answers which simply say your doing something wrong aren't good answers at all, so I'll try to attempt to give you some avenues to approach your problem.
The closest thing which svn does in terms of transforms is it can change the line ending on check-out, and change it again on check-in. This allows the repository to have a single idea of a line ending, and for different clients to have the files modified to their preferences. While this feature sounds fairly straight forward, a number of people seem to have problems getting it to work correctly. Simply Google 'svn eol-style'.
Since svn does not provide any sort of customizable client side filters, I think it would be safe to assume you are going to need to modify the svn client, and compile it for your own purposes. Perhaps you could submit a patch or an extension back to svn.
So at this point, you should have downloaded the svn source, and be able to get it to compile the client. At this point, turn your attention to libsvn_subr/subst.c. This file contains the routines to translate to and from various formats. Currently it does translation on keyword expansion and eol's.
You simply need to create a new property, maybe called member-variable-style. For files which have this flag set, you can invoke a special transform in the subst.c code. You could be able to track down reference in svn to the transform code by looking at the calls to svn_subst_translate_stream3.
OK. That was the easy part. Now you need to get a function to properly translate your code from one form to another. You can't simply pull out the cpp processor out of gcc, because there is no guarantee the code will be valid / compile. You have to do your best job creating lexing rules which hopefully will do the right thing on the right variables. For varaibles starting with m_ or even m, this is fairly straight forward to do. Unfortunately, for the member on your team who doesn't use m_ at all, it can be quite a challenge determining what it a member variable in C++. Fortunately, there exists quite a bit of research in the field done by people who create syntax highlighting code. I'd poke around and find some code which does a good job highlighting C++ code.
Lastly, as these transforms could become quite complicated, I'd suggest you have svn shell out to a filter program at this stage. This wouldn't be great for performance, but it would make it much easier to write and debug your filter. You could then write your filter in Perl or the language of your choice. For a good example of using external an external filter program, see Squid redirectors.
Good luck!
Subversion doesn't have hooks that work on update - you could have a post-commit hook* that would allow you to convert from one convention to another (repository standard), and you could use a script that you write yourself that does the checkout, and then performs the necessary adjustments, but this would give you false readings on svn diff etc.
My suggestion is to just sit down with your colleagues and agree on a standard. The post-commit hook would still be useful to catch slip-ups though.
*I'm thinking something that sees a commit has occurred, automatically checks out and alters the code to adhere to the repository standard convention, and then commits if necessary. Another option is to have a pre-commit hook that disallows the commit if the code doesn't adhere to the standard.