why did c++ add the class keyword?

Discussion in 'C++' started by 440gtx@email.com, Sep 24, 2006.

  1. Guest

    The class keyword created a lot of confusion that resulted in a popular
    style that says struct is appropriate for POD (plain old data) and
    class is appropriate for fancier things (member functions, data hiding,
    inheritance). And indeed the FAQ even advocates this usage model. I
    myself have broken from this tradition because I find the public
    defaulting of struct more appropriate than class and thus prefer it
    100% of the time. The benefit is I no longer need to unhide the
    constructor and I don't lose any explicit control over privacy. So what
    was the reason for introducing the class keyword?
     
    , Sep 24, 2006
    #1
    1. Advertising

  2. Steve Pope Guest

    <> wrote:

    >The class keyword created a lot of confusion that resulted in a popular
    >style that says struct is appropriate for POD (plain old data) and
    >class is appropriate for fancier things (member functions, data hiding,
    >inheritance). And indeed the FAQ even advocates this usage model. I
    >myself have broken from this tradition because I find the public
    >defaulting of struct more appropriate than class and thus prefer it
    >100% of the time.


    (OT)

    I also always use struct, since normally the first element of
    a struct or class is public, and therefore it saves a keyword.
    I find the theory that if there's so much as a member function it
    should be a class unconvincing. Everyone knows a struct
    and a class are the same thing.

    But please note I am not a software engineer in the first place. :)

    Steve
     
    Steve Pope, Sep 24, 2006
    #2
    1. Advertising

  3. wrote:

    > The class keyword created a lot of confusion that resulted in a popular
    > style that says struct is appropriate for POD (plain old data) and
    > class is appropriate for fancier things (member functions, data hiding,
    > inheritance). And indeed the FAQ even advocates this usage model. I
    > myself have broken from this tradition because I find the public
    > defaulting of struct more appropriate than class and thus prefer it
    > 100% of the time. The benefit is I no longer need to unhide the
    > constructor and I don't lose any explicit control over privacy. So what
    > was the reason for introducing the class keyword?
    >


    Most of the time, I use the class keyword and
    annotate the sections. I have sections for public,
    protected and private in my stencil. The class
    keyword helps me to distinguish object-oriented
    projects from ad-hoc or C style projects.

    My philosophy is that everything should be private
    unless proven otherwise. Information is distributed
    on a need to know basis (high encapsulation). This
    really helps in debugging, especially on large
    projects.

    For demos and experiments, I use the struct.


    --
    Thomas Matthews

    C++ newsgroup welcome message:
    http://www.slack.net/~shiva/welcome.txt
    C++ Faq: http://www.parashift.com/c -faq-lite
    C Faq: http://www.eskimo.com/~scs/c-faq/top.html
    alt.comp.lang.learn.c-c++ faq:
    http://www.comeaucomputing.com/learn/faq/
    Other sites:
    http://www.josuttis.com -- C++ STL Library book
    http://www.sgi.com/tech/stl -- Standard Template Library
     
    Thomas Matthews, Sep 24, 2006
    #3
  4. Bo Persson Guest

    wrote:
    > The class keyword created a lot of confusion that resulted in a
    > popular style that says struct is appropriate for POD (plain old
    > data) and class is appropriate for fancier things (member functions,
    > data hiding, inheritance). And indeed the FAQ even advocates this
    > usage model. I myself have broken from this tradition because I find
    > the public defaulting of struct more appropriate than class and thus
    > prefer it 100% of the time. The benefit is I no longer need to
    > unhide
    > the constructor and I don't lose any explicit control over privacy.
    > So what was the reason for introducing the class keyword?


    I believe the current state is just an accident in the evolution of
    the language.

    Originally the class concept was added to C (in the language "C with
    classes"). At that stage structs and unions were still identical to
    their C language counterparts.

    Only later did someone ask "Why can't I have member functions in a
    struct?". And there were no good reasons...



    Bo Persson
     
    Bo Persson, Sep 24, 2006
    #4
  5. wrote:
    > The class keyword created a lot of confusion that resulted in a popular
    > style that says struct is appropriate for POD (plain old data) and
    > class is appropriate for fancier things (member functions, data hiding,
    > inheritance). And indeed the FAQ even advocates this usage model. I
    > myself have broken from this tradition because I find the public
    > defaulting of struct more appropriate than class and thus prefer it
    > 100% of the time. The benefit is I no longer need to unhide the
    > constructor and I don't lose any explicit control over privacy. So what
    > was the reason for introducing the class keyword?
    >



    When C++ was designed, it was to be mostly compatible with C, while
    providing an object orientated language. Proper OO dictates that
    objects should have private data by default, and let members be
    explicitly public. If they were to make struct public by default, it
    would break a lot of C code so therefore the class keyword would be used
    for classes, and struct for classes that default to public. Over the
    years it became accepted that structs should be used for POD types, and
    classes for proper OO types. This system, while a little confusing,
    allowed people to code C++ in a proper OO manner, while keeping C++ as
    compatible with C as possible.

    In all cases, it is probably best to explicitly state if a member is to
    be private, protected or public.
     
    Gregory Currie, Sep 26, 2006
    #5
  6. Earl Purple Guest

    Steve Pope wrote:
    >
    > I also always use struct, since normally the first element of
    > a struct or class is public, and therefore it saves a keyword.


    My first element is usually private because I put members first then
    functions. Just my style, I guess. I know a lot of people like the
    public at the top because then as users they see first what they are
    going to need to use the class.

    Private methods (other than possibly a disabled copy-constructor and
    operator=) generally go at the bottom of my classes, thus I have 2
    private sections.

    > I find the theory that if there's so much as a member function it
    > should be a class unconvincing. Everyone knows a struct
    > and a class are the same thing.


    I will sometimes use struct for functors that have no member variables
    at all. Probably because I've seen others use it in sample code.

    Generally I will use the class keyword unless everything in it is
    public. And generally member variables will be public only if it's
    grouped-together data and then it would generally have no member
    functions other than trivial constructors (often one default
    constructor and one that has initial values for all the members).
     
    Earl Purple, Sep 26, 2006
    #6
  7. Bo Persson wrote:
    > wrote:
    >> The class keyword created a lot of confusion that resulted in a
    >> popular style that says struct is appropriate for POD (plain old
    >> data) and class is appropriate for fancier things (member functions,
    >> data hiding, inheritance). And indeed the FAQ even advocates this
    >> usage model. I myself have broken from this tradition because I find
    >> the public defaulting of struct more appropriate than class and thus
    >> prefer it 100% of the time. The benefit is I no longer need to
    >> unhide
    >> the constructor and I don't lose any explicit control over privacy.
    >> So what was the reason for introducing the class keyword?

    >
    > I believe the current state is just an accident in the evolution of
    > the language.
    >
    > Originally the class concept was added to C (in the language "C with
    > classes"). At that stage structs and unions were still identical to
    > their C language counterparts.
    >
    > Only later did someone ask "Why can't I have member functions in a
    > struct?". And there were no good reasons...


    My beef with class is that it's also in the tag name space. The tag name
    space is a language design mistake. I suggested back in the 80's to
    Bjarne that the class be in the regular name space, and leave struct in
    the tag name space for C compatibility. He replied there was too much
    existing C++ code to make such a change.

    With the D programming language there was a chance to fix that. Structs
    are for POD, classes are for objects, and both are in the regular name
    space (there is no tag name space in D). Both class and struct default
    to public.

    Walter Bright
    www.digitalmars.com C, C++, D programming language compilers
     
    Walter Bright, Sep 27, 2006
    #7
  8. Bo Persson Guest

    Walter Bright wrote:
    > Bo Persson wrote:
    >> wrote:
    >>> The class keyword created a lot of confusion that resulted in a
    >>> popular style that says struct is appropriate for POD (plain old
    >>> data) and class is appropriate for fancier things (member
    >>> functions,
    >>> data hiding, inheritance). And indeed the FAQ even advocates this
    >>> usage model. I myself have broken from this tradition because I
    >>> find
    >>> the public defaulting of struct more appropriate than class and
    >>> thus
    >>> prefer it 100% of the time. The benefit is I no longer need to
    >>> unhide
    >>> the constructor and I don't lose any explicit control over
    >>> privacy.
    >>> So what was the reason for introducing the class keyword?

    >>
    >> I believe the current state is just an accident in the evolution of
    >> the language.
    >>
    >> Originally the class concept was added to C (in the language "C
    >> with
    >> classes"). At that stage structs and unions were still identical to
    >> their C language counterparts.
    >>
    >> Only later did someone ask "Why can't I have member functions in a
    >> struct?". And there were no good reasons...

    >
    > My beef with class is that it's also in the tag name space. The tag
    > name space is a language design mistake.


    I guess so. I don't seem to write code where it matters, so it's not a
    big deal for me. Perhaps more of a problem to compiler writers?

    > I suggested back in the 80's
    > to Bjarne that the class be in the regular name space, and leave
    > struct in the tag name space for C compatibility. He replied there
    > was too much existing C++ code to make such a change.
    >
    > With the D programming language there was a chance to fix that.
    > Structs are for POD, classes are for objects, and both are in the
    > regular name space (there is no tag name space in D).


    So it seems that there really _were_ reasons to keep the structs
    unchanged. Some of the memcpy-guys are now arguing that they need a
    pod_struct or something, to have the compiler assure the POD-ness of
    their data.

    So, keeping structs as C-style PODs might have been a good idea after
    all. But now there is *way* too much C++ code to make such a change.

    > Both class and struct default to public.


    Typing an additional "public:" per class definition is not big deal,
    and it also serves as documentation. Making it optional could satisfy
    both sides, of course.


    Bo Persson
     
    Bo Persson, Sep 27, 2006
    #8
  9. Earl Purple Guest

    Bo Persson wrote:

    > So it seems that there really _were_ reasons to keep the structs
    > unchanged. Some of the memcpy-guys are now arguing that they need a
    > pod_struct or something, to have the compiler assure the POD-ness of
    > their data.


    Better solution is to have a standard is_pod that can be overloaded for
    user-defined types.

    > So, keeping structs as C-style PODs might have been a good idea after
    > all. But now there is *way* too much C++ code to make such a change.


    Useful for optimisation but something that is_pod can resolve, even if
    the data members are private. basic types and pointers (including
    pointers to functions) would be pods by default.

    Somewhere in between POD and non-POD are movable classes/structs. A
    class is movable if you can move it to another memory location without
    invalidating any of its members. Obviously any external pointers to it
    or its members may become invalidated by such a move.

    Note that not everything is copyable or moveable with memcpy/memmove
    even in C. Well not as a whole set anyway. (How do you copy or move a
    linked-list?).

    > Typing an additional "public:" per class definition is not big deal,
    > and it also serves as documentation. Making it optional could satisfy
    > both sides, of course.


    I agree though having inheritance default to public would be useful
    because that's the most common type of inheritance. I guess they made
    the default private to be "orthogonal".
     
    Earl Purple, Sep 27, 2006
    #9
  10. Bo Persson wrote:
    > Walter Bright wrote:
    >> My beef with class is that it's also in the tag name space. The tag
    >> name space is a language design mistake.

    > I guess so. I don't seem to write code where it matters, so it's not a
    > big deal for me. Perhaps more of a problem to compiler writers?


    It's not too much of a problem in C because the lookups are always
    qualified with 'struct' or 'union', but it's a bit of a mess in C++. The
    names default to being in the main space, but then are pushed into the
    tag space if there are any other declarations with the same name. The
    semantic analyzer has to look in the tag space if it's expecting to see
    a class name based on the context, after first looking in the regular
    space and finding a name that isn't a tag. It's just goofy - and it
    didn't have to be that way.

    >> With the D programming language there was a chance to fix that.
    >> Structs are for POD, classes are for objects, and both are in the
    >> regular name space (there is no tag name space in D).

    > So it seems that there really _were_ reasons to keep the structs
    > unchanged. Some of the memcpy-guys are now arguing that they need a
    > pod_struct or something, to have the compiler assure the POD-ness of
    > their data.


    POD objects and OOP objects are just different and serve different
    design goals. I think that any code design that tries to mix them
    together (with, say, inheritance) is probably a mistake. People coming
    to D programming from C++ at first find the struct(POD)/class(OOP)
    dichotomy to need a bit of getting used to, but once they do, the
    feedback on the choice is clearly positive.

    Structs and classes are like ints and floats. Sure, you can use a float
    as a loop counter, but it's just not meant for that.

    > So, keeping structs as C-style PODs might have been a good idea after
    > all. But now there is *way* too much C++ code to make such a change.


    I agree. C++ is boxed in by legacy code based on decisions made 20 years
    ago. This happens, of course, to all successful languages.

    >> Both class and struct default to public.

    > Typing an additional "public:" per class definition is not big deal,
    > and it also serves as documentation. Making it optional could satisfy
    > both sides, of course.


    It's a minor thing, I agree. It's like a story my father told me. We
    lived in a small town, and he once asked the mayor what the biggest
    problem he faced was. The mayor replied that the town was evenly divided
    between dog lovers and dog haters. Neither side could gain ascendancy,
    so his work was occupied with constantly trying to compromise and
    reconcile the two <g>.

    Walter Bright
    http://www.digitalmars.com
    C, C++, D programming language compilers
     
    Walter Bright, Sep 27, 2006
    #10
    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. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    909
    Mark Rae
    Dec 21, 2006
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,998
    Smokey Grindel
    Dec 2, 2006
  3. Replies:
    6
    Views:
    458
    Peter Otten
    May 10, 2007
  4. Hamilton, William

    RE: keyword checker - keyword.kwlist

    Hamilton, William, May 10, 2007, in forum: Python
    Replies:
    4
    Views:
    356
  5. Daniel Waite
    Replies:
    2
    Views:
    228
    Daniel Waite
    May 2, 2008
Loading...

Share This Page