C++/CLI limitations?
in [C++]
|
Prev: Exceptions
Next: C++ Concepts
From: Dave Harris on 19 Sep 2005 13:14 David-White(a)earthlink.net (David F) wrote (abridged): > Computer science theory proved already decades ago that altogether, > GC is more of a liability than an asset Can you cite the paper where that was proved? I am surprised I have not heard of it before. -- Dave Harris, Nottingham, UK. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: kanze on 20 Sep 2005 05:39 Ismail Pazarbasi wrote: > > You are right because the whole thing called GC being > > imposed on a programmer is one big compatibility flap. > From standard's point of view, there is nothing called GC. Correct. An implementation can provide it, with certain restrictions, but it isn't required. > ISO C++ is not interested in GC. I seem to understand otherwise; that there is some interest in the standards committee for making it standard. > GC is not interested in ISO C++ either. GC is a concept, not an organization or a person. There are garbage collectors for C++. They work pretty well, and in fact, I normally use the Boehm collector in new projects. > The whole idea that ISO C++ states "do not move pointers", and > the whole idea of GC is to "reclaim memory". So what's the relationship? First, of course, strictly speaking, ISO C++ doesn't say "do not move pointers"; it says that any moving of pointers must be transparent. With current compilers, this does mean don't move pointers, but conceptually, at least, it should be possible to make a compiler which did allow for pointer movement. Secondly, just as of course, is the fact that many garbage collectors (such as the Boehm collector) don't move pointers. > So the problem is, in fact, the GC implementation is > incompatible with ISO C++ - it's not designed for ISO C++ > compatibility in mind. I'm not sure if it is intentional, but you've subtly changed the argument. From "garbage collection [in general]" to "the GC implemenation" (i.e. a specific implementation). There are certainly implementations of garbage collectors which were not designed with C/C++ compatibility in mind. But of course, if I want C/C++ compatibility, I will choose an implementation which does respect the language constraints. [The rest of your post seems to be only concerned with CLI. Not my thing, so I won't comment on it.] -- James Kanze GABI Software Conseils en informatique orient?e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Ismail Pazarbasi on 20 Sep 2005 05:52 Hyman, I did not say "reclaiming memory is incompatible with ISO C++". I said "GC implementation is incompatible with ISO C++". The GC implementation itself is incompatible with ISO C++. As you already know, CLR implements a compacting garbage collector that moves objects around. This implementation is not compatible with ISO C++. This is why we have a handle "in addition to" to pointers. 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 20 Sep 2005 20:08 > "Allan W" <allan_w(a)my-dejanews.com> 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. David F wrote: > 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. I don't remember saying that! Okay, let's back up. C and C++ define the semantics of pointers, and C++ defines the semantics of pointer-to-member. There is an obvious way to implement both of these, but neither standard requires it. There's no reason why a GC couldn't maintain a table of addresses of objects in the free store, and then have a "pointer" be an index into the table plus an object. This would require support from the compiler, of course. I'm not familiar with any implementation that works this way... that doesn't mean it doesn't exist. Even if it doesn't exist today, that doesn't mean it won't exist tomorrow... my point right now is that we should stop saying that GC is "incompatible" with C++. > 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. I join the large gang of people asking for a pointer to this "proof." > Besides, there are many GC packages > available in the market for C++ for those who OPT for it, I completely agree. > and w/o > forcing one to use it and worse, modifying the language as MS did. How is MS forcing you to use GC? Even within the .Net platform it is possible to create "unsafe" pointers, although that is not preferred... but it's certainly possible to bypass .NET altogether, and AFAIK MS doesn't point guns at people... > > 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, In Visual Studio .Net 2003, click "File/New/Project" (or Ctrl+N). From "Visual C++ Projects" select "Win32 Console Project". Type a name and click OK. Click on "Application Settings." Check the "Empty project" box, press Finish. Click "File/Add New Item..." (or Ctrl+Shift+A). Select "C++ File" and enter a filename. Click "Open". Enter a program that follows ISO/IEC 14882:1998(E) (Ansi C++, 7/28/1998). Note that C++98 does not understand what a Window is! Use console I/O only. However, you are perfectly free to use pointers/new/delete in the standard way, without having to use the "unsafe" keyword -- you are not writing a ..NET program! Click "Build/Rebuild Solution" to compile and link. Select "Debug/Start Without Debugging" (or Ctrl+F5) to run it. Which part of this is significantly different than using any other standard compiler? > 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++. Don't use BOOL, INT, INT32... use bool and int instead. Sheesh! > 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 !. Which part of ISO/IEC 14882:1998(E) tells you how to use C++ to create Web sites? > "...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. See above. > I think this has nothing to do with bashing but with the ability to face > thing as they are. Possibly not "bashing" but simple ignorance... Did you even ask anyone for help? Or did you just decide that standard C++ was not possible with that compiler? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Branimir Maksimovic on 20 Sep 2005 20:05
Ismail Pazarbasi wrote: > > >From standard's point of view, there is nothing called GC. ISO C++ is > not interested in GC. GC is not interested in ISO C++ either. The whole > idea that ISO C++ states "do not move pointers", and the whole idea of > GC is to "reclaim memory". So the problem is, in fact, the GC > implementation is incompatible with ISO C++ - it's not designed for ISO > C++ compatibility in mind. As I know there are three generic GC implementations. Reference counting, copying and mark and sweep. Only copying GC is not compatible with c++ because it has to update all references/pointers to GC heap but there actually exists copying collectors for ISO C++ (no problem if one uses smart pointers that can be recognized and updated as GC pointers). Copying collector has advantage of no fragmentation but it use twice as much memory then mark and sweep or reference counting and it has to update all pointers and copy used blocks to other memory area in order to defragment, which is costly in run time IMO. Best bet for ISO C++ is mark and sweep it works pretty good and fast and does not require any language or program change. In the matter of fact it works with non GC programs as well. I can't see what's incompatible with C++ there. Greetings, Bane. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |