User forums > Using Code::Blocks
Bug in 'swap header / source'
Zini:
Haven't tried it myself, but from what I see you are limiting the search to one directory per file. Wouldn't that break the feature entirely for source layouts, where h and cpp files are separated into different directories?
ironhead:
--- Quote from: Zini on October 17, 2009, 03:10:07 pm ---Haven't tried it myself, but from what I see you are limiting the search to one directory per file. Wouldn't that break the feature entirely for source layouts, where h and cpp files are separated into different directories?
--- End quote ---
Yes, the patch I supplied would not correct this issue, but the original implementation would only work if you only had one occurrence of each file. Let's say you had:
root
--- subdir1
--- src
Config.cpp
--- headers
Config.h
--- subdir2
--- src
Config.cpp
--- headers
Config.h
In the original implementation, if you opened Config.h in subdir2 and hit 'Swap...' you would get Config.cpp in subdir1/src I suspect.
To correct this, I believe you would need to implement what Tim S. suggested and search the include path for the project / build target. However, even this implementation I suspect will have issues (i.e. I don't think it would work well for my particular issue).
I'm open to suggestions on how to more generically address this issue. ;)
Zini:
Well, you could make a list of all candidate files and then apply some heuristics to find the most likely candidate. For a start you could look for identical path elements (subdir1 in your example).
But that still doesn't handle the case, where the corresponding file does not exist yet. At this point you only have two options:
1. Offer the user a new dialogue, in which he can specify the right directory. Additionally you might want to use the heuristics mentioned above to find the most likely candidate.
Example:
include
-- A
---- foo.h
---- bar.h
-- B
---- foo.h
src
-- A
---- foo.cpp
-- B
---- foo.cpp
From the include/A/foo.h src/A/foo.cpp pair a smart algorithm may deduce, that the newly created cpp file for bar.h goes into src/A/bar.cpp
2. Enhance the Code::Blocks project file format with some information about the source layout. This information could be used to improve other functionality too. For example it could help to automatically pick the right directory for files newly created from the File -> New dialgoue.
Both options sound like a lot of work unfortunately.
ironhead:
Looking at the code again, it actually already searches the include path if it doesn't find it in the list of currently open editors or in the project files (i.e. in the same directory):
--- Code: --- // get targets include dirs
for (int i = 0; i < project->GetBuildTargetsCount(); ++i)
{
ProjectBuildTarget* target = project->GetBuildTarget(i);
if (target)
{
for (unsigned int ti = 0; ti < target->GetIncludeDirs().GetCount(); ++ti)
{
// TODO (Morten#5#): target include dirs might override project include dirs, take append/prepend option into account
wxString dir = target->GetIncludeDirs()[ti];
if (dirs.Index(dir) == wxNOT_FOUND)
dirs.Add(dir);
}
}
}
--- End code ---
With my patch applied, would it be possible for you to validate if my patch actually breaks the scenario you proposed?
As for the scenario where the file doesn't exist, I wouldn't suggest any automation in terms of guessing where the file should be created. I would leave it up to the developer and simply provide a file dialogue to create the file.
Zini:
--- Quote ---Looking at the code again, it actually already searches the include path if it doesn't find it in the list of currently open editors or in the project files (i.e. in the same directory):
--- End quote ---
That is a part of the problem. Why the treat open files differently from non-open files? If it only works if the file isn't open, the algorithm is already broken.
--- Quote ---With my patch applied, would it be possible for you to validate if my patch actually breaks the scenario you proposed?
--- End quote ---
Guess it will be less work, if you try it out. Please note that I have uploaded a test project, that demonstrates the problem (a few posts above).
Anyway, I couldn't sleep, so I wrote a new algorithm. Hope you can understand my python-pseudo-code. No guarantees about the correctness though (despite not being able to get to sleep I am awful sleepy already):
--- Code: ---listCandidates (file):
e = extension (file)
if e in header_extension_list:
extension_list = source_extension_list
elseif e in source_extension_list:
extension_list = header_extension_list
else
throw error (unknown extension)
l = leaf_without_extension (file)
for f in project: # iterate over all files in the project
if leaf_without_extension (f)==l and extension (f) in extension_list:
add f to list
return list
findCandidate (file):
list = listCandidates (file)
n = len (file) # len (file) is the number of path elements
if n>1:
for f in list if len (f)==n:
for i in range (0, n-2):
if f[i]==file[i]:
return f # success
else
for f in list if len (f)==1:
return f # success (top level directory)
# maybe add other methods to determine the file in case the above fails
return null # no file found; either does match no known pattern or it does not exist
swap (file):
c = findCandidate (file):
if c!=null:
open c
return
# file does not exist
parent = file[0:n-2] # one level up (the directory where the file is located)
for f in parent if f!=file: # iterating over the files in the directory
c = findCandidate (f)
if c!=null:
create corresponding file in directory c[0:n-2] and open it
return
# give up; either ask the user for a directory or report that the file can't be created
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version