Inline Members

[laserlight]

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".

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?

[Mybowlcut]

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.

[sgiri1981]

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

#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

[laserlight]

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:

A preprocessing directive of the form

# 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.

Does it matter if these libraries are static or dynamic?

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

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.

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:

A preprocessing directive of the form

# 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

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

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

[sgiri1981]

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

[D_Drmmr]

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.

class foo
{
	void bar();
};

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

[Raislin]

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.

[Speedo]

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.

[Raislin]

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