Printable View
There are DLLs which export native C++ classes, as far as I know these can only be accessed from .net via mixed-mode 'glue' DLLs implemented in C++/CLI.Quote:
Originally Posted by darwen
Also it may be easier / more efficient to access some COM objects via C++/CLI.
But those are relatively rare special cases. In general I agree that managed code should not be mixed with non-managed code in the same DLL.
In your lecture you correctly point out the difference between the languages,Quote:
Originally Posted by TheCPUWizard
b) Exiting a "using" block in C#
c) Using stack semantics in C++/CLI
Now I find the C++/CLI way both "better and more predictable". It's because it happens automatically and doesn't rely on the programmer to always remember to supply a using block. If you don't share my view please feel free to explain why you prefer the C# way.
1) It happens automatically if the user "remembers" to use stack semantics and not reference semantics.Quote:
It's because it happens automatically and doesn't rely on the programmer to always remember to supply a using block. If you don't share my view please feel free to explain why you prefer the C# way.
1a) FxCop can be configured to report any IDisposable object which is created outside a using block.
As to "prefer the C# way". I never said that. I merely said that I do not prefer the C++/CLI way, as there are no real advantages in this regard. In other words, the issues of managed object memory management, is (roughly) equivilant. The c# method has some advantages, in that you can do additional processing between different objects being disposed without any additional work.
The much bigger issue with memory management, it that most of the paradigms that apply to native code, are actually bad programming practice in a managed (Garbage Collected) environment. This topic is completely independant of the language being used.
Well you're entitled to an opinion and I won't yell "Wrong, False, Utterly UNTRUE!" at you for having it.Quote:
Originally Posted by TheCPUWizard
What we're discussing IS part of the bigger issue. How can resources securely and predictably be disposed off of in a GC environment. I think the RAII idiom is a good solution and I think I prefer the C++/CLI implementation.Quote:
The much bigger issue with memory management, it that most of the paradigms that apply to native code, are actually bad programming practice in a managed (Garbage Collected) environment. This topic is completely independant of the language being used.
Threading support in 1.0 and 1.1 was limited but it's pretty good in 2.0. 2.0 supports thread pooling (ala QueueUserWorkItem) and also a ReaderWriterLock class.
If you like to perform thread synchronization using RAII, you can do this in C# by leveraging the using statement.
So say I wanted to add thread safety to a property of a class
The cool thing about this is that the syntax for locking a mutex or ReaderWriterLock is similiar. Here's an example of locking a RWlock to read.Code:public string Location
{
get
{
using( AutoLock< LockableCS >
Lock = AutoLock< LockableCS >.Create( _csLock ) )
{
return _location;
}
}
}
Sure you can do this with the lock{ } block, but lock doesn't allow the granularity of this technique and doesn't provide mutexes and reader writer locking support.Code:public string Location
{
get
{
using( AutoLock< LockableRW >
Lock = AutoLock< LockableRW >.Create( _rwLock, LockType.Read, 5000 ) )
{
return _location;
}
}
}
Actually I was a Microsoft Employee at the time these decisions were made. Many were tradeoffs to keep thinks in a "C++ Paradigm" even if it was not optimal from other points of view. RAII with reference objects contains some inherent inner conflicts. An object needs to be able to support being Disposed of multiple times, and All methods on the object should fail once the object is destroyed once.Quote:
I'm sure the designers of C++/CLI also have given this some serious thought and they discarded the C# way. Why don't you go yell "Wrong, False, Utterly UNTRUE!" at Herb Sutter instead of me, or maybe you already did that?
If you use stack semantics on a managed object, and start passing and holding on to the references, you run into many of the same problems that you had in conventional C++ with holding references to objects which have gone out of scope. C++ programmers are used to this, so it was not deemed a proble. C# and most other Managed Languages, handle this a little more gracefully.
Actually there have been some heated discussions between us over the years.Quote:
Why don't you go yell "Wrong, False, Utterly UNTRUE!" at Herb Sutter instead of me, or maybe you already did that?
The methodology for handling the Dispose() of objects between the various languages can be debated on merits. This is an opinion.
The "predicitability" is a matter of fact. Objects get disposed if and only if the Dispose method (expressed as a destructor in C++/CLI) gets called. Objects get finalized, and their memory released as a function of the garbage collector and is independant of the language used. As far as I can see, there is NO difference in predictability.
I don't think it is possible to do that kind of 'using statement' with C++/CLI stack semantics, because you need to receive a reference to an object which was created in the called function (as discussed here).Quote:
Originally Posted by Arjay
My example was C#. Is the using statement, IDisposable not supported in C++/CLI? If so, that's a great reason right there to choose C#.Quote:
Originally Posted by Zaccheus
Have a look at the link in my post. You can create an instance of a class which is automatically disposed, but I cannot see a way of automatically disposing a reference received from a function call in C++/CLI.Quote:
Originally Posted by Arjay
However, it did just dawn on me that it might be possible to write a generic class which supports stack semantics, whose only purpose is to receive such a reference and dispose the received reference when it gets disposed itself ! A bit like a managed auto_ptr.
Sure and there's no special reason for you to call my opinion "Wrong, False, Utterly UNTRUE!". It's still my opinion and I suggest you stick to arguments even if you feel your opinion is superior.Quote:
Originally Posted by TheCPUWizard
In one case the language relies on the programmer to initiate destruction and in the other case this is taken care of automatically by the language. In my view in the latter case the language offers a higher degree of predictability. A reference object on the method stack will be destructed when the method is left. No programmer intervention necessaryQuote:
The "predicitability" is a matter of fact. Objects get disposed if and only if the Dispose method (expressed as a destructor in C++/CLI) gets called. Objects get finalized, and their memory released as a function of the garbage collector and is independant of the language used. As far as I can see, there is NO difference in predictability.
Okay predictability may be the wrong expression but now you know what I mean. In any case I wouldn't use this as a determining factor in the choise of language.
By automatically disposed, are you referring to the delete statement in the finally block?Quote:
Originally Posted by Zaccheus
100% agreement, not a determining factor.Quote:
In one case the language relies on the programmer to initiate destruction and in the other case this is taken care of automatically by the language. In my view in the latter case the language offers a higher degree of predictability.
Okay predictability may be the wrong expression but now you know what I mean. In any case I wouldn't use this as a determining factor in the choise of language.
Perhaps you really did not mean predictability, because in C#
1) If there is no call to Dispose, and the object is not in a using block. It will bot be deterministically Disposed.
2) If there is a using block it will be disposed.
3) If there is no using block, and there is an explicit call, it will be disposed itf the code executes. It must be inside a finally block to insure it is called in the event of an exception.
Therefore looking at any peice of C# code that has an object that implements IDisposable, I can "predict" if the object will be disposed with 100% certainity that my prediction is corredt. Not code like this:
I would definately consider to be less predictable. :DCode:IDisposable obj;
int x = Random.Next();
if (x%1)
obj.Dispose();
I think perhaps it's simply a case of what you are used to. In one case (C++/CLI) you have to create an auto-disposed object by leaving out the ^ symbol and the 'new' statement, in the other (C#) you have to put using() around a variable declaration which is otherwise unchanged. I don't think either is more logical than the other.Quote:
Originally Posted by _uj
Not having coded in C++/CLI I can't say for sure, but understanding the implications of leaving off the ^ and not using the 'new' sounds more trouble than in C#. In C# there is no ^ and everything must be 'new'd, so this part is removed from consideration. As far as the using statement, you can use the using block or call Dispose directly. If you try to call using on something that doesn't implement IDispose, the compiler tells you immediately. It just seems simpler in C#.Quote:
Originally Posted by Zaccheus
There are other considerations like :
(1) In C# intellisense works, in C++ it is very flaky.
(2) C# is much, much quicker to write code in.
By (2) I mean you don't have to type as much e.g.
In C# the seperator is '.' (dot) whereas in C++ it's ':' (colon) - I'm a speed typer and even to me a dot is easier to type than a colon as a colon requires the shift key.
In C# you can use 'as' to do casting whereas in C++/CLI it's safe_cast<>.
No need for #includes in C# (great !).
There are all sorts of other points like these which in my opinion make C# so much more of a nice language to code .NET in than C++.
Darwen.