V.Basic, C# or C++?

M

mickn66

Regular
Joined
Nov 2, 2002
Messages
53
I know a couple of people have discussed this in a couple of threads, but I'd like to get some more opinions. I program in V.B. Net - from what I understand there's no real difference between Vb and C#, and that if you know VB.Net, you can spend a day or two learning the c# syntax and once you do that you know c# as well, but what about c++? I'm fairly familiar with it, but not very. I've heard that it's somehow more poawerful than VB.NET - what is it good for that VB isn't as good for? Any information would be welcome :) Thanks

Mick
 
I've never really understood the point of C++.NET myself. VB.NET can do everything the .NET framework is capable of, as is C#. If you need to do low-level and/or dependency free programming you'd use regular C++.

You use C++.NET when you still want to use the .NET framework, but need to do low level programming, but most of that is possible in VB.NET... I can't think of anything you can do in C++.NET that you can't do in C#.
 
I have a friend that has been trying to get me into going with C++, obviously he thinks that VB.NET is not very good, especially its speed. Also I've heard that VB.NET inherits a lot of bad programming habits?

I only program in VB.NET btw :) ....and HTML.......and sometimes JavaScript.......
 
Managed C++ has some advantages, like being able to freely mix unmanaged and managed code, and you also get all the bells and wistles that C++ provides (Templates, etc). It's interesting to say least, but the syntax is far from elegant (and can get quite messy) when compared to C# syntax.
 
VB.NET adopts bad coding styles only if you do. You can make excellent code in .NET or you can make very messy code. VB.NET does have VB6 compatability functions that you should never use (C# doesn't), but as long as you don't use them, VB.NET is perfectly fine.
 
.Net is faster than Unmanaged code. Compiling for the system it is being run on and compiling at runtime means it can squeeze every bit of performance from the computer(hardware wise) as possible.

The only disadvantage of .Net is that not all of Windows' features have been implemented in the framework forcing you to resort to APIs [Framework has no sound or multimedia classes]. However, just using Managed code will allow you to write a program that is more efficent than a C++ application with even less effort.

C++.Net is just C++ 6 with Managed extensions. It still runs slower than a fully Managed application anyway, though. The industry standard (Looking at some requirements to apply for jobs in the game industry) say C# skills are required meaning everyone is slowly moving to .Net . Using VB.Net may not get you a job but it supports everything C# does anyway.

If you know VB.Net you can move to C# reasonably easily as long as you've used C++ or Java or something with C syntax but it has the same features as VB.Net anyway.

If you keep using VB.Net always turn on Option Strict (Project Settings) then everything produced should be almost exactly the same as C#. The generated MSIL has been shown to be a bit longer than C# MSIL but that's most likely because C# was designed for the Framework to begin with rather than adapted like VB.
 
Last edited:
.NET isn't faster than unmanaged code. Potentially, unmanaged code is much faster... If you want speed when doing graphics, you need to use DX9 or GDI32. Obviously with GDI32 you don't get the insane flexibility of GDI+, but you get the raw speed. In DX9 you do get flexibility and speed, but you get a large overhead.

The reason sound and multimedia aren't part of the framework is that they are too platform dependent for them to be properly ported to another platform without changing it.

C++.NET is actually C++ 7 with managed extensions. You can also create an unmanaged C++ 7 project from within the .NET IDE and it won't use the .NET framework at all.

And I don't know what you mean about the IL being longer in VB. There should be no reason for that, as long as you do things exactly the same way in both languages. VB.NET was designed for the .NET framework, as was C#. VB.NET isn't just a version of VB6 or something..
 
AndreRyan:
.NET can be as fast as unmanaged code in some instances, but there's no way that it's faster.

VolteFace:
I'd think that anything that uses the Windows API is pretty platform dependant, yet there are tons of classes in the .NET framework that do just that. There's the mono-project that's trying to port the .NET framework to Unix platforms and what not, but that's an entirely seperate download. I think think in future releases we'll see things like a music class library along with the DirectX SDK being included with the .NET framework.

C# was built from the ground up to use .NET. VB.NET, just like other 3rd party .NET languages, was adapted to use the .NET framework.
 
The framework code definately internally uses Windows API to implement it, but it could easily be transferred to another platform.

For example, System.Graphics wraps Windows' internal graphics functions (like the GDI32). Obviously the GDI32 wouldn't work on Linux, but the Mono project's implementation probably wraps something different, like Gtk+ for its graphics. That means that although the implementation of the .NET framework is different, the code to create a window and draw an image is the same on both platforms.
 
System.Graphics wraps GDI+. .Net is potentially faster than Unmanaged. This is because it compiles at runtime which allows for runtime compilation options that aren't avaliable in an Unmanaged C++ compile. .Net wraps the Windows API but this does not affect the fact that if the processor has special capabilities and native functions the program will be adapted to use them without you having to write any extra code where as in an Unmanaged application you would need to manually check for each feature and use it if possible, most likely, manually. Even if you do this that doesn't mean the program will adapt to new Native aditions that weren't around when you wrote the application which .Net probably will because of the updates to the framework.

It is still stupid of Microsoft to leave out a basic Sound class(Wrap PlaySound, anything is better than nothing), Macintosh and Linux both have sound support so not even having a class with just Play, Pause and Stop is irrational.

GDI+ is a bit slower than GDI32 but this has nothing to do with .Net, blame GDI+'s new features like translucency.


I never was insulting VB.Net, I always use VB.Net because I've always hated C syntax(case sensitivity has always annoyed me). It has, however, been shown that in a VB.Net application and a C# application that perform exactly the same thing, the VB.Net application will have an extra three lines every 30 or so. There was some experiment that I read somewhere, I'll post the link if I find it again.
 
Last edited:
I made my own example, it's not particularly good because the .Net compiler optimises the program and ejected some of the code
Visual Basic: 
Module Module1

    Sub Main()
        Console.WriteLine("Testing VB")
        Console.Read()

        Dim Exc As System.Exception
        Dim IOExc As System.IO.IOException
        IOExc = New System.IO.IOException("Text")
        Exc = CType(IOExc, System.Exception)

        Console.WriteLine("Finished")
        Console.Read()
    End Sub

End Module
Code: 
.method public static void  Main() cil managed
{
  .entrypoint
  .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 ) 
  // Code size       46 (0x2e)
  .maxstack  1
  .locals init (class [mscorlib]System.Exception V_0,
           class [mscorlib]System.IO.IOException V_1)
  IL_0000:  ldstr      "Testing VB"
  IL_0005:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_000a:  call       int32 [mscorlib]System.Console::Read()
  IL_000f:  pop
  IL_0010:  ldstr      "Text"
  IL_0015:  newobj     instance void [mscorlib]System.IO.IOException::.ctor(string)
  IL_001a:  stloc.1
  IL_001b:  ldloc.1
  IL_001c:  stloc.0
  IL_001d:  ldstr      "Finished"
  IL_0022:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0027:  call       int32 [mscorlib]System.Console::Read()
  IL_002c:  pop
  IL_002d:  ret
} // end of method Module1::Main
C#: 
namespace CsharpSpeed
{
	/// <summary>
	/// Summary description for Class1.
	/// </summary>
	class Class1
	{
		/// <summary>
		/// The main entry point for the application.
		/// </summary>
		[STAThread]
		static void Main(string[] args)
		{
			//
			// TODO: Add code to start application here
			//
			Console.WriteLine("Testing C#");
			Console.Read();

			System.Exception Exc;
			System.IO.IOException IOExc;
			IOExc=new System.IO.IOException("Text");
			Exc=(System.Exception)IOExc;

			Console.WriteLine("Finished");
			Console.Read();
		}
	}
}
Code: 
.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
  .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 ) 
  // Code size       44 (0x2c)
  .maxstack  2
  .locals init (class [mscorlib]System.IO.IOException V_0)
  IL_0000:  ldstr      "Testing C#"
  IL_0005:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_000a:  call       int32 [mscorlib]System.Console::Read()
  IL_000f:  pop
  IL_0010:  ldstr      "Text"
  IL_0015:  newobj     instance void [mscorlib]System.IO.IOException::.ctor(string)
  IL_001a:  stloc.0
  IL_001b:  ldstr      "Finished"
  IL_0020:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0025:  call       int32 [mscorlib]System.Console::Read()
  IL_002a:  pop
  IL_002b:  ret
} // end of method Class1::Main
The C# code here is 2 (or 3) lines shorter than the VB.Net version even though they are virtually identical.
 
Managed code can quite easily be faster than unmanaged code, I proved this in another thread a few weeks ago. C# code that just iterates over a loop and increments a counter always beat its C counterpart.

The next release of .NET has a managed class to play sounds.
 
divil is refering to this topic;
http://www.xtremedotnettalk.com/showthread.php?s=&threadid=71822

Heh there's also a mention of C#Builder in there which I never noticed.

Anyway... this is a good test for loops of simple mathematics, unfortunately not all programs are built with just loops. They're also built with things like ADO.NET, Managed/Unmanaged DirectX, Windows GDI/.NET GDI+, etc. Granted Quake II .NET isn't a great example itself, it does prove that .NET is not faster then C++ but it has the potential to be. In which case we're still stuck without any proof.

I am just stuborn in my ways. :P I refuse to believe anything unless I see 100% absolute proof that a .NET application is running faster then a native application (C++).

Despite all this, .NET still rocks. Regardless of the vs language argument, the development speed of .NET makes more then up for any deficiencies it may or may not have.

As for managed sound; awsome. :D
 
Back
Top