[Delphi] Hab ein paar Fragen zur Sprache

[i_hasser]

Hi

Jetzt hats mich auch erwischt. Ich muss ein Prog schreiben (das ist ja harmlos), und das in Delphi (da darf man sich doch tatsache seinen in feinster Kleinarbeit antrainierten, für andere völlig unlesbaren C/++ -Stiel versauen ).

Im moment hab ich erstmal nur eine Frage - gibts eine Möglichkeit möglichst elegant Steuerelemente während der Programmausführung zu erstellen?

Sowas kann selbst VisualBasic, also es würde mich arg wundern wenn Delphi (nehme übrigens 7) sowas nicht kann.

[i_hasser]

Bin jetzt per Google selbst drübergestollpert -

var
  Button: TButton;
begin
  Button:=TButton.Create(Form1);
  try
    with Button do 
    begin
      Parent:=Self;
      Left:=Random(Form1.ClientWidth-Width);
      Top:=Random(Form1.ClientHeight-Height);
      Caption:='Button';
    end;
  except
    Button.Free;
  end;
end;

Dieser grässliche Delphi Code erzeugt neue Elemente.

[i_hasser]

Gibts eigentlich die Möglichkeit in Delphi irgendwie Makros zu definieren?

Also genau machen will ich das hier:

#define { begin
und
#define } end

[i_hasser]

Hab noch eine Frage.

Will einer Prozedur ein Multidimensionales dynamisches Array als Parameter geben.


Also sowas

procedure blabla(a: array of array[0..2] of Integer;...);

Klappt aber net, delphi meckert rum

[\²³/]

Original geschrieben von intel_hasser
Gibts eigentlich die Möglichkeit in Delphi irgendwie Makros zu definieren?

Also genau machen will ich das hier:

#define { begin
und
#define } end

;D

Was meinst du mit Makros?

Vielleicht einfach eine Protzedur?

Also, dass du schreibst

procedure tudas;
begin
//Das soll das Prog machen, wenn ich tudas aufrufe: 
Form1.Color:=clred;
end;

Dann schreibst du in deinem Quelltext

procedure TForm1.Button1Click(Sender: TObject);
begin
tudas; // jetz wird das gemacht, was in der Prozedur tudas steht, wenn ich den Button1 klicke 
end;

[i_hasser]

Nein nein, in C kann man zb. sowas machen.

statt

void main()
{
   for(...)
   {
       ...
   }
}

Können die Pascal-Freaks (für mich nicht nachvollziehbar wie man so eine Sprache ernsthaft zu irgendwas benutzen kann) zb. sowas hier machen:

#define begin {
#define end }

void main()
begin
   for(...)
   begin
      ...
   end
end

Die beiden Defines da oben sind Makros, der Compiler ersetzt vor dem eigentlichen kompilieren dann das begin und end durch { und }


EDIT: Ach ja, jetzt sieht man mal wieder was für einen hässlichen Einfluss Pascal doch hat. Hab die Funktionsdeklarationen korrigiert

[TiKu]

Nee, Makros sind was anderes. In C/C++ kann man Makros definieren. Diese werden beim Kompilieren vom Präprozessor aufgelöst und sehen bspw. so aus:

#define SECUREFREE(x) free(x); x = NULL

oder

#define SECURESIZEOF(x) sizeof(x) / sizeof(TCHAR)

Im Programm schreibt man dann nur noch:

// allocate 100 bytes
void* p = malloc(100);
// do something with the mem
...
// free the mem
SECUREFREE(p);  // the preprocessor will replace this with free(p); p = NULL;
// p is now NULL

Makros sind also quasi sowas wie Konstanten, die man auch für Quellcode nutzen kann.

Intel_hasser möchte mit Makros seinen Delphi-Code etwas nach C/C++ aussehen lassen, indem er das begin und end mit { und } ersetzt. Ich halte das aber für ziemlichen Blödsinn.

@intel_hasser: Schlag bitte mal im Duden die Bedeutungen von Stiel und Stil nach.

/e: Verdammte Axt, zu langsam

[\²³/]

Also bitte, intel_hasser, mach doch mal (Object-)Pascal so runter, ja.

[i_hasser]

Original geschrieben von \²³/
Also bitte, intel_hasser, mach doch mal (Object-)Pascal so runter, ja.

Tue ich doch die ganze Zeit schon

Nein, also mal im Ernst. Der Syntax ist grauenhaft - ok, daran kann man sich vielleicht noch gewöhnen. Dann ist jede Unit eine Ansammlung von Sonderfällen, anders kann man es garnet bezeichnen. So ein Haufen Zeugs was da sinnlos drinnen rumsteht, C/++ kommt ohne diese ganzen Begriffe aus (zb. uses, interface, implementation).
Aber das ist auch noch nicht so schlimm. Wirklich schlimm ist, dass Delphi so ein haufen Zeugs ohne Nachfrage automatisch reinpackt. Dann wird nicht zwischen Groß/Kleinschreibung unterschieden.

Furchtbar!

Und dann hat der Syntax auch eklatante Schwächen. Das fängt damit an, dass man Funktionen allen Anschein nach eben keine Multidimensionalen Arrays geben kann (Variablen kann man aber durchaus so deklarieren) und hört bei Sachen wie Klammersetzung auf. Bei C kann man zb. auch semantische Klammern setzen (zb. ist int (*a)[123] was anderes als int *(a[123]) ).
C/++ ist durch und durch logisch aufgebaut. Manchmal, wenn ich von irgendwas nicht weis wie es geht schreibe ich einfach hin wie ich es mir denke und idR funktioniert es dann problemlos (weil sich der Syntax eben logisch erschließen lässt).

[\²³/]

Ich verstehe echt nicht, was du willlst.
Wenn dir Delphi nicht gefällt, dann bleibt du doch bei deiner MS Sprache.
Wir sind doch keine Kleinen Kinder, und bewerfen uns jezt Stunden/Tage/Wochen/Monate/Jahre/für den rest unseres Lebens mit Schlamm, nur weil wir unterschiedliche Vorlieben in den Sprachen haben.

So long, und nicht weiter


\²³/

[Procyon]

Tach erstmal

Original geschrieben von intel_hasser
Hab noch eine Frage.

Will einer Prozedur ein Multidimensionales dynamisches Array als Parameter geben.


Also sowas

procedure blabla(a: array of array[0..2] of Integer;...);

Klappt aber net, delphi meckert rum

ich weiß nicht in wie weit Delphi (zum Kotzen die Sprache ... aber TP rult!) dynamische Arrays unterstützt ... aber multidimensionale Arrays gehen so:

var a:array[0..2,0..2] of integer;

versuch das ganze mal als Referenzparameter zu übergeben:

procedure blabla(var a: array of array[0..2] of Integer;...);

[i_hasser]

Ok, versuch ich. In der Hilfe stand eben array of array of ... - ohne Indizangaben ist das Array dann dynamisch.

Das Problem ist, dass er bei Parametern nach dem ersten array of rummäkelt. Eben ein Compiler, der seine eigenen Sprache nicht versteht - zuletzt sah ich sowas bei QBasic, wo man bei for-Schleifen keine Arrayelemente als Zähler angeben kann

@\²³/

C/++ ist doch keine MS Sprache! Ich nehm für sowas 4 Compiler - den Gnu CC/g++ für Linux, und die Ports Mingw32 und Cygwin für Windows, sowie DJGPP für Dos.
GNU für alle Systeme eben

So Portabel ist Delphi nichtmal ansatzweise. Normalerweise komme ich mit den Delphi-Leuten gut klar - ich weis, dass die Sprache weniger Leistungsfähig ist und desswegen benutze ich sie einfach nicht.
Dummerweise muss ich das Prog diesmal in Delphi schreiben *FingerindenHalssteck* und desswegen ist's vorbei mit der Neutralität.

[TiKu]

Original geschrieben von intel_hasser
So Portabel ist Delphi nichtmal ansatzweise.

Naja, für Linux gibt's Kylix. Also ist Delphi doch schon relativ portabel.

Ich mag Delphi/Pascal auch nicht, lass das aber nicht so raushängen.

[i_hasser]

Wie gesagt, mich ärgert es auch nur, dass ich das jetzt selbst nehmen muss. Sonst würde ich da auch net so drüber herziehen

Kylix geht für Linux. GnuC/++ gibts für alles wo Unix drauf oder dransteht (oder drinnen steckt wie bei Linux), und das selbstverständlich für alle möglichen und unmöglichen Hardware Plattformen (sogar für intels missglückten i960).

Was ist portabler?

[TiKu]

Ich habe nicht gesagt, dass Delphi portabler ist als C/C++.

[i_hasser]

Hab mal noch eine Frage (ich hoffe ich hab mit meinem Gewettere jetzt nicht alle Delphianer aus dem Thread vertrieben, so langsam gewöhne ich mich an die komischen Umgangsformen von Delphi).

Will eine Klasse, die mehrere andere Klassen implementiert. In C würde ich das so schreiben:

class a
{
...
}

class b
{ 
...
}

class c : public a, public b
{
... // alles von a
... // alles von b
... // neues, was wir in c dazuimplementieren
}

In Delphi geht das irgendwie nicht so gut.

c = class(a)

Implementiert ja eine Klasse, aber wie geht das mit 2 oder mehr Klassen?

[mtb][sledgehammer]

Zu deiner letzten Frage: du meinst wohl mit implementieren vererbenen (ich hab noch kein C geschrieben, sodass ich dessen Begrifflichkeit und Code nicht 100% verstehe).
Und soweit ich weiß gibts in Delphi (wie auch in Java) keine Mehrfachvererbung. (Und laut meinem Info Dozent ist das auch gut so. [Und wenn man logisch programmiert, braucht man das auch nicht "duck_und_renn"] ).
(Edit: jetzt verstehe ich warum du implemtieren schreibst. Implementieren geht einfach, ist wohl aber nicht 100% schön:

so:
TClasssC = class
  A: TClassA;
  B: TClassB;
end;

oder so:
TClassC = class(TClassA)
  B: TClassB;
end;

Hilft dir allerdings nicht unbedingt weiter, wenn du Ploymorphismus (hoffentlich richtiger Begriff) nutzen willst.

Dein Problem mit den mehrdimensionalen Arrays ist eines womit ich selber schon ein wenig gekämpft habe, die Lösung müsste ich erstmal wieder in einbem Quellcode suchen. Probier es mal mit dynamischen arrays oder mit einem neu definierten DatenTyp:

type NewType = array[a..b] of array[c..d] of int;

Keine Garantie für 100% richtigen Quellcode, hab in letzter Zeit wenig geschrieben

Von Makros habe ich keine Ahnung, schreib einfach begin und end, ist sowiso viel leserlicher als das Hyroglyphenzeugs (ich sag nur == = ^ != % / ), OK ich geb zu das ist Geschmacksache

@

var
  Button: TButton;
begin
  Button:=TButton.Create(Form1);
  try
    with Button do 
    begin
      Parent:=Self;
      Left:=Random(Form1.ClientWidth-Width);
      Top:=Random(Form1.ClientHeight-Height);
      Caption:='Button';
    end;
  except
    Button.Free;
  end;
end;

Was ist daran hässlich? Du könntest noch die try except end; Ausnahmebehandlung weglassen, sofern du dir sicher bist, dass alles tut.

[skyphab]

Hö, um was gehts jetz?
Mehrdimensionale Arrays sind doch einfach nur ein Array mit Arrays als Felder? Dann noch einen Rekord reinpacken und er ist 3-Dimensional.
Das Ganze als Typ definieren und in einer Methode als Eingangsparameter oder Ausgangsparameter definieren. Was ist daran schlecht?

// Ist jetzt halt nur 2D

interface

type RSchlumpf = record
  Name : string;
  Alter: integer;
end;

type TSchluempfe = array [0..10] of RSchlumpf;

implementation

procedure test(iSchluempfe: TSchluempfe);
begin
end;

Wieso willst du eine Klasse machen, die andere Klassen implementiert? Vererbe doch und implementiere? Blick ich nicht...

:Update: Achso, du vererbst von mehreren Klassen. Das ist bei Delphi nicht zulässig, wie es sich gehört

[i_hasser]

Implementieren und Vererben ist doch eh das selbe .

In Java hat man Interfaces die man implementiert (da heist das Schlüsselwort implement oder implements), in C++ macht man für die selbe Sache eine Klasse mit (optional) virtuellen Funktionen, die man vererbt.

Aber warum solles unsauber sein, mehrere Interfaces zu implementieren? Das artet sonst nur in Klassenwühlerei aus, also ich seh da ehrlich nix schlechte - in Java geht das auch problemlos (also afaik kann eine Klasse mehrere interfaces implementieren, hab sowas in Java aber auch noch nie gebraucht).

Mit Klassenwühlerei meine ich das hier:

a=class
  ...
end;

b=class
  ...
end;

// Wenn wir die nun beide in C implementieren wollen und das so machen würden

c=class
  ca: a;
  cb: b;
end;

// Haben wir ein Problem, wenn Funktionen von A auf Funktionen von C zugreifen sollen
// Ergo müssen wir erstmal noch haufenweise abgeleitete Klassen von A/B erstellen, so ungefähr

a1=class(a)
  parent: c;
  // Funktionen und deren Implementierung, wie wir es normalerweise in "class c: public a, public b" gemacht hätten
end;

b1=class(b)
  parent: c;
  // nochmal das selbe
end;

// und nun die endültige Implementierung bzw. die eigentlich richtige vererbung:
c=class
  ca: a1;
  cb: b1;
end;

Sonst bekomm ich aus einer Funktion von a keinen Zugriff auf die Funktionen, die ich sonst noch so in C reinpacke. Mit einer Mehrfachvererbung könnten wir uns a1 und b1 sparen, bzw. würden die nahtlos in C wandern, ohne den Namespace zu verpesten.



Momentan hab ich mich erstmal um die Arrays gedrückt, aber das muss ich früher oder später auch implementieren. Danke auf jeden Fall für den Source.

[skyphab]

Wie das mit Interfaces ist, weiß ich gar nicht. Bei Mehrfachvererbung meine ich wirklich nur die Vererbung von Attributen und Methoden einer Klasse auf die Unterklasse.
Soweit ich weiß, kann man bei C Mehrfachvererbung betreiben, sprich (so wie du es geschildert hast), die Klasse C setzt sich aus Klasse A und Klasse B zusammen.

Wenn ich mich recht entsinne, wurde das aber abgeschafft und auch bei Java kann man keine Mehrfachvererbung machen, genauso wenig wie bei ObjectPascal. Vielleicht ist das bei den Interfaces anders.

Mehrfachvererbung ist sicher praktisch, verleitet aber evtl. zu unsauberen Konzepten. Eine Klasse kann mehrfache Beziehungen haben, sich aber definitiv nur von einer Klasse ableiten.
Wenn sich jetzt Klasse A aus Klasse B und C zusammensetzt, müssen B und C konzeptionell etwas gemeinsam haben, was sich in A vereint. Wenn B und C etwas gemeinsam haben, müsste das dann aber in einer übergeordneten Klasse verankert sein und A würde sich dann genauso wie B und C von dieser ableiten.

Man muss natürlich das Konzept etwas anders aufbauen, aber ohne Mehrfachvererbung ist die konzeptionelle Linie schon klarer zu sehen. Im Grunde aber Geschmackssache, ich habe noch nie mit Mehrfachvererbung gearbeitet

[i_hasser]

B und C können aber auch völlig verschiedene Funktionen beinhalten, deren Ausführung im Fall der Klasse A nur voneinander abhängt

Ich wüsste nicht, dass die Mehrfachvererbung in C abgeschafft werden soll. Die Interfaces in Java sind eine Besonderheit von C Klasse, nämlich wo keinerlei Code implementiert ist und alles eben nur virtual ist.

[skyphab]

Wenn B und C aber völlig unterschiedlich sind, ist eine Mehrfachvererbung auch fragwürdig. Klar kann das einfacher sein, aber das wäre ja wie wenn sich ein Kind aus einer Klasse Mensch und einer Klasse Fahrrad zusammensetzt. Das geht auch nicht

In C bleibt die Mehrfachvererbung natürlich. Nur die neueren OO-Sprachen kennen keine Mehrfachvererbung (z.B. Java, ObjectPascal oder auch ABAP Objects).

Bei Interfaces mag es anders sein. Da machts ja auch wieder Sinn, dass eine Klasse von mehreren Interfaces bedient wird, da sie ja auch unterschiedlichste Schnittstellen haben kann. Aber wie gesagt, hab mich damit nie tiefer beschäftigt.

Da du vorhin dynamische Arrays angesprochen hast: array [0..0] of x ist zwar dynamisch, aber du musst dann den Speicher manuell erweitern und verringern. Ist in Delphi etwas umständlich gemacht.

Ich verwende mittlerweile fast keine Arryas mehr, sondern ObjectList-Container. Die sind von Natur aus dynamisch und beherbergen nur Objekte. Falls du mal drüberstolperst

[mtb][sledgehammer]

Genau das meinte ich im Prinzip mit
"Und wenn man logisch programmiert, braucht man das auch nicht"
Man könnte aus einem Mensch einen Fahrradfahrer vererben, der als Attribut ein Fahhrad hat. Aber aus einem Mensch und einem Fahhrad ein Fahhradmensch zu erstellen, welcher Beine und Räder hat, ist schon komisch.
Um intel_hassers Problem zu lösen, muss man eben bei den höher geordneten Klassen allgemeiner programmieren, sodass sich in Klasse A alles befindet, was Klasse C auch aus B braucht.

[i_hasser]

Werd ich mir mal anschauen

Nochmal zu Klassen/Interfaces. Interfaces in Java sind ein Spezialfall von Klassen in C++.

interface a
{
  public:
    void x();
    void y();
};

in Java entspricht exakt (also wirklich exakt)

[code]
class a
{
public:
virtual void x();
virtual void y();
};
[/code

In C++. Nur implementiert man eben in Java ein Interface, und in C++ vererbt man die Klasse.
In Java kann man mehrere Interfaces implementieren, und in C++ kann man eben mehrere Klassen implementieren. Beide Varianten implementieren eine Schnittstelle, und keinerlei Code - anders als mit Mehrfachvererbung geht das in C++ nicht, genauso wie es eben nur über das Implementieren von mehreren Interfaces in Java geht. Desswegen hat die Mehrfachvererbung in C++ durchaus ihren Sinn.

[mtb][sledgehammer]

Bei der mehrfachvererbung in C++ müsstest du allerdings auch Code mitvererben können, was bei Interfaces in Java einfach nicht geht. Ein Interface ist eben nur eine Schnittstelle auf die andere Programmteile zugreifen können, wenn sie wissen, dass eine Klasse dieses Interface hat. Bei der Mehrfachvererbeung hingegen besteht die neue Klasse aus den Eigenschaften der Vofahren.