«

I just read this in the description of how C++ is supposed to be
implemented:

"All external object and function references are resolved. Library
components are linked to satisfy external references to functions and
objects not defined in the current translation. All such translator output
is collected into a program image which contains information needed for
execution in its execution environment."

What I'm wondering is what exactly I'm supposed to understand that to mean.
Typically when I think of linking, it means arranging different parts of
the object code so that symbols can be resolved to relative memory
locations within the resulting assembly. The standard doesn't give a clear
definition of "library", nor does it give a very clear notion of "linking".
How do others read that paragraph?
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

Steven T. Hatton wrote:

> The standard doesn't give a clear definition of "library", nor does
> it give a very clear notion of "linking". How do others read that
> paragraph?

The standard does not care about that. Each operating system and family of
tools can have his own notions about how linking is done and librarys are
stored and handled.

You can view a library, in the linking sense, just as a couple of object
files stored togheter in some way.

Code can be linked by resolving symbols to relative or absolute adresses, to
references to symbols in dynamic loading libraries... Or can be not
resolved to any type of address, delaying that to loading or run time.

--
Salu2

Steven T. Hatton wrote:
> I just read this in the description of how C++ is supposed to be
> implemented:

That's not how it's supposed to be implemented. That's the compilation
model that the standard is based on. Different compilation models are
perfectly acceptable, as long as they produce the same results. For
example, many compilers do preprocessing as an integral part of the rest
of the compilation, not as a separate phase.

>
> "All external object and function references are resolved. Library
> components are linked to satisfy external references to functions and
> objects not defined in the current translation. All such translator output
> is collected into a program image which contains information needed for
> execution in its execution environment."
>
> What I'm wondering is what exactly I'm supposed to understand that to mean.
> Typically when I think of linking, it means arranging different parts of
> the object code so that symbols can be resolved to relative memory
> locations within the resulting assembly. The standard doesn't give a clear
> definition of "library", nor does it give a very clear notion of "linking".
> How do others read that paragraph?

It's deliberately vague, to avoid unnecessary contraints. Your reading
is a reasonable one, and it's how most implementations handle it.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Pete Becker wrote:

> Steven T. Hatton wrote:
>> I just read this in the description of how C++ is supposed to be
>> implemented:
>
> That's not how it's supposed to be implemented. That's the compilation
> model that the standard is based on. Different compilation models are
> perfectly acceptable, as long as they produce the same results. For
> example, many compilers do preprocessing as an integral part of the rest
> of the compilation, not as a separate phase.

That was a bad choice of wording on my part. I stand corrected. It is a
description of an abstract machine which defines the behaviors required of
an implementation. With the exception of where the Standard specifically
states that the implementation may deviate. If I read the wording
correctly, it is possible for an implementation to execute the same program
with the same starting conditions, and produce different results each run.
It is for this reason that the abstract machine is said to be
non-deterministic.

I guess that has to do with things such as the order of evaluation of
expressions in a function call argument list. Stroustrup commented on this
with words similar to 'I've been told this is done for purposes of
performance.' Which makes me wonder if he really buys the argument. I
wonder what the cost/benefit ratio is for that.

http://www.gotw.ca/gotw/056.htm

>> "All external object and function references are resolved. Library
>> components are linked to satisfy external references to functions and
>> objects not defined in the current translation. All such translator
>> output is collected into a program image which contains information
>> needed for execution in its execution environment."
>>
>> What I'm wondering is what exactly I'm supposed to understand that to
>> mean. Typically when I think of linking, it means arranging different
>> parts of the object code so that symbols can be resolved to relative
>> memory
>> locations within the resulting assembly. The standard doesn't give a
>> clear definition of "library", nor does it give a very clear notion of
>> "linking". How do others read that paragraph?
>
> It's deliberately vague, to avoid unnecessary contraints. Your reading
> is a reasonable one, and it's how most implementations handle it.

What I'm trying to get at is what the abstract notion of linking, and
library are. I guess what the paragraph essentially means is that the
processor should have some means of retrieving or modifying the value of an
externally referenced object, or calling an externally referenced function.
This linking could be done explicitly and immutably in the final phase in
the described translation, or it could be delayed until some later time,
but storing sufficient information to resolve the linkage in the future.
That could entail anything from dynamically loadding and linking, to
communicating with another process on a remote system which executes the
function, or provides the variable.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

Steven T. Hatton wrote:
>
> What I'm trying to get at is what the abstract notion of linking, and
> library are.

There is no abstract notion. These terms refer to whatever the
implementation does. Again: it's deliberately vague. Don't try to force
a detailed meaning on it.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Pete Becker wrote:

> Steven T. Hatton wrote:
>>
>> What I'm trying to get at is what the abstract notion of linking, and
>> library are.
>
> There is no abstract notion. These terms refer to whatever the
> implementation does. Again: it's deliberately vague. Don't try to force
> a detailed meaning on it.

I disagree about there being an abstract notion communicated in the
paragraph. To force a detailed meaning would not be to understand the
abstraction. See the signature. Abstraction only happens when there are
multiple examples of the underlying pattern. Therefore, it is useful to
formulate thought experiments to examine what circumstances actually to
satisfy the essential conditions to fit the abstraction class. It's an
iterative process of refinement. What is abstracted from the concrete
example can be designated as a form of symmetry. See, for example, Hermann
Weyl's _Symmetry_.

The authors of the paragraph I quoted probably did not have concepts of
object oriented programming in mind, and may well not have had dynamic
linking in mind at all. I suspect that when it was written, and in the
context it was written, it was not considered intentionally vague, it just
stated facts as they were.

Consider the possibility of modules which are similar to classes in their
protection mechanism, and that they can be instantiated once per program,
i.e., singletons. They would however share some characteristics of
namespaces, such as suport for `using' directives and declarations. They
would be primarily intended to group related program units into dynamicly
loadable libraries. Their names could be used to avoid ODR problems, as
could their data hiding features. Having the instantiability of a class
would enable the use of RAII to perform load-time initialization such as
starting a thread, loading data, obtaining resources, etc, and unload-time
shutdown actions, such as stopping the thread, saving data, freeing
resources. Of course some of the resources might be other modules. Since
these would present a clearly defined interface to their external
environment, they would probably serve well as distributed modules in the
sense of EJB, or CORBA.

But I repeat myself.

You might find this interesting. It's a proposal to actually change the
wording of the paragraph in the C++ Standard to better address issues of
creating dynamic linking. Obviously _someone_ thought the wording of that
paragraph is important, and has bearing on the topic.

http://www.open-std.org/jtc1/sc22/wg...rogram%20Model
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

> You might find this interesting. It's a proposal to actually change the
> wording of the paragraph in the C++ Standard to better address issues of
> creating dynamic linking. Obviously _someone_ thought the wording of that
> paragraph is important, and has bearing on the topic.


> http://www.open-std.org/jtc1/sc22/wg.../n1496.html#Pr...

Yes, it was quite interesting. Thanks.

In response, I wrote the following blogger on the history of linkage.

http://distributed-software.blogspot...sms-and-z.html

I did so to avoid confusing "Z++ as a product" with "Z++ as an
abstraction for research". Researchers can see how C++ can be extended
towards a more abstract system programming language, with almost no
learning curve for a C++ engineer. The key is the mentality that "we do
not think about some one or more particular things".

Some of my views on an abstract software devemopment languages are:

http://distributed-software.blogspot...-abstract.html
http://distributed-software.blogspot...sable-for.html
http://distributed-software.blogspot...eudo-code.html

Since these will result in discussions towards correcting and extending
C++, I also created a user group for such discussions. That way, we can
discuss future issues without bothering those who need coding help
based on current standard. Admittedly, mentioning any flaw in the
standard seems like a religious matter, when posted in this group.

http://groups-beta.google.com/group/...Z?lnk=li&hl=en

I certainly appreciate the issues that you bring up. That was the
encouragement to create the new group. I hope my posting in no-way is
offensive. It is just a reaction to events.

BTW, I cannot release the source code due to the underlying theory in
the design of the virtual processor. But the binaries will always be
freely available to the public.

Regards,
Z.

Steven T. Hatton wrote:

>
> You might find this interesting. It's a proposal to actually change the
> wording of the paragraph in the C++ Standard to better address issues of
> creating dynamic linking. Obviously _someone_ thought the wording of that
> paragraph is important, and has bearing on the topic.
>
> http://www.open-std.org/jtc1/sc22/wg...rogram%20Model

You might find it interesting to check the name of the author of that
paper. And note that I didnt' say that the wording of those paragraphs
isn't important. I said that it's vague, and deliberately so.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Pete Becker wrote:

> Steven T. Hatton wrote:
>
>>
>> You might find this interesting. It's a proposal to actually change the
>> wording of the paragraph in the C++ Standard to better address issues of
>> creating dynamic linking. Obviously _someone_ thought the wording of
>> that paragraph is important, and has bearing on the topic.
>>
>>
http://www.open-std.org/jtc1/sc22/wg...rogram%20Model
>
> You might find it interesting to check the name of the author of that
> paper. And note that I didnt' say that the wording of those paragraphs
> isn't important. I said that it's vague, and deliberately so.

I'm not sure what the history of the paragraph is. It seems to have
originated in ANSI C, or perhaps ever earlier. The documentation that
descended from USL's documentation and implementation goes into extensive
detail in discussing the meaning of that paragraph. The wording may have
become vague over the years due to the changing context. It is probably
the case that it has been intentionally left unspecific in subsequent
revisions of the document.

One more thought on the original paragraph:

"I have reluctantly come to accept that some system-related issues would
have been better handled within C++. System-related issues, such as
dynamic linking of classes and interface evolution do not logically belong
in a language and language-based solutions are not preferable on technical
grounds. However, the language provides the only common forum in which a
truly standard solution can become accepted."

This may be one consequence of leaving things vague:

//================================================== ===========================
/**
* @file streams.h
*
* streams.h,v 1.34 2005/05/17 13:06:22 ******** Exp
*
* @author ******* ********
*
* This file contains the portability ugliness for the Standard C++
* Library. As implementations of the "standard" emerge, this file
* will need to be updated.
*
* This files deals with the streams includes.
*
*
*/
//================================================== ===========================
http://www.cs.wustl.edu/~schmidt/ACE...lobal_Macros.h

To be fair, the ACE developers acknowledge the amount of macro hackery is
less than idea. They claim it is/was necessary for portability between
"implementations".




--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

Steven T. Hatton wrote:
> Pete Becker wrote:
>
>
>>Steven T. Hatton wrote:
>>
>>
>>>You might find this interesting. It's a proposal to actually change the
>>>wording of the paragraph in the C++ Standard to better address issues of
>>>creating dynamic linking. Obviously _someone_ thought the wording of
>>>that paragraph is important, and has bearing on the topic.
>>>
>>>
>
> http://www.open-std.org/jtc1/sc22/wg...rogram%20Model
>
>>You might find it interesting to check the name of the author of that
>>paper. And note that I didnt' say that the wording of those paragraphs
>>isn't important. I said that it's vague, and deliberately so.
>
>
> I'm not sure what the history of the paragraph is. It seems to have
> originated in ANSI C, or perhaps ever earlier. The documentation that
> descended from USL's documentation and implementation goes into extensive
> detail in discussing the meaning of that paragraph. The wording may have
> become vague over the years due to the changing context. It is probably
> the case that it has been intentionally left unspecific in subsequent
> revisions of the document.

The words you're talking about are in the C++ Standard. The C++
Standard's Committee wrote them, drawing on experience with the C
language standard. The words are deliberately vague, to avoid imposing
unnecessary restrictions.

Since you insist that there's an abstraction, here it is: compilation
units get translated somehow into something, and eventually those
somethings get linked with other stuff, called libraries, to create an
executable file.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)