C++, Objective-C und Java.
Und in der Schule hatten wir Delphi und ich kann bestätigen, dass es kacke ist. :<
Und in der Schule hatten wir Delphi und ich kann bestätigen, dass es kacke ist. :<
Jo Construktor und Destruktor manuell aufrufen zu müssen ist schon echt nice.Quote:
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.
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.Quote:
Konstruktor und Destruktor manuell aufrufen? Seit wann? Ein Konstruktor wird grundsätzlich beim Erstellen und ein Destruktor beim Zerstören eines Objektes automatisch aufgerufen.
C++ hat auch keine Abhängigkeit wenn die Laufzeit statisch gelinkt wurde, mal davon abgesehn finde ich das negativ.Quote:
Delphi braucht keine Runtimes.
Wieso ist das in C++ anders?Quote:
Delphi ist modular durch Komponenten erweiterbar - besonders schön für GUI Anwendungen!
Jo hier ein Post dazu von mir:Quote:
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).
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;
});
};
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.Quote:
aso... und in C++ sind die Objekte also einfach... da
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.Quote:
Du solltest wirklich mal eine hübsche Forms Anwendung mit Delphi machen. Du merkst sofort, wie der Hase läuft.
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.Quote:
Und deine Signalklasse... kein Kommentar. Einfach nein.
Außer vllt, dass das meine Argumente unterstützt..
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.Quote:
aha, und wozu gibt es dann new?
Code:Foo bar = new Foo();
void someBasicFunction() {
Foo bar; // Ein Foo-Objekt wird erstellt - Default-Construktor wird aufgerufen.
bar.doSomething();
} // bar wird zerstört.
Das ist ebenso wenig korrekt. Ursprünglich stammt das Signal-Slots Konzept von Qt.Quote:
afaik war dieses Prinzip der Komponentenverwaltung schon immer an Delphi gebunden. Unabhängig davon, ob man VCL, FMX, Jedi, Indy,... verwendet.
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.Quote:
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.
// 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);
Joa, ich weiß. Sry, hab mich wohl vertippt.Quote:
Es müsste Foo *bar heißen.
Häh? Den Zusammenhang versteh ich nun wirklich nicht.Quote:
Das ist ebenso wenig korrekt. Ursprünglich stammt das Signal-Slots Konzept von Qt.
Und wann hab ich gesagt, dass ichs nicht versteh? Thread Sicherheit? Ja, schön, aber das kann man auch anders einbaun.Quote:
Nur weil du etwas nicht verstehst, heißt es nicht, dass es nicht einfach ist.
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.Quote:
Das zeigt sehr schön die Flexibilität die C++ da aufweist. Definitiv unübertroffen.