Inline Members

Quote:

---

Originally Posted by Mybowlcut

Typo? Doesn't make sense to me though, even if I relate it to D_Drmmr's example; perhaps it's just the phrasing?

---

Typographical error: the latter "definition" should be "declaration".

Quote:

---

Originally Posted by Mybowlcut

I don't know enough about compilation etc. to really talk about stuff like this, but isn't the .cpp merged with the .h at compilation? E.g. the definition is always guaranteed to be complete by the time you include it (unless you have circular dependencies or haven't defined functions/statics/etc)? Hence making it a definition?

---

Well, that would be true if you were including the header in the source file that contains the member function definition. But what if you were including the header in another source file that contains code that is supposed to use objects of the class type?

Quote:

---

Originally Posted by laserlight

Well, that would be true if you were including the header in the source file that contains the member function definition. But what if you were including the header in another source file that contains code that is supposed to use objects of the class type?

---

I don't know haha. That's why I said I don't know much about it. :p

This has been a great thought provoking thread, with the kind of discussions not found in any book.

Anyway, my chain of thoughts led me to wonder whats the difference between the following

Code:

---

#include <iostream>


#include "/relative path given in make file/MyProject/someFile.h"

---

In the first case, I believe the compiler will look for the standard C libraries provided along with the compiler (??? not sure here). Thats because we are enclosing the includes in < >.
Does it matter if these libraries are static or dynamic? Also, is there a separate file for each such library, or does it depend on the compiler (i use GCC)

Regarding second case, if some header file is not found in the path where it is supposed to be, then the compiler will complain. If the definition of a class is not found, then the linker will complain.

thanks in advance,
sgiri


sgiri

Quote:

---

Originally Posted by sgiri1981

In the first case, I believe the compiler will look for the standard C libraries provided along with the compiler (??? not sure here). Thats because we are enclosing the includes in < >.

---

I think that the text of the C++ standard should be a good read here:

Quote:

---

A preprocessing directive of the form

Code:

---

# include <h-char-sequence> new-line

---

searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.

---

Quote:

---

Originally Posted by sgiri1981

Does it matter if these libraries are static or dynamic?

---

This just concerns headers, so the type of linking is not relevant.

Quote:

---

Originally Posted by sgiri1981

Also, is there a separate file for each such library, or does it depend on the compiler (i use GCC)

---

For the standard headers, it depends on the compiler. In theory, there might not even be a file for the header.

Quote:

---

Originally Posted by sgiri1981

Regarding second case, if some header file is not found in the path where it is supposed to be, then the compiler will complain. If the definition of a class is not found, then the linker will complain.

---

Again, allow me to quote the standard:

Quote:

---

A preprocessing directive of the form

Code:

---

# include "q-char-sequence" new-line

---

causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read

Code:

---

# include <h-char-sequence> new-line

---

with the identical contained sequence (including > characters, if any) from the original directive.

---

Quote:

---

Originally Posted by laserlight

I think that the text of the C++ standard should be a good read here:



This just concerns headers, so the type of linking is not relevant.


For the standard headers, it depends on the compiler. In theory, there might not even be a file for the header.


Again, allow me to quote the standard:

---

Thanks laserlight!
May I ask you the source of the c++ standard and is it readable for beginner/intermediate level programmer? (Google threw up some sites which were a little advanced for me)

sgiri

Quote:

---

Originally Posted by Raislin

What I decided to do about my situation is simple. For the code that I'm writing based off this book/source, I'm leaving the method definitions in the header file, but outside of the class definition. Makes me more comfortable, and seems cleaner to me. This way, you can quickly look through the class to see what's in it before looking at any method definitions.

---

Make sure you declare the function definitions as inline, else you run into linker errors when you include the header file in multiple cpp files.

Code:

---

class foo
{
        void bar();
};

inline void foo::bar()
{
        //...
}

---

Quote:

---

Originally Posted by D_Drmmr

Make sure you declare the function definitions as inline, else you run into linker errors when you include the header file in multiple cpp files.

---

Yeah, I already learned that the hard way. My intent was to try to keep from defining them as inline at all. But if I'm starting to understand correctly, that decision is made best by the compiler. I don't mind having a separate file for the definitions, though.

Quote:

---

Originally Posted by Raislin

What I decided to do about my situation is simple. For the code that I'm writing based off this book/source, I'm leaving the method definitions in the header file, but outside of the class definition. Makes me more comfortable, and seems cleaner to me. This way, you can quickly look through the class to see what's in it before looking at any method definitions.

---

That's not a problem for basic test/learning type programs, but don't get in habit for the long-term. When you start dealing with complex programs that involve dozens of classes, having everything in headers will mean that the slightest change in your source code requires huge amounts of recompiling.

That's a good thing to remember. I intend to keep the definitions out of the header from now on anyway.