Getting Started With Visual C++/CLI

Sup !

I would be writing a series of tutorials for Visual C++/CLI. Before you can start following C++/CLI tutorials, you need to understand what .NET Framework is and its core elements that makes it what it is today. You also need to understand basic syntax and managed types of C++/CLI. This is what exactly this tutorial will provide.

Prerequisites:

¦ Microsoft Visual Studio 2008 or 2010. Visual Studio Ultimate Key:

YCFHQ-9DWCY-DKV88-T2TMH-G7BHP

¦ At-least some basic knowledge of C or C++ language.
¦ Some passion to learn new stuff.

THE .NET FRAMEWORK:

The .NET Framework is a central concept in Visual C++ 2010 as well as in all the other .NET languages from Microsoft. The .NET Framework consists of two elements: Common Language Runtime [CLR] in which your application executes, and a set of libraries called the .NET Framework class libraries. The .NET Framework class libraries provide the functional support your code will need when executing with the CLR, regardless of the programming language used, so .NET programs written in C++, C#, VB or any of the other languages that support the .NET Framework all use the same .NET libraries.

There are two kinds of C++ applications you can develop with Visual C++ 2010. You can write applications that natively execute on your computer [Those, the processor understands directly without translation]. These applications are referred to as native C++ programs. You can also write applications to run under the control of the CLR in an extended version of C++ called C++/CLI. These programs are referred to as CLR programs, or C++/CLI programs.

CLR and CLI:
The Common Language Runtime [CLR] is a standardized environment for the execution of programs written in a wide range of high-level languages including Visual Basic, C#, and of course C++. The specification of the CLR is now embodied in the European Computer Manufacturers Association [ECMA] standard for the Common Language Infrastructure [CLI], the ECMA-335, and also in the equivalent ISO standard, ISO/IEC 23271, so the CLR is an implementation of this standard. You can see why C++ for the CLR is referred to as C++/CLI — it is C++ for the Common Language Infrastructure.

If you are curious, you can read full Common Language Infrastructure specification here: ECMA 335 - CLI Specification

The Common Language Infrastructure [CLI] is essentially a specification for a Virtual Machine environment that enables applications written in diverse high-level programming languages to be executed in different operating systems without the original source code being changed or replicated. The CLI specifies a standard Common Intermediate Language for the virtual machine, to which the high-level code is compiled. It is reffered to as MSIL or simply IL. The CLI also defines a common set of data types called the Common Type System [CTS] that should be used for programs written in any programming language targeting a CLI implementation.

Difference between CLR and CLI:
The CLR is just one implementation of the CLI specification that executes under Microsoft Windows on a PC. There will undoubtedly be other implementations of the CLI for other operating system environments and hardware platforms. You'll sometimes find that the terms CLI and CLR are used interchangeably, although it should be clear that they are not the same thing. The CLI is a standard specification while the CLR is Microsoft's implementation of the CLI. Microsoft has created several language compilers that target the runtime: C++/CLI, C#, Visual Basic, F#, Iron Python, Iron Ruby, and an Intermediate Language (IL) Assembler.

Choosing a Language:
Now that you know what .NET Framework is and what capability its core elements offer, you must decide which programming language to use. This task is usually difficult because different languages offer different capabilities. For example, in unmanaged [Native] C/C++, you have pretty low-level control of the system. You can manage memory exactly the way you want to, create threads easily if you want to, and so on. Microsoft Visual Basic 6, on the other hand, allows you to build UI applications very rapidly and makes it easy for you to control COM objects.

The CLR is just what its name says it is: a runtime that is usable by different and varied programming languages. The core features of the CLR [such as memory management, assembly loading, security, exception handling, and thread synchronization] are available to any and all programming languages that target it. For example, the runtime uses exceptions to report errors, so all languages that target the runtime also get errors reported via exceptions. Another example is that the runtime also allows you to create a thread, so any language that targets the runtime can create a thread.

At runtime, the CLR has no idea which programming language the developer used for the source code. This means that you should choose whatever programming language allows you to express your intentions most easily. You can develop your applications in any programming language you desire as long as the compiler you use to compile your code targets the CLI or CLR.

So, if CLR do not care and do not have any idea about what language is used at runtime, what is the advantage of using one language over another ? The answer is simple. Different programming languages allow you to write code using different syntax. For writing compilers, F# would be a much better choice when compared to C# and VB.NET. Similarly, APL programming language, although syntactically complex, can save a lot of time writing mathematical and financial applications. You should choose a language that best describes your taste in terms of syntax and functionality.

The following figure shows the process of compiling source code into managed modules:

Parts of managed module:

PE32 or PE32+ header: The standard Windows PE file header, which is similar to the Common Object File Format [COFF] header. If the header uses the PE32 format, the file can run on a 32-bit or 64-bit version of Windows. If the header uses the PE32+ format, the file requires a 64-bit version of Windows to run. This header also indicates the type of file: GUI, CUI, or DLL, and contains a timestamp indicating when the file was built. For modules that contain only IL code, the bulk of the information in the PE32[+] header is ignored. For modules that contain native CPU code, this header contains information about the native CPU code.

CLR Header: Contains the information [interpreted by CLR] that makes this a managed module. The header includes the version of the CLR required, some flags, the MethodDef metadata token of the managed module’s entry point method [Main method], and the location/size of the module’s metadata, resources, strong name, some flags, and a few other things.

Metadata: Every managed module contains metadata tables. There are two main types of tables: tables that describe the types and members defined in your source code and tables that describe the types and members referenced by your source code.

IL Code: Code the compiler produced as it compiled the source code. At runtime, the CLR compiles the IL into native CPU instructions.

Why To Code In C++/CLI:

Why C++/CLI

If you can't bother reading the complete article, here are a few points you should consider:

¦ Performance: C++/CLI offers unparalleled speed and performance compared to other .NET languages.
¦ Support for Native code: What makes C++/CLI the most powerful .NET language is that it allows you to mix pure C/C++ code right in between managed code [.NET]. You don't have to make ugly calls to P/Invoke. Don't have to include dozens of constants and structs just to call a native function. You simply include the library and make calls to native functions like you do in pure C++.
¦ Familiar Syntax: You have a strong background in C++ and you can't bother learning a new language or you simply love C++ syntax, you are going to use C++/CLI.

OK, enough of the .NET Platform details. Let's move to more interesting stuff.

Creating a New C++/CLI project in Visual Studio:

Open Visual Studio from Start Menu: All Programs: Microsoft Visual Studio 2008/2010: Microsoft Visual Studio 2008/2010 [Executable] as shown in the figure below:

Once Visual Studio is loaded, Creating New Project by one of the following methods:

¦ Using a shortcut key: CTRL+Shift+N
¦ Navigating through File Menu: Goto File Menu: Rollover New: Click Project...
¦ Clicking the New Project button on Start Page: Click New Project button as shown in the image below:

New Project dialog will load up. Choose Visual C++ from the Installed Templates. For the sake of learning basics of C++/CLI first [Without going through the complexities of GUI app], we'll create a CLR Console Application. So, select it from the list of project types. Give it a meaningful name and press OK to finalize project creation, as shown in the figure below:

Alright, after your new project is loaded, the following code appears in your code window:

Code:

// IntroToCPPCLI.cpp : main project file.

#include "stdafx.h"

using namespace System;

int main(array<System::String ^> ^args)
{
    Console::WriteLine(L"Hello World");
    return 0;
}

Note: If your project is targeting .NET Framework 3.5, you will need to use v100 Platform Toolset. To do this, goto Project Menu and click Properties. Project Properties dialog will open. Then set the Platform Toolset option to v100 as shown in the figure below:

Let me explain this code line by line:

Code:

// IntroToCPPCLI.cpp : main project file.

This line is a standard C++ comment. Comments are completely ignored by the compiler. They are just there for your own clarification of code.

Moving on:

Code:

#include "stdafx.h"

This line uses a standard C++ Pre-processor directive, include. Pre-processors directives always start with # sign. The include directive tells the compiler to include the code written in the file which is enclosed in either double quotes, or in between <>. What's the difference between using either of the method to include the file ? When enclosing the file in brackets, you are telling the compiler to look for the file in the folder reserved for header files. You can find this folder in your Visual Studio installation folder. In my PC, header files are located in:

Code:

C:\Program Files\Microsoft Visual Studio 10.0\VC\include

When enclosing file in double quotes, you are telling the compiler to look for the header file in project's Parent and Debug folder.

For Example:

Code:

C:\Users\Username\Documents\Visual Studio 2010\Projects\IntroToCPPCLI\IntroToCPPCLI

You can find the "stdafx.h" file in this directory (IntroToCPPCLI is your project name). If you open this file, you'll just one line:

Code:

#pragma once

#pragma once is a non-standard but widely supported preprocessor directive designed to cause the current source file to be included only once in a single compilation. Thus, #pragma once serves the same purpose as #include guards, but with several advantages, including: less code, avoiding name clashes, and improved compile speed.

Back to the include directive. Here, in this code, stdafx.h is enclosed in the double quotes, which has a very specific and special meaning to the C++ compiler. It is used for telling the compiler to use pre-compiled header files.

Pre-Compiled header:
When using pre-compiled header, the compiler includes the header file; for example: <myheader.h> only once in the application. [Remember #pragma once inside the "stdafx.h" ?]

You can read about it more here: Precompiled Header

If you don't want to use pre-compiled header, you can turn it off in the project properties as shown below:

Moving to the third line;

Code:

using namespace System;

This line uses a namespace System using the keyword 'using'. Namespaces allow you to group your code under a unique name. When you work under team projects, there is a very real chance that the same name for classes, functions, and so on can be used by more than one coder. To allow same names to be used by multiple coders working on a same project or whatever reason, namespaces were introduced.

Suppose you have two classes named MathFunctions from different sources and you want to use them in the same namespace / file:

Code:

namespace AllMathFunctions
{

class MathFunctions

{

};

class MathFunctions

{

};


}

The above code will fail to compile, because the MathFunctions class is defined twice in the same file under same scope. To resolve this, we enclose one of them or both in meaningful namespace:

Code:

namespace AllMathFunctions

{
    namespace SourceA
    {
        class MathFunctions

        {

        };

    }
    namespace SourceB
    {
        class MathFunctions

        {

        };

    }
}

Now, we have grouped these classes using namespaces and we can explicitly tell the compiler which class to use:

Code:

AllMathFunctions::SourceA::MathFunctions MFunctions;

The above code declares a new instance of MathFunctions class. The MathFunctions class referred here is defined using the scope resolution operator ::. The scope resolution operator helps to identify and specify the context to which an identifier refers. Using scope resolution operator you drill down in namespaces until you precisely refer to a particular namespace or class. In this case, we are using the MathFunctions class defined by SourceA.

Next, we have a function that has a special meaning to the C++ compiler. This function is called main:

Code:

int main(array<System::String ^> ^args)
{
    Console::WriteLine(L"Hello World");
    return 0;
}

This function, main, is the entry point of the C++ program. When the compiler starts compilation, it tries to find main function. If it cannot find it, it raises a compiler error indicating that the entry point function is missing from the source code.

The first line of this code defines the signature of the main function. Every function returns a value with the exception of void that makes it a method [Means, nothing is returned to the caller]. Here, this function returns an integer value to the operating system / caller upon exiting.

After the function name, you see parameters in the round brackets. i.e;
(array<System::String ^>^ args)

You can define any number of parameters inside these brackets, separated by a comma. Here, as you can see there is only one parameter. It looks frightening at first sight but it's not.

Let's break it down:
array is a reserved keyword that is used to denote an array. An array is a series of elements of the same type placed in contiguous memory locations that can be individually referenced by adding an index to a unique identifier.

In pure C++, here's what an array variable looks like:

Code:

int x[5] = {0,1,2,3,4};

Here, array's type is integer (int), it's variable name is x, it has the capacity to store 5 integers in contiguous memory locations, and each of the integer in these locations are assigned an initial value in the curly braces {}. To access a value from an array variable, you use the indexing operator, just as you use it to define the capacity of the array. So, if I want to access the 2nd element of the array x, I would write:

int elem = x[1];

Here, 1 is called index. In arrays, indexes are zero-based. This means, if I want to access the 2nd element, I would write x[1]. Similarly, if I want to access 5th element, I would write x[4]. I would write x[0], for accessing the first element of the array.

As you can see, in the C++/CLI, arrays are defined using a different syntax.

(array<System::String ^>^ args)

Here, the name of the parameter is args, and it is of generic type.
Generics allow the use of to-be-specified-later types. They provide a means of passing a data type as an argument of another type. For Example: We are passing String type to array, which is also a type. The greatest benefit of generics is that they are type-safe. Prior to generics, generalization was accomplished using Object type, which is the ultimate root type of all other types in .NET. This means that there was no way of checking, at compile-time, if I am passing a string to a type that should accepts an integer. To prevent this, generics allow specific types to be specified when declaring them. So, as you can see in the parameter array<System::String ^>^ args we are restricting the array to only accept string values. If any other type of data is supplied, the program will not compile at all, hence preventing an error at runtime (while the application is running).

Still focusing the parameter args (args is the name of the parameter), let me describe you the way managed types are specified in C++/CLI.

Note: There are two types of types. Value types and Reference types. Without going in to detail at the moment, just keep in mind that Value types are stored in Stack (Memory area), while Reference types are stored in Managed Heap (A special memory area reserved by C++ compiler).

Here's how you write a managed type in C++/CLI:

Code:

System::String^ str = "A quick brown fox jumped over the ten lazy dogs.";

Focusing on System::String^ part; System is the namespace where all the standard managed types reside. String is the managed reference type we are going to use here. We use scope-resolution operator :: to specify that the String reference type resides in the System namespace. Then comes the handle ^. The ^ punctuator (pronounced as cap) represents a handle to a managed object. Handles are managed references to the objects on managed heap. Means, that instead just containing the memory location of a native (pure C++) object (via the use of pointers), they contain reference to the C++/CLI object.
Then comes the variable name, i.e; str. Right after defining the name of the variable, the variable str is set to hold some initial string data. String data is enclosed in double quotes as you can see.

Similarly, if I want to use an integer, I can use the managed type Int16, Int32 or Int64. These differ in the range of integers values they can store.

Code:

System::Int32^ V = 50;

As, I stated earlier, you can mix native C++ code right in between the managed code. So, I can write the above statement as:

Code:

int V = 50;

So, once again, let's took a look at the parameter from a top view:

int main(array<System::String ^>^ args)

You specify the type for the a generic parameter in these <> brackets.
So, here array type takes the String parameter in the brackets. You'll notice that there is another handle right after the <> bracket is closed. It is the handle of the array generic. So, for every managed type there is an handle. Finally you have args. This is simply the name of the parameter.

So, why is this parameter here and what does it do ?
Your application always start execution at main method. Windows allow an application to take arguments as it starts execution. Arguments allow you to get specific information from the operating system that may or may not relate to your application.

For Example:

Code:

C:\myapplication.exe "/hide"

In the above snippet, "/hide" is the argument that is passed to the application by the operating system. You can use it perform a specific task. For example, here the purpose of this parameter was to hide the application as soon it starts.

I can use more than one argument, in fact any number of arguments I want.

So, by passing the an array parameter to the main function, you can access all these arguments in your code.

Here's how I would access the first argument passed to the application by OS:

Code:

System::String^ FirstArgument = args [0];

args[0] accesses the first argument. I already told you how you can store and retrieve array values using the indexing operator [].

Moving on, we have the body of the function specified by the curly brackets:

{

}

Your application runs as long as the statements are executing under these brackets. Anything inside these brackets is a part of the function.

Inside the body, we have 2 statements.

Code:

Console::WriteLine(L"Hello World");
return 0;

The first one, as you might expect, displays the obligatory Hello World string on the console.

Focusing on it, the Console is a class that resides in System namespace. If we hadn't used the namespace System in the second line of our code, we'll have to write this line as:

Code:

System::Console::WriteLine(L"Hello World");

Since, we are using that namespace, any class in that namespace is readily available without writing the namespace name over and over again.

Console class is followed by WriteLine function. Here WriteLine function is getting a string literal "Hello World" as a parameter. Note, that String data is not the only data that is accepted by the WriteLine function. There is a wide range of data WriteLine function accepts. I won't go in detail at this time, but will explain it in some other tutorial.

You'll notice that the parameter has the alphabet L before the string literal "Hello World". It is used for converting the wide-string literals. Ignore it for this time.

Code:

Console::WriteLine("Hello World");

Next, we have a return statement:

Code:

return 0;

return is a standard keyword, and is used to return some value to the caller of the function. Here, since the caller of the main function is the operating system, we are returning with an integer 0, indicating that program has executed successfully and now you are ready to release any unreleased resources of the program. Even, if you don't explicitly return an int value indicating success to operating system, the operating system gets to know that your application has ended execution. There are other integer values that have special meaning to operating system, that can be returned from the function.

Finally, the end of the function (in this case, end of application) is reached with the closing bracket }.

Now that you have a complete understanding of what that code does, you can execute it by pressing F5 from your keyboard or by going to Debug menu, and clicking Start Debugging. You can also execute your application by pressing the Green Play button from the debug toolbar as shown in the figure below:

Assuming, you have written the correct code, your application will start compiling and upon successful compilation, will start the executable produced as a result of compilation. If you are running the default code produced by Visual Studio when creating a new C++/CLI project, the application will print Hello World on the console window and will immediately close after that. You'll hardly see Hello World printed on the console window.

To avoid this, you'll have to command the program to stop and wait for me before closing the application. Just below the

Code:

Console::WriteLine("Hello World");

; add this line:

Code:

Console::ReadLine();

This statement uses the ReadLine function to stop the program and wait for you to enter some string value. After entering the value you have to press enter for submitting the value you entered to this function. Since, there is no more statements in the program after this statement, program will terminate indicating successful execution. ReadLine function is usually used to store user input received from the user, but we used it to pause the program for sometime. Here's the final code:

Code:

int main(array<System::String ^>^ args)
{
	Console::WriteLine("Hello World");
	Console::ReadLine();
    return 0;
}

Now, if you run the application, you'll not only see Hello World printed on the screen but your program will also pause until you press Enter key from your keyboard.

That is all you need to know to get started with Visual C++/CLI. As I said in the start of the tutorial, this tutorial will be used as a reference by the up coming Visual C++/CLI tutorials. I will explain new things on those tutorials as they come along.

Do read some of the Wiki links I provided while explaining .NET Framework and its core components. It will help you a lot in understanding this powerful and important language.

Although the title says "Getting Started With Visual C++/CLI" and you haven't done anything visual yet, this tutorial is the base for following the upcoming Visual tutorials.

Also, take note that English is not my native language, but I have tried my best explaining things to you. If there are any grammatical mistakes or mistakes that relate to my English, sorryz for that ;P

I know that for some of you it might be hard at first to grasp but read it a couple of times and it'll start making sense to you. Still, if you have any question, feel free to ask.

Cheers,
Hassan

Me Gusta. ☺☺☺

ARGHHH SOOOOO LONGGGGGGGGGGGG

Originally Posted by Mr-[S]nipe

ARGHHH SOOOOO LONGGGGGGGGGGGG

I know. I had to explain it properly, so didn't noticed I wrote it that long ;P
@Mr-[S]nipe

Originally Posted by Hassan

I want to use native C++ libraries in .NET ? I also want to run my code at least twice as faster than other .NET languages ? Yeah, sure C# and VB.NET is the best choice.

{Not saying that C# and VB.NET are bad languages. They are pretty epic.}

*applause*

o.O

lol well I like your tutorial

Thank you this has really helped me get started with everything!

if I use visual c++ can people still use .net reflector to decompile my code like they can with c# and VB?

Originally Posted by cout<<

if I use visual c++ can people still use .net reflector to decompile my code like they can with c# and VB?

I think so. But you can use .NET Reactor to obfuscate your program so it can not be decompiled using .NET Reflector.

Thank you so much for this Tutorial, It helped me a lot ! :}

As i am going through this .. i find myself in a constant state of awe

AWESOMENESS!!!

Originally Posted by Hyper Hax

As i am going through this .. i find myself in a constant state of awe
AWESOMENESS!!!

. I think there's enough interest in CLI/C++. Maybe it's time for another tutorial.