Same name for a type and a method allowed?

[mczard]

I would like to have a method with a name same as some type in the
same namespace. Is it allowed by the C++ standard? I tried to figure
it out experimentally in gcc, but I get ambiguous results - for
example:

struct Point
{
int x;
int y;
};

struct Utils
{
Point Point()
{
return Point();
}

std::string Point()
{
return "";
}
};

The first method produces compile-time error, but the second method is
ok.

 

[suresh shenoy]

I would like to have a method with a name same as some type in the
same namespace. Is it allowed by the C++ standard? I tried to figure
it out experimentally in gcc, but I get ambiguous results - for
example:

struct Point
{
        int x;
        int y;

};

struct Utils
{
        Point Point()
        {
                return Point();
        }

        std::string Point()
        {
                return "";
        }

};

The first method produces compile-time error, but the second method is
ok.

I believe you need to provide the scope for Point() method.

Suresh M Shenoy

 

[Ian Collins]

I would like to have a method with a name same as some type in the
same namespace. Is it allowed by the C++ standard? I tried to figure
it out experimentally in gcc, but I get ambiguous results - for
example:

struct Point
{
int x;
int y;
};

struct Utils
{
Point Point()
{
return Point();
}

std::string Point()
{
return "";
}
};

The first method produces compile-time error, but the second method is
ok.

While writing :oint Point() resolves the immediate issue, surely a
naming convention that uses the same capitalisation for types and method
names is fraught with perils such as this?

You can't have two methods with the same signature (with does not
include the return type) in the came class, so the two methods could not
coexist.

 

[Juha Nieminen]

I would like to have a method with a name same as some type in the
same namespace. Is it allowed by the C++ standard? I tried to figure
it out experimentally in gcc, but I get ambiguous results - for
example:

struct Point
{
int x;
int y;
};

struct Utils
{
Point Point()
{
return Point();
}

Try to see if this works:

:oint Point()
{
return :oint();
}

 

[mczard]

  Try to see if this works:

        :oint Point()
        {
            return :oint();
        }

Yes, this works with GCC. But is it compliant with ISO C++ for sure?

 

[Ian Collins]

Yes, this works with GCC. But is it compliant with ISO C++ for sure?

It's perfectly legal, but it's still a poor choice of naming convention.

 

[Jeff Schwab]

I would like to have a method with a name same as some type in the
same namespace. Is it allowed by the C++ standard?

Yes, but it's probably not a wonderful idea to exercise this particular
freedom.

struct point { };

void point() { }

int main() { point(); }

I tried to figure
it out experimentally in gcc, but I get ambiguous results - for
example:

struct Point
{
int x;
int y;
};

struct Utils
{
Point Point()
{
return Point();
}

std::string Point()
{
return "";
}
};

Huh? When client code calls Point(), which Point function is supposed
to be called?

If you need a function to create an object of a particular type (and
return it by value), a popular convention is to call the function
make_whatever. For example, see std:air and std::make_pair.

 

[mczard]

It's perfectly legal, but it's still a poor choice of naming convention.

I have a special situation in a smart pointers library:

ref<T> smart_ptr<T>::ref() const;

I think its simplicity is worth repeating the name.

 

[Jeff Schwab]

I have a special situation in a smart pointers library:

ref<T> smart_ptr<T>::ref() const;

I think its simplicity is worth repeating the name.

The standard library has at least two work-arounds for this situation:

(1) Give the type a _t extension, such that a method called size()
returns an object of type size_t (typedef'd to size_type).

(2) Abbreviate the name of the method, but not the name of the type.
For example, stringstream's str() method returns an object of type string.

A third option would be to define your ref<T> template in a separate
namespace. The smart_ptr can provide a typedef for it, so that you will
have:

smart_ptr<T>::ref_type smart_ptr<T>::ref() const;

 

[James Kanze]

The problem isn't just the repetition. The names are too short
to be meaningful. In general, the length of a name should be
inversely proportional to it's visibility. There's nothing
wrong with using i as the name of a local variable---in fact,
it's actually recommended in certain cases. But anything
visible globally requires a longer name.

The standard library has at least two work-arounds for this
situation:

The standard is the standard. It's part of the language. As
such, programmers "know" it (at least in theory), and it can use
a bit more liberty in its naming. (To begin with, calling the
namespace std would not have been acceptable if it hadn't been
the standard.)

(1) Give the type a _t extension, such that a method called size()
returns an object of type size_t (typedef'd to size_type).

That's a convention from C: typedef's end in _t. In many ways,
it's a silly convention, but it's now so established that
there's no point in changing it. Thus, we have size_t and
intmax_t, which are typedefs, but unsigned and long, which are
built-in types. (In C++, of course, wchar_t is a built-in type.
But it's a typedef in C, whence the name.)