C++/CLI limitations?
in [C++]
|
Prev: Exceptions
Next: C++ Concepts
From: Lars on 15 Sep 2005 18:57 Hi, I am currently sinking my teeth into the C++/CLI stuff since I just want to know a bit more about it. Now, during some playing around I found out that using pointer-to-member types together with reference classes are not possible, e.g. I tried: public ref class Foo { public: void bla( int blubb ); // ... }; typedef void ( Foo::*FooMemberPtr )( int ); Then the compiler (VC++2005 Beta 2) reported: "cannot take the address of a non-static data member or method of a managed type" This is a pity, since using pointer-to-member e.g. in conjunction with templates (which I want to play around next with ;) could be very helpful. Is there a workaroung/replacement for that? Will this be added in future versions of the C++/CLI standard? Another point is that the const keyword has been rendered obsolete if somebody wishes that the code written in C++ is to be usable from other CLI languages - which is something I can understand. But another question I'd like to ask is if there is some kind of document where I can read about such issues. thanks in advance Lars [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Allan W on 16 Sep 2005 04:18 Lars wrote: > using pointer-to-member types together with reference > classes are not possible, e.g. I tried: > > public ref class Foo > { > public: > void bla( int blubb ); > // ... > }; > > typedef void ( Foo::*FooMemberPtr )( int ); > > Then the compiler (VC++2005 Beta 2) reported: > "cannot take the address of a non-static data member or method of a > managed type" 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++. Try creating a project of type "Win32 Console project" instead, and then try it again without the keyword "ref". [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Ismail Pazarbasi on 16 Sep 2005 09:24 > 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). 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! What's the problem? But you cannot play with handles the way you can play with pointers. You can't cast it to integral types, there is no "void^"... Forget that managed things have addresses; you are not going to use those addresses. Creating a "Win32 Console project" without /clr switch does nothing; it doesn't compile "ref class". Having /clr keyword is 98% equivalent of File->New->project->CLR console application. There is a C++/CLI specs documentation (a draft version of it) somewhere in Microsoft's site. Try to check http://msdn.microsoft.com/visualc you can see it somewhere in there. 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. Ismail [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Allan W on 17 Sep 2005 09:58 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. 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). [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David F on 17 Sep 2005 09:55
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), pointer-to-member is sometimes a requirement which I am not aware of an alternative. By no alternative I mean don't use templates or there is no other practical and/or elegant solution. I say "...practical and/or elegant..." etc. since the mathematician Alan Turing proved already 60 or 70 years ago that all boolean machines are equivalent (in the sense that with a proper sequencing, they can produce the same output given the same input). That includes of course computer programs writen in any language. 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 (although this one was too big even for MS to completely fend off as far as they are successfuly marching with regard to C/C++). In the heart of C & C++ there is the portability. And portability is for a bully like MS like waving a red flag in front of a bull. What they want is that when you write an application for Windows, it will run ONLY on Windows, and you could not simply take your source code without changing a line (well, I will give you a "discount" - allowing to change one/two #pragma lines in a million lines of a program), "crossing the street" to a UNIX machine (or any other machine for that matter), push the compile button and create the equivalent object code for anther OS. Only if you could do that it means that an OS supports an ISO C/C++ (or other standard languages). 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. David Actually, I should take back that exception I made for the above program... because VS2005 will try to steer you to printf_s() although in this case printf_s() is a bit not safer than printf(). And not only that, if you have many printf() in your program, it will be very annoying to see that the stupid compiler will repeat that lengthy warning as many times (instead only once for the first encounter and maybe one/two more line(s) that contain just the line #s for all the rest encounters), craming the results reporting subwindows which is small enough to begin with. "Lars" <califax(a)uni.de> wrote in message news:1126815930.029795.163610(a)f14g2000cwb.googlegroups.com... > Hi, > > I am currently sinking my teeth into the C++/CLI stuff since I just > want to know a bit more about it. Now, during some playing around I > found out that using pointer-to-member types together with reference > classes are not possible, e.g. I tried: > > public ref class Foo > { > public: > > void bla( int blubb ); > > // ... > }; > > typedef void ( Foo::*FooMemberPtr )( int ); > > Then the compiler (VC++2005 Beta 2) reported: > "cannot take the address of a non-static data member or method of a > managed type" > > This is a pity, since using pointer-to-member e.g. in conjunction with > templates (which I want to play around next with ;) could be very > helpful. Is there a workaroung/replacement for that? Will this be added > in future versions of the C++/CLI standard? > > Another point is that the const keyword has been rendered obsolete if > somebody wishes that the code written in C++ is to be usable from other > CLI languages - which is something I can understand. But another > question I'd like to ask is if there is some kind of document where I > can read about such issues. > > > thanks in advance > > Lars [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |