The simple fact that precompiled headers are not universally available should be enough reason not to rely on them, and to not teach them to newbies.
The simple fact that precompiled headers are not universally available should be enough reason not to rely on them, and to not teach them to newbies.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Let's first of all say that I think this is a personal preference thing.
Second, I prefer to see, directly, which header files are NEEDED by any particular source file. If you have some "include most things for everything" header file, you don't see what this source file requires, because it's dragging in "half the world" as a "common include everything" header file. Not a nice idea, in my mind.
And note that if you do windows applications, rather than console apps, I do believe that you will need Windows.h in lots of your files [unless it's a HUGE app and you have your own little widget package], so this is a different case. But the subject of this thread is console apps, which are generally not including "Windows.h" as a "common include" [and if you don't put it in your "common header" then you still have to wait, because it's not part of the precompiled headers].
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
That's like saying, if you have a hammer, a screwdriver and a screw, you should use the hammer because it's the most available tool, that some might not have a screwdriver.
Of course you should teach them precompiled headers if the IDE supports it. No using waiting several seconds/minutes just because the project is compiling. Why not teach them some convenience? Is that so wrong? It really doesn't hurt anything.
And this is wrong, how, exactly?
It doesn't seem like a bad idea, exactly. If a header is missing in one source file, stuff it in the precompiled header and away it goes.
If you really need to know what headers a file needs, then put a comment. That's what I usually do in header files when they require other include files (common includes). Then I can take those common includes and stuff them in the precompiled header and I don't have to wait a minute for that little header to compile in my source because of the big common includes.
Come on, that's like saying, "don't use a debugger, because every IDE does not have one!".
But if "everything" is included in "stdafx.h", then you get into the problem that you don't know which source file ACTUALLY uses which part - comments tend to get out of date as soon as you change something related to the comment. Compilers enforce at least LACK of header files - there's really no way to detect that "somefile.h" isn't actually USED in this source.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
But that's the thing - what does it do if there's more headers than necessary? It will not affect the size of the executable. It might affect the size of the compiled files (I think?), but so what? What's a little extra space these days?
Other than a individual opinion, is there are practical use for not enforcing more headers than necessary?
It tells you the dependancies - what OTHER COMPONENTS do you need for this particular source file. Of course, it still gets messy when
And by the way, just because what I listed may be part of the project itself, I actually do care if a source file uses for example stdio.h, linux.h, windows.h or whatever the system includes that apply to a particular project.Code:a.c: a.h b.h e.h b.c : b.h c.h c.c: c.h d.h d.c : d.h e.c: e.h f.h f.c: f.h
No, it doesn't make much difference in general, but for example, if you search for "windows.h" in your source files, you know that the files you find may depend on windows specific things - files that DON'T include windows.h [along with other non-portable files of course] are likely to work on another system.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Precompiled headers are non-portable and cause more problems than they're worth. "Newbies" have a hard enough time just learning how to use headers properly. Precompiled headers only dumb it down to "throw everything in here" - which doesn't help the learning curve. And for what? A few seconds of a compile time? Not likely.
Precompiled headers have no business in a forum like this, which advocates portable, standards compliant C++.
If someone wants to understand what precompiled headers are, and how they might be useful when including a massive number of headers from a framework like MFC - just provide a link to MSDN.
This is just my opinion.
gg
When you start making big projects (which probably all newbies will one day), those headers will come in handy.
But it's just as I say, if you HAVE a tool - maybe the right tool to do the job (as per the C# vs. C/C++ discussion), why not use it?
Why not use C# if you only intend to use Windows to make a fine GUI for an app.
Why not use precompiled headers if you only intend to use Visual Studio to do the job?
It's also one thing to discourage the use and one to encourage the use. Specifically saying "disable precompiled headers" might not be as good.
And just saying "disable precompiled headers" will most likely make them ask why, as well.
My thinking is that if something doesn't break anything (precompiled headers doesn't mess up your system or create security holes as opposed to unsafe functions such as gets and scanf), then you shouldn't outright diss them. Explain the good and the bad and let everyone make their own choice. You're also holding them back if you don't tell them to use a specific thing just because it might not be portable (And who says precompiled headers aren't portable anyway? The actual include file exists, so you can include it as normal and make it compile.) doesn't mean you should tell everyone not to use it.
This board also has a forum for C#. And as it stands, the .NET Framework and C# are pretty unportable right now, and yet people use it and we don't go saying "don't use it - it's unportable!!!".
Use the right tool for the job. Explain the good and the bad - teach. That's what we usually do here, is it not? Teaching people how to do it right. And give them suggestions to improve.
So you're claiming that precompiled headers solve a different problem than normal headers? (On the language level.)
What you should do is teach a newcomer to tools a manual screwdriver. Sure, the electrical one is nice, but the newbie should learn the basics first.
Yes, it does. It gives them a skewed view of what C++ supports. Newbies shouldn't learn implementation-specific features because during their initial learning, they have a harder time of distinguishing standard C++ from extensions.Of course you should teach them precompiled headers if the IDE supports it. No using waiting several seconds/minutes just because the project is compiling. Why not teach them some convenience? Is that so wrong? It really doesn't hurt anything.
I'm not advertising not teaching PCHs. I'm saying that you shouldn't teach them to newbies. You say that PCHs are useful for large projects, which the newbies will eventually do. That's true, but by that time they won't be newbies anymore.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Then there's the argument of what newbies should learn and not to learn while they're still newbies.
Should they worry about features such as PCH? Or should they not? Considering they'll probably be using the same compiler all the time while they're still newbies, it also tends to swing the argument in favor of PCH.
Maybe when they get more experience, maybe then will they need to start worrying about PCH?
As I mentioned, I consider it a tool. A very nice tool that you can begin using straight away. As long as one understand the mechanism of includes, it should not be a problem. In fact, I would recommend that all use PCH if they can, to start learning it now and not later. The sooner, the better.
That's me, though.
Hi,
Thanks for all your help. I eventually want to move onto C++ CLR, but in the mean time im playing with C/C++ console. The compiler so far looks nice, and will hopefully help me on my way to being a red hot programmer.
Cheers
Tuurbo46
Hi,
Well.... The c++ version of c#. I mentioned c++ .net on here once, and somebody said there is no such thing as c++ .net its c++ CLR.
In short the simpler version of MFC if that makes sense.
Does what i said make sense?