member function names identical to class names

[Ares Lagae]

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

 

[Victor Bazarov]

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

 

[Ares Lagae]

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:erson". 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

 

[Richard Herring]

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 .

 

[Victor Bazarov]

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

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:erson". 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...

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

 

[Richard Herring]

[...]

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.

[...]

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.

 

[Ares Lagae]

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

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

 

[Richard Herring]

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.

 

[Ares Lagae]

Richard Herring wrote:

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