qualified name VS unqualified name in class template.

[Wayne Shu]

Hey, guys.

There is a problem.
e.g.

template <typename T>
class foo
{
public:
foo();
~foo();
private:
static size_t bar;
};

template <typename T>
size_t foo<T>::bar = 0;

template <typename T>
foo<T>::foo()
{
++bar; // (1)
}

template <typename T>
foo<T>::~foo()
{
--bar; // (2)
}

Note the place (1), (2), it can be replaced with
++foo<T>::bar;
--foo<T>::bar;

The qualified name and unqualified name are all OK,
and most c++ book use the qualified name preferable.
I know that it is something related with the name lookup.
but I don't know the details.

Does it have somebody explain it for me??
thanks.


Regards.

 

[Alf P. Steinbach]

* Wayne Shu:

There is a problem.

Is there?

e.g.

template <typename T>
class foo
{
public:
foo();
~foo();
private:
static size_t bar;
};

template <typename T>
size_t foo<T>::bar = 0;

template <typename T>
foo<T>::foo()
{
++bar; // (1)
}

template <typename T>
foo<T>::~foo()
{
--bar; // (2)
}

Note the place (1), (2), it can be replaced with
++foo<T>::bar;
--foo<T>::bar;

The qualified name and unqualified name are all OK,
and most c++ book use the qualified name preferable.
I know that it is something related with the name lookup.
but I don't know the details.

Does it have somebody explain it for me??

It may have been just a basic instinct or style on the part of the
authors, it may be that you've misunderstood the context, that the
books' examples haven't been exactly equivalent to the code you present.
You don't say which books or which examples that befuddle you.
Without that information further discussion would be just as much pure
speculation as this short reply. ;-)

 

[Wayne Shu]

* Wayne Shu:




Is there?













It may have been just a basic instinct or style on the part of the
authors, it may be that you've misunderstood the context, that the
books' examples haven't been exactly equivalent to the code you present.

The book is "C++ Template The Complete Guide",
and the example is the section 16.3 "The Curiously Recurring Template
Pattern"
The complete code is

// inherit/objectcounter.hpp
template <typename CountedType>
class ObjectCounter {
private:
static size_t count; // number of existing objects

protected:
// default constructor
ObjectCounter() {
++ObjectCounter<CountedType>::count;
}

// copy constructor
ObjectCounter (ObjectCounter<CountedType> const&) {
++ObjectCounter<CountedType>::count;
}

// destructor
~ObjectCounter() {
--ObjectCounter<CountedType>::count;
}

public:
// return number of existing objects:
static size_t live() {
return ObjectCounter<CountedType>::count;
}
};

// initialize counter with zero
template <typename CountedType>
size_t ObjectCounter<CountedType>::count = 0;

// inherit/testcounter.cpp
#include "objectcounter.hpp"
#include <iostream>

template <typename CharT>
class MyString : public ObjectCounter<MyString<CharT> > {
//...
};

int main()
{
MyString<char> s1, s2;
MyString<wchar_t> ws;

std::cout << "number of MyString<char>: "
<< MyString<char>::live() << std::endl;
std::cout << "number of MyString<wchar_t>: "
<< ws.live() << std::endl;
}

 

[Alf P. Steinbach]

* Wayne Shu:

The book is "C++ Template The Complete Guide",
and the example is the section 16.3 "The Curiously Recurring Template
Pattern"
The complete code is

// inherit/objectcounter.hpp
template <typename CountedType>
class ObjectCounter {
private:
static size_t count; // number of existing objects

protected:
// default constructor
ObjectCounter() {
++ObjectCounter<CountedType>::count;
}

// copy constructor
ObjectCounter (ObjectCounter<CountedType> const&) {
++ObjectCounter<CountedType>::count;
}

// destructor
~ObjectCounter() {
--ObjectCounter<CountedType>::count;
}

public:
// return number of existing objects:
static size_t live() {
return ObjectCounter<CountedType>::count;
}
};

[snip]

Well, David Vandevoorde & Nicolai Josuttis are very compentent folks,
but I see no technical need for the qualification in this case.

If you post this to [comp.lang.c++.moderated] perhaps Daveed will
explain the reason(s).

I'd guess it's just a coding convention to avoid the problems that
unqualified names in template code can cause in other contexts, or to be
very explicit (very clear what 'count' means), which is generally good,
in the same vein that "unnecessary" parentheses may be used for clarity.

Hth.,

- Alf

 

[vandevoorde]

* Wayne Shu:

The book is "C++ Template The Complete Guide",
and the example is the section 16.3 "The Curiously Recurring Template
Pattern"
The complete code is

// inherit/objectcounter.hpp
template <typename CountedType>
class ObjectCounter {
private:
static size_t count; // number of existing objects

protected:
// default constructor
ObjectCounter() {
++ObjectCounter<CountedType>::count;
}

// copy constructor
ObjectCounter (ObjectCounter<CountedType> const&) {
++ObjectCounter<CountedType>::count;
}

// destructor
~ObjectCounter() {
--ObjectCounter<CountedType>::count;
}

public:
// return number of existing objects:
static size_t live() {
return ObjectCounter<CountedType>::count;
}
};

[snip]

Well, DavidVandevoorde& Nicolai Josuttis are very compentent folks,
but I see no technical need for the qualification in this case.

If you post this to [comp.lang.c++.moderated] perhapsDaveedwill
explain the reason(s).

(I can reply here too ;-)

I'd guess it's just a coding convention to avoid the problems that
unqualified names in template code can cause in other contexts, or to be
very explicit (very clear what 'count' means), which is generally good,
in the same vein that "unnecessary" parentheses may be used for clarity.

Yes, it was just written that way to emphasize the fact that we're
referring to something stored in the base class itself (the class
template is later used as a base class instantiated over the derived
class, and the aim was to help the reader not look for "count" in
places that are too far away). A note in the text would have been a
good idea.

Also, as I think you suggest, in templates it's often a good idea to
make your names as explicit as reasonable to avoid changes in binding
caused by harmless-looking changes. In this particular instance, that
may not be a strong argument though.

Daveed