Re: The C++ type system

Discussion in 'C++' started by Paul, Jan 9, 2011.

  1. Paul

    Paul Guest

    "Francis Glassborow" <> wrote in message
    news:...
    > The C++ type system can is far from simple and the terminology for writing
    > about it can be confusing so I will no doubt fail in the eyes of at least
    > one person to be entirely correct in the following.
    > C++ types include:
    >
    > 1) Object types
    > Fundamental types
    > Derived types (that is types that are derived from other types by adding
    > cv qualifiers)
    > Enum types
    > Class types


    A class is not a type, a class defines a UserDefinedType.

    With:
    class foo;
    Class is not a type. That is a declaration of the type foo.

    If you mean static varaibles with:
    className::typename foo;
    The type of the variable is not a class type, the class is a scope specifier
    not a type.

    'Class type' seems to be some kind of old C terminology.
    C programmers never really did did understand OOP, let alone support it.
    Eventually they reluctantly had to learn C++ because C++ programmers could
    understand their language/code. The same could not be said for them knowing
    C++.
    Back in the days when people like Richard Heathfield jumping around shouting
    that C is better than C++, He was another nobhead that wrote a book on C and
    thought he ruled the world for a few years.


    > Pointer types


    A pointer is NOT a type.
    A pointer is a varaible that has a type of integer(or some similar type,
    that is capable of storing an address) .


    > Array types
    > Collectively the above types are called object types
    >
    > 2) Function types
    > Function types (divided into free functions and member functions). Member
    > functions come in two flavours, static member functions that provide the
    > behaviour for the class as a whole and non-static member functions that
    > provide the behaviour for individual instances (objects) of the class.
    > Function types are not object types (by explicit statement in the C++
    > Standard) however it is possible to derive a pointer to (possibly member)
    > function and these are object types. All pointer types, AFAIK – but I am
    > happy to be corrected on this issue -- are object types.


    A function is not a type
    You can have a type of function i.E: a member function, a static function ,
    a _stdcall function etc.
    Or you can have a function signature type.

    >
    > 3) Reference types
    > Reference types are easily misunderstood because in the context of C++
    > they are not the same as reference types in other languages (such as
    > Java). Effectively a reference (and instance of a reference type) provides
    > another handle for an existing type. Every non-reference type in C++ has
    > an associated reference type. Nothing can be derived from a reference
    > type. You cannot cv qualify a reference type, you cannot have an array of
    > a reference type and you cannot have a pointer to a reference type.


    A referene is not a type anymore than a pointer is a type.
    A reference is simply an alias.

    >
    > Note on static v dynamic type
    > All entities have a static type which is the type with which they are
    > declared. In the case of pointers and references there is a second
    > (dynamic) type which is the type of the entity actually pointed to (well
    > strictly speaking it is the type of the pointer to that type) or
    > referenced. C++ provides a mechanism to access the behaviour of the
    > dynamic type when that is different to the behaviour of the static type.


    The above is the scribblings of a very confused C programmer.

    >
    > What is a C++ object?
    > The Standard dictates that an object is a region of storage coupled with
    > an object type. Note that neither functions nor references are objects but
    > storage for a pointer is. [Another confusion is that we loosely refer to a
    > pointer to mean both the value (an address in colloquial terminology) and
    > the storage for such a value.]


    Again the scribblings of a very confused C programmer.

    >
    > Objects of a user defined type can be composed of sub-objects. In the
    > interests of efficiency some license is granted to sub-objects that is not
    > available to complete objects. A sub-object can be of zero size and a
    > sub-object can occupy disjoint storage (the latter is essential in order
    > to support C++ multiple inheritance). In addition to sub-objects all
    > object types (including built-in types) allow the inclusion of other
    > storage which is either padding or used for internal purposes.


    A licence is granted to subobject? :S
    WTF is that shit?..... is the subobject going to be selling tobacoo and
    alcohol
    >
    > For example a C++ reference needs a mechanism to locate the entity being
    > referenced though the C++ Standard does not specify what this mechanism
    > is. That mechanism almost always requires storage for data that allows
    > locating the entity being referenced. The dynamic binding mechanism used
    > by pointers and references also needs the object to include some
    > information. Multiple inheritance needs storage to handle the access to
    > the base class sub-objects.


    :S Is the above example supposed to clarify something? :S
    >
    > From a common sense perspective external objects that are pointed to or
    > referenced by an object might logically be considered as part of the
    > object. However, in the case of pointers C++ does not consider such
    > external objects to be part of the object. I think the issue is slightly
    > less clear cut in the case of references though I think the majority would
    > not consider a referenced entity to be part of the C++object.


    The reference cannot reference the object because the referenced object
    pointed to by the refernced pointer might be within the object.
    The standards are not sure if that object is a reference to this pointer or
    if they should actually define an object that isn't actually referenced , so
    therefore I must be really confusing....Two millionth word.

    >I hope that most can see that the complexity of the above (and I could
    >easily write another ten thousand words on the subject and still have


    .... Blah blah blah yeah ,snip that bullshit.

    A pointer is generally NOT thought of as a TYPE in programming, it's a
    pointer to an address.
    Technically speaking when you examine a pointers TYPE it's some kind of
    INTEGER TYPE , suitable for the memory addressing system.
    IF you think a pointer should be described as a TYPE in the context of the
    C++ standards... IDGAF but it just poves what an asshole you are.

    To post this bullshit in a beginners forum in a deliberate attempt to
    mislead and confuse people, in the context that it comes from an 'expert'
    shows exactly the kind of bullshitting arsehole you really are.

    You and your homosexual friend Francesco started an argument with me then do
    nothing more than slander and put me down in an attempt to make you look
    smart. You provoke me to make insults and you create more arguments which
    you cannot resolve.

    From you and your homosexual following I never had any respect in the first
    place. I never wanted any respect nor do I give a **** if they will ever
    know the meaning of respect.
    So go **** yourself and your following you technically incorrect
    bullshitting motherfucker.
     
    Paul, Jan 9, 2011
    #1
    1. Advertising

  2. Paul

    Ian Collins Guest

    On 01/10/11 08:46 AM, Leigh Johnston wrote:
    >
    > You really are an obnoxious as well as utterly stupid troll aren't you?


    Did you really have to quote all of its obnoxious rantings?

    It's time to put this troll on a starvation diet!

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

  3. * Paul, on 09.01.2011 20:15:
    >


    Plinked, now also in [comp.lang.c++].

    Bye.

    - Alf

    --
    blog at <url: http://alfps.wordpress.com>
     
    Alf P. Steinbach /Usenet, Jan 9, 2011
    #3
  4. Paul

    Paul Guest

    "Alf P. Steinbach /Usenet" <> wrote in
    message news:igd46a$ec1$-september.org...
    >* Paul, on 09.01.2011 20:15:
    >>

    >
    > Plinked, now also in [comp.lang.c++].
    >
    > Bye.
    >
    > - Alf
    >
    > --
    > blog at <url: http://alfps.wordpress.com>
    >


    :)
    http://www.youtube.com/watch?v=nJy4wV25f_o
     
    Paul, Jan 9, 2011
    #4
  5. Paul

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 09/01/2011 20:34, Paul wrote:
    >>
    >> "Leigh Johnston" <> wrote in message
    >> news:...
    >>> On 09/01/2011 19:15, Paul wrote:
    >>>>
    >>>> "Francis Glassborow" <> wrote in
    >>>> message news:...
    >>>>> The C++ type system can is far from simple and the terminology for
    >>>>> writing about it can be confusing so I will no doubt fail in the eyes
    >>>>> of at least one person to be entirely correct in the following.
    >>>>> C++ types include:
    >>>>>
    >>>>> 1) Object types
    >>>>> Fundamental types
    >>>>> Derived types (that is types that are derived from other types by
    >>>>> adding cv qualifiers)
    >>>>> Enum types
    >>>>> Class types
    >>>>
    >>>> A class is not a type, a class defines a UserDefinedType.
    >>>>
    >>>> With:
    >>>> class foo;
    >>>> Class is not a type. That is a declaration of the type foo.
    >>>>
    >>>> If you mean static varaibles with:
    >>>> className::typename foo;
    >>>> The type of the variable is not a class type, the class is a scope
    >>>> specifier not a type.
    >>>>
    >>>> 'Class type' seems to be some kind of old C terminology.
    >>>> C programmers never really did did understand OOP, let alone support
    >>>> it.
    >>>> Eventually they reluctantly had to learn C++ because C++ programmers
    >>>> could understand their language/code. The same could not be said for
    >>>> them knowing C++.
    >>>> Back in the days when people like Richard Heathfield jumping around
    >>>> shouting that C is better than C++, He was another nobhead that wrote a
    >>>> book on C and thought he ruled the world for a few years.
    >>>>
    >>>>
    >>>>> Pointer types
    >>>>
    >>>> A pointer is NOT a type.
    >>>> A pointer is a varaible that has a type of integer(or some similar
    >>>> type,
    >>>> that is capable of storing an address) .
    >>>>

    >> <snip....snip ....snip.........>.
    >>>
    >>> You really are an obnoxious as well as utterly stupid troll aren't you?
    >>>
    >>> "pointer type" is not the same as "pointer":
    >>>
    >>> typedef int* pointer_type;
    >>> pointer_type pointer;
    >>>
    >>> /Leigh

    >>
    >> In the code above the word 'pointer' is a variable of type
    >> 'pointer_type'. You have defined 'pointer_type' as a pointer to an
    >> integer type. If that's the best argument to suggest otherwise, then
    >> apparently it's correct that a *pointer* is NOT a type.

    >
    > Yes a pointer is an object not a type;<snip.....snip>


    Apparently a pointer is *NOT* a type now.
    You are obviously a very confused individual.
     
    Paul, Jan 9, 2011
    #5
  6. Leigh Johnston <> writes:
    [snip BS]
    > Yes a pointer is an object not a type; a pointer is an instance of a
    > pointer type so don't complain about the term "pointer type".

    [...]

    There's some genuine confusion on this point, and it's fairly easy to
    avoid.

    The unqualified word "pointer" is ambiguous. It can refer, in
    different contexts, to a pointer object, to a pointer value, or to
    a pointer type. (The C standard, for example, says that malloc()
    returns a pointer, meaning a pointer value; I'm not sure whether
    the C++ standard does something similar.)

    Usually the meaning is sufficiently clear from the context, but
    sometimes it's best to avoid using the word "pointer", instead
    referring explicitly to a pointer object, a pointer value, or a
    pointer type.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 9, 2011
    #6
  7. Paul

    SG Guest

    On 9 Jan., 21:34, "Paul" wrote:
    >
    > > typedef int* pointer_type;
    > > pointer_type pointer;

    >
    > In the code above the word 'pointer' is a variable of type 'pointer_type'.
    > You have defined 'pointer_type' as a pointer to an integer type. If that's
    > the best argument to suggest otherwise, then apparently it's correct that a
    > *pointer* is NOT a type.


    I believe the expression "type of" and its different meanings is one
    of the reasons why there are these misunderstandings. I see that a
    sentence like

    x is a type of a pointer

    could be interpreted to mean

    x is a pointer

    but also

    x is a type

    depending on what exact meaning you attatch to the expression "type
    of". But this possible ambiguity should be resolved once you add "x is
    not a pointer".

    Here are usage examples for the official terminology:

    int* p;
    double add(double,double);

    p is a pointer variable. The type of p is int*. int* is a type. More
    specifically, int* is an object type because you can create an object
    of that type. More specifically, int* is a pointer type because you
    can create a pointer with that type. Note that I'm not intending to
    say that int* is pointer. It's just a type a pointer variable might
    have (a type of a pointer).

    add is a function. The type of add is double(double,double).
    double(double,double) is a type. double(double,double) is not an
    object type because you cannot create an object of that type.
    double(double,double) is a function type because you can create a
    function with that type. Note that I'm not intending to say that
    double(double,double) is function. It's just a type a function might
    have (a type of a function).

    Here, "x is the type of y" means "the type property of y is x" and not
    "x is a kind of y". Do you see where I'm going with this?

    Cheers!
    SG
     
    SG, Jan 9, 2011
    #7
  8. Paul

    SG Guest

    On 9 Jan., 22:58, SG wrote:
    > I believe the expression "type of" and its different meanings is one
    > of the reasons why there are these misunderstandings. I see that a
    > sentence like
    >
    >   x is a type of a pointer
    >
    > could be interpreted to mean
    >
    >   x is a pointer
    >
    > but also
    >
    >   x is a type
    >
    > depending on what exact meaning you attatch to the expression "type
    > of". But this possible ambiguity should be resolved once you add "x is
    > not a pointer".


    In addition, the expression "instance of" could be misinterpreted just
    like that. But "type of" and "instance of" in a computer science
    context have special meanings and cannot be used interchangably.
    Example:

    class foo;
    foo x;

    foo is a type, more specifically, an object type, more spedifically, a
    class type. x is an object. foo is the TYPE OF x. x is an INSTANCE of
    foo.

    I'n not an English native speaker, so I'm only guessing that an
    English native speaker without "CS training" might use "type of" and
    "instance of" interchangably.

    Cheers!
    SG
     
    SG, Jan 9, 2011
    #8
  9. * Leigh Johnston, on 09.01.2011 22:10:
    >
    > People sometimes use the term "pointer" when they actually mean "pointer type".


    Just to back that up, the Holy Standard also uses "pointer" with the meaning
    "pointer type", so at least for the purpose of reading the standard it's
    necessary to know about this meaning (if not necessarily to employ oneself, e.g.
    I don't, and I haven't heard anyone else doing it either).

    Now, just checking the standard I didn't find the wording that I remember, but I
    found this little gem:

    §3.4.5/7 ... "the class pointed to by the pointer expression"

    Clearly some intelligence is needed in order to understand that. ;-)


    Cheers,

    - Alf

    --
    blog at <url: http://alfps.wordpress.com>
     
    Alf P. Steinbach /Usenet, Jan 9, 2011
    #9
  10. Paul

    James Kanze Guest

    On Jan 9, 7:15 pm, "Paul" <> wrote:
    > "Francis Glassborow" <> wrote in message


    > news:...


    > > The C++ type system can is far from simple and the
    > > terminology for writing about it can be confusing so I will
    > > no doubt fail in the eyes of at least one person to be
    > > entirely correct in the following. C++ types include:

    >
    > > 1) Object types
    > > Fundamental types
    > > Derived types (that is types that are derived from other types by adding
    > > cv qualifiers)
    > > Enum types
    > > Class types


    > A class is not a type, a class defines a UserDefinedType.


    A class definition defines a type. Types defined by class
    definitions are called class types, to distiguish them from e.g.
    fundamental types, enum types, etc.

    [...]
    > > Pointer types


    > A pointer is NOT a type.


    No. A pointer is an object (in C++) which has pointer type.

    > A pointer is a varaible that has a type of integer(or some
    > similar type, that is capable of storing an address) .


    A pointer most definitly doesn't have an integral types. A
    pointer has pointer type.

    > > Array types
    > > Collectively the above types are called object types


    > > 2) Function types
    > > Function types (divided into free functions and member
    > > functions). Member functions come in two flavours, static
    > > member functions that provide the behaviour for the class as
    > > a whole and non-static member functions that provide the
    > > behaviour for individual instances (objects) of the class.
    > > Function types are not object types (by explicit statement
    > > in the C++ Standard) however it is possible to derive a
    > > pointer to (possibly member) function and these are object
    > > types. All pointer types, AFAIK but I am happy to be
    > > corrected on this issue -- are object types.


    > A function is not a type


    But a function has a type. A function type is not an object
    type, because a function is not an object.

    > > 3) Reference types
    > > Reference types are easily misunderstood because in the context of C++
    > > they are not the same as reference types in other languages (such as
    > > Java). Effectively a reference (and instance of a reference type) provides
    > > another handle for an existing type. Every non-reference type in C++ has
    > > an associated reference type. Nothing can be derived from a reference
    > > type. You cannot cv qualify a reference type, you cannot have an array of
    > > a reference type and you cannot have a pointer to a reference type.


    > A referene is not a type anymore than a pointer is a type.


    A reference is not a type; a reference is an entity, which has a
    reference type.

    > A reference is simply an alias.


    It none the less has a type.

    Do you know what "type" means in a programming language context?

    > > Note on static v dynamic type
    > > All entities have a static type which is the type with which they are
    > > declared. In the case of pointers and references there is a second
    > > (dynamic) type which is the type of the entity actually pointed to (well
    > > strictly speaking it is the type of the pointer to that type) or
    > > referenced. C++ provides a mechanism to access the behaviour of the
    > > dynamic type when that is different to the behaviour of the static type.


    > The above is the scribblings of a very confused C programmer.


    No. The above describes rather exactly how the type system
    works in C++.

    > > What is a C++ object?
    > > The Standard dictates that an object is a region of storage coupled with
    > > an object type. Note that neither functions nor references are objects but
    > > storage for a pointer is. [Another confusion is that we loosely refer to a
    > > pointer to mean both the value (an address in colloquial terminology) and
    > > the storage for such a value.]


    > Again the scribblings of a very confused C programmer.


    No. The above describes rather exactly the object model in C++.

    > > Objects of a user defined type can be composed of sub-objects. In the
    > > interests of efficiency some license is granted to sub-objects that is not
    > > available to complete objects. A sub-object can be of zero size and a
    > > sub-object can occupy disjoint storage (the latter is essential in order
    > > to support C++ multiple inheritance). In addition to sub-objects all
    > > object types (including built-in types) allow the inclusion of other
    > > storage which is either padding or used for internal purposes.


    > A licence is granted to subobject? :S
    > WTF is that shit?..... is the subobject going to be selling tobacoo and
    > alcohol


    If you don't want to understand, then there's not much we can do
    to help you.

    [...]
    > A pointer is generally NOT thought of as a TYPE in programming, it's a
    > pointer to an address.


    What you just said doesn't make sense in English.

    > Technically speaking when you examine a pointers TYPE it's some kind of
    > INTEGER TYPE, suitable for the memory addressing system.


    And that's simply not true in any language I know (except maybe
    assembler, and very early C). A pointer does *not* have an
    integral type; it has a pointer type.

    > IF you think a pointer should be described as a TYPE in the
    > context of the C++ standards... IDGAF but it just poves what
    > an asshole you are.


    He never said that a pointer was a type. He said that in C++,
    there are pointer types. It would help if you could read.

    > To post this bullshit in a beginners forum in a deliberate
    > attempt to mislead and confuse people,


    Now that's something that would apply to your own postings.

    --
    James Kanze
     
    James Kanze, Jan 9, 2011
    #10
  11. Paul

    James Kanze Guest

    On Jan 9, 10:43 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
    > wrote:

    > Now, just checking the standard I didn't find the wording that
    > I remember, but I found this little gem:


    > 3.4.5/7 ... "the class pointed to by the pointer expression"


    > Clearly some intelligence is needed in order to understand that. ;-)


    I presume that the authors of the standard got tired of
    inserting the word type everywhere where it was obvious.
    Formally, that should doubtlessly be "the object of class type
    pointed to by the expression of pointer type". Which is, IMHO,
    a bit verbose. But if you think that the standard is too short
    and too succinct, you can ask Pete to change it (and everywhere
    else such shortcuts in wording occur).

    --
    James Kanze
     
    James Kanze, Jan 9, 2011
    #11
  12. Paul

    James Kanze Guest

    On Jan 9, 9:16 pm, Keith Thompson <> wrote:
    > Leigh Johnston <> writes:


    > [...]
    >
    > There's some genuine confusion on this point, and it's fairly easy to
    > avoid.


    > The unqualified word "pointer" is ambiguous. It can refer, in
    > different contexts, to a pointer object, to a pointer value, or to
    > a pointer type. (The C standard, for example, says that malloc()
    > returns a pointer, meaning a pointer value; I'm not sure whether
    > the C++ standard does something similar.)


    Well, not about malloc. (All it says about malloc is see the C
    standard.) But in general, if the context is clear (and it
    usually is to anyone who understands the difference between
    objects, values, expressions and types), the C++ standard does
    say things like "pointer expression", rather than "expression
    with pointer type".

    > Usually the meaning is sufficiently clear from the context,
    > but sometimes it's best to avoid using the word "pointer",
    > instead referring explicitly to a pointer object, a pointer
    > value, or a pointer type.


    The same thing holds for a lot of other things, and not just in
    the standard. If the program contains "int a;", we'll often say
    that a is an int, when what we really mean is that a is an
    object of type int. At some point, it just gets tiresome
    constantly repeating phrases like "object of type", and the
    meaning is perfectly clear to anyone who isn't a complete idiot.

    --
    James Kanze
     
    James Kanze, Jan 10, 2011
    #12
  13. James Kanze <> writes:
    > On Jan 9, 9:16 pm, Keith Thompson <> wrote:
    >> Leigh Johnston <> writes:

    >
    >> [...]
    >>
    >> There's some genuine confusion on this point, and it's fairly easy to
    >> avoid.

    >
    >> The unqualified word "pointer" is ambiguous. It can refer, in
    >> different contexts, to a pointer object, to a pointer value, or to
    >> a pointer type. (The C standard, for example, says that malloc()
    >> returns a pointer, meaning a pointer value; I'm not sure whether
    >> the C++ standard does something similar.)

    >
    > Well, not about malloc. (All it says about malloc is see the C
    > standard.) But in general, if the context is clear (and it
    > usually is to anyone who understands the difference between
    > objects, values, expressions and types), the C++ standard does
    > say things like "pointer expression", rather than "expression
    > with pointer type".


    That's not quite the same thing. In "pointer expression", the word
    "pointer" qualifies the word "expression", and it's clear that a
    pointer expression is an expression with pointer type (I should have
    mentioned expressions in addition to objects, values, and types).
    I was talking about the unadorned word "pointer".

    For example (I just checked this), the C++ standard says a
    new-expression "returns a pointer to the object created".

    >> Usually the meaning is sufficiently clear from the context,
    >> but sometimes it's best to avoid using the word "pointer",
    >> instead referring explicitly to a pointer object, a pointer
    >> value, or a pointer type.

    >
    > The same thing holds for a lot of other things, and not just in
    > the standard. If the program contains "int a;", we'll often say
    > that a is an int, when what we really mean is that a is an
    > object of type int. At some point, it just gets tiresome
    > constantly repeating phrases like "object of type", and the
    > meaning is perfectly clear to anyone who isn't a complete idiot.


    Agreed, mostly.

    On the other hand, it's been argued by some that "a pointer" can
    only be a pointer object, not a pointer value. Both the C and
    C++ standards at least sometimes refer to a pointer value just as
    "a pointer". (They do so in a context where there's little risk
    of ambiguity.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 10, 2011
    #13
  14. James Kanze <> writes:
    > On Jan 9, 10:43 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
    > > wrote:
    >
    >> Now, just checking the standard I didn't find the wording that
    >> I remember, but I found this little gem:

    >
    >> 3.4.5/7 ... "the class pointed to by the pointer expression"

    >
    >> Clearly some intelligence is needed in order to understand that. ;-)

    >
    > I presume that the authors of the standard got tired of
    > inserting the word type everywhere where it was obvious.
    > Formally, that should doubtlessly be "the object of class type
    > pointed to by the expression of pointer type". Which is, IMHO,
    > a bit verbose. But if you think that the standard is too short
    > and too succinct, you can ask Pete to change it (and everywhere
    > else such shortcuts in wording occur).


    No, if you look at the context I think it means "the type of the
    object of class type pointed to by the expression of pointer type".

    I'd say it's a reasonable verbal shorthand, and I wouldn't
    necessarily recommend changing it.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 10, 2011
    #14
  15. Paul

    James Kanze Guest

    On Jan 10, 6:19 pm, Keith Thompson <> wrote:
    > James Kanze <> writes:
    > > On Jan 9, 10:43 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
    > > > wrote:


    > >> Now, just checking the standard I didn't find the wording that
    > >> I remember, but I found this little gem:


    > >> 3.4.5/7 ... "the class pointed to by the pointer expression"


    > >> Clearly some intelligence is needed in order to understand that. ;-)


    > > I presume that the authors of the standard got tired of
    > > inserting the word type everywhere where it was obvious.
    > > Formally, that should doubtlessly be "the object of class type
    > > pointed to by the expression of pointer type". Which is, IMHO,
    > > a bit verbose. But if you think that the standard is too short
    > > and too succinct, you can ask Pete to change it (and everywhere
    > > else such shortcuts in wording occur).


    > No, if you look at the context I think it means "the type of the
    > object of class type pointed to by the expression of pointer type".


    Maybe. I didn't look it up in context. All I was concerned
    with was giving some idea as to how verbose the results could
    end up.

    > I'd say it's a reasonable verbal shorthand, and I wouldn't
    > necessarily recommend changing it.


    My last sentence was meant to be ironic. I can't imagine anyone
    really thinking that the standard is too short and to succinct,
    and I definitely don't want this sort of change to take place.

    --
    James Kanze
     
    James Kanze, Jan 11, 2011
    #15
    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.

Share This Page