Was nervt euch so, während der Programmierung oder so allgemein

[Delphi-Laie]

Ganz schlimm sind auch Zeiger und alles, was damit zusammenhängt. Das ist ein dermaßen fragiler Müll, wer konnte sich nur solch einen kranken Mist ausdenken? Jede Veränderung irgendwelcher Speicherinhalte führt zu tausend unverhofften Nebeneffekten, weil alles mögliche auf irgendwelche gleichen Adressen zeigt. In der Endkonsequenz geht sogar das gewohnte determinierte Verhalten der Programme verloren - mal funktioniert es, mal kommt irgendeine Exception, und das alles unter gleichen Startbedingungen (Programmstart und dann die gleiche Werte eingegeben). Zudem widersprechen Zeiger dem Konzept einer jeden Programmiersprache schlechthin (denn Programmiersprachen sind alle "höher", Assembler ist keine echte Programmiersprache), lenken vom wesentlichen ab und kosten unendlich viel Zeit (knapp 100% der Erstellung zeigerbehafteter Routinen benötige ich für die Fehlersuche - wirklich, produktiver gehts nimmer).

Zeiger? Pfui Teufel, die dürften sogar für so manchen Informatiker und Hardcoreprogrammierer eine Qual werden! Was für eine Entgleisung!

[Elvis]

Du hast doch immer und überall Zeiger. (jede Referenz auf ein TObjekt ist ein Zeiger)
Wer damit nicht umgehen kann, darf IMO seinen Unterhalt nicht mit Programmieren verdienen.

Sicherlich sollte man untypisierte Zeiger vermeiden, außer man zeigt halt auf generisch reservierte Bereiche.

Aber so einen Gefühlsausbruch kann man nur mit fehlendem Verständnis erklären...

[implementation]

Mein Gott, die Programmiersprachen mussten sich auch erstmal entwickeln. Es gab noch nicht immer Objektorientierung. Und wenn du ein komplexes Programm/Bibliothek prozedural umsetzen willst, bist du verdammt froh, dass es Zeiger gibt. Willst du lieber ein zentrales Array haben und immer nur Indizes benennen? Klar, geht auch, ist aber im Grunde das Gleiche.

[Delphi-Laie]

Zitat von Elvis:

Du hast doch immer und überall Zeiger. (jede Referenz auf ein TObjekt ist ein Zeiger)

Um die geht es doch natürlich nicht!

Zitat von Elvis:

Wer damit nicht umgehen kann, darf IMO seinen Unterhalt nicht mit Programmieren verdienen.

Dieser Zwang ist mir zum Glück erspart geblieben.

Zitat von Elvis:

Sicherlich sollte man untypisierte Zeiger vermeiden, außer man zeigt halt auf generisch reservierte Bereiche.

Generisch hin, (un)typisiert her. Mir geht es einfach nur um eine doppelt verkettete Liste. Allein bei deren Deklaration bekam ich schon zu Turbo-Pascal-Zeiten einen dicken Hals: Wie kann etwas sich selbst vollständig als echte Teilmenge enthalten? Das ist mit mathematischer Logik nicht faßbar, das gibt es n.m.W. nur bei unendlichen Mengen. Inzwischen weiß ich, wie das gemeint ist.

Zitat von Elvis:

Aber so einen Gefühlsausbruch kann man nur mit fehlendem Verständnis erklären...

Sicher, aber ohne sich damit zu beschäftigen, lernt man es normalerweise nicht (vielleicht Du). Was abläuft, erkenne ich durchaus, es wird sich von Element zu Element durch diese Liste gehangelt, und wenn man auf nil stößt, dann ist man eben an eines ihrer Enden gelangt. Wenn man diesen Unrat wenigstens vernünftig debuggen könnte, ist aber leider Fehlanzeige. Sogar selbstgeschriebene, im Normalfall auch funktionierende Konvertierungsprozeduren, die man immerhin sogar im Fenster für die überwachten Ausdrücke benutzen kann - da muß ich den Borländern ein Kompliment machen, daß das überhaupt möglich ist - versagen leider, sobald irgendetwas aus dem Ruder läuft - nämlich genau dann, wenn man diese Information eigentlich benötigt. Anonsten bleiben eben in besagtem Fenster nur Speicheradressen mit "$" & Co. - damit kann ich leider nichts anfangen, weil mich nicht die Speicheradressen, sondern die dort abgelegten Informationen interessieren.

Faszinierend ist lediglich die hohe Geschwindigkeit, mit der das ganze abläuft und die mich - bisher - diese Tortur durchhalten ließ.

Ergänzung: Delphi hat mörderisch zu kämpfen: Aufrufe der Konvertierungsfunktionen mit falschen Argumenten im Fenster der zu überwachenden Ausdrucke führen zur Fehlermeldung "Fehler beim Setzen des Debug-Exception-Hook" (sic!). Was sagte ich weiter oben? Fragil!

[jfheins]

Benutze C#

Um Pointer überhaupt zu benutzen musst du einen unsafe-Block benutzen (ggf. mit fixed-Block falls du auf etwas zeigen willst, das es schon gibt)
und tief in den Projektoptionen (am besten für Debug und Release Konfiguration) eben jenen unsafe-Block separat erlauben.

Du siehst, C# schikaniert dich hier viel mehr bevor du Pointer benutzen kannst - da überlegt man sich das vielleicht dann doch nochmal

[himitsu]

Pointer in JavaScript und Co?

Ach, ich weiß ... du benutzt einfach BrainFuck ... dort gibt es keine Pointer und schon hast du DIE Programmiersprache, welche du dir schon immer gewünscht hast.

[Medium]

Dein Problem ist einfach, dass du eine elementare Strategie in der Programmierung nicht sauber umgesetzt bekommst, und zudem dies mit Mitteln tust, in einem Tool, dass diese eigentlich eher aus "Legacy"-Gründen beinhaltet, bzw. weil es für nicht alle ab und an gebrauchten Kniffe eine OOP Lösung parat hält. (Für flotte Listen taugt typsicheres Pascal aber prima!)
Im Allgemeinen meckerst du ohnehin zu viel, vor allem oftmals ohne den Eindruck zu vermitteln, dass du ausreichend Substanz für deine bemängelten Dinge hast, die einen erst berechtigen würden diese glaubhaft zu bemängeln. Bei vielen deiner Beiträge frage ich mich echt ernsthaft, was dich bei Delphi bzw. der Softwareentwicklung überhaupt hält, wenn doch quasi alles nur doof und unlogisch ist.

[BUG]

Beim Entwickeln mit Zeigern fand ich Assertions immer recht hilfreich um zu sehen wo invalide Zeiger in die Datenstruktur kommen, auch wenn sie da noch nicht benutzt werden.
Wenn man dann noch darauf achtet, das die Zeiger immer einen definierten Zustand haben und man typisierte Zeiger benutzt, kann gar nicht mehr so viel schief gehen (ausgenommen der Frage: wo/wann geben ich den Speicher wieder frei).
Rechnen mit Zeigern sollte man tatsächlich nur betreiben, wenn man gut ausgeschlafen ist. Am besten werden diese Berechnungen dann in Prozeduren/Methoden gekapselt und ordentlich typisiert.

[jaenicke]

Zitat von Delphi-Laie:

Generisch hin, (un)typisiert her. Mir geht es einfach nur um eine doppelt verkettete Liste. Allein bei deren Deklaration bekam ich schon zu Turbo-Pascal-Zeiten einen dicken Hals: Wie kann etwas sich selbst vollständig als echte Teilmenge enthalten? Das ist mit mathematischer Logik nicht faßbar, das gibt es n.m.W. nur bei unendlichen Mengen. Inzwischen weiß ich, wie das gemeint ist.

Warum brauchst du denn für eine doppelt verkettete Liste explizite Pointer?

Zitat von Delphi-Laie:

Wenn man diesen Unrat wenigstens vernünftig debuggen könnte, ist aber leider Fehlanzeige.

Ich habe mal kurz eine doppelt verkettete Liste geschrieben, die kann ich auch sehr gut debuggen (wobei ich die geschrieben und einmal testweise gestartet habe und es lief ):

Delphi-Quellcode:

type
  TDoubleLinkedListEntry<T> = class
  private
    var
      FValue: T;
      FPrevious: TDoubleLinkedListEntry<T>;
      FNext: TDoubleLinkedListEntry<T>;
    procedure SetValue(const Value: T);
    procedure SetNext(const Value: TDoubleLinkedListEntry<T>);
    procedure SetPrevious(const Value: TDoubleLinkedListEntry<T>);
  public
    constructor Create(const AValue: T; const APrevious, ANext: TDoubleLinkedListEntry<T>);
    property Value: T read FValue write SetValue;
    property Previous: TDoubleLinkedListEntry<T> read FPrevious write SetPrevious;
    property Next: TDoubleLinkedListEntry<T> read FNext write SetNext;
  end;

  TDoubleLinkedList<T> = class
  private
    var
      FHead, FTail: TDoubleLinkedListEntry<T>;
    type
      TListEnumerator = class
      private
        var
          FFirst: Boolean;
          FCurrent: TDoubleLinkedListEntry<T>;
      public
        constructor Create(AList: TDoubleLinkedList<T>);
        property Current: TDoubleLinkedListEntry<T> read FCurrent;
        function MoveNext: Boolean;
      end;
  public
    destructor Destroy; override;
    procedure Append(const Value: T);
    procedure Delete(const Value: T);
    procedure Remove(const Value: TDoubleLinkedListEntry<T>);
    function GetEnumerator: TListEnumerator;
    property Head: TDoubleLinkedListEntry<T> read FHead;
    property Tail: TDoubleLinkedListEntry<T> read FTail;
  end;

{ TDoubleLinkedListEntry<T> }

constructor TDoubleLinkedListEntry<T>.Create(const AValue: T; const APrevious, ANext: TDoubleLinkedListEntry<T>);
begin
  FValue := AValue;
  FPrevious := APrevious;
  FNext := ANext;
end;

procedure TDoubleLinkedListEntry<T>.SetNext(const Value: TDoubleLinkedListEntry<T>);
begin
  FNext := Value;
end;

procedure TDoubleLinkedListEntry<T>.SetPrevious(const Value: TDoubleLinkedListEntry<T>);
begin
  FPrevious := Value;
end;

procedure TDoubleLinkedListEntry<T>.SetValue(const Value: T);
begin
  FValue := Value;
end;

{ TDoubleLinkedList<T> }

destructor TDoubleLinkedList<T>.Destroy;
var
  CurrentEntry: TDoubleLinkedListEntry<T>;
begin
  if Assigned(FHead) then
  begin
    CurrentEntry := FHead;
    while Assigned(CurrentEntry.Next) do
    begin
      CurrentEntry := CurrentEntry.Next;
      CurrentEntry.Previous.Free;
    end;
    FTail.Free;
  end;
  inherited;
end;

function TDoubleLinkedList<T>.GetEnumerator: TListEnumerator;
begin
  Result := TListEnumerator.Create(Self);
end;

procedure TDoubleLinkedList<T>.Append(const Value: T);
begin
  if Assigned(FTail) then
  begin
    FTail.Next := TDoubleLinkedListEntry<T>.Create(Value, FTail, nil);
    FTail.Next.Previous := FTail;
    FTail := FTail.Next;
  end
  else
  begin
    FTail := TDoubleLinkedListEntry<T>.Create(Value, FTail, nil);
    FHead := FTail;
  end;
end;

procedure TDoubleLinkedList<T>.Remove(const Value: TDoubleLinkedListEntry<T>);
begin
  if Assigned(Value.Previous) then
    Value.Previous.Next := Value.Next;
  if Assigned(Value.Next) then
    Value.Next.Previous := Value.Previous;
end;

procedure TDoubleLinkedList<T>.Delete(const Value: T);
var
  CurrentEntry: TDoubleLinkedListEntry<T>;
begin
  CurrentEntry := FHead;
  while Assigned(CurrentEntry) do
    if TComparer<T>.Default.Compare(CurrentEntry.Value, Value) = 0 then
    begin
      Remove(CurrentEntry);
      CurrentEntry.Free;
      Break;
    end
    else
      CurrentEntry := CurrentEntry.Next;
end;

{ TDoubleLinkedList<T>.TListEnumerator }

constructor TDoubleLinkedList<T>.TListEnumerator.Create(AList: TDoubleLinkedList<T>);
begin
  FFirst := True;
  FCurrent := AList.Head;
end;

function TDoubleLinkedList<T>.TListEnumerator.MoveNext: Boolean;
begin
  Result := Assigned(FCurrent) and (Assigned(FCurrent.Next) or FFirst);
  if Result and not FFirst then
    FCurrent := FCurrent.Next;
  FFirst := False;
end;

Benutzung:

Delphi-Quellcode:

var
  Test: TDoubleLinkedList<Integer>;
  CurrentEntry: TDoubleLinkedListEntry<Integer>;
begin
  Test := TDoubleLinkedList<Integer>.Create;
  try
    Test.Append(100);
    Test.Append(300);
    Test.Append(200);
    for CurrentEntry in Test do
      ShowMessage(IntToStr(CurrentEntry.Value)); // 100, 300, 200
    Test.Delete(300);
    for CurrentEntry in Test do
      ShowMessage(IntToStr(CurrentEntry.Value)); // 100, 200
  finally
    Test.Free;
  end;
end;

Und debuggen kann ich das auch problemlos:

DoubleLinkedListDebug.png

Sicher, explizite Zeiger braucht man an manchen Stellen natürlich. Solange man das ganze durchdacht strukturiert machen die aber auch nicht mehr Probleme als andere Sprachbestandteile.

Ein Beispiel, das ich beruflich vor einer Weile brauchte, war ein generischer Ringpuffer. Da dort auch z.B. Records hineingespeichert werden können sollten, brauchte ich einen Pointer auf die gespeicherten Daten um diese verändern zu können. Dies wird leider nicht komplett unterstützt, aber vom Prinzip her sah das am Ende so aus:

Delphi-Quellcode:

  TCircularBuffer<T> = class
  public
    type
      TBufferPointer = ^T;
  strict private
    var
      FElements: TArray<T>;
  // ...
  public
    type
      TBufferEnumerator = class(TEnumerator<TCircularBuffer<T>.TBufferPointer>)
      // ...
      public
        constructor Create(ABuffer: TCircularBuffer<T>);
        property Current: TCircularBuffer<T>.TBufferPointer read GetCurrent;
        function MoveNext: Boolean;
      end;
    function GetEnumerator: TBufferEnumerator; reintroduce;
    // ...
  end;

Ohne Generics und den Pointer in Kombination wäre das gar nicht möglich das typsicher so umzusetzen. Aber trotzdem ist das ganze immer noch typsicher.

[Namenloser]

Ich wünschte ich hätte Generics

Edit: Btw ich verstehe nicht, wieso immer alle auf Pointern rumhacken. Wenn der Code mit Pointern schwer zu debuggen ist, wäre er mit Objekten oder Referenzen (wenn Delphi sowas hätte) genau so schwer zu debuggen. Es liegt an der Struktur des Codes, nicht an den Pointern.

Ich verwende manchmal Pointer, vor allem wenn ich mit irgendwelchen Buffern hantiere, und habe damit eigentlich nie Probleme.