NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/cplus/18513

Text File | 1992-12-29 | 3.2 KB | 72 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!taumet!steve
From: [e-mail] (Steve Clamage)
Subject: Re: Sizeof and Virtual functions
Message-ID: <[e-mail]>
Organization: TauMetric Corporation
References: <[e-mail]>
Date: Tue, 29 Dec 1992 21:15:05 GMT
Lines: 61

[e-mail] (Suresh Thennarangam - Research Scholar) writes:

>One of the things that distinguishes virtual functions from other
>normal member functions of a class is that some compilers that I
>know of, store an extra pointer that is  probably used to index
>a vector table...

>Is this an implementation-specific issue only ?

Yes.  A pointer to an array of pointers to the virtual member functions
of a class is the usual implementation method.  It is not required by
the language, but is easy to implement and efficient at run time.

>A C++ programmer should  not have to know of these ugly little pointers
>lurking around in his structures.

Right, but see below.

>These monsters add 4 bytes each
>(on a 32 bit machine) to your structure; sizeof no longer tells the
>truth and seemingly innocent  actions like fwrite'ing such structures
>to  a file can quickly assume rather pernicious connotations.

'sizeof' better tell the truth.  It must report the amount of storage
required by an object of that type.  If the object has extra data added
by the compiler, that is part of its size.  This is conceptually no
different from the padding a compiler might add to get suitable alignment
of individual members.  You are not allowed to assume the size of any
type other than "char" (which is always 1 by definition).  In C as well
as C++, struct types might have a size different from that calculated
by adding the size of each member.

>If I write classes with virtual functions to interpret and save
>file formats like XWD, TIFF, GIF , etc and innocently use sizeof()
>to calculate the size and write to a file I will be writing along
>addresses in my machines data area. Obviously, no one will be able
>to read those files either. Of course an experienced C++ programmer
>would know how work around this problem  but this just an illustration.

You are ignoring a critical part of C++.  Objects of class type must be
constructed.  Reading data from a file into raw memory is not in general
the same as constructing an object.  The exact layout of members of a
class is not promised in general either, so blindly overwriting a class
object is likely to produce poor results in general.

If you have an object of class type which has no base classes, no
virtual member functions, no members of pointer type, and no static data
members, you should be able to get away with a bit-copy to external
storage and bit-copy back.

A C++ class is an abstraction mechanism.  This means you give up
intimate control of the representation in exchange for the ability to
deal with object using a portable, high-level approach.

C++ allows control of pure data types in exactly the same way as C.
You can, for example, create a C-style struct containing just the data
of interest, and derive a class from it which has all the functionality
you want.  You can still write and read back the data as you would in C.
--

Steve Clamage, TauMetric Corp, [e-mail]