C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  CLI draft Goto page 1, 2, 3, 4, 5, 6  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Gerhard Menzl Guest Posted: Wed Sep 29, 2004 9:42 am    Post subject: CLI draft disconcerted by concentration on superficial aspects such as __gcnew vs gcnew real problem: CLI is modelled after Java paradigm, which is mimicked by C# (garbage collection, removal of deterministic destruction in the mistaken belief that memory is the only resource, domination of inheritance for reuse and huge, monolithic class hierarchies, emphasis on dynamic over static typechecking, lack of genericity) -> runs against established best C++ practices C++ is multiparadigm, but CLI forces C++ to bend towards this single paradigm which dilutes the strengths of C++ ..NET security: no verifiably type-safe code using C++ standard C++ things that do not work in .NET: - using declarations in managed types - member functions of managed types returning non-managed non-aggregates - member functions of managed types taking __value types derivation of ref classes without access specifier defaults to *public* in CLI nullptr/implicit boxing of 0 no overriding of a private virtual function - why this gratuitous restriction? containment of native types in reference types only by pointer -> forced manual deallocation! (no smart pointer possible) http://msdn.microsoft.com/visualc/default.aspx?pull=/library/en-us/dnvs05/html/TransGuide.asp "A virtual interface within a family of sub-types cannot practicably be a superset of all the possible methods of its many children, and so a downcast facility will always be needed within an object-oriented language." "If you see the additional language support as representing a shift in programming paradigm, you will extend the language." "Once it became clear that support for the Common Language Infrastructure within C++ represented a distinct programming paradigm, it followed that the language needed to be extended to provide both a first class coding experience for the user, and an elegant design integration with the ISO-C++ standard in order to respect the sensibility of the larger C++ community and engage their commitment and assistance." "The flagship feature of the CLI is the reference type" reworking of Dispose/destructor logic allows automatic resource cleanup for automatic objects, but class members would still have to be deleted [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Nicola Musatti Guest Posted: Thu Sep 30, 2004 10:38 am    Post subject: Re: CLI draft Gerhard Menzl <gerhard.menzl (AT) spambucket (DOT) net> wrote Quote: disconcerted by concentration on superficial aspects such as __gcnew vs gcnew real problem: CLI is modelled after Java paradigm, which is mimicked by C# (garbage collection, removal of deterministic destruction in the mistaken belief that memory is the only resource, domination of inheritance for reuse and huge, monolithic class hierarchies, emphasis on dynamic over static typechecking, lack of genericity) -> runs against established best C++ practices C++ is multiparadigm, but CLI forces C++ to bend towards this single paradigm which dilutes the strengths of C++ So? CLI is not an attractive environment to program to for competent C++ programmers. Microsoft made the same unfortunate choice made by Borland with Delphi/VCL and followed by Sun with Java. At least Sun has the justification that they designed what was meant to be and mostly is a single language environment. However the problem is, that's the way it is. I don't think the C++ community has any hope of subverting this state of things. What we can make sure of is that the distinction between C++ and CLI is kept evident and that C++ is allowed to evolve along its natural, platform independent nature. Cheers, Nicola Musatti [ 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: Fri Oct 01, 2004 11:47 am    Post subject: Re: CLI draft Thanks. Gerhard. I appreciate the interest and the time to look at the C++/CLI design. And, first of all, I do acknowledge there are things in it that we wish we'd found a better way to do. But I think the news is actually better than you fear on some of the points below, so let me try to provide some information about a few of them: On 29 Sep 2004 05:42:31 -0400, Gerhard Menzl <gerhard.menzl (AT) spambucket (DOT) net> wrote: Quote: disconcerted by concentration on superficial aspects such as __gcnew vs gcnew Actually, syntax matters. It was a major piece of (negative) customer feedback on the Managed Extensions, and it impacts semantics because a key goal is that, wherever possible, the same operation should have the same effect -- but also the same syntax -- across the type system. As a small example, consider what T* meant in the Managed Extensions. (Those who know will realize why that syntax mattered, and was a bad problem that desperately needed to be fixed because it really hurt programmers.) Quote: real problem: CLI is modelled after Java paradigm, which is mimicked by C# (garbage collection, removal of deterministic destruction in the mistaken belief that memory is the only resource, domination of inheritance for reuse and huge, monolithic class hierarchies, emphasis on dynamic over static typechecking, lack of genericity) -> runs against established best C++ practices C++ is multiparadigm, but CLI forces C++ to bend towards this single paradigm which dilutes the strengths of C++ I agree that would be bad, if it were true. Actually, an explicit (and achieved) design goal is to "bring C++ to CLI, and CLI to C++" -- adding dynamic programming as a new orthogonal programming style to the existing procedural, OO, and generic programming styles (and letting all of them be mixed freely, as are the existing ones). In particular, one of my two most fundamental design philosophies has always been that C++ features like templates and deterministic cleanup work across the type system also for CLI types, and that CLI features like properties and GC work (eventually) across the type system also for non-CLI types. In the subset of that goal that is implemented in this release, I think there's more of the former (C++ features applies to CLI types) than the latter, and CLI programmers are widely responding positively to being able to use the strengths of C++ also for CLI types (e.g., putting a CLI type on the stack and having C++ naturally automatically clean it up, instead of the Java Dispose pattern). (The other fundamental design philosophy was to make it a set of pure extensions that didn't change the meaning of any existing ISO C++ program. That has been largely achieved, even in the presence of macros. For example, C++/CLI allows "ref" as a contextual keyword in code like "ref class R { };", but "ref" can still be used as a variable or type -- or MACRO -- name without change of meaning in existing programs. I'm particularly happy that we were even able to dodge the preprocessor on that one. This was accomplished with much-appreciated help and input from folks like Bjarne and Tom Plum, and UK experts like Roger Orr. Quote: .NET security: no verifiably type-safe code using C++ Actually, the following complete program is fully verifiable: int main() { System::Console::WriteLine( "Hello, world" ); } It only gets better from there. Any verifiable program you can write in VB or C# (and then some) you can write in C++/CLI. However, it is true that many non-CLI parts of C++ cannot be made verifiable, including any use of native pointers (because of the nature of pointers, which can point to freed memory, be xor'd, etc.). All of native C++ can be seamlessly used in C++/CLI and seamlessly compiled to IL, but not all of it can be made verifiable. Quote: standard C++ things that do not work in .NET: - using declarations in managed types - member functions of managed types returning non-managed non-aggregates - member functions of managed types taking __value types derivation of ref classes without access specifier defaults to *public* in CLI We (the C++/CLI committee) are going to revisit that, only because it's controversial. The intent was simply that it is not possible to have anything but "public" there, so the choice is between requiring the programmer to always write an always-redundant "public," or to default it to the only possible value. Clearly, the former avoids imposing avoidable tedium on programmers. But if others don't like it and view it as a 'needless' variance from ISO C++, that matters too. I don't particularly care, one way or the other. The reason for the original choice was simply ease of use. I can go either way. Quote: nullptr/implicit boxing of 0 Is it nullptr or implicit boxing you don't care for? If nullptr, there are good reasons to not have 0 mean two things; see for example Bjarne's and my paper N1601 which proposes nullptr for ISO C++: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1601.pdf . If implicit boxing, here's the canonical motivating example: Console::WriteLine( "{0} + {1} = {2}", 5, 6, 11 ); Without implicit boxing, that would be (in the best case): Console::WriteLine( "{0} + {1} = {2}", gcnew int(5), gcnew int(6), gcnew int(11) ); Or, equivalently: Console::WriteLine( "{0} + {1} = {2}", gcnew Int32(5), gcnew Int32(6), gcnew Int32(11) ); In the Managed Extensions, you had to write: Console::WriteLine( "{0} + {1} = {2}", __box(5), __box(6), __box(11) ); If we didn't have implicit boxing, I think that would be a serious adoption-blocker. We got lots of clear (and negative) customer feedback about the above explicit __box requirement in the Managed Extensions. Quote: containment of native types in reference types only by pointer -> forced manual deallocation! (no smart pointer possible) You can indeed write a smart pointer for this, and it would just be a ref class rather than a native class. For example, I think you could cut-and-paste boost::shared_ptr's source and just add "ref" in front of "class shared_ptr." I haven't tried that specifically, but I would expect it to work with few or no changes. But you're right that we don't allow value containment of managed typs in native types (and vice versa) today. It's designed for, but it didn't fit into this release. After this release, we will definitely allow full mixed types, meaning that any type can have arbitrary bases and members. (Today, a CLI type can only have bases and members of CLI (or pointer) type, and a non-CLI type can only have bases and members of non-CLI (or gcroot) type.) Quote: reworking of Dispose/destructor logic allows automatic resource cleanup for automatic objects, Yes, this is a Big Feature. It's also a poster child of bringing C++ idioms to bear, with great benefit, on CLI programming. Quote: but class members would still have to be deleted Are you sure? This program works fine for me: using namespace System; ref class R { public: R() { Console::WriteLine( "R" ); } ~R() { Console::WriteLine( "~R" ); } }; ref class R2 { R r; public: R2() { Console::WriteLine( "R2" ); } ~R2() { Console::WriteLine( "~R2" ); } }; int main() { R2 r2; } Output: R R2 ~R2 ~R Thanks, 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) Architect, Developer Division, 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 Andreas Huber Guest Posted: Fri Oct 01, 2004 4:20 pm    Post subject: Re: CLI draft Nicola Musatti wrote: Quote: So? CLI is not an attractive environment to program to for competent C++ programmers. Why? Regards, -- Andreas Huber When replying by email, please remove the 8 UPPERCASE letters from the address shown in the header [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gerhard Menzl Guest Posted: Fri Oct 01, 2004 5:05 pm    Post subject: Re: CLI draft As you might have guessed, this posting was never intended for publication. It's a collection of notes that has escaped via a rogue click. My plea to the moderators to discard it seems to have come to late. Please ignore it. -- Gerhard Menzl Humans may reply by replacing the obviously faked part of my e-mail address with "kapsch". [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top White Wolf Guest Posted: Sun Oct 03, 2004 3:05 am    Post subject: Re: CLI draft Nicola Musatti wrote: [SNIP] Quote: So? CLI is not an attractive environment to program to for competent C++ programmers. Is that so? [SNIP] Quote: What we can make sure of is that the distinction between C++ and CLI is kept evident and that C++ is allowed to evolve along its natural, platform independent nature. In what way do you think C++/CLI is inherently platform dependent? I am not only refering to mono, but I would really like ot see some explicit mentioning of C++/CLI (language) features which will not and cannot be implemented outside of the CLI. I ask this, because I cannot recall any and I wonder what did I miss. -- WW aka Attila ::: The act of giving is more important than the merit of the receiver. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Nicola Musatti Guest Posted: Mon Oct 04, 2004 6:52 pm    Post subject: Re: CLI draft "White Wolf" <wolof (AT) freemail (DOT) hu> wrote Quote: Nicola Musatti wrote: [SNIP] So? CLI is not an attractive environment to program to for competent C++ programmers. Is that so? See my reply to Andreas. Quote: [SNIP] What we can make sure of is that the distinction between C++ and CLI is kept evident and that C++ is allowed to evolve along its natural, platform independent nature. In what way do you think C++/CLI is inherently platform dependent? I am not only refering to mono, but I would really like ot see some explicit mentioning of C++/CLI (language) features which will not and cannot be implemented outside of the CLI. I ask this, because I cannot recall any and I wonder what did I miss. Well, it is a binding to a specific platform, isn't it? The platform here is CLR, and not the underlying OS. All of the CLR features can obviously be implemented outside it, if only by cloning it. What remains to be seen is whether the CLR implementation is the only one possible or the best way to implement them in a platform independent language. Note that I'm not claiming that they made some mistake and forcing it on C++, nor that the C++ future is compromised by the mere existence of CLR or C++/CLI. I only say that care should be exercised in ensuring that C++/CLI features influence the evolution of C++ only if they really are sufficiently general. Cheers, Nicola Musatti [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Nicola Musatti Guest Posted: Mon Oct 04, 2004 6:56 pm    Post subject: Re: CLI draft "Andreas Huber" <ahd6974-SPAMlistsTRAP (AT) yahoo (DOT) com> wrote Quote: Nicola Musatti wrote: So? CLI is not an attractive environment to program to for competent C++ programmers. Why? I think the reply is inherent in Gerhard's observations. .NET was invented to support a style of programming different from the currently dominant best practices of the C++ community: He wrote: Quote: real problem: CLI is modelled after Java paradigm, which is mimicked by C# (garbage collection, removal of deterministic destruction in the mistaken belief that memory is the only resource, domination of inheritance for reuse and huge, monolithic class hierarchies, emphasis on dynamic over static typechecking, lack of genericity) -> runs against established best C++ practices I'm aware of the effort made into making it possible to mix C++ specific paradigms with the .NET one and I consider it a very good thing. I'm still afraid though that programming in C++ for/with .NET will remain a rather clumsy exercise, even if much improved over the first attempt. Cheers, Nicola Musatti [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Andreas Huber Guest Posted: Tue Oct 05, 2004 10:37 pm    Post subject: Re: CLI draft Nicola Musatti wrote: Quote: "Andreas Huber" <ahd6974-SPAMlistsTRAP (AT) yahoo (DOT) com> wrote in message news:<415c65a8$1_1 (AT) news (DOT) bluewin.ch>... Nicola Musatti wrote: So? CLI is not an attractive environment to program to for competent C++ programmers. Why? I think the reply is inherent in Gerhard's observations. .NET was invented to support a style of programming different from the currently dominant best practices of the C++ community: You seem to be implying that a change in programming style / best practices is necessarily a bad thing? This has happened in C++ several times (introduction of exceptions and later templates) and I definitely like the end result. Quote: I'm aware of the effort made into making it possible to mix C++ specific paradigms with the .NET one and I consider it a very good thing. I'm still afraid though that programming in C++ for/with .NET will remain a rather clumsy exercise, even if much improved over the first attempt. That may well be, only time and experience will tell. However, I think your original statement is far fetched. For a certain class of problems a GC environment is clearly superior (ease of memory management, performance, etc.). Therefore, I don't see why a competent C++ programmer would/should ignore these advantages? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gerhard Menzl Guest Posted: Tue Oct 05, 2004 10:41 pm    Post subject: Re: CLI draft This is going to be among the most prominent episodes of my upcoming title "Most Embarrassing Moments on Usenet". When I started using Managed C++ about a year ago and following the discussions concerning C++/CLI here, I began taking notes that should eventually result in a well-conceived, coherent newsgroup article that even Herb Sutter might feel inclined to respond to. Lazy as I am, I simply clicked on Reply To Newsgroup and abused the Drafts folder of my newsreader for the note keeping. Then, one fateful morning, after reading Stan Lippman's Translation Guide and adding a few more notes, my mouse pointer went a few inches astray, and before I could think "Abort", the jumbled, completely unedited mass was released unto the public, wheat and chaff and all. That will teach me to keep loaded weapons lying around! Needless to say, the rogue posting was approved in what appears to be record time, and my e-mailed plea to the moderators to reject the thing came too late. On the other hand, my please-ignore-this-follow-up spent enough time in the moderation queue to make people take this serious and respond, among them Herb Sutter. Holy Murphy! Now that the worms have escaped from the can, I can only apologize for the time this has cost you needlessly, and try to make the points I would rather have saved for a later date now. Herb Sutter wrote: Quote: Actually, syntax matters. It was a major piece of (negative) customer feedback on the Managed Extensions, and it impacts semantics because a key goal is that, wherever possible, the same operation should have the same effect -- but also the same syntax -- across the type system. I neither am one to underestimate the importance of syntax, nor do I have a particular liking for underscores, let alone leading double ones. On the contrary, I have the greatest admiration for your efforts to clean up that syntactic mess. Being a terminology buff, I just love the term "handle", and I find the choice of the hat symbol very elegant. It's just that I found it surprising how vigorously the advantages of property over __property or ref over __gc were being discussed in this community of advanced C++ users while no-one (at least while I was paying attention) seemed to mind the end of const-correctness (to my knowledge, the constraint that member functions of managed types cannot be qualified const or volatile has not been lifted in CLI, but I would be happy to stand corrected). In more general terms, I feel that the paradigmatic impact of CLI on C++ is underestimated, and the syntactic aspect overrated in comparison. Quote: I agree that would be bad, if it were true. Actually, an explicit (and achieved) design goal is to "bring C++ to CLI, and CLI to C++" -- adding dynamic programming as a new orthogonal programming style to the existing procedural, OO, and generic programming styles (and letting all of them be mixed freely, as are the existing ones). I agree that would be good, if it were true. <g> Why do I think it isn't? First, there are principless and best practices in C++ that are not restricted to a certain paradigm. Const correctness, which I have already mentioned, is one, and emphasis on static typing is another one. A paradigm that does away with the former and discourages the latter does not seem to be yet another design option to me; it rather transforms the language into something that suspiciously smells of coffee. Second, I have tried to mix freely (admittedly using the somewhat fledgling incarnation called Managed C++), and I'm afraid to say it just doesn't work, especially when using a CLI-based framework. From what I have seen of CLI/C++, you have managed to weed out several gross incompatibilities (such as the impossibility of using RAII), but my feeling (and not having touched an actual implementation yet it cannot be more than that) is that what constraints remain will silently impose the CLI paradigm on the entire program. Wrapping entire native layers may work, but free mixing? I don't think so. Quote: In particular, one of my two most fundamental design philosophies has always been that C++ features like templates and deterministic cleanup work across the type system also for CLI types, and that CLI features like properties and GC work (eventually) across the type system also for non-CLI types. In the subset of that goal that is implemented in this release, I think there's more of the former (C++ features applies to CLI types) than the latter, and CLI programmers are widely responding positively to being able to use the strengths of C++ also for CLI types (e.g., putting a CLI type on the stack and having C++ naturally automatically clean it up, instead of the Java Dispose pattern). Again, kudos to you and all good people involved with this Herculean task. It is a relief to learn that something like ref class ScopeGuard { public: ScopeGuard () { /* acquire */ } ~ScopeGuard () { /* release */ } }; void MyRefClass::f () { Scopeguard guard; // ... } will be possible. But the power of RAII as we know it is not restricted to the stack. In Standard C++, we can extend the scope of a guard object to span the entire lifetime of the containing object like this: class C { //... private: SuitableSmartPointerThatCanHandleIncompleteTypes<CImpl> pImpl; }; To make this work in CLI/C++, you would have to be able to make CLI class types contain CLI or native class types by value. Will you? To my knowledge, you won't, but again I would be happy to be told I'm wrong. In case I am right, however, we are left with a watered down version of RAII at best. Has this been discussed? Are there idioms that make up for the deficit? Oh, wait a moment ... Quote: You can indeed write a smart pointer for this, and it would just be a ref class rather than a native class. For example, I think you could cut-and-paste boost::shared_ptr's source and just add "ref" in front of "class shared_ptr." I haven't tried that specifically, but I would expect it to work with few or no changes. So ref class types will be able to contain objects of ref class type? It doesn't say so in Stan's Guide. Still, I doubt that simply adding ref to native RAII classes will do the trick. What about const or volatile member functions? What about other native types contained by value? Quote: .NET security: no verifiably type-safe code using C++ nullptr/implicit boxing of 0 I am afraid those were just isolated notes. Sorry for the time it took you to adress them. -- Gerhard Menzl Humans may reply by replacing the obviously faked part of my e-mail address with "kapsch". [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ioannis Vranos Guest Posted: Wed Oct 06, 2004 1:26 pm    Post subject: Re: CLI draft Gerhard Menzl wrote: Quote: I neither am one to underestimate the importance of syntax, nor do I have a particular liking for underscores, let alone leading double ones. On the contrary, I have the greatest admiration for your efforts to clean up that syntactic mess. Being a terminology buff, I just love the term "handle", and I find the choice of the hat symbol very elegant. It's just that I found it surprising how vigorously the advantages of property over __property or ref over __gc were being discussed in this community of advanced C++ users while no-one (at least while I was paying attention) seemed to mind the end of const-correctness (to my knowledge, the constraint that member functions of managed types cannot be qualified const or volatile has not been lifted in CLI, but I would be happy to stand corrected). In more general terms, I feel that the paradigmatic impact of CLI on C++ is underestimated, and the syntactic aspect overrated in comparison. Yes, member functions of CLI (and .NET) can not be const, but it has to do with the CLI VM and not the language support. That is, all CLI languages C# etc cannot support const member functions. On the other hand, in ISO C++ code you can use const, including non-ref template classes getting managed types: ref class Managed {}; template <class T> class test { public: void some() const {} }; int main() { test<Managed> obj; } C:c>cl /clr temp.cpp Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40904 for Microsoft (R) .NET Framework version 2.00.40607.16 Copyright (C) Microsoft Corporation. All rights reserved. temp.cpp Microsoft (R) Incremental Linker Version 8.00.40904 Copyright (C) Microsoft Corporation. All rights reserved. /out:temp.exe temp.obj C:c> Quote: Second, I have tried to mix freely (admittedly using the somewhat fledgling incarnation called Managed C++), and I'm afraid to say it just doesn't work, especially when using a CLI-based framework. From what I have seen of CLI/C++, you have managed to weed out several gross incompatibilities (such as the impossibility of using RAII), but my feeling (and not having touched an actual implementation yet it cannot be more than that) is that what constraints remain will silently impose the CLI paradigm on the entire program. Wrapping entire native layers may work, but free mixing? I don't think so. Well, you can view it in another way. CLI-specific code and ISO C++ code remain separated and source portability to non CLI environments gets improved. Of course this is my personal view with which you may disagree. The way that I view this, is that you write the main engine of your program in ISO C++ and use C++/CLI for the system specific stuff. C++/CLI also gives you a second hand of portability to other CLI engines. CLI VM does not support many features of C++ like const member functions, and C++/CLI gives support (guarantees) for all C++ abilities possible for CLI types, under those restrictions. That is, it is a real life trade off. And still you can use all ISO C++ features in ISO C++ code under a CLI VM. Quote: class C { //... private: SuitableSmartPointerThatCanHandleIncompleteTypes<CImpl> pImpl; }; To make this work in CLI/C++, you would have to be able to make CLI class types contain CLI or native class types by value. Will you? To my knowledge, you won't, but again I would be happy to be told I'm wrong. I don't understand what you mean with the above, however you can use template classes with both managed and unmanaged types, providing the needed template class specialisations. -- Ioannis Vranos http://www23.brinkster.com/noicys [ 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 06, 2004 10:32 pm    Post subject: Re: CLI draft Just a couple of comments from someone who has been using "old" Managed C++ as well. Quote: I neither am one to underestimate the importance of syntax, nor do I have a particular liking for underscores, let alone leading double ones. On the contrary, I have the greatest admiration for your efforts to clean up that syntactic mess. "Cleaning up the syntatic mess" would have been nice before Managed C++ was released. Now, it means breaking people's code and learning a new syntax all over again. Frankly, I believe the customers who complained about "ugly syntax" were just giving excuses to switch to C#. Really, how many people use C++ (in general, not only Managed) because of its pretty syntax? I don't think even Dr Stroustrup thinks C++ has "pretty" syntax :) Quote: Second, I have tried to mix freely (admittedly using the somewhat fledgling incarnation called Managed C++), and I'm afraid to say it just doesn't work, especially when using a CLI-based framework. True, but why would you want to do that in the first place? I use MC++ for two things: 1) To make managed interfaces for my C++ components, so they can be used from other .NET languages. 2) (Rarely, but still happens) To wrap a .NET component in a C++ class that can be used in "regular" C++ code. I don't see much value in mixing "Kansas and Oz" (Stan Lippman's metaphore). Making them working together nicely is already a great achievement. Quote: impossibility of using RAII RAII is actually very easy to use with "old" Managed C++, by wrapping __gc classes into __nogc classes. It comes with some performanse penalties, though. [ 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: Wed Oct 06, 2004 11:37 pm    Post subject: Re: CLI draft On 5 Oct 2004 18:41:14 -0400, Gerhard Menzl <gerhard.menzl (AT) spambucket (DOT) net> wrote: Quote: This is going to be among the most prominent episodes of my upcoming title "Most Embarrassing Moments on Usenet". No worries. We've all been there. FWIW, I do the same thing with my email Drafts folder, and after several embarrassing experiences I now have an Outlook rule that delays sent mail for one minute. That lets me recover from premature sends, at least in email. Quote: Herb Sutter wrote: Actually, syntax matters. It was a major piece of (negative) customer feedback on the Managed Extensions, and it impacts semantics because a key goal is that, wherever possible, the same operation should have the same effect -- but also the same syntax -- across the type system. I neither am one to underestimate the importance of syntax, nor do I have a particular liking for underscores, let alone leading double ones. On the contrary, I have the greatest admiration for your efforts to clean up that syntactic mess. Being a terminology buff, I just love the term "handle", and I find the choice of the hat symbol very elegant. It's just that I found it surprising how vigorously the advantages of property over __property or ref over __gc were being discussed in this community of advanced C++ users while no-one (at least while I was paying attention) seemed to mind the end of const-correctness (to my knowledge, the constraint that member functions of managed types cannot be qualified const or volatile has not been lifted in CLI, but I would be happy to stand corrected). True, and in a nutshell this is largely because the CLR doesn't support const, and the Base Class Library (BCL) and all the .NET libraries don't know about const and so don't have const member functions. That means that, for example, having a const R^ where R is a BCL or FX type means you can't use it without casting away const every time. Our Whidbey goal is for C++ to be the systems programming language for ...NET (CLI), exposing the CLI naturally and more fully than any other language. (See my blog entry yesterday at http://www.pluralsight.com/blogs/hsutter/.) This was a major driver of our choice of features to implement in this release. Given that we only had time to implement most, but not all, of our language extensions design in this single release (e.g., we also have a design for, but deferred the implementation of, "mixed types" which means the ability for any managed/native type to inherit from, or embed a member variable of, any other managed/native type), we focused on a coherent set of features that made C++ the language that best exposed the CLI's features (e.g., we support more of CLI generics than VB or C#), and applied selected key C++ language-level features (like deterministic destructors) that best leveraged C++'s strengths also to managed types. However, as with mixed types, we have deliberately left the door open to adding full const in a future release. I personally feel that this will be yet another benefit of using C++ on CLI. Quote: In more general terms, I feel that the paradigmatic impact of CLI on C++ is underestimated, and the syntactic aspect overrated in comparison. Agreed. Both are important and were given attention, but people tend to debate more about syntax because it's more visible. Still, I don't think the paradigmatic impact is as bad as you probably fear, and integrating dynamic programming as another orthogonal paradigm went even better than I had hoped we would be able to achieve. This is certainly due to much input from inside and outside Microsoft, and particularly I always need to acknowledge indebtedness to Bjarne's, EDG's, Dinkumware's, and Plum Hall's input in particular. Bjarne especially always made himself available for me to fly down to Texas to spend a day as needed working out the pointer and storage model, and that is both most appreciated and has made a real difference in the quality of the result; the integration would not have ended up being as smooth as it is without that. Steve Adamczyk, president of EDG and the world's overload resolution guru, made a real difference (and continues to do so right now in TG5) making sure the integration with overload resolution and conversions is right. Daveed, John, ... I could go on for a long time. Having said that, everyone recognizes that C++/CLI features often aren't what you would have designed in a vacuum to extend C++ in these areas. Many of the parts are great, and many are tweaked because of the constraint that we're binding specifically to CLI. It's the same as when Bjarne created C++ in the first place and constrainted himself to C compatibility; it wouldn't have been the same language, and many parts would have been much smoother (e.g., declaration syntax), if he had not decided to be nearly fully C-compatible. But then we would have had a smoother language with few users. Quote: I agree that would be bad, if it were true. Actually, an explicit (and achieved) design goal is to "bring C++ to CLI, and CLI to C++" -- adding dynamic programming as a new orthogonal programming style to the existing procedural, OO, and generic programming styles (and letting all of them be mixed freely, as are the existing ones). I agree that would be good, if it were true. <g> Why do I think it isn't? First, there are principless and best practices in C++ that are not restricted to a certain paradigm. Const correctness, which I have already mentioned, is one, and emphasis on static typing is another one. A paradigm that does away with the former and discourages the latter does not seem to be yet another design option to me; it rather transforms the language into something that suspiciously smells of coffee. Don't forget other C++ features that were specifically injected into managed types and can be authored best (or only) in C++: Deterministric destructors, copy constructors, and copy assignment operators come to mind. And, as noted above, we do intend to add const. As for static typing, you still get that, and C++ already has both static typing and RTTI. Can you explain what you want to do that you can't do? You also get static polymorphism, and only with C++ -- you can have templates of CLI type, such as template<typename T> ref class G { }; and instantiate templates with CLI types, such as ref class R { /*...*/ }; cli::vector<R> v; v.push_back( R() ); (Of course, CLI types not authored in C++ won't have copy constructors. Quote: Second, I have tried to mix freely (admittedly using the somewhat fledgling incarnation called Managed C++), and I'm afraid to say it just doesn't work, especially when using a CLI-based framework. Absolutely. MC++ is broken in various respects, and experience with it is not an indicator. Quote: From what I have seen of CLI/C++, you have managed to weed out several gross incompatibilities (such as the impossibility of using RAII), but my feeling (and not having touched an actual implementation yet it cannot be more than that) is that what constraints remain will silently impose the CLI paradigm on the entire program. Wrapping entire native layers may work, but free mixing? I don't think so. You can get the beta compiler and try it out (but also get the refresh): http://blogs.msdn.com/hsutter/archive/2004/09/04/225736.aspx has the links. Quote: But the power of RAII as we know it is not restricted to the stack. In Standard C++, we can extend the scope of a guard object to span the entire lifetime of the containing object like this: class C { //... private: SuitableSmartPointerThatCanHandleIncompleteTypes<CImpl> pImpl; }; To make this work in CLI/C++, you would have to be able to make CLI class types contain CLI or native class types by value. Will you? Yes, that works today for managed types embedded in other managed types: ref class R { public: ~R() {/*...*/} }; ref class R2 { R r; }; The compiler generates ~R2() which automatically links to ~R() as usual. As you point out, as with the stack-based part of deterministic destruction, this is a Big Deal. We generally don't know how good destructors are till we go to a language that doesn't have them, and then we start to miss them very quickly. After this release, we'll do mixed types so that you will also be able to write: ref class R3 { NativeType n; // not supported in VC 2005, but will be in the future // for now, hold it by NativeType*, or Pimpl out all the private // members in one swoop using a ref class smart pointer }; Thanks for the interest! Herb --- Herb Sutter (www.gotw.ca) (www.pluralsight.com/blogs/hsutter) Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso) Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj) Architect, Developer Division, 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 Gerhard Menzl Guest Posted: Fri Oct 08, 2004 12:43 am    Post subject: Re: CLI draft Nemanja Trifunovic wrote: Quote: Second, I have tried to mix freely (admittedly using the somewhat fledgling incarnation called Managed C++), and I'm afraid to say it just doesn't work, especially when using a CLI-based framework. True, but why would you want to do that in the first place? Because I abhor downcasting every time I retrieve something from a container? Because I think that reliable resource management requires deterministic destruction? Because I am a sentimental, old fool? Quote: I don't see much value in mixing "Kansas and Oz" (Stan Lippman's metaphore). Making them working together nicely is already a great achievement. It would be a shame if Oz would increasingly resemble Kansas. Quote: RAII is actually very easy to use with "old" Managed C++, by wrapping __gc classes into __nogc classes. It comes with some performanse penalties, though. This approach also reaches its limits very quickly as soon as inheritance comes into play. -- Gerhard Menzl Humans may reply by replacing the obviously faked part of my e-mail address with "kapsch". [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gerhard Menzl Guest Posted: Fri Oct 08, 2004 12:45 am    Post subject: Re: CLI draft Ioannis Vranos wrote: Quote: Yes, member functions of CLI (and .NET) can not be const, but it has to do with the CLI VM and not the language support. That is, all CLI languages C# etc cannot support const member functions. I am well aware that this restriction is attributable to the deficiencies in other CLI languages, but that does not stop me from worrying about the impact this is going to have on Standard C++ in the long run. Quote: On the other hand, in ISO C++ code you can use const, including non-ref template classes getting managed types: Of course you can. Do you think many people will systematically gcroot<> and wrap every managed type in this way in order to maintain const correctness? I don't think so. I know that I don't because I have to get my work done. Quote: Well, you can view it in another way. CLI-specific code and ISO C++ code remain separated and source portability to non CLI environments gets improved. Of course this is my personal view with which you may disagree. The way that I view this, is that you write the main engine of your program in ISO C++ and use C++/CLI for the system specific stuff. C++/CLI also gives you a second hand of portability to other CLI engines. Providing the "main engine" does not need any system specific stuff, which is, to put it mildly, unrealistic. In practice, you need all kinds of system services at lower levels. Theoretically, you can ban all CLI stuff down there and resort to conventional APIs, but the resulting conversion hassle will quickly make you think twice. Another problem is callbacks from model to view/controller classes. You can't use events because that would require the model classes to be managed, too. Ordinary abstract base class interfaces are out because managed classes cannot inherit from them, and to store a pointer to a managed interface, you need a gcroot<> ... In my experience, mixing managed and unmanaged C++ makes you work against the language, and that's an uphill battle. CLI/C++ will certainly alleviate this, but I have my doubts as to whether the remaining hurdles will be insignificant enough to make true mixing workable. Quote: And still you can use all ISO C++ features in ISO C++ code under a CLI VM. Why should I bother with the CLI VM as long as I stay within the realm of Standard C++? On the other hand, as soon as I target CLI, CLI issues will leak into my code. Quote: class C { //... private: SuitableSmartPointerThatCanHandleIncompleteTypes<CImpl> pImpl; }; To make this work in CLI/C++, you would have to be able to make CLI class types contain CLI or native class types by value. Will you? To my knowledge, you won't, but again I would be happy to be told I'm wrong. I don't understand what you mean with the above, however you can use template classes with both managed and unmanaged types, providing the needed template class specialisations. I mean that the above will not compile any more if you change the first line to __gc class C In order to compile with ref class C pImpl would have to be a managed type, but class template instantiations are not managed. Are CLI generics going to fill this gap? How would you solve the problem? Note that the example doesn't have to involve pimples; it's about deterministic destruction of contained objects in general. -- Gerhard Menzl Humans may reply by replacing the obviously faked part of my e-mail address with "kapsch". [ 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  Next Page 1 of 6   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.