InterlockedIncrement in welcher Unit?

[Uwe Raabe]

Außerdem:

Delphi-Quellcode:

interface
uses Windows, System.SyncObjs;

aber dann:

Delphi-Quellcode:

  { Safely increment the counter. }
  winapi.windows.InterlockedIncrement(GetMemCalls); //Bereits hier meckert der Compiler

Entweder WinApi an beiden Stellen (empfohlen) oder an keiner.

[Papaschlumpf73]

Richtig, bei 10.3 war das ja noch in der System.SyncObjs. Wir sollten eine Delphi-PRAXis-History für Fragen zu den älteren Delphi-Versionen einführen. Zumindest gefühlt werden das ja immer mehr.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1542744)

Verwende stattdessen das "neue" platformunabhänige AtomicIncrement (aus der System-Unit)

Dem kann ich nur zustimmen - die Atomic intrinsics gibt es ab XE3.

Der Text in der Hilfe ist leider immer noch etwas irreführend, da dort steht dass sie für "mobile Delphi-Compiler" seien, was kompetter Unfug ist. Diese Routinen stehen für alle Platformen zur Verfügung und generieren den entsprechenden Binärcode.

Edit: fwiw, ich hab das mal reported

[delphifan2004]

Genau da meckert aber mein Compiler Delphi 11.3 Community Edition und genau das kann ich mir nicht erklären. Ich weiß neichet mehr was ich noch tun soll. Warum gibt es solche böden Fehler nur bei Mir?

Besser ich baue mir eine eigene Rotine dafür aber wie fange ich das an? Da zugehörige Projet ist im Delphi Pfad wie er installiert ist under dem Ordner Prokekte.Delphi legt ja dafür unter

c:\Users\Konta\Documents\Embarcadero\Studio\Projek te\

meinen Pfad an und dort gibt es meinjen Unterordner für das Projekt. Für jedes Projekt ein Unterordner in /Projekte

Warum findet der Compiler dann eine Unit nicht? Bin verzweifelt!:(

[delphifan2004]

Danke @Stevie! AtomicIncrement ist die Lösung!:cheers:

Echt frustrierend wenn sich die Lokationen der Bezeichner auch noch von Version zu Verion ändern, da ist es kein Wunder, wenn/dass man irgendwann frustriert aufgibt, was als Hobby Programmierer ja geht. Wie aber soll der professionelle Programmierer einem Kunden erklären dass das Programm wegen solcher vermeidbaren Probleme so teuer ist???. Und es ist sinnlos vergeudete Arbeitszeit in der professionellen Programmierung, die der programmierende zu Recht anständig bezahlt haben will.

[himitsu]

Zitat:

Zitat von delphifan2004 (Beitrag 1542745)

Das hieße ja dass ich die Klasse TInterlocked nicht erst instanziieren muss?

Natürlich nicht, denn

Delphi-Quellcode:

  TInterlocked = class sealed
  public
    class function Increment(var Target: Integer): Integer; overload; static; inline;
    class function Increment(var Target: Int64): Int64; overload; static; inline;

(man beachte das CLASS)

Delphi-Quellcode:

var MyVar: Integer;

AtomicIncrement(MyVar);  // die System.pas ist immer eingebunden
InterlockedIncrement(MyVar);  // Winapi.Windows.pas
TInterlocked.Increment(MyVar);  // System.SyncObjs.pas

[Stevie]

Zitat:

Zitat von delphifan2004 (Beitrag 1542751)

Danke @Stevie! AtomicIncrement ist die Lösung!:cheers:

Ich hab nur zitiert, was himi schon geschrieben hatte...

Zitat:

Zitat von delphifan2004 (Beitrag 1542751)

wenn sich die Lokationen der Bezeichner auch noch von Version zu Verion ändern

Übertreiben wir hier ein wenig? Die Atomic Intrinsics gibt es seit XE3, welches die erste Delphiversion war, die über Windows hinaus ging.

Zitat:

Zitat von delphifan2004 (Beitrag 1542751)

der professionelle Programmierer

Aus eigener Erfahrung kann ich dir berichten, dass man sich - so wie in allen Berufen, wo sich regelmäßig Dinge ändern und nicht Jahrzehnte gleich bleiben - mit seinen Werkzeugen auseinander setzen muss.

[Rollo62]

Zitat:

Zitat von Stevie (Beitrag 1542753)

Übertreiben wir hier ein wenig? Die Atomic Intrinsics gibt es seit XE3, welches die erste Delphiversion war, die über Windows hinaus ging.

<KlugScheisserei>

Eigentlich war schon XE2 ziemlich über Windows hinweg :-D
aber ja, XE3 war sicher stabiler und es gab noch eine Menge Änderungen ... :stupid:

https://de.wikipedia.org/wiki/Embarc...dename_Pulsar)

</KlugScheisserei>

[Stevie]

Stimmt, außer OSX32 lief das allerdings über FPC und für OSX32 funktionierte noch der x86 asm Code, deshalb sah man zu diesem Zeitpunkt wohl noch nicht die Notwendigkeit für platformübergreifende Intrinsics.
Muss ich verdrängt haben 8-)