PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : [Delphi] Hab ein paar Fragen zur Sprache



i_hasser
12.06.2004, 21:25
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
12.06.2004, 22:05
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
12.06.2004, 22:30
Gibts eigentlich die Möglichkeit in Delphi irgendwie Makros zu definieren?

Also genau machen will ich das hier:

#define { begin
und
#define } end

;D

i_hasser
12.06.2004, 23:20
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 :(

\²³/
13.06.2004, 00:55
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
13.06.2004, 01:39
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
13.06.2004, 01:41
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 *motz*

\²³/
13.06.2004, 02:40
Also bitte, intel_hasser, mach doch mal (Object-)Pascal so runter, ja. 8-(

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

Tue ich doch die ganze Zeit schon ;D

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

\²³/
13.06.2004, 09:22
*noahnung* Ich verstehe echt nicht, was du willlst.
Wenn dir Delphi nicht gefällt, dann bleibt du doch bei deiner M$ 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
13.06.2004, 09:50
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
13.06.2004, 11:59
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 ;D - zuletzt sah ich sowas bei QBasic, wo man bei for-Schleifen keine Arrayelemente als Zähler angeben kann *lol*

@\²³/

C/++ ist doch keine m$ 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 ;D

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
13.06.2004, 12:15
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
13.06.2004, 12:23
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
13.06.2004, 12:29
Ich habe nicht gesagt, dass Delphi portabler ist als C/C++.;)

i_hasser
13.06.2004, 12:31
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
13.06.2004, 14:43
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
13.06.2004, 14:53
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
13.06.2004, 15:19
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
13.06.2004, 15:34
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
13.06.2004, 15:44
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
13.06.2004, 15:54
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 *buck*

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
13.06.2004, 16:07
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
13.06.2004, 16:09
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
13.06.2004, 16:16
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.

i_hasser
13.06.2004, 16:22
Wenn du aber eine Klasse komplett virtual deklarierst (sprich jede Funktion als virtual) bekommen die Funktionen in der Klasse selbst keinen Code, den musst du dann in der vererbten Klasse implementieren.

In Delphi würde das so aussehen:



a=class
procedure b(); virtual; abstract;
end;


Wenn du die Klasse a erstellst und b aufrufst gibts eine Exception, weil die Funktion b nicht implementiert ist. Praktisch genauso läuft es auch in C++ ab. Die Funktion b kannst du dann eben in der Klasse implementieren, die du aus b abgeleitet hast - oder auch nicht, und erst in der Klasse danach, also wie es einem eben gefällt.

Also es gibt in C++ Klassen, die nicht eine Zeile Code enthalten (übrigens ist das virtual-Schlüsselwort nur optional). Und die entsprechen haargenau den Interfaces in Java.

skyphab
13.06.2004, 16:28
Ja redest du die ganze Zeit nur von Interfaces? Dann mach doch einfach ein Interface in Delphi ;)

Ich hab damit noch nie gearbeitet, stöbere gerade in der Hilfe, wie das ist.


type i = interface
end;

type a = interface
end;

type b = class(TInterfacedobject,i,a)
end;

i_hasser
13.06.2004, 16:36
Interfaces sind doch nur eine Spezialform von Klassen ;)

Aber da hast du recht, ich könnte einen Teil der Klassen auch als Interfaces deklarieren, weil die wirklich nur virtual funktionen implementieren.

skyphab
13.06.2004, 16:41
Original geschrieben von intel_hasser
Interfaces sind doch nur eine Spezialform von Klassen ;)

Aber da hast du recht, ich könnte einen Teil der Klassen auch als Interfaces deklarieren, weil die wirklich nur virtual funktionen implementieren.

Das ist richtig, nur mit Interfaces könntest du dann die Mehrfachvererbung vollziehen, die du doch willst :)
Auch wenn eine Klasse abstrakt ist, kannst du sie nicht mehrfach vererben. Da Interfaces grundsätzlich abstrakt sind, geht das.

Wahrscheinlich hat man bei den neuen OO-Sprachen Interfaces eingeführt, um die Sache mit der Mehrfachvererbung eliminieren zu können. Da bei C Mehrfachvererbung möglich ist, braucht man auch keine Interfaces, da man sie sich aus Klassen baut.

i_hasser
13.06.2004, 16:54
Ja, ich hatte eben nur nicht daran gedacht, dass man auch mehrere Interfaces implementieren kann, weil es die in C++ eben auch nur einfache Klassen sind ;).

Auf jeden Fall ein großes Dankeschön, damit wird so einiges leichter.

Hab allerdings noch eine Frage *buck*

Ich will 2 Units aufeinander verweisen lassen. Bei uses ... bekomm ich die Fehlermeldung, dass die Units gerade das machen.

Grund - brauche sowas, will das aber besser strukturieren (so wie ich es hingeschrieben hab funktioniert es):



type

a=class;
b=class;

a=class
public
procedure x(ptr: b);
end;

b=class
public
procedure y(ptr: a);
end;


Also 2 Klassen, die irgendwo Links aufeinander enthalten (hier ja als Funktionsargumente).
Wenn ich das in eine unit a und b packe und die Prototypen oben dazuschreibe bekomme ich aber eine Fehlermeldung, dass je ein Prototyp (in unit a b, in b a) nicht implementiert wird bzw. nicht definiert wird.

Gibts da irgend eine elegante Lösung?

skyphab
13.06.2004, 18:45
Das mit den Units ist etwas fummlig :)
Ich sage einfach mal, wie ich es mache:

Alle Typendeklarationen (Records, Arrays) in eine extra Unit: Unit_Types.pas
Jede Klasse in eine extra Unit: Klasse_a.pas, Klasse_b.pas usw

In den Klassenunits muss man nun auf die anderen Units verweisen, dabei gilt folgendes: Du kannst (z.B.) nur Unit b in Unit a in der uses-Klausel stehen haben, hat auch Unit b Unit a in der Uses-Klausel, ist das ein Fehler. Das gilt für den Abschnitt interface, ausgenommen sind die Delphi-eigenen Units (SysUtils, Classes, etc.)

Du kannst nach dem Wort implementation aber nochmal Uses deklarieren und dort alle Units wild und quer aufeinander verweisen lassen.

Du brauchst eine Unit nur unter interface zu deklarieren, wenn du auch etwas von ihr im Abschnitt interface brauchst (z.B. Datentypen, oder Klassennamen für Vererbungen). Falls nicht, einfach nach implementation deklarieren.

Bei mir ists dann so, dass jede Klassenunit dann unter interface Unit_Types deklariert und die Units in denen Klassen drinstehen, von denen vererbt wird.
Braucht man andere Units (Aber nicht im Interface-Abschnitt), sind die dann nach implementation.

Ich hoffe das war verständlich :)

Noch ein Tipp: Als private deklarierte Attribute und Methoden werden nicht über verschiedene Units hin vererbt. Da muss man dann protected nehmen. Hat mich viele Nerven gekostet *buck*

i_hasser
13.06.2004, 18:58
Original geschrieben von skyphab
Das mit den Units ist etwas fummlig :)
Ich sage einfach mal, wie ich es mache:

Alle Typendeklarationen (Records, Arrays) in eine extra Unit: Unit_Types.pas
Jede Klasse in eine extra Unit: Klasse_a.pas, Klasse_b.pas usw

In den Klassenunits muss man nun auf die anderen Units verweisen, dabei gilt folgendes: Du kannst (z.B.) nur Unit b in Unit a in der uses-Klausel stehen haben, hat auch Unit b Unit a in der Uses-Klausel, ist das ein Fehler. Das gilt für den Abschnitt interface, ausgenommen sind die Delphi-eigenen Units (SysUtils, Classes, etc.)

Du kannst nach dem Wort implementation aber nochmal Uses deklarieren und dort alle Units wild und quer aufeinander verweisen lassen.

Du brauchst eine Unit nur unter interface zu deklarieren, wenn du auch etwas von ihr im Abschnitt interface brauchst (z.B. Datentypen, oder Klassennamen für Vererbungen). Falls nicht, einfach nach implementation deklarieren.

Bei mir ists dann so, dass jede Klassenunit dann unter interface Unit_Types deklariert und die Units in denen Klassen drinstehen, von denen vererbt wird.
Braucht man andere Units (Aber nicht im Interface-Abschnitt), sind die dann nach implementation.

Ich hoffe das war verständlich :)

Noch ein Tipp: Als private deklarierte Attribute und Methoden werden nicht über verschiedene Units hin vererbt. Da muss man dann protected nehmen. Hat mich viele Nerven gekostet *buck*


Ich mag Delphi nicht *chatt*

Da werd ich das wohl einfach so stehen lassen. Das mit Private ist normal, das geht immer verloren. In C++ kannst du dir das aber aussuchen, eben indem du statt class a: public b eben zb. class a: private b oder class a: protected b nimmst. Virtual geht an der Stelle auch, so kann man eine komplette Klasse Virtual implementieren, also class a: virtual public b

Novox
14.06.2004, 13:05
Original geschrieben von intel_hasser
Ich will 2 Units aufeinander verweisen lassen. Bei uses ... bekomm ich die Fehlermeldung, dass die Units gerade das machen.

Kein Wunder, zyklische Verweise gibt’s in Delphi nicht.

i_hasser
14.06.2004, 16:17
Aber anscheinend gibts in Delphi ja auch nicht mal richtige Prototypen, womit das kein Problem wäre und wodurch man das dann auch durch einen einfachen zyklischen Verweis in zb. C++ lösen kann.

skyphab
14.06.2004, 18:14
Prototypen? Für was braucht man denn sowas schonwieder *buck*

i_hasser
14.06.2004, 18:20
Jaja, so sind die Delphianer - kennen nichtmal wichtigste Grundbegriffe *buck*

In Delphi machst du auch Prototypen. Nur heist es da nicht so (und das Wort Prototyp kommt in C auch nirgends vor).

Das ist zb. einer:

int main();

(man beachte, kein {...} sondern einfach ; ).

Das sagt dem Compiler, dass er früher oder später über die Funktion main stolpern wird. Sowas geht auch mit allen anderen Dingen, zb.

class a;

oder

class a
{
int b();
int c();
};

Beides sind Prototypen, der letzte prototypisiert dabei auch die Funktionen in der Klasse.
Implementieren kann man die Funktion dann zb. so

a::b()
{
...
}

Aber wenn vor der Implementierung schonmal irgendwas die Funktion b der Klasse a aufruft gibts eben keinen Compiler-Fehler. In C kann man die Prototypen da machen wo es einem Spaß macht (idR packt man es in den header), und so genau wie man will (zb. erst class a; dann mit Funktionen - http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=165184 hier braucht man das zb.).

Funktionszeiger enthalten auch Prototypen von Funktionen (sowas kennt Delphi nichtmal ansatzweise) - so zb. void (*a)(int, float);

skyphab
14.06.2004, 22:19
Jagut, Delphianer bin ich erst seit 6 Monaten und in 3 ist das dann gottlob auch wieder vorbei, bin also kein Eingefleischter :)

Also ich sehe jetzt zwar was die Prototypen sind, nur den notwendigen Sinn verstehe ich noch nicht ;)

C++ ist natürlich schon mächtiger und komplexer als Delphi. Aber da Delphi um einiges einfacher ist, ist es für zwei kleine Projekte im 5-Stelligen Bereich lukrativer :) Ich finde es toll, wie man auch später recht komplexe Sachen ziemlich einfach realisieren kann und das noch mit einer schnellen Laufzeit.

i_hasser
14.06.2004, 22:48
Naja, schau dir mal den Borland C++ Builder an. Ich weis jetzt net wie es im Moment um den steht, aber früher war das praktisch Delphi nur mit C++.

C++ ist durchgehend genauso einfach wie Delphi. Das ist ja das schöne ;).
Und C++ bietet auch mindestens die selben Möglichkeiten bezüglich Klassen wie Delphi, und damit ist es je nach Programmierstiel eben auch kein Problem früher oder später noch irgendwas zu erweitern. Delphi allein betrachtet ist wirklich garnicht so schlecht, mich stört nur, dass Borland da unbedingt sein eigenes Süppchen kochen muss (gibt ja von niemanden sonst was gescheites zu Pascal) - wie gesagt, C++ ist nicht im geringsten schwieriger (oft muss man nur den Syntax auf C übertragen) aber der Syntax ist viel weiter verbreitet (der C Syntax kommt ja in Java, PHP, Perl, JavaScript und noch vielen anderen Sachen zum Einsatz) und auch viel leistungsfähiger. Der Pascal Syntax hat so einiges mit dem Basic Syntax gemein (wenn ich es mir recht überlege sogar ziemlich viel, nur dass der Basic Syntax an einigen Stellen elegant-kürzer ist).

Soll Borland lieber den C++ Builder aufpolieren (die letzte Version die ich selbst genommen hab war 4.0) und Delphi endlich in den Ruhestand schicken. Wie gesagt, Delphi hat fast nur einen anderen Syntax als C++.

Mal ein paar Beispiele wo Basic kürzer ist als Delphi (sorry, das kann ich mir jetzt einfach nicht verkneifen ;D):



Pascal

for i:=0 to n do
begin
...
end;

Basic

for i=0 to n
...
next i '// (das ist übrigens wirklich was sinvolles, bei C hab ich es mir angewöhnt die Zählervariable per Kommentar hinten dran zu schreiben, bei Basic geht es direkt aus dem Code hervor)

C++

for(i=0;i<=n;i++)
{
...
}





procedure xyz(a: Integer; b: Integer);
var
...
begin
...
end;

Sub xyz(a as integer, b as integer)
... '// Bei Basic werden Variablen im Code deklariert
... '// Code
End Sub

void xyz(int a, int b)
{
... // Variablen
... // Code
}



So lassen sich viele Beispiele finden, die C++ Variante hab ich nur der Vollständigkeit halber mit drangesetzt. Ich hab damals mit VB6 aufgehört, desswegen weis ich nicht, wie man in vb.net Klassen deklariert - der Syntax dürfte dem Pascal Syntax aber wieder ziemlich ähnlich sein. Auch sowas wie With Blöcke (die in Basic und Pascal auch mit "with varname" anfangen) sind fast völlig identisch.

hmm.... Typendeklarationen sind auch ähnlich. Auch die If Anweisungen gleichen sich ziemlich.



Pascal

if [Bedingung] then
begin
...
end;

if [bedingung then ...;

Basic

If [Bedingung] Then
...
End If

If [Bedingung] Then ...

C++

if([Bedingung])
{
...
}

if([Bedingung]) ...;




Beim Funktionsaufrufsyntax gibts auch so einige Ähnlichkeiten:



Pascal

procedure xyz();
begin
...
end;

xyz(); // gültig
xyz; // gültig

Basic

Sub xyz();
...
End Sub

xyz() // gültig
xyz // gültig

C++

void xyz() {...}

xyz(); // gültig
xyz; // ungültig, xyz ist ein einfacher Zeiger auf eine Funktion (da steckt in C zb. wieder viel mehr Logik), damit Code ausgeführt wird muss ein () dahinter

// Sowas geht rein nach C Syntax zb. auch:
void *a; // void Zeiger zeigen genau genommen auf "nichts", und speichern nur die Adresse im Speicher

a=xyz; // a zeigt jetzt auf die Funktion xyz

( (void (*)()) a )(); // Da man das so idR nicht braucht sieht der Syntax auch abenteuerlich aus.
// Das wandelt den Zeiger a in einen Funktionszeiger auf eine Funktion der Form void() um und ruft diese Funktion auf. Nur ein Beispiel für die Leistungsfähigkeit des Syntaxes
// Eigentlich ist der Syntax aber auch ziemlich einfach - ( (cast operator, wandelt den Zeigertyp um) Variable)(Parameter - xyz will keine Parameter)



Ich merk schon, ich schweife ab ;D.
Morgen bekomme ich das Delphi Prog hoffentlich fertig - die Chancen stehen gut ;)


PS

Ach ja, Rückgabewerte:



function a() : integer;
begin
...
a:=n;
exit;
end;

Function a() as Integer
a=n
exit
End Function

int a()
{
return n;
}

skyphab
14.06.2004, 23:01
Delphi scheint gegenüber C++ ein bisschen 'entmatheisiert', was die Ausdrücke angeht. In der Delphi Hilfe steht ja auch immer die C++ Syntax, da hab ich mich in der Tat schon des öfteren verguckt ;)

Da du es aber anscheinend kurz und prägnant magst, musst du wohl mal ABAP-Quellcode vor Augen geführt bekommen, da schreibst ganze Romane. Werde morgen mal was posten *buck*

Hier ein Vorgeschmack:



Pascal:

Name := One + ' ' + Two + ' ' + Three;

ABAP:

CONCATENATE ONE TWO THREE INTO NAME SEPARATED BY SPACE.


Fehlt nur noch die Kommasetzung bei ABAP, dann wär's ein Satz *lol*
ABAP hat aber auch einen anderen Ansatz und enorm viel integrierte Logik, trotzdem teilweise derb.

TiKu
14.06.2004, 23:05
Original geschrieben von intel_hasser
ProgrammierstielArgh, es heißt Stil! Und übrigens auch die Syntax.;)


Original geschrieben von intel_hasser

Sub xyz(a as integer, b as integer)
... '// Bei Basic werden Variablen im Code deklariert
... '// Code
End Sub

void xyz(int a, int b)
{
... // Variablen
... // Code
}
So ganz das selbe ist das aber nicht. Die Visual-Basic-Variante müsste so aussehen:
Sub xyz(ByVal a As Integer, ByVal b As Integer)

Original geschrieben von intel_hasser
Ich hab damals mit VB6 aufgehört, desswegen weis ich nicht, wie man in vb.net Klassen deklariert
<Modifier> Class xyz ... End Class

TiKu
14.06.2004, 23:08
Original geschrieben von skyphab


Pascal:

Name := One + ' ' + Two + ' ' + Three;

ABAP:

CONCATENATE ONE TWO THREE INTO NAME SEPARATED BY SPACE.
Alles in Großbuchstaben?? Da würde ich durchdrehen. Wenn man da ein längeres Programm liest, bekommt man ja Augenkrebs.*buck*

i_hasser
14.06.2004, 23:11
hmm... ja, mein gott. Nobody is perfect ;D

Ok. Dann werden die Vars eben ByRef übergeben. Da ist C wieder logischer als VB oder Delphi, alles wird ByVal übergeben. ByRef wird da so realisiert:



void a(int a, int* b)
{
a=3; // ändert den Parameter a nicht
*b=4; // ändert den für b übergebenen Parameter
}


a wäre in VB ByVal, b wäre in VB ByRef - entsprechend muss man auf B auch wie auf einen Zeiger zugreifen.

Wie wird das eigentlich in Delphi gehandhabt?

TiKu
14.06.2004, 23:14
Keine Ahnung, vll. auch als Pointer (per ^).
Bei VB.net ist übrigens nicht mehr ByRef Standard, sondern ByVal.

i_hasser
14.06.2004, 23:25
Naja, in Delphi sind die Zeiger nicht wirklich gut implementiert... -> schlechter Programmierstil ;)

In C/++ kommt man ohne Zeiger nicht vorwärts, trotzdem ist das alles ziemlich sauber. In Delphi sind erzeugte Klassen ja immer Zeiger - in C kann man eine Klasse auch direkt ansprechen, also zb. "classxyz a;"

Um das mit Delphi "gleichwertig" zu gestallten müsste man "classxyz *a;" schreiben.


@skyphab

Das ist allerdings ziemlich... *chatt*
Dagegen ist ja selbst Cobol noch harmlos *lol*

skyphab
15.06.2004, 09:03
Cobol ist ja ein indirekter Vorgänger von ABAP. Hier nochmal was ;D


DELETE ADJACENT DUPLICATES FROM Chargenmerker.


WRITE (15) IZ2BDE_ME-MENGE RIGHT-JUSTIFIED COLOR COL_TOTAL INTENSIFIED ON NO-GAP.


SHIFT <stelle1> LEFT DELETING LEADING SPACE.

Ist teilweise schon extrem umständlich. Aber dafür hat man auch z.B. hiermit


PARAMETERS i_begdat LIKE sy-datum

mal locker ein Eingabefeld für den Benutzer auf der Maske definiert, oder 'SUM' summiert alle zu summierenden Felder einer Tabelle.


MOVE-CORRESPONDING z2bde_me TO iz2bde_me.

schiebt alle Felder der Tabelle z2bde_me in die Tabelle iz2bde_me, die die gleiche Struktur haben, auch schick :D

Sind spürbar andere Ansätze, naja 4GL halt *buck*

i_hasser
15.06.2004, 09:39
So langsam verstehe ich, wieso Sources öffentlich als Sprache anerkannt sind *buck*

skyphab
15.06.2004, 10:22
Manche Sachen sind echt extrem. So sind die Programme wortwörtlich selbsterklärend ;D

i_hasser
15.06.2004, 10:28
Lass mich raten - in ABAP kann man keine Kommentare setzen? *buck*

skyphab
15.06.2004, 12:40
Original geschrieben von intel_hasser
Lass mich raten - in ABAP kann man keine Kommentare setzen? *buck*

Doch, das geht trotzdem *buck*
Es gibt in SAP sogar den sog. Pretty Printer. Der formatiert den Code automatisch ;D

i_hasser
15.06.2004, 16:29
Na sowas macht VisualBasic ja auch (eben eine IDE von m$... QBasic machts nämlich auch *buck*).

Am Anfang ist sowas ja angenehm, aber irgendwann stört es doch. Vor allem würde es beim C Syntax stören, weil es ziemlich hässlich aussieht, wenn zb. bei
a= ( *((int*) b) + ((long long int) c) ) * (d+e); zwischen 2 Elementen immer ganz genau ein Leerzeichen steht.

Das sähe dann so aus:



a = ( * ( (int *) b) + ( (long long int) c) ) * (d + e)


und ist viel unleserlicher. Bei einer Zeile geht das noch, bei 100 Zeilen wirds schon schlimmer. Und vor allem sieht der Code in VB einfach schrecklich monoton aus.

Wie würdest du die Code-Zeile in ABAP eigentlich umsetzen? Die Casts und die Zeigerops kannst du ja weglassen ;).

TiKu
15.06.2004, 16:38
Original geschrieben von intel_hasser
Und vor allem sieht der Code in VB einfach schrecklich monoton aus.Ich hoffe, ich muss mit Dir nie zusammen an einem Projekt arbeiten.*buck* Bei dem was ich mittlerweile so über Deinen Programmierstil weiß...*chatt*
Ich halte mich immer strikt an meine eigenen festen Code-Konventionen. Dadurch ist der Code erheblich lesbarer als wenn er total unregelmäßig formatiert ist.

i_hasser
15.06.2004, 16:54
Ich muss dir wohl mal ein Schnipsel ordentlichen Code schicken. Das was ich bei den Progg Wettbewerben abliefer ist natürlich kein sauberer Code, da ich jede Zeile mindestens n mal umgeändert hab, wobei n proportional zur Wettbewerbsdauer läuft (und idR nie <4 ist *chatt*).

Der große Lesbarkeitsvorteil bei C besteht darin, dass man eben nicht so viele Funktionswörter hat. Kein Then, kein End If/Sub/Function/With..., kein To im For.......

Namensmäßig benutze ich eigentlich ziemlich wenige Vorgaben. Allgemein fange ich Klassennamen immer groß an (C unterscheidet ja Groß/Kleinschreibung) und nehme ziemlich lange Namen (zb. DiskIO_Handler statt DIO_Hndl). Unterstriche nehm ich bei Klassennamen auch gerne.
Funktionen bekommen oft ähnlich lange Namen, fast immer mit irgend einem beschreibenden Präfix (zb. init_set_option statt set_option) womit ich Funktionen im selben Namespace (bzw. in der selben Klasse) grob gruppiere.
Und zu guter letzt Variablen, die bekommen was übrig bleibt - immer klein, kurz und prägnant. Natürlich nur bei lokalen Variablen, globale bekommen lange Namen.
Auf Hilfsvariablen wie i, j, k ... kann ich selten verzichten, und die machen auch vieles lesbarer (wenn ich mit i irgend eine Schleife bastele weis ich sofort, dass ich da nur eine Aktion auf zb. ein Array anwenden will, auf jeden Fall hat das i vor und nach der Schleife keine damit im Zusammenhang stehende Bedeutung).



Ok, manchmal bin ich auch etwas unsauber. Wobei es eher kurz als unsauber ist, sowas mach ich zb. gerne:



for(i=0;i<n;i++) if(...[i]...) break;
if(i==n); // Schleife lief durch ohne, dass die If-Anweisung auch nur 1mal zutraf
else; // Schleife wurde durch break in der If-Anweisung abgebrochen


Sowas macht sich gut, wenn man zb. gucken möchte, ob ein ganzes Array auf 0 steht oder was vergleichbares. Man spart sich eben eine Variable, und das macht den Code im Endeffekt wieder lesbarer. Das ist auch C-konform.

In Delphi sieht das dagegen wegen der anderen For-Schleife wieder ziemlich böse aus, es funktioniert aber trotzdem ;D. Aber Delphi ist ja sowieso ziemlich zimperlich, zb. kann man die Zählervariable in einer For-Schleife net ändern. Viel zu statisch ;) (ich meine damit zb. sowas: for(i=0;i<n;i++) if(...) i+=2;



for i:=0 to n-1 do if ... then break;
if i=n then ...
else ...;


Weil Delphi immer ein for(...;...<=...;...) macht muss man erstmal n-1 einsetzen, und dann wird eben nicht ersichtlich, welchen Wert die Zählervar nach dem Durchlauf hat.



So, jetzt hab ich aber keine Zeit mehr, muss das Delphi Prog weitermachen :(

skyphab
15.06.2004, 23:45
Original geschrieben von intel_hasser

a= ( *((int*) b) + ((long long int) c) ) * (d+e); zwischen 2 Elementen immer ganz genau ein Leerzeichen steht.

Das sähe dann so aus:



a = ( * ( (int *) b) + ( (long long int) c) ) * (d + e)


und ist viel unleserlicher. Bei einer Zeile geht das noch, bei 100 Zeilen wirds schon schlimmer. Und vor allem sieht der Code in VB einfach schrecklich monoton aus.

Wie würdest du die Code-Zeile in ABAP eigentlich umsetzen? Die Casts und die Zeigerops kannst du ja weglassen ;).

Ich glaube die Klammersetzung ändert der Pretty Printer nicht. Geht hauptsächlich um das Einrücken, denn SAP kennt keinen Tabulator *buck* (zumindest in 4.5b nicht, in 4.6, 6.x oder gleich mySAP ist das endlich textorientiert aufgebaut).

Rechnen funktioniert eigentlich wie gewohnt, nur bei den Klammern ist es teilweise wichtig, dass an gewissen Stellen Leerzeichen zwischen den Variablen stehen. bei 4.6+ ist das aber sicher dann auch anders (gottlob).

Typenumwandlung etc. macht ABAP ohnehin automatisch,
MOVE a TO B verschiebt alles in alles, man muss natürlich wissen was man erwartet :)

Edit: Kann man bei Delphi in einer For-Schleife die Zählervariable nicht ändern? Tönt mir etwas unsauber, dafür hat's doch While-Schleifen? Inc(i) ist zwar nicht so kurz wie i++, aber auch noch akzeptabel :)

i_hasser
16.06.2004, 00:48
Casts braucht man ja aber zb. auch für sowas:



int a,b;

b=...;

// a soll zb. 5/7 von b sein ->
a=b*5/7 // schlecht, weil b dann max. nur 2^32/5 sein darf

// besser:
a= ((long long int) b *5/7);

// am schlechtesten:
a=b/7*5;


So, ich bin mit dem... Programm jetzt fertig. Ich sag euch, ich werd nie wieder irgendwas größeres mit Delphi machen! *chatt*

Heute hab ich übrigens auch meinen Tee-Rekord gebrochen, 3 Kannen hab ich vernichtet *chatt*

skyphab
16.06.2004, 10:25
Das ist zu technisch:


weil b dann max. nur 2^32/5 sein darf

In SAP arbeitet man mit defnierten DataDictonary-Strukturen, für was bräuchte man so lange Zahlen? Die Datentypen sind ohnehin nicht so wichtig, ist ja wie gesagt 4GL. NUMC hat 255 Stellen max., damit kann man auch rechnen. LCHR hat's noch sehe ich gerade (Long Character), Stellen: 256-max. Keine Ahnung was max ist *buck*

Was der intern damit macht interessiert mich nicht, das sind Details. ;)

i_hasser
16.06.2004, 15:29
Stimmt auch wieder.

Ich bin heute endlich diesen Krampf losgeworden ;D. Was ein Glück, dass es unter Linux praktisch nix für Pascal gibt ;D (ok, wenn ich es mir recht überlege gibts unter Windooows auch so gut wie nix für Pascal, nur Delphi).


So schnell mache ich bestimmt nix wieder mit Delphi, davon muss ich mich erstmal erholen *chatt*

skyphab
16.06.2004, 19:29
;) ;D
Naja C ist schon edel, kann's nur nicht brauchen :)
Delphi war schon immer so ein Zwischending, teilweise fast am Abgrund, aber dann doch stetig neue Versionen. In der c't haben sie ja Delphi 8 für .net in hohen Tönen gelobt, was mich ehrlich gesagt erstaunte. Borland lässt das Ding auch nicht sterben, die erweitern das ja auch immer mit Kylix für Linux usw. Scheint wohl noch eine stetige Klientel zu haben, für Schulen usw. find ich's eigentlich Top, leicht zu verstehen und nicht zu abstrakt.

i_hasser
16.06.2004, 20:02
Original geschrieben von skyphab
;) ;D
Naja C ist schon edel, kann's nur nicht brauchen :)
Delphi war schon immer so ein Zwischending, teilweise fast am Abgrund, aber dann doch stetig neue Versionen. In der c't haben sie ja Delphi 8 für .net in hohen Tönen gelobt, was mich ehrlich gesagt erstaunte. Borland lässt das Ding auch nicht sterben, die erweitern das ja auch immer mit Kylix für Linux usw. Scheint wohl noch eine stetige Klientel zu haben, für Schulen usw. find ich's eigentlich Top, leicht zu verstehen und nicht zu abstrakt.

Hätten sie es bloß sterben lassen :]

Aber was ist an C denn abstrakter als an Delphi? Das ist es ja gerade, wäre Delphi einfacher als C++ oder hätte es sonst irgendwo einen Vorteil würde ich ja garnet meckern... ;D
Jedes Kind kann heute JavaScript - aber C, das ja den selben Syntax benutzt (bzw. umgekehrt) will man niemanden zumuten. Wenn man was einfaches, nicht abstraktes will soll man doch gleich zu VB greifen - das ist einfach ;).

Irgendwo hab ich auch mal eine ganz andere Theorie dazu gelesen - es geht den Mathematikern einfach gegen den Strich, dass Zuweisungen in allen anderen Sprachen mit = erfolgen, was ja mathematisch nicht so ganz korrekt ist.
Und weil Delphi die einzige Sprache ist, die das "richtig" implementiert (eben diese Grässlichkeit von :=) wird es von denen am Leben erhalten *buck*.


C ist einfach viel leserlicher, dadurch logischer und prägnanter (vor allem letzteres ist mir bei Delphi ziemlich übel aufgestoßen - da findet man sich ja garnet mehr durch den eigenen Code).
Ein Delphi Prog, wo der Source sagen wir 100kB ist, ist in C++ bei genau der selben Implementierung nur halb so groß, wenn überhaupt. Ein "int abc(double b, int c);" sagt schon alles aus was man braucht - integer als Rückgabe, abc als Name und den 64bit Float b und den 32bit int c als Parameter. Nur die Klammern haben da wenig mit dem Inhalt zu tun.
Dagegen ist "function abc(b: real; c: Integer): Integer;" genau 18 Zeichen länger (und damit 1.72mal so lang) und sagt mir auf den ersten Blick nur die Hälfte. "function" - die Funktion gibt irgendwas zurück, was erfahre ich erst nachdem ich mich durch die restliche Definition gewühlt hab - ich nehme einen Satz doch auch nicht und schreibe den Anfang oben, und den Rest unten aufs Blatt.
Dann kommt der Funktionsname - wenigstens hier kann Delphi mit C mithalten. Aber dann bröckelts auch schon wieder - die Parameter. Bei C gucke ich nach dem ersten Komma, was ja schnell gefunden ist (das tiefststehende Zeichen überhaupt). Bei Delphi stolpere ich erstmal über eine Ansammlung von ; und :, die optisch genau gleich aussehen.
Beim 2. Blick hab ich dann endlich die ; gefunden (während ich bei C schon weis, welche Parameter es gibt) - nun kommt der nächste Teil, die einzelnen Parameter kann man ja quasi nicht in einem Rutsch lesen, wegen dem dämlichen : dazwischen (was man natürlich instinktiv mit ; verwechselt und sich gleich erstmal fragt, ob man nicht doch die falsche Stelle erwischt hat... nebenbei bemerkt hab ich die C Definition schon längst fertig gelesen). Also nach ca. 5 Arbeitsschritten hab ich nun endlich auch bei Delphi die Parameter erfasst.
Und als wäre das bisher nicht unleserlich genug gewesen kommt direkt danach wieder ein :, und nun erfahre ich endlich auch was die Funktion eigentlich zurückgibt.

In C geht es danach sofort mit dem Code los, die { und } sind schnell überlesen und anhand der Einrückungen erkennt man den Funktionscode sofort (idR schreib ich auch 2 Zeilen Kommentare über eine Funktion, selbst wenn die Zeilen leer sind - so hebt sich die nächste Funktion schon farblich ab).
In Delphi kommt jetzt erstmal das fürchterliche "var". Nachdem sich meine Augen wieder durch Ansammlungen von ;:::;:;;:;;;; gequält haben und ich mir nebenbei schon denke wie schön doch Delphi ist, wo wir die Variablen nicht erst deklarieren wenn wir sie denn nunmal auch brauchen sondern einfach alles oben schön unübersichtlich reinklatschen überlese ich erstmal das "begin", weil es sich optisch nicht im geringsten unterscheidet.

Also komme ich ins Stutzen und fahre 2 Zeilen zurück - ach da haben wir es ja. Also (in CPU Jargon) machen wir einen Pipeline Flush und schmeißen alles raus bis zur letzten wirklichen Variablendeklaration (natürlich ist der Unterbrechung wegen inzwischen die Hälfte durchgesickert und im Datennirvana gelandet) und stellen uns auf Code um (es gibt bei CPUs übrigens nix schlimmeres als einen Pipeline Flush...).

In C hab ich inzwischen fast die gesamte Funktion durchgearbeitet *buck*

Aber das schönste kommt ja noch - während ich mich jetzt also durch den Pascal Code quäle vergesse ich natürlich die Hälfte der Variablen, weil sie bisher (sagen wir nach 50 Codezeilen) nicht aufgetaucht sind.
Und nun gehts los - "hä?". (inzwischen) Instinktiv fahre ich wieder zu "var" hoch und schaue nochmal nach - so war das also, ok, dann ist ja alles klar.
Jetzt kann ich endlich zurück zum Code und weiterlesen - ich hab die Pipeline Flushes jetzt mal weggelassen, waren ja nur schlappe 2.


Ich rede besser nicht weiter, sonst wird mir hier als Mod noch fehlende Neutralität unterstellt *chatt*

skyphab
16.06.2004, 23:32
Jetzt aber mal langsam ;)

Glaubst du ich (der nur mal C gemacht hat, um zu wissen wie es ansatzweise aussieht) würde sich in einem C-Programm schneller zurechtfinden als in einem Delphi-Programm, wo ich mittlerweile ein paar Monate tiefere Praxis habe? Und das nur, weil C logischer aufgebaut ist? Das halte ich schlichtweg für falsch und Gewohnheitssache.

Das was man kennt, hat man verinnerlicht und findet es logisch. Das was unlogisch ist, nimmt man hin und kennt es. Poste mal einen C-Code und ich sage dir, dass ich jede zweite Zeile scheiße finde, weil ich mich nicht zurechtfinde. Das lässt sich dann genauso widerlegen wie das was du über Delphi sagst :)

Das ist alle Gewohnheitssache. Wenn man in Delphi Rückgabewerte einer Funktion strukturiert und sie als Rückgabewert benutzt, hat man auch kein Problem mit dem Namen ;)
Bei mir sind 80% aller Funktionensrückgabewerte strukturierte Datentypen und wenn ich integer oder string zurückgegebe, brauche ich doch dem Kind nicht auch noch einen Namen geben? *buck*
Und wenn man Parametern strukturierte und einheitliche Namen gibt, hat man auch keine Probleme mit dem Erkennen ;)

i_hasser
16.06.2004, 23:51
C ist einfach deutlich prägnanter und formal einfacher zu erfassen - da kannst du sagen, was du willst ;D ;)

Das liegt daran, dass der "Hilfssyntax", also das, was keine(wenige) Informationen ausdrückt auf ein absolutes Mindestmaß reduziert wurde. Ergo findet man überall wo man hinschaut Informationen.
Ich hab mich oben auch wirklich nur auf den Syntax bezogen, und es ist auch überhauptkein Wunder, dass man heute fast alles in einem C-Syntax macht - Perl, PHP, Java, JavaScript, und was es da nicht noch alles geben mag. Hat seinen Grund ;)

Und Visuell ist das "," zur Parametertrennung auch einfach auffallender, als das ; so sowieso schon haufenweise : drinnen stehen. Und der C-Syntax ist auch einfach logischer aufgebaut als der von Pascal. Das zeigt zb. die Tatsache, dass man auch semantische Klammern setzen kann, und dass man fast die komplette Sprache aus sich selbst herleiten kann.
Versuch doch mal in Delphi die Grundrechenarten mit einer Klasse zu implementieren, oder eine For-Schleife mit einer Klasse zu implementieren. Dazu kommt C mit erstaunlich wenigen Grundvorraussetzungen aus, und hat damit schon fast was von unserer Mathematik *buck*

Delphi, Pascal allgemein und auch viele andere Sprachen sind schlicht Sprachen - C++ ist ein logisches, in sich geschlossenes System. Bei Smalltalk ist es ähnlich (afair ist der Syntax aber deutlich einfacher), und bei Java auch.

Delphi dagegen... *nein*

Novox
17.06.2004, 14:53
Ich muß mich doch jetzt auch mal in die Diskussion einmischen, Deine Haßtiraden gegen alles nicht C-artige sind ja unerträglich ;D und zeugen nicht gerade von Flexibilität.
Daß ich nicht ganz Deiner Meinung bin, ist wohl nicht verwunderlich, bedenkt man, daß (Turbo) Pascal meine Programmier-Muttersprache ist (ich bin also nicht neutral). Heute nutze ich zwar auch meist Sprachen mit C-Syntax, und empfinde die kompakte Schreibweise mittlerweile übersichtlicher. Ich hab aber die Erfahrung gamacht, daß sie auf Anfänger unnötig kryptisch und damit abschreckend wirkt. Daß die C-Syntax logischer sein soll kann ich ehrlicherweise nicht nachvollziehen. Prägnanter und vor allem kompakter, ja; aber logischer?

Du hast bisher nur Beispiele gebracht, in denen Pascal das Nachsehen hat. Die Schwächen der Pascal-Syntax hast Du zwar korrekt analysiert, die von C aber einfach ausgeklammert. Doch auch die gibt es. Man denke nur mal an das "==" als Quell vieler Anfängerfehler. Es läßt sich wohl kaum bestreiten, daß A xor B leichter zu lesen ist als A ^ B. Das gilt auch für not/!, or/||, mod/%, and/&&. Ganz schlimm der *-Operator, der mal eine Multiplikation sein kann, mal eine Dereferenzierung veranlasst und ein ander mal zur Pointerdeklaration dient (nicht, daß @ und ^ in Pascal schöner wären). Oder das & als logisches AND, Adress-of-Operator oder zur Referenzdeklaration.

Jetzt wist Du sagen: "Na und, geht doch alles offensichtlich aus dem Kontext hervor." Ja, für jemanden, der die C-Sytax halbwegs beherrscht. Aber eben nicht für einen Neuling, der sieht nur einen Wust aus { c = a%b & **c && d || a; (); blubb->*buh(&p_grkl); } (nein, ich hab nicht überbrüft ob das gültiges C ist ;)).

Ein ganz anderes Thema ist die Mächtigkeit einer Sprache und die Fähigkeiten einer Programmierumgebung. Daß C/C++ vielseitiger als Pascal/Delphi ist, steht gar nicht zur Debatte. Aber der Punkt ist, daß Delphi in dem Bereich, auf den es optimiert ist (RAD), sehr effizient ist. Ein Datenbankfrontend klickt auch ein nicht sehr versierter Programmierer damit in ein paar Minuten zusammen. Das liegt weniger an der Sprache, als vielmehr an der VCL und der IDE. Der C++Builder funktioniert ja AFAIK ähnlich, nur eben mit C++ als Sprache.

Ein "richtiger Programmierer" nimmt das Werkzeug, mit der er die gestellte Aufgabe möglichst effizient erledigen kann. Das kann in vielen Fällen C/C++ sein, in vielen anderen ist es das nicht (ein KI-ler wird mit C++ z.B. wenig anfangen können).


Original geschrieben von intel_hasser
Delphi, Pascal allgemein und auch viele andere Sprachen sind schlicht Sprachen - C++ ist ein logisches, in sich geschlossenes System. Bei Smalltalk ist es ähnlich (afair ist der Syntax aber deutlich einfacher), und bei Java auch.

Du stellst C++ auf eine Stufe mit Smalltalk? :-X
"The main problem for the C++ community today is to use Standard C++ in the way it was intended rather than as a glorified C or a poor man's Smalltalk." — Bjarne Stroustrup

i_hasser
17.06.2004, 17:27
Original geschrieben von Novox
Ich muß mich doch jetzt auch mal in die Diskussion einmischen, Deine Haßtiraden gegen alles nicht C-artige sind ja unerträglich ;D und zeugen nicht gerade von Flexibilität.
Daß ich nicht ganz Deiner Meinung bin, ist wohl nicht verwunderlich, bedenkt man, daß (Turbo) Pascal meine Programmier-Muttersprache ist (ich bin also nicht neutral). Heute nutze ich zwar auch meist Sprachen mit C-Syntax, und empfinde die kompakte Schreibweise mittlerweile übersichtlicher. Ich hab aber die Erfahrung gamacht, daß sie auf Anfänger unnötig kryptisch und damit abschreckend wirkt. Daß die C-Syntax logischer sein soll kann ich ehrlicherweise nicht nachvollziehen. Prägnanter und vor allem kompakter, ja; aber logischer?

Die richtige Logik hast du natürlich nur bei C/++.

Guck mal:


void a()
{
...
}
Was sagt uns das? Genau - a ist eine Funktion.

Nichts könnte ungenauer sein ;D

a ist keine Funktion - a ist ein Zeiger auf eine Funktion.
In C gibt es wenn man es so will keine echten Funktionen, sondern immer nur Zeiger auf Funktionen. Das () nach dem Funktionsnamen hat dabei die selbe Wirkung wie [] (wir können uns das * sparen).
Damit ist die Sache so logisch wie Assembler selbst - da machen wir eine Funktion folgendermaßen:

[Label]
[ Code]
RET

Der Funktionszeiger a hat erstmal wenig mit dem eigentlichen Code zu tun - der Code wird nur ausgeführt, weil er eben direkt nach "void a()" steht.
Damit stellt C Funktionen zur Verfügung, ohne deren Herkunft zu verschleiern (also wie es in Assembler aussieht) und damit bleibt auch ein Teil der Leistungsfähigkeit von Assembler erhalten.
Klar hat das in einer richtigen OO Sprache nicht unbedingt was verloren, aber da C ansonsten mit Funktionen mindestens alles machen kann, was andere Sprachen auch können gibt es keinen Grund daran was zu ändern - und so kann man auch in C++ problemlos Funktionszeiger benuzten.

Dann könnte man zb. auch die oft als unlogisch betrachtete For-Schleife nachschreiben. Der Prototyp des überladenen Operators sähe dann ungefähr so aus (weis jetzt nicht, ob das wirklich 100%ig genau geht - aber auf jeden Fall gehts mit der selben Funktionalität):

operator(void (*a)() int (*b)() int (*c)()) int (*d)();

Die Funktion dazu sähe so aus:



{
(*a)();
while( (*b)()!=0 )
{
(*c)();
(*d)();
}
return;
}


Auf jeden Fall ließe sich mit 4 Paremetern eine Funktion gestallten, die genau das selbe wie die For-Schleife tut - nur der Syntax wäre womöglich etwas anders (weis jetzt nicht ob die Klammern bei der Operatordefinition gültig sind und wie man das ";" am besten implementiert).

Das sind beides nur Beispiele, da finden sich wenn man lange genug Programmiert hat noch viele mehr. Wenn ich wissen will wie ich etwas in C realisiere, was ich bisher noch nicht gemacht hab probiere ich inzwischen den Syntax aus, der mir dafür logisch erscheint. Und - interessanter Weise - es funktioniert fast immer.

Zb. auch sowas hier:



class a; // Prototypen von Klassen

class a
{
class b;
};

class a::b
{
int x();
int y();
};

int a::b::x()
{
}


Sowas - allein schon das verschachteln von Klassendefinitionen geht in Delphi zb. nicht.
Damit hält man aber seinen Namespace gut sauber und strukturiert einfach besser (natürlich sollte man das nicht auf Teufelkommraus benutzen ;)).

Der Vergleich mit Smalltalk war ja auch nicht auf allgemein alles was C++ betrifft bezogen, richtig lesen ;)

Novox
17.06.2004, 23:44
Eins vorweg: es heißt "die Syntax".


Original geschrieben von intel_hasser
Die richtige Logik hast du natürlich nur bei C/++.

Kommt darauf an, was man unter "richtiger Logik" versteht.


Guck mal:


void a()
{
...
}
Was sagt uns das? Genau - a ist eine Funktion.
Nichts könnte ungenauer sein ;D

Stimmt, ungenauer geht’s fast nimmer ;D. Anstatt zwischen Funktionen und Prozeduren explizit zu unterscheiden, gibt’s halt den Pseudotyp "void". Aus Sicht der Rechnerarchitektur ist das zwar nachvollziehbar — anschaulich ist es nicht. Was soll das denn sein, "void", ein "Nicht-Ding", das letztlich auch nur dazu dient, Methoden mit und ohne Rückgabewert implementiern zu können. Ein Kunstgriff eben.


a ist keine Funktion - a ist ein Zeiger auf eine Funktion.

Ja. Und was willst Du mit dieser bahnbrechenden Neuigkeit zum Ausdruck bringen? Spielst Du darauf an, daß man u.a. in Pascal Prozeduren einfach beim Namen ruft, bei leerer Parameterliste also ohne "()"? Was ist daran unverständlich? Wenn Du einem Mitmenschen einen Befehl ohne Zusatzinformationen gibst, sagst Du auch nicht "Tu das (void)!". ;) Allerdings verbessern die Klammern die Lesbarkeit, man sieht sofort, was eine Methode ist. Das ist sicher ein Vorteil.


In C gibt es wenn man es so will keine echten Funktionen, sondern immer nur Zeiger auf Funktionen.

Was sind bitte "echte Funktionen"? Und wo soll da der Unterschied zu anderen Programmiersprachen sein? Ob nun "foo();" oder "foo;" nach "call foo" übersetzt wird, ist doch wurscht.


Damit ist die Sache so logisch wie Assembler selbst - da machen wir eine Funktion folgendermaßen:

Ah, jetzt seh ich wie der Hase läuft. Eine Programmiersprache sollte Deiner Meinung nach also möglichst 1:1 ASM nachbilden. Kein Wunder, daß C für Dich das einzig Wahre ist... *chatt*


Damit stellt C Funktionen zur Verfügung, ohne deren Herkunft zu verschleiern (also wie es in Assembler aussieht) und damit bleibt auch ein Teil der Leistungsfähigkeit von Assembler erhalten.

Das bestreitet ja auch keiner. Nur gibt es Anwendungsfälle, in denen es durchaus sinnvoll ist, auf einem abstrakterem Level zu Programmieren. Wenn ich in Smalltalk einem Objekt X eine Nachricht schicke, es solle Aktion A ausführen, ist es mir gelinde gesagt völlig gleichgültig, wie dieser Vorgang auf die Maschinen abgebildet wird, ob da am Stack rumgepfuscht und Objekte auf dem Heap erzeugt werden. Das ist nicht meine Aufgabe, mit sowas langweiligem will ich mich eigentlich nicht aufhalten müssen. Das können Maschinen viel besser und die beschwehren sich auch nicht über solche Sklavenarbeiten.


Klar hat das in einer richtigen OO Sprache nicht unbedingt was verloren, aber da C ansonsten mit Funktionen mindestens alles machen kann, was andere Sprachen auch können gibt es keinen Grund daran was zu ändern - und so kann man auch in C++ problemlos Funktionszeiger benuzten.

In der Tat. Was nichts daran ändert, daß spezialisierte Sprachen in ihren jeweiligen Domäne produktiver sind, auch wenn Du mit C alles "nachprogrammieren" kannst. Sinnvoll ist das wohl kaum, wenn es bereits eine Lösung gibt.


Wenn ich wissen will wie ich etwas in C realisiere, was ich bisher noch nicht gemacht hab probiere ich inzwischen den Syntax aus, der mir dafür logisch erscheint. Und - interessanter Weise - es funktioniert fast immer.

Wenn Du gelernt hast, wie ein x86-Prozessor zu denken, dann geht das natürlich. *chatt* Das wäre mir aber etwas zu low-level.


Sowas - allein schon das verschachteln von Klassendefinitionen geht in Delphi zb. nicht.
Damit hält man aber seinen Namespace gut sauber und strukturiert einfach besser (natürlich sollte man das nicht auf Teufelkommraus benutzen ;)).

Mal abgesehen davon, daß ich den Vorteil dieses Konstrukts nicht sehe, und man sowas in einem guten Design nie brauchen wird, hast Du Recht, das geht in Delphi nicht. Braucht man aber auch praktisch nie. Und wenn doch, kann man C++ nehmen. ;)

skyphab
18.06.2004, 00:17
Das zeigt wieder nur überdeutlich, dass es eigentlich nur um Vorlieben geht :)

Wer unbedingt superlogisch sein muss, kann ja Assembler nehmen, sich in einen Keller hocken und dort bis zum Lebensende auf der Ebene weiterprogrammieren (Viel weiter kommt man mit sowas eh nicht ;)), die Anderen benutzen halt etwas anderes.

Interessant ist nur immer der schlechte Stand von Delphi. Lustigerweise hoppeln immer die am meisten drauf rum, die nur privat damit arbeiten. Ein Freund von mir ist noch auf der FH und tüdelt dort ausschließlich mit Java rum. Gleichzeitig beschwert er sich aber immer, warum in aller Welt ich für die zwei Projekte in die ich involviert war, Delphi vorgeschlagen habe.

Tatsache ist aber, dass es effizient sein muss und Delphi ist verdammt effizient. Was anderes zu behaupten wäre schlichtweg quatsch.
Während mein Kollege seit acht Monaten von seinem Java schwärmt und sich einen Pizzabestellservicesimulator aus der Nase zieht, habe ich in der Zeit zwei Projekte im Produtionsumfeld im Volumen von mehr als 120kEur mit Delphi durchgezogen. Da hängt von Funkwaagen, Drucker, Barcodescanner bis zu SPS-Steuerungen alles dran. Was will man mehr?

Was ist denn jetzt eigentlich an Delphi schlecht, was wirkliche Schwächen bedeutet? Irgendwelche abgedrehten Sachen machen und dann drüber zu philosophieren ist doch eh Schnick Schnack und klingt für mich nach Mathematikprofessor. Für sowas hat man im kommerziellen Umfeld eh keine Zeit.
Das einzige was mich heute an Delphi genervt hat ist, dass es keinen Garbage Collector hat und ich Memory Leaks hatte (Was logischerweise aber an mir lag). Da hätte mir C++ aber auch nicht weitergeholfen ;)

Nunugt, meine Delphieeskaparten sind in zwei Monaten vorbei, sehr hoch kommt man mit dieser Art der Programmierung ohnehin nicht :] Was man benutzt ist eigentlich egal, habe aber in letzter Zeit nur extrem wenig Stellenanzeigen gesehen, die C- oder Delphi-Leute suchen *buck*

i_hasser
18.06.2004, 00:27
Original geschrieben von Novox
Eins vorweg: es heißt "die Syntax".


Tja... wie auch immer eben ;)



Kommt darauf an, was man unter "richtiger Logik" versteht.
Darunter verstehe ich eine Sprachgestalltung, die zb. so wenig Annahmen wie möglich in die Welt setzt. Funktionen sind so eine Annahme. Grundvariablentypen sind Annahmen. Das wird jetzt langsam etwas mathematischer ;)
Grundsätzlich könnte man sagen, dass das Modell mit den wenigsten Annahmen bei gleicher Leistungsfähigkeit (zumindest unter diesem Aspekt) vorzuziehen ist.

Annahmen sind auch For-Schleifen (ok - die nur in Delphi), If-Bedingungen usw... eben alle wirklichen Grundelemente einer Programmiersprache.



Stimmt, ungenauer geht’s fast nimmer ;D. Anstatt zwischen Funktionen und Prozeduren explizit zu unterscheiden, gibt’s halt den Pseudotyp "void". Aus Sicht der Rechnerarchitektur ist das zwar nachvollziehbar — anschaulich ist es nicht. Was soll das denn sein, "void", ein "Nicht-Ding", das letztlich auch nur dazu dient, Methoden mit und ohne Rückgabewert implementiern zu können. Ein Kunstgriff eben.
Ganz im Gegenteil, das ist viel nachvollziehbar nicht zwischen Funktionen und Subs/Prozeduren zu unterscheiden.

In Pascal sieht das logisch so aus: Als Grundlage dient eine Klasse (nicht aus Programmierersicht, sondern rein logisch) - Prozeduren und Funktionen sind von dieser Klasse abgeleitet. Zur Erklärung von Funktionen und Prozeduren sind in Pascal also 3 Klassen erforderlich, könnte man so hier darstellen:



class GrundKlasse;
class Funktionen : GrundKlasse;
class Prozeduren : GrundKlasse;


In C dagegen hast du nur eine Klasse - Funktionen. Mehr nicht. Also


class Funktionen;

Sieht doch einfacher aus, oder etwa nicht? Dadurch können wir damit allgemeiner umgehen, was gut ist - ohne an Leistungsfähigkeit zu verlieren.

In Assembler wird beides übrigens unterschiedlich umgesetzt. Bei Prozeduren müssen keine Parameter vom Stack geholt werden etc.


Ja. Und was willst Du mit dieser bahnbrechenden Neuigkeit zum Ausdruck bringen? Spielst Du darauf an, daß man u.a. in Pascal Prozeduren einfach beim Namen ruft, bei leerer Parameterliste also ohne "()"? Was ist daran unverständlich? Wenn Du einem Mitmenschen einen Befehl ohne Zusatzinformationen gibst, sagst Du auch nicht "Tu das (void)!". ;) Allerdings verbessern die Klammern die Lesbarkeit, man sieht sofort, was eine Methode ist. Das ist sicher ein Vorteil.

Wieder genau das selbe Prinzip. Bei Pascal gibts folgende Objekte (nur die, die jetzt wichtig sind): Variablen, Zeiger, Funktionen, Prozeduren.
In C dagegen gibts nur die folgenden: Variablen, Zeiger.
Weniger Annahmen ;). Trotzdem selbe Leistungsfähigkeit - genau das wollen wir, und genau das verstehe ich auch unter einem eleganten Desing (mit so wenig wie möglich so viel wie möglich zu erreichen - desswegen mag ich auch Windooows nicht, das nur so mit Sonderlösungen vollgestopft ist die aber in ihrer Summe nicht mehr Funktionen bieten als eine ordentlich überlegte API die auch weniger komplex ist).



Was sind bitte "echte Funktionen"? Und wo soll da der Unterschied zu anderen Programmiersprachen sein? Ob nun "foo();" oder "foo;" nach "call foo" übersetzt wird, ist doch wurscht.
Du wirst dich vielleicht wundern, aber C ist C und kein Assembler ;). Es ist mir auch völlig wurscht wie das in Assembler nun letztendlich implementiert wird, da hat sowieso jede Architektur ihre eigenen Befehle.
Ich könnte jetzt statt C++ auch Java schreiben, dann wirds deutlicher.

Es geht mir um die Logik die im Desing steckt, und die Eleganz - mit möglichst wenig Annahmen so viele Möglichkeiten bzw. so viel Leistungsfähigkeit wie nur irgend möglich zu offerieren.

Das ist wie in der Mathemtik (wenn ich mir das so überlege ist das sogar ein verdammt guter Vergleich!). Jeder Mensch kann sich Vorstellen was es zb. mit der Wahrscheinlichkeit auf sich hat. Trotzdem wird das mathematisch pingeligst genau erfasst, es wird bewiesen, dass die Häufigkeitsverteilung zb. mit zunehmender Anzahl an beobachteten Versuchen gegen die Wahrscheinlichkeit strebt (also nicht nur "das ist eben so", sondern das wird wirklich mathematisch bewiesen - wenn du willst kann ich den Beweis mal hinschreiben).

Alles nur, um diese dummen Grundannahmen soweit wie nur irgend möglich zu reduzieren bzw. zu eliminieren. Wo wären wir denn heute, wenn man bei jedem Phänomen gesagt hätte "das soll eine Grundvorraussetzung sein"? Um mal die Wahrscheinlichkeit wieder aufzugreifen - einfache Zusammenhänge (die sich jeder logisch erklären kann) kann man so in mathematische Ausdrücke vereinfachen (zb. Mengenbeziehungen). Und wieder sind wir eine Grundvorraussetzung los.

Ein gutes Beispiel ist der Primzahlfaktorisierungswettbewerb. Da geht es darum von einer Trunc/Fix/Round Funktion die Ableitung zu bilden. Momentan ist diese Funktion eine Grundvorraussetzung, also das lässt sich mathematisch nicht so einfach ausdrücken.
Könnten wir das rein mathematisch ausdrücken wäre es kein Problem eine xbeliebige Zahl innerhalb kürzester Zeit in das Produkt 2er Primzahlen zu zerlegen - in einem Bruchteil eines Bruchteils eine Bruchteils des heute nötigen Aufwands.

... aber ich schweife ab... ;)


Ah, jetzt seh ich wie der Hase läuft. Eine Programmiersprache sollte Deiner Meinung nach also möglichst 1:1 ASM nachbilden. Kein Wunder, daß C für Dich das einzig Wahre ist... *chatt*

Tja, da muss ich dich leider enttäuschen ;).



Das bestreitet ja auch keiner. Nur gibt es Anwendungsfälle, in denen es durchaus sinnvoll ist, auf einem abstrakterem Level zu Programmieren. Wenn ich in Smalltalk einem Objekt X eine Nachricht schicke, es solle Aktion A ausführen, ist es mir gelinde gesagt völlig gleichgültig, wie dieser Vorgang auf die Maschinen abgebildet wird, ob da am Stack rumgepfuscht und Objekte auf dem Heap erzeugt werden. Das ist nicht meine Aufgabe, mit sowas langweiligem will ich mich eigentlich nicht aufhalten müssen. Das können Maschinen viel besser und die beschwehren sich auch nicht über solche Sklavenarbeiten.

Ich wollte auch nie eine 1:1 Assembler umsetzung haben, wie schon gesagt.
In C kann man einfach die selben Dinge wie in Delphi oder anderen Sprachen unter Zuhilfename von weniger Grundvorraussetzungen ausdrücken. Und das macht die Sprache klarer, logischer und prägnanter (das ist jetzt semantisch und nicht syntaktisch gemeint, aber kein Syntax ohne Semantik, also das eine folgt aus dem anderen ;)).

Und je weniger Grundvorraussetzungen wir haben, desto abstrakter programmieren wir (also desto weiter entfernt von irgendwelchen Dingen die uns in ein Korsett zwängen wollen, wie zb. x86 Assembler).


In der Tat. Was nichts daran ändert, daß spezialisierte Sprachen in ihren jeweiligen Domäne produktiver sind, auch wenn Du mit C alles "nachprogrammieren" kannst. Sinnvoll ist das wohl kaum, wenn es bereits eine Lösung gibt.

Du müsstest nur 1mal eine ordentliche API für C++ schreiben (zb. eine Klasse) und dann hast du für immer die selbe Leistungsfähigkeit wie die spezialisierte Sprache, weil du diese praktisch in C++ implementierst.



Wenn Du gelernt hast, wie ein x86-Prozessor zu denken, dann geht das natürlich. *chatt* Das wäre mir aber etwas zu low-level.

Was hat denn der C-Syntax mit x86 gemein? Mein gcc spuckt mir C Code für jede nur erdenkliche Plattform aus, aber ich denke ich hab jetzt schon oft genug gesagt, dass ich gerne abstrakt programmiere.
Man kann in C-Syntax denken - und sich darüber neue Sachen herleiten ;). C ist nicht wie Delphi wo man feste Konstrukte (Funktionen, If-Anweisungen etc.) anwenden kann, sondern C ist eher wie eine gesprochene Sprache, wo man semantische Elemente zu immer neuen Konstrukten kombinieren kann. Und desswegen kann man sich anhand der semantischen Elemente herleiten, wie eben unbekannte Konstrukte auszusehen haben.


Mal abgesehen davon, daß ich den Vorteil dieses Konstrukts nicht sehe, und man sowas in einem guten Design nie brauchen wird, hast Du Recht, das geht in Delphi nicht. Braucht man aber auch praktisch nie. Und wenn doch, kann man C++ nehmen. ;)

Wie war das mit 80/20 bzw. 95/5? Wann brauchst du denn schon Vererbungen, Interfaces (bzw. das C-Aquivalent - wieder so eine Sache, in C hast du keine Interfaces sondern du kannst die Sache auch mit Klassen realisiseren -> weniger Annahmen) usw.?

Wenn dann aber mal doch, bist du heilfroh es zu haben ;)

TiKu
18.06.2004, 01:41
@intel_hasser: Irgendwie hat Novox aber Recht: Du machst Dir massig Gedanken wie der Compiler den Code einfacher umsetzen kann. Den meisten Programmierern ist das aber vollkommen egal.
Fakt ist: Je einfacher und abstrakter eine Sprache sein soll, desto mehr Kompromisse muss man idR eingehen. Das sieht man sehr gut an C/C++, Delphi und Visual Basic. C/C++ ist am meisten low level. Deshalb geht damit auch am meisten. Dann kommt IMHO Delphi, welches schon einige Einschränkungen hat, aber doch ein wenig mehr zu können scheint als VB. VB ist extrem einfach (auch durch die Garbage Collection), kann dadurch aber im Grunde am wenigsten. Wenn man Ahnung hat, kann man natürlich auch mit VB und Delphi fast alles proggen was mit C/C++ auch geht.
VB und Delphi haben den großen Vorteil, dass die Entwicklung eines Programmes extrem schnell geht. Ich merke das gerade recht deutlich: Ich "portiere" (naja, komplettes Redesign) momentan ein größeres Projekt von VB6 nach VC++ 2003. Die low-level-Sachen gehen mit C++ etwas schneller, aber der Rest (und das ist nunmal der Großteil) ging mit VB6 erheblich schneller.

@skyphab:
Ihr Delphianer seid was die Akzeptanz angeht noch gut dran. Hier an der TU Dresden sieht's so aus:
Java ist das Nonplusultra (kann ich nicht nachvollziehen). C++ ist natürlich auch sehr angesehen. Pascal und Delphi werden akzeptiert, aber als VBler wird man schon fast gesteinigt. 8-( Wird in einer Vorlesung gefragt, welche Sprachen wir so nutzen und es ruft jemand "Delphi", heißt es sinngemäß "aha, Pascal, schön". Bei einem "Visual Basic" wird man schlicht ignoriert (nichtmal ein Blick, obwohl er es definitiv gehört hat).
In einer anderen Vorlesung meinte der Prof mal "...oder so ganz exotische Sachen wie Visual Basic"*buck* Ich hätte fast reingerufen "Gehen Sie mal in die Firmen und schauen Sie was da genutzt wird. Sie werden sehr sehr oft Java, Delphi und Visual Basic vorfinden". VB war in Nordamerika mal die am meisten genutzte Sprache.

Naja, Uni ist sowieso ziemlich realitätsfremd.

i_hasser
18.06.2004, 14:17
Original geschrieben von TiKu
@intel_hasser: Irgendwie hat Novox aber Recht: Du machst Dir massig Gedanken wie der Compiler den Code einfacher umsetzen kann. Den meisten Programmierern ist das aber vollkommen egal.
Fakt ist: Je einfacher und abstrakter eine Sprache sein soll, desto mehr Kompromisse muss man idR eingehen. Das sieht man sehr gut an C/C++, Delphi und Visual Basic. C/C++ ist am meisten low level. Deshalb geht damit auch am meisten. Dann kommt IMHO Delphi, welches schon einige Einschränkungen hat, aber doch ein wenig mehr zu können scheint als VB. VB ist extrem einfach (auch durch die Garbage Collection), kann dadurch aber im Grunde am wenigsten. Wenn man Ahnung hat, kann man natürlich auch mit VB und Delphi fast alles proggen was mit C/C++ auch geht.
VB und Delphi haben den großen Vorteil, dass die Entwicklung eines Programmes extrem schnell geht. Ich merke das gerade recht deutlich: Ich "portiere" (naja, komplettes Redesign) momentan ein größeres Projekt von VB6 nach VC++ 2003. Die low-level-Sachen gehen mit C++ etwas schneller, aber der Rest (und das ist nunmal der Großteil) ging mit VB6 erheblich schneller.

Das sind Vorurteile ;).

Im Borland C++ Builder kann man die GUI genauso schön und einfach zusammenklickern wie in Delphi. Im Code ist C++ aber auch nicht komplizierter als Delphi oder VB, das sind wirklich nur Vorurteile aus C-Zeiten.

Mal ein paar Beispiele:



Basic:

Dim a(3) as Integer '// weis net ob die Array definition stimmt, ist schon lange her
a(0)=4
a(1)=8
a(2)=12

ReDimm Preserve a(5) as Integer

a(3)=5
a(4)=2


In Delphi kann ich das zugegebenerweise nicht :]

C++:

vector<int> a(3);
a[0]=4;
a[1]=8;
a[2]=12;



Größe ändern etc. geht auch problemlos (1 Befehl, also sowas wie a.changesize(123);) -
hab mich damit aber auch noch nicht beschäftigt, weil ich für sowas lieber die alten C-Konstrukte nehme (also realloc).
Darüber hinaus bietet C++ auch die Möglichkeit zb. mitten drinnen ein Element zu löschen oder neu einzufügen - auch je ein einzelner Befehl.

Strings sind früher in C auch hässlich gewesen, heute kein Problem mehr:



'// Basic

Dim a as String
a="123"
a=a + "1243" '// weis jetzt garnicht mehr ob das wirklich so geht

// Delphi

a: String;
a:='123';
a:=a + '1243';


// C++

String a();

a="123";
a+="12343"; // könnte man auch als a=a+... schreiben



C/++ verführt zum unsauberen Programmieren, und man denkt wegen den Erfahrungswerten bei anderen Sprachen schnell, dass es in C++ keine andere Möglichkeit gibt und die Sache einfach so kompliziert ist (zb. die Strings in C, die als char[] repräsentiert werden).

C++ kennt aber auch all die eleganten Lösungen wie es sie in Delphi oder Basic gibt. In gewisser Weise ist das wie Windows<-> Linux. Bei Windows ist extrem viel vorgegeben (zb. Systemstart/skripte, die einzelnen Elemente usf.) - in Linux hat man dagegen die volle Kontrolle über alles, weil die Startskripte eben nicht fest ins OS einkompiliert sind, sondern einfache Shell Skripte sind.

Desswegen muss man sich zwar erstmal damit beschäftigen, aber dann ist man viel flexibler.

TiKu
18.06.2004, 14:38
Original geschrieben von intel_hasser
Das sind Vorurteile ;).

Im Borland C++ Builder kann man die GUI genauso schön und einfach zusammenklickern wie in Delphi. Im Code ist C++ aber auch nicht komplizierter als Delphi oder VB, das sind wirklich nur Vorurteile aus C-Zeiten.Tja, ich schreibe aber keine Anwendung, sondern ein ActiveX-Control. Da ist nix mit zusammenklicken. Und das war es auch nicht was die Entwicklung mit VB6 so beschleunigt hat.



Basic:

Dim a(3) as Integer '// weis net ob die Array definition stimmt, ist schon lange her
a(0)=4
a(1)=8
a(2)=12

ReDimm Preserve a(5) as Integer

a(3)=5
a(4)=2
Richtig wäre:


Dim a(2) As Integer
a(0) = 4
a(1) = 8
a(2) = 12
Oder wenn Du das dann Redimmen willst:


Dim a() As Integer
Redim a(2) As Integer
a(0) = 4
a(1) = 8
a(2) = 12
Redim Preserve a(4) As Integer
a(3) = 5
a(4) = 2


Strings:


'// Basic

Dim a as String
a="123"
a=a + "1243" '// weis jetzt garnicht mehr ob das wirklich so geht
Geht, besser (weil schneller und problemloser, wenn man noch andere Datentypen als String mit verkettet) wäre aber a = a & "1243"
Davon abgesehen: STL ist nicht alles. Wenn man Win32-Anwendungen schreibt, kann man bspw. kaum STL-Strings nehmen. Und die meisten Anwendungen sind nun mal Win32-Anwendungen.

i_hasser
18.06.2004, 14:49
Original geschrieben von TiKu
Und die meisten Anwendungen sind nun mal Win32-Anwendungen.

Mein Linux beherbergt um Dimensionen mehr Anwendungen als eine Windooows Installation ;)

Allein /bin, /sbin, /usr/bin und /usr/sbin und noch /opt/kde/bin beherrbergen zusammen schlappe 3100 Programme!
Bei Windooows hat eine normale Installation idR nichtmal so viele Dateien, wovon aber auch nur ~1% Executables sind.


Im Endeffekt bist du mit C++ fast immer so schnell wie mit Delphi oder Pascal (gibt nur ganz ganz wenige und seltene Ausnahmen) und dabei aber deutlich flexibler. Allerdings muss man C++ wirklich können - viele Möglichkeiten bieten auch viele Möglichkeiten etwas falsch zu machen, und gerade das Thema Programmierstil ist bei C++ wegen den vielen Freiheiten extrem wichtig.

Um das jetzt mal auf ein abschließendes, ganz objektives Fazit zu bringen:

C++ ist für die, die wirklich programmieren können *buck* *duck&renn*

TiKu
18.06.2004, 14:58
Original geschrieben von intel_hasser
Mein Linux beherbergt um Dimensionen mehr Anwendungen als eine Windooows Installation ;)

Allein /bin, /sbin, /usr/bin und /usr/sbin und noch /opt/kde/bin beherrbergen zusammen schlappe 3100 Programme!
Bei Windooows hat eine normale Installation idR nichtmal so viele Dateien, wovon aber auch nur ~1% Executables sind.Und? Kommt Windows mit einem Office-Paket usw. daher? Ziemlich sinnloser Vergleich. Dein Linux ist eine komplette Distri, Windows ist nicht wirklich eine Distri. Naja, wird langsam OT, also lassen wir das.


Original geschrieben von intel_hasser
Um das jetzt mal auf ein abschließendes, ganz objektives Fazit zu bringen:

C++ ist für die, die wirklich programmieren können *buck* *duck&renn* Wie gut, dass ich inzwischen auch C++ nehme (weil VB6 ausstirbt - VB.net ist was ganz anderes).;) Aber hättest Du das ernst gemeint, hätteste eigentlich einen PLONK verdient.

i_hasser
18.06.2004, 15:03
Der Vergleich haut schon ungefähr hin - ich nehme ja schließlich kein Suse, sondern Slackware. Das passt gut auf 2 CDs.

Und Office Pakete (in der Hinsicht ist wirklich nur KOffice dabei gewesen - insgesammt haben alle KDE Progs und KDE selbst gerade einmal 400 Binaries) nicht die Welt, KOffice hat vielleicht 20 Binaries.

Ich möchte garnicht wissen wieviel Müll da eine Suse Distri mit ihren 2 DVDs beherrbergt.

Naja... soviel zum OT ;).

mtb][sledgehammer
20.06.2004, 15:19
@intel_hasser
Irgendwie sind deine Ansichten ja nicht ganz einheitlich. Vor ein paar Seiten hast du noch für gut befunden, dass C++ dich so versteht wie du es willst, ich zitier wohl besser mal:
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). Jetzt frage ich mich, was ist logischer für einen Menschen: Zu sagen: "Tu das" oder "Tu das (keine Parameter)".
Delphi weist in Bezug auf Methoden aber auf alle Fälle sehr viele Möglichkeiten auf, z.B. finde ich die Variablenparameter (procedure tudas(var a: integer; var b: boolean; c: string) sehr praktisch. In Java müsste ich dafür erst eine neue Klasse definieren, ein neuese Objekt erstellen, übergeben usw., wie es da in C++ aussieht weiß ich natürlich nicht.
Und wenn du dich wirklich an den Prozeduren störst kannst du auch jede Prozedur folgendermaßen schreiben

function Tudas: boolean
begin
...
result:= "was auch immer"
end;

Methodenaufruf
begin
...
Tudas;
...
end;Daran meckert der Compiler nicht und du kannst für eventuelle Fälle noch nen möglichen Rückgabewert zurückgeben.

Edit:
Das schönste an Delphi habe ich noch ganz vergessen, die propertys: Ich meine nur, was ist leslicher:
MeinWert := Objekt.getWert(); oder
MeinWert := Objekt.Wert;
Und trotzdem ist beides gleich sicher :D

Novox
21.06.2004, 00:19
Nein, zum Thema hab ich nix mehr zu sagen, skyphab hat’s bereits auf den Punkt gebracht.

Aber:
Original geschrieben von intel_hasser
[..] es wird bewiesen, dass die Häufigkeitsverteilung zb. mit zunehmender Anzahl an beobachteten Versuchen gegen die Wahrscheinlichkeit strebt.
Du meinst wohl: das arithmetische Mittel strebt gegen den Erwartungswert.
µ = EX = ∫ x f(x) dx, (x = -∞..∞ )
bzw.
µ = EX = ∑ xipi, i = 1..∞ für diskrete Verteilungen mit abzählbar unendlich vielen Werten (sonst bis n)

Jedenfalls wenn ich das richtig in Erinnerung hab. Falls nicht, bitte nicht hauen, ist schon ein paar Semester her... ;)

i_hasser
21.06.2004, 01:02
Hab den Beitrag ganz übersehen :]

Also mal langsam


Original geschrieben von mtb][sledgehammer
@intel_hasser
Irgendwie sind deine Ansichten ja nicht ganz einheitlich. Vor ein paar Seiten hast du noch für gut befunden, dass C++ dich so versteht wie du es willst, ich zitier wohl besser mal: Jetzt frage ich mich, was ist logischer für einen Menschen: Zu sagen: "Tu das" oder "Tu das (keine Parameter)".

Wieso, das "();" hinter dem Funktionsnamen sagt doch schon alles. Warum soll ich bitteschön einen Sachverhalt an 2 Stellen ausdrücken?
Das wäre zwar für diese Eigenschaft deutlicher, aber insgesammt wäre es wie viel gelaber um den heißen Brei ;)

Im Gegensatz zu C++ stiftet Delphi hier viel mehr verwirrung. ZB. dadurch, dass man bei Prozeduren/Funktionen ohne Parameter keine Parameter (bzw. kein void) angeben muss (das "();" also weglassen kann).

In C++ drückt man so unmissverständlich aus, dass es sich eben um eine Funktion handelt (der Funktionsname ist der Zeiger darauf und das "();" bewirkt eben die Ausführung der Funktion).
In Delphi dagegen (und das hat mich zb. auch bei VisualBasic immer ein bisschen gestört) könnte es sich theoretisch genausogut um eine einfache Variable handeln.
An sich wäre das ja noch garnicht mal so blöd, wirklich blöd ist, dass eine Prozedur im Gegensatz zu einer Variable oder Funktion (oder einer Funktion) gerade keinen Wert zurückgibt und desswegen ist die einheitliche Syntax an der Stelle ein Verbrechen an der Logik ;)




Delphi weist in Bezug auf Methoden aber auf alle Fälle sehr viele Möglichkeiten auf, z.B. finde ich die Variablenparameter (procedure tudas(var a: integer; var b: boolean; c: string) sehr praktisch.

Kannst du mir das mal erklären? In C wäre das einfach "void tudas(int a, bool b, string c);" - was ist daran besonders?
Jetzt sag bitte nicht, dass du auf sachen wie variable Parameterzahl hinaus willst - einerseits geht das in C ganz problemlos ("int a(int b, ...);") und andererseits sollte man sowas nicht nehmen, weil die Anzahl der Parameter mit übergeben werden muss -> nette Fehler wenn man die falsche Anzahl gibt.

Meinst du vielleicht, dass man einer Funktion verschiedene Parameter(typen) geben kann? Ist in C++ auch garkein Problem, da ist C++ sogar noch vie leistungsfähiger als Delphi.
Schönes Beispiel ist der Vektor, "vector<abc>" erstellt eben ein Array aus abc, wobei es völlig egal ist was abc nun eigentlich ist - das sind Templates, die sich auch an anderen Stellen wunderhübsch sauber und logisch einsetzen lassen.


In Java müsste ich dafür erst eine neue Klasse definieren, ein neuese Objekt erstellen, übergeben usw., wie es da in C++ aussieht weiß ich natürlich nicht.
Java ist 1. was anderes und 2. brauchst du das auch in Java nicht, da muss der Funktionsprototyp in den Header und die Implementierung einfach irgendwo dazu - alles in die Main-Klasse.
Und sag jetzt ja nix gegen Java, so sauber ist Delphi um längen nicht ;). Java ist zwar langsam und hat einige Formprobleme (zb. dass man die Implementierung nicht vom Header trennen muss), aber ansonsten ist das einfach eine extrem feine Sprache.
Natürlich sollte man da nicht mit einem C-Stiel (ohne ++) rangehen, da wird man schnell unglücklich.
Auch gutes und sauberes Programmieren will gelernt sein, und dazu muss man es einfach irgendwann lernen. Es reicht nicht eine gute Sprache zu benutzen wie den letzten QBASIC Compiler - man muss auch das nutzen was die Sprache im Funktionsumfang von anderen Sprachen unterscheidet.




Und wenn du dich wirklich an den Prozeduren störst kannst du auch jede Prozedur folgendermaßen schreiben

function Tudas: boolean
begin
...
result:= "was auch immer"
end;

Methodenaufruf
begin
...
Tudas;
...
end;
Daran meckert der Compiler nicht und du kannst für eventuelle Fälle noch nen möglichen Rückgabewert zurückgeben.

*lol*

Das ist jetzt nicht dein Ernst, oder?
Da geht ja die logische Trennung von Funktion und Prozedur (die es übrigens auch in C/++ eben mit void gibt) völlig verloren. Nein, ich bin für BASIC. Und nein, den leistungsfähigen QBasic Compiler lassen wir heute in der Ecke stehen - GWBASIC lautet das Stichwort!




Edit:
Das schönste an Delphi habe ich noch ganz vergessen, die propertys: Ich meine nur, was ist leslicher:
MeinWert := Objekt.getWert(); oder
MeinWert := Objekt.Wert;
Und trotzdem ist beides gleich sicher :D [/B]
[/quote]

Das macht den Code unübersichtlich und wir müssen schon wieder einen einfach nicht benötigten Sonderfall einführen.
Für die 2. Variante würde ich einfach eine Public Variable nehmen, oder wenn eben nicht anders möglich eine Funktion.

Was ist an "meinwert=abc.wert();" denn falsch? Es drückt viel deutlicher aus, dass wert nicht einfach nur eine Variable ist, sondern dass da Code dahinter steckt.
Über verschiedene Parameter kannst du auch sowas realisieren:



a=xyz.wert();
xyz.wert(234);


Einmal lesen wir den Wert aus, dann setzen wir ihn. Mach sowas mal so elegant in Delphi - ohne so ein absolut unnötiges Konstrukt wie Properties zuhilfe zu nehmen.
Properties sind nicht mehr als Funktionen, und desswegen ist es einfach sinnfrei da neue Strukturen für einzuführen.



@Novox

Ja, das kommt ungefähr hin. Die Ereignisse mappen wir auf 0 und 1 und dann wird summiert.

TiKu
21.06.2004, 01:45
Original geschrieben von intel_hasser
Wieso, das "();" hinter dem Funktionsnamen sagt doch schon alles.Wenn man es weiß, dann schon. Aber frag mal einen Laien was verständlicher ist: Procedure a() bzw. Sub a() oder void a().;)

Original geschrieben von intel_hasser
Im Gegensatz zu C++ stiftet Delphi hier viel mehr verwirrung. ZB. dadurch, dass man bei Prozeduren/Funktionen ohne Parameter keine Parameter (bzw. kein void) angeben muss (das "();" also weglassen kann).Dann schreib in VB doch ein Call davor und setze die () hintendran. Bei Delphi gibt's sicher auch sowas. Also bspw. Call EineSub(). Das Call macht es übrigens noch eindeutiger: "Rufe den Code auf" bzw. "Führe den Code aus".

Original geschrieben von intel_hasser
In C++ drückt man so unmissverständlich aus, dass es sich eben um eine Funktion handelt (der Funktionsname ist der Zeiger darauf und das "();" bewirkt eben die Ausführung der Funktion).Für Dich muss die Syntax eng mit der dahintersteckenden Architektur verbunden sein. Wir finden es besser, wenn die Syntax von technischen Details unabhängig ist (quasi portabler *Seitenhieb* ;)).

In Delphi dagegen (und das hat mich zb. auch bei VisualBasic immer ein bisschen gestört) könnte es sich theoretisch genausogut um eine einfache Variable handeln.Nicht wenn man konsequent die () dahinter- und bei Subs das Call davorsetzt. An Deinem schlechten Stil bist Du selbst schuld.

Jetzt sag bitte nicht, dass du auf sachen wie variable Parameterzahl hinaus willst - einerseits geht das in C ganz problemlos ("int a(int b, ...);") und andererseits sollte man sowas nicht nehmen, weil die Anzahl der Parameter mit übergeben werden mussIn C/C++ vll., aber nicht in VB. VB kennt glücklicherweise SafeArrays, die ihre Größe selbst kennen. Delphi hat sowas sicher auch.
Das nervt mich an C/C++ so sehr: Man muss bei jedem Mist die Größe mit übergeben.

Das macht den Code unübersichtlich und wir müssen schon wieder einen einfach nicht benötigten Sonderfall einführen.Properties sind was Feines! Erstens ist es eindeutiger: "Die Klasse 'Mensch' hat eine Eigenschaft 'Augenfarbe'" ist doch viel intuitiver als "Die Klasse 'Mensch' hat eine Methode 'setze_Augenfarbe' und eine Methode 'hole_Augenfarbe'". Zweitens sind zumindest bei VB.net die Get- und Set-Methoden codetechnisch zusammengefasst und bilden somit eine Einheit. 2 einzelne Methoden sind dagegen erstmal unabhängig voneinander und man muss sie optisch dann irgendwie (Kommentare?) "zusammenschweißen". Drittens verhalten sich Properties nach außen hin wie öffentliche Variablen. Dem Nutzer der Klasse ist doch vollkommen egal, wie das intern realisiert ist. Eine öffentliche Variable kann man später problemlos durch eine Property ersetzen, ohne dass man die Kompatibilität zum aufrufenden Code bricht. Mach das mal mit C/C++ und Methoden.;) Da fehlt dann überall das (). Von der anderen Syntax beim Setzen des Wertes ganz zu schweigen...

Was ist an "meinwert=abc.wert();" denn falsch? Es drückt viel deutlicher aus, dass wert nicht einfach nur eine Variable ist, sondern dass da Code dahinter steckt.Und? Das interessiert in den seltensten Fällen.




a=xyz.wert();
xyz.wert(234);


Einmal lesen wir den Wert aus, dann setzen wir ihn. Mach sowas mal so elegant in DelphiDa geht das noch viel eleganter:


a := xyz.wert;
xyz.wert := 234;


ohne so ein absolut unnötiges Konstrukt wie Properties zuhilfe zu nehmen.
Properties sind nicht mehr als Funktionen, und desswegen ist es einfach sinnfrei da neue Strukturen für einzuführen.Man kann natürlich alles was die Lieblingssprache nicht kann als sinnlos hinstellen.;) Ich denke C++ kann alles?;)

mtb][sledgehammer
21.06.2004, 16:10
Ergänzend zu TiKu muss ich da doch auch noch auf ein paar Dinge eingehen:
Original geschrieben von intel_hasser
Wieso, das "();" hinter dem Funktionsnamen sagt doch schon alles. Warum soll ich bitteschön einen Sachverhalt an 2 Stellen ausdrücken?
Das wäre zwar für diese Eigenschaft deutlicher, aber insgesammt wäre es wie viel gelaber um den heißen Brei ;)Wenn du dich an den fehlenden Klammern störst, dann schreib dch einfach wie in C++ auch "Methode();", habs gerade getestet, dass es problemlos funktioniert. Aber ist in diesem Fall nicht Delphi einfach die Sprache, die mehr kann?

In C++ drückt man so unmissverständlich aus, dass es sich eben um eine Funktion handelt (der Funktionsname ist der Zeiger darauf und das "();" bewirkt eben die Ausführung der Funktion).Also eigentlich sollte man doch schon am Methodennamen erkennen, dass es sich um eine Methode handelt.

Kannst du mir das mal erklären? In C wäre das einfach "void tudas(int a, bool b, string c);" - was ist daran besonders? Nein ich will nicht auf variable Parameteranzahl hinaus. Vielleicht dzu ein kleines Beispiel, eine Methode soll einen Integer Wert in biäre Daten zerlegen (3 bits) und zusätzlich einen String mit einem Errorcode zurückgeben, insgesamt also ein array mit 3 Feldern für je einen boolean Wert, und einen String. In Delphi könnte ich das ganze noch in einen record zusammenfassen, in Java kenne ich den Datentyp record zumindest nicht. Daher wäre ich gezwungen das Problem mit einer extra Klasse zu lösen. In Delphi kann ich dagegen einfach Prozeduren und Funktionen mit mehreren Rückgabewerten programmieren. (Ob man das schon findet der nicht ist wieder subjektiv, aber man hat die Möglichkeit)

Und sag jetzt ja nix gegen Java, so sauber ist Delphi um längen nicht ;). Ich würde auch nie behaupten, dass Java unsauber ist. Der Vergleich wäre ja auch wie zw. AMD64 und IA64, das eine schleift Altlasten ala A20 mit sich rum, während das andere alle Macken der alten Technik versucht zu vermeiden. ;)
*lol*

Das ist jetzt nicht dein Ernst, oder?
Da geht ja die logische Trennung von Funktion und Prozedur (die es übrigens auch in C/++ eben mit void gibt) völlig verloren. Nein, ich bin für BASIC. Und nein, den leistungsfähigen QBasic Compiler lassen wir heute in der Ecke stehen - GWBASIC lautet das Stichwort!Ich würde das selber nicht so machen, da ich mich ja auch nicht daran störe statt "function void" einfach "procedure" zu schreiben. Wobei ich das bei fertigen Klassen schon mal anwende, wenn mir der Rückgabewert egal ist. (Würde ich den Wert einer extra Variablen zuweisen, weißt mich nur der Compiler noch drauf hin, dass ich den Variablenwert nie nützen würde)

Einmal lesen wir den Wert aus, dann setzen wir ihn. Mach sowas mal so elegant in Delphi - ohne so ein absolut unnötiges Konstrukt wie Properties zuhilfe zu nehmen.
Properties sind nicht mehr als Funktionen, und desswegen ist es einfach sinnfrei da neue Strukturen für einzuführen. Auch diese Möglichkeit (Überladen von Methoden) ist in Delphi gegeben. Man schreibe, wie der Compiler befiehlt hinter den Methodenkopf ein "overload" (hat gleich den Vorteil, dass man ungewolltes Überladen vermeidet), und schon ist das analog in Delphi möglich. Die propertys sind eben nur eine weitere Möglichkeit, auf sichere Wiese auf geschützte Attribute einer Klasse zuzugreifen. Vorteil für den Anwender: er kann sie wie public Attribute behandeln (und muss wie Tiku sagte keine großen Veränderungen bei Umstellung von public auf private durchführen)

i_hasser
21.06.2004, 17:15
Also jetzt gehts ja völlig durcheinander.

Habt ihr beide eigentlich schonmal richtig mit C++ programmiert? Also ich meine richtig - nicht nur ein paartausend Zeilen ;).



Wenn man es weiß, dann schon. Aber frag mal einen Laien was verständlicher ist: Procedure a() bzw. Sub a() oder void a().;)
Von einem BASIC Programmierer hab ich auch nix anderes erwartet - eine Sprache, die man lernen muss ist ja eh Mist... ;)
Na mal ernst, eine Programmiersprache muss man sich mal angucken bevor man damit loslegt - und das void ist in C/++ ganz eindeutigst vergeben - nämlich für nix. void...() gibt nix zurück und void* a ist ein Zeiger auf nix.


Dann schreib in VB doch ein Call davor und setze die () hintendran. Bei Delphi gibt's sicher auch sowas. Also bspw. Call EineSub(). Das Call macht es übrigens noch eindeutiger: "Rufe den Code auf" bzw. "Führe den Code aus".
Das ist eine Möglichkeit, die aber wieder nur völlig unübersichtlich ist und aus der Unfähigkeit der Sprache resultiert (wieso einfach wenn es auch kompliziert geht? Das () einfach direkt an die Funktion zu heften wäre ja viel zu einfach und viel zu übersichtlich).


Für Dich muss die Syntax eng mit der dahintersteckenden Architektur verbunden sein. Wir finden es besser, wenn die Syntax von technischen Details unabhängig ist (quasi portabler *Seitenhieb* ;)).

Jaja, sei mal ganz ruhig ;D. Ich zähle auf - VB: 2 OS (win9x/winnt). Und Delphi? 3 OS (Win9x/NT und Linux).

C/++ - so ziemlich alle OS die es gibt. Es hat schon seinen Grund, dass C/++ so weit verbreitet ist - und im professionellen Bereich (wo sowieso kein Windows zum Einsazt kommt) C/++, Java und Fortran vorherrschen.


Nicht wenn man konsequent die () dahinter- und bei Subs das Call davorsetzt. An Deinem schlechten Stil bist Du selbst schuld.
Ok, in Delphi kann man es auch so dahintersetzen. Aber nicht umsonst sagt man PHP wäre zb. eine unsaubere Sprache - Möglichkeiten verführen einfach. PHP benutzt nämlich ziemlich genau die C-Syntax - die Möglichkeiten (zb. Variablendeklarationen wegzulassen) machen die Sprache erst unsauber.


In C/C++ vll., aber nicht in VB. VB kennt glücklicherweise SafeArrays, die ihre Größe selbst kennen. Delphi hat sowas sicher auch.
Das nervt mich an C/C++ so sehr: Man muss bei jedem Mist die Größe mit übergeben.
In C++ geht das auch - und auch ohne die Parameterzahl zu geben. Mein Beispiel war noch auf alt-C bezogen (zb. ist printf so realisiert).

Und VB nimmt dir da auch einfach zuviel Arbeit ab und desswegen ist es auch so extrem langsam! Wenn du einfach Parameter geben willst brauchst du eben irgendwas, was das Zählen übernimmt. Und in C/++ kannst du das auch selber reinproggen, und demnach auch die Performance kontrollieren.
In VB hast du einen vorgefertigten Handler der langsam ist und dich ziemlich einschränkt.

Wie man variable Parameter möglichst glücklich in C++ realisiert weis ich jetzt nicht aus dem Stehgreif - geht sicher über Vektoren oder Templates. Die cout Funktion ist aber schon ein gutes Beispiel, auch wenn sie mir persönlich nicht so gefällt.


Properties sind was Feines! Erstens ist es eindeutiger: "Die Klasse 'Mensch' hat eine Eigenschaft 'Augenfarbe'" ist doch viel intuitiver als "Die Klasse 'Mensch' hat eine Methode 'setze_Augenfarbe' und eine Methode 'hole_Augenfarbe'". Zweitens sind zumindest bei VB.net die Get- und Set-Methoden codetechnisch zusammengefasst und bilden somit eine Einheit. 2 einzelne Methoden sind dagegen erstmal unabhängig voneinander und man muss sie optisch dann irgendwie (Kommentare?) "zusammenschweißen". Drittens verhalten sich Properties nach außen hin wie öffentliche Variablen. Dem Nutzer der Klasse ist doch vollkommen egal, wie das intern realisiert ist. Eine öffentliche Variable kann man später problemlos durch eine Property ersetzen, ohne dass man die Kompatibilität zum aufrufenden Code bricht. Mach das mal mit C/C++ und Methoden. Da fehlt dann überall das (). Von der anderen Syntax beim Setzen des Wertes ganz zu schweigen...

Properties sind was feines für den unsauberen Programmierer - mehr nicht. ;)

Ich hab dir außerdem kurz danach ein Beispiel gegeben, wie man das gut realisieren kann. Man könnte auch einfach einen Operator überladen und dann hättest du exakt den Delphi Syntax (also abc.wert=3; und xyz=abc.wert;).

Aber das ist typisches Windooows denken - "was es nicht gibt geht nunmal nicht". In C++ kann man sich Lösungen für solche Probleme selbst basteln! Und da ist man immer variabler als mit irgend einer vorgefertigten Lösung. Aber es gibt auch genügend fertige Lösungen.

Ich wäre für einen einfachen Feldtest - sagen wir 10 kleine Szenarien müssen programmiert werden, und danach vergleichen wir wie kompliziert und elegant die Sache in Delphi, Basic und C++ geworden ist ;D.

Die Idee gefällt mir jetzt wirklich ;D


Und? Das interessiert in den seltensten Fällen.
In VB bist du es ja auch sicher nicht gewohnt Source zu optimieren - VB ist einfach immer langsam... ;D
Wenn du irgendwann mal was etwas performanter realisieren musst wirst du dich freuen, wenn du schon am Code siehst was denn lange dauert. Eine sache, die in VB gänzlich unmöglich ist, weil die einfachsten Funktionen extrem langsam sind.


Da geht das noch viel eleganter:
Das ist nicht nur unleserlicher, sondern auch nicht wirklich eleganter. Die verschiedenen Prototypen dagegen sind völlig sauber und erfordern keine neuen Konstrukte wie eben zb. Properties - und das trotz eines besseren Funktionsumfanges (mit Funktionen kann mindestens alles realisieren was auch mit properties geht).



Man kann natürlich alles was die Lieblingssprache nicht kann als sinnlos hinstellen.;) Ich denke C++ kann alles?;)
Ja, kann es auch (fast) - Properties gehören auch dazu. Ich bin mir sogar ziemlich sicher, dass es nicht nur mit den Funktionen geht, sondern dafür auch schon fertige Klasse im C-Standard gibt mit denen man sowas realisieren kann. Der Klasse selbst brauchst du natürlich nur das = und den cast überladen und dann hast du exakt das gleiche Aussehen wie Properties.
Warum müssen andere Sprachen eigentlich immer das wichtigste verschleiern? In Delphi oder Basic wird zb. nicht ersichtlich was ein Propertie eigentlich ist. Wie kann man sowas nur toll finden?


So, und nun auf zum 2. Streich (hab mich gerade warm geschrieben ;D)


Wenn du dich an den fehlenden Klammern störst, dann schreib dch einfach wie in C++ auch "Methode();", habs gerade getestet, dass es problemlos funktioniert. Aber ist in diesem Fall nicht Delphi einfach die Sprache, die mehr kann?
Wie schon gesagt ist das tatsache eine Lösungsmöglichkeit. Und wie auch schon gesagt - PHP ist nicht umsonst als unsaubere Sprache verschrieen.


Also eigentlich sollte man doch schon am Methodennamen erkennen, dass es sich um eine Methode handelt.
Die Dinger heißen Funktionen ;).
Aber wieso in aller Welt sollte man das am Namen erkennen? Als nächstes fangen wir wohl alle Strings mit "str"... an?

Abstraktes Programmieren ist damit auf jeden Fall nicht möglich, weil du dich dann mit dem Namen an die Realisierung bindest.


Nein ich will nicht auf variable Parameteranzahl hinaus. Vielleicht dzu ein kleines Beispiel, eine Methode soll einen Integer Wert in biäre Daten zerlegen (3 bits) und zusätzlich einen String mit einem Errorcode zurückgeben, insgesamt also ein array mit 3 Feldern für je einen boolean Wert, und einen String. In Delphi könnte ich das ganze noch in einen record zusammenfassen, in Java kenne ich den Datentyp record zumindest nicht. Daher wäre ich gezwungen das Problem mit einer extra Klasse zu lösen. In Delphi kann ich dagegen einfach Prozeduren und Funktionen mit mehreren Rückgabewerten programmieren. (Ob man das schon findet der nicht ist wieder subjektiv, aber man hat die Möglichkeit)

Gibts in C++ genauso - gibt sogar ein 1:1 äquivalent. Natürlich musst du die immer vorher definieren (so wie ich das verstanden hab ein Record aber auch). Die Dinger heißen übrigens structs ;)

zb.:



struct xyz
{
int a;
string b;
}


Man kann das aber auch als Vektor realisieren (da spart man sich das Struct).
Zb. so ungefähr (ist jetzt sicher komplizierter als es sein müsste weil ich das ehrlich gesagt noch nie gebraucht hab):



vector<vector> abc(2);
abc[0]=new vector<string>;
abc[1]=new vector<int>;

usw.


Den 2. Vektor bekommt man definitiv auch wieder weg, so dass der eine Vektor mehrere verschiedene Typen enthält.

Und Fehlerübergabe per Funktionsrückgabewert ist übrigens sowieso als unsauber verschrieen. Wieso? Weil man zu oft den Rückgabewert einfach nicht überprüft. Und durch diesen Fehler sind schon zu oft Sicherheitslücken entstanden.


Ich würde auch nie behaupten, dass Java unsauber ist. Der Vergleich wäre ja auch wie zw. AMD64 und IA64, das eine schleift Altlasten ala A20 mit sich rum, während das andere alle Macken der alten Technik versucht zu vermeiden.

Da würde ich lieber mal aufpassen, IA64 hat mit Delphi viel mehr zu tun als Java. IA64 Code ist extrem aufgebläht, genauso wie der Delphi (oder auch VB) Code.
Ein Hauptvorteil von AMD64/IA32.

Dann ist IA64 ziemlich unflexibel was die Desktop-üblichen Anforderungen angeht (Sprungvorhersage etc.) - wenn mir in Java oder C++ irgendwas fehlt kann ich das schnell dazuproggen, in Delphi muss ich mir dann was anderes überlegen (in VB natürlich auch).



Ich würde das selber nicht so machen, da ich mich ja auch nicht daran störe statt "function void" einfach "procedure" zu schreiben. Wobei ich das bei fertigen Klassen schon mal anwende, wenn mir der Rückgabewert egal ist. (Würde ich den Wert einer extra Variablen zuweisen, weißt mich nur der Compiler noch drauf hin, dass ich den Variablenwert nie nützen würde)
Der letzte Teil schreit schon wieder nach Sicherheitslücke. Fehler die nicht ausgewertet werden sind wie schon gesagt viel zu oft Ursachen für Lücken gewesen, wesswegen du in Java auch Exceptions hast (und afaik gibts das in C++ auch).



Auch diese Möglichkeit (Überladen von Methoden) ist in Delphi gegeben. Man schreibe, wie der Compiler befiehlt hinter den Methodenkopf ein "overload" (hat gleich den Vorteil, dass man ungewolltes Überladen vermeidet), und schon ist das analog in Delphi möglich. Die propertys sind eben nur eine weitere Möglichkeit, auf sichere Wiese auf geschützte Attribute einer Klasse zuzugreifen. Vorteil für den Anwender: er kann sie wie public Attribute behandeln (und muss wie Tiku sagte keine großen Veränderungen bei Umstellung von public auf private durchführen)

Ja, die Properties sind eine weitere unsaubere, völlung unnütze Methode sich auszudrücken. ;)

Und Funktionen kannst du auch einfach nach private/protected schieben. Ich seh einfach den Nachteil nicht, den die Funktionen gegenüber dem Property haben sollen *noahnung*


So, ich habs ja schon aufgegriffen - jetzt will ich sehen ;D
Wir müssten uns also ein paar schöne, oft auftretende Szenarien ausdenken und dafür was in VB, Delphi und C++ schreiben. Und dann wird verglichen welche Lösung die elegantere ist.

TiKu
21.06.2004, 17:56
Original geschrieben von intel_hasser
Habt ihr beide eigentlich schonmal richtig mit C++ programmiert? Also ich meine richtig - nicht nur ein paartausend Zeilen ;).Bin grad dabei. Gegenfrage: Hast Du schonmal richtig mit VB programmiert? Ich bin übrigens der Meinung, dass die Länge eines Programms nichts aussagt. Man kann Millionen von Zeilen schreiben und die Möglichkeiten der Sprache doch nur ankratzen.

Original geschrieben von intel_hasser
Von einem BASIC Programmierer hab ich auch nix anderes erwartet - eine Sprache, die man lernen muss ist ja eh Mist... ;)Das habe ich nie behauptet und entspricht auch nicht meiner Meinung. Ich sehe es als Vorteil, wenn eine Sprache intuitiv und leicht erlernbar ist, aber ich sage nicht, dass Sprachen, auf die das nicht zutrifft, Mist sind.

Original geschrieben von intel_hasser
Jaja, sei mal ganz ruhig ;D. Ich zähle auf - VB: 2 OS (win9x/winnt). Und Delphi? 3 OS (Win9x/NT und Linux).Und? Was sagt uns das? Dass einfach noch keiner eine VB- oder Delphi-VM für andere OS geschrieben hat. Mehr nicht.

im professionellen Bereich (wo sowieso kein Windows zum Einsazt kommt)<OT>sehr gewagte Behauptung... Man kann es sich natürlich sehr einfach machen und den professionellen Bereich als das definieren was nicht Windows nutzt. Mit dr Realität hat das aber nix zu tun.</OT>

Möglichkeiten verführen einfach.Tja, und wo C/C++ doch so extrem viele Möglichkeiten bietet, verführt das doch noch viel mehr zu einem unsauberen Stil, oder?;) Wie gesagt: An seinem Stil ist allein man selbst schuld.

Und VB nimmt dir da auch einfach zuviel Arbeit abSpätestens wenn Du mal an einem kommerziellen Projekt arbeitest, wirst Du eben das zu schätzen wissen.

und desswegen ist es auch so extrem langsam!Jaja, das alte Klischee vom langsamen VB. Wenn man keine Ahnung hat, ist es natürlich langsam.

Properties sind was feines für den unsauberen Programmierer - mehr nicht.Oder was feines für den Programmierer, der das Programm, welches er schreibt als abstraktes Modell sieht und nicht als eine Befehlsfolge.

Ich hab dir außerdem kurz danach ein Beispiel gegeben, wie man das gut realisieren kann. Man könnte auch einfach einen Operator überladen und dann hättest du exakt den Delphi Syntax (also abc.wert=3; und xyz=abc.wert;).Sicher, dass das geht? Folgende Klasse:

class xyz {
...
private:
int m_Param1;
int m_Param2;

// was muss hierein, damit man später bla = xyz.Param1/2 bzw. xyz.Param1/2 = bla schreiben kann?
}
Die Frage ist ernst gemeint, ich weiß wirklich nicht, ob es geht.

Aber das ist typisches Windooows denken - "was es nicht gibt geht nunmal nicht".*lol* Das erzählst Du einem, der von sich behaupten kann, außer MultiThreading mit VB so ziemlich alles gemacht zu haben was man sich vorstellen kann. Wusste bspw. gar nicht, dass VB standardmäßig Inline-Assembler und andere neckische Sachen kann. Nutzen tue ich sie trotzdem.

In C++ kann man sich Lösungen für solche Probleme selbst basteln!Wenn man genug Zeit hat.

In VB bist du es ja auch sicher nicht gewohnt Source zu optimieren - VB ist einfach immer langsam... ;DSelten so'n Stuss gelesen. 1) VB ist nur langsam, wenn man keine Ahnung hat. 2) Natürlich optimiere ich meinen Code.

Wenn du irgendwann mal was etwas performanter realisieren musstLängst geschehen.

Eine sache, die in VB gänzlich unmöglich ist, weil die einfachsten Funktionen extrem langsam sind.*lol* Junge, ich schreibe an einem kommerziellen Statikprogramm für den Brückenbau. Das ist so ähnlich wie R-Stab und ganz und gar nicht langsam.

TiKu
21.06.2004, 18:10
Original geschrieben von intel_hasser
Und Funktionen kannst du auch einfach nach private/protected schieben. Ich seh einfach den Nachteil nicht, den die Funktionen gegenüber dem Property haben sollen *noahnung*Es ging mir eher um Folgendes:
Du hast diesen Code:

class xyz {
public:
int Param1;
}
Der Zugriff erfolgt per

int x = xyz.Param1;
xyz.Param1 = 123;
Nun willst Du aber Code ausführen, wenn der Wert gelesen/geschrieben wird:

class xyz {
private:
int Param1;
public:
int Param1(void);
void Param1(int newVal);
}
Den Zugriff musst Du nun umbauen:

int x = xyz.Param1();
xyz.Param1(123);

Bei VB sieht das dagegen so aus:
Vorher:

Public Param1 As Long

'// Aufruf:
Dim x As Long
x = xyz.Param1
xyz.Param1 = 123

Nachher:

Private m_Param1 As Long
Public Property Get Param1() As Long
Param1 = m_Param1
End Property
Public Property Let Param1(ByVal newVal As Long)
m_Param1 = newVal
End Property

'// Aufruf:
Dim x As Long
x = xyz.Param1
xyz.Param1 = 123

Wie Du hoffentlich siehst, ändert sich am Aufruf nichts. Ein klarer Vorteil für Properties. Dass sie vom Compiler am Ende genauso wie Funktionsaufrufe behandelt werden, ist für den Programmierer uninteressant.

mtb][sledgehammer
21.06.2004, 18:17
Der Vergleich zu IA 64 bezog sich nicht auf Codedicht (gebläht) sondern auf die Altlasten.
Delphi hat eine lange Vorgeschichte mit Turbo Pascal und Pascal. Soweit ich weiß kannte die erste Version noch nicht mal dynamische Strings. Und diese Sprache hat man bis zu einer objektorientierten Sprache aufgebläht. Die alten Möglichkeiten der Kapselung sind aber immer noch erhalten. Und so eben auch die alte Sprachstruktur.
Java hingegen ist jedoch wesentlich jünger, entstand eben von Anfang an objektorientiert und konnte ohne irgendwelche Altlasten entwickelt werden, eben wie IA 64, bei dem die Entwickler auch ein konsequentes Konzept verfolgen können.

Klar ist die Linie einheitlicher wenn ich jede Methode auf die selbe Art und Weise behandle, warum es jedoch weh tut, wenn man Sonderfälle kenntlich macht? Sind wir nicht in jeder Sprache froh, wenn uns Sonderfälle die Sprache erleichtern? Versuch einmal die hinreichende Bedingung eines Extrumums einer mathematischen Funktion von 5 Veränderlichen ohne Symbole zu schreiben. Ich wünsche viel Spaß. --> Sonderfälle/Symbolik hilft beim Verständnis von komplexen Verhältnissen.

Auch unverständlich für mich ist es, dass du propertys als unsauber betrachtest. Sie stellen kein Sicherheitsrisiko dar. Für den Nutzer einer klasse sind sie viel transparenter, weil sie den Wert eines Attrbuts, sowie deren Zugriffsmethoden zusammenfassen. Und letztendlich stellen sie das dar, auf was der User zugreift: Variablen, die man lesen und ändern kann. Dass dazwischen noch ein SicherheitsLayer ist, ist für den User uninteressant. Ich wüsste auf alle Fälle nicht, wie ich bei propertys etwas falsch machen kann. Ganz im Gegensatz beispielsweise zur Mehrfachvererbung.

i_hasser
21.06.2004, 18:18
Original geschrieben von TiKu
Bin grad dabei. Gegenfrage: Hast Du schonmal richtig mit VB programmiert? Ich bin übrigens der Meinung, dass die Länge eines Programms nichts aussagt. Man kann Millionen von Zeilen schreiben und die Möglichkeiten der Sprache doch nur ankratzen.


Ja, ich habe auch lange Zeit mit VB geproggt. Und damals hatte ich sogar ähnliche Ansichten wie du - war damals auch Basic-Verfechter.
Dann hab ich mich richtig mit C auseinandergesetzt (und auch viele Features der Sprache genutzt) und inzwischen sehe ich die Nachteile, die Basic hat.



Das habe ich nie behauptet und entspricht auch nicht meiner Meinung. Ich sehe es als Vorteil, wenn eine Sprache intuitiv und leicht erlernbar ist, aber ich sage nicht, dass Sprachen, auf die das nicht zutrifft, Mist sind.

Tja, und warum fragt du dann, ob ein void oder procedure einfacher zu lesen ist? Ist einfach nur Gewöhnungssache - void ist aber kürzer und schneller zu lesen.


Und? Was sagt uns das? Dass einfach noch keiner eine VB- oder Delphi-VM für andere OS geschrieben hat. Mehr nicht.
Ja, weil es da einfach keiner haben will, weil die Leute mit dem vorhandenen vollkommen zufrieden sind ;D


<OT>sehr gewagte Behauptung... Man kann es sich natürlich sehr einfach machen und den professionellen Bereich als das definieren was nicht Windows nutzt. Mit dr Realität hat das aber nix zu tun.</OT>
Es ist kein Geheimniss, dass große Server (also wirklich große Server) nicht unter Windoows laufen. OS/sowieso, Solaris, Irix... alles OSs für den professionellen Einsatz. Und da hast du kein Delphi/VB ;D


Tja, und wo C/C++ doch so extrem viele Möglichkeiten bietet, verführt das doch noch viel mehr zu einem unsauberen Stil, oder?;) Wie gesagt: An seinem Stil ist allein man selbst schuld.
Aber in PHP braucht man zb. Variablen nicht zu deklarieren - das ist unsauber. Die Möglichkeiten von C++ dagegen sind nicht unsauber - da ist ein himmelweiter Unterschied.


Spätestens wenn Du mal an einem kommerziellen Projekt arbeitest, wirst Du eben das zu schätzen wissen.
Es gibt auch in C++ fertige Lösungen, das solltest du endlich mal begreifen!
Du kannst alles selber machen oder auf vorgefertigte Funktionen (die aber auch in C++ realisiert sind) zurückgreifen. Das macht C++ doch gerade aus!


Jaja, das alte Klischee vom langsamen VB. Wenn man keine Ahnung hat, ist es natürlich langsam.
So ziemlich alle Funktionen von VB sind nunmal einfach langsamer als in C/++, desswegen wurden zb. Spiele bisher fast immer in C/++ geschrieben. Oder kennst du ein wirklich großes VB Spiel??


Oder was feines für den Programmierer, der das Programm, welches er schreibt als abstraktes Modell sieht und nicht als eine Befehlsfolge.
Genau, und das ist in C++ viel besser möglich als in VB oder Delphi, weil die Abstraktion viel weiter geht!



Sicher, dass das geht? Folgende Klasse:

class xyz {
...
private:
int m_Param1;
int m_Param2;

// was muss hierein, damit man später bla = xyz.Param1/2 bzw. xyz.Param1/2 = bla schreiben kann?
}
Die Frage ist ernst gemeint, ich weiß wirklich nicht, ob es geht.
Auf jeden Fall kannst du ein Property über eine Subklasse implementieren. Ich weis nicht, ob es noch eine schnellere Möglichkeit gibt, aber ein Property ist über eine SubKlasse definitiv möglich.


*lol* Das erzählst Du einem, der von sich behaupten kann, außer MultiThreading mit VB so ziemlich alles gemacht zu haben was man sich vorstellen kann. Wusste bspw. gar nicht, dass VB standardmäßig Inline-Assembler und andere neckische Sachen kann. Nutzen tue ich sie trotzdem.
Tja, und fast immer wird es ein mörderischer Krampf! Dahingegen kannst du sowas in C++ viel einfacher und sauberer realisieren.


Wenn man genug Zeit hat.
Du hast den wichtigen Teil weggelassen - es gibt in C++ auch für fast alles vorgefertigte Lösungen, und die sind auch gut. Aber das hab ich jetzt schon 3mal gesagt und es nervt langsam...


Selten so'n Stuss gelesen. 1) VB ist nur langsam, wenn man keine Ahnung hat. 2) Natürlich optimiere ich meinen Code.
Längst geschehen.
*lol* Junge, ich schreibe an einem kommerziellen Statikprogramm für den Brückenbau. Das ist so ähnlich wie R-Stab und ganz und gar nicht langsam.

Jaja, schon gut. Du weist doch garnicht was wirklich schnell ist, und C++ ist in jedem Fall schneller als VB ;)

i_hasser
21.06.2004, 18:25
Original geschrieben von mtb][sledgehammer
Der Vergleich zu IA 64 bezog sich nicht auf Codedicht (gebläht) sondern auf die Altlasten.
Delphi hat eine lange Vorgeschichte mit Turbo Pascal und Pascal. Soweit ich weiß kannte die erste Version noch nicht mal dynamische Strings. Und diese Sprache hat man bis zu einer objektorientierten Sprache aufgebläht. Die alten Möglichkeiten der Kapselung sind aber immer noch erhalten. Und so eben auch die alte Sprachstruktur.
Java hingegen ist jedoch wesentlich jünger, entstand eben von Anfang an objektorientiert und konnte ohne irgendwelche Altlasten entwickelt werden, eben wie IA 64, bei dem die Entwickler auch ein konsequentes Konzept verfolgen können.

Klar ist die Linie einheitlicher wenn ich jede Methode auf die selbe Art und Weise behandle, warum es jedoch weh tut, wenn man Sonderfälle kenntlich macht? Sind wir nicht in jeder Sprache froh, wenn uns Sonderfälle die Sprache erleichtern? Versuch einmal die hinreichende Bedingung eines Extrumums einer mathematischen Funktion von 5 Veränderlichen ohne Symbole zu schreiben. Ich wünsche viel Spaß. --> Sonderfälle/Symbolik hilft beim Verständnis von komplexen Verhältnissen.

Auch unverständlich für mich ist es, dass du propertys als unsauber betrachtest. Sie stellen kein Sicherheitsrisiko dar. Für den Nutzer einer klasse sind sie viel transparenter, weil sie den Wert eines Attrbuts, sowie deren Zugriffsmethoden zusammenfassen. Und letztendlich stellen sie das dar, auf was der User zugreift: Variablen, die man lesen und ändern kann. Dass dazwischen noch ein SicherheitsLayer ist, ist für den User uninteressant. Ich wüsste auf alle Fälle nicht, wie ich bei propertys etwas falsch machen kann. Ganz im Gegensatz beispielsweise zur Mehrfachvererbung.

Du kannst Properties genauso gut über eine Klasse implementieren, die genau diese Funktionen zur Verfügung stellt. Wenn ich mir das so überlege geht das sogar extrem sauber, ist genauso leistungsfähig wie ein Property und ist eben kein neues Konstrukt sondern basiert auf einfachen Klassen.

Ich versuch das nachher einfach mal.

i_hasser
21.06.2004, 18:38
So, auf gehts:



template<class T>
class property
{
T ptr;

// reine kosmetik, so können wir einen Startwert übergeben
property(T initvalue)
{
ptr=initvalue;
}

void operator=(T val)
{
ptr=val;
}

operator T()
{
return ptr;
}
}

// So, ich hoffe das ist soweit richtig.
// Über Funktionszeiger kann man jetzt auch speziefische Funktionen realisieren, aber
// der Übersicht halber spare ich mir das jetzt ;)
// Macht keinen Spaß Code im P3D Editor zu schreiben *buck*

// Im Code sieht das nun so aus:

property<int> a;

a=1234;
x=a;

// Das funktioniert einwandfrei, und wie gesagt, mit Funktionszeigern (oder auch einfach mit entsprechenden Klassen - sauberer und ich denke sogar kürzer) können wir auch speziefische Funktionen für Wertübergaben/Abfragen dazusetzen.

TiKu
21.06.2004, 18:43
Original geschrieben von intel_hasser
Ja, ich habe auch lange Zeit mit VB geproggt. Und damals hatte ich sogar ähnliche Ansichten wie du - war damals auch Basic-Verfechter.
Dann hab ich mich richtig mit C auseinandergesetzt (und auch viele Features der Sprache genutzt) und inzwischen sehe ich die Nachteile, die Basic hat.Die Nachteile sehe ich auch (habe sie schon immer gesehen), nur übersehe ich deswegen nicht die Vorteile. Genauso sehe ich auch bei C++ Vor- und Nachteile.

Es ist kein Geheimniss, dass große Server (also wirklich große Server) nicht unter Windoows laufen. OS/sowieso, Solaris, Irix... alles OSs für den professionellen Einsatz. Und da hast du kein Delphi/VB ;D [ ] Der professionelle Bereich besteht nur aus Servern.

Es gibt auch in C++ fertige Lösungen, das solltest du endlich mal begreifen!Das habe ich längst begriffen, sonst würde ich wohl kaum ATL, WTL, STL und wxWidgets nehmen.

So ziemlich alle Funktionen von VB sind nunmal einfach langsamer als in C/++Langsamer mag sein, aber meistens nur vernachlässigbar minimal. Richtig langsam ist VB eigentlich nur bei Strings und da gibt es genug Tricks, dieses Manko zu umgehen.

desswegen wurden zb. Spiele bisher fast immer in C/++ geschrieben. Oder kennst du ein wirklich großes VB Spiel?? [ ] Spiele sind in dieser Frage repräsentativ.
1) VB hat durch das "Basic" im Namen noch immer einen schlechten Ruf. Das schreckt erstmal ab.
2) DirectX war lange Zeit nicht mit VB nutzbar.
3) VB basiert auf COM. COM hat in normalen Anwendungen viele Vorteile, bei Spielen aber eigentlich nur Nachteile.
4) VB war schon immer klar auf normale Anwendungen ausgelegt. C++ ist auf keinen speziellen Bereich optimiert, wodurch es sich für Spiele besser als VB eignet.

Auf jeden Fall kannst du ein Property über eine Subklasse implementieren. Ich weis nicht, ob es noch eine schnellere Möglichkeit gibt, aber ein Property ist über eine SubKlasse definitiv möglich.Dann doch lieber ein simples Schlüsselwort "Property". Warum umständlich wenn's auch einfach geht.;)

Jaja, schon gut. Du weist doch garnicht was wirklich schnell ist, und C++ ist in jedem Fall schneller als VB ;) R-Stab ist sowas wie der Branchenführer und wurde in C++ geschrieben. Wenn COBEAM (so heißt unser Projekt) bei gleichen Sachen ungefähr genauso schnell ist wie R-Stab, gibt's dafür 2 mögliche Erklärungen:
1) R-Stab ist beschissen geschrieben. Dann wäre es aber wahrscheinlich kein Branchenführer.
2) Auch VB-Programme können schnell sein.

mtb][sledgehammer
21.06.2004, 18:46
Wenn hier immer von "möglichst schnell" zu lesen ist: warum ist denn das so wichtig. Das mag in kleinen Anwendungsbereichen vielleicht wichtig sein (3D Gaming, bzw das ganze Multimedia Geschäft, Rendering und Simulationen). Sind das nicht aber die unwichtigsten Programme die es gibt? Viel wichtiger sind doch heute all die kleinen (oder auch größeren) Programme, ohne die sich heute kein Fön mehr bewegt. Ich meine Computer in Industrieanlagen (Robotor, Prozessüberwachung,...), Energieanlagen (Kraftwerke), Endprodukten (Autos, Flugzeuge, ..., Multimediageräte, Medizintechnik),.... dort ist die Geschwindigkeit nur ein geringfügiger Entscheidungsfaktor, das was dort zählt ist fehlerfreie Funktion, weil dort ein BlueScreen eben sehr teuer werden kann (Ich sag nur viel Spaß bei der AugenOP, bei der der Computer ausfällt :] ). Und ich denke, dass ich nicht falsch liege, wenn ich behaupte, dass dieser Computersektor den weit grßeren Marktanteil hat. Die Argumentation mit der Performance halte ich daher für sehr unnötig.

TiKu
21.06.2004, 18:48
Original geschrieben von mtb][sledgehammer
Wenn hier immer von "möglichst schnell" zu lesen ist: warum ist denn das so wichtig. Das mag in kleinen Anwendungsbereichen vielleicht wichtig sein (3D Gaming, bzw das ganze Multimedia Geschäft, Rendering und Simulationen). Sind das nicht aber die unwichtigsten Programme die es gibt? Viel wichtiger sind doch heute all die kleinen (oder auch größeren) Programme, ohne die sich heute kein Fön mehr bewegt. Ich meine Computer in Industrieanlagen (Robotor, Prozessüberwachung,...), Energieanlagen (Kraftwerke), Endprodukten (Autos, Flugzeuge, ..., Multimediageräte, Medizintechnik),.... dort ist die Geschwindigkeit nur ein geringfügiger Entscheidungsfaktor, das was dort zählt ist fehlerfreie Funktion, weil dort ein BlueScreen eben sehr teuer werden kann (Ich sag nur viel Spaß bei der AugenOP, bei der der Computer ausfällt :] ). Und ich denke, dass ich nicht falsch liege, wenn ich behaupte, dass dieser Computersektor den weit grßeren Marktanteil hat. Die Argumentation mit der Performance halte ich daher für sehr unnötig. *zustimm*

Ich mag es zwar auch, wenn meine Programme schön schnell sind, aber man kann's auch übertreiben.

TiKu
21.06.2004, 18:50
Original geschrieben von intel_hasser
Tja, und fast immer wird es ein mörderischer Krampf! Dahingegen kannst du sowas in C++ viel einfacher und sauberer realisieren.Um es mit Deinen Worten zu sagen:
Es gibt auch in VB fertige Lösungen, das solltest du endlich mal begreifen!

i_hasser
21.06.2004, 19:03
So, also das hab ich eben zusammengehackt - geht sicher auch besser ;)
Aber das zeigt wie elegant man in C++ neue Feature implementieren kann, wichtig wirds ab usage - der Rest verschwindet in irgend einem Header und vergammelt dort ;)


// Property implementation
template<class T>
class property
{
T ownvalue;
int usehandler;
prop_hndl<T>* handler;

property(prop_hndl<T>* ptr)
{
handler=ptr;
usehandler=1;
}

property()
{
usehandler=0;
}


void operator=(T value)
{
if(usehandler==0) ownvalue=value;
else handler->f_set(value);

}

T operator T()
{
if(usehandler==0) return ownvalue;
else return handler->f_get();
}


}

// Property Handler Interface
template<class T>
class prop_hndl
{
virtual void f_set(T value);
virtual T f_get();
}



// ---- Usage ----

// a class with property
class a
{
// Constructor
a()
{
// Initialize Property
px=new property<int>(new handler1);
}

// Handler Code
class handler1 : prop_hndl<int>
{
void f_set(int value)
{
// Do something funny
}

int f_get()
{
// Also do something funny
}
}

property<int> px;

}

int main()
{
a* x;

x=new a();

// access property
x->px=5;
int y=x->px;
}



Und nun gehts weiter mit dem üblichen... :P


[X] Spiele sind in dieser Frage repräsentativ.

Durchaus, da Spiele nunmal oft auf Performance ausgerichtet sind ;)
Dazu sind Spiele irre komplex, schau dir mal die Entwicklungszeiten an (und die gehen nicht nur für die Graphik drauf).


Dann doch lieber ein simples Schlüsselwort "Property". Warum umständlich wenn's auch einfach geht.
guck dir den Usage Teil an, der ist ganz einfach ;)


R-Stab ist sowas wie der Branchenführer und wurde in C++ geschrieben. Wenn COBEAM (so heißt unser Projekt) bei gleichen Sachen ungefähr genauso schnell ist wie R-Stab, gibt's dafür 2 mögliche Erklärungen:
1) R-Stab ist beschissen geschrieben. Dann wäre es aber wahrscheinlich kein Branchenführer.
2) Auch VB-Programme können schnell sein.

Das ist schwachsinn! Schau dir mal die Progg-Wettbewerbe an (warum machst du da eigentlich nicht mal mit VB mit? Du hättest keine Chance ein halbwegs schnelles Programm abzuliefern).
Ich hab inzwischen 7 Primzahlalgs geschrieben - viele implementieren fast den selben Algorithmus, aber trotzdem sind die letzten mit Abstand die schnellsten.

Also bei sowas komplexen kannst du nicht einfach 1:1 vergleichen - die Algorithmen sind doch völlig verschieden!


Wenn hier immer von "möglichst schnell" zu lesen ist: warum ist denn das so wichtig. Das mag in kleinen Anwendungsbereichen vielleicht wichtig sein (3D Gaming, bzw das ganze Multimedia Geschäft, Rendering und Simulationen). Sind das nicht aber die unwichtigsten Programme die es gibt? Viel wichtiger sind doch heute all die kleinen (oder auch größeren) Programme, ohne die sich heute kein Fön mehr bewegt. Ich meine Computer in Industrieanlagen (Robotor, Prozessüberwachung,...), Energieanlagen (Kraftwerke), Endprodukten (Autos, Flugzeuge, ..., Multimediageräte, Medizintechnik),.... dort ist die Geschwindigkeit nur ein geringfügiger Entscheidungsfaktor, das was dort zählt ist fehlerfreie Funktion, weil dort ein BlueScreen eben sehr teuer werden kann (Ich sag nur viel Spaß bei der AugenOP, bei der der Computer ausfällt ). Und ich denke, dass ich nicht falsch liege, wenn ich behaupte, dass dieser Computersektor den weit grßeren Marktanteil hat. Die Argumentation mit der Performance halte ich daher für sehr unnötig.

Das trifft auch für zb. den Linux Kernel zu, und so ziemlich alle wissenschaftlichen Projekte. Was denkst du, was die Leute gerade bei Mozilla machen?!? Auf Speed optimieren!
Also 3GHz Boliden sind kein ersatz für optimierte Programme, wegen der Einstellung sind 3GHz Boliden auch nur notwending geworden.

Wenn ich mir das OS/2 Warp3 in meinem Schrank anschaue, was auf einem 486er absolut flüssig läuft - das ist ein schnelles OS. Und sowas braucht auch keine 3GHz Rechner.

VB ist gelinde gesagt extrem langsam - @Tiku: Für den M1 (1. Primzahlalg) ist der Source noch ziemlich einfach, programmier den doch einfach mal nach! Du wirst sehen wie schnell VB da ist...

TiKu
21.06.2004, 19:14
Original geschrieben von intel_hasser
warum machst du da eigentlich nicht mal mit VB mit?Keine Zeit und nicht wirklich Lust. Ich progge lieber Desktop-Anwendungen als irgendwelche eigenständigen Algorithmen, die für mich keinen Nutzen haben, weil ich sie in meinen aktuellen Projekten nicht brauche.

i_hasser
21.06.2004, 19:19
Original geschrieben von TiKu
Keine Zeit und nicht wirklich Lust. Ich progge lieber Desktop-Anwendungen als irgendwelche eigenständigen Algorithmen, die für mich keinen Nutzen haben, weil ich sie in meinen aktuellen Projekten nicht brauche.

Und weil du mit VB einfach keine Chance hättest ;).

Hab ich beim Fibonacci Projekt gemerkt, da hab ich anfangs spaßeshalber mal mit VB mitgemacht. Hab zwar die glückliche Optimierung gefunden, aber die C++ Version war dann doch um Längen schneller, dabei bestand die Hauptschleife daraus:

for(i=2;i<n;i++)
{
a2=a1;
a1=a0;
a0=a1+a2;
}

Und da kommt nix mit Strings vor ;). C++ (und zwar genau gensagt der langsame DJGPP Compiler für DOS) war afair 10mal so schnell :o

Glaub mir, du würdest mit VB keinen Blumentopf gewinnen. Vielleicht implementiere ich mal den ersten Primzahlalgorithmus in VB - die späteren Versionen gehen ja sowieso nicht, weil VB bei Bitschiebeoperationen zu 100% nicht mit C++ mithalten kann.

TiKu
21.06.2004, 19:21
Original geschrieben von intel_hasser
Und weil du mit VB einfach keine Chance hättest ;).Kann ich nicht beurteilen, hab's ja noch nicht probiert.;)

i_hasser
21.06.2004, 19:24
Ich hab es probiert (Fibonacci - an die "einfache" Berechnung schloss sich auch noch eine kleine Lib für große Zahlen an) und C++ war einfach extrem viel schneller.

Ich hab jetzt keine Lust noch VS6 auf mein VMWare Windows zu ziehen, vielleicht hab ich heute Abend mehr Lust.

i_hasser
21.06.2004, 20:23
So, jetzt hab ich das auch mal mit Funktionszeigern realisiert. Von der Sache her sind die ja nicht unsauber, C++ erzwingt ja ein korrektes Type-Casting.

Im Code fehlen ein paar Prototypes usw. - auch nur schnell zusammengehackt.
Aber jetzt sieht die Lösung praktisch wie die Properties in Delphi oder VB aus - auch die Umsetzung in der entsprechenden Klasse.


// Property implementation
template<class T>
class property
{
T ownvalue;
int usehandler;

// function pointers
void (*prop_set)(T);
T (*prop_get)();

// set/get function as parameter
// (*f_set)(T value) would be more clear but longer ;)
property(void (*f_set)(T), T (*f_get)() )
{
usehandler=1;
prop_set=f_set;
prop_get=f_get;
}

property()
{
usehandler=0;
}


void operator=(T value)
{
if(usehandler==0) ownvalue=value;
else handler->(*prop_set)(value);

}

T operator T()
{
if(usehandler==0) return ownvalue;
else return handler->(*prop_get)();
}


}

// ---- Usage ----

// a class with property
class a
{
// Constructor
a()
{
// Initialize Property
px(px_set, px_get);
}

// Handler Code
void px_set(int value)
{
// Do something funny
}

int px_get()
{
// Also do something funny
}


property<int> px;

}

int main()
{
a* x;

x=new a();

// access property
x->px=5;
int y=x->px;
}

Hab auch einen Fehler korrigiert, den ich vorhin in der Eile reingesetzt hab. px muss natürlich anders initalisiert werden, da kein Zeiger.

i_hasser
21.06.2004, 21:03
So, jetzt kommt das absolut vernichtende Urteil. Hab den Primzahlalg mal implementiert ;D

Hier die VB Variante (nur der Alg selbst):



Function primem1(areaend As Long) As Long
Dim a() As Long
Dim i As Long
Dim searchval As Long
Dim cpos As Long
Dim primecount As Long
primecount = areaend

'// Create Primetab
ReDim a(areaend + 1) As Long
For i = 0 To areaend
a(i) = 1
Next i

searchval = 2

'// start filtering
While searchval < areaend ^ (0.5)

'// Eliminate all nx of searchval
For cpos = searchval * 2 To areaend Step searchval
If a(cpos) <> 0 Then
a(cpos) = 0
primecount = primecount - 1
End If
Next cpos

'// get next searchval
For cpos = searchval + 1 To areaend
If a(cpos) <> 0 Then Exit For
Next cpos

'// dirty method to leave - vb doesn't know break?
If cpos = areaend Then searchval = areaend
searchval = cpos

Wend

primem1 = primecount

End Function

War nach so langer Zeit auch mal interessant wieder VB Code zu schreiben :P

Also für alle Primes zwischen 0 und einer Millionen hat der Alg 1.5599 Sekunden gebraucht. Geht eigentlich.
Das ist ziemlich genau der Prime M1, inzwischen sind wir beim M7 - desswegen ist das oben auch extrem unoptimiert ;). Zum Alg selber sag ich nix, ist alles gut dokumentiert beim Primzahlwettbewerb.

Und hier die C Variante:


int primem1(int areaend)
{
int searchpos=2, curpos;
int primecount=areaend;

int i,j;

int *a;
a=malloc(sizeof(int)*areaend);
for(i=0;i<areaend;i++) a[i]=1;

while (searchpos<sqrt(areaend))
{
// filter nx of searchpos
for(curpos=searchpos*2;curpos<areaend;curpos+=searchpos)
{
if(a[curpos]!=0)
{
primecount--;
a[curpos]=0;
}
}

// get next searchpos
for(curpos=searchpos+1;curpos<areaend;curpos++)
{
if(a[curpos]!=0) break;
}
if(curpos==areaend) break;

searchpos=curpos;
}

return primecount;
}


Die Algorithmen stimmen genau überein (int in C ist auch 32bit). Und die selben Primzahlen liefern sie auch.

Der C Code hier braucht bei mir gerade mal 0.08 Sekunden - unoptimiert. Mit -O2 sind es 0.06 Sekunden, aber der Timer wird hier auch langsam ungenau.

Tja, 1.559 / 0.06 macht... 25.99

Fairerweise muss ich natürlich sagen, dass das unter VMWare getestet war. Desswegen hab ich die Geschichte auch mal unter Wine laufen lassen - immerhin war er 10mal so schnell (hab letztens mit Wine einen AMBiX86 Durchlauf gemacht, ist nicht wirklich langsamer als nativ).

Da waren es nur noch 0.18 Sekunden - immerhin. Damit ist C nur noch 3mal so schnell.
Allerdings ist der Alg auch denkbar günstig für VB - schaut euch mal den M6 oder gar den M7 an, da kommen so viele Bitschiebeops usw. vor, da fällt VB extrem weit zurück.
Ich glaub ich werd den C Code mal durch DJGPP jagen und beides auf einem Windooows Rechner testen.


PS Und ja - ich weis, dass der Code schweinisch aussieht. Hab beide Varianten in insgesammt 5 Minuten zusammengehackt *chatt*

TiKu
21.06.2004, 21:11
VB kann Break nur bei For- und Do-Schleifen. Also Do While...Loop nehmen.
/e: Ah, ich meine natürlich Exit Do und nicht Break.

If a(cpos) Then ist schneller als If a(cpos) <> 0 Then


If cpos = areaend Then searchval = areaend
searchval = cposDer Code ist Schmarrn. Ein simples searchval = cpos reicht.

i_hasser
21.06.2004, 21:20
So, jetzt hab ich die Tests fertig - hab mir einen inzwischen etwas altersschwachen P2-350MHz herausgesucht.

Die VB Version braucht 0.38 Sekunden, die DJGPP Version 0.16 Sekunden.

Ist denke ich ziemlich eindeutig. Dazu benutzt DJGPP eine ziemlich alte GCC Version, die neueren wären sicherlich schneller (auch ich hab nicht den aktuellsten GCC). Der Intel Compiler wäre sicherlich noch schneller.

Und wie gesagt, auf Binäroperationen usw. hab ich jetzt völlig verzichtet. Davon macht der M7 ziemlich stark gebrauch, da kommen auch mehrere Arrays zum Einsatz.

i_hasser
21.06.2004, 21:23
Original geschrieben von TiKu
VB kann Break nur bei For- und Do-Schleifen. Also Do While...Loop nehmen.

If a(cpos) Then ist schneller als If a(cpos) <> 0 Then


If cpos = areaend Then searchval = areaend
searchval = cposDer Code ist Schmarrn. Ein simples searchval = cpos reicht.

1. hab ich gesagt, dass ich für beide Varianten zusammen 5 Minuten gehackt hab und
2. schau dir mal den M7 an. Wenn du einen ähnlich schnellen Alg auf die Beine stellst (zum Vergleich: Der M7 braucht für alle Primzahlen bis 200 Millionen gerade mal 1.5 Sekunden) kannst du anfangen zu krittisieren ;). Und
3. ja, das ist nicht so ganz logisch ;)

Allerdings hab ich die If-Anweisung bei C genauso genommen.


PS: Für alles bis 20 Millionen braucht der Alg hier übrigens schon 1.9 Sekunden, die Zeit steigt also nicht linear (sonst klingen die 1.5 Sekunden für 200mio für den M7 etwas schlecht ;))

mtb][sledgehammer
21.06.2004, 23:23
Ich glaube keiner bezweifelt hier eigentlich, dass C++ unglaublich schnell ist und man auch soviel machen kann wie man will. Ich habe auch nie C++ kritisiert; für seinen Anwendungsbereich, was meist zeitkritische Anwendungen sind, wo Performance zählt ist es mit Sicherheit das Optimale. Wenn am Ende am Tikus Brücken einstürzen ist das für sein Programm ein viel entscheidenderes Kriterium, als ob die Brücke 5 Minutn schneller berechnet ist. Ebenso ist in seinem Fall ein perfektes GUI viel wichtiger, da das Arbeitszeit des Ingenieur erspart, in diesem Fall nicht ein paar Minuten Rechnzeit. Was für diese Anwendung besser geeignet ist, das kann ich nicht sagen. Aber nochmal ein Wort zur Performance: auch wenn ein Programm die doppelte Rechenzeit benötigt, ist das bei kritischen Anwendungen doch so egal, dann nimmt man einfach die doppelt so schnelle CPU, dort ist der Preis egal. So ganz nebenbei, in Medizintechnik (z.B. Chirurgische Robotor) ist ein redundantes System nicht unwahrscheinlich, bei dem die beiden Systeme möglichst nicht identisch sind.

Deine Beantwortung meiner Frage, warum "Properties sind was feines für den unsauberen Programmierer - mehr nicht." bist du mir aber immernoch schuldig, stattdessen bist du darin geflüchtet, das Terminalsymbol "property" zu emulieren (ich habs zwar noch nicht ganz verstanden, weil ih kein C++ Hacker bin, aber ich nehms dir mal ab das es tut).

TiKu
21.06.2004, 23:49
Original geschrieben von mtb][sledgehammer
Wenn am Ende am Tikus Brücken einstürzen ist das für sein Programm ein viel entscheidenderes Kriterium, als ob die Brücke 5 Minutn schneller berechnet ist. Ebenso ist in seinem Fall ein perfektes GUI viel wichtiger, da das Arbeitszeit des Ingenieur erspart, in diesem Fall nicht ein paar Minuten Rechnzeit. Was für diese Anwendung besser geeignet ist, das kann ich nicht sagen.Die Frage ist schnell beantwortet bzw. stellt sich gar nicht erst: Mein Chef kann bloß VB.;D Und alles alleinmachen kann ich auch nicht, weil dazu erhebliches Fachwissen im Bereich Brückenbau nötig ist. Bereut haben wir die Entscheidung bisher nicht.
Wie Du schon sagtest, ist die GUI bei so einem Programm sehr wichtig. Und da können wir mit VB auf einen Riesenfundus an ActiveX-Controls zurückgreifen. Mit C++ läuft nicht jedes ActiveX-Control, außerdem sind C++ und ActiveX nicht die besten Freunde (Controls in C++ schreiben geht gut, aber Controls in C++ nutzen ist etwas umständlich).
Ich habe spaßeshalber immer mal wieder das Web abgegrast nach C++-GUI-Komponenten, die die selbe Funktionalität haben. Ergebnis: Wir hätten wohl viele Sachen selbst schreiben müssen und wären dadurch wohl bei weitem nicht so weit mit dem Programm wie wir es jetzt sind.

Ach ja, kurze Info was das Programm eigentlich macht: Man gibt einen Brückenquerschnitt ein, die verwendeten Materialien, die Abfolge der Bauabschnitte (wann wurde welcher Abschnitt mit welchem Beton betoniert und die wievielte Schicht ist das usw.), die Umweltdaten während des Baus und danach, die Belastungen usw. Die Software berechnet dann an welcher Stelle wann welche Kräfte auftreten und ob diese Kräfte kritisch werden usw.
An richtig komplexen Brücken können da schonmal 9 Tage Rechenzeit rauskommen. Ob man bei solchen Zeitrahmen 2 Stunden länger rechnet als R-Stab, ist ziemlich egal (sowas zählt als gleich schnell). Wichtig sind die Features und das Handling.

Und das Beste: Die Entwicklungskosten sind bei uns sehr gering (dank RAD kurze Entwicklungszeit, fast keine kommerzielle Komponenten und als studentische Hilfskraft koste ich deutlich weniger.:P).

Naja, Back2Topic.*chatt*

i_hasser
22.06.2004, 12:42
Naja, Oberflächen sind so eine Sache... so ziemlich alles in Linux ist mit C/++ geschrieben, auch die Oberflächen. Und die sind bei den ausgefeilteren Programmen extrem viel intuitiver als in der Windows Welt.

Also es kommt auf das OS an. Und für QT und GTK gibt es auch gute Oberflächendesinger, die dir fertigen Code ausspucken - zb. den Glade Interface Desinger (der kann auch noch Gnome Komponenten nebst GTK) und den Qt Desinger.

Ob es für Windows einen Oberflächendesinger gibt weis ich nicht, ist mir aber ehrlich gesagt auch herzlichst egal ;). Das C++ in Visual Studio ist eh so eine Sache... nicht umsonst gibt es einen eingeschworenen Kreis der VisualStudio Hasser ;D


Ach ja, und Geschwindigkeitstechnisch ist ein gutes C++ Programm deutlich schneller (sprich 1/2 oder 1/3) als ein VB Programm. Siehe den Primzahlalgorithmus, heute werd ich vielleicht mal den M6 implementieren.
Und dabei ist gerade das noch ziemlich einfacher Code, bei Klassenverwaltung etc. wird es dann deutlich schwieriger.

mtb][sledgehammer
22.06.2004, 15:48
@ intel_hasser
Und wieder einmal hast du meine Frage nicht beantwortet.

i_hasser
22.06.2004, 16:10
Original geschrieben von mtb][sledgehammer
Ich glaube keiner bezweifelt hier eigentlich, dass C++ unglaublich schnell ist und man auch soviel machen kann wie man will.

Jepp, allerdings kommt das nicht nur durch die Sprachstrukturierung, sondern auch durch die Verbreitung. Der Vergleich von den verschiedenen Compilern zeigt deutlich, dass auch C/++ alleine nicht schnell sein muss.


Ich habe auch nie C++ kritisiert; für seinen Anwendungsbereich, was meist zeitkritische Anwendungen sind, wo Performance zählt ist es mit Sicherheit das Optimale.
Und da fängt es an. C++ ist nicht nur für zeitkrittische Sachen gut, sondern dank der Mächtigkeit der Sprache auch für extrem komplexe Algorithmen (imho).
Das ist es ja gerade, in Delphi hat man seine eingebauten Features mit denen man viele gute Sachen machen kann, aber wenn was fehlt dann fehlts eben.
C++ selbst liefert so ziemlich garkeine fest eingebauten Elemente (zb. nur short int, long int, long long int, char, float, double und long double bei den Variablen). Alles weitere ist in der Sprache selbst realisiert - den Source für die String Klasse, oder für die Vektor Klasse findest du zb. in der C-Library. Alles einfacher C++ Code.



Wenn am Ende am Tikus Brücken einstürzen ist das für sein Programm ein viel entscheidenderes Kriterium, als ob die Brücke 5 Minutn schneller berechnet ist.
Dann wäre der Alg fehlerhaft und ein C++ Programm hätte ebenso einstürzende Brücken simuliert ;).
Und wir reden nicht von 5 Minuten, sondern von Faktoren - 2 bis 10. Und 5 Tage oder 2 Tage sind schon ein ziemlich enormer Unterschied.


Ebenso ist in seinem Fall ein perfektes GUI viel wichtiger, da das Arbeitszeit des Ingenieur erspart, in diesem Fall nicht ein paar Minuten Rechnzeit.
Da hab ich ja schon geantwortet, C++ bedeutet nicht gleich schlechte GUI. Ok, mit Windows GUIs hab ich mich noch nicht so beschäftigt, da weis ich nicht wie es ist. Aber ich weis, dass zb. Qt und GTK Möglichkeiten für enorm leistungsfähige und elegante GUIs liefern - und idR nimmt man dazu C++ (überhaupt glaube ich inzwischen, dass 95% der Linux bezogenen Sources C/++ sind).


Was für diese Anwendung besser geeignet ist, das kann ich nicht sagen. Aber nochmal ein Wort zur Performance: auch wenn ein Programm die doppelte Rechenzeit benötigt, ist das bei kritischen Anwendungen doch so egal, dann nimmt man einfach die doppelt so schnelle CPU, dort ist der Preis egal.
Desswegen kann sich VB nicht bei wissenschaftlichen Sachen und/oder bei Spielen durchsetzen.
Ich frag mich was ihr wollt, die Verbreitung spricht doch eindeutig für mich - und Tiku hat ja auch schon gesagt, dass er VB unter anderem desswegen nimmt, weil sein Chef nix anderes kann.


So ganz nebenbei, in Medizintechnik (z.B. Chirurgische Robotor) ist ein redundantes System nicht unwahrscheinlich, bei dem die beiden Systeme möglichst nicht identisch sind.
Mag ja sein, aber was hat das mit VB/C++ zu tun? Wenn du damit die Fehlerbehandlung in C++ ansprechen willst - die ist genauso gut (wenn nicht besser) als die von VB. Ich schreib schon nicht umsonst manchmal nur C, manchmal C++ und manchmal C/++. Beide Sprachen kann man mixen (malloc ist zb. C, new... ist C++ - beides kann man in einem Progamm benutzen) aber wenn man reines C++ benutzt ist das absolut sicher. C Programme (übrigens ist der Linux Kernel und solche Sachen die des öfteren Sicherheitslücken aufweisen) nicht in C++ sondern in C geschrieben. Liegt aber daran, dass man für C++ wesentlich mehr Grundvorraussetzungen braucht (zb. einen definitiv funktionierenden Speichermanager).


Deine Beantwortung meiner Frage, warum "Properties sind was feines für den unsauberen Programmierer - mehr nicht." bist du mir aber immernoch schuldig
Das ist meine persönliche Ansicht. Warum Properties wenn man sowas genauso sauber mit Funktionen ausdrücken kann? Klar, Properties können auch sehr nützlich sein (war vielleicht etwas hart formuliert). Ich implementiere eine Konfiguration nur idR völlig anders, so dass Properties ziemlich unnötig werden (eine Klasse, darein alle Parameter und durch eine Config-Funktion übergibt man der eigentliche Klasse die Config Klasse).

Ich finde Properties haben auch das Problem, dass die Auswirkungen nicht so deutlich sichtbar sind - wenn ich die Config Funktion einer Klasse aufrufe wird sofort klar, dass unten drunter so einiges passiert. Mit einem Property spiele ich womöglich wie mit einer Variable rum, und auf einmal hab ich den Salat, weil irgendwelche Abhängigkeiten oder weis der Geier was nicht erfüllt sind.
Besonders übel aufstoßen kann sowas bei deaktivierbaren Steuerelementen (um mal Steuerelemente allgemein als Beispiel zu nehmen).
Ich hantiere mit einem Property ziemlich aktiv rum und irgendwoanders (womöglich sogar ein anderer Thread) deaktiviert das Steuerelement.

Sofort bekomme ich ziemlich undurchsichtige Fehler rein.


, stattdessen bist du darin geflüchtet, das Terminalsymbol "property" zu emulieren (ich habs zwar noch nicht ganz verstanden, weil ih kein C++ Hacker bin, aber ich nehms dir mal ab das es tut).

Was meinst du mit Terminalsymbol? Ich hab das Property nicht emuliert, sondern implementiert - in C++ implementiert man solche Sachen mit der Sprache selbst, bei Delphi oder VB wird vieles in den Compiler implementiert.
Das ist der große Unterschied und das macht C++ eben so leistungsfähig. Das von mir ausgedachte Property ist nicht langsamer als die Delphi Implementierung, weil es der Delphi Compiler im Endeffekt ähnlich implementiert (nur hast du darauf keinen Einfluss).

Da liegt auch wieder ein Vorteil weil C/++ so schnell ist. Würde ich sowas in VB Implementieren (ginge vielleicht auch) wäre es auf jeden Fall langsamer als wenn es der Compiler implementiert. Die Sachen die man in C/++ per Code dazuimplementiert sind aber so schnell wie bei anderen Sprachen Dinge, die im Compiler integriert sind.

Schau dir doch mal die C/++-Lib an - die ist in C/++ geschrieben. Ich bezweifle, dass die Standard-Lib von VB in VB, oder die von Delphi in Delphi geschrieben ist.

TiKu
22.06.2004, 19:33
Wenn C++ so gut ist, warum hat es dann Visual Basic in den 90ern geschafft, eine Zeit lang in Nordamerika die am meisten genutzte Sprache zu sein, wo sie doch auch noch erheblich jünger ist als C++? Das war meines Wissens wohlgemerkt VB3 oder VB4, da gab es noch nicht mal einen Native Compiler. VB war damals also wirklich langsam und die Rechner hatten noch keine 3 GHz mit 1 GB DDR400-RAM.;)

Desweiteren ist es ein wenig unfair, VB mit C++ zu vergleichen, wenn man den icc oder gcc als Referenz nimmt. Von VB gibt's exakt 1 Compiler. Der ist von MS, nicht sonderlich gut und bietet exakt 2 Optimierungseinstellungen: 1x auf Größe und 1x auf Geschwindigkeit.*buck* Selbst der MS C++-Compiler bietet zig Optimierungsmöglichkeiten, darunter inzwischen auch SSE2. Dazu kommt, dass der letzte VB-Compiler inzwischen 6 Jahre auf dem Buckel hat.
Wennschon muss man vergleichbar gute Compiler heranziehen, um Aussagen über die Sprachen treffen zu können. Aber selbst der MS C++-Compiler ist ne ganze Ecke besser als der VB-Compiler. Und trotzdem schafft's VB, mit C++-Programmen größtenteils mitzuhalten. Da kann die Sprache also nicht vom Design her schon so langsam sein wie Du sie siehst.

Schau Dir mal Powerbasic an. Die Sprache ist VB ziemlich ähnlich und der Compiler spuckt Binaries aus, die extrem klein sind und performancetechnisch auch gerne mal C++-Pendants ausstechen.

Ja, mit C++ kann man so ziemlich alles machen. Aber es gibt Bereiche, für die sich andere Sprachen sehr viel besser eignen. Bei der Objektorientierung ist das IMHO C#, bei Anwendungen mit Datenbankanbindung sind das VB und Delphi und in der Logikprogrammierung sind das Prolog, Lisp, Haskell und Konsorten.
Niemand, der bei klarem Verstand ist, nutzt für ein Datenbankprojekt wie eine Hotelverwaltung C++, wenn er auch VB oder Delphi nehmen könnte. Niemand wird auf die Idee kommen, Lodikprogrammierung mit C++ zu betreiben.
Nicht weil es in C++ nicht möglich wäre, sondern weil C++ für sowas viel zu sehr low-level ist. Man hätte viel zu viel Arbeit mit dem ganzen Drumherum.
Oder schreibe mal ein ActiveX-Control mit VB und dann mit C++ (mit exakt gleicher Funktionalität). Mit C++ wirst Du sehr viel länger brauchen und sehr viel mehr tippen. Der einzige Grund für die weiter oben in diesem Thread angesprochene Portierung eines großen ActiveX-Controls, die ich momentan betreibe, ist, dass VB6 nicht mehr weiterentwickelt wird.
Sprache und Compiler sollten dem Programmierer möglichst viel abnehmen, aber dennoch viele Möglichkeiten bieten. C++ schafft IMHO nur das letztere, VB und Delphi erfüllen das 2. zwar nicht zu 100%, aber dafür das 1.



und Tiku hat ja auch schon gesagt, dass er VB unter anderem desswegen nimmt, weil sein Chef nix anderes kann.Das hast Du übrigens scheinbar etwas falsch verstanden: Dadurch, dass mein Chef nix anderes kann, hat sich die Frage nach der Sprache nicht erst gestellt. Das heißt noch lange nicht, dass wir C++ genommen hätten, wenn Chefele es könnte.
Gut möglich, dass wir in C++ angefangen und nach 6 Monaten in VB neu angefangen hätten, weil wir keine wirklich brauchbaren GUI-Komponenten gefunden hätten. Bspw. ist ein Kern-Steuerelement ein Grid-Control, also ein Tabellensteuerelement, dass von der Funktionalität her mit Excel mithalten kann. Für VB haben wir innerhalb 1 Woche so ein Control gefunden, welches sich auch noch leicht handhaben lässt. Das Beste: Wir konnten sogar zwischen insgesamt 4 solchen Controls wählen. Ich habe spaßeshalber immer mal wieder so eine Komponente für C++ gesucht. Auch heute, 18 Monate später, habe ich noch nichts gefunden was unseren Ansprüchen genügen würde.

i_hasser
22.06.2004, 20:20
Original geschrieben von TiKu
Wenn C++ so gut ist, warum hat es dann Visual Basic in den 90ern geschafft, eine Zeit lang in Nordamerika die am meisten genutzte Sprache zu sein, wo sie doch auch noch erheblich jünger ist als C++? Das war meines Wissens wohlgemerkt VB3 oder VB4, da gab es noch nicht mal einen Native Compiler. VB war damals also wirklich langsam und die Rechner hatten noch keine 3 GHz mit 1 GB DDR400-RAM.;)

Quelle?
Wer wurde dabei mit einbezogen? Die OpenSource Progger in den USA bestimmt nicht, oder?
Traue nie einer Statistik, die du nicht selbst gefälscht hast ;)


Desweiteren ist es ein wenig unfair, VB mit C++ zu vergleichen, wenn man den icc oder gcc als Referenz nimmt. Von VB gibt's exakt 1 Compiler. Der ist von MS, nicht sonderlich gut und bietet exakt 2 Optimierungseinstellungen: 1x auf Größe und 1x auf Geschwindigkeit.*buck* Selbst der MS C++-Compiler bietet zig Optimierungsmöglichkeiten, darunter inzwischen auch SSE2. Dazu kommt, dass der letzte VB-Compiler inzwischen 6 Jahre auf dem Buckel hat.
Wennschon muss man vergleichbar gute Compiler heranziehen, um Aussagen über die Sprachen treffen zu können. Aber selbst der MS C++-Compiler ist ne ganze Ecke besser als der VB-Compiler. Und trotzdem schafft's VB, mit C++-Programmen größtenteils mitzuhalten. Da kann die Sprache also nicht vom Design her schon so langsam sein wie Du sie siehst.

Find ich nicht. Klar könnte man theoretisch einen VB Compiler schreiben, der jeden C Compiler kilometerweit hintersich lässt.
Anders herum geht es aber auch, und es geht nunmal darum, was die IDE/Sprache aktuell leistet! Und bei der Performance leistet VB nicht viel ;)
Mag sein, dass das am alten Compiler liegt (ist sogar fast sicher, von den Strukturen her ist VB nicht prinzipiell langsamer als C/++), aber wenn es eben keinen neuen Compiler gibt...



Schau Dir mal Powerbasic an. Die Sprache ist VB ziemlich ähnlich und der Compiler spuckt Binaries aus, die extrem klein sind und performancetechnisch auch gerne mal C++-Pendants ausstechen.
Ja, womit wurden die C++ Pendants compiliert? Den Gcc oder noch besser den Intel Compiler schafft PowerBasic bestimmt nicht. Bestimmt nicht!
Das liegt auch einfach daran, dass zb. am gcc so extrem viele Leute optimieren...




Ja, mit C++ kann man so ziemlich alles machen. Aber es gibt Bereiche, für die sich andere Sprachen sehr viel besser eignen. Bei der Objektorientierung ist das IMHO C#, bei Anwendungen mit Datenbankanbindung sind das VB und Delphi und in der Logikprogrammierung sind das Prolog, Lisp, Haskell und Konsorten.
Niemand, der bei klarem Verstand ist, nutzt für ein Datenbankprojekt wie eine Hotelverwaltung C++, wenn er auch VB oder Delphi nehmen könnte. Niemand wird auf die Idee kommen, Lodikprogrammierung mit C++ zu betreiben.
Wieso denn das nicht?!? Erklär mir das mal bitte.
In anderen OSs gibts extrem viele Programme die du nicht in C++ schreiben würdest, aber die nunmal doch in C++ realisiert sind! In Windoows genauso. Du würdest vielleicht nicht auf die Idee kommen C++ zu benutzen ;)



Nicht weil es in C++ nicht möglich wäre, sondern weil C++ für sowas viel zu sehr low-level ist.
Zum Hunderdtausendsden mal - C++ IST NICHT LOW LEVEL!
C ist Low Level, aber C++ nicht!

Wie oft soll ich das noch sagen?!?

C und C++ ist eine ideale Mischung. Die Sprache C++ selbst bietet ziemlich wenig - eigentlich nur Verwaltungsstrukturen wie Klassen etc. ansonsten nix. Der Rest ist von der Sache her C.
Die ganzen Dinge die wir in C++ kennen sind teilweise in C implementiert und bieten ein C++ Interface, teilweise bauen sie auf anderen C++ Sachen auf, die in C realisiert worden.

Beispiele dafür sind zb. Strings und Vektoren, oder OS speziefische Funktionen.
C++ bietet dir die Möglichkeit komplexe Sachen aufzubauen - die eben nicht LowLevel sind!
Schau dir mal cout an - das ist auch nur eine C++ Funktion die per C/++ implementiert wurde. Du hast bei C/++ die Entscheidung, ob du die LowLevel Funktionen benutzen willst, oder ob du lieber HighLevel Funktionen benutzt - die HighLevel Funktionen sind dann in irgend einem Paket was du nutzt in C/++ implementiert.

Zeig mir irgend einen Code den du für HighLevel hälst und ich zeig dir dazu was in C++, was genauso HighLevel ist! Und wenn du noch einmal sagst, dass C++ nicht HighLevel ist schreib ich nix mehr ;)


Man hätte viel zu viel Arbeit mit dem ganzen Drumherum.
Tja, das denkt man, wenn man die fertigen HighLevel Funktionen nicht kennt.


Oder schreibe mal ein ActiveX-Control mit VB und dann mit C++ (mit exakt gleicher Funktionalität). Mit C++ wirst Du sehr viel länger brauchen und sehr viel mehr tippen.
Ja, wenn ich die komplette API selbst implementiere weil ich unwillens bin die vorgefertigten APIs zu benutzen...

Und was du als VB Programmierer nicht merkst ist, wieviel Code da vor dir versteckt wird. Eine Form ohne Code gibts nicht! Du brauchst immer einen Batzen Code um zb. eine Form zu erzeugen.
Bei vielen C++ IDEs siehst du den Code, aber der wird automatisch erzeugt (zb. auch bei VC++) - wenn du das als Code anrechnest tuts mir herzlich leid für dich...


Der einzige Grund für die weiter oben in diesem Thread angesprochene Portierung eines großen ActiveX-Controls, die ich momentan betreibe, ist, dass VB6 nicht mehr weiterentwickelt wird.
Sprache und Compiler sollten dem Programmierer möglichst viel abnehmen, aber dennoch viele Möglichkeiten bieten. C++ schafft IMHO nur das letztere, VB und Delphi erfüllen das 2. zwar nicht zu 100%, aber dafür das 1.
Tja, das ist typisches Windows-Denken. Klar klingt das jetzt wieder klischeehaft (eben die typischen Linuxer) - aber es ist wirklich so!

Mensch ich war doch fürher auch begeisterter Basic Progger. Und ich hab mich damals auch mit anderen Leuten gefetzt die meinten C++ sei der Stein der Weisen (damals konnte ich C++ auch nicht wirklich).
Ich hab mich erst mit C, dann mit C++ auseinandergesetzt - und inzwischen hab ich meine Meinung geändert.

Eine Sprache sollte dir nicht so viel abnehmen wie möglich, sondern Raum schaffen, damit andere Leute diese Möglichkeiten in der Sprache selbst implementieren können. Genau das kannst du mit C++ machen! Und nicht nur auf Low-Level sondern auch auf High-Level!
Das ist ja gerade das perfekte daran. Beispiel Vektor: Ich brauche ein dynamisches Array. Also überleg ich mir - nimmst du einen Vektor (C++) oder einen Zeiger mit malloc/realloc (C). Je nachdem ob ich das für Performance oder Struktur brauche entscheide ich mich entweder für die C Variante (ist eben deutlich schneller da wirklich LowLevel) oder für die C++ Variante (und nur mal so nebenbei: Was die C++ Vektoren an Funktionalität bieten hast du wender in Delphi, noch in VB - alles HighLevel realisiert).

In meinem C/++ Code den du bisher gesehen hast ging es ja stets um Performance, und da schreib ich natürlich so LowLevel wie es nur geht, weil einfach schneller.
Bei anderen Sachen (von denen ich nun mal nicht den Code gepostet hab) nehm ich aber auch die HighLevel Funktionen von C++. Und im Unterschied zu Delphi oder VB sind auch die HighLevel Funktionen teilweise LowLevel (C) und/oder HighLevel (C++) realisiert. Oft sind eben auch die performanteren Teile in C, der Rest C++.
Mich als Programmierer stört das aber nicht, weil es für mich keinen Unterschied macht ob der String nun in C oder C++ realisiert wurde - er funktioniert immer gleich und bietet mir immer die selben High Level Funktionen.



Das hast Du übrigens scheinbar etwas falsch verstanden: Dadurch, dass mein Chef nix anderes kann, hat sich die Frage nach der Sprache nicht erst gestellt. Das heißt noch lange nicht, dass wir C++ genommen hätten, wenn Chefele es könnte.
Gut möglich, dass wir in C++ angefangen und nach 6 Monaten in VB neu angefangen hätten, weil wir keine wirklich brauchbaren GUI-Komponenten gefunden hätten. Bspw. ist ein Kern-Steuerelement ein Grid-Control, also ein Tabellensteuerelement, dass von der Funktionalität her mit Excel mithalten kann. Für VB haben wir innerhalb 1 Woche so ein Control gefunden, welches sich auch noch leicht handhaben lässt. Das Beste: Wir konnten sogar zwischen insgesamt 4 solchen Controls wählen. Ich habe spaßeshalber immer mal wieder so eine Komponente für C++ gesucht. Auch heute, 18 Monate später, habe ich noch nichts gefunden was unseren Ansprüchen genügen würde.

Das betrifft aber explizit die Win32 Welt. Und ich wette, dass es irgendwo auch was vergleichbares für C++ gibt. Afair ist das doch eh alles als .ocx/.dll oder was auch immer realisiert, und das bekommst du doch mit jeder vernünftigen IDE zum Laufen.

TiKu
22.06.2004, 21:06
Original geschrieben von intel_hasser
Quelle?Ich notiere mir nicht bei jedem Satz, den ich irgendwo lese, die Quelle, um sie später in Diskussionen angeben zu können.;)

Ja, womit wurden die C++ Pendants compiliert? Den Gcc oder noch besser den Intel Compiler schafft PowerBasic bestimmt nicht. Bestimmt nicht!Quelle?;)

Wieso denn das nicht?!? Erklär mir das mal bitte.
In anderen OSs gibts extrem viele Programme die du nicht in C++ schreiben würdest, aber die nunmal doch in C++ realisiert sind! In Windoows genauso. Du würdest vielleicht nicht auf die Idee kommen C++ zu benutzen ;)Dass sie in C++ realisiert wurden, heißt nicht zwangsläufig, dass das eine gute Entscheidung war.

Zum Hunderdtausendsden mal - C++ IST NICHT LOW LEVEL!
C ist Low Level, aber C++ nicht!Pointer sind IMHO low level. Strings und Arrays, die ihre Größe nicht kennen, sind IMHO low level. Mag sein, dass es irgendeine Library gibt, die das kapselt. Aber das kommt dann eben nur durch die Library und nicht durch C++.

Tja, das denkt man, wenn man die fertigen HighLevel Funktionen nicht kennt.Du schmeißt Sprache und Libraries zusammen. Du stellst es so hin, als würde die STL zum Sprachumfang von C++ gehören. Sie ist aber nur eine Library. Bei VB zählst Du irgendeine SupiDupi-Library doch auch nicht gleich zur Sprache.

Ja, wenn ich die komplette API selbst implementiere weil ich unwillens bin die vorgefertigten APIs zu benutzen...Ich benutze für das Projekt die ATL, die Active Template Library. Die ist u. a. für solche Sachen entwickelt worden. Und selbst damit tippt man sich einen Wolf.
Hast Du eigentlich jemals in C++ ein ActiveX-Control geschrieben? Klingt für mich nicht unbedingt so.

Und was du als VB Programmierer nicht merkst ist, wieviel Code da vor dir versteckt wird. Eine Form ohne Code gibts nicht! Du brauchst immer einen Batzen Code um zb. eine Form zu erzeugen.
Bei vielen C++ IDEs siehst du den Code, aber der wird automatisch erzeugt (zb. auch bei VC++) - wenn du das als Code anrechnest tuts mir herzlich leid für dich...Mache ich nicht. Es ist auch so oft erheblich mehr Code.

Tja, das ist typisches Windows-Denken. Klar klingt das jetzt wieder klischeehaft (eben die typischen Linuxer) - aber es ist wirklich so!
(...)
Eine Sprache sollte dir nicht so viel abnehmen wie möglichVergiss mal Deine Hobbyprogrammierung und arbeite an einem Projekt mit Deadlines und begrenztem Budget.

Das ist ja gerade das perfekte daran. Beispiel Vektor: Ich brauche ein dynamisches Array. Also überleg ich mir - nimmst du einen Vektor (C++) oder einen Zeiger mit malloc/realloc (C). Je nachdem ob ich das für Performance oder Struktur brauche entscheide ich mich entweder für die C Variante (ist eben deutlich schneller da wirklich LowLevel) oder für die C++ Variante (und nur mal so nebenbei: Was die C++ Vektoren an Funktionalität bieten hast du wender in Delphi, noch in VB - alles HighLevel realisiert).Was hindert Dich daran, Dir in Delphi oder VB eine Klasse zu schreiben, die dasselbe kann? STL::vector ist doch auch nur eine Klasse. Aber Du zählst das ja schon zur Sprache dazu...

Mich als Programmierer stört das aber nicht, weil es für mich keinen Unterschied macht ob der String nun in C oder C++ realisiert wurde - er funktioniert immer gleich und bietet mir immer die selben High Level Funktionen.Mensch, endlich hast Du begriffen, dass es den Programmierer selten interessiert wie etwas intern gelöst wird.


Das betrifft aber explizit die Win32 Welt. Und ich wette, dass es irgendwo auch was vergleichbares für C++ gibt. Afair ist das doch eh alles als .ocx/.dll oder was auch immer realisiert, und das bekommst du doch mit jeder vernünftigen IDE zum Laufen. [ ] Du hast COM wenigstens ansatzweise verstanden.
Was hat die IDE damit zu tun???? ActiveX/COM heißt nicht, dass man in der IDE ein Control auf ein Fenster ziehen kann. Das geht nämlich auch ohne COM (s. MFC). COM beschreibt die Art und Weise wie man mit dem Steuerelement kommuniziert. Nämlich auf sehr abstrakte Art und Weise. Das hat zur Folge, dass COM-Objekte sehr vielfältig einsetzbar sind. Bspw. in irgendwelchen Dokumenten, in Webseiten (wo es aber nicht hingehört, weil die dafür nötigen Sicherheitsfeatures meistens fehlen)... COM gibt es auch für MacOS und für Unix (zu welchem Grad weiß ich nicht). Das .net-Framework basiert im Grunde auf COM. Die meisten Teile von Windows, MS Office, IE usw. sind über COM-Interfaces ansprechbar und dadurch sehr mächtig. Man kann MS Office über COM komplett fernsteuern und so bspw. dessen Rechtschreibprüfung nutzen, ohne irgendwelche Details darüber wissen zu müssen.
Man kann das komplette Windows-Dateisystem mit allem was dazu gehört über COM-Interfaces ansteuern. Der Windows-Explorer ist kein Dateibrowser, er ist de fakto ein COM-Browser. Man könnte eine Shell-Extension schreiben, deren Inhalt dreidimensional dargestellt wird, ohne etwas an Windows oder dem Explorer ändern zu müssen.
Das alles wird gerne übersehen, weil es nur für den Programmierer sichtbar ist. Da heißt es dann schnell mal Windows XP ist kaum anders als Windows 95. Aus Sicht eines Programmierers liegen da aber Welten dazwischen. Windows 95 war bis zum IE4 praktisch gar nicht über COM ansprechbar. Bei Windows XP kann man fast alles darüber ansprechen. Der Benutzer kommt das nur in Form von leistungsfähigeren Anwendungen mit.

Okay, wie COM funktioniert, weißt Du jetzt immernoch nicht und das war jetzt auch ziemlich OffTopic, aber ich hoffe Du hast jetzt mal einen Eindruck von COM bekommen. Zur Erinnerung: VB basiert auf COM. C++ bietet keine native COM-Unterstützung. Man muss in C++ also (von irgendwelchen Libraries abgesehen) immer from scratch anfangen. Und das ist verdammt aufwendig.

/e: Übrigens ist der von mir verwendete MS C++-Compiler schon vergleichsweise COM-freundlich. Es gibt da schon den ein oder anderen zusätzlichen Befehl, der die Nutzung von COM-Objekten erleichtert. Aber selbst damit ist es noch ein ziemlicher Krampf.

i_hasser
22.06.2004, 21:56
Original geschrieben von TiKu
Ich notiere mir nicht bei jedem Satz, den ich irgendwo lese, die Quelle, um sie später in Diskussionen angeben zu können.;)

Jaja komm, ist schon gut.


Quelle?;)
Ich verwette einen Kasten Wein/Bier oder was du sonst so gerne trinkst, dass die richtigen C/++ Compiler PowerBasic in die Tasche stecken.



Dass sie in C++ realisiert wurden, heißt nicht zwangsläufig, dass das eine gute Entscheidung war.

*lol*

*nachdenk*

*lol*

Ne also mal ehrlich. Das ist doch wohl nicht dein Ernst, oder? Es hat einen Grund, dass Delphi und VB bisher nicht bzw. praktisch nicht auf andere Plattformen portiert wurden.
Komm mal von deiner Win32 Welt los, es gibt auch noch andere Sachen.


Pointer sind IMHO low level. Strings und Arrays, die ihre Größe nicht kennen, sind IMHO low level.

Und damit hast du eben gezeigt, dass du von der Sprache C++ überhaupt keine Ahnung hast!
Vektoren kennen ihre Größe, und Pointer sind auch Objekte (nachträgliches EDIT: Strings kennen natürlich auch ihre Länge, wenn ich das jetzt richtig im Kopf hab (nehm die selten) einfach über String::length() ). Aber das ist anscheinend an dir vorbeigegangen, damit erübrigt sich jede Diskussion - ich kenne VB. Desswegen kann ich auch drüber Diskutieren. Ich kenne auch C++, desswegen kann ich mir ausmalen, wo die Schwächen liegen.
Du kennst nur VB und ziehst über C++ her ohne eine Ahnung davon zu haben!

Vektoren kennen ihre Größe, du kannst Elemente aus Vektoren einfach in der Mitte rauslöschen usw. - Vektoren sind übrigens allgemein die modernen C++ Arrays.


Mag sein, dass es irgendeine Library gibt, die das kapselt. Aber das kommt dann eben nur durch die Library und nicht durch C++.
Und du hast nicht verstanden, worum es bisher überhaupt gegangen ist. Warum hab ich mir eigentlich die Mühe gemacht und das alles geschrieben?!? Da steckt ARBEIT dahinter, und ich mach sowas ungerne für die Katz!

Das ist das Konzept von C++. Die Sprache sieht Strings, Vektoren usw. vor! Allerdings im Gegensatz zu Delphi, VB und weis der Geier was ist das in der Sprache selbst implementiert! Was denkst du, wozu es die ganzen C-Standards gibt?



Du schmeißt Sprache und Libraries zusammen. Du stellst es so hin, als würde die STL zum Sprachumfang von C++ gehören. Sie ist aber nur eine Library. Bei VB zählst Du irgendeine SupiDupi-Library doch auch nicht gleich zur Sprache.
*heul*

Doch, das ist ja das Konzept von C++ und das macht C++ auch viel leistungsfähiger als Delphi oder VB. GENAU DAS IST ES!
Was denkst du, wie das bei Linux abläuft?!? Da gibts die Bash, da gibt SysVInit, da gibts die "definition" zur SH (die die bash zb. implementiert) und so weiter und so fort. Alles das bildet GNU. Aber trotzdem sind das eigene Programme, die nicht zum OS gehören.

GNU ist wenn du so willst die "Oberfläche", Linux ist nur eine Implementierung. Genauso wie die Gnu C Lib nur eine Implementierung des C/C++ Standards ist (C++ nimmt btw. ne andere Lib).

Ich sag das mit der Windows-Ansicht die du hast doch nicht einfach nur daher, ich denke mir was dabei! Nach dem was du sagst existiert Linux nicht, bzw. ist es nur der Kernel. Von der Sache her ist das auch garnicht mal so falsch (nur von der Begriffsbildung!), aber wenn du dir zb. dein Suse anschaust hast du da GNU realisiert. Und die vielen variablen Teile bilden alle zusammen GNU - der Linux Kernel, die Bash, die Modutils, alles Netzwerkbezogene - zusammen ergibt das GNU. Die Einzelteile sind ziemlich unabhängig voneinander.
Bei Windows dagegen hast du ein "Programm" (das Windows OS), das die komplette Win32 API implementiert.
Und desswegen (uA) ist die Sache auch so starr.

Das selbe gilt für C++. Der Standard selbst schreibt nicht so extrem viel vor (zb. keine angewandten APIs afair), die Leistungsfähigkeit kommt dadurch, dass man die Sprache gleichwertig zu irgend einer festen Implementierung in einer anderen Sprache mit sich selbst erweitern kann!

Mir gehen bald die Vergleiche aus, das ist wie eine selbstlernende KI und ein intelligenter Algorithmus, der im Endeffekt aber nur das macht, was man ihm einprogrammiert.

Zu einem Linux basierten GNU OS gehören eben zb. auch die Startup Scripts. Das sind einfache SH Skripte (oder was für eine Shell man auch immer nehmen will), die aber eben zum OS dazugehören! Genauso die Strings und Vektoren in C++, das ist einfacher C/++ Code und trotzdem gehörts dazu! Und - noch ein allerletztes mal - DAS IST NICHT LOWLEVEL!

Du kannst die größe Eines Vektors abfragen, du kannst ein Element irgendwo im Vektor löschen (entsprechend wird der Vektor dann kleiner), du kannst mit Vektoren die tollsten Sachen machen. Natürlich gibts auch einen Überlaufschutz (den man afaik aber sinnigerweise auch entfernen kann, wenn das Prog steht und funktioniert frisst ein Überlaufschutz einfach zu viel Leistung... dem VB Compiler kannst du auch sagen, er soll die Array-Checks entfernen).



Ich benutze für das Projekt die ATL, die Active Template Library. Die ist u. a. für solche Sachen entwickelt worden. Und selbst damit tippt man sich einen Wolf.
Hast Du eigentlich jemals in C++ ein ActiveX-Control geschrieben? Klingt für mich nicht unbedingt so.
Nein, hab ich nicht - so wie du anscheinend noch nie ein richtige C++ Programm geschrieben hast.
Ich kann dir aber sagen wie es in der Linux Welt aussieht (und da hängt im Endeffekt wesentlich mehr dran als an der Windows Welt, weil Linux ziemlich vollständig POSSIX implementiert und man damit Zugang zu zb. so ziemlich allen was irgendwie UNIX ist hat - meine Programme kann ich praktisch ohne Änderung auf so ziemlich jedem UNIX kompilieren und auch auf so ziemlich jeder Plattform, ob nun x86, PPC, Sparc, MIPS...).


Vergiss mal Deine Hobbyprogrammierung und arbeite an einem Projekt mit Deadlines und begrenztem Budget.
Komm, sag jetzt ja nicht, du stempelt alle OpenSource Progger als Hobbyprogger ab 8-(

Dann wäre ich echt enttäuscht von dir...


Was hindert Dich daran, Dir in Delphi oder VB eine Klasse zu schreiben, die dasselbe kann? STL::vector ist doch auch nur eine Klasse. Aber Du zählst das ja schon zur Sprache dazu...
Tja, es gibt nunmal Dinge wie zb. Possix die sowas erfassen! Schnapp dir mal ein wirklich gutes C++ Buch und lies eine Weile, vielleicht änderst du deine Ansichten dann...

Klar kann man sowas auch in Delphi implementieren, aber da ist man deutlich eingeschränkter... wenn ich mir das recht überlege kann man das doch nicht in Delphi implementieren. Oder kennt Delphi Templates? vector<int> nutzt ein Template...


Mensch, endlich hast Du begriffen, dass es den Programmierer selten interessiert wie etwas intern gelöst wird.

Mich interessiert es aber sehr wohl, ob ich mir meine eigenen Interfaces schaffen kann die genauso elegant gekapselt sind, oder ob das nicht geht.
Und Delphi schränkt mich mindestens ein, und VB macht sowas fast unmöglich!


[ ] Du hast COM wenigstens ansatzweise verstanden.
Was hat die IDE damit zu tun???? ActiveX/COM heißt nicht, dass man in der IDE ein Control auf ein Fenster ziehen kann. Das geht nämlich auch ohne COM (s. MFC). COM beschreibt die Art und Weise wie man mit dem Steuerelement kommuniziert. Nämlich auf sehr abstrakte Art und Weise. Das hat zur Folge, dass COM-Objekte sehr vielfältig einsetzbar sind. Bspw. in irgendwelchen Dokumenten, in Webseiten (wo es aber nicht hingehört, weil die dafür nötigen Sicherheitsfeatures meistens fehlen)... COM gibt es auch für MacOS und für Unix (zu welchem Grad weiß ich nicht). Das .net-Framework basiert im Grunde auf COM. Die meisten Teile von Windows, MS Office, IE usw. sind über COM-Interfaces ansprechbar und dadurch sehr mächtig. Man kann MS Office über COM komplett fernsteuern und so bspw. dessen Rechtschreibprüfung nutzen, ohne irgendwelche Details darüber wissen zu müssen.
Man kann das komplette Windows-Dateisystem mit allem was dazu gehört über COM-Interfaces ansteuern. Der Windows-Explorer ist kein Dateibrowser, er ist de fakto ein COM-Browser. Man könnte eine Shell-Extension schreiben, deren Inhalt dreidimensional dargestellt wird, ohne etwas an Windows oder dem Explorer ändern zu müssen.
Das alles wird gerne übersehen, weil es nur für den Programmierer sichtbar ist. Da heißt es dann schnell mal Windows XP ist kaum anders als Windows 95. Aus Sicht eines Programmierers liegen da aber Welten dazwischen. Windows 95 war bis zum IE4 praktisch gar nicht über COM ansprechbar. Bei Windows XP kann man fast alles darüber ansprechen. Der Benutzer kommt das nur in Form von leistungsfähigeren Anwendungen mit.

Okay, wie COM funktioniert, weißt Du jetzt immernoch nicht und das war jetzt auch ziemlich OffTopic, aber ich hoffe Du hast jetzt mal einen Eindruck von COM bekommen. Zur Erinnerung: VB basiert auf COM. C++ bietet keine native COM-Unterstützung. Man muss in C++ also (von irgendwelchen Libraries abgesehen) immer from scratch anfangen. Und das ist verdammt aufwendig.

/e: Übrigens ist der von mir verwendete MS C++-Compiler schon vergleichsweise COM-freundlich. Es gibt da schon den ein oder anderen zusätzlichen Befehl, der die Nutzung von COM-Objekten erleichtert. Aber selbst damit ist es noch ein ziemlicher Krampf.

Tja, sowas gibt es unter Linux schon seit ewigkeiten. Die APIs sind nicht immer ganz einheitlich, aber gerade die Variablität die du ansprichst ist bei Linux in einem Grad realisiert, wo Windows nichtmal ansatzweise mitkommt.
Du befeierst da praktisch eine Sache die unter Linux längst Standard ist.

Aber wer weder C++ noch Linux wirklich kennt kann sich da natürlich kein Urteil drüber erlauben...


Also - nimm es mir nicht übel, aber du erfüllst gerade das typische Bild eines Basic-Verfechters.
Überspitzt formuliert von nix ne Ahnung und ist von allem beeindruckt was neu ist... auch wenn es woanders schon viel leistungsfähiger und weiter entwickelt seit längerer Zeit vorhanden ist.

Wie gesagt - überspitzt formuliert...

TiKu
22.06.2004, 22:34
Original geschrieben von intel_hasser
Komm mal von deiner Win32 Welt los, es gibt auch noch andere Sachen.Ja, aber die haben im von mir angepeilten Markt keinen Anteil von 90%.;)

Original geschrieben von intel_hasser
Vektoren kennen ihre GrößeUnd wieder schmeißt Du STL und C++ zusammen.

Original geschrieben von intel_hasser
Du kennst nur VB und ziehst über C++ her ohne eine Ahnung davon zu haben!Genauso kann ich Dir vorwerfen, dass Du nicht viel über VB weißt.

Original geschrieben von intel_hasser
Das ist das Konzept von C++. Die Sprache sieht Strings, Vektoren usw. vor! Allerdings im Gegensatz zu Delphi, VB und weis der Geier was ist das in der Sprache selbst implementiert! Was denkst du, wozu es die ganzen C-Standards gibt?Mir ist es egal, ob die Strings, die ich gerade verwende in VB, C++, ASM, Delphi, Haskell,... realisiert sind, solange sie sich so verhalten wie ich es erwarte.

Komm, sag jetzt ja nicht, du stempelt alle OpenSource Progger als Hobbyprogger ab 8-(Nein, das tue ich nicht. Ein OSS-Projekt hat aber den Vorteil, dass es selten irgendwie unter Druck arbeiten muss und somit die Wahl zwischen RAD-Tool und C++ relativ unwichtig ist. Außerdem haben die meisten OSS-Projekte das Ziel Platformunabhängigkeit. Da fallen VB und Delphi schonmal raus. Es gibt aber dennoch auch OSS-Projekte, die diese beiden Sprachen nutzen (Beispiele: VB: PDFCreator, Delphi: InnoSetup)

Fassen wir zusammen: C++ ist die einzige Sprache, alles andere ist Müll. VB ist so langsam, dass ein Hallo Welt den Earth Simulator braucht. Das einzige professionelle Einsatzgebiet sind Linux-Server. Jemand, der Linux nicht als Haupt-OS nutzt und vor allem in VB6 Win32-Anwendungen schreibt, kann keine Ahnung haben. Beim Programmieren zählt nicht die Entwicklungsdauer und der -aufwand, sondern nur die Geschwindigkeit des Programms. Interessanterweise nutzt Du trotzdem OO und nicht ASM. C++ hat nur Vorteile und VB und Delphi haben nur Nachteile.

Ich unterstelle Dir jetzt einfach mal, dass das daran liegt, dass Du inzwischen C++ nutzt und nicht zugeben kannst, dass etwas was Du selbst verwendest, auch Nachteile haben kann.

Für mich ist das Thema beendet, solche Ignoranz tu ich mir nicht länger an.

i_hasser
22.06.2004, 23:08
Da mir wirklich was dran liegt hier den Unterschied zwischen C und C++ zu zeigen hab ich mal was fertig gemacht:


#include <stdio.h>
#include <stdlib.h>

int main()
{
int i;

// Declare a String - as pointer/direct
char *str1="Hello World!";
char str2[]="Hello World!";

// Make an Array - as pointer/direct
int* a1=malloc(sizeof(int)*5);
int a2[5];

// Resize Array (only possible with pointer-array)
a1=realloc(a1, sizeof(int)*10);

// Get array size... it's impossible
printf("\na1: %ld", 10);
printf("\na2: %ld", 5);

for(i=0;i<10;i++) printf("\n%ld", a1[i]);
for(i=0;i<5;i++) printf("\n%ld", a2[i]);

return 0;
}



#include <stdio.h>
#include <stdlib.h>
#include <iostream>
#include <vector>

using namespace std;

int main(int argc, char *argv[])
{
int i;

// Declare a String - as pointer/direct
string* str1=new string("Hello World!");
string str2("Hello World");

// Make an Array - as pointer/direct
vector<int>* a1=new vector<int>(5);
vector<int> a2(5);

// Resize Array
a1->resize(10, 1); // make 5 new elements and init them to 1
a2.resize(10,1); // same thing

// Get Array Size
cout << endl << "a1: " << a1->size();
cout << endl << "a2: " << a2.size();

// Print arrays
// Für die Zeigervariante gibts sicher noch eine bessere Lösung,
// dummerweise weis ich die gerade net
for(i=0;i<a1->size();i++) cout << endl << (*a1)[i];
for(i=0;i<a2.size();i++) cout << endl << a2[i];

return 0;
}


Etwas Beispielcode, einmal in C, einmal in C++.

So, jetzt wieder zum "üblichen" Programm :P


Und wieder schmeißt Du STL und C++ zusammen.
Und du hast immer noch nicht begriffen wozu es Sachen wie Possix gibt. Und - Vektoren sind in der STL ;) (nur mal so nebenbei)

Nur, und das ist ja das entscheidende, die STL ist selber in C/++ geschrieben.



Genauso kann ich Dir vorwerfen, dass Du nicht viel über VB weißt.
Über VB6 weis ich eine ganze Menge, hab schließlich genug und viel damit geproggt.


Mir ist es egal, ob die Strings, die ich gerade verwende in VB, C++, ASM, Delphi, Haskell,... realisiert sind, solange sie sich so verhalten wie ich es erwarte.

Das mag ja sein, aber dadurch wird doch die Leistungsfähigkeit der Sprache deutlich, worum es mir eigentlich die ganze Zeit lang geht!
In Delphi kannst du die STL nicht in Delphi schreiben ohne die STL zu nutzen, in VB noch weniger.
In C/++ geht das!
Ich kann dir gerne einen Link zur GNU C-Lib bzw. C++-Lib (also die STLs) geben, der Source ist in C/C++ abgefasst. Tja, also entweder erzeugst du damit rekursiven Code (was ja nicht ginge), oder C/C++ ist einfach so leistungsfähig, dass man die STLs eben in der Sprache selbe implementieren kann.
Und solche Dinge wie POSSIX werden über die STL realisiert. Und POSSIX ist keine STL ;)


Fassen wir zusammen: C++ ist die einzige Sprache, alles andere ist Müll. VB ist so langsam, dass ein Hallo Welt den Earth Simulator braucht. Das einzige professionelle Einsatzgebiet sind Linux-Server. Jemand, der Linux nicht als Haupt-OS nutzt und vor allem in VB6 Win32-Anwendungen schreibt, kann keine Ahnung haben. Beim Programmieren zählt nicht die Entwicklungsdauer und der -aufwand, sondern nur die Geschwindigkeit des Programms. Interessanterweise nutzt Du trotzdem OO und nicht ASM. C++ hat nur Vorteile und VB und Delphi haben nur Nachteile.

Ich unterstelle Dir jetzt einfach mal, dass das daran liegt, dass Du inzwischen C++ nutzt und nicht zugeben kannst, dass etwas was Du selbst verwendest, auch Nachteile haben kann.

Und ich unterstelle dir jetzt einfach, dass dir der nötige Sachverstand zu C++ fehlt. Es gibt tatsächlich nur extrem wenige Sachen (-> ich kenn keine) die sich in C++ nicht so elegant wie in zb. Delphi implementieren lassen.
Aber natürlich kannst du eine Sprache nicht mit einer IDE vergleichen, und desswegen musst du fairerweise schon zb. den C++ Builder gegen Delphi antreten lassen. Und der C++ Builder ist auch auf ähnlich schnelle Lösungen wie Delphi fixiert. Und der C++ Builder nimmt dir auch wie Delphi viele Sachen ab.

Die Stärken vom GCC liegen dagegen wieder woanders, aber das hat eben wenig mit der Sprache zu tun - es gibt die IDE Delphi und die Sprache ObjectPascal (oder wie auch immer die heißen mag).



Für mich ist das Thema beendet, solche Ignoranz tu ich mir nicht länger an.

Und ich merk auch, dass es keinen Sinn macht. Desswegen werd ich den Thread jetzt auch schließen.

i_hasser
22.06.2004, 23:47
Tiku hat mich gebeten noch die Quelle nachzureichen: http://dotnet.mvps.org/dotnet/articles/whyvbdotnet/

Ich denke jeder sollte sich aus dem Thread seine eigene Meinung bilden. Es sind teilweise viele Argumente gefallen, es sind teilweise keine Argumente gefallen (auf beiden Seiten!)... ich hab meine Meinung, du hast deine Meinung - so ist das dann eben ;D

Und Konkurrenz belebt das Geschäft (auch in nicht-finanziellen Bereichen).