Martin von Loewis <loewis@informatik.hu-berlin.de> writes:

> comeau@panix.com (Greg Comeau) writes:
>
> > Martin von Loewis  <loewis@informatik.hu-berlin.de> wrote:
> > >With older linkers, C++ may be unimplementable.
> >
> > I haven't seen that to be the case yet, assuming one is also
> > allowed to add additional tools.
>
> Here's my top list of things that are 'difficult':

[...]

> - support Unicode in identifiers
>   [problem: linkers may not like symbols with non-ASCII bytes]

Given that the C++ standard reserves all names which contain double
underscores for the implementation, this one should be quite easy. A
simple translation could be from \uxxxx to __uxxxx, which gives a
legal identifier for the linker, but a forbidden identifier for the
user. Of course one has to make sure that the encoding works well with
the rest of the name mangling.

[...]

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

<thp@cs.ucr.edu> wrote in message news:9q5q6l$q9n$1@glue.ucr.edu...
> The C++ Standard requires that inline functions and their static
> locals have a globally unique address.  That's a wonderful feature,
> but how, using standard (i.e., 1975) linker and makefile technology,
> does such a thing get implemented?  Or is there more advanced linker
> technology involved?

The run time library may maintain a map from mangled names (including highly
mangled names of local variables) to functions or objects.  When the address
of such an item is needed, the runtime code can check to see if it is in the
map.  If not, the compiler-generated tentative definition may be inserted
into the map.

Your code:
  extern inline int& foo(){ static int i; return i; }

Compiler generated code (assuming address of foo() is not used)
  extern __some_map_type __ugly_map;
  static int& foo()
  {
     static map__node<int> tentative__i;
     return *(int*)  __ugly_map.FindOrInsert("::foo(){i", &tentative__i);
  }

Actually, this is probably the same thing that a linker with weak symbols is
doing.  I'm not aware of anything in the standard that prevents this "weak"
linking from being deferred to runtime.

This may not be as efficient as you would hope.


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

thp@cs.ucr.edu writes:

> : Recently, the GNU linker was further enhanced to deal with template
> : instantiations and inline functions: by means of "link-once" sections,
> : the linker may eliminate duplicate symbol definitions from multiple
> : object files, again maintaining an arbitrary single definition.
>
> Under this approach, does each .o-file contain a non-inline copy of
> each function whose address is taken?  If so, is an attempt made to
> strip redundant copies out of the final executable?

That is indeed done that way: each function is compiled into its own
linkonce section, and duplicates are eliminated. Of course, you cannot
eliminate duplicates in multiple shared libraries that way: The
dynamic linker will then pick an arbitrary definition from one of the
shared libraries available at run-time.

It turns out that object files can still become huge under this
approach, not because of the inline functions, but because of the
template instantiations (which normally exceed non-inline copies of
inline functions both in size and number). As a result, the final
executable may be much smaller than the sum of all object files.

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                ]

<thp@cs.ucr.edu> wrote in message news:9q5q6l$q9n$1@glue.ucr.edu...
> The C++ Standard requires that inline functions and their static
> locals have a globally unique address.  That's a wonderful feature,
> but how, using standard (i.e., 1975) linker and makefile technology,
> does such a thing get implemented?  Or is there more advanced linker
> technology involved?

No, there is old linker technology involved.  Most linkers still support
Fortran "common blocks" which let you declare extern objects which do
not have to be defined.  This lets you allocate a global to hold the
pointer without specifying which translation unit has the definition.

For linkers which allow multiple conflicting initializations of common
blocks, this is sufficient.  Each translation unit which needs the address
initializes the global with a pointer to a local out-of-line copy of the
function, and the linker picks which of the values is actually used.

Otherwise the choice can be made dynmically.  For example, any use of
"&f" where "f" is inline can be implemented as:

     extern void (*pointer_to_f)();  // really a common block
     static void local_f();          // local out-of-line copy of f

     (pointer_to_f ? pointer_to_f : (pointer_to_f = &local_f))

It doesn't matter which copy is actually used.

(Note that locks would be required in an environment which uses
preemptive threads, but that goes beyond the standard.)


-- Bill Gibbons

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

comeau@panix.com (Greg Comeau) writes:

> Martin von Loewis  <loewis@informatik.hu-berlin.de> wrote:
> >With older linkers, C++ may be unimplementable.
>
> I haven't seen that to be the case yet, assuming one is also
> allowed to add additional tools.

Here's my top list of things that are 'difficult':

- support constructors of global objects. If that sounds easy:
- support constructors of global objects, allowing main() to
  be compiled with the system C compiler.
  [Problem: how to run code before main() starts]
- correctly implement destructor ordering, including constraints
  for atexit
  [Problem: atexit may be restricted to 32 slots]
- guarantee uniqueness of various addresses
  (as discussed in this thread, plus template instantiations,
   plus static variables, plus string literals)
- support Unicode in identifiers
  [problem: linkers may not like symbols with non-ASCII bytes]
- put C library into std::, guarantee that everything is a function
  that should be
  [problem: may need to completely rewrite the system vendor's
   header files]

Most of the problems can be solved indeed, unless you require
interworking with C code. For example, I doubt the atexit problem can
be solved if you simultaneously require that std::atexit is the same
as C's atexit, and that C libraries can be linked into the
application.

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                ]

The C++ Standard requires that inline functions and their static
locals have a globally unique address.  That's a wonderful feature,
but how, using standard (i.e., 1975) linker and makefile technology,
does such a thing get implemented?  Or is there more advanced linker
technology involved?

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                ]

thp@cs.ucr.edu wrote:
> The C++ Standard requires that inline functions and their static
> locals have a globally unique address.  That's a wonderful feature,
> but how, using standard (i.e., 1975) linker and makefile technology,
> does such a thing get implemented?  Or is there more advanced linker
> technology involved?

How do you implement export with standard 1975 linkers   ?

  --   VB

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

thp@cs.ucr.edu writes:

> The C++ Standard requires that inline functions and their static
> locals have a globally unique address.  That's a wonderful feature,
> but how, using standard (i.e., 1975) linker and makefile technology,
> does such a thing get implemented?  Or is there more advanced linker
> technology involved?

In the ELF object file format, a symbol can be declared as "weak",
meaning that the symbol can be defined arbitrarily often, and that the
linker may chose an arbitrary definition. Many compilers use weak
symbols for inline function.

At run time, the dynamic linker is faced with the same issue; the ELF
dynamic linker will chose the first weak definition according to some
specified search order, or a "strong" symbol if it finds one.

Recently, the GNU linker was further enhanced to deal with template
instantiations and inline functions: by means of "link-once" sections,
the linker may eliminate duplicate symbol definitions from multiple
object files, again maintaining an arbitrary single definition.

With older linkers, C++ may be unimplementable. From the C++
standardization point of view, this is not an issue: The linker is
part of the implementation, so it is the responsibility of the vendor
to make sure the linker works correctly. In fact, some C++
implementations bring their own linkers, to avoid problems with the
system linkers.

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:
: thp@cs.ucr.edu writes:

:> The C++ Standard requires that inline functions and their static
:> locals have a globally unique address.  That's a wonderful feature,
:> but how, using standard (i.e., 1975) linker and makefile technology,
:> does such a thing get implemented?  Or is there more advanced linker
:> technology involved?

[...]
: Recently, the GNU linker was further enhanced to deal with template
: instantiations and inline functions: by means of "link-once" sections,
: the linker may eliminate duplicate symbol definitions from multiple
: object files, again maintaining an arbitrary single definition.

Under this approach, does each .o-file contain a non-inline copy of
each function whose address is taken?  If so, is an attempt made to
strip redundant copies out of the final executable?

Thanks,
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 <9q5q6l$q9n$1@glue.ucr.edu>,  <thp@cs.ucr.edu> wrote:
>The C++ Standard requires that inline functions and their static
>locals have a globally unique address.

Correct.

>That's a wonderful feature,

Well, at least it intends to maintain integrity as expected.

>but how, using standard (i.e., 1975) linker and makefile technology,
>does such a thing get implemented?  Or is there more advanced linker
>technology involved?

It might be argued that "advanced" is the wrong word here,
but clearly it needs help, either by a modified linker, or
a tool which conspires with the linker.  Whichever, the
functionality which bubbles up as more practical might be of
merging duplicates, or controlling where the (perhaps arbitrary)
"ownership" of the inline function should be.  As long as the
"compiler system" is intact, this should be possible even with
1975 linkers :)
--
Greg Comeau         export ETA: December
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 <9qfgrj$g6$1@glue.ucr.edu>,  <thp@cs.ucr.edu> wrote:
>Martin von Loewis <loewis@informatik.hu-berlin.de> wrote:
>: thp@cs.ucr.edu writes:
>:> The C++ Standard requires that inline functions and their static
>:> locals have a globally unique address.  That's a wonderful feature,
>:> but how, using standard (i.e., 1975) linker and makefile technology,
>:> does such a thing get implemented?  Or is there more advanced linker
>:> technology involved?
>
>[...]
>: Recently, the GNU linker was further enhanced to deal with template
>: instantiations and inline functions: by means of "link-once" sections,
>: the linker may eliminate duplicate symbol definitions from multiple
>: object files, again maintaining an arbitrary single definition.
>
>Under this approach, does each .o-file contain a non-inline copy of
>each function whose address is taken?  If so, is an attempt made to
>strip redundant copies out of the final executable?

I don't know the approach taken but the linker that Martin mentions,
but it's surely implementable that each won't contain a non-inline copy.
For instance, Comeau C++ can be configured to allow an object file
inline function ownership model w.r.t. this, and it works similarly
to an object file template instantiation ownership model we can also use.
--
Greg Comeau         export ETA: December
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 <j4669giyhz.fsf@informatik.hu-berlin.de>,
Martin von Loewis  <loewis@informatik.hu-berlin.de> wrote:
>With older linkers, C++ may be unimplementable.

I haven't seen that to be the case yet, assuming one is also
allowed to add additional tools.

>From the C++
>standardization point of view, this is not an issue: The linker is
>part of the implementation, so it is the responsibility of the vendor
>to make sure the linker works correctly. In fact, some C++
>implementations bring their own linkers, to avoid problems with the
>system linkers.

Replace "the linker" with "the linker and whatever else
the vendor can come up with" :)
--
Greg Comeau         export ETA: December
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                ]