Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Naming conventions for private virtual methods

33 views
Skip to first unread message

Daniel

unread,
Feb 14, 2014, 11:27:52 AM2/14/14
to
I know, nobody likes this kind of question, but there aren't many questions these days, so ...

Consider a case of private virtual inheritance where the motivation is to have overloading on the preferred method name "value".

class base
{
public:
void value(int val)
{
// calls value_
}
void value(long val)
{
// calls value_
}
void value(long long val)
{
// calls value_
}
private:
virtual void value_(long long val) = 0;
};

class derived : public base
{
private:
// implements value_
};

Can anyone suggest a reasonable naming convention for the overridable private method value_? I've seen variants of "doValue", "value_long_long", and "value_event". Any commonly used conventions?

Thanks,
Daniel

Victor Bazarov

unread,
Feb 14, 2014, 11:53:14 AM2/14/14
to
On 2/14/2014 11:27 AM, Daniel wrote:
> I know, nobody likes this kind of question, but there aren't many
questions these days, so ...
>
> Consider a case of private virtual inheritance where the motivation
> is

There is no private virtual inheritance in your post, just so we talk
about the same thing, a private virtual inheritance is this relationship
between classes A and B:

class A { ... };
class B : virtual A { ... };

to have overloading on the preferred method name "value".
>
> class base
> {
> public:
> void value(int val)
> {
> // calls value_
> }
> void value(long val)
> {
> // calls value_
> }
> void value(long long val)
> {
> // calls value_
> }
> private:
> virtual void value_(long long val) = 0;
> };
>
> class derived : public base
> {
> private:
> // implements value_
> };
>
> Can anyone suggest a reasonable naming convention for the overridable
> private method value_? I've seen variants of "doValue",
> "value_long_long", and "value_event". Any commonly used conventions?

From the implementation 'value' here is a "setter", so it might make
sense to indicate that.

Another argument is that the overloaded function shall be specific to
each class deriving from 'base', so it might make sense to add
"specific" to it (either as a suffix or as a prefix).

And of course I admit that I am not aware of any convention you're
alluding to in your message. If there exists something of that sort, I
have never come across it, or cannot recall such an occurrence.

V
--
I do not respond to top-posted replies, please don't ask

Paavo Helde

unread,
Feb 14, 2014, 12:34:57 PM2/14/14
to
Daniel <daniel...@gmail.com> wrote in
news:0be77c62-9923-4477...@googlegroups.com:
FWIW, I am naming private/protected virtual functions (this means most
virtual functions) with prefix Do. In your example it would be something
like DoSetValue(). However, I would not have multiple functions calling
it, instead there would be a single nonvirtual SetValue() which is
checking pre- and postconditions etc. If overloads are indeed needed, I
would probably need to invent a third name for them.

hth
Paavo



Öö Tiib

unread,
Feb 14, 2014, 12:46:25 PM2/14/14
to
On Friday, 14 February 2014 18:27:52 UTC+2, Daniel wrote:
> Can anyone suggest a reasonable naming convention for the overridable
> private method value_? I've seen variants of "doValue",
> "value_long_long", and "value_event". Any commonly used conventions?

I prefer to avoid setters; when still needed I prefer to indicate that
in name as "set value". Getters I prefer to name just "value". For
private virtual I use prefix "do" so for your example ... "do set value".

Note that it is about naming so usually I follow whatever conventions
code-base under work already uses. There are no "ultimate"
conventions. There can be convention or there can be awful mess caused
by people with different "ultimates".

Daniel

unread,
Feb 14, 2014, 1:28:26 PM2/14/14
to
On Friday, February 14, 2014 11:53:14 AM UTC-5, Victor Bazarov wrote:
>
> From the implementation 'value' here is a "setter", so it might make
> sense to indicate that.
>
> Another argument is that the overloaded function shall be specific to
> each class deriving from 'base', so it might make sense to add
> "specific" to it (either as a suffix or as a prefix).
>
That's helpful, thanks,
Daniel
0 new messages