class operator OnesComplement ? o.O

[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.