Is Microsoft abandoning generics?
-
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++. **** It's not a matter of "figuring out how it's done", it's a matter of resources. At the beginning of this product cycle, the C++ team had to choose between making C++ better or developing a way to write .NET code using C++ (known as the Managed Extentions to C++). This was a choice between being part of the .NET world or not, and not having the managed extensions would have made it much much more difficult for people to move to the .NET world. Doing so took a fair amount of resources, and therefore we couldn't make as many improvements to the standard C++ side of the world as we'd like. The Visual C++ .NET (7.0) release does have improved performance, but it doesn't have things like partial template specialization. We do, however, have some new optimization improvements, such as full-program optimization. If you feel strongly about this, you might want to post your views in the microsoft.public.dotnet.languages.vc newsgroup on the Microsoft news server, where you'll encounter PMs who are responsible for the next version (ie the one after this fall's). They know more about our plans than I do. Or, alternatively, if there was enough interest, I could try to recruit one, and you could ask questions here.
Or, alternatively, if there was enough interest, I could try to recruit one, and you could ask questions here. The number of people who responded in the eight odd hours since I logged off and went to bed are probably a testament to the fact that there is a fair degree of concern amongst VC users that the standard seems to be getting ignored in favour of new gadgets. I am constantly disappointed to read about cool things that can be done with templates, with the caveat that VC's implimentation is too poor to support them. For example, I was reading in the Sept 2001 WDJ a review of a book called Modern C++ Design, which apparently includes a library that works under Code Warrior, but due to use of templates ( within the standard ) reports 100's of syntax errors in VC. I'd love to see someone who makes these sorts of decisions here, and I think it's clear from the responses below that I'm not the only one who would like to ask some tough questions about Microsoft's commitment to C++. I'm also interested to know how Microsoft would feel if a third party implimented the C# standard in as ad hoc a manner ? I know we're talking about reasonably esoteric features here, but we're up to release 6, service pack 5, and we're saying no real improvement in version 7. 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. 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 think you have to look at the strengths of templates to get a clear picture: 1) Type safety. 2) Generalizing algorithms to operate on any data type. You proposed that C# can handle the same things that C++ templates do, in a simpler fashion. From what I see from your example code posted to Christian, C# takes the same route as Java for its container classes: casting. But your code is not quite correct -- to match the equivalent C++ syntax, where the data type is bound to the container and will be caught at runtime, I'd have to write at try/catch handler to deal with a bad cast during a program run: ArrayList ar = new ArrayList(); ar.Add("Hello"); ar.Add("Aloha"); ar.Add("Buenos Dias"); try { for (int i = 0; i < ar.Count; i++) { Console.WriteLine(ar[i]); string s = (string) ar[i]; } } catch (InvalidCastException e) { Console.WriteLine("Illegal cast"); } Compare this to the much safer and shorter C++ version without the need for exception handling (where the data type is bound to an STL list template). Run-time safety is definitely _not_ the same as compile-time safety. This is a big advantage of STL -- I cannot make a mistake in casting that will throw an exception; there's no casting to screw up. Doing a bad cast happens to me a lot in Java programming, when using many different containers with UDTs. Also, another proposal suggests that you can add methods to your own containers easily, but this is just what templates were NOT designed for. The purpose of templates was to separate algorithms from their containers. Template algorithms can operate in a generic way on ANY container in the same fashion. From your example (correct me if I'm wrong), but you can only do simple operations like copy and swap on a C# base Object type. Anything more complex, and you're back to casting or trying to design generic interfaces for some base class container. The only thing I won't argue with you on is iterators, which are the least useful element of STL and probably the most confusing. I wish all STL algorithms assumed that they were to operate on the entire container by default. I hope this provides you with the concrete examples you were looking for. Best regards, CodeGuy http://groups.yahoo.com/group/wtl
-
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.
So you agree with me! My point is that the THEORY of generic programming is (at the moment) supported by a fairly poor IMPLEMENTATION in the form of C++ templates. The complexity of the basic concept is amplified greatly by the C++ syntax. I have no argument with anyone who wants to discuss the many and varied problems and difficulties in becoming familiar with C++ templates. This has lead to a situation where the only real widespread use of generic programming is containers - the STL being a primary eaample. Yet ATL and WTL demonstrate my basic point better - here are powerful frameworks that offer much greater control and power than MFC, yet are used by most people grudgingly simply because the C++ template syntax and rules are intrinsically complex. Do I want to continue using C++ template for generic programming? Not particularly - like you, I want a better syntax for expressing concepts, an end to typedefs , better documentation, etc. I tolerate ATL/WTL/STL because I have no choice. Do I want generic programming removed from my programming choices? NO! Removing generics from the programming landscape just at the time that the concepts are starting to develop is extremely frustrating. In short, we need to improve generics, not remove them. Microsoft created C# - in doing so, they had to make choices. They decided that generics was not as important as other features. I regret that decision very much - to me, it sounds a little like deciding to make an "improved C compiler" rather than a "new fangled C++ compiler" back in 1989. Had they decided to do that, they'd have got it wrong badly - because there were plenty of rivals, and they were making the move to C++. In the absence of any serious rival for desktop languages in 2001, there is no real market pressure on this current decision, so it will be 'right' by default - and we get 5 more years of 'java-style' programming (just a different flavor of OOP).
-
So you agree with me! My point is that the THEORY of generic programming is (at the moment) supported by a fairly poor IMPLEMENTATION in the form of C++ templates. The complexity of the basic concept is amplified greatly by the C++ syntax. I have no argument with anyone who wants to discuss the many and varied problems and difficulties in becoming familiar with C++ templates. This has lead to a situation where the only real widespread use of generic programming is containers - the STL being a primary eaample. Yet ATL and WTL demonstrate my basic point better - here are powerful frameworks that offer much greater control and power than MFC, yet are used by most people grudgingly simply because the C++ template syntax and rules are intrinsically complex. Do I want to continue using C++ template for generic programming? Not particularly - like you, I want a better syntax for expressing concepts, an end to typedefs , better documentation, etc. I tolerate ATL/WTL/STL because I have no choice. Do I want generic programming removed from my programming choices? NO! Removing generics from the programming landscape just at the time that the concepts are starting to develop is extremely frustrating. In short, we need to improve generics, not remove them. Microsoft created C# - in doing so, they had to make choices. They decided that generics was not as important as other features. I regret that decision very much - to me, it sounds a little like deciding to make an "improved C compiler" rather than a "new fangled C++ compiler" back in 1989. Had they decided to do that, they'd have got it wrong badly - because there were plenty of rivals, and they were making the move to C++. In the absence of any serious rival for desktop languages in 2001, there is no real market pressure on this current decision, so it will be 'right' by default - and we get 5 more years of 'java-style' programming (just a different flavor of OOP).
I couldn't agree more that templates in C++ are poorly implemented. But at the same time, I also understand the MS stance that they had to start somewhere....and given that everything is derived from a common base object, the absolute need for generics is reduced in C# compared to C++. But again.....I've heard sooooo many silly arguements against C# which boil down to: Why did MS create a new language without my permission....;) Obviously C++ is a very complex, very powerful language. But Java -- the less powerful language -- is being used by more and more people.....so why not create a language which builds on the better aspects of 3 languages?? Afterall, C was built on B.....C++ on C....Java on C++.....it only makes sense. I feel people are throwing the baby out with the bath water with C#.....its still a very new language. Lets use it before we complain about it!
-
So you agree with me! My point is that the THEORY of generic programming is (at the moment) supported by a fairly poor IMPLEMENTATION in the form of C++ templates. The complexity of the basic concept is amplified greatly by the C++ syntax. I have no argument with anyone who wants to discuss the many and varied problems and difficulties in becoming familiar with C++ templates. This has lead to a situation where the only real widespread use of generic programming is containers - the STL being a primary eaample. Yet ATL and WTL demonstrate my basic point better - here are powerful frameworks that offer much greater control and power than MFC, yet are used by most people grudgingly simply because the C++ template syntax and rules are intrinsically complex. Do I want to continue using C++ template for generic programming? Not particularly - like you, I want a better syntax for expressing concepts, an end to typedefs , better documentation, etc. I tolerate ATL/WTL/STL because I have no choice. Do I want generic programming removed from my programming choices? NO! Removing generics from the programming landscape just at the time that the concepts are starting to develop is extremely frustrating. In short, we need to improve generics, not remove them. Microsoft created C# - in doing so, they had to make choices. They decided that generics was not as important as other features. I regret that decision very much - to me, it sounds a little like deciding to make an "improved C compiler" rather than a "new fangled C++ compiler" back in 1989. Had they decided to do that, they'd have got it wrong badly - because there were plenty of rivals, and they were making the move to C++. In the absence of any serious rival for desktop languages in 2001, there is no real market pressure on this current decision, so it will be 'right' by default - and we get 5 more years of 'java-style' programming (just a different flavor of OOP).
Microsoft created C# - in doing so, they had to make choices. They decided that generics was not as important as other features. I regret that decision very much - to me, it sounds a little like deciding to make an "improved C compiler" rather than a "new fangled C++ compiler" back in 1989. ***** Can you tell me what scenarios you'd use generics in that you can't do without them (ie using object) in C#?
-
Eric, being someone who has never been part of a compiler or interpreter developement team, I obviously am no expert, but it seems to me that a computer language is nothing more than a syntax. The compiler interprets the code, and converts it in to a form that the processor can use. My collegue and I came up with this scheme for templates in VB.NET (don't know how MS was planning to do this, if at all in VB, but we liked this syntax):
Public Template <T> Class MyArray
Private m_Array() As T
Private m_nElementCount As Integer=0Public Function Add(newElement As T) As Integer
m_nElementCount+=1
Redim Preserve m_Array(m_nElementCount)
m_Array(m_nElementCount)=newElement
Return m_nElementCount
End Function
End ClassWhich I see as equivilent to:
<template class T>
class MyArray
{
private:
T *m_Array;
int m_nElementCount;public:
int Add(T& newElement)
{
m_nElementCount++;
m_Array=(T *)realloc(m_Array, m_nElementCount * sizeof(T));
m_Array(m_nElementCount)=newElement;
return m_nElementCount;
}
};They're almost identical, except that one is VB.NET, the other is C++(.NET). So why does it matter what language you're using; can't the VB (or C# for those codes) compiler simply use the same algorythms with different key words? Again, I don't know the specifics, so that's why I'm asking. :) Thanks in advance for any insight. Jamie Nordmeyer Portland, Oregon, USA
What we're talking about doing for C# isn't a template based approach; it's an approach where generic types exist at the runtime level. I think it's a superior approach for a number of reasons, but implementing it requires both compiler and runtime work.
-
What we're talking about doing for C# isn't a template based approach; it's an approach where generic types exist at the runtime level. I think it's a superior approach for a number of reasons, but implementing it requires both compiler and runtime work.
Ah. I see. Thanks for the reply, Eric. :) Jamie Nordmeyer Portland, Oregon, USA
-
What we're talking about doing for C# isn't a template based approach; it's an approach where generic types exist at the runtime level. I think it's a superior approach for a number of reasons, but implementing it requires both compiler and runtime work.
Forgot to ask; will you be doing such a thing for just C#, or for the CLR (so it's available to all languages)? Thanks again. Jamie Nordmeyer Portland, Oregon, USA
-
Forgot to ask; will you be doing such a thing for just C#, or for the CLR (so it's available to all languages)? Thanks again. Jamie Nordmeyer Portland, Oregon, USA
It will be in the CLR, but it's not clear how much other languages will expose it.
-
It will be in the CLR, but it's not clear how much other languages will expose it.
Well, as a VB programmer, I gaurentee you'll have a lot of people very upset if VB doesn't support some form of generics, when the means to do so exist in the CLR runtime. Myself included. Again it goes back to a matter of syntax; if C++ and C# can handle generics, why on Earth would you leave it out of VB when the syntax, as I imagine it, anyway, is almost identical? Jamie Nordmeyer Portland, Oregon, USA
-
Well, as a VB programmer, I gaurentee you'll have a lot of people very upset if VB doesn't support some form of generics, when the means to do so exist in the CLR runtime. Myself included. Again it goes back to a matter of syntax; if C++ and C# can handle generics, why on Earth would you leave it out of VB when the syntax, as I imagine it, anyway, is almost identical? Jamie Nordmeyer Portland, Oregon, USA
I don't think it's really a matter of syntax; I think it's more a matter of language philosophy. I think the question would be how you could expose generics in VB without adding a lot of complexity. That's really a question for the VB team, however; I'm not that knowledgeable about their users.
-
I don't think it's really a matter of syntax; I think it's more a matter of language philosophy. I think the question would be how you could expose generics in VB without adding a lot of complexity. That's really a question for the VB team, however; I'm not that knowledgeable about their users.
But it's already complex with the cryptic way that API functions are declared, and in VB5 and above, the AddressOf operator. Generics couldn't complicate things too much more. But, that's for the VB team. ;) Jamie Nordmeyer Portland, Oregon, USA
-
Microsoft created C# - in doing so, they had to make choices. They decided that generics was not as important as other features. I regret that decision very much - to me, it sounds a little like deciding to make an "improved C compiler" rather than a "new fangled C++ compiler" back in 1989. ***** Can you tell me what scenarios you'd use generics in that you can't do without them (ie using object) in C#?
Eric, I can't give you an exact scenario of what I can do in C++ that I can't do in C#, because I haven't used C# yet. So why do I comment on a language I haven't used ? Well, from what I have read C# as some real advantages (I personally am a 'believer' in garbage collection, for example), but it has removed what I consider to be THE most important development in software theory in the last 5years - generics. I can give you a sample of what I am starting to do with templates. C# may be able to do this some other way, so this may not stand as a perfect example of the differences - however, I still believe that my use and understanding of generics(templates) is only just beginning - containers are the obvious first example, but generica can go much further. I needde to develop a persistence system for reading/writing C++ objects to disk. I wanted this to be 'seemless', and to handle both objects, containers of objects, and containers of pointers of objects. In the later case, a container of objectws may not all be of the same type - the container may conatiner pointers to base objects, or to any number of derived class objects. To make such containers 'type safe' I needed to be able to defined aleternative methods of 'copying' a container. For utility reasons I needed to write a 'find' function that searches a special variation of containers and finds items that match a given string. In some instances this search is case sensitive, in some cases it is not. So I had a number of varying requirements - XML IO, string matching, containers of pointers, base/derived construction and copying. I have written a set of templates that encompasses all of these requirements - any programmer can now simply 'request' the type of the functionality required of his objects/containers by simply inherting from template classes, or sending his own class into a template. Is it complex ? yes. Is the syntax frightening? Yes (well, typedefs REALLY help this a lot). Does it work well ? Yes. I can now implement any number of variations on these themes, with just a single line of code, and can extend this system at any time (for instance, if I need a new type of string matching - say Asian language support) I roll up a new 'string matching traits' template, and it instantly 'fits' with all the other classes and templates. I regret the syntax and complexity that C++ templates forces on me, but the end result is SO powerful it amazing. "Modern C++ Design" is the book that best demonstrates these new concepts. The
-
I couldn't agree more that templates in C++ are poorly implemented. But at the same time, I also understand the MS stance that they had to start somewhere....and given that everything is derived from a common base object, the absolute need for generics is reduced in C# compared to C++. But again.....I've heard sooooo many silly arguements against C# which boil down to: Why did MS create a new language without my permission....;) Obviously C++ is a very complex, very powerful language. But Java -- the less powerful language -- is being used by more and more people.....so why not create a language which builds on the better aspects of 3 languages?? Afterall, C was built on B.....C++ on C....Java on C++.....it only makes sense. I feel people are throwing the baby out with the bath water with C#.....its still a very new language. Lets use it before we complain about it!
I hate to boil things down to a 'single issue', but my one and only (strong) issue with C# is generics. In many ways C# sounds like an improvement over C++. I also liked a lot of Java concepts (initially). The only point I am making here that generics are far more important than just container implementations. There's a whole new level of programming (type safe, efficient, flexible) hiding in the C++ syntax, and Java and C# are locking us out of it entirely. What we need is a language where generics are a primarly feature, not an add on (as they are in C++, and will be in Java and C# (perhaps - it remains to be seen whether such promises ever really see the light of day, and in what form)). I accept the reality that we don't have that, and will not have that in the forseeable future. I am just expressing a little frustration that the first large scale, widely available language in the last 6 years has chosen to ignore a major advance in programming theory, simply because generics are difficult to implement, and are assumed to be about 'containers'. Very short sighted, very wrong.
-
I hate to boil things down to a 'single issue', but my one and only (strong) issue with C# is generics. In many ways C# sounds like an improvement over C++. I also liked a lot of Java concepts (initially). The only point I am making here that generics are far more important than just container implementations. There's a whole new level of programming (type safe, efficient, flexible) hiding in the C++ syntax, and Java and C# are locking us out of it entirely. What we need is a language where generics are a primarly feature, not an add on (as they are in C++, and will be in Java and C# (perhaps - it remains to be seen whether such promises ever really see the light of day, and in what form)). I accept the reality that we don't have that, and will not have that in the forseeable future. I am just expressing a little frustration that the first large scale, widely available language in the last 6 years has chosen to ignore a major advance in programming theory, simply because generics are difficult to implement, and are assumed to be about 'containers'. Very short sighted, very wrong.
I don't know if I'd say it was short sighted to choose to implement it later due to it being difficult....a lot of my development takes exactly that route....and often by doing that, I give myself more time to think about the problem and come up with a better solution. The way C++ implements templates is a curse on mankind. So if MS went ahead and added generics that were basicaly the same as what C++ offers via templates, we really won't be moving forward. Perhaps with a couple million people writing code in C#, a better way will emerge based on actual developer input rather than the compiler teams assumtions about how people are going to work. I'm going to miss container classes....I'm going to miss algorithms.....but I suspect that there is something which will replace -- after all, I didn't even realize I needed them until 4 years ago! So lets all just relax and take a wait-and-see attitude.
-
Eric, I can't give you an exact scenario of what I can do in C++ that I can't do in C#, because I haven't used C# yet. So why do I comment on a language I haven't used ? Well, from what I have read C# as some real advantages (I personally am a 'believer' in garbage collection, for example), but it has removed what I consider to be THE most important development in software theory in the last 5years - generics. I can give you a sample of what I am starting to do with templates. C# may be able to do this some other way, so this may not stand as a perfect example of the differences - however, I still believe that my use and understanding of generics(templates) is only just beginning - containers are the obvious first example, but generica can go much further. I needde to develop a persistence system for reading/writing C++ objects to disk. I wanted this to be 'seemless', and to handle both objects, containers of objects, and containers of pointers of objects. In the later case, a container of objectws may not all be of the same type - the container may conatiner pointers to base objects, or to any number of derived class objects. To make such containers 'type safe' I needed to be able to defined aleternative methods of 'copying' a container. For utility reasons I needed to write a 'find' function that searches a special variation of containers and finds items that match a given string. In some instances this search is case sensitive, in some cases it is not. So I had a number of varying requirements - XML IO, string matching, containers of pointers, base/derived construction and copying. I have written a set of templates that encompasses all of these requirements - any programmer can now simply 'request' the type of the functionality required of his objects/containers by simply inherting from template classes, or sending his own class into a template. Is it complex ? yes. Is the syntax frightening? Yes (well, typedefs REALLY help this a lot). Does it work well ? Yes. I can now implement any number of variations on these themes, with just a single line of code, and can extend this system at any time (for instance, if I need a new type of string matching - say Asian language support) I roll up a new 'string matching traits' template, and it instantly 'fits' with all the other classes and templates. I regret the syntax and complexity that C++ templates forces on me, but the end result is SO powerful it amazing. "Modern C++ Design" is the book that best demonstrates these new concepts. The
Thanks for the example. In my earlier posts, I neglected to point out that C# does support a variant of generic programming; since everything is be derived from the type "object", an object reference can point to any type in the type system. This means you can write a collection that stores any type, and you can write object persistance code (though serialization is built into the framework, so you don't need to). This is type safe, but it isn't compile-time typesafe; that would be one of the benefits of a real generics implementation.