technical correctness 2

Discussion in 'C++' started by PaulR, Jan 6, 2011.

  1. PaulR

    PaulR Guest

    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.
     
    PaulR, Jan 6, 2011
    #1
    1. Advertising

  2. PaulR

    Ian Collins Guest

    On 01/ 6/11 01:22 PM, PaulR wrote:
    > 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.

    --
    Ian Collins
     
    Ian Collins, Jan 6, 2011
    #2
    1. Advertising

  3. PaulR

    Paul Guest

    "Ian Collins" <> wrote in message
    news:...
    > On 01/ 6/11 01:22 PM, PaulR wrote:
    >> 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.


    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.
     
    Paul, Jan 6, 2011
    #3
  4. PaulR

    Ian Collins Guest

    On 01/ 6/11 03:16 PM, Paul wrote:
    >
    > "Ian Collins" <> wrote in message
    > news:...
    >> On 01/ 6/11 01:22 PM, PaulR wrote:
    >>> 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.

    >
    > 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?

    --
    Ian Collins
     
    Ian Collins, Jan 6, 2011
    #4
  5. PaulR

    Sjouke Burry Guest

    PaulR wrote:
    > 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.
     
    Sjouke Burry, Jan 6, 2011
    #5
  6. PaulR

    Paul Guest

    "Ian Collins" <> wrote in message
    news:...
    > On 01/ 6/11 03:16 PM, Paul wrote:
    >>
    >> "Ian Collins" <> wrote in message
    >> news:...
    >>> On 01/ 6/11 01:22 PM, PaulR wrote:
    >>>> 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.

    >>
    >> 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.

    >

    So this is not a standard?
    http://webstore.ansi.org/RecordDetail.aspx?sku=ISO/IEC 29124:2010
     
    Paul, Jan 6, 2011
    #6
  7. PaulR

    Ian Collins Guest

    On 01/ 6/11 04:25 PM, Paul wrote:
    >
    > "Ian Collins" <> wrote in message
    > news:...
    >> On 01/ 6/11 03:16 PM, Paul wrote:
    >>>
    >>> "Ian Collins" <> wrote in message
    >>> news:...
    >>>> On 01/ 6/11 01:22 PM, PaulR wrote:
    >>>>> 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.
    >>>
    >>> 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.

    >>

    > 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.

    --
    Ian Collins
     
    Ian Collins, Jan 6, 2011
    #7
  8. PaulR

    Paul Guest

    "Ian Collins" <> wrote in message
    news:...
    > On 01/ 6/11 03:16 PM, Paul wrote:
    >>
    >> "Ian Collins" <> wrote in message
    >> news:...
    >>> On 01/ 6/11 01:22 PM, PaulR wrote:
    >>>> 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.

    >>
    >> 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?
    >
    > --
    > Ian Collins
    >


    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.
     
    Paul, Jan 6, 2011
    #8
  9. PaulR

    gwowen Guest

    On Jan 6, 3:34 am, Ian Collins <> wrote:
    > 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.
     
    gwowen, Jan 6, 2011
    #9
  10. PaulR

    Ian Collins Guest

    On 01/ 6/11 08:49 PM, gwowen wrote:
    > On Jan 6, 3:34 am, Ian Collins<> wrote:
    >> 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.


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

    --
    Ian Collins
     
    Ian Collins, Jan 6, 2011
    #10
  11. * 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

    --
    blog at <url: http://alfps.wordpress.com>
     
    Alf P. Steinbach /Usenet, Jan 6, 2011
    #11
  12. PaulR

    Paul Guest

    "Alf P. Steinbach /Usenet" <> wrote in
    message news:ig42tn$ng7$-september.org...
    >* 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
    >
    > --
    > blog at <url: http://alfps.wordpress.com>
    >

    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.
     
    Paul, Jan 6, 2011
    #12
  13. * Paul, on 06.01.2011 12:36:
    >
    > "Alf P. Steinbach /Usenet" <> wrote in message
    > news:ig42tn$ng7$-september.org...
    >> * 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.

    [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

    --
    blog at <url: http://alfps.wordpress.com>
     
    Alf P. Steinbach /Usenet, Jan 6, 2011
    #13
  14. PaulR

    stan Guest

    Paul wrote:
    <snip>

    > 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?
     
    stan, Jan 7, 2011
    #14
  15. PaulR

    LR Guest

    A question about sizeof, offsetof, new and objects in contiguous

    Alf P. Steinbach /Usenet wrote:

    > 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: <>
    Francis Glassborow <>
    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
     
    LR, Jan 7, 2011
    #15
  16. PaulR

    James Kanze Guest

    Re: A question about sizeof, offsetof, new and objects in contiguous

    On Jan 7, 5:59 am, LR <> wrote:
    > Alf P. Steinbach /Usenet wrote:


    > > 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?


    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: <>
    > Francis Glassborow <>
    > 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.

    --
    James Kanze
     
    James Kanze, Jan 7, 2011
    #16
  17. PaulR

    LR Guest

    Re: A question about sizeof, offsetof, new and objects in contiguous

    James Kanze wrote:
    > On Jan 7, 5:59 am, LR <> wrote:
    >> Alf P. Steinbach /Usenet wrote:

    >
    >>> 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?

    >
    > 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
     
    LR, Jan 7, 2011
    #17
  18. Re: A question about sizeof, offsetof, new and objects in contiguous

    * LR, on 07.01.2011 06:59:
    >
    >
    > Alf P. Steinbach /Usenet wrote:
    >
    >> 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:<>
    > Francis Glassborow<>
    > 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

    --
    blog at <url: http://alfps.wordpress.com>
     
    Alf P. Steinbach /Usenet, Jan 7, 2011
    #18
  19. PaulR

    James Kanze Guest

    Re: A question about sizeof, offsetof, new and objects in contiguous

    On Jan 7, 5:09 pm, LR <> wrote:
    > James Kanze wrote:
    > > On Jan 7, 5:59 am, LR <> wrote:
    > >> Alf P. Steinbach /Usenet wrote:


    > >>> 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?


    > > 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.


    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.

    > > 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. ...


    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.

    --
    James Kanze
     
    James Kanze, Jan 7, 2011
    #19
  20. PaulR

    Paul Guest

    Re: A question about sizeof, offsetof, new and objects in contiguous regions. (Was Re: technical correctness 2)

    "Alf P. Steinbach /Usenet" <> wrote in
    message news:ig7o4e$mmm$-september.org...
    >* Francis Glassborow, on 07.01.2011 19:46:
    >> On 07/01/2011 18:34, Alf P. Steinbach /Usenet wrote:
    >>> * LR, on 07.01.2011 06:59:
    >>>>
    >>>>
    >>>> Alf P. Steinbach /Usenet wrote:
    >>>>
    >>>>> 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:<>
    >>>> Francis Glassborow<>
    >>>> 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.
    >>>

    >>
    >> This is one of the ways in which complete objects are distinct from
    >> sub=objects.
    >> The latter can be disjoint and the former cannot be.

    >
    > 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
     
    Paul, Jan 7, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ryan Stewart
    Replies:
    9
    Views:
    400
    Ryan Stewart
    Mar 7, 2004
  2. spiros
    Replies:
    7
    Views:
    502
    John Harrison
    Jul 20, 2004
  3. Jim Strathmeyer

    stl list, const correctness

    Jim Strathmeyer, Mar 19, 2005, in forum: C++
    Replies:
    2
    Views:
    526
    Pete Becker
    Mar 20, 2005
  4. Matthias Kaeppler

    const-correctness and lambda expression

    Matthias Kaeppler, Apr 16, 2005, in forum: C++
    Replies:
    1
    Views:
    635
    Kanenas
    Apr 20, 2005
  5. Paul

    technical correctness

    Paul, Dec 31, 2010, in forum: C++
    Replies:
    117
    Views:
    2,094
Loading...

Share This Page