Re: What Standard says on declared only symbols
On Oct 23, 12:04 pm, Adam Badura <abad...@o2.pl> wrote:
Lets assume I have declared a symbol (lets say, a function "void
f()") but never defined it as well as never used it. All compilers
that I have worked with do not make any problems, they just ignore
"f". But do Standard makes any guarantee on that? Or is such program
not well formed?
No, only (non-pure) virtual and inline function declarations - require
a corresponding function definition be provided in every case.
Otherwise, the set of functions that a C++ program must define - is
the same set of functions that the program had to declare - in order
to be well-formed in the first place. In other words, if a particular
function did not have to be declared, then that same function does not
have to be defined anywhere in the program.
So to answer the question: because f()'s declaration is not inline, is
not virtual, and is not needed for the program to compile successfully
- the answer is "no": the absence of a definition to match f()'s
declaration, does not mean that the program is ill-formed.
This question arose from a simple problem. I had a template
container (TreeInfo). I wanted to make it serializable (by inheriting
from my own IWritable interface). The interface introduced two (pure
virtual) functions "load" and "save". I wrote them for the TreeInfo
assuming the contained type was serializable as well. In case the
contained type was not serializable the code was incorrect (however
syntax was OK). But I thought that if the contained type was not
serializable then no one will ever serialize the container and thous
"load" and "save" would not be used and thous no error would occur
during compilation. However it didn't work this way. (Maybe it is
compiler specific, this time I used MSVC 8.0.) It seems that since
"load" and "save" are virtual they must be present in vtable and thous
must be compiled even if not used.
The C++ Standard actually requires load() and save() to be defined in
this case:
"A virtual function declared in a class shall be defined, or declared
pure in that class, or both; but no diagnostic is required."[?10.3/8]
And this requirement makes a lot of sense. After all, a call to a
virtual function is resolved only at runtime - and is resolved each
time the call is made. And the overloaded class method chosen to
handle the call upon each invocation - may well vary (since the choice
is dependent on the dynamic type of the object used to make the call).
Under these circumstances, a C++ compiler would have a very difficult
time to prove that a particular virtual method is "unused." At best, a
C++ compiler might be able to show that no objects of a particular
class were allocated. But the compiler would not be able prove that no
objects were allocated (because such an allocation is possible). At
any rate, there would be very little to gain by figuring out whether a
virtual method is "used". Therefore, the C++ Standard effectively
requires an implementation to assume that every virtual function is
used by the program.
I try to solve the problem somehow. I can make just a
TreeInfoSerializable which will inherit TreeInfo as well as IWritable
and expect my users to use either one as needed. I could try some
tricks with template metaprogramming (this seems most elegant however
is likely to be worst because the code is in a large project and this
could cause need for a lot of changes).
The polymorphism of a "TreeInfo" is implemented with a template, while
the polymorphism of "IWritable" class is implemented through
inheritance. So perhaps an intermediate "bridge" class that would map
inheritance to the compile-time polymorphism of templates could work
as a solution.
The basic plan would be to subclass IWritable with a class template,
call it "TWritable" (or some such name). TreeInfo would then inherit
from TWritable<TreeInfo> (instead of from IWritable directly).
TWritable would define load() and save() methods (so the current link
error would be fixed). Furthermore TWritable's implementations of
load() and save() could be as simple as calling (non-virtual) methods
defined in the TreeInfo<> class template to serialize and unserialize
the TreeInfo object. The TreeInfo class template could, in turn,
ensure that these methods would be declared only when the TreeInfo<>
specialization had been instantiated with a serializable type.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]