C# or C++

Started by
110 comments, last by jumpjumpjump 20 years, 3 months ago
quote:Original post by jperalta
quote:Original post by GamerSg
Just a question, i don't care about which is better, because C++ has proved itself overtime and C# has gotten many praises so i assume both are great.

But how does C# or Java make you 10 times more productive? HOW? For me, there is little difference between Java and C++, but i prefer C++ because i like some of it's features not present in Java and not having to make a class for everything.Noone has been able to answer this question of mine.

So all of you C# and Java fans please convince me on how these make you more productive. All other points which you mention are pointless to me, because you can do almost anything with C++, and it is a proven language. I have used Java for 2 years and i think it instead slows me down in some cases and i could get the job done faster in C++.

The performance gap between C++ and .NET languages is negligible because i have used VB.NET before and it is barely noticable. For GUI applications, .NET framework really makes you more productive, as compared to writing thousands of lines using the WIN32 API. But this is because of the framework and not the language. For game development, where do i gain in productivity?


// Test.cpp : Defines the entry point for the application.//#include "stdafx.h"#include "Test.h"#define MAX_LOADSTRING 100// Global Variables:HINSTANCE hInst;								// current instanceTCHAR szTitle[MAX_LOADSTRING];					// The title bar textTCHAR szWindowClass[MAX_LOADSTRING];			// the main window class name// Forward declarations of functions included in this code module:ATOM				MyRegisterClass(HINSTANCE hInstance);BOOL				InitInstance(HINSTANCE, int);LRESULT CALLBACK	WndProc(HWND, UINT, WPARAM, LPARAM);LRESULT CALLBACK	About(HWND, UINT, WPARAM, LPARAM);int APIENTRY _tWinMain(HINSTANCE hInstance,                     HINSTANCE hPrevInstance,                     LPTSTR    lpCmdLine,                     int       nCmdShow){ 	// TODO: Place code here.	MSG msg;	HACCEL hAccelTable;	// Initialize global strings	LoadString(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING);	LoadString(hInstance, IDC_TEST, szWindowClass, MAX_LOADSTRING);	MyRegisterClass(hInstance);	// Perform application initialization:	if (!InitInstance (hInstance, nCmdShow)) 	{		return FALSE;	}	hAccelTable = LoadAccelerators(hInstance, (LPCTSTR)IDC_TEST);	// Main message loop:	while (GetMessage(&msg, NULL, 0, 0)) 	{		if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg)) 		{			TranslateMessage(&msg);			DispatchMessage(&msg);		}	}	return (int) msg.wParam;}////  FUNCTION: MyRegisterClass()////  PURPOSE: Registers the window class.////  COMMENTS:////    This function and its usage are only necessary if you want this code//    to be compatible with Win32 systems prior to the 'RegisterClassEx'//    function that was added to Windows 95. It is important to call this function//    so that the application will get 'well formed' small icons associated//    with it.//ATOM MyRegisterClass(HINSTANCE hInstance){	WNDCLASSEX wcex;	wcex.cbSize = sizeof(WNDCLASSEX); 	wcex.style			= CS_HREDRAW | CS_VREDRAW;	wcex.lpfnWndProc	= (WNDPROC)WndProc;	wcex.cbClsExtra		= 0;	wcex.cbWndExtra		= 0;	wcex.hInstance		= hInstance;	wcex.hIcon			= LoadIcon(hInstance, (LPCTSTR)IDI_TEST);	wcex.hCursor		= LoadCursor(NULL, IDC_ARROW);	wcex.hbrBackground	= (HBRUSH)(COLOR_WINDOW+1);	wcex.lpszMenuName	= (LPCTSTR)IDC_TEST;	wcex.lpszClassName	= szWindowClass;	wcex.hIconSm		= LoadIcon(wcex.hInstance, (LPCTSTR)IDI_SMALL);	return RegisterClassEx(&wcex);}////   FUNCTION: InitInstance(HANDLE, int)////   PURPOSE: Saves instance handle and creates main window////   COMMENTS:////        In this function, we save the instance handle in a global variable and//        create and display the main program window.//BOOL InitInstance(HINSTANCE hInstance, int nCmdShow){   HWND hWnd;   hInst = hInstance; // Store instance handle in our global variable   hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,      CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);   if (!hWnd)   {      return FALSE;   }   ShowWindow(hWnd, nCmdShow);   UpdateWindow(hWnd);   return TRUE;}////  FUNCTION: WndProc(HWND, unsigned, WORD, LONG)////  PURPOSE:  Processes messages for the main window.////  WM_COMMAND	- process the application menu//  WM_PAINT	- Paint the main window//  WM_DESTROY	- post a quit message and return////LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam){	int wmId, wmEvent;	PAINTSTRUCT ps;	HDC hdc;	switch (message) 	{	case WM_COMMAND:		wmId    = LOWORD(wParam); 		wmEvent = HIWORD(wParam); 		// Parse the menu selections:		switch (wmId)		{		case IDM_ABOUT:			DialogBox(hInst, (LPCTSTR)IDD_ABOUTBOX, hWnd, (DLGPROC)About);			break;		case IDM_EXIT:			DestroyWindow(hWnd);			break;		default:			return DefWindowProc(hWnd, message, wParam, lParam);		}		break;	case WM_PAINT:		hdc = BeginPaint(hWnd, &ps);		// TODO: Add any drawing code here...		EndPaint(hWnd, &ps);		break;	case WM_DESTROY:		PostQuitMessage(0);		break;	default:		return DefWindowProc(hWnd, message, wParam, lParam);	}	return 0;}// Message handler for about box.LRESULT CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam){	switch (message)	{	case WM_INITDIALOG:		return TRUE;	case WM_COMMAND:		if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL) 		{			EndDialog(hDlg, LOWORD(wParam));			return TRUE;		}		break;	}	return FALSE;}[source]vs.[source]using System;using System.Drawing;using System.Collections;using System.ComponentModel;using System.Windows.Forms;using System.Data;namespace Test2{	/// <summary>	/// Summary description for Form1.	/// </summary>	public class Form1 : System.Windows.Forms.Form	{		/// <summary>		/// Required designer variable.		/// </summary>		private System.ComponentModel.Container components = null;		public Form1()		{			//			// Required for Windows Form Designer support			//			InitializeComponent();			//			// TODO: Add any constructor code after InitializeComponent call			//		}		/// <summary>		/// Clean up any resources being used.		/// </summary>		protected override void Dispose( bool disposing )		{			if( disposing )			{				if (components != null) 				{					components.Dispose();				}			}			base.Dispose( disposing );		}		#region Windows Form Designer generated code		/// <summary>		/// Required method for Designer support - do not modify		/// the contents of this method with the code editor.		/// </summary>		private void InitializeComponent()		{			this.components = new System.ComponentModel.Container();			this.Size = new System.Drawing.Size(300,300);			this.Text = "Form1";		}		#endregion		/// <summary>		/// The main entry point for the application.		/// </summary>		[STAThread]		static void Main() 		{			Application.Run(new Form1());		}	}}


I think it's kinda obvious which one is easier to write even a non-functional windows application.


Pls read my post carefully, what you have shown me is how the .NET framework makes you more productive in this case in creating a window. Also, if i wanted, i could use the .NET framework with C++ as well and i would not have been any less productive. As for game development, i don't write the code, i just copy the windows init code from Nehe or some other place or i can use GLUT. Don't confuse C# with the .NET framework, what im trying to ask is how C# on it's own makes you more productive than C++ without .NET or any API.

[edited by - GamerSg on December 15, 2003 12:53:50 AM]
Advertisement
I don''t have anything to offer the original post ... just wanted to address the point below.
quote:Original post by zarthrag
But so far, longhorn sucks.

I''m tired of people saying this ... it''s pre-alpha people ... it''s only a developer preview so you can start playing with the new apis.


Joel Martinez
http://www.codecube.net/
Joel Martinez
http://codecube.net
[twitter]joelmartinez[/twitter]
quote:Original post by GamerSg
But how does C# or Java make you 10 times more productive?


Ignore those claims. They are unprovable marketing hype.



--
Dave Mikesell Software & Consulting

[edited by - dmikesell on December 16, 2003 7:41:03 AM]
Ya i understand 10 times is over exaggeration, but even 50% productivity is something, i just want to see what language features are present in them that make you so much more productive? Everyone goes on blabbering about how Java/C# is the greatest thing since sliced bread, but whenever i ask how it increases productivity, i never get a satisfactory reply.

[edited by - GamerSg on December 16, 2003 7:44:08 AM]
quote:Original post by GamerSg
Ya i understand 10 times is over exaggeration, but even 50% productivity is something, i just want to see what language features are present in them that make you so much more productive? Everyone goes on blabbering about how Java/C# is the greatest thing since sliced bread, but whenever i ask how it increases productivity, i never get a satisfactory reply.

[edited by - GamerSg on December 16, 2003 7:44:08 AM]


This is pure speculation, but I would guess that most people who switch from C++ to C# or Java see the lack of memory issues to be the biggest win. Honestly, I don''t see the trouble in C++ regarding memory if you use RAII, smart pointers (e.g. boost::shared_ptr), and std::string and std::vector. Using these are second nature to me now and my programs don''t leak memory or suffer from buffer overruns.

Portability doesn''t have to be a problem, either. A wxWindows/OpenGL combination gives you a portable, windowed graphics application. If you need networking, use ACE.

I use both C++ and Java in my daily work (and Perl ;-)). Each does certain things better than the others. I prefer C++ in general because it allows me to work at a high level of abstraction and get close to the metal in the same program, but when a problem screams for Java or Perl, I use them. YMMV.


--
Dave Mikesell Software & Consulting
Geee some ms zealots will hate me but here''s some of my points
.history has proven that no software is good until release 3
.most problems i read in the thread related to c++ comes from things that arised after the design and heavy usage of c++ and that''s something c# still doesn''t have: history and proven record (well ms can *prove* it has history, if you''re willing to believe them...)
.c# portability is still a marketing speech rather than reality, specially in game development (or does somebody wrote a directx emulation under linux or something?, portability needs to exist also at library level or it becomes just a bluff) will it be a reality in the future? dunno but i guess that ms interests and past history is the only thing you can take into account when you look at the future
.gc goshhhhh i never seen a topic more misused than that, gc is almost as good as evil at the same time, in my own experience on large projects it just changed the place were problems appeared in the past: with gc i''ve seen many applications suffering performance and memory leaks (yes, holding references in c# or java is a very common error i''ve seen) whenever in the past the problems were illegal access to previously freed memory, pointer arithmetic errors or things like that.
.once your application has enough complexity or size, you *will* have to peek inside the lang and the GC stuff for squeezing bits and nanoseconds on performance, unless of course your target is space invaders/tetris or if you are going to use just as a glue.
.c# probably has some good enhacenments over c++ since it has been designed *based on* and later than c++

My personal opinion is that is a good time to peek inside it but not to take very seriously (*yet*)

Memory issues are not a problem for me, it was when i started with C++, but with memory leak detectors and other coding methods, they are not a major problem.
quote:Original post by dmikesell
quote:Original post by GamerSg
But how does C# or Java make you 10 times more productive?


Ignore those claims. They are unprovable marketing hype.



--
Dave Mikesell Software & Consulting

[edited by - dmikesell on December 16, 2003 7:41:03 AM]



Can you actually prove that claim yourself?

Why is it that our company has a documented AND fully researched 39% increase in productivity since switching to C#?

Sure it's not 10 times the productivity, but hey an extra 40% increase cuts out 4.8 months out of the year.


EDIT: Oh sorry I forgot some reasons:

A) When you work on Enterprise projects.. you always have bugs and memory problems. If you say you don't, than you haven't worked as a professional programmer on enterprise projects, because they are HUGE with a team of guys. It isn't just one guy sitting in his basement going over his code with a fine-tooth comb.

- C# solves this by getting rid of 80% of OUR DOCUMENTED DEBUGGING TIME. There are no memory problems. Sure we have to profile to make sure we are using memory efficiently but we had to do that in the old days of using C++ as well.


B) Please stop trying to seperate the C# language from the .NET framework and CLR, as they add up to one.

- Why? C# was built to be used with the CLR and .NET framework, ALSO it was built FOR the .NET framework. So yes while you can use managed extentions in C++ it is not native to the language like C# is. If you think you could write a managed C++ application as the same speed you could write a C# application, you are day-dreaming =]


C) Object-Oriented code is now standard in C#.

- Now when you work in a team, everybody does not code the exact same way as you. And contrary to your popular belief, people make mistakes and bad coding errors or leave things saying "I'll fix it later", and that time doesn't come until later down the road.

With C# you can't jump into procedural coding mode, and everything has a definate design. Sure you can somewhat built delegates/events using C++, and abstractions, etc... but they are not built into the core language. The C# core language itself enforces type-safe object-oriented code.


I could keep going but I have a lot of work today =]

[edited by - Imperil on December 16, 2003 9:42:52 AM]
well 3 months ago i was a C# zelot its a great language and i was able to develop it fast. So why the 3 months ago part. well I spend the entire time from the managed DirectX release untill 3 months ago writing tutorials and examples. ive racked up quite a few and they all work just fine and the code is easy to read. there is just one problem, they take 30-40 megs of ram for rendering a triangle with fog. That is retarted, so i went the only way that would give me better performance and would definately work on Longhorn(non MFC) C with a sprinklying of ASM. I started in Pure ASM but saw the advantages of C. So yes i look at the C# developers and a bit niave but i look at the c++ developers a knowlingly wastfull. Just my attempt at a flame war.
quote:Original post by HippieHunter
well 3 months ago i was a C# zelot its a great language and i was able to develop it fast. So why the 3 months ago part. well I spend the entire time from the managed DirectX release untill 3 months ago writing tutorials and examples. ive racked up quite a few and they all work just fine and the code is easy to read. there is just one problem, they take 30-40 megs of ram for rendering a triangle with fog. That is retarted, so i went the only way that would give me better performance and would definately work on Longhorn(non MFC) C with a sprinklying of ASM. I started in Pure ASM but saw the advantages of C. So yes i look at the C# developers and a bit niave but i look at the c++ developers a knowlingly wastfull. Just my attempt at a flame war.



If you were knowledgable you would realize you are using a framework of an OS on top of another OS and it needs to be loaded into RAM.

Now if you had 2 C# applications going (lets just say the exact same program) you would see this:

Application 1: 30-40MB RAM
Application 2: 1-5MB RAM

lol you need to learn to seperate the .NET framework from your application when profiling. It is the .NET framework that takes about 25MB RAM or so, and thereafter it takes nothing, only your applications.

If you think 25MB of RAM for the framework of an OS is a lot of RAM, you are obviously a little behind in technology, considering your average system sold in the last 2 years has a minimum of 256MB RAM and usually 512MB RAM.

This topic is closed to new replies.

Advertisement