Defining the function in C/C++ file and including repective file in header

Question

I've declared a function in a header file and define functions in C++/C file. Header file, where function has been declared is included in C++ file where a function is defined.

Now including that C++ file whenever that function call is required in any other C++. Is this bad practice? Or I should define functions in .h file only?

function.h

char *BoyerMoore_skip(char *string, int strLength);

BM.cpp:

#include "function.h"
char *BoyerMoore_skip(char *string, int strLength);
{
    ...
}

main.cpp:

    include "BM.cpp"
    int main()
{
---
BoyesMoore_skip()
}

You should try *not* to define functions in header files. You have to deal with ODR issues. — chris, Aug 17 '13 at 04:40
Check this out:- http://stackoverflow.com/questions/453372/writing-function-definition-in-header-files-in-c — Rahul Tripathi, Aug 17 '13 at 04:41

score 3 · Answer 1 · answered Aug 17 '13 at 04:41

3

It's not necessarily considered "bad practice" though it is customary to define them in separate header files.

You could experience some ODR issues if you define them before the "main method", however I would say go for it. Do what you please.

answered Aug 17 '13 at 04:41

1

I thought ODR is `one definition rule` :D – billz Aug 17 '13 at 04:46
@billz I guess it works with both... I always thought it was the online dispute resolution... hahaha whoops. – Aug 17 '13 at 04:47

score 1 · Answer 2 · answered Aug 17 '13 at 04:41

1

Usually its customary to put all the function declarations and #defines in a separate header file and include it in your .c or .cpp files. But I don't think what you are doing is bad practice.

answered Aug 17 '13 at 04:41

Hrishi

7,110
5
27
26

score 1 · Answer 3 · answered Aug 17 '13 at 05:11

I interpret your question to mean that you are including one .cpp file in another .cpp file.

If this is what you are doing it certainly is bad practice! The linker will "connect" your function calls to the function definitions, provided you (or your IDE) provides the linker with all the relevant files.

Normal practice is to declare a bunch of related stuff in one header, and include that header in the .cpp that defines those functions and every .cpp that uses them. Often you would also include that header in another header when you need that "related" stuff.

score 1 · Accepted Answer · answered Aug 17 '13 at 06:22

Yes it is bad practice if you are including that header in multiple areas. So what an include does is this: Whenever a compiler sees a #include, what it does is take all that code that is located in that area and insert it where that #include is. Now if you are compiling multiple cpp files together, or #including files that #include the same file. This inserts that chunk of code multiple times which increases the size of your program unnecessarily. Another good practice is using in the header files the #ifndef...#endif for large programs. It would look like this:

Say i have a person.h file coded as

#ifndef PERSON_H_
#define PERSON_H_

#include <stdio.h>
#include <stdlib.h>

typedef char NAME[41];

typedef struct date {
    int month;
    int day;
    int year;
} DATE;

typedef struct person {
    NAME name;
    int age;
    float height;
    DATE bday;
} PERSON;
#endif

What this does is in the preprocessor stage of compilation, if it doesn't see PERSON_H_ defined, it creates it and associates everything between #define and #endif under that PERSON_H_ token. Now every time the preprocessor comes across a #include "person.h" it will check to see if PERSON_H_ exists already, if so it doesn't include the code again associated with PERSON_H_ again. This prevents against defining functions multiple times through header file inclusion and so forth.

It is good practice to define your function in the header file. These are called function prototypes. They tell the compiler what functions to expect. And the prototype is a little different than what you did, you do not need to declare the variable names, only the declarations. So your function prototype would be:

char *BoyerMoore_skip(char *, int );

instead of

char *BoyerMoore_skip(char *string, int strLength);

@lon: thanks. related question `#ifndef dictionary_h__ #define dictionary_h__ extern char *dictionary(char *buf); #endif` what does it mean? — user123, Aug 18 '13 at 07:05
take a look at above for the #ifndef--->#endif explanation. As far as extern goes, here's some things that are very explanatory: http://stackoverflow.com/questions/1433204/what-are-extern-variables-in-c http://www.geeksforgeeks.org/understanding-extern-keyword-in-c/ — Ion, Aug 18 '13 at 19:52

score 1 · Answer 5 · answered Aug 17 '13 at 07:04

This is more of an expensive practice as opposed to a bad practice.

The compiler should either: flag this as an error forcing you to remove which definition you consider to be duplicate, or issue a warning and accept one of them.

However, the expensive part of this practice is that the next programmer who maintains this code will initially be confused and have to spend some time thinking about why this was done. Without any comments guesses will abound.

The real expense is if one of the two prototypes are changed and now there is a polymorphism (assuming C++) which has the potential to generate all kinds of new bugs and again force the next programmer into figuring out that there are actually two prototypes!!

Defining the function in C/C++ file and including repective file in header

5 Answers5