Good c++ prog
- Thread starter reap
- Start date
Varsity
Newbie
- Joined
- Apr 13, 2004
- Messages
- 2,683
- Reaction score
- 2
gooball
Newbie
- Joined
- Sep 21, 2003
- Messages
- 106
- Reaction score
- 0
reap said:
Hey Reap,
The Half-Life2 SDK will definately use the Visual C++ 6 project file format.
Dev-C++ will be great to learn the language on, at least for some console apps.
I recommend: http://www.cplusplus.com/doc/tutorial/
A port of the SDK to Dev-C++ may be possible in the future, but not likely anytime soon after the SDK comes out, and possibly not officially supported by Valve. It would take a lot of work to move an entire game platform to something like Dev-C++.
I doubt the HL2 SDK will come with it's own C++ or mod editor.
Until Windows Longhorn comes out, Visual C++ 6 will be the standard for 99% of the serious windows programs.
Maybe get a used copy, or something?
:thumbs:
VC++6 is a pile of pish.
pish pish pish.
VC7.1 (which comes with VS.Net03) is the emerging new standard, mainly coz its compiler works (unlike the pish which is VS6 which has huge problems with the standard, did i mention is was pish?)
If you can get an acidemic (sp?) verison of it, do so, otherwise dont worry about it (and certainly dont get the 'standard' version if you want anywhere near half decent performance) and use something like GCC, which is also standard complient and comes with the program linked by Varsity.
did i mention VS6 was pish btw?
pish pish pish.
VC7.1 (which comes with VS.Net03) is the emerging new standard, mainly coz its compiler works (unlike the pish which is VS6 which has huge problems with the standard, did i mention is was pish?)
If you can get an acidemic (sp?) verison of it, do so, otherwise dont worry about it (and certainly dont get the 'standard' version if you want anywhere near half decent performance) and use something like GCC, which is also standard complient and comes with the program linked by Varsity.
did i mention VS6 was pish btw?
bobvodka said:
Actually, from what I've heard ( read: speculation) the way Longhorn will treat unmanaged (unsafe) code will mean that the Managed languages (Managed C++.NET, C#.NET, VB.NET and JScript.NET) will not incur the speed hit that unmanaged languages will.
So, with some applications maybe the speed hit will be enough to prevent it from working well enough.
Whether this can be turned off on a system-wide or per-application (e.g option to run apps as 'trusted') basis, I don't know.
mrchimp
Newbie
- Joined
- Jul 19, 2003
- Messages
- 1,928
- Reaction score
- 0
.NET isn't to windows longhorn as the win32 API is to windows 98 (atleast I think 98 was the first to use 32bit).
I havn't thought it out well enough to give a proper response, but I know this is a different situation.
BTW I was suggesting that MS may be trying to use .NET as a vendor lock in but a open source party are developeing a .NET framework for Linux (and subsquently GCC compilers), plus I heard you can download the .NET command line tools free so dev's won't get forced into useing VS .NET. However this will still give MS more control and I just can't help but get the feeling MS have a side agenda when it comes to .NET and C#.
I havn't thought it out well enough to give a proper response, but I know this is a different situation.
BTW I was suggesting that MS may be trying to use .NET as a vendor lock in but a open source party are developeing a .NET framework for Linux (and subsquently GCC compilers), plus I heard you can download the .NET command line tools free so dev's won't get forced into useing VS .NET. However this will still give MS more control and I just can't help but get the feeling MS have a side agenda when it comes to .NET and C#.
The reasons that people should move over to managed code are:
1) All the new APIs in Longhorn are managed. Avalon, WinFS, Indigo, that's all managed, so if you want to get at that, you want to writing your apps today managed, so that painful conversion and/or interop does not have to be done in the future to be able to use these new APIs.
2) Managed code is great to use. Microsoft are at heart a code shop, so when they decide to write a system like .net from the ground up, they make good choices. C# and the .Net framework is great to use.
Interestingly enough, C# and the .net CLS are not Microsoft's attempt to trash standards, they are actually standards. You can go look them up:
http://www.ecma-international.org/publications/standards/Ecma-335.htm
then write a compiler for a language to platform-inspecific MSIL. If anything, .net prevents platform lock-in. C# code written using only the parts of the .net framework supported by both Mono and the MS .net framework will work unmodified, even unrecompiled, on Linux, Mac OS, Windows, whatever. Brilliant. It just so happens that Microsoft have only written an implementation for Windows, and not other platforms, but that's their perogative. And yeh, all the command line tools for .net are free, including compilers for C# and VB.net. They're just annoying to use 'cause they're command line.
1) All the new APIs in Longhorn are managed. Avalon, WinFS, Indigo, that's all managed, so if you want to get at that, you want to writing your apps today managed, so that painful conversion and/or interop does not have to be done in the future to be able to use these new APIs.
2) Managed code is great to use. Microsoft are at heart a code shop, so when they decide to write a system like .net from the ground up, they make good choices. C# and the .Net framework is great to use.
Interestingly enough, C# and the .net CLS are not Microsoft's attempt to trash standards, they are actually standards. You can go look them up:
http://www.ecma-international.org/publications/standards/Ecma-335.htm
then write a compiler for a language to platform-inspecific MSIL. If anything, .net prevents platform lock-in. C# code written using only the parts of the .net framework supported by both Mono and the MS .net framework will work unmodified, even unrecompiled, on Linux, Mac OS, Windows, whatever. Brilliant. It just so happens that Microsoft have only written an implementation for Windows, and not other platforms, but that's their perogative. And yeh, all the command line tools for .net are free, including compilers for C# and VB.net. They're just annoying to use 'cause they're command line.
Couple of points;
1 - While the new APIs are going to be mangaged the old Win32 interface will still be there and frankly, you dont need any more than that to write games anyways.
2 - Managed stuff is great, agreed, however bits of the system wont be managed, such as everything in the kernel space (drivers etc, which frankly CANT be managed)
3 - The performance overhead for non-managed code cant be high for the simple reason of the amount of legacy code which already exists, if a program runs slowler on Longhorn than say XP people just wont upgrade (this includes business' who live in a 'if it aint broke, dont fix it world' and wont start re-writing huge amounts of code for longhorn.
3a- However, the slow parts will be intreactions with internal libraries (where the data is checked and changed from one form to another) and the majority of games dont spend much time talking to the Win32 API, mainly the DX API and i dont see MS being daft enuff to cripple that (although OGL lovers such as myself would love to see that, infact OpenGL could well be faster than D3D simple because it doenst have to use a managed layer, code goes direct into a dll which jumps to a driver more or less right away, so thats a good reason for MS not to shoot themselves in the foot)
3b - So, aside from API interactions (which is generaly kept low anyways) there simply CANT be a speed hit to general unmanaged code, its still native to the processor its running on (just because managed is perfered doesnt make it native) so will be just as fast. If you are running a program with alot of window API interaction then you might notice a very small speed hit (translation of values from unmanaged to managed code) however frankly, it wont be noticeable.
1 - While the new APIs are going to be mangaged the old Win32 interface will still be there and frankly, you dont need any more than that to write games anyways.
2 - Managed stuff is great, agreed, however bits of the system wont be managed, such as everything in the kernel space (drivers etc, which frankly CANT be managed)
3 - The performance overhead for non-managed code cant be high for the simple reason of the amount of legacy code which already exists, if a program runs slowler on Longhorn than say XP people just wont upgrade (this includes business' who live in a 'if it aint broke, dont fix it world' and wont start re-writing huge amounts of code for longhorn.
3a- However, the slow parts will be intreactions with internal libraries (where the data is checked and changed from one form to another) and the majority of games dont spend much time talking to the Win32 API, mainly the DX API and i dont see MS being daft enuff to cripple that (although OGL lovers such as myself would love to see that, infact OpenGL could well be faster than D3D simple because it doenst have to use a managed layer, code goes direct into a dll which jumps to a driver more or less right away, so thats a good reason for MS not to shoot themselves in the foot)
3b - So, aside from API interactions (which is generaly kept low anyways) there simply CANT be a speed hit to general unmanaged code, its still native to the processor its running on (just because managed is perfered doesnt make it native) so will be just as fast. If you are running a program with alot of window API interaction then you might notice a very small speed hit (translation of values from unmanaged to managed code) however frankly, it wont be noticeable.
It isn't a necessity to switch to managed code for Longhorn, there will not be a speed penalty on unmanaged native code like someone else suggested.
All Win32 apps will continue to run fine on Longhorn, exactly as they did before. It's not like Microsoft are re-writing the whole OS managed. That's a crazy undertaking. But all the new stuff is now managed.
So, if you want to take advantage of the new technologies in Longhorn, you are going to want to be writing in managed. Sure, there's a performance hit on managed, and it is slighty slower than native, which means we're probably not going to be seeing cutting-edge games of the same sort of class as HL2 and the Source engine written in managed for a while, if ever. But there's no reason not to have games like say, the Sims, or something in managed, there's even a managed interface to DirectX which is about as efficient as the unmanged COM interface.
And yeh, re-writing code for new platforms is bad, so this is why companies should be wanting to write new code in managed today, so come Longhorn things like Avalon or WinFS can be easily dropped in, as opposed to requiring mammoth feats of interop code to integrate.
All Win32 apps will continue to run fine on Longhorn, exactly as they did before. It's not like Microsoft are re-writing the whole OS managed. That's a crazy undertaking. But all the new stuff is now managed.
So, if you want to take advantage of the new technologies in Longhorn, you are going to want to be writing in managed. Sure, there's a performance hit on managed, and it is slighty slower than native, which means we're probably not going to be seeing cutting-edge games of the same sort of class as HL2 and the Source engine written in managed for a while, if ever. But there's no reason not to have games like say, the Sims, or something in managed, there's even a managed interface to DirectX which is about as efficient as the unmanged COM interface.
And yeh, re-writing code for new platforms is bad, so this is why companies should be wanting to write new code in managed today, so come Longhorn things like Avalon or WinFS can be easily dropped in, as opposed to requiring mammoth feats of interop code to integrate.
R
Rincewind
Guest
From the VERC:
Microsoft Releases Developer's Toolkit
[Sun Apr 18, 2004 / 09:21pm PDT] Skyler 'Zipster' York - comments (5)
Some good news for those aspiring to become talented C++ developers (or Half-Life coders), but without a lot of cash to fund their endeavors. Microsoft has recently released the Microsoft Visual C++ Toolkit 2003. Quoting MSDN:
The Microsoft Visual C++ Toolkit 2003 includes the core tools developers need to compile and link C++-based applications for Windows and the .NET Common Language Runtime.
This is basically the same optimizing compiler and linker (as well as all the necessary standard libraries) that come with Visual Studio .NET 2003 Professional, all for free. In addition, it also has the ability to use the .NET Framework and target the CLR. Visit the website for more information, in addition to a list of frequently asked questions.
post modified on Sun Apr 18, 2004 / 09:22pm PDT [general / press release]
Microsoft Releases Developer's Toolkit
[Sun Apr 18, 2004 / 09:21pm PDT] Skyler 'Zipster' York - comments (5)
Some good news for those aspiring to become talented C++ developers (or Half-Life coders), but without a lot of cash to fund their endeavors. Microsoft has recently released the Microsoft Visual C++ Toolkit 2003. Quoting MSDN:
The Microsoft Visual C++ Toolkit 2003 includes the core tools developers need to compile and link C++-based applications for Windows and the .NET Common Language Runtime.
This is basically the same optimizing compiler and linker (as well as all the necessary standard libraries) that come with Visual Studio .NET 2003 Professional, all for free. In addition, it also has the ability to use the .NET Framework and target the CLR. Visit the website for more information, in addition to a list of frequently asked questions.
post modified on Sun Apr 18, 2004 / 09:22pm PDT [general / press release]
Revisedsoul
Newbie
- Joined
- Oct 9, 2003
- Messages
- 1,441
- Reaction score
- 0
.net is awsome. but microsoft has currupted my class. we are forced to take visual basic.net for 3 SEMESTERS!!!! GOD HELP US ALL. i want my visual c++ and c#
MapE
Newbie
- Joined
- Jul 4, 2003
- Messages
- 61
- Reaction score
- 0
R
Rincewind
Guest
Yup, thats where.
Not necessarily, I haven't tried, but, Dev-C++ maybe able to be set-up to use the MS compiler - there is also other IDEs you could try. Or, of course, you could just struggle along using the command prompt 
On another note, I'm not too sure on the validity of what I said about it not being the full linker - I heard of some people trying to link in SDL, which uses multi-threaded DLLs.
On another note, I'm not too sure on the validity of what I said about it not being the full linker - I heard of some people trying to link in SDL, which uses multi-threaded DLLs.
R
Rincewind
Guest
Similar threads
