0

below is the code structure, where stack, Queue, tree folder code rely on list folder code,

../Computing >ls
HashTable  list  Queue  recursion  stack  tree

list folder duplicated in tree/rootedTree folder unlike recommended approach to include dependent header files, mentioned here,

../Computing/tree/rootedTree >ls
lcrsImpl.c  list  main.c  multiWalkImpl.c  tree.h

here is the incomplete code for rootedTree folder.

To avoid code duplication of List folder, How to maintain the code structure?

Community
  • 1
  • 1
overexchange
  • 15,768
  • 30
  • 152
  • 347

1 Answers1

3

You seem to have the following structure:

whatever/
   list/
      ...
      list.h  
   ...
   queue/
      ... <- some files have an #include "list/list.h";
      list/ <- duplicate
   tree/
      rootedTree/
         ...
         list/ <- duplicate
         tree.h <- has an #include "list/list.h";
         test.c <- #include "tree.h"

In this code, you first go to the folder where you want to compile things, and then compile them inside the folder:

 you@somewhere:~/whatever/tree/rootedTree$ gcc -Wall -I. -g *.c -o test

The paths of the #include statements are relative to where the compiler is invoked from (as long as you include the -I. argument; thanks, @jean-françois-fabre). So you can very well have the following (non-duplicated) structure:

whatever/
   list/
      ...
      list.h  
   ...
   queue/
      ... <- some files have an #include "list/list.h"; no list/ duplicate
   tree/
      rootedTree/
         ...
         tree.h <- has an #include "list/list.h"; no list/ duplicate
   testTree.c <- #includes "tree/rootedTree/tree.h" and others

and, from within the whatever folder, you can write

you@somewhere:~/whatever$ gcc -Wall -I. -g */*.c testTree.c -o testTree

and get an executable to test. Since calling the compiler directly is boring, especially if you only want to compile the parts of the code where you have actually made changes, you generally use some sort of project definition file (Makefile, Scons, ...) to handle that for you.

Duplication is bad, and there is (almost) always a way to avoid it.

tucuxi
  • 17,561
  • 2
  • 43
  • 74
  • So, How `#include "List/List.h"` is working in your answer? How does pre-processor(`cpp`) find the code ,when you say `List/List.h`? `*/*.c` is just the c code in all immediate child folders but not header files. Can you elaborate? – overexchange Dec 22 '16 at 11:05
  • When the compiler finds an #include, it attempts to read the referred-to file from its current working directory. If I run gcc from within `whatever/`, then gcc can correctly read `List/list.h` when encountering an `#include "List/list.h"` in, say, `Tree/tree.h`. – tucuxi Dec 22 '16 at 11:23
  • But List folder is not suppose to be in tree folder to avoid duplication – overexchange Dec 22 '16 at 11:54
  • I have added what I understand to be your current layout in indented-tree notation, so that you can compare to what I propose. – tucuxi Dec 22 '16 at 12:29
  • OK. `testTree.c` is sitting as sibling of `tree` folder within `whatever` folder(say), So, `tree.h` is in `whatever/tree/rootedTree/` folder. How mentioning `#include"list/list.h"` in `whatever/rootedTree/tree/tree.h` will resolve to `whatever/list/list.h`? Is it not resolving to `list/list.h` in `tree` folder? **Am missing this from your answer** – overexchange Dec 23 '16 at 16:15
  • 1
    You seem to think that #includes resolve according to the file where they are found. They do not, they resolve according to where the compiler is being called from. So, if your file is in `a/b/c/d` and the compiler is working from `a/b`, then `#include "z"` is actually attempting to include `a/b/z`. – tucuxi Dec 23 '16 at 17:16
  • 1
    @tucuxi: have you tested what you're stating? because it doesn't work unless you set `-I.`, check this Q/A: http://stackoverflow.com/questions/41307381/error-no-such-file-or-directory-c/41307473#41307473 – Jean-François Fabre Dec 23 '16 at 20:35
  • @Jean-FrançoisFabre thanks, I have just fixed the answer. I should have tested it before posting. – tucuxi Dec 23 '16 at 23:07