On 9/18/07, Ioannis Gyftos <jgif@xxxxxxxxxxx> wrote:
> Hello,
>
> I assume that this is the correct mailing list to ask this, as opposed
> to a Cpp list, since it appears to me that this is compiler-related.
>
> 1)
>
> class foo
> {
> int priv;
> public:
> void bar();
> };
>
> Supposing i am writing the definition of foo::bar, and i want to change
> the private member priv. Is "this->priv=1" equal to "priv=1", as far as
> performance goes? I assume that since there is an explicit dereference
> of *this, there is no performance overhead so both would be equal,
> however i could not locate any documentation on this (and typing "this"
> on search engines does not weild the best results...). Is this correct?
>
> (I am asking because of a suggested policy to refer to members of
> classes with "this->", in an effort to distinguish them from
> non-members, something like priv_)
>
> 2)
>
> #undef DEBUG_FLAG
>
> void foo()
> {
> #ifdef DEBUG_FLAG
> DoSomeStuff();
> #endif
> }
>
> inline void bar()
> {
> #ifdef DEBUG_FLAG
> DoSomeStuff();
> #endif
> }
>
> int main(...)
> {
> foo();
> bar();
> }
>
> Consider the foo function, where after the pre-compiler step, the
> compiler would know that the body of a given function is empty. Is the
> call to that function included in the built .o? (call/ret, possibly
> push/pop, etc). I am asking because such a thing would add (usually?)
> unnecessary overhead.
>
> Also, in the inlined empty function case. This should (always?) be
> expanded to a no-op (and thus eliminated) from the .o object, the way i
> see it. But again, i could not find any confirmation. Is this correct?
>
> (What i try to achieve by this is to have debugging functionality added
> that completely vanishes from the executable after i compile it with
> different options. I would maintain the calls to debugging functions to
> the performance-critical parts, in hope that they are recognised as
> empty and not add any performance penalty)
>
> Thank you for your time,
> Ioannis.
Forwarding to list gcc-help.
