member function names identical to class names

Discussion in 'C++' started by Ares Lagae, Sep 23, 2004.

  1. Ares Lagae

    Ares Lagae Guest

    When adopting the coding style of the standard C++ library, you often run
    into naming problems because class names are lower case, and member
    functions do not have get/set prefixes.

    For example:
    - The class stringstream has a member function "string stringstream::str()".
    It would be more logical to name it "string stringstream::string()".
    - The class ios_base has a member function "locale ios_base::getloc()". It
    would be more logical to name it "locale ios_base::locale()". Especially
    because the "get" prefix is never used in the standard library for
    inspectors.

    Lets consider that problem (I do not want to discuss coding styles, or which
    name is the best for a member function).

    Consider the following code snippet:

    class foo {};

    class bar
    {
    public:
    foo foo()
    {
    return foo_;
    }
    private:
    foo foo_;
    };

    Obviously this does not compile. Also changing the order of the private and
    public part does not help.

    class bar
    {
    private:
    foo foo_;
    public:
    foo foo()
    {
    return foo_;
    }
    };

    Adding "class" solves the problem:

    class bar
    {
    public:
    class foo foo()
    {
    return foo_;
    }
    private:
    class foo foo_;
    };

    Now suppose the class foo is a class template.

    template <typename T>
    class foo {};

    The obvious solution does not work.

    class bar
    {
    public:
    class foo<int> foo()
    {
    return foo_;
    }
    private:
    class foo<int> foo_;
    };

    Have I missed something or used an incorrect syntax ?

    Amazingly, changing the order of the private and public part now does help.

    class bar
    {
    private:
    class foo<int> foo_;
    public:
    class foo<int> foo()
    {
    return foo_;
    }
    };

    Is there somewhere more information available about issues like this ?

    best regards,
    Ares Lagae
     
    Ares Lagae, Sep 23, 2004
    #1
    1. Advertising

  2. Ares Lagae wrote:
    > When adopting the coding style of the standard C++ library, you often run
    > into naming problems because class names are lower case, and member
    > functions do not have get/set prefixes.


    No, I don't run into issues like that, why do you think I do?

    > [...]
    > Is there somewhere more information available about issues like this ?


    Well, the standard library naming convention never struck me an confusing,
    and whatever convention we're following here at work is a convention and
    is supposed to make sense to everybody to be adopted. So, no issues so
    far.

    As to your example

    class foo {};

    class bar {
    public:
    foo foo();
    };

    It's clear nonsense because class bar should simply have the operator foo
    instead of oddly named function.

    Victor
     
    Victor Bazarov, Sep 23, 2004
    #2
    1. Advertising

  3. Ares Lagae

    Ares Lagae Guest

    Victor Bazarov wrote:

    > Ares Lagae wrote:
    >> When adopting the coding style of the standard C++ library, you often run
    >> into naming problems because class names are lower case, and member
    >> functions do not have get/set prefixes.

    >
    > No, I don't run into issues like that, why do you think I do?


    Suppose you have a class color, and a class pen. Adopting the coding style
    of the standard C++ library, pen would have a member function "color
    pen::color()", and you would have a problem. You can solve this problem
    like the C++ standard library does: rename the member function, and
    introduce a less logical name. I hope you recognize this situation is
    identical to the the "locale ios_base::getloc()" example.

    When using aggregation, sometimes the role name can be used. For example,
    when you have a class person and a class account, you would introduce a
    member function "person account::holder()" instead of "person
    account::person". However, there are many cases in which a role name is not
    obvious (like in the pen/color example). Then you run into the problem I
    describe.

    I explicitely mentioned I did not want to discuss coding style, or wether
    the names in the standard C++ library are logical or not...

    >
    > As to your example
    >
    > class foo {};
    >
    > class bar {
    > public:
    > foo foo();
    > };
    >
    > It's clear nonsense because class bar should simply have the operator foo
    > instead of oddly named function.


    Is it? Again, suppose you have a class color, and a class pen. Then you say
    the class pen should have an operator color instead of a member function
    color ? Just because the names match ? If this is the case, I would rather
    not have you coding in my company.

    Best regards,
    Ares Lagae
     
    Ares Lagae, Sep 23, 2004
    #3
  4. In message <u4A4d.3048$09.us.to.verio.net>,
    Victor Bazarov <> writes
    >Ares Lagae wrote:
    >> When adopting the coding style of the standard C++ library, you often run
    >> into naming problems because class names are lower case, and member
    >> functions do not have get/set prefixes.

    >
    >No, I don't run into issues like that, why do you think I do?
    >
    >> [...]
    >> Is there somewhere more information available about issues like this ?

    >
    >Well, the standard library naming convention never struck me an confusing,
    >and whatever convention we're following here at work is a convention and
    >is supposed to make sense to everybody to be adopted. So, no issues so
    >far.
    >
    >As to your example
    >
    >class foo {};
    >
    >class bar {
    >public:
    > foo foo();
    >};
    >
    >It's clear nonsense because class bar should simply have the operator foo
    >instead of oddly named function.
    >

    Hardly nonsense: you may not want an implicit conversion to foo. Giving
    the function the name of the thing it returns is in some circumstances a
    sensible solution. The OP can probably solve his problem by judicious
    use of ::foo .

    --
    Richard Herring
     
    Richard Herring, Sep 23, 2004
    #4
  5. Ares Lagae wrote:
    > Victor Bazarov wrote:
    >
    >
    >>Ares Lagae wrote:
    >>
    >>>When adopting the coding style of the standard C++ library, you often run
    >>>into naming problems because class names are lower case, and member
    >>>functions do not have get/set prefixes.

    >>
    >>No, I don't run into issues like that, why do you think I do?

    >
    >
    > Suppose you have a class color, and a class pen. Adopting the coding style
    > of the standard C++ library, pen would have a member function "color
    > pen::color()", and you would have a problem. You can solve this problem
    > like the C++ standard library does: rename the member function, and
    > introduce a less logical name. I hope you recognize this situation is
    > identical to the the "locale ios_base::getloc()" example.


    To get the color you use 'getcolor', to set it you use 'setcolor'.
    You could have

    operator color& ();

    and

    operator color() const;

    if you want to use your 'pen' where 'color' is expected.

    > When using aggregation, sometimes the role name can be used. For example,
    > when you have a class person and a class account, you would introduce a
    > member function "person account::holder()" instead of "person
    > account::person". However, there are many cases in which a role name is not
    > obvious (like in the pen/color example). Then you run into the problem I
    > describe.


    No, once again, _I_ don't run into problems like that. It seems that
    you're creating your own problems.

    > I explicitely mentioned I did not want to discuss coding style, or wether
    > the names in the standard C++ library are logical or not...


    What did you want to discuss? Some kind of solution to purposely have
    the names of members the same as names of accessor functions? Or names
    of members the same as type-ids? Perhaps if you just explained what is
    it you're trying to ultimately achieve...

    >
    >
    >>As to your example
    >>
    >>class foo {};
    >>
    >>class bar {
    >>public:
    >> foo foo();
    >>};
    >>
    >>It's clear nonsense because class bar should simply have the operator foo
    >>instead of oddly named function.

    >
    >
    > Is it? Again, suppose you have a class color, and a class pen. Then you say
    > the class pen should have an operator color instead of a member function
    > color ?


    Yes.

    > Just because the names match ?


    No. Because that _makes_sense_.

    > If this is the case, I would rather
    > not have you coding in my company.


    I am not coding in your company, nor do I want to (judging by the problems
    you seem to have).

    V
     
    Victor Bazarov, Sep 23, 2004
    #5
  6. In message <55C4d.3052$09.us.to.verio.net>,
    Victor Bazarov <> writes
    >Ares Lagae wrote:
    >> Victor Bazarov wrote:
    >>
    >>>Ares Lagae wrote:


    [...]
    >>>

    >> Suppose you have a class color, and a class pen. Adopting the
    >>coding style
    >> of the standard C++ library, pen would have a member function "color
    >> pen::color()", and you would have a problem. You can solve this problem
    >> like the C++ standard library does: rename the member function, and
    >> introduce a less logical name. I hope you recognize this situation is
    >> identical to the the "locale ios_base::getloc()" example.

    >
    >To get the color you use 'getcolor', to set it you use 'setcolor'.
    >You could have
    >
    > operator color& ();
    >
    >and
    >
    > operator color() const;
    >
    >if you want to use your 'pen' where 'color' is expected.


    I don't see anything in what AL has posted that suggests that he wants
    to do this. He just wants the member function pen::color() to return
    something of type ::color. It isn't difficult; he just needs to use a
    scope resolution operator to distinguish them.

    [...]
    >>
    >>>As to your example
    >>>
    >>>class foo {};
    >>>
    >>>class bar {
    >>>public:
    >>> foo foo();
    >>>};
    >>>
    >>>It's clear nonsense because class bar should simply have the operator foo
    >>>instead of oddly named function.

    >> Is it? Again, suppose you have a class color, and a class pen. Then
    >>you say
    >> the class pen should have an operator color instead of a member function
    >> color ?

    >
    >Yes.
    >
    >> Just because the names match ?

    >
    >No. Because that _makes_sense_.


    You _appear_ to be advocating that any class A which happens to contain
    a B should have an implicit conversion to B. I hope you don't mean it;
    most people would say that was a highly evil thing to do.

    --
    Richard Herring
     
    Richard Herring, Sep 23, 2004
    #6
  7. Ares Lagae

    Ares Lagae Guest


    > It isn't difficult; he just needs to use a
    > scope resolution operator to distinguish them.


    Yes, I am aware that the scope resolution operator solves the problem. I was
    wondering how to extend the "class foo foo()" syntax to the class template
    case, and why changing the public and private part helps in the class
    template case, but not when foo isn't a class template ...


    >>
    >>No. Because that _makes_sense_.

    >
    > You _appear_ to be advocating that any class A which happens to contain
    > a B should have an implicit conversion to B. I hope you don't mean it;
    > most people would say that was a highly evil thing to do.


    I had the same impression.

    Ares Lagae
     
    Ares Lagae, Sep 24, 2004
    #7
  8. In message <>, Ares Lagae
    <> writes
    >
    >> It isn't difficult; he just needs to use a
    >> scope resolution operator to distinguish them.

    >
    >Yes, I am aware that the scope resolution operator solves the problem. I was
    >wondering how to extend the "class foo foo()" syntax to the class template
    >case,


    I wasn't thinking of class foo foo() but ::foo foo(). Or N::foo foo(),
    if everything is within namespace N.

    >and why changing the public and private part helps in the class
    >template case, but not when foo isn't a class template ...


    I suspect it's not public vs. private but order of declaration that's
    the problem. Once you have declared member function foo, in the context
    of class bar the unqualified name now means the member function, not the
    type, so you have to qualify it to get the type.

    --
    Richard Herring
     
    Richard Herring, Sep 24, 2004
    #8
  9. Ares Lagae

    Ares Lagae Guest

    Richard Herring wrote:


    >>and why changing the public and private part helps in the class
    >>template case, but not when foo isn't a class template ...

    >
    > I suspect it's not public vs. private but order of declaration that's
    > the problem. Once you have declared member function foo, in the context
    > of class bar the unqualified name now means the member function, not the
    > type, so you have to qualify it to get the type.


    Indeed. But then I wonder why changing the order of declaration helps in the
    case of the template classes, but does not help in the case of the
    non-template classes ... Anyway, it does not really matter, but I'm just
    curious :)

    Ares Lagae
     
    Ares Lagae, Sep 24, 2004
    #9
    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. E11
    Replies:
    1
    Views:
    4,955
    Thomas Weidenfeller
    Oct 12, 2005
  2. Replies:
    12
    Views:
    737
    fluden
    Feb 11, 2005
  3. ciccio
    Replies:
    3
    Views:
    299
    Ron Natalie
    Jan 11, 2008
  4. Praetorian
    Replies:
    11
    Views:
    2,385
    James Kanze
    Apr 3, 2008
  5. Daniel Berger
    Replies:
    3
    Views:
    150
    Eric Hodel
    Dec 4, 2006
Loading...

Share This Page