Whole Tomato Software Forums

Whole Tomato Software Forums

All Forums

Visual Assist

Feature Requests

Remove unnecessary #includes

You must be registered to post a reply.
Click here to register.

Screensize:

UserName:

Password:

Format:

Message:

Forum code is on.
Html is off.

Check to include your profile signature.
Check to subscribe to this topic.

T O P I C R E V I E W
Vertexwahn	Posted - Jun 15 2011 : 7:25:11 PM It would be awesome if there would be a Remove unnecessary #includes - Feature for C++ I know this feature was often wished but it was too hard for you guys to implement. Why do you not choose a brute force approach to find out which includes are needed and which are not. When manually done you just comment out one #include after another and do a recompile to find out if a certain include file is really needed. Some time ago I thought about programming a small VB Macro within Visual Studio that just does this automatically - just find each line that contains a #include -> uncomment -> recompile -> if it worked -> just add a comment behind that header file like "VAssistX Detected, that this header file is not needed and commented it out for that reason" In simple cases this approach should work - the final result can look like this #include "car.h" #include "wheel.h" // #include "foo.h" /* VAssistX Detected, that this header file is not needed and commented it out for that reason */ #include "bar.h" Things get more complicated if for example wheel.h needs to know something about car.h but car.h and wheel.h are not needed - what I mean is that both header files could be safely removed without a compilation error, but when only one header file is removed the simple brute force approach doen't work. What you really need to do is to uncomment all permutations of header files to find out what is really necessary and what is not Example: #include "h1.h" #include "h2.h" #include "h3.h" #include "h4.h" All permutations: 0000 (0 = comment header file out, 1 = leave it unchanged) 0001 0010 0011 .. 1111 Some permutation can be skipped because one file can only depend on another if its included later than the file it depends on - also its more likely that depending header files are grouped together, so a combination of 110111111111111111011 is not as mush likely as 110011111111111111111. Mabye you gather some statistical data from real world projects to find more common patterns - maybe you can allow the user to check for some patterns first. Recompilation time shouldn't be a big problem (you change only one .cpp file and maybe it is possible to do parallel compilation) There should be a dialog showing the currently checked header file code (110111111111111111011) It should be possible to abort this brute force search. Even if it take a long time this is not a problem because it can be started when leaving work an run overnight - in the morning the ongoing search can be aborted and the results can be viewed. I have real world project with moth than 30 includes in some implementation files. I am always too lazy to check out manually which header files are needed - I am sure there at least 5 files that are not needed but it cost to mush time to find out which ones are not needed - the downside is that I have unnecessary decencies in my code.
7 L A T E S T R E P L I E S (Newest First)
Vertexwahn	Posted - Feb 08 2014 : 3:28:02 PM Small Update: http://www.youtube.com/watch?v=kAvkTGJq7hM BlueGo is an OpenSource project: more information can be found here: http://vertexwahn.de/bluego.html
Vertexwahn	Posted - Sep 04 2011 : 8:23:12 PM maybe you can use Wave (a Standard conformant C++ preprocessor library - see http://www.codeproject.com/KB/recipes/wave_preprocessor.aspx) to work difficult cases out.
feline	Posted - Aug 05 2011 : 2:07:07 PM There are two main, simple situations where this is difficult. First is chains of #included header files. Consider this: type_declared_here.h includes_declared.h includes_above1.h includes_above2.h source_file.cpp The idea is that each file #includes the file immediately above it. Not a very good "diagram", but hopefully you can work out what I am getting at. Now sit in "includes_above1.h", is "includes_declared.h" a required, or unnecessary #include line? You have to scan a lot of things to work this out. The other common situation is #ifdef statements.
markr2	Posted - Aug 05 2011 : 11:05:25 AM I would also like to see this feature implemented at some point. Out of curiosity, what are the major complexity factors that are holding this feature back? This capability is present in certain .NET based language refactoring tools, but I imagine it must be significantly more difficult for C++. I think it would entirely acceptable if the process took some time (e.g. modal progress box while VAX runs a thorough usage analysis). Another (possibly naive) thought - what if the user could right-click on an #include line and request that VAX "Find local uses of symbols from header file". When triggered, VAX would produce a report similar to "find references results" that show where (in the current translation unit) symbols from the header file are used. The function could optionally work recursively (scanning .h files included in the target, etc.). Of course, this concept is NOT the same as determining (definitively) whether a header file is "unnecessary", but it might give the developer a reasonable starting point for such investigations. If the process came up empty, for example, the developer might then comment out the include and attempt a recompile.
feline	Posted - Jun 17 2011 : 1:19:09 PM We are hoping to get to this, and various other new features, somewhat before hell gets that cold I have put a comment onto this case about compiling the file to work out which include lines are required. It is certainly one approach, and should work in a good number of cases. I am a little concerned about how slow it might be some of the time though. But for complex cases, any sort of thorough check is going to take time.
Vertexwahn	Posted - Jun 16 2011 : 12:41:25 PM case=32032 G?? oh its done when hell freezes over ;) When the command is triggered in a header file you can also search for #include directives and remove them if they are not necessary. If it takes hours/days it is not your problem G?? as I posted above it should be possible to abort the process every time G?? if the user thinks it takes to long he or she can abort it quote: What about debug vs release mode? Sometimes #include lines are wrapped in pre processor blocks. There should be three modes DEBUG_ONLY, RELEASE_ONLY and DEBUG_AND_RELEASE. The default mode should be DEBUG_AND_RELEASE which means that after some includes are commented out the project is first build in debug mode and after that in release mode G?? if one build fails the specific includes files canG??t be removed. If the user chooses DEBUG than only the debug build is tested to find out if the specific include files are needed. The same story for the RELEASE_ONLY mode. If this is not possible to implement you can just use the current build configuration G?? if the user is currently in debug mode than only a debug build is made and the user is informed so the user is aware of that this file might be only removable in debug mode. What happens when the IDE is not set up to compile the code? E.g. people are using the IDE as an editor, but the compiler is for a different OS. output a message to the user G?IDE is not set up to compile the code G?? brute force #include decency checking does not work in this caseG? imaging I give you this file: #include G?my_secret_lib.hG? //G? It is not predictable if the project is not probably set up because we do not know where to find my_secret_lib.h - maybe there a different variants of my_scree_lib.h in different folders on the currently used workstation Edit: I just did a small experiment: I open a .cpp file with 42 includes - I started to uncomment the last include file and worked to the top (to the first include file) - I found out that 18 Include files were not needed - it took me about 13 minutes to manually uncomment and recompile the cpp file each time
feline	Posted - Jun 16 2011 : 09:48:14 AM We are considering adding a feature to do this at some point: case=32032 I am not sure that doing this by compiling is going to work though. Here are a couple of obvious edge cases for you to consider. What if this command is triggered in a header file? I have seen cases where triggering a recompile after updating a header file can take a couple of hours, or more. What about debug vs release mode? Sometimes #include lines are wrapped in pre processor blocks. What happens when the IDE is not set up to compile the code? E.g. people are using the IDE as an editor, but the compiler is for a different OS.

Snitz Forums 2000