In article <slrna3c0v9.3iv.jk@beercask.home>, jk@steel.orel.ru (Eugene
Karpachov) wrote:
>>  public:
>>    must inline T(std::size_t n) : mem_(alloca(n)) {}
>>  };
>>If the compiler would not inline this, the memory allocation would go out
>>of the window.
>
>BTW in C++ as it is now, even if compiler would inline this, the memory
>allocation still go out of the window. Inlining don't change program
>semantics, including scoping, lifetimes etc.

In the case of alloca, the semantics does change depending on whether one
inlines or not, as the allocation is put on the stack space of the current
function call.

Thus, if one does not inline say f, the allocation will be in the function
call of f, but if one does inline, then the allocation will happen in the
first function call above f not inlined.

The problem is that the runtime object that alloca creates does not live
by anything compatible with the scoping that C++ currently has.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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                ]

What about adding the features "must" and "ought" to "inline":

must inline ...
would mean that the compiler must inline, and thus operations like taking
the function pointer is illegal. One use of this is when using alloca say
in a class constructor:
  class T {
    void* mem_;
  public:
    must inline T(std::size_t n) : mem_(alloca(n)) {}
  };
If the compiler would not inline this, the memory allocation would go out
of the window.

ought inline ... f ... { ... }
would mean that the compiler must inline f in all situations where it is
possible, but it is still possible to take the function pointer of f. The
use of this is as a replacement for preprocessor macros.

Of course, one might use other keywords than "must" and "ought"; I just
choose them in order express the idea.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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                ]

Hans Aberg wrote:
>
> What about adding the features "must" and "ought" to "inline":
>
> must inline ...
> would mean that the compiler must inline, and thus operations like taking
> the function pointer is illegal. One use of this is when using alloca say

VC++ uses funky declspec (__forceinline) to do this (although a pramga ...or again a dogma)
would probably be nice (Sun supports the forcing of inlines but you must
provide the mangled names on the command line to the compiler which is really
inconvenient, especially with templates).

---
[ 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                ]

Fri,  4 Jan 2002 15:48:07 GMT Hans Aberg wrote:
>  public:
>    must inline T(std::size_t n) : mem_(alloca(n)) {}
>  };
>If the compiler would not inline this, the memory allocation would go out
>of the window.

BTW in C++ as it is now, even if compiler would inline this, the memory
allocation still go out of the window. Inlining don't change program
semantics, including scoping, lifetimes etc.

--
jk

---
[ 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                ]