In article 2FB92EB8@iname.com, anupam kapoor <anupamk@iname.com> writes:
>
>As I understand , 'inline' keyword is just a directive , much like the
>'register' keyword in C for the compiler for optimization purposes.

Yes, under the rules in the draft standard. (In the ARM, "inline"
also meant "static", but not any more.)

>Is there a way of finding out whether the member functions are actually
>getting inlined or not ?

No portable way, just as there is no portable way to find out whether
a variable declared "register" is actually placed in a register.

Some compilers have an optional warning about inline functions not being
generated inline.

---
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I'd like to ask for opinions about a question involving inline
functions. The following program has two different outcomes depending
on the compiler.

#include <iostream.h>

class dummy
{
  public :
  void  func1()
  {
    cout<<"first func"<<endl;
    return;
  }
  void func2()
  {
    cout<<"second func"<<endl;
    return;
  }
};
main ()
{
dummy a1;
a1.func1();
a1.func2();
}

With compiler X, the program ends with the call to a1.func1(),
apparently because the compiler does the inlining with the following
effect:

main ()
{
  dummy a1;
  cout<<"first func"<<endl;
  return;
  cout<<"second func"<<endl;
  return;
}

Other compilers complete both function calls.

The only thing I could find in the draft relating to this is the
following.

  7.1.2  Function specifiers                              [dcl.fct.spec]

  ...

2 The  inline specifier is a hint to the implementation that inline sub-
  stitution of the function body is to be preferred to the  usual  func-
  tion call implementation.  The hint can be ignored.  The inline speci-
  fier shall not appear on a block scope function declaration.  For  the
  linkage  of inline functions, see _basic.link_ and _dcl.stc_.  A func-
  tion (_dcl.fct_,  _class.mfct_,  _class.friend_)  defined  within  the
  class definition is inline.

This appears to allow the compiler to literally do "...inline
substitution of the function body...". Is this a correct
interpretation? Is there anything in the draft which says that the
compiler needs to allow for the example above?

Thanks

Joe


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 72t@engnews1.Eng.Sun.COM, "joe (j.) halpin" <jhalpin@nortel.ca> writes:
>I'd like to ask for opinions about a question involving inline
>functions. The following program has two different outcomes depending
>on the compiler.
>
>#include <iostream.h>
>
>class dummy
>{
>  public :
>  void  func1()
>  {
>    cout<<"first func"<<endl;
>    return;
>  }
>  void func2()
>  {
>    cout<<"second func"<<endl;
>    return;
>  }
>};
>main ()
>{
>dummy a1;
>a1.func1();
>a1.func2();
>}
>
>With compiler X, the program ends with the call to a1.func1(),
>apparently because the compiler does the inlining with the following
>effect:
>
>main ()
>{
>  dummy a1;
>  cout<<"first func"<<endl;
>  return;
>  cout<<"second func"<<endl;
>  return;
>}

That is clearly wrong. Section 7.1.2 "Function specifiers" does talk
about "inline substitution of the function body", but it doesn't say
"substitution of the source-code". That is, an inline function is
not a source-text macro.

If you look at the sections on linkage (3.5 and 7.1.1), function call
(5.2.2), and the "return" statement (6.6.3), it should be clear that
declaring a function inline does not change the semantics of calling it.
In particular, the return statement is defined to "return to its caller".
In this example, a1.func is called from main, and so must return to main.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

On 16 Aug 1996 15:50:35 GMT, "joe (j.) halpin" <jhalpin@nortel.ca>
wrote:

>class dummy
>{
>  public :
>  void  func1()
>  {
>    cout<<"first func"<<endl;
>    return;
>  }
>  void func2()
>  {
>    cout<<"second func"<<endl;
>    return;
>  }
>};
>main ()
>{
>dummy a1;
>a1.func1();
>a1.func2();
>}

This is a conforming program(*) that should print what you expect.

(*) Except for "main()" vs. "int main(int,char**)", but that's
nitpicking. :-)

>With compiler X, the program ends with the call to a1.func1(),

Compiler X would seem to be broken if it acts as you report... which
compiler is it?

>apparently because the compiler does the inlining with the following
>effect:
>
>main ()
>{
>  dummy a1;
>  cout<<"first func"<<endl;
>  return;
>  cout<<"second func"<<endl;
>  return;
>}

I doubt that this is what's happening, since plainly 'substituting the
function body' means with the exception of the return statement (else
inlines would never work).  Inlines are not glorified macro
substitutions.

---
Herb Sutter (herbs@cntc.com)

Current Network Technologies Corp.
3100 Ridgeway, Suite 42, Mississauga ON Canada L5L 5M5
Tel 416-805-9088  Fax 905-608-2611
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

> "joe (j.) halpin" <jhalpin@nortel.ca> wrote in article
<4v25cb$72t@engnews1.Eng.Sun.COM>...
> I'd like to ask for opinions about a question involving inline
> functions. The following program has two different outcomes depending
> on the compiler.
>
[code snippet deleted]
> main ()
> {
> dummy a1;
> a1.func1();
> a1.func2();
> }
>
> With compiler X, the program ends with the call to a1.func1(),
> apparently because the compiler does the inlining with the following
> effect:
>
> main ()
> {
>   dummy a1;
>   cout<<"first func"<<endl;
>   return;
>   cout<<"second func"<<endl;
>   return;
> }
>
Yike... I sure hope not.  Like your quote says the inline keyword
is only a hint (sort of a 'register' keyword on steroids?). The
compiler must maintain the meaning of your code whether it decides
to do the inlining or not.  If you actually saw this in your
debugger your compiler is more than broken.

The only thing I can think of is that for some reason 'cout' is not
being flushed after the second call. That's a stretch but without
more info it's hard to tell.

marco
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]