User forums > Using Code::Blocks
Bug in 'swap header / source'
ironhead:
--- Quote from: Zini on October 18, 2009, 02:00:43 am ---
--- 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.
--- End quote ---
Just to clarify, the patch I provided works with both open and non-open files in the same manor.
--- Quote from: Zini on October 18, 2009, 02:00:43 am ---
--- 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).
--- End quote ---
Hrm, the patch doesn't handle the include/A with src/A correctly, so there is definitely room for improvement. :)
--- Quote from: Zini on October 18, 2009, 02:00:43 am ---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 ---
--- End quote ---
I'm afraid my python knowledge is non-existent, but I'll take a closer look at this tomorrow once I've had a chance to catch up on some sleep myself. Thank you for the pseudo code!
Cheers!
ironhead:
Putting some more thought into the 'include/A/Unit.h' / 'src/A/Unit.cpp' I'm not sure there is a sure fire solution. For the swapping to the header, you could use the project / build target's include paths and add the relevant relative path (i.e. the 'A'), but the for the other direction, how would C::B implicitly know that the source files for 'include/A' are in 'src/A'?
Zini:
Because of the 'A'? ;)
That might not be 100% correct all the time, but you would need some rather exotic layout for the test to fail.
ironhead:
Even the approach of using the immediate parent directory isn't full proof either.
Lets say you had:
<root>
--- <A>
--- <src>
Config.cpp
--- <include>
Config.h
Again, the include path would determine where Config.h is relative to Config.cpp, but how would C::B know that for Config.h, Config.cpp is in <src>?
At this point I really don't see a better way of handling things then what I've already proposed in my patch. I fully admit that it does not handle all cases, but I don't know of an algorithm that would, and I believe the patch makes it better than what is there today.
If anyone else is willing to take a stab at implementing a better algorithm, I'd be happy to help out in any way I can.
Zini:
Still haven't got around to test your patch (sorry, so busy atm. its insane!), but IIRC it stops the feature from working when h and cpp files sit in different directories. That would break the feature completely for me (and most likely a lot of other people).
--- Quote ---At this point I really don't see a better way of handling things then what I've already proposed in my patch. I fully admit that it does not handle all cases, but I don't know of an algorithm that would, and I believe the patch makes it better than what is there today.
--- End quote ---
I agree that a solutation that handles all cases isn't possible without storing information about the source layout in the project file. However the situation you mentioned is handled perfectly by my algorithm. Did you have to time to take a look at it?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version