remove.haberg@matematik.su.se (Hans Aberg) writes:

> I figure that if the compiler sees an inline function in a header,
> it must still create a function block of it in case some translation
> unit decides to take its function pointer.

Not true. Some compilers will not emit an out-of-line definition if
the pointer of the inline function is never taken.

The inline keyword is still needed to indicate that the
one-definition-rule does not apply to this function (but rules on the
sequence of tokens defining the inline function do apply). If you have
only one definition of your inline function, you can safely remove the
inline keyword without changing the meaning of the program.

Regards,
Martin

---
[ 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:
>
> I wonder if the keyword "inline" is needed anymore, as the compilers
> nowadays can decide for themselves when to inline:

Most of the compilers I've used are NOT overly smart (even if you
tell them it's OK to inline at random).  I spent a lot of time
getting the both the SUN and VC++ to inline things by forcing the
issue (VC++ provides a keyword to override it's inline decision,
the technique used by the Sun compiler is an abomination).

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

In article <remove.haberg-0601021349320001@du131-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>I wonder if the keyword "inline" is needed anymore, as the compilers
>nowadays can decide for themselves when to inline:

"inline" and "register" are hints from the programmer, who may sometimes be
able to tell better than the compiler which functions and variables can
benefit most from these optimizations.

--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

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

Martin von Loewis <loewis@informatik.hu-berlin.de> wrote:
[...]
: The inline keyword is still needed to indicate that the
: one-definition-rule does not apply to this function (but rules on the
: sequence of tokens defining the inline function do apply).

Agreed.  So, why not make the inline version of the one-definition
rule (which might be called "the equivalent-definition rule") the
standard for all functions?  The benefit of that change would be that
it would simplify the standard and would be one less thing for
students to learn and programmers to keep in mind.

Tom Payne

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

In article <a1f9hf$peh$1@glue.ucr.edu>,  <thp@cs.ucr.edu> wrote:
>...why not make the inline version of the one-definition
>rule (which might be called "the equivalent-definition rule") the
>standard for all functions?  The benefit of that change would be that
>it would simplify the standard and would be one less thing for
>students to learn and programmers to keep in mind.

This _tends_ to be what C has, for objects, and it's not necessarily
simpler.   For instance, students are lost understanding why
something like C's ``tentative definitions'' are available,
because for instance, they don't know when to use them or not.
And so on...
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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

In article <j4ell1rvu9.fsf@informatik.hu-berlin.de>, Martin von Loewis
<loewis@informatik.hu-berlin.de> wrote:
>The inline keyword is still needed to indicate that the
>one-definition-rule does not apply to this function

My guess this is the property of the inline function that I wanted to
catch, its ability to avoid multiple definitions, despite being put in a
header.

Perhaps one could do away with the need, for this purpose, to indicate
"inline" explicitly by adding the capacity of file inclusion directly into
C++ (instead of relying on the preprocessor):

One suggestion (in another thread some time ago) was that writing
  using <file-name>;
  using "file-name";
would let the C++ compiler to include the file in question into the given
local context.

This way, one can might do away with the traditional file structure of
headers and sources:

The compiler will know that the file it compiles should produce object
code. It will not produce object code for the stuff in the files included
by the "using" directive, as it knows these will be compiled separately;
instead, those files will scanned only for the declaration aspect,
skipping the code definition aspect.

This way of treating the input is not possible when using the
preprocessor, as the then the context of where the input is put is lost to
the actual C++ compiler.

  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                ]

Greg Comeau <comeau@panix.com> wrote:
: In article <a1f9hf$peh$1@glue.ucr.edu>,  <thp@cs.ucr.edu> wrote:
:>...why not make the inline version of the one-definition
:>rule (which might be called "the equivalent-definition rule") the
:>standard for all functions?  The benefit of that change would be that
:>it would simplify the standard and would be one less thing for
:>students to learn and programmers to keep in mind.

: This _tends_ to be what C has, for objects, and it's not necessarily
: simpler.   For instance, students are lost understanding why
: something like C's ``tentative definitions'' are available,
: because for instance, they don't know when to use them or not.
: And so on...

I'm not familiar with C's tentative definitions.  What I have in mind
for inline can be explained in two sentences:

  * Under current implementation technology, a compiler can inline function
    calls only when the called function is defined in the translation unit
    being compiled.

  * If more than one translation unit defines a given nonstatic
    function, those definitions must be syntactically equivalent, or
    the resulting behavior will be undefined (since most linkers will
    get confused).

Tom Payne

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

remove.haberg@matematik.su.se (Hans Aberg) writes:

> My guess this is the property of the inline function that I wanted to
> catch, its ability to avoid multiple definitions, despite being put in a
> header.

I don't want to lose the one definition rule; I consider it an
advantage rather than a source of problems. Notice that a violation of
the requirement that all copies of the inline function have identical
token sequences is not detected by as many implementations as a
violation of the ODR.

> One suggestion (in another thread some time ago) was that writing
>   using <file-name>;
>   using "file-name";
> would let the C++ compiler to include the file in question into the given
> local context.
>
> This way, one can might do away with the traditional file structure of
> headers and sources:

That would completely change the nature of C++. #include is so
different from any import/using scheme I know of that you probably
cannot describe all interesting parts of its semantics in a only few
pages of text, let alone in 50 or so lines of a Usenet article.

Regards,
Martin

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

Martin von Loewis <loewis@informatik.hu-berlin.de> wrote:
: remove.haberg@matematik.su.se (Hans Aberg) writes:

:> My guess this is the property of the inline function that I wanted to
:> catch, its ability to avoid multiple definitions, despite being put in a
:> header.

: I don't want to lose the one definition rule; I consider it an
: advantage rather than a source of problems. Notice that a violation of
: the requirement that all copies of the inline function have identical
: token sequences is not detected by as many implementations as a
: violation of the ODR.

A very good point, but ODR violations do not require a diagnostic and
simple checksum-based schemes could catch nearly all violations of
an equivalent-definition rule.

Tom Payne

---
[ 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 wonder if the keyword "inline" is needed anymore, as the compilers
nowadays can decide for themselves when to inline:

I figure that if the compiler sees an inline function in a header, it must
still create a function block of it in case some translation unit decides
to take its function pointer.

So why not allowing every function to be treated as "inline", that is,
whenever possible any function may be inlined if the compiler can do it.
Then the programmer needs no longer to insert this word everywhere.
Instead, one would have some means to ensure that a function is not
inlined, if there are circumstances that the programmer needs to be able
to dictate that.

  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                ]

In article <remove.haberg-0601021349320001@du131-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>So why not allowing every function to be treated as "inline", that is,
>whenever possible any function may be inlined if the compiler can do it.

This is already the case.
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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 <remove.haberg@matematik.su.se> wrote:
: I wonder if the keyword "inline" is needed anymore, as the compilers
: nowadays can decide for themselves when to inline:

: I figure that if the compiler sees an inline function in a header, it must
: still create a function block of it in case some translation unit decides
: to take its function pointer.

: So why not allowing every function to be treated as "inline", that is,
: whenever possible any function may be inlined if the compiler can do it.
: Then the programmer needs no longer to insert this word everywhere.

AFIK, the only behavioral significance of the inline qualifier (other
than its service as an optimization hint) is that nonstatic inline
functions can be identically defined in multiple translation units
without violating the one-definition rule.

: Instead, one would have some means to ensure that a function is not
: inlined, if there are circumstances that the programmer needs to be able
: to dictate that.

IMHO, language specifications should "dictate" behavior (and only
"hint" at implementation).

Tom Payne

















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