[delphi7] Compiler slaat code over (blauwe stipjes)

[Pantalaimon]

Ik ben bezig met een uitgebreid project, en in één van de units doet zich ineens wat vreemds voor: de compiler slaat op sommige plekken stukjes code over (er verschijnen geen blauwe stipjes voor de betreffende regels). Nu weet ik wel dat Delphi inderdaad sommige stukjes code kan weglaten bij het compilen als er met deze waarden verder niets meer gebeurt in de rest van de code.

In mijn geval slaat hij stukjes code over die wel degelijk gebruikt worden:


Je ziet dat de toekenning van waardes aan U en V simpelweg worden overgeslagen door de compiler (omcirkeld de ontbrekende blauwe stipjes). Verderop in de code worden de waarden U en V wel degelijk gebruikt bij de toekenning van Texel. Ook Texel wordt gebruikt voor toekenning aan Color, en wat uiteindelijk de output wordt. Allemaal wel degelijk belangrijke info, maar de compiler denkt er dus anders over.

Nou heb ik van m'n project de DCU's al weggegooid en opnieuw manueel door de compiler gegooid, Delphi opnieuw gestart, computer opnieuw gestart, wat wezen schuiven met code, telkens met verschillende resultaten, maar feit blijft dat hij continue in deze routines belangrijke code weglaat.
Wat doe ik ingodsnaam fout?

[Creepy]

En je krijgt hierdoor errors in je code? Misschien heeft de optimizer ze wel "weggeoptimaliseerd". Ik zou me over het weglaten van die blauwe puntjes pas zorgen gaan maken op het moment dat je daadwerkelijke fouten krijgt.

[Pantalaimon]

Dat is het 'm juist Mijn programma werkt wel gewoon, maar mijn output is gescrambled omdat hij de juiste U-V posities in Material.Texture negeert.. t ziet er niet uit.

[JoetjeF]

Ik heb het een keer opgelost door de .DCU file weg te gooien (heb je al gedaan) en de .PAS in notepad te openen, iets wijzigen en dan opslaan.

Volgens iemand had het te maken met de LF en/of CR tekens. Op deze manier converteert notepad ze allemaal naar de DOS standaard.

[ Voor 8% gewijzigd door JoetjeF op 15-02-2005 19:05 ]

[joepP]

Zet optimization eens uit in de compiler opties, en build je project opnieuw. De puntjes zullen dan wel verschijnen denk ik. Of de code het dan ineens wel doet weet ik niet, het lijkt me eerlijk gezegd nogal sterk dat de optimizer dit soort grove bugs bevat.

[Verwijderd]

De optimizer van Delphi wil soms nog wel 's "slimmer" zijn dan 'ie moet zijn...
In jouw geval hebben de locale variabelen U en V dezelfde naam als de attributes/properties van het record/object waar je naar verwijst, en da's meestal niet handig. De IDE en de compiler hebben de mogelijkheid om om te gaan met ingewikkelde 'with ... do' structuren, en het lijkt erop dat ze zich in dit geval hierin verslikken.
Dus, probeer die locale variabelen eens een ander naampje te geven.

[Pantalaimon]

Thnx allen. M'n code lijkt het nu weer goed te doen; de output is iig weer zoals ie moet zijn! :):)

[.oisyn]

Verwijderd schreef op dinsdag 15 februari 2005 @ 19:01:
In jouw geval hebben de locale variabelen U en V dezelfde naam als de attributes/properties van het record/object waar je naar verwijst, en da's meestal niet handig. De IDE en de compiler hebben de mogelijkheid om om te gaan met ingewikkelde 'with ... do' structuren, en het lijkt erop dat ze zich in dit geval hierin verslikken.
Dus, probeer die locale variabelen eens een ander naampje te geven.

Nou heb ik an sich geen ervaring met Delphi, maar met mijn kennis van compilerbouw moet ik toch zeggen dat dit heel onzinnig klinkt. Een with...do structuur is niet ingewikkelder dan elke andere statement, en tenzij de topicstarter geen with...do om z'n code heen heeft staan is het erg onwaarschijnlijk dat dat fout gaat. Er is simpelweg geen andere context om in te kijken.

Pantalaimon schreef op dinsdag 15 februari 2005 @ 20:31:
Thnx allen. M'n code lijkt het nu weer goed te doen; de output is iig weer zoals ie moet zijn! :):)

Wat heb je nu precies gedaan?

Sidenote: je renderer zal waarschijnlijk niet heel erg goed presteren met die PutPixel32 call daar in je inner loop. Je kunt beter direct naar een memorybuffer schrijven. Die deling ziet er ook niet helemaal kosher uit, aangezien de delta's voor u en v voor elke scanline hetzelfde zijn (kun je dus al uitrekenen voor je de outer loop in gaat)

[Verwijderd]

.oisyn schreef op dinsdag 15 februari 2005 @ 21:30:
Nou heb ik an sich geen ervaring met Delphi, maar met mijn kennis van compilerbouw moet ik toch zeggen dat dit heel onzinnig klinkt. Een with...do structuur is niet ingewikkelder dan elke andere statement, en tenzij de topicstarter geen with...do om z'n code heen heeft staan is het erg onwaarschijnlijk dat dat fout gaat. Er is simpelweg geen andere context om in te kijken.

Klinkt inderdaad onzinnig, maar door schade en schande (ik gebruik Delphi al sinds versie 2) ben ik onderhand wel een beetje wijzer geworden...

I.t.t. tot bv. C++ is Delphi een 'one pass' compiler.

Voordeel: 't compileert als een speer (een full build van 700.000 regels code binnen 2 minuten is geen uitzondering, op m'n P3 1GHz ontwikkelmachientje).

Nadeel: de optimizer kan niet echt vooruit kijken. Meestal is dat geen enkel probleem, maar soms moet je 'm een beetje helpen, door bv. locale variabelen andere namen te geven.

[Tomatoman]

Het lijkt erop dat Delphi in een with ... do constructie niet altijd de context pakt die je zou verwachten. Dat is geen fout in de compiler, maar het is ook niet erg intuïtief.

code:

type
  TTest = class
  private
    FMaat: TPoint;
  public
    constructor Create;
    function BreedtePlusTwee(Maat: TPoint): Integer;
    property Maat: TPoint read FMaat;
  end;

implementation

constructor TTest.Create;
begin
  FMaat.x := 10;
end;

function TTest.BreedtePlusTwee(Maat: TPoint): Integer;
begin
  with Maat do
    Result := x + 2;
end;

In dit voorbeeld retourneert BreedtePlusTwee als functieresultaat altijd de waarde 12, ongeacht de waarde die aan de functieparameter Maat is toegekend. Het probleem is eenvoudig op te lossen door de functie te herschrijven:

code:

function TTest.BreedtePlusTwee(AMaat: TPoint): Integer;
begin
  with AMaat do
    Result := x + 2;
end;

Nu is functieresultaat zoals je zou verwachten. Blijkbaar neemt de compiler binnen de with constructie in een class altijd de property (als die voorhanden is) en niet de lokale variabele. Het is een kwestie van weten, maar leidt soms tot heel obscure bugs.

[Pantalaimon]

.oisyn schreef op dinsdag 15 februari 2005 @ 21:30:
Wat heb je nu precies gedaan?

Het was iig niet verkeerde LF/CR tekens. . Het vreemde was dat de delphi auto-complete ook helemaal in de war was in die unit. Er zaten wel wat slordige typcast foutjes in andere code die informatie doorsluizen naar de polygon filler, waardoor deze waarschijnlijk in de war werd gebracht. (Komt ervan als je van floats naar fixed gaat en wat vergeet mee te nemen ).

Sidenote: je renderer zal waarschijnlijk niet heel erg goed presteren met die PutPixel32 call daar in je inner loop. Je kunt beter direct naar een memorybuffer schrijven. Die deling ziet er ook niet helemaal kosher uit, aangezien de delta's voor u en v voor elke scanline hetzelfde zijn (kun je dus al uitrekenen voor je de outer loop in gaat)

Inderdaad, de putpixel routines moeten nog vervangen worden naar geoptimaliseerde hline routines- staat dus nog op de planning.

En over die deling: die heb ik ook al eens buiten m'n loop gezet, maar dit geeft op een één of andere manier glitches in de rendering zoals hier:

[Verwijderd]

tomatoman schreef op woensdag 16 februari 2005 @ 00:58:
Het lijkt erop dat Delphi in een with ... do constructie niet altijd de context pakt die je zou verwachten. Dat is geen fout in de compiler, maar het is ook niet erg intuïtief.

code:

function TTest.BreedtePlusTwee(Maat: TPoint): Integer;

Maak het nog maar moeilijker dan het al was.

code:

function TTest.BreedtePlusTwee(FMaat: TPoint): Integer;