On Tue, 2018-05-01, Daniel wrote:
> Consider the header file A.hpp, which contains a definition of A,
>
> class A
> {
> };
>
> Now suppose we introduce a new header file B.hpp, which contains a
> definition of B that uses A,
>
> #include <A.hpp>
>
> struct B
> {
> void f()
> {
> A a;
> }
> };
>
> Now, suppose it's desirable for our users that including A.hpp also brings
> in B, and we particularly want to keep the name A for that header file.
Sounds a bit speculative. Any real-life examples?
You have people using A, and you introduce B which depends on A.
Seems to me if people are explicitly interested in B, they might as
well #include B.h.
I also believe it's not an error to define both A and B in A.h,
if B is some kind of utility closely related to A.
> Solution 1. include B.hpp at the bottom of A.hpp (but I've never
> actually seen anyone do this, include header files at the bottom.)
> Is this bad?
>
> Solution 2 (seems to be the boost approach)
>
> Move the definition of class A to a separate file, boost likes detail/A.hpp,
> and rewrite A.hpp as
>
> #include <detail/A.hpp>
> #include <B.hpp>
>
> Comments?
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/
snipabacken.se> O o .