technical correctness 2

[PaulR]

Many valid points I have raised have gone unanswered and dismissed
even though I support my opinions with extracts from the C++
standards.

The latest points being those raised in this message:
http://groups.google.com/group/comp.lang.c++/msg/746044473c191d29

It seems the one insult I made has provoked a hell of a lot of
hostility. But I would like to make it clear that my insult was
delivered in a light hearted way to draw attention. It was nothing
like the deep rooted hostile and nasty insults I seem to be getting
bombarded with by these so called proffessionals.

If I have left any replies unanswered in my other thread , please
excuse me but I do not choose to discuss with people who mess with
your accounts and email address in a deliberate attempt to cause harm.

As I said in my initial discussion if we have no repsect for technical
correctness what is the point of these discussion groups.
A group of bullies who can do nothing more than dismiss an individual
as a troll, does not constitute technical correctness.

 

[Ian Collins]

Many valid points I have raised have gone unanswered and dismissed
even though I support my opinions with extracts from the C++
standards.

You either quote form the standard (there is only one) without
comprehending, or deliberately misinterpret the wording to provoke
argument. If you were to take the time to underhand the document,
people might be willing to engage with you.

 

[Paul]

You either quote form the standard (there is only one) without
comprehending, or deliberately misinterpret the wording to provoke
argument. If you were to take the time to underhand the document, people
might be willing to engage with you.

I would like to draw your attention the the following link:
http://www.open-std.org/jtc1/sc22/wg21/
This page contains more than one standard that applies applies to the C++
programming language.

Also you make accusations that I misinterpet the standards yet you have
provided no evidence to support this.
This seems like nothing more than an unjustified barrage of hostility.

 

[Ian Collins]

I would like to draw your attention the the following link:
http://www.open-std.org/jtc1/sc22/wg21/
This page contains more than one standard that applies applies to the
C++ programming language.

Wow, your lack of understanding is even greater than I had assumed.
Committee working papers aren't a standard.

The current C++ standard is available from

http://webstore.ansi.org/RecordDetail.aspx?sku=BS+ISO/IEC+14882:2003

Also you make accusations that I misinterpet the standards yet you have
provided no evidence to support this.

You have already provided more than enough evidence, I don't think there
is more to add.

This seems like nothing more than an unjustified barrage of hostility.

Pot, kettle?

 

[Sjouke Burry]

Many valid points I have raised have gone unanswered and dismissed
even though I support my opinions with extracts from the C++
standards.

The latest points being those raised in this message:
http://groups.google.com/group/comp.lang.c++/msg/746044473c191d29

It seems the one insult I made has provoked a hell of a lot of
hostility. But I would like to make it clear that my insult was
delivered in a light hearted way to draw attention. It was nothing
like the deep rooted hostile and nasty insults I seem to be getting
bombarded with by these so called proffessionals.

If I have left any replies unanswered in my other thread , please
excuse me but I do not choose to discuss with people who mess with
your accounts and email address in a deliberate attempt to cause harm.

As I said in my initial discussion if we have no repsect for technical
correctness what is the point of these discussion groups.
A group of bullies who can do nothing more than dismiss an individual
as a troll, does not constitute technical correctness.

Plonk.

 

[Paul]

Wow, your lack of understanding is even greater than I had assumed.
Committee working papers aren't a standard.

The current C++ standard is available from

http://webstore.ansi.org/RecordDetail.aspx?sku=BS+ISO/IEC+14882:2003

So this is not a standard?
http://webstore.ansi.org/RecordDetail.aspx?sku=ISO/IEC+29124:2010

 

[Ian Collins]

So this is not a standard?
http://webstore.ansi.org/RecordDetail.aspx?sku=ISO/IEC+29124:2010

What does that have to do with your earlier nonsense?

Yes it's a standard, no it isn't the C++ language standard and it
certainly isn't the source of your quotes.

 

[Paul]

Wow, your lack of understanding is even greater than I had assumed.
Committee working papers aren't a standard.

The current C++ standard is available from

http://webstore.ansi.org/RecordDetail.aspx?sku=BS+ISO/IEC+14882:2003


You have already provided more than enough evidence, I don't think there
is more to add.


Pot, kettle?

I think its quite obviously I have proven you wrong about the number of
standards relevant to C++.
I have given clear evidence to prove that more than one standard exists yet
you refuse to accept it.
Your accusations that I lack understanding and misinterpeet the standards,
without any evidence, is nothing more than hostile insults.

 

[gwowen]

Yes it's a standard, no it isn't the C++ language standard and it
certainly isn't the source of your quotes.

Do not try to wrestle with pigs. You both get covered in shit, only
the pigs enjoy it.

 

[Ian Collins]

Do not try to wrestle with pigs. You both get covered in shit, only
the pigs enjoy it.

Oh I wasn't. Just having a bit of fun on quiet afternoon!

 

[Alf P. Steinbach /Usenet]

* PaulR, on 06.01.2011 01:22:

Many valid points I have raised have gone unanswered and dismissed
even though I support my opinions with extracts from the C++
standards.

The latest points being those raised in this message:
http://groups.google.com/group/comp.lang.c++/msg/746044473c191d29

It seems the one insult I made has provoked a hell of a lot of
hostility. But I would like to make it clear that my insult was
delivered in a light hearted way to draw attention. It was nothing
like the deep rooted hostile and nasty insults I seem to be getting
bombarded with by these so called proffessionals.

If I have left any replies unanswered in my other thread , please
excuse me but I do not choose to discuss with people who mess with
your accounts and email address in a deliberate attempt to cause harm.

As I said in my initial discussion if we have no repsect for technical
correctness what is the point of these discussion groups.
A group of bullies who can do nothing more than dismiss an individual
as a troll, does not constitute technical correctness.

Huh, I'm away for fourteen days or so and suddenly y'all go overboard in flame
wars. Hah!

Paul, as far as I understand the issue after skimming the article you linked to,
you think that some sub-objects can have zero size.

That is correct.

A base class sub-object can have zero size.

The size of a reference member is more vaguely specified, as I recall.

Also, as I recall there is an issue with the current standard about objects of
the same type, like when you have a first data member of the same type as a base
class. The intention is that they should have different addresses. But I think
(may be wrong here) that the C++98 standard didn't sufficiently pin that down.
Still, as I recall, that issue has been fixed in C++0x. Or at least, that they
attempted a fix -- it's quite tricky to get right.

If you're interested in the details, then I suggest checking out the Defect Reports.


Now, children.

Cheers,

- Alf

 

[Paul]

* PaulR, on 06.01.2011 01:22:

Huh, I'm away for fourteen days or so and suddenly y'all go overboard in
flame wars. Hah!

Paul, as far as I understand the issue after skimming the article you
linked to, you think that some sub-objects can have zero size.

That is correct.

A base class sub-object can have zero size.

The size of a reference member is more vaguely specified, as I recall.

Also, as I recall there is an issue with the current standard about
objects of the same type, like when you have a first data member of the
same type as a base class. The intention is that they should have
different addresses. But I think (may be wrong here) that the C++98
standard didn't sufficiently pin that down. Still, as I recall, that issue
has been fixed in C++0x. Or at least, that they attempted a fix -- it's
quite tricky to get right.

If you're interested in the details, then I suggest checking out the
Defect Reports.


Now, children.

Cheers,

- Alf

Alf the fact that a member function does not reside in the same storage
area as an object is irrellevant.

A member function IS part of an object, end of story.

The argument put forward that, because a function does not live inside the
same region of storage is not proof to suggest a member function cannot be
part of an object.


It seems pretty clear to me that many of these people are completely
unreasonable people and incapable of having a proper technical discussion.

 

[Alf P. Steinbach /Usenet]

* Paul, on 06.01.2011 12:36:[please don't quite signatures and other irrelevant stuff, snipped]

Alf the fact that a member function does not reside in the same storage area as
an object is irrellevant.

I should hope so, no matter what it is that you're referring to (I'm in the dark
there, and I'm not going to read up on the old thread to find out).

A member function IS part of an object, end of story.

Well that's a question of context and terminology.

I can understand that you were getting some heat if you were insisting that
others adopt some uncommon terminology, if you did. That's always a good way to
start flame wars. This about where member functions reside is a new one, though.

Previously the Great Terminology Debates (read: flame wars) have mostly been
about whether constructors can be "called".

If you'd like to put some extra gasoline on the fire, then for the "is it part
of or not" debate I think it could be useful to read up on the holy standard's
use of the not-clearly-defined term "region of storage".

It so happened that this vagueness (allowing non-contiguous regions) was done
deliberately in order to support multiple virtual inheritance, but that at least
some committee members saw it as not only necessary for virtual inheritance, but
also allowing implementations that scatter parts of objects all around in
memory. Thus, the wording in the standard does not say right out that it's in
support of virtual inheritance. The standard intentionally leaves the door open
for what we'd now regard as "perverse" implementations.

The argument put forward that, because a function does not live inside the same
region of storage is not proof to suggest a member function cannot be part of an
object.

Right, there is no such thing as proof when it comes to terminology.

Terminology is just defined; it means what it means, by definition.

However, in order to communicate clearly, it can be a good idea to explicitly
define or at least outline in broad strokes the terminology that one employs.

It seems pretty clear to me that many of these people are completely
unreasonable people and incapable of having a proper technical discussion.

Rather, I think perhaps some of them were reacting to the non-technical nature
of the discussion, namely the terminology aspect?


Cheers & hth.,

- Alf

 

[stan]

Paul wrote:

Also you make accusations that I misinterpet the standards yet you have
provided no evidence to support this.

Let's agree that the possibility of misinterpretation exists; what would you accept as evidence?

 

[LR]

It so happened that this vagueness (allowing non-contiguous regions)
was done deliberately in order to support multiple virtual
inheritance, but that at least some committee members saw it as not
only necessary for virtual inheritance, but also allowing
implementations that scatter parts of objects all around in memory.
Thus, the wording in the standard does not say right out that it's in
support of virtual inheritance. The standard intentionally leaves
the door open for what we'd now regard as "perverse" implementations.

Would I be correct in inferring that non-contiguous classes are no
longer regarded as necessary? If not, does the current draft still
support a requirement for this?

Did any implementation create objects with non-contiguous memory? Anyone
know?

However, in thread "Re: technical correctness"
in Message-ID: <[email protected]>
Francis Glassborow <[email protected]>
wrote: "All subobjects must reside in a single contiguous region which
is the object. Otherwise sizeof and operator new would be useless:"

Would this also be a requirement for the offsetof macro as well? I
don't recall if offsetof is in the standard, but it is in n3126.

If I understand what they've written correctly, I think that either Mr.
Steinbach or Mr. Glassborow is wrong. Perhaps someone could clarify?
Provide a cite from either the standard or the latest draft?

TIA

LR

 

[James Kanze]

Alf P. Steinbach /Usenet wrote:

Would I be correct in inferring that non-contiguous classes are no
longer regarded as necessary? If not, does the current draft still
support a requirement for this?

All of the implementations I know do insert extra bytes here and
there in the object; in this sense, they all use non-contiguous
memory.

The real question is: what did the authors of the standard mean
by "non-contiguous"? That parts of other objects are somehow
interspaced in the memory of the object. I don't think that
this could be made to work; how would operator new work, for
example. That not all of the memory encompassed in sizeof is
used by the object. That's the case, even in C, because padding
is not only allowed, but also necessary.

Did any implementation create objects with non-contiguous memory? Anyone
know?

However, in thread "Re: technical correctness"
in Message-ID: <[email protected]>
Francis Glassborow <[email protected]>
wrote: "All subobjects must reside in a single contiguous region which
is the object. Otherwise sizeof and operator new would be useless:"

Would this also be a requirement for the offsetof macro as well? I
don't recall if offsetof is in the standard, but it is in n3126.

The macro offsetof is in the C++ standard, but it is restricted
to PODS.

 

[LR]

All of the implementations I know do insert extra bytes here and
there in the object; in this sense, they all use non-contiguous
memory.

Yes, but I don't think that padding or putting things like vtable
pointers in an object is what was meant here.

The real question is: what did the authors of the standard mean
by "non-contiguous"? That parts of other objects are somehow
interspaced in the memory of the object. I don't think that
this could be made to work; how would operator new work, for
example. That not all of the memory encompassed in sizeof is
used by the object. That's the case, even in C, because padding
is not only allowed, but also necessary.

I suspect that actual non-contiguous objects could be made to work. But
it would require some jumping through some interesting, for which read:
probably pointless, hoops.


However,

From n3126

1.8, from 5 ... An object of trivially copyable or standard-layout
type (3.9) shall occupy contiguous bytes of storage. ...

3.9 Types
2 For any object (other than a base-class subobject) of trivially
copyable type T, whether or not the object holds a valid value of type
T, the underlying bytes making up the object can be copied into an array
of char or unsigned char [which a footnote says can be done using for
example std::memcpy or std::memmove]. If the content of the array of
char or unsigned char is copied back into the object, the object shall
subsequently hold its original value. ...

And since arrays have to be contiguous per 8.3.4,1 ... An
object of array type contains a contiguously allocated non-empty set of
N subobjects of type T. ...

I think this requires a contiguous region for some objects. But I don't
think it addresses the issue of multiple virtual inheritance.

LR

 

[Alf P. Steinbach /Usenet]

* LR, on 07.01.2011 06:59:

Would I be correct in inferring that non-contiguous classes are no
longer regarded as necessary? If not, does the current draft still
support a requirement for this?

Did any implementation create objects with non-contiguous memory? Anyone
know?

However, in thread "Re: technical correctness"
in Message-ID:<[email protected]>
Francis Glassborow<[email protected]>
wrote: "All subobjects must reside in a single contiguous region which
is the object. Otherwise sizeof and operator new would be useless:"

Would this also be a requirement for the offsetof macro as well? I
don't recall if offsetof is in the standard, but it is in n3126.

If I understand what they've written correctly, I think that either Mr.
Steinbach or Mr. Glassborow is wrong. Perhaps someone could clarify?
Provide a cite from either the standard or the latest draft?

Well, Francis' comment about the non-usefulness of 'sizeof' would apply also to
an object with a virtual base.

struct Base{ int x; };
struct D1: virtual Base { int d1; };
struct D2: virtual Base { int d2; };
struct Bottom: D1, D2 {};

Bottom doh;

Within the object 'doh' you can have the D1 sub-object of size sizeof(D1), but
then, since a part of it is shared with the D2 sub-object, the D2 sub-object
can't be of size sizeof(D2). And vice versa. But you can still pick up a
reference to, say, the D2 sub-object, and pass it to some function that doesn't
know about Bottom or anything other than that it is a D2 object, so on the
inside of that object there is necessarily some indirection referring to the
Base sub-object: the Base sub-object is not necessarily directly contained.

So Francis' /argument/ is lacking, but in practice his conclusion is correct
when "the object" is replaced with "the object of the most derived class".

The purely formal and purely academic problem is that the standard doesn't
guarantee even that... The C++98 standard allows the same shenanigans that the
compiler must insert for D1 and D2 objects, for any non-POD object. But, since I
don't know of any actual implementation where it doesn't hold, when I try to
explain this to novices I just say that a /variable/ is a contiguous region of
storage, because it is in practice.


Cheers & hth.,

- Alf

 

[James Kanze]

Yes, but I don't think that padding or putting things like vtable
pointers in an object is what was meant here.

I don't really think so either, but... it's either padding, or
parts of some other object. And I don't think they really want
to allow parts of some other object.

Or perhaps it is meant to refer to something that are implicitly
created. If instead of a vptr, you use a map, with the address
of the object as a key, I suppose you could think of the map
entry as "part of the object".

But to tell the truth, I'm just guessing about what they might
have meant.

I suspect that actual non-contiguous objects could be made to work. But
it would require some jumping through some interesting, for which read:
probably pointless, hoops.

From n3126

1.8, from 5 ... An object of trivially copyable or standard-layout
type (3.9) shall occupy contiguous bytes of storage. ...

Tha text, of course, isn't present in the current standard. But
it certainly does imply that the text about non-contiguous
didn't mean padding, since even trivially copyable objects can
have padding.

3.9 Types
2 For any object (other than a base-class subobject) of trivially
copyable type T, whether or not the object holds a valid value of type
T, the underlying bytes making up the object can be copied into an array
of char or unsigned char [which a footnote says can be done using for
example std::memcpy or std::memmove]. If the content of the array of
char or unsigned char is copied back into the object, the object shall
subsequently hold its original value. ...

And since arrays have to be contiguous per 8.3.4,1 ... An
object of array type contains a contiguously allocated non-empty set of
N subobjects of type T. ...

I think this requires a contiguous region for some objects. But I don't
think it addresses the issue of multiple virtual inheritance.

I'm sure that some objects have to be contiguous. I can't see
any possibility of a POD not being contiguous.

 

[Paul]

* Francis Glassborow, on 07.01.2011 19:46:

Progress, we agree that your original wording saying just "object" was
misleading, but none of us write perfect formally correct things in Usenet
articles. ;-) We'd have to quote all relevant stuff from the standard for
that. Totally impractical, yes.

But re your new tack here:

Yes but you don't blame me because I pointed it out.
Although I am right most of the time , I accept that sometimes I am wrong
too when this is the case the best thing is just to admit it.
Now look at the confusion he's caused by supporting this ridiculous idea
that an object is "simply a region of storage".
Now there will be lots of people who may have read that going around
actually thinking this is correct, when it isn't.
He may have spawned a whole generation of programming morons who dont even
know what an object is. THink of the quality degradation of programmers as
this is diluted through the generations