[To the moderator: I don't know where to redirect followups; perhaps
comp.lang.c++.flame.wars.ptr.arithm ?]

[[Moderator replies: I've redirected followups to comp.lang.c++. -fjh]]

John Calcote wrote:
>
> Trevor Yann wrote in message <343C233D.8E1DD26C@vet.com.au>...
>
> >Any programs that use pointer arithmetic are buggy programs.

I don't think we need to answer such stupid statements.

> This is a rather broad and generic statement, isn't it? After all, don't we
> use pointer arithmetic when we index an array? Okay, granted, the compiler
> is doing some checking for us in this case...but not very much!

Just to clarify this debate
---------------------------

Pointer arithmetic vs index in an array and bound checking are
orthogonal issues. Cheching is an efficiency and security issue,
while ptr arithmetic/array index is a style issue.

The fact that most C/C++ implementation don't do bound checking
and that other languages where bound checking is mandatory don't
support ptr arithmetic doesn't means anything except that some
people who wants checking don't like the ptr arithmetic style
and checking for ptr arithmetic can be less efficient than for
array index.

A pointer has an advantage over an index because it has a type;
if you have an int, you can do many stupid things with it
(for example, computing the product of two index in the same
array). You can also use an index in an array of int into
an array of points. I you use a pointer, you'll get a type
mismatch.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Chip Salzenberg wrote:
>
> For purposes of memory allocation, it might be useful to assert that
> sizeof(Derived) == sizeof(Base).

I'm afraid I can't see how. Relying on such an assertion sounds
kludgish, to me. And why would one ever want to design a hierarchy where
no derived classes can add data members?

I suppose there might be a good case, and I'm too dim to see it. :)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Chip Salzenberg <chip@rio.atlantic.net> writes:

> According to Mark Wilden <Mark@mwilden.com>:
> >Valentin Bonnard wrote:
> >> I have never used sizeof on an abstract class, I usually you don't.
> >> But it makes sens to ask its size.
> >
> >I was trying to think of a case where this would be useful, but I
> >couldn't. Can you?

No, I can't. But the concept of size makes sens; you just don't
use it in practice.

> For purposes of memory allocation, it might be useful to assert that
> sizeof(Derived) == sizeof(Base).

This is never garantied byt the std. In other words, your code
relying on that won't be portable.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard wrote:
I have never used sizeof on an abstract class, I usually you don't.
But it makes sens to ask its size.

I was trying to think of a case where this would be useful, but I
>couldn't. Can you?
--------

While evaluating the implementation of a class hierarchy, it might be
useful to known what the contributions to the size of concrete objects
are.  This would input into optimizing.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Trevor Yann wrote in message <343C233D.8E1DD26C@vet.com.au>...

>Any programs that use pointer arithmetic are buggy programs.

This is a rather broad and generic statement, isn't it? After all, don't we
use pointer arithmetic when we index an array? Okay, granted, the compiler
is doing some checking for us in this case...but not very much!

>Generally arrays cannot be treated polymorphically. The compiler should
>be able to diagnose the problem here in a simlar way to the detection of
>use of incomplete types.


This is a much better way to say it. Scott Meyers, in his book Effective
C++, makes the same statement very concisely when he says, (paraphrasing)
"...arrays and polymorphism don't mix and never will..."

John Calcote
Directory Services
Novell, Inc.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Abstract classes don't seem to qualify as incomplete types as defined in
the draft standard.

It appears that in some ways an abstract class should be treated like an
incomplete type:

given
 class X
 {
 public:
  int foo() = 0;
 };

sizeof(X) is not meaningful - there can never be an instance of the
class. In addition pointer arithmetic is not meaningful for pointers to
objects of class X.

Any programs that use pointer arithmetic are buggy programs.

e.g.
 class Y : public X
 {
 public:
  int foo() {return x;}
 private:
  int x;
 };

 X* p = new Y[2];

 p[1].foo();

the call to p[1].foo() is a bug.

Generally arrays cannot be treated polymorphically. The compiler should
be able to diagnose the problem here in a simlar way to the detection of
use of incomplete types.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Trevor Yann wrote:

> Abstract classes don't seem to qualify as incomplete types as defined in
> the draft standard.

No they don't.

> It appears that in some ways an abstract class should be treated like an
> incomplete type:
>
> given
>         class X
>         {
>         public:
>                 int foo() = 0;
>         };
>
> sizeof(X) is not meaningful - there can never be an instance of the
> class.

Of course you can ! Otherwise you wouldn't be able to construct
derived class objects (a derived object is constructed by first
constructing all its base and member classes). In practice you
just never use instances of abstract base classes.

I have never used sizeof on an abstract class, I usually you don't.
But it makes sens to ask its size.

> In addition pointer arithmetic is not meaningful for pointers to
> objects of class X.

> Generally arrays cannot be treated polymorphically.

That's correct. A good compiler could emmit a warning (mine
doesn't).

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

On 09 Oct 97 09:01:53 GMT, Trevor Yann <TYann@vet.com.au> wrote:

>Abstract classes don't seem to qualify as incomplete types as defined in
>the draft standard.

Right.

>It appears that in some ways an abstract class should be treated like an
>incomplete type:
>given
> class X {
> public:
>  int foo() = 0;
> };
>
>sizeof(X) is not meaningful - there can never be an instance of the
>class. In addition pointer arithmetic is not meaningful for pointers to
>objects of class X.

True enough.

>Any programs that use pointer arithmetic are buggy programs.
>e.g.
> class Y : public X {
> public:
>  int foo() {return x;}
> private:
>  int x;
> };
>
> X* p = new Y[2]; // <===
>
> p[1].foo();
>
>the call to p[1].foo() is a bug.

But that is so whether or not Y is an abstract class. The marked line
that allocates the array is a bug waiting to happen in any event.
Defining abstract classes to be incomplete types doesn't help this
problem.

OTOH, if abstract classes were defined to be incomplete types, we
would have the inconsistency of allowing some, but not all, incomplete
classes to be base classes. Extending the previous example:

class Z; // not defined yet
class A : public Z { ... }; // error, because Z is incomplete
class B : public X { ... }; // ok, even though X is incomplete

You would need a new rule to explain why B is ok but not A. Maybe
something like "An incomplete type cannot be used as a base class
unless it is an abstract class." I don't see this as an improvement.

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>>>> "TY" == Trevor Yann <TYann@vet.com.au> writes:

TY> Abstract classes don't seem to qualify as incomplete types as defined in
TY> the draft standard.

Indeed, they are not.

TY> It appears that in some ways an abstract class should be treated like an
TY> incomplete type:

TY> given
TY>  class X
TY>  {
TY>  public:
TY>   int foo() = 0;
TY>  };

TY> sizeof(X) is not meaningful - there can never be an instance of the
TY> class.

Indeed, but this is not enough a reason to introduce a confusion.

TY> In addition pointer arithmetic is not meaningful for pointers to
TY> objects of class X.

[...]

TY> Generally arrays cannot be treated polymorphically. The compiler should
TY> be able to diagnose the problem here in a simlar way to the detection of
TY> use of incomplete types.

This has nothing to do with abstract classes. It is true as well of
any class used polymorphically.

Best Regards!

--
Marc Girod         Nokia Telecommunications  INS/IPS/MS/NOMA
Valimo 1/2         P.O. Box 315              Phone:  +358-9-511 63331
00380 Helsinki     00045 NOKIA Group         Fax:    +358-9-511 63310
Finland                                      marc.girod@ntc.nokia.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

According to Mark Wilden <Mark@mwilden.com>:
>Valentin Bonnard wrote:
>> I have never used sizeof on an abstract class, I usually you don't.
>> But it makes sens to ask its size.
>
>I was trying to think of a case where this would be useful, but I
>couldn't. Can you?

For purposes of memory allocation, it might be useful to assert that
sizeof(Derived) == sizeof(Base).
--
Chip Salzenberg          - a.k.a. -           <chip@pobox.com>
        "He's Mr. Big of 'Big And Tall' fame."  // MST3K
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]