Warum ist Delphi/(Pascal) bei uns so beliebt? (und wie erklären wir das den Neuen?)

[himitsu]

Zitat:

Zitat von EWeiss (Beitrag 1346642)

Warum muss eine procedure immer über der liegen (bzw. global deklariert werden) von der sie aufgerufen wird.

Müssen sie nicht :stupid:

Wenn du die Funktionen als Methoden ordentlich in Klassen kapselst, dann ist die Reihenfolge egal.
Und man kann auch Forward-Deklarationen deklarieren. (implizit oder explizit)

Delphi-Quellcode:

// so wäre es eigentlich
type
  TMyRecord = record
    ...
  end;
  PMyRecord = ^TMyRecord;

Delphi-Quellcode:

// das geht auch, da hier Delphi implizit das als Forward anerkennt, da es weiß, dass der Pointer immer genau 4/8 Bytes groß ist
type
  PMyRecord = ^TMyRecord;  
  TMyRecord = record
    ...
    FFriend: PMyRecord;
    ...
  end;

Delphi-Quellcode:

type
  TMyClass = class;  // hier auch ... ein Pinter ist immer 4/8 Byte, drum kann man diesen Typ vorher in einer anderen Klasse, oder in der Klasse selber verwenden
  ...
  TMyClass = class
    ...
  end;

Delphi-Quellcode:

interface 

procedure MyProc;  // implizit / bei Klassen+Methoden das Selbe

implementation

procedure MyProc;
begin
  ...
end;

Delphi-Quellcode:

implementation

procedure MyProc; forward;  // explizit

...

procedure MyProc;
begin
  ...
end;

[add] :stupid: https://en.wikipedia.org/wiki/One-pa...Pascal_Example

Zitat:

Zitat von EWeiss (Beitrag 1346642)

Ich hätte lieber das man proceduren und functionen auch recursive in den Units finden könnte.

Geht auch, aber bevor man seine Units kreuzverlinkt, sollte man sich besser überlegen, ob man da nicht ein Designproblem hat.

Zitat:

Zitat von EWeiss (Beitrag 1346642)

Sollte doch eigentlich egal sein ob drüber oder drunter solange wie sich diese in der gleichen Unit befindet.

Weil der Compiler/Parser zu dem Zeitpunkt noch nicht weiß was und ob es das später mal gibt und wie es deklariert ist, wenn dessen Deklaration erst später kommt? :stupid:

Single-Pass-Compiler / One-Pass-Compiler gegen Multi-Pass-Compiler

Delphi ist war deswegen so ein schneller Compiler, weil es nur einmal über den Code läuft und nicht versucht in mehreren Durchgängen alles zu vermanschen und gegenzuprüfen.
Seit LLVM ist das ein "war einmal".

[EWeiss]

Hmm denke du hast mich nicht verstanden..
Ich habe nicht von Klassen geredet.

Bsp:

Delphi-Quellcode:

procedure Mein(bla, bla);
begin

  Recursive(geht nix);
end;

procedure Recursive(blaaa);
begin

end

Wie du siehst steht Recursive unter Mein.
Und das wird nicht gefunden wenn ich Recursive(geht nix); aufrufe.
In dem Fall muss ich Recursive(blaaa); Global definieren oder in eine Klasse unterbringen andernfalls wird es nicht gefunden.
Zumindest nicht unter D2010.

Als Einsteiger bzw.. als jemand der von VB6 nach Delphi gewechselt ist war es nicht so einfach das zu verstehen.
Da unter VB6 es egal war wo eine Procedure oder function abgelegt wurde.
Bei einer Alphabetischen Reihenfolge (Formatierung des Quelltextes) würde bei Delphi dann nichts mehr gehen.

Zitat:

Ich hätte lieber das man proceduren und functionen auch recursive in den Units finden könnte.

Ich habe von einer Unit geredet nicht von kreuzverlinken (UNIT'S)
Siehe mein Beispiel!

gruss

[Mavarik]

Zitat:

Zitat von EWeiss (Beitrag 1346646)

Hmm denke du hast mich nicht verstanden..

Du hast es nicht verstanden... in diesen Fall musst du nur die forward declaration benutzen...

Nix global, nix in einer Klasse. Und schon kann deine Procedure drunter stehen.

[EWeiss]

Zitat:

Zitat von Mavarik (Beitrag 1346647)

Zitat:

Zitat von EWeiss (Beitrag 1346646)

Hmm denke du hast mich nicht verstanden..

Du hast es nicht verstanden... in diesen Fall musst du nur die forward declaration benutzen...

Nix global, nix in einer Klasse. Und schon kann deine Procedure drunter stehen.

Delphi-Quellcode:

forward; // explizit

Ach so.. Hmm ehrlich das wusste ich nicht.
Sehe ich aber als Unsinnig an dafür extra ein direktive für anzulegen.
Aber gut wenn's geht.

Nebenbei eine Garantie ist es auch nicht wenn ich meinen Quelltext anschließend Alphabetisch sortieren würde.
Dann nutzt auch ein Forward nichts.

gruss

[Mavarik]

Zitat:

Zitat von stahli (Beitrag 1346621)

Falls das ein Schreibfehler war: Wozu müssen mich in einer Hochsprache Pointer auf Chars interessieren?

Kein Schreibfehler... Noch nie ein C Programm gesehen? "Die" arbeiten "nur" mit Pointern!

Genau wie die Windows API...

Darum gibt es ja diese bescheuerten aufrufen.

1. Aufruf: Größe der Strucktur ermitteln.
2. Aufruf: Nochmal aufrufen und den Pointer auf den eigen Puffer übergeben!

Die Windows API kennt ja auch nur PChars... Warum wohl?

[stahli]

Hmm, ich kenne mich da nicht aus und kann das daher nicht wirklich nachvollziehen.
Egal.

Ich würde PHP jedenfalls nicht ablehnen, weil kein natives Kompilat heraus kommt.
Ich mag es nicht weil, weil ich es zu umständlich finde, damit zu arbeiten (zumindest den Bruchstücken nach, die ich so gesehen habe).

C# finde ich als Sprache nicht schlecht. Was mir nicht gefallen hat ist das Databinding an die GUI.
In der Theorie hörte sich das oft ganz gut an, in der Praxis war es aber auch nicht so einfach, mit größeren Datenmengen umzugehen.

[rokli]

Moin,

ich arbeitet seit Delphi 3 mit Delphi, habe auch ein paar Sachen in VB und später in Visual Studio mit Basic gemacht, aber insbesondere bei der Anbindung von Datenbanken ist Delphi einfach unschlagbar gut; gleichgültig ob seinerzeit mit der BDE, mit ADO oder heute FireDAC!

Und auch gleichgültig, ob mit TTabel oder TQuery; mit persistenten Feldern oder nicht - da coden sich die Kollegen von der VB Abteilung die Finger wund. So langsam gibts auch bei VS "Komponenten Unterstützung" wenn man Datenbanken anbinden will, aber das kann Delphi einfach alles besser!

Ja und schneller sind wir bei der Entwicklung mit RAD Delphi sowieso ... :roll:

Rolf

[dGeek]

Zitat:

Zitat von EWeiss (Beitrag 1346648)

Delphi-Quellcode:

forward; // explizit

Ach so.. Hmm ehrlich das wusste ich nicht.
Sehe ich aber als Unsinnig an dafür extra ein direktive für anzulegen.

Da stimme ich zu. Bei einem so teuren Produkt sollte man eigentlich davon ausgehen können, dass das auch ohne extra-Definition möglich ist.

[Papaschlumpf73]

Zitat:

Zitat von rokli (Beitrag 1346655)

Moin,

ich arbeitet seit Delphi 3 mit Delphi, habe auch ein paar Sachen in VB und später in Visual Studio mit Basic gemacht, aber insbesondere bei der Anbindung von Datenbanken ist Delphi einfach unschlagbar gut; gleichgültig ob seinerzeit mit der BDE, mit ADO oder heute FireDAC!

Und auch gleichgültig, ob mit TTabel oder TQuery; mit persistenten Feldern oder nicht - da coden sich die Kollegen von der VB Abteilung die Finger wund. So langsam gibts auch bei VS "Komponenten Unterstützung" wenn man Datenbanken anbinden will, aber das kann Delphi einfach alles besser!

Ja und schneller sind wir bei der Entwicklung mit RAD Delphi sowieso ... :roll:

Rolf

So ist es!!! Datenbankanwendungen sind mit der VCL super schnell entwickelt und sie laufen auch extrem schnell und stabil. Und selbst sehr komplexe Anforderungen lassen sich sehr schnell und übersichtlich umsetzen.

[Papaschlumpf73]

Unsere Kunden setzen unsere Delphi-Anwendungen weitestgehend auf Windows-Terminal-Servern ein. Dabei greifen zwischen 20 und 1000 User auf eine Anwendung zu. Wer sich damit im professionellen Umfeld etwas auskennt, weiss, dass Installationen in diesen Umgebungen sehr umständlich sein können. Häufig wird neue Software erst auf einem Master-Server installiert und getestet und anschließend auf die anderen WTS gespiegelt - natürlich nachts. Mit Delphi-Anwendungen ist dieses Prozedere oft nicht nötig, denn:

An Delphi schätze ich ganz besonders, dass keine extra Frameworks oder Laufzeitbibliotheken (Java, .Net usw.) benötigt werden. Viele Delphi-Anwendungen können einfach so auf jedem Windows-Rechner ausgeführt werden.

Und deshalb installieren wir unsere Anwendungen erst gar nicht auf den Servern, sondern lassen Sie einfach von einer Netzwerkfreigabe starten.

[Mavarik]

Zitat:

Zitat von dGeek (Beitrag 1346659)

Da stimme ich zu. Bei einem so teuren Produkt sollte man eigentlich davon ausgehen können, dass das auch ohne extra-Definition möglich ist.

OMG: Was hat das den damit zu tun?

Es geht hier um die Syntax von Pascal...
Und da ist die Regel ganz einfach: Es wird NIX verwendet, was nicht vorher definiert ist.

Abgesehen davon kann das der 1-Pass-Compiler sowieso nicht...

[Valle]

Zitat:

Zitat von hoika (Beitrag 1346625)

<Auch wenn ich gerne ein I++ hätte, aber ein inc(I) tut es auch...>

Was ist denn der Unterschied zwischen
i:=i+1;
und
Inc(i);

Belegen auf der Platte auf jeden Fall erst mal beide 7 Zeichen ...

Öhm, ich würde mal sagen dass i++ und ++i einen Rückgabewert haben, diese beiden Statements hingegen nicht?

Damit kann man Konstrukte wie

Code:

do_sth(array[++i]);

eben nur in zwei Zeilen machen. Was auch ein Vorteil sein kann.

[Benedikt Magnus]

Zitat:

Zitat von Valle (Beitrag 1346669)

Öhm, ich würde mal sagen dass i++ und ++i einen Rückgabewert haben, diese beiden Statements hingegen nicht?

Damit kann man Konstrukte wie

Code:

do_sth(array[++i]);

eben nur in zwei Zeilen machen. Was auch ein Vorteil sein kann.

Da scheint mir die Verwendung einer For-Schleife aber sehr viel übersichtlicher.

Edit: Ich empfand die Kombination mehrere Befehle in vielen anderen Sprachen (insbesondere C/C++) immer schon eher als Nachteil denn wirklich nützlich...

[EWeiss]

Zitat:

Abgesehen davon kann das der 1-Pass-Compiler sowieso nicht...

Genau und wir gehen davon aus das es eigentlich funktionieren sollte. (Bei einen so teuren Produkt)

OK.. OFFTOPIC.. sorry

gruss

[Benedikt Magnus]

Zitat:

Zitat von EWeiss (Beitrag 1346683)

Zitat:

Abgesehen davon kann das der 1-Pass-Compiler sowieso nicht...

Genau und wir gehen davon aus das es eigentlich funktionieren sollte. (Bei einen so teuren Produkt)

OK.. OFFTOPIC.. sorry

gruss

Du gehst aber auch davon aus, dass ein so teurer Compiler möglichst schnell ist, oder?
Im Grunde ist das ja nur eine Abwägung zugunsten der Kompiliergeschwindigkeit. Und für einen so flinken Compiler wie den von Delphi sortiere ich meine Prozeduren und Funktionen gerne mal inhaltlich statt alphabetisch, oder definiere so global, oder schreibe dieses eine Wort dahinter (diese Möglichkeit ich auch gerade erst kennengelernt habe). Oder sehe ich das falsch?

[Delphi-Laie]

Zitat:

Zitat von bytecook (Beitrag 1346523)

Warum ist Delphi/(Pascal) bei uns so beliebt?

Da kann ich nur für mich sprechen, aber bei mir ist es so beliebt, weil seine Syntax der natürlichen Sprache und damit dem Denken nahekommt. Übersetzt man die englischen Schlüsselwörter ins Deutsche, dann kann man "im Prinzip" ein Pascalprogramm einfach vorlesen und damit seine Betriebsweise gewissermaßen gleich auch erklären. Natürlich ist es nur eine Übungssache, auch andere Programmiersprachen flüssig zu lesen und zu schreiben und sich dennoch auf den Algorithmus zu konzentrieren, aber es ist mühsamer und langsamer zu erlernen.

Allerdings muß ich gestehen, daß mir die Möglichkeit von C & Co., komprimierten Code zu schreiben, sehr gefällt. Simples, mir bekanntes und von mir benennbares Beispiel sind die impliziten In- und Dekrementoren in "übergeordneten" Anweisungen.

[Tango]

Egal ob es Kostenlose Programmier Suite(n) gibt, was mich bei Delphi festhällt ist das es Native Anwendungen erzeugt. Und diese kann ich egal Win95 bis Win10 einsetzten.
Ich brauche keine Net Frameworks um meine Anwendung zu starten. Und das kann zwar auch manch andere Sprachen auch , die sind wiederum schwiriger zu erlernen gegenüber Delphi.

[EWeiss]

Zitat:

oder schreibe dieses eine Wort dahinter (diese Möglichkeit ich auch gerade erst kennengelernt habe). Oder sehe ich das falsch?

Na ja ist ja nicht so wild das ganze..
Zumindest wissen wir jetzt wofür "forward" Verwendung findet..

gruss

[stahli]

@Tango

Es weicht etwas vom Thema ab, aber da will ich mal nachfragen...

Die NET-Plattform ist doch ohnehin heutzutage Standard und quasi bei jedem Windows dabei.
Insofern kann man es für neue Projekte m.E. auch nutzen.

Wenn ich ein Programm nutze kann es mir letztlich egal sein, ob es nativ oder unter NET läuft.

[Tango]

Zitat:

Zitat von stahli (Beitrag 1346689)

@Tango

Es weicht etwas vom Thema ab, aber da will ich mal nachfragen...

Die NET-Plattform ist doch ohnehin heutzutage Standard und quasi bei jedem Windows dabei.
Insofern kann man es für neue Projekte m.E. auch nutzen.

Wenn ich ein Programm nutze kann es mir letztlich egal sein, ob es nativ oder unter NET läuft.

Teilweise hast du recht, Net Frameworks werden mit Windows mitgelifert aber nicht alle Versionen. Ich entwickle z.B. mit Net Framework 3.5 oder sogar noch älter, dann ist der Kunde gezwungen(Kunde kann ich auch sein) dieses zu nachinstallieren. Und bei uns in der Firma können wir nicht ohne weiteres Anwendungen installieren. Da arbeite ich lieber mit Native Exe und brauche es nicht zu installieren.

[Benedikt Magnus]

Zitat:

Zitat von stahli (Beitrag 1346689)

@Tango

Es weicht etwas vom Thema ab, aber da will ich mal nachfragen...

Die NET-Plattform ist doch ohnehin heutzutage Standard und quasi bei jedem Windows dabei.
Insofern kann man es für neue Projekte m.E. auch nutzen.

Wenn ich ein Programm nutze kann es mir letztlich egal sein, ob es nativ oder unter NET läuft.

Mit FreePascal wird das noch ausschlaggebener: Installiere mal .NET/Mono auf einem Raspberry Pi. :stupid:
Dort müsste man schon Python oder Java verwenden. Ersteres nutze ich höchstens mal für kleinere Dinge (z.B. das Ansprechen einer kleinen LED über GPIO bei Systemstart).
Gerade erst habe ich ein größeres, grafisches Projekt in FreePascal für den Pi portiert, erledigt in fünf Minuten (Crosscompiler installiert und angestellt), und alles läuft flüssig und nativ auf dem Pi. Was will man mehr? :)

[jfheins]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346691)

Mit FreePascal wird das noch ausschlaggebener: Installiere mal .NET/Mono auf einem Raspberry Pi. :stupid:
Dort müsste man schon Python oder Java verwenden. Ersteres nutze ich höchstens mal für kleinere Dinge (z.B. das Ansprechen einer kleinen LED über GPIO bei Systemstart).
Gerade erst habe ich ein größeres, grafisches Projekt in FreePascal für den Pi portiert, erledigt in fünf Minuten (Crosscompiler installiert und angestellt), und alles läuft flüssig und nativ auf dem Pi. Was will man mehr? :)

Hab ich schon mal gemacht :-D Ich erinnere mich nicht mehr an alles, aber es war ungefähr so: 1. apt-get install mono 2. Die exe vom Laptop rüberschieben 3. x-Flag setzen, exe ausführen, läuft :thumb:

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1346646)

In dem Fall muss ich Recursive(blaaa); Global definieren oder in eine Klasse unterbringen andernfalls wird es nicht gefunden.

Das ist eine der guten Seiten von C#. Da kann man nicht einfach irgendwelche Methoden lose irgendwo hinwerfen. Da ist man gezwungen diese in namespaces, Klassen usw. einzusortieren.

Leider ist dies eine der Altlasten des rein prozedural orientierten ursprünglichen Pascal, dass das in Delphi heute noch geht. Ansonsten wären viele Quelltexte viel besser strukturiert.

[himitsu]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346674)

Edit: Ich empfand die Kombination mehrere Befehle in vielen anderen Sprachen (insbesondere C/C++) immer schon eher als Nachteil denn wirklich nützlich...

Ich vergesse ständig wer was wie rum macht.
i++ und ++i :stupid:

In Delphi/Pascal sind Zuweisungen immer deutlich erkennbar.
In PHP (ist auch eine C-Sprache) bin ich schon auf ein if (i = 2) reingefallen, denn dass liefet immer True und i ist danach plötzlich 2. :stupid:
PHP erlaubt es, aber zum Glück hatten dann später einige PHP-Editoren sowas über eine Syntaxprüfung als Warnung dir angezeigt. :stupid:

[frapo]

Zitat:

Zitat von himitsu (Beitrag 1346728)

Ich vergesse ständig wer was wie rum macht.
i++ und ++i :stupid:

Dabei ist das so einfach: Prä-und Postinkrement, sieht man ja eigentlich wo der Operator steht, eben vor oder nach der Variablen :-D

Angenehm an diesem Thread(und am Titel) finde ich ja, dass mal endlich zwischen Delphi und Pascal/Object Pascal unterschieden wird. Sonst hört sich das ja immer so an, als ob Pascal automatisch im Besitz von Emba wäre.

Pascal/Object Pasccal ist nach wie vor eine ganz tolle Sprache um ganz klar und strukturiert zu programmieren. Diese Eigenschaft macht Pascal auch für die Zukunft immer wieder interessant.

Egal ob Emba irgendwann mal die Kurve bekommt oder nicht, Pascal/Object Pascal wird weiterhin bei vielen beliebt bleiben.

[Mikkey]

Zitat:

Zitat von Tango (Beitrag 1346690)

Ich entwickle z.B. mit Net Framework 3.5 oder sogar noch älter, dann ist der Kunde gezwungen(Kunde kann ich auch sein) dieses zu nachinstallieren.

Sorry, aber da bist Du auf dem Holzweg. Eine .NET-Anwendung, die für die Version 3.5 geschrieben wurde, läuft unter dieser und unter allen späteren Versionen.

[Tango]

Zitat:

Zitat von Mikkey (Beitrag 1346743)

Zitat:

Zitat von Tango (Beitrag 1346690)

Ich entwickle z.B. mit Net Framework 3.5 oder sogar noch älter, dann ist der Kunde gezwungen(Kunde kann ich auch sein) dieses zu nachinstallieren.

Sorry, aber da bist Du auf dem Holzweg. Eine .NET-Anwendung, die für die Version 3.5 geschrieben wurde, läuft unter dieser und unter allen späteren Versionen.

Danke für die Info, wie gesagt habe ich das nie ausprobiert (Net Sprachen) Ich werde es aber mal testen ob es auch funktioniert :)

[creed steiger]

Dann hast du aber immernoch das Problem mit schlampigen Installern, die explizit auf einer .Net Version beharren und ansonsten die Installation verweigern.

[uligerhardt]

Zitat:

Zitat von jaenicke (Beitrag 1346708)

Das ist eine der guten Seiten von C#. Da kann man nicht einfach irgendwelche Methoden lose irgendwo hinwerfen. Da ist man gezwungen diese in namespaces, Klassen usw. einzusortieren.

In Namespaces? Muss schon ne Klasse sein, oder?
Und das macht ja z.B. für Sin/Cos etc. nicht so viel Sinn.

[jaenicke]

Zitat:

Zitat von uligerhardt (Beitrag 1346769)

Und das macht ja z.B. für Sin/Cos etc. nicht so viel Sinn.

TMath.Sin usw. als Klassenmethoden macht schon Sinn, weil man dann das ganze so thematisch unterteilt und nicht mehr einfache Prozeduren herumfliegen hat.

Denn ansonsten fehlt dir z.B. die Syntaxergänzung oder du schreibst den ganzen Unitnamen ab.
So schreibst du einfach TMath. und siehst die verfügbaren Methoden ohne tausend weitere globale Prozeduren zu sehen.

[uligerhardt]

Zitat:

Zitat von jaenicke (Beitrag 1346770)

Zitat:

Zitat von uligerhardt (Beitrag 1346769)

Und das macht ja z.B. für Sin/Cos etc. nicht so viel Sinn.

TMath.Sin usw. als Klassenmethoden macht schon Sinn, weil man dann das ganze so thematisch unterteilt und nicht mehr einfache Prozeduren herumfliegen hat.

Denn ansonsten fehlt dir z.B. die Syntaxergänzung oder du schreibst den ganzen Unitnamen ab.
So schreibst du einfach TMath. und siehst die verfügbaren Methoden ohne tausend weitere globale Prozeduren zu sehen.

Da macht das Formelschreiben Spaß. Und Sin krieg ich ohne Syntaxvervollständigung hin. :mrgreen:

[OlafSt]

Das mag bei simplen bzw. oft genutzten Dingen wie mathematische Funktionen noch unsinnig erscheinen.

Doch wie ist das z.B. mit TFormatSettings ? Da kenne ich bei weitem nicht alle Elemente, die sich dahinter verbergen. Ähnlich ist es in .NET mit der statischen Math-Klasse, der Converter-Klasse (die nahezu alles in alles Konvertieren kann und weit über IntToStr oder TStringList.DelimitedText='bla' hinausgeht), der BitConverter-Klasse und so weiter.

Gerade am Anfang, wenn man noch neu in .NET ist, ist das eine unschätzbare Hilfestellung. Ein Delphi-Neuling muß lernen, das man einen Int per "IntToStr" in einen String verwandelt. Und das es noch FloatToStr und FormatDateTime usw. usf. gibt... Dem .NET-Neuling sagt man "schau in die Convert-Klasse" und er findet von selbst den Weg zu all diesen Konvertierungen.

So unsinnig ist das ganze also nicht ;)

[Sherlock]

Zitat:

Zitat von Mikkey (Beitrag 1346743)

Zitat:

Zitat von Tango (Beitrag 1346690)

Ich entwickle z.B. mit Net Framework 3.5 oder sogar noch älter, dann ist der Kunde gezwungen(Kunde kann ich auch sein) dieses zu nachinstallieren.

Sorry, aber da bist Du auf dem Holzweg. Eine .NET-Anwendung, die für die Version 3.5 geschrieben wurde, läuft unter dieser und unter allen späteren Versionen.

Aha, das ist dann wohl auch der Grund, warum man auf einem frischen Win10 kein Delphi Berlin installiert bekommt, ohne das beschickerte 3.5 nachzuinstallieren. .net ist Krätze. (<- Punkt)
Die angebliche Plattformübergreifung ist erst durch Linux-Enthusiasten mit Mono halbwegs Realität geworden. Unter Windows gibt es nunmal nur eine Plattform (von Mobile mal abgesehen, aber für derart winzige Nischen entwickelt ja keiner), das sieht man daran, daß zB eine Delphi-Exe unter jeder Windows-Version klaglos läuft. Microsoft hat mit .net zum einen zwar ein hübsches c# gebracht, zum andern aber lediglich die MFC durch .net Libs ausgetauscht. Aber das rennt grad wieder Richtung OT.

Sherlock

[uligerhardt]

Zitat:

Zitat von OlafSt (Beitrag 1346772)

Das mag bei simplen bzw. oft genutzten Dingen wie mathematische Funktionen noch unsinnig erscheinen.

Ich sag ja auch nicht, dass Namespaces oder Klassen überflüssig sind. Überflüssig ist hingegen, alles andere verbieten zu wollen, selbst wenn es sinnvoll sein kann. :wall:

Zitat:

Zitat von OlafSt (Beitrag 1346772)

Ein Delphi-Neuling muß lernen, das man einen Int per "IntToStr" in einen String verwandelt. Und das es noch FloatToStr und FormatDateTime usw. usf. gibt... Dem .NET-Neuling sagt man "schau in die Convert-Klasse" und er findet von selbst den Weg zu all diesen Konvertierungen.

Naja, aber suche ich IntToStr jetzt in der String-, Integer- oder einer Pseudo-Namespace-Converter-Klasse? Ohne gute Doku etc. kommt man da eh nicht aus.

[mkinzler]

InToToStr -> Integer.toString
StrToInt -> String.toInteger/asInteger

[uligerhardt]

Zitat:

Zitat von mkinzler (Beitrag 1346775)

InToToStr -> Integer.toString
StrToInt -> String.toInteger/asInteger

OK, OK... :mrgreen:

[OrNEC]

Bei mir ist das einfach "die erste Liebe". Bin zwar von Delphi zu Lazarus gewandert, aber letztendlich ist das alles Pascal.

[frapo]

Zitat:

Zitat von Sherlock (Beitrag 1346773)

Zitat:

Zitat von Mikkey (Beitrag 1346743)

Zitat:

Zitat von Tango (Beitrag 1346690)

Ich entwickle z.B. mit Net Framework 3.5 oder sogar noch älter, dann ist der Kunde gezwungen(Kunde kann ich auch sein) dieses zu nachinstallieren.

Sorry, aber da bist Du auf dem Holzweg. Eine .NET-Anwendung, die für die Version 3.5 geschrieben wurde, läuft unter dieser und unter allen späteren Versionen.

Aha, das ist dann wohl auch der Grund, warum man auf einem frischen Win10 kein Delphi Berlin installiert bekommt, ohne das beschickerte 3.5 nachzuinstallieren. .net ist Krätze. (<- Punkt)

Um mal in deinem Sprachgebrauch zu bleiben: "beschickert" dürfte eher sein, dass im Delphi-Setup auf .NET 3.5 bestanden wird, statt auch höhere .NET Versionen zu akzeptieren. Das diese abwärtskompatibel sind, weiß man ja eigentlich.

So richtig "beschickert" ist ja aber eher noch, dass Delphi überhaupt .NET braucht!

[bra]

Zitat:

Zitat von frapo (Beitrag 1346786)

Um mal in deinem Sprachgebrauch zu bleiben: "beschickert" dürfte eher sein, dass im Delphi-Setup auf .NET 3.5 bestanden wird, statt auch höhere .NET Versionen zu akzeptieren. Das diese abwärtskompatibel sind, weiß man ja eigentlich.

So richtig "beschickert" ist ja aber eher noch, dass Delphi überhaupt .NET braucht!

.NET ist eben nicht komplett abwärtskompatibel. Für Anwendungen, die für 1.1, 2.0, 3.5 und 4.x+ geschrieben wurden, braucht man i.d.R. die entsprechende .NET-Version. Die sind jeweils nur zu einigen Vorversionen kompatibel.

[himitsu]

Wenn du das als Static-Class-Methods deklariert hast, dann kannst du auch ein

Delphi-Quellcode:

with TMath(nil) do

vor deine Berechnung schreiben und schon ist der "Namespace" weg. :stupid:

Aber man kann das inzwischen auch schön als Record-Helper an Single/Double/Integer/usw. hängen, dann schreibst du eben satt

Delphi-Quellcode:

Sin(x)

ein

Delphi-Quellcode:

x.Sin

.