Markus Schaaf wrote:
>
> If you never use the address of such an object, and it has
> internal linkage, the compiler could make it zero-sized,
> i.e. drop it except for the side-effects. Why to render
> this difficult for no reason?

It's not at all difficult. If you don't every do anything that depends
on the size of the object then the compiler is free to give it any size
that works well, including zero.

>
> It seems to me, that this may be a matter of wording in
> the standard, rather than really changing the programming
> language. If this is an issue at all. I don't know exactly.
>

This is known as the "as if" rule: the compiler must generate code that
works as if it had followed the rules exactly. If a change from the
details of the rules won't be detected by the program, then that change
is okay.

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

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

Markus Schaaf <m.schaaf.exp-jun2001@gmx.de> wrote in message
news:9csv8p$f6s5r$1@ID-3706.news.dfncis.de...
> I feel a bit of sympathy for Dennis' idea of zero-sized
> objects, so I'll try.
>
> Imagine you have a class that does some magic with c'tor
> and d'tor (e.g. locking a file or owning a mutex), but
> hasn't any data members. In your code you will have objects
> of that type here and there. So the compiler must allocate
> storage for these objects, for the standard's sake.
>
> If you never use the address of such an object, and it has
> internal linkage, the compiler could make it zero-sized,
> i.e. drop it except for the side-effects. Why to render
> this difficult for no reason?

What is sizeof(ThisSometimesZeroSizedSometimesNotClass)? Presumably, you'd
have to go with the non-zero value.

I think one of the main goals of a new C++ standard should be to make the
language more intuitive by reducing unexpected behaviours and special cases.
Whilst I like the motives behind both the existing zero sized base class
optimization and the proposed zero sized object, they have unintuitive
features:

1. sizeof(SomeEmptyClass) has a constant non-zero value. So, it is
unintuitive that an object of SomeEmptyClass sometimes takes up less space
than that. It breaks the intuitive relationship of

sizeof(Base1) + sizeof(Base2) <= sizeof(Derived)

2. Aforementioned problems with taking address of zero-sized objects.
3. How will references be implemented for zero-sized objects? Most (all?)
compilers implement references as pointers.

I have a counter proposal: leave out zero-size objects but replace the
optional empty base class optimization with a mandatory language feature:

class A {/* ... */} = 0;   // "pure class"

Such a class cannot be instantiated as it stands. You must derive from it to
use it. So, it has the same effect as a pure virtual function in the class.
The difference is that, if the class has no virtual functions or data
members, it will never add any size to a class lattice that contains it.

Incidentally, a lot of what you could do with a zero-size object you can get
by using static member functions and never actually instantiating any
objects. A good example of where zero-size objects *would* be useful is when
implementing a functor.

Something I include for your amusement only. It is not a general solution
and I suspect it violates a large number of rules:

class EmptyClass
{
public:
    // ...
    void* operator new(size_t)
    {
        return (void*)1;
    }
    void operator delete(void*){}
};

int main()
{
    EmptyClass* pec = new EmptyClass;
    delete pec;
}

;-)

Regards

--
Garry Lancaster
Codemill Ltd
mailto: glancaster@*nospamplease*codemill.net
Visit our web site at http://www.codemill.net

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

"Harvey Taylor" <het@despam.autobahn.mb.ca> wrote:

> I don't know what Dennis has in mind [please do elucidate, Dennis]

I feel a bit of sympathy for Dennis' idea of zero-sized
objects, so I'll try.

Imagine you have a class that does some magic with c'tor
and d'tor (e.g. locking a file or owning a mutex), but
hasn't any data members. In your code you will have objects
of that type here and there. So the compiler must allocate
storage for these objects, for the standard's sake.

If you never use the address of such an object, and it has
internal linkage, the compiler could make it zero-sized,
i.e. drop it except for the side-effects. Why to render
this difficult for no reason?

It seems to me, that this may be a matter of wording in
the standard, rather than really changing the programming
language. If this is an issue at all. I don't know exactly.

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