Is Microsoft abandoning generics?
-
It seemed there was a time when Microsoft was moving toward template programming. Technologies like WTL, ATL and STL were great alternatives to MFC and other libraries. But now with the advent of .NET, these options are gone. Even MI (Multiple Inheritance) is not supported by the CLR. Generics might just be the competitive advantage Microsoft needs to step over Java.
-
It seemed there was a time when Microsoft was moving toward template programming. Technologies like WTL, ATL and STL were great alternatives to MFC and other libraries. But now with the advent of .NET, these options are gone. Even MI (Multiple Inheritance) is not supported by the CLR. Generics might just be the competitive advantage Microsoft needs to step over Java.
Microsoft has said that generics are on the list for V2 of the CLR. Lee
-
Microsoft has said that generics are on the list for V2 of the CLR. Lee
And Sun has said the same thing for the next version of Java.
-
It seemed there was a time when Microsoft was moving toward template programming. Technologies like WTL, ATL and STL were great alternatives to MFC and other libraries. But now with the advent of .NET, these options are gone. Even MI (Multiple Inheritance) is not supported by the CLR. Generics might just be the competitive advantage Microsoft needs to step over Java.
WTL, ATL and STL are still around in VS.NET. They are not being abandoned. In the final VS.NET release, there should be new versions of ATL and Dinkumware STL. WTL will continue to be released on the Platform SDK. CodeGuy http://groups.yahoo.com/group/wtl
-
It seemed there was a time when Microsoft was moving toward template programming. Technologies like WTL, ATL and STL were great alternatives to MFC and other libraries. But now with the advent of .NET, these options are gone. Even MI (Multiple Inheritance) is not supported by the CLR. Generics might just be the competitive advantage Microsoft needs to step over Java.
Generics aren't in the current version of C# or .NET. It's mostly a resource issue - we're very interested in adding generics, but we couldn't do it in the current version. We are likely to do it in a future version, but note that "future version" doesn't necessarily mean "the next version". Because of the built-in class library with .NET, I think that generics are less important than in C++. The main thing we'd get from it are: 1) No more casting from object to the type you want 2) Collection classes of value types. WRT MI, that's a tougher issue. We don't currently have a way to do MI without slowing down SI. Even if we did, there are differences between how MI works on different languages, and that might prove to be less tractable.
-
Generics aren't in the current version of C# or .NET. It's mostly a resource issue - we're very interested in adding generics, but we couldn't do it in the current version. We are likely to do it in a future version, but note that "future version" doesn't necessarily mean "the next version". Because of the built-in class library with .NET, I think that generics are less important than in C++. The main thing we'd get from it are: 1) No more casting from object to the type you want 2) Collection classes of value types. WRT MI, that's a tougher issue. We don't currently have a way to do MI without slowing down SI. Even if we did, there are differences between how MI works on different languages, and that might prove to be less tractable.
It seems to me that generics are important enough that they should have been in .NET from the beginning. Aside from gaining what you mentioned, generics would have also served to woo over diehard C++ and Java developers. In addition, generics could have also allowed the .NET collection classes (which I know nothing about) to be generic right from the start. Instead, .NET will end up with a dual set of collection classes, such as GenericVector, GenericList, etc., and perhaps cause confusion. This is all my opinion and I'm interested in what you have to say about it. I'm curious, how much time was expected it would have taken to incorporate generics up front? More importantly, how much time will it take to add it later when a dozen or so .NET dialects... er, languages are running around? Thanks, Alvaro
-
It seems to me that generics are important enough that they should have been in .NET from the beginning. Aside from gaining what you mentioned, generics would have also served to woo over diehard C++ and Java developers. In addition, generics could have also allowed the .NET collection classes (which I know nothing about) to be generic right from the start. Instead, .NET will end up with a dual set of collection classes, such as GenericVector, GenericList, etc., and perhaps cause confusion. This is all my opinion and I'm interested in what you have to say about it. I'm curious, how much time was expected it would have taken to incorporate generics up front? More importantly, how much time will it take to add it later when a dozen or so .NET dialects... er, languages are running around? Thanks, Alvaro
I agree that we would have preferred to have generics in from the start, but there just wasn't time in the schedule. If we had extra time (has anybody *ever* had extra time while developing a product?) there are other things that we would have put in before adding generics. With the specific implementation we're looking at, generics exist at the IL level, so there's a fair amount of work in the runtime. It's unlikely that generic support would be required as part of the CLS, so they won't be required of all languages. How they show up in all .NET languages is an interesting problem. My *guess* is that the support would be full-fledged in some languages, that other languages might be able to consume generic types but not author them, and that some languages wouldn't be able to use them at all. Being in a multi-language environment means you have to deal with these sort of tradeoffs. Figuring out things like that and how you deal with generics from a class library perspective is one of the reasons that this is a big item. I don't know the exact cost, but I do know that it's pretty substantial.
-
I agree that we would have preferred to have generics in from the start, but there just wasn't time in the schedule. If we had extra time (has anybody *ever* had extra time while developing a product?) there are other things that we would have put in before adding generics. With the specific implementation we're looking at, generics exist at the IL level, so there's a fair amount of work in the runtime. It's unlikely that generic support would be required as part of the CLS, so they won't be required of all languages. How they show up in all .NET languages is an interesting problem. My *guess* is that the support would be full-fledged in some languages, that other languages might be able to consume generic types but not author them, and that some languages wouldn't be able to use them at all. Being in a multi-language environment means you have to deal with these sort of tradeoffs. Figuring out things like that and how you deal with generics from a class library perspective is one of the reasons that this is a big item. I don't know the exact cost, but I do know that it's pretty substantial.
Eric, it sounds like you're basically saying you'd *like* to put in generics, but you don't know when it will happen. I'm sure I'm not alone in saying that until C# supports templates, I would regard it as in incomplete language. I admit I've not yet had a chance to install my .Net beta 2 CD, and I'm sure when I do I'll be in a better place to comment, but still, the noises you're making now do not inspire confidence in the likelyhood of generics *ever* eventuating. If there are other things you'd put before it now, it's likely to stay that way, or so it would seem to me. Christian Secrets of a happy marriage #27: Never go to bed if you are mad at each other. It's more fun to stay up and fight.
-
Eric, it sounds like you're basically saying you'd *like* to put in generics, but you don't know when it will happen. I'm sure I'm not alone in saying that until C# supports templates, I would regard it as in incomplete language. I admit I've not yet had a chance to install my .Net beta 2 CD, and I'm sure when I do I'll be in a better place to comment, but still, the noises you're making now do not inspire confidence in the likelyhood of generics *ever* eventuating. If there are other things you'd put before it now, it's likely to stay that way, or so it would seem to me. Christian Secrets of a happy marriage #27: Never go to bed if you are mad at each other. It's more fun to stay up and fight.
I'm just being careful that I'm not promising to deliver features in a specific timeframe. If I told you (for example) that we were going to have generics (or any other feature) in the next version and then something changed, you'd be unhappy. I'd rather underpromise at this point. WRT your comment about completeness, while I understand the benefit of having generics, I haven't found the lack of generics to be an obstacle to anything that I've been writing. Can you expand a bit on your stance? Is there a specific situation where you think you'd be too constrained by the language to write your code effectively?
-
I'm just being careful that I'm not promising to deliver features in a specific timeframe. If I told you (for example) that we were going to have generics (or any other feature) in the next version and then something changed, you'd be unhappy. I'd rather underpromise at this point. WRT your comment about completeness, while I understand the benefit of having generics, I haven't found the lack of generics to be an obstacle to anything that I've been writing. Can you expand a bit on your stance? Is there a specific situation where you think you'd be too constrained by the language to write your code effectively?
I'm just being careful that I'm not promising to deliver features in a specific timeframe. If I told you (for example) that we were going to have generics (or any other feature) in the next version and then something changed, you'd be unhappy. I'd rather underpromise at this point. That's fair enough. I guess I may be reading too much in to what you're saying when you're just trying to be cautious. :) Is there a specific situation where you think you'd be too constrained by the language to write your code effectively? Well, the obvious one is writing a container class. Not that I write my own, I use STL, but if I needed to write one because the STL didn't have something to suit me, I would absolutely write it as a templated class and write iterators so that it plugged into the STL. Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
-
I'm just being careful that I'm not promising to deliver features in a specific timeframe. If I told you (for example) that we were going to have generics (or any other feature) in the next version and then something changed, you'd be unhappy. I'd rather underpromise at this point. That's fair enough. I guess I may be reading too much in to what you're saying when you're just trying to be cautious. :) Is there a specific situation where you think you'd be too constrained by the language to write your code effectively? Well, the obvious one is writing a container class. Not that I write my own, I use STL, but if I needed to write one because the STL didn't have something to suit me, I would absolutely write it as a templated class and write iterators so that it plugged into the STL. Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
Thanks for the scenario. All the .NET container classes deal with parameters of type object, so I'd typically write something like: Hashtable ht = new Hashtable(); ht.Add("Hello", "Goodbye"); ht.Add("Hot", "Cold"); ht.Add("True", "False"); If I want to access the values, I need to do something like: string key = "Hello"; string s = (string) ht[key]; where I cast from object to string. That's a bit clumsy, but it's not that bad. If I'm dealing with an ArrayList, things work similarly: ArrayList ar = new ArrayList(); ar.Add("Hello"); ar.Add("Aloha"); ar.Add("Buenos Dias"); for (int i = 0; i < ar.Count; i++) { Console.WriteLine(ar[i]); string s = (string) ar[i]; } Many times, I'd use a foreach, and then wouldn't need the cast: foreach (string greeting in ar) { Console.WriteLine(greeting); string s = greeting; } So, while you do have to use a few extra casts, you don't lose any type safety (though it is at runtime rather than compile time). You do have boxing overhead if your collection stores a value type. WRT STL, I know that it's well liked by lots of people, but it's far too baroque for my tastes; I don't find that the added flexibility is worth the additional complexity. Having a templated list is really useful; being able to mix and match with iterators makes it too complex for my tastes. Keeping C# from being too complex is one of our design goals, so we'll have to balance the power the generics can add with the complexity that they add. I'm not sure how that will shake out, but it's possible you couldn't write something like STL in C#. Personally, I think I'd view that as a "good thing".
-
Thanks for the scenario. All the .NET container classes deal with parameters of type object, so I'd typically write something like: Hashtable ht = new Hashtable(); ht.Add("Hello", "Goodbye"); ht.Add("Hot", "Cold"); ht.Add("True", "False"); If I want to access the values, I need to do something like: string key = "Hello"; string s = (string) ht[key]; where I cast from object to string. That's a bit clumsy, but it's not that bad. If I'm dealing with an ArrayList, things work similarly: ArrayList ar = new ArrayList(); ar.Add("Hello"); ar.Add("Aloha"); ar.Add("Buenos Dias"); for (int i = 0; i < ar.Count; i++) { Console.WriteLine(ar[i]); string s = (string) ar[i]; } Many times, I'd use a foreach, and then wouldn't need the cast: foreach (string greeting in ar) { Console.WriteLine(greeting); string s = greeting; } So, while you do have to use a few extra casts, you don't lose any type safety (though it is at runtime rather than compile time). You do have boxing overhead if your collection stores a value type. WRT STL, I know that it's well liked by lots of people, but it's far too baroque for my tastes; I don't find that the added flexibility is worth the additional complexity. Having a templated list is really useful; being able to mix and match with iterators makes it too complex for my tastes. Keeping C# from being too complex is one of our design goals, so we'll have to balance the power the generics can add with the complexity that they add. I'm not sure how that will shake out, but it's possible you couldn't write something like STL in C#. Personally, I think I'd view that as a "good thing".
WRT STL, I know that it's well liked by lots of people, but it's far too baroque for my tastes; I don't find that the added flexibility is worth the additional complexity. Having a templated list is really useful; being able to mix and match with iterators makes it too complex for my tastes. *grin* baroque - I like that. I admit it has a learning curve, but once you know it, I don't find it particularly complex. Keeping C# from being too complex is one of our design goals, so we'll have to balance the power the generics can add with the complexity that they add. I'm not sure how that will shake out, but it's possible you couldn't write something like STL in C#. Personally, I think I'd view that as a "good thing". Given your target for the language ( i.e. the power of C++, the simplicity of VB ), I can see how templates and certainly STL like containers would be a low to non-priority. I guessed that C# would have it's own containers - how is this done without some sort of generics ? Am I wrong in thinking your example showed me how to use existing containers rather than write my own ? Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
-
WRT STL, I know that it's well liked by lots of people, but it's far too baroque for my tastes; I don't find that the added flexibility is worth the additional complexity. Having a templated list is really useful; being able to mix and match with iterators makes it too complex for my tastes. *grin* baroque - I like that. I admit it has a learning curve, but once you know it, I don't find it particularly complex. Keeping C# from being too complex is one of our design goals, so we'll have to balance the power the generics can add with the complexity that they add. I'm not sure how that will shake out, but it's possible you couldn't write something like STL in C#. Personally, I think I'd view that as a "good thing". Given your target for the language ( i.e. the power of C++, the simplicity of VB ), I can see how templates and certainly STL like containers would be a low to non-priority. I guessed that C# would have it's own containers - how is this done without some sort of generics ? Am I wrong in thinking your example showed me how to use existing containers rather than write my own ? Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
Given your target for the language ( i.e. the power of C++, the simplicity of VB ), I can see how templates and certainly STL like containers would be a low to non-priority. I guessed that C# would have it's own containers - how is this done without some sort of generics ? Am I wrong in thinking your example showed me how to use existing containers rather than write my own **** I wouldn't call them a low priority. We do value performance, and I think having better perf on value types is an important goal (you can write your own type-specific collection class if you really need the perf). If you want to write your own container, you can just make it store a value of type object, and you therefore know it can store any type in the type system.
-
Given your target for the language ( i.e. the power of C++, the simplicity of VB ), I can see how templates and certainly STL like containers would be a low to non-priority. I guessed that C# would have it's own containers - how is this done without some sort of generics ? Am I wrong in thinking your example showed me how to use existing containers rather than write my own **** I wouldn't call them a low priority. We do value performance, and I think having better perf on value types is an important goal (you can write your own type-specific collection class if you really need the perf). If you want to write your own container, you can just make it store a value of type object, and you therefore know it can store any type in the type system.
Oh - so it's like Java ? I'm wondering, given how C# is so similar to Java, why it gets marketed as a better C++ instead of a better Java ? I've not used it yet, but every snippet I've seen looks more like Java than C++ to me. Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
-
Given your target for the language ( i.e. the power of C++, the simplicity of VB ), I can see how templates and certainly STL like containers would be a low to non-priority. I guessed that C# would have it's own containers - how is this done without some sort of generics ? Am I wrong in thinking your example showed me how to use existing containers rather than write my own **** I wouldn't call them a low priority. We do value performance, and I think having better perf on value types is an important goal (you can write your own type-specific collection class if you really need the perf). If you want to write your own container, you can just make it store a value of type object, and you therefore know it can store any type in the type system.
From my perspective, the lack of generics is a massive sideways step in the evolution of programming languages. I see a clear path of evolution of progamming theory : 1. Assembler 2. Procedural (C, Pascal) 3. Object Oriented (C++, Smalltalk, Java, and now C#) 4. Generics (C++ templates, ???) The entire concept of generics is only just starting to get underway - the STL and Containers are just the tip of the iceberg. Whilst OO has moved programming theory foward in leaps and bounds in terms of encapsulation, etc, the "reuse" element has proven to be not as great as first thought. Designing truly resuable classes has proven to be difficult. Generics offers a immediate boost to the reuse concept - in effect, you are telling the compiler to write the details after you give it the broad concept ("Compiler, I want a vector of ints - go do it now, please"). Unfortunately, the only currently widely available implementation of generics theory is C++ templates, and that cares a large complexity burden just in the syntax, if not the concept. I believe that generic programming has not spread quickly precisely because the C++ 'overhead' is too great - the implementation is dragging the theory down. C# is a new syntax for Objected Oriented programming - it is not a new concept in programming. The lack of generics both limits the language itself, and(and this is my greater concern) the evolution of programming theory itself. If the vast majority of programmers are using a language that offers no generic concepts at all, then the entire thory of generics becomes just an academic sideline - one that has little practical application. To me, C# is a step sideways in most regards, and a big step backwards in the area of generics. This cannot be a good thing - but we're stuck with it for the immediate future! Such is the power of a monopoly ...
-
From my perspective, the lack of generics is a massive sideways step in the evolution of programming languages. I see a clear path of evolution of progamming theory : 1. Assembler 2. Procedural (C, Pascal) 3. Object Oriented (C++, Smalltalk, Java, and now C#) 4. Generics (C++ templates, ???) The entire concept of generics is only just starting to get underway - the STL and Containers are just the tip of the iceberg. Whilst OO has moved programming theory foward in leaps and bounds in terms of encapsulation, etc, the "reuse" element has proven to be not as great as first thought. Designing truly resuable classes has proven to be difficult. Generics offers a immediate boost to the reuse concept - in effect, you are telling the compiler to write the details after you give it the broad concept ("Compiler, I want a vector of ints - go do it now, please"). Unfortunately, the only currently widely available implementation of generics theory is C++ templates, and that cares a large complexity burden just in the syntax, if not the concept. I believe that generic programming has not spread quickly precisely because the C++ 'overhead' is too great - the implementation is dragging the theory down. C# is a new syntax for Objected Oriented programming - it is not a new concept in programming. The lack of generics both limits the language itself, and(and this is my greater concern) the evolution of programming theory itself. If the vast majority of programmers are using a language that offers no generic concepts at all, then the entire thory of generics becomes just an academic sideline - one that has little practical application. To me, C# is a step sideways in most regards, and a big step backwards in the area of generics. This cannot be a good thing - but we're stuck with it for the immediate future! Such is the power of a monopoly ...
Let's face it though - it's hardly surprising that Microsoft are not including generics in C#, if they had figured out how it was done they would have adhered to the full standard in C++. VC++ 7 is coming soon, and the M$ response to bug reports ( from CUJ/WDJ, where I read them ) is 'known bug, future release'. I don't get why they need to reveal a new lagnauge when they could spend time getting the languages they impliment already right instead. My great fear is that M$ is sick of people pointing out how poorly they do in this area and hope to retire non M$ languages in the next few releases, so no-one can tell them they got it wrong, as they will be *writing* the standard. Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
-
Let's face it though - it's hardly surprising that Microsoft are not including generics in C#, if they had figured out how it was done they would have adhered to the full standard in C++. VC++ 7 is coming soon, and the M$ response to bug reports ( from CUJ/WDJ, where I read them ) is 'known bug, future release'. I don't get why they need to reveal a new lagnauge when they could spend time getting the languages they impliment already right instead. My great fear is that M$ is sick of people pointing out how poorly they do in this area and hope to retire non M$ languages in the next few releases, so no-one can tell them they got it wrong, as they will be *writing* the standard. Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
Templates are extremely important. It is very unfortunate that C# will not have them. Without templates, i'm not excited about C#. I'm shur that C# has many compelling features, as it has the advantage of hindsight on what other lanaguages do well and dont, but without templates, its just not that interesting to me. I will stick with C++ thank you.
-
Thanks for the scenario. All the .NET container classes deal with parameters of type object, so I'd typically write something like: Hashtable ht = new Hashtable(); ht.Add("Hello", "Goodbye"); ht.Add("Hot", "Cold"); ht.Add("True", "False"); If I want to access the values, I need to do something like: string key = "Hello"; string s = (string) ht[key]; where I cast from object to string. That's a bit clumsy, but it's not that bad. If I'm dealing with an ArrayList, things work similarly: ArrayList ar = new ArrayList(); ar.Add("Hello"); ar.Add("Aloha"); ar.Add("Buenos Dias"); for (int i = 0; i < ar.Count; i++) { Console.WriteLine(ar[i]); string s = (string) ar[i]; } Many times, I'd use a foreach, and then wouldn't need the cast: foreach (string greeting in ar) { Console.WriteLine(greeting); string s = greeting; } So, while you do have to use a few extra casts, you don't lose any type safety (though it is at runtime rather than compile time). You do have boxing overhead if your collection stores a value type. WRT STL, I know that it's well liked by lots of people, but it's far too baroque for my tastes; I don't find that the added flexibility is worth the additional complexity. Having a templated list is really useful; being able to mix and match with iterators makes it too complex for my tastes. Keeping C# from being too complex is one of our design goals, so we'll have to balance the power the generics can add with the complexity that they add. I'm not sure how that will shake out, but it's possible you couldn't write something like STL in C#. Personally, I think I'd view that as a "good thing".
this is really a reply to the rest of the thread...
i'm new to c# but have been trying to learn it, i am also well expereienced with stl and templates and such i have found so far that c# provides the same flavor of template programming. the richness and robustness of the base class library provides this. it may take a few extra lines of code but you can easily create type specific containers
//example code entered from memory, pardon the syntax
class CFoo {//foo}class CFoos : CollectionBase
{
public CFoos()
{}
private override int Add(object item)
{
//made private to block access
return 0;
}public int Add(CFoo foo)
{
this.innerlist.add(foo);
return 0;
}//rest of implementation
//don't forget the indexer
}this is very flexible, and is extremely easy to write "baroque" is a good description of the stl, something that is so foundational should be easier to use (or at least better documented ;P ) if all you want out of generics is typed containers then c# doesn't need them. one of the main uses i had been using templates in c++ was for custom memory mangement, creating template class for managing different types T of stuff, but with the hands-off memory management of c# this use for generics is now moot. there are many other uses, i think they would still be extremely useful, but the gross case issues are already taken care of. -John
-
WRT STL, I know that it's well liked by lots of people, but it's far too baroque for my tastes; I don't find that the added flexibility is worth the additional complexity. Having a templated list is really useful; being able to mix and match with iterators makes it too complex for my tastes. *grin* baroque - I like that. I admit it has a learning curve, but once you know it, I don't find it particularly complex. Keeping C# from being too complex is one of our design goals, so we'll have to balance the power the generics can add with the complexity that they add. I'm not sure how that will shake out, but it's possible you couldn't write something like STL in C#. Personally, I think I'd view that as a "good thing". Given your target for the language ( i.e. the power of C++, the simplicity of VB ), I can see how templates and certainly STL like containers would be a low to non-priority. I guessed that C# would have it's own containers - how is this done without some sort of generics ? Am I wrong in thinking your example showed me how to use existing containers rather than write my own ? Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
"the power of C++, the simplicity of VB" Now, let's face it. C# does not have the power of C++, not even close. On the other side, VB is not that simple at all, except for trivial apps; I've worked with both C++ and VB, and found that VB can be as complex as any other language. IMHO C# can be a nice replacement for VB (that is, if VB programmers decide to change their programming language :suss: ). It has MUCH nicer syntax than VB, and it can be used in all the situations where VB was dominant (database front end, ASP, middle-tier components). I vote pro drink X|
-
From my perspective, the lack of generics is a massive sideways step in the evolution of programming languages. I see a clear path of evolution of progamming theory : 1. Assembler 2. Procedural (C, Pascal) 3. Object Oriented (C++, Smalltalk, Java, and now C#) 4. Generics (C++ templates, ???) The entire concept of generics is only just starting to get underway - the STL and Containers are just the tip of the iceberg. Whilst OO has moved programming theory foward in leaps and bounds in terms of encapsulation, etc, the "reuse" element has proven to be not as great as first thought. Designing truly resuable classes has proven to be difficult. Generics offers a immediate boost to the reuse concept - in effect, you are telling the compiler to write the details after you give it the broad concept ("Compiler, I want a vector of ints - go do it now, please"). Unfortunately, the only currently widely available implementation of generics theory is C++ templates, and that cares a large complexity burden just in the syntax, if not the concept. I believe that generic programming has not spread quickly precisely because the C++ 'overhead' is too great - the implementation is dragging the theory down. C# is a new syntax for Objected Oriented programming - it is not a new concept in programming. The lack of generics both limits the language itself, and(and this is my greater concern) the evolution of programming theory itself. If the vast majority of programmers are using a language that offers no generic concepts at all, then the entire thory of generics becomes just an academic sideline - one that has little practical application. To me, C# is a step sideways in most regards, and a big step backwards in the area of generics. This cannot be a good thing - but we're stuck with it for the immediate future! Such is the power of a monopoly ...
Sidestep my ass! ;) While I use templates, it isn't because I WANT to use them, but because there isn't an alternative. PLEASE don't tell me that you find STL, ATL, or WTL template classes easy to use!!! They aren't. I've been using STL for 3 years, and while I can do some wonderful things with it, they also create quite a bit of confusion....what is "second" when you're using a given iterator?? The compiler knows, but the programmer is a bit fuzzier. I find myself having to look back at my typedefs (needed to keep the template names form getting overly lengthy) a lot....and if I write a class with templates (either a template based class or a function with a template parameter) I have to stick my code in the header whereas all the non-template code can be in the .cpp file....ick! I look at it like this: It seems MS is looking at making 90% of the programmers in the world happier and more efficient....for 10% of the developers C# won't tackle the most complex problems, but since they're in the top 10%, they'll have no problem writting their code in unmanaged C++....where is the tradeoff....or is this really just the sort of thing I hate seeing from my clients -- the desire to have the kitchen sink in everything for no particularly good reason.