Non-overloadable non-inline function definitions in different translation units
Asked Answered
P

1

4

Let's say I have 2 TUs with 2 non-inline function definitions with external linkage which differ only in their return types.
Which paragraph(s) my program violates?
[basic.def.odr]/4 says:

Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program outside of a discarded statement; no diagnostic required.

But

  1. This paragraph says "that is odr-used" which may or may not be the case.
  2. How do I tell if I define the same non-inline function in different TUs, after all? [over.dcl]/1 speaks about the same scope.
Phototopography answered 25/2, 2020 at 20:11 Comment(0)
P
7

I believe you're looking for: [basic.link]/9:

Two names that are the same ([basic.pre]) and that are declared in different scopes shall denote the same variable, function, type, template or namespace if

  • both names have external or module linkage and are declared in declarations attached to the same module, or else both names have internal linkage and are declared in the same translation unit; and
  • both names refer to members of the same namespace or to members, not by inheritance, of the same class; and
  • when both names denote functions or function templates, the signatures ([defns.signature], [defns.signature.templ]) are the same.

If multiple declarations of the same name with external linkage would declare the same entity except that they are attached to different modules, the program is ill-formed; no diagnostic is required. [ Note: using-declarations, typedef declarations, and alias-declarations do not declare entities, but merely introduce synonyms. Similarly, using-directives do not declare entities. — end note ]

And [basic.link]/11:

After all adjustments of types (during which typedefs are replaced by their definitions), the types specified by all declarations referring to a given variable or function shall be identical, except that declarations for an array object can specify array types that differ by the presence or absence of a major array bound ([dcl.array]). A violation of this rule on type identity does not require a diagnostic.

And [defns.signature]:

⟨function⟩ name, parameter-type-list ([dcl.fct]), and enclosing namespace (if any)

The return type isn't part of the signature, so you're violating the rule that same signature means same entity.


Generally speaking, all discussions of scope and name lookup in the standard are pretty broken until Davis "The Hero We Don't Deserve" Herring's work goes through.

Pigling answered 25/2, 2020 at 20:19 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.