// Old Post. <- See, I’m a programmer!
We know that this header thing in C++, is an inherited problem from the programming language C. Which forces extra typing work, and causes slow compile time, as well as can cripple smooth IDE functionality. Sadly though, not even for C++ 17 it’s guaranteed that C++ is going to get a module system that would allow to ditch headers. It may be too early to ask whether UE4 will support this. But also UE4/Epic could provide another reason for those who implement new features into C++ 17? Or even a possible Visual Studio 2017*?
However, the PDF linked above, with the document number N4047, is aiming to introduce two new keywords which are ‘import’ and ‘module’. Seems that UE4 would need some changes, too.
So what’s Epic’s view on this? Needless to say, that if C++17/UE4/VS2017* could support headerless code in two years, it would also reduce the need for C# in UE4. Don’t get me wrong, I wold love to have C# in UE4, but how likely it that going to happen**?
Or whatever the name of the VS2015 successor is going to be.
** You don’t have to answer this question. It was rhetorical.
Yes, this will be an awesome and welcomed addition! I am greatly looking forward to modules that is for sure. I heard (Not sure though) it wont make it for c++17, but likely a TS shortly afterwards!
I would bet it will not become standard/common until it has reached the point where all platforms and compilers support it. Something similar happened when UE4 was under heavy development. I heard since many legacy platforms where being dropped, the team was encouraged to use modern compiler agnostic C++11 code, since all the intended compilers/platforms had almost complete support of the c++11 spec.
I would guess at least a few years at the very least, till it started getting adopted at the engine level. Although refactoring the engine, and other technical limitation may make it not feasible for quite awhile.
I know Clang and VS15 (update 1) now have experimental support for their implementations. Time to experiment!
Hate to rain on the parade, but I have a few points to make (I haven’t read the paper and I’m not a C++ mastermind, so who knows what crazy stuff they talk about in there):
First of all (and this I’m sure we all know), Epic isn’t going to add features to C++ 17, so if that was a semi-serious idea it’s probably best to let that one go right away. If Headerless code is even possible in C++ for a code base as large as this, then until some huge company does it like MSDN or something and makes it the Standard (and they throw out all the rulebooks on C++ and start again), then it’s not gonna happen.
Secondly, I don’t even think headerless code is possible. Unless compilers / linkers change as well, then surely all we’ll end up with is bloated binaries - since each class you create would have to ‘include’ every other class, and somehow avoid circular dependencies. Just because you can doesn’t mean you should…
And of course the main thing is, any effect this has on compile / iteration times will more than likely be negative, not positive. You won’t be able to just compile .cpp files anymore for fast iteration, you’ll have to recompile the entire code base - which is just ridiculous.
TL;DR: Unlikely to happen IMO. A quick google search indicates why Headerless C++ (if possible) would be a bad idea.
Yeah i agree with jamsh as far as trying to go headerless. I was mainly speaking of incorporating some of the module functionality for portions of the engine where it may make sense.
First i will say that technically it’s already supported. You don’t HAVE to write headers, you can either just make them by using “makeheaders”. Allowing you never to have to write headers again. This is something i was looking to update to UE4 but i do not have time. OR you can just write your headers in cpp files, therefore no header files this is a joke, do not do this. even though you can
Yep, the module system has been around for a very long time, if they wanted it, we would have it already.
Ditching headers is not a good thing, since the mechanism allows precise control over visibility of classes/variables/functions/etc in CPP files, unlike, say, C#, where declaring anything makes it visible in every file that has access to the same namespace which can result in clashes and namespace pollution. CPP files are isolated from each other and it is a GOOD thing.
Removing headers is shooting yourself in the foot. Not making programming easier.
Last time there was C++ standard upgrade it took several years to get major compilers to the point where they more or less supported new features. So, you should expect C++17 features to become widely available in 2021 or something like that.
I’m against this feature. It makes programmer’s life harder and offers no benefits.
Including headers in wrong order causes errors, which are incredibly hard to track, and don’t forget about circular dependencies…
Not to mention small change in header included by everything will cause to recompile everything.
Which is why you learn how to use headers efficiently.
Never had an issue with that.
No, that’s not what I’m saying. I’m not in the mood for another pointless C++ vs C# “discussion”.
The languages follow different goals, and I like C++ goal more.
You guys should just request C# binding or something.
Just a thought, maybe the compilers are getting smarter and using all those extra resources we can throw at them. Not that I think one way or the other here, Im just open to the possibility of change by looking forward. If we can offload more of the tedious work to automated processes I only see that as a good thing, Im happy to watch the future unfold and it cant come quick enough honestly. Its great to see C++ going somewhere again, it was really stagnant for ages but now there is a positive push forward, ofcoarse not all features work out the way they were initially planned to but the direction is right.
I’m not sure what you mean. Maybe you talk about a limited IDE. Because even with VS 2015 that does give a lot to C++, because of the **** headers, IntelliSense is very slow. It isn’t just about not having to write headers, it’s also about IDEs that can work with the C++ code to a larger extend and don’t take ages to get done simple thinks.
Nobody said that. And I said this:
By the way, those three dudes seem to work with/for Micro$oft. M$ did an excellent job with C# and Visual Studio.
Get Visual Assist X - Intellisense sucks with large code bases. Any UE dev will tell you that VAX is just as essential as Visual Studio. Since VS is essentially free now, there’s no excuse
Either way, this is already starting to feel like another C# vs C++ thread - and we all know how those end so let’s try to avoid that.
IMO - Hot reloading doesn’t take much time at all if you’re only changing CPP files - usually less than a few seconds (for me at least, on a 3/4 year old stock i7-3820K), and it HR works pretty well nowadays. The precompiled headers take a long time to compile but you guise are forgetting all the stuff that UBT and UHT does for you, without you ever knowing. That stuff is still going to get done whether you abolish headers or not - only now you won’t be able to do fast reloading at all. Circular Dependencies are stupidly easy to avoid so long as you keep a tidy code base, and if you understand how the compiler/linker works.
Surely wasn’t my fault, though. I was suggesting to improve C++ and not to implement C#. And actually, nobody was suggesting in this thread, the implementation of C# into UE4.
I’m not sure where this C++ vs C# nonsense is coming from. 0.o
Headers exist because of one of very important features in C++. *Every *.cpp file is treated as completely separate thing from all the other .cpp files..
Lots of C++ libraries actually rely on that behavior and use multi tier header system to control visibility of this or that feature.
You might want to tell people why the heck did you want modules in the first place.
If you want “faster intellisense”, there are other ways to go about that. QtCreator was pretty **** fast last time I used it, for example.
this is a joke, do not do this. even though you can