Mike Rubenstein wrote:

>         extern void inline f() {}
[...lots of quoted material snipped by moderator... -fjh.]
> Unless I've missed something, this is a conforming program.

extern void inline f() {} ???
------                 --

Am I wrong or isn't extern in connection with a definition inappropriate?

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

Axel Dahmen <a.dahmen@pop.gun.de> wrote:

> Mike Rubenstein wrote:
>
> >         extern void inline f() {}
> [...lots of quoted material snipped by moderator... -fjh.]
> > Unless I've missed something, this is a conforming program.
>
> extern void inline f() {} ???
> ------                 --
>
> Am I wrong or isn't extern in connection with a definition inappropriate?

You are wrong.  In both C and C++ extern is permitted in a definition.


It's unusual in C since it's never (read: I can't think of a counter
example) very useful, but in C++ there are times when it is desirable.
This is one of them -- you must use extern to make the inline function
have external linkage (this may have changed recently, but was still
true as of the September DWP).  Another example is something like

 const extern int a = 5;

to make a const have external linkage.


Michael M Rubenstein
---
[ 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
]

Axel Dahmen <a.dahmen@pop.gun.de> writes:

>Mike Rubenstein wrote:

>>         extern void inline f() {}
>[...lots of quoted material snipped by moderator... -fjh.]
>> Unless I've missed something, this is a conforming program.

>extern void inline f() {} ???
>------                 --

>Am I wrong or isn't extern in connection with a definition inappropriate?

At file scope, "extern" is implied for objects and functions if "static"
is omitted. You can write "extern" explicitly if you want without
changing the meaning of the definition. (The exception is const
objects, which have internal linkage unless declared extern.)
--
Steve Clamage, stephen.clamage@eng.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                             ]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) wrote:

> Mark Nelson <markn@tiny.com> writes:
>
> >Mike Rubenstein wrote:
> >>
> >> Mark Nelson <markn@tiny.com> wrote:
> >>
> >> > I'm trying to determine whether some behavior in Borland C++
> >> > represents a bug or not.  The draft says that a function
> >> > defines as "extern inline" needs to have external linkage,
> >> > which Borland does not do. .
>
> What do you mean when you say that "Borland does not do" this?
> The standard doesn't specify how things are to be implemented.
> If you think Borland C++ has a bug, can you give an example of a
> C++ program for which you think Borland C++ gives the wrong results?

FYI, the bug is that Borland C++ 5.0 just won't compile it.  The file

 extern inline void f()
 {
 }

when compiled gives

 d:\work\test>bcc32 -c -A t.cpp
 Borland C++ 5.0 for Win32 Copyright (c) 1993, 1996 Borland
  International
 t.cpp:
 Error t.cpp 1: Too many storage classes in declaration
 *** 1 errors in Compile ***

and does not produce an object file.  Note that the -A compiler option
specifies that the compiler is to conform to the [draft] standard.

I reported this bug to Borland some time ago, but originally missed
the associated bug that a inline function without extern is treated
like an extern at least in that there is only one copy of static
locals for all occurences of the function.  After Mark's messages on
this I have reported it as a bug also.

Michael M Rubenstein
---
[ 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 <31E9578F.66F4@tiny.com>, markn@tiny.com says...
>
>I'm trying to determine whether some behavior in Borland C++
>represents a bug or not.  The draft says that a function
>defines as "extern inline" needs to have external linkage,
>which Borland does not do.
>

How did you determine this? Did you write a conforming program that
acts
differently when compiled with our compiler than the WP says? The key
here is
to be very careful about what you think "extern" means. Hint: it does
not mean
that it is callable from another translation unit.

>However, Borland says that this is okay, because the draft
>*also* says that a function designated inline in one unit
>must be inline in every unit.  Thus, it wouldn't be possible
>for the external linkage to ever be useful.
>

Actually, I think what we said was that the example program you gave
us was not
a conforming program, because it attempted to access a function that
had been
declared extern inline in another translation unit, without providing
an inline
definition in the accessing unit. i.e.:

Unit1.cpp
---------
extern inline void f() {}

Unit2.cpp
---------
extern void f(); // illegal

>So the real questions is what is the intent of allowing this
>seemingly contradictory function declaration to exist?  And
>while Borland may technically appear to not be compliant,
>could anyone actually ever come to any harm as a result of it?

 Making an inline function "extern" means mostly that it is subject to
the one definition rule, which means that all definitions of that
function must
be identical. Violation of the ODR, however, does not require a
diagnostic.
 -- Pete




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

John_David_Galt@cup.portal.com wrote:

> Michael M Rubenstein <miker3@ix.netcom.com> says:
>
> > But in this case it is useful.  Consider
>
> >  extern inline int f()
> >  {
> >    static int n = 0;
> >    return ++n;
> >  }
>
> > With the extern, f() refers to the same function in each compilation
> > unit so f() will return sequential integers regardless of where it is
> > called from.  Without the extern, f() is a different function in each
> > compilation unit so there will be a separate sequence returned for
> > each.
>
> Bzzzt!  Wrong!  The declaration of n as "static" implies a separate sequence
> for each.  Change n to extern and you get a single sequence.  This holds true
> regardless of whether f() is extern or not.
>
> I haven't seen the new draft, so I don't know whether or why an implementation
> is required to support "extern inline", but it seems contradictory to me.
> "extern" just exports the name whose declaration it modifies.  Thus, declaring
> a function "extern inline" says both, "I'm exporting the address of this
> function's code, so it can be called from other modules" and "Generate inline
> code when the user tries to 'call' this function, so it will have no specific
> address."

No, I'm not wrong.  Since f() is extern, there is only one function
named f().

I'd suggest reading the draft.  extern gives an object external
linkage (7.1.1).  That means

 the entity it denotes can be referred to by names from scopes
 of other translation units or from other scopes of the same
 translation unit.

This may (usually is) accomplished by exporting an address, but that's
just an implementation strategy.  The key is that references to the
name from different scopes refer to the same entity.  In the case of
inline extern, this means that there is only one function and that
implies that there is only one copy of static locals for the function.


Michael M Rubenstein
---
[ 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
]

Fergus Henderson wrote:
>
> >>
> >> > I'm trying to determine whether some behavior in Borland C++
> >> > represents a bug or not.  The draft says that a function
> >> > defines as "extern inline" needs to have external linkage,
> >> > which Borland does not do. .
>
> What do you mean when you say that "Borland does not do" this?
> The standard doesn't specify how things are to be implemented.
> If you think Borland C++ has a bug, can you give an example of a
> C++ program for which you think Borland C++ gives the wrong results?

When you define a function as "extern inline", Borland does not generate
a PUBDEF in their object file, so for all practical purposes it might as
well be static.  I don't know the standard well enough to say what
compliance means when it comes to external linkage, but Borland is
not doing anything that looks to me like external linkage.

This doesn't mean I can produce a program that gives wrong results.  That
is the whole reason I started this thread; I was confused over what possible
purpose "extern inline" could serve.

Mike Rubenstein has given a rational explanation.  In his view, "extern inline"
serves to make "all uses of the function in different units refer to the
same function."  The only immediate effect I can see that this has is in the
way static variables defined in a function are treated.

The reason this is all so oblique is that Mike's explanation is not
immediately obvious (at least not to me) by the statement in the draft that
"extern inline" mandates external linkage.

I'd love to hear anyone else's opinion about this.  But at this time,
without a good rebuttal, I guess Mike Rubenstein seems the most rational.

-----------------------------
Mark Nelson
markn@tiny.com
http://web2.airmail.net/markn
---
[ 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
]

In article <9607181712.2.18292@cup.portal.com>
John_David_Galt@cup.portal.com writes:

|> Michael M Rubenstein <miker3@ix.netcom.com> says:

|> > But in this case it is useful.  Consider

|> >  extern inline int f()
|> >  {
|> >    static int n = 0;
|> >    return ++n;
|> >  }

|> > With the extern, f() refers to the same function in each compilation
|> > unit so f() will return sequential integers regardless of where it is
|> > called from.  Without the extern, f() is a different function in each
|> > compilation unit so there will be a separate sequence returned for
|> > each.

|> Bzzzt!  Wrong!  The declaration of n as "static" implies a separate
|> sequence for each.  Change n to extern and you get a single sequence.
|> This holds true regardless of whether f() is extern or not.

No.  The declaration of n as static implies a separate sequence for each
instance of the function.  The declaration of the function as extern
implies a single instance, so a single sequence.

|> I haven't seen the new draft, so I don't know whether or why an
|> implementation is required to support "extern inline", but it seems
|> contradictory to me. "extern" just exports the name whose declaration
|> it modifies.  Thus, declaring a function "extern inline" says both, "I'm
|> exporting the address of this function's code, so it can be called from
|> other modules" and "Generate inline code when the user tries to 'call'
|> this function, so it will have no specific

Extern and inline are orthogonal concepts.  Extern implies that the
function has external linkage, and that all references to it refer to
the same function.  Inline is nothing more than a hint to the compiler
that it could try and inline the function.  Inline also means that the
default linkage is static, instead of extern, but since the linkage is
explicitly given here, this is not relevant.

An essential rule is that inline is just a hint, and that making a
function inline do not change the semantics in anyway.  Thus, for
example, if I take the address of a function with static linkage in two
different modules, I *must* get a different address, and if I take the
address of a function with extern linkage in two different modules, I
*must* get the same address.  This is true irregardless of whether the
function is static or not.  Similarly, in a function with static
linkage, a local static variable must have a separate instance for each
compilation unit in which it appears.  If the function has extern
linkage, there most be one and only one instance.

How the compiler does this is its business.  The easiest solution is
just to ignore the inline hint, and merge the multiple copies of
functions with extern linkage.  (This is what many compilers currently
do with templates anyway.)  A simple improvement would be to only ignore
the inline if the function has a static variable or has its address
taken.  And it shouldn't be that difficult in the case of a local static
variable to generate the function inline, and just merge the variable if
the function had extern linkage.

With regards to the complaints about Borland "bugs" in handling this: it
is worth noting that the committee only recently clarified this point,
and it is entirely possible that Borland still implements an earlier
interpretation.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ 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've just heard that the C++ committee made a change to the semantics
of `inline' at last week's meeting -- apparently `inline' will no
longer imply static linkage.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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                             ]

pbecker@wpo.borland.com (Pete Becker) wrote:

> In article <31E9578F.66F4@tiny.com>, markn@tiny.com says...
> >
> >I'm trying to determine whether some behavior in Borland C++
> >represents a bug or not.  The draft says that a function
> >defines as "extern inline" needs to have external linkage,
> >which Borland does not do.
> >
>
> How did you determine this? Did you write a conforming program that
> acts
> differently when compiled with our compiler than the WP says? The key
> here is
> to be very careful about what you think "extern" means. Hint: it does
> not mean
> that it is callable from another translation unit.
>
> >However, Borland says that this is okay, because the draft
> >*also* says that a function designated inline in one unit
> >must be inline in every unit.  Thus, it wouldn't be possible
> >for the external linkage to ever be useful.
> >
>
> Actually, I think what we said was that the example program you gave
> us was not
> a conforming program, because it attempted to access a function that
> had been
> declared extern inline in another translation unit, without providing
> an inline
> definition in the accessing unit. i.e.:
>
> Unit1.cpp
> ---------
> extern inline void f() {}
>
> Unit2.cpp
> ---------
> extern void f(); // illegal
>
> >So the real questions is what is the intent of allowing this
> >seemingly contradictory function declaration to exist?  And
> >while Borland may technically appear to not be compliant,
> >could anyone actually ever come to any harm as a result of it?
>
>  Making an inline function "extern" means mostly that it is subject to
> the one definition rule, which means that all definitions of that
> function must
> be identical. Violation of the ODR, however, does not require a
> diagnostic.

Come on Pete.  It's very easy to find a conforming program that acts
differently when compiled with your compiler than as specified by the
WP.  Borland just doesn't support extern inline at all.

Here's an example:

 #include <iostream>

 extern void inline f() {}

 int main()
 {
   cout << "hello world\n";
 }

When compiled with BC++ 5.0, the compiler produces the messages

 d:\work\test>bcc32 -A t.cpp
 Borland C++ 5.0 for Win32 Copyright (c) 1993, 1996 Borland
  International
 t.cpp:
 Loaded pre-compiled headers.
 Error t.cpp 3: Too many storage classes in declaration
 *** 1 errors in Compile ***

and does not generate an executable.  Unless I've missed something,
this is a conforming program.


Michael M Rubenstein
---
[ 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
]

Pete Becker wrote:
>
> In article <31E9578F.66F4@tiny.com>, markn@tiny.com says...
> >
> >I'm trying to determine whether some behavior in Borland C++
> >represents a bug or not.  The draft says that a function
> >defines as "extern inline" needs to have external linkage,
> >which Borland does not do.
> >
>
> How did you determine this? Did you write a conforming program that
> acts
> differently when compiled with our compiler than the WP says? The key
> here is
> to be very careful about what you think "extern" means. Hint: it does
> not mean
> that it is callable from another translation unit.
>

It's quite easy to show that Borland doesn't conform, because 4.5x and 5.0
refuse to compile anything declared "extern inline".

But, I'm thinking that this syntax is also acceptable:


extern int foo();

inline int foo()
{
    return 1;
}

If this syntax is equivalent to declaring a functions as "extern inline",
then you can easily show that Borland isn't conforming.  Hint:  try
it.

-----------------------------
Mark Nelson
markn@tiny.com
http://web2.airmail.net/markn
---
[ 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
]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

>I've just heard that the C++ committee made a change to the semantics
>of `inline' at last week's meeting -- apparently `inline' will no
>longer imply static linkage.

Not exactly.

Class member functions have external linkage, whether they are
declared inline or not. It wasn't clear in the ARM whether that
was the case, but recent versions of the DWP made that point.

The C++ Committee just added the capability to declare a non-member
function "extern inline". Such a function has external linkage,
meaning that all references to that function refer to the same
definition; at most one copy exists in the entire program. The
function can still (in principle) be generated inline.

Non-member functions declared "inline" but not "extern inline" still
have static linkage implicitly. Existing programs have unchanged
semantics.
--
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
]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

>clamage@Eng.Sun.COM (Steve Clamage) writes:

>>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>>
>>>I've just heard that the C++ committee made a change to the semantics
>>>of `inline' at last week's meeting -- apparently `inline' will no
>>>longer imply static linkage.
>>
>>Not exactly.
>
>Now I'm really confused.  Wasn't that capability already present before
>the most recent meeting, e.g. in the June 96 DWP?  That was certainly
>my understanding, and as far as I can tell my understanding is supported
>by the wording in the June 96 DWP.

Sorry, I was confused. At the last meeting a change was voted in
to make extern linkage the default for inline functions. To get
the old semantics you have to declare a function "static inline".

The change was part of the template compilation model that was
adopted.
--
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
]

clamage@Eng.Sun.COM (Steve Clamage) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>>I've just heard that the C++ committee made a change to the semantics
>>of `inline' at last week's meeting -- apparently `inline' will no
>>longer imply static linkage.
>
>Not exactly.
>
>Class member functions have external linkage, whether they are
>declared inline or not. It wasn't clear in the ARM whether that
>was the case, but recent versions of the DWP made that point.
>
>The C++ Committee just added the capability to declare a non-member
>function "extern inline".

Now I'm really confused.  Wasn't that capability already present before
the most recent meeting, e.g. in the June 96 DWP?  That was certainly
my understanding, and as far as I can tell my understanding is supported
by the wording in the June 96 DWP.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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'm trying to determine whether some behavior in Borland C++
represents a bug or not.  The draft says that a function
defines as "extern inline" needs to have external linkage,
which Borland does not do.

However, Borland says that this is okay, because the draft
*also* says that a function designated inline in one unit
must be inline in every unit.  Thus, it wouldn't be possible
for the external linkage to ever be useful.

So the real questions is what is the intent of allowing this
seemingly contradictory function declaration to exist?  And
while Borland may technically appear to not be compliant,
could anyone actually ever come to any harm as a result of it?


-----------------------------
Mark Nelson
markn@tiny.com
http://web2.airmail.net/markn
---
[ 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                             ]

Mark Nelson <markn@tiny.com> wrote:

> I'm trying to determine whether some behavior in Borland C++
> represents a bug or not.  The draft says that a function
> defines as "extern inline" needs to have external linkage,
> which Borland does not do.
>
> However, Borland says that this is okay, because the draft
> *also* says that a function designated inline in one unit
> must be inline in every unit.  Thus, it wouldn't be possible
> for the external linkage to ever be useful.
>
> So the real questions is what is the intent of allowing this
> seemingly contradictory function declaration to exist?  And
> while Borland may technically appear to not be compliant,
> could anyone actually ever come to any harm as a result of it?

It doesn't matter if it is useful -- the draft requires that extern
inline be supported.  That should decide the matter.  Even if this is
not useful, the harm is that Borland's compiler will not handle some
strictly conforming programs.  Goodbye portability.

But in this case it is useful.  Consider

 extern inline int f()
 {
   static int n = 0;
   return ++n;
 }

With the extern, f() refers to the same function in each compilation
unit so f() will return sequential integers regardless of where it is
called from.  Without the extern, f() is a different function in each
compilation unit so there will be a separate sequence returned for
each.


Michael M Rubenstein
---
[ 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                             ]

Please tell me if I misunderstand the situation.

A non-member function declared without a linkage specifier is
automatically extern. If the function is later defined inline, then it
must be defined inlined in every translation unit.

If the function is declared static to begin with, then the subsequent
inline definition is internal to the translation unit. Other translation
units may define it non-inline.

What if the function is a member function? The first declaration is
necessarily extern because a class may not be declared static. So what
happens if the function is defined inline in one translation unit and
non-inline in others?

-Christopher Dunn
(Please respond via e-mail.)
--
Electrical and Computer Engineering
Carnegie Mellon University
cxdunn@ece.cmu.edu
---
[ 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
]

Mike Rubenstein (miker3@ix.netcom.com) wrote:
: But in this case it is useful.  Consider

:  extern inline int f()
:  {
:    static int n = 0;
:    return ++n;
:  }

: With the extern, f() refers to the same function in each compilation
: unit so f() will return sequential integers regardless of where it is
: called from.  Without the extern, f() is a different function in each
: compilation unit so there will be a separate sequence returned for
: each.

Actually, the function being inline does not mean that we would get
different static n variables everywhere anyway.  My current compiler seems
to have the smarts to create a single n if the function is "inline"
without the extern.  It refuses to expand functions with static variables
inline, though.  Also, if you change inline to static, you get more than
one n variable.
---
[ 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
]

In article 41C6@ece.cmu.edu, Christopher Dunn <cxdunn@ece.cmu.edu> writes:
>Please tell me if I misunderstand the situation.

I'll answer according to the current version of the draft standard,
but not all current compilers yet follow all the latest rules.

>A non-member function declared without a linkage specifier is
>automatically extern. If the function is later defined inline, then it
>must be defined inlined in every translation unit.

Yes, but the inline definition must occur before the first use of the function.

>If the function is declared static to begin with, then the subsequent
>inline definition is internal to the translation unit. Other translation
>units may define it non-inline.

Yes, as long as the other defintions are also static or non-extern inline.

>What if the function is a member function? The first declaration is
>necessarily extern because a class may not be declared static. So what
>happens if the function is defined inline in one translation unit and
>non-inline in others?

Member functions of non-local classes always have external linkage.

(A "local class" is one defined in a function block. It can have only
inline functions, and the functions are unavailable outside the block
in which the class is defined.)

There is at most one instantiation of a member function in an entire
program.

---
Steve Clamage, stephen.clamage@eng.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                             ]

In article <4sgbr1$jnp@engnews1.Eng.Sun.COM> clamage@Eng.sun.com (Steve
Clamage) writes:

|> There is at most one instantiation of a member function in an entire
|> program.

1. How can this be?  Wouldn't each inline expansion count as an
instantiation?

2. How can an conforming program tell?

Obviously, there must be only one instantiation of any local static
variables in the entire program, and the implementation must have some
mechanism for always choosing the same instance when the address of the
function is taken, but I don't see why the implementation cannot
instantiate the function itself as many times as it wants.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ 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                             ]

jodle@bix.com (jodle) writes:

>Mike Rubenstein (miker3@ix.netcom.com) wrote:
>:  extern inline int f()
>:  {
>:    static int n = 0;
>:    return ++n;
>:  }
[...]
>Actually, the function being inline does not mean that we would get
>different static n variables everywhere anyway.  My current compiler seems
>to have the smarts to create a single n if the function is "inline"
>without the extern.

If it is true that your compiler creates only a single occurrence of
static variables in inline functions not declared extern, rather than
one for each translation unit, then your compiler does not conform to
the ANSI/ISO C++ committee's draft working paper.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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                             ]

Mark Nelson <markn@tiny.com> wrote:

> Mike Rubenstein wrote:
> >
> > Mark Nelson <markn@tiny.com> wrote:
> >
> > > I'm trying to determine whether some behavior in Borland C++
> > > represents a bug or not.  The draft says that a function
> > > defines as "extern inline" needs to have external linkage,
> > > which Borland does not do. .
>  .
>  .
> > But in this case it is useful.  Consider
> >
> >         extern inline int f()
> >         {
> >           static int n = 0;
> >           return ++n;
> >         }
> >
>
> Borland says they have this covered.  They only create a single
> copy of any static variable in an inline function, regardless
> of how many times the inline function is defined or instantiated.
> They use this as additional ammo for not having to worry about
> whether the inline actually has extneral linkage or not.
>
> I still don't undestand *why* the standard has the definition of
> how "extern inline" should be handled when the mandatory use
> of inline in every definition of the function seems to make it
> a moot point.
>
> Anyone have a clue?

They are not covering it -- they are screwing it up.  The draft
(7.1.1) says that unless you specify extern inline functions are
static.  static functions refer to different functions in unit in
which they appear so they should have different static locals.

Again.  The purpose of extern in an inline definition is to make all
uses of the function in different units refer to the same function.
Without extern the name of an inline function, like any other static
function, refers to a different function in each compilation unit.

Let's give an (untested) example:

t.h:

 inline int f() { static int i; return ++i; }
 extern inline int g() { static int i; return ++i; }
 extern void h();

t.cpp:

 #include <iostream>
 #include "t.h"

 int main()
 {
   cout << f() << '\n';
   cout << g() << '\n';
   h();
   return 0;
 }

t1.cpp:

 #include <iostream>
 #include "t.h"

 void h()
 {
   cout << f() << '\n';
   cout << g() << '\n';
 }

f refers to different functions in the two compilation units, each
with its own copy of the static local variable i, but g refers to the
same function, with one copy of the local variable.  This program
should print out

 1
 1
 1
 2

The fact that Borland doesn't compile inline correctly without extern
doesn't mean that they are right to not allow extern inline.  They
should fix both bugs.


Michael M Rubenstein
---
[ 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
]

jodle@bix.com (jodle) wrote:

> Mike Rubenstein (miker3@ix.netcom.com) wrote:
> : But in this case it is useful.  Consider
>
> :  extern inline int f()
> :  {
> :    static int n = 0;
> :    return ++n;
> :  }
>
> : With the extern, f() refers to the same function in each compilation
> : unit so f() will return sequential integers regardless of where it is
> : called from.  Without the extern, f() is a different function in each
> : compilation unit so there will be a separate sequence returned for
> : each.
>
> Actually, the function being inline does not mean that we would get
> different static n variables everywhere anyway.  My current compiler seems
> to have the smarts to create a single n if the function is "inline"
> without the extern.  It refuses to expand functions with static variables
> inline, though.  Also, if you change inline to static, you get more than
> one n variable.

Your compiler isn't smart -- it's buggy.  I've had some buggy
compilers too, but the the fact that some compilers are wrong doesn't
change what the language means.

Unless extern is specified, an inline function defaults to static and
a static function represents different function in each compilation
unit.  Different functions must have different local static variables.


Michael M Rubenstein
---
[ 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 96Jul17132913@slsvgqt.lts.sel.alcatel.de,
kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
>In article <4sgbr1$jnp@engnews1.Eng.Sun.COM> clamage@Eng.sun.com (Steve
>Clamage) writes:
>
>|> There is at most one instantiation of a member function in an entire
>|> program.
>
>1. How can this be?  Wouldn't each inline expansion count as an
>instantiation?
>
>2. How can an conforming program tell?
>
>Obviously, there must be only one instantiation of any local static
>variables in the entire program, and the implementation must have some
>mechanism for always choosing the same instance when the address of the
>function is taken, but I don't see why the implementation cannot
>instantiate the function itself as many times as it wants.

The "as-if" rule always applies, but I should have said that. If a
valid program could detect that more than one instantiation occurred of
an extern function (inline, non-inline, member, whatever), the
implementation is in error.  If a program can't tell, for practical
purposes there isn't more than one instantiation.

It's kind of like quantum mechanics. Attempting to view detailed behavior
can change that behavior.
---
Steve Clamage, stephen.clamage@eng.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                             ]

clamage@Eng.sun.com (Steve Clamage) writes:

>Christopher Dunn <cxdunn@ece.cmu.edu> writes:
>>If the function is declared static to begin with, then the subsequent
>>inline definition is internal to the translation unit. Other translation
>>units may define it non-inline.
>
>Yes, as long as the other defintions are also static or non-extern inline.

That's not quite correct.  It's OK for a function `f()' to be defined as
static in one translation unit and extern in another.  For example,
the C++ program consisting of the following three translation units
is strictly conforming according to the C++ committee's draft working paper,
I believe.

 // file 1
 static inline void f() {}

 // file 2
 void f() {}

 // file 3
 int main() { return 0; }

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


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

Mark Nelson <markn@tiny.com> writes:

>Mike Rubenstein wrote:
>>
>> Mark Nelson <markn@tiny.com> wrote:
>>
>> > I'm trying to determine whether some behavior in Borland C++
>> > represents a bug or not.  The draft says that a function
>> > defines as "extern inline" needs to have external linkage,
>> > which Borland does not do. .

What do you mean when you say that "Borland does not do" this?
The standard doesn't specify how things are to be implemented.
If you think Borland C++ has a bug, can you give an example of a
C++ program for which you think Borland C++ gives the wrong results?

>>         extern inline int f()
>>         {
>>           static int n = 0;
>>           return ++n;
>>         }
>
>Borland says they have this covered.  They only create a single
>copy of any static variable in an inline function, regardless
>of how many times the inline function is defined or instantiated.

If the function is declared `extern inline', then that is correct
behaviour.  But if the function is declared `inline' without the `extern',
then a conforming C++ compiler must create one copy of `n' for each
translation unit in which `f()' is defined.

>I still don't undestand *why* the standard has the definition of
>how "extern inline" should be handled when the mandatory use
>of inline in every definition of the function seems to make it
>a moot point.

As described above, there is a difference in the semantics of
`inline' and `extern inline', so I don't think the point is moot.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


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