From 5068311291834055537
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,15a3eb1ed336ff4e
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 2002-02-16 14:26:01 PST
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!dispose.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail
From: brangdon@cix.co.uk (Dave Harris)
Newsgroups: comp.std.c++
Subject: Re: Proposal: Nested inline (function | functor)
Date: Sat, 16 Feb 2002 22:25:46 GMT
Approved: Fergus Henderson <fjh@cs.mu.oz.au>, moderator of comp.std.c++
Message-ID: <memo.20020216121052.11581B@brangdon.madasafish.com>
References: <xPWa8.3851$bS4.156208@weber.videotron.net>
Reply-To: brangdon@cix.co.uk
X-Trace: mail2news.demon.co.uk 1013898352 mail2news:3204 mail2news mail2news.demon.co.uk
X-Complaints-To: abuse@demon.net
X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au
X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f
X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov)
X-Orig-NNTP-Posting-Host: pc2-clif3-0-cust11.not.cable.ntl.com (80.4.39.11)
X-Orig-X-Trace: fu-berlin.de 1013861316 1216853 80.4.39.11 (16 [57443])
Lines: 37
Xref: archiver1.google.com comp.std.c++:9688

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                ]



