template specification oddness

Discussion in 'C++' started by Matthias Buelow, Feb 21, 2008.

  1. 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.
    Matthias Buelow, Feb 21, 2008
    #1
    1. Advertising

  2. Matthias Buelow

    James Kanze Guest

    On Feb 21, 8:24 pm, "Victor Bazarov" <> wrote:
    > 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? 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 (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Feb 22, 2008
    #2
    1. Advertising

  3. Matthias Buelow

    James Kanze Guest

    On Feb 21, 8:31 pm, Matthias Buelow <> wrote:
    > Victor Bazarov wrote:
    > > typename std::list<Closure<void, Targ> *>::const_iterator i =


    > Thanks...


    > > ... ; ++i)


    > 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.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Feb 22, 2008
    #3
  4. James Kanze wrote:
    > On Feb 21, 8:24 pm, "Victor Bazarov" <> wrote:
    >> 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
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Feb 22, 2008
    #4
  5. Matthias Buelow

    James Kanze Guest

    On Feb 22, 3:52 pm, "Victor Bazarov" <> wrote:
    > James Kanze wrote:


    [...]
    > > 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...


    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.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Feb 23, 2008
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Owen Jacobson

    Template oddness with libpqxx

    Owen Jacobson, Aug 2, 2003, in forum: C++
    Replies:
    3
    Views:
    517
    Shane Neph
    Aug 3, 2003
  2. Marc Schellens

    template specification

    Marc Schellens, Oct 2, 2003, in forum: C++
    Replies:
    4
    Views:
    355
    Marc Schellens
    Oct 4, 2003
  3. Marek Vondrak
    Replies:
    9
    Views:
    329
    Marek Vondrak
    May 15, 2006
  4. Victor Bazarov

    Re: template specification oddness

    Victor Bazarov, Feb 21, 2008, in forum: C++
    Replies:
    3
    Views:
    308
    Matthias Buelow
    Feb 21, 2008
  5. Replies:
    10
    Views:
    507
    Eric Pruneau
    Jun 20, 2008
Loading...

Share This Page