template specification oddness

[Matthias Buelow]

Hi folks,

I have a weird problem that I can't seem to put my finger on. The
following example program illustrates it:

----------------------------------------------------------------------
using namespace std;

template<typename Tval, typename Targ> struct Closure {
virtual Tval f(Targ arg) = 0;
virtual ~Closure() = 0;
// add environment by subclassing
};

#include <list>

template<typename Targ> struct Hooks {
std::list<Closure<void, Targ> *> hooks;

void AddHook(Closure<void, Targ> *cl) { hooks.push_front(cl); }
void RemoveHook(Closure<void, Targ> *cl) { hooks.remove(cl); }
void RunHooks(Targ arg) {
std::list<Closure<void, Targ> *>::const_iterator i = hooks.begin();
for (; i != hooks.end(); i++)
(*i)->f(arg);
}
};

int main()
{
Hooks<bool> h;

return 0;
}
----------------------------------------------------------------------

When compiling this, g++ (g++ (GCC) 4.1.2 20061115 (prerelease)
(Debian 4.1.1-21)) gives the following error:

t.cc: In member function 'void Hooks<Targ>::RunHooks(Targ)':
t.cc:17: error: expected `;' before 'i'
t.cc:18: error: 'i' was not declared in this scope

The Intel compiler, however, compiles it without error (icpc (ICC) 10.1
20070913).

Which compiler is right? Is it a g++ bug?

Thanks.

 

[James Kanze]

Matthias Buelow wrote:

[...]

I don't think so. Intel is often too forgiving.

Isn't the Intel compiler based on the EDG front-end? If so, how
forgiving it is definitely depends on the options you give it
(unless Intel has deactivated some features). EDG is
exceptional in ensuring 1) that their compiler conforms to the
standard, and 2) that their compiler supports a maximum of
existing code. And when these two goals conflict (as in this
case), they normally support both, depending on options used.

 

[James Kanze]

Any reason for this one?

It's one of those stupid myths which have established
themselves. If you use i++, you'll end up spending too much
time arguing with people who are concerned with
microoptimizations which aren't and who've never actually
measured anything.

If your existing code base uses i++, don't bother changing it.
If you don't have an existing code base, using ++i will prevent
stupid, useless comments, and so save you some time in the long
run.

 

[Victor Bazarov]

Matthias Buelow wrote:
[...]

The Intel compiler, however, compiles it without error (icpc (ICC)
10.1 20070913).
Which compiler is right? Is it a g++ bug?

I don't think so. Intel is often too forgiving.

Isn't the Intel compiler based on the EDG front-end?

I do not know.

If so, how
forgiving it is definitely depends on the options you give it
(unless Intel has deactivated some features). EDG is
exceptional in ensuring 1) that their compiler conforms to the
standard, and 2) that their compiler supports a maximum of
existing code. And when these two goals conflict (as in this
case), they normally support both, depending on options used.

If Intel C/C++ has options, there must be default values for
those. And since Intel C/C++ at some point was made to be very
compatible with MS C/C++, I can only guess what defaults many
of those options have and what purposes they serve... Just to
compile MS Platform SDK one need to have their compiler smoke
a few joints before doing any work.

V

 

[James Kanze]

James Kanze wrote:

[...]

If Intel C/C++ has options, there must be default values for
those. And since Intel C/C++ at some point was made to be very
compatible with MS C/C++, I can only guess what defaults many
of those options have and what purposes they serve...

As one of the developers at EDG (I forget which one) once said
to me, they do strive to maintain bug compatibility with all of
the widespread compilers (VC++ and g++, at least). (The notion
of "bug compatibility" is not new---back in the "good old days",
any Fortran compiler worth its salt was bug compatible with
IBM's Fortran H.)

Just to compile MS Platform SDK one need to have their
compiler smoke a few joints before doing any work.

Yes. I think you've got the picture.