Joe Duffy has written an interesting piece over on “Generalities & Details: Adventures in the High-tech Underbelly” about problems with the CLR thread pool. Joe’s a program manager on the CLR team at Microsoft, so he knows what he’s talking about!
I find the issues that Joe raises interesting as I spent some time designing a flexible thread pool for my C++ IOCP servers some time go and came across the problems that he’s facing.
So here I am, writing a piece about how the C++/CLI destructor and finalizer stuff could have been a bit neater and I put together some sample code to demonstrate my point and it doesn’t do what the docs I mentioned yesterday suggest that it should do…
Given this example class….
ref class Example { public : Example( bool throws) : m_count(s_count++), m_string(gcnew String("MyString")) { Console::WriteLine(m_count + " - Example(throws = " + throws + ")"); if (throws) { throw "Thrown"; } } Example() : m_count(s_count++), m_string(gcnew String("MyString")) { Console::WriteLine(m_count + " - Example"); } ~Example() { Console::WriteLine(m_count + " - ~Example"); delete m_string; this->!
Whilst I’m ranting about the little things…
You still can’t create named versions of the .Net ManualResetEvent and AutoResetEvent, even in .Net 2.0. Wasn’t everything going to be fixed in Whidbey?
Of course, I realise that you can “simply” access the underlying Win32 API to do it, but a) why should we have to? and b) it’s not recommended that you do…
I guess the fact that the P/Invoke route isn’t recommended is the reason for the dearth of nicely packaged up solutions to this problem; surely anyone who needs this functionality would write an object that wraps it up nicely rather than doing it “long hand” like this?
Ted Neward has a very nice piece about the new language features in C# v3 and how they work together to provide something quite powerful. Go read it!
Given that implicit typing, object initialisers and extension methods are all designed to allow LINQ to be a be able to generate classes on the fly and extend existing classes I’d still be happier if they could be optionally restricted from use on ’normal’ classes to help prevent the less experienced running amok with these new language features and creating code that has interesting maintenance properties…
Having looked through the slides that Vagn pointed me to in a comment to my recent post about C# v3.0 Extension Methods I can understand, a little more, about the reasoning behind the change to the language. Given that the C# v3.0 spec contains the following warning:
“Extension methods are less discoverable and more limited in functionality than instance methods. For those reasons, it is recommended that extension methods be used sparingly and only in situations where instance methods are not feasible or possible.
There’s a lot of noise coming out of the Microsoft PDC right now. Something that interested me was the future direction of C#; you can grab the spec from here.
It seems they’re adding “extension methods” which, to me, appear to be just syntactic sugar to make up for the lack of free functions…
In C++ you can have functions that aren’t part of an object. In C no functions are part of an object.
I’ve been merging my UDP framework development branch back to main, building all of my example servers and running all of the “black box” server tests for The Server Framework. In doing so I’ve experienced the pain of changing virtual function signatures. This is one area where C# syntax is definitely better than the C++ syntax…
The Server Framework relies on derivation for extension and use. That wasn’t one of my brightest ideas.
I have some code that launches another process in a suspended state, does some stuff (tm) and then resumes the process. This uses CreateProcess() and works fine on unmanaged exes. When I try and launch a manged exe with the same code the process starts up in a running state rather than in a suspended state. The docs for CreateProcess() don’t mention any strangeness. Does anyone know of any docs that explain what’s going on?
Jeff Atwood has a nice piece on the productivity of different programming languages (go read it). His sums up with the following:
*Given ..
1). the abandonment of C++ and C for mainstream programming
2). the huge influence of individual programmer skill
the slow but steady adoption of scripting/dynamic language conventions in Java and .NET* *.. maybe all modern programming languages really are the same.
Ole Eichhorn has already taken Jeff to task in the comments about his definition of mainstream, and Jeff has responded here so I’ll leave that one alone for now ;) Several people picked up on the relative unfairness of using lines of code as a productivity measure, so I’ll leave that one ;) which leaves me with something I’ve been meaning to write about for a while…
Geoff Appleby discovers that a common C++ template idiom doesn’t work with .Net generics. The code that doesn’t work is this:
Public Class Class1(Of V As System.Web.Services.Protocols.SoapHttpClientProtocol) Inherits V End Class which is the .Net generics equivalent of this common C++ idiom:
template <class base> class TDerived : public base { }; This is useful in all kinds of situations, as Christopher Diggins explains and, as Geoff says: “You don’t know if V is NotIneritable, MustInherit, or whatever.
