On Sun, 2010-08-29 at 17:13 +0530, Uday P. Khedker 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.
Yes, that is what I meant. Any compile-time tool produces some abstraction. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
