CODEWITHSUNDEEP
c++class
user13567216
user13567216

Reputation:

c++ classes: different ways to write a function

what's the difference between the following 3 cases:

1) in point.h:

class point
{
    int x,y;
    public:
    int getX();
};

int point::getX() {
    return this->x;
}

2) in point.h:

class point
{
    int x,y;
    public:
    int getX()
    {
        return this->x;
    }
};

3) in point.h:

class point
{
    int x,y;
    public:
    int getX();
};

int point.cpp:

int point::getX() {
    return this->x;
}

Note: I read that it's somehow connected to inline but not sure which one of them makes the compiler to treat int getX() and inline int getX()

Upvotes: 1

Views: 119

Answers (2)

eerorika
eerorika

Reputation: 238311

what's the difference between the following 3 cases

  1. The function definition is outside of the class definition. Note that in this example you've defined a non-inline function in a header. Including this header into more than one translation unit violates the One Definition Rule. This is most likely a bug.

  2. The function definition is inside of the class definition. In this case, the function is implicitly inline. As such, it is fine to include it into multiple translation units.

  3. The function definition is outside of the class definition again. The function is not declared inline. This time the function is defined in a separate translation unit, thereby conforming to the ODR even if the header is included into multiple translation units.

what's the problem if both b.cpp & a.cpp includes my header file

The problem is that then both b.cpp and a.cpp will define a non-inline function. The One Definition Rule says that there must be at most one definition of any inline function. Two is more than one. Therefore doing this violates the ODR and therefore such program would be ill-formed.

I'm too much confused why it's an error to write the same function in two different cpp files?

It is an "error" because the rules of the language (explained above) say that it is an "error".

what if both want to use that function?

Then declare the function in both translation units. Only define the function in one translation unit unless you declare the function inline, in which case define the function in all translation units (where the function is used) instead. Look at the examples 2. and 3. of your question to see how that can be done.

so the code in method 1 is not automatically inlined?

No. Functions are not automatically declared inline. Function is declared inline only if A. inline keyword is used, or if B. it is a non-static member function that is defined within the class definition (or in a case involving constexpr that I shall omit here). None of those cases apply to the example 1, therefore it is not an inline function.

Upvotes: 1

AndyG
AndyG

Reputation: 41092

Avoid this first one:

struct point
{
    int x,y;
    int getX();
};

int point::getX() {
    return this->x;
}

If multiple source files include point.h, you will get multiple definitions of point::getX, leading to a violation of the One Definition Rule (and modern linkers will give an error message).

For the second one:

struct point
{
    int x,y;
    int getX()
    {
        return this->x;
    }
};

This implicitly inlines the function. This means that the function definition may be copy-pasted everywhere it is used, instead of resolving a function call. There are a few trade offs here. On one hand, by providing definitions in headers, you can more easily distribute your library. Additionally, in some cases you may see performance improvements due to the locality of the code. On the other hand, you may actually hurt performance due to instruction cache misses (more instructions around == it won't all fit in cache). And the size of your binaries may grow as the inlined function gets copied around.

Another tradeoff is that, should you ever need to change your implementation, all clients must rebuild.

Finally, depending on the sensitivity of the function, you may be revealing trade secrets through your headers (that is, there is absolutely no hiding of your secret sauce) (note: one can always decompile your binary and reverse engineer an implementation, so putting the def in the .cpp file won't stop a determined programmer, but it keeps honest people honest).

The third one, which separates a definition into a .cpp file:

// point.h
struct point
{
    int x,y;
    int getX();
};

// point.cpp
int point::getX() {
    return this->x;
}

This will cause a function to get exported to your library (at least for gcc. In Windows, you need to be explicit by using __declspec directives to import/export). Again, there are tradeoffs here.

Changing the implementation does not require clients to recompile; you can distribute a new library for them to link to instead (the new library is ABI-compatible if you only change the impl details in the .cpp file). However, it is more difficult to distribute your library, as your binaries now need to be built for each platform.

You may see a performance decrease due to the requirement to resolve function pointers into a library for running code. You may also see a performance increase over inlining due to the fact that your code may be friendlier to the instruction cache.

In the end, there is a lot to consider. My recommendation is to go with #3 by default unless you are writing templates. When you want to look at improving performance, you can start to measure what inlining does for you (binary size as well as runtime perf). Of course you may have other information up front that makes approach #2 or #3 better suited for the task (e.g., you have a Point class, and you know that accessing X will happen everywhere and it's a really small function, so you decide to inline it).

Upvotes: 1

Related Questions