Nish [Chat Host]:
Hello guys - I am the chat host for today's topic - Visual C++ 2005 Language Enhancements
Prakash Jha:
Oh...gr8....Hi Nish.....
Nish [Chat Host]:
I'll be using this web-interface - which means we won't have a special question-option - it'll be just regular chat
Nish [Chat Host]:
If you don't have any specific questions regarding the chat, can I begin?
Prakash Jha:
ok...
Prakash Jha:
pls....go ahead....!!
Nish [Chat Host]:
I'll be giving a quick overview of the new features in VC++ 2005 - and will focus on the new C++/CLI specification
Nish [Chat Host]:
While I am doing that, you can ask any questions relating to the current-topic-context
Chakravarthy:
pl go ahead
Nish [Chat Host]:
Starting with VC++ 7, MS added the managed extensions to the C++ compiler - called Managed C++ or MC++ which C++ programmers accepted with mixed reactions. There were several issues with MC++ :-
Nish [Chat Host]:
[Excerpt from one of my articles]
Nish [Chat Host]:
* Ugly and twisted syntax and grammar - All those double underscores weren't exactly pleasing to the eye. * Second class CLI support - Compared to C# and VB.NET, MC++ used contorted workarounds to provide CLI support, for e.g. it didn't have a for-each
Nish [Chat Host]:
* Poor integration of C++ and .NET - You couldn’t use C++ features like templates on CLI types and you couldn’t use CLI features like garbage collection on C++ types.
Nish [Chat Host]:
* Confusing pointer usage - Both unmanaged C++ pointers and managed reference pointers used the same * based syntax which was quite confusing because __gc pointers were totally different in nature and behavior from unmanaged pointers.
Nish [Chat Host]:
* The MC++ compiler could not produce verifiable code
Nish [Chat Host]:
Okay?
nsgirish:
Yup
Nish [Chat Host]:
On October 6th 2003, the ECMA announced the creation of a new task group to oversee development of a standard set of language extensions to create a binding between the ISO standard C++ programming language and Common Language Infrastructure (CLI). It was
Nish [Chat Host]:
Note - ECMA is an international standards body
Nish [Chat Host]:
It was also made known that this new set of language extensions will be known as the C++/CLI standard, which will be supported by the VC++ compiler starting with the Whidbey release (VS.NET 2005).
Nish [Chat Host]:
Here's a quick overview of what C++/CLI offers us (advantages compared to the previous MC++ syntax) :-
Nish [Chat Host]:
* Elegant syntax and grammar -This gave a natural feel for C++ developers writing managed code and allowed a smooth transition from unmanaged coding to managed coding. All those ugly double underscores are gone now.
Nish [Chat Host]:
* First class CLI support - CLI features like properties, garbage collection and generics are supported directly. And what's more, C++/CLI allows us to use these features on native unmanaged classes too.
Nish [Chat Host]:
* First class C++ support - C++ features like templates and deterministic destructors work on both managed and unmanaged classes. In fact C++/CLI is the only .NET language where you can *seemingly* declare a .NET type on the stack or on the native C++ he
Nish [Chat Host]:
the native C++ heap
Nish [Chat Host]:
* Bridges the gap between .NET and C++ - C++ programmers won't feel like a fish out of water when they attack the BCL
Nish [Chat Host]:
* The executable generated by the C++/CLI compiler can now be fully verifiable (depending on the compiler switch used)
Nish [Chat Host]:
Ok. Now shall I jump into some C++/CLI syntax ?
SV:
Yes, do so
Prathap:
yea sure
Nish [Chat Host]:
Here's how you declare a ref class (managed class - or class for C#ers)
Nish [Chat Host]:
ref class A
{
};
ref struct B {};
Nish [Chat Host]:
In C++, both structs and classes can be managed (ref types) - this is different from C# behavior where classes are always ref types and structs are always value types.
Nish [Chat Host]:
Declaring value types is similar :-
Nish [Chat Host]:
value class A{};
value struct B{};
Nish [Chat Host]:
This same syntax is used for interfaces, enums etc
Nish [Chat Host]:
interface class IA{};
enum struct Dat{};
Nish [Chat Host]:
Native types are declared same as in traditional C++ :-
Nish [Chat Host]:
class Native{};
Nish [Chat Host]:
Before we see how CLI types are instantiated, lets take a look at the new concept of handles.
Nish [Chat Host]:
One major confusion in the old syntax was that we used the * punctuator with unmanaged pointers and with managed references. To solve this, C++/CLI introduces the handle, represented by the ^ punctuator.
Nish [Chat Host]:
According to the CLI specification a handle is a managed object reference.
Nish [Chat Host]:
Handles are the new-syntax equivalent of __gc pointers in the MC++ syntax. Handles are not to be confused with pointers and are totally different in nature from pointers.
Nish [Chat Host]:
How handles differ from pointers? (excerpt from my article) :-
Nish [Chat Host]:
* Pointers are denoted using the * punctuator while handles are denoted using the ^ punctuator.
Nish [Chat Host]:
* Handles are managed references to objects on the managed heap, pointers just point to a memory address.
Nish [Chat Host]:
* Pointers are stable and GC cycles do not affect them, handles might keep pointing to different memory locations based on GC and memory compactions.
Nish [Chat Host]:
* For pointers, the programmer must delete explicitly or else suffer a leak. For handles delete is optional.
Nish [Chat Host]:
* Handles are type-safe while pointers are most definitely not. You cannot cast a handle to a void^.
Nish [Chat Host]:
* Just as a new returns a pointer, a gcnew returns a handle.
Nish [Chat Host]:
So, basically pointers and handles are totally different entities and C++/CLI makes this difference clear to the developer
SV:
ok
Nish [Chat Host]:
Okay, now that we understand the concept of handles, lets look at how CLI types are instantiated.
Nish [Chat Host]:
The gcnew keyword is used to instantiate CLR objects and it returns a handle to the object on the CLR heap. The good thing about gcnew is that it allows us to easily differentiate between managed and unmanaged instantiations.
Nish [Chat Host]:
String^ str = gcnew String("Hello World");
Object^ o1 = gcnew MyClass();
Nish [Chat Host]:
The C++ gcnew is same as the C# new
Nish [Chat Host]:
Note that gcnew is one of 3 new key-words that *might* clash with existing code (the other two being nullptr and generic). Other newly added keywords are either spaced keywords or contextual keywords that are backward-compatible.
Nish [Chat Host]:
One useful change from MC++ is that boxing is now implicit :-)
Nish [Chat Host]:
As you can see, unboxing is explicit - just do a reinterpret_cast and then dereference the pointer. During boxing, a bit-wise copy is performed and a new object created on the CLR heap,
Nish [Chat Host]:
so the boxed Object and the original value type do not reference the same object (can be verified by changing one of them).
Nish [Chat Host]:
When you box a value-type, the returned object remembers the original value type. Thus you cannot try and unbox to a different type.
Chakravarthy:
Nish: Sorry for intrupting you... are you going to through some light on the IDE Enhancements too?
Nish [Chat Host]:
Nope - I am only talking about the language enhancements
Chakravarthy:
Thanks Nish... please go ahead
Nish [Chat Host]:
Some of the VSTS designers (like the GUI-based class diagram view) are available for C++ too
Nish [Chat Host]:
But they were quite buggy in the betas released so far and may not make it in the final release
Nish [Chat Host]:
[continuing...]
Nish [Chat Host]:
If you look at the IL generated, you'll see the MSIL box instruction in action.
Nish [Chat Host]:
Ok - having trouble pasting the IL
Nish [Chat Host]:
I'll just type the relevant line here :-
Nish [Chat Host]:
box [mscorlib]System.Single
Nish [Chat Host]:
As you can observe, the IL box instruction also takes as argument the type of the value type being boxed
Nish [Chat Host]:
From the MSIL docs -> "The box instruction converts the ‘raw’ valueType (an unboxed value type) into an instance of type Object. This is accomplished by creating a new object and copying the data from valueType into the newly allocated object."
Nish [Chat Host]:
As a performance note - if you have a big loop, it's best to avoid intensive boxing inside the loop - every box results in a new Object getting created
Nish [Chat Host]:
One disadvantage with implicit boxing is you might not notice the amount of boxing that's being done
Nish [Chat Host]:
I am going to jump into the new array syntax now
Chakravarthy:
Nish: If i'm not mistaken the code name for C++ for .NET 2003 is called as "Everett" ... so is there any similar name given in 2005?
Nish [Chat Host]:
Yes - it's called Whidbey
Nish [Chat Host]:
2005 is code-named Whidbey
Chakravarthy:
but Whidbey is a collective name for 2005
Chakravarthy:
is there some thing special for visual c++
Chakravarthy:
Nish [Chat Host]:
Yes, but VC++ 2005 is code-named VC++ Whidbey
Nish [Chat Host]:
No special name for C++ this time
Chakravarthy:
ok
Chakravarthy:
thanks
nsgirish:
Nish :
Sorry for interrupting you. How abt Marshalling between .NET objects and native objects. Any changes in them?
Nish [Chat Host]:
In fact .NET 2 was initially codenamed Whidbey
Nish [Chat Host]:
And since VS.NET 2005 was coming out at the same time as .NET 2, the same code-name was shared
Chakravarthy:
that's sounds clear
Nish [Chat Host]:
Girish - IJW is still there - which means you have the option of doing custom marshalling
Nish [Chat Host]:
But if you are using P/Invoke, it's the CLR marshaller that'll do all the data-marshalling for you
nsgirish:
Ok
Nish [Chat Host]:
One additional construct available in C++ is marshal_as<> pseudo template
Nish [Chat Host]:
The compiler will generate the required marshalling code for you
Nish [Chat Host]:
Ok?
nsgirish:
Ok. Thank you Nish
Nish [Chat Host]:
One major change in syntax is with regard to managed arrays. (Note - managed arrays are allocated on the CLR heap and System::Array is the automatic base-type for managed arrays)
Nish [Chat Host]:
The declaration and usage of array types in C++/CLI seems to use a pseudo-template type (through compiler-magic)
Nish [Chat Host]:
Note - there is no such template, but it seems there is one such template - all done by the compiler
Nish [Chat Host]:
Another Note - array is declared inside the stdcli::language namespace so as to avoid conflicts with existing source code
Nish [Chat Host]:
Some examples should help make this clear :-
Nish [Chat Host]:
C++ programmers used to templates should find this syntax easy on the eyes, but for others it might initially appear slightly confusing.
Chakravarthy:
Nish
: Before i forget let me ask you a quick question ... Are there any performance Optimizations issues are considered?
Nish [Chat Host]:
Yes, I do talk about performance a little later - but focussing on interop
Nish [Chat Host]:
With the new syntax, jagged arrays are a piece of cake (in the old syntax they had to be simulated using an ugly pattern) Note - Jagged arrays are non-rectangular, and are actually arrays of arrays.
Chakravarthy:
fine.. thanks Nish ... pl go ahead
Nish [Chat Host]:
arr is a jagged array of 5 arrays each of which is an array of ints. The jagged array as well as its member arrays are all of rank 1 as can be easily verified :-
Nish [Chat Host]:
Console::WriteLine("Rank = {0}; Length = {1}",
arr->Rank,arr->Length);
/*
Output :-
Rank = 1; Length = 5
*/
Nish [Chat Host]:
for(int i=0; i<5; i++)
Console::WriteLine("Rank = {0}; Length = {1}",
arr[i]->Rank,arr[i]->Length);
/*
Output :-
Rank = 1; Length = 10
Rank = 1; Length = 20 . . . */
Nish [Chat Host]:
You can use a typedef to simplify jagged array usage :-
Nish [Chat Host]:
That looks better on the eyes
Nish [Chat Host]:
The new syntax allows direct initialization of arrays.
Nish [Chat Host]:
Now C++/CLI supports Parameter arrays :-
Nish [Chat Host]:
R^ r = gcnew R();
r->Test("Nish");
r->Test("Nish",1);
r->Test("Nish",1,15);
r->Test("Nish",1,25,100);
Nish [Chat Host]:
There can only be one such parameter array per function and it also needs to be the last parameter.
Nish [Chat Host]:
You can declare C++/CLI arrays where the array type is of a non-CLI object. The only inhibition is that the type needs to be a pointer type. Since they are native objects on the standard C++ heap, they need to have delete called on them individually.
Nish [Chat Host]:
Alternatively you could declare stack objects and pass their addresses (in which case you don't need to delete them)
Nish [Chat Host]:
C++ is the only language where you can use a .NET feature (managed array in this case) with native classes
Nish [Chat Host]:
Here's some fancy code that shows how you can directly manipulate the contents of an array using native pointers.
Chakravarthy:
is there any modification for the above way of declaration?
Nish [Chat Host]:
Lemme show you sample code - should make it clearer :-
Nish [Chat Host]:
Here there is no need to call delete, because when they go out of scope, their destructors get called automatically and they are removed from the stack
Nish [Chat Host]:
Far more efficient since the CLR heap is not used and thus the GC is avoided
Nish [Chat Host]:
Only useful where you use the array within a limited scope
Nish [Chat Host]:
Here's some fancy code that shows how you can directly manipulate the contents of an array using native pointers.
Nish [Chat Host]:
This'll be handy when doing speed-sensitive processing on an array
Nish [Chat Host]:
Note - A pinning pointer (or a pinned pointer) prevents the GC from relocating the pinned object for as long as the pinning pointer remains in scope.
Nish [Chat Host]:
Performance tip - avoid pinning too many pointers within the same scope - this results in heap fragmentation as the GC will ignore objects that are pinned
Nish [Chat Host]:
I've seen code where people pin objects they pass to native code without bothering to explore whether the marshaller would alreday be pinning the objects
Nish [Chat Host]:
Usually the marshaller will pin objects that need to be pinned - so you won't have to pin objects for interop calls
Nish [Chat Host]:
Now, on to deterministic destruction
Nish [Chat Host]:
C++ coders weren't too pleased with the non-deterministic finalization feature they were provided with by the .NET Garbage Collection algorithm.
Nish [Chat Host]:
The Dispose-pattern suggested by Microsoft required the programmer to manually and consistently call Dispose whenever the object needed to be finalized and it became worse when the object had managed member objects that themselves would need to have
Nish [Chat Host]:
Dispose called on them, which then meant they too needed to implement IDisposable. Not very good.
Nish [Chat Host]:
In C++/CLI, the Microsoft VC++ team gives us a destructor that internally gets compiled to the Dispose method and the old finalizer gets an alternate syntax,
Nish [Chat Host]:
so we basically have finalizers and destructors as two separate entities that behave differently as they should have in the previous version.
Nish [Chat Host]:
The designers of C# made the unfortunate initial mistake of calling their finalizer a destructor and I presume there must be tens of thousands of C# coders out there who have no inkling of the fact that
Nish [Chat Host]:
of the fact that they have got a basic concept in object life-time maintenance absolutely confused with the wrong thing.
Nish [Chat Host]:
Doesn't apply to all people obviously
Nish [Chat Host]:
Destructors follow the same syntax used in the pre-managed times, where ~classname would be the method name for the destructor. It also brings out a new naming syntax, !classname which is the method name for the finalizer.
Nish [Chat Host]:
ref class R1
{
public:
R1()
{
Console::WriteLine("R1::ctor");
}
Nish [Chat Host]:
~R1()
{
Console::WriteLine("R1::dtor");
}
Nish [Chat Host]:
protected:
!R1()
{
Console::WriteLine("R1::fnzr");
}
};
Nish [Chat Host]:
The destructor (~R1) gets compiled into a Dispose method in the generated IL. There is a call made to GC::SuppressFinalize in the generated Dispose method to ensure that the finalizer does not get called during the garbage collection cycle that claims this
Nish [Chat Host]:
that claims this object's memory.
Nish [Chat Host]:
BTW that's GC: : SuppressFinalize
Nish [Chat Host]:
The smiley code took over :-)
Nish [Chat Host]:
You can use it like a typical stack-object in unmanaged C++ :-
Nish [Chat Host]:
R1 r; //No need to gcnew
int y=100;
Nish [Chat Host]:
The pseudo C# equivalent of the generated IL is shown below :-
Nish [Chat Host]:
R1 r = null;
int y;
r = new R1();
try
{
y = 100;
}
Nish [Chat Host]:
catch
{
r.Dispose();
}
r.Dispose();
Nish [Chat Host]:
The compiler detects the scope of the variable and calls Dispose for us. BTW, you can also do this :-
Nish [Chat Host]:
R1^ r = gcnew R1();
delete r;
Nish [Chat Host]:
The delete gets compiled into a call to Dispose (the variable is cast to IDisposable first to ensure that it's a disposable class, and Dispose called on this IDisposable variable).
Nish [Chat Host]:
Some things to remember (when using destrutors and finalizers) :-
Nish [Chat Host]:
* You cannot have a method named Dispose in your class, for obvious reasons
Nish [Chat Host]:
* Destructors get called when the object goes out of scope, but the memory won't be freed up until the next GC cycle
Nish [Chat Host]:
* The destructor and finalizer won't get called for the same object
Nish [Chat Host]:
* Automatic Member variables get disposed for you [compiler generates code]
Nish [Chat Host]:
* Handle member variables need to be explicitly deleted
Nish [Chat Host]:
Note - While this is similar to C#'s using block, it's a lot more intuitive to C++ people and is also a lot easier on the eyes when you have deeply nested scope-blocks.
Nish [Chat Host]:
BTW I presume most of you are C# developers?
SV:
I am
SV:
C# I mean
Chakravarthy:
Me too
MVP_mayank:
same here
Nish [Chat Host]:
Ok - thanks. Some C#ers have complained that the C++/CLI syntax is kinda confusing
nsgirish: I have worked in VC++ and C#
Nish [Chat Host]:
Thus far into the chat, do you all feel so too?
SV: A little - yes :-)
Chakravarthy:
a kind such.. but need to agree that it is C++ not C#
SV:
Maybe because I am used to C#
SV:
I haven't done much C++ before
Nish [Chat Host]:
Ok
Nish [Chat Host]:
Thanks - I'll quickly run through generics - running out of time
Nish [Chat Host]:
Beginning with .NET 2.0, Microsoft has introduced generics into the CLI whereby parameterized types can be declared and used. Generics and templates, while similar in nature, are also different in many ways.
Nish [Chat Host]:
The most outstanding of these differences is that while templates are implemented by the compiler, generics are instantiated at runtime by the CLR's execution engine (this is possible because generics is directly supported by MSIL).
Nish [Chat Host]:
Note - In C++/CLI, templates can be used both with native and with managed types
Nish [Chat Host]:
Sample declaration of a generic class :-
Nish [Chat Host]:
void DoStuff(T2 t2)
{
//...
}
private:
T1 m_t1;
};
Nish [Chat Host]:
Very similar syntax to templates
Nish [Chat Host]:
Except that generic classes need to be ref classes (can't use them on native classes)
Nish [Chat Host]:
Templates use lazy constraints, but since generics are implemented at run-time, you need to specify sub-type constraints. See the following template class :-
Nish [Chat Host]:
t->Bark(x);
t->WagTail();
delete t;
}
};
Nish [Chat Host]:
It compiles fine even though the compiler has no idea of whether T is a type that has Bark and WagTail methods. With generics, you'd have to do it this way :-
Nish [Chat Host]:
interface class IDog
{
void Bark(int Loudness);
void WagTail();
};
Nish [Chat Host]:
Note - C++ (as of now) won't let you gcnew a parameter type (I believe C# lets you do this)
Nish [Chat Host]:
Nor can you delete a parameter type
Nish [Chat Host]:
That's why I had to use the generic overload of Activator::CreateInstance as a substitute for gcnew
Nish [Chat Host]:
And I had to cast to Object^ to delete it
Nish [Chat Host]:
C++/CLI also supports generic functions (you can have a non-generic class with a generic function or you can have a global generic function).
Nish [Chat Host]:
This doesn't apply to C# as it doesn't support global functions
Nish [Chat Host]:
Another cool feature introduced in VC++ 2005 is STL.NET - a re-engineered version of STL that uses both C++ templates as well as CLI generics to give an interface usable from .NET.
Nish [Chat Host]:
Why would you want to use the STL container classes when you have the .NET generic collection classes? For C++ people familiar with STL, STL.NET would come as a natural extension.
Nish [Chat Host]:
Also, by nature, STL is a highly extensible and flexible model - the same cannot be said of the .NET generic collection classes (though hardcore .NETers would disagree).
Nish [Chat Host]:
STL separates container classes and algorithms in such a way that you can use any algorithm on any container class.
Nish [Chat Host]:
So you can add a new algorithm that's now applicable to all container classes or you can add a new container to which all algorithms can be applied. This is one of STL's biggest selling points.
Nish [Chat Host]:
Another advantage with STL.NET over the BCL classes would be performance. STL.NET gives us some generic class wrappers on top of an underlying template based library written in C++
Nish [Chat Host]:
- which would obviously give us a more performant interface than what regular BCL classes would.
Nish [Chat Host]:
Sample :-
Nish [Chat Host]:
vec1->push_back("William");
vec1->push_back("Nish");
vec1->push_back("Smitha");
Nish [Chat Host]:
sort( vec1->begin(), vec1->end() );
for(int i = 0; i < vec1.size(); i++)
Console::WriteLine(vec1[i]);
Nish [Chat Host]:
Great huh? The power of STL + the power of the .NET classes - couldn't get any better than this :-)
Nish [Chat Host]:
Now, I'll talk about the interop mechanisms available
Nish [Chat Host]:
C++/CLI offers the fastest interop mechanism among all .NET languages. Languages like C# offer P/Invoke (also supported by C++/CLI) where the DllImport attribute is applied to the method declarations of imported functions.
Nish [Chat Host]:
The CLR marshalling layer does all the marshalling for you. But with C++/CLI, you can use C++ interop or IJW (it just works) and take any existing C++ code and recompile it with /clr.
Nish [Chat Host]:
Not only does this allow you to access unmanaged code that do not expose themselves through DLLs, but it is also far more performant than the P/Invoke mechanism.
Nish [Chat Host]:
It's the caller who's responsible for handling data-marshalling and this brings in an efficiency level not possible with P/Invoke's automatic marshalling.
Nish [Chat Host]:
It's quite easy to test out the performance differences. Write a simple C# app that uses P/Invoke to call a Win32 API (say GetWindowsDirectory) and write a C++ app that uses IJW to do the same.
Nish [Chat Host]:
Call the API 10,000 times or so and compare the different times both programs take to complete the loop.
Nish [Chat Host]:
Of course, such high levels of performance may not apply to most .NET application development contexts, but on the occasions when it does matter, you'll know you have a better tool with you when you are using C++/CLI.
Nish [Chat Host]:
A side note
Nish [Chat Host]:
__asm int 3 used to generate the MSIL break instruction in the previous compiler
Nish [Chat Host]:
in C++/CLI __asm int 3 is generated as an X86 code block of the int 3 native code
Nish [Chat Host]:
So if you had code depending on an MSIL break by any chance - say you were using a CLR profiler or something, it won't work now
Nish [Chat Host]:
You can alternatively use __debugbreak though
Nish [Chat Host]:
which will generate the MSIL break instrution when the /clr mode is enabled
Nish [Chat Host]:
I want to wrap up my overview with an explanation of the three compiler sub-switches for /clr mode (not counting the oldSyntax option)
Nish [Chat Host]:
/clr - this is the default mode that lets you build mixed-mode assemblies and you have everything - P/Invoke, IJW, pointers etc.
Nish [Chat Host]:
This is the mode you need to use when you are compiling legacy C++ applications and libraries
Nish [Chat Host]:
/clr:pure - this generates pure MSIL (no X86 blocks) which means no IJW. You still have P/Invoke and pointers though.
Nish [Chat Host]:
/clr : pure (stupid smiley code) :-)
Nish [Chat Host]:
This is the mode you need to use when you want comparable output to C# or VB.NET
Nish [Chat Host]:
You won't have X86 blocks - it'll be a pure MSIL assembly that's generated
Nish [Chat Host]:
/clr:safe - this generates fully verifiable MSIL. This is stricter than pure mode and you can't use P/Invoke or pointers [useful if you want to run your code in tight security conditions like say inside SQL Server 2005]
Nish [Chat Host]:
/clr : safe (damn smiley again)
Nish [Chat Host]:
This will generate the safest purest MSIL code that's 100% verifiable
Nish [Chat Host]:
This is used when apps need to run in 100% trusted mode as in say Yukon stored procedures
Nish [Chat Host]:
Winding up, the advantages C++/CLI offer you over other .NET languages are :-
Nish [Chat Host]:
** Compile existing C++ code to IL (/clr magic)
Nish [Chat Host]:
** Deterministic destruction and true destructors that run at the right time
Nish [Chat Host]:
** IJW - Native interop support that outmatches anything other CLI languages can offer
Nish [Chat Host]:
** No more ugly underscores as in MC++ :-)
Nish [Chat Host]:
Okay - that's the end of the chat people
Nish [Chat Host]:
Thanks for attending and the small discussions
SV:
:-)
SV:
Thanks Nish
Chakravarthy:
Nish: one personal Question Are you the same Nish hosting the voidnish.com ?
Nish [Chat Host]:
Yes - I am
Nish [Chat Host]:
My web site is at www.voidnish.com and I blog at blog.voidnish.com
Chakravarthy:
that's great to know...
nsgirish:
Thank You Nish
Nish [Chat Host]:
I do blog on C++/CLI too
Nish [Chat Host]:
You are welcome
Chakravarthy:
i have few bugs to deal with objects ctor ... can i mail you ?
Nish [Chat Host]:
Yes, you can mail me Chakravarthy
Nish [Chat Host]:
My replies might not be very prompt though due to the high volume of mails I receive
Chakravarthy:
at ?
Nish [Chat Host]:
nish@asianetindia.com
nsgirish:
In terms of performance how closer the new MSIL code comes near native code?
Nish [Chat Host]:
Please mention you are the guy from the chat though
Chakravarthy:
sure nish... My problems are not time constraint.. but need attention to improve the performance of the objects... so you can thorough some light on when you find some time
Nish [Chat Host]:
Girish, I am not very much into CLR performance, but I believe the JIT compiler and the GC have both been further tuned to increase performance levels
nsgirish:
Ok
Nish [Chat Host]:
If the CLR team blogs are to be believed, performance boosts of upto 300% may happen depending on your memory usage
nsgirish:
Sounds great
Nish [Chat Host]:
At the compiler level, C++ does a lot more optimizations than other compilers
H:
great
nsgirish:
Thank you Nish
Nish [Chat Host]:
So the MSIL generated by C++ would probably have a small edge over other compilers
Nish [Chat Host]:
Okay guys - I've got to go now - it was a very cool sort of chat - nice to see some people interested in C++/CLI and performance aspects :-)
nsgirish:
ok
Nish [Chat Host]:
Bye all of you.
Prakash Jha:
Bye....Nish....Happy Coding Guyz................
Chakravarthy:
bye Nish