C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Ecma International Moves to Standardize C++ Binding for CLI Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Javier Estrada Guest Posted: Wed Oct 08, 2003 8:05 pm    Post subject: Ecma International Moves to Standardize C++ Binding for CLI Can anyone clarify the impact of this press release in the future of C++? http://www.ecma-international.org/news/ecma-TG5-PR.htm Quote: From the press release and the figures involved it (Herb, EDG, Dinkumware) would seem that good things may come from it, but what I'm interested in the general--and objective--opinion of the C++ community. In particular, what are the proposed extensions and how seamlessly would my code today integrate with the extensions tomorrow? Regards, Javier [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Martin v. Löwis Guest Posted: Sat Oct 11, 2003 3:18 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for Javier Estrada wrote: Quote: From the press release and the figures involved it (Herb, EDG, Dinkumware) would seem that good things may come from it, but what I'm interested in the general--and objective--opinion of the C++ community. In particular, what are the proposed extensions and how seamlessly would my code today integrate with the extensions tomorrow? I would expect the outcome of this effort to look very much like managed C++ today. I.e. you get __gc, __struct, and __pin keywords, attribute syntax, etc. I personally dislike these extensions - if .NET is not capable of executing C++ as-is without extensions, it may well be that .NET is best used from C# only. If so, extending C++ for it is pointless - any development for .NET will use C#, anyway. Regards, Martin [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Javier Estrada Guest Posted: Tue Oct 14, 2003 8:40 am    Post subject: Re: Ecma International Moves to Standardize C++ Binding for Quote: I would expect the outcome of this effort to look very much like managed C++ today. I.e. you get __gc, __struct, and __pin keywords, attribute syntax, etc. I personally dislike these extensions - if .NET is not capable of executing C++ as-is without extensions, it may well be that .NET is best used from C# only. If so, extending C++ for it is pointless - any development for .NET will use C#, anyway. Someone described before that there is a difference between managed types and managed code. .NET is capable of executing C++ as is--it compiles it to MSIL--and runs it as managed_code. The MC++ keywords are already there, so I wouldn't expect more keywords. On the contrary, I'd expect less if they're going to the effort of produding a "binding". I'd rather expect more integration and compliance from the CLI to the C++language then viceversa--obvious, but I can only guess a few things--e.g., deterministic destruction of objects, instead of GC. I dislike the current idioms for "destructors" in the .NET languages when you get it for free in C++. Other things I would expect would be a seamless mapping of the generics version that .NET will start to offer with Whidbey with C++ templates, although this is a tough nut to crack, given the differences that have been described in some postings. Could possibly Herb or Dave clarify? C'mon, guys, you're moderators I think that this is of interest to several of us, not for the ..NET side of it, but from the C++ aspect. Regards, Javier [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Herb Sutter Guest Posted: Tue Oct 14, 2003 9:36 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for I can offer a few comments on this. As an overall comment, here's my take on the meaning of this work, I think the most important thing I can say is that I believe this work demonstrates the continued relevance of C++ on modern platforms. Specifically: - Myth #1: Critics of C++ frequently claim that it is a "dying tongue." The reality is that C++ is still dominant in the industry and its use is actually still growing moderately (see for example Plum's article in the October issue of DDJ), and I think this work is further evidence that C++ is alive and well in the industry in general. - Myth #2: People almost as frequently claim that C++ is no longer important to Microsoft. The reality is that C++ is the subject of heavy and continued investment (and internal use) at Microsoft. Other Microsoft products, including C#, get attention because they're new, which is understandable. C++ has been a core product for over 10 years and continues to be widely used inside Microsoft to build its products and platforms, including the CLR. The C++/CLI work demonstrates Microsoft's commitment that C++ be a key and first-class language on .NET moving forward, without compromising ISO conformance (which we just spent most of a release cycle on with VC++ 2003, aka 7.1, and will keep improving). - Elegance and stability are both important. The first version of "Managed C++" had problems that need fixing and so a revision is necessary, but stability is also important because people need to know that this is real and won't just be changed again in another two years. Collaborating with experts outside Microsoft on the design, and committing to an open standards process for the extensions, hopefully demonstrates that Microsoft is committing to this as a long-term design for C++ on .NET that is suitable for code investment and that will have multiple interoperable implementations (i.e., not just from Microsoft). After all, the CLI exists on non-Microsoft platforms today too. On 11 Oct 2003 11:18:51 -0400, "Martin v. Löwis" <martin@v.loewis.de> wrote: Quote: I would expect the outcome of this effort to look very much like managed C++ today. I.e. you get __gc, __struct, and __pin keywords, attribute syntax, etc. Not quite. The existing "Managed C++" design had several problems, including: - The syntax and features were uneven, and sometimes just weird. For example, T* meant three different and incompatible things depending on the type of T, so you had to remember the differences all the time, and there was little hope of successfully writing agnostic templates that acted on T*'s. - The extensions looked ugly (e.g., __keywords). Although the reason those names were chosen was that it's the easiest way to respect ISO conformance, the overwhelming response from users was: "Yuck!" So in our revised design we are still doing pure conforming extensions (avoiding taking reserved words), but using different approaches that require more compiler work but are more usable while preserving conformance (e.g., contextual keywords instead of "__" ones). - The extensions lacked first-class support for some fundamental CLR features (e.g., __property decorations on individual member functions that the compiler would cobble together for you, instead of a property abstraction). - MC++ followed what one might call a "two worlds" (or perhaps "schizoid"?) hypothesis -- it did expose the important CLR features, but only for CLR types, not native types; and it did not expose native C++ features also for CLR types. The two worlds were grafted together, not integrated. It turns out that "some things work over here, other things work over there, and it's your job to keep score at home" is just not a good answer. This has been a constant source of surprises to programmers who always have to remember the list of things that don't work, or work differently, when using CLR types. We ought to do better. We are fixing these problems. For the past year or so I've been the lead architect for the language design team, and together with bright people both inside and outside of Microsoft we have come up with a design for the .NET extensions that meets all of the following goals: - provides an elegant (and uniform!) syntax and semantics that give a natural feel for C++ programmers - provides first-class support for all current and upcoming .NET features (e.g., properties, events, garbage collection, generics) for all types including existing C++ classes - provides first-class support for C++ features (e.g., deterministic destruction, templates) for all types including .NET classes - preserves ISO C++ standards conformance (by adding pure extensions, but also in a way that we don't need to use "__" keywords) Quote: I personally dislike these extensions - if .NET is not capable of executing C++ as-is without extensions, it may well be that .NET is best used from C# only. If so, extending C++ for it is pointless - any development for .NET will use C#, anyway. I hear you, but let me put it this way: A key driver here is that developers are increasingly writing programs targeted to modern environments characterized by a virtual machine with garbage collection. Leading examples include the JVM and the .NET CLR (ISO CLI, or Common Language Infrastructure, is the standardized subset of the .NET runtime environment and frameworks class library). True, Standard C++ has no notion of now-fundamental concepts like garbage collection. Does that mean C++ is simply obsolescent? No; it can be cleanly extended to directly support these modern environments, and there's nothing wrong with that. What's more, C++ actually offers compelling advantages that can make it the language of choice for your application, even on the "home turf" of newer languages specifically designed for these new environments. That's the kind of thing I get excited about. Really excited about. For a specific example, see the deterministic destruction notes below. On 14 Oct 2003 04:40:16 -0400, [email]ljestrada (AT) hotmail (DOT) com[/email] (Javier Estrada) wrote: Quote: Someone described before that there is a difference between managed types and managed code. .NET is capable of executing C++ as is--it compiles it to MSIL--and runs it as managed_code. The MC++ keywords are already there, so I wouldn't expect more keywords. On the contrary, I'd expect less if they're going to the effort of produding a "binding". Right. This doesn't preclude keyword cleanup. :-) Quote: I'd rather expect more integration and compliance from the CLI to the C++language then viceversa--obvious, but I can only guess a few things--e.g., deterministic destruction of objects, instead of GC. In C++/CLI, you get "both" deterministic destruction and GC -- both are important and valued, and I've heard as many C# programmers complain about the lack of deterministic destruction in C# as I've heard C++ programmers complain about the lack of GC in C++. C++/CLI delivers both, on a per-object basis for objects of any type. For example, in C++/CLI you can take objects from the .NET Frameworks and C# libraries and naturally apply deterministic destruction to them (by calling delete, or by putting them on the stack where the dtors/Dispose gets run automatically as per C++ usual). Quote: I dislike the current idioms for "destructors" in the .NET languages when you get it for free in C++. Amen. Consider that the normal mode of progress in computing is that we discover idioms and then in later languages/versions add direct language support for them. Frankly, I consider it a regression to take an important feature that already has language support (deterministic destruction) and regress to making it a coding idiom, which is to say fragile and error-prone. Quote: Other things I would expect would be a seamless mapping of the generics version that .NET will start to offer with Whidbey with C++ templates, although this is a tough nut to crack, given the differences that have been described in some postings. Done. Generics and templates are overlapping but distinct features, and each does things well that the other can't touch. Both will be supported and can be used together. For example, generics will be able to match template template parameters (but PLEASE don't tell Andrei, you know what he did with templates -- he's just bound to make this do brain-wrenching things and discover new and completely unforeseen uses for them). For those who are interested in seeing the shape of the project, we will be making the proposed standard's base document (the "starting point" document) publicly available on November 15. Then, starting in December 2003, the new ECMA committee will take over the base document and craft it into a consensus standard, which Microsoft will track (i.e., we will incorporate changes the committee makes into our product). The current thinking is that the ECMA standard will take about one year to complete and approve, so we're targeting the end of 2004. Cheers, Herb P.S.: Okay, so now you know why the C++ Coding Standards books is late. But Andrei and I really are working on it now. --- Herb Sutter (www.gotw.ca) Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso) Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj) Visual C++ architect, Microsoft (www.gotw.ca/microsoft) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Attila Feher Guest Posted: Wed Oct 15, 2003 12:47 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for Martin v. Löwis wrote: Quote: Javier Estrada wrote: From the press release and the figures involved it (Herb, EDG, Dinkumware) would seem that good things may come from it, but what I'm > interested in the general--and objective--opinion of the C++ community. In particular, what are the proposed extensions and how seamlessly would my code today integrate with the extensions tomorrow? I would expect the outcome of this effort to look very much like managed C++ today. I.e. you get __gc, __struct, and __pin keywords, attribute syntax, etc. I personally dislike these extensions - if .NET is not capable of executing C++ as-is without extensions, it may well be that .NET is best used from C# only. If so, extending C++ for it is pointless - any development for .NET will use C#, anyway. IMO the extensions are there to provide reuse of C++ code. Basically you are able to compile you (original) C++ for the .NET and provide interfaces to the C# (or whatever else is used, Python ) native .NET code. Sort of "porting C++ libraries to .NET". I am not exactly convinced that Microsoft wants .NET to be programmed in managed C++. IMO the "ugliness" is one indicator for it. C# being created is another. However if Microsoft wants applications to be ported to .NET (and they do) they have to provide a relatively easy path for porting - hence managed C++ is created. -- Attila aka WW [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Nemanja Trifunovic Guest Posted: Wed Oct 15, 2003 7:49 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for Quote: In C++/CLI, you get "both" deterministic destruction and GC -- both are important and valued, and I've heard as many C# programmers complain about the lack of deterministic destruction in C# as I've heard C++ programmers complain about the lack of GC in C++. C++/CLI delivers both, on a per-object basis for objects of any type. For example, in C++/CLI you can take objects from the .NET Frameworks and C# libraries and naturally apply deterministic destruction to them (by calling delete, or by putting them on the stack where the dtors/Dispose gets run automatically as per C++ usual). Wow!!! We really need that. See what kind perversions I needed to come up with to overcome the lack of deterministic finalization with managed types: http://www.codeproject.com/managedcpp/managedraii.asp [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top WW Guest Posted: Thu Oct 16, 2003 8:57 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for Attila Feher wrote: [SNIP] Quote: IMO the extensions are there to provide reuse of C++ code. Basically you are able to compile you (original) C++ for the .NET and provide interfaces to the C# (or whatever else is used, Python ) native .NET code. Sort of "porting C++ libraries to .NET". I am not exactly convinced that Microsoft wants .NET to be programmed in managed C++. IMO the "ugliness" is one indicator for it. C# being created is another. However if Microsoft wants applications to be ported to .NET (and they do) they have to provide a relatively easy path for porting - hence managed C++ is created. Since writing this I have got the mail from Herb's mailing list... and I am forced to change my position. C++ is there and it is to stay there on top of CLI - as I understand it now. And as for current managed C++: it was a first and somehwat failed attempt. The evolution is going on, as I see with full power. -- WW aka Attila [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Richard Howard Guest Posted: Tue Oct 28, 2003 3:54 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for I came across futher discussion on this on InformIT http://www.informit.com/isapi/weblog_id~{395A2988-9096-47EE-959C-D1357A884A57}/st~{24BBB2C8-C4F9-4474-B4C9-0F9DF4DEC0D8}/weblog/showComments.asp [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top smitty_one_each Guest Posted: Wed Oct 29, 2003 4:43 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for Two questions, Herb: Quote: For those who are interested in seeing the shape of the project, we will be making the proposed standard's base document (the "starting point" document) publicly available on November 15. Then, starting in December 2003, the new ECMA committee will take over the base document and craft it into a consensus standard, which Microsoft will track (i.e., we will incorporate changes the committee makes into our product). The current thinking is that the ECMA standard will take about one year to complete and approve, so we're targeting the end of 2004. 1. Could you elaborate on the relationship between this work and the C++0x work. (Pronouncing C++0x as 'cooks' hints at some cliche about broth...) Quote: Cheers, Herb P.S.: Okay, so now you know why the C++ Coding Standards books is late. But Andrei and I really are working on it now. 2. Can you hint when this bit of reading might be out? Sounds Spring-ish, at best. Alluding to the 'C++ as a dying tongue' thread, my eyeball survey has C++ losing the battle of the bookshelf pretty handily. To answer the 'where is _your_ book?' question in advance, I just figured out the environment variable subtleties so that I could compile boost under VC7.1 with bjam. Domo, Chris [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Chris Wundram Guest Posted: Thu Oct 30, 2003 2:33 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for Quote: - MC++ followed what one might call a "two worlds" (or perhaps "schizoid"?) hypothesis -- it did expose the important CLR features, but only for CLR types, not native types; and it did not expose native C++ features also for CLR types. The two worlds were grafted together, not integrated. It turns out that "some things work over here, other things work over there, and it's your job to keep score at home" is just not a good answer. This has been a constant source of surprises to programmers who always have to remember the list of things that don't work, or work differently, when using CLR types. I found this to be one of the most usefull features of the current managed c++ implementation. When I want to develop for the CLR, I would use c# which has a good mapping of it's features to the CLR's object model. However when I am writing libraries for the CLR, (that bridge the CLR to older legacy libraries written for c++), I use the current managed c++ because it allows me to use both object models in the same code. So I can, for example, write code for CLR objects which live in the managed heap, and are garbage collected, that use older C++ objects which live in the win32 heap, and are not garbage collected. Sure the current syntax of managed c++ is not pretty, but given that it's primary purpose (in my opinion), is to bridge the old win32 world with the new managed world, I think the syntax that maintains a seperation of the two object models is good. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Herb Sutter Guest Posted: Mon Nov 10, 2003 7:59 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for On 29 Oct 2003 11:43:42 -0500, [email]smitty_one_each (AT) hotmail (DOT) com[/email] (smitty_one_each) wrote: Quote: 1. Could you elaborate on the relationship between this work and the C++0x work. The two are separate. C++0x is the next version of the ISO C++ standard, currently under development -- the evolution of the C++ language. C++/CLI is a binding between that ISO C++ standard and the ISO CLI standard, as set of pure extensions to ISO C++ with near-zero impact on existing ISO C++ programs. The goal is to make it easy and natural to use ISO C++ when writing programs for CLI platforms (e.g., .NET, Rotor, Mono) -- as easy, and in some cases easier, than C#. Quote: 2. Can you hint when this bit of reading might be out? Sounds Spring-ish, at best. That's our current guesstimate too. Herb --- Herb Sutter (www.gotw.ca) Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso) Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj) Visual C++ architect, Microsoft (www.gotw.ca/microsoft) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Tue Nov 11, 2003 3:46 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for In article <aejvqv84b6rh9gg3uc7uaa4hhh3v6o49ju (AT) 4ax (DOT) com>, Herb Sutter <hsutter (AT) gotw (DOT) ca> writes Quote: On 29 Oct 2003 11:43:42 -0500, [email]smitty_one_each (AT) hotmail (DOT) com[/email] (smitty_one_each) wrote: 1. Could you elaborate on the relationship between this work and the C++0x work. The two are separate. C++0x is the next version of the ISO C++ standard, currently under development -- the evolution of the C++ language. C++/CLI is a binding between that ISO C++ standard and the ISO CLI standard, as set of pure extensions to ISO C++ with near-zero impact on existing ISO C++ programs. The goal is to make it easy and natural to use ISO C++ when writing programs for CLI platforms (e.g., .NET, Rotor, Mono) -- as easy, and in some cases easier, than C#. However what concerns a number of us is that these 'pure extensions' will have a negative impact on the future development of C++. I, for one, do not think that introducing new keywords and/or semantics is the task of a bindings standard. Note that I ma not claiming that this will happen but I am saying that should it, I will need very strong persuasion before encouraging my National Body to endorse the resulting ECMA Standard as an ISO one. I know that I am not alone in considering this attempted use of ECMA as an 'end run' and think the Microsoft should be very careful before it continues along this line. I also think that individuals involved in both processes (ECMA and ISO) should carefully consider potential conflicts of interest. -- Francis Glassborow ACCU If you are not using up-to-date virus protection you should not be reading this. Viruses do not just hurt the infected but the whole community. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Glen Low Guest Posted: Tue Nov 11, 2003 5:00 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for Quote: - The extensions lacked first-class support for some fundamental CLR features (e.g., __property decorations on individual member functions that the compiler would cobble together for you, instead of a property abstraction). I wonder whether you're considering (or have considered) mapping some C#/.NET features into their more natural (in C++) syntax: Properties -> proxy classes with operator= and conversion operator overloads Indexers -> operator[] overloads. Essentially this would mean whenever a developer creates a proxy class with just operator= and a conversion operator (possibly marking it somehow in the source?), the operator= and conversion are associated with the equivalent .NET property, so that non-C++ .NET clients could use them transparently as properties. I'd imagine what would need to happen under the hood is the get_xxx and set_xxx methods on the declaring object call through to the equivalent methods on the proxy directly. Since the proxy would have to be a public data member (!) to get the same syntax in C# and C++, it should have the same lifetime as the declaring object. Indexers could work through temporary proxies. I don't know whether it's worth the trouble reconciling these two similar but not identical systems in C++ and .NET. But it would be cool... Cheers, Glen Low, Pixelglow Software www.pixelglow.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Troll_King Guest Posted: Tue Nov 11, 2003 5:02 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for [email]ljestrada (AT) hotmail (DOT) com[/email] (Javier Estrada) wrote in message news:<d522680b.0310130838.4c3a17bc (AT) posting (DOT) google.com>... Quote: I would expect the outcome of this effort to look very much like managed C++ today. I.e. you get __gc, __struct, and __pin keywords, attribute syntax, etc. I personally dislike these extensions - if .NET is not capable of executing C++ as-is without extensions, it may well be that .NET is best used from C# only. If so, extending C++ for it is pointless - any development for .NET will use C#, anyway. Could possibly Herb or Dave clarify? C'mon, guys, you're moderators I think that this is of interest to several of us, not for the .NET side of it, but from the C++ aspect. Regards, Javier I think that C# is a better language for .Net than Standard C++ and here are my reasons. The .Net framework is a product and it's target customer is business and undergraduates (eventually mostly for Europeans and people in the developing countries). The solutions developers are specializing the vendor classes that are already implemented, and a simple language like C# is more than sophisticated enough for solution implementation. Anything that Microsoft deals in is turned into a product, they purposely hold back some features of the product so that they can roll them out later on and charge for upgrades. Microsoft could have used the Standard C++ language definition as the language of .Net in the very begining, however they did not do this on purpose, if anything, Microsoft will offer a Standard C++ mapping of the intermediate language in order to associate Standard C++ with solution implementation as opposed to system implementation (where the focus is on generalization). They will remove the ability to implement systems at the operating sytem layer and in it's place they will let you specialize with Standard C++ and accomplish the same tasks as C# currently handles, so that you will migrate to the .Net framework and their new product line and use a software layer decoupled from the operating system. Microsoft wants above all a more flexible and mobile architecture that they can make into a product and have more control over the factors of production (R&D). Now they will do anything to attract people to the new product line, any langauge goes, they will add 'Seal Language' if it will attract enough followers. I think that Standard C++ for .Net is a bad thing but I don't know what it all means, whether it makes a difference because I really don't understand why people invested time into Standard C++ on the Microsoft product in the first place. And it was all done terribly, your marketing failed because all of the good examples were closed and unavailable to the masses. The truth is that Herbert Schlidt invented C++, that's a fact, especially MSVC++. That is not the reality but it is the fact, just look around anywhere outside this circle. If you can't use Standard C++ and learn, if you are unwilling to learn, to think about the context, than you will have Standard C++ on the .Net framework and be able to migrate to the new product line, but you never even had Standard C++ to begin with, you would closer to the truth if you used Seal Language instead, it would be more fitting.. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top WW Guest Posted: Tue Nov 11, 2003 10:51 pm    Post subject: Re: Ecma International Moves to Standardize C++ Binding for Francis Glassborow wrote: [SNIP] Quote: However what concerns a number of us is that these 'pure extensions' will have a negative impact on the future development of C++. I, for one, do not think that introducing new keywords and/or semantics is the task of a bindings standard. Note that I ma not claiming that this will happen but I am saying that should it, I will need very strong persuasion before encouraging my National Body to endorse the resulting ECMA Standard as an ISO one. [SNIP] IMHO it is already showing if you follow the signs carefully. I mean as I understood the votes of the evolution group, people want a new, more class like, safe enum. And not to touch the existing one. Now it would be a very logical step to use the "enum class" series of keywords to defines such a thing. But wait! That is already used by the C++/CLI binding... And I think it is not too far fecthed that people will start talking about Microsoft hijacking the C++ language via ECMA. I do *not* say it happens (the hijacking) but considering the paranoia around MS and the fact that the proposed syntax does have an effect on the possible routes the C++ evolution can take I believe that people will say this. IMO MS would do better introducing some (one) keyword to put before those constructs. I think about this as a courtesy to ISO and WG21. Otherwise C++/CLI might define constructs in a binding which otherwise would have been taken by the C++ language itself. It would not be a problem in itself, but it will most probably do happen with incompatible semantics. I want to stress again that I am not in any way against the C++/CLI binding, on the contrary. I only think that this binding (ehem, the community making it) should take every possible precaution not to use constructs which the ISO C++ might/could use in its evolution. With some it is quite simple, because "enum class" could actually be called "cli enum", "interface class" could be called "cli interface" and so forth. Possibly with another "trigger" word. it might even be possible with that trigger word remaining free to use as an identifier - if max munch allows. Although I am really a nobody and I do not imagine that I can even hope to have any effect in this quest I humbly but honestly and strongly suggest for the ECMA committee to consider such a construct (triggerword enum, triggerword interface etc.). The biggest problem is with operator symbols. There is an ongoing discussion about creating "Java style references" in C++ (comp.std.c++). I do not really follow it and I have no idea how much real support it has, but such a thing would/could evidently use the hat (^) symbol for its type declaration. But as of today CLI has taken that symbol away. The big question is: will the semantics of the C++/CLI ECMA standard be compatible with the semantics decided for the evolving C++? There was real concern voiced by some at the WG21 meeting about the fact that WG21 (ISO) has no control over the ECMA standardization process. It was worded rather as cooperation/coordination, but basically it trims down to control: since the ECMA standardization will be finished before WG21/J16 members (working on C++ evolution but having no money to spend on ECMA) could have a word on its work. My biggest fear is that the unfortunate happens and C++/CLI (ECMA) will manage to use up C++ constructs what what WG21 later wants to use for the CLI indepedent C++. And those things go into the ECMA standard. And that goes into the ISO fast track process. And then some countries will just not accept it. And when those features will be proposed to ISO WG21 Microsoft will be forced to vote OMDB, since it would kill their efforts. But anyhow, if such a thing happens - even without national bodies rejection and OMDB from MS -, it will be percieved as a hijacking of C++ by MS. And that can have a very very badly effect the future of the language, since it will polarize the ANSI/ISO commitee. I really hope that the honorable effort of making the C++/CLI binding will not result in something like that. But avoiding this disaster scennario won't happen by accident, only by deliberate actions taken by the ECMA team. IMO the people participating in the ECMA work hold a much bigger responsibility than it first meets the eye. They do not only create a binding, but their work will have various effects on the language itself. I do not remember this being explicitly mentioned on the WG21 meeting, but I want to stress that I believe that the ECMA group has a task *beyond* making sure that the CLI related extensions will not break existing code. They have to make sure that whatever extensions they add to the language they will not have any limiting effect on the future evolution of the ISO C++ language. I have already suggested a way for avoiding "overloading" of existing C++ keywords. For places where "collision" is unavoidable the task is even more delicate/difficult. The ECMA team has to make sure that they come up with semantics, which can be generalized up to the semantics the main language may wish to use the construct for. Not an easy task. We have to be honest. Microsoft is big enough to make sure it will have a C++/CLI binding. Its interests call for a fast and effective (for surfacing the CLI features) standardization process. Thanks to Herb it is done very politely. But make no mistake ( (C) G.W.B), it is done in a very determined way. Microsoft's main interest is in making the CLI available and very easy to use in C++. But for the larger C++ community (which is already partially represented in the ECMA committee) it is also important to make sure that the repercussions (I might use the wrong word here) to the C++ language and its evolution are minimal, or even none if possible. It is no easy task. As a sidenote let me express my thoughts about what I see as unusual about the CLI/C++ binding. Language bindings I have seen were either pure library ones, or ones which extended the language with definitely unambiguous syntactical constructs. Such ones, which are 99.999% unlikely to collide with the language itself. As an example I can remember the ESQL/C I have used 12 years ago. Each SQL command started with $SQL, making it sure that C is not effected. Let me recap. A language binding (usually) should: - add pure library functionality (pure, I mean no language changes, like leaving out headers and still getting magic library functions) - adding new syntax, which "sticks" out of the language, without the slightest chance of collision - further restrictions in the original definitions, but not changing them (for example saying: int is always 32 bits) The "problem" with the C++/CLI binding is that it is more than a traditional language binding. And it has to be, it is just a fact. In fact I feel that Microsoft is actually pushing the C++ language a little bit, not being satisfied by the pace it embraced new ideas (such as virtual machines, or portable language environments and GC and so forth). I do not mean pushing as a bad word here. So the C++/CLI is actually *extending* the language. It does not "only" bind. It will be the first standard introduction of GC into the language... and many more things. The problem is not with these facts, the problem is that C++ itself has a (possibly last) language evolution step left and that full scale coordination is nearly impossible because of the very different pace of the ISO and the ECMA work. As I have said earlier I think it would be much "nicer" from ECMA/MS to introduce a cli (or some other) keyword/magic word (depeding what does the syntax allow) into the language and name its added constructs using that. I kinda like seeing "cli enum" much more than seeing "enum class" as a CLI dependent construct. I can see I use a CLI dependent feature there and it will surely not collide with C++ itself. And IMO it won't break code either - I believe it has less chance of breaking code than enum class has. And I also believe that it does not take a bit away from the "naturalness" of the cli features in the code. But about the hat (^) symbol I am worried. It seems to be a demanding (if not impossible) task to define it on a way that its semantics will allow the use of the same symbol for a possible new language feature of C++. I think it is indeed a good candidate for some sort of new reference like type, with possible automagically generated factory functions... but that leads far. I honestly would be very happy and willing to participate in the work of this ECMA committee. But do not worry. My employer will not sponsor this and I will never have that kinda money so you are all safe. But I do think there will be revolutionary work done there and I do think that the committee will have an enormous repsonsibility in regards of the future of the C++ language. A nice and challenging task. So let me ask you all involved in ECMA to please please consider what I wrote and do not only concenrate on not breaking existing code, but also on not to break/coerce/hijack the future direction/evolution the ISO C++ langauge could take. -- WW aka Attila [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next Page 1 of 9   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.