Hacker News Reader

Comment by mystified5016 | Hacker News Reader

Typically you declare a member in the header and define it in the CPP. But you can also freely write definitions in your header.

You cannot define the same member twice, tough.

In an ideal universe, your header contains only declarations for functions which are defined elsewhere. If you define something in your header, it should be something intended to be accessed without the CPP. Say, a utility function to give you a string describing an error code.

In reality, because there are no hard rules, people do anything. You get definitions mixed into headers and such.

Look at it this way, each CPP file is intended to be an isolated compiled object. The header defines the ABI you use to talk to that object. And members defined in your header get copied into other CPP files and also compiled there. You want all reusable code to go into a separate compilation so it's not duplicated all over your binary.

View on HN

> In reality, because there are no hard rules, people do anything. You get definitions mixed into headers and such.

All of that is done so forward declaration works.

The problem is #include does just what it says on the tin. It includes whatever is in the file into the file the #include is in. By convention that is .h/.hpp for headers. But there is nothing saying it can not be something like #include<'somerandom.jpg'> or even another .cpp file (seen it). Now that probably will not compile. But the pre-processor will include it at the spot you say. Then promptly barf on it because it does not parse.

The compiler says anything you declare though needs to be defined. Usually a built in type, or class, or struct, or typedef. Basically defined before use. So technically I can glom all of my stuff together and if I get it in the right order I could have one giant file and zero new headers. But we like our class/function files to be semi organized so forward declaring items is the norm.

C++ adds a bit of a twist on all of this. In that a class file does not have to be all in one spot. It can be in a header or smeared across 20 other files. The one rule the linker needs is hey is this declared before you use it. That way the linker can eventually find the right code to call.

To understand the 'why' you have to understand the linker and preprocessor work together to make it happen.

> The compiler says anything you declare though needs to be defined.

No it doesn’t. If that were true dynamic linking would not be a thing, but it’s not even true in the most basic way either.

> Basically defined before use.

Also not true. But this is “not even wrong” since “before use” isn’t defined here, however if it is meant to be appears before in the input, then that is wrong.

> The one rule the linker needs is hey is this declared before you use it. That way the linker can eventually find the right code to call.

Because of the way C++ is defined this is somewhat true (not so much for incomplete types), but also a tortured avoidance of the compiler role (Translation phase 7) in the process, and really the meat of what is going on. I’d recommend someone just read cppreference first.

https://stackoverflow.com/questions/1410563/what-is-the-diff...

Just want to add the tiny nitpick that there's no C++ "law" that the end result must be code duplicated in the binary. It's just that it may require link time optimizations and untangling which in practice is not done, so you'd end up with duplicates, after all.

Reply on news.ycombinator.com