[C++] template probleem

[.oisyn]

Ik geloof dat ik gek wordt (maar het kan ook aan mijn compiler liggen )

Ik heb hier namelijk een template, die volgens de Visual C++ compiler gewoon goed is, maar volgens de Arm C++ compiler niet

code:

template <int N> class fixed
{
public:
    int value;
    
    fixed<N> ()
    {
    }
    
    fixed<N> (int i) : value (1 << N)
    {
    }
    
    template <int M> fixed<N> (const fixed<M> & f)
    {
      if (N < M)
        value = f.value << (N - M);
      else
        value = f.value >> (M - N);
    }
};

De ARM C++ compiler komt met de volgende fout:

Serious error: illegal in constant expression: non constant 'M'

Zie ik iets over het hoofd? Of is mijn template declaratie toch niet helemaal netjes terwijl VC++ m wel pakt?

't kan heel goed dat het gewoon aan de compiler ligt, want in de documentatie staat ook dat ie nog niet alle C++ features ondersteund (zoals namespaces bijvoorbeeld), maar templates ondersteunt ie wel helemaal (volgens de docs dan)

[Orphix]

En als je van die <int N> <class N> maakt?

[.oisyn]

nee want N is een integer, geen type

[Orphix]

ja was ook een gokje, bij mij compiled die ook (vc++, hoogste warning level), als het ontwerp verder functioneel goed werkt, dan is mijn gok ook dat het aan de compiler ligt...

edit:
ik dacht dat member templates wel vaker fouten schijnen te geven (ook onder g++), is ook vrij nieuwe in de taal (dacht ik)

[Scare360]

= compiler 100% zeker... jaag hem eens door een low-level heen...

[.oisyn]

Op woensdag 12 september 2001 14:56 schreef paulgielens het volgende:
= compiler 100% zeker... jaag hem eens door een low-level heen...

Heb je misschien ook een minder cryptische omschrijving van je suggestie?

[Verwijderd]

Borland C++ eet em zonder problemen, ik denk ook dat het aan de compiler ligt.

[Scare360]

Op woensdag 12 september 2001 15:04 schreef OiSyN het volgende:

[..]



Heb je misschien ook een minder cryptische omschrijving van je suggestie?

Probeer je programma eens te compilen met een low-level compiler... ik denk niet dat ik exact uit kan leggen wat dat is... iig niet beter dan een search in google voor je kan doen. Maar uhm ik heb hem met succes door een c++ compiler heengehaald...dus ik denk dat je compiler vervelend doet... zoals ik dus al zij.

Een freeware compiler installeren en voor de gein eens testen is misschien een goed idee

[.oisyn]

oh op zo'n manier... Maar ja, zoals jij, ik en anderen al zeiden, het ligt waarschijnlijk aan de compiler

Na ja, ik hack wel om deze fout heen (door de operatoren buiten de klasse te declareren (als dat wel werkt tenminste)), want een andere compiler is niet echt een optie...

[whoami]

Op dinsdag 11 september 2001 23:59 schreef OiSyN het volgende:
nee want N is een integer, geen type

Denk toch dat het aan die int kan liggen hoor...
doe eens:

code:

template<type N>
class TemClass
{
};

[^Mo^]

Wat is het nut van de template als je alleen een integer kan invoeren?? Ik heb toch altijd geleerd dat een template juist nuttig is om verschillende datatypes in te kunnen voeren

[.oisyn]

Op woensdag 12 september 2001 18:32 schreef _Mo_ het volgende:
Wat is het nut van de template als je alleen een integer kan invoeren?? Ik heb toch altijd geleerd dat een template juist nuttig is om verschillende datatypes in te kunnen voeren

dan heb je niet alles geleerd

Neem nou bijvoorbeeld deze (veel voorkomende) template class

code:

template <int N> class vector
{
private:
    float elements[N];

public:
    void add (vector<N> v)
    {
      for (int i = 0; i < N; i++)
        elements[i] += v.elements[i];
    }

    float length ()
    {
      float l = 0.f;
      for (int i = 0; i < N; i++)
        l += elements[i] * elements[i];

      return (float)sqrt (l);
    }
}

Je hebt nu de klasse vector, en je kunt zelf bepalen hoeveel elementen erin moeten zitten. Als je dit zonder template wilt implementeren, dan moet je dus ook nog het aantal elementen bijhouden, en je moet ook nog eens de array van elementen apart alloceren

.edit: Bovendien kun je dan 2 vectoren van niet gelijke lengte bij elkaar optellen, dus dan moet je daar ook weer een check voor inbouwen. Als je dat nu probeert, dan krijg je een compile error, en hoef je dus tijdens run-time nergens rekening mee te houden, omdat de compiler dat al voor je heeft gedaan

[.oisyn]

Op woensdag 12 september 2001 18:20 schreef whoami het volgende:

[..]

Denk toch dat het aan die int kan liggen hoor...
doe eens:

code:

template<type N>
class TemClass
{
};

uhm ja, denk eens na

stel, ik doe dat, en dan instantieer ik de volgende class:

code:

fixed<float> f (4);

en dan wordt de constructor aangeroepen, en daar staat dan

code:

value = 4 << float;

dat maakt ook zo lekker veel 'sense'

[whoami]

Op woensdag 12 september 2001 19:12 schreef OiSyN het volgende:

[..]

uhm ja, denk eens na

stel, ik doe dat, en dan instantieer ik de volgende class:

code:

fixed<float> f (4);

en dan wordt de constructor aangeroepen, en daar staat dan

code:

value = 4 << float;

dat maakt ook zo lekker veel 'sense'

code:

template <type N>
class fixed
{
  public:
     N value;
};

[.oisyn]

Op woensdag 12 september 2001 21:32 schreef whoami het volgende:

[..]

code:

template <type N>
class fixed
{
  public:
     N value;
};

FYI: ik was bezig met een fixed-point klasse. Oftewel, een 32 bits getal waarvan er N bits worden gebruikt om waarden kleiner dan 0 op te slaan. Dus het type is altijd int, en de shift die toegepast moet worden is dus N

[whoami]

Op woensdag 12 september 2001 21:36 schreef OiSyN het volgende:

[..]

FYI: ik was bezig met een fixed-point klasse. Oftewel, een 32 bits getal waarvan er N bits worden gebruikt om waarden kleiner dan 0 op te slaan. Dus het type is altijd int, en de shift die toegepast moet worden is dus N

Owja, sorry dat ik leef hoor.

[.oisyn]

Op woensdag 12 september 2001 21:41 schreef whoami het volgende:

[..]

Owja, sorry dat ik leef hoor.

nou moet je je niet gelijk beledigd voelen. Jouw suggestie was alleen al eerder gedaan (de allereerste reactie zelfs), en daar zei ik ook dat het wel gewoon een int moest zijn. Als jij dan komt met de in mijn ogen opdringerige opmerking dat het moet TOCH type zijn, tja...

[curry684]

Op dinsdag 11 september 2001 23:45 schreef OiSyN het volgende:

code:

    template <int M> fixed<N> (const fixed<M> & f)

De ARM C++ compiler komt met de volgende fout:
Serious error: illegal in constant expression: non constant 'M'

Het lijkt erop dat ie die const-reference niet slikt, ik gok dat je probleem weg is als je de const wegknikkert.

Is in dat geval overigens wel een compilerprobleem inderdaad, dit is zo legaal als wat.

[Verwijderd]

Misschien mis ik iets, maar hoe wil jij die M van een waarde voorzien in je template? Je geeft alleen N mee aan het template, niet M. Je hebt een geneste template erin staan, maar je voorziet de parameter van dat template NIET van een waarde. (althans, nogmaals: zoals ik er naar kijk), en wellicht dat de Arm compiler er dan niets meer van begrijpt, omdat hij de M niet thuis kan brengen en niet kan bepalen of het een constant is of niet.

[edit]
Dus ik denk dat de 1e regel moet worden:

code:

template <int N, int M> class fixed

No offence, maar vind jij het ook niet een beetje een knoeiboel? ik bedoel: wat voor class wil je nu construeren? Templates zijn voor type-safe generatie van code op basis van argumenten, maar om nu integers mee te geven aan templates lijkt me een beetje overbodig. Het zal best, dat je, wanneer je dagelijks naar spagetti-templates staart, je in een oogopslag ziet wat deze template combinatie oplevert, maar eerlijk gezegd zie ik het niet. Kun je een voorbeeld geven van een codesnippet wat door deze template combinatie opgeleverd zou moeten worden? (En hoe je M van een waarde voorziet voor je function template?)

[Verwijderd]

Kan het niet gewoon zo zijn dat de ARM compiler (nog) geen member-templates pakt? Member-templating is nogal lastig voor compilers omdat er een geparametriseerd type nogmaals geparametriseerd wordt.

Er zijn wel workarounds maar dat zijn hacks, je zou de precisie N bv. als member kunnen opslaan.

<edit>
Beetje warrige zin, nahja net terug van een nachtje ziekenhuis, dus let er niet op.
</edit>

[.oisyn]

Op donderdag 13 september 2001 10:55 schreef Otis het volgende:
Misschien mis ik iets, maar hoe wil jij die M van een waarde voorzien in je template? Je geeft alleen N mee aan het template, niet M. Je hebt een geneste template erin staan, maar je voorziet de parameter van dat template NIET van een waarde. (althans, nogmaals: zoals ik er naar kijk), en wellicht dat de Arm compiler er dan niets meer van begrijpt, omdat hij de M niet thuis kan brengen en niet kan bepalen of het een constant is of niet.

[edit]
Dus ik denk dat de 1e regel moet worden:

code:

template <int N, int M> class fixed

No offence, maar vind jij het ook niet een beetje een knoeiboel? ik bedoel: wat voor class wil je nu construeren? Templates zijn voor type-safe generatie van code op basis van argumenten, maar om nu integers mee te geven aan templates lijkt me een beetje overbodig. Het zal best, dat je, wanneer je dagelijks naar spagetti-templates staart, je in een oogopslag ziet wat deze template combinatie oplevert, maar eerlijk gezegd zie ik het niet. Kun je een voorbeeld geven van een codesnippet wat door deze template combinatie opgeleverd zou moeten worden? (En hoe je M van een waarde voorziet voor je function template?)

ik neem aan dat je weet wat fixed-point getallen zijn? Ik wil dus een type maken wat in principe gewoon een fixed-point getal is, en waarmee je gewoon normaal kunt rekenen door de operatoren te overloaden
Heet aantal bits precisie achter de komma geef je dus aan met N (en daarom moet M er niet ook nog eens bij in de template definitie, die M gebruik ik om fixed-point klassen met M bits precisie te converteren naar N bits precisie)

voorbeeld:

code:

fixed<16> a = 4, b = 2, c;
fixed<8> d = 1.5;
// a.value is nu 0x00040000, en b.value is nu 0x00020000
// d.value is nu 0x00000180

c = a * b * d;
// c.value is nu 0x000c0000 (4 * 2 * 1.5 = 12)

en operator * is gedefinieerd als

code:

template <int N, int M> inline fixed<N> operator * (fixed<N> f1, fixed<M> f2)
{
    return fixed<N> ((int)(((long long)f1.value * f2.value) >> M), false);
}

dit is overigens geen memberfunctie, maar gewoon een globale functie, omdat een memberfunctie niet wil werken met een template <int M> met de ARM C++ compiler

[.oisyn]

Op donderdag 13 september 2001 12:01 schreef mietje het volgende:
Kan het niet gewoon zo zijn dat de ARM compiler (nog) geen member-templates pakt? Member-templating is nogal lastig voor compilers omdat er een geparametriseerd type nogmaals geparametriseerd wordt.

Er zijn wel workarounds maar dat zijn hacks, je zou de precisie N bv. als member kunnen opslaan.

<edit>
Beetje warrige zin, nahja net terug van een nachtje ziekenhuis, dus let er niet op.
</edit>

Ik heb er idd omheen gehacked door alle <int M> templated globaal te definieren... ik heb dan alleen geen copyconstructor, en hij loopt een warning te genereren die zegt dat operator = geen memberfunctie is (jammer dan, het werkt wel)

N opslaan in de klasse gaat echt GIGANTISCH ten koste van de performance, dus dat is absoluut geen optie (want dan is N variabel, en nu is N constant, dus goed te optimizen)

[Verwijderd]

Vindt het een beetje warrig verhaal, om fixed point integer math in classes te stoppen ivm performance. Waar wil je deze class voor gebruiken? Vertexclasses? Eigen lightcalculations?

[.oisyn]

Op vrijdag 14 september 2001 10:25 schreef Otis het volgende:
Vindt het een beetje warrig verhaal, om fixed point integer math in classes te stoppen ivm performance. Waar wil je deze class voor gebruiken? Vertexclasses? Eigen lightcalculations?

Ik stop het niet in classes ivm performance, ik stop het in classes omdat dat makkelijker werkt dan de hele tijd eigenhandig te shiften.
Het is voor ons gameboy advance projectje, daar zit een ARM7DTI processor in (da's een 32 bits RISC cpu), en GEEN coprocessor, dus ook GEEN floating point support (wel via software emulatie, maar das natuurlijk superlangzaam)
Dus nee, geen vertexclasses, en geen eigen lightcalculations (die op de gewone PC met floatingpoint toch sneller EN mooier zijn)

[Verwijderd]

Op vrijdag 14 september 2001 11:13 schreef OiSyN het volgende:

[..]

Ik stop het niet in classes ivm performance, ik stop het in classes omdat dat makkelijker werkt dan de hele tijd eigenhandig te shiften.
Het is voor ons gameboy advance projectje, daar zit een ARM7DTI processor in (da's een 32 bits RISC cpu), en GEEN coprocessor, dus ook GEEN floating point support (wel via software emulatie, maar das natuurlijk superlangzaam)
Dus nee, geen vertexclasses, en geen eigen lightcalculations (die op de gewone PC met floatingpoint toch sneller EN mooier zijn)

Vond het ook al een raar verhaal, maar nu valt het kwartje

[.oisyn]

[reclame-modus]

zie ook: gfx-ians gezocht

[/reclame-modus]