Chris Hargrove

Member
  • Content count

    106
  • Joined

  • Last visited

Community Reputation

256 Neutral

About Chris Hargrove

  • Rank
    Member
  1. New standard language?

    Quote:How? What kind of "hack" would you use to load a class at runtime, enumerate all its properties, methods and fields and execute a method by name on it? Quote:I completely agree with this, as one of the reasons my server application is so powerful is because of the functionality that C# provides in this regard. There was just no way at all to do this in C++. There are ways to do this in C++. They're platform-specific, but certainly doable. I've been using a C++ reflection API for months (including support for the above features, plus delegates, .NET-style "attributes" via a few macros, and so forth) and it's been working like a charm. As for the topic in general: I worked with C# as my primary language for the better part of a year. I like it, but IMO it has some maturing to do on several fronts (the language syntax, the framework API, and the back-end) before it could be considered sufficient for professional use. Several of my problems with it stem from "features" that are actually deficiencies from my point of view, and if these deficiencies are not sufficiently addressed then it would significantly impact my desire to move over to it permanently. So as to avoid going off on a rant, I'll just keep my list short and to the point, unless someone wants me to clarify. 1. Needs much better support for type-safe weak references. If a garbage collected system ever wants to get greater adoption from people used to manual memory management systems, it must place a priority on supporting weak references just as well as it supports strong ones. System.WeakReference does not cut it. Anyone who works primarily with a "single owner, multiple reference" approach to memory management should know exactly where I'm coming from with this. 2. Support for assembly-less interfaces (yes, that's right, I want header files available as an option). When I first moved to C#, I thought the lack of header files was a wonderful thing. It turns out that it's both a blessing and a curse, because without header files you can't expose purely abstract interfaces without either making an "interface assembly", or forcing yourself into some nasty circular reference situations (which the assembly loader forbids). A solution would be to support the export of generated assembly metadata into a binary file that could be included into another assembly directly, so the loader doesn't have to be as involved. 3. Better support for value types (C# structs). C# treats these as second-class citizens that are only really there to support necessary interop. They are critical for games, however, and their functionality should be improved as such. 4. Better back-end support for the FPU. I know the JIT compiler may have theoretically improved performance over normal compiled native code (eventually), but I don't want theoretical, I want empirical. Fix the FPU support, and show me on the profiler. It's very important. I've got a huge laundry list of other things that I found problematic (I could rant for pages on IDisposable alone) but that wouldn't be productive. The above items are critical though, as they're among the things that have prevented me from moving primarily to C# already. Other developers I've talked to have similar lists, with plenty of items of their own. And that's still in the context of PC developers (the console guys have plenty of their own obvious reasons to stick with C/C++). It has potential, but it's not ready for primetime yet. - Chris