Printable View
Hi all,
Im just about to move from Dev C++ to Vs C++ 08 and im trying to use console applications, but when i compile i cannot get the console window to pop up when run is selected (I think i have set up the project wrong). Can somebody give me the steps to setup a c/c++ project in this enviroment?
Thanks tuurbo46
Did you set Project properties -> Linker -> system -> subsystem -> console?
Um, no i just left it in defualt form.
I will try that one.
Is this the eviroment you use for c/ c++?
thanks
tuurbo46
It tells the linker if you're going to use the typical CLI environment or the standard Windows environment (dos prompt vs no dos prompt).
For typical beginner and class apps, it's the choice you want to use, but for real apps, not just restricted to Windows, the other choice is what you'll most likely use.
When creating a new (empty) console project from the beginning:
- Create a new project, either of the following will do:
- File->New->Project
- File->Add->New Project
- The "Add New Project" window appears
- Select "Win32" under "Project Types
- Select "Win32 Console Application" under "Visual Studio installed templates"
- Enter a name for the project and a location in the appropriate areas
- The "Win32 Application Wizard" window appears
- Click on the "Next" button.
- Uncheck the "Precompiled Header" check box.
- Check the "Empty Project" check box.
- Click on the "Finish" button.
- You now have an empty console project to which you can add your source files.
The above is for Visual Studio 2008 Express Edition (if that's what you mean by VS C++ 08, if not then never mind).
No, don't uncheck Precompiled Header!Quote:
The "Win32 Application Wizard" window appears
* Click on the "Next" button.
* Uncheck the "Precompiled Header" check box.
* Check the "Empty Project" check box.
* Click on the "Finish" button.
Is there a reason you do that? Because it yields compilation speed increase which is useful.
Yes, but it also means that you have to HAVE a particular header file to precompile, e.g. stdafx.h - if you don't have a common file that you include lots of times, it's just confusing. For small to medium projects, precompiled headers make very little difference. When it comes to larger projects and you change the "included everywhere header", then it makes a difference. Particularly if you start including "Windows.h" - but you don't usually do that in small console apps anyways.Quote:
Originally Posted by Elysia
--
Mats
I do not see a good reason to not use precompiled headers. It always reduces compiling time. Visual Studio automatically create a stdafx.h file and puts common include files there.
If you're going to use Visual Studio, then you should do it right.
It's not confusing at all.
Just put all common includes (excluding your own) in the precompiled header file and put it in every source file.
If you have a hammer and screwdriver and a screw, you don't use the hammer, do you (same as putting includes in all files)?
Instead you use the more convenient method, the screwdriver (use precompiled headers).
Right, so you need to put a #include <stdafx.h> in ALL your source files. Even if you are copying from examples in a book, for example. That's the sort of thing that confuses people. It's also, to some extent, confusing in the sense that you don't know what includes are actually included in this particular file.Quote:
Originally Posted by Elysia
And when it takes half a second or so to compile your project, how much time do you actually save?
Yes, I agree, it's useful - WHEN YOU UNDERSTAND HOW TO USE IT. [I've used it myself - but I actually prefer a method of "minimal amount of includes" - that keeps the interfaces cleaner, and you can quickly scan the includes to this particular source file and see what it includes, and get a good picture of what other components it depends on - even if they are "system" components].
--
Mats
I don't know about you, but I find it annoying to wait one second (or more!) to include all these annoying includes like Windows.h t hat are huge.
It's like we teach not to use unsafe functions, we might as well teach how to use precompiled headers. The sooner you start to use them, the better you understand them and the sooner you fall in love with them.
Let's not turn them away from a very useful function.
Yes, but most "simple" applications [at least the ones I write] are not including big files like windows.h.Quote:
Originally Posted by Elysia
Have you tested [best to use command line for this] to compile a simple hello.c/hello.cpp with and without pre-compiled headers, and compared the time. I don't have a MS compiler on my work machine, so I can't say, but I doubt it makes a noticeable difference.
--
Mats
I don't know what "headers" that would be. Math.h and stdio.h are fast ones.
Hi,
Thanks for all your input, i will have a go tonight when i get home from work, and i will get back to you tomorrow.
Cheers
Tuurbo46
Entirely my point. If you write small & SIMPLE programs [and portable], the header files are usually small and fast, so you don't gain anything noticeable from pre-compiled headers, and you GAIN from not having to make sure that every single source file includes the "stdafx.h".Quote:
Originally Posted by Elysia
Also, if you keep your "windows specific code" into one module [like you should for a small-ish project][1] that handles the windows specific stuff, then you hopefully don't need to include windows.h in every single file.
[1] Edit: Of course, the same applies for a larger project, but here you may need MULTIPLE non-portable modules, as the amount of non-portable code in a really large project may be more than what's suitable in one file.
--
Mats
But every time you change that file, you have to wait several seconds for it to compile.
And with precompiled headers, you can just stuff in all common headers and include only one include in every source file instead of every single header your functions need.
Handy.
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.
Let's first of all say that I think this is a personal preference thing.Quote:
Originally Posted by Elysia
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
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.Quote:
Originally Posted by CornedBee
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?Quote:
Originally Posted by matsp
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.Quote:
Originally Posted by Elysia
--
Mats
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 whenQuote:
Originally Posted by Elysia
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
So in essence, it's just your opinion and doesn't generally make any difference in real terms, I take it.
If so, then it's definitely a good idea to teach precompiled headers. After all, it's up to each and everyone how to use them.
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.)Quote:
Originally Posted by Elysia
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.Quote:
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.
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
CLR as in .NET, or just plain Win32?
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?
Yes, I understand what you mean, but I don't recommend it.
C++ CLR/CLI/.NET is Microsoft ONLY. Vendor lock-in so to speak.
If you want .NET, I recommend you use C#. But my opinion (not recommendation) is simply to use C++.
Ok i agree, but does this mean i should just keep playing with flat c++ in console form? Then when i apply to jobs, learn there enviroment (microsoft, unix etc) when i arrive?
I agree alot of time is waisted trying to learn silly compiler quibs, and never perfecting the language.
Look forward to your advice.
Console? Who said C++ is limited to console?
All those fancy apps you see out there, or hey, games - what are they written in? C++ of course!
C++ can do all that C# and .NET does. It's not limited to console. It's just more difficult to write GUI in C++.
Ok sounds good, but my brain is limited to embedded, .net and console at minute. What are games etc written in? Dev-C++ and then executed by and exe. I dont really understand how they are developed. I only really understand micrsoft - sorry to be so thick.
Applications are applications and games are applications - they're just a file with a bunch of resources, data and executable code. They're no different from anything else.
Dev-C++ is an IDE. It uses a compiler. A compiler turns your code into an application. It doesn't matter what IDE or compiler you use - in the end, you get an application.
There are two types of applications mostly, though: CLI and GUI (for a lack of a better name).
The only difference between them is that CLI has a dos window and the other does not.
Games simply use the second type. They use windows (not the OS) to draw graphics upon.
In a thread where the Common Language Infrastructure has been referred to as CLI, it might be wise to point out that in this case, CLI stands for Command Line Interface.
Well ... what do you think draws the windows? The OS does. Besides, games that use DirectX or OpenGL (i.e. all except the really basic ones) only use windows because DirectX needs them as identification hooks - after that, all the drawing is done through the DirectX interface.Quote:
They use windows (not the OS) to draw graphics upon.