Holy shit I hate headers

The Partridge Family were neither partridges nor a family. Discuss.
Post Reply
albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Holy shit I hate headers

Post by albinopapa » November 26th, 2017, 10:06 pm

So I've been trying to setup a D3D framework for a few days now and was running into some compile errors. These errors were coming from WinNT.h and IntSafe.h, which are part of the Windows SDK so I knew they weren't really the issue. I've had issues in the past with including Windows.h out of order from say Winsock2.h, and I've had errors trying to bypass including Windows.h by just including WinUser.h or something to cut back on the amount of included files. This wasn't the case this time. I had a chili like include file defining WIN32_LEAN_AND_MEAN and NOMINMAX, then including Windows.h, d3d11.h, wincodec.h and wrl/client.h. I did this so the defined macros would propagate through the loading of Direct3D and the Windows Imaging Component headers since they both include Windows.h.

The rest of the solution had a Model class and a Camera class that needed the DirectX math and DirectX collision headers ( DirectXMath.h and DirectXCollision.h ) and I made some helper classes and functions for extending the functionality of the DirectX math types ( XMFLOAT3, XMFLOAT4X4, etc... ). These were in a Math.h file that included cmath and DirectXMath.h. This file was included by Camera.h and Model.h. They both also had #include <DirectXCollision.h> in them.

So after spending the last couple of days looking for inclusions of Windows headers out of order, I decided I'd exclude all files from the project and add them back one by one until I found the trouble maker(s). Everything went well until I came to Camera.h. Including that file, which included Model.h caused the errors. So I commented out #include "Model.h" and it compiled fine. I followed the includes between Camera and Model and there wasn't any Windows headers in the hierarchy of included headers...unless you could the DirectXMath and DirectXCollision headers. And there it was.

I had in one of the files included DirectXCollision before DirectXMath and it may have been more indirect than that. If I remember correctly, I included the DirectXCollision header in Model and Camera, and the DirectXMath header in Math.h. Which meant somewhere down the line, DirectXCollision was included before DirectXMath. The solution was rearrange the damn #include statements so that headers were included in the correct order.

TL;DR Headers suck and hope modules helps this BS nightmare of inclusion order.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

MrGodin
Posts: 721
Joined: November 30th, 2013, 7:40 pm
Location: Merville, British Columbia Canada

Re: Holy shit I hate headers

Post by MrGodin » November 28th, 2017, 1:30 am

ever tried precompiled headers ?. I generally create one header will most all the includes i will need and and then just include that one header file. Suppose it slows down compile time. I have never encountered the problem you are facing though.
Curiosity killed the cat, satisfaction brought him back

User avatar
chili
Site Admin
Posts: 3948
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: Holy shit I hate headers

Post by chili » November 28th, 2017, 1:38 am

The thing about modules is, they're already implemented, and I suppose when they actually make it into the standard we'll get modules for the stdlib, but I'm doubtful that MS will put the effort into converting all the old WinAPI stuff to modules. Especially when they wanna push as many people as possible in .NET and Universal stuff.

Would be nice though.
Chili

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Holy shit I hate headers

Post by albinopapa » November 28th, 2017, 4:19 am

In Visual Studio, they aren't REALLY implemented. They are still experimental and yeah, I kind of figured they wouldn't go back through their C Win32 API since they would want you to use their universal app api either using WinRT. I've considered going that route a few times, but never got up the nerve. You know SOMEONE is going to create Win32 modules.

Currently, the programs build fine using modules, but not having intellisense support makes it rough to use. You have to go: "eh, I know I've imported this shit, so just ignore all the red squiggles".

The thing I'm hoping modules fix is going to be circular dependencies or dependency order. This would be super helpful and alleviate some headaches. Though, it would be nice for the WinSDK to be retrofitted.

@MrGodin. No, I have not tried using precompiled headers, and it's not about build speed really. It's about clarity. I know when I look at the top of a header or source file what libraries I have included and which APIs I can use if the headers are listed at the top of the file. If they all say #include "Includes.h" then I have to wonder if I added the things I need and all that. I say that, but normally if file C includes B and B includes A, then I don't always include A in C if C needs it, though sometimes I do.

Then there is the compile time. If I can, I like to keep as many includes in cpp files and forward declare things I can. This allows me to make modifications to headers and have fewer source files to recompile. This approach sucks when dealing with template stuff. I haven't found a way of forward declaring templates and trying to forward declare stuff from the STL would be a nightmare anyway, those template argument lists get long and obnoxious. I suppose PCHs would be a better approach for a compile time speedup.

I have used the one include file approach and it is a lot nicer than having to include everything you want to use in each header/source file. The downside is trying to do this with your own project files. You start getting circular dependencies. I suppose you could do this for some of the tools like Vec2/Vec3/Vec4 which wouldn't include anything from the rest of the project.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

Post Reply