Wieso gibt es keine gute Programmiersprache?

"Dachschaden" ist halt psychisch krank.

5cript

hustbaer schrieb:

5cript schrieb:

Wenn man sowas vermeiden kann, kann man auch keine Kapselungsfehler machen oder Sachen vergessen.

Natürlich kann man dann noch Kapseln. Und natürlich kann man dann noch Dinge vergessen. Manchmal schreibst du schon phenomänal unsinnigen Unsinn.

*weniger -> fixed
&ja den Begriff verwendet niemand, war mir so aus dem Kopf gerutscht.

Ich kann schließlich nicht alles aufzählen, wofür Kapselung gut ist

Hey ich benutze auch manchmal friend um Methoden private zu machen.
come kill me!

Andromeda

ich weiß echt nicht schrieb:

"Dachschaden" ist halt psychisch krank.

Er berichtete bereits von einer gescheiterten Kindheit. Ich entlockte ihm diesentsprechende Statements. Armes Schwein. Möget ihr seine fachlichen Äußerungen vor dem eben genannten Hintergrund betrachten, ergo: mit Vorsicht genießen. Ich nehme an, dass seine Erkrankung sein Urteilsvermögen trübt.

Zeus

Finnegan schrieb:

Zeus schrieb:

... Versus: ...

No other comment included!

Die Anforderung war, dass zwar auf dem Stack immer Speicher für das Objekt reserviert werden soll, der Programmierer aber bestimmen möchte ob und wann es konstruiert und zerstört wird.
Die zweite Variante erfüllt diese Anforderung nicht, da Reservierung von Stack-Speicher und Konstruktoraufruf nicht getrennt sind.

Ferner war der Code lediglich ein Beispiel dafür wie man das für beliebige Klassen in C++ umsetzen kann und mitnichten eine Anleitung wie man immer und überall Objekte kostruieren sollte (Bloss nicht!).

Finnegan

Vielleicht sollte nach den Sinn deines Beispiel fragen?

Zeus schrieb:

Vielleicht sollte nach den Sinn deines Beispiel fragen?

Vielleicht solltest du lesen, was du zitiert hast?

Finnegan schrieb:

dachschaden schrieb:

Kann ich in C++ dem Compiler sagen, dass er nur ein bisschen Speicherbereich auf dem Stack reservieren soll für ein Objekt, und Initialisierung und Freigabe komplett mir überlassen soll? Wenn ja, will ich nichts gesagt haben.

Zeus

Wird ja immer schlimmer.. schrieb:

Zeus schrieb:

Vielleicht sollte nach den Sinn deines Beispiel fragen?

Vielleicht solltest du lesen, was du zitiert hast?

Finnegan schrieb:

dachschaden schrieb:

Kann ich in C++ dem Compiler sagen, dass er nur ein bisschen Speicherbereich auf dem Stack reservieren soll für ein Objekt, und Initialisierung und Freigabe komplett mir überlassen soll? Wenn ja, will ich nichts gesagt haben.

Vielleicht solltest du mehr effektive C++ Bücher lesen, damit man weißt dass es Unsinn ist. Statt zu sagen, dass es Unsinn ist, wird sehr unsinniger Code gepostet.

Finnegan

Andromeda schrieb:

Er berichtete bereits von einer gescheiterten Kindheit. ...

"Ad hominem" zu argumentieren kommt zumindest bei mir nicht besonders gut an, ungeachtet dessen wie stark oder schwach die Argumente des anderen sind.
Wenn du nichts substantielles zur fachlichen Diskussion beizutragen hast, wäre zumindest ich dankbar, wenn du in Zukunft einfach schweigen würdest.

Finnegan

Andromeda

Finnegan schrieb:

Andromeda schrieb:

Er berichtete bereits von einer gescheiterten Kindheit. ...

"Ad hominem" zu argumentieren kommt zumindest bei mir nicht besonders gut an,

Du hast natürlich Recht. Ad hominem ist niemals eine gültige Argumentationsfigur. Ich gebe zu, dass es mir in dem Fall nur darum ging, diesen Freak zu dissen und zu bashen. Ich mag nunmal keine Nazis. Bei Nazis geht mir das Messer in der Tasche auf. Egal, wo sie in Erscheinung treten.

Btw, ich bin selber kein Freund von C++. Mir ist C auch viel sympathischer. Aber letztlich beruht das alles auf Erfahrungswerten. Wer mit anspruchsvollen Softwareprojekten auf leistungschwacher Hardware zu tun hatte (aus Kostengründen), und andererseits unter Zeitdruck Programme hinfrickeln durfte, die früh serienreif sein sollten und denen man nicht anmerken sollte, dass sie mit der heißen Nadel gestrickt waren, der wird mit C++ in keinem Fall glücklich.

Ich bin der Meinung, dass C++ im mittleren Leistungsegment durchaus seine Berechtigung hat. Aber sobald ein managed environment aka .NET, Java-VM, Docker, usw. vorhanden ist, hat C++ ausgedient.

dachschaden

Zeus schrieb:

#include <iostream>

struct Objekt
{
	Objekt(int value) : value{ value } {}
	void print() const { std::cout << value << std::endl; }
	int value;
};

int main()
{
	Objekt obj(5);
	obj.print();
	return 0;
}

No other comment included!

Bitte lies nochmal:

dachschaden schrieb:

Kann ich in C++ dem Compiler sagen, dass er nur ein bisschen Speicherbereich auf dem Stack reservieren soll für ein Objekt, und Initialisierung und Freigabe komplett mir überlassen soll? Wenn ja, will ich nichts gesagt haben.

Dein Code hingegen macht genau das nicht. Er zwingt mich, meinen Init-Code in eine eigene Funktion zu packen, oder halt mit der unter Umständen teuren Objektinitialisierung zu leben.

hustbaer schrieb:

Wenn du keine Exceptions verwenden willst, dann verwende keine.

Bitte lies dir das nächste Mal Posts genauer durch:

dachschaden schrieb:

Für ersteres kann ich auch einfach irgendwelchen anderen C-Libs verwenden, die keine Exceptions kennen, und auch selbst keine schreiben

hustbaer schrieb:

Und was Konstruktoren/Destruktoren angeht: Hallo, Inlining?

Finnegan schrieb:

Wird in C ein Aufruf wegoptimiert, bei dem zur Compile-Zeit bekannt ist, dass es sich um eine leere Funktion handelt?

Dann ist modulübergreifende LTO für, sagen wir den g++, endlich soweit, dass ein memset , welches einen Speicherbereich nullen soll (private Daten, bei denen sichergestellt werden soll, dass diese nicht noch im Speicher rumgeistern, falls der Server geowned wird), nicht wegoptimiert wird, aber andere, komplett leere Funktionsaufrufe schon? Genau das war nämlich das Problem bei Heartbleed - dass die Daten so schön weit beisammen im Speicher waren, weil OpenSSL seinen eigenen Allokator bebaut hat, aber nicht hinter sich hergeräumt hat (wobei ich nicht mal davon ausgehe, dass sie memset verwendet haben - nur hätte ihnen das wohl auch nicht viel gebracht).

LTO wirft sowas weg für lokale Variablen - Dead Store Elimination. Und nicht nur bei lokalen Variablen, sondern auch für Zeiger, die danach freigegeben werden ( free/delete ). Ohne LTO kann der Linker (bei Funktionen, bei denen die Implementierung in einem anderen Modul liegt) nicht sagen, ob der Call eingespart werden kann. Zumindest ist das bei C der Fall. Und meine Frage war jetzt, ob in Fällen, in denen ich Schnittstelle und Implementierung trenne, der Linker intelligent genug ist, das zu erkennen.

Im eigenen Modul - ja klar, das erkennt der Compiler. In anderen Modulen? Und genau das ist meine Frage.

hustbaer schrieb:

Natürlich ist es trotzdem in den meisten Fällen beknackt so zu programmieren.

Meine Rede:

dachschaden schrieb:

kann man machen, aber dann schaut jeder einen an wie einen Geistesgestörten.

Finnegan schrieb:

Wenn du das vermeiden willst, kannst du z.B. den virtuellen Speicher erst dann allozieren, wenn zum ersten mal darauf zugegriffen wird
(z.B. in einer get() -Methode, wenn hinter dem internen Pointer noch kein Speicher steckt).

Dazu müsste ich hinbekommen, dass existierender Code (sagen wir mal spontan, pthreads, oder entsprechende Implementierung in C++) diesen get() auch aufruft. Wird er wahrscheinlich nicht machen. Deswegen muss ich, bevor ich meinen Speicher übergebe, erst get() aufrufen. Jetzt benenne get() in _init um, weil es effektiv genau das ist, und wir sind wieder beim unnötigen Funktionsaufruf.

Andromeda schrieb:

Nehmt mal diesen "Dachschaden" nicht so ernst. Der Typ ist ein Nazi. Bei solchen Leuten fehlen immer ein paar Latten am Zaun.

Jetzt geht er in die Vollen ...

Finnegan schrieb:

P.S.: Und was zum Henker geht hier in diesem Thread? "Nazi"? "psychisch krank"?
Ist das ein Diskussionsniveau das wir hier in einem technischen Forum haben wollen? (Denke da kann man noch einiges mehr löschen!)

Er ist ein Troll, der verzweifelt darum bemüht ist, Aufmerksamkeit zu erheischen. Wie mein Urgroßvater zu sagen pflegte: "Garnnich drum kümmern".

EDIT: LTO-Paragraph korrigiert (unschönen, offenen Satz vervollständigt), Storage => Store, und hinzugefügt, dass dem auch bei Zeigern auf dem Heap so ist, wenn diese freigegeben werden.

Zeus

dachschaden schrieb:

Zeus schrieb:
#include <iostream>

struct Objekt
{
	Objekt(int value) : value{ value } {}
	void print() const { std::cout << value << std::endl; }
	int value;
};

int main()
{
	Objekt obj(5);
	obj.print();
	return 0;
}
No other comment included!
Bitte lies nochmal:

dachschaden schrieb:

Kann ich in C++ dem Compiler sagen, dass er nur ein bisschen Speicherbereich auf dem Stack reservieren soll für ein Objekt, und Initialisierung und Freigabe komplett mir überlassen soll? Wenn ja, will ich nichts gesagt haben.

Dein Code hingegen macht genau das nicht. Er zwingt mich, meinen Init-Code in eine eigene Funktion zu packen, oder halt mit der unter Umständen teuren Objektinitialisierung zu leben.

Objektinitialisierung werden erst teuer, wenn Leute nicht wissen, wo die Kosten entstehen. Und bei dir hab ich den Eindrück, dass das so ist, weil viele Probleme entstehen wenn man Objekt-Initialisierung und -Konstruktion trennt. Sonst empfehle ich die Buchreihe zu lesen, die ich hier schon mal erwähnt hatte.

Zeus schrieb:

dachschaden schrieb:
Zeus schrieb:
#include <iostream>

struct Objekt
{
	Objekt(int value) : value{ value } {}
	void print() const { std::cout << value << std::endl; }
	int value;
};

int main()
{
	Objekt obj(5);
	obj.print();
	return 0;
}
No other comment included!
Bitte lies nochmal:

dachschaden schrieb:

Kann ich in C++ dem Compiler sagen, dass er nur ein bisschen Speicherbereich auf dem Stack reservieren soll für ein Objekt, und Initialisierung und Freigabe komplett mir überlassen soll? Wenn ja, will ich nichts gesagt haben.

Dein Code hingegen macht genau das nicht. Er zwingt mich, meinen Init-Code in eine eigene Funktion zu packen, oder halt mit der unter Umständen teuren Objektinitialisierung zu leben.
Objektinitialisierung werden erst teuer, wenn Leute nicht wissen, wo die Kosten entstehen. Und bei dir hab ich den Eindrück, dass das so ist, weil viele Probleme entstehen wenn man Objekt-Initialisierung und -Konstruktion trennt. Sonst empfehle ich die Buchreihe zu lesen, die ich hier schon mal erwähnt hatte.

dachschaden

Zeus schrieb:

Objektinitialisierung werden erst teuer, wenn Leute nicht wissen, wo die Kosten entstehen.

OK, du liest also Posts nur halbherzig. Gut zu wissen.

EDIT: An den Imitator hier: wenn du schon unbedingt Leute imitieren willst, dann mach das wenigstens glaubwürdig.

dachschaden schrieb:

Zeus schrieb:

Objektinitialisierung werden erst teuer, wenn Leute nicht wissen, wo die Kosten entstehen.

OK, du liest also Posts nur halbherzig. Gut zu wissen.

Bitte ein Bit

Was für ein hübscher Flame War...

5cript

Wisst ihr was, ihr habt recht: explicit ist schlimm. Nach diesem Thread mache ich mir bzgl Kollegen in Zukunft mehr sorgen.

...und eine weitere Seele gerettet

turbo autist schrieb:

Jetzt mal ohne Witz, Computer Science existiert schon mehrere Dekaden und die Leute haben es noch immer nicht hinbekommen, eine gute Programmiersprache zu schreiben?

Doch haben sie, lustigerweise sehr früh am Anfang. Aber die Computer waren noch zu schwach und man musste sich erst mal mit C und Konsorten herumschlagen. Nach und nach wurden dann aber langsam die alten Konzepte auch in modernere Sprachen übernommen.

Leider sind die Leute heute so in ihrem Klammerwald gefangen, dass sie die perfekte Syntax nicht erkennen, weil sie zu viele Klammern sehen.

und worin besteht nun genau der durchgreifende syntaktische Vorteil von "klammerfreien" Sprachen?

Gut, man kann sich mit Python hin und wieder eine vergnügliche Debugging-Sitzung bereiten, falls man beim Editieren in der Hektik unbemerkt eine Tab-Einrückung gelöscht hat und damit versehentlich den Programmablauf verändert, aber sonst?

hmm.. mein Satz mit dem Klammerwald war etwas wirr und unsinnig...

Ich wollte darauf anspielen, dass viele Außenstehende ein Problem mit der Lisp/Scheme-Syntax haben aber nicht mit Java oder C++.

gute Programmiersprachen gibt es. Perfekte nicht.
Wie denn auch? Dafür müsste man eine Sprache veröffentlichen, warten was die Community nach Monaten und Jahren dazu für Feedback gibt, dann alles verwerfen und die Sprache neu aufsetzen.
Dann, wenn wieder ein neues Feature nötig ist, dieses so einbauen, dass es möglichst gut ins Gesamtbild passt, Abwärtskompatibilität ist egal.
Und so weiter.

Ich persönlich finde mit guten Sprachen mein Auslangen, eine Programmiersprache ist ein Werkzeug, und jedes Werkzeug hat seine Vor und Nachteile und Einsatzbereiche. Dass trotzdem so emotional drüber diskutiert wird liegt wohl in den Genen der Informatiker