Re: Virtual Destructor - Implication & Specification

* Francis Glassborow:


It seems that Chaud argues, with reference to a paragraph from "The C++
Programming Language", that the language guarantees something it
doesn't. Just to clear that (on-topic misunderstanding) up: as soon as
one's dealing with non-standard extensions, all the standard's behavior
guarantees are void, and furthermore, the language is formally defined
by the standard, not by any book, not even one from the language's
creator. Perhaps a non-standard extension provides most of the
standard's behavior guarantees, but that can't be determined with
reference only to the standard.


That's certainly relevant to Chaud's argument (and I've mentioned it
earlier in the thread), but I don't think it's relevant to topicality.

For example, the C++ standard has nothing to say about static libraries,
either. In the common meaning of the term "library" the standard has
nothing to say about libraries at all except the contents of the C++
standard library. And since the standard refers to various parts of the
standard C++ library as libraries, e.g. the "Numerics library", a
meaning of "library" that's not the common one, it could be a
terminological challenge to introduce anything about libraries.

First of all, but unrelated to your comment, that's a major shortcoming
of a language meant for "programming in the large", and I think that's
worthy of a number of large clc++m threads on its own, but second, and
regarding the quoted statement above, we can't let the standard's
silence about tools mean that we shouldn't discuss tools at all. Hey
you, you there, you mentioned a compiler! Off-topic with you, be gone.


I think a major problem is that the standard is geared towards producing
a C++ /program/. Unix dynamic libraries seem to fit within that model,
but I'm not sufficiently familiar with them to say that they definitely
do fit within that model in all respects. It seems to me that the
language already accommodates Unix dynamic libraries, that only formal
recognition of that fact (if it is) is lacking, but I could be wrong.

However, Windows DLLs go outside the monolithic "program" model of the
standard, providing linkage at a level outside or above the "program":

   Within a DLL, whatever the language supports, e.g. the C++ model:
   * No linkage.
   * Internal linkage.
   * External linkage, type safe (default).
   * External linkage, not type safe ('extern "C"').

   DLL interface (no C++ support):
   * Not exported.
   * Exported by ordinal number (not type safe).
   * Exported by name (type safety or not via language mechanisms).

Something that has C++ external linkage is, as I understand it, visible
in the interface of a Unix dynamic library, but it isn't visible in a
DLL interface unless it's exported. This means that a DLL can contain
e.g. a complete copy of the runtime library, without that copy's
functions and variables being visible outside the DLL. Thus, for DLLs
we're dealing with a level of abstraction not addressed by the standard:
a DLLs interface is a level above C++ linkage.

In addition DLLs have support for per-thread initialization and cleanup,
as well as a very brittle support for per-thread storage, and although
the Boost library supports both threads and per-thread storage,
threading is not currently addressed by the C++ standard. One would
hope that whatever threading support is introduced in C++0x, it will be
compatible with Windows DLLs (which could happen by default if the
support is sufficiently low level). Otherwise a major platform will be
effectively excluded for a wide range of in-practice ways of using the
language.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]