[VC 2003] Template probleempje...

[Verwijderd]

Ik ben sinds een paar dagen een beetje bezig met het uitproberen van de nieuwe visual studio .net 2003. Er zijn een boel bugs gefixed, en het werkt allemaal wel redelijk, maar sommige van mijn oude stukjes code werken niet goed op de nieuwe C++ compiler. Gisteravond kreeg ik een prachtige 'Internal compiler error' op een stukje code wat met de oudere compilers wel compileert.

Na wat zoekwerk heb ik het kunnen reproduceren met het volgende stukje code:

C++:

#include <iostream>
#include <tchar.h>

using namespace std;

template <class Etype>

class tpl
{
public:
 tpl() {}
 ~tpl() {}

 static int (__cdecl *function)(Etype &arg);
};

template <class Etype>
int (__cdecl *tpl<Etype>::function)(Etype &arg) = NULL;

class cls
{
public:
 int a;
};

tpl<cls> data;

int _tmain(int argc, _TCHAR* argv[])
{
 cout <<"done" <<endl;
}

Ben ik hier nu iets vreselijks verbodens aan het doen, of heeft ome bill (weer) een steekje laten vallen bij het bouwen van de template afhandeling?
(Ja, ik weet dat het erg lelijke code is, maar het is al oud en hoeft alleen maar te werken, geen beauty-contest te winnen ).

[curry684]

Wauw complimenten met de spectaculaire code, ziet er lekker ranzig uit Lijkt mij op zich dat dit zou moeten compileren al kan ik snappen dat dit soort ranzig zeldzame constructs zelden voorkomen tijdens beta-fases. Werkt ie zonder de = NULL initialisatie well?

[.oisyn]

Ik heb het even geprobeerd, de compiler raakt op de een of andere manier door de war door het includen van iostream. Zonder die include werkt ie namelijk wel.

Er is wel een workaround die volgens mij verder prima werkt: een typedef aanmaken

C++:

#include <iostream> 
#include <tchar.h> 

using namespace std; 

template <class Etype> 

class tpl 
{ 
public: 
    tpl() {} 
    ~tpl() {} 

    typedef int (__cdecl *function_t)(Etype &arg);
    static function_t function;
}; 

template <class Etype> 
typename tpl<Etype>::function_t tpl<Etype>::function = NULL; 


class cls 
{ 
public: 
    int a; 
}; 

tpl<cls> data; 

int _tmain(int argc, _TCHAR* argv[]) 
{ 
    cout <<"done" <<endl; 
}

[Verwijderd]

Met de typedef werkt 't inderdaad. Die workaround gebruik ik momenteel ook.
Hij gaat inderdaad pas stuk als ik iostream include, maar dat hoort natuurlijk niet te gebeuren, dus dit lijkt me nog steeds een (rare) compiler bug (temeer daar het wel werkt op de oudere compilers). In mijn originele scenario trad de ICE trouwens op in yval.h op de constructor van een _LockIt class. De volgorde waarin dingen worden geinclude maakt ook uit, maar telkens loopt 't stuk op de constructor van een of ander onbenullig classje.

Ik heb op de microsoft news server ook een berichtje achter gelaten; eens zien wat ze er daar van te zeggen hebben.

Werkt ie zonder de = NULL initialisatie well?

Nee. Het is een static member, dus die moet ik wel initialiseren. De betreffende functie (een compare functie voor qsort in mijn originele code) wordt pas later aan de hand van het type in de template toegevoegd. Tegenwoordig zou ik dat wel anders aanpakken, maarja, ook de oude rommel moet af en toe worden onderhouden

[ Voor 25% gewijzigd door Verwijderd op 14-05-2003 10:14 ]

[.oisyn]

Eigenlijk zou je statics members moeten kunnen initializen in de class deifnitie zelf... Ok, dan krijg je duplicate symbols tijdens de link, maar bij functies is dat ook geen probleem. Bovendien krijg je het op deze manier ook, omdat elke translation unit zijn eigen members definieert (die @ linktime weer worden samengevoegd)

[Verwijderd]

Hm. De reakties die ik krijg op de MS nieuwsgroepen zijn ook niet echt hoopgevend. Het is een bug, het is gefixed, het wachten is nu op de eerste update:

Hi Emiel,

This is a problem with the vc++ compiler shipped in 2003.
It will get fixed in the future releases of the product.

Thanks a lot for reporting it.

--
Mukul Kumar, Visual C++ Team
This posting is provided AS IS with no warranties, and confers no rights.

en

I took a look and the problem is fixed in current internal builds of the
compiler.

I'm afraid I can't offer any concrete suggestions to avoid this problem.
It involves some global state that isn't handled properly across template
instantiations, and isn't really something you can easily code around in
general.

Thanks for reporting the issue.
--
Jason Shirk, Visual C++ Compiler Team
This posting is provided AS IS with no warranties, and confers no rights.