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

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

Zitat von Delphi-Laie (Beitrag 1174547)

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? :gruebel:

Zitat:

Zitat von Delphi-Laie (Beitrag 1174547)

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 :wink:):

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:

Anhang 37262

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.

[Daniel]

Ich denke da gerade an Beispiel aus C, bei denen es Pointer auf Pointer gab, die dann *huppsala* wieder auf Pointer zeigten. Das hat schon ein gewisses Potential für einen Knoten im Hirn. Einen einfachen Pointer auf eine Datenstruktur jedoch sehe ich nun auch nicht als "per se" problematisch an - bei vielen API-Funktionen von Windows ist es die einzige Art, diese zu verwenden.

[DeddyH]

In Delphi ist das intern ja auch nicht anders, bleibt dem Entwickler aber zum größten Teil verborgen (zum Glück).

[mkinzler]

Delphi referenziert/dereferenziert auch automatisch.

[Delphi-Laie]

Na, da habe ich wohl wieder etwas losgetreten. Also das gute vorweg: Ich nahm mich der Sache noch einmal an, und jetzt funktioniert es. Es ist die Langzahlenarithmetik aus dem "Arbeitsbuch für Turbo Pascal 4.0" aus dem ehrenhaften Jahre 1988. Delphi mit seiner beeindruckenden Abwärtskompatibilität hat an "nur-Turbo-Pascal-tauglichen" Quelltexten als solchen natürlich überhaupt nichts auszusetzen. Ein Fehler war m.E. schon im Buch, bei einem anderen bezweifele ich, daß er auch in Turbo-Pascal schon auftrat. Wenn ein Variablenparameter in einer Prozedur einen anderen Wert hat (auch unmittelbar vor ihrem Verlassen) als danach, dann sieht man ganz schon alt aus, weil sich diese Wertänderung beim Debuggen nicht nachverfolgen läßt. Der andere Wert ist aus heiterem Himmel eben plötzlich da. Da ich so etwas vorher noch nie hatte, blieb mir nichts anderes übrig, als "die bösen Zeiger" als Schuldige auszumachen, weil (für mich) kaum nachvollziebar ist, wann nur Zeiger (=Adressen) und wann Speicherinhalte geändert werden. Vielleicht lag in einem dieser Nebeneffekte ja die Ursache.

Zitat:

Zitat von jaenicke (Beitrag 1174555)

Zitat:

Zitat von Delphi-Laie (Beitrag 1174547)

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? :gruebel:

Ich weiß nicht, was ein "expliziter" Pointer ist und ob es auch andere (implizite?) gibt. Es ging und geht um doppelt verkettete Listen, bei denen man sich über Zeiger von Element zu Element - vorwärts oder rückwärts dank der doppelten Verkettung - hangeln kann / muß. Das meiste ist in Routinen enthalten und mithin mehr oder weniger versteckt, gekapselt , so daß ich mich nicht darum kümmern mußte (so z.B. mit new und dispose neue Listenwerte anzulegen bzw. alte zu annullieren. Das ganze wird ständig über den ^ -Operator referenziert, adressiert, wie auch immer, das sind nach meiner Kenntnis Zeiger, also ist das gesamte "Rumgemache" (neu"deutsch": Handling) eben "total verzeigert". Und das führt zu allen möglichen Neben-/Seiteneffekten, die ich weiter oben schon bemängelte. Delphi hat sogar mit seiner Stabilität zu kämpfen (hielt sich aber wacker), und nach dem Schließen der IDE wird man auch noch mal mit irgendeiner Fehlermeldung (access violation?) verabschiedet. Sind wirklich eine ekelhafte Angelegenheit, diese Zeiger. Wenn es funktioniert, flutscht es wie am Schnürchen und ist sehr schnell, aber wehe, es steckt irgendwo ein Fehler (eher schon: er versteckt sich) und man steht vor der Aufgabe, diesen aufzuspüren.

[jaenicke]

Ach so, du machst das mit Records. Das macht es unnötig kompliziert. Mit Klassen wie in meinem Beispiel geht es einfacher. Das sind implizite Pointer, weil das einfach eine Variable mit einem Objekt drin ist. Ein expliziter Pointer ist ein Pointer auf einen Record oder so, den man auch als solchen behandeln muss.

Wichtig ist natürlich auch immer, dass man die einzelnen Funktionen möglichst kurz und übersichtlich macht und nicht zu viel in eine. Das lässt sich sonst gerade bei etwas komplexerer Logik (gut ist ne doppelt verkettete Liste nicht wirklich, aber zumindest ein bisschen) schwer sehen, ob das so richtig ist.

Jedenfalls hilft da FastMM beim Debuggen, weil man da Stacktraces bekommt wo das Objekt erzeugt und wo freigegeben wurde, wenn man danach noch einmal darauf zugreift.

[Namenloser]

So allgemein nervt mich, dass bei etlichen Verpackungen das Mindesthaltbarkeitsdatum völlig woanders steht als „Mindestens haltbar bis:“. Es ist eine Kleinigkeit, aber einfach unnötig. Wenn es eh darauf hinausläuft, dass ich die ganze Verpackung nach dem erstbesten Datum absuchen muss und einfach davon ausgehen muss, dass es sich dabei um das Mindesthaltbarkeitsdatum handelt, könnten sie sich den Text auch gleich sparen.

[jaenicke]

Zitat:

Zitat von NamenLozer (Beitrag 1174954)

So allgemein nervt mich, dass bei etlichen Verpackungen das Mindesthaltbarkeitsdatum völlig woanders steht als „Mindestens haltbar bis:“. [...] könnten sie sich den Text auch gleich sparen.

Das würden viele sich sicher auch gerne sparen, aber wenn du einmal in die Verordnung über die Kennzeichnung von Lebensmitteln in Paragraph 7 Abschnitt 2 schaust, siehst du warum das nicht geht.

Zitat:

Das Mindesthaltbarkeitsdatum ist unverschlüsselt mit den Worten "mindestens haltbar bis ..." unter Angabe von Tag, Monat und Jahr in dieser Reihenfolge anzugeben. Die Angabe von Tag, Monat und Jahr kann auch an anderer Stelle erfolgen, wenn in Verbindung mit der Angabe nach Satz 1 auf diese Stelle hingewiesen wird.

Ähnlich steht dies in der europäischen Neufassung in Verordnung 1169/2011 unter Anhang X drin:

Zitat:

1. Das Mindesthaltbarkeitsdatum wird wie folgt angegeben:
a) Diesem Datum geht folgende Angabe voran:
— „mindestens haltbar bis …“, wenn der Tag genannt wird;
— „mindestens haltbar bis Ende …“ in den anderen Fällen.
b) In Verbindung mit der Angabe nach Buchstabe a wird angegeben
— entweder das Datum selbst oder
— ein Hinweis darauf, wo das Datum in der Kennzeichnung zu finden ist.
Diese Angaben werden erforderlichenfalls durch eine Beschreibung der Aufbewahrungsbedingungen ergänzt, deren
Einhaltung die angegebene Haltbarkeit gewährleistet.
c) Das Datum besteht aus der unverschlüsselten Angabe von Tag, Monat und gegebenenfalls Jahr in dieser Reihen*
folge.
[...]

Ich halte das aber auch für sinnvoll, dass man den Text nicht ganz entfernen darf, denn wenn nicht einmal da stehen muss wo man das Datum finden, sucht man sich erst recht tot...

[Namenloser]

Wenn da wenigstens noch steht „Siehe Prägung/Deckel/Rand“, sehe ich es ja ein, aber wenn kein Hinweis darauf zu finden ist, wo man suchen soll, ist es herzlich sinnlos...

[jaenicke]

Zitat:

Zitat von NamenLozer (Beitrag 1174961)

Wenn da wenigstens noch steht „Siehe Prägung/Deckel/Rand“, sehe ich es ja ein, aber wenn kein Hinweis darauf zu finden ist, wo man suchen soll, ist es herzlich sinnlos...

Sollte dir der Fall begegnen, kannst du das der Verbraucherschutzzentrale melden, denn entweder das Datum oder die Angabe wo man das Datum findet sind bei dem Satz vorgeschrieben. Und das sowohl nach der bisherigen als auch nach der neuen EU-Regelung (wobei es bei letzterer unmissverständlicher formuliert ist).

[himitsu]

Warum ist auf flüssigen/pulfrigen/krümligen Lebensmitteln der Aufdruck oftmals unten?


Mindesthaltbarkeitsdatum ist eh falsch. Da drucken doch alle nur hin, bis wann sie den "Geschmack", bzw. die beste "Qualität" garantieren, aber nicht bis wann es wirklich "hält".

Was ich aber wirklich hasse, das sind Blisterverpackungen ...
Letzens hatte ich mich daran geschnitten, beim Versuch das Mistding aufzubekommen.
Und ich hatte wirklich mal eine Schere, die hat man nicht rausbekommen, weil das Ding so gut verschweißt war. Jedenfalls nicht ohne eine andere Schere (Messer) zu benutzen und nun ratet mal, warum ich mir eine Schere kaufte? ... genau, weil ich Keine mehr hatte :wall:

Meine letzte Schere hatte ein Stück Pappe und eine Plastikschnur dran und ich erinnere mich noch gut daran, daß sich damals mein Delphi 4 sehr leicht auspacken ließ...
Wie ist denn Delphi/RAD heutzutage verpackt, wenn man es nicht downloadet? (WHS2011 war jedenfalls auch sehr gut eingeschweißt)

[Namenloser]

Zitat:

Zitat von jaenicke (Beitrag 1174963)

Zitat:

Zitat von NamenLozer (Beitrag 1174961)

Wenn da wenigstens noch steht „Siehe Prägung/Deckel/Rand“, sehe ich es ja ein, aber wenn kein Hinweis darauf zu finden ist, wo man suchen soll, ist es herzlich sinnlos...

Sollte dir der Fall begegnen, kannst du das der Verbraucherschutzzentrale melden, denn entweder das Datum oder die Angabe wo man das Datum findet sind bei dem Satz vorgeschrieben. Und das sowohl nach der bisherigen als auch nach der neuen EU-Regelung (wobei es bei letzterer unmissverständlicher formuliert ist).

Der Aufwand lohnt sich natürlich :angel2:

Mir ist sowas schon öfters begegnet. Gerade bei einer Tüte Snickers. Wobei das Datum in dem Fall nicht völlig woanders steht – es steht mit ein paar cm Abstand darüber auf einer weißen Fläche – und dazwischen steht noch irgendein komischer Code. Aber es ist halt nicht nach bzw. unter dem Doppelpunkt, wo man es eigentlich erwartet...

[BUG]

Zitat:

Zitat von himitsu (Beitrag 1174964)

Mindesthaltbarkeitsdatum ist eh falsch. Da drucken doch alle nur hin, bis wann sie den "Geschmack", bzw. die beste "Qualität" garantieren, aber nicht bis wann es wirklich "hält".

Dann definiere mal, wann ein Lebensmittel nicht mehr haltbar ist.

• Wenn es ein durchschnittlich Kunde nicht mehr verdauen kann ohne ihm schlecht wird?
• Ab einer bestimmten Konzentration an Mikroorganismen oder/und Giftstoffen?
• Wenn es nicht mehr schmeckt (wann ist das)?

Gar nicht so einfach. Insbesondere wenn man es nachprüfen will, um dem Hersteller Nachlässigkeit nachzuweisen.

[himitsu]

Das wäre doch mal was ... wenn da steht es hält bis heute 15:43
und schwups, um Punkt 15:44 isses verschimmelt :angle:

[Meflin]

Zitat:

Zitat von himitsu (Beitrag 1174964)

Mindesthaltbarkeitsdatum ist eh falsch. Da drucken doch alle nur hin, bis wann sie den "Geschmack", bzw. die beste "Qualität" garantieren, aber nicht bis wann es wirklich "hält".

Mindesthaltbarkeit ist genau richtig. Es heißt ja schließlich genau NICHT Höchsthaltbarkeit. Wie soll es denn sonst heißen?! Bis zum Ablauf der Mindesthaltbarkeit gerantiert der Hersteller eben die Genießbarkeit. Das impliziert rein garnichts bezüglich der tatsächlichen Haltbarkeit, nichtmal suggestiv.

[himitsu]

Nervendes:


Warum sind Typen, wie z.B. die THashedStringList nicht wiederverwendbar? (versteckt sich in der Implementation der IniFiles)

Warum schaft Emba es niemals die (teuer erkauften gratis) Zusatzkomponenten upzudaten?
- gab es jemals ein Jedi-Update? (außer wenn es extreme Bugs gab oder zum Kaufen mit der nächsten Delphi-Version)
- SVN 1.7 wird offiziell auch immernoch nicht unterstützt, oder hab es das schon als Update von Emba? :roll:
- FastMM wächst ebenfalls weiter, aber auch da nix.
- HilfeUpdates (vorallem bei den "fehlenden" und fehlerhaften Einträgen) gibt es auch meistens nur für die aktuellste Version
(wenn die endlich, so wie vom MSDN und Co. bekannt, in ihrer OH erwähnen würden wann was eingeführt wurde, dann könnten die bestimmt auch sehr leicht Updates für ältere Delphis bereitstellen)
-Bbraucht man noch die kranken und arschlangsamen Updates, mit ihren platzverschwendenden gigabyteweisen Kopien, erwähnen?
- Wieso ist die Strukturansicht vorallem bei vielen Komponenten so buggi? (das was ich im Formdesigner auswähle ist nicht in der Strukturansicht sichtbar)
- Wieso ist der Formdisigner so bugg?
Diese Ausrichtungslinien oder Hints bleiben oftmals einfach sichtbar, wenn man in die Codeansicht der selben oder einer anderen Unit wechselt.
Manchmal geht das wieder weg, wenn man zurück zur Codeansicht dieser Unit und da via F12 erneut in den code wechselt, aber meistens hilft nur noch ein Neustart, vorallem wenn dan soein blöder Hint ständig vor dem Code rumschwebt. :wall:
- ...

[divBy0]

Was mich echt genervt hat, dass es bei XE2 die TMS Smooth Controls nicht mehr als Gratisdownload gab.

Am schlimmsten aber finde ich, dass der FinalBuilder bei XE2 bei mir jammert, dass er nicht lizensiert sei. Ich weiß jetzt gar nicht, ob der wirklich nur als Testversion dabei ist, oder ob sich bei mir was verabschiedet hat...

[himitsu]

Was ich besonders mag, ist die Codesuche und Fehlerbehandlung der Generics.

Deklaration suchen (Strg+Linksklick) einer Metode/Property eines generischen Types landed niemals in der Deklaration des ursprünglichen Generis, sondern immer nur irgendwo in der Unit, wo man den generischen Type deklariert hatte ... meißt ganz am Ende der Unit.
Genauso werden Fehler im Nimandsland der falschen Unit angezeigt und man weiß garnicht was genau der Compiler von einem will, bzw. auf welche Codestelle es sich bezieht.


Ich hab jetzt bestimmt sinnlos eine halbe Stunde an der falschen Stelle gesucht, weil die Fehlermeldung nach was Anderem aussah, als es am Ende war. :wall:

[himitsu]

Früher gab's in der VCL mal die Custom-Controls ala TCustomEdit, wo nicht gleich alles Published war ... bei FMX dachte man sich wohl, sowas sei Old School und alle wollen immer gleich alles sehn.
Selbst nachträglich die Property nach Public oder Kleiner zurückzuverschieben bringt irgendwie nichts.

[himitsu]

Ich hasse zwanghafte SCOPEDENUMS.

Freiwillig (wenn nötig) mit Namespace/Scope benutzbar ist OK, aber warum muß die VCL/FMX einen immer und überall dazu zwingen?

[jaenicke]

Ich finde das (wie auch z.B. in C#) sehr sinnvoll und füge das bei allen neuen Quelltexten auch hinzu. Die alte Krücke mit den Prefixes spare ich mir dabei dann auch, so dass der Quelltext viel besser lesbar wird.

Bei VCL/FM kommt glaube ich dazu, dass aufgrund der Ähnlichkeit an manchen Stellen die Bezeichner identisch wären, wenn kein Scope angegeben würde.

Und was spricht denn dagegen?
(Außer Schreibfaulheit, aber so etwas lasse ich nicht gelten.)

[Furtbichler]

Mit gut funktionierender Codecompletion gäbe es keine Schreibfaulen.

[jaenicke]

Bei mir funktioniert die z.B. bei XE nur innerhalb von anonymen Methoden nicht und bei untypisierten Parametern wie bei Format (und bei letzterem ist es ja nachvollziehbar).

[himitsu]

Wenn es funktioniert, dann fände ich manchmal/oftmals eine andere Sortierung (erst die passenden Konstanten, dann Property/Funktionen, welche genau diesen Typen liefern und erst dann verschachtelte Dinge, wo in tieferen Ebenen dann der Typ vorkommt) und/oder eine erweiterte Suchfunktion (nicht nur der Wortanfang) nützlich, denn in der Masse an Vorschlägen findet man nicht immer das, was man braucht, vorallem wenn man grade nicht genau weiß wie das heißt, was man grade braucht.

Ansonsten sind die Dinge manchmal enfach häßlich lang.
Mit Scope und auch noch mit Präfix in einem CASE. (ala TCalloutPosition.cpTop)

PS: Wenn der Typ eindeutig ist, was in Delphi meistens der Fall ist, Dank der strikten Typisierung, dann könnte der Compiler auch etwas freundlicher sein und sich den richtigen/passenden Typen raussuchen, anstatt sich nur die letzte gefundene Implementation anzusehn und zu mackern "nee, paßt nich", dann wären an den meisten Stellen garkeine Scopes nötig, außer da, wo kein fester Typ gegeben ist, wie bei Ord, TypeInfo, offenen VAR-Parametern und Co.

[TiGü]

Zitat:

Zitat von himitsu (Beitrag 1177296)

Ansonsten sind die Dinge manchmal enfach häßlich lang.
Mit Scope und auch noch mit Präfix in einem CASE. (ala TCalloutPosition.cpTop)

PS: Wenn der Typ eindeutig ist, was in Delphi meistens der Fall ist, Dank der strikten Typisierung, dann könnte der Compiler auch etwas freundlicher sein und sich den richtigen/passenden Typen raussuchen, anstatt sich nur die letzte gefundene Implementation anzusehn und zu mackern "nee, paßt nich", dann wären an den meisten Stellen garkeine Scopes nötig, außer da, wo kein fester Typ gegeben ist, wie bei Ord, TypeInfo, offenen VAR-Parametern und Co.

Es passt zwar nicht ganz, aber:
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)

Jemand der in fünf Jahren dein Programm warten muss, wäre über die "überflüssigen" Informationen erfreut. Klar findet man vieles über Strg+Linksklick, aber das stört den Fluss beim Verstehen eines Quelltextes.

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1177296)

Ansonsten sind die Dinge manchmal enfach häßlich lang.

Was ist an der Länge schlecht? Man sieht dadurch einfach besser was zu was gehört.

Ich habe auch Enumerationen in nested types, da ist der Bezeichner noch länger, aber auch das halte ich nicht für schlecht. Dafür ist dann der einzelne Typbezeichner kürzer, da klar ist worauf der sich bezieht. Zum Beispiel:

Delphi-Quellcode:

bipLeft
// oder
TButtonImagePosition.bipLeft

Was ist da wohl schneller lesbar, wenn man den Quelltext überfliegt? (bei neuen Werten sinnvollerweise natürlich ohne Prefix, also TButtonImagePosition.Left)

Deshalb finde ich den Zwang dazu eine gute Möglichkeit diejenigen zu disziplinieren, die ansonsten die kürzeren Bezeichner der Lesbarkeit vorziehen...

[Namenloser]

Also mir gefällt diese Schreibweise TFoo.Bar bei Enums sehr gut, denn ich hatte schon öfters Probleme mit Namenskollisionen mit den Präfixen. Mein Delphi kennt das leider noch nicht...

In PHP (schreckliche Sprache, aber darum geht es jetzt nicht) emuliere ich übrigens auch gerne auf diese Weise Enums:

Code:

class MyEnum {
  const A = 0;
  const B = 1;
  const C = 2;
}

$x = MyEnum::A;

[himitsu]

Ich empfinde es eben gerade nicht unbedingt als Lesbaret, wenn "redundanter" Code "sinnlos" den eigentlichen Code vollmüllt.

[jaenicke]

Die Information ist ja nicht redundant. Sie ist schlicht ohne den Scope nicht beim Lesen des Quelltextes vorhanden.
--> Informationsmangel

[Iwo Asnet]

Zitat:

Zitat von jaenicke (Beitrag 1177285)

...wie bei Format (und bei letzterem ist es ja nachvollziehbar).

VS (oder ReSharper) kann das. Es wäre ein leichtes, die Formatanweisung zu parsen (so sie denn eine Konstante ist) und dann entsprechende Vorschläge zu unterbreiten. Man könnte sogar (wie das VS macht), den jeweiligen Platzhalter mit highlighten, sodaß man genau sieht, für welchen Platzhalter man nun den Wert auswählen soll. Last, but not least, meckert VS auch dann, wenn ich z.B. 3 Platzhalter, aber nur 2 Werte angebe.

Delphi-Quellcode:

Format('One:%s Two:%s Three:%s',[One,Two]);

.

[jaenicke]

Natürlich könnte man entsprechende Behandlungen für bestimmte Routinen einbauen. Aber im Moment gibt es das eben noch nicht.

[Iwo Asnet]

Klar, nur du hast geschrieben... 'nachvollziehbar' und das ist es eben nicht. Das es so nicht umgesetzt ist, wissen wir ja.

[Memnarch]

Zitat:

Zitat von Barlow

In der Ferne ist ein Geräusch zu vernehmen. Es ist Malte, und er lacht.

Ich wusste gar nicht, das die bei Emba nen "Malte" haben -.-

Da Hantiere ich unter XE schon mit AnsiStrings und nutze extra die AnsiStarts/AnsiEnds methoden um compiler warnings bezüglich implizitem cast Ansi<->Unicode zu umgehen, da klatschen mir die warnings trotzdem ins Gesicht, und ich bemerke die Deklaration:

Code:

function AnsiStartsText(const S1, S2: string): Boolean;

HAHA, sehr witzig m(_ _)m

[himitsu]

Weil du falsch guckst.
Binde mal die Unit AnsiStrings ein.

Auf diese idiotische Idee ist man gekommen, um die ANSI-Unicode-Umstellung zu vereinfachen.
Wenn man schon seinen Mist baut, dann bitte ohne diese Extraunit und alles direkt an der alten Stelle überladen.

[Memnarch]

Das ist jetzt mein persönliches Highlight:

Code:

function StartsText(const ASubText, AText: AnsiString): Boolean; inline; overload;
function AnsiStartsText(const ASubText, AText: AnsiString): Boolean; overload;

:wall::wall::wall:

Was sol dass den? JA das mag funktionieren, weil der Compiler die Funktionen anhand des Types rauspickt, aber das ist doch trotzdem unsinnig. o.O

[BMI]

also was ich zum Kotzen finde ist, daß - besonders, wenn man noch keine SSD 2.0 hat -


die IDE's immenoch 10 Sekunden zum Laden brauchen, bevor man wirklich anfangen kann.

Delphi 3 Pro war da ja noch wirklich fix - draufklicken, rutsch, bereit.

Delphi 5 Std. ging auch noch - bis auf den Umstand, daß erstmal online bei Inprise aufm Server nach NEWS für mich gesucht werden mußte.

Delphi 7 Std. .... naja, hab die Ladezeiten vergssen, kann aber nicht so gravierend sein

^^ auf XP


zzT. hab ich Turbo Delphi 2006. (auf Win7)
Was ein ROTZ.
das Ding braucht 10-20 Sekunden, bis alle Fenster geladen sind.

Dan drück ich auf Compilieren (leere Form) und es öffnet sich ein Fenster.Blitzlichtgewitter - und tadaaa, nach 4 Sekunden startet mein Programm.
Hallo?, bei Delphi 3 war das - schwupps da.

Das erinnert mich an TurboPascal 6. Das brauchte auch so lange.


Suchen in der Hilfe - WAHHH, auch das dauert Ewigkeiten.
Für nen einzigen Token 5-10 Sekunden.
Außerdem:
Wo sind die ganzen Codebeispiele in der HILFE, die ja selbst der 3er beilagen ???

Sind die neuen XE wenigstens etwas fixer?

Oder bezahlt man mit den kostenpflichtigen wenigstens wieder die wunderschönen Animationen (Laden, Compilieren, etc.)


WAHHHH !

[himitsu]

Eigentlich dauert nur das erste Laden der OH ewig.
Wenn die schon offen ist, bzw. vor einer Weile offen war, dann geht es recht flott.
Tipp: Binde dir die Delphi-Referenz direkt als Suchprovider in deinen Browser ein oder nutze das Addon (dessen Name ich ständig vergesse), welches die OH im Delphi um die Delphi-Referenz erweitert.

Und wegen den langen Startzeiten des Delphis ... warum machst du es überhaupt zu? Schäm dich! :warn:
(am Besten Delphi und den Rechner nie runterfahren)

[jaenicke]

Die IDEs nach Turbo Delphi sind wieder etwas schneller geworden. Aber auch Turbo Delphi ist ab Vista durch den Cache relativ fix. (Mit normaler HDD Startzeit ca. 6 Sekunden und Ausführen ca. 0,5 Sekunden nach dem Kompilieren)
Bei XP dauert das alles natürlich etwas länger.

Hast du denn DelphiSpeedup installiert?