Just out of curiosity - isn't this what C# does with objects? would it perhaps be something like that in how mcs (mono) builds objects and tracks their lifespan?
On Sun, Aug 29, 2010 at 4:43 AM, Uday P. Khedker <u...@cse.iitb.ac.in> wrote: > >> I am not sure that is easily feasible. I would believe it is impossible. >> >> Within the compiler (or inside a GCC plugin, or inside a GCC extension >> coded in MELT), you probably are able change/inspect C++ classes& every >> other declaration any compiler is tracking. You are also able to find >> every occurrence of variables containing a pointer to such classes. > >> >> However, you are apparently willing to track a single *instance* of such >> a class, and this instance is in the execution of the compiled program >> [not inside the compiler]. This means that you are able to deal with all > > > To put it in other words: Here the issue is seeking runtime information at > compile time. An object is a run time entity. At compile time, we only see > the class. However, we also see the statements that create an object and > manipulate it. Although it is not possible to track each object distinctly, > a compile time approximation is certainly possible. And that is where > creativity > in compiler research lies. The better the approximations, the better the > gains. > For example, all objects that get created by a given statement can be > treated > alike. There is no way of distinguishing between them at compile time, but > perhaps > there is no need to do so because all of them are likely to be treated alike > at run time. if an object O1 and O2 are created by the same statement, > asking > the question whether a method m1 is invoked for O1 does not need us to > distinguish > between O1 and O2. > > To summarize, a good approximation is indeed possible at compile time. > > >> the aliasing& pointer equivalence issues (a task known to be >> impossible). How can the compiler surely know that pointer p in [a >> particular instruction of] method YourClass::foo() is never (or >> sometimes, or always) pointing to the same instance -in the running >> process of the compiled program- as pointer q in method yourclass::bar() > > Basile, you keep mentioning that English is not your first language and I > appreciate your politeness for reminding the reader for that (English is not > the first language for me too). It is in that light that I would like to > point > out that your use of word "impossible" is a little too strong. Perhaps you > mean > difficult. It is impossible if you want exact information. However, if > imprecisions can be tolerated for some gains, excellent approximations are > possible _within_ a procedure body which is what Jeff asked for, to begin > with. > > We have been working on this problem (pointer analysis) for a while but > are quite far from production implementation. Our ideas now seem to mature > a bit and whenever we have a conference paper, I will be happy to share it > with the gcc folks. > >> Or maybe you want to instrument your compiler so that for every code >> emitted for method yourclass::gee() you add a first block which checks >> that the this reciever is not a given pointer. >> >> In other words& C++ parlance, you could (this is doable, but not >> trivial) hack the compiler so that at the start of every method (i.e. >> member function in C++) the equivalent of the following C++ code has >> been magically added >> >> extern "C" YourClass* hunted_yourclass_pointer; >> extern "C" void some_error_routine(void); >> >> if (this == hunted_yourclass_pointer) >> some_error_routine(); > > This is a very good way of paraphrasing the "ideal" requirement. > > Regards, > > Uday. >
