C++ / Delphi



  • Ein Speicherblock bestimmter Größe.

    das stimmt basta! nur die variable enthält einen pointer auf das erste element dieses speicherblocks und wird einfach automatisch dereferenziert

    std::vector ist doch auch nicht sehr viel anderes als eine Liste.

    < 10 Minuten Zeit zum umschreiben benutzen.

    andere haben vielleicht die zeit sowas unmzuschreiben aber ich mach in der zeit lieber was neues.
    std::vector und alle darauf anwendbaren algorithmen haben mehrere tausend zeilen code und die alle anzupassen... ausserdem isses doch irgendwie käse in einem projekt immer den selben code mit kleinen unterschieden zu haben.

    ausserdem finde ich es irrelevant zu sagen der vorteil von templates ist nicht so gross wie alle immer denken weil man das auch anders machen kann...
    "jo klar wer braucht schon klassen? ich meine das kann ich ja auch mit structs und so nachbilden..." is ungefähr eine gleich starke argumentation.

    und zu dem mit dem for.... wenn ich gewusst hätte was ich damit auslöse 🙂

    ich hab mich ja auch nur beschwert das man mir unbedingt beibringen wollte das das ein nachteil ist... warum denn es macht vom generierten code her keinen unterschied und nur weil ich in c++ die möglichkeit hab die variable zu verändern muss ich das ja nicht tun...

    [ Dieser Beitrag wurde am 06.01.2003 um 16:35 Uhr von japro editiert. ]



  • [quote von mir]
    Kommentare werden in Pascal übrigens per {} gemacht!
    [end quote]

    Für die, die es noch nicht mitbekommen haben: Wir führen hier keine C / Pascal weder noch eine C++ / Pascal sondern eine C++ / ObjectPascal Diskussion.

    Ich frage mich, wie jemand, der nur sehr geringfügige Sprachkenntnisse hat einem, der offensichtlich um einiges mehr an Sprachkenntniss besitzt darauf hinzuweisen, obwohl er nicht die geringste Ahnung davon hat, dass es ein Sprachkonstrukt, was in jedem Quelltext vorkommt, in einer Sprache nicht exisitert, die überhaupt nicht zur Diskussion steht.

    So, mein Kleiner, jetzt reicht's aber! Hast du schonmal nen Delphi-Quellcode gesehen? Ja? Dann müsste dir klar sein, dass dort Kommentare in geschweifte Klammern gesetzt werden. Und nochmal für dich: Delphi ist Object Pascal. Und was die Arrays angeht: mit deinen Kommentaren ist wohl klar, dass DU hier derjenige bist, der absolut keine Ahnung hat von dem, was im Speicher so abgeht. Ich glaube, es wird besser für dich sein, wenn du hier deinen Mund hältst, denn wie du siehst, wissen alle hier besser bescheid als du.



  • Hallo,

    So, mein Kleiner, jetzt reicht's aber! Hast du schonmal nen Delphi-Quellcode gesehen? Ja?

    Im Gengensatz zu Dir schon!

    Dann müsste dir klar sein, dass dort Kommentare in geschweifte Klammern gesetzt werden

    *LACH*

    Und nochmal für dich: Delphi ist Object Pascal

    Genauso bescheuert währe: MSVC ist C++

    Und was die Arrays angeht: mit deinen Kommentaren ist wohl klar, dass DU hier derjenige bist, der absolut keine Ahnung hat von dem, was im Speicher so abgeht

    Was sind Arrays denn deiner Meinung nach ?

    Ich glaube, es wird besser für dich sein, wenn du hier deinen Mund hältst

    DITO

    denn wie du siehst, wissen alle hier besser bescheid als du.

    Du bist der einzige in dieser Diskussionsrunde, der überhaupt kein Ahnung von ObjectPascal hat. Du versuchst mit deinem geringfügigem Wissen über diese Sprache herzufallen. Leider bist du anscheinend nicht dazu imstande zu merken, dass das ziemlich in die Hose geht.

    mfg
    Th3Law

    [ Dieser Beitrag wurde am 06.01.2003 um 17:06 Uhr von Th3Law editiert. ]



  • Kommentare so:
    {} für einen mehrzeiligen block oder so
    // für eine Zeile.

    Was ist so schlimm daran, wenn ein TButton mit einer TStringlist verwandt ist? Gut, sie haben nicht viel gemeinsam (außer, dass sie von TObject abstammen 😃 ).



  • Hallo,

    Antwort ist sie haben nichts gemeinsam. Die Klasse TObject steht in der ObjectHieracheie jeder Klasse ganz oben!

    mfg
    Th3Law

    [ Dieser Beitrag wurde am 06.01.2003 um 18:15 Uhr von Th3Law editiert. ]



  • Aus der Delphi-Hilfe zu TObject:

    TObject encapsulates fundamental behavior common to VCL objects by introducing methods that

    1. create, maintain and destroy instances of the object by allocating, initializing, and freeing required memory.
    2. return class-type and instance information on an object and runtime type information (RTTI) about its published properties.
    3. support message handling.
    4. support interfaces that the object implements.

    In so fern ist es logisch, dass beide von TObject abstammen. Und genau das haben sie auch gemeinsam.

    [ Dieser Beitrag wurde am 06.01.2003 um 18:56 Uhr von Luckie editiert. ]



  • Ok, eine etwas eigentümliche Vorstellung von Klassen aus Sicht von C++.
    In C++ wird vorausgesetzt, dass jede Klasse diese Eigenschaften automatisch
    besitzt. Aber vertretbar ist es.... obwohl es mir ein wenig quer liegt 😃

    [ Dieser Beitrag wurde am 06.01.2003 um 20:55 Uhr von Taurin editiert. ]



  • Darüber kann man sich streiten, ich denke beides ist nur reine Gewohnheitssache.

    Es ist trotzdem unkomfortabel, der C Standard wurde ja auch nicht umsonst geändert um zu ermöglichen, dass man überall Variablen definieren kann, wie man will 🙂

    Objekte werden in Delphi, eh dynamisch erstellt.

    😮 WAS! Kein wunder, dass Delphi so laaaaaannngsaam ist 🙂 Naja da wär es wohl Performanter Speicher für alle Objekte in einem Block zu belegen.

    @WebFritzi

    Ich glaube, es wird besser für dich sein, wenn du hier deinen Mund hältst, denn wie du siehst, wissen alle hier besser bescheid als du.

    Wir sind doch alle groß und alt und müssen uns nicht angreifen!

    http://community.borland.com/soapbox/techvoyage/article/1,1795,10280,00.htm#5.0

    Das man 3 Möglichkeiten für Kommentare hat finde ich übrigens gar nicht schlecht, weil ich mit { } Code auskommentiere (* 😉 brauch ich für längere Kommentare und // für kurze, dass hat den Vorteil, dass ich nicht wie bei C(++) leicht mit den /**/ in Bedrängniss komme

    /*
    blabla(); /* foo */
    bar(); */
    

    @Luckie

    In so fern ist es logisch, dass beide von TObject abstammen. Und genau das haben sie auch gemeinsam.

    Das ist eben der billige Trick von O Programmisprachen, die keine Templates besitzen (von wegen Typ Sicherheit!)

    BTW.
    Ist Object Pascal eigentlich proprietär oder gibt es da einen Standard oä.?

    [ Dieser Beitrag wurde am 06.01.2003 um 20:59 Uhr von kingruedi editiert. ]



  • Original erstellt von kingruedi:
    **
    Ist Object Pascal eigentlich proprietär oder gibt es da einen Standard oä.?
    **

    Soweit ich weiß ist Object Pascal eine reine Borlandangelegenheit. Insofern
    wird es (vermutlich) nur einen privaten Borlandstandard gegeben oder so.



  • Hallo,

    dass Delphi so laaaaaannngsaam ist

    Die angeblichen Geschwindigkeitsnachteile von Delphi sind Gerüchte. ObjectPascal schneidet im Geschwindigkeitstest mit C++, als beinahe gleichschnell ab (kein wunder zu Zeiten von HochOptimierung)

    Naja da wär es wohl Performanter Speicher für alle Objekte in einem Block zu reservieren

    Scherzbold

    Das ist eben der billige Trick von O Programmisprachen, die keine Templates besitzen (von wegen Typ Sicherheit!)

    Was für ein billiger Trick ?!

    mfg
    Th3Law



  • Original erstellt von Th3Law:
    Die angeblichen Geschwindigkeitsnachteile von Delphi sind Gerüchte. ObjectPascal schneidet im Geschwindigkeitstest mit C++, als beinahe gleichschnell ab (kein wunder zu Zeiten von HochOptimierung)

    Hast du schon mal versucht, DirectDraw oder Direct3D Programme in Delphi
    umzusetzten??? Trotz DelphiX wird das hier nicht mehr viel mit Delphi...



  • Original erstellt von Th3Law:
    Was für ein billiger Trick ?!

    Na zB:

    vector<foo>

    ist dann ein

    ObjectVector

    und beinhaltet referenzen/zeiger auf TObjects - dh man kann es wie einen vector<foo> verwenden.
    dirty hack

    generische Programmierung ist sehr maechtig. Warum schreien denn Java und .NET Entwickler nach Templates?

    variablen am anfang einer funktion zu deklarieren ist nicht nur out sondern auch unpraktisch.

    Fuer mich wirkt ObjectPascal wie ein verzweifelter versuch pascal in eine sprache zu verwandeln die man auch in der wirtschaft verwenden kann. IMHO ist das nicht besonders gut gelungen. Haette Delphi nicht die VCL wuerde es wohl kaum jemand verwenden. Und Delphi hat IMHO auch nur den Plusplunkt, dass es gratis ist - sonst sehe ich keinen sinn warum man nicht gleich den BCB nehmen sollte.



  • Die Diskussion, ob begin oder { oder wie die for-Schleifen genau arbeiten soll ist ziehmlich lächerlich, weil Geschmackssache.

    Begin und { macht ja wohl null Unterschied außer vielleicht bei der Tipparbeit, wobei ich begin genausoschnell getippt hab wie AlgGr-7 zu drücken.

    Die schleifen ist auch wurscht, weil es für jede möglichkeit sich entsprechende schleifenkonstrukte gibt.

    Ich kenn mich jetzt nicht so gut in Delphi aus, hab aber früher einiges Object-Pascal programmiert. Soweit ich mich erinnere, müssen NICHT alle Klassen von einem Objekt abgeleitet sein. TObject ist das Basisobject für die VCL, für andere Bibliotheken ist das aber in keinster weise zwingen. In den MFC sind auch alle Klassen von CObject abgeleitet.

    Dass alle Objekte Referenzen sind, ist eine bewusste Designentscheidung der Entwickler von Object-Pascal. Das ist auch in anderen OO-Sprachen so (Java). In C++ nicht, deswegen sind aber auch manche sachen etwas komplizierter, bzw. nicht so einsichtig, wenn man nicht täglich damit arbeiten (Copy-Ctor und ähnliche geschichten).

    Dass man die Objekte an einem Platz zusammenfasst und kein neuen Scopes aufmachen kann, ist ebenfalls ein Designmerkmal und kann nicht pauschal als Nachteil angesehen werden. Und da der Konstruktor sowieso explizit aufgerufen wird, stimmt es auch nicht, dass man so Objekte instanziiert, die man womöglich garnicht braucht.

    Operator-Überladung ist zwar ganz witzig, aber es macht für das Design eines Programms eigentlich keinen unterschied.

    Einer der größten Vorteile von C++ gegenüber den meisten OO-Sprachen ist aber die automatische Destruktion von Objekten. Damit (RAII) kann man sich das ganze Garbage-Collection-Zeug sparen, man kann das gleiche Prinzip für jede Art von Resourcen-Belegung anwenden und tut sich leichter bei der Ausnahmebehandlung. Hier ist Delphi klar in Nachteil, weil es eben auch keine Garbage-Collection hat und man dadurch ziehmlich viel mit try-catch-finally-Klauseln arbeiten muss.

    Außerdem bleiben dann natürlich noch die Templates. Delphi hat da nichts Vergleichbares zu bieten.

    Dafür hat Delphi aber in der Handhabbarkeit einige Vorteile. imho ist der Code wesentlich leichter zu lesen. Ich arbeite täglich mit c++ und so gut wie nie mit Delphi, kann aber den Code in etwa gleich gut lesen. Pascal-Code ist einfach übersichtlicher. Von der Geschwindigkeit sind Delphi-Progs in der Praxis (außer bei hoch-Performance-Anwendungen) wohl gleichwertig, mir ist aber noch nie ein C++-Compiler untergekommen der nur annäherungsweise so schnell compiliert wie Delphi.
    In C++ hat man natürlich sehr viel mehr Spielraum für sein Programmdesign, weil mehr Sprachparadigmen unterstützt werden. Andrerseits hat das auch zur folge, dass man nur einen geringen Teil der Sprache wirklich nutzt (und jeder Programmierer nen anderen) und man schon einiges an Lehrzeit investieren muss, bevor man richtig produktiv mit arbeiten kann. In Delphi wird man viel schneller produktiv, irgendwann fühlt man sich aber vielleicht eingeengt. C++ gleicht insofern eher einer natürlichen gewachsenen Sprache mit vielen eleganten und auch unschönen Möglichkeiten, etwas auszudrücken, Delphi ist halt mehr einfach gestrickt.



  • Sehr schöne Zusammenfassung.

    Kleines Detail: In Delphi sind alle Klassen von TObject abgeleitet,
    auch wenn man es nicht explizit hinschreibt.

    TMyClass = class
      //..
      end;
    

    ist gleichwertig mit

    TMyClass = class(TObject)
      //..
      end;
    


  • Original erstellt von Taurin:
    **
    Kleines Detail: In Delphi sind alle Klassen von TObject abgeleitet,
    auch wenn man es nicht explizit hinschreibt.
    [/code]**

    Inwiefern stellt das eigentlich, wie hier von einigen vertreten, einen Nachteil dar?



  • Original erstellt von Bashar:
    Inwiefern stellt das eigentlich, wie hier von einigen vertreten, einen Nachteil dar?

    IMHO ist das insofern ein nachteil da ich keinen vorteil sehe.

    was ist der vorteil von so einer basisklasse.



  • Original erstellt von Shade Of Mine:
    **IMHO ist das insofern ein nachteil da ich keinen vorteil sehe.

    was ist der vorteil von so einer basisklasse.**

    ...und ich sehe es als Nachteil von C++ an, dass der Dereferenzierungsoperator * und nicht § ist. Grund : Ich sehe keinen Vorteil von * gegenüber §.
    🙂

    EDIT : *SCNR*

    [ Dieser Beitrag wurde am 07.01.2003 um 15:52 Uhr von Gregor editiert. ]



  • Original erstellt von Gregor:
    ...und ich sehe es als Nachteil von C++ an, dass der Dereferenzierungsoperator * und nicht § ist. Grund : Ich sehe keinen Vorteil von * gegenüber §.
    🙂

    EINE basisklasse bedeutet das fehlen von mehrfachvererbung - es sei denn man wuerde automatisch virtual erben... aber das waere wohl auch nicht ideal.

    sag mal was der vorteil an einer basisklasse ist.



  • Original erstellt von Shade Of Mine:
    EINE basisklasse bedeutet das fehlen von mehrfachvererbung

    Nö, siehe z.b. CLOS

    **
    - es sei denn man wuerde automatisch virtual erben... aber das waere wohl auch nicht ideal.**

    Bitte ausführlicher.

    **
    sag mal was der vorteil an einer basisklasse ist.**

    Die Behauptung, es wäre ein Nachteil, kam zuerst.



  • Das Fehlen von Mehrfachvererbung kann aber auch wieder eine bewusste Design-Entscheidung sein.

    Die Ableitung von einem gemeinsamen Basisobjekt ist zwingend, wenn man mit Containern arbeiten will, in die man alle Objekte einbinden kann.

    Jede Klasse deren Objekte in diesem Container abgelegt werden können sollen, muss von einer gemeinsamen Basisklasse abgeleitet werden.

    Würden die Objekte nicht zwingend eine Basisklasse haben, müsste man - beim fehlen von Mehrfachvererbung - entscheiden, ob alle Klassen einer Klassenhierarchie in den Container passen sollten (dann würde die Basisklasse der Speziellen Hierarchie von TObjekt abgeleitet) oder nicht - dann würde die Basisklasse nicht von TObjekt abgeleitet und man könnte aber nicht entscheiden, dass eine Klasse irgendwo anders in besagter Hierarchie nicht doch in den Container passen würde.

    Wegen der Templates in C++ kann man aber auf diese ganze Schema "Container für Elemente mit gemeinsamer Basisklasse" verzichten. Da aber Templates im grunde programmiertechnisch was ziehmlich neues sind, kann man das imho nicht als Nachteil von Delphi ggü. C++ sondern als Vorteil von C++ gegenüber den meisten anderen Sprachen sehen.

    Eine gemeinsame Basisklasse ist in C++ also erstmal nicht nötig, weils Mehrfachvererbung gibt.
    Seit es Templates gibt, ist aber diese ganze Technik für nen Container nicht mehr nötig. Das hat klare Vorteile (z.B. Typsicherheit).
    Eine gemeinesame Basisklasse bringt einen gewissen Overhead mit. Wird die gemeinsame Basisklasse aber nicht benutzt, dürfte dieser aber eher von theoretischer Natur sein, wird sie benutzt ist das kein Overhead mehr.

    [ Dieser Beitrag wurde am 07.01.2003 um 16:35 Uhr von kartoffelsack editiert. ]


Anmelden zum Antworten