0

The program that I'm working on involves large amounts of user-input data. For this reason, I have quite a few functions whose purpose is solely to verify the input and ensure that it is formatted/the correct type.

First of all, what would be the best method to move code to outside files? When I designed the custom classes for my project, I used a .h and .cpp file pair to declare and implement the functions; is the same appropriate for these other random functions?

Secondly, under what circumstances should code be moved outside of the file? I could easily include it all in the main file, but it appears cluttered.

James Webster
  • 31,873
  • 11
  • 70
  • 114
Michael Hang
  • 199
  • 2
  • 2
  • 15
  • 3
    Show it to someone else. If they start screaming, it's time to reorder your files. – Kerrek SB Nov 19 '12 at 00:08
  • [c++ book list](http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list) – Luchian Grigore Nov 19 '12 at 00:10
  • 1
    One could argue that any group of functions that serve a similar purpose (a suite, if you will) should be factored out into a separate module of compilation unit. In c++, we can do this by creating a new namespace for the functions, creating a header file that holds only their declarations (inside the new namespace, of course) and a cpp file containing the actual definitions. This is similar to the class approach, but instead of a class with just static methods, we use a namespace for organization, to avoid confusion. – jpm Nov 19 '12 at 00:12

2 Answers2

1

If the main file gets too big, move some out.

If the functions can be reused, separate them out into separate files. One file contains the definition or content of the functions. The other file contains the declarations of the files (a.k.a. prototypes, headers).

One reason for extracting code into separate files is when your done testing, separate files don't need to be recompiled. The linker can refer to their object file states. This speeds up the build process (and the development process).

Thomas Matthews
  • 56,849
  • 17
  • 98
  • 154
  • related question- Is it considered bad style to create 'file chains' if it is logical to do so? For example, I have a 'menu.cpp' that calls functions defined in 'buffer.h' file, which in turn interacts with the 'team' class. Thus, 'menu.cpp' #includes 'buffer.h' which in turn #includes 'team.h'... – Michael Hang Nov 19 '12 at 02:36
  • In some shops, yes it is bad form for chaining. My rule is that a header file should only include files necessary to resolve the function declarations in that file. If `menu.cpp` requires a function in `buffer.hpp` it should include `buffer.hpp`. If `menu.cpp` requires a function in `team.hpp`, it should include `team.hpp` regardless of whether `buffer.hpp` needs it or not. – Thomas Matthews Nov 19 '12 at 02:46
1

If these 'random' functions are logically connected (ie they all do input validation) then I would create an InputValidator class (you'll have to make a .h and .cpp file). In your applications main (or where ever you get the input) create an InputValidator instance and call it's methods to validate your input. If you don't actually have any use for the instance you could make the methods static and then you would call them with InputValidator.MyMethod() without having to create an instance.

evanmcdonnal
  • 46,131
  • 16
  • 104
  • 115
  • Are there any circumstances in which you'd merge both parts in a single file? If so, would .cpp or .h be more appropriate? – Michael Hang Nov 19 '12 at 02:31
  • @MichaelHang If the class were very small you may put it all in the .cpp file. There's no reason you can't but generally declarations go in .h files and implementation goes in the .cpp file. – evanmcdonnal Nov 19 '12 at 03:15