This code fails to compile on Comeau C++ and VC++ 7.1 (with language
extensions disabled)
template <class T>
struct B
{
T b;
};
template <class T>
struct D : B<T>
{
void f() { b = 1; }
};
int main()
{
D<int> x;
x.f();
}
Error messages refer to 'b = 1;' with the message 'undefined identifier b'.
Substituting this->b for b or making B a non-template class both make the
code compile.
What's going on here? I was so surprised when I saw this on VC++ that I
assumed it was a compiler bug, but apparently not.
john
25  3142 
"John Harrison" <jo*************@hotmail.com> wrote... This code fails to compile on Comeau C++ and VC++ 7.1 (with language
extensions disabled)
template <class T>
struct B
{
T b;
};
template <class T>
struct D : B<T>
{
void f() { b = 1; }
};
int main()
{
D<int> x;
x.f();
}
Error messages refer to 'b = 1;' with the message 'undefined identifier
b'. Substituting this->b for b or making B a non-template class both make the
code compile.
What's going on here? I was so surprised when I saw this on VC++ that I
assumed it was a compiler bug, but apparently not.
Why do you say "apparently not"? I cannot find anything in the Standard
that would make the look-up of name 'b' in D<T>::f() fail. As far as the
Standard goes, the usual rules of 10.2 should apply. The base class has
to be searched if 'b' is not found in D definition.
14.6/8 says "When looking for the declaration of a name used in a template
definition, the usual lookup rules (3.4.1, 3.4.2) are used for nondependent
names."
3.4.1/8 says "A name used in the definition of a function that is a member
function (9.3)29) of class X shall be declared in one of the following
ways:
- before its use in the block in which it is used or in an enclosing block
(6.3), or
- shall be a member of class X or be a member of a base class of X (10.2),
or ..."
So, "shall be a member of class X or be a member of a base class of X"
should do it. 'b' is a member of the base class.
Well, at least that's how I read it. Perhaps Greg Comeau or other
knowledgeable people will enlighten us both.
Victor
"John Harrison" <jo*************@hotmail.com> wrote... This code fails to compile on Comeau C++ and VC++ 7.1 (with language
extensions disabled)
template <class T>
struct B
{
T b;
};
template <class T>
struct D : B<T>
{
void f() { b = 1; }
};
int main()
{
D<int> x;
x.f();
}
Error messages refer to 'b = 1;' with the message 'undefined identifier
b'. Substituting this->b for b or making B a non-template class both make the
code compile.
What's going on here? I was so surprised when I saw this on VC++ that I
assumed it was a compiler bug, but apparently not.
Why do you say "apparently not"? I cannot find anything in the Standard
that would make the look-up of name 'b' in D<T>::f() fail. As far as the
Standard goes, the usual rules of 10.2 should apply. The base class has
to be searched if 'b' is not found in D definition.
14.6/8 says "When looking for the declaration of a name used in a template
definition, the usual lookup rules (3.4.1, 3.4.2) are used for nondependent
names."
3.4.1/8 says "A name used in the definition of a function that is a member
function (9.3)29) of class X shall be declared in one of the following
ways:
- before its use in the block in which it is used or in an enclosing block
(6.3), or
- shall be a member of class X or be a member of a base class of X (10.2),
or ..."
So, "shall be a member of class X or be a member of a base class of X"
should do it. 'b' is a member of the base class.
Well, at least that's how I read it. Perhaps Greg Comeau or other
knowledgeable people will enlighten us both.
Victor
On Sun, 10 Aug 2003 14:13:59 +0100, "John Harrison" <jo*************@hotmail.com> wrote: This code fails to compile on Comeau C++ and VC++ 7.1 (with language
extensions disabled)
template <class T>
struct B
{
T b;
};
template <class T>
struct D : B<T>
{
void f() { b = 1; }
};
int main()
{
D<int> x;
x.f();
}
Error messages refer to 'b = 1;' with the message 'undefined identifier b'.
Substituting this->b for b or making B a non-template class both make the
code compile.
Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)
It compiles just fine with 7.0, with and without language extensions
disabled (/Za).
What's going on here? I was so surprised when I saw this on VC++ that I
assumed it was a compiler bug, but apparently not.
Apparently it is a compiler bug.
At least, I agree with Victor that the usual look-up rules should apply.
On Sun, 10 Aug 2003 14:13:59 +0100, "John Harrison" <jo*************@hotmail.com> wrote: This code fails to compile on Comeau C++ and VC++ 7.1 (with language
extensions disabled)
template <class T>
struct B
{
T b;
};
template <class T>
struct D : B<T>
{
void f() { b = 1; }
};
int main()
{
D<int> x;
x.f();
}
Error messages refer to 'b = 1;' with the message 'undefined identifier b'.
Substituting this->b for b or making B a non-template class both make the
code compile.
Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)
It compiles just fine with 7.0, with and without language extensions
disabled (/Za).
What's going on here? I was so surprised when I saw this on VC++ that I
assumed it was a compiler bug, but apparently not.
Apparently it is a compiler bug.
At least, I agree with Victor that the usual look-up rules should apply.
"Alf P. Steinbach" wrote:
Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)
Are you also glad that you haven't checked whether you have the EDG
front end? <g> It rejects this code, too.
It compiles just fine with 7.0, with and without language extensions
disabled (/Za).
What's going on here? I was so surprised when I saw this on VC++ that I
assumed it was a compiler bug, but apparently not.
Apparently it is a compiler bug.
At least, I agree with Victor that the usual look-up rules should apply.
Since EDG rejects it, I suspect that the analysis is wrong. I don't
claim to understand two-phase lookup, but it looks to me like 'b' is a
dependent name. After all, its meaning depends on the defintion of B<T>,
and B<T> can be specialized for various T's. During phase one it has to
be explicitly qualified, in order to tell the compiler that not having a
'b' in B<T> is an error.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
"Alf P. Steinbach" wrote:
Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)
Are you also glad that you haven't checked whether you have the EDG
front end? <g> It rejects this code, too.
It compiles just fine with 7.0, with and without language extensions
disabled (/Za).
What's going on here? I was so surprised when I saw this on VC++ that I
assumed it was a compiler bug, but apparently not.
Apparently it is a compiler bug.
At least, I agree with Victor that the usual look-up rules should apply.
Since EDG rejects it, I suspect that the analysis is wrong. I don't
claim to understand two-phase lookup, but it looks to me like 'b' is a
dependent name. After all, its meaning depends on the defintion of B<T>,
and B<T> can be specialized for various T's. During phase one it has to
be explicitly qualified, in order to tell the compiler that not having a
'b' in B<T> is an error.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
On Sun, 10 Aug 2003 10:12:08 -0400, Pete Becker <pe********@acm.org> wrote: "Alf P. Steinbach" wrote:
Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)
Are you also glad that you haven't checked whether you have the EDG
front end? <g> It rejects this code, too.
I'm pretty sure that I don't have that, since I don't have Comeau,
unless it's used by Visual C++ 7.1. It compiles just fine with 7.0, with and without language extensions
disabled (/Za).
>What's going on here? I was so surprised when I saw this on VC++ that I
>assumed it was a compiler bug, but apparently not.
Apparently it is a compiler bug.
At least, I agree with Victor that the usual look-up rules should apply.
Since EDG rejects it, I suspect that the analysis is wrong.
EDG lists Comeau Computing as one of the compilers (or at least, companies)
that use their front-end.
If that's correct that means it's still just two compilers (or compiler
parts) that reject the code: Visual C++ 7.1 and Comeau.
If Visual C++ 7.1 also uses the EDG front-end then it's just one.
On Sun, 10 Aug 2003 10:12:08 -0400, Pete Becker <pe********@acm.org> wrote: "Alf P. Steinbach" wrote:
Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)
Are you also glad that you haven't checked whether you have the EDG
front end? <g> It rejects this code, too.
I'm pretty sure that I don't have that, since I don't have Comeau,
unless it's used by Visual C++ 7.1. It compiles just fine with 7.0, with and without language extensions
disabled (/Za).
>What's going on here? I was so surprised when I saw this on VC++ that I
>assumed it was a compiler bug, but apparently not.
Apparently it is a compiler bug.
At least, I agree with Victor that the usual look-up rules should apply.
Since EDG rejects it, I suspect that the analysis is wrong.
EDG lists Comeau Computing as one of the compilers (or at least, companies)
that use their front-end.
If that's correct that means it's still just two compilers (or compiler
parts) that reject the code: Visual C++ 7.1 and Comeau.
If Visual C++ 7.1 also uses the EDG front-end then it's just one.
> > What's going on here? I was so surprised when I saw this on VC++ that I
assumed it was a compiler bug, but apparently not.
Why do you say "apparently not"?
Because two apparently unrelated compilers produce effectively identical
error messages. I hadn't considered Alf's suggestion that VC++ 7.1 might use
the EDG front end. However Microsoft aren't on EDG's list of corporate
licensees and you might expect them to make a fuss about it if MS were using
EDG.
john
> > What's going on here? I was so surprised when I saw this on VC++ that I
assumed it was a compiler bug, but apparently not.
Why do you say "apparently not"?
Because two apparently unrelated compilers produce effectively identical
error messages. I hadn't considered Alf's suggestion that VC++ 7.1 might use
the EDG front end. However Microsoft aren't on EDG's list of corporate
licensees and you might expect them to make a fuss about it if MS were using
EDG.
john
On Sun, 10 Aug 2003 15:47:03 +0100, "John Harrison" <jo*************@hotmail.com> wrote: >
> What's going on here? I was so surprised when I saw this on VC++ that I
> assumed it was a compiler bug, but apparently not.
Why do you say "apparently not"?
Because two apparently unrelated compilers produce effectively identical
error messages. I hadn't considered Alf's suggestion that VC++ 7.1 might use
the EDG front end. However Microsoft aren't on EDG's list of corporate
licensees and you might expect them to make a fuss about it if MS were using
EDG.
Only about 50% of the licensees are on the public list.
On Sun, 10 Aug 2003 15:47:03 +0100, "John Harrison" <jo*************@hotmail.com> wrote: >
> What's going on here? I was so surprised when I saw this on VC++ that I
> assumed it was a compiler bug, but apparently not.
Why do you say "apparently not"?
Because two apparently unrelated compilers produce effectively identical
error messages. I hadn't considered Alf's suggestion that VC++ 7.1 might use
the EDG front end. However Microsoft aren't on EDG's list of corporate
licensees and you might expect them to make a fuss about it if MS were using
EDG.
Only about 50% of the licensees are on the public list.
"Alf P. Steinbach" wrote:
On Sun, 10 Aug 2003 10:12:08 -0400, Pete Becker <pe********@acm.org> wrote:
"Alf P. Steinbach" wrote:
Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)
Are you also glad that you haven't checked whether you have the EDG
front end? <g> It rejects this code, too.
I'm pretty sure that I don't have that, since I don't have Comeau,
unless it's used by Visual C++ 7.1.
It compiles just fine with 7.0, with and without language extensions
disabled (/Za).
>What's going on here? I was so surprised when I saw this on VC++ that I
>assumed it was a compiler bug, but apparently not.
Apparently it is a compiler bug.
At least, I agree with Victor that the usual look-up rules should apply.
Since EDG rejects it, I suspect that the analysis is wrong.
EDG lists Comeau Computing as one of the compilers (or at least, companies)
that use their front-end.
If that's correct that means it's still just two compilers (or compiler
parts) that reject the code: Visual C++ 7.1 and Comeau.
If Visual C++ 7.1 also uses the EDG front-end then it's just one.
Visual C++ 7.1 does not use the EDG front end. Even if it did, counting
compilers doesn't tell you much. EDG is usually right.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org... "Alf P. Steinbach" wrote:
Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)
Are you also glad that you haven't checked whether you have the EDG
front end? <g> It rejects this code, too.
It compiles just fine with 7.0, with and without language extensions
disabled (/Za).
What's going on here? I was so surprised when I saw this on VC++ that
I assumed it was a compiler bug, but apparently not.
Apparently it is a compiler bug.
At least, I agree with Victor that the usual look-up rules should
apply.
Since EDG rejects it, I suspect that the analysis is wrong. I don't
claim to understand two-phase lookup, but it looks to me like 'b' is a
dependent name.
Exactly. Use
template <class T>
struct B
{
T b;
};
template <class T>
struct D : B<T>
{
void f() { B<T>::b = 1; }
};
or perhaps
template <class T>
struct B
{
T b;
};
template <class T>
struct D : B<T>
{
using B<T>::b;
void f() { b = 1; }
};
if you'll be using B's b in many places in D (note, if B's b was protected,
you should probably also make the using decl. protected).
/kv
On Sun, 10 Aug 2003 14:13:59 +0100, John Harrison wrote: This code fails to compile on Comeau C++ and VC++ 7.1 (with language
extensions disabled)
template <class T>
struct B
{
T b;
};
template <class T>
struct D : B<T>
{
void f() { b = 1; }
};
int main()
{
D<int> x;
x.f();
}
Error messages refer to 'b = 1;' with the message 'undefined identifier b'.
Substituting this->b for b or making B a non-template class both make the
code compile.
What's going on here? I was so surprised when I saw this on VC++ that I
assumed it was a compiler bug, but apparently not.
john
It's definitely not a compiler bug. HP's aCC compiler even tells you where
to look in the Standard:
Error (future) 641: "xx.cc", line 16 # Undeclared variable 'b'. A variable
with the same name exists in a template base class, but is not visible
according to the Standard lookup rules (See [temp.dep], 14.6.2(3) in the
C++ Standard). You can make it visible by writing 'this->b'.
void f() { b = 3; }
^
There is an explanation of this rule in the book "C++ Templates - The
Complete Guide" by Vandevoorde and Josuttis (section 9.4.2).
Pete Becker wrote:
"Alf P. Steinbach" wrote:
If Visual C++ 7.1 also uses the EDG front-end then it's just one.
Visual C++ 7.1 does not use the EDG front end.
What I should have said is, do you have any reason to think that VC++
used EDG's front end? I have no information either way.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
On Sun, 10 Aug 2003 10:12:08 -0400, Pete Becker <pe********@acm.org> wrote: "Alf P. Steinbach" wrote:
Am I glad that I haven't even checked whether I _have_ VC 7.1... ;-)
Are you also glad that you haven't checked whether you have the EDG
front end? <g> It rejects this code, too.
It compiles just fine with 7.0, with and without language extensions
disabled (/Za).
>What's going on here? I was so surprised when I saw this on VC++ that I
>assumed it was a compiler bug, but apparently not.
Apparently it is a compiler bug.
At least, I agree with Victor that the usual look-up rules should apply.
Since EDG rejects it, I suspect that the analysis is wrong. I don't
claim to understand two-phase lookup, but it looks to me like 'b' is a
dependent name. After all, its meaning depends on the defintion of B<T>,
and B<T> can be specialized for various T's. During phase one it has to
be explicitly qualified, in order to tell the compiler that not having a
'b' in B<T> is an error.
?
I agree that this two-phase thing is a mess... ;-) But just reading the
standard it says that such names are "unbound" (including the operator)
and become bound at template instantiation time. So I fail to see why
it even _could_ be correct to fail to compile this code; all the
information the compiler needs is there, when it needs it.
PS: I also don't understand "that not having a 'b' in B<T> is an error".
"Alf P. Steinbach" wrote:
PS: I also don't understand "that not having a 'b' in B<T> is an error".
If D<T> mentions 'this->b' but doesn't define 'b' then 'b' must be
defined in its base. If B<int> doesn't have a member named 'b' then the
name is undefined.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
"Alf P. Steinbach" wrote:
On Sun, 10 Aug 2003 10:12:08 -0400, Pete Becker <pe********@acm.org> wrote:
Since EDG rejects it, I suspect that the analysis is wrong. I don't
claim to understand two-phase lookup, but it looks to me like 'b' is a
dependent name. After all, its meaning depends on the defintion of B<T>,
and B<T> can be specialized for various T's. During phase one it has to
be explicitly qualified, in order to tell the compiler that not having a
'b' in B<T> is an error.
?
I agree that this two-phase thing is a mess... ;-) But just reading the
standard it says that such names are "unbound" (including the operator)
and become bound at template instantiation time. So I fail to see why
it even _could_ be correct to fail to compile this code; all the
information the compiler needs is there, when it needs it.
In this area I defer to EDG's reading of the standard.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
On Sun, 10 Aug 2003 16:10:53 +0100, "Simon Saunders" <si************@net.ntl.com> wrote: On Sun, 10 Aug 2003 14:13:59 +0100, John Harrison wrote:
This code fails to compile on Comeau C++ and VC++ 7.1 (with language
extensions disabled)
template <class T>
struct B
{
T b;
};
template <class T>
struct D : B<T>
{
void f() { b = 1; }
};
int main()
{
D<int> x;
x.f();
}
Error messages refer to 'b = 1;' with the message 'undefined identifier b'.
Substituting this->b for b or making B a non-template class both make the
code compile.
What's going on here? I was so surprised when I saw this on VC++ that I
assumed it was a compiler bug, but apparently not.
john
It's definitely not a compiler bug.
How can you be sure of that?
HP's aCC compiler even tells you where
to look in the Standard:
Error (future) 641: "xx.cc", line 16 # Undeclared variable 'b'. A variable
with the same name exists in a template base class, but is not visible
according to the Standard lookup rules (See [temp.dep], 14.6.2(3) in the
C++ Standard). You can make it visible by writing 'this->b'.
void f() { b = 3; }
^
According to §14.6.2/3 the base class scope is not examined _until_ the class
is instantiated -- naturally, since the information required (type T) isn't
present until then. And until then, 'b' is "unbound" according to §14.6.2/1.
There is an explanation of this rule in the book "C++ Templates - The
Complete Guide" by Vandevoorde and Josuttis (section 9.4.2).
Could you please quote? The rule about not examining the base class
scope until instantiation needs no explanation, really, so if that's
what Jousittis explains it's irrelevant. The failure to compile this
code sans name qualification does need an explanation, and the effect
of qualification (on these compilers) needs to be rooted in the standard.
On Sun, 10 Aug 2003 11:22:29 -0400, Pete Becker <pe********@acm.org> wrote: Pete Becker wrote:
"Alf P. Steinbach" wrote: >
> If Visual C++ 7.1 also uses the EDG front-end then it's just one.
Visual C++ 7.1 does not use the EDG front end.
What I should have said is, do you have any reason to think that VC++
used EDG's front end? I have no information either way.
Neither have I; if was an "if".
On Sun, 10 Aug 2003 17:27:47 +0100, "Simon Saunders" <si************@net.ntl.com> wrote: On Sun, 10 Aug 2003 15:41:25 +0000, Alf P. Steinbach wrote:
On Sun, 10 Aug 2003 16:10:53 +0100, "Simon Saunders"
<si************@net.ntl.com> wrote:
On Sun, 10 Aug 2003 14:13:59 +0100, John Harrison wrote:
This code fails to compile on Comeau C++ and VC++ 7.1 (with language
extensions disabled)
template <class T>
struct B
{
T b;
};
template <class T>
struct D : B<T>
{
void f() { b = 1; }
};
int main()
{
D<int> x;
x.f();
}
}
Error messages refer to 'b = 1;' with the message 'undefined
identifier b'. Substituting this->b for b or making B a non-template
class both make the code compile.
What's going on here? I was so surprised when I saw this on VC++ that
I assumed it was a compiler bug, but apparently not.
john
It's definitely not a compiler bug.
How can you be sure of that?
HP's aCC compiler even tells you where to look in the Standard:
Error (future) 641: "xx.cc", line 16 # Undeclared variable 'b'. A
variable
with the same name exists in a template base class, but is not
visible according to the Standard lookup rules (See [temp.dep],
14.6.2(3) in the C++ Standard). You can make it visible by writing
'this->b'.
void f() { b = 3; }
^
According to §14.6.2/3 the base class scope is not examined _until_ the
class is instantiated -- naturally, since the information required
(type T) isn't present until then. And until then, 'b' is "unbound"
according to §14.6.2/1.
14.6.2/1 says that _dependent_ names are unbound until instantiation. The
point is that the name "b" in the definition of D<T>::f() is a
nondependent name according to the rules laid out in the Standard (whereas
"this->b" is dependent).
Ah, this is opposite of Pete Becker's tentative usage of the term.
The wording of the standard just become much clearer... ;-)
Although the effect it specifies is counter-intuitive in the extreme;
awkward and inconsistent name lookup, so incomprehensible that neither I,
Victor Bazarow nor Pete Becker have fully grasped it, just to marginally
optimize compilation. Donald Knuth was right. It's evil.
...
I'll do my best to summarize it. Nondependent names are looked up when the
template D is first encountered, not postponed until instantiation as is
the case for dependent names. The advantage of this approach is that
errors caused by missing symbols can be diagnosed earlier. It also
prevents surprises resulting from explicit specializations of the
dependent base class, e.g. consider this:
#include <iostream>
using namespace std;
int b = 0;
template <class T>
struct B
{
T b;
};
template <class T>
struct D : B<T>
{
void f() { b = 3; }
};
template <>
struct B<int>
{
};
int main()
{
D<int> x;
x.f();
cout<<b<<endl;
}
Older compilers (such as Visual C++ 6.0) that do not implement the current
rules will compile this and print out "3" when the program is executed,
Isn't that right according to current rules? 'b' in D is, counter-intuitively
and inconsistent with non-template code, bound to the global 'b'?
yet without the explicit specialization the output is "0".
?
"Alf P. Steinbach" wrote:
Although the effect it specifies is counter-intuitive in the extreme;
awkward and inconsistent name lookup, so incomprehensible that neither I,
Victor Bazarow nor Pete Becker have fully grasped it
I haven't tried to, so that's not a meaningful data point.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
On Sun, 10 Aug 2003 13:51:17 -0400, Pete Becker <pe********@acm.org> wrote: "Alf P. Steinbach" wrote:
Although the effect it specifies is counter-intuitive in the extreme;
awkward and inconsistent name lookup, so incomprehensible that neither I,
Victor Bazarow nor Pete Becker have fully grasped it
I haven't tried to, so that's not a meaningful data point.
You have years of experience with C++, you're a smart guy, and you work
at Dinkumware.
IMO language should not be so complicated that you (or I, for that matter)
has to really try; with a few years of usage it should all be there, although
I do not require the same of C++ as of Pascal, which I and I think most
real programmers at that time knew the full syntax & semantics of in detail.
"Alf P. Steinbach" wrote:
On Sun, 10 Aug 2003 13:51:17 -0400, Pete Becker <pe********@acm.org> wrote:
"Alf P. Steinbach" wrote:
Although the effect it specifies is counter-intuitive in the extreme;
awkward and inconsistent name lookup, so incomprehensible that neither I,
Victor Bazarow nor Pete Becker have fully grasped it
I haven't tried to, so that's not a meaningful data point.
You have years of experience with C++, you're a smart guy, and you work
at Dinkumware.
None of which give me any significant experience with the details of
two-phase lookup. I haven't studied it, so the fact that I don't
understand it says very little about its comprehensibility. Like most
powerful tools, programming languages require study and practice.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Alexandre Tolmos |
last post by:
Hi all,
I can't compile the following code with Gcc 3.3 (compiles with
CodeWarrior 8):
template <typename T = int>
class Boule
{
friend class Boule<int>;
friend class Boule<float>;
|
by: John Harrison |
last post by:
This code fails to compile on Comeau C++ and VC++ 7.1 (with language
extensions disabled)
template <class T>
struct B
{
T b;
};
template <class T>
|
by: tirath |
last post by:
Hi all,
I have a templated class that derives from a non-templated abstract class.
How do I then cast a base class pointer to a <templated> derived class
pointer in a generalised fashion?
...
|
by: Pete |
last post by:
If anyone here can tell me what's going wrong in this snippet, I'd be much
obliged. It works under g++ 3.3 but not the (fussier) g++ 3.4. Thanks...
template<typename T>
struct base
{
T...
|
by: Steven T. Hatton |
last post by:
I find the surprising. If I derive Rectangle from Point, I can access the
members of Point inherited by Rectangle _IF_ they are actually members of a
Rectangle. If I have a member of type Point...
|
by: Amadeus W. M. |
last post by:
Template member functions cannot be virtual - I know - but is there any
way to simulate that (other than making the entire class templated,
with non-templated members).
What I have is this:
...
|
by: devmentee |
last post by:
Hello,
I am trying to create a map/dictionary where the type of key is known
ie std::string, but the value could be of any built in type. ie. int,
double etc. (something along the lines of...
|
by: cpunerd |
last post by:
Hello, I'm not new to C++, but for some reason, until now I'd never
had a need for deriving templated classes. Now though, I find myself
seeing a weird problem. If I have a templated base class...
|
by: Bhawna |
last post by:
I am into c++ code maintenance for last 3-4 years but recently I am
put into design phase of a new project. Being a small comapany I dont
have enough guidance from seniors.
Currently I am into a...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
