philippeb@videotron.ca (Philippe A. Bouchard) wrote (abridged):
> (I'll post it again and assume I'm right if nobody has a
> counterexample.)
>
> What would you say if the 'inline' keyword would become a deterministic
> keyword in nested classes or functions (therefore virtual, recursive or
> too much complex functions rejected)?

Inlining is best left to the compiler. It usually has more patience and
more knowledge of the target hardware.


> It would be great here:
>
> template <typename _T>
>     void foo(_T const & t)
>     {
>         t();
>     }
>
> int main()
> {
>     int i;
>
>     inline bool f() { return i == 1; }
>
>     struct
>     {
>         inline bool operator()() { return i == 2; }
>     } s;
>
>     foo(f); // 'inline' would be needed in order to be accepted
>     foo(s); // 'inline' of operator() would be needed to be accepted
> }

I think the word you are looking for is "external". For templates we need
some way to request external linkage of nested classes. It has little to
do with inlining.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20020214195820.5663B@brangdon.madasafish.com...
> Inlining is best left to the compiler. It usually has more patience and
> more knowledge of the target hardware.

Yes, it's true.

> I think the word you are looking for is "external". For templates we need
> some way to request external linkage of nested classes. It has little to
> do with inlining.

My primary concern was to easily access stacked variables with nested
functors instanciated in template functions. Inlining gave an opportunity
for the compiler to modify the generated contents of a function to access
that stacked variable, depending on the depth the nested class was
instanciated in the template function. Having an external functor meant
introducing garbage collectors since the member function had to be
instanciated once only for virtual tables, etc. and the stacked variable was
to be accessed in different depths at the same time (a~ n_instanciation /
depth).

Initially I wanted to easily use <algo> with on-the-fly functors.
for_each(), find_if(), ... are all template functions who need functors:

#include <algorithm>
#include <iostream>
#include <string>

using namespace std;

int main()
{
 string a[] =
 {
  "Marc",
  "Shawn",
  "George",
  "Robert"
 };

 find_if
 (
  a,
  a + 4,
  struct
  {
   bool operator()(string const & b) const
   {
    return b == a[2];
   }
  } ()
 );
}



Regards,

Philippe A. Bouchard
Xandros Software Engineer

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Phillipe A. Bouchard:
> > What would you say if the 'inline' keyword would become a deterministic
> > keyword in nested classes or functions (therefore virtual, recursive or
> > too much complex functions rejected)?

Dave Harris:
> Inlining is best left to the compiler. It usually has more patience and
> more knowledge of the target hardware.

Hmm. Agree that the compiler has more knowledge
than most programmers about the target hardware.

But programmers can profile their code under
typical usage conditions in order to
determine performance bottlenecks. They then
have knowledge about the situation that the
compiler doesn't have access to and so are
in a better position to make inlining decisions.

Granted, most programmers don't do this for most
code, which is why I believe the semantics of
inline should remain as they are, but the point
remains that, at least some of the time,
programmers can make better inlining decisions
than compilers [1].

Accepting that inline stays as it is, there is certainly
nothing wrong in compiler vendors supporting
pragmas that force inlining in the way proposed,
but I don't believe the addition of a separate
forced_inline keyword, or whatever you want to call it,
to the core language has sufficient utility to be
worth the additional language complexity.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

NOTES:

1. I find this spiritually reassuring. The day my
collection of zeros and ones compiler is always
smarter than me will be a sad day. (I have learned
to accept the fact that it is *usually* smarter than
me ;-)

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

philippeb@videotron.ca (Philippe A. Bouchard) wrote (abridged):
> My primary concern was to easily access stacked variables with nested
> functors instanciated in template functions. Inlining gave an
> opportunity for the compiler to modify the generated contents of
> a function to access that stacked variable, depending on the depth
> the nested class was instanciated in the template function. Having
> an external functor meant introducing garbage collectors since the
> member function had to be instanciated once only for virtual tables,
> etc. and the stacked variable was to be accessed in different depths
> at the same time (a~ n_instanciation / depth).

I think it would help if you could express the effect of "inline" without
it sounding like an optimisation.

In a case like this, the compiler can see the full source code of the
functor. It can probably see the full source code of the template, too.
This gives it a lot of scope for optimisation. What does "inline" tell it
that it can't already deduce for itself? Is there some new constraint on
inline functions?

I don't really follow how you think "inline" helps with memory management.
Where a stack variable is accessed by two nested functors, it still has to
live on the stack, right? It will still be destroyed when it goes out of
scope. If the template keeps a reference to it, or to the function that
uses it, we will still get a dangling reference.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Dave Harris" <brangdon@cix.co.uk> wrote in message
> In a case like this, the compiler can see the full source code of the
> functor. It can probably see the full source code of the template, too.
> This gives it a lot of scope for optimisation. What does "inline" tell it
> that it can't already deduce for itself? Is there some new constraint on
> inline functions?

My only concern is to simplify things here. It happens that 'inline' is the
quickest way to implement something in the compiler for compiler writers
since the generated code of those inline functions can discreetly use a
different relative address to access that variable living on the stack. That
relative address will depend on the depth because the stack pointer (%esp)
will be modified each time a new function is called.

It's possible not to use the 'inline' keyword, but things get more
complicated:

// There are other ways to implement this but it's not the goal of my
example.
#include <string>
#include <algorithm>

using namespace std;

struct S // Is external to make the example work
{
 string const & reference_to_local;

 S(string const & s):reference_to_local(s) {}

 bool operator()(string const & s) const
 {
  return s == reference_to_local;
 }
};

int main()
{
 string c[] = {"John", "Peter", "Alexi"};

 cout << * find_if(c, c + 3, S("Peter")) << endl;
}


We need to transform the local variable into a referenced parameter.


Philippe


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

(I'll post it again and assume I'm right if nobody has a counterexample.)

What would you say if the 'inline' keyword would become a deterministic
keyword in nested classes or functions (therefore virtual, recursive or too
much complex functions rejected)?

It would be great here:

template <typename _T>
    void foo(_T const & t)
    {
        t();
    }

int main()
{
    int i;

    inline bool f() { return i == 1; }

    struct
    {
        inline bool operator()() { return i == 2; }
    } s;

    foo(f); // 'inline' would be needed in order to be accepted
    foo(s); // 'inline' of operator() would be needed to be accepted
}


Thanks,
Philippe


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Philippe> What would you say if the 'inline' keyword would become a
Philippe> deterministic keyword in nested classes or functions
Philippe> (therefore virtual, recursive or too much complex functions
Philippe> rejected)?

I would say it would be a great step backward.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]