C++/CLI limitations?
in [C++]
|
Prev: Exceptions
Next: C++ Concepts
From: Ismail Pazarbasi on 18 Sep 2005 08:04 I am sorry, I do not know what part of the message you took as "bashing", I was not offending you, at least it was not my intention. I apologize, if I sound I was attacking. I just thought that the first paragraph of your reply is not correct. I also did not take your post as bashing on Microsoft. Of course, MC++ is different, type system is different, run-time has its very own specs, we don't have everything we can do in C++ in C++/CLI today... It's all told that way, too; these are pure extensions to ISO C++. Ismail [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Malte Clasen on 18 Sep 2005 08:00 David F wrote: > You have to be aware that C++/CLI, like "Managed C++", like the mere > creation of C#, etc., are all part of MS grand scheme/scam to devoid the > usage of pure ISO C++, and like any other international standard language > such as HTML [...] So that's why they're working with Borland, EDG, IBM etc. to make it an ECMA standard? http://www.ecma-international.org/news/ecma-TG5-PR.htm http://msdn.microsoft.com/visualc/homepageheadlines/ecma/default.aspx > What they want is that > when you write an application for Windows, it will run ONLY on Windows, [...] Bad luck. Mono already runs CLI programs and GCC seems just one step away from compiling C++ to CLI code: http://www.mono-project.com/CPlusPlus Malte [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David F on 18 Sep 2005 08:10 "Allan W" <allan_w(a)my-dejanews.com> wrote in message news:1126908080.729666.41600(a)g49g2000cwa.googlegroups.com... > I wrote: >>> You are using "managed types" in C++. Managed types are .NET >>> extensions to the language. They give you several features in >>> return for losing a few points of compatibility with Standard C++. > > Ismail Pazarbasi wrote: >> It's not because of compatibility, but its because the object can be >> "anywhere". Objects in GC heap can move around by GC, during >> compacting. Pointers, on the other hand, show one location that doesn't >> change. > [and about 46 more lines defending Microsoft's practices, ending with] >> You can ask here, I guess, if you have questions. There is a Visual C++ >> forum as well, again, somewhere in Microsoft's web site. > I think that you and Ismail are both right. Ismail is technically right, GC makes that pointer-to-member impossible like it makes many other ISO C++ standard impossible. You are right because the whole thing called GC being imposed on a programmer is one big compatibility flap. Computer science theory proved already decades ago that altogether, GC is more of a liability than an asset and I never heard that there were new theortical revelations here. If there were, I thank in advance for pointing me to such news. Besides, there are many GC packages available in the market for C++ for those who OPT for it, and w/o forcing one to use it and worse, modifying the language as MS did. > Ismail: not sure which part of my essay made you feel that I was > attacking Microsoft. In fact, I'm using .Net more and more myself... > > Microsoft is not above criticism, but somehow they tend to get FAR > more "bashing" than they deserve... if you use Google to check my > posts over the past 10 years, you'll find that I have often > criticized mindless "bashing," and only occasionally have I made > any direct criticisms. > > This message wasn't either one of those. All I said was that > "Managed C++" is different than "Standard C++." Now I'll add that > each has an advantage, and I applaud Microsoft for giving us this > choice rather than trying to force us all into one mold (as they > have sometimes tried in the distant past). "...giving us this choice..."?! I would more than appreciate if you show me how can I write in ISO C++ for Windows, especially using more modern tools such as VS .NET or even VC with MFC only. Maybe, and its a big maybe, if I go and dig deep into the thousands of most primitive components of Windows' API, for which "human" documentation does not exist, maybe then I could write in standard C++ but it is almost a safe bet to say that even then I could not. Bear in mind that even BOOL, INT, INT32 are NOT standard C++. Moreover and as example, if you open VS 2005, even if configured for so called "C++", and you click File->New->Web Site you get the New Web Site dialoge window. In that window, there is a selection box called Language. Try to select a language. The ONLY languages available are MS proprietary VB,C# and J#. C++ is not even listed. That is, in this case, they don't even hide behind misleading terms such as "Managed C++" - they simply say with bold face - C++? not in our backyard !. "...giving us this choice..."? - Could there be more pollyannaish? But again, I would be extremely happy if you prove me wrong by telling how can I choose ISO C++ to write an application for Windows. I think this has nothing to do with bashing but with the ability to face thing as they are. Just to make it clear, I am happy to use several MS products. When they came out with Word 2.0, I dumpped Word Perfect in no time. Even though VS IDE contains an important piece, Windows Forms, that was stolen from Borland's IDE (what good ORIGINAL work came out of MS?), and generally I prefer originals over immitations, I did find MS' IDE easier to learn and use over Borland's so I clearly prefer VS IDE. Overall, I found that MS has a much better understanding of the importance of consistency of applications than many of their competitors. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Lars on 18 Sep 2005 10:47 David F schrieb: > I went through similar paths. So instead to specifically address what you > brought up, I will provide you with a "general purpose solution" that can > address many problems of the like. > > If you want to use C++ templates, which I believe to be the most important > contribution of C++ (and in MHO way more superior to inheritance), At this point I strongly agree with you. [snip] > So I hope that will save your time by saying that if you want to use C/C++ > standards for ANY purpose more significant than the program: > main(){printf("\nHello World!";} > you simply have to FORGET from all those C++/CLI or any other of those MS > "inventions" in these areas. > And better even, don't even think about them. Hm, I must say that I am a bit sad about this point. You are right, when you say that you don't "...specifically address..." what I brought up. For how I understood C++/CLI, it addresses a completely different programming model which brings advantages like reflection to C++. I'd be very thankful for pointing me to other packages that can do this. I wanted to express that I would have liked to use known syntactic constructs (like pointer-to-member) in this new environment. In the first place, the intend of this question was not to start a MS-vs-non-MS-style discussion, but to find out if there are alternatives with regard to using p-t-m constructs - maybe I should have pointed this out more clearly. Not using a technology is IMHO not a "general purpose solution" for dealing with issues regarding it. regards Lars [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Lars on 18 Sep 2005 13:45
Ismail Pazarbasi schrieb: > > You are using "managed types" in C++. Managed types are .NET > > extensions to the language. They give you several features in > > return for losing a few points of compatibility with Standard C++. > > > > It's not because of compatibility, but its because the object can be > "anywhere". Objects in GC heap can move around by GC, during > compacting. Pointers, on the other hand, show one location that doesn't > change. A very frequently used example; you can write them to disk, > read them back, they are still valid (if app is still running). On the > other hand, you cannot use pointer (*) on a ref (managed) class, you > need to have a handle (^) for GC handles (i.e. GC pointers). The difference between managed and unmanaged types is something I understood, so not being able to use a pointer to an object of a reference class (or managed class) is something I understood, too. But: In my example I used a typedef which has nothing to do with an object allocated on a managed or unmanaged heap. And as far as I am concerned a pointer-to-member differs from a pointer to such an allocated object. I _could_ understand that _calling_ e.g. a member function pointer on a managed object wouldn't work the way it does in ISO C++ (for instance by specifying a tracking reference to that object). What I don't understand is that I am not able to use a pointer-to-member in a typedef. > You can't have a function pointer, in C function pointer semantics, in > your C++/CLI code. C++ standard is not necessaily valid for CLR type > system. You can, however, use delegates rather than function pointers: > > delegate void bla(int); > > ref class T > { > public: > viod AnotherBla(int); > }; > > // somewhere in your code: > > T t; > bla^ hBla = gcnew bla(%t, &T::AnotherBla); > hBla(5); > > It's not a pity. Visual C++ team is still working on this project and > you will take anything from ISO C++ list and apply it in CLR list. This > is why Herb uses "C++ x CLI" cartesian product ;) But those are > post-Whidbey things. Today, we can perform 2/3 of this cartesian > product. You can still use those handles and delegates with templates! This is interesting and I will definitely give it a try. > What's the problem? My problem is, that I wanted to write a class template which does some constraint checking the way it's suggested in Herb Sutter's "More Exceptional C++". And for that I declared a pointer to a member function of the template type argument. I didn't want to call it. For example: template<typename ImplBase> public ref class LogFormat : ImplBase { public: virtual ~LogFormat(void) { void (LogFormat::*pConstraintCheck)(void) = checkConstraints; pConstraintCheck; } private: // declaration of p-t-m type - no call typedef String^ (ImplBase::*FormatMethodType)(LogLevel^, String^, String^); void checkConstraints( void ) { FormatMethodType pRequiredFormater = ImplBase::format; pRequiredFormater; } }; As you can see, the intend is to specify a ref class as template argument which I could have made a bit clearer by also using the __is_ref_class type trait with the argument ImplBase. Otherwise the code wouldn't worked anyway because of the derivation. As an alternative I also could have used a generic that places some constraints on it's arguments but that's not what I wanted because I want to use a compile time mechanism - which invalidates generics as an option. In addition I don't want to introduce a new type (for example an interface class) that the generic argument is required to be derived from. This would have "complicated" the class hierarchy and it would have introduced a new semantic and a new variation point in the class hierarchy. Now is there a possibility to deal with these requirements right now? regards Lars [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |