class operator OnesComplement ? o.O

[himitsu]

Ja ähhhhhhhh,

im Grunde weiß ich was diese Operation machen sollte, ich kann sie sogar implementieren.

Delphi-Quellcode:

type
  TTest = record
    x: Integer;
    class operator OnesComplement(a: TTest): TTest;
  end;

Aber praktisch hab ich keine Ahnung wie ich das verwenden soll. :oops:

Rein praktisch ist es ja eine Art "BitwiseNot", aber

Delphi-Quellcode:

x := not X;

wird nicht angenommen.



Nja, bin zufällig auf diesen Operator gestoßen, aber bisher scheint ihn noch keiner zu kennen.

Weder die OH, nur die hat ja eh nie eine Ahnung, aber auch Google weiß von nix :shock:
und in der DP und Co. kennt Dieses scheinbar auch noch keiner? :lol:


Ach ja, nur zur Info, das sind übrigens alle Operatoren, welche der XE3-Compiler kennt:
Explicit Implicit Add Subtract Multiply Divide Modulus LogicalAnd LogicalOr LogicalXor LogicalNot LeftShift RightShift BitwiseAnd BitwiseOr BitwiseXor
Equal GreaterThan LessThan NotEqual GreaterThanOrEqual LessThanOrEqual Inc Dec Negative Positive OnesComplement

(gut, den Positive-Operator hab ich auch noch nie verstanden, da er mathematisch praktisch nutzlos ist und die Operatoren, welche ich mir mal gewünscht hab, gibt es leider immernoch nicht :cry: )




NOT wird ja komischer Weise nut von LogicalNot behandelt, selbst wenn es mal ein "BitwiseNot" sollte (

Delphi-Quellcode:

i := not 1

), was es aber nicht gibt.
Und warum es überhaupt Logical- und Bitwise.Operatoren gibt, ist auch unklar, da man das in Delphi nicht via Code entscheiden kann, außer das Booleans Logical sein sollten und der Rest Bitwise. (wie in C die |, ||, & und && gibt's halt nicht)

[marky522]

Hallo Himitsu,

bitweises invertieren läßt sich auch durch folgende Operation durchführen:

bei Bytes:

Delphi-Quellcode:

x := x xor $FF

bei Word:

Delphi-Quellcode:

x := x xor $FFFF

bei Integer:

Delphi-Quellcode:

x := x xor $FFFFFFFF

usw.

mfg

Markus

[himitsu]

Ich wollte es nicht nutzen ... war nur neugierig, da es das ja scheinbar gibt, aber es noch keiner kenn :zwinker:


bei Bytes:

Delphi-Quellcode:

x := not x

oder

Delphi-Quellcode:

x := x xor not 0

bei Word:

Delphi-Quellcode:

x := not x

oder

Delphi-Quellcode:

x := x xor not 0

bei Integer:

Delphi-Quellcode:

x := not x

oder

Delphi-Quellcode:

x := x xor not 0

usw.

oder eben LogicalNot nutzen und darin einfach bitweise Invertieren :angle2:

[himitsu]

Da ich grade wieder drüber gestopert bin und meinen alten Post in Google fand... (falls es auch Andere finden)

OnesComplement ist in Delphi nicht nutzbar (auch wenn man es dort implementieren kann).
Es ist eigentlich für den C++Builder gedacht und .NET kennt den Befehl ebenfalls. LogicalNot ist also das "logische not" (Boolean) und OnesComplement das "binäre not" (Integer).

Außerdem gibt es auch noch die undokumentierten True und False.
Für

Delphi-Quellcode:

if MyRecord then

implementiert man somit das

Delphi-Quellcode:

MyRecord.True

, wobei man natürlich auch einen Implicit-Cast nach Boolean verwenden könnte. :stupid:

Schachsinnig ist, daß der Delphicompiler bei

Delphi-Quellcode:

if not MyRecord then

nicht das

Delphi-Quellcode:

MyRecord.False

oder

Delphi-Quellcode:

not MyRecord.True

benutzt, sondern es zwanghaft nach

Delphi-Quellcode:

MyRecord.LogicalNot.True

übersetzen will, was beim Fehlen des LogicalNot schön knallt.

Delphi-Quellcode:

TRecord = record
  class operator OnesComplement(A: TRecord): TRecord;
  class operator True(A: TRecord): boolean;
  class operator False(A: TRecord): boolean;
end;

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1291918)

Außerdem gibt es auch noch die undokumentierten True und False.

Cool, die kannt ich gar nicht - und hätt sie neulich sogar gebrauchen können :)

[himitsu]

IstWar halt geheim. :lol:

Hier nochmal alles, was die Kompiler (bis XE7) kennen:
http://geheimniswelten.de/sonstiges/...senoperatoren/
(fehlt nur noch Initialize, Finalize und CopyRecord :cry:)

[Der schöne Günther]

Oder man erlaubt endlich einen impliziten Standard-Konstruktoraufruf (und Destruktor) für Records. Warum das nicht implementiert ist habe ich nie verstanden.

[himitsu]

OK, ob es Initialize und Finalize heißt (siehe die Funktionen in der System.pas) oder Contrucor (ohne Parameter) und Destructor, ist ja erstmal egal. (aber stimmt, deinee Namen klingen besser)
Es werden für Records bereits diese Methoden ausgeführt (siehe System.pas), aber es gibt keine Weiterleitung zu "eigenen" Implementationen, was sich durch die zentralen Stellen hätte bestimmt ganz leicht implementieren lassen.

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1291980)

CopyRecord :cry:)

Jo das Fehlt!

und was ist Convert?

[himitsu]

Zitat:

Zitat von Mavarik (Beitrag 1292006)

und was ist Convert?

Meinst du die "Konvention"?

Delphi-Quellcode:

var
  A, B: TMyRecord;
begin  // Initialize/Create
  ...
  A := B;  // Copy (B -> A) + Finalize (altes A)
  ...
end;  // Finalize/Destroy

Beim Copy werden "direkte" Inhalte kopiert (Move) und Referenzen von Interface, String, dyn. Array, Variant und ARC-Objecten behandelt,
aber eigene Behandlungen kann man nicht durchühren, wie z.B. das darin verlinkte Interface/Objekt zu klonen, was man oft benötigen könnte.

[Stevie]

Nur mal kurz zusammengeschludert:

Delphi-Quellcode:

program RecordFinalizer;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  Generics.Collections,
  SysUtils,
  TypInfo,
  DDetours;

type
  TFinalizer = procedure (Self: Pointer);
  TCopyOperator = procedure (Dest, Source: Pointer);

var
  Finalizers: TDictionary<PTypeInfo,TFinalizer>;
  CopyOperators: TDictionary<PTypeInfo,TCopyOperator>;

type
  TMyRecord = record
  private
    s: string;
  public
    procedure Destroy;
    class procedure Copy(var dest, source: TMyRecord); static;
  end;

{ TMyRecord }

class procedure TMyRecord.Copy(var dest, source: TMyRecord);
begin
  dest.s := 'Copy: ' + source.s;
end;

procedure TMyRecord.Destroy;
begin
  Writeln(s);
  Writeln('TMyRecord.Destroy');
end;

procedure Main;
var
  r, r2: TMyRecord;
begin
  r.s := 'Hello World';
  r2 := r;
end;


function GetFinalizeRecord: Pointer;
asm
  mov @Result, offset System.@FinalizeRecord
end;

function GetCopyRecord: Pointer;
asm
  mov @Result, offset System.@CopyRecord
end;

var
  FinalizeRecord: function(p: Pointer; typeInfo: Pointer): Pointer;
  CopyRecord: procedure (Dest, Source, TypeInfo: Pointer);

function FinalizeRecordHook(p: Pointer; typeInfo: Pointer): Pointer;
var
  finalizer: TFinalizer;
begin
  if Finalizers.TryGetValue(typeInfo, finalizer) then
    finalizer(p);
  if Assigned(FinalizeRecord) then
    Result := FinalizeRecord(p, typeInfo);
end;

procedure CopyRecordHook(Dest, Source, TypeInfo: Pointer);
var
  copyOperator: TCopyOperator;
begin
  if CopyOperators.TryGetValue(TypeInfo, copyOperator) then
    copyOperator(Dest, Source)
  else
    CopyRecord(Dest, Source, TypeInfo);
end;

begin
  Finalizers := TDictionary<PTypeInfo,TFinalizer>.Create;
  Finalizers.Add(TypeInfo(TMyRecord), @TMyRecord.Destroy);

  CopyOperators := TDictionary<PTypeInfo,TCopyOperator>.Create;
  CopyOperators.Add(TypeInfo(TMyRecord), @TMyRecord.Copy);

  FinalizeRecord := InterceptCreate(GetFinalizeRecord, @FinalizeRecordHook);
  CopyRecord := InterceptCreate(GetCopyRecord, @CopyRecordHook);

  try
    Main;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
  ReportMemoryLeaksOnShutdown := True;

  InterceptRemove(@FinalizeRecord);
  InterceptRemove(@CopyRecord);
  Finalizers.Free;
  CopyOperators.Free;
end.

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1292012)

Nur mal kurz zusammengeschludert:

Hi Stevie!

Immer wenn ich "Deinen" Sourcecode lese, habe ich das Gefühl ich habe keine Ahnung von Delphi... :stupid:

Bedeutet das ich kann doch den RecordCopy "überladen"?

Problem ist:

Delphi-Quellcode:

type
  TFoo = record
           A : Array of String;
         end;

Var
  Foo : TFoo;

Procedure MachNixMitFoo;
var
  Merk : TFoo;
begin
  Merk := Foo;
  Foo[3] := 'Soll nicht geändert werden';
  Machwas(Foo);
  Foo := Merk;
end;

Leider ist Foo[3] danach mit 'Soll nicht geändert werden' belegt, da "nur" die Referenzen Kopiert werden.

Bietet "Deine" Routine da einen Lösung?

Mavarik

[himitsu]

Das ist das eines der Probleme, die ich damit lösen wollte.

Für dynamische Arrays gibt es kein CopyOnWrite, wenn man schreibend auf ein Feld des dynamischen Arrays zugreift.
Bei Strings (die intern auch nur aufgemotzte dynamische Arrays sind) wird vor jedem Schreibzugriff auf ein Char (da ja

Delphi-Quellcode:

array[1..length] of char

) sichergestellt, daß RefCount auch 1 ist.
(durch Aufruf von UniqueString)

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1292026)

Bedeutet das ich kann doch den RecordCopy "überladen"?

Naja, als Überladen würd ich das nicht bezeichnen. Da werden System Funktionen gehooked.
D.h. bei allen vom Compiler generierten CopyRecord aufrufen in deiner gesamten Anwendung läuft der extra Dictionary Lookup.

Ich bin ja schon recht großzügig, Code nicht als Hack sondern als "geschickte Ausnutzung der Mechanik" zu bezeichnen, aber das ist definitiv ein Hack - und zwar ein gewaltiger - da muss man schon wissen, was man damit anstellt :)

Zitat:

Zitat von Mavarik (Beitrag 1292026)

Bietet "Deine" Routine da einen Lösung?

Vermutlich denkst du an sowas?

Delphi-Quellcode:

class procedure TFoo.Copy(var dest, source: TFoo);
begin
  dest.a := System.Copy(source.a);
end;

Jo, müsste gehen.

Gibt allerdings noch eine andere Möglichkeit, die genauso funktioniert, wie bei Strings:

Delphi-Quellcode:

type
  TFoo = record
  private
    a: array of string;
    function GetItem(i: Integer): string; inline;
    procedure SetItem(i: Integer; const Value: string); inline;
  public
    property Items[i: Integer]: string read GetItem write SetItem; default;
  end;

function GetArrayRef(A: Pointer): Integer; inline;
type // geliehen aus der System.pas
  PDynArrayRec = ^TDynArrayRec;
  TDynArrayRec = packed record
  {$IFDEF CPUX64}
    _Padding: LongInt; 
  {$ENDIF}
    RefCnt: LongInt;
    Length: NativeInt;
  end;
begin
  Result := NativeInt(A);
  if Result <> 0 then
    Result := PDynArrayRec(PByte(A) - SizeOf(TDynArrayRec))^.RefCnt;
end;

function TFoo.GetItem(i: Integer): string;
begin
  Result := a[i];
end;

procedure TFoo.SetItem(i: Integer; const Value: string);
begin
  if GetArrayRef(a) > 1 then
    a := System.Copy(a);
  a[i] := Value;
end;

[himitsu]

Am schönsten wäre es ja, wenn man auf sowas wie deim GetArrayRef verzichten könnte.
Für Strings hat man das ja inzwischen auch eingebaut. StringRefCount

Copy(arr) ruft System.DynArrayCopy auf, aber du kannst stattdessen, und ohne RefCount vorher zu prüfen, System.DynArrayUnique ausrufen (prüft selbst intern das RefCount)


Aber am "optimalsten" wäre es halt, wenn Emba solche Methoden in der RTTI aufnimmt, also direkt als Flag/Referenz, so wie z.B. beim [Weak]-Status,
und dann in den originalen Funktionen ganz schnell zu schauen, ob es was zum Aufrufen gibt, welches per Class-Operator dort eingetragen wurde.

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1292036)

Jo, müsste gehen.

Gibt allerdings noch eine andere Möglichkeit, die genauso funktioniert, wie bei Strings:

Delphi-Quellcode:

type
  TFoo = record
  private
    a: array of string;
    function GetItem(i: Integer): string; inline;
    procedure SetItem(i: Integer; const Value: string); inline;
  public
    property Items[i: Integer]: string read GetItem write SetItem; default;
  end;

function GetArrayRef(A: Pointer): Integer; inline;
type // geliehen aus der System.pas
  PDynArrayRec = ^TDynArrayRec;
  TDynArrayRec = packed record
  {$IFDEF CPUX64}
    _Padding: LongInt; 
  {$ENDIF}
    RefCnt: LongInt;
    Length: NativeInt;
  end;
begin
  Result := NativeInt(A);
  if Result <> 0 then
    Result := PDynArrayRec(PByte(A) - SizeOf(TDynArrayRec))^.RefCnt;
end;

function TFoo.GetItem(i: Integer): string;
begin
  Result := a[i];
end;

procedure TFoo.SetItem(i: Integer; const Value: string);
begin
  if GetArrayRef(a) > 1 then
    a := System.Copy(a);
  a[i] := Value;
end;

OK Aber dann muss man "überall" den Zugriff ändern.

Ich suche eher eine Lösung für den Umstiegt von Short auf Long und Array[L..H] nach Array of...

Beispiel:

Delphi-Quellcode:

type
  TFooOld = Record
              Bla : Integer;
              Blub : Array[0..10] of Shortstring;
            end;
  TFooNeu = Record
              Bla : Integer;
              Blub : Array of String; // Oder auch TStringDynArray
            end;

Der "Rest" der Software hat keine Ahnung von der Umstellung... Abgesehen von den entsprechenden SetLength.

So ALLE

Delphi-Quellcode:

var
  A,B : TFooNeu;
begin
  ...
  A := B;
end;

müssen sich genau verhalten wie vorher... Ohne

Delphi-Quellcode:

A := B.Clone

aufrufen zu müssen....

Mavarik

[himitsu]

Blub als Array-Property deklarieren und dort im Setter ein UniqueArray.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1292048)

Blub als Array-Property deklarieren und dort im Setter ein UniqueArray.

Vermutlich müsste er dann alle SetLength auf Blub im Code ändern... - aber die dürften ja über Compilefehler zu finden sein.

Einfach Zähne zusammen beißen, die Record Types vernünftig kapseln und dann is gut.

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1292048)

UniqueArray.

UniqueArray?

Gab es das schon in D2007?
Momentan mach ich immer ein Copy im Setter...

[himitsu]

k.A.
In XE(1) hab ich es nicht gefunden ... dachte aber das gibt's schon viel länger.
Vielleicht unter einem anderem Name, aber auch da fand ich auf die Schnelle nix.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1292068)

k.A.
In XE(1) hab ich es nicht gefunden ... dachte aber das gibt's schon viel länger.
Vielleicht unter einem anderem Name, aber auch da fand ich auf die Schnelle nix.

DynArrayUnique heißt die und ist mit XE7 neu.
Kannste dir aber auch selbst bauen, denn da steckt keine Compilermagic hinter - array und typeInfo übergeben und gut.

[himitsu]

Daß da nix drin war, hatte ich gesehn, aber es ist halt praktischer, wenn man "nur TypeInfo und Pointer" übergeben muß, denn dann muß man sich nicht selber um das "böse" rumgepointere kümmern, um an den RefCount zu kommen.
(oder man ruft Copy einfach nur immer blind auf, egal ob der RefCount schon kleiner 2 ist)

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1292050)

Vermutlich müsste er dann alle SetLength auf Blub im Code ändern... - aber die dürften ja über Compilefehler zu finden sein.

Einfach Zähne zusammen beißen, die Record Types vernünftig kapseln und dann is gut.

Leider nicht, da die Software in teilen über 30 Jahre alt ist, sind hier viele Proceduren mit

Delphi-Quellcode:

Procedure Foo(Var Data);

und sehr viele "Moves" enthalten.. Da hält der Compiler leider nicht an.

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1292138)

Leider nicht, da die Software in teilen über 30 Jahre alt ist, sind hier viele Proceduren mit

Delphi-Quellcode:

Procedure Foo(Var Data);

und sehr viele "Moves" enthalten.. Da hält der Compiler leider nicht an.

Manchmal wirkt ein befreiender Frühjahrsputz Wunder. Alternativ kann man auch jedesmal, wenn man so ein antiquiertes Konstrukt sieht, das vernünftig wegrefaktorisieren. Solche Code-Teile neigen nämlich dazu, den Code im Umfeld mit zu vergiften.

[DeddyH]

:thumb:

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1292149)

Manchmal wirkt ein befreiender Frühjahrsputz Wunder. Alternativ kann man auch jedesmal, wenn man so ein antiquiertes Konstrukt sieht, das vernünftig wegrefaktorisieren. Solche Code-Teile neigen nämlich dazu, den Code im Umfeld mit zu vergiften.

Als ich "Antworten" gedrückt habe, dachte ich mir schon das solche Kommentare kommen... Im Prinzip hast Du natürlich Recht...
Ein paar Longstrings in einem Record haben jetzt schon 6 Monate mit nahezu 18/7 Programmierung gekostet... Bei Projekten > 500 Units und > 2 Mio. Zeilen ist nix "mal eben" gemacht. Da gibt es auch keine Inseln die man mal eben umbaut... Jede Änderung zieht sich durch mindestens 350 Units. Immer wenn schon der Grep mehr als 10000 Stellen ausgibt, sucht man nach besseren Lösungen. Besonders, da es 5000 Stellen gibt die weder grep noch der Compiler findet...

Mavarik

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1292162)

Ein paar Longstrings in einem Record haben jetzt schon 6 Monate mit nahezu 18/7 Programmierung gekostet... Bei Projekten > 500 Units und > 2 Mio. Zeilen ist nix "mal eben" gemacht. Da gibt es auch keine Inseln die man mal eben umbaut... Jede Änderung zieht sich durch mindestens 350 Units. Immer wenn schon der Grep mehr als 10000 Stellen ausgibt, sucht man nach besseren Lösungen. Besonders, da es 5000 Stellen gibt die weder grep noch der Compiler findet...

An so einer Stelle war sicher jeder von uns schon mal und die meisten (wenn nicht alle) werden dort auch immer wieder ankommen - selbst mit aktuell akzeptablen Code-Strukturen. Es entwickelt sich halt alles weiter und der Aufwand für die Code-Pflege muss irgendwie mit eingerechnet werden. Du bist somit auch sicher nicht der erste und einzige der hier ein gehöriges Pack an Technical Debt angesammelt hat. Man kann das entweder aussitzen oder doch in den sauren Apfel beißen. Dabei kann sowohl das eine wie auch das andere eine Firma ganz gehörig belasten. Man darf die dadurch entstehenden (teils virtuellen) Kosten nicht einfach ignorieren. Insofern kann ich eine gewisse Zurückhaltung durchaus verstehen. Eine solche Investition muss gut überlegt sein.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1292194)

An so einer Stelle war sicher jeder von uns schon mal und die meisten (wenn nicht alle) werden dort auch immer wieder ankommen - selbst mit aktuell akzeptablen Code-Strukturen. Es entwickelt sich halt alles weiter und der Aufwand für die Code-Pflege muss irgendwie mit eingerechnet werden.

Dank Mobile, NextGen, AutoRefCount, ZeroBasedStrings, UnitNamespaces usw. wird es auch nicht leichter.
Man muß seine Codes weiterentwickeln, sich neue Wege überlegen und kann die schöne Abwärtskompatibilität genauso vergessen, wie die problemlose Wiederverwendbarkeit in allen Platformen.

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1292984)

Man muß seine Codes weiterentwickeln, sich neue Wege überlegen und kann die schöne Abwärtskompatibilität genauso vergessen, wie die problemlose Wiederverwendbarkeit in allen Platformen.

Ich rede ja nicht von neuen Plattformen... Da kann man ja noch sagen: OK! Neue Plattform, neuer Sourcecode!

Aber wir reden von Compiler D2007 auf XE7 und dann ggf. noch auf 64Bit... Kaum machbar bzw. der Aufwand einfach seht groß. Hier muss man sich gut überlegen ob es das Wert ist!

Der Eigenantrieb ist natürlich schon groß, wenn man auf der einen Seite iOS&Android programmiert mit Generics, Parallel.Library und anonymen Proceduren und dann wieder zurück geht um die Windows Version zu pflegen und "alles" fehlt.

Mavarik

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1293310)

Aber wir reden von Compiler D2007 auf XE7 und dann ggf. noch auf 64Bit... Kaum machbar bzw. der Aufwand einfach seht groß. Hier muss man sich gut überlegen ob es das Wert ist!

Das kannst du aber nicht so allgemein sagen. Bei meinen Projekten war der Umstieg von D2007 auf D2009 innerhalb weniger Stunden erledigt, nachdem alle verwendeten Libraries verfügbar waren. Der Sprung nach 64-Bit ging nicht ganz so reibungslos, da in alten Zeiten noch Extended-Werte in externe Dateien geschrieben wurden und ich zumindest das Lesen dieser Dateien noch sicherstellen musste. Aber auch hier war durch eine zwischengeschaltete Leseroutine der Drops schnell gelutscht.

Auch andere Projekte meiner Kunden, die z.B. von D5 nach XE3 portiert wurden, machten zumindest in diesem Punkt keine Probleme. Der Löwenaufwand steckt dort meistens im Aufräumen der im Laufe der Jahre verwachsenen Architektur.

Wenn man sich frühzeitig von PChar-Arithmetik, AnsiStrings und ShortStrings verabschiedet hat, sind solche Umstellungen eigentlich kaum der Rede wert. Es hilft wirklich, seinen Code ständig so zu pflegen, wie manche Leute ihr Auto.

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1293329)

Es hilft wirklich, seinen Code ständig so zu pflegen, wie manche Leute ihr Auto.

Dem entgegen steht: Never change a running System...

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1293355)

Zitat:

Zitat von Uwe Raabe (Beitrag 1293329)

Es hilft wirklich, seinen Code ständig so zu pflegen, wie manche Leute ihr Auto.

Dem entgegen steht: Never change a running System...

Es sei denn, es läuft auf dem Holzweg oder vor die Wand. Ich habe auch (ehemalige) Kunden, die ihr "Running-System" solange nicht angefasst haben, daß jetzt jede noch so winzige Änderung das Budget sprengen würde. Das ist leider kein Einzelfall. Bei einem Kunden hat dann letztendlich wirklich der Blitz eingeschlagen (ernsthaft!) und quasi eine Erneuerung erzwungen.

[smallie]

Catch-22:

... man müßte das System tiefgreifend ändern, um es testfähig zu machen.
... ohne ein testfähiges System zu haben, kann man es nicht tiefgreifend ändern.

:stupid:

[Uwe Raabe]

Zitat:

Zitat von smallie (Beitrag 1293370)

Catch-22:

... man müßte das System tiefgreifend ändern, um es testfähig zu machen.
... ohne ein testfähiges System zu haben, kann man es nicht tiefgreifend ändern.

In dem Fall empfehle ich diese Lektüre: Working Effectively with Legacy Code

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1293355)

Zitat:

Zitat von Uwe Raabe (Beitrag 1293329)

Es hilft wirklich, seinen Code ständig so zu pflegen, wie manche Leute ihr Auto.

Dem entgegen steht: Never change a running System...

Typisches Totschlagargument wenn man einfach nix machen will - oder Angst vor Änderungen hat.

Diese Angst beruht aber oft darauf, dass es dunkle Ecken im System geht, die man nicht kennt oder versteht. Hat man Code, den man versteht, der abgetestet ist und wo keine schwarze Magie drin steckt, dann ist eine Änderung genauso painless wie nen Öl- oder Reifenwechsel.

Da die meisten Programmierer aber immer noch vorgehen wie Meister Röhrig, sieht der Code halt auch oft "zusammengetüdelt" aus.

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1293390)

Typisches Totschlagargument wenn man einfach nix machen will - oder Angst vor Änderungen hat.

Diese Angst beruht aber oft darauf, dass es dunkle Ecken im System geht, die man nicht kennt oder versteht. Hat man Code, den man versteht, der abgetestet ist und wo keine schwarze Magie drin steckt, dann ist eine Änderung genauso painless wie nen Öl- oder Reifenwechsel.

Da die meisten Programmierer aber immer noch vorgehen wie Meister Röhrig, sieht der Code halt auch oft "zusammengetüdelt" aus.

Es kommt ja auch vor, daß man selbst gar nichts für diese Situation kann. Wer hat nicht schon mal ein solches Projekt geerbt oder den Auftrag bekommen, "mal eben" eine kleine Änderung daran zu machen? Sei es, daß der Verursacher gar nicht mehr da ist oder auch einfach nur nicht mehr klar kommt. Ein "das müssen wir neu schreiben" ist dann nur selten die richtige Antwort.

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1293392)

Es kommt ja auch vor, daß man selbst gar nichts für diese Situation kann. Wer hat nicht schon mal ein solches Projekt geerbt oder den Auftrag bekommen, "mal eben" eine kleine Änderung daran zu machen? Sei es, daß der Verursacher gar nicht mehr da ist oder auch einfach nur nicht mehr klar kommt. Ein "das müssen wir neu schreiben" ist dann nur selten die richtige Antwort.

Hab ich irgendwo was von "neu schreiben" geschrieben?
Was machst du denn, wenn du ein altes vergammeltes Haus erbst? Einziehen und drauf hoffen, dass es dir nicht aufn Kopf fällt? Oder es renovieren?

[Bernhard Geyer]

Zitat:

Zitat von Stevie (Beitrag 1293390)

Zitat:

Zitat von Mavarik (Beitrag 1293355)

Zitat:

Zitat von Uwe Raabe (Beitrag 1293329)

Es hilft wirklich, seinen Code ständig so zu pflegen, wie manche Leute ihr Auto.

Dem entgegen steht: Never change a running System...

Typisches Totschlagargument wenn man einfach nix machen will - oder Angst vor Änderungen hat.

Vor allem gibt es heute keine Statisches System mehr.
Alle 4 Wochen gibts Windows-Updates (OS-API-Verhaltensänderungen), Alle 2 Woche Adobe-Updates (PDF-Integration), alle 5 Jahre wird der Rechner ausgetauscht (Neues OS, Ander HW mit unterschiedlichen Treiberverhalten), alle 5 wird ein ERP/PLM/CRM-System mit dem man Arbeitet durch ein anderes ersetzt...

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1293426)

Hab ich irgendwo was von "neu schreiben" geschrieben?
Was machst du denn, wenn du ein altes vergammeltes Haus erbst? Einziehen und drauf hoffen, dass es dir nicht aufn Kopf fällt? Oder es renovieren?

Vielleicht habe ich mich unklar ausgedrückt. Auf keinen Fall wollte ich dir eine Aufforderung zum "neu schreiben" unterstellen. Das ist aber häufig das, was bei einem Entwicklerwechsel passiert. Dazu muss das Projekt gar nicht mal schlecht wartbar sein. Es reicht, wenn der Neue in manchen Dingen (z.B. Programmiersprache) nur andere Präferenzen hat. Mein Nachfolger bei meinem letzten Arbeitgeber hatte entgegen meiner ausdrücklichen Empfehlung keine Ahnung von Delphi. Das Projekt wurde dann in Java neu begonnen. Nach einem Jahr wurde er dann wegen nicht erfüllter Erwartungen durch einen C++-Jünger ersetzt. Nach nunmehr fast 10 Jahren ist das Projekt noch meilenweit von dem damaligen Delphi-Stand entfernt. Aber der für diese Personalentscheidungen Verantwortliche bekommt natürlich regelmäßig seinen Bonus. Sorry, ich schweife ab.

Ich wollte eigentlich nur aufzeigen, daß fehlende Pflege nicht immer in unserer Hand liegt. Das "Renovieren eines vergammelten Hauses" ist genau das, was ich eigentlich ausdrücken wollte. Danke für diese Metapher :thumb:

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1293390)

Diese Angst beruht aber oft darauf, dass es dunkle Ecken im System geht, die man nicht kennt oder versteht. Hat man Code, den man versteht, der abgetestet ist und wo keine schwarze Magie drin steckt, dann ist eine Änderung genauso painless wie nen Öl- oder Reifenwechsel.

Da gebe ich Dir zu 100% Recht!

Edit: [OT]

Man(n) hat irgendwo im Jahr 1984 mit dem Code angefangen... Turbo Pascal 1.5/2.0
Aus dieser Zeit existiert noch Code der bis heute unverändert ist.

Der Tag hat nur 24h, die Woche nur 7 Tage... Die Kundenanzahl wächst, die Wünsche auch...
Also bleibt Code so lange unangetastet, bis dafür Bedarf besteht.

Dann Mitte 96 die versuchen mit Delphi 1 den DOS-Bildschirm in einem Windowsfenster zu emulieren verworfen. Denn Delphi 2 ist rausgekommen...

Also schnell im RAD-Style die nötigen Fenster zusammen geklickt...
Button -> Doppelklick -> Code rein... Genau wie es in JEDER Präsentation gezeigt wurde...

JEDER hat so programmiert... Es soll mir keine erzählen er hätte mit Delphi 2 MVVM gemacht und nur gegen Interfaces programmiert...

Also:
Der Tag hat nur 24h, die Woche nur 7 Tage... Die Kundenanzahl wächst, die Wünsche auch...
Also bleibt Code so lange unangetastet, bis dafür Bedarf besteht.

Dann kommt plötzlich jemand auf die Idee das "alle" Strings plötzlich Unicode "seien müssen"...
Und schon bleiben unzählige Projekte auf D2007...

Hätte man es 1984 wissen können?
Hätte man früher etwas machen müssen?

Alles Fragen nach der verschütteten Milch...

Ein Monster-Projekt auf MVVM umbauen? Eher nicht... Das wäre eine Neuentwicklung..

Dem Kunden ist es auch egal wo der Code ist, wenn er einen Button drückt...
Es bezahlt keiner für "schönen" Code, damit wir Programmierer uns um Kreis stellen und gegenseitig auf die Schulter klopfen können.

Denn:
Der Tag hat nur 24h, die Woche nur 7 Tage... Die Kundenanzahl wächst, die Wünsche auch...
Also bleibt Code so lange unangetastet, bis dafür Bedarf besteht.

Und die ein oder andere "dunkle Ecken im System" bleibt uns noch ein bisschen erhalten...

Aber hin und wieder wird eine beseitigt... Alles wird gut...

Edit: [/OT]

Mavarik