[U] Mit welcher Programmiersprache programmiert ihr?

[snow]

C++, Objective-C und Java.
Und in der Schule hatten wir Delphi und ich kann bestätigen, dass es kacke ist. :<

[Master674b]

Originally Posted by マルコ

Nunja, über Geschmack lässt sich streiten. Ich mag Delphi. Ich mag die Syntax. Ich mag die Features - vor allem die, die bei anderen Sprachen nicht gegeben sind. Ich würde es in jedem Fall C++ vorziehen. Emarbcadero Delphi XE3 (Borland wtf???)finde ich eine sehr viel bessere Umgebung, als VS2012. Ich habe beides und arbeite mit beidem fast täglich.

@Master: Allein daran, was du schreibst, sehe ich, dass du Delphi nicht kennst und die entsprechende Umgebung nie genutzt hast. Wie willst du also nur ansatzweise hier eine Aussage machen? Du flamst hier nur rum. Nicht einmal auf den Thread hast du geantwortet.

@Moep: Deine Argumentation? Warum sollte er mit seinem ohne Recherche geschriebenen, fehlerhaften Beitrag Recht haben?


Und zu euren Argumentationsweise (imho):

Der gute Weg, ein Gegenargument zu bringen:


Der schlechte Weg (Moep):


Der FULLRETARDWAY(Master):


Macht euch mal Gedanken darüber, wie ihr von anderen gesehen werdet.

Jo Construktor und Destruktor manuell aufrufen zu müssen ist schon echt nice.
Move semantics haben die nie was gehört, ebenso wenig gibts da <memory> (smart_ptr), weil unmöglich mit der Kacksprache.

Das einzigste was mir daran gefällt sind properties, die möchte ich auch haben.

[Njahs]

Was bringt es euch nun, sich über Vor-/Nachteile einer Programmiersprache zu streiten?
Jede Programmiersprache hat Vorteile und Nachteile, mancher findet das eine gut,
das andere aber schlecht.
Wenn ihr etwas gegen jemanden habt, der mit einer Programmiersprache hantiert die
ihr nicht mögt akzeptiert es.
Ihr könnt, auch wenn ihr hier mit euren tausenden Argumenten wie toll eure Sprache /
andere Sprachen sind kommt, ihn nicht davon abhalten, weiterhin diese Sprache zu benutzen.
So, warum kommen wir dann nicht zurück zum Thema und hören auf mit dem Flamewars...

Autoit, Delphi, C#, (PHP)

[マルコ]

Konstruktor und Destruktor manuell aufrufen? Seit wann? Ein Konstruktor wird grundsätzlich beim Erstellen und ein Destruktor beim Zerstören eines Objektes automatisch aufgerufen.
move? Wieso? Delphi regelt das komplett anders...
Ein Smartpointer ist das einzige, was dich stört? Es braucht 10 Zeilen Code, um nen Smartpointer nachzubaun. Habe ich bereits erledigt, hübsch als Klasse und benutz das immer wieder.
Delphi braucht keine Runtimes.
try..except..finally.
Delphi ist modular durch Komponenten erweiterbar - besonders schön für GUI Anwendungen!
Vergleich mal die generierten Fehlermeldungen... Delphi siegt hoch bei Verständlichkeit!
Achja, und das Thema Datenbanken will ich hier auch auflisten! Eine Delphi Spezialität.
Auf der anderen Seite.. schonmal versucht, mit C++ ein halbwegs vernünftiges Callbacksystem zu erstellen? Der beste Ansatz, den ich kenne, wurde in CEGUI verbaut. Mit Delphi ist sowas um ein vielfaches einfacher und verständlicher (s. Delegates).


Subjektiv:
Die Sprache ist eleganter, verständlicher, wartbarer, robuster, ja, ich würd sogar sagen, sicherer. Delphi macht SPASS. C++ ist mühsam (und auf keinen Fall entwickle ich in C++ weniger als in Delphi!).

Falls du weiter diskutieren willst, ich diskutiere immer gerne. Aber bitte recherchier erstmal und such dir dann eine geeignetere Stelle zum rumjammern.

[Dr. Coxxy]

C/C++ und assembler, ab und zu etwas java etc.

[Master674b]

Konstruktor und Destruktor manuell aufrufen? Seit wann? Ein Konstruktor wird grundsätzlich beim Erstellen und ein Destruktor beim Zerstören eines Objektes automatisch aufgerufen.

Hey, du musst jedes mal Create aufrufen um Objekte überhaupt initialisiert zu haben, das sind sonst tote Referenzen. C++ spart sich das, ist ein Construktor vorhanden, werden die Objekte bei Deklaration initialisiert. Es wird zudem von dir verlangt bei Vererbung einen Konstruktor der Basisklasse explizit aufzurufen, ist das nicht definiert fügt Delphi da nicht mal einen automatischen Aufruf hinzu.

Delphi braucht keine Runtimes.

C++ hat auch keine Abhängigkeit wenn die Laufzeit statisch gelinkt wurde, mal davon abgesehn finde ich das negativ.
Code der Laufzeit auszulagern in eine DLL macht durchaus Sinn.

Die C++ Laufzeit kann schließlich statisch im CRTStartup Objekte initialisieren und registriert automatisch atexit Handler für deren Zerstörung.

Delphi / Pascal haben zudem eine höchst seltsame Syntax.

Delphi ist modular durch Komponenten erweiterbar - besonders schön für GUI Anwendungen!

Wieso ist das in C++ anders?

Auf der anderen Seite.. schonmal versucht, mit C++ ein halbwegs vernünftiges Callbacksystem zu erstellen? Der beste Ansatz, den ich kenne, wurde in CEGUI verbaut. Mit Delphi ist sowas um ein vielfaches einfacher und verständlicher (s. Delegates).

Jo hier ein Post dazu von mir:


Wird so benutzt:

const auto pWindow = UI::Components::Frame::Create(100.0f, 100.0f);
const auto pButton = UI::Components::Button::Create(L"Some Button");
pButton->GetCaption()->SetColor(Utils::Color(0xFF, 0x90, 0x50, 0x70));
pWindow->PushChild(pButton);
pButton->SetPosition(Utils::Vector2(20.0f, 20.0f));

pButton->OnClickEvent += [pWindow] (const std::shared_ptr<UI::Components::IPushable> &pSender) {
        float4 glow = {1.1f, 1.25f, 1.25f, 1.45f};
        pWindow->FadeTo(200, glow); // In 200 ms -> remove glow

        sEngine.FrameTimer.AddTimer(200, [pWindow] (const Utils::STimerDispatchEvt&) {
                float4 normal = {1.0f, 1.0f, 1.0f, 1.0f};
                pWindow->FadeTo(200, normal);
                return TIMER_STOP_EXECUTION;
        });
};

Wo wir beim Thema wären, wie sieht es denn da mit std::bind als Delphi Äquivalent / Lambda Funktionen aus? (Variadischen) Templates?

[マルコ]

aso... und in C++ sind die Objekte also einfach... da. Natürlich musst du auch in C++ Speicher allocieren. Sonst wird das nix.
Und dass ich den parent constructor extra aufrufen muss empfinde ich persönlich als VORTEIL.
Windows Philosophie ist: Alles zusammenpacken, nix re-usen. Wieso sollte man da irgendwo abweichen? Delphi macht das ganz toll von Natur aus. Da musst du nicht extra Arbeit rein stecken.
Zur Syntax hab ich meine Meinung ja bereits geäußert.
C++ hat diese Modularität nicht, nein. Du solltest wirklich mal eine hübsche Forms Anwendung mit Delphi machen. Du merkst sofort, wie der Hase läuft.
Und deine Signalklasse... kein Kommentar. Einfach nein.
Außer vllt, dass das meine Argumente unterstützt..

Zugegebenermaßen, das sind ganz niedliche neue Features. Ja, Delphi hat sowas nativ (noch) nicht dabei. Ein solches Verhalten lässt sich aber ganz einfach hinzufügen. Hierfür gibt es bereits Units, die man einfach nur noch downloaden muss, und schon hat man solche Dinge "nachgerüstet". Ich könnte dazu z.B. folgende Seite anführen:

[Master674b]

aso... und in C++ sind die Objekte also einfach... da

In der Tat. Stichwort default-constructor. Uninitialisiert gibts nicht, außer wenn ein default constructor fehlt und zudem! die Klasse native typen wie int, float usw benutzt. Der Compiler versucht auch den default Konstruktor von "fully-contained" Objekten aufzurufen auch wenn du das nicht explizit angibst. Es ist kein Vorteil und es macht keinen Sinn Objekte da zu haben die nicht initialisiert wurden. Da hast du sonst "Müll"-Speicher, der schwer zu Debuggen wird.

C++ erzeugt lokale Klassenobjekte übrigens direkt auf dem Stack. Zu Beginn nachm Funktionsprolog wird für die statischen Infos soweit Platz gemacht. Create ist glaub ich jedes mal ein HeapAlloc.

Du solltest wirklich mal eine hübsche Forms Anwendung mit Delphi machen. Du merkst sofort, wie der Hase läuft.

Das habe ich aber FMX und VCL sind Bestandteile von Embarcadero RAD Studio. Das hat mit Delphi rein überhaupt nichts am Hut, außerdem gibts davon eine C++ Fassung die das selbe ermöglicht.

Und deine Signalklasse... kein Kommentar. Einfach nein.
Außer vllt, dass das meine Argumente unterstützt..

Da bist du wohl baff wie einfach das geht, selbst funktionstüchtig auf pre C++11 Compilern. Für die C++11 Fassung gilt nur die Klasse innerhalb von #ifdef VARIADIC_TEMPLATES_SUPPORTED. Das ist dann noch kürzer und eleganter.

Ansonsten gibt es noch 2 signal implementationen von boost, welches für mich schon fast zum Standard gehört.

[マルコ]

aha, und wozu gibt es dann new?

Foo bar = new Foo();

afaik war dieses Prinzip der Komponentenverwaltung schon immer an Delphi gebunden. Unabhängig davon, ob man VCL, FMX, Jedi, Indy,... verwendet.

einfach????? Das ist der größte WUSCHT. Das ist hässlich. Schau dir bitte den CEGUI Sourcecode an. Das ist einfach. Aber immer noch zu kompliziert für meinen Geschmack.

[hallo6]

Java

[Master674b]

Originally Posted by マルコ

aha, und wozu gibt es dann new?

Foo bar = new Foo();

Das gilt ausschließlich für Speicher auf dem Heap, außerdem ist das so wie du es geschrieben hast ungültig. Es müsste Foo *bar heißen. Statische Objekte erfordern keine Benutzung von new und werden auf dem Stack reserviert und am Ende des Scopes wird deren Destruktor aufgerufen.

void someBasicFunction() {
    Foo bar; // Ein Foo-Objekt wird erstellt - Default-Construktor wird aufgerufen.
    bar.doSomething();
} // bar wird zerstört.

afaik war dieses Prinzip der Komponentenverwaltung schon immer an Delphi gebunden. Unabhängig davon, ob man VCL, FMX, Jedi, Indy,... verwendet.

Das ist ebenso wenig korrekt. Ursprünglich stammt das Signal-Slots Konzept von Qt.

einfach????? Das ist der größte WUSCHT. Das ist hässlich. Schau dir bitte den CEGUI Sourcecode an. Das ist einfach. Aber immer noch zu kompliziert für meinen Geschmack.

Nur weil du etwas nicht verstehst, heißt es nicht, dass es nicht einfach ist. Es gibt dort mehrere Faktoren zu berücksichtigen. Das wäre zum einen die einfache Handhabung, zum 2. soll das ganze flexibel über templates sein und 3. gilt es hier Threadsicherheit einzuhalten. Ich habe mich dafür entschieden, damit die Handhabung meiner Klasse so einfach wie möglich ausfällt.

Schau dir doch mal den Source Code der Standard Library Implementation von MSVC an. Die sieht genauso "hässlich" aus. Das ändert nichts daran, dass das völlig unerheblich ist, die Flexibilität spielt eine viel wichtigere Rolle, außerdem hat den Code niemand anzurühren. Das kümmert mich einen Dreck wie das intern aussieht. Genauso ist in etwa meine Eventklasse aufgebaut, einfach zu handhaben und flexibel und sicher. Delphi schenkt sich da in dieser Hinsicht überhaupt nichts, nur das dort ALLES absolut hässlich aussieht. Auch Code der nicht zu einem Library Helper gehört.

Stichwort partielle Template Spezialisierung und Syntaxunterstüzung für pre-C++11 Compiler. Mit C++11 geht das in wenigen Zeilen Code, vorher aber nicht.

// Neues Event erstellen mit einem float als Rückgabe und 2 ints als Parameter.
Utils::Event<float (int, int)> someEvent;

// Einen Handler hinzufügen
someEvent += [] (int a, int b) {
    return a / b;
};

// Aufrufen!
float ergebnis = someEvent(2, 3);

// Alle Ergebnisse der registrierten Handler ausgeben:
auto results = someEvent.invoke_getall(2, 3);

// Methode A
for (auto& i: results)
    std::cout << i << ", ";

// Methode B - effizienter
std::ostream_iterator<float> output(std::cout, ", ");
std::move(results.begin(), results.end(), output);

Das zeigt sehr schön die Flexibilität die C++ da aufweist. Definitiv unübertroffen.

[Twist']

C#

[Cencil]

Delphi (fap fap, noch einer)

C++ zwecks Reversing wage Basiskenntnisse (kleinere Tools, Hacks bekomme ich da schon noch hin) vorhanden, wollte mich da mal mehr reinsteigern, möchte aber gerne noch einige Projekte in Delphi fertigstellen.

[マルコ]

Originally Posted by Master674b

Es müsste Foo *bar heißen.

Joa, ich weiß. Sry, hab mich wohl vertippt.

Originally Posted by Master674b

Das ist ebenso wenig korrekt. Ursprünglich stammt das Signal-Slots Konzept von Qt.

Häh? Den Zusammenhang versteh ich nun wirklich nicht.

Originally Posted by Master674b

Nur weil du etwas nicht verstehst, heißt es nicht, dass es nicht einfach ist.

Und wann hab ich gesagt, dass ichs nicht versteh? Thread Sicherheit? Ja, schön, aber das kann man auch anders einbaun.

Und NOCHMAL: Ich finde Delphi SCHÖN. Akzeptier das einfach. Über den Punkt werden wir uns nicht einig.

Originally Posted by Master674b

Das zeigt sehr schön die Flexibilität die C++ da aufweist. Definitiv unübertroffen.

und nochmal ganz klasse, wie du dort mit niedlichen neuen Standards prahlst. Klar, Delphi ist nicht so verbreitet, deshalb zieht es C++ in solchen Dingen hinterher, aber ich bin mir relativ sicher, dass auch diese neuen Ideen in Delphi übernommen werden. Delphi und dessen Tools sind keinesfalls tot.

[Saedelaere*]

Delphi <3