OOP - für was in aller Welt soll denn das gut sein?

[Christian M. (Gast)]

Hallo Programmierer,

ich bin im JS-Kurs jetzt bei den Objekten angelangt. Aber mir 
erschliesst sich der Sinn eines solch abstrakten Gebildes absolut nicht. 
Kann mir einer verklickern, wofür das gut sein soll?

Im Kurs mach ich jetzt als Uebung eine Telephonliste von Freunden, 
komplizierter geht es ja wohl nicht, wie soll man da flexibel erweitern?

Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String 
manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die 
Zahl das Objekt sein...?!

Intern wird es ja eh prozedural verarbeitet.

Bin ich zu alt?

Gruss Chregu

[Jonas (Gast)]

Zu alt kann ich nicht beurteilen, aber womöglich zu sehr auf prozedural 
eingeschoßen.

Die Grundidee ist doch, dass du Objekte hast, welche für dich bestimmte 
Dinge tun bzw. bestimmte Dinge darstellen.

Wie die das genau machen, kann dir aber relativ egal sein. Was du nur 
willst, wie du dem Objekt informationen gibt´s und was du von ihm 
erwarten kannst.

So können Objekte einmal entstehen und stehen dann für eine bestimmte 
Tätigkeit, du musst nicht jedesmal den gesamten Code anpacken.
Es können sich dann auch Aufgaben geteilt werden, da Person A Objekt X 
macht und Person B Objekt Y und auf den anderen zugreifen, ohne zu 
wissen wie er es genau macht.

Soviel zumindest zur Theorie. Die Praxis wird dir ein erfahrerener OO 
Programmierer sagen können.

[Jan H. (j_hansen)]

Christian M. schrieb:
> ich bin im JS-Kurs jetzt bei den Objekten angelangt. Aber mir
> erschliesst sich der Sinn eines solch abstrakten Gebildes absolut nicht.
> Kann mir einer verklickern, wofür das gut sein soll?

Es gibt ungefähr sieben Trilliarden Webseiten und fünf Millionen Bücher 
zu dem Thema. Effizienter wäre es, du würdest dort einmal in zwei, drei 
Ressourcen hineinschauen und dann mit konkreten Fragen kommen.

> Im Kurs mach ich jetzt als Uebung eine Telephonliste von Freunden,
> komplizierter geht es ja wohl nicht, wie soll man da flexibel erweitern?

Weder kennt hier jemand den Kurs den du da machst, noch das Beispiel, 
udn warum das kompliziert sein soll.

> Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String
> manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die
> Zahl das Objekt sein...?!

Es gibt verschiedene Arten von Objekten. Strings sind jeweils ein Objekt 
mit Methoden. Das Math-Objekt hingegen ist einfach eine Sammlung von 
Methoden, mit denen man übergebene Zahlen bearbeiten kann usw.

> Intern wird es ja eh prozedural verarbeitet.

OOP ist für das Rundherum zuständig, die konkreten Anweisungen müssen 
natürlich z.B. prozedural geschrieben werden.

[Trolljäger (Gast)]

Christian M. schrieb:
> Bin ich zu alt?

Nein, zu troll.

Wenn du keiner bist, ignorier denn OOP-Kram. Triviale Projekte kannst du 
auch ohne lösen. Was anspruchsvolleres machst du offensichtlich nicht, 
denn dann würdest du keine so dumme Frage stellen.

[Sheeva P. (sheevaplug)]

Christian M. schrieb:
> ich bin im JS-Kurs jetzt bei den Objekten angelangt. Aber mir
> erschliesst sich der Sinn eines solch abstrakten Gebildes absolut nicht.
> Kann mir einer verklickern, wofür das gut sein soll?

Wofür könnten eine bessere Codeorganisation, definierte Schnittstellen, 
Modularisierung, Erweiterbarkeit und Wiederverwendbarkeit wohl gut sein? 
Vielleicht, um mit möglichst geringem Aufwand stabile, wartbare Software 
zu entwickeln.

> Im Kurs mach ich jetzt als Uebung eine Telephonliste von Freunden,
> komplizierter geht es ja wohl nicht, wie soll man da flexibel erweitern?

Der Sinn erschließt sich Dir möglicherweise erst, wenn Du es verstanden 
hast. Geht vielen so, die aus der prozeduralen Programmierung kommen. Am 
Anfang eines Kurses (was ist ein JS-Kurs? JavaScript?) schon zu 
erwarten, daß Du den vollen Durchblick hast, ist ein bisschen viel 
verlangt.

> Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String
> manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die
> Zahl das Objekt sein...?!

Da hier keiner Deinen Code kennt, kann Dir niemand sagen, was das 
Math.-Objekt ist und wozu es gut ist. Anhand des Namens vermute ich mal, 
daß es  irgendwas mit Mathematik zu tun hat, aber was das in einer 
Telefonliste zu suchen hat, erschließt sich mir (noch?) nicht.

> Bin ich zu alt?

Wenn Du "Telefon" noch mit "ph" schreibst, ... Womöglich weißt Du sogar 
noch, wie man ein Wählscheibentelefon bedient. :-)

[Mark B. (markbrandis)]

Christian M. schrieb:
> Aber mir erschliesst sich der Sinn eines solch abstrakten Gebildes absolut
> nicht.

Stichwort: Funktionen und Daten.

In der prozeduralen Programmierung sind beide voneinander getrennt. Man 
hat auf der einen Seite Datentypen und auf der anderen Seite Funktionen, 
die mit den Daten etwas anstellen.

In der OOP ist diese Trennung aufgehoben. Eine Klasse enthält sowohl die 
nötigen Datentypen als auch den nötigen Code, um das zu tun was ihre 
Aufgabe ist.

[Random .. (thorstendb)]

sagen dir "structs" etwas?
Damit bündelst du Daten, damit du einen gemeinsamen "Aufhänger" hast.

In der OOP kommen - vereinfacht gesagt - noch die Methoden hinzu.
Viele gehen noch weiter, und erlauben keinen direkten Zugriff auf die 
Variablen in einem (jetzt:) Objekt, sondern nur über GetXxx() und 
SetXxx() Methoden, welche die Daten vorher prüfen. Die Daten selbst sind 
dann idR. als privat deklariert und von aussen nicht direkt zugreifbar.

Jetzt kanst du weiterhin von Objekten erben. Beispielweise hast du ein 
Objekt (z.B. "Mensch"), welches Daten und Methoden (= Funktionen) für 
eine gemeinsame Basisfunktionalität bereitstellt (z.B. Name, Strasse, 
Hausnummer, PLZ, Ort, Land).
Dann schreibst du weitere Klassen, welche besondere, weitergehende 
Eigenschaften enthalten, und von der Basisklasse erben (z.B. zwei 
Klassen "Mann" und "Frau".)

Das klingt für dieses Beispiel vllt. etwas trivial, ist aber Teil der 
Grundidee.

Im anderen Fall stellst du beispielsweise eine gemeinsame Schnittstelle 
zur Verfügung.
So gibt es im Basisobjekt "GeoObject" die Variablen für eine Position, 
Farbe, Zeichenstärke etc., sowie eine (virtuelle) Funktion "Draw()".
Die Klassen "Rechteck, Quadrat, Kreis, Ellipse" erben von dieser, und 
implementieren selbst die Funktion "Draw()".
Der Teil deines Programms, welcher für das Zeichnen zuständig ist, 
braucht jetzt nur Objekte vom Typ "GeoObject" zu speichern, und kann 
diese über die Draw() Funktion zeichen.

[Karl (Gast)]

Lies dir das hier (und die weiteren Teile) durch, danach kannst du 
nochmal fragen:

https://wiki.delphigl.com/index.php/Tutorial_Softwareentwicklung1

[Der Andere (Gast)]

Trolljäger schrieb:
> Triviale Projekte kannst du auch ohne lösen.

Also ist entweder Linux ein triviales Projekt, oder der Troll bist du.

OOP ist eine (durchaus erfolgreiche) Methode/Art der Programmierung, 
nicht mehr und nicht weniger.

[Carl D. (jcw2)]

Das Math-Objekt ist schlicht eine Sammlung von Funktionen aus dem 
Bereich Mathematik, analog zu <math.h> für C-Programmierer.

Nur gibt es eben bei JavaScript keine andere Bündelungsmöglichkeit als 
das Objekt. Es kann als Namespace- oder Library-Ersatz benutzt werden, 
oder eben als Objekt im Sinne von OO. Und es ist für die 
Laufzeitumgebung die einzige Möglichkeit so was wie eine Bibliotek von 
Funktionen bereitzustellen.

Und man kann auch in fortgeschrittenem Alter Verständnis für JavaScript 
entwickeln, obwohl ich mir gut vorstellen kann, daß der erste Kontakt 
Fremdeln verursacht.

[Karl (Gast)]

Der Andere schrieb:
> Trolljäger schrieb:
>> Triviale Projekte kannst du auch ohne lösen.
>
> Also ist entweder Linux ein triviales Projekt, oder der Troll bist du.

Nur weil er geschrieben hat, dass man triviale Projekte ohne OOP lösen 
kann heißt das nicht, dass man schwierige Projekte nur mit OOP lösen 
kann. Die meisten Forenteilnehmer befinden sich auch nicht auf dem 
geistigem Niveau eines Linus Torvalds.

[Christian M. (Gast)]

Sheeva P. schrieb:
> Da hier keiner Deinen Code kennt, kann Dir niemand sagen, was das
> Math.-Objekt ist und wozu es gut ist. Anhand des Namens vermute ich mal,
> daß es  irgendwas mit Mathematik zu tun hat

Naja, eben, ich versuche es Momentan mit "Gehirnwäsche", also ich setz 
mich dem solange aus, bis es mir logisch ist:
https://youtu.be/txFu0VNSPbE?list=PLWjV3rrL77CAZGdXwnqJDUDXCCqh-Au-0
Nach diesem Video fragt nur einer, der noch nie mit OOP zu tun gehabt 
hat, was das Math.-Objekt ist!

Gruss Chregu

[Christian M. (Gast)]

Sheeva P. schrieb:
> Der Sinn erschließt sich Dir möglicherweise erst, wenn Du es verstanden
> hast. Geht vielen so, die aus der prozeduralen Programmierung kommen. Am

Ja, vielleicht. Ich lese immer: Ein Auto hat eine Farbe, eine Marke, 
vier Räder und macht "Hup Hup", aber ich habe gar kein Auto, und will 
auch nie Eins!

> Anfang eines Kurses (was ist ein JS-Kurs? JavaScript?) schon zu
> erwarten, daß Du den vollen Durchblick hast, ist ein bisschen viel
> verlangt.

OK, ich bleib dran! :-))

Vielleicht kann mir jemand ein konkretes Beispiel geben, wo OOP klar ein 
Vorteil ist gegenüber Prozedural. Und Nein, Trolljäger, vielleicht habe 
ich noch keine komplexeren Projekte gemacht, nur so kleines Zeug wie:
http://www.magnetmotor.ch/ibm.html
und
http://www.magnetmotor.ch/lcd-sim.html

Arbeite ja nicht bei LT oder MS :-))

Chregu

[Der Andere (Gast)]

Christian M. schrieb:
> Ja, vielleicht. Ich lese immer: Ein Auto hat eine Farbe, eine Marke,
> vier Räder und macht "Hup Hup", aber ich habe gar kein Auto, und will
> auch nie Eins!

Manchmal braucht man Autos, nicht überall sind so gute (aber auch teure) 
öffentliche Verkehrsmittel wie in der Schweiz :-)

OOP ist einfach eine Art ein Problem zu strukturieren. Es hat einige 
Vorteile gegenüber der rein prozeduralen Programmierung aber man kann 
sich damit auch wunderbar ins Knie schießen. Ich habe schon mehr 
Scheißcode in C++ gesehen als guten.
Versuch dich einfach unvoreingenommen auf die Ideen einzulassen. Wenn du 
von C oder Pascal aus kommst (oder sonstigen prozeduralen Sprachen) 
wirst du dir an Anfang im Wege stehen, dazu braucht es eine Menge Übung.

[TriHexagon (Gast)]

Mit OOP lässt sich viel einfacher robuste, fehlerfreie und erweiterbare 
Software entwickeln. Einerseits ist es dank Datenkapselung möglich 
fehlerhafte Programmzustände auszuschließen. Andererseits kann man 
existierende Software wunderbar mithilfe von Vererbung und Polymorphie 
erweitern und wiederverwenden. Wie man diese Mechanismen zu seinem 
Vorteil ausreizen kann sieht man besonders gut bei Entwurfsmuster wie 
z.B. Adapter, Observer etc..

[D. I. (Gast)]

Christian M. schrieb:
> Vielleicht kann mir jemand ein konkretes Beispiel geben, wo OOP klar ein
> Vorteil ist gegenüber Prozedural. Und Nein, Trolljäger, vielleicht habe
> ich noch keine komplexeren Projekte gemacht, nur so kleines Zeug wie:
> http://www.magnetmotor.ch/ibm.html
> und
> http://www.magnetmotor.ch/lcd-sim.html
>
> Arbeite ja nicht bei LT oder MS :-))
>
> Chregu

Ja bei so Mini-1-Mann-Projekten ist OOP nicht unbedingt notwendig. Bei 
Softwareprojekten in der Größenordnung von Mannjahren sieht das anders 
aus. Wenn du damit noch nicht in Kontakt gekommen bist, hattest du halt 
noch nicht mit professioneller Softwareentwicklung in größeren Projekten 
zu tun. Ist ja keine Schande etwas nicht zu verstehen wenn man damit 
nichts zu tun hat.

[Stefan S. (Gast)]

Nicht dass ich von diesem Thread irgend etwas gelesen hätte oder das 
vorhabe -- aber dass der OPP Hype, insbesondere die Vererbung etwas am 
abebben ist hatte ich ja schon mehrfach erwähnt. Siehe etwa

http://spf13.com/post/is-go-object-oriented/

und insbesondere auch die Links zu Reddit und HackerNews

https://news.ycombinator.com/item?id=7868485

https://www.reddit.com/r/golang/comments/27p2bc/is_go_an_object_oriented_language_spf13com/

Ich muss mir das auch noch mal in Ruhe durchlesen...

[Tim (Gast)]

Mark B. schrieb:
> In der OOP ist diese Trennung aufgehoben. Eine Klasse enthält sowohl die
> nötigen Datentypen als auch den nötigen Code, um das zu tun was ihre
> Aufgabe ist.

Nein. In manchen Ausprägungen von OOP ist das so. Im Allgemeinen nicht.

[Stefan S. (Gast)]

Ja, nicht OPP sondern OOP.

Und ECS wäre das neue Stichwort:

https://en.wikipedia.org/wiki/Entity_component_system

[Mark B. (markbrandis)]

Tim schrieb:
> Nein. In manchen Ausprägungen von OOP ist das so. Im Allgemeinen nicht.

Laut Definition in diesem Buch ist es so:
https://books.google.de/books?id=9NGWq3K1RwUC&pg=PA18&redir_esc=y&hl=en#v=onepage&q&f=false

In welcher konkreten Programmiersprache ist es denn anders?

[Md M. (Firma: Potilatormanufaktur) (mdma)]

Christian M. schrieb:
> http://www.magnetmotor.ch/ibm.html

Ist das kommerziell? Dann solltest du die Rechtschreibung nochmal 
prüfen.
Was ist das überhaupt für ein geiler Online-Shop? Das Sortiment besteht 
nur aus BC547C und 1N4148. Und beides im 100er-Pack. Also wenn ich das 
mal brauche, bestelle ich auf jeden Fall bei dir :-)

[Michael B. (laberkopp)]

Christian M. schrieb:
> OOP - für was in aller Welt soll denn das gut sein?

Du zeigst ja nicht mal das Programm aus dem Kurs.

Da kann man nicht beurteilen, ob dir der Dozent vielleicht 
unverständlich/unlogisches serviert hat.

ABER: Wenn du in prozeduralen Sprachen irgendwelche Module
schreiben willst die du an jemand anderen geben kannst, dann
packst du die in eine DLL (Library).

Diese DLL exportiert nach aussen nur Funktionen, damit dir
der Fremde Mensch nicht unkontrolliert an deinen Daten
rumfummelt.

Und wenn diese DLL nicht bloss einen Datensatz verarbeiten
soll sondern mehrere verschiedene, dann brauchst du auch
Funktionen um neue Daten anzulegen.

Schon bist du beim objektorientierten Programmieren, mit
einer Klasse (deine DLL), und Methoden die auf versteckte
(private) Daten arbeiten, und Funktionen um neue Instanzen
der Klasse (Datensätze) anzulegen bzw. wegzuwerfen.

Deine Windows Programme sind nicht anders strukturiert,
dort hast du Fenster (HWND) in Klassen, und von dort
kennst du auch den Weg, um ein Standardfenster (z.B.
einer Edit-Box) andere Eigenschaften zu geben (z.B.
syntaxhighlighting): Du baust eine Unterklasse (WndProc)
die nur die Methoden (Messages) behandelt die anders sind
und ansonsten weiterleitet.

u.s.w. ist OOP eigentlich eine logische Folge. Aber wie bei
allen Methoden gibt es Leute die sie nicht verstanden haben
und dogmatisch befolgen, dann sind die Ergebnisse meistens
unlogisch und bringen viel overhead.

[Rolf M. (rmagnus)]

Mark B. schrieb:
> In welcher konkreten Programmiersprache ist es denn anders?

In C, oder jeder anderen Programmiersprache, bei der das OOP-Konzept 
nicht bereits in der Sprache selbst verankert ist.
OOP ist nicht einfach ein Element der Syntax einer Sprache, sondern ein 
Programmierkonzept, das man im Prinzip in jeder Sprache umsetzen kann - 
in der einen besser, in der anderen weniger gut.
Grundelement von OOP ist daher auch nicht, dass man Code und Daten nun 
in einen gemeinsamen Block schreibt. Viel mehr geht's um ganz andere 
Dinge wie z.B. Vererbung und Polymorphie.
Was das "Math"-Objekt betrifft, ist das ein Zugeständnis. Hier wird 
etwas, das eigentlich grundlegend prozedural ist und gar nichts mit OOP 
zu tun hat, in ein Objekt-Korsett gesteckt. Für das Verständnis von OOP 
sollte man solche Dinge erstmal beiseite lassen.

[Daniel A. (daniel-a)]

Bei OOP ist die Idee, ein Objekt durch seine Eigenschaften und darauf 
anwendbaren Aktionen zu beschreiben.

Je nach Programmiersprache gibt es Variationen, wie OOP umgesetzt oder 
wird. Haufig wird nur über Funktionen des Objekts dessen Daten 
verändert. Dadurch kann ein von den Daten entkoppeltes Interface 
definiert werden, das sich auf alle Objekte die diesem genügen anwenden 
lässt. Dies ist vor allem in Java populär. Andere Sprachen wie c und Go 
verfolgen eine andere Philosophie. Dort hat man structs, die auch andere 
Structs beinhaltenkönnen, und Funktionen die diese als Argument nehmen. 
Es ist der Unterschied zwischen "Ein Objekt ist eine Sammlung von darauf 
anwendbaren Methoden" und "Ein objekt ist eine Samlung von 
Eigenschaften, welches von Funktionen verarbeitet werden kann". Beide 
Sichtweisen haben ihre vor- und nachteile.

Bei JS gibt es einen grossen unterschied zwischen ES6 (ECMAScript 2015) 
und ES5. Bei ES6 gibt es das class keyword, bei ES5 musste man aufwendig 
mit Funktionen und Prototypen arbeiten.

Was Vererbung angeht, das ist ein Konzept um Redundanz zu verringern. 
Man kann es übertreiben, und manche sprachen können Mehrfachvererbung, 
und manche nicht. Es ist ein bischen ein Zweischneidiges schwert.

[vn nn (Gast)]

Beitrag "Re: Wieso Objektorientiert?"
Beitrag "Re: Verständnis OOP für hardwarenahe Programmierer"

[Karl (Gast)]

Rolf M. schrieb:
> Mark B. schrieb:
>> In welcher konkreten Programmiersprache ist es denn anders?
>
> In C, oder jeder anderen Programmiersprache, bei der das OOP-Konzept
> nicht bereits in der Sprache selbst verankert ist.
> OOP ist nicht einfach ein Element der Syntax einer Sprache, sondern ein
> Programmierkonzept, das man im Prinzip in jeder Sprache umsetzen kann -
> in der einen besser, in der anderen weniger gut.

You Can Write FORTRAN in any Language

[Mark B. (markbrandis)]

Rolf M. schrieb:
> Mark B. schrieb:
>> In welcher konkreten Programmiersprache ist es denn anders?
>
> In C, oder jeder anderen Programmiersprache, bei der das OOP-Konzept
> nicht bereits in der Sprache selbst verankert ist.
> OOP ist nicht einfach ein Element der Syntax einer Sprache, sondern ein
> Programmierkonzept, das man im Prinzip in jeder Sprache umsetzen kann -

Je nun... das stimmt schon. Die meisten Leute würden wohl trotzdem die 
Sprache C nicht unbedingt als OOP-Sprache einstufen, sondern als 
imperative, prozedurale Sprache.

Also anders gefragt:
Gibt es eine Programmiersprache, die "von Haus aus" OOP unterstützt, und 
bei der Daten und Funktionen durch das Konzept der Klasse keine 
Einheit bilden?

[Daniel A. (daniel-a)]

Mark B. schrieb:
> Also anders gefragt:
> Gibt es eine Programmiersprache, die "von Haus aus" OOP unterstützt, und
> bei der Daten und Funktionen durch das Konzept der Klasse keine
> Einheit bilden?

GO? https://en.wikipedia.org/wiki/Go_(programming_language)

Man kann Methoden auf Objekten aufrufen, aber die Methoden sind nicht in 
der Objektbeschreibung definiert, sondern als Funktionen ausserhalb.

[Marc (Gast)]

Mark B. schrieb:
> Tim schrieb:
>> Nein. In manchen Ausprägungen von OOP ist das so. Im Allgemeinen nicht.
>
> Laut Definition in diesem Buch ist es so:
> https://books.google.de/books?id=9NGWq3K1RwUC&pg=P...

Wieso sollte der Autor relevant sein? Kennt den jemand?

> In welcher konkreten Programmiersprache ist es denn anders?

In Common Lisp. In Perls Moose ist es wohl genauso, aber Perl kenne ich 
nicht wirklich.

[c-hater (Gast)]

Rolf M. schrieb:

> Was das "Math"-Objekt betrifft, ist das ein Zugeständnis. Hier wird
> etwas, das eigentlich grundlegend prozedural ist und gar nichts mit OOP
> zu tun hat, in ein Objekt-Korsett gesteckt.

Nein. Ein Objekt ist die Instanz einer Klasse. Die Zusammenfassung 
der Methoden, die für alle Instanzen der gleichen Klasse benutzt 
werden und der Daten, die jeweils nur für die einzelne Instanz gelten.

Dieses math-Dingens ist also üblicherweise eben kein Objekt, sondern nur 
eine (nicht instanziierbare) Klasse. Eben weil es darin keine Daten 
gibt, sondern nur Methoden.

Allerdings: so ganz sauber ist die Unterscheidung auch wieder nicht, 
denn es gibt in vielen OOP-Sprachen auch Daten, die direkt zur Klasse 
gehören. Das betrifft natürlich vor allem Konstanten. Beim Beispiel math 
etwa: math.Pi

Wie auch immer: Um OOP zu verstehen, muss man als allererstes den 
Unterschied zwischen einer Klasse und ihren Instanzen, also aus der 
Klasse konstruierten Objekten verstehen, sonst wird das nix.

Aber ja, ich gebe zu, dass ich auch schwere Probleme hatte, mir diesen 
OOP-Kram zu verinnerlichen. Dabei war es für mich noch vergleichsweise 
einfach, weil ich von rein prozeduraler Programmierung mit Pascal auf 
Object Pascal umgestiegen bin und obendrein Assembler konnte, so dass 
ich jederzeit hinter die Kulissen gucken konnte, was da eigentlich genau 
passiert. Trotzdem habe ich ungefähr ein Jahr aktive Programmierung 
benötigt, um wirklich "OOP zu denken" und Programme von Grund auf 
entsprechend zu designen.

Für eingefleischte C-ler, die für OOP-Konzepte naturgemäß auf C++ 
umsteigen müssten, ist die Hölle definitiv um vieles heisser...

[Dussel (Gast)]

Das größte Problem sehe ich darin, dass objektorientierte Programmierung 
anscheinend meistens an winzigen Beispielprogrammen gezeigt wird. Da ist 
sie deutlich aufwendiger, als das Programm einfach prozedural zu 
schreiben, ohne dass dadurch ein Vorteil entsteht.
Erst wenn man mal ein großes Programm schreibt und weiß, dass es sowas 
wie objektorientierte Programmierung gibt, werden die Vorteile klar.

[Stefan S. (Gast)]

Dussel schrieb:
> Erst wenn man mal ein großes Programm schreibt und weiß, dass es sowas
> wie objektorientierte Programmierung gibt, werden die Vorteile klar.

Aber auch umgekehrt: Im Lehrbuch hat man ein schönes Beispiel wo OOP 
schön funktioniert, aber in der Praxis ist alles komplizierter und 
unschöner.

[Rolf M. (rmagnus)]

c-hater schrieb:
> Rolf M. schrieb:
>
>> Was das "Math"-Objekt betrifft, ist das ein Zugeständnis. Hier wird
>> etwas, das eigentlich grundlegend prozedural ist und gar nichts mit OOP
>> zu tun hat, in ein Objekt-Korsett gesteckt.
>
> Nein. Ein Objekt ist die Instanz einer Klasse.

Ach was, mach Sachen!
Und das ist auch der Sinn von Klassen - dass man sie instanziiert, oder 
zumindest davon ableitet. Eine Klasse, die ausschließlich statische 
Elemente hat, sollte meiner Meinung nach gar keine Klasse sein. Bei 
Sprachen, die Funktionen nur in Klassen zulassen, geht's aber nicht 
anders, und das meinte ich damit, dass Dinge, die eigentlich nichts mit 
OOP zu tun haben, in ein Objekt-Korsett gesteckt werden. Vielleicht 
hätte ich besser Klassen-Korsett sagen sollen.

[Paul B. (paul_baumann)]

Rolf M. schrieb:
> Eine Klasse, die ausschließlich statische
> Elemente hat, sollte meiner Meinung nach gar keine Klasse sein.

Das ist auch die Ansicht vieler Berufsschul-Lehrer.

MfG Paul

[Daniel A. (daniel-a)]

Rolf M. schrieb:
> Eine Klasse, die ausschließlich statische
> Elemente hat, sollte meiner Meinung nach gar keine Klasse sein.

Ich denke das korrekte Sprachelement dafür sind Namespaces. Namespaces 
sind das einzige, das ich in C gegenüber C++ vermisse, und sie werden 
viel zu selten verwendet. Ich denke der Ersatz in z.B. Java mittels 
Packages und Klassen ist durchaus vertretbar.

Stefan S. schrieb:
> Aber auch umgekehrt: Im Lehrbuch hat man ein schönes Beispiel wo OOP
> schön funktioniert, aber in der Praxis ist alles komplizierter und
> unschöner.

Ja, man muss auf vieles Aufpassen. z.B. das man keine Kreise von 
Ellipsen ableitet, oder umgekehrt. Oder dass man keine Interfaces nutzt, 
und dann Mehrfachvererbung brauchte. Oder dass man eine Sendefunktion 
hat, deren Sendepuffer aber aufgefüllt werden könnte, und man nichts 
anderes machen kann bis der Puffer wieder leer wird ohne das Design zu 
ändern. Oder wenn man plötzlich vor Singelton Repository Factory Factory 
Factory Beans steht. Oder wenn man plötzlich zwei Ballklassen ohne 
gemeinsames Interface hat. Oder...

Natürlich funktioniert das auch umgekehrt.

[T.roll (Gast)]

OOP wurde für Leute gemacht, die nicht wie ein Computer denken können. 
OOP soll dem "menschlichen" Denken ähnlicher sein. Deswegen bauen die 
Klassen normal aufeinander auf: z.B. Hosentasche→Hose→Kleisung

Das Problem an der immer extremeren Extrahierung ist die massiv 
steigende Prozessorlast. OOP hat durch diese Verschachtelung einen 
großen Overhead, weil ein Computer eben nicht wie ein Mensch denkt.

[TriHexagon (Gast)]

T.roll schrieb:
> OOP wurde für Leute gemacht, die nicht wie ein Computer denken können.
> OOP soll dem "menschlichen" Denken ähnlicher sein. Deswegen bauen die
> Klassen normal aufeinander auf: z.B. Hosentasche→Hose→Kleisung
>
> Das Problem an der immer extremeren Extrahierung ist die massiv
> steigende Prozessorlast. OOP hat durch diese Verschachtelung einen
> großen Overhead, weil ein Computer eben nicht wie ein Mensch denkt.

Na wenigstens steht er zudem was er ist, das kann man von anderen nicht 
behaupten ;)

[Sheeva P. (sheevaplug)]

Daniel A. schrieb:
> Mark B. schrieb:
>> Also anders gefragt:
>> Gibt es eine Programmiersprache, die "von Haus aus" OOP unterstützt, und
>> bei der Daten und Funktionen durch das Konzept der Klasse keine
>> Einheit bilden?
>
> GO? https://en.wikipedia.org/wiki/Go_(programming_language)
>
> Man kann Methoden auf Objekten aufrufen, aber die Methoden sind nicht in
> der Objektbeschreibung definiert, sondern als Funktionen ausserhalb.

Laut dem verlinkten Artikel ist Go allerdings nicht 
objektorientiert...

Nach Alan Kay gibt es drei wesentliche Eigenschaften, die eine 
OO-Sprache auszeichnen: Datenkapselung, Polymorphie, und Vererbung. Der 
Mann sollte es wissen, schließlich hat er es erfunden. :-)

Datenkapselung bedeutet, daß Daten und Routinen nicht mehr von einander 
getrennt sind, sondern zu Objekten zusammengefaßt werden, in welchen die 
Daten (Eigenschaften) den Zustand (state) und die Routinen (Methoden) 
das Verhalten (behaviour) eines Objekts festlegen.

Polymorphie heißt, daß eine Methode je nachdem, mit welchen Parametern 
sie aufgerufen wurde, unterschiedliche Dinge tut. Eine Methode "add", 
die mit zwei Integers aufgerufen wird, wird diese beiden addieren und 
das Ergebnis der Addition zurückgeben. Aber eine Methode "add", die mit 
zwei Strings aufgerufen wird, wird diese konkatenieren: 3 + 3 = 6, "a" + 
"b" => "ab".

Die dritte Eigenschaft, die eine OO-Sprache ausmacht, ist Vererbung. Das 
heißt, ich kann ein Objekt von einem anderen erben lassen und damit 
dessen Eigenschaften und Methoden übernehmen, überschreiben, oder durch 
weitere Methoden verändern.

[Sheeva P. (sheevaplug)]

Marc schrieb:
> Mark B. schrieb:
>> In welcher konkreten Programmiersprache ist es denn anders?
>
> In Common Lisp. In Perls Moose ist es wohl genauso, aber Perl kenne ich
> nicht wirklich.

Perl{5,6} und auch Moose machen das ganz klassisch, nur daß die 
Definition da nicht Klasse, sondern Package heißt.

[Sheeva P. (sheevaplug)]

T.roll schrieb:
> OOP wurde für Leute gemacht, die nicht wie ein Computer denken können.

Nö. OOP wurde für Leute gemacht, die komplexe Probleme lösen müssen.

> OOP soll dem "menschlichen" Denken ähnlicher sein. Deswegen bauen die
> Klassen normal aufeinander auf: z.B. Hosentasche→Hose→Kleisung

Nö. OOP bietet verschiedene Arten einer Beziehung. So ist die 
Hosentasche üblicherweise Bestandteil einer Hose (Beziehungstyp has-a), 
welche wiederum eine Spezialisierung eines Kleidungsstücks 
(Beziehungstyp is-a) ist.

> Das Problem an der immer extremeren Extrahierung ist die massiv
> steigende Prozessorlast. OOP hat durch diese Verschachtelung einen
> großen Overhead, weil ein Computer eben nicht wie ein Mensch denkt.

Nö, moderne Compiler optimieren das einfach weg. Es gibt ein paar 
Features der OOP, die Kosten verursachen -- in C++ etwa Exceptions -- 
aber wenn man diese Features vermeidet, ist das Binary am Ende kein Byte 
größer als eine klassische prozedurale Implementierung.

[Daniel A. (daniel-a)]

Sheeva P. schrieb:
> Laut dem verlinkten Artikel ist Go allerdings nicht
> objektorientiert...

Es wurde bei der englischen version nicht explizit als solche 
spezifiziert, aber auf der Deutschen version schon. Gemäss der 
offiziellen FAQ sind beide Ansichten richtig:
https://golang.org/doc/faq#Is_Go_an_object-oriented_language

> Nach Alan Kay gibt es drei wesentliche Eigenschaften, die eine
> OO-Sprache auszeichnen: Datenkapselung, Polymorphie, und Vererbung. Der
> Mann sollte es wissen, schließlich hat er es erfunden. :-)

Die Erde dreht sich weiter. Wie ich in meinen vorherigen beiträgen 
bereits andeute, betrachte ich das OOP Konzepte nicht so strict:
 * Obwohl in go methoden nicht in den Structs declariert werden, kann 
man dennoch methoden zu Datentypen definieren, die man ganz normal auf 
dem Objekt aufrufen kann, also zu diesem gehören. Deshalb betrachte ich 
die Datenkapselung als erfüllt. Ich finde diese version ist sogar 
flexibler.
 * Obwohl die von dir beschriebene Form der Polymorphie, so nicht direkt 
vorkommt, stellt dein Beispiel kein Problem dar. Entweder du hast ein 
anderes Objekt auf welchem die Methode aufgerufen wird, das geht in go, 
oder du gibst der concat funktion den korrekten Namen. Aber weshalb soll 
das feature notwendig sein, um ein Objekt zu beschreiben? Es hat keinen 
Einfluss auf Inhalt, Methoden, Funktionalität oder Verwendung des 
Objekts, es ist also ein unnötiges Feature.
 * Obwohl es in go keine Vererbung gibt, haben anonyme strukt member 
exakt den selben Effekt. Aber es ist besserer stil, statdessen 
interfaces zu verwenden. Dadurch vermeidet man auch unnötige OO 
probleme.

PS: Ich habe noch keine go programme geschrieben, und es gibt auch dinge 
die mir daran nicht gefallen, aber einige von deren Konzepten sind 
einfach verdammt gut.

[Rolf M. (rmagnus)]

Sheeva P. schrieb:
> Nach Alan Kay gibt es drei wesentliche Eigenschaften, die eine
> OO-Sprache auszeichnen: Datenkapselung, Polymorphie, und Vererbung. Der
> Mann sollte es wissen, schließlich hat er es erfunden. :-)
>
> Datenkapselung bedeutet, daß Daten und Routinen nicht mehr von einander
> getrennt sind, sondern zu Objekten zusammengefaßt werden, in welchen die
> Daten (Eigenschaften) den Zustand (state) und die Routinen (Methoden)
> das Verhalten (behaviour) eines Objekts festlegen.

Hmm, für mich ist Datenkapselung eher, dass man auf die Daten nicht 
direkt zugreifen kann, sondern nur über bereitgestellte Funktionen. Man 
weiß nicht mal, wie die Daten sind. Das ist für mich etwas, das bei OOP 
wichtig ist, aber nicht unbedingt ein OOP-Konzept. In C gibt es den 
FILE*, den ich von fopen() zurückbekomme und auf den ich nie direkt 
zugreife, sondern ihn nur an andere File-Funktionen übergebe. Das ist 
für mich auch Datenkapselung, aber nicht OOP.

> Polymorphie heißt, daß eine Methode je nachdem, mit welchen Parametern
> sie aufgerufen wurde, unterschiedliche Dinge tut. Eine Methode "add",
> die mit zwei Integers aufgerufen wird, wird diese beiden addieren und
> das Ergebnis der Addition zurückgeben. Aber eine Methode "add", die mit
> zwei Strings aufgerufen wird, wird diese konkatenieren: 3 + 3 = 6, "a" +
> "b" => "ab".

Das, was du beschreibst, ist eher einfache Funktionsüberladung. Das 
wesentliche Element von Polymorphie ist, dass man beim Aufruf der 
Funktion den Typ des Objekts gar nicht kennt. Deshalb wird zur Laufzeit 
automatisch entschieden, welche Funktion dann tatsächlich aufgerufen 
werden soll ("dynamic dispatch"). Wenn die Entscheidung, welche Funktion 
aufzurufen ist, ähnlich deinem Beispiel von zwei oder mehr Objekten 
abhängig ist, spricht man von multiple dispatch, was in keiner mir 
bekannten OOP-Sprache direkt umgesetzt ist.

[Christian M. (Gast)]

Nochmal schnell zu JS und meinem Unverständnis:

Jan H. schrieb:
>> Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String
>> manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die
>> Zahl das Objekt sein...?!
>
> Es gibt verschiedene Arten von Objekten. Strings sind jeweils ein Objekt
> mit Methoden. Das Math-Objekt hingegen ist einfach eine Sammlung von
> Methoden, mit denen man übergebene Zahlen bearbeiten kann usw.

Verstehe ich jetzt das richtig: Strings (als Variablen) sind Objekte, 
die Methoden haben, aber Zahlen (auch Variablen) sind keine Objekte, da 
muss man mit deM Math-Objekt (deren Methoden) "bearbeiten"?! => 
Unlogisch und unkonsequent, oder?!

Danke,
Gruss Chregu

[Tobias (Gast)]

Christian M. schrieb:
> Verstehe ich jetzt das richtig: Strings (als Variablen) sind Objekte,
> die Methoden haben,

Strings sind erstmal Strings. Punkt.
Wenn du zum String Methoden hinzufügst (z.B. set, get), dann erhältst du 
ein Objekt. In der Regel verbirgt man die string-Variable vor dem 
Zugriff von außen und erlaubt jegliche Veränderung nur über Methoden. 
Damit vermeidet man unerwünschte Veränderungen...

[(prx) A. K. (prx)]

Christian M. schrieb:
> Verstehe ich jetzt das richtig: Strings (als Variablen) sind Objekte,
> die Methoden haben, aber Zahlen (auch Variablen) sind keine Objekte, da
> muss man mit deM Math-Objekt (deren Methoden) "bearbeiten"?! =>

Hängt von der Sprache ab. Manche OOP Sprachen, wie etwa C++, 
unterscheiden zwischen Variablen, die Objekte im Sinn von 
Klasseninstanzen sind, und anderen Daten, die keine Objekte sind. In 
Sprachen wie Smalltalk sind hingegen alle Daten Objekte und die üblichen 
mathematischen Operatoren sind auch nur Methoden.

[Sheeva P. (sheevaplug)]

Daniel A. schrieb:
> Sheeva P. schrieb:
>> Laut dem verlinkten Artikel ist Go allerdings nicht
>> objektorientiert...
>
> Es wurde bei der englischen version nicht explizit als solche
> spezifiziert, aber auf der Deutschen version schon.

Die deutschsprachige Wikipedia schreibt aber auch: "Auf Klassen wird 
bewußt verzichtet". Tatsächlich ist die Datenkapselung aber eine der 
wesentlichen Eigenschaften der OO. Wenn Go die nicht umsetzt, dann ist 
es leider auch keine OO-Sprache, gleichgültig, was seine Entwickler 
behaupten oder was in der deutschsprachigen Wikipedia steht.

> Gemäss der offiziellen FAQ sind beide Ansichten richtig:
> https://golang.org/doc/faq#Is_Go_an_object-oriented_language

Aus dieser FAQ: "Go takes a different approach."

Ok, "Go verfolgt einen anderen Ansatz". Kein Problem -- aber ein anderer 
Ansatz, dem wesentliche Eigenschaften der Objektorientierung fehlen, ist 
eben kein objektorientierter Ansatz. Ich verstehe nicht, wie man auf der 
einen Seite sagen kann, man habe einen besseren Ansatz gefunden, der dem 
OO-Ansatz überlegen sei, auf der anderen Seite aber behauptet, der neue 
Ansatz sei in Wirklichkeit dann irgendwie doch objektorientiert, obwohl 
dabei wesentliche Teile dessen fehlen, was OO ausmacht. Sorry, aber das 
ist doch schizophren.

>> Nach Alan Kay gibt es drei wesentliche Eigenschaften, die eine
>> OO-Sprache auszeichnen: Datenkapselung, Polymorphie, und Vererbung. Der
>> Mann sollte es wissen, schließlich hat er es erfunden. :-)
>
> Die Erde dreht sich weiter.

Natürlich. Aber OO hat bestimmte Eigenschaften. Wenn die erfüllt sind, 
ist es OO. Wenn nicht, dann nicht.

[Michael B. (laberkopp)]

Sheeva P. schrieb:
> Sorry, aber das ist doch schizophren.

Aber Marketing. Hast du da jemals was anderes gehört ?

XML löst endlich alle Dateiformatprobleme, Scrum alle 
Programmierprobleme, Java ermöglicht plattformunabhängige Programmierung 
und WYSIWYG ist was für die Deppen von früher heute können wir aus 
HTML-Quelltext das Ergenis sehen.

[Sheeva P. (sheevaplug)]

Rolf M. schrieb:
> Sheeva P. schrieb:
>> Nach Alan Kay gibt es drei wesentliche Eigenschaften, die eine
>> OO-Sprache auszeichnen: Datenkapselung, Polymorphie, und Vererbung. Der
>> Mann sollte es wissen, schließlich hat er es erfunden. :-)
>>
>> Datenkapselung bedeutet, daß Daten und Routinen nicht mehr von einander
>> getrennt sind, sondern zu Objekten zusammengefaßt werden, in welchen die
>> Daten (Eigenschaften) den Zustand (state) und die Routinen (Methoden)
>> das Verhalten (behaviour) eines Objekts festlegen.
>
> Hmm, für mich ist Datenkapselung eher, dass man auf die Daten nicht
> direkt zugreifen kann, sondern nur über bereitgestellte Funktionen. Man
> weiß nicht mal, wie die Daten sind. Das ist für mich etwas, das bei OOP
> wichtig ist, aber nicht unbedingt ein OOP-Konzept. In C gibt es den
> FILE*, den ich von fopen() zurückbekomme und auf den ich nie direkt
> zugreife, sondern ihn nur an andere File-Funktionen übergebe. Das ist
> für mich auch Datenkapselung, aber nicht OOP.

Wie, Du hast noch nie den Filedescriptor aus einem FILE*-Handle heraus 
gefiddelt? :-)

Nee, echt jetzt: Fachbegriffe haben die Aufgabe, bestimmte Dinge für 
Fachleute greif- und benennbar zu machen. Wenn sich jeder seine eigene 
Definition zulegt, kommen wir nach Babylon. Ein FILE*-Handle ist keine 
Datenkapselung, sondern schlicht eine Datenstruktur, nicht weniger, aber 
auch nicht mehr. Datenstrukturen sind der Kern jeder Datenkapselung, 
gehen aber über die reine Strukturierung von Daten hinaus.

>> Polymorphie heißt, daß eine Methode je nachdem, mit welchen Parametern
>> sie aufgerufen wurde, unterschiedliche Dinge tut. Eine Methode "add",
>> die mit zwei Integers aufgerufen wird, wird diese beiden addieren und
>> das Ergebnis der Addition zurückgeben. Aber eine Methode "add", die mit
>> zwei Strings aufgerufen wird, wird diese konkatenieren: 3 + 3 = 6, "a" +
>> "b" => "ab".
>
> Das, was du beschreibst, ist eher einfache Funktionsüberladung. Das
> wesentliche Element von Polymorphie ist, dass man beim Aufruf der
> Funktion den Typ des Objekts gar nicht kennt. Deshalb wird zur Laufzeit
> automatisch entschieden, welche Funktion dann tatsächlich aufgerufen
> werden soll ("dynamic dispatch").

Dynamic Dispatching ist eines der Elemente von Polymorphie, virtuelle 
Funktionen, das Überladen von Funktionen und Operatoren etc. sind andere 
Elemente, die dazugehören. Im Kern dreht sich alles darum, dieselben 
Schnittstellen mit unterschiedlichen Datentypen nutzen zu können.

Gerade am Wegesrand gefunden: http://openbook.rheinwerk-verlag.de/oop/

[Sheeva P. (sheevaplug)]

Christian M. schrieb:
> Verstehe ich jetzt das richtig: Strings (als Variablen) sind Objekte,
> die Methoden haben, aber Zahlen (auch Variablen) sind keine Objekte, da
> muss man mit deM Math-Objekt (deren Methoden) "bearbeiten"?! =>
> Unlogisch und unkonsequent, oder?!

In JavaScript sind Zahlen Objekte, und haben Eigenschaften und Methoden. 
Da man aber nicht ständig Funktionen wie sin(), max() oder exp() 
braucht, ist es durchaus sinnvoll, diese Funktionen nicht direkt an die 
Zahl-Objekte zu klemmen, sondern sie in eine eigene Einheit auszulagern 
-- und genau diese Funktion hat das Math-Objekt, das mathematische 
Funktionen und Konstanten bündelt. Dadurch bleibt der globale Namensraum 
sauber, und die einzelnen Number-Objekte bleiben klein und performant.

Entschuldige, aber was ist eigentlich Dein Ziel? Wolltest Du nun 
JavaScript lernen oder dessen Entwicklern Fehler nachweisen? Wenn Du 
alles, das Du noch nicht verstehst, gleich als "unlogisch und 
unkonsequent" abtust, wirst Du vermutlich nicht allzu weit kommen. Und 
wenn Du den JavaScript-Entwicklern die Unzulänglichkeiten von JavaScript 
nachweisen willst, dann gib' Dir keine Mühe: das hat Douglas Crockford 
in "JavaScript: The Good Parts" bereits sehr ausführlich und überaus 
kompetent getan.

[Vancouver (Gast)]

Der Sinn der OOP wird klarer, wenn Du etwas kompliziertere Objekte 
betrachtest als Zahlen und Strings. Angenommen, Du willst eine 
Bibliothek für Vektorarithmetik schreiben. Einen Vektor kannst Du auf 
verschiedene Arten implementieren, z.B. als Array, als verkettete Liste, 
als feste Anzahl einzelner Variablen. Wenn Du jetzt eine Funktion hast, 
um Vektoren zu addieren, dann sieht diese Funktion für alle drei 
Implementierungen völlig unterschiedlich aus. Der Array-Methode musst Du 
zwei Array-Pointer übergeben, der Listenmethode zwei Listenpointer, der 
Variablenmethode eine Haufen einzelner Werte.
Beim Objektorientierten Ansatz ist Dein Vektor in ein Objekt gekapselt. 
Statt einer Funktion rufst Du eine Additions-Methode des Objekts auf und 
übergibst als Parameter ein anderes Vektorobjekt. Dabei spielt die 
interne Implementierung eines Objekts überhaupt keine Rolle. Für den 
Benutzer ist das eben ein Vektor und sonst nichts. Du kannst die 
verschiedenen Vektorklassen beliebig gegeneinander austauschen, ohne 
dass Du Deine Software ändern musst. Die Methoden abstrahieren so weit 
von der internen Darstellung des Vektors, dass Du sie verwenden kannst, 
ohne die Details zu kennen. Änderungen an der Vektorklasse erfordern 
keine Änderung am Programm. Wenn Deine Software irgendwann auf einem 
echten Vektorprozessor laufen soll, der z.B. Vektoraddition in der 
Hardware unterstützt, dann leitest Du aus der alten Vektorklasse eine 
neue ab, die die Vektoradditiion an die Hardware durchreicht und alle 
übrigen Funktionen wie bisher an das alte Vektorrobjekt weitergibt. Das 
nennt man Vererbung.
Du darfst nicht den Fehler machen, die Kapselung in Objekte als 
Einschränkung zu sehen. Objekte werden erst dadurch flexibel einsetzbar, 
dass sie ihren inneren Aufbau verbergen und vom Benutzer kein Wissen 
darüber voraussetzen.
Die Vorteile der OOP werden einem nicht so schnell klar, wenn man gerade 
damit anfängt, das ging mir auch so. Aber nach einer Weile willst Du 
nciht mehr darauf verzichten, Wobei es naürlich auch Situationen gibt, 
in denen sich OOP einfach nicht lohnt, z.B. auf kleinen 
Microcontrollern. Aber das Fass will ich hier nicht schon wieder 
aufmachen.

[Marc (Gast)]

Rolf M. schrieb:
> Wenn die Entscheidung, welche Funktion
> aufzurufen ist, ähnlich deinem Beispiel von zwei oder mehr Objekten
> abhängig ist, spricht man von multiple dispatch, was in keiner mir
> bekannten OOP-Sprache direkt umgesetzt ist.

Schon wieder Common Lisp.

[Sheeva P. (sheevaplug)]

Marc schrieb:
> Rolf M. schrieb:
>> Wenn die Entscheidung, welche Funktion
>> aufzurufen ist, ähnlich deinem Beispiel von zwei oder mehr Objekten
>> abhängig ist, spricht man von multiple dispatch, was in keiner mir
>> bekannten OOP-Sprache direkt umgesetzt ist.
>
> Schon wieder Common Lisp.

Ich hab ja heimlich den Verdacht, daß Lisp in Wahrheit Binärcode ist: 
"(" für eine 1, ")" für eine 0, alles andere sind Kommentare. :-)

[Michael B. (laberkopp)]

Sheeva P. schrieb:
> In C gibt es den
>> FILE*, den ich von fopen() zurückbekomme und auf den ich nie direkt
>> zugreife, sondern ihn nur an andere File-Funktionen übergebe. Das ist
>> für mich auch Datenkapselung, aber nicht OOP.
>
> Wie, Du hast noch nie den Filedescriptor aus einem FILE*-Handle heraus
> gefiddelt? :-)

Warum sollte er, dafür gibt es die Funktion fileno, sozusagen eine 
Memberfunktion von FILE zum Zugriff auf diese private Variable.

[Mark B. (markbrandis)]

Sheeva P. schrieb:
> Ich hab ja heimlich den Verdacht, daß Lisp in Wahrheit Binärcode ist:
> "(" für eine 1, ")" für eine 0, alles andere sind Kommentare. :-)

https://xkcd.com/224/

[Sheeva P. (sheevaplug)]

Michael B. schrieb:
> Sheeva P. schrieb:
>> Wie, Du hast noch nie den Filedescriptor aus einem FILE*-Handle heraus
>> gefiddelt? :-)
>
> Warum sollte er, dafür gibt es die Funktion fileno,

Ja, genau damit macht man das... Entschuldige, aber ich habe leider 
nicht verstanden, was Du mir damit sagen möchtest.

> sozusagen eine
> Memberfunktion von FILE zum Zugriff auf diese private Variable.

In C gibt es keine privaten Variablen. Ja, static existiert, ist aber 
was anderes als "private" in C++-Structs oder -Klassen.

[W.S. (Gast)]

Christian M. schrieb:
> Verstehe ich jetzt das richtig: Strings (als Variablen) sind Objekte,
> die Methoden haben

Laß mal deine konkrete Programmiersprache, die du grad übst, außen vor 
und betrachte das Ganze mit etwas größerem Abstand.

Also:

Stell dir vor, du müßtest irgend eine Anwendung schreiben, die mit 
vielen unterschiedlichen Dingen sich abgibt, wobei aber diese Dinge eine 
Reihe gleicher Anforderungen erfüllen müssen - das klassische Beispiel 
ist ein Grafikprogramm, wo man auf dem Bildschirm oder Drucker oder 
sonstiger Fläche eine Vielzahl von Dingen haben kann: Punkte, Kreise, 
Dreiecke, Vierecke, rote und blaue, gefüllte und ungefüllte. Die sind 
alle unterschiedlich, aber sie müssen in einigen Hinsichten gleich 
behandelt werden: speichern, laden, zeichnen, und so weiter.

Jetzt könntest du für jede Art dieser Dinge in einer umfänglichen 
Routine if ding=kreis else if ding=viereck.. usw. alle Varianten 
berücksichtigen, wenn es daran geht, all die Dinge, die der Grafiker auf 
seinem Bildschirm haben will zu zeichnen. Das ist umfänglich und wenn 
ein neues Ding dazukommt, mußt du deine Riesenroutine umschreiben, damit 
sie auch das neue Ding zeichnen kann.

Mit Objekten macht man das anders. Da hat so ein Objekt nicht nur seine 
Eigenschaften (wie XY-Position, Größe, Farbe usw), sondern auch seine 
Methoden und eine davon ist die Methode "Zeichne_Dich". Deine Routine 
zum Zeichnen aller Dinge des Bildes, was der Grafiker da grad entwirft, 
schnurrt deshalb auf Mini-Größe zusammen: for all do Zeichne_Dich; und 
jedes Objekt zeichnet sich selber - und zwar unabhängig von allen 
anderen Objekten. Dem Kreis ist es egal, wie ein Dreieck sich zeichnet. 
Er braucht bloß zu können, sich selbst zu zeichnen.

Genauso geht es, wenn dem Grafiker sein Bild nicht gefällt und er das 
eine Ding mehr nach rechts rücken will und das andere nach oben, oder 
das nächste etwas größer oder gedreht. Zu diesem Zweck haben all die 
Objekte des Grafikprogramms eine Reihe von Eigenschaften (Properties), 
die man von außen verändern kann (ohne wissen zu müssen, was man damit 
innerhalb des Objektes anrichtet), die aber bei allen gleich sind (dank 
Vererbung).

Die Koordinate ist ein typisches Beispiel.
Wenn du prozedural programmierst, mußt du auch für das Verrücken eines 
Kringels eine Riesenroutine starten, denn jedes Ding ist ja ein Record 
(oder in C ein Struct) und du kannst nicht mit dem gleichen Befehl auf 
Records (Struct's) von unterschiedlicher Definition zugreifen (ein 
struct Dreieck ist eben was anderes als ein struct Kreis).

Wenn man jedoch Kreis, Dreieck, Rechteck usw. von einem gemeinsamen 
Vorfahren "Kringel" ableitet, der solche Eigenschaften wie Koordinate, 
Drehwinkel, Größe, Farbe, Füllung usw. bereits in sich hat, dann kann 
man eben diese Eigenschaften bei allen Dingen auf dem Bild des Grafikers 
ändern, ohne unterscheiden zu müssen, um was für ein Ding es sich grad 
handelt. Also etwa so: Current_Kringel.X = 147 (egal ob es konkret ein 
Dreieck oder Viereck ist)

Kurzum: Wenn man mit einer Vielzahl von Dingen hantieren muß, die in 
gewisser Hinsicht alle gleich behandelt werden müssen, die aber dennoch 
innerlich unterschiedlich sind, dann ist OOP angesagt.

Für irgend eine blöde Variable inclusive Strings ist sowas hingegen 
Mumpitz. Da ist eine simple Zuweisung nebst Formel (wenn nötig) völlig 
ausreichend. Ein String.LöscheDich ist Unfug, String:='' tut's auch.

Etwas klarer jetzt?

W.S.

[Stefan S. (Gast)]

W.S. schrieb:
> Ein String.LöscheDich ist Unfug, String:='' tut's auch.

Wobei man etwas aufpassen muss. Letztere Anweisung kann in einigen 
Sprachen einen neuen, leeren String erzeugen, und der alte String muss 
vom GC entsorgt werden. Und dann ist da natürlich die Schreibweise -- 
clearString(str) bzw. str.clear. Wobei man für letzteres nicht unbedingt 
OOP benötigt, in DLang, Nim und einigen anderen Sprachen wird str.clear 
automatisch in den Funktionsaufruf clear(str) gewandelt. Dlang nennt das 
UFCS:

http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394

Bei Nim hat man zugegebener Weise das Problem, wenn man clear() vom 
Modul strings qualifiziert importiert, dann müsste man ja 
strings.clear(str) schreiben und str.strings.clear wäre nicht schön und 
funktioniert wohl auch nicht. Einige sehen da ein Problem, aber die 
meisten importieren einfach das ganze Modul, also alle Funktionen 
unqualifiziert, dann funktioniert es, und da andere gleichnamige 
Funktionen in der Regel andere Parameter haben gibt es auch meist keine 
Probleme. Und wenn doch, dann meckert der Compiler, und man muss eben 
den Modulnamen angeben.

[TriHexagon (Gast)]

Moby A. schrieb im Beitrag #4624966:
> Jan H. schrieb im Beitrag #4621860
>> Es gibt ungefähr sieben Trilliarden Webseiten und fünf Millionen Bücher
>> zu dem Thema.
>
> Die sind auch nötig.
> Das ist nichts was naturgegeben intuitiv und ohne steile Lernkurve
> einfach anzuwenden wär.
> OOP gibt vor Dinge zu vereinfachen, führt aber tatsächlich eine Menge
> neuer Bürokratie ein.
> Das lohnt sich erst bei grösseren Projekten.

Und wie wir wissen, spricht hier einer aus Erfahrung...

Ne echt jetzt, wie wär's wenn du das OOP Bashing mal unterlassen 
könntest. Du hast schlicht keine Ahnung davon. Du hast OOP noch nicht 
ein einziges Mal angewendet. Was außer einem ATtiny und Assembler kennst 
du überhaupt?

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4624966:
> Jan H. schrieb im Beitrag #4621860
>> Es gibt ungefähr sieben Trilliarden Webseiten und fünf Millionen Bücher
>> zu dem Thema.
>
> Die sind auch nötig.

Eigentlich sind die meisten davon ähnlich überflüssig wie Deine 
"Beiträge" zu diesem Thread hier. OO ist kein Hexenwerk, wobei es 
zugegeben ein wenig schwieriger ist, sie ausgerechnet an JavaScript mit 
einer etwas exotischen Realisierung der OO lernen zu wollen.

> OOP gibt vor Dinge zu vereinfachen, führt aber tatsächlich eine Menge
> neuer Bürokratie ein.
> Das lohnt sich erst bei grösseren Projekten.

OO ist auch bei kleinen Projekten sinnvoll, wenngleich die Stärken der 
OO mit zunehmender Projektgröße immer stärker zum Tragen kommen. Ab 
einer gewissen Projektgröße ist die Entwicklung ohne OO kaum noch 
beherrschbar.

In den meisten Fällen trägt OO allerdings sehr dazu bei, die 
Projektgröße kleiner und beherrschbarer zu machen, auch bei kleinen 
Projekten. Insofern führt OO keine Bürokratie ein, sondern hilft dabei, 
sie zu verringern und das Projekt insgesamt zu vereinfachen -- was 
naturgemäß zu fehlerärmerer, stabilerer und besser wartbarer Software 
führt.

Das kann man natürlich alles nicht wissen, wenn man OO nicht kennt und 
aus Angst vor dem Scheitern auch nicht lernen will. Und bevor Du jetzt 
schon wieder einen fremden Thread kaperst, lies' doch einfach Kapitel 2 
des von mir oben schon verlinkten Openbook. Dann kannst Du vielleicht 
wenigstens etwas halbwegs kompetentes zum Thema beitragen. :-)

[Carl D. (jcw2)]

Moby A. schrieb im Beitrag #4625040:
> TriHexagon schrieb:
>> Es gibt ungefähr sieben Trilliarden Webseiten und fünf Millionen Bücher
>> zu dem Thema.
>
> einfach mal zur Kenntnis zu nehmen.

Besser wäre "Erkenntnis gewinnen"

Leider sind eben 99,99% dieser Seiten für "Zur-Kenntnis-Nehmer" 
geschrieben.

Zudem kann man doch nicht OOP dafür verantwortlich machen, daß ein so 
geringer Anteil der IT-Schaffenden sie zur Lösung von Problemen 
einzusetzen versteht.
Ich entwickle täglich mit OO die Software, die mir einen Lebenunterhalt 
verdient. Und dann bin ich ja Anwender der üblichen 
PC-Software-Verdächtigen,

Moby A. schrieb im Beitrag #4625040:
> Damit muß dann um die Ecke gedacht werden. Alles im lächerlichen Namen der
> Vereinfachung?

 die MS aus welchen Gründen auch immer, durch "Um-die-Ecke-Denken" 
programmiert. Vielleicht sind diese Ecken ja für manche sehr straight 
und nur für die Anderen ein Hindernis beim Denken.

[Baku M. (baku)]

Um mal wieder auf den Ausganspost zurück zu kommen:
Christian M. schrieb:
> Hallo Programmierer,

Bin ich nicht, aber ich habe in meinem langen Leben schon viele Zeilen 
Software entwickelt. Ziemlich viele, und in verschiedensten Sprachen.

> ich bin im JS-Kurs jetzt bei den Objekten angelangt. Aber mir
> erschliesst sich der Sinn eines solch abstrakten Gebildes absolut nicht.
> Kann mir einer verklickern, wofür das gut sein soll?
> Im Kurs mach ich jetzt als Uebung eine Telephonliste von Freunden,
> komplizierter geht es ja wohl nicht, wie soll man da flexibel erweitern?

Naja. Das Grundproblem bei dir ist wahrscheinlich, daß man dir eine an 
sich gute Sache (OOP) anhand einer totalverkackten 'Programmiersprache' 
(JS) beibringen will. Das muß zwangsläufig zu Abwehrreaktionen führen!

> Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String
> manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die
> Zahl das Objekt sein...?!
Und da hast du schon die Depperei entdeckt. In anderen Sprachen bindet 
man z.B. die math.h ein, um die Bibliotheksfunktionen zu nutzen, oder 
man hat 'Zahlenobjekte' einer Klasse, die von selber die höheren 
Funktionen kann.
Das math von JS ist kein Objekt, sondern eine Krücke.
Nun gut, in der realen Welt ist auch die Krücke ein reales Objekt...

> Intern wird es ja eh prozedural verarbeitet.

Am Ende ist alles Assembler.
Aber das ist auch nur eine Metaebene, zu guterletzt wird alles in 
Microcode auf dem Prozessor abgearbeitet.
Wer eine Telephonliste von Freunden in Microcode realisieren will, hat 
meine Hochachtung! Assembler ist ja auch nicht das, was wirklich auf dem 
Blech abläuft.

> Bin ich zu alt?
Kann sein... Mit dem Alter kommt die Erfahrung, und man merkt auch 
leichter, wenn man verarscht wird. Wenn man MIR z.B. auch nur irgendwas 
neues, aktuelles, hippes mit JS beibringen wollte, dann würde ich von 
vornherein nur lachen (oder wahlweise abkotzen).
Was ist denn das überhaupt für ein bescheuerter Kurs, bei dem man 
'programmieren' mit JS lernen soll?
Die Dozenten haben als Ausbildung wahrscheinlich auch nur "Webseiten 
programmieren (sic!) mit JavaScript in drei Wochen"


> Gruss Chregu
Dito,
Baku

[Christian M. (Gast)]

@W.S.:

Vielen Dank für diese mal anschauliche Erklärung! Nicht dieses "Auto ist 
rot, Auto hupt"! :-)

@Baku M.:

Ist der Online-Kurs bei codecademy. HTML/CSS habe ich schon durch, 
danach folgt dann noch git und noch ein paar. Wenn ich das durch habe, 
stellt mich eine Firma als Programmierer an.
Hobbymäßig habe ich schon ziemlich viel programmiert, auf dem C64 ein 
bisschen, Z80, 68HC11, Amiga, PIC und PC/Windows. Assembler, BASIC, 
Arexx, alles ausser C.

Gruss Chregu

[Daniel A. (daniel-a)]

Sheeva P. schrieb:
> Aus dieser FAQ: "Go takes a different approach."
>
> Ok, "Go verfolgt einen anderen Ansatz". Kein Problem -- aber ein anderer
> Ansatz, dem wesentliche Eigenschaften der Objektorientierung fehlen, ist
> eben kein objektorientierter Ansatz. Ich verstehe nicht, wie man auf der
> einen Seite sagen kann, man habe einen besseren Ansatz gefunden, der dem
> OO-Ansatz überlegen sei, auf der anderen Seite aber behauptet, der neue
> Ansatz sei in Wirklichkeit dann irgendwie doch objektorientiert, obwohl
> dabei wesentliche Teile dessen fehlen, was OO ausmacht. Sorry, aber das
> ist doch schizophren.

Ein anderer Ansatz muss ja nicht im Wiederspruch zu OO stehen. Es spielt 
doch keine rolle, ob man es nun Klassen nennt oder wie in go 
Structtypen. Es spielt keine Rolle, ob man Datentypen funktionen 
zuordnet, oder man Funktionen datentypen zuordnet. Das resultat ist das 
selbe, der Ansatz ein anderer, aber OO wiederspricht er nicht 
zwangslaufig.

Baku M. schrieb:
> Wenn man MIR z.B. auch nur irgendwas neues, aktuelles, hippes mit JS
> beibringen wollte, dann würde ich von vornherein nur lachen (oder
> wahlweise abkotzen).
> Was ist denn das überhaupt für ein bescheuerter Kurs, bei dem man
> 'programmieren' mit JS lernen soll?

Du kennst dich mit JS nicht (mehr) aus, glaubst aber alles darüber zu 
wissen? JS ist auch schon einige Jahre alt, und es hat sich stark 
verändert. Damals, befor es ES6 gab, war es für OO wirklich unbrauchbar:

"use strict"; // ungetestet

function Person(name){
  this.name = name;
}

Person.prototype.introduce = function introduce(){
  alert("Hi, I'm "+this.name);
};

Seit ES6 ist es aber gereits ganz brauchbar geworden:

"use strict"; // ungetestet

class Person {
  constructor(name){
    this.name = name;
  }
  introduce(){
    alert("Hi, I'm "+this.name);
  }
}

Man kann fast alles, was man nativ schreiben kann, auch als webanwendung 
schreiben. Inklusive 3D Games, Videochat & Verarbeitungsprogramme und 
co. Zugegebenermassen wird für Dinge, die viel Leistung brauchen haufig 
von anderen Sprachen nach asmjs übersetzt, aber asmjs ist immernoch ein 
JS subset. Einige unschönheiten konnte auch ES6 nicht ausbügeln, aber 
gröstenteils kann es sich sehen lassen.

[Sheeva P. (sheevaplug)]

Daniel A. schrieb:
> Ein anderer Ansatz muss ja nicht im Wiederspruch zu OO stehen. Es spielt
> doch keine rolle, ob man es nun Klassen nennt oder wie in go
> Structtypen.

In C gibt es auch Structs, trotzdem ist es keine OO-Sprache.

> Es spielt keine Rolle, ob man Datentypen funktionen
> zuordnet, oder man Funktionen datentypen zuordnet.

Doch, das sind zwei fundamental unterschiedliche Konzepte. Das eine 
heißt Datenkapselung, das andere heißt Typsicherheit. Die Datenkapselung 
ist ein wesentlicher Bestandteil von OO, Typsicherheit nicht.

Obendrein unterstützt Go auch keine Vererbung und keinen Polymorphismus. 
Versteh' mich bitte nicht falsch, ich hab' nichts gegen Go, aber wenn 
man einen vollkommen anderen Ansatz verfolgt, der nicht einmal eine 
einzige der wesentlichen Eigenschaften von OO unterstützt, dann ist es 
keine OO. Darum sollen sich die Go-Leute doch bitte ein anderes Wort 
ausdenken, anstatt zu versuchen, einen etablierten Fachbegriff 
umzudefinieren.

[TriHexagon (Gast)]

Sheeva P. schrieb:
> Obendrein unterstützt Go auch keine Vererbung und keinen Polymorphismus.

Also eigentlich unterstützt Go Polymorphismus, nämlich mithilfe von 
Interfaces (in Rust sind es Traits). Das mag vielleicht nicht der 
klassische Weg sein wie in C++ oder Java, aber praktisch ist es 
Polymorphismus, schließlich bilden sie eigene Typen. Diese neue, leicht 
gewichtete Variante von OOP (keine Vererbung) sieht man fast überall bei 
den neuen Sprachen. Bei Go, Rust ist es so und bei Nimrod scheint es 
auch so zu sein. Den Ansatz finde ich gar nicht so schlecht, kann mir 
aber vorstellen, dass man Vererbung vermissen wird.

Moby A. schrieb im Beitrag #4625040:
> TriHexagon schrieb:
>> Du hast schlicht keine Ahnung davon.
>
> Dazu langt es schon, die nötige Masse von
>
>> Es gibt ungefähr sieben Trilliarden Webseiten und fünf Millionen Bücher
>> zu dem Thema.
>
> einfach mal zur Kenntnis zu nehmen.
> Was wird da wohl alles drin beschrieben sein?
> Es braucht viele viele Erklärungen. Das bedeutet nichts anderes als daß
> hier intuitives prozedurales Denken mit Gewalt umgebogen werden muß. Mit
> viel zu vielen neuen Konstruktionen. Damit muß dann um die Ecke gedacht
> werden. Alles im lächerlichen Namen der Vereinfachung?
> Für viele Anwendungen ist das überflüssig wie ein Kropf... Ne echt
> jetzt.

Hahaha, also ist jetzt die Anzahl der Literatur, über ein Thema, ein 
Indikator dafür wie komplex eben dieses ist. Wenn man das so sieht kommt 
man wohl zur Erkenntnis, dass Kochen komplexer ist als Quantenphysik. Es 
gibt schließlich viel mehr über das Kochen zu lesen als über Physik.

Ne was kann OOP dafür, dass es zigtausend Bücher über den einen gleichen 
Sachverhalt gibt, obwohl ein einziges Gutes ausreicht? Es gibt auch 
zigtausend Bücher über C#. Da wird zum Teil beim gleichen Verlag jedes 
Jahr ein neues rausgehauen, aber sagt es mehr aus oder hat sich was an 
C# verändert (wohlgemerkt Anfängerbücher)? Nö. Besser sind die auch 
nicht, nur kann man noch mal Bücher verkaufen, da die Menschen oft 
glauben, sie brauchen das Neuste.

Ich z.B. habe mir nie ein Buch über OOP gekauft, darüber gabs in meinem 
C# Buch damals zwei oder drei kleine Kapitel, die völlig ausreichend 
waren, um OOP zu verstehen und anwenden zu können. Das habe ich schon 
zur Schulzeit gelernt, allein mit einem Buch, so schwer kanns also nicht 
sein.

[(prx) A. K. (prx)]

TriHexagon schrieb:
> Ich z.B. habe mir nie ein Buch über OOP gekauft, darüber gabs in meinem
> C# Buch damals zwei oder drei kleine Kapitel, die völlig ausreichend
> waren, um OOP zu verstehen und anwenden zu können.

Wen dem Einen wie Schuppen aus den Haaren fällt, dafür braucht der 
Andere eben 5 Mio Bücher - und verzweifelt trotzdem (oder deshalb).

[W.S. (Gast)]

Moby A. schrieb im Beitrag #4624966:
> Die sind auch nötig.
> Das ist nichts was naturgegeben intuitiv und ohne steile Lernkurve
> einfach anzuwenden wär.
> OOP gibt vor Dinge zu vereinfachen, führt aber tatsächlich eine Menge
> neuer Bürokratie ein.
> Das lohnt sich erst bei grösseren Projekten.

Einem Teil deiner Sätze stimme ich zu.

Für viele Programmierer ist prozedurales Denken und Programmieren die 
gewohnte Herangehensweise. Kommt vom PAP her. Wer das gar sehr 
verinnerlicht hat, braucht Zeit und passenden Lesestoff, um den Sinn des 
Ganzen zu kapieren - es ist nämlich relativ viel.

Weiters führt OOP tatsächlich ne Menge neuer Bürokratie ein, jaja, aber 
zugleich vereinfachen sich die Dinge eben genau dadurch ganz erheblich - 
vorausgesetzt, man setzt OOP dort ein wo sie sinnfällig ist und nicht 
fanatisch auf Biegen oder Brechen.

Zum Schluß: Es lohnt sich auch bei kleinen Projekten, da kommt es eben 
auf's Projekt an. Ich habe OOP schon bei vielen µC-Projekten benutzt. In 
C und mit händisch angefertigten Objekt-Typen. Insbesondere bei 
Menüsystemen und Grafikdisplays ist sowas ne echte Erleichterung. Für 
eine ganz kleine Anwendung schau dir die Lernbetty und dort das (ganz 
simple) Menü an. Ja, diese Minimalst-system hätte man auch anders 
schreiben können, aber wenn du mal draufguckst, solltest du das 
Potential erkennen, was da drinsteckt.

W.S.

[nasefuss (Gast)]

c-hater schrieb:
> Für eingefleischte C-ler, die für OOP-Konzepte naturgemäß auf C++
> umsteigen müssten, ist die Hölle definitiv um vieles heisser...

Stimmt MMN so nicht. Ich bin in C "heimisch", das ist die Sprache in der 
ich denke und mich ausdrücke. Um C++ mache ich einen großen Bogen, und 
das nicht nur weil ich "OOP-Konzepte" in plain C umsetzen kann.

[nenene (Gast)]

Dann mal eine Frage an die Profis hier: Wie löst ihr das 
Konfigurationsproblem (d.h. Konfiguration wird zur Laufzeit, z.B. durch 
eine Konfig-Datei festgelegt). Diese Daten beeinflussen ja auch Objekte 
niedrigster Hierachiestufe.
Also wie gehts: Singleton Pattern? Mit String-Hash? Was passiert wenn 
der Hash-Eintrag nicht da ist?
Irgendeine statisch-typisierte Lösung?
oder ein Factory Pattern?

Falls Singleton: wie vermeidet ihr Perfomance-Verluste durch Locks beim 
Multithreading?

Wie löst ihr das, so dass man auch in Zukunft (neue Version braucht z.B. 
weitere Konfiguration) flexibel bleibt?

[(prx) A. K. (prx)]

nasefuss schrieb:
> Stimmt MMN so nicht. Ich bin in C "heimisch", das ist die Sprache in der
> ich denke und mich ausdrücke.

Eine einzige Sprache von der Wiege bis zur Bahre, das wär mir zu eng.

[W.S. (Gast)]

nasefuss schrieb:
> das nicht nur weil ich "OOP-Konzepte" in plain C umsetzen kann

Naja.. Man kann da schon einiges machen, aber das ist kein Vergleich zu 
dem, was man in Pascal mit Delphi/Lazarus und so geboten kriegt.

Und eines muß ich mal wieder loswerden: Wer soweit ist, daß er in C 
Kategorien denkt, der sollte was dagegen tun, Horizont erweitern.

W.S.

[Mark B. (markbrandis)]

nenene schrieb:
> Dann mal eine Frage an die Profis hier: Wie löst ihr das
> Konfigurationsproblem (d.h. Konfiguration wird zur Laufzeit, z.B. durch
> eine Konfig-Datei festgelegt).

Vielleicht solltest Du für diese Fragestellung einen eigenen Thread 
aufmachen.

> Diese Daten beeinflussen ja auch Objekte niedrigster Hierachiestufe.

Nicht unbedingt. Zunächst einmal gibt es auch konfigurierbare Systeme, 
deren Software überhaupt gar nicht per OOP implementiert ist...

> Also wie gehts: Singleton Pattern? Mit String-Hash? Was passiert wenn
> der Hash-Eintrag nicht da ist?
> Irgendeine statisch-typisierte Lösung?
> oder ein Factory Pattern?
>
> Falls Singleton: wie vermeidet ihr Perfomance-Verluste durch Locks beim
> Multithreading?
>
> Wie löst ihr das, so dass man auch in Zukunft (neue Version braucht z.B.
> weitere Konfiguration) flexibel bleibt?

...und um solche Fragen beantworten zu können, müsstest Du näher 
ausführen was denn nun genau die Anforderungen an das konkrete System 
sind. Eine pauschale Antwort hierzu wird es vermutlich nicht geben.

[Mark B. (markbrandis)]

A. K. schrieb:
> nasefuss schrieb:
>> Stimmt MMN so nicht. Ich bin in C "heimisch", das ist die Sprache in der
>> ich denke und mich ausdrücke.
>
> Eine einzige Sprache von der Wiege bis zur Bahre, das wär mir zu eng.

Das ist mMn nicht das, was er ausdrücken wollte. Dass man eine 
Lieblingssprache hat, mit der man am besten klar kommt, ist keinesfalls 
ungewöhnlich.

Auch mir liegt C am ehesten, aber ich mag auch C++ und Java. Python zu 
lernen habe ich mir seit einer Weile vorgenommen... sollte das endlich 
mal wahr machen ;-)

[Sheeva P. (sheevaplug)]

nenene schrieb:
> Dann mal eine Frage an die Profis hier: Wie löst ihr das
> Konfigurationsproblem (d.h. Konfiguration wird zur Laufzeit, z.B. durch
> eine Konfig-Datei festgelegt). Diese Daten beeinflussen ja auch Objekte
> niedrigster Hierachiestufe.
> Also wie gehts: Singleton Pattern? Mit String-Hash? Was passiert wenn
> der Hash-Eintrag nicht da ist?
> Irgendeine statisch-typisierte Lösung?
> oder ein Factory Pattern?

Ehrlich gesagt, habe ich Dein Problem nicht ganz verstanden. Vielleicht 
magst Du einen eigenen Thread aufmachen und dort dann ein wenig genauer 
beschreiben, was genau Du machen willst?

[c-hater (Gast)]

nasefuss schrieb:

> Stimmt MMN so nicht. Ich bin in C "heimisch", das ist die Sprache in der
> ich denke und mich ausdrücke. Um C++ mache ich einen großen Bogen, und
> das nicht nur weil ich "OOP-Konzepte" in plain C umsetzen kann.

Du setzt in plain C Vererbung und Polymorphie um? Nicht, dass das nicht 
wirklich ginge, aber wer kann das dann noch lesen und verstehen?

Also: Höchstens als Machbarkeitsstudie interessant und vielleicht, um 
auch eingefleischten C-lern begreiflich zu machen, was in C++ passiert. 
Dafür ist es durchaus akzeptabel, ich selber hab' mir die OOP-Sache ja 
letztlich auch erst wirklich erfolgreich beigebracht, indem ich auf 
Asm-Ebene verfolgt habe, was da so im Detail passiert. Erst dadurch ist 
wirkliches Verständnis entstanden und damit die Möglichkeit, den Kram 
sinnvoll zu nutzen.

Diese Umwege haben aber wirklich nur Leute nötig, die von der ein 
prozeduralen Programmierung kommen. Leute, die direkt von Anfang an OO 
programmieren, brauchen das nicht. Das Schlimme ist: so gut wie kein 
Programmieranfänger programmiert wirklich OO, selbst wenn er mit einer 
OO-Sprache beginnt. Er benutzt i.d.R. vielmehr fertige Klassen, leimt 
die mit ein bissel prozeduralem Kram zusammen und versteht am Ende einen 
Scheissdreck davon, wie man OO-Programme schreibt...

[(prx) A. K. (prx)]

Man muss nicht mit OOP aufgewachsen sein, um es als Fortschritt zu 
sehen. C++ hatte damals etliche Leute recht fix überzeugt (*) und mit 
Zortech C++ kam auch recht schnell ein guter nativer x86 Compiler raus. 
Zu diesem Zeitpunkt kannten aber die meisten Leute nur prozedurale 
Programmierung - die paar Leute mit Smalltalk oder Simula Kenntnissen 
spielten keine Rolle.

*: Freilich nicht unbedingt ohne Kritik. Mit manchen Stellen der Syntax 
konnte ich mich nach der Lektüre vom Stroustrup nicht anfreunden.

[Daniel A. (daniel-a)]

c-hater schrieb:
> Du setzt in plain C Vererbung und Polymorphie um? Nicht, dass das nicht
> wirklich ginge, aber wer kann das dann noch lesen und verstehen?

Ich mache das häufig, der Code wird dadurch strukturierter, besser 
gekapselt und schlussendlich besser lesbar. Hier mal einige 
Implementierungsmöglichkeiten, je nach Anwendungsfall kann man es auch 
anders machen.

Beispiel mit Objekten:

// person.h

#ifndef DPA_PERSON_H
#define DPA_PERSON_H

struct DPA_Person {
  const char* name;
};

void DPA_Person_introduce( struct DPA_Person* );

#endif

// person.c

#include <stdio.h>
#include <DPA/example/person.h>

void DPA_Person_introduce( struct DPA_Person* person ){
  printf( "Hi, I'm %s\n", person->name );
}

Beispiel für Vererbung, der Einfachheit halber ohne virtuelle Methoden:

// developer.h

#ifndef DPA_DEVELOPER_H
#define DPA_DEVELOPER_H

#include <DPA/example/person.h>

struct DPA_Developer {
  struct DPA_Person person;
  const char* company;
};

void DPA_Developer_introduce( struct DPA_Developer* );

#endif

// developer.c

#include <stdio.h>
#include <DPA/example/person.h>

void DPA_Developer_introduce( struct DPA_Developer* developer ){
  printf(
    "Hi, I'm %s from %s\n",
    developer->person->name,
    developer->company,
  );
}

// main.c
#include <DPA/example/person.h>
#include <DPA/example/developer.h>

int main(){

  Person tom = {
    .name = "tom"
  };

  Developer john = {
    .person = {
      .name = "john"
    },
    .company = "ABC AG"
  };

  DPA_Person_introduce(tom);
  DPA_Person_introduce(john.person);
  DPA_Developer_introduce(john);

  return 0;
}

Ausgabe:

Hi, I'm tom
Hi, I'm john
Hi, I'm john from ABC AG

Anderes Beispiel, ungetestet. Man kann auch einfach so eine art 
Interface machen und als vtable für Polymorphie verwenden:

// output_device.h

#ifndef DPA_OUTPUT_DEVICE_H
#define DPA_OUTPUT_DEVICE_H

struct DPA_OutputDevice;
struct DPA_OutputDeviceInterface {
  void(*init)(struct OutputDevice*);
  void(*print)(struct OutputDevice*,const char*);
  void(*destroy)(struct OutputDevice*);
};

struct DPA_OutputDevice {
  const struct OutputDeviceInterface* interface;
};

extern const struct DPA_Terminal_x86_Interface DPA_terminal_x86_interface;

#endif

// terminal_x86.h

#ifndef DPA_TERMINAL_X86_H
#define DPA_TERMINAL_X86_H

#include <DPA/ExampleOS/output_device.h>

struct DPA_Terminal_x86;
struct DPA_Terminal_x86_Interface {
  struct DPA_OutputDeviceInterface interface;
  void(*clear)( struct DPA_Terminal_x86* );
};

struct DPA_TerminalCharacter_x86 {
  uint8_t character,
  uint8_t color
} __attribute__((packed));

struct DPA_Terminal_x86 {
  union {
    const struct DPA_Terminal_x86_Interface* interface;
    struct DPA_OutputDevice outputDevice;
  };
  uint_least16_t columns;
  uint_least16_t rows;
  uint_least32_t cursor;
  volatile DPA_TerminalCharacter_x86* buffer;
};

// terminal_x86.c

#include <string.h>
#include <DPA/ExampleOS/terminal_x86.h>

static void init( struct DPA_OutputDevice* od ){
  struct DPA_Terminal_x86* terminal = (void*)od;
  terminal->columns = 80;
  terminal->rows    = 25;
  terminal->buffer  = *(volatile struct DPA_TerminalCharacter_x86*)0xB8000;
}

static void print( struct DPA_OutputDevice* od, const char* text ){
  struct DPA_Terminal_x86* terminal = (void*)od;
  char character;
  uint_least8_t  color  = terminal->color;
  uint_least32_t cursor = terminal->cursor; 
  uint_least32_t size   = terminal->columns * terminal->rows;
  while( character = *text++ ){
    if( cursor >= size )
      cursor = 0;
    terminal->buffer[cursor++] = (struct DPA_TerminalCharacter_x86){
      .character = character,
      .color = color
    };
  }
  terminal->cursor = cursor;
}

static void clear( struct DPA_Terminal_x86* terminal ){
  memset( (void*)terminal->buffer, 0, terminal->columns * terminal->rows );
}

static void destroy( struct DPA_OutputDevice* od ){
  struct DPA_Terminal_x86* terminal = (void*)od;
  (void)terminal;
}

const struct DPA_Terminal_x86_Interface DPA_terminal_x86_interface = {
  .terminal = {
    .init = init,
    .print = print,
    .destroy = destroy
  },
  .clear = clear
};

const struct DPA_OutputDeviceInterface* outputDeviceList[] = {
  &DPA_terminal_x86_interface.terminal
};

Nach diesem Muster könnte man beliebig viele DPA_OutputDevice typen 
definieren und über die DPA_OutputDeviceInterface schnittstelle 
ansprechen.
Alles total übersichtlich und einfach zu verstehen.

[TriHexagon (Gast)]

A. K. schrieb:
> Man muss nicht mit OOP aufgewachsen sein, um es als Fortschritt zu
> sehen. C++ hatte damals etliche Leute recht fix überzeugt (*)

Interessanterweise scheint es Leuten, die Jahre lang nur prozedural 
programmiert haben und nichts anderes kennen, schwerer zu fallen OOP zu 
lernen als diejenigen, die nur OOP gemacht haben, PP zu lernen.

@Daniel Abrecht Genau genommen ist das eine Komposition und keine 
Vererbung. Aber es ist ein gängiger Workaround Vererbung nachzubilden. 
Ein C++ Compiler dürfte das ungefähr so umsetzten. In Rust setzt man 
sowas entweder mit einer Komposition um oder man verwendet type 
aliasing:

http://stackoverflow.com/questions/32736170/what-is-the-best-way-to-inherit-a-struct-in-rust-1-3

Man kann in C übrigens auch richtig kapseln, nämlich indem man die 
Deklaration der Datenstruktur nicht öffentlich macht und Zeiger als 
Handle verwendet. Nur ausgewählte Funktionen (quasi Methoden) können mit 
den Daten operieren.

foo.h

struct Foo;

Foo* foo_create();
void foo_doThis(Foo* foo);
void foo_doThat(Foo* foo);

foo.c

#include "foo.h"

struct Foo {
  int a;
  //...
};

Foo* foo_create() {
  Foo* foo = malloc(sizeof(Foo));
  //...
  foo->a = 0;
  //...
}

void foo_doThis(Foo* foo) {
  //...
}

void foo_doThat(Foo* foo) {
  //...
}

Großer Nachteil dabei ist, dass man die Struktur nicht mehr auf den 
Stack legen kann. Jedenfalls außerhalb von foo.c.

[TriHexagon (Gast)]

Daniel A. schrieb:
> Alles total übersichtlich und einfach zu verstehen.

In C++ wäre es jedenfalls übersichtlicher und einfacher. Genau deswegen 
mach ich in C kaum noch OOP, weil dann kann ich ja gleich zu C++ 
greifen, dass mir wiederum auch andere Vorteile bietet.

[Stefan F. (Gast)]

Über die technischen vor- und Nachteile von OOP kann man lange 
philosophieren.

Ich schätze dabei vor allem, dass OOP dabei hilft, den Programmcode 
ordentlich zu strukturieren, so dass er über viele Jahre wartbar bleibt.

[Tommi (Gast)]

OOP habe ich bisher nur in Delphi benutzt, dort werden Instanzen aber 
immer dynamisch erzeugt. Auf einen kleinen µC liese sich das nicht 
übertragen, da ja dann eine Speicherverwaltung/Betriebssystem notwendig 
wäre. Wie ist das in C++? Ich nehme an, dass dort das statische Anlegen 
von Instanzen möglich ist?

[(prx) A. K. (prx)]

Tommi schrieb:
> C++? Ich nehme an, dass dort das statische Anlegen
> von Instanzen möglich ist?

Ja.

[Tommi (Gast)]

A. K. schrieb:
> Ja.
Ein Beispiel wäre nicht schlecht.
Ich denke dass das nicht ganz offtopic ist.

[Marc (Gast)]

class A {...}

A statischesA;

[Bernd K. (prof7bit)]

Tommi schrieb:
> OOP habe ich bisher nur in Delphi benutzt, dort werden Instanzen aber
> immer dynamisch erzeugt

Du kannst auch den Datentyp Object verwenden, dessen Speicherort kannst 
(musst) Du manuell verwalten, also kannst Du es auch auf dem Stack 
haben, in dieser Hinsicht verhält sich Object genau wie ein Record..

[(prx) A. K. (prx)]

Man kann C++ vollständig statisch schreiben, ohne auf Grundfunktionen 
der OOP verzichten zu müssen. Das ist ein Grund, weshalb man es für 
Mikrocontroller mit sparsamer RAM-Ausstattung verwenden kann, bei denen 
dynamische Speicherverwaltung nicht in Frage kommt. Man ist dabei 
natürlich eingeschränkt, aber m.E. besser dran als in C.

[+++ (Gast)]

An Python sieht man die Vorteile von OOP ganz gut.
Dort sind Datentypen wie Strings oder Listen Objekte und haben 
Funktionen, die man darauf anwenden kann. Z.B.:
https://docs.python.org/3.5/library/string.html
https://docs.python.org/3.5/tutorial/datastructures.html

[(prx) A. K. (prx)]

Tommi schrieb:
> Ein Beispiel wäre nicht schlecht.
> Ich denke dass das nicht ganz offtopic ist.

Die Speicherverwaltung der Klasseninstanzen unterscheidet sich in C++ 
nicht von der Speicherverwaltung von Skalaren, Arrays und Structs 
(Pascal: Records). Globale instanzen sind statisch und lokale 
(nichtstatische) Instanzen landen auf dem Stack. Dynamisch alloziert 
(jenseits des Stacks) wird nur explizit.

Natürlich schränkt das ein. So ziemlich jede normale nicht eigens dafür 
geschriebene C++ Lib kann man bei Verzicht auf den Heap vergessen.

Auch wenn das kein typisches OOP Beispiel ist: Für Stringverarbeitung 
wird man normalerweise dynamischen Speicher verwenden, weil das einfach 
nahe liegt. Ohne Heap muss man sich ersatzweise eben auf eine 
Stringverarbeitung verlegen, die mit einer für die jeweilige Instanz 
definierten maximalen Länge arbeitet und keine temporären Instanzen auf 
dem Heap benötigt.

Man kann aber trotzdem typische Elemente von OOP Sprachstrukturen 
verwenden, wie etwa heterogene Datenstrukturen über Vererbung. Etwa 
mehrere verschiedene Typen von Temperatursensoren so zusammenfassen, 
dass sich zwar die Implementierung unterscheidet, nicht aber die 
Verwendung. Oder auf ähnliche Art unterschiedlichsten 
Konfigurationsparametern ein gemeinsames Interface verpassen.

[Tommi (Gast)]

@A.K.
Danke für die Ausführungen!
Mit gewissen Vorbehalten gegen C (wofürs ja auf dem Mikrocontrolle kaum 
eine Alternative gibt), habe ich mich bisher von C++ ferngehalten. Wenn 
sich eine statische OOP dort aber so einfach umsetzen lässt, ist es doch 
mal ein Versuch wert.

[Stefan F. (Gast)]

Schau Dir Arduino an. Dort wird C++ angewendet, soweit es auf kleinen µC 
Sinn macht.

[Michael B. (laberkopp)]

Sheeva P. schrieb:
>> sozusagen eine Memberfunktion von FILE zum Zugriff auf diese
>> private Variable.
>
> In C gibt es keine privaten Variablen. Ja, static existiert, ist aber
> was anderes als "private" in C++-Structs oder -Klassen.

Was verstehst du am Wort 'sozusagen' nicht ?

Übrigens gibt es sehr wohl Impementationen, die FILE in einer Art 
exportieren, daß die interne Struct darauf gar nicht abgebildet wird.

Stefan U. schrieb:
> Ich schätze dabei vor allem, dass OOP dabei hilft, den Programmcode
> ordentlich zu strukturieren, so dass er über viele Jahre wartbar bleibt.

Immer diese Laien.
Du hast offensichtlich noch nie versucht, ein vo jemand anderem 
geschriebenes reales OOP (z.B. C++) Programm zu durchblicken oder ?
GERADE das was alles 'versteckt' abläuft macht es UNENDLICH SCHWER 
nachzuvollziehen was das Programm tut (und was man ändern bzw. wie man 
ergänzen darf ohne es kaputt zu machzen).

C ist wesentlich wartungsfreundlicher.

[Michael B. (laberkopp)]

A. K. schrieb:
> Eine einzige Sprache von der Wiege bis zur Bahre, das wär mir zu eng.

Aha, Englisch als Muttersprache, in der Schule Deutsch gelernt und dann 
in Spanien spanisch gesprochen um im Alter in Griechenland an 
griechisch-Kursen teilzunehmen.

Dein Leben ist nicht das normale Leben.

[(prx) A. K. (prx)]

Michael B. schrieb:
> Dein Leben ist nicht das normale Leben.

Den Spruch kenn ich schon. Aber damit kann ich leben. ;-)

Für seinen Bildungshorizont ist allerdings jeder selbst verantwortlich. 
Ich bin mir freilich sicher, dass niemand, der mit APL anfängt, ein 
Leben lang nur bei dieser einen Sprache bleibt. Ebenso jene, die in den 
80ern mit dem BASIC des C64 laufen lernten.

Wenn das allerdings heissen soll, dass jene, die sich heute als 
Jungspunde in C stürzen, überwiegend bis zur Rente nur darin verharren 
werden, dann Amen.

[Stefan F. (Gast)]

>> Ich schätze dabei vor allem, dass OOP dabei hilft, den Programmcode
>> ordentlich zu strukturieren, so dass er über viele Jahre wartbar bleibt.

> Immer diese Laien.
> Du hast offensichtlich noch nie versucht,

Ja laberkopp, wenn du meinst. Dann reichen 20 Jahre Berufserfahrung mit 
OOP wohl nicht aus, um auf dein Niveau zu kommen.

[Michael B. (laberkopp)]

Stefan U. schrieb:

> Ja laberkopp, wenn du meinst. Dann reichen 20 Jahre Berufserfahrung mit
> OOP wohl nicht aus, um auf dein Niveau zu kommen.

Nein, reichen nicht.

[Chris F. (chfreund)]

Michael B. schrieb:
> Immer diese Laien.
> Du hast offensichtlich noch nie versucht, ein vo jemand anderem
> geschriebenes reales OOP (z.B. C++) Programm zu durchblicken oder ?
> GERADE das was alles 'versteckt' abläuft macht es UNENDLICH SCHWER
> nachzuvollziehen was das Programm tut (und was man ändern bzw. wie man
> ergänzen darf ohne es kaputt zu machzen).
>
> C ist wesentlich wartungsfreundlicher.

Das ist totaler Unsinn. Den einzigen Laien den ich hier sehe, der bist 
Du. Du redest abfällig über Dinge über die Du keinen Überblick hast.

Ich verwende C++, C und ASM seit Beginn der 90er und nutze es eben da wo 
es Sinn macht und passt. Solche plumpen Sprüche und dann auch noch 
andere Laien nennen, weil die die eigene Meinung nicht teilen.

Benenne doch mal die Vorteile von C gegenüber C++ bei Großprojekten.

[Georg A. (georga)]

So weit hergeholt mit der Wartungs(un)freundlichkeit bei C++ ist das 
nicht. Bei fremden Codes ist es durch die virtuellen Methoden und 
zigfache (Mehrfach) Vererbung manchmal schon unmöglich, allein durch 
statisches Code-Anschauen rauszufinden, welche der 100 identisch 
benannten "get/add/etc"-Funktionen am Ende für ein Objekt aufgerufen 
wird.

Klar lässt sich sowas mit einem Debugger rausfinden, aber das ist auch 
nicht immer so einfach (Echtzeit, ISR, etc.). Da hilft dann nur noch 
Verstreuen von printf aka neudeutsch "Instrumentierung" ;)

Dagegen ist die Code-Vereinfachung durch die Standard-Container mit 
Templates wirklich sehr schön.

[Chris F. (chfreund)]

Georg A. schrieb:
> So weit hergeholt mit der Wartungs(un)freundlichkeit bei C++ ist das
> nicht. Bei fremden Codes ist es durch die virtuellen Methoden und
> zigfache (Mehrfach) Vererbung manchmal schon unmöglich [..]
> Klar lässt sich sowas mit einem Debugger rausfinden, aber das ist auch
> [..]

Schlechter und unübersichtlich aufgebauter Quellcode ist immer 
wartungsunfreundlich, egal in welcher Sprache.

C++ ermöglicht sehr viele unterschiedliche Vorgehensweisen und ist eine 
sehr freie Sprache. Wenn man es nicht effektiv benutzen kann, bzw. 
keinen Bock hat genau das zu lernen, oder ständig Sprachmittel einsetzt 
die man nicht verstanden hat, dann sollte man es auch nicht verwenden. 
;-)

[Georg A. (georga)]

> Schlechter und unübersichtlich aufgebauter Quellcode ist immer
> wartungsunfreundlich, egal in welcher Sprache.

Das komische ist aber gerade bei C++, dass selbst bei nur einem Autor 
die Einzelklassen "schön" und strukturiert aussehen können, aber dann 
das Gesamtkonstrukt gerade wegen den anonymen Objekten nicht mehr 
durchschaubar ist. So extrem ist mir das noch bei keiner anderen Sprache 
aufgefallen. Bei Perl oder C sieht man schon an einem File aus dem 
Projekt, ob alles Schrott ist ;)

[Michael B. (laberkopp)]

Chris F. schrieb:
> Schlechter und unübersichtlich aufgebauter Quellcode ist immer
> wartungsunfreundlich, egal in welcher Sprache.

Sicher, bloss lässt sich C++ besser zur obfuscation einsetzen als C.

In C muss man wenigstens hinschreiben, wenn was passieren soll, an der 
Stelle wo es passiert, und das hingeschriebene ist eindeutig.

In C++ holen sich die jüngsten Coder einen runter was sie heute wieder 
an neuesten Quirks gelernt haben, die sie sofort einsetzen müssen, um 
ihre eigene eingebildete Überlegenheit vor allen anderen Programmierern 
zu zeigen. Das geht so weit, daß der modernere C-Compiler die Konstrukte 
des alten nicht mehr übersetzen kann.

Die Regel "Benutze nie mehr als nötig" wurde in C++ noch nie befolgt. Es 
hat seinen Grund, warum heutige Programme grottig langsam und fehlerhaft 
schlecht sind, Scrum alleine ist nicht an allem schuld.

> C++ ermöglicht sehr viele unterschiedliche Vorgehensweisen und ist eine
> sehr freie Sprache. Wenn man es nicht effektiv benutzen kann, bzw.
> keinen Bock hat genau das zu lernen, oder ständig Sprachmittel einsetzt
> die man nicht verstanden hat, dann sollte man es auch nicht verwenden.

Was hilft das, wenn du ein Programm von einem anderen bekommst ? Das ist 
leider die Realität im Business. Wirst du auch noch lernen, wenn du aus 
der Schule kommst.

[Mark B. (markbrandis)]

Michael B. schrieb:
>> C++ ermöglicht sehr viele unterschiedliche Vorgehensweisen und ist eine
>> sehr freie Sprache. Wenn man es nicht effektiv benutzen kann, bzw.
>> keinen Bock hat genau das zu lernen, oder ständig Sprachmittel einsetzt
>> die man nicht verstanden hat, dann sollte man es auch nicht verwenden.
>
> Was hilft das, wenn du ein Programm von einem anderen bekommst ? Das ist
> leider die Realität im Business. Wirst du auch noch lernen, wenn du aus
> der Schule kommst.

Beides ist richtig.

Es gibt leider viele Firmen, die qualitativ schlechten Sourcecode 
akzeptieren. Meistens weil die Entscheidungsträger sowieso nicht 
verstehen wie qualitativ gute Software denn aussieht.

[Chris F. (chfreund)]

Michael B. schrieb:
> Sicher, bloss lässt sich C++ besser zur obfuscation einsetzen als C.
> [..]
> In C++ holen sich die jüngsten Coder einen runter was sie heute wieder
> an neuesten Quirks gelernt haben, die sie sofort einsetzen müssen, um
> [..]
> Die Regel "Benutze nie mehr als nötig" wurde in C++ noch nie befolgt. Es
> [..]
> leider die Realität im Business. Wirst du auch noch lernen, wenn du aus
> der Schule kommst.

Besser kann man nicht zeigen, dass man noch nie im professionellen 
Umfeld mit C++ gearbeitet hat.

Beantworte bitte meine Frage und benenne die Vorteile von C gegenüber 
C++ in großen Projekten. Wie wurde da in der Architekturplanung 
vorgegangen und warum ist das dann in C++ schlechter?

[Sheeva P. (sheevaplug)]

Michael B. schrieb:
> Sheeva P. schrieb:
>>> sozusagen eine Memberfunktion von FILE zum Zugriff auf diese
>>> private Variable.
>>
>> In C gibt es keine privaten Variablen. Ja, static existiert, ist aber
>> was anderes als "private" in C++-Structs oder -Klassen.
>
> Was verstehst du am Wort 'sozusagen' nicht ?

Das Wort kenne ich, aber hier ist es falsch. Es gibt eine Definition, 
was eine Memberfunktion ist. fileno(3) ist keine, auch nicht 
"sozusagen". Es gibt auch eine Definition, was eine private Variable 
ist. Eine Variable in einem C-Struct ist keine, auch nicht "sozusagen".

[Michael B. (laberkopp)]

Chris F. schrieb:
> Beantworte bitte meine Frage und benenne die Vorteile von C gegenüber
> C++ in großen Projekten.

Deine Frage wurde beantwortet, aber du verstehst es nicht, was soll man 
da noch dazu schreiben ?

Der erste wichtige Unterschied liegt darin begründet, daß man ein 
grosses C Programm lesend verstehen kann, während man ein C++ Programm 
debuggen muss um nachvollziehen zu können, was an einigen Stellen 
passieren mag.

Bei Projekten, die mehr als 1 Person erfordern, so daß die anderen 
niemals das ganze Programm lesen und überblicken können, ist das 
immanent wichtig. So lange du zu Hause nur deine kleinen Projekte 
machst, ist es natürlich egal.

Man kann sich auch in C++ beschränken und Konstrukte nur dort 
einsetzen wo sie gut und sinnvoll sind. Tut aber keiner, zumindest kein 
C++ Verfechter. So ist leider die Realität, und dazu muss man keinen 
Code von indischen Softwareentwicklern bekommen, dazu reichen die 
deutschen Uniabsolventen schon aus.

[Michael B. (laberkopp)]

Sheeva P. schrieb:
> Das Wort kenne ich, aber hier ist es falsch.

Das Wort ist keineswegs falsch, sondern:
Lässt man das Wort weg, wäre der Satz falsch.
Da du geistig offenbar nicht in der Lage bist das Wort richtig 
einzuordnen und es einfach überliest als ob es nicht da wäre, kommst du 
fälschlicherweise zu der Schlussfolgerung, der Satz wäre falsch.
Andere Leute sagen dazu;: Du bist dumm.
Aber es mangelt dir nicht an Selbstüberheblichkeit den Fehler anderen 
Leuten zuzuordnen.

[Michael B. (laberkopp)]

Mark B. schrieb:

> Es gibt leider viele Firmen, die qualitativ schlechten Sourcecode
> akzeptieren. Meistens weil die Entscheidungsträger sowieso nicht
> verstehen wie qualitativ gute Software denn aussieht.

Es gibt viele Firmen, deren Mitarbeiter den schlechten Code massenhaft 
produzieren (kein Wunder, wenn man z.B. die Leistung von Programmierern 
in der Anzahl geschriebener Zeilen bewertet, oder ihnen in Scrum pro 
Sprint mehr abgearbeitete Änderungen abverlangt).

Gute Software habe ich schon lange nicht mehr gesehen. Dabei bin ich 
nicht besonders anspruchsvoll: Den Source Code von CP/M, GEM und Windows 
3.1 beispielsweise kann ich durchaus als gut gelten lassen.

Abschreckende Beispiele waren MFC, PGP und OpenOffice Calc. Google 
Chrome beispielsweise ist nicht mal wirklich schlecht, aber unendlich 
aufgebläht durch den typischen C++ Effekt. Funktionen die fast nichts 
tun, nur weiterleiten um die (Zugriffs- Aufruf- Typen-) Beschränkungen 
von C++ zu umgehen.

[Mikro 7. (mikro77)]

Michael B. schrieb:

> Der erste wichtige Unterschied liegt darin begründet, daß man ein
> grosses C Programm lesend verstehen kann, während man ein C++ Programm
> debuggen muss um nachvollziehen zu können, was an einigen Stellen
> passieren mag.

Tatsächlich? ;-)

Ich denke, dass könnte vielleicht auch daran liegen, dass C-Konstrukte 
wesentlich einfacher zu verstehen sind. Bei C++ dagegen wird man allein 
von den syntaktsichen Möglichkeiten erschlagen (C++11... läßt auch 
Grüßen).

Selbst wenn man den Überblick hat, sich auch in STL und Boost 
eingearbeitet hat, braucht es einiges an praktischer Erfahrung, um mit 
C++ sinnvoll zu arbeiten (und anderen Code zu verstehen).

Daher sind bei C++ im Unternehmen Schulungen und Coding Guidelines ein 
wichtiger Faktor. Richtig angewand kann man die (umfangreichen) Vorteile 
der Sprache nutzen. Und mit vernünftigen Design, lassen sich (imho) C++ 
Programme (viel!) besser verstehen als C Programme.

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but 
when you do, it blows away your whole leg." [Bjarne Stroustrup]

[nicht"Gast" (Gast)]

Mikro 7. schrieb:
>> Der erste wichtige Unterschied liegt darin begründet, daß man ein
>> grosses C Programm lesend verstehen kann, während man ein C++ Programm
>> debuggen muss um nachvollziehen zu können, was an einigen Stellen
>> passieren mag.
>
> Tatsächlich? ;-)

Na ja,

warscheinlich ist es mal wieder das kleine, feine, gut Dokumentierte, 
dessen Funktionen ausschließlich gut benamst sind, C - Programm.

Und gegen dieses muss das große, aufgeblähte, mit grauenvoll benamsten 
Klassen, die über tausende Zeilen groß sind antreten.

Kein Wunder das da OOP "verliert"


PS: C++ ist eine grauenvolle Sprache. Da gibts wesentlich bessere, aber 
darum gehts hier ja nicht ^^

[Chris F. (chfreund)]

Was hier als "Argumente" gebracht wird ist wie früher die Diskussion ob 
man auf dem Amiga Makroassembler (lang lebe OMA2 ;-)) oder bei 
PC-Programmen Pascal oder C verwenden sollte um Anwendungen zu 
schreiben, weil reiner Assembler ja viel besser sei und solche 
"Skriptsprachen" total lame und die Compiler total viel unnötiges Zeug 
einfügen. (bitte entsprechende newsgroup- und irc-flame Diskussionen 
hier einfügen)

Weil etwas mehr Möglichkeiten bietet als etwas anderes, bietet es auch 
mehr Möglichkeiten Unfug zu machen.

Aber deswegen ist es nicht direkt schlecht, es bedarf eben mehr Sorgfalt 
und Richtlinien/Absprachen und einer ordentlichen Architektur.

Wenn ein Substandardprogrammierer, der nicht lernwillig ist, sich aus 
ideologischen Gründen auf einzelne Programmiersprachen beschränkt ist 
das sein Ding. Wenn er Code in einer Sprache die er nicht lernen und 
begreifen will (oder kann) für unlesbar hält ist das auch sein Ding.

Hellhörig werde ich immer wenn ich so Sprüche höre wie: "solange du/man 
zu hause die kleinen Projekte" oder wenn eine gegensätzliche Ansicht 
geäußert wird: "du bist ja geistig nicht in der Lage die Wahrheit zu 
sehen"/"Du bist dumm", wenn eine Sprache starke Typisierung und 
Zugriffsbeschränkungen ermöglicht: "Es müssen Funktionen gebaut werden 
die mit Murks die Zugriffsbeschränkungen aufheben"

Die Frage müsste lauten: "Warum hat wohl der Ersteller dieser Bibliothek 
da Zugriffsbeschränkungen eingebaut?"

Für Substandardprogrammierer die weder Bock auf Lernen oder 
Selbstreflektion haben, ist das dann so wie bei MFC oft gesehen: 
Beschränkungen werden weggecastet, dadurch Zugriff auf Ecken wo der User 
nicht dransollte, komische Fehlermeldungen, Linkerfehler, so kommt er 
dann zum persönlichen Fazit: MFC/C++/Windows/Microsoft ist alles 
Scheisse obwohl es daran liegt, dass er es nicht bedienen kann oder 
lernen will.

In reinem C ist es übrigens noch VIEL schlimmer wenn man sich nicht an 
den Aufbau von komplexen Frameworks hält und mit deren Eigenheiten lebt. 
Das ist z.B. bei gängigen Linuxtools so, wer eine stored-procedure für 
eine Datenbank, ein Kernel- oder Webserver-Modul bauen will, der wird zu 
Vorgehensweisen gezwungen die total nebulös sind, verwendet 
Schnittstellen die aus Rohdatenstrukturen, Funktionszeigercallbacks 
usw... bestehen und muss die darunterliegende Struktur wie ein rohes Ei 
behandeln.

Wenn nun eine Sprache daherkommt die das alles durch Sprachmittel und 
Compilerprüfungen vereinfacht, dann ist das für große Projekte mit einem 
Zeitplan und Budget ein Segen und sorgt für bessere Resultate mit 
weniger eigenem, zu wartenden, Code.

[Sheeva P. (sheevaplug)]

Michael B. schrieb:
> Sheeva P. schrieb:
>> Das Wort kenne ich, aber hier ist es falsch.
>
> Das Wort ist keineswegs falsch, sondern:
> Lässt man das Wort weg, wäre der Satz falsch.

Der Satz bleibt auch mit dem Wort falsch.

> Da du geistig offenbar nicht in der Lage bist das Wort richtig
> einzuordnen und es einfach überliest als ob es nicht da wäre, kommst du
> fälschlicherweise zu der Schlussfolgerung, der Satz wäre falsch.

Deine Pöbeleien ändern nichts daran, daß der Satz falsch ist.

> Andere Leute sagen dazu;: Du bist dumm.
> Aber es mangelt dir nicht an Selbstüberheblichkeit den Fehler anderen
> Leuten zuzuordnen.

Solange es reicht, C++ auch ohne Debugger zu verstehen, ist Dein 
kindisches Gepöbel nur eine Aussage über Dich selbst. Lustig! :-)

[Stefan F. (Gast)]

> daß man ein grosses C Programm lesend verstehen kann,
> während man ein C++ Programm debuggen muss

Diese Aussagwe trifft meiner Meinung nach nur auf Personen zu, die C++ 
nicht beherrschen.

[Mark B. (markbrandis)]

Stefan U. schrieb:
>> daß man ein grosses C Programm lesend verstehen kann,
>> während man ein C++ Programm debuggen muss
>
> Diese Aussagwe trifft meiner Meinung nach nur auf Personen zu, die C++
> nicht beherrschen.

Jein. Man kann in jeder Sprache schlechten Code schreiben. Also auch in 
C. Also auch in C++. Und schlechter Code ist eben oft schwer zu 
verstehen.

[Carl D. (jcw2)]

Mark B. schrieb:
> Stefan U. schrieb:
>>> daß man ein grosses C Programm lesend verstehen kann,
>>> während man ein C++ Programm debuggen muss
>>
>> Diese Aussagwe trifft meiner Meinung nach nur auf Personen zu, die C++
>> nicht beherrschen.
>
> Jein. Man kann in jeder Sprache schlechten Code schreiben. Also auch in
> C. Also auch in C++. Und schlechter Code ist eben oft schwer zu
> verstehen.

Die Aussage war aber: in C++ ist es IMMER unlesbar.

Der Trugschluß ist wahrscheinlich C++ sieht doch aus wie C, also muß ich 
das nach 20 Jahren C verstehen und wenn nicht, liegt's an C++.

Und wer ersthaft meint per Debugger zu verstehen, was er als C++ nicht 
versteht, der hat noch nie gesehen, was ein ordentlicher Compiler so an 
Code generiert.

[(prx) A. K. (prx)]

Kurz ausgedrückt: Was ich nicht verstehe, das taugt nichts.

[Mark B. (markbrandis)]

Carl D. schrieb:
> Die Aussage war aber: in C++ ist es IMMER unlesbar.

Das stimmt so natürlich nicht - klar.

A. K. schrieb:
> Kurz ausgedrückt: Was ich nicht verstehe, das taugt nichts.

Und wenn der Bauer nicht schwimmen kann, liegt es an der Badehose. ;-)

[Chris F. (chfreund)]

Sheeva P. schrieb:
>> Andere Leute sagen dazu;: Du bist dumm.
> Solange es reicht, C++ auch ohne Debugger zu verstehen, [...]

Made my day ... lol

[W.S. (Gast)]

Michael B. schrieb:
> C ist wesentlich wartungsfreundlicher.

.. als C++
Ja, sehe ich genauso. Der Grund liegt aber nicht in der OOP, sondern 
darin, wie das Ganze in C++ umgesetzt worden ist. Anstatt mal endlich 
sinnvolle und merkbare Schlüsselwörter einzuführen, hat Stroustrup 
wieder mal in die typische C Kiste gegriffen und doppelte Doppelpunkte, 
Tilden vor Methoden und eine Menge Automatismen eingeführt, die man sich 
alle merken muß, um damit nicht auf die Fresse zu fliegen.

Stroustrup hat's übertrieben - und zwar in die falsche Richtung. Ich hab 
ihn seit Jahren im schrank stehen und schon etliche Male darüber den 
großen Brechreiz bekommen. Nein, C++ nicht mit mir. Ich vergleiche das 
mit dem Ansatz von Pascal und finde letzteren um Größenordnungen besser, 
sauberer strukturiert, lesbarer.

A. K. schrieb:
> Wenn das allerdings heissen soll, dass jene, die sich heute als
> Jungspunde in C stürzen, überwiegend bis zur Rente nur darin verharren
> werden, dann Amen.

AMEN. kruzisakramenzifix AMEN.

Ich sehe da kein Licht am Horizont. Mit Pascal wäre das kein Problem 
gewesen, Pascal ist flexibel genug für Zukünftiges.

Aber die Jungspunde wollen ja nichts als C können und alle bisherigen 
Versuche, aus dieser Furche herauszukommen, sind an zu kleinem geistigen 
Horizont gescheitert. Das sieht alles wie ein bissel durchgemangeltes C 
aus, wo ohne jegliche Fortune alle häßlichen Altlasten von C beibehalten 
wurden.

Ich vergleiche das mal mit dem Versuch, vom Turnschuh wegzukommen, indem 
man hinten nen Stöckel-Absatz drannagelt. Sorry, ein eleganter Pumps 
wird auf solche Weise nicht draus. Höchstens eine Botte, mit der man auf 
die Nase fällt.

Also bleibt es bis auf nicht absehbare Zeiten eben beim ollen häßlichen 
C und all seinen Unzulänglichkeiten.

W.S.

[Sheeva P. (sheevaplug)]

W.S. schrieb:
> Michael B. schrieb:
>> C ist wesentlich wartungsfreundlicher.
>
> .. als C++
> Ja, sehe ich genauso. Der Grund liegt aber nicht in der OOP, sondern
> darin, wie das Ganze in C++ umgesetzt worden ist. Anstatt mal endlich
> sinnvolle und merkbare Schlüsselwörter einzuführen, hat Stroustrup
> wieder mal in die typische C Kiste gegriffen und doppelte Doppelpunkte,
> Tilden vor Methoden und eine Menge Automatismen eingeführt, die man sich
> alle merken muß, um damit nicht auf die Fresse zu fliegen.
>
> Stroustrup hat's übertrieben - und zwar in die falsche Richtung. Ich hab
> ihn seit Jahren im schrank stehen und schon etliche Male darüber den
> großen Brechreiz bekommen. Nein, C++ nicht mit mir. Ich vergleiche das
> mit dem Ansatz von Pascal und finde letzteren um Größenordnungen besser,
> sauberer strukturiert, lesbarer.

Das ist aber nur eine Frage Deines persönlichen Geschmacks, über den 
sich bekanntlich nicht streiten läßt, und somit kein technisches oder in 
einer anderen Weise sachliches Argument. Bei mir sieht es anders aus: 
ich habe keine Angst vor Tilden, Doppelpunkten und anderen Sonderzeichen 
(solange wir hier nicht über APL reden... :-)) und finde Pascal schwer 
lesbar, was höchstwahrscheinlich daran liegt, daß ich seit dreißig 
Jahren nichts mehr damit gemacht habe.

In Wirklichkeit ist diese Syntax vermutlich auch nur dann schwer lesbar, 
wenn man nicht daran gewöhnt ist. Wie sonst wäre es zu erklären, daß es 
dermaßen viele Sprachen gibt, die sich an diese Syntax anlehnen: C++, na 
klar, aber auch Java, Perl, ECMAScript, R, Google Go, PHP, sowie etwa 60 
andere. Das hätten die Autoren dieser Sprachen sicherlich nicht gemacht, 
wenn sie die Syntax als schlecht lesbar empfunden hätten.

Man kann sicher trefflich über die Designentscheidungen von Stroustrup 
und den Standardisierungsgremien philosophieren, allein: es nutzt 
nichts. Die Designentscheidungen sind nun einmal gemacht, und sich 
darüber zu ärgern, kann und wird nichts mehr daran ändern. Jetzt hat man 
als Entwickler die Wahl: entweder, man findet Dich mit den Gegebenheiten 
ab, oder man läßt es bleiben und sucht sich die Nische, in der man mit 
einer Sprache und Syntax arbeiten kannst, die einem eher zusagen.

> Ich sehe da kein Licht am Horizont. Mit Pascal wäre das kein Problem
> gewesen, Pascal ist flexibel genug für Zukünftiges.
>
> Aber die Jungspunde wollen ja nichts als C können und alle bisherigen
> Versuche, aus dieser Furche herauszukommen, sind an zu kleinem geistigen
> Horizont gescheitert.

Das liegt keineswegs am geistigen Horizont -- eine Unterstellung, die Du 
Dir gerne hättest verkneifen können --, sondern an einem anderen Grund: 
nämlich daran, daß C nunmal der etablierte Industriestandard ist, und es 
Unmengen von Code, Libraries etc. dafür gibt. Das sind nunmal handfeste, 
sachliche und technische Gründe, die eindeutig für C sprechen, auch wenn 
die Pascal-Freunde das nicht gerne hören.

[Carl D. (jcw2)]

Man sollte halt auch Bedenken, daß bei C++ eine der wichtigsten 
Designentscheidung war, kompatibel zu C zu sein. Was kein Problem 
darstellen muß. Zudem gibt es ein C++-Kommitee, daß lange ringt, bis 
neue Features implementiert werden. Und wenn dann so was wie das 
Umdeuten eines Keywords wie bei "auto" ansteht (das ist in 2 Jahrzehnten 
der einzige Fall), dann werden vorher alle verfügbaren Sourcen 
gescanned, um abzuklären ob das geht.

Und für alle, denen OO mit C++ zu kryptisch ist, gibt es auch 
Object-FORTRAN oder noch besser Object-COBOL, da kann man dann auch 
Romane schreiben.

> Und wenn der Bauer nicht schwimmen kann, liegt es an der Badehose. ;-)

Ist doch klar. Was denn sonst. Schließlich leben wir doch gerade in 
einer Phase, in der, wenn man sich verzockt hat, immer alle anderen 
Schuld sind.

[(prx) A. K. (prx)]

Sheeva P. schrieb:
> Das ist aber nur eine Frage Deines persönlichen Geschmacks, über den
> sich bekanntlich nicht streiten läßt, und somit kein technisches oder in
> einer anderen Weise sachliches Argument.

Ich teile die Kritik an C++ seitens W.S., verstehe aber auch den Ansatz 
von Stroustrup.

Die Syntax ist an mehreren Stellen übel verkrampft und auch zweideutig. 
Die Grundstruktur der Sprache sorgt für unnötig schlechte Lesbarkeit, 
aufgrund verkorkster Deklarationstechnik. Das ist freilich kein Fehler 
von C++, sondern ein Erbe von C, das durch die Komplexität von C++ 
verstärkt auftritt.

Hätte Stroustrup aber eine syntaktisch völlig neue Sprache definiert, es 
wäre ihm wahrscheinlich so ergangen wie Wirth. Viel Lob aus den Rängen 
der Akademie, wenig Erfolg in der Masse.

> Bei mir sieht es anders aus:
> ich habe keine Angst vor Tilden, Doppelpunkten und anderen Sonderzeichen
> (solange wir hier nicht über APL reden... :-))

Ich favorisiere zwar eine klarere eher wortorientierte Ausdrucksweise, 
kann aber mit Sonderzeichen leben. APL mag mich in Aspekten wie 
räumlichem Denken bei der Programmierung beeinflusst haben, aber weder 
in der Ausdrucksform der Sprache noch in der Strukturierung von 
Programmen. Das ist aber auch nicht der Punkt. (NB: Ich tippe Worte 
schneller als den Salat aus AltGR-Sonstwas auf deutscher Tastatur, 
weshalb ich lange Zeit US-Layout vorzog).

Zu den Fehlern von C und damit C++ gehört die Deklarationssyntax. Statt 
dem C'schen hin- und her mit Hilfe von Vorrangtabellen, über das 
Anfänger immer und manche ein Leben lang stolpern, gehört sich so etwas 
linear von links nach rechts, oder von mir aus auch umgekehrt. Dass ich 
mit dieser Ansicht nicht allein bin zeigt GO, denn das adressiert u.A. 
genau diesen Punkt, ohne sich syntaktisch allzu radikal von C zu lösen.

> In Wirklichkeit ist diese Syntax vermutlich auch nur dann schwer lesbar,
> wenn man nicht daran gewöhnt ist. Wie sonst wäre es zu erklären, daß es
> dermaßen viele Sprachen gibt, die sich an diese Syntax anlehnen:

Das ist weniger der Qualität zuliebe so, als aus der Erkenntnis 
abgeleitet, dass viele Leute eine ihnen bekannt vorkommende Syntax 
präferieren.

> Die Designentscheidungen sind nun einmal gemacht, und sich
> darüber zu ärgern, kann und wird nichts mehr daran ändern.

Die normative Kraft des Faktischen.

> Jetzt hat man
> als Entwickler die Wahl: entweder, man findet Dich mit den Gegebenheiten
> ab, oder man läßt es bleiben und sucht sich die Nische, in der man mit
> einer Sprache und Syntax arbeiten kannst, die einem eher zusagen.

Ja.

> Das liegt keineswegs am geistigen Horizont

Der Begriff "Bildungshorizont" kam ursprünglich von mir, nicht von W.S. 
Und ich stehe dazu, zumindest im Kontext eines studierten Informatikers. 
So jemand sollte ein Spektrum von Sprach-Paradigmata kennengelernt 
haben. Und damit meine ich nicht so sehr C vs Pascal, oder C++ vs Java, 
denn die unterscheiden sich in dieser Hinsicht nicht voneinander. 
Sprachen von Lisp über APL und Smalltalk bis hin zum extrem abweichenden 
Prolog demonstrierten mir früher, dass es mehr gibt als prozedurale 
Sprachen mit Skalaren als dominanten Datentypen. IMHO ist dies auch so 
etwas, das Informatik von Programmieren unterscheidet.

> Das sind nunmal handfeste, sachliche und technische Gründe,
> die eindeutig für C sprechen, auch wenn
> die Pascal-Freunde das nicht gerne hören.

Natürlich. Weshalb ich u.A. C und C++ verwende. Dass ich zwar 
gelegentlich als Kritiker von C auftrete, mir diese Sprache aber 
keineswegs fremd ist, dürften manche hier schon gemerkt haben. ;-)

[(prx) A. K. (prx)]

Sheeva P. schrieb:
> In Wirklichkeit ist diese Syntax vermutlich auch nur dann schwer lesbar,
> wenn man nicht daran gewöhnt ist.

Japaner jonglieren mit 4 verschiedenen Schriftsystemen im gleichen Text, 
in 3 verschiedenen Paradigmata, von denen die komplexeste Schrift 
eigentlich überhaupt nicht zur Sprache passt. Und das völlig 
selbstverständlich, jedenfalls bei ausreichender Bildung.

Das heisst aber bloss, dass Menschen mit ausreichend Aufwand auch arg 
unpraktische Systeme zu beherrschen in der Lage sind. Nicht aber, dass 
man - wenn man die Wahl hat - so etwas anstreben sollte.

[Michael B. (laberkopp)]

A. K. schrieb:
> Sprachen von Lisp über APL und Smalltalk bis hin zum extrem abweichenden
> Prolog demonstrierten mir früher, dass es mehr gibt als prozedurale
> Sprachen mit Skalaren als dominanten Datentypen.

Natürlich.

Aber weder in Lisp, noch in APL noch in Prolog wurden brauchbare 
Programme geschrieben, sebst bei Smalltalk kenne ich ganze Firmen die 
damit untergegangen sind.

Die taugen höchsten in Nischen als Macrosprache (Emacs, AutoCad) oder 
Rule-Engine. Die Wahl der falschen Sprache kann also sehr wohl fatal 
sein, obwohl alles Turing vollständige Sprachen sind, also 
leistungsmässig äquivalent.



W.S. schrieb:
>> C ist wesentlich wartungsfreundlicher.
>
> .. als C++
> Ja, sehe ich genauso.

Psssst, das darfst du hier nicht sagen. Die Anderen hier sehen gar 
nichts.

[Carl D. (jcw2)]

Moby A. schrieb im Beitrag #4629249:
> Ob dieser Hinweis hier wirklich bei jedem auf fruchtbaren Boden fällt?
> Manch einer betrachtet gerade die lernintensiven "arg unpraktischen"
> Systeme mit ihrer komplizierteren Herangehensweise als der Weisheit
> letzten Schluß. Komplexität (= flexiblere Realisierungsformen) wird hier
> geradezu angehimmelt als Wert an sich.
.
> Ausgeblendet wird dabei mal eben der höhere "Verwendungs-Aufwand" = der
> Aufwand, das nötige Wissen zur Anwendung zu erwerben und dieses immer
> wieder wirklich richtig einzusetzen. Mit höheren Ansprüchen dünnt die
> Spitze der "Könner" aber aus und das Mittelmaß bestimmt öfter die
> Landschaft. Mit Mittelmaß wiederum büßen Systeme mit hohen Ansprüchen an
> möglicher Effizienz ein.
.
> Ausgeblendet wird schließlich in den Fokus zu nehmen, wieviel
> Komplexität die konkrete Anwendung vielleicht gerade nur zu ihrer
> Umsetzung benötigt.
>
> Solche "arg unpraktischen" Systeme können je nach Anwendungsfall sein:
> OOP (vs. prozedural) oder auch 32-Bit (vs. 8-Bit) bzw. im Bedienkomfort
> Linux (vs. Windows).

Schreibt einer, der sich laut anderem Thread einen hochkomplexen 32bit 
Rechner zulegt und dann schon beim Passwort eintippen vor großen 
Problemen steht: "da werden ja gar keine Zeichen angezeigt". Aber schön, 
daß hier auch die unbeleckten mitschreiben dürfen.

[Sheeva P. (sheevaplug)]

A. K. schrieb:
> Hätte Stroustrup aber eine syntaktisch völlig neue Sprache definiert, es
> wäre ihm wahrscheinlich so ergangen wie Wirth. Viel Lob aus den Rängen
> der Akademie, wenig Erfolg in der Masse.

Es ging darum, C mit OO zu erweitern und dabei trotzdem, soweit möglich, 
kompatibel zu C zu bleiben, mit allen Implikationen, die die Erweiterung 
einer existierenden Sprache nunmal hat. So gesehen, mögen die Ergebnisse 
von Stroustrup und Co. nicht perfekt sein, aber bezüglich der 
gewünschten Ziele ist das Ergebnis ziemlich gut.

> Zu den Fehlern von C und damit C++ gehört die Deklarationssyntax. Statt
> dem C'schen hin- und her mit Hilfe von Vorrangtabellen, über das
> Anfänger immer und manche ein Leben lang stolpern, gehört sich so etwas
> linear von links nach rechts, oder von mir aus auch umgekehrt. Dass ich
> mit dieser Ansicht nicht allein bin zeigt GO, denn das adressiert u.A.
> genau diesen Punkt, ohne sich syntaktisch allzu radikal von C zu lösen.

Go hat auch fünf verschiedene Vorränge, ok, C kennt 15. Aber bei 
Software ohne mathematischen oder statistischen Hintergrund ist das doch 
wohl eher nebensächlich; die meisten Entwickler, die ich kenne, benutzen 
an dieser Stelle im Zweifelsfall einfach Klammern.

>> Die Designentscheidungen sind nun einmal gemacht, und sich
>> darüber zu ärgern, kann und wird nichts mehr daran ändern.
>
> Die normative Kraft des Faktischen.

Ja, genau. Gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht 
ändern kann, den Mut, Dinge zu ändern, die ich ändern kann, und die 
Weisheit, das eine vom anderen zu unterscheiden.

> Und ich stehe dazu, zumindest im Kontext eines studierten Informatikers.
> So jemand sollte ein Spektrum von Sprach-Paradigmata kennengelernt
> haben. Und damit meine ich nicht so sehr C vs Pascal, oder C++ vs Java,
> denn die unterscheiden sich in dieser Hinsicht nicht voneinander.
> Sprachen von Lisp über APL und Smalltalk bis hin zum extrem abweichenden
> Prolog demonstrierten mir früher, dass es mehr gibt als prozedurale
> Sprachen mit Skalaren als dominanten Datentypen. IMHO ist dies auch so
> etwas, das Informatik von Programmieren unterscheidet.

Tja, ich bin kein studierter Informatiker und habe trotzdem verschiedene 
Paradigmen kennengelernt. Da die verbreiteten Sprachen aber alle mehrere 
Paradigmen unterstützen, ist das eher von akademischem Interesse. In der 
Praxis werden Paradigmen oft parallel genutzt. Warum auch nicht?

>> Das sind nunmal handfeste, sachliche und technische Gründe,
>> die eindeutig für C sprechen, auch wenn
>> die Pascal-Freunde das nicht gerne hören.
>
> Natürlich. Weshalb ich u.A. C und C++ verwende. Dass ich zwar
> gelegentlich als Kritiker von C auftrete, mir diese Sprache aber
> keineswegs fremd ist, dürften manche hier schon gemerkt haben. ;-)

Kein Zweifel daran. Aber Deine Kritik ist ja auch fundiert und sachlich, 
und genau das ist der kleine, feine Unterschied. ¦-)

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4629249:
> Manch einer betrachtet gerade die lernintensiven "arg unpraktischen"
> Systeme mit ihrer komplizierteren Herangehensweise als der Weisheit
> letzten Schluß.

Sicher nicht. Wenn es morgen eine einfachere Möglichkeit gibt, dann bin 
ich der Erste, der sie adoptiert. Für professionelle Entwickler geht es 
immer nur um Effizienz, alles andere ist nebensächlich.

> Komplexität (= flexiblere Realisierungsformen) wird hier
> geradezu angehimmelt als Wert an sich.

Nö.

> Ausgeblendet wird dabei mal eben der höhere "Verwendungs-Aufwand" = der
> Aufwand, das nötige Wissen zur Anwendung zu erwerben

Den leistet man genau ein einziges Mal.

[Sheeva P. (sheevaplug)]

Michael B. schrieb:
> Aber weder in Lisp, noch in APL noch in Prolog wurden brauchbare
> Programme geschrieben, sebst bei Smalltalk kenne ich ganze Firmen die
> damit untergegangen sind.

Aus eigener Anschauung kenne ich zwei Banken und einen Mobilfunker, bei 
denen wesentliche Teil der geschäftskritischen Software in Smalltalk 
implementiert sind.

> Die Wahl der falschen Sprache kann also sehr wohl fatal sein,

Das mag ja gerne sein, aber auf OO im Allgemeinen und C++ im Besonderen 
trifft das zweifellos nicht zu.

Erfreulich, daß Du auch in der Sache etwas beitragen kannst. :-)

[(prx) A. K. (prx)]

Sheeva P. schrieb:
> Go hat auch fünf verschiedene Vorränge, ok, C kennt 15.

Bei der Deklaration verwendet man besser überhaupt keine. Es geht mit um 
den Unterschied zwischen sowas wie der C Notation
  int (*a)[5]
  int *b[5]
und der wesentlich leichter linear von links nach rechts lesbaren 
Schreibweise
  a: pointer to array[5] of int
  b: array[5] of pointer to int
oder der dazu analogen an C orientierten Kurzschrift von Go
  a *[5]int
  b [5]*int

Um die C Deklaration zu entschlüsseln benötigt man nicht nur 
Prioritäten, sondern muss überhaupt erst einmal rausfinden, wo man 
anfangen muss. Man muss einen komplexen Parser im Kopf trainieren, statt 
einfach von links nach rechts zu lesen. Oben ist es noch relativ klar, 
man fängt beim Namen der Variablen an und handelt sich entlang der 
Prioritäten nach aussen. In der Syntax namenloser Typen (z.B. Casts) 
wird das schon interessanter:
  int (*)[5]
  int *[5]

Dazu kommt, dass man in den Pascal/Go Varianten den Namen der Variablen 
sofort findet, während sich der Name in C irgendwo mittendrin versteckt.

Klassendefinitionen in C++ leiden massiv darunter, dass der Name der 
Variablen und insbesondere der Funktion mitten im Gewirr steckt, schon 
in relativ einfachen Fällen. Weil der nicht immer sehr kurze Return-Typ 
der Funktion vorneweg steht, und die Parameter dahinter. Was man nur 
durch konsequente Formatierung des Quellcodes einigermassen in den Griff 
kriegt. Name vorneweg, Parameter und Return-Typ dahinter, ist von Haus 
aus weit übersichtlicher.

Ich habe das hier schon aus Faulheit recht einfach gehalten. Noch ein 
weiteres * oder[] hinzu, angereichert mit const, und der Unterschied in 
der Lesbarkeit wird noch wesentlich krasser. Es soll C Programmierer 
geben, die bis an ihr Lebensende nicht wissen, wie man einen konstanten 
Pointer schreibt. Weshalb man in C gut beraten ist, auf 
Zwischen-Typedefs zu setzen um das zu zerlegen.

@Moby: Bleib in deiner eigenen Welt. Die hier ist nichts für dich. Es 
geht mir hier um die unterschiedliche Struktur von ggf. auch komplexen 
Hochsprachen, nicht um Fundamentalkritik an Hochsprachen generell.

[Michael B. (laberkopp)]

Sheeva P. schrieb:
>> Aber weder in Lisp, noch in APL noch in Prolog wurden brauchbare
>> Programme geschrieben, sebst bei Smalltalk kenne ich ganze Firmen die
>> damit untergegangen sind.
>
> Aus eigener Anschauung kenne ich zwei Banken und einen Mobilfunker, bei
> denen wesentliche Teil der geschäftskritischen Software in Smalltalk
> implementiert sind.

Wenn du lesen könntest, hättest du im Satz oben bemerkt, daß Smalltalk 
nicht in der Liste "weder in..wurden brauchbare Programme geschrieben" 
steht. Der Satz schliesst also nicht aus, daß man in Smalltalk auch mal 
ein brauchbares Programm schreiben kann. Er sagt nur, daß manch eine 
Firma an der Fehlentscheidung zu Grunde gegangen ist.

Aber deine Lesefähigkeit ist offenkundig unterentwickelt. Das sieht man 
auch an deinen anderen Beiträgen hier.

[Michael B. (laberkopp)]

A. K. schrieb:
> Die Syntax ist an mehreren Stellen übel verkrampft und auch zweideutig.
> Die Grundstruktur der Sprache sorgt für unnötig schlechte Lesbarkeit,
> aufgrund verkorkster Deklarationstechnik. Das ist freilich kein Fehler
> von C++, sondern ein Erbe von C, das durch die Komplexität von C++
> verstärkt auftritt.

Sagen wir mal so: In Objective-C ist das alles noch viel schlimmer.

[Assembler ist das Beste der Welt (Gast)]

Am besten alles in Assembler schreiben.
Da hat man alles unter Kontrolle und muß nicht so blödsinnige Sprachen 
lernen.

[Hurz (Gast)]

Assembler ist das Beste der Welt schrieb:
> Am besten alles in Assembler schreiben.
> Da hat man alles unter Kontrolle und muß nicht so blödsinnige Sprachen
> lernen.

Ja, Moby...

[Karl (Gast)]

Assembler ist das Beste der Welt schrieb:
> Am besten alles in Assembler schreiben.
> Da hat man alles unter Kontrolle und muß nicht so blödsinnige Sprachen
> lernen.

Volle Kontrolle hat man aber nur auf dem selbst entwickelten Prozessor, 
deshalb am besten selber Transistoren zusammenlöten!

P.S. Während in Villarriba schon gefeiert wird, wird in Villabajo noch 
Assembler geschrieben.

[Sheeva P. (sheevaplug)]

Michael B. schrieb:
> Sheeva P. schrieb:
>>> Aber weder in Lisp, noch in APL noch in Prolog wurden brauchbare
>>> Programme geschrieben, sebst bei Smalltalk kenne ich ganze Firmen die
>>> damit untergegangen sind.
>>
>> Aus eigener Anschauung kenne ich zwei Banken und einen Mobilfunker, bei
>> denen wesentliche Teil der geschäftskritischen Software in Smalltalk
>> implementiert sind.
>
> Wenn du lesen könntest, hättest du im Satz oben bemerkt, daß Smalltalk
> nicht in der Liste "weder in..wurden brauchbare Programme geschrieben"
> steht. Der Satz schliesst also nicht aus, daß man in Smalltalk auch mal
> ein brauchbares Programm schreiben kann. Er sagt nur, daß manch eine
> Firma an der Fehlentscheidung zu Grunde gegangen ist.

Wenn hingegen Du lesen könntest, hättest Du meine Aussage verstanden, 
daß die Verwendung von Smalltalk nicht zum Untergang des Unternehmens 
führen muß. Offensichtlich solltest Du lieber an Deiner eigenen 
Lesefähigkeit und Deinem Textverständnis arbeiten, statt Dir über meine 
Gedanken zu machen.

Aber wo Du schon so lieb darum bittest, schauen wir uns doch einmal den 
sachlichen Gehalt Deiner anderen Aussagen an...

Tatsächlich ist ein wesentlicher Teil der Funktionalität des GNU/Emacs 
in Lisp geschrieben, AutoCAD hat einen Lisp-Interpreter eingebaut, 
ebenso Audacity und LilyPond. Zudem wird Lisp laut diesem [1] Beitrag 
häufig in "Animation and Graphics, AI, Bioinformatics, B2B and 
E-Commerce, Data Mining, Electronic Design Automation/Semiconductor 
applications, Expert Systems, Finance, Intelligent Agents, Knowledge 
Management, Mechanical Computer Aided Design (CAD), Modeling and 
Simulation, Natural Language, Optimization, Research, Risk Analysis, 
Scheduling, Telecom, and Web Authoring" eingesetzt. Dr. Dobb's hat dazu 
einen schon etwas älteren Artikel [2] darüber, wofür Prolog so alles 
eingesetzt wird.

Für APL bin ich jetzt zu faul zum Suchen, Tatsache ist jedenfalls: nicht 
nur Deine implizite Andeutung ist falsch, daß Unternehmen aufgrund ihrer 
Verwendung von Smalltall untergingen, ebenso falsch ist Deine 
Behauptung, in Prolog und Lisp seien keine brauchbaren Programme 
geschrieben worden.

Neben Deinen Lesefähigkeiten und Deiner Sozialkompetenz ist also auch 
Dein Fachwissen noch ziemlich ausbaufähig, was insbesondere dann etwas 
peinlich wirkt, wenn Du hier die dicke Host gibst und professionelle 
Entwickler mit jahrzehntelanger Berufserfahrung abkanzelst. Zum Glück 
erkennen geneigte Leser durch Deine Ausfallerscheinungen, was vom 
sachlichen Gehalt Deiner Aussagen zu halten ist. :-)

[1] https://www.quora.com/What-is-Lisp-used-for
[2] 
http://www.drdobbs.com/parallel/the-practical-application-of-prolog/184405220

> Aber deine Lesefähigkeit ist offenkundig unterentwickelt.

Solange ich C++ ohne Debugger verstehe, bin ich da unbesorgt. :-)

[(prx) A. K. (prx)]

Sheeva P. schrieb:
> Für APL bin ich jetzt zu faul zum Suchen,

In den Jahren um 1980 herum wurde APL produktiv auf einem Mainframe in 
einem grösseren Unternehmen eingesetzt. Mir bekannte Einsatzbereiche 
waren - naheliegend - das CAD Umfeld und rechnerische Verfahren. Aber 
auch gänzlich andere Rollen, nämlich interaktive Verwaltungsaufgabe, 
also Datenbank mit Dialog-Frontend. Programmierung in diesen Bereichen 
hatte mir damals ein paar Mäuse über Ferienjobs eingebracht.

[Chris F. (chfreund)]

Eins vorneweg:
Man darf den Trollen nie gegenüber persönlich verletzend werden, 
besonders nicht, wenn die selber damit angefangen haben. "Michael 
Bertrand" ist eine arme Sau und wir sollten ihm genau das geben was er 
in seinem Leben sonst nie erfährt: Einen respektvollen Umgangston.

Das durch den Einsatz von Smalltalk irgeneine Firma zugrunde geht, halte 
ich für ein Gerücht. Leute die mit solchen Sprachen arbeiten wissen auch 
wo deren Grenzen sind und können auch mit den Systemen umgehen die ihre 
Smalltalk-Umgebungen hosten.
Es wird auch heute noch im Finanzsektor und in der Forschung intensiv 
eingesetzt. Wer Smalltalk kennt weiß auch, dass Javascript und C++ 
eigentlich garnicht "richtig" objektorientiert sind. ;-)

[Chris F. (chfreund)]

A. K. schrieb:
> Sheeva P. schrieb:
>> Für APL bin ich jetzt zu faul zum Suchen,
> In den Jahren um 1980 herum wurde APL produktiv auf einem Mainframe in [..]

Das gibt es auch heute noch innerhalb von Versicherungsrechenkernen. Da 
hatte ich mal auf der Arbeit mit zu tun. Wurde auf Windows von einer 
C-Dll aufgerufen, die wiederum von einem Cobol-Tool aufgerufen wurde.

[Michael B. (laberkopp)]

Chris F. schrieb:

> Das durch den Einsatz von Smalltalk irgeneine Firma zugrunde geht, halte
> ich für ein Gerücht.

Das liegt wahrscheinlich an deiner unzureichenden Praxiserfahrung.

> Man darf den Trollen nie gegenüber persönlich verletzend werden,
> besonders nicht, wenn die selber damit angefangen haben.

Hmm, angefangen.
Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?"

Nach deiner Doktrin darfst du jetzt also anfangen.

> "Michael Bertrand" ist eine arme Sau ..

... ist ein persönliche Beleidigung aber das ist DIR natürlich recht.

Aber das ist ein schöner Thread: Hier hat man gleich die ganze 'Elite', 
die Verursacher der aktuellen Softwarekrise ist, auf einen Haufen.

[Chris F. (chfreund)]

Michael B. schrieb:
>> "Michael Bertrand" ist eine arme Sau und wir
>> sollten ihm genau das geben was er
>> in seinem Leben sonst nie erfährt:
>> Einen respektvollen Umgangston.
>
> ... ist ein persönliche Beleidigung aber das ist DIR natürlich recht.

Dafür das Du so austeilst bist Du aber SEHR dünnhäutig, mein Lieber. ;-)

Mein Mitleid hast Du Dir ehrlich erarbeitet.

Benenne doch mal die Firm_EN_ die an Smalltalk zu Grunde gingen. Wenn 
die eh pleite und kaputt sind, sollte das ja kein Problem sein. Leg los. 
:)

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4630612:
> Alles bitteschön dort wo es wirklich Sinn macht ;-)

Natürlich. Kein denkender Mensch benutzt einen Akkuschrauber, um Nägel 
einzuschlagen. Daß es Menschen gibt, die das trotzdem versuchen, spricht 
weder gegen Akkuschrauber, noch gegen Nägel.

Andererseits kann jemand, der nur Nägel kennt, den Nutzen und den Zweck 
von Akkuschraubern natürlich nicht verstehen.

[Sheeva P. (sheevaplug)]

Chris F. schrieb:
> Dafür das Du so austeilst bist Du aber SEHR dünnhäutig, mein Lieber. ;-)

;-)

> Mein Mitleid hast Du Dir ehrlich erarbeitet.

Mitleid bekommt man geschenkt. Nur Neid muß man sich erarbeiten.

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4630642:
> Sheeva P. schrieb:
>> Andererseits kann jemand, der nur Nägel kennt, den Nutzen und den Zweck
>> von Akkuschraubern natürlich nicht verstehen.
>
> Das sagt der Richtige ;-)

Gut erkannt.

[Bernd K. (prof7bit)]

Moby A. schrieb im Beitrag #4630642:
> Sheeva P. schrieb:
>> Andererseits kann jemand, der nur Nägel kennt, den Nutzen und den Zweck
>> von Akkuschraubern natürlich nicht verstehen.
>
> Das sagt der Richtige ;-)

Er ist ja schon drollig unser Moby. Oft wirkt er zwar nur unfreiwillig 
komisch aber manchmal hat man fast das Gefühl er übt sich in der 
vollendetsten Form der Selbstironie, so extrem in der Aussage und doch 
zugleich der Spott über sich selbst so subtil zwischen den Zeilen 
versteckt daß man es fast nicht bemerkt. Meisterhaft!

[Carl D. (jcw2)]

Bernd K. schrieb:
> Er ist ja schon drollig unser Moby. Oft wirkt er zwar nur unfreiwillig
> komisch aber manchmal hat man fast das Gefühl er übt sich in der
> vollendetsten Form der Selbstironie, so extrem in der Aussage und doch
> zugleich der Spott über sich selbst so subtil zwischen den Zeilen
> versteckt daß man es fast nicht bemerkt. Meisterhaft!

Nur verstanden hat er dich nicht. Also wohl doch eher unfreiwillig 
komisch.

[Karl Käfer (Gast)]

Heiner schrieb im Beitrag #4632584:
> Moby A. schrieb im Beitrag #4632581:
>> Ich denke bei Kurt Bindl bist Du wirklich besser aufgehoben, da kann man
>> Deine Beiträge eher als fachspezifisch werten ;-)
>
> Komm schon Moby, jeder der hier schon länger als ein paar Wochen
> vorbeischaut, weiß noch wie du dich bis auf die Knochen blamiert hast
> mit deinem Wissen.

Es war wohl weniger das Wissen, als vielmehr dessen Absenz. ;-)

[Tobias (Gast)]

Moby A. schrieb im Beitrag #4633161:
> Zu was steigende und steigende und steigende Komplexität generell führt
> kann man gerade bei der bundesweiten Netz-Störung bei Vodafone/Kabel
> beobachten.

Stimmt. Wenn die gesamte Netz-Software in ASM programmiert wäre, hätte 
das nicht passieren müssen. Schuld ist nur die Faulheit, ASM zu lernen 
:-)

[Karl (Gast)]

Moby A. schrieb im Beitrag #4633161:
> OOP bläst die geradezu
> explosionsartig auf. Und der Trend zu immer neuen, detaillierteren
> Konstruktionen geht weiter...

Nein bei einer ordentlichen Softwareentwicklung führt OOP genau zu dem 
Gegenteil. Komplexe Systeme werden in kleine Pakete zerlegt und der Code 
kann gut lesbar geschrieben werden (das bezieht sich nicht explizit 
aus C++).

[Daniel A. (daniel-a)]

@Moby AVR (moby-project)

Es ist wohl wahr, das man schlechten Code schreiben kann, wenn man jedes 
Konstrukt und jedes Pattern hineinpackt, nur wel es existiert. Solange 
man aber nur Konstrukte verwendet die zur jeweiligen Problemstellung 
passen, und man ein Gesammtkonzept sowie Namenskonventionen hat, ist es 
bei OOP doch wesentlich einfacher zu lesen, sich zurechtzufinden, und 
auch grössere Änderungen vorzunehmen.

Was ich an OOP am meisten schätze ist, das zusammengehörende Daten 
zusammengefasst werden. Ich arbeite gerade an einem Projekt, welches 
älter als ich bin ist, das teile enthält von 1992. Es ist in C und 
Fortran, und es gibt Tonnenweise globale Variablen und 
Convertierfunktionen zwischen z.B. c und Fortran strings. Die 
Funktionsaufrufe c->fortran und umgekehrt wurden erreicht, indem c 
Funktinsnamen und Typen in abhängigkeit vom Compiler an die Fortran ABI 
angepasst wurde. Und nun lauft das Refactoring, wo das alles geändert 
werden muss... Da lernt man die Modernen Interopabilitätstandards und 
die Designpatterns sowie OOP erst richtig zu schätzen.

[MaWin (Gast)]

Karl schrieb:
> Nein bei einer ordentlichen Softwareentwicklung führt OOP genau zu dem
> Gegenteil. Komplexe Systeme werden in kleine Pakete zerlegt und der Code
> kann gut lesbar geschrieben werden (das bezieht sich nicht explizit
> aus C++).

Eine ordentliche Softwareentwicklung besteht sowieso daraus, komplexe 
Systeme in kleine Pakete zu unterteilen und die in gut lesbaren Code zu 
formulieren,

ob mit OOP oder ohne.

Ob OOP das gut unterstützt oder nicht, ist eine durchaus offene Frage. 
Bei C++ kann man da Zweifel haben, bei Java sieht es besser aus finde 
ich, aber Java lebt zu sehr in seiner eigenen Welt.

Wenn heute davon geredet wird, ein Uniabsolvent könne "C++" kann er 
meist bloss "C" und wenn man davon redet, die Programme wären in "C++" 
geschrieben, sind sie meist bloss in "C". Oder schlecht.

Wie schlecht objektorientierte Formulierungen von durchaus 
objektorientierten Welten sein können, sieht man an MFC.

[Karl Käfer (Gast)]

Moby A. schrieb im Beitrag #4633161:
> Zu was steigende und steigende und steigende Komplexität generell führt
> kann man gerade bei der bundesweiten Netz-Störung bei Vodafone/Kabel
> beobachten die immer noch nicht behoben ist. Das gilt für Software mit
> ihrer steigenden Bürokratie ganz genauso (ob die wohl dahintersteckt?).

Nach dem Buschfunk liegt es an einem defekten Backbone-Switch -- die 
sind aber alle in Assembler programmiert.

Es bestätigt sich, was die klugen Benutzer moderner Hochsprachen bereits 
wissen: unlesbarer Assembler-Spaghetticode ist nicht dazu geeignet, die 
Komplexität realer Probleme zu beherrschen. Darum fällt einem Assembler 
bei allem, das komplizierter ist als blinkende LEDs, irgendwann böse auf 
die Füße -- Dir früher, anderen später.

Aber wem sage ich das. In Deinem ersten Assemblerthread haben Dir die 
hier anwesenden Experten sogar in Deinen wenigen Dutzend Zeilen 
trivialsten Codes etliche gravierende Anfängerfehler nachgewiesen.

Aber Respekt vor Deinem Mut! Jeder, der sich irgendwo so blamiert hat 
wie Du hier, würde normalerweise mikroskopisch kleine Nanobrötchen 
backen.

> OOP bläst die geradezu explosionsartig auf. Und der Trend zu immer
> neuen, detaillierteren Konstruktionen geht weiter... Bloß gut, daß die
> Experten hier alles unter Kontrolle haben. Stimmts, Karl Käfer?

Nein, Moby AVR, stimmt nicht. Das genaue Gegenteil trifft zu: 
schwierigere Probleme können nur gelöst werden, weil OO die Komplexität 
reduziert.

[W.S. (Gast)]

Sheeva P. schrieb:
> Wie sonst wäre es zu erklären, daß es
> dermaßen viele Sprachen gibt, die sich an diese Syntax anlehnen: C++, na
> klar, aber auch Java, Perl, ECMAScript, R, Google Go, PHP, sowie etwa 60
> andere. Das hätten die Autoren dieser Sprachen sicherlich nicht gemacht,
> wenn sie die Syntax als schlecht lesbar empfunden hätten.

GRÖHL...

Also, du verwechselst mal wieder die Dinge ganz gehörig. Andersherum 
wird der berüchtigte Schuh draus:

Es hat bereits vor langen Jahren genug Leute gegeben, die erkannt haben, 
daß man mit C auf Dauer nicht froh wird, weil C eben nicht geeignet ist, 
mit wachsenden Anforderungen mitzuwachsen. Genau deshalb hane sich all 
diese Leute darangemacht, etwas neueres zu kreieren: C++, Java und 
Konsorten. Aber da sie nun mal bereits beim Entwurf ihrer "neuen" 
Sprache von C geistig verbogen sind (oder sagen wir's dezenter 
"vororientiert" sind), ist bei allen Versuche, was Neues zu kreieren, 
eben immer ein durchgemangeltes C dabei herausgekommen. Die 
C-Programmierer kommen eben nicht mehr aus ihrer geistigen Furche 
heraus. Das ist es.

Eine andere Frage ist es, warum gerade berufsmäßige Programmierer sich 
auf C gestürzt haben und schlichtweg bessere Pascal aufgegeben haben. 
Ich hatte dazu mal nen Burschen gefragt, der mal bei mir in der Firma 
war und sich dann woanders zum Programmierer entwickelt hat. Antwort: 
Bei Pascal muß man ja so viel schreiben und der Chef bildet sich ein, er 
könnte sowas verstehen, weil es ja lesbar aussieht.

W.S.

[W.S. (Gast)]

Sheeva P. schrieb:
> Den leistet man genau ein einziges Mal.

Nein, im Allgemeinen eben nicht.

Es gibt Ausnahme in Form von reinen Programmierern, die den ganzen Tag 
nichts anderes machen.

Alle anderen Leute, die beruflich neben Anderem eben auch programmieren, 
haben den Aufwand jeden Tag.

Ich merk das ja an mir selber beim ständigen Umschalten von C nach 
Delphi und wieder zurück - und weil ich daneben eben auch noch einen 
Sack ganz anderer Esel zu kämmen habe. Wer nix anderes tut als immerzu 
nur in einem engen Kreis ähnlichster Sprachen zu programmieren, der 
merkt das halt nicht und kommt dann zu solchen Aussagen wie du.

Und was die Zukunft angeht: Ich schätze, es wird weiter mit C gehen, 
ganz gleich, wie unangemessen C für künftige Aufgaben sein wird. Dafür 
gibt es dann in steigendem Maße Zusatz-Zeugs wie Programmgeneratoren, 
Kontrolletti-Systeme (MISRA & Co) und so weiter. Mit steigender 
Komplexität steigt die Bugrate an, weswegen sich insbesondere 
Kontrolettizeugs rasant vermehren wird. Pascal wird sich in Form von 
Delphi in den Sphären von Datenbank-Affinem halten und die Kraft, einen 
Schnitt zu machen und was wirklich dem dann erforderlichen Stand der 
Dinge entsprechendes zu schaffen, wird keiner haben.

Ob ich das dann gut finden werde? Nö. Hauptsache ABS, ESP und anderer 
Krempel in meinem Auto sind nicht so buggy wie derzeit beim Tesla.

W.S.

[(prx) A. K. (prx)]

Karl Käfer schrieb:
> Nach dem Buschfunk liegt es an einem defekten Backbone-Switch -- die
> sind aber alle in Assembler programmiert.

Eher noch ein wenig weiter unten. Switching Engines sind spezielle 
Hardware, nicht Software. Die Software konfiguriert und verwaltet.

[Sheeva P. (sheevaplug)]

MaWin schrieb:
> Eine ordentliche Softwareentwicklung besteht sowieso daraus, komplexe
> Systeme in kleine Pakete zu unterteilen und die in gut lesbaren Code zu
> formulieren,
>
> ob mit OOP oder ohne.
>
> Ob OOP das gut unterstützt oder nicht, ist eine durchaus offene Frage.

Nein, eigentlich nicht. Diese Diskussion gibt es nur im Embedded-Umfeld, 
wo die OO ihre Stärken wegen der meist eher überschaubaren Projektgrößen 
nicht voll ausspielen kann. Aber überall dort, wo Projekte regelmäßig 
größer als einige 10k oder 100k LOC sind, ist die Diskussion schon lange 
entschieden, und zwar eindeutig für die OOP.

> Wenn heute davon geredet wird, ein Uniabsolvent könne "C++" kann er
> meist bloss "C" und wenn man davon redet, die Programme wären in "C++"
> geschrieben, sind sie meist bloss in "C". Oder schlecht.

Vielleicht kenne ich andere Uniabsolventen als Du.

> Wie schlecht objektorientierte Formulierungen von durchaus
> objektorientierten Welten sein können, sieht man an MFC.

Ach Du liebe Güte... die MFC war niemals ein OO-Design, sondern 
lediglich ein Wrapper um die c- und assemblerbasierte WinAPI.

[Sheeva P. (sheevaplug)]

W.S. schrieb:
> Es hat bereits vor langen Jahren genug Leute gegeben, die erkannt haben,
> daß man mit C auf Dauer nicht froh wird, weil C eben nicht geeignet ist,
> mit wachsenden Anforderungen mitzuwachsen. Genau deshalb hane sich all
> diese Leute darangemacht, etwas neueres zu kreieren: C++, Java und
> Konsorten. Aber da sie nun mal bereits beim Entwurf ihrer "neuen"
> Sprache von C geistig verbogen sind (oder sagen wir's dezenter
> "vororientiert" sind), ist bei allen Versuche, was Neues zu kreieren,
> eben immer ein durchgemangeltes C dabei herausgekommen. Die
> C-Programmierer kommen eben nicht mehr aus ihrer geistigen Furche
> heraus. Das ist es.
>
> Eine andere Frage ist es, warum gerade berufsmäßige Programmierer sich
> auf C gestürzt haben und schlichtweg bessere Pascal aufgegeben haben.

Ich verstehe ja, daß es Dich ärgert und schmerzt, daß die C-basierten 
sich letztlich gegen Dein geliebtes Pascal durchgesetzt haben. Aber wenn 
Du den Entwicklern und Anwendern von C-basierten Sprachen pauschal 
vorwirfst, von C verdorben, zu faul, oder zu dumm zu sein, um andere 
Sprachen zu erlernen dann ist das ebenso arrogant wie dumm von Dir 
selbst und disqualifiziert nicht darum nur Deinen Standpunkt.

Darüber hinaus ist Deine hohle Unterstellung aber auch vollkommen 
falsch, soweit es mich betrifft: ich bin vor vielen Jahren von Basic und 
Assembler erst zu C, später zu C++ gekommen, habe viele Jahre lang Perl 
genutzt und erfreue mich heute an Python und Lua. Und morgen setze ich 
vielleicht auf Rust, Nim, Go oder Scala? Das wird sich zeigen, ich bin 
da flexibel.

Warum ich mit Pascal nie warm geworden bin? Keine Ahnung. Tatsächlich 
habe ich von TurboPascal über Kylix bis Delphi und Lazarus immer wieder 
einmal hineingeschaut (und manchmal sogar Geld ausgegeben), aber 
irgendwie hat es mich nie so richtig überzeugt.

[Sheeva P. (sheevaplug)]

W.S. schrieb:
> Sheeva P. schrieb:
>> Den leistet man genau ein einziges Mal.
>
> Nein, im Allgemeinen eben nicht.
>
> Es gibt Ausnahme in Form von reinen Programmierern, die den ganzen Tag
> nichts anderes machen.
>
> Alle anderen Leute, die beruflich neben Anderem eben auch programmieren,
> haben den Aufwand jeden Tag.
>
> Ich merk das ja an mir selber beim ständigen Umschalten von C nach
> Delphi und wieder zurück - und weil ich daneben eben auch noch einen
> Sack ganz anderer Esel zu kämmen habe. Wer nix anderes tut als immerzu
> nur in einem engen Kreis ähnlichster Sprachen zu programmieren, der
> merkt das halt nicht und kommt dann zu solchen Aussagen wie du.

Wie gesagt: im Moment nutze ich hauptsächlich C, C++, Python und Lua, 
und Programmieren ist nur eine Nebenaufgabe meiner eigentlichen Arbeit 
bei der Datenverarbeitung, -analyse und -visualisierung. Trotzdem kann 
ich Deine Aussagen leider beim besten Willen nicht nachvollziehen: OO 
ist nur eins von einer ganzen Reihe von Werkzeugen, die ich nutze, wie 
mit dem Hammer und dem Akkuschrauber: für einen Nagel nehme ich einen 
Hammer, für eine Schraube einen Akkuschrauber. So what?

> Ob ich das dann gut finden werde? Nö. Hauptsache ABS, ESP und anderer
> Krempel in meinem Auto sind nicht so buggy wie derzeit beim Tesla.

Naja, verglichen mit einem System zum autonomen Fahren, wie es gerade 
bei einem Tesla versagt hat (wobei auch der Fahrer des Tesla den LKW ja 
wohl übersehen hat), sind ein ABS und ein ESP doch eher trivial.

[Dieter V. (Gast)]

Moby A. schrieb im Beitrag #4634054:
> Und wie Du oben schon selber bestätigt hast taugt Asm für mehr als nur
> blinkende LEDs ;-)

Also ich lese da was anderes, eher das Gegenteil:
> Darum fällt einem Assembler bei allem, das komplizierter ist
> als blinkende LEDs,
> irgendwann böse auf die Füße -- Dir früher, anderen später.

[Andreas H. (ahz)]

Sheeva P. schrieb:
> Ich hab ja heimlich den Verdacht, daß Lisp in Wahrheit Binärcode ist:
> "(" für eine 1, ")" für eine 0, alles andere sind Kommentare. :-)

Naja, ohne die Diskussion weiter in Richtung Lisp treiben zu wollen, 
solltest Du Dir Common Lisp vielleicht mal ansehen.
Die Sprache ist nämlich wirklich Klasse und (entgegen der "öffentlichen" 
Meinung) auch gut im Einsatz. Allerdings erkennt man viele Vorteile 
erst, wenn man nach einer Weile CL wieder zu was anderem wechseln muss 
:/

Das Stichwort in Zusammenhang mit OOP wäre CLOS (Common Lisp Object 
System). Da kannst Du z.B. auch den Method Dispatch (fast) beliebig 
umbauen ;-)

Da Du ja KEIN Anfänger bist:
"The Art of the Metaobject Protocol" von Gregor Kiczales u.a. (JA, das 
IST der Kiczales, der auch AspectJ entwickelt hat).

Und bitte, bitte kein Language War. Das ist doch so ermüdend ;-)

/regards

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4634073:
> OOP hat seine Stärken. Dort wo es Sinn macht: Große Projekte mit großen
> Datenmengen.

Gerade bei großen Datenmengen tendiere ich eher zu funktionalen 
Techniken, weil die sich oft besser parallelisieren und verteilen 
lassen.

> Handwerkszeug welches man beherrscht macht immer Freude. Die Frage ist
> nur: Brauchts das wirklich?

Da sind wir wieder beim Akkuschrauber. Den "brauche" ich eigentlich 
nicht, im Sinne von: er ist nicht notwendig. Schrauben kann ich 
schließlich auch von Hand mit einem Schraubendreher eindrehen.

Andererseits "brauche" ich meine Akkuschrauber in dem Sinne, daß sie mir 
das Schrauben wesentlich einfacher und angenehmer machen.

> Bei einem Blick ins aktuelle VS2015 wird jedem Anfänger schwarz vor
> Augen. Der will vielleicht nur eine einfache Anwendung schreiben, steht
> aber vor einem ganzen Gebirge von OOP-Bürokratie und Anwender-APIs.

Visual Studio war immer schon ein überfrachtetes Monster, und .NjET ist 
ein ebensolches Framework. Das liegt aber nicht an der OO, sondern an 
MS' Tendenz, alles mit riesigen Monolithen totzuschlagen. Word, Excel 
und Co. haben allesamt nichts mit OO zu tun, sind aber genauso 
überfrachtet.

> Wenn mir jemand erzählen will wie einfach doch dies und jenes sei schau
> ich immer zuerst auf den Umfang der Doku  ;-)

Das ist eine ziemlich dumme Idee. Mir sind im Laufe meines Lebens viele 
Dinge begegnet, die schwer zu erklären, aber einfach zu verstehen sind, 
angefangen bei der Abseitsregel im Fußball über das Reizen beim Skat bis 
zur Datenbanknormalisierung, um nur ein paar Beispiele zu nennen. Zudem 
können manche Leute besser, andere hingegen weniger gut erklären; einige 
Dinge lassen sich leichter an einem konkreten Kontext erklären, der für 
das Verständnis der Erklärung erst einmal begriffen sein muß.

[Scelumbro (Gast)]

Moby A. schrieb im Beitrag #4634073:

> OOP hat seine Stärken. Dort wo es Sinn macht: Große Projekte mit großen
> Datenmengen.
Manchmal lieber Moby habe ich das Gefühl du weißt überhaupt nicht was 
OOP bedeutet. Es kommt nicht darauf an wie große die Datenmenge ist, 
sondern wie komplex die Probleme sind die mit den Daten zu lösen sind. 
Ein paar einfache Datenbankoperationen auf ein paar Millionen 
Datensätze? Schreibe ich nicht in C++ / Java usw. sondern in SQL bzw. 
der Skriptsprache (i.d.R eher Prozedural) des Datenbankanbieters. Beste 
und performanteste Lösung.


> Gerne. Das will ich Dir auch gar nicht ausreden.
> Handwerkszeug welches man beherrscht macht immer Freude. Die Frage ist
> nur: Brauchts das wirklich? Brauchts immer mehr davon?
> Bei einem Blick ins aktuelle VS2015 wird jedem Anfänger schwarz vor
> Augen. Der will vielleicht nur eine einfache Anwendung schreiben, steht
> aber vor einem ganzen Gebirge von OOP-Bürokratie und Anwender-APIs. Wenn
> mir jemand erzählen will wie einfach doch dies und jenes sei schau ich
> immer zuerst auf den Umfang der Doku  ;-)

Erstens haben weder moderne APIs noch IDEs unmittelbar etwas mit OOP zu 
tun. Ein Windows hat nuneinmal etwas komplexere Schnittstellen als ein 
AVR. Deswegen Programmiert auch niemand Windows mit ASM.
Zweites war jeder Softwareentwickler sicher mal ein Anfänger, aber 
glücklicherweise sind es nicht mehr alle. Und nur weil dich als Anfänger 
eine moderne IDE überfordet, so schließe bitte nicht von dir auf andere. 
Eine IDE ist nuneimal keine Taschenlampen-APP sondern ein professionlles 
Werkzeug. Oder lehnst du CAD Programme ab, weil nicht jeder Anfänger 
einen Motor konstruieren kann? Ich für meinen Teil habe auch ein 
Weilchen gebraucht, aber nun liebe ich die unzähligen Hilfsfunktionen 
meines Eclipse und könnte auch bei den großen Projekten die ich betreue 
kaum die Übersicht behalten.

[Stefan F. (Gast)]

Ist es nicht so, dass man beruflich in der Programmiersprache entwickeln 
muss, die einem vorgesetzt wird? (Bei mir ist und war das so, die ganzen 
20 Jahre in 6 Unternehmen. Und die sind teilweise mit und teilweise ohne 
OOP.)

Wenn dem so ist, dann kommt man mit einer flexiblen Einstellung 
wesentlich besser voran, als mit der Diskussion, wessen ... der längste 
ist, bzw wessen Lieblings-Programmiersprache die Beste ist.

[TriHexagon (Gast)]

Moby A. schrieb im Beitrag #4634054:
> Jan H. schrieb im Beitrag #4621860
>> ungefähr sieben Trilliarden Webseiten und fünf
>> Millionen Bücher zu dem Thema.
>
> und immer fettere OOP Installationen zu bedeuten haben.

? 1. Hat die Größe des Maschinencodes von einer klassischen Anwendung, 
keinen Einfluss auf die Installationsgröße, da er nicht mal 1% davon 
ausmacht.

2. Nein ganz und gar nicht bedeutet OOP mehr Maschinencode. Das liegt 
schon daran, dass es nicht die Umsetzung von OO zu Maschinencode gibt.

Moby A. schrieb im Beitrag #4634073:
>> bei OOP doch wesentlich einfacher zu lesen, sich zurechtzufinden, und
>> auch grössere Änderungen vorzunehmen.
>
> OOP hat seine Stärken. Dort wo es Sinn macht: Große Projekte mit großen
> Datenmengen.

Definiere Groß. >10k, >100k oder >1M LOC?

Mein 3k LOC Programm damals hat jedenfalls nicht an OOP gelitten, eher 
im Gegenteil. War ne kleine Physiksimulation für die Schule 
(Stoßgesetze). Könnte man dank OOP auch prima erweitern und ausbauen.

Moby A. schrieb im Beitrag #4634241:
> Sheeva P. schrieb:
>> Andererseits "brauche" ich meine Akkuschrauber in dem Sinne, daß sie mir
>> das Schrauben wesentlich einfacher und angenehmer machen.
>
> Wenn denn OOP nur annähernd so simpel wäre... Der Vergleich hinkt
> gewaltig.
>
>> Visual Studio war immer schon ein überfrachtetes Monster
>
> Es ist ein Spiegelbild der OOP-Möglichkeiten.
>
>>> Wenn mir jemand erzählen will wie einfach doch dies und jenes sei schau
>>> ich immer zuerst auf den Umfang der Doku  ;-)
>>
>> Das ist eine ziemlich dumme Idee.
>
> Ganz und gar nicht. Je mehr Doku notwendig desto mehr Umfang hat die
> Sache. Die einfachsten Dinge haben sogar gar keine Doku nötig, weil
> sie selbsterklärend sind. Das ist der anzustrebende, mehr oder weniger
> illusorische Idealzustand. Nichtsdestotrotz ist aber das die
> Zielrichtung. OOP mit seinen realen Spielarten läuft in die entgegen
> gesetzte.

Ja Moment mal. Einerseits gibst du zu, OOP eignet sich für große 
Projekte. Andererseits sagst du aber, OOP erhöht die Komplexität und 
erschwert den Durchblick. Wie kommst du dann darauf, dass sich OOP für 
große Projekte eignet? Wenn das zu lösende Problem schon komplex genug 
ist, und das sind große Programme ja immer, warum sollte man dann ein 
Paradigma wählen, dass dem ganzen noch ne Schippe an Komplexität 
drauflegt? Warum willst du keine PP verwenden, wenn du doch der Meinung 
bist, dass diese in Sachen Komplexität der OOP überlegen ist. Ja OOP 
soll ja gar die Dokumentation erschweren.

Fazit: Deine Meinung zu OOP ist undifferenziert und emotional. Was eine 
Folge von viel Halbwissen, deiner verzerrten Vorstellung von Einfachheit 
und schlechter Erfahrung von überladender Anwendungssoftware ist.

Das grundlegene Problem ist aber, dass du das weder einsehen wirst, egal 
wie die Fakten sind, denn du hast in dieser Sache recht und alle in 
diesem Forum, die dir widersprechen im Unrecht. Das sind fehlgeleitete 
Anhänger der ketzerischen Religion namens Komplexität. Das trifft in der 
Diskussion um OOP als auch in der Diskussion um ASM/C zu. Ach ja AVR vs. 
ARM hab ich noch vergessen.

Dabei kennst du nur AVRs und ASM...

[Stefan S. (Gast)]

TriHexagon schrieb:
> Fazit: Deine Meinung zu OOP ist undifferenziert

Meine auch :-)

Wobei es ja meist weniger um OOP geht, als um Vererbung. Go erlaubt ja 
wohl tatsächlich überhaupt keine Vererbung. Ich hatte darüber schon mal 
etwas gelesen, aber wohl nicht ganz verstanden. Heute abend werde ich 
dies mal lesen:

http://stackoverflow.com/questions/1727250/embedding-instead-of-inheritance-in-go

[MaWin (Gast)]

Sheeva P. schrieb:
> Visual Studio war immer schon ein überfrachtetes Monster

Eclipse bestimmt nicht. Herr wirf Hirn.

Sheeva P. schrieb:
> Naja, verglichen mit einem System zum autonomen Fahren, wie es gerade
> bei einem Tesla versagt hat (wobei auch der Fahrer des Tesla den LKW ja
> wohl übersehen hat), sind ein ABS und ein ESP doch eher trivial.

Aber ebenfalls fehlerhaft. Ich kenne bei beiden unfallgefährliche 
Ausfälle (d.h. bei ABS nicht-mehr-bremsen-können wo es ohne ABS gut 
verzögernd ginge und bei ESP Vollbremsung ohne Grund - sicher 
Sensorfehler der Softwaremässig nicht erkannt wurde weil 
Plausibilitätsprüfung fehlt)), und es gab sicher auch schon Tote nur 
hinterher weiss man das nicht mehr, der Fahrer kann es ja nicht mehr 
sagen, und arrogante KFZ Hersteller würden es stets abstreiten. 
Tempomaten als Fahrerassistenzsystem (siehe Tesla) sind sicher auch für 
viele Tote bei Lastwagen-Auf-Stauende Auffahrunfälle zuständig, auch da 
weiss man es hinterher nur nicht mehr, aber ich merk ja selbst wie ich 
beim Tempomat am liebsten ein Buch lesen würde (und dann den Tempomaten 
wieder ausschalte).

Sheeva P. schrieb:
> die Diskussion schon lange entschieden, und zwar eindeutig für die OOP.

Auch wenn du nicht mehr drüber nachdenken magst, gibt es Viele, die die 
Realität beobachten, und OOP für viele Probleem aktueller Software 
verantwortlich machen, und deren Analysen sind nicht so einfach wie du 
es gerne willst von der Hand zu wischen. Aber was du nicht willst gibt 
es ja nicht, so macht man sich das Leben schön.

> Vielleicht kenne ich andere Uniabsolventen als Du.

Bestimmt. Deine Traumwelt halt.

> Ach Du liebe Güte... die MFC war niemals ein OO-Design, sondern
> lediglich ein Wrapper um die c- und assemblerbasierte WinAPI.

Ah, im Notfall immer rausreden, sehr pragmatisch.

[TriHexagon (Gast)]

Stefan S. schrieb:
> TriHexagon schrieb:
>> Fazit: Deine Meinung zu OOP ist undifferenziert
>
> Meine auch :-)
>
> Wobei es ja meist weniger um OOP geht, als um Vererbung. Go erlaubt ja
> wohl tatsächlich überhaupt keine Vererbung. Ich hatte darüber schon mal
> etwas gelesen, aber wohl nicht ganz verstanden. Heute abend werde ich
> dies mal lesen:
>
> 
http://stackoverflow.com/questions/1727250/embedding-instead-of-inheritance-in-go

Sehr gute Idee! Es ist immer gut seinen Horizont zu erweitern und sich 
mit neuartigen Sprachen/Konzepten zu beschäftigen. Das würde unseren 
Moby mal richtig gut tun ;), wobei ich ihm eher zu konservativen 
Sprachen raten würde. Ich hätte schon mal Lust mal ein kleineres 
Programm in Rust umzusetzen, leider fehlt mir dazu gerade die Zeit.

[HVV (Gast)]

Scelumbro schrieb:
> Ein Windows hat nuneinmal etwas komplexere Schnittstellen als ein
> AVR. Deswegen Programmiert auch niemand Windows mit ASM.

Ach Nein? Google mal MASM32...

[August E. (Gast)]

HVV schrieb:
> Scelumbro schrieb:
>> Ein Windows hat nuneinmal etwas komplexere Schnittstellen als ein
>> AVR. Deswegen Programmiert auch niemand Windows mit ASM.
>
> Ach Nein? Google mal MASM32...

Ach ja? Ist Windows tatsächlich mit Assembler programmiert?
Man lernt eben nie aus ;-)

[W.S. (Gast)]

Stefan U. schrieb:
> Ist es nicht so, dass man beruflich in der Programmiersprache entwickeln
> muss, die einem vorgesetzt wird?

Nö. So geht es womöglich den Leuten, die als Codeschreiber eingesetzt 
werden.
Bei mir sieht das anders aus: Ich benutze das, was ich zuvor eingekauft 
habe.

Allerdings sehe ich das Ganze durchaus kritisch: Die Auswahl ist 
heutzutage geradezu mickrig geworden, wenn man das µC-Gebiet im Auge 
hat. Da ist außer C eigentlich nix mehr zu finden (und Hersteller wie 
Mikroe sind bisher zu kurz gesprungen), weswegen sich die Auswahl auf 
verschiedene C-Compiler-Hersteller eingrenzt.

Ist halt ne Monokultur geworden - und sowas ist erwiesenermaßen von 
Grund auf schlecht, jedenfalls auf lange Sicht. Übrigens gilt dies auch 
für die derzeitige µC-Hardware, die inzwischen vom Cortex dominiert ist. 
Nee, das ist kein schlechter Prozessor in all seinen Ausbaustufen, im 
Gegenteil, er ist besser als alles zuvor, aber dennoch ist es ne 
Monokultur und das ist auf lange Sicht bedenklich.

W.S.

[Carl D. (jcw2)]

> Ist halt ne Monokultur geworden - und sowas ist erwiesenermaßen von
> Grund auf schlecht

Ja war das noch schön, als ein Zeichen 6..9 Bits hatte und man mal im 
Einer-, mal im Zweier-Komplement rechnete. Und schön auch die gefühlt 
100 verschiedenen FP-Formate nur bei einem Hersteller (DEC).
Schön auch, wenn man für jede Kiste eine eigene Hochsprache hat.
Ein Hoch auf die Vielfallt!

Oder nennt man das schlicht Chaos?

[Durchstarter (Gast)]

Leute ihr frustriert mich^^ - ich habe schon mal versucht Trolltjreads 
zu starten (um den Hatern was zu schreiben zu geben), die ich bewusst 
mit Reizthemen versah. Dazu noch meinen Unwillen zu lernen angedeutet 
und ein paar Rechtschreibfehler eingebaut. Hat nichts genutzt. Das hier 
funktioniert viel besser.

Im ernst - ich würde mich auf den Standpunkt stellen, dass man OO 
einfach sinnvoll (nicht auf Teufel komm raus jedes Pattern) und seinen 
Fähigkeiten entsprechend einsetzten muss. Das ist mit C und ASM ja auch 
nicht anders.
Selbst in meinem kleinen Ein-Mann-Projekt habe ich OO eingesetzt und ich 
denke auf eine Weise wo es Sinn macht. Inetrfaces und Vererbung scheinen 
mir ein mächtiges Schwert zu sein. Ich habe eine Testumgebung gemacht. 
Wenn ich einen weiteren Test brauche, leite ich die Basisklasse ab, 
implmentiere die 3 Methoden aus dem Interface, die individuell sein 
sollen und bin nach 10 bis 30 Minuten fertig.

[Andreas H. (ahz)]

W.S. schrieb:
> Nö. So geht es womöglich den Leuten, die als Codeschreiber eingesetzt
> werden.

Nö. So geht es allen Leuten die in Firmen arbeiten, wo sie selber nicht 
an der Entscheidungsfindung zu diesem Thema beteiligt sind.

Also z.B. bei allen Firmen, deren Produkte länger leben als man selber 
in der Firma ist oder die SW für >10 Jahre supported werden muss (Die 
NASA sucht wohl immer noch einen Hacker für die Voyager - der Letzte der 
alten Truppe geht in Rente - 
http://www.popularmechanics.com/space/a17991/voyager-1-voyager-2-retiring-engineer/).

Ähnliches bei Firmen wo Haftungsfragen etwas "böser" hochkommen. Warum 
"kleben" wohl die Banken/Versicherungen soooo an Cobol?

> Die Auswahl ist
> heutzutage geradezu mickrig geworden, wenn man das µC-Gebiet im Auge
> hat. Da ist außer C eigentlich nix mehr zu finden

Aha. Obwohl: 
https://docs.adacore.com/gnat_ugx-docs/html/gnat_ugx/gnat_ugx/arm-elf_topics_and_tutorial.html
(Und wenn man sich die Realtime & LowLevel Features von Ada anschaut 
dann wundert man sich erst mal, warum überhaupt noch jemand uC's in 
C(++) programmiert ... Bis man mal auf die Preise schaut^^)

> Übrigens gilt dies auch
> für die derzeitige µC-Hardware, die inzwischen vom Cortex dominiert ist.
Auch nicht überall. Broadcom 
(http://www.broadcom.com/products/search?q=mips) und Dialog Semi 
(http://www.dialog-semiconductor.com/media-centre/press-releases/press-releases-details/2012/03/26/dialog-semiconductor-extends-green-voip-ic-family-to-address-high-end-phones)
benutzen z.B. MIPS.

Also nicht frustriert sein. Ist doch eigentlich wie immer ;-)

/regards

[Carl D. (jcw2)]

Moby A. schrieb im Beitrag #4634978:
> Ja, ein gewisser Hang die Dinge imposant aufzublasen wohnt dem Menschen
> schon inne ;-)

Ach!

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4634241:
> Sheeva P. schrieb:
>> Andererseits "brauche" ich meine Akkuschrauber in dem Sinne, daß sie mir
>> das Schrauben wesentlich einfacher und angenehmer machen.
>
> Wenn denn OOP nur annähernd so simpel wäre...

Ist sie. Die Prinzipien der OO -- Datenkapselung, Polymorphie, Vererbung 
-- kann man in weniger als einer halben Stunde erklären.

>> Visual Studio war immer schon ein überfrachtetes Monster
>
> Es ist ein Spiegelbild der OOP-Möglichkeiten.

Nein. Es ist ein Spiegelbild von Microsofts Tendenz, allen möglichen und 
unmöglichen Mist in eine einzelne monolithische Anwendung zu stopfen. 
Wie gesagt, dieselbe fatale Tendenz siehst Du bei der Office-Software, 
wo von 80/20-Programmen geredet wird: 80 Prozent der Nutzer nutzen 
höchstens 20 Prozent der Funktionen. All das hat mit OO nichts zu tun.

>>> Wenn mir jemand erzählen will wie einfach doch dies und jenes sei schau
>>> ich immer zuerst auf den Umfang der Doku  ;-)
>>
>> Das ist eine ziemlich dumme Idee.
>
> Ganz und gar nicht. Je mehr Doku notwendig desto mehr Umfang hat die
> Sache. Die einfachsten Dinge haben sogar gar keine Doku nötig, weil
> sie selbsterklärend sind.

Die Prinzipien der OO -- Datenkapselung, Polymorphie, Vererbung -- kann 
man leicht auf weniger als einer DIN-A4-Seite erklären.

Das einzige Problem ist wieder einmal, daß Du nicht den leisesten Hauch 
einer Ahnung davon hast, wovon hier die Rede ist. Das sieht man 
besonders gut an dummen Aussagen wie der, daß die Überfrachtung von VS 
an der OO läge. Tatsächlich ist die OO aber ein Programmierparadigma 
und kann auch mit einfachen Texteditoren benutzt werden. Daran ändert 
sich nichts, weil jemand den Texteditor mit Build- und Debuggingtools, 
Versionsverwaltung, Dokumentations- und Hilfswerkzeugen und anderem Zeug 
überfrachtet.

[Sheeva P. (sheevaplug)]

MaWin schrieb:
> Sheeva P. schrieb:
>> Visual Studio war immer schon ein überfrachtetes Monster
>
> Eclipse bestimmt nicht.

Eclipse ist ebenfalls ein überfrachtetes Monster, genauso wie KDevelop, 
IntelliJ, Codeblocks, Qt Creator, und jede anderen IDE, die ich bisher 
gesehen habe. Zu dumm für Dich, daß das alles nichts mit OO zu tun hat. 
Schließlich kann man OO nicht nur mit überfrachteten IDEs, sondern mit 
jedem einfachen Texteditor benutzen.

> Herr wirf Hirn.

Zum Glück erkennst Du selbst, was Dir fehlt.

> Sheeva P. schrieb:
>> die Diskussion schon lange entschieden, und zwar eindeutig für die OOP.
>
> Auch wenn du nicht mehr drüber nachdenken magst, gibt es Viele, die die
> Realität beobachten, und OOP für viele Probleem aktueller Software
> verantwortlich machen, und deren Analysen sind nicht so einfach wie du
> es gerne willst von der Hand zu wischen.

Selbst wenn es so viele gäbe, wäre das nur ein argumentum ad populum. 
Aber in Wirklichkeit gibt es ja gar nicht so viele.

> Aber was du nicht willst gibt es ja nicht, so macht man sich das Leben
> schön. [...]
> Bestimmt. Deine Traumwelt halt.

Ach, Du Armer, hast Du es mal wieder nötig? Schade eigentlich: Du kannst 
kaum deutlicher sagen, daß Du kein sachliches Argument hast.

>> Ach Du liebe Güte... die MFC war niemals ein OO-Design, sondern
>> lediglich ein Wrapper um die c- und assemblerbasierte WinAPI.
>
> Ah, im Notfall immer rausreden, sehr pragmatisch.

Erfreulicherweise habe ich gar keinen Notfall. Es ist nämlich nicht 
meine Schuld, daß die Realität so ist, wie ich sie beschrieben habe, und 
es ist auch nicht meine Schuld, daß das Design der MFC ebenso verhunzt 
ist wie die meisten anderen MS-Produkte auch. Aber auch das hat nichts 
mit OO zu tun, sondern damit, wie MS seine Bananaware zusammenzimmert.

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4634978:
> Scelumbro schrieb:
>> Eine IDE ist nuneimal keine Taschenlampen-APP sondern ein professionlles
>> Werkzeug.
>
> Schließen sich Professionalität und einfache Anwendung etwa aus?

Natürlich, sonst bräuchte man ja keine Berufsausbildung dafür.

> TriHexagon schrieb:
>> Nein ganz und gar nicht bedeutet OOP mehr Maschinencode.
>
> In der Theorie.

Nein, in der Praxis.

> OOP ist einfach zu komplex anzuwenden.

Das kannst Du doch gar nicht beurteilen. Du hast die OO noch nie 
angewendet und kennst sie nicht einmal; Dir sind ja sogar prozedurale 
Sprachen viel zu "bürokratisch", zu "kompliziert", bzw.: zu hoch.

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4635007:
> Sheeva P. schrieb:
>> Wenn denn OOP nur annähernd so simpel wäre...

Zitieren lernen: das war nicht von mir, sondern von Dir.

>> Ist sie. Die Prinzipien der OO -- Datenkapselung, Polymorphie, Vererbung
>> -- kann man in weniger als einer halben Stunde erklären.
>
> Klasse. Du bist ja echt lustig. Wozu es dann noch der
>
> Jan H. schrieb im Beitrag #4621860
>> ungefähr sieben Trilliarden Webseiten und fünf
>> Millionen Bücher zu dem Thema
>
> bedarf?

Wie bereits oben gesagt: derer bedarf es gar nicht, und die meisten 
davon beschäftigen sich ja auch kaum mit der OO, sondern mit anderen 
Themen wie konkreten Umsetzungen von OO in verschiedenen Sprachen, 
Diagrammtypen und Werkzeugen zur Modellierung, und so weiter.

> VS bietet alle Möglichkeiten der OOP und ist als solches das Spiegelbild
> ihrer Komplexität.

Jeder popelige Texteditor bietet alle Möglichkeiten der OO und ist als 
solcher das Spiegelbild ihrer Einfachheit.

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4635011:
> Sheeva P. schrieb:
>> Natürlich, sonst bräuchte man ja keine Berufsausbildung dafür.
>
> Stimmt. Für diese Form aufgeblasener Programmierung braucht's ne
> Ausbildung.

Wenn Du Aussagen schon aus dem Zusammenhang reißt, solltest Du das nicht 
ganz so offensichtlich machen. :-) Und, Pardon, für Deine permanente 
Überforderung bin ich nicht verantwortlich.

>> Das kannst Du doch gar nicht beurteilen. Du hast die OO noch nie
>> angewendet und kennst sie nicht einmal
>
> Du kannst von Glück reden, daß ich meine Aussagen zum Können anderer
> nicht so an den Haaren herbeiziehe. Mir ist da noch ein tolles
> C-Programm als Beispiel Deiner Fähigkeiten in Erinnerung... naja, wollen
> wir die Geschichte hier nicht nochmal aufwärmen  ;-)

LOL! Du meinst meine kleine Falle, in die Du so "erfolgreich" 
hineingetappt bist? Nee, wat hebbt wij lacht.

[Scelumbro (Gast)]

Moby A. schrieb im Beitrag #4635014:
> Im übrigen mußt Du Dich in punkto OOP schon entscheiden: Brauchts nun ne
> Ausbildung oder passt das Thema auf ein A4 Blatt ?

Moby nochmal für dich: IDEs haben nichts mit OOP zu tun. Die Grundlagen 
von OOP passen auf ein DIN A4 Blatt. Die von Eclipse nicht. Oder müssen 
für dich eine CNC Fräse oder auch nur eine Drehbank auch so gebaut sein, 
dass jeder Anfänger damit sofort Motorteile herstellen kann?
Man kann übrigens sehr komfortabel in Eclipse ASM für deine AVRs 
programmieren. Selbst die eher kleinen Programme von ein paar Dutzend 
Zeilen die du so machst. Sich in Eclipse ordentlich einzuarbeiten dauert 
übrigens weniger lang als eine Ausbildung zu den oben genannten 
Werkzeugen. Also keine Angst, auch du kannst das schaffen. Vielleicht 
verlierst du dann langsam deine Angst vor den Fortschritten der 
Softwareentwicklung der letzten 20 Jahre.

[Bernd K. (prof7bit)]

Moby,

hier ist eine Frage an Dich:

- Du hast 2 identische UARTs in deinem µC, beide sollen verwendet werden
- RX und TX sollen vollkommen selbstständig im Interrupt laufen
- Jeder UART braucht deshalb zwei FIFO-Queues
- Du brauchst also Code für 2 UART und insgesamt 4 FIFOs
- Du willst kein Flash verschwenden und keine Zeile Code duplizieren

[Zeit vergeht]

- Es stellt sich raus Du brauchst noch ein dritten UART:
  - leider gibts keinen mehr, also Software-UART
  - er soll das selbe Interface wie die anderen beiden
    UARTs haben und sich genauso verhalten.
  - Du willst kein Flash verschwenden und keine Zeile Code duplizieren

Jetzt lass mal hören wie Du Dir das vorstellst.

[(prx) A. K. (prx)]

Sheeva P. schrieb:
>> Wenn denn OOP nur annähernd so simpel wäre...
>
> Ist sie. Die Prinzipien der OO -- Datenkapselung, Polymorphie, Vererbung
> -- kann man in weniger als einer halben Stunde erklären.

Kannst du das bitte auch Moby in einer halben Stunde auf 1x A4 erklären? 
Das würde solche "Kurt"-Threads wie dieser hier erübrigen.  ;-)

[Durchstarter (Gast)]

>Schließen sich Professionalität und einfache Anwendung etwa aus?
Eine Motorsäge und ein Harvester machen am Ende das gleiche. Trotzdem 
liegen in ihrer Bedienung Welten dazwischen.

>In der Theorie. Praktisch führt die ineffiziente Anwendung durch den
>selten perfekt erfahrenen Programmierer aber zur Vergeudung von
>Ressourcen. OOP ist einfach zu komplex anzuwenden.
Oft genug ist die wichtigste Rescource die Arbeitszeit. Und wenn ich die 
auf Kosten von ein paar kB sparen kann (Desktop PC), wenn die Anwendung 
nicht unbedingt das letzte bisschen Laufzeit erfordert, wird sich mein 
Chief für die kB nicht interessieren.
Außerdem ist auch ein prozedural Prorammierender selten "perfekt 
erfahren" und baut genau so Mist. Das ist aber nicht die Schuld des 
Konzeptes.

[(prx) A. K. (prx)]

Moby A. schrieb im Beitrag #4634978:
> Der Codebedarf eines simplen funktionslosen Windows-Fensterchens zeigt
> schon, wie ineffizient bereits das OS aufgebaut ist.

Yep. Wieso haben wir in der Mikro-Computerei eigentlich jemals das 
Stadium der Fernschreiber als Ein- und Ausgabemedium verlassen? Schon 
der C64 war doch viel komplexer als nötig.

> Auch wenn ich meine Ergebnisse in erster Linie damit erziele langt es
> schon noch für den Blick über den Tellerrand- leider mit den
> beschriebenen Erfahrungen.

Frühe Kartographen pflegten solche Gebiete mit "there be dragons" zu 
kennzeichnen.

[Scelumbro (Gast)]

Durchstarter schrieb:
> Oft genug ist die wichtigste Rescource die Arbeitszeit. Und wenn ich die
> auf Kosten von ein paar kB sparen kann (Desktop PC), wenn die Anwendung
> nicht unbedingt das letzte bisschen Laufzeit erfordert, wird sich mein
> Chief für die kB nicht interessieren.
> Außerdem ist auch ein prozedural Prorammierender selten "perfekt
> erfahren" und baut genau so Mist. Das ist aber nicht die Schuld des
> Konzeptes.

Jep, die ganze Speicherplatzeffizienzdiskussion ist bei Programmcode für 
alles außer die kleinsten Mikrocontroller sowieso müßig. Was kostet ein 
halbwegs talentierter Programmierer pro Stunde für ein Unternehmen? Und 
wieviel 1GB Festplattenplatz beim Kunden? Und selbst mit den 
gammeligsten Skriptsprachen und schlechtesten Frameworks braucht man ein 
langes Weilchen um dieses GB mit Code vollzubekommen.

[TriHexagon (Gast)]

Moby A. schrieb im Beitrag #4635007:
> VS bietet alle Möglichkeiten der OOP und ist als solches das Spiegelbild
> ihrer Komplexität. Das hat erstmal mit Überfrachtung rein gar nix zu
> tun.

LOL "alle Möglichkeiten der OOP" magst du das bitte näher ausführen, ich 
kenne ein paar IDEs und OOP kenne ich auch, trotzdem kann ich mir nicht 
vorstellen was das bedeuten soll? Liegt es an deinem Halbwissen?

Moby A. schrieb im Beitrag #4635011:
> Sheeva P. schrieb:
>> Natürlich, sonst bräuchte man ja keine Berufsausbildung dafür.
>
> Stimmt. Für diese Form aufgeblasener Programmierung braucht's ne
> Ausbildung.

Oh wow ich wusste ja gar nicht, dass ich und so viele Leute hochbegabt 
sind. Eine ganze Ausbildung in so kurzer Zeit allein zu bewältigen, dass 
ist sehr bemerkenswert. Vielleicht aber überschätzt du das Ganze 
gänzlich. Aber es gibt ja so einiges, was du hier behauptest...

Moby A. schrieb im Beitrag #4634978:
> TriHexagon schrieb:
>> Nein ganz und gar nicht bedeutet OOP mehr Maschinencode.
>
> In der Theorie. Praktisch führt die ineffiziente Anwendung durch den
> selten perfekt erfahrenen Programmierer aber zur Vergeudung von
> Ressourcen. OOP ist einfach zu komplex anzuwenden.

Blablabla. Nur haltlose Behauptungen, gib mal ein Beispiel mit 
Quellcode. Dass eine schlechte Architektur ineffiziente Programme 
hervorrufen gilt genauso für PP.

Moby A. schrieb im Beitrag #4634978:
> Der Codebedarf eines simplen funktionslosen Windows-Fensterchens zeigt
> schon, wie ineffizient bereits das OS aufgebaut ist. Im Prinzip langt
> doch dafür die Übergabe einiger Paramater mit sagen wir mal einer
> prozeduralen WINDOWS(Parameter) Instruktion. Was macht die liebe OOP
> Programmierung draus? Kilobyteweise Code...

Du meinst die WinAPI? Tja bloßt blöd, dass es sich hierbei um PP handelt 
und nicht, wie du fälschlicherweise glaubst, um OOP. "Kilobyteweise 
Code" gibts auch nicht.

Weißt du wie man ein Fenster in OOP anzeigen lassen kann, wenn man es 
einfach umsetzt? Das kann so gehen mit einer Zeile, wo ist die 
Komplexität?

Window win;

//Oder mit ein paar Parametern
Window win("Titel", 800, 600);

Moby A. schrieb im Beitrag #4634978:
>> Könnte man dank OOP auch prima erweitern und ausbauen.
>
> Sicher. Prima erweitern und ausbauen kann ich aber auch schon meine
> Asm-Programme. Alles eine Frage gelungener Systematik bei der
> Programm-Implementierung.

Das wirst du kaum schaffen ohne eine einzige Zeile im bestehenden Code 
zu ändern. Das ist ja der Clou an der Sache. Ich habe eine Erweiterung 
nicht vorgesehen und trotzdem muss ich nicht eine einzige Zeile ändern 
oder in den alten Code hinzufügen, dank OOP. Ich mache eine neue Datei 
und schreibe eine neue Klasse die von PhysicObject erbt. Sowas wird mit 
PP ziemlich schwer ohne Funktionszeigern und die baut man nur ein, wenn 
man sie braucht. Davor wurden sie nicht gebraucht. Und zack schon hat 
man das Problem.

Moby A. schrieb im Beitrag #4634978:
>> Dabei kennst du nur AVRs und Asm
>
> Woher willst Du das wissen?
> Auch wenn ich meine Ergebnisse in erster Linie damit erziele langt es
> schon noch für den Blick über den Tellerrand- leider mit den
> beschriebenen Erfahrungen.

So weit kann der Blick nicht gewesen sein, dass du hier so viel 
Halbwissen rum posaunst.

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4635014:
> Sheeva P. schrieb:
>> LOL! Du meinst meine kleine Falle, in die Du so "erfolgreich"
>> hineingetappt bist? Nee, wat hebbt wij lacht.
>
> Klar doch. Jetzt war's ne Falle.

War es damals schon, das weißt Du doch.

> War ja auch ne peinliche Geschichte mit Deinem C-Versuch.

Ja, aber nicht für mich. :-)

Moby A. schrieb im Beitrag #4635014:
> Im übrigen mußt Du Dich in punkto OOP schon entscheiden: Brauchts nun ne
> Ausbildung oder passt das Thema auf ein A4 Blatt ?

Die OO braucht keine Ausbildung, alles Nötige paßt auf ein Din-A4-Blatt. 
Bei der Professionalität ging es um IDEs, ich habe das für Dein 
schwaches Gedächtnis noch einmal rekonstruiert:

Scelumbro schrieb:
>>>  Eine IDE ist nuneimal keine Taschenlampen-APP sondern ein
>>> professionlles Werkzeug.

Moby A. schrieb im Beitrag #4634978:
>> Schließen sich Professionalität und einfache Anwendung etwa aus?

Sheeva P. schrieb:
> Natürlich, sonst bräuchte man ja keine Berufsausbildung dafür.

Wie gesagt: nicht ganz so plump aus dem Zusammenhang reißen, hm? Sonst 
wird es wieder peinlich für Dich.

[MaWin (Gast)]

Scelumbro schrieb:
> Jep, die ganze Speicherplatzeffizienzdiskussion ist bei Programmcode für
> alles außer die kleinsten Mikrocontroller sowieso müßig. Was kostet ein
> halbwegs talentierter Programmierer pro Stunde für ein Unternehmen? Und
> wieviel 1GB Festplattenplatz beim Kunden?

Du hast es nicht und wirst es nicht kapieren, wieso du dich mit dieser 
Einstellung zum schlechtesten Programmierer der Welt machst auf den alle 
Anwender einen Hass haben.

Wenn eines "common sense" unter den Anwendern ist, dann dass aktuelle 
Programme zu gross und zu langsam sind, auf Grund der Arroganz von 
Programmieren wie dir, die in ihrer optimalen Umgebung (dicke schnelle 
Maschine mit guter Anbindung ohne weiteren Ballast) meinen: "Es reicht, 
so wie es ist", und sich faul zurücklehnen.

[Sheeva P. (sheevaplug)]

A. K. schrieb:
> Sheeva P. schrieb:
>>> Wenn denn OOP nur annähernd so simpel wäre...
>>
>> Ist sie. Die Prinzipien der OO -- Datenkapselung, Polymorphie, Vererbung
>> -- kann man in weniger als einer halben Stunde erklären.
>
> Kannst du das bitte auch Moby in einer halben Stunde auf 1x A4 erklären?

Einem Troll kann man nichts erklären, weil er das gar nicht will.

> Das würde solche "Kurt"-Threads wie dieser hier erübrigen.  ;-)

Das halte ich für ein Gerücht. ;-)

[Sheeva P. (sheevaplug)]

TriHexagon schrieb:
> Weißt du wie man ein Fenster in OOP anzeigen lassen kann, wenn man es
> einfach umsetzt? Das kann so gehen mit einer Zeile, wo ist die
> Komplexität?
>

> Window win;
> 
> //Oder mit ein paar Parametern
> Window win("Titel", 800, 600);
>

Bist Du denn von allen guten Geistern verlassen? Jetzt gleich wird er 
behaupten, Parameter seien der ultimative Beweis für die "ausgeuferte 
Bürokratie der OOP". ;-)

[Daniel A. (daniel-a)]

MaWin schrieb:
> Wenn eines "common sense" unter den Anwendern ist, dann dass aktuelle
> Programme zu gross und zu langsam sind, auf Grund der Arroganz von
> Programmieren wie dir, die in ihrer optimalen Umgebung (dicke schnelle
> Maschine mit guter Anbindung ohne weiteren Ballast) meinen: "Es reicht,
> so wie es ist", und sich faul zurücklehnen.

Die grösse des Programms hat nichts mit dessen Laufzeit, und nichts mit 
OOP zu tun.

Ausserdem denken viele, grosse ausführbare Dateien bedeuten viel code, 
was auch nicht zutrifft. Bei grossen Programmen sind meist Ressourcen 
wie Bilder enthalten, oder es wurden viele statische Libraries mithinein 
kompiliert und die Option nicht verwendete Methoden zu entfernen nicht 
gesetzt, oder irgendwo ist ein grosses Array. Die kunden würden es 
einfach merkwürdig finden, wenn die Anwendung so kompiliert würde, das 
sie nur wenige KB gross wäre.

Die laufzeit ist von der Komplexität, die ein gutes OOP Programm 
sowisonicht hat, auch nicht wirlich abhängig. Diese ist meistens das 
Resultat blokierender Aktionen, die nicht in andere Threads ausgelagert 
wurden, langsamer Netzwerkverbindungen, grosser Datenmengen und nicht 
idealen Verarbeitungsalgorithman, oder langsamen Winapi operationen, 
etc. All das hat nichts mit OOP zu tun.

[(prx) A. K. (prx)]

MaWin schrieb:
 Du hast es nicht und wirst es nicht kapieren, wieso du dich mit dieser
> Einstellung zum schlechtesten Programmierer der Welt machst auf den alle
> Anwender einen Hass haben.

So einfach ist das nicht, erst recht nicht so pauschal. Du scheinst das 
nur aus der Sicht von Standardanwendungen zu sehen.

Bei Programmen für die Masse ist es sehr nervend, wenn beispielsweise 
ein Support-Programm fürs Smartphone einen 1Gb Installer mitsamt SQL 
Express mitbringt, nur weil das für den Anbieter so einfacher ist. Das 
macht verhasst.

Wenn man allerdings eine kundenspezifische Lösung benötigst, dann kann 
es schon sinnvoll sein, eine zeitlich aufwändige aber schlanke Lösung zu 
verbilligen,  indem man  zugunsten kürzerer Entwicklung eine fettere 
Variante mit vergleichweise billiger Hardware bewirft .

[Sheeva P. (sheevaplug)]

MaWin schrieb:
> Scelumbro schrieb:
>> Jep, die ganze Speicherplatzeffizienzdiskussion ist bei Programmcode für
>> alles außer die kleinsten Mikrocontroller sowieso müßig. Was kostet ein
>> halbwegs talentierter Programmierer pro Stunde für ein Unternehmen? Und
>> wieviel 1GB Festplattenplatz beim Kunden?
>
> Du hast es nicht und wirst es nicht kapieren, wieso du dich mit dieser
> Einstellung zum schlechtesten Programmierer der Welt machst auf den alle
> Anwender einen Hass haben.
>
> Wenn eines "common sense" unter den Anwendern ist, dann dass aktuelle
> Programme zu gross und zu langsam sind, auf Grund der Arroganz von
> Programmieren wie dir, die in ihrer optimalen Umgebung (dicke schnelle
> Maschine mit guter Anbindung ohne weiteren Ballast) meinen: "Es reicht,
> so wie es ist", und sich faul zurücklehnen.

Warum kaufen (oder klauen) die Anwender dann genau diese Programme? 
Warum muß jeder Hansel, der die Helligkeit seiner Urlaubsfotos 
korrigieren will, dazu unbedingt Photoshop haben? Warum nutzen Anwender 
Monster wie Wörd, um ein paar Gesprächsnotizen anzufertigen?

Einer Anwenderin, die sich darüber beschwert hat, daß das alles so 
langsam sei, habe ich empfohlen, Gesprächsnotizen einfach mit Notepad zu 
machen. Da hat die Dame mir tatsächlich erklärt, nur für ein paar 
Gesprächsnotizen werde sie doch jetzt nicht noch ein neues Programm 
lernen. Was soll man da noch sagen?

Genau dasselbe begegnet mir hier im Forum, wenn ich darauf hinweise, daß 
es zur Softwareentwicklung nicht unbedingt einer IDE bedarf. Da werden 
die IDE-Freunde aber unleidlich und erklären mir, wie antiquiert mein 
Ansatz sei. Und genau dieselben trifft man dann wieder, wenn irgendwas 
mit ihrer IDE nicht richtig funktioniert oder wenn sie darüber weinen, 
daß ihre IDE so ein aufgeblähtes, langsames GUI-Monster sei.

Sorry, aber solche Probleme liegen nicht an der Software, sondern an den 
Anwendern selbst und ihren manchmal einfach bescheuerten Forderungen und 
Erwartungen. Entwickler und Programmierer liefern das, was die Anwender 
kaufen, und solange sich eine Software mit dem Werbebanner "jetzt noch 
mehr Funktionen, die kein Mensch je brauchen wird" besser verkaufen 
läßt, müssen Entwickler und Programmierer solche Funktionen einbauen.

[MaWin (Gast)]

Sheeva P. schrieb:
> Genau dasselbe begegnet mir hier im Forum, wenn ich darauf hinweise, daß
> es zur Softwareentwicklung nicht unbedingt einer IDE bedarf. Da werden
> die IDE-Freunde aber unleidlich und erklären mir, wie antiquiert mein
> Ansatz sei. Und genau dieselben trifft man dann wieder, wenn irgendwas
> mit ihrer IDE nicht richtig funktioniert oder wenn sie darüber weinen,
> daß ihre IDE so ein aufgeblähtes, langsames GUI-Monster sei.
>
> Sorry, aber solche Probleme liegen nicht an der Software, sondern an den
> Anwendern selbst

Danke für die erklärend erheitenden Worte.

Du nutzt also lieber selbst keine IDE weil zu gross und bulky, sicher in 
OOP geschrieben,
sondern antiquirte (Kommandozeilen) Software, sicher prozedural nach 
guter alter Art geschrieben, weil die einfach handlicher ist und dem Job 
angemessen und empfiehlst das auch anderen z.B. mit Notepad (Quellcode 
habe ich hier) statt Word (OOP).

Selten so entlarvendees gelesne, und das nach dutzenden Lügenmärchen die 
du hier über OOP aufgetischt hast.

Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit 
Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie 
schon bei "Speichern" unverständlichen Welt wiedersieht. Ich gucke 
nämlich öfters mal Anwendern über die Schulter, welche Probleme sie so 
mit Software haben. Übrigens hat nicht jeder Anwender den neuesten 
i7-4.5GHz Gaming-PC mit 16GB, TB-SSD, GBitEthernet wie ihn OOP 
Programmierer voraussetzen.

[Scelumbro (Gast)]

MaWin schrieb:
> Du hast es nicht und wirst es nicht kapieren, wieso du dich mit dieser
> Einstellung zum schlechtesten Programmierer der Welt machst auf den alle
> Anwender einen Hass haben.
>
> Wenn eines "common sense" unter den Anwendern ist, dann dass aktuelle
> Programme zu gross und zu langsam sind, auf Grund der Arroganz von
> Programmieren wie dir, die in ihrer optimalen Umgebung (dicke schnelle
> Maschine mit guter Anbindung ohne weiteren Ballast) meinen: "Es reicht,
> so wie es ist", und sich faul zurücklehnen.

Wärst du bereit für irgendeine Software einen Aufpreis für eine 
Size-Optimized-Variante zu bezahlen, die sich von der Standardvariante 
nur dadurch unterscheidet, dass die Binaries (nicht die sonstigen 
Resourcen, den die üppig bebilderte Onlinehilfe auch für Analphabeten 
will ja trotzdem jeder) x% kleiner sind? Ein Office-Optimized?
Und mit was für einem Effekt? Für ein paar gesparte Minuten beim 
Download? Für ein paar gesparte MB auf der Festplatte?

[Sheeva P. (sheevaplug)]

MaWin schrieb:
> Sheeva P. schrieb:
>> Genau dasselbe begegnet mir hier im Forum, wenn ich darauf hinweise, daß
>> es zur Softwareentwicklung nicht unbedingt einer IDE bedarf. Da werden
>> die IDE-Freunde aber unleidlich und erklären mir, wie antiquiert mein
>> Ansatz sei. Und genau dieselben trifft man dann wieder, wenn irgendwas
>> mit ihrer IDE nicht richtig funktioniert oder wenn sie darüber weinen,
>> daß ihre IDE so ein aufgeblähtes, langsames GUI-Monster sei.
>>
>> Sorry, aber solche Probleme liegen nicht an der Software, sondern an den
>> Anwendern selbst
>
> Danke für die erklärend erheitenden Worte.

Für Dich immer gerne, wenngleich die Erheiterung ganz bei mir liegt. ;-)

> Du nutzt also lieber selbst keine IDE weil zu gross und bulky,

Nein, da hast Du wohl wieder einmal etwas flashc verstanden. Ich nutze 
keine IDEs, weil sie mir zu unflexibel sind, weil ich bis dato keine IDE 
gefunden habe, die alle von mir genutzten Paradigmen und Sprachen -- und 
darunter sind nicht nur Programmiersprachen, sondern auch Auszeichnungs- 
und Datenformate wie XML, JSON, HTML, LaTeX -- ähnlich gut unterstützt.

Darüber hinaus bin ich allerdings ohnehin kein großer Freund von GUIs, 
wie sogar Du hättest verstehen können, wenn Du die geistigen Kapazitäten 
dazu hättest und nicht nur darauf erpicht wärst, mir das Wort im Mund 
herum zu drehen. Meine Briefe und Präsentationen schreibe ich mit LaTeX 
statt mit Wörd/LoWriter oder Powerpoint/LoImpress, statt einer 
Tabellenkalkulation wie Excel benutze ich lieber iPython und Pandas, und 
wenn ich eine Datenbank haben will, greife ich nicht zu Access oder 
LoBase, sondern habe PostgreSQL und für simple, kleine Dinge SQLite 
installiert. Klar, für einige Dinge sind GUI-Programme einfach besser: 
zum Websurfen, zur Visualisierung, für CAD und interaktive 
Grafikbearbeitung nutze natürlich auch ich GUI-Software. Aber wo ich 
GUIs meiden kann, benutze ich keine.

Außerdem habe ich recht leistungsfähige Entwicklungsrechner. Daher würde 
es mir nichts ausmachen, eine aufgeblähte Software zu benutzen, wenn ich 
sie denn benutzen wollen würde. Aber, wie gesagt: ich will ja gar nicht.

> Selten so entlarvendees gelesne, und das nach dutzenden Lügenmärchen die
> du hier über OOP aufgetischt hast.

LOL! Daß jemand, der so etwas wie GALBLAST.C verbrochen hat, mit 
meinen Aussagen überfordert ist und sie nicht verstehen kann, dafür habe 
ich ja ein gewisses Verständnis. Aber versteh' bitte auch, daß ich so 
jemanden nicht ernstnehmen kann, wenn er versucht, mir etwas über 
Softwaredesign, -paradigmen und -entwicklung zu erzählen.

> Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit
> Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie
> schon bei "Speichern" unverständlichen Welt wiedersieht.

Datei->Speichern oder Ctrl-s versus Datei->Speichern oder Ctrl-s... Ja, 
das ist wirklich zu schwierig, kein Wunder, daß Du es nicht verstehst.

> Übrigens hat nicht jeder Anwender den neuesten i7-4.5GHz Gaming-PC mit
> 16GB, TB-SSD, GBitEthernet wie ihn OOP Programmierer voraussetzen.

Es ist zum Glück und erfreulicherweise nicht mein Problem, daß Du noch 
mit einem dampfbetriebenen 286er unterwegs bist. Wenn Du mehr von 
Software und Softwareentwicklung verstündest als von primitivem 
Verbalinjurien und dem gezielten, böswilligen Mißverstehen Deines 
Gegenübers, ja dann könntest Du vielleicht genug verdienen, um Dir einen 
richtigen Computer zu kaufen. ;-)

[(prx) A. K. (prx)]

MaWin schrieb:
> Übrigens hat nicht jeder Anwender den neuesten
> i7-4.5GHz Gaming-PC mit 16GB, TB-SSD, GBitEthernet wie ihn OOP
> Programmierer voraussetzen.

Für OOP per se benötigt man keine Highend-Umgebung. OOP bedeutet nicht, 
dass es sich um einen riesigen Apparat handelt.  Zumal man sich die 
Basis des Prinzips auch interpretiert aneignen kann.

Eine solche Umgebung kann allerdings sinnvoll sein, wenn bei grossen 
Projekten die eingesparte Arbeitszeit teurer ist als die Investition im 
gute Hardware. Das dürfte freilich auch für FPGA Design gelten.

[Carl D. (jcw2)]

Lustige Diskusion.
Kann man mit VisualStudio nicht auch ASM-Programme schreiben?
Damit wäre ja dann bewiesen, daß ASM zu Bürokratie und Code-Blähungen 
führt.

[Helmut D. (Gast)]

Carl D. schrieb:
> Damit wäre ja dann bewiesen, daß ASM zu Bürokratie und Code-Blähungen
> führt.

Wenn ich mir den ganzen Kindergarten so anschaue ("wer hat den 
längsten?"), dann krieg ich ganz andere Blähungen :-)

[Stefan F. (Gast)]

MaWin schrieb:
> Übrigens hat nicht jeder Anwender den neuesten
> i7-4.5GHz Gaming-PC mit 16GB, TB-SSD, GBitEthernet wie ihn OOP
> Programmierer voraussetzen.

Blödes Argument.

Ich habe OOP mit Turbo Pascal auf einem nicht vernetzten 286er mit 10Mhz 
und 512MB RAM gelernt und darauf auch zwei kommerzielle Anwendungen 
entwickelt.

Heutzutage verbergen sich derart leistungsfähige Rechner zum Beispiel in 
Glühlampen-Fassungen. Mein Smarthone leistet schon ein vielfaches davon, 
und das ist wahrlich kein High-End Gerät.

Abgesehen davon ist die Aussage grundsätzlich falsch, dass OOP den Code 
oder den Ressourcen-Bedarf wesentlich erhöhe.

> OOP bedeutet nicht, dass es sich um einen riesigen Apparat handelt.

Yepp

[(prx) A. K. (prx)]

Carl D. schrieb:
> Lustige Diskusion.
> Kann man mit VisualStudio nicht auch ASM-Programme schreiben?
> Damit wäre ja dann bewiesen, daß ASM zu Bürokratie und Code-Blähungen
> führt.

Und wenn man die Entwicklung unter einem Windows-Blähsystem mit VS 
durchführt, statt unter einem ranken schlanken Commandline-Linux mit 
vi/make, dann wird das gleiche Programm dadurch natürlich um 
Größenordnungen fetter.

[D. I. (Gast)]

Mh, wie die "OOP-Verweigerer" wohl ein Softwareprojekt realisieren bei 
dem ca. 600 aktive Entwickler ihre Wiener ins Senfglas stecken? ...

[(prx) A. K. (prx)]

D. I. schrieb:
> Mh, wie die "OOP-Verweigerer" wohl ein Softwareprojekt realisieren bei
> dem ca. 600 aktive Entwickler ihre Wiener ins Senfglas stecken? ...

Sicher, dass dies zu einem anderen Ergebnis führt? Solche Projekte haben 
eine gewisse Neigung, in die Fritten zu gehen. ;-)

[Scelumbro (Gast)]

D. I. schrieb:
> Mh, wie die "OOP-Verweigerer" wohl ein Softwareprojekt realisieren
> bei
> dem ca. 600 aktive Entwickler ihre Wiener ins Senfglas stecken? ...

Das macht Moby schon - alleine und in ASM. Gut das Projekt darf nicht 
komplexer sein, als LED-Blinky + Tastenentprellung. Und es muss auf 
einem AVR laufen, schließlich ist x86 ASM zu komplex. Aber dann wird es 
total effizient programmiert werden. Schließlich kann nur einer dran 
arbeiten, dass heisst keine Schnittstellen, keine Architektur, keine 
Absprachen,keine Meetings- kein Overhead, 100% Effizienz.

[D. I. (Gast)]

A. K. schrieb:
> D. I. schrieb:
>> Mh, wie die "OOP-Verweigerer" wohl ein Softwareprojekt realisieren bei
>> dem ca. 600 aktive Entwickler ihre Wiener ins Senfglas stecken? ...
>
> Sicher, dass dies zu einem anderen Ergebnis führt? Solche Projekte haben
> eine gewisse Neigung, in die Fritten zu gehen. ;-)

Nun ja das Ding lebt schon relativ lange und steckt in diversen 
Endprodukten in unterschiedlicher Ausprägung in realen Produkten und 
wird halt weiterentwickelt.

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4635958:
> Sheeva P. schrieb:
>> Sorry, aber solche Probleme liegen nicht an der Software, sondern an den
>> Anwendern selbst und ihren manchmal einfach bescheuerten Forderungen und
>> Erwartungen.
>
> Damit hast Du wunderschön auf den Punkt gebracht was ich Dir an anderer
> Stelle schon vorgehalten habe: Die Bedürfnisse Deiner Programmierung und
> Deines Systems über die Forderungen und Erwartungen des Anwenders zu
> stellen. Stichwort Admin-Welt! Das ist wieder mal der selbstherrliche
> Entwickler wie er im Buche steht. Der Gott in weiß- äh der Gott am PC
> ;-(

Weißt Du, ich arbeite gar nicht für Microsoft oder Adobe, und habe mit 
den genannten GUI-Monstern aus diesen Häusern nicht einmal als Anwender 
etwas zu tun. Es ist auch nicht meine Schuld, und erst recht nicht mein 
Problem, daß es immer noch Leute gibt, die dieses Zeug kaufen.

Für die Feststellung, daß kommerzielle Software immer aufgeblähter 
werden wird, je länger das Argument "jetzt mit neuen Funktionen, die 
kein Mensch braucht" noch beim Verkauf zieht, bedarf keines besonderen 
Genies, sollte also auch für Deinen Intellekt einigermaßen zugänglich 
sein. Die meisten Anwender von Word, Excel, Access, Powerpoint und 
Photoshop werden jedoch heute schon von ihrer Software überfordert und 
benutzen nur einen kleinen Bruchteil der Funktionen dieser Software.

Und natürlich rede ich nicht davon, an den Forderungen und Erwartungen 
von Anwendern vorbei zu entwickeln, was für eine selten dumme 
Interpretation. Ganz im Gegenteil kritisiere ich, daß Kaufanreize immer 
noch über neue, unnötige Funktionen gesetzt werden, anstatt sich darauf 
zu beschränken, die benötigte und sinnvolle Funktionalität mit einer 
sauberen Usability anzubieten. Gerade von Dir mit Deiner manischen 
Phobie gegenüber allem, das komplizierter ist als ein Loch in den Schnee 
zu pinkeln, hätte ich da eher volle Zustimmung erwartet. Stattdessen 
versuchst Du schon wieder, mir die Worte im Mund herum zu drehen... 
Langsam bekomme ich eine Idee davon, wen Einstein gemeint hat, als er 
von unendlicher Dummheit sprach. :-)

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4635945:
> Sheeva P. schrieb:
>> War ja auch ne peinliche Geschichte mit Deinem C-Versuch.
>>
>> Ja, aber nicht für mich. :-)
>
> Also ich schrieb nichts in C.

Natürlich nicht. Das kannst Du ja auch gar nicht.

[(prx) A. K. (prx)]

Moby/Sheeva: Meint ihr wirklich, dass ihr mit wechselseitigen 
Beschimpfungen weiter kommt?

[MaWin (Gast)]

Sheeva P. schrieb:
> wenn Du die geistigen Kapazitäten dazu hättest und nicht nur darauf
> erpicht wärst, mir das Wort im Mund herum zu drehen.

Bei dir muss man nicht Worte im Mund umdrehen,
sondern ich ordne nur deine kruden Aussagen hier.

Du hingegen, nein, du verstehst das:

Sheeva P. schrieb:
>> Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit
>> Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie
>> schon bei "Speichern" unverständlichen Welt wiedersieht.
>
> Datei->Speichern oder Ctrl-s versus Datei->Speichern oder Ctrl-s... Ja,
> das ist wirklich zu schwierig, kein Wunder, daß Du es nicht verstehst.

nicht miss, sondern du schreibst absichtlich 'Du' statt 'diese 
Anwenderin' weil du bloss dummdreist provozieren willst. Leute, die 
anderen vorhalten, was sie selber tun, sind krank. Such dir einen 
Psychiater.

Sheeva P. schrieb:
> LOL! Daß jemand, der so etwas wie GALBLAST.C verbrochen hat, mit
> meinen Aussagen überfordert ist und sie nicht verstehen kann, dafür habe
> ich ja ein gewisses Verständnis.

Es steht dir frei, das Programm besser zu schreiben (wäre nach 20 Jahren 
ja mal Zeit, ist noch Win16), es ist open source.
Aber von Dummschwätzern wie dir kommt natürlich kein eigener Handschlag, 
und die Anwender finden es gut zu bedienen, gut zu verstehen, gut zu 
benutzen, sehen also keine Veranlassung es zu verunstalten.

Stefan U. schrieb:
>> Übrigens hat nicht jeder Anwender den neuesten
>> i7-4.5GHz Gaming-PC mit 16GB, TB-SSD, GBitEthernet wie ihn OOP
>> Programmierer voraussetzen.
>
> Blödes Argument.

Das Argument brauchte ich gar nicht bringen, das kommt hier:

Sheeva P. schrieb:
> Außerdem habe ich recht leistungsfähige Entwicklungsrechner. Daher würde
> es mir nichts ausmachen, eine aufgeblähte Software zu benutzen,

Idioten wie Sheeva benutzen eben leistungsfähige Rechner, schreiben 
darauf OOP-Software bis sie meinen daß alles in Odnung ist und 
angemessen schnell läuft, und dann kommt die Software zum Anwender:

Stefan U. schrieb:
> Ich habe OOP mit Turbo Pascal auf einem nicht vernetzten 286er mit 10Mhz
> und 512MB RAM gelernt

Welchem auch immer, eben nicht dem leistungsfähigen Entwicklungsrechner 
sondern dem realen Gerät und alle regen sich ZU REHT über die 
lahmbarschige Bloatsoftware von Sheeva auf.

[Stefan F. (Gast)]

> weil ich bereits beim Design auf die nötige ... achte.
> Alles andere ist m.M.n. als Gesamtkonzept Pfusch.

Tja, du hast echt Glück, wenn du Projekte mit sauberem Gesamtkonzept 
umsetzen darfst.

In der Praxis ist es leider oft so, dass Kosten und Zieltermin schon vor 
dem Funktionsumfang festgelegt werden. Dann werden Funktionen gefordert, 
die sich gegenseitig stören bzw. wegen unvollständigem Konzept nicht 
funktionieren können.

Irgendwann sagt Dir dein Auftraggeber "Fang schonmal an und mach 
irgendwas sinnvolles. Die Detaul überlegen wir uns noch". Und dann 
werden nur einige Konzept-Lücken geschlossen, stattdessen ständig andere 
Funktionen gefordert. Und zwar nicht selten bis zum letzten Tag vor der 
Abnahme - falls überhaupt eine offizielle Abnahme stattfindet. Manche 
diese Forderungen stellen das gesamte Design der Software in Frage.

Und jetzt stelle Dir so ein Projekt vor, verteilt auf drei Firmen, die 
sich nicht gerade lieb haben (da Konkurrenten) beauftragt von einem 
Kunden, der Keine Ahnung hat (von Technik, Juristischen Aspekten und dem 
Business) und trotzdem meint, selbst Projektleiter spielen zu können.

DAS, mein lieber Moby, ist die Realität, mit der sie die allermeisten 
Programmierer tagtäglich herum schlagen müssen. Programmieren können ist 
nur die halbe Miete (eher noch weniger). Projektarbeit ist die Kür.

Und zum Ausgleich arbeiten einige davon an Open-Source Projekten mit 
oder machen ihre eigene Show, damit sie wenigstens einmal im Leben ein 
aus ihrer Sicht sauberes Projekt durchziehen können, das man auch 
vorzeigen kann ohne sich in den Boden zu schämen.

Ich behaupte, daß sich die Entwickler von 90% aller kommerziellen 
Programme für ihre eigenen Werke schämen, da sie nichtmal die eigenen 
Ansprüche von Qualität erfüllen.

[Scelumbro (Gast)]

Moby A. schrieb im Beitrag #4635907:
>>
>
> Scelumbro nochmal für Dich: Das hat auch niemand behauptet (jedenfalls
> ich nicht).
> Eine IDE wie VS zeigt aber alle konkreten Möglichkeiten der OOP auf, ist
> insofern (und auch im Blick auf die vielen angebotenen
> Spezial-Werkzeuge) Spiegelbild ihrer Komplexität

Moby, komplexe Software ist nicht die Folge von komplexen 
Programmiersprachen. Ihre Komplexität ist vielmehr die Summe vieler 
einfacher Teile. Die einfache Kombinierbarkeit dieser einfachen Teile 
ist aber ein Vorteil von OOP. Viele Teile einer IDE haben auch nichts 
mit der Programmiersprache an sich zu tun sondern bearbeiten Probleme 
rund um ein Projekt wie Versionsverwaltung.

[W.S. (Gast)]

Moby A. schrieb im Beitrag #4634978:
> Der Codebedarf eines simplen funktionslosen Windows-Fensterchens zeigt
> schon, wie ineffizient bereits das OS aufgebaut ist. Im Prinzip langt
> doch dafür die Übergabe einiger Paramater mit sagen wir mal einer
> prozeduralen WINDOWS(Parameter) Instruktion. Was macht die liebe OOP
> Programmierung draus? Kilobyteweise Code...

Moby, ich muß an dieser Stelle mal auf die Bremse drücken. Verwechsle du 
bitte NICHT objektorientierte Programmierung mit irgend einer 
Klassenbibliothek oder sonstiger Middleware.

Ich geb dir mal ein Beispiel: Wenn du mit Delphi eine GUI-Anwendung 
schreibst, dann kostet dich ein simples "Hello World" bei Delphi 6 so um 
die 400 KByte, bei Delphi 10 schon über 2 MB und wenn man dann noch nen 
gefälligeren Skin drauf haben will, an die 3 MB - so etwa.

Das liegt aber NICHT an OOP, sondern an der jeweiligen Klassenbibliothek 
und deren Grundstruktur, die ein echt4s Smart-Linking nicht zuläßt.

Wenn du hingegen mal sowas wie KOL (Key Objects Lib) ausprobiert 
hättest, was nach einigem Installations-Eiertanz unter Delphi 6 recht 
ordentlich läuft, dann würdest du sehen, daß das gleiche GUI-Programm 
lediglich einige Dutzend KB (ich schätze so 20..25 K) benötigt. Und auch 
die KOL ist tatsächlich OOP. siehe: "http://wiki.freepascal.org/KOL";



MaWin schrieb:
> Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit
> Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie
> schon bei "Speichern" unverständlichen Welt wiedersieht.

Eben. Verstehe ich genauso. In diesem Punkte treffen wir uns mal wieder. 
Die Meinige macht auch ALLES mit MS Office, selbst Dinge, die ich 
damit nie zuwege bringen würde.

Das ist eben immer wieder die für manche befremdliche tatsache, daß 
Leute verschiedener Provenienz und verschiedener Arbeits-Umgebungen auch 
verschiedene Spezialfertigkeiten entwickelt haben. Wer im Umgang mit MS 
Office geübt ist, ist damit weitaus besser und effektiver als jemand, 
der seine Bilder per Kommandozeile bearbeiten will (hatten wir neulich 
hier einen). ich sehe auch in der Firma viele, die mitdem Explorer 
geradezu artistisch umgehen, was mir selbst (als TC-Benutzer) nicht 
sonderlich genehm ist. OK, unsereiner kann damit selbstverständlich 
umgehen, aber eben nicht so effektiv wie jemand, der damit warmgeübt 
ist. Und bei der betreffenden Anwenderin sieht das genauso aus. Die Dame 
hat ganz gewiß ein völlig anderes Arbeitsfeld und genau dieses ist es, 
wo sie richtig gut sein muß - da ist sowas wie der PC nur eben das, was 
er sein soll: ein Hilfsmittel und eben nicht der berufliche 
Lebensinhalt.

Ganz viele der Schreiber hier in diesem Forum ignorieren das immer 
wieder, bis hin dazu, daß so einer neulich solche Anwender und 
Anwenderinnen als "brain dead" bezeichnet hat. Brett vor'm Kopf kann ich 
dazu nur sagen.

W.S.

[Sheeva P. (sheevaplug)]

MaWin schrieb:
> Sheeva P. schrieb:
>>> Und JA: Ich verstehe die Anwenderin, die vielleicht mit Mühe Word mit
>>> Ribbons erlernt hat und nun bei Notepad sich in einer anderen, für sie
>>> schon bei "Speichern" unverständlichen Welt wiedersieht.
>>
>> Datei->Speichern oder Ctrl-s versus Datei->Speichern oder Ctrl-s... Ja,
>> das ist wirklich zu schwierig, kein Wunder, daß Du es nicht verstehst.
>
> nicht miss, sondern du schreibst absichtlich 'Du' statt 'diese
> Anwenderin' weil du bloss dummdreist provozieren willst. Leute, die
> anderen vorhalten, was sie selber tun, sind krank. Such dir einen
> Psychiater.

Es war nicht die Anwenderin, sondern es warst Du, der mit dem 
"Speichern" angefangen hat. Zum Glück hast Du die Entstehungsgeschichte 
meiner Aussage ja bereits selbst zitiert; vielen Dank dafür, daß Du es 
diesmal wenigstens korrekt und in der richtigen Reihenfolge zitiert 
hast.

Und was das dummdreiste Provozieren angeht, kann ich Dir da lange nicht 
das Wasser reichen. Beinahe jeder "Beitrag" von Dir ist mit persönlichen 
Angriffen gespickt, nicht nur in diesem Thread hier. Jetzt rastest Du 
aus, weil dieses Mal jemand dagegenhält und sich Deine wirren Pöbeleien 
nicht widerspruchslos gefallen läßt. Das ist einerseits lustig, aber 
auch sehr schade, denn schließlich wußten schon unsere Mütter: wie man 
in den Wald hineinruft, so schallt es wieder heraus. Oder, kurz gesagt: 
wenn Du schon so ein Mimöschen bist, solltest Du dringend damit 
beginnen, Dein eigenes Sozial- und Kommunikationsverhalten zu 
überarbeiten.

MaWin schrieb:
> Übrigens hat nicht jeder Anwender den neuesten
> i7-4.5GHz Gaming-PC mit 16GB, TB-SSD, GBitEthernet wie ihn OOP
> Programmierer voraussetzen.
>
> Sheeva P. schrieb:
>> Außerdem habe ich recht leistungsfähige Entwicklungsrechner. Daher würde
>> es mir nichts ausmachen, eine aufgeblähte Software zu benutzen,

Ich habe die Zitate mal in die richtige Reihenfolge gebracht: 
tatsächlich, mein lieber Freund, warst es nämlich Du, der mit dem 
dämlichen Gelaber vom "i7-4,5GHz Gaming PC" angefangen hat. Darauf waren 
meine "leistungsfähigen Entwicklungsrechner" nur die passende Antwort, 
insofern Du Dich wieder mal an Dein eigenes Näschen fassen darfst.

Es ist wirklich schade, daß jemand, der so viel von Elektronik versteht 
wie Du, so unfähig ist, ohne Beleidigungen zu kommunizieren. Daß Du Dich 
unter Verdrehung der Tatsachen aber jetzt noch zum, selbstverständlich 
gänzlich unschuldigen Opfer stilisierst, ist entweder unglaublich frech 
oder ein Zeichen dafür, daß Du ein Problem mit der Diskrepanz ziwschen 
Deiner Selbst- und Außenwahrnehmung hast, und die mir so warm empfohlene 
professionelle Hilfe sehr viel nötiger hast als ich. Viel Glück!

[Sheeva P. (sheevaplug)]

Moby A. schrieb im Beitrag #4636025:
> A. K. schrieb:
>> Moby/Sheeva: Meint ihr wirklich, dass ihr mit wechselseitigen
>> Beschimpfungen weiter kommt?
>
> Ich beschimpfe niemand. Trotzdem kann und sollte man manchen Leuten
> natürlich deutlich ihre Defizite vor Augen führen. Ein SheevaP hat das
> mit seinem Kommunikationsniveau ganz besonders nötig.

:-)

[Sheeva P. (sheevaplug)]

W.S. schrieb:
> Moby A. schrieb im Beitrag #4634978:
>> Der Codebedarf eines simplen funktionslosen Windows-Fensterchens zeigt
>> schon, wie ineffizient bereits das OS aufgebaut ist. Im Prinzip langt
>> doch dafür die Übergabe einiger Paramater mit sagen wir mal einer
>> prozeduralen WINDOWS(Parameter) Instruktion. Was macht die liebe OOP
>> Programmierung draus? Kilobyteweise Code...
>
> Moby, ich muß an dieser Stelle mal auf die Bremse drücken. Verwechsle du
> bitte NICHT objektorientierte Programmierung mit irgend einer
> Klassenbibliothek oder sonstiger Middleware.

Danke für diesen sachlichen, unaufgeregten Beitrag.

> Das ist eben immer wieder die für manche befremdliche tatsache, daß
> Leute verschiedener Provenienz und verschiedener Arbeits-Umgebungen auch
> verschiedene Spezialfertigkeiten entwickelt haben. Wer im Umgang mit MS
> Office geübt ist, ist damit weitaus besser und effektiver als jemand,
> der seine Bilder per Kommandozeile bearbeiten will (hatten wir neulich
> hier einen).

Natürlich. Dennoch erscheint es mir einigermaßen widersprüchlich, wenn 
die Anwender dieser Software sich dann einerseits über deren 
Überfrachtung und mangelhafte Performanz beklagen, jedoch Hinweise auf 
einfache und bereits installierte Alternativen zurückweisen. Stattdessen 
wurden in dem von mir vorgebrachten Beispiel dann gleich drei Admins, 
ein Vorgesetzter, und ein Mitarbeiter des Einkaufs in Marsch gesetzt und 
dann eine Erweiterung des Arbeitsspeichers für die Dame verbaut. Das 
Problem, daß die Dame über zu langsame Software beklagt, ist leider 
trotzdem geblieben.

Solche Geschichten begegnen unseren Admins ständig: ein Anwender will 
unbedingt die teuerste Version seines Betriebssystems, kann aber weder 
sagen, was der Unterschied zur einfachen Variante ist, noch, welche 
Funktionen der  teueren Version er braucht. Ein anderer Anwender möchte 
dringend eine Photoshop-Lizenz um ein paar Bilder zu skalieren, weil er 
Photoshop ja von zuhause kennt, und schreit unseren Einkäufer an, wenn 
sein Ansinnen abgelehnt und stattdessen PSP empfohlen wird.

Gleichzeitig sehe ich die Diskussionen hier im Forum, wo Windows-User zu 
Linux wechseln, weil sie von Windows die Nase voll haben, und sich dann 
darüber beklagen, daß Linux nicht genauso wie Windows ist... ach, war 
gerade das nicht der Grund für den Wechselgedanken?

Sorry, es mag ja sein, daß ich ein paar Dinge zu sehr aus der Admin- und 
Entwicklersicht sehe. Trotzdem komme ich beim besten Willen nicht um die 
traurige Feststellung herum, daß die Erwartungen, die manche Anwender an 
ihre Software, ihre Entwickler und ihre Admins stellen, manchmal einfach 
unrealistisch, und in anderen Fällen schlicht ignorant sind. Niemand 
kann mir einreden, daß daran immer nur die Admins und Entwickler schuld 
seien. Und ich glaube, die unkritische Haltung "der Anwender hat immer 
Recht" ist eine der wesentlichen Ursachen für die unrealistische 
Erwartungshaltung und die daraus resultierende Unzufriedenheit vieler 
Anwender.

Aber laßt uns zum eigentlichen Thema zurückkommen: der OO.

[MaWin (Gast)]

Sheeva P. schrieb:
> Ich habe die Zitate mal in die richtige Reihenfolge gebracht:
> tatsächlich, mein lieber Freund, warst es nämlich Du, der mit dem
> dämlichen Gelaber vom "i7-4,5GHz Gaming PC" angefangen hat. Darauf waren
> meine "leistungsfähigen Entwicklungsrechner" nur die passende Antwort,
> insofern Du Dich wieder mal an Dein eigenes Näschen fassen darfst.

Natürlich war die Reihenfolge so. Alle anderne Leser hier sehen also, 
daß ich die richtige Vorahnung gehabt habe. Du hast sie nur bestätigt. 
Offensichtlich bist du aber überfordert, Satz und Sachverhalt 
nachzuvollziehen.

Sheeva P. schrieb:
> Niemand
> kann mir einreden, daß daran immer nur die Admins und Entwickler schuld
> seien.

Dachte ich mir. Nennt man wohl Blindheit gegenüber eigenen Defiziten. 
Der Anwender ist jedoch schon mal nicht schuld oder zu blöd, denn FÜR 
IHN sollte die Software geschrieben sein, schlieb also nicht plump die 
Schuld auf ihn. Daß der Entwickler schlechte Rahmenbedingungen gehabt 
haben mag, vor allem zu wenig Zeit, Überforderung, mag alles als 
Entschuldigung herhalten. Letztlich hat er es aber verbrochen, selbst 
wenn die Vorgaben von einem fachlich uninformierten Chef kamen. Red dich 
also nicht raus und schieb die Schuld auf andere. Leider gibt es von 
deinr Sorte viele unter den Entwicklern.

Sheeva P. schrieb:
> Aber laßt uns zum eigentlichen Thema zurückkommen: der OO.

Mit Dogmatikern wie dir kommt da wohl kaum was sinnvolles bei raus. Da 
diskutiert es sich ja noch mit einem Islamisten besser. Aber so wie der 
Wasser predigt und Wein trinkt, so predigst du OOP, nutzt aber lieber 
Programme die ordentlich geschrieben wurden. Danke, mehr woltlen wir 
nicht wissen.

[Daniel A. (daniel-a)]

MaWin schrieb:
> Der Anwender ist jedoch schon mal nicht schuld oder zu blöd, denn FÜR
> IHN sollte die Software geschrieben sein, schlieb also nicht plump die
> Schuld auf ihn.

Du behaupest also, Anwender können nicht zu dumm für ihre Arbeit sein?

[Karl Käfer (Gast)]

Ui, hier ist ja wieder was los...

MaWin schrieb:
> Sheeva P. schrieb:
>> Ich habe die Zitate mal in die richtige Reihenfolge gebracht:
>> tatsächlich, mein lieber Freund, warst es nämlich Du, der mit dem
>> dämlichen Gelaber vom "i7-4,5GHz Gaming PC" angefangen hat. Darauf waren
>> meine "leistungsfähigen Entwicklungsrechner" nur die passende Antwort,
>> insofern Du Dich wieder mal an Dein eigenes Näschen fassen darfst.
>
> Natürlich war die Reihenfolge so. Alle anderne Leser hier sehen also,
> daß ich die richtige Vorahnung gehabt habe. Du hast sie nur bestätigt.

Also ich habe das ganz anders verstanden. Du hast Entwicklern und Admins 
pauschal und böswillig unterstellt Ressourcen zu verschwenden. Sheeva 
hat nur gesagt daß er sich eine Ressourcen verschwendende IDE leisten 
kann weil er auf seinen Rechnern genügend Power hat.

> Offensichtlich bist du aber überfordert, Satz und Sachverhalt
> nachzuvollziehen.

Offensichtlich willst Du ihn mißverstehen um ihn zu provozieren.

> Der Anwender ist jedoch schon mal nicht schuld oder zu blöd, denn FÜR
> IHN sollte die Software geschrieben sein, schlieb also nicht plump die
> Schuld auf ihn.

Wenn die Software für die Anwender geschrieben wäre würden sie nicht 
dauernd darüber schimpfen. Entweder ist die Software also nicht für die 
Anwender geschrieben oder die Anwender kaufen die falsche Software.

Er erklärt das mit den Mechanismen des heutigen Softwaremarktes. Du 
hingegen sagst daß es an der OOP läge. Echt jetzt? Im Ernst?

> Mit Dogmatikern wie dir kommt da wohl kaum was sinnvolles bei raus. Da
> diskutiert es sich ja noch mit einem Islamisten besser.

Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich. 
Merkst Du eigentlich noch was?

[Stefan F. (Gast)]

> oder die Anwender kaufen die falsche Software.

Viele (vielleicht gar die meisten) Anwender müssen mit Software 
arbeiten, die andere gekauft haben. Diese ärgern sich dann besonders 
schnell über Mängel.

[MaWin (Gast)]

Karl Käfer schrieb:
> Wenn die Software für die Anwender geschrieben wäre würden sie nicht
> dauernd darüber schimpfen.
> Entweder ist die Software also nicht für die Anwender geschrieben

Das stimmt natürlich sogar manchmal, beispielsweise bei Produkten wie 
Windows, wo es nicht den einen Kunden gibt, sondern alle Kunden etwas 
vorgesetzt bekommen.
Aber Auftragsentwicklung hätte natürlich den Kunden für den sie 
geschrieben wird, und Software für den Markt sollte so sein daß 
möglichst viele Menschen als Anwender in Frage kommen.

> oder die Anwender kaufen die falsche Software.

Kann schon sein, manchmal haben sie keine Wahl. Daher zahlen sie wohl 
auch so ungerne dafür: Die Erlebnisse waren zu schlecht als daß die 
Software was wert gewesen wäre.

> Er erklärt das mit den Mechanismen des heutigen Softwaremarktes.

Er erklärt es eher gar nicht, sondern sagt einfach der Anwender ist 
schuld, der hat doch gefälligst seine Sofwtare toll zu finden.

> Du hingegen sagst daß es an der OOP läge. Echt jetzt? Im Ernst?

Es liegt oft an Leuten wie Sheeva, die nicht in der Lage sind, sich in 
andere Menschen hineinzuversetzen und hochtrabend selbstüberzeugt 
glauben ihre Position wäre die einzige richtige. Eben wie religiöse 
Dogmatiker.

Sheeva ist so ziemlich das Abziehbild von dem Entwickler der alles 
falsch macht:
- Er glaubt, in OOP Läge das Heil.
- Er nutzt leistungfähigere Rechner (und das auch noch mit schlanker 
Software) als Entwicklungrechner als sie später der Kunde hat.
- Er sieht die Fehler beim Anwender und nicht bei sich selbst.

>> Mit Dogmatikern wie dir kommt da wohl kaum was sinnvolles bei raus. Da
>> diskutiert es sich ja noch mit einem Islamisten besser.
>
> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.

Im Gegenteil, er ist schlimmer.

[Borislav B. (boris_b)]

MaWin schrieb:
> - Er glaubt, in OOP Läge das Heil.

Meiner Erfahrung nach ist das tatsächlich so.

MaWin schrieb:
> - Er nutzt leistungfähigere Rechner (und das auch noch mit schlanker
> Software) als Entwicklungrechner als sie später der Kunde hat.

Aber sicher doch. Ein Entwicklungsrechner kann garnicht genup Power 
haben. Trotz Xeon mit 16 Kernen (hyperthreaded), 32 Gig RAM und SSD baue 
ich an meinen aktuellen Projekten z.T. > 1h. Der Rechner dürfte also 
gerne noch schneller sein :-)  (ja, die Projekte sind groß)
Zum TESTEN kann man dann gerne Gammel-Rechner einstzen, wie sie manche 
Kunden noch verwenden...

MaWin schrieb:
> - Er sieht die Fehler beim Anwender und nicht bei sich selbst.

Auch der Anwender ist nicht über jeden Zweifel erhaben...

[Stefan K. (stefan64)]

MaWin schrieb:
>> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.
>
> Im Gegenteil, er ist schlimmer.

Weil er er wagt, gegen Deine und Mobys krude OOP-Verschwörungstheorien 
anzudiskutieren?

Was Du hier bringst, ist purer Populismus. Hetze ohne ein einziges 
stichhaltiges Argument. Pfui.

[MaWin (Gast)]

Stefan K. schrieb:
> Was Du hier bringst, ist purer Populismus. Hetze ohne ein einziges
> stichhaltiges Argument. Pfui.

Hmm, dein einziger Beitrag hier.

Argumente lese ich in ihm auch nicht, bloss persönliche Diffamierung.

Du ahst also im ganzen Thread nichst gebracht.

Stefan, das ist: Unter aller Sau.

[Stefan K. (stefan64)]

MaWin schrieb:
> Argumente lese ich in ihm auch nicht, bloss persönliche Diffamierung.

Keine Argumente von Sheeva Plug? Hast Du hier eigendlich komplett 
mitgelesen? Oder verwechselst Du irgendwen? Persönliche Diffamierung 
finde ich hier hauptsächlich in Deinen Beiträgen.

[Bernd K. (prof7bit)]

Moby A. schrieb im Beitrag #4635907:
> Das hab ich mir noch nicht vorstellen müssen weil ich bereits beim
> Design auf die nötige Anzahl identisch ansprechbarer Hardware-UARTS
> achte. Alles andere ist m.M.n. als Gesamtkonzept Pfusch.

Danach habe ich nicht gefragt. Du weichst der Frage aus. Um Dir entgegen 
zu kommen lass den zweiten Teil erstmal weg, der ist (vorerst) aus 
Konstengründen gestrichen.

Also was ist jetzt?

[MaWin (Gast)]

Stefan K. schrieb:
> Keine Argumente von Sheeva Plug? Hast Du hier eigendlich komplett
> mitgelesen? Oder verwechselst Du irgendwen?

Bist du Sheeva Plug ? Argumente lieferte er jedoch nicht, bloss 
Behauptungen. Und versucht sich in frechen Umdeutungen

Da behauptet er:
! > Wie schlecht objektorientierte Formulierungen von durchaus
! > objektorientierten Welten sein können, sieht man an MFC.
! Ach Du liebe Güte... die MFC war niemals ein OO-Design, sondern
! lediglich ein Wrapper um die c- und assemblerbasierte WinAPI.
daß MFC kein OOP wäre. Das ist schlicht gelogen, aber irgendwie muss er 
ja vermeiden daß seine allumfassendee Heilsbotschaft "OOP ist gut" 
Kratzer kriegt, da schreckt er auch vor Lügen nicht zurück, die aber 
natürlich sofort auffallen. Klar ist MFC ein schlechter OOP Wrapper um 
das WinAPI, aber nichtsdestrotrotz OOP und Grundlage für viele OOP 
Programme. Ja, die sind vielleicht sogar alle schlecht gecschrieben und 
schlecht wartbar, aber immer noch eine Realisierung in OOP. Das darf 
natürlich nach seiner Heilsdoktrin nicht sein.


Du hingegen fordest Argumente ein, lieferst selbst aber kein einziges.
Also immer erst mal vor der eigenen Haustür kehren.


> Persönliche Diffamierung finde ich hier hauptsächlich in Deinen Beiträgen.

Blinde mit Scheuklappeen, ja ja.

[nicht"Gast" (Gast)]

Bernd K. schrieb:
> Danach habe ich nicht gefragt. Du weichst der Frage aus. Um Dir entgegen
> zu kommen lass den zweiten Teil erstmal weg, der ist (vorerst) aus
> Konstengründen gestrichen.
>
> Also was ist jetzt?

Moin,

darauf zu Pochen ist müßig bei Moby. Erweitern von Projekten kennt er 
nicht und da haben schon gefühlt 100 Leute in anderen Threads 
nachgehakt, nachgefragt... verzweifelt.

Heb dir deine Kraft für die Diskussion um OOP auf^^.


Zum Topic. Ich bin immer etwas verwundert, warum die Leute so Probleme 
mit dem Konzept haben. Eigentlich abstrahiert es doch die Realität viel 
besser als rein prozedurale Programmierung.

Das wird ja in der Naturkunde auch so gemacht.
Hier ein Beispiel aus aktuellem Anlass :)

Apfel --- Birne

Beide aus der Familie der Rosengewächse (Basisklasse), die sich aber in 
Eingenschaften (Farbe, Geschmack, Vergleichbarkeit) unterscheiden 
(Ableitungen).

Moby A. schrieb im Beitrag #4636020:
> Dann erstelle mal ein leeres Win-Fenster mit Visual C++ und schau Dir
> die resultierende Codegröße an. Da wird Dir auch ein
>
>> Window win("Titel", 800, 600);
>
> im Programm wenig Ersparnis bringen.
> Wenn freilich die paar Ascii-Bytes dieser Zeile schon das ganze
> Programm wären... So einfach ist es aber leider nicht. Warum nur?

Zugegenermaßen in C# ist die Datei 6,5K groß. Du tust allerdings so, als 
wenn jedes eingebene Zeichen die Datei proportional weiter vergößern 
würde. Die größten Platzfresser bei den Programm sind aber nun mal nicht 
die Code Binaries, sondern die restlichen Ressourcen wie Bilder, Daten 
und ähnliches.

Ach ich seh grad. Ich hab ausgerechnet Moby zitiert. Bitte ignorieren.

Grüße.

[Stefan K. (stefan64)]

MaWin schrieb:
> Du hingegen fordest Argumente ein, lieferst selbst aber kein einziges.

Ich fordere hier einen besseren Umgangston ein. Beleidigungen und 
persönliche Angriffe wie diese hier (kleiner Auszug aus Deinen 
"Diskussionsbeiträgen") werden in diesem Forum nicht toleriert:


MaWin schrieb:
> Du hast es nicht und wirst es nicht kapieren, wieso du dich mit dieser
> Einstellung zum schlechtesten Programmierer der Welt machst auf den alle
> Anwender einen Hass haben.

MaWin schrieb:
> Selten so entlarvendees gelesne, und das nach dutzenden Lügenmärchen die
> du hier über OOP aufgetischt hast.

MaWin schrieb:
> Idioten wie Sheeva benutzen eben leistungsfähige Rechner, schreiben
> darauf OOP-Software bis sie meinen daß alles in Odnung ist und
> angemessen schnell läuft, und dann kommt die Software zum Anwender:

MaWin schrieb:
>>> Mit Dogmatikern wie dir kommt da wohl kaum was sinnvolles bei raus. Da
>>> diskutiert es sich ja noch mit einem Islamisten besser.
>>
>> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.
>
> Im Gegenteil, er ist schlimmer.

[MaWin (Gast)]

Stefan K. schrieb:
> persönliche Angriffe wie diese hier (kleiner Auszug aus Deinen
> "Diskussionsbeiträgen") werden in diesem Forum nicht toleriert

Deine hingegen schon ? Merkwürdige Lebensauffassung.

Stefan K. schrieb:
> krude OOP-Verschwörungstheorien
> purer Populismus.
> Hetze ohne ein einziges stichhaltiges Argument.
> Pfui.

[Stefan K. (stefan64)]

Nach

>> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.
>
> Im Gegenteil, er ist schlimmer.

war das ja wohl mehr als angemessen.

Dafür, dass Du andere Forenteilnehmer mit Gewalttätern gleichsetzt, bist 
Du bei Deiner eigenen Person merkwürdig empfindlich.

[Durchstarter (Gast)]

>Beide aus der Familie der Rosengewächse (Basisklasse), die sich aber in
>Eingenschaften (Farbe, Geschmack, Vergleichbarkeit) unterscheiden
>(Ableitungen).

^^Vielleicht gibt es ja deshalb so viel Schlechtes in der Welt - weil 
sie auf OO gründet!

(Tut mir leid, konnt´s mir nicht verkneifen)

[W.S. (Gast)]

Karl Käfer schrieb:
> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.
> Merkst Du eigentlich noch was?

Stop mal, mein Junge!

Du bist es, der hier nichts merkt.
Er hat ihn nämlich nicht mit einem fanatischen Gewalttäter 
gleichgesetzt. Du warst das, der ihm dies unterschieben wollte. Er hat 
stattdessen ganz konkret geschrieben "Da diskutiert es sich ja noch mit 
einem Islamisten besser".

Abgesehen davon kann ich mich immer noch an einen Papst erinnern, der 
mit dem Attentäter, der es auf ihn abgesehen hatte, diskutiert hat.

Mal im ganz rüden Klartext: Gesprächsbereitschaft setzt auch das 
Zuhörenwollen voraus, sonst ist sie nutzlos. Das schließt auch das 
sachliche Ausdiskutieren von Argumenten ein. Aber stattdessen sehe ich 
hier bösartige Unterstellungen und ne Menge Fanatismus.



Sheeva P. schrieb:
> Dennoch erscheint es mir einigermaßen widersprüchlich, wenn
> die Anwender dieser Software sich dann einerseits über deren
> Überfrachtung und mangelhafte Performanz beklagen, jedoch Hinweise auf
> einfache und bereits installierte Alternativen zurückweisen.

Es ist durchaus nicht widersprüchlich. Bedenke mal, daß gerade Windows 
und gerade MS Office von Milliarden von Leuten benutzt werden. Glaubst 
du ernsthaft, diese wären alle mental gleichgeschaltet? Natürlich nicht! 
Also gibt es immer eine Verteilung von Ansprüchen und Meinungen. Ob 
Gauss oder ne andere Verteilung.

Und die von dir angedeutete, jedoch nicht benannten Alternativen sehe 
ich nirgendwo - ganz besonders nicht "einfache und bereits installierte 
Alternativen". Was denn bitte? Nein, das war lediglich ein vorlauter 
Zungenschlag deinerseits. Ich hab vor vielen Jahren in der Firma die 
Umstellung von Wordperfect auf OpenOffice miterlebt - für EDV-Gesindel 
wie unsereins ist das kein Thema, aber die Welt besteht vorrangig aus 
Leuten, die eben nicht zum EDV-Gesindel gehören.

Nun, das was du da an Klagen formulierst, ist vorrangig das Klagen eben 
dieser Leute, die sich mühsam an eine MS Office Version gewöhnt hatten 
und dann bei einer viel neueren Version erstmal ihre Menüpunkte nicht 
dort gefunden haben, wo sie bisher waren.
Begreif das mal als ein echtes Problem.
Es IST ein echtes Problem.
Vielleicht würde es dir was nützen, wenn du mal was Entsprechendes für 
DICH dir formulieren würdest, also dir vorzustellen, daß du für deinen 
Job etwas tun müßtest, was ganz und gar aus deinem eigenen Berufsbild 
heraussteht. z.B. deine Zwischenberichte bislang in Sanskrit verfassen 
und dich dann auf Hieroglyphen umstellen müssen. Oder 35 verschiedene 
wichtige Tinkturen anrühren müssen, wo du mit Mühe gelernt hast, wie die 
167 verschiedenen Chemikalien in welcher Reihenfolge rein müssen und nun 
wird bei 42 Zutaten auf was Anderes umgestellt und alle Reihenfolgen 
sind anders, ebenso die Mengen usw. Verstehst du, was ich meine?


Sheeva P. schrieb:
> Sorry, es mag ja sein, daß ich ein paar Dinge zu sehr aus der Admin- und
> Entwicklersicht sehe.

Zumindest ist die Erkenntnis dessen ein erster Schritt.

ich geb dir mal nen Spruch, den ich vor langer Zeit gehört und sinngemäß 
behalten habe. Es geht da zwar um das Schreiben von Manuals, aber das 
dahinterstehende Prinzip ist es, worauf es ankommt:

"Schreib dein Manual so, als ob du es für einen alten Advokaten 
schreiben würdest. Der versteht von deiner Arbeit und deinem Fache 
reinweg GARNICHTS - aber deswegen solltest du ihn nicht gering schätzen. 
Er ist nämlich jemand mit einem riesengroßen Wissen und Erfahrungsschatz 
- jedoch auf allen anderen Gebieten außer eben deinem. Er hat auch einen 
rasiermesserscharfen Verstand, kann zuhören und verstehen und überhört 
dabei nichts - vorausgesetzt, du drückst dich verständlich aus. Er kann 
auch logisch denken und seine Fragen zeigen dir, wo DU ein Defizit im 
Gesagten hattest und nicht wo sein Verstand zu gering wäre."

W.S.

[D. I. (Gast)]

http://9gag.com/gag/aoppmDx

[Sheeva P. (sheevaplug)]

MaWin schrieb:
> Stefan K. schrieb:
>> Keine Argumente von Sheeva Plug? Hast Du hier eigendlich komplett
>> mitgelesen? Oder verwechselst Du irgendwen?
>
> Bist du Sheeva Plug ?

Ich kann nicht für Stefan K. sprechen, aber soweit es mich betrifft, bin 
ich jedenfalls nicht er.

> Argumente lieferte er jedoch nicht, bloss Behauptungen.

Du scheinst mich mit jemandem zu verwechseln, eventuell mit Dir selbst.

> Und versucht sich in frechen Umdeutungen
>
> Da behauptet er:
> ! > Wie schlecht objektorientierte Formulierungen von durchaus
> ! > objektorientierten Welten sein können, sieht man an MFC.
> ! Ach Du liebe Güte... die MFC war niemals ein OO-Design, sondern
> ! lediglich ein Wrapper um die c- und assemblerbasierte WinAPI.
> daß MFC kein OOP wäre. Das ist schlicht gelogen,

Das wäre es, wenn ich das gesagt hätte. Habe ich aber gar nicht, wie Du 
selbst hättest bemerken können, wenn Du nicht mehr Energie investieren 
würdest, mich mißzuverstehen, als darin, meine Aussagen zu lesen.

Tatsächlich habe ich nicht geschrieben, daß die "MFC kein OOP wäre". Was 
ich geschrieben habe, ist, daß die MFC kein OO-Design ist, sondern nur 
ein OO-Wrapper um eine im Kern prozedurale API, die WinAPI. Verstehst Du 
nicht den Unterschied zwischen "kein OO" und "kein OO-Design"?

Die MFC krankt seit jeher unter mehreren Problemen: daß sie nur ein 
OO-Schnittstelle zu einer nicht-OO-API statt eines OO-Designs ist; daß 
sie aus einer Zeit stammt, in der es noch nicht sehr viele Erfahrungen 
mit OO unter C++ gab und die OO unter C++ noch relativ unausgereift war; 
daß Microsoft damals dazu tendierte, Frameworks unnötig aufzublähen und 
die interne Funktionalität seines Betriebssystems als Geschäftsgeheimnis 
zu betrachten.

Nachgerade ist es daher keine gute Idee, ausgerechnet die MFC als 
Beispiel für die Stärken oder Schwächen der OO zu betrachten; da eignen 
sich echte OO-Frameworks wie Qt, wxWidgets, die Boost-Libraries oder 
sogar .NjET viel besser.

> aber irgendwie muss er ja vermeiden daß seine allumfassendee
> Heilsbotschaft "OOP ist gut"

Das ist gar nicht meine Botschaft, und das habe ich auch nie gesagt. In 
Wahrheit habe ich sogar ganz ausdrücklich geschrieben: "OO ist nur eins 
von einer ganzen Reihe von Werkzeugen, die ich nutze" [1], daß "die 
verbreiteten Sprachen [] alle mehrere Paradigmen unterstützen", die "in 
der Praxis [] oft parallel genutzt" werden [2], daß ich "bei großen 
Datenmengen [] eher zu funktionalen Techniken [tendiere]" [3], und: 
"Wenn es morgen eine einfachere Möglichkeit gibt, dann bin ich der 
Erste, der sie adoptiert" [4].

Von einer "Heilsbotschaft", gar einer "allumfassenden", habe ich nichts 
geschrieben, das findet alles nur in Deinem eigenen Kopf statt. Pardon, 
aber für die Vorgänge in Deinem Kopf bin ich nicht verantwortlich.

[1] Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?"
[2] Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?"
[3] Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?"
[4] Beitrag "Re: OOP - für was in aller Welt soll denn das gut sein?"

> Kratzer kriegt, da schreckt er auch vor Lügen nicht zurück, die aber
> natürlich sofort auffallen. Klar ist MFC ein schlechter OOP Wrapper um
> das WinAPI,

Nichts anderes habe ich gesagt, und das hier:

> aber nichtsdestrotrotz OOP und Grundlage für viele OOP
> Programme. Ja, die sind vielleicht sogar alle schlecht gecschrieben und
> schlecht wartbar, aber immer noch eine Realisierung in OOP.

...steht dem, was ich gesagt habe, nicht entgegen. Das Problem scheint 
zu sein, daß Du nicht zuhörst und deswegen oft etwas ganz anderes liest, 
als Dein Gegenüber schreibt, und Dich dann an den Strohpuppen 
hochziehst, die nur in Deinem eigenen Kopf stattfinden. Das andere 
Problem ist, daß Du zwar wacker austeilen, aber nicht einstecken kannst, 
und mit Widerspruch, sagen wir mal, eher mäßig gut umgehen kannst.

> Blinde mit Scheuklappeen, ja ja.

Wer im Glashaus sitzt, ...

[Karl (Gast)]

Es gibt schon komische Leute hier, weil sie das Konzept von OOP nicht 
verstehen ist es Teufelszeug und als Kronzeuge dafür muss MS herhalten. 
Leute die auch mal über ihren Tellerand schauen und in OOP auch Vorteile 
erkennen werden wild beschimpft und als blöd abgestempelt. Und das 
Lamentieren über Programmgrößen und Performance ist überhaupt nicht 
nachvollziehbar. 1. Hat das nichts mit OOP zutun und 2. ist die aussage, 
dass ein leeres Fenster zuviel Speicher braucht ungefähr so wie die, 
dass ein LKW zuviel Diesel brauch und zu langsam ist, um an die Arbeit 
zu fahren.

[Sheeva P. (sheevaplug)]

W.S. schrieb:
> Karl Käfer schrieb:
>> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.
>> Merkst Du eigentlich noch was?
>
> Du bist es, der hier nichts merkt.
> Er hat ihn nämlich nicht mit einem fanatischen Gewalttäter
> gleichgesetzt. Du warst das, der ihm dies unterschieben wollte. Er hat
> stattdessen ganz konkret geschrieben "Da diskutiert es sich ja noch mit
> einem Islamisten besser".

MaWin hat dieser Interpretation jedenfalls nicht widersprochen.

> Mal im ganz rüden Klartext: Gesprächsbereitschaft setzt auch das
> Zuhörenwollen voraus, sonst ist sie nutzlos. Das schließt auch das
> sachliche Ausdiskutieren von Argumenten ein.

Das sachliche Ausdiskutieren bedingt zunächst einmal das Vorbringen 
von sachlichen Argumenten. MaWin hat zu diesem Thread bisher nur 
unbelegte Behauptungen, bösartige Unterstellungen und wüste Pöbeleien 
"beigetragen", oder kannst Du mir ein einziges sachliches oder gar 
begründetes Argument von ihm zeigen? Schon sein erster Beitrag in diesem 
Thread beinhaltet a) die unbelegte Behauptung, die Unterstützung durch 
die OOP sei eine offene Frage, b) die Unterstellung, alle Uniabsolventen 
könnten kein C++ sowie c) die unsinnige Behauptung, die MFC sei eine 
objektorientierte Bibliothek und demonstriere, wie schlecht die OOP sei.

Und das war noch sein mit Abstand harmlosestes Posting in diesem Thread, 
denn schon in seinem zweiten "Beitrag" hier mißversteht er mich 
böswillig und absichtlich und behauptet, mir mangele es an Hirn, das 
irgendjemand deswegen werfen möge. In einem ähnlichen Stil geht der 
zweite "Beitrag" dann auch gleich weiter: KFZ-Hersteller sind allesamt 
arrogant und darum nicht daran interessiert, potentiell tödliche Fehler 
an ihren Produkten zu beheben. Dann wieder gezielt und persönlich gegen 
mich: die "Analysen", von denen er keine zitieren oder verlinken kann, 
soll ich -- "weil ich es gerne will" -- "von der Hand wischen" wollen, 
und was ich "nicht will, das gibt es nicht"; ich "mache mir das Leben 
schön", lebe "in einer Traumwelt" und "im Notfall" (in welchem 
eigentlich?) "rede" ich mich "'raus".

Im dritten Beitrag ist dann Scelumbro das Ziel, der "der schlechteste 
Programmierer der Welt" sein soll, "auf den alle Anwender einen Hass 
haben". Wenn Du magst, kann ich noch seitenweise weitermachen, schlage 
jedoch vor, daß wir uns das für diesmal sparen.

Zu all dem hast Du nichts gesagt, um Karl nun mit dieser Spitzfindigkeit 
zu kommen, da sei doch gar nicht die Person, sondern nur die Diskussion 
gemeint gewesen? Ach kommm.

> Aber stattdessen sehe ich hier bösartige Unterstellungen und ne Menge
> Fanatismus.

Ja, aber die gehen allesamt von genau zwei Usern aus. Ich freue mich 
aber, daß Du in einem der beiden Fälle mittlerweile etwas gesagt hast 
und auch selbst zu einem sachlichen Umgang gefunden hast. Danke dafür.

> Sheeva P. schrieb:
>> Dennoch erscheint es mir einigermaßen widersprüchlich, wenn
>> die Anwender dieser Software sich dann einerseits über deren
>> Überfrachtung und mangelhafte Performanz beklagen, jedoch Hinweise auf
>> einfache und bereits installierte Alternativen zurückweisen.
>
> Es ist durchaus nicht widersprüchlich. Bedenke mal, daß gerade Windows
> und gerade MS Office von Milliarden von Leuten benutzt werden.

Ja, natürlich, das ist das inhärente Merkmal von Standardsoftware. Aber 
wenn Du Dir mal zum Beispiel die Apple-Software anschaust, dann erkennst 
Du schnell, warum die gerade bei solchen Leuten besonders erfolgreich 
war und ist, die mit der Technik ganz besonders wenig zu tun haben 
wollen: Grafiker, Musiker, und andere Kreative. Das liegt auch nicht 
(nur) daran, daß die Macs schön hip aussehen, sondern das war auch schon 
so, als die Macs noch genau dieselben langweiligen beigen Kisten waren 
wie die PCs.

(Um Weiterem vorzubeugen: mein letzter Mac war ein Mac II).

> Glaubst du ernsthaft, diese wären alle mental gleichgeschaltet?

Nein, wie kommst Du darauf? Habe ich das irgendwo gesagt oder auch nur 
angedeutet?

> Und die von dir angedeutete, jedoch nicht benannten Alternativen sehe
> ich nirgendwo - ganz besonders nicht "einfache und bereits installierte
> Alternativen". Was denn bitte?

Es ging dabei um ein konkretes Beispiel, in dem für den Anwendungsfall 
"Gesprächsnotizen" statt MS Wörd als "einfache und bereits installierte 
Alternative" Notepad empfohlen worden war. Da kann ich mich ziemlich gut 
dran erinnern, denn schließlich habe ich diese Story selbst erlebt und 
hier als Beispiel eingebracht.

> Ich hab vor vielen Jahren in der Firma die
> Umstellung von Wordperfect auf OpenOffice miterlebt - für EDV-Gesindel
> wie unsereins ist das kein Thema, aber die Welt besteht vorrangig aus
> Leuten, die eben nicht zum EDV-Gesindel gehören.

Auch in diesem Punkt habe ich nie etwas Gegenteiliges behauptet. Würde 
ich auch nie, schon gar nicht, weil wir im letzten Jahr von Groupwise 
auf MS Exchange und Outlook umgestellt haben, mir die Schwierigkeiten 
dabei voll bewußt und gut erinnerlich sind, und wir uns immer noch mit 
verschiedenen Nickeligkeiten als Ergebnis der Migration herumschlagen. 
Damit habe ich selbst zwar glücklicherweise nicht viel zu tun, bekomme 
es aber natürlich bei den Kollegen in den anderen Teams immer noch 
hautnah mit.

> Nun, das was du da an Klagen formulierst, ist vorrangig das Klagen eben
> dieser Leute, die sich mühsam an eine MS Office Version gewöhnt hatten
> und dann bei einer viel neueren Version erstmal ihre Menüpunkte nicht
> dort gefunden haben, wo sie bisher waren.
> Begreif das mal als ein echtes Problem.
> Es IST ein echtes Problem.

Das weiß ich alles und habe auch niemals etwas anderes gesagt, oder? 
Hier ging es aber doch gar nicht um verschiedene Versionen von MS-Office 
oder um Alternativen dazu, sondern einzig und alleine darum, daß Notepad 
für schnelle Notizen nun einmal besser geeignet ist als Wörd oder ein 
anderer Wortprozessor. Nur darum ging es, und um nichts anderes. (Ganz 
am Rande bemerkt: "Notepad" heißt übersetzt soviel wie "Notizblock", was 
IMHO sehr eindeutig darauf hinweist, wofür dieses Programm besonders 
geeignet ist.)

Wie kommst Du darauf, daß es um verschiedene Office-Versionen gegangen 
sei? Drücke ich mich wirklich so unklar aus? Mache ich zu viele Worte 
für die junge Generation Twitter, oder wo liegt das Problem?

Schau, ich verstehe sehr gut, daß Anwender nicht zwischen GUI-Monstern 
wechseln wollen, wenn sie einmal eins gelernt haben. Was ich aber nicht 
verstehe, ist, daß sie a) immer zu den fetten Profimonstern greifen, 
wenn sie die Wahl haben, und b) für Aufgaben, die mit verfügbarer, 
einfacher, kleiner und flotter Software wie Notepad gelöst werden 
könnten, trotzdem immer noch zu denselben fetten Monstern greifen.

> Vielleicht würde es dir was nützen, wenn du mal was Entsprechendes für
> DICH dir formulieren würdest, also dir vorzustellen, daß du für deinen
> Job etwas tun müßtest, was ganz und gar aus deinem eigenen Berufsbild
> heraussteht. z.B. deine Zwischenberichte bislang in Sanskrit verfassen
> und dich dann auf Hieroglyphen umstellen müssen. Oder 35 verschiedene
> wichtige Tinkturen anrühren müssen, wo du mit Mühe gelernt hast, wie die
> 167 verschiedenen Chemikalien in welcher Reihenfolge rein müssen und nun
> wird bei 42 Zutaten auf was Anderes umgestellt und alle Reihenfolgen
> sind anders, ebenso die Mengen usw. Verstehst du, was ich meine?

Mein Sanskrit ist nicht mehr so gut, und mit den Hieroglyphen hatte ich 
schon in der Schule meine Schwierigkeiten... Nein, im Ernst: wenn Du mir 
sagen willst, daß die Umstellung auf eine neue Software einen 
Lernaufwand erfordert, bin ich ganz bei Dir, wenngleich ich den 
Lernaufwand in dem oben genannten Beispiel -- also: den "Umsteig" von 
Wörd auf Notepad für einfache Notizen -- für ausgesprochen überschaubar 
halte.

> Sheeva P. schrieb:
>> Sorry, es mag ja sein, daß ich ein paar Dinge zu sehr aus der Admin- und
>> Entwicklersicht sehe.
>
> Zumindest ist die Erkenntnis dessen ein erster Schritt.

Dann wird es Dich vielleicht freuen, daß ich mir dieser Erkenntnis 
bereits seit vielen Jahren bewußt bin, sie mich allerdings trotzdem 
nicht davon abhält, mir aus meiner ganz persönlichen, professionellen 
Perspektive eine Meinung über das leider oft inkonsistente und 
irrationale Verhalten von "normalen Anwendern" zu bilden. Die "normalen 
Anwender" setze ich da mal in Anführungszeichen, weil es so etwas meiner 
Meinung nach nicht wirklich gibt; die Wahrnehmung von Anwendern als 
Individuen mit individuellen Vorstellungen, Bedürfnissen und 
Arbeitsweisen erscheint mir jedenfalls zielführender als die grobe 
Einteilung zwischen "normale" und "unnormale" Anwender. ;-)

> ich geb dir mal nen Spruch, den ich vor langer Zeit gehört und sinngemäß
> behalten habe. Es geht da zwar um das Schreiben von Manuals, aber das
> dahinterstehende Prinzip ist es, worauf es ankommt:
>
> "Schreib dein Manual so, als ob du es für einen alten Advokaten
> schreiben würdest. Der versteht von deiner Arbeit und deinem Fache
> reinweg GARNICHTS - aber deswegen solltest du ihn nicht gering schätzen.
> Er ist nämlich jemand mit einem riesengroßen Wissen und Erfahrungsschatz
> - jedoch auf allen anderen Gebieten außer eben deinem. Er hat auch einen
> rasiermesserscharfen Verstand, kann zuhören und verstehen und überhört
> dabei nichts - vorausgesetzt, du drückst dich verständlich aus. Er kann
> auch logisch denken und seine Fragen zeigen dir, wo DU ein Defizit im
> Gesagten hattest und nicht wo sein Verstand zu gering wäre."

Das ist alles schön, gut und auch sehr richtig, betrifft mich aber 
nicht. Ich entwickle keine Software für Endanwender, sondern für einen 
äußerst exklusiven Personenkreis, in welchem ich jedes einzelne Mitglied 
seit Jahren persönlich kenne. Ich habe das schon einmal geschrieben, 
aber es ist anscheinend untergegangen: mit Endanwendern wie der im 
Beispiel genannten Dame habe ich nur insoweit zu tun, als diese mich 
mögen, meine Kompetenzen schätzen (was beides auf Gegenseitigkeit 
beruht, am Rande bemerkt), und darum mit ihren Problemen erst zu mir 
kommen, bevor sie unsere Windows-Techniker fragen.

Meine eigentlichen Aufgaben liegen eher in einem Bereich, der neudeutsch 
als "Big Data", "Data Mining" und "Data Science" bezeichnet wird: 
Analyse, Exploration, Visualisierung von Daten, Distributed Computing, 
Skalier- und Hochverfügbarkeit, Echtzeit-Streaming, solche Dinge. Ich 
entwickle keine Anwendersoftware und betreue weder Anwender noch 
Anwendersoftware. Die einzigen armen Leute, die mit meiner Software 
arbeiten müssen, sind meine Mitarbeiter und Kollegen sowie ich selbst, 
und wir alle kommen mit meiner Software erstaunlich gut zurecht.

Insofern ist MaWins Unterstellung, ich würde Anwender mit aufgeblähten 
OO-Programmen nerven, selbst jedoch eher schnelle PP-Software nutzen, 
ganz flashc. Im Moment benutze ich hauptsächlich Apache Spark, Apache 
Storm und ein paar andere Werkzeuge aus dem Hadoop-Universum, die samt 
und sonders objektorientiert sind, und die von mir verwendete 
GUI-Software wurde mit Ausnahme des GNU/Emacs ebenfalls objektorientiert 
entwickelt. Trotzdem bin und bleibe ich ein Kommandozeilenjunkie, und 
ja, tatsächlich, da sind die meisten Werkzeuge PP-orientiert, 
vornehmlich wohl deswegen, weil die OO zu jener Zeit, als sie entstanden 
sind, noch in den Kinderschuhen steckte.

[Karl (Gast)]

Sheeva P. schrieb:
> Trotzdem bin und bleibe ich ein Kommandozeilenjunkie, und
> ja, tatsächlich, da sind die meisten Werkzeuge PP-orientiert,
> vornehmlich wohl deswegen, weil die OO zu jener Zeit, als sie entstanden
> sind, noch in den Kinderschuhen steckte.

Neben dem Alter würde ich mal behaupten, dass viele 
Kommandozeilenprogramme vom Umfang her auch nicht wirklich eine OOP 
brauchen. Die meisten Programme beschränken sich ja auf einen Input, 
einen Output und ein paar Parameter, die noch übergeben werden. 
Klassisches EVA-Prinzip halt.

[Karl Käfer (Gast)]

W.S. schrieb:
> Karl Käfer schrieb:
>> Jetzt setzt Du ihn sogar schon mit einem fanatischen Gewalttäter gleich.
>> Merkst Du eigentlich noch was?
>
> Stop mal, mein Junge!
>
> Du bist es, der hier nichts merkt.
> Er hat ihn nämlich nicht mit einem fanatischen Gewalttäter
> gleichgesetzt.

Meine Interpretation hat MaWin doch mittlerweile selbst bestätigt und 
sogar geschrieben er sei schlimmer. Das war übrigens noch bevor Du 
Deinen Beitrag gepostet hast. Vielleicht merk ich mehr als Du denkst? ;)

[MaWin (Gast)]

Sheeva P. schrieb:
> Die MFC krankt seit jeher unter mehreren Problemen: daß sie nur ein
> OO-Schnittstelle zu einer nicht-OO-API

Du kennst dich wohl nicht so aus, denn das WinAPI ist eine sehr gute 
Implementation eines OO-Designs in normalem C. Objekte werden durch 
Handles abgebildet, was self Pointer in das Datensegment des 
Betriebssystems waren, in denen die Instanzvariablen der Objekte z.B. 
vom GDI (HBRUSH HPEN etc.) private als struct aufbewahrt wurden, Klassen 
sind abgeleitet, man kann HINSTANCE an Stelle von HMODULEs verwenden 
etc. und Fensterklassen um Unterklassen erweitern, DefWndProc.
Daß nicht alle Dinge von einem gemeinsamen Grundobjekt abgeleitet 
wurden, ist bei C++ ja auch nicht anders. Ein int ist auch dort keine 
class.

Weitere von dir abgeleitet Schlussfolgerungen sind damit genau so 
falsch.

Sheeva P. schrieb:
> Nachgerade ist es daher keine gute Idee, ausgerechnet die MFC als
> Beispiel für die Stärken oder Schwächen der OO zu betrachten;

Natürlich aus deiner Sicht nicht, weil es vor allem Schwächen zeigt. 
Allerdings sind sher viele Programme damit geschrieben, es halt also 
sher wohl einen erklecklicher Anteil an der Realität der OO Software.

> Ich kann nicht für Stefan K. sprechen, aber soweit es mich betrifft, bin
> ich jedenfalls nicht er.

Er verweist jedoch auf unter Sheeva Plug geschriebene Artikel und 
behauptet das wären seine Argumente.

Sheeva P. schrieb:
> MaWin hat dieser Interpretation jedenfalls nicht widersprochen.

Du glaust offenbar alle Behauptungen die du aufstellst seinen Wahr so 
lange ihnen niemand widerspricht und ziehst Diskussionen daher so lange 
durch bis dir genervt niemand mehr widerspricht. Funktionierte 
vielleicht  bei deiner Mama, im echten Leben eher nicht.


Es gibt sehr viel Software.
Ein guter Teil davon ist inzwischen mit OO Techniken geschrieben.
Es gibt sehr viel schlechte Software.
Viele der Software ist schlecht trotz der OO Techniken.
Die Frage wäre, ob Software 'dank' OO besser oder schlechter geworden 
ist.
Eine richtige statistische Auswertung gibt es dazu nicht.
Aber die Annahme, es wäre durch OO besser geworden, darf stark 
angezweifelt werden.
Das tue ich, und begründe es, unter anderem weil man in C++ an vielen 
Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext 
kein einziges Zeichen steht. Das führt meiner Erfahrung nach zu 
schlechter Wartbarkeit und dazu daß Programmierer den Überblick 
verlieren wie aufwändig die Sachen sind die sie machen, also langsame 
Bloatware erzeugen. Gegenargumente kamen keine. Demnach stimmt es also, 
nach deiner Weltsicht.


Du ziehst über GalBast her.
Dieses (winzige) Programm jedoch besser zu machen bringst du nicht, 
stattdessen investierst du ein mehrfaches an Mühe hier deine 
Desinformationen zu erarbeiten.
Es ist das typische Asi-Verhalten von Selbstüberheblichen wie dir.

[nicht"Gast" (Gast)]

MaWin schrieb:
> Das tue ich, und begründe es, unter anderem weil man in C++ an vielen
> Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext
> kein einziges Zeichen steht.

Das must du mal genauer Erklären. Was soll denn ausgeführt werden, was 
nicht im Quelltext steht? Du meinst jetzt aber nicht so trivialkram wie 
ctor und dtor, oder doch?

[Borislav B. (boris_b)]

MaWin schrieb:
> Es ist das typische Asi-Verhalten von Selbstüberheblichen wie dir.

Das sagt bereits alles. Typen wie MaWin kann/darf/sollte man nicht ernst 
nehmen...

[Karl (Gast)]

MaWin schrieb:
> Es gibt sehr viel Software.
> Ein guter Teil davon ist inzwischen mit OO Techniken geschrieben.
> Es gibt sehr viel schlechte Software.
> Viele der Software ist schlecht trotz der OO Techniken.
> Die Frage wäre, ob Software 'dank' OO besser oder schlechter geworden
> ist.

Was ist den das für eine Argumentationstechnik?

> Es gibt sehr viel Software.
> Ein guter Teil davon ist ohne OO Techniken geschrieben.
> Es gibt sehr viel schlechte Software.
> Viele der Software ist schlecht trotz des Verzichts auf OO Techniken.
> Die Frage wäre, ob Software 'dank' Verzicht auf OO besser oder schlechter
> ist.

Hast du sonst noch Argumente? Wie wäre es damit:

You Can Write FORTRAN in any Language

MaWin schrieb:
> Aber die Annahme, es wäre durch OO besser geworden, darf stark
> angezweifelt werden.

Genauso wie die Annahme, dass Software ohne OO besser wäre.

MaWin schrieb:
> Das tue ich, und begründe es, unter anderem weil man in C++ an vielen
> Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext
> kein einziges Zeichen steht.

C++ != OO. Das gleiche Argument gilt für jeden anderen Quelltext, in den 
man externe Bibliotheken einbindet.

[MaWin (Gast)]

Karl schrieb:
> Das gleiche Argument gilt für jeden anderen Quelltext, in den
> man externe Bibliotheken einbindet.

Das ist falsch, du hast es offenbar nicht verstanden.

Wenn man eine externe Bibliothek einbindet, passiert dadurch zunächst 
einmal nichts.

Damit etwas passiert, muss man die exportierten Funktionen dieser 
Bibliothek aufrufen.

Dazu muss man in den üblichen prozeduralen Programmiersprachen etwas 
hinschreiben, eineen Funktionsaufruf.

Dann und nur dann passiert hier und nur genau hier etwas, eine Aktion 
durch die externe aufgerufene Funktion.

Das sieht man schon beim Ansehen des Quelltextes, und kann nachforschen, 
z.B. welche Seiteneffekte sie hat.

> C++ != OO.

Kann man so verstehen daß C++ nicht die reine Lehre des OO 
widerspiegelt.

Oder daß C++ sowieso keine OO Sprache wäre.

Du wirst dieses hingerotze != also interpretieren wie es dir gerade in 
den Kram passt.

[Karl (Gast)]

MaWin schrieb:
> Dazu muss man in den üblichen prozeduralen Programmiersprachen etwas
> hinschreiben, eineen Funktionsaufruf.
>
> Dann und nur dann passiert hier und nur genau hier etwas, eine Aktion
> durch die externe aufgerufene Funktion.

Aha, und bei OO passiert einfach so etwas, ohne das man etwas 
hinschreibt? Kannst du mal ein Beispiel nennen, was du dir da 
vorstellst?

MaWin schrieb:
>> C++ != OO.
>
> Kann man so verstehen daß C++ nicht die reine Lehre des OO
> widerspiegelt.
>
> Oder daß C++ sowieso keine OO Sprache wäre.
>
> Du wirst dieses hingerotze != also interpretieren wie es dir gerade in
> den Kram passt

Nein, das brauche ich nicht. Ich habe dir nur gezeigt, dass deine 
Argumentation nichts mit OO zutun hat sondern mit der Programmiersprache 
C++. Ich könnte genauso behaupten, dass Prozedurale Programmierung 
schlecht ist, weil C zu Speicherüberläufen führt. Hat bloß nichts 
miteinander zu tun.

[bla bla (Gast)]

Christian M. schrieb:
> ich bin im JS-Kurs jetzt bei den Objekten angelangt. Aber mir
> erschliesst sich der Sinn eines solch abstrakten Gebildes absolut nicht.
> Kann mir einer verklickern, wofür das gut sein soll?

Wenn Du damit schon so Probleme hat, wird Dich funktionale 
Programmierung in den Selbstmord treiben.

[MaWin (Gast)]

Karl schrieb:
> Ich habe dir nur gezeigt, dass deine Argumentation nichts mit OO
> zutun hat sondern mit der Programmiersprache C++.

Du hast gar nichts gezeigt, sondern bloss ein C++ != OO hingerotzt,
mit dem du behauptest alles gesagt zu haben. Na dann, shut up.

[Karl (Gast)]

Du hast geschrieben:

MaWin schrieb:
> Aber die Annahme, es wäre durch OO besser geworden, darf stark
> angezweifelt werden.
> Das tue ich, und begründe es, unter anderem weil man in C++ an vielen
> Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext
> kein einziges Zeichen steht.

Worauf ich antwortete:

Karl schrieb:
> C++ != OO. Das gleiche Argument gilt für jeden anderen Quelltext, ...

Deine Argumentation mit C++ gegen OO macht immer noch keinen Sinn. 
Schade das du es nicht erkennst.

Karl schrieb:
>> Dann und nur dann passiert hier und nur genau hier etwas, eine Aktion
>> durch die externe aufgerufene Funktion.
>
> Aha, und bei OO passiert einfach so etwas, ohne das man etwas
> hinschreibt? Kannst du mal ein Beispiel nennen, was du dir da
> vorstellst?

Ich würde mich über ein Beispiel freuen!

MaWin schrieb:
> Du hast gar nichts gezeigt, sondern bloss ein C++ != OO hingerotzt,
> mit dem du behauptest alles gesagt zu haben. Na dann, shut up.

Genau C++ ist nicht Objektorientierte Programierung oder kurz C++ != OO. 
Als jemand der sich mit Programierung beschäftigt, solltest du das doch 
verstehen. Eine Interpretation, wie von dir gefordert, ist bei einer 
Ungleichung nicht notwendig. Hinrotzen geht im Internet auch nicht, da 
wurde noch keine App für erfunden, das Verb heißt schreiben.

[Kupferstecher (Gast)]

Streitet euch doch nicht. Das Thema kann man doch ganz sachlich 
diskutieren...


MaWin schrieb:
> [...], denn das WinAPI ist eine sehr gute
> Implementation eines OO-Designs in normalem C. Objekte werden durch
> Handles abgebildet, was self Pointer in das Datensegment des
> Betriebssystems waren, in denen die Instanzvariablen der Objekte z.B.
> vom GDI (HBRUSH HPEN etc.) private als struct aufbewahrt wurden, Klassen
> sind abgeleitet, man kann HINSTANCE an Stelle von HMODULEs verwenden
> etc. und Fensterklassen um Unterklassen erweitern, DefWndProc.
Hier stellt sich die Frage, ob die Api eines graphischen Betriebssystems 
nicht zwangsläufig objektorientiert aufgebaut sein muss, um für 
Anwendungsprogramme (-programmierer) überhaupt ordentlich nutzbar zu 
sein. Dass man die Techniken dann auch sprachlich verfügbar macht 
(Klassen, Vererbung) ist dann eine logische Konzequenz (und 
Verbesserung).

Ein (weiterer) großer Vorteil der OOP, den ich insbesondere im 
Zusammenhang mit Grafikprogrammierung sehe, ist, dass man selbst bei 
dynamisch erzeugten Objekten auf Pointer verzichten kann (gilt wohl 
nicht für C++). Allein das macht einem das Leben schon deutlich 
einfacher, auch wenn die Probleme mit falschen Referenzen die gleichen 
sind.

[Sheeva P. (sheevaplug)]

MaWin schrieb:
> Sheeva P. schrieb:
>> Die MFC krankt seit jeher unter mehreren Problemen: daß sie nur ein
>> OO-Schnittstelle zu einer nicht-OO-API
>
> Du kennst dich wohl nicht so aus,

Das stimmt. Windows, die Windows-API und die MFC habe ich mir das letze 
Mal vor rund zwanzig Jahren angeschaut und bin dann schnell 
davongelaufen. Sorry, das ist nicht meine Welt: in a world without walls 
and fences, who needs windows and gates?

> denn das WinAPI ist eine sehr gute Implementation eines OO-Designs in
> normalem C.

Ach, die einen sagen so, die anderen anders. Was OO ist und was nicht, 
da halte ich mich -- wie Du meiner Konversation oben mit dem klugen 
Daniel Abrecht entnehmen kannst -- streng an den Erfinder der OO, Alan 
Kay. Nach diesem Maßstab ist die Windows API nicht objektorientiert, 
aber wenn Du magst, kannst Du das natürlich gerne anders sehen.

> Objekte werden durch Handles abgebildet,

Wenn ich mich recht entsinne, durch Void-Pointer... How to accidentally 
shoot yourself six times in the foot.

> Daß nicht alle Dinge von einem gemeinsamen Grundobjekt abgeleitet
> wurden, ist bei C++ ja auch nicht anders. Ein int ist auch dort keine
> class.

Ja, äh... und? In manchen OO-Sprachen gibt es eine Klasse Integer, in 
Java zum Beispiel -- trotzdem gibt es auch in Java noch einen nativen 
Datentyp int. In Python gibt es old-style Klassen, die nicht von 
_builtin_.object erben, und new-style Klassen, die das tun; das fällt 
einem immer dann auf, wenn man von einer Tkinter-Klasse (old-style) 
erben will und die Methoden der Elternklasse nicht mit "super()" 
aufrufen kann. C++ ist aber nur eine Implementierung der OO -- manche 
sagen sogar, keine besonders gelungene -- und nicht der Maßstab für OO.

> Sheeva P. schrieb:
>> Nachgerade ist es daher keine gute Idee, ausgerechnet die MFC als
>> Beispiel für die Stärken oder Schwächen der OO zu betrachten;
>
> Natürlich aus deiner Sicht nicht, weil es vor allem Schwächen zeigt.

Aus meiner Sicht zeigt die MFC nur, daß man auch mit OO beschissene APIs 
designen kann. Überraschung, wer hätte das gedacht?! Und, noch 
wichtiger: wer hätte das jemals bestritten? Ich jedenfalls nicht. Das 
ändert aber nicht das Geringste daran, daß man mit C++ auch sehr 
elegante und saubere APIs designen und implementieren kann, think Qt.

Aber wenn Du eine wirklich vollkommen verkackte API sehen willst, dann 
schau Dir doch spaßeshalber einfach mal OpenSSL an. Völlig prozedural, 
komplett ohne OO, und trotzdem total, absolut, und auf ganzer Linie 
komplett verkackt. Verglichen damit ist sogar die MFC ein Wunderwerk 
technischer Eleganz und genialer Implementierung!

Aber käme ich jetzt auf die Idee, deswegen die PP zu verdammen und das, 
was Du über die OO behauptest, andersherum über die PP sagen? Natürlich 
nicht. Und wenn doch, würdest Du mich zurecht genauso auslachen wie ich 
das gerade umgekehrt mache.

> Allerdings sind sher viele Programme damit geschrieben, es halt also
> sher wohl einen erklecklicher Anteil an der Realität der OO Software.

Aber -- und das ist der kleine, feine Unterschied -- nicht an der OO.

Deine Strategie ist es, Dir eine beschissene OO-Implementierung heraus 
zu suchen, darauf herumzuhacken, wie beschissen sie ist, und das dann 
auf die OO zu schieben. Ich habe einige andere OO-Implementierungen 
genannt: Qt, WxWidgets, die Boost-Bibliotheken, .NjET und die STL. Mein 
Argument dabei ist, daß es offensichtlich möglich ist, saubere, 
verständliche OO-Designs und -Implementierungen zu entwickeln. Geh' doch 
einfach mal auf dieses Argument ein, oder paßt Dir das nicht in den 
Kram?

>> Ich kann nicht für Stefan K. sprechen, aber soweit es mich betrifft, bin
>> ich jedenfalls nicht er.
>
> Er verweist jedoch auf unter Sheeva Plug geschriebene Artikel und
> behauptet das wären seine Argumente.

Nein, er sagt, das seien meine Argumente. Bitte lern lesen, das würde 
die Diskussion wirklich ganz enorm vereinfachen.

> Sheeva P. schrieb:
>> MaWin hat dieser Interpretation jedenfalls nicht widersprochen.
>
> Du glaust offenbar alle Behauptungen die du aufstellst seinen Wahr

Aus meiner (natürlich subjektiven) Sicht sind meine Aussagen wahr, sonst 
würde ich sie ja nicht äußern. Es ist Dir unbenommen, eine andere Sicht 
zu haben und natürlich ebenso, diese zu äußern. Wenn Du sie dann auch 
noch sachlich und idealerweise sogar ohne Verbalinjurien begründen 
kannst, dann -- aber nur dann -- schaffst Du es vielleicht sogar, mich 
von Deiner Sicht zu überzeugen. Probier es doch einfach mal. Ich bin ein 
vernunftbegabter Mensch (ok, meistens jedenfalls), und gegenüber 
sachlichen, schlüssigen, logisch konsistenten und begründeten Ideen 
(fast) immer aufgeschlossen.

> so lange ihnen niemand widerspricht

Papperlapapp: Du hast Deine Aussage ja sogar noch einmal bekräftigt, 
indem Du Dich zu der absurden Beleidigung verstiegen hast, ich sei sogar 
noch schlimmer als ein fanatischer Gewalttäter.

> und ziehst Diskussionen daher so lange
> durch bis dir genervt niemand mehr widerspricht. Funktionierte
> vielleicht  bei deiner Mama, im echten Leben eher nicht.

Bei Deiner Mama hat es jedenfalls prima geklappt. ;-)

> Es gibt sehr viel Software.

Richtig, danke für den Hinweis.

> Ein guter Teil davon ist inzwischen mit OO Techniken geschrieben.

Ebenfalls richtig, danke nochmals.

> Es gibt sehr viel schlechte Software.

Wiederum richtig, aber ebenfalls keine Überraschung.

> Viele der Software ist schlecht trotz der OO Techniken.

Und noch einmal richtig, langsam wirst Du mir unheimlich.

> Die Frage wäre, ob Software 'dank' OO besser oder schlechter geworden
> ist.

Das mag Deine Frage sein. Meine erste Frage ist allerdings, ob sich 
durch die OO überhaupt etwas an der Softwarequalität geändert hat, und 
erst die zweite Frage ist dann für mich, ob zum Guten oder zum 
Schlechten.

> Eine richtige statistische Auswertung gibt es dazu nicht.

Die dürfte auch ziemlich schwierig werden, schließlich fällt mir auf 
Anhieb ein gutes Dutzend an Qualitätsmerkmalen für Software ein. Und 
selbst wenn wir uns auf bestimmte Kriterien einigen könnten, bleibt da 
immer noch die Frage der Gewichtung.

> Aber die Annahme, es wäre durch OO besser geworden, darf stark
> angezweifelt werden.

Natürlich. Ebenso darf aber auch die Annahme bezweifelt werden, daß es 
durch die OO schlechter geworden sei.

Meine ganz persönliche Meinung dazu ist allerdings, daß sich in Wahrheit 
überhaupt gar nichts geändert hat. Es gibt qualitativ minderwertige OO- 
und ebenso minderwertige PP- und FP-Software, es gibt hochwertige OO- 
und ebenso hochwertige PP- und FP-Software.

Überraschung: Software wird immer noch von Menschen gemacht! Von 
Menschen, die ihre Werkzeuge mal mehr, mal weniger gut beherrschen. Gute 
Entwickler entwickeln daher gute, schlechte Entwickler schlechte 
Software. Solange das der Fall ist, wird es gute und schlechte Software 
geben, und daran können und werden Programmierparadigmen leider auch 
nichts ändern.

> Das tue ich, und begründe es, unter anderem weil man in C++ an vielen
> Stellen nicht mehr sieht was an Aktionen abläuft, weil dazu im Quelltext
> kein einziges Zeichen steht.

Abgesehen davon, daß OO nicht C++ und C++ nicht OO ist -- man kann in 
C++ problemlos auch prozedural und funktional entwickeln -- scheinst Du 
da ein anderes C++ zu kennen als ich. Kannst Du mir bitte ein konkretes 
Beispiel aufzeigen, idealerweise in Code, was genau Du meinst? Danke.

[Karl (Gast)]

Sheeva P. schrieb:
> Kannst Du mir bitte ein konkretes
> Beispiel aufzeigen, idealerweise in Code, was genau Du meinst? Danke.

Habe ich auch schon gefragt. Außer heiße Luft ist da aber nichts zu 
erwarten. Auch der Hinweis, dass C++ nicht OOP ist hat ihn ehr verwirrt, 
als einsichtig gemacht.

[Dr. Honigtau Bunsenbrenner (Gast)]

Beaker schrieb im Beitrag #4638054:
> Mimi mimi miiiiii
> Mimi mimi miiiiii

Beaker, meine Lieber! Dass ich Dich wiedergefunden habe! So eine Freude.
https://www.youtube.com/watch?v=g0b6J5O2UdI

[W.S. (Gast)]

Kupferstecher schrieb:
> Hier stellt sich die Frage, ob die Api eines graphischen Betriebssystems
> nicht zwangsläufig objektorientiert aufgebaut sein muss, um für
> Anwendungsprogramme (-programmierer) überhaupt ordentlich nutzbar zu
> sein.

Schon wieder solche Behauptungen, die von purer Ahnungslosigkeit zeugen.

Also: Das API von Windows ist definitiv prozedural und NICHT 
objektorientiert. Angesichts von Bezeichnungen wie "Windowsklassen" 
sollte man sich nicht verleiten lassen, auch das API des OS als OO 
anzunehmen.

Wer sich mal ein objektorientiertes OS anschauen will, sollte über 
EPOC-OS bzw. Symbian-OS nachlesen. Das war - nebenbei gesagt - eine 
echte Spaßbremse für Anwendungs-Programmierer, weil als 
Programmiersprache einzig C++ benutzbar war, weswegen es kaum 
Anwendungen für diesen Zweig der Betriebssysteme gab.

Das, was hier vermutlich gemeint worden ist, ist nicht 
"objektorientiert", sondern "ereignisgesteuert". Ist ein Unterschied!

W.S.

[Beaker (Gast)]

https://www.youtube.com/watch?v=_goMQolXcbs

Erinnert mich Stellenweise an an "Memory" aus Cats

[Kupferstecher (Gast)]

W.S. schrieb:
> Also: Das API von Windows ist definitiv prozedural und _NICHT_
> objektorientiert. Angesichts von Bezeichnungen wie "Windowsklassen"
> sollte man sich nicht verleiten lassen, auch das API des OS als OO
> anzunehmen.
>
> Das, was hier vermutlich gemeint worden ist, ist nicht
> "objektorientiert", sondern "ereignisgesteuert". Ist ein Unterschied!
Das, was hier gemeint worden ist, ist objektorientiert!
- Die Zugriffe über Handles stellen die Objektreferezen dar.
- Allein das Arbeiten mit Structs/Records ist schon eine Vorstufe zur 
Objektorientierung.
- Die Kapselung der Funktionen zum Betriebssystem.
Das sind alles Konzepte aus der Objektorientierung. Oder anders rum, die 
Objektorientierung benutzt genau diese Konzepte. Die OOP ist ja nicht 
zufällig entstanden.

[Sheeva P. (sheevaplug)]

Karl schrieb:
> Sheeva P. schrieb:
>> Kannst Du mir bitte ein konkretes
>> Beispiel aufzeigen, idealerweise in Code, was genau Du meinst? Danke.
>
> Habe ich auch schon gefragt. Außer heiße Luft ist da aber nichts zu
> erwarten. Auch der Hinweis, dass C++ nicht OOP ist hat ihn ehr verwirrt,
> als einsichtig gemacht.

Willst Du wohl bitte aufhören, weiteres Öl ins Feuer zu gießen!? Danke.

[chris_ (Gast)]

Meiner Meinung nach haben sich die Programmiersprachen immer in 
bestimmten Kontexten entwickelt.
OOP hat sich mit der Einführung der graphischen Benutzeroberflächen 
entwickelt, dort kann man die "Objekte" ja auch richtig sehen. Es macht 
ziemlich viel Sinn, die Eigenschaften von graphischen Elementen zu 
vererben und diese zu erweitern. Eine "reichhaltige" graphische 
Oberfläche in Assembler zu programmieren, wäre wohl ziemlich mühselig.
Dass man OOP Konzepte später für alles Mögliche wie Treiber oder 
ähnliches verwenden kann, betrachte ich eher als einen Seiteneffekt.

Lisp dagegen hat sich im Umfeld der künstlichen Intelligenz Forschung 
entwickelt und ist für deren Probleme eher geeignet.

[chris_ (Gast)]

Hier noch was passendes:
http://www.heise.de/developer/artikel/Vererbung-fuer-Objekte-nuetzlich-fuer-Werte-gefaehrlich-3254433.html

[Yalu X. (yalu) (Moderator)]

chris_ schrieb:
> Hier noch was passendes:
> 
http://www.heise.de/developer/artikel/Vererbung-fuer-Objekte-nuetzlich-fuer-Werte-gefaehrlich-3254433.html

Guter Artikel!

Und endlich mal wieder etwas Substanzielles in dieser Diskussion, in der
leider die guten Beiträge in dem von einigen wenigen Ahnungslosen
verursachten Dauerlärm untergehen.

Der Artikel zeigt anhand eines Beispiels, wie OOP falsch angewendet
werden kann bzw. wo die Grenzen gewisser Konzepte (in diesem Fall der
Implementierungsvererbung) liegen.

Man kann jetzt natürlich wie ein Rohrspatz über OOP schelten, weil sie
nicht idiotensicher ist. Aber das wäre so, als lehne man Autos ab, weil
beim Autofahren mehr Fehler passieren können als beim Zufußgehen.

Was die Implementierungsvererbung betrifft, ist sich ja sogar James
Gosling, der Entwickler von Java, nicht mehr ganz sicher, ob das ein
gutes Konzept ist:

  http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html

... someone asked him [James Gosling]: "If you could do Java over again,
what would you change?" "I'd leave out classes," he replied. ... he
explained that the real problem wasn't classes per se, but rather
implementation inheritance (the extends relationship). Interface
inheritance (the implements relationship) is preferable. You should
avoid implementation inheritance whenever possible.

[Heiner K. (heinerkuhlmann)]

> Und endlich mal wieder etwas Substanzielles in dieser Diskussion, in der
> leider die guten Beiträge in dem von einigen wenigen Ahnungslosen
> verursachten Dauerlärm untergehen.

Unterstrichen Punkt

OOP heisst Objekt-Orientierte-Programmierung und nicht 
Objekt-Orgien-Programmierung. Soll heissen, wir sollten vorsichtig mit 
dem bereitgestellten Modell und seinen Konzepten umgehen und es nicht 
vergewaltigen (nach dem Motto: Vererb Dich oder ich beiß Dich).

Andererseits ist OOP und vor allem das Konzept der Kapselung sehr stark. 
Wir können und sollten es auch in Nicht-OOP-Sprachen anwenden.

Problematisch wird bei O-Orgien-Programmierung die Klassenstruktur.

Aus der Sicht des Programmierens im Kleinen mag eine Klassenstruktur 
noch sinnvoll erscheinen, obwohl Vererbung viel zu oft anstelle von 
Komposition benutzt wird.

Sieht man sich OO Programme im Grossen an, sieht es oft aus wie 
Spaghetti.

Ein solcher Code ist nur sehr schwer zu pflegen. Die Verheissungen der 
Wiederverwendbarkeit haben sich geradezu als Fluch erwiesen. Das Problem 
liegt nicht in der Wiederverwendung selbst sondern in unüberlegter 
Verwendung von Klassen aus fremdem Kontexten.

Es ist unerlässlich, Bereiche abzugrenzen, geradezu Feuerwände 
einzuziehen, die es nicht erlauben, Klassen aus anderen Bereichen 
unbesehen zu verwenden.

In diesem Sinne wird Software von Architekten erstellt. Den Code 
erstellen Programmier-Maurer. Einfamilienhäuser können Maurer (Meister) 
erstellen, Hochhäuser Architekten.

Beispiele: die Elbphilharmonie und der Kölner Dom ;-)


Hier kann ich diese Frage stellen:

Wer würde einen Informatiker mit je einem Wochen-Kurs in Pspice und 
Eagle, Hardware entwickeln lassen?

[(prx) A. K. (prx)]

Heiner K. schrieb:
> Hier kann ich diese Frage stellen:

Ja, gewissermaßen ...

> Wer würde einen Informatiker mit je einem Wochen-Kurs in Pspice und
> Eagle, Hardware entwickeln lassen?

... denn umgekehrt sehen das viele hier als selbstverständlich an. ;-)

[Heiner K. (heinerkuhlmann)]

Christian M. schrieb:

> Unlogisch ist es auch: Das Objekt hat Methoden, die z.B. den String
> manipulieren, aber wofür ist denn das Math.-Objekt? Da sollte doch die
> Zahl das Objekt sein...?!
>
> Intern wird es ja eh prozedural verarbeitet.
>
> Bin ich zu alt?

Nein.

Einen String kann man gut als Objekt oder Klasse verstehen. Er wird mit 
Methoden manipuliert, dabei ändert sich sein Inhalt, Zustand (meistens).
Richtig Sinn macht es erst, wenn ein Bild im Browser betrachtet wird. Es 
kann verschoben, verkleinert, gedreht usw. werden. UND man kann leicht 
ein Bild mit Rahmen daraus machen.

Eine mathematische Bibliothek stellt eine Reihe von Funktionen bereit.
Die Bibliothek hat keinen Zustand. Man kann die Bibliothek allerdings 
auf verschiedene Typen (Genauigkeit usw) anwenden. In OO Sprachen ist 
man gezwungen, daraus eine Klasse zu machen.

Javascript ist eine OO-Sprache im Sinne des zweiten Os: Orientierung:
Javascript erlaubt es, OO zu Programmieren, zwingt aber nicht dazu.
OO ist vielmehr übergestülpt worden. Klassen sehen wie Funktionen aus. 
Das kann schon verwirren.

Ich empfehle sich zunächst mit dem Konzept von OOP vertraut zu machen. 
Leider geht das nicht mal eben auf einer Seite.

Zunächst würde ich darauf in Javascript zu verzichten. Später finden 
sich dann sinnvolle Anwendungen.

Mir sind die häufigen Abfragen nach dem Browser ein Dorn im Auge.
Das ist ein typischer Fall, wo Polymorphismen prozedural aufgelöst 
werden.
Anscheinend ist nicht leicht, OOP sinnvoll anzuwenden.

Christian, wenn Du später diese Aussage verstehst, solltest Du mit OO 
anfangen.

[Yalu X. (yalu) (Moderator)]

Heiner K. schrieb:
> Eine mathematische Bibliothek stellt eine Reihe von Funktionen bereit.
> Die Bibliothek hat keinen Zustand. Man kann die Bibliothek allerdings
> auf verschiedene Typen (Genauigkeit usw) anwenden. In OO Sprachen ist
> man gezwungen, daraus eine Klasse zu machen.

Es wurde ja weiter oben in diesem Thread schon geschrieben, dass das
Math-Objekt ein Weg ist, mehrere Symbole (Funktionen und Konstanten) in
einem Namensraum zusammenzufassen. In C++ gibt es zu diesem Zweck
Namespaces, in Java und Python Module.

Da es in Javascript weder Namespaces noch Module gibt, könnte man auf
die Idee kommen, stattdessen eine Klasse mit lauter static-Elementen
anzulegen, die im Wesentlichen denselben Zweck erfüllt.

Da es in Javascript aber auch keine Klassen gibt, wird dort stattdessen
ein Objekt verwendet.

> Javascript ist eine OO-Sprache im Sinne des zweiten Os: Orientierung:
> Javascript erlaubt es, OO zu Programmieren, zwingt aber nicht dazu.
> OO ist vielmehr übergestülpt worden. Klassen sehen wie Funktionen aus.
> Das kann schon verwirren.

Die (nichtexistenten) Klassen in Javascript werden durch ihren
Konstruktor repräsentiert, der seinerseits natürlich eine Funktion ist.
Das ist an sich nicht schlimm, aber für Leute, die von Java, C++ oder
Delphi kommen, ungewohnt. Um diesen Leuten entgegenzukommen, gibt es in
Javascript inzwischen eine syntaktisch an Java und C++ angelehnte
Klassendeklaration der Form

class MyClass {
  constructor(x) { ... }
  methode1(x, y) { ... }
  ...
}

Echte Klassen gibt es deswegen aber immer noch nicht, denn diese
Klassendeklaration ist nur syntaktischer Zucker. Unter der Decke ist
MyClass nach wie vor eine Funktion, was man leicht mit

typeof(MyClass)   ——>   function

feststellen kann.

Heiner K. schrieb:
> Zunächst würde ich darauf in Javascript zu verzichten.

Das kommt darauf an: Man lernt ja OOP meist nicht als reine Philosophie
losgelöst von jeglicher Anwendung, sondern um danach in einer konkreten
Sprache programmieren zu können. Das kann Java oder C++ sein für
PC-Anwendungen oder eben Javascript, falls das Interesse eher in
Client-Side-Internet-Anwendungen liegt. IMHO lernt man mit Java oder C++
nicht "besser" OOP als in Javascript.

Nur wenn man wirklich tiefer in die "Philosophie" der Objektorientierung
vorstoßen möchte, sollte man sich eher mit einer reinen OOP-Sprache, wie
bspw. Ruby oder Scala beschäftigen (Smalltalk lasse ich mal auf Grund
des hohen Alters außen vor). Diese Sprachen zwingen einen regelrecht,
alles in Klassen zu packen, was einem auch eine gute Chance gibt, die
Grenzen der OOP zu erkennen.

[Daniel A. (daniel-a)]

Yalu X. schrieb:
> Echte Klassen gibt es deswegen aber immer noch nicht, denn diese
> Klassendeklaration ist nur syntaktischer Zucker. Unter der Decke ist
> MyClass nach wie vor eine Funktion, was man leicht mit
>
> typeof(MyClass)   ——>   function
>
> feststellen kann.

Das dachte ich lange auch. Dann musste ich feststellen, das damit 
auchnoch eine Überprüfung eingebaut wurde, ob man es mit new aufgerufen 
hat. Dass muss sein, weil super eingefürt wurde, welches kurzform für 
new.target.prototype.constructor ist, wobei new.target nur gesetzt ist, 
wenn mit new aufgerufen. Ich würde gerne solche Dinge tun:

function ProxifyEarly(constructor,handler,...args){
  var o = Object.create(constructor.prototype);
  var p = new Proxy(o,handler);
  return constructor.apply(p,...args) || o;
}

function MyClass1(){}
ProxifyEarly(MyClass1,{}); // ok

class MyClass2{}
ProxifyEarly(MyClass2,{}); // TypeError: class constructors must be invoked with |new|

Man hätte new.target und super auch anders auflösen können, aber so wie 
es jetzt ist, ist es ein unlösbares Problem. Dabei hätte ich so tolle 
Anwendungsmöglichkeiten dafür gehabt, wenn ich schon das this im 
constructor vor dessen aufruf in einen Proxy hätte packen können...

[Yalu X. (yalu) (Moderator)]

Heiner K. schrieb:
> OOP heisst Objekt-Orientierte-Programmierung und nicht
> Objekt-Orgien-Programmierung. Soll heissen, wir sollten vorsichtig mit
> dem bereitgestellten Modell und seinen Konzepten umgehen und es nicht
> vergewaltigen (nach dem Motto: Vererb Dich oder ich beiß Dich).

Vollkommen richtig.

Leider wird in vielen Lehrbüchern zu OOP-Sprachen die Vererbung als
die große Errungenschaft herausgestellt, weil es die meisten anderen
Konzepte wie Kapselung und verschiedene Formen der Polymorphie auch in
Nicht-OOP-Sprachen gibt. So entsteht beim Leser der Eindruck, ein
OO-Design sei nur dann gut, wenn möglichst viele Klassen zueinander in
einer Vererbungsbeziehung stehen.

Umgekehrt: Schafft der Leser es nicht, die einzelnen Klassen seines
Programms voneinander erben zu lassen oder gemeinsame Basisklassen zu
finden, weil die Problemstellung einfach keinen Anlass dafür gibt, hat
er ein schlechtes Gewissen und denkt, er hätte die OOP noch nicht
verstanden.

> Andererseits ist OOP und vor allem das Konzept der Kapselung sehr stark.
> Wir können und sollten es auch in Nicht-OOP-Sprachen anwenden.

Ebenfalls Zustimmung.

Aber gerade, weil die Kapselung nicht OOP-spezifisch ist, wird sie in
der OOP-Literatur zwar behandelt, aber im Vergleich zur Vererbung nicht
ganz so sehr in den Vordergrund gestellt. Da die Kapselung ohne viel
Nachdenken sowieso leicht zu bewerkstelligen ist, konzentriert der
Lernende seine geballte Kreativität auf eine möglichst komplexe
Klassenhierarchie :-)

> Aus der Sicht des Programmierens im Kleinen mag eine Klassenstruktur
> noch sinnvoll erscheinen, obwohl Vererbung viel zu oft anstelle von
> Komposition benutzt wird.

Solche Dinge wie

- wann man Vererbung einsetzt und wann besser Komposition oder gar
  nichts von beidem,

- wann man eine Funktion als instanzbezogene Memberfunktion definiert
  und wann besser als instanzunabhängige Klassenfunktion oder (in C++)
  als freie Funktion, und

- falls man sich für eine instanzbezogene Memberfunktion entscheidet, in
  welche Klasse man sie packt (es gibt genügend Beispiele, wo das
  absolut nicht trivial ist),

lernt man erst in der Fortgeschrittenenliteratur, die aber kaum einer
liest, weil man ja mit dem Anfängerbuch bereits alle Sprachelemente
kennengelernt hat.

Hier ist noch ein Zitat vom C++-Entwickler Stroustrup zu diesem Thema:

Please note that object-oriented programming is not a panacea. "OOP"
does not simply mean "good" - if there are no inherent hierarchical
relationships among the fundamental concepts in your problem then no
amount of hierarchy and virtual functions will improve your code. The
strength of OOP is that there are many problems that can be usefully
expressed using class hierarchies - the main weakness of OOP is that too
many people try to force too many problems into a hierarchical mould.
Not every program should be object-oriented. As alternatives, consider
plain classes, generic programming, and free-standing functions (as in
math, C, and Fortran).

(Aus: http://www.stroustrup.com/bs_faq.html)

Genau die Software von Leuten, die mit roher Gewalt "too many problems
into a hierarchical mould" pressen, liefern das Futter für die Anti-OOP-
Schreihälse hier im Thread. Statt sich von diesen Negativbeispielen,
(die es übrigens für jedes Programmierparadigma gibt) abschrecken zu
lassen, sollte man aus ihnen lernen und versuchen, selber die gleichen
Fehler nicht zu machen.

Schlussbemerkung:

Ich bin selber auch kein riesiger Fan der OOP und setze sie nur dort
ein, wo ich die damit verbundenen Vorteile in Bezug auf eine bestimmte
Anwendung schon von vornherein deutlich erkennen kann. Mich nerven aber
Leute, die solche Dinge lautstark und in unzähligen Wiederholungen als
den größten Mist der Menschheitsgschichte abstempeln, ohne sich zuvor
mit der erforderlichen Intensität damit auseinandergesetzt zu haben.

[Stefan Salewski (Gast)]

Yalu X. schrieb:
> Smalltalk lasse ich mal auf Grund
> des hohen Alters außen vor)

Pharo soll eine sehr gute moderne Smalltalk-Variante sein:

https://de.wikipedia.org/wiki/Pharo_(Programmiersprache)

[Phony (Gast)]

Dann muss ich jetzt mal ganz blöd fragen:

Ich programmiere ausschließlich OOP, da ich nie was anderes 
kennengelernt habe. Üblicherweise verwende ich die Sprachen C++, C#, 
Java, Python und JavaScript (bzw. TypeScript), je nach Projekt.

Ich kann mir ehrlich gesagt gar nicht vorstellen, auf OOP zu verzichten.
Kann mir jemand mal ein paar Beispiele für Projekte nennen, die durch 
rein prozedurale Programmierung effizienter zu implementieren bzw. 
wartungsfreundlicher sind?

[Jobst Q. (joquis)]

Phony schrieb:
> Dann muss ich jetzt mal ganz blöd fragen:
>
> Ich programmiere ausschließlich OOP, da ich nie was anderes
> kennengelernt habe. Üblicherweise verwende ich die Sprachen C++, C#,
> Java, Python und JavaScript (bzw. TypeScript), je nach Projekt.
>
> Ich kann mir ehrlich gesagt gar nicht vorstellen, auf OOP zu verzichten.
> Kann mir jemand mal ein paar Beispiele für Projekte nennen, die durch
> rein prozedurale Programmierung effizienter zu implementieren bzw.
> wartungsfreundlicher sind?

Stringverarbeitung zB ist in purem C wesentlich effizienter und 
schneller. Natürlich muss man dazu verstehen, was ein Pointer ist. Aber 
in der Zeit, die man damit verbringt, eine Stringklasse mit all ihren 
Methoden zu studieren, kann man sich auch damit beschäftigen.

Ein nicht unbedeutendes Projekt in purem C ist der Linux-Kernel. Ein 
Grund dafür ist wohl die Durchschaubarkeit von C, die mit C++ verloren 
gegangen ist. Wer sich mit CPUs und Assembler auskennt, kann anhand des 
Quelltextes in etwa voraussehen, was im Prozessor geschehen wird. Keine 
andere Hochsprache ist da so konsistent.

Die wichtigsten Vorteile der OOP, zusammengehörige Daten zusammen zu 
halten und mit einer einzigen Referenz darauf zugreifen zu können, sind 
schon mit der Verwendung von structs gegeben und selbst mit Assembler 
möglich.

OOP ist keine Alternative zur PP, sondern eine andere Ebene. Als 
Autofahrer muss man nicht unbedingt wissen, was unter der Motorhaube 
geschieht, aber deshalb sind Automechaniker nicht überflüssig, im 
Gegenteil.

Als OOP-Programmierer setzt man im wesentlichen Bausteine zusammen wie 
beim LEGO. Aber wie werden diese Bausteine hergestellt? Im Kern mit 
simpler PP, nur der Rahmen ist OOP-spezifisch.

[D. I. (Gast)]

Assembler ist auch nur der objektorientierte Rahmen von 
Mikrocodeanweisungen im Prozessor, man steckt die einzelnen 
Assemblerbefehle zusammen wie bei Lego.

[Jobst Q. (joquis)]

D. I. schrieb:
> Assembler ist auch nur der objektorientierte Rahmen von
> Mikrocodeanweisungen im Prozessor, man steckt die einzelnen
> Assemblerbefehle zusammen wie bei Lego.

Bis auf das 'objektorientierte' stimme ich dir zu.

Und so wie der Microcode bei den Prozessorentwicklern nicht veraltet 
ist, weil nur wenige ihn kennen, ist auch die prozedurale Programmierung 
nicht veraltet, sondern nur eine andere Ebene.

Dass wir auf den Schultern von Riesen stehen, ist kein Grund auf Sie 
herabzublicken.

[Borislav B. (boris_b)]

Jobst Q. schrieb:
> Stringverarbeitung zB ist in purem C wesentlich effizienter und
> schneller.

Das ist, so weit ich weiß, falsch. Die C++ string Klasse ist in vielen 
Fällen schneller als C-Strings. Gründe dafür sind z.B. dass die Länge 
des Strings bekannt ist, und dass die Strings nicht null-terminiert 
sind.
Daher benötigt z.B. strlen() O(N), std::string::size() aber nur O(1).

Jobst Q. schrieb:
> Als OOP-Programmierer setzt man im wesentlichen Bausteine zusammen wie
> beim LEGO. Aber wie werden diese Bausteine hergestellt? Im Kern mit
> simpler PP, nur der Rahmen ist OOP-spezifisch.

Das ist definitiv Quatsch. Rein inhaltlich gibt es überhaupt keinen 
Unterschied. Lediglich die Strukturierung ist eine andere.

[Rolf M. (rmagnus)]

Jobst Q. schrieb:
> Stringverarbeitung zB ist in purem C wesentlich effizienter und
> schneller.

Stringverarbeitung ist nun aber gerade etwas, das man nicht in großem 
Rahmen komplett in C machen will (ich zumindest nicht). Es ist einfach 
zu umständlich und fehlerträchtig.

> Ein nicht unbedeutendes Projekt in purem C ist der Linux-Kernel. Ein
> Grund dafür ist wohl die Durchschaubarkeit von C, die mit C++ verloren
> gegangen ist.

Hauptgrund wird eher sein, dass Linus Torvalds C++ nicht mag. Seine 
Aussagen dazu lassen vermuten, dass er sich aber auch nicht wirklich 
damit beschäftigt hat.
Übrigens benutzt auch der Linux-Kernel OO-Konzepte (z.B. Polymorphie), 
nur dass sie eben nicht direkt über in der Sprache eingebaute Mittel 
verwendet werden, sondern zu Fuß implementiert sind.

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Ähm, der Linux Kernel den ich kenne ist aber so etwas von 
objektorientiert!

Auch wenn's zum Großteil c ist...

Im Übrigen ist ein Betriebssystem ein sehr, sehr gutes Beispiel bei dem 
Objektorientierung sinnvoll ist.

Bestes Beispiel: Prozesse

da hat jeder seinen Stack, sein Register-File, einen Pointer zum 
Entry-Point... und natürlich Funktionen wie Run/Stop/Suspend.

Ohne OOP hätte man jetzt unzählige einzelne (globale?) Arrays für alles.

Mit OOP ist das alles eine Klasse oder zumindest ein struct.

Da ist keine Vererbung im Spiel oder so aber es zeigt wie viel 
strukturierter das werden kann (also 42 Arrays wo man mit dem richtigen 
Index reinfingern muss vs. ein Array von Objekten).

Wenn ich mir jetzt verschiedene Dateisysteme ansehe, dann würde ich das 
als gutes Beispiel für den Einsatz von Vererbung sehen... sys-calls für 
Dateien (open, close, read, write) sind gleich - was sie tun aber nicht.

Unser Moby ist leider... Moby... seine These, dass er in asm kleineren 
code erzeugt als ein ein c(++) compiler hat sich ja schon einmal als 
falsch herausgestellt.

Ich schreibe viel prozedural und viel mehr objektorientiert... die 
Grenze ziehe ich unscharf dort wo zuviele unterschiedliche Objekte mit 
einander koexistieren müssen. Oft genug gibts es aber kein 
(definierbares) Objekt...

73

[Dumdi D. (dumdidum)]

Phony schrieb:
> Ich kann mir ehrlich gesagt gar nicht vorstellen, auf OOP zu verzichten.

Hast Du in einem Deiner Programme Klassen geschrieben bei denen  die 
getter und setter transparent waren (d.h. den Wert direkt verwendet); 
und Du zudem auf Polymorphismus verzichtet hast? In Wirklichkeit hast Du 
da auf OOP verzichtet.

[Borislav B. (boris_b)]

Dumdi D. schrieb:
> Hast Du in einem Deiner Programme Klassen geschrieben bei denen  die
> getter und setter transparent waren (d.h. den Wert direkt verwendet);
> und Du zudem auf Polymorphismus verzichtet hast? In Wirklichkeit hast Du
> da auf OOP verzichtet.

OOP bedeutet nicht, dass ich in jeder Zeile Code eine Klasse ableite 
oder sonst was ;-)
OOP ist ein Architekturkonzept. Natürlich ist auch in jedem OOP 
basierten projekt sehr viel prozeduraler Code enthalten...

[Daniel A. (daniel-a)]

Boris P. schrieb:
> OOP bedeutet nicht, dass ich in jeder Zeile Code eine Klasse ableite
> oder sonst was ;-)

Wäre aber auch mal eine Herausforderung. Ich versuch's mal:

class symbol_table extends Object{hello_world(){}}
class symbol_printer extends symbol_table{greating(){console.log(this.hello_world.name);}}
new class extends symbol_printer{constructor(){super();this.greating();}};

Scheint definitiv möglich in ES6, mit nichts als Ableitung, und einer 
Ableitung pro Zeile zu Programmieren :)

[Heiner K. (heinerkuhlmann)]

Wir verlieren uns in Details. Welche Sprache, OOP, PP ist die beste um 
Programmileinileinschen zu schreiben.

In einem anderen Bild: Maurer unterhalten sich darüber, welche 
Mauertechnik die beste ist.

OO macht aber Sinn, wenn wir es uns aus der Sicht eines Architekten 
ansehen.

Der Linux-Kernel zeigt, dass es auch ohne OOP geht.
Ich kenne andere Systeme, mit Millionen LOC fast alle ohne OO-Sprache.
Einige Systeme sind sehr wohl objektorientiert strukturiert.

Die Voraussetzung für den Erfolg solcher Systeme sind saubere 
Strukturen. Damit sind Module und deren Abhängigkeiten gemeint. Die 
Module haben klare Interfaces. Die Implementation ist gekapselt. Wer was 
verwenden darf ist klar geregelt. Wenn ich mir diese Module ansehe gibt 
es zwei Klassen:

Bibliotheken wie Mathe, die Funktionen anbieten, die Elemente bekommen 
und Ergebnis-Elemente liefern. Der Zeitpunkt des Aufrufs und deren 
Reihenfolge haben keinen Einfluss auf das Ergebnis.

Module mit Zustand. Hier hat der Zeitpunkt des Aufrufs und deren 
Reihenfolge einen Einfluss auf das Ergebnis.

Module fassen das zusammen, was zusammengehört.

Einige Herangehensweisen ignorieren Module mit Zustand. Sie beschreiben 
an einer Stelle die Elemente, die Daten und an einer anderen Stelle wird 
beschrieben wie sie verarbeitet werden. Diese Sicht fördert 
unübersichtliche Strukturen.

Die wichtigste Idee hinter OO ist, Daten und die bereitgestellten 
Funktionen zusammenzufassen.

Damit ein komplexes System übersichtlich bleibt, werden von einem Modul 
nur die essentiellen Funktionen bereitgestellt. Wie sie implementiert 
sind,
ist im Modul verborgen. Verborgen in dem Sinne, das der Anwender des 
Moduls die Implementierung nicht sehen braucht, sie sich jedoch ansehen 
darf. Nur eines darf er nicht, sich darauf verlassen, dass die 
Implementation sich  nicht ändert. Weil der Anwender die Implementierung 
nicht sehen braucht, muss das Verhalten des Moduls klar im Interface 
beschrieben sein.

Module in grossen Systemen sind riesig, sie enthalten wiederum Module 
usw.
Es ergibt sich ein eine hierarchische Architektur.

Module werden oft in verschiedenen Kontexten benötigt. Da ist es 
wünschenswert, sie parametrisieren zu können. Man kann generische Module 
erstellen, die sogar andere Module als Parameter haben können. 
Eigentlich geht es darum, Module zu abstrahieren und allgemeiner zu 
formulieren.
Der Sinn des Ganzen ist Wiederverwendbarkeit.

Währen wir oben Module als Objekte mit Zustand, Interface und Kapselung
gesprochen haben. Haben wir es jetzt mit Klassen zu tun. Aber das ist 
nicht die ganze Welt. Die oben erwähnten generischen Module sind eine 
andere Sicht, die Möglichkeiten bietet von denen manche OO-Programmierer 
nicht einmal träumen.

Um es noch einmal klarzustellen, die meisten (grossen) Module sind 
Objekte und nur wenige Klassen und noch weniger generisch.

Diese Strukturen kann man auch mit Nicht-OO-Sprachen aufbauen. Es bedarf 
klarer Regeln und Vorgaben.

Die wichtigste Regel besagt: "Du darfst nicht verwenden was Du willst 
sondern nur was Du verwenden darfst."

Die OO-Sprachen unterstützen diese Regel durch ihre Kapselung. Leider 
nur im Kleinen. Dafür stellen sie mächtige Konzepte wie Polymorphismen 
und Vererbung bereit. Erklärt wird das Ganze an Objektileinileinchen. 
Und jeder bastelt sich seine Klassen zurecht. Interfaces werden 
überfrachtet und vor allem nicht beschrieben. Man kann sich ja den Code 
ansehen.

Fatal wirkt sich dann aus, dass dann jeder eine Klasse, die ihm geeignet 
scheint in sein Programm einbaut. Wir wundern uns dann, wie es passieren 
kann, wenn jemand die Farbe in einem Fenster ändert, an anderen Stellen 
auch alles grün wird.

Die freie Verwendbarkeit von Modulen ist hier das Problem ebenso das 
Problem wie wohldurchdachte und dokumentierte Interfaces.

Auf der anderen Seite werden natürlich breit oder sogar global 
verwendbare Module benötigt. Solche Module sollten nur von Könnern 
erstellt werden.

Fazit:

Objektorientierung im Keinen ist ein mächtiges schönes Werkzeug, das 
leider oft nicht einmal im Kleinen beherrscht wird. Nicht die Sprache, 
sondern das Konzept und vor allen seine Implikationen.

Objektorientierung im Grossen ist eine essentielle Sichtweise, die 
leider durch die Werkzeuge des Keinen nicht beherrschbar sind.

Hochhäuser aus der Sicht eines Maurers.

Wie sagte Tom DeMarco: A fool with a tool ...

P.S.

Der Linux-Kernel ist sehr wohl objektorientiert (nicht Orgien). Was sind 
denn die Treiber? Die Architektur ist vor allem sehr gut strukturiert. 
Seine graue Eminenz Linus wacht darüber mit Argusaugen.

[Rolf M. (rmagnus)]

Hans W. schrieb:
> Wenn ich mir jetzt verschiedene Dateisysteme ansehe, dann würde ich das
> als gutes Beispiel für den Einsatz von Vererbung sehen... sys-calls für
> Dateien (open, close, read, write) sind gleich - was sie tun aber nicht.

Nicht nur Dateisysteme, sondern auch die ganzen Gerätetreiber. Die sind 
schließlich auch alle als virtuelle Dateien implementiert, die diese 
ganzen Syscalls haben. Ein Linux-Treiber muss dazu eine Struktur mit 
Funktionspointern auf seine Implementierung dieser Syscalls anlegen und 
dem Kernel übergeben. Beim Zugriff auf das Device wird dann über diese 
Pointer die richtige Funktion gefunden und ausgeführt. Das ist genau das 
gleiche wie eine vtable, nur eben zu Fuß.

[Karl Käfer (Gast)]

Heiner K. schrieb:
> Der Linux-Kernel zeigt, dass es auch ohne OOP geht. [...]
> Der Linux-Kernel ist sehr wohl objektorientiert (nicht Orgien).

Eigentlich zeigt der Linuxkernel zwei Dinge. Erstens daß es nicht ohne 
OOP geht und zweitens daß OOP auch ohne direkte Unterstütung durch 
besondere sprachliche Mittel realisiert werden kann.

[Heiner K. (heinerkuhlmann)]

Karl Käfer schrieb:

> Eigentlich zeigt der Linuxkernel zwei Dinge. Erstens daß es nicht ohne
> OOP geht und zweitens daß OOP auch ohne direkte Unterstütung durch
> besondere sprachliche Mittel realisiert werden kann.

Zu Erstens:

JA, nein.

Es geht ohne OOP. Objekte sind immanente Elemente eines Systems. Sie zu 
erkennen ist ist die Leistung und sie bewusst anzuwenden ist OO. Das 
könnte man als (P) Programmierung bezeichnen aber nicht im herkömmlichen 
Sinne, Code zu produzieren.

Zu Zweitens:

JA

Genau darum geht der Streit in diesem Thread, kann man Objekt ORIENTIERT 
programmieren ohne eine OO-Sprache im engeren Sinne zu verwenden.

Die Denkweise in Objekten liegt uns näher, als wir uns bewusst machen.

Der Gedanke des Zusammenfassens und Kapselns von Daten, Zustand und 
Funktionen geht in dem Geplärre von Vererbung und Polymorphismus ebenso 
unter wie das Konzept der Komposition.

[Jobst Q. (joquis)]

Boris P. schrieb:
> Jobst Q. schrieb:
>> Stringverarbeitung zB ist in purem C wesentlich effizienter und
>> schneller.
>
> Das ist, so weit ich weiß, falsch. Die C++ string Klasse ist in vielen
> Fällen schneller als C-Strings. Gründe dafür sind z.B. dass die Länge
> des Strings bekannt ist, und dass die Strings nicht null-terminiert
> sind.
> Daher benötigt z.B. strlen() O(N), std::string::size() aber nur O(1).

Ja, du Schlauberger. Aber wie kommt Länge in das Objekt? Bei jeder 
Zuweisung und Veränderung muss die Länge neu ermittelt werden, mit 
strlen() oder ähnlichem. Nur weil sie irgendwann mal gebraucht werden 
könnte. Eine Art Vorratsdatenspeicherung, die genau deshalb einen 
gewaltigen Overhead verursacht. Sie kann von Vorteil sein, wenn ein 
String nur einmal eingelesen und dann nur abgefragt wird. Das kann man 
aber nicht Stringverarbeitung nennen, sondern höchstens 
Stringverwendung.

In purem C ist ein String einfach nur eine Adresse, alles andere ergibt 
sich daraus. Der Prozessor muss nichts überfüssiges machen, die 
Stringverarbeitung ist schnellstmöglich. Wenn für jede neue 
Stringvariable Speicher alloziiert und Strukturen aufgebaut und gefüllt 
werden müssen, damit es ein vollwertiges Objekt ist, braucht das seine 
Zeit und Resourcen. Wenn bei der Programmierung von Compilern 
Stringobjekte statt char* verwendet würden, wären viele Kaffepausen 
gesichert.

Ich bin nicht prinzipiell gegen OOP, für große Objekte bringt sie viele 
Vorteile, aber für Strings ist sie überflüssig wie ein Kropf. Das schöne 
an C++ ist, dass man die Möglichkeiten von OOP nutzen kann, aber nicht 
muss.

[Georg A. (georga)]

Jobst Q. schrieb:
> Ja, du Schlauberger. Aber wie kommt Länge in das Objekt? Bei jeder
> Zuweisung und Veränderung muss die Länge neu ermittelt werden, mit
> strlen() oder ähnlichem. Nur weil sie irgendwann mal gebraucht werden
> könnte. Eine Art Vorratsdatenspeicherung, die genau deshalb einen
> gewaltigen Overhead verursacht.

Schön, wie man ein negativ besetztes Wort mit etwas zusammenbringen 
kann, mit dem es gar nichts zu tun hat...

Warum sollte bei einer Zuweisung ala a=b die Länge neu ermittelt werden 
müssen? Und wozu sollte man strlen brauchen, wenn die Länge der 
Ausgangsstrings bekannt ist und die Operationen darauf deterministisch 
sind?

[Sensemännchen (Gast)]

Jobst Q. schrieb:
>> Daher benötigt z.B. strlen() O(N), std::string::size() aber nur O(1).
>
> Ja, du Schlauberger. Aber wie kommt Länge in das Objekt? Bei jeder
> Zuweisung und Veränderung muss die Länge neu ermittelt werden, mit
> strlen() oder ähnlichem.

Nein, fast immer genügt eine einzelne Addition bzw. Subtraktion. Der 
zusätzliche Aufwand ist also im Gesamtkontext irrelevant.

> die genau deshalb einen gewaltigen Overhead verursacht.
> Wenn bei der Programmierung von Compilern Stringobjekte statt char*
> verwendet würden, wären viele Kaffepausen gesichert.

War starker Unterdruck nötig, sich diesen Unsinn aus den Fingern zu 
saugen? Und nein, ich bin kein Fanboy, die Stringverarbeitung in C++ ist 
nichts Halbes und nichts Ganzes.

[Yalu X. (yalu) (Moderator)]

Jobst Q. schrieb:
> In purem C ist ein String einfach nur eine Adresse, alles andere ergibt
> sich daraus. Der Prozessor muss nichts überfüssiges machen, die
> Stringverarbeitung ist schnellstmöglich.

Nein, i.Allg. ist das nicht der Fall.

Bei den meisten String-Operationen ist es von Vorteil, wenn man die
Länge vorab kennt. Ein paar Beispiele:

Länge bestimmen:
Das ist nur ein einzelner Zugriff auf die Längeninformation. Bei
nullterminierten Strings müssen die Zeichen gezählt werden.

Kopieren:
Das Kopieren kann in großen Blöcken erfolgen, da man nicht jedes
einzelne Zeichen auf '\0' abprüfen muss. Die Längeninformation muss zwar
mitkopiert werden, das ist aber nur ein einzelner Integer-Wert.

Anhängen eines Strings s2 an einen anderen String s1:
Man weiß sofort, an welche Stelle im Buffer von s1 man s2 kopieren muss.
Die Länge von s1 muss zwar aktualisiert werden, das ist aber nur eine
einfache Addition.

Bereichsprüfung des Index:
Bei nullterminierten String muss vor der eigentlichen Prüfung die Länge
durch Abzählen bestimmt werden.

Vorteile (mit Einschränkungen) von nullterminierten Strings:

- Sie belegen ein paar Bytes weniger Speicher. Dafür darf aber das
  Zeichen NUL ('\0') nicht im String vorkommen.

- Auf manchen Prozessorarchitekturen geht das Iterieren über alle
  Zeichen des Strings etwas schneller. Es gibt aber auch Architektueren,
  wo es genau anders herum ist. Außerdem ist bei der Iteration über
  nullterminierte Strings kein Loop-Unrolling möglich.

Der Grund, warum C von Hause aus nur die nullterminierten Strings hat,
liegt darin, dass die Anzahl der vordefinierten Datentypen klein halten
wollte. Ein String mit Längenangabe wäre ein spezielles Struct, das aber
ein Anwendungsprogrammierer oder ein Bibliotheksschreiber auch selber
nach eigenem Gutdünken definieren kann.

C ist die einzige mir bekannte Programmiersprache mit nullterminierten
Strings. Alle anderen verwenden entweder

- Zeichenarrays mit zusätzlicher Längenangabe,
- verkettete Listen von Zeichen oder
- verkettete Zeichenarrays mit Längenangabe.

Wobei jetzt die interne Repräsentation von Strings mit dem Thema OOP
nichts, aber auch gar nichts zu tun hat :)

[Jobst Q. (joquis)]

Yalu X. schrieb:
> Jobst Q. schrieb:
>> In purem C ist ein String einfach nur eine Adresse, alles andere ergibt
>> sich daraus. Der Prozessor muss nichts überfüssiges machen, die
>> Stringverarbeitung ist schnellstmöglich.
>
> Nein, i.Allg. ist das nicht der Fall.
>
> Bei den meisten String-Operationen ist es von Vorteil, wenn man die
> Länge vorab kennt. Ein paar Beispiele:
>
> Länge bestimmen:
Ja, es ist beim Bestimmen der Länge von Vorteil, wenn man sie schon 
kennt.
Welch tiefe Weisheit, auch Tautologie genannt.

Bei den meisten String-Operationen, die ich kenne und verwende, spielt 
die Länge keine Rolle.

> Das ist nur ein einzelner Zugriff auf die Längeninformation. Bei
> nullterminierten Strings müssen die Zeichen gezählt werden.

Müssen sie nicht, wenn die Stringfunktionen die Adresse der Null am Ende 
zurückgeben. Die Funktion strcpy tut das dummerweise nicht, sie gibt den 
Anfang zurück, den man eh schon kennt. Aber da gibt es auch die Funktion 
stpcpy die genau das tut, was sie soll.

Beispiel für die Längenbestimmung beim Aneinanderhängen von zwei 
Strings:

l=stpcpy(stpcpy(buf,s1),s2)- buf;

Weder die Länge von s1 noch von s2 muss vorher bekannt sein und doch 
bekommt man die Gesamtlänge fast gratis.

>
> Kopieren:
> Das Kopieren kann in großen Blöcken erfolgen, da man nicht jedes
> einzelne Zeichen auf '\0' abprüfen muss. Die Längeninformation muss zwar
> mitkopiert werden, das ist aber nur ein einzelner Integer-Wert.

Strings sind aber selten große Blöcke, deshalb fällt das kaum ins 
Gewicht.
Für Blöcke gibt es die mem-Funktionen. Jeden String als Block zu 
definieren, halte ich nicht für sinnvoll.

Ein großer Vorteil der Null-terminierten Strings ist aber, dass man viel 
seltener kopieren muss. Einen längeren String, zB eine Zeile aus einer 
Datei in einem Puffer, kann man an Ort und Stelle in mehrere benötigte 
Teilstrings zerlegen, indem man die Trennzeichen durch eine Null 
ersetzt. Das geht mit keinem anderen Stringmodell.

Ein anderer großer Vorteil ist sehr simple Verkürzen der Strings. ZB das 
Überspringen von Leerzeichen und tabs:

while(*s==' '||*s=='\t')s++;

Wie man eine solche Aufgabe mit Objektstrings löst, überlasse ich 
anderen.
Deren Methoden erinnern mich stark an den Murks der Stringbehandlung in 
GWBasic, mit dem ich mich rumquälte, bevor ich C entdeckte.


> Wobei jetzt die interne Repräsentation von Strings mit dem Thema OOP
> nichts, aber auch gar nichts zu tun hat :)

Sehe ich nicht so. Strings sind ein gutes Beispiel, wie OOP-Dogmen 
einfaches kompliziert und ineffektiv machen können.

[nfet (Gast)]

for ( std::string::iterator it=s.begin(); it!=s.end(); ++it) {
    if ( (*it = ' ') or  (*it=='\t') ) {
        it++;
    }
}

wow der Unterschied...
Sollte das etwa gar nichts mit OOP zu tun haben?

Ich habe noch nie jemanden gesehen, der mir ernsthaft erzählen wollte, 
wie toll Stringverarbeitung mit C geht. Ich kann mir auch nicht 
vorstellen, dass du dir das selber erzählst.

[Mark B. (markbrandis)]

nfet schrieb:
> Ich habe noch nie jemanden gesehen, der mir ernsthaft erzählen wollte,
> wie toll Stringverarbeitung mit C geht.

Stringverarbeitung mit C geht jedenfalls - sie wird millionenfach 
durchgeführt. Ob sie "toll" ist, sei dahingestellt. Dazu müsste man erst 
einmal definieren, was man unter toller Stringverarbeitung versteht. 
"Toll" kann ja auch verrückt heißen... ;-)

[Yalu X. (yalu) (Moderator)]

nfet schrieb:

  for ( std::string::iterator it=s.begin(); it!=s.end(); ++it) {

Naja, das war jetzt eher ein Beispiel dafür, wie kompliziert eine
einfache Iteration über die Zeichen eines Strings in C++ sein kann.

Mit C-Strings würde man einfach schreiben:

  for(char *it = s; *it; it++) {

Aber auch mit C++-Strings geht es einfacher, sogar noch einacher als in
C:

  for (auto c: s) {

Durch die auto-Deklaration funktioniert das sogar gleichermaßen für
string- wie für wstring-Typen.


nfet schrieb:
> Sollte das etwa gar nichts mit OOP zu tun haben?

Mein diesbezüglicher Kommentar von oben bezog sich auf die interne
Repräsentation von Strings. Das von Jobst angeprangerte Mitführen der
Länge in einem String-Datentyp ist keine OOP-spezifische Eigenschaft.

[Rolf M. (rmagnus)]

Yalu X. schrieb:
> for ( std::string::iterator it=s.begin(); it!=s.end(); ++it) {
>
> Naja, das war jetzt eher ein Beispiel dafür, wie kompliziert eine
> einfache Iteration über die Zeichen eines Strings in C++ sein kann.
>
> Mit C-Strings würde man einfach schreiben:
>   for(char *it = s; *it; it++) {

Was ist jetzt an dem ersten komplizierter als am zweiten? Der Typenname 
ist etwas länger, aber das war's dann auch.

> Aber auch mit C++-Strings geht es einfacher, sogar noch einacher als in
> C:
>   for (auto c: s) {

Das hat nichts mit "einfacher" zu tun. Es ist schlicht eine kürzere 
Schreibweise. Und es macht nicht mal das gleiche. Im ersten Fall habe 
ich schließelich einen Iterator auf die Stelle, wo das Zeichen steht, 
den ich in weiteren Funktionen auf den String anwenden kann, während ich 
bei deiner Variante nur das Zeichen selbst habe. Gut, das überspringen 
von Zeichen in der Schleife könnte man damit auch machen.
Wobei man auto natürlich auch für den Iterator verwenden kann:

for (auto it=s.begin(); it!=s.end(); ++it) {

Das tolle an Iteratoren ist eben auch, dass die eigentliche 
Datenstruktur dich gar nicht interessieren muss, während die 
Pointer-Variante aus c ausschließlich mit Arrays funktioniert. Dann 
klappt das z.B. auch bei einer Stringklasse, die die Daten intern als 
verkettete Liste aus Arrays hält, wie man das bei Texteditoren 
üblicherweise macht. Die arbeiten ja in der Regel mit sehr langen 
Zeichenketten, bei denen man ständig mittendrin was einfügen muss.

[Beaker (Gast)]

Muss zugeben, dass verstehe ich nicht (soll wirklich nur eine Frage 
sein)
>for(char *it = s; *it; it++)
*it = s setzt den als itterator benutzten Zeiger auf Element 0 vom 
Zielstring
>> *tt das versteh ich nicht - wie wird hier die Abbruchbedingung erfüllt? Hat das 
Terminierungszeichen automatisch den Wert, dass es als Abbruchbedingung dient?
it++ => inkrement des itterators

[Peter (Gast)]

Beaker schrieb:
> Muss zugeben, dass verstehe ich nicht (soll wirklich nur eine
> Frage sein)
>>for(char *it = s; *it; it++)
> *it = s setzt den als itterator benutzten Zeiger auf Element 0 vom
> Zielstring
>>> *tt das versteh ich nicht - wie wird hier die Abbruchbedingung erfüllt?

Bedingung ist "wenn *it wahr".
Beim Terminierungszeichen '\0' (0) ist *it false (also Abbruch), sonst 
true (weiter).

> Hat das Terminierungszeichen automatisch den Wert, dass es als
> Abbruchbedingung dient?

Ja; weil 0 in C (als bool) als false interpretiert wird, alle anderen 
Werte als true. Wäre für C-Strings als Terminierungszeichen nicht 0, 
sondern z.B. 255 definiert, würde es also so nicht funktionieren (es sei 
denn, dieser Wert würde dann als false interpretiert werden und die 
anderen als true).

[Mikro 7. (mikro77)]

Rolf M. schrieb:
> ...
> Das hat nichts mit "einfacher" zu tun. Es ist schlicht eine kürzere
> Schreibweise.

Und das ist nicht "einfacher"? ;-)

> Und es macht nicht mal das gleiche.

Dann eben:

for (auto &c: s) ...

[Jobst Q. (joquis)]

nfet schrieb:
> Ich habe noch nie jemanden gesehen, der mir ernsthaft erzählen wollte,
> wie toll Stringverarbeitung mit C geht.

Du Ärmster! Soll ich dir jetzt ein Bild von mir schicken ?

[nicht"Gast" (Gast)]

Jobst Q. schrieb:
> while(*s==' '||*s=='\t')s++;

Wie sehts mit

s.TrimStart() aus? Das ist deutlich Übersichtlicher und man sieht auf 
den ersten Blick, was passieren soll.

Außerdem sollte an der Stelle im Code, wo du dein String trimmen willst, 
auch bei PP nicht Dein while Konstrukt stehen sondern das sollte in 
einer Funktion sein. Alles andere ist schlechter Stil und das hat mit 
OOP oder PP bekanntlich nichts zu tun.

[Jobst Q. (joquis)]

nicht"Gast" schrieb:
> Jobst Q. schrieb:
>> while(*s==' '||*s=='\t')s++;
>
> Wie sehts mit
>
> s.TrimStart() aus? Das ist deutlich Übersichtlicher und man sieht auf
> den ersten Blick, was passieren soll.

Und wenn TrimStart() nicht in der verwendeten Klassenbibliothek 
vorhanden ist?

Der Name sagt vielleicht, was passieren soll, aber nicht, was wirklich 
geschieht, was alles in der Methode Trimstart drinsteckt. Was in der 
while-Zeile geschieht, ist dagegen klar für jeden, der was von C 
versteht.

Es ging nicht um die kürzeste Schreibweise, sondern um die kürzeste 
Ausführungszeit, und die ist gegeben, wenn nur das getan wird, was für 
die
Aufgabe nötig ist. Da ein String in C eine simple Zeigervariable ist, 
gibt es keinerlei Verwaltungsaufwand, der die Performance ausbremsen 
kann.

>
> Außerdem sollte an der Stelle im Code, wo du dein String trimmen willst,
> auch bei PP nicht Dein while Konstrukt stehen sondern das sollte in
> einer Funktion sein. Alles andere ist schlechter Stil und das hat mit
> OOP oder PP bekanntlich nichts zu tun.

Auch bei mir steht

while(*s==' '||*s=='\t')s++;
return s;

nur in meiner Funktion nextvis(). In meinen Programmen steht dann 
lediglich

s=nextvis(s);

[Rolf M. (rmagnus)]

Mikro 7. schrieb:
> Rolf M. schrieb:
>> ...
>> Das hat nichts mit "einfacher" zu tun. Es ist schlicht eine kürzere
>> Schreibweise.
>
> Und das ist nicht "einfacher"? ;-)

Kommt drauf an, was du unter "einfacher" verstehst. Hier scheint nämlich 
jeder was anderes damit zu meinen. Der eine versteht darunter, dass es 
für den Prozessor effizienter ist, der nächste, dass es leichter 
verständlich ist, der dritte, dass es weniger Zeichen zu tippen sind.

>> Und es macht nicht mal das gleiche.
>
> Dann eben:for (auto &c: s) ...

Das kann man immer noch nicht als Iterator in den String benutzen.

[Beaker (Gast)]

So wie ich das sehe, sind das jetzt Detailklauberreien. C ist ja eine 
Untermenge von C++. Also kann ich da meine Strings genau so bearbeiten, 
wenn ich das will.

[nicht"Gast" (Gast)]

Jobst Q. schrieb:
> Es ging nicht um die kürzeste Schreibweise, sondern um die kürzeste
> Ausführungszeit, und die ist gegeben, wenn nur das getan wird, was für
> die
> Aufgabe nötig ist. Da ein String in C eine simple Zeigervariable ist,
> gibt es keinerlei Verwaltungsaufwand, der die Performance ausbremsen
> kann.
>
>>

Soso,

irgend wie scheinst du dich an dem falschen Thema abzuarbeiten. Das 
Zerlegen und/oder Trimmen von Zeichenketten ist in so ziemlich keiner 
sinvollen Anwendung der zeitkritische Teil. (google mal nach "Premature 
optimization is the root of all evil").

Bei der Verarbeitung von großen Datensätzen ist es eigentlich immer die 
Beschaffung von Speicher, IO Operationen oder besondere Algorithmik, 
welche einer genauen Betrachtung bedarf. Einfache Stringverarbeitung ist 
da eher uninteressant.


BTW, ich weiß ja nicht wie du Quellcode liest, aber wenn ich irgend wo 
im Text ein TrimStart sehe, dann weiß ich, dass die Whitespaces am 
Anfang des Strings entfernt werden. Wie das passiert ist eigentlich 
völlig Schnuppe, es sei denn ich hab Bugs an der Stelle oder es ist so 
Schei*e implemtiert, dass es wirklich langsam wird.

Jobst Q. schrieb:
> Auch bei mir steht
>
> while(*s==' '||*s=='\t')s++;
> return s;
>
> nur in meiner Funktion nextvis(). In meinen Programmen steht dann
> lediglich
>
> s=nextvis(s);

Toll, du verwirfst also mit deinem Code den Startzeiger auf deinen 
Speicher. Der geistert dann als Memory Leak für den Rest der 
Programmlaufzeit durch deinen Heap...... Ich lass das einfach mal 
unkommentiert.

[Karl (Gast)]

Jobst Q. schrieb:
> Und wenn TrimStart() nicht in der verwendeten Klassenbibliothek
> vorhanden ist?

Kann man mit Vererbung eine neue Klasse erzeugen und die Methode 
Implementieren?

[Karl (Gast)]

Jobst Q. schrieb:
> Der Name sagt vielleicht, was passieren soll, aber nicht, was wirklich
> geschieht, was alles in der Methode Trimstart drinsteckt. Was in der
> while-Zeile geschieht, ist dagegen klar für jeden, der was von C
> versteht.

Was wirklich geschieht, steht auch in einem C-Code nicht. Da kommt der 
Compiler und macht sein ding.

[Scelumbro (Gast)]

Jobst Q. schrieb:
> Der Name sagt vielleicht, was passieren soll, aber nicht, was wirklich
> geschieht, was alles in der Methode Trimstart drinsteckt. Was in der
> while-Zeile geschieht, ist dagegen klar für jeden, der was von C
> versteht.

Wenn man mal größere Frameworks verwendet hat oder auch nur in einem 
größeren Team an einem Projekt gearbeitet hat, kann man nicht mehr 
wissen was ein Funktionsaufruf aus einem anderen Projektteil genau tut. 
Er sollte es halt ordentlich tun, sorgfältig dokumentiert und ohne 
unbekannte Nebenwirkungen.

[Jobst Q. (joquis)]

nicht"Gast" schrieb:
>> s=nextvis(s);
>
> Toll, du verwirfst also mit deinem Code den Startzeiger auf deinen
> Speicher. Der geistert dann als Memory Leak für den Rest der
> Programmlaufzeit durch deinen Heap...... Ich lass das einfach mal
> unkommentiert.

Deine unsinnigen Unterstellungen will ich mal nicht unkommentiert 
lassen.
Wo steht denn, dass s der Startzeiger auf einen Speicher ist?

s steht für sourcepointer ist nach bewährter Tradition von 
Kernighan&Ritchie ein Lesezeiger, der ständig bewegt wird. Der 
entsprechende Schreibzeiger ist t für targetpointer.

Leerzeichen können ja nicht nur am Anfang einer Zeile stehen. Würdest du 
dann jedesmal einen neuen String anlegen?

Der Speicher für Stringverarbeitung heißt bei mir meistens buf und liegt 
als lokale Variable auf dem Stack. Oder ist global und fängt dann mit 
einem Großbuchstaben an. Wozu sollte man Speicher alloziieren, wenn es 
garnicht nötig ist?

[Rolf M. (rmagnus)]

Jobst Q. schrieb:
> Der Name sagt vielleicht, was passieren soll, aber nicht, was wirklich
> geschieht, was alles in der Methode Trimstart drinsteckt.

Und genau das soll er ja auch. Genau wie mich beim memcpy nur 
interessiert, dass es einen Speicherblock von A nach B kopiert, nicht 
aber, ob das jetzt durch eine simple Schleife mit byteweisem Kopieren 
oder durch ein Duff-Device oder einen DMA-Transfer oder ein vom Compiler 
inline erzeugtes für diesen Aufruf speziell optimiertes Stück Code 
gemacht wird.

> Es ging nicht um die kürzeste Schreibweise, sondern um die kürzeste
> Ausführungszeit, und die ist gegeben, wenn nur das getan wird, was für
> die Aufgabe nötig ist.

Da Stringhandling in den wenigsten Progammen der Flaschenhals ist, 
wollen die meisten lieber ein komfortable als eine maximal schnelle 
Stringverarbeitung.

[nicht"Gast" (Gast)]

Jobst Q. schrieb:
> s steht für sourcepointer ist nach bewährter Tradition von
> Kernighan&Ritchie ein Lesezeiger, der ständig bewegt wird. Der
> entsprechende Schreibzeiger ist t für targetpointer.

Uii,

er hat ein C Buch zu Hause stehen. Da bin ich ja total beeindruckt. So 
ein Vollchecker, ein Profi, ein Vollnerd. Wenn du jetzt noch behauptest, 
dass du schon mal in den Source von Linux geschaut (auch immer ein 
beliebtes Totschlagargument) dann verneige ich mich vor Dir.

</Sarkasmus> (nur zur Sicherheit)

Genug der Schmeicheleien. Man kan hier nur das bewerten, was man lesen 
kann.
BTW: getVis ist ein schlecht gewählter Name. Da sind die Buchstaben an 
der falschen Stelle gespart.

[Stefan K. (stefan64)]

@nicht"Gast":

Auf die Gefahr hin, daß ich mich wiederhole:
Kannst Du solche persönlichen Angriffe bitte unterlassen? Solche 
argumentlosen Posts zerstören einen interessanten Thread.

Stefan

[nicht"Gast" (Gast)]

Stefan K. schrieb:
> Auf die Gefahr hin, daß ich mich wiederhole:
> Kannst Du solche persönlichen Angriffe bitte unterlassen? Solche
> argumentlosen Posts zerstören einen interessanten Thread.

kann man geteilter Meingung sein, aber hast ja in Summe Recht.

// Versöhnungskeks rüber reich.

[Stefan K. (stefan64)]

Vielen Dank :-)

[Jobst Q. (joquis)]

nicht"Gast" schrieb:

> BTW: getVis ist ein schlecht gewählter Name. Da sind die Buchstaben an
> der falschen Stelle gespart.

Als Oberlehrer sollte man wenigstens lesen können. Meine Funktion heißt 
nextvis und gibt einen Zeiger auf das nächste sichtbare Zeichen zurück. 
PointerToNextVisibleChar sagt da auch nicht mehr, macht aber einen 
großen Mehraufwand beim Schreiben und Lesen des Quelltextes.

TrimStart sagt da noch weniger aus. Gibt es auch eine TrimStop Funktion?

Und was hast du sonst noch für Sorgen?

[D. I. (Gast)]

Jobst Q. schrieb:
> nextvis und gibt einen Zeiger auf das nächste sichtbare Zeichen zurück.
> PointerToNextVisibleChar sagt da auch nicht mehr, macht aber einen
> großen Mehraufwand beim Schreiben und Lesen des Quelltextes.

Von CleanCodeDevelopment hast du offensichtlich noch nichts gehört.

Jobst Q. schrieb:
> TrimStart sagt da noch weniger aus. Gibt es auch eine TrimStop Funktion?

TrimEnd

[nicht"Gast" (Gast)]

Jobst Q. schrieb:
> nicht"Gast" schrieb:
>
>> BTW: getVis ist ein schlecht gewählter Name. Da sind die Buchstaben an
>> der falschen Stelle gespart.
>
> Als Oberlehrer sollte man wenigstens lesen können. Meine Funktion heißt
> nextvis und gibt einen Zeiger auf das nächste sichtbare Zeichen zurück.
> PointerToNextVisibleChar sagt da auch nicht mehr, macht aber einen
> großen Mehraufwand beim Schreiben und Lesen des Quelltextes.
>
> TrimStart sagt da noch weniger aus. Gibt es auch eine TrimStop Funktion?
>
> Und was hast du sonst noch für Sorgen?

Jobst Q. schrieb:
> TrimStart sagt da noch weniger aus. Gibt es auch eine TrimStop Funktion?

nein, aber eine TrimEnd() und eine Trim(). Die Namensgebung kannst du 
mir nicht anlasten, beschwer dich bei MS^^

Um mal zum Topic zurück zu kommen. Das schöne an der String Klasse in 
dem Fall ist einfach, das die IDE gut parsen kann welche Methoden die 
Klasse hat und über Intellisense (wie das bei Eclipse und QT Designer 
benannt ist, weiß ich nicht, aber die beiden können das auch sehr gut) 
die möglichen Methoden/Properties, oder was sonst noch anfällt, 
hilfsbereiterweise anzeigen kann.

Um das mal zu Erläutern..

du hast einen
string foo = "nüscht";

wenn du jetzt "foo." eintippst, dann bringt die VS eine Liste mit 
vorschlägen, was du mit deinem foo so alles anstellen kannst.

Das geht mit C sourcecode einfach deutlich schlechter, da keine 
"offiziellen" Zusammenhänge erkennbar sind. Da kann dir die IDE 
höchstens Vorschläge für den Funktionsnamen machen. Zusammenhänge sind 
deutlich schwerer darstellbar.

[nicht"Gast" (Gast)]

nicht"Gast" schrieb:
>> Als Oberlehrer sollte man wenigstens lesen können. Meine Funktion heißt
>> nextvis und gibt einen Zeiger auf das nächste sichtbare Zeichen zurück.
>> PointerToNextVisibleChar sagt da auch nicht mehr, macht aber einen
>> großen Mehraufwand beim Schreiben und Lesen des Quelltextes.

ach, vergessen...

'Schulterzuck'

[Tom (Gast)]

Jobst Q. schrieb:
> großen Mehraufwand beim Schreiben

Wenn man mit Notepad entwickelt.

[Jobst Q. (joquis)]

Tom schrieb:
> Jobst Q. schrieb:
>> großen Mehraufwand beim Schreiben
>
> Wenn man mit Notepad entwickelt.

Freiwillig benutze ich keine Microsoft-Produkte.

Aber auch beim Lesen mag ich keine Monsternamen. 7 Buchstaben sind 
schneller zu lesen als 30 und der Zeitaufwand zu überprüfen, ob alle 
Buchstaben richtig sind, steigt fast exponentiell.

[nicht"Gast" (Gast)]

Jobst Q. schrieb:
> Freiwillig benutze ich keine Microsoft-Produkte.
>
> Aber auch beim Lesen mag ich keine Monsternamen. 7 Buchstaben sind
> schneller zu lesen als 30 und der Zeitaufwand zu überprüfen, ob alle
> Buchstaben richtig sind, steigt fast exponentiell.

Was benutzt du denn für einen Editor zum programmieren. Die meisten 
können wenigstens einfache Auto Vervollständigung. Da sollte die Länge 
des Bezeichners egal sein.

[Jobst Q. (joquis)]

Rolf M. schrieb:
> Da Stringhandling in den wenigsten Progammen der Flaschenhals ist,
> wollen die meisten lieber ein komfortable als eine maximal schnelle
> Stringverarbeitung.

Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung 
bestehen. Programme, die Textdateien einlesen und andere ausgeben. 
Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen 
Mensch und Maschine, etwas was beide verstehen.

Für mich ist die C-Stringbearbeitung nicht nur schneller, sondern auch 
komfortabler als die Arbeit mit Stringobjekten. Mit diesen ist es wie 
mit Stützrädern bei Fahrrädern, wenn man Radfahren kann, sind sie keine 
Hilfe, sondern Behinderung.

[nicht"Gast" (Gast)]

Jobst Q. schrieb:
> Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung
> bestehen. Programme, die Textdateien einlesen und andere ausgeben.
> Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen
> Mensch und Maschine, etwas was beide verstehen.

Hast du das mal durch einen Profiler laufen lassen? Die IO Operationen 
sind doch um Welten langsamer als die Bearbeitung der Strings.

[Rolf M. (rmagnus)]

Jobst Q. schrieb:
> Rolf M. schrieb:
>> Da Stringhandling in den wenigsten Progammen der Flaschenhals ist,
>> wollen die meisten lieber ein komfortable als eine maximal schnelle
>> Stringverarbeitung.
>
> Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung
> bestehen. Programme, die Textdateien einlesen und andere ausgeben.
> Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen
> Mensch und Maschine, etwas was beide verstehen.

Und du hast verifiziert, dass die Nutzung einer Stringklasse in deinem 
Programm ein Flaschenhals wäre? Oder vermutest du das nur (alias 
"premature optimization")?

> Für mich ist die C-Stringbearbeitung nicht nur schneller, sondern auch
> komfortabler als die Arbeit mit Stringobjekten.

Mir würde wirklich keine Sprache einfallen, in der Stringhandling so 
unkomfortabel ist wie in C.
Ich finde jedenfalls ein

string c = a + b;

wesentlich komfortabler (und weniger fehleranfällig) als ein

char* c = malloc(strlen(a) + strlen(b) + 1);
strcpy(c, a);
strcat(c, b);
// Plus später daran denken, den Speicher wieder freizugeben

> Mit diesen ist es wie mit Stützrädern bei Fahrrädern, wenn man Radfahren
> kann, sind sie keine Hilfe, sondern Behinderung.

[Borislav B. (boris_b)]

Rolf M. schrieb:
> Mir würde wirklich keine Sprache einfallen, in der Stringhandling so
> unkomfortabel ist wie in C.

Wie würde wohl ein

myString = myString.Replace("Hund", "Salamander");

in C aussehen? Uaah, schauder...
Da lobe ich mir doch die moderne, objektorientierte und effiziente 
Stringbehandlung, wie sie z.B. C# bietet.

[W.S. (Gast)]

Rolf M. schrieb:
> Mir würde wirklich keine Sprache einfallen, in der Stringhandling so
> unkomfortabel ist wie in C.

Da sprichst du mir aus der Seele.

Naja, C kennt strenggenommen eigentlich überhaupt keine Strings. Und 
selbst das, was salopp mit char bezeichnet wird, ist eigentlich kein 
Textzeichen, sondern eine Integer-Variable. Naja, Steinzeit eben. Aber 
wir scheinen unsere Faustkeile ja zu lieben...

W.S.

[Jobst Q. (joquis)]

Boris P. schrieb:
> Wie würde wohl einmyString = myString.Replace("Hund", "Salamander");
> in C aussehen? Uaah, schauder...

Ganz einfach:

s=StrReplace(s,"Hund","Salamander");

Reine Formsache.

[(prx) A. K. (prx)]

Jobst Q. schrieb:
> Ganz einfach:
> s=StrReplace(s,"Hund","Salamander");
> Reine Formsache.

Klappt besonders gut mit
  char b[100] = ...
  char *s = StrReplace(b, "Hund", "Katze");
  s = StrReplace(s, "Salamander", "Krokodil");

[Borislav B. (boris_b)]

Jobst Q. schrieb:
> Ganz einfach:
> s=StrReplace(s,"Hund","Salamander");
> Reine Formsache.

Tja, fehlt nur noch die Implementierung...

[nenene (Gast)]

A. K. schrieb:
> Klappt besonders gut mit
>   char b[100] = ...
>   char *s = StrReplace(b, "Hund", "Katze");
>   s = StrReplace(s, "Salamander", "Krokodil");

So ist es m.M.n falsch. StrReplace ruft free(b) oder realloc auf (muss 
es, da 'Katze' länger als 'Hund' ist); und ich vermute ein free auf ein 
lokale Variable führt zu undefiniertem Verhalten.

[(prx) A. K. (prx)]

nenene schrieb:
> So ist es m.M.n falsch.

Eben. ;-)

[Le X. (lex_91)]

Jobst Q. schrieb:
> Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung
> bestehen. Programme, die Textdateien einlesen und andere ausgeben.
> Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen
> Mensch und Maschine, etwas was beide verstehen.

Solche Helferleins kennt jeder Programmierer, die schreibt man sich in 
der Regel in Python oder Ähnlichem.

Aber wenn man nur nen Hammer kennt...

[Carl D. (jcw2)]

Jobst Q. schrieb:
> Rolf M. schrieb:
>> Da Stringhandling in den wenigsten Progammen der Flaschenhals ist,
>> wollen die meisten lieber ein komfortable als eine maximal schnelle
>> Stringverarbeitung.
>
> Ich habe mehrere Programme, die zum größten Teil aus Stringbehandlung
> bestehen. Programme, die Textdateien einlesen und andere ausgeben.
> Strings bzw Texte sind nun mal eine wichtige Schnittstelle zwischen
> Mensch und Maschine, etwas was beide verstehen.
>
> Für mich ist die C-Stringbearbeitung nicht nur schneller, sondern auch
> komfortabler als die Arbeit mit Stringobjekten. Mit diesen ist es wie
> mit Stützrädern bei Fahrrädern, wenn man Radfahren kann, sind sie keine
> Hilfe, sondern Behinderung.

Richtige Kerle benutzen für Strings:
REPNZ MOVS
REPNZ SCAS
...
Da sieht man gleich, was da passiert.

Oder so ;-)

[HVV (Gast)]

aber vorher bitte ecx, esi, edi laden und das direction flag 
setzen/löschen.....

[Carl D. (jcw2)]

HVV schrieb:
> aber vorher bitte ecx, esi, edi laden und das direction flag
> setzen/löschen.....

Ja, das konnt ich alles mal. Vor Jahrzehnten. Als man PC-C-Compiler 
nichtmal für viel Geld kaufen konnte und std::string noch nicht 
existierte. Wobei ich zum ein paar Textfiles aufmischen heute auch 
Python benutzen würde (und vereinzelt hab). Aber warum soll man sich 
nicht das Leben schwer machen ;-)

[(prx) A. K. (prx)]

Carl D. schrieb:
> Als man PC-C-Compiler nichtmal für viel Geld kaufen konnte

Der erste C Compiler für DOS-PCs kam immerhin schon 1982.

[(prx) A. K. (prx)]

Carl D. schrieb:
> Richtige Kerle benutzen für Strings:

Und Waschlappen machten es so:
https://www.cs.auckland.ac.nz/references/macvax/op-codes/Instructions/movc.html

[Carl D. (jcw2)]

A. K. schrieb:
> Carl D. schrieb:
>> Richtige Kerle benutzen für Strings:
>
> Und Waschlappen machten es so:
> https://www.cs.auckland.ac.nz/references/macvax/op-codes/Instructions/movc.html

Ja, wenn sie sich ne Vax leisten konnten, oder Assi an der Uni waren ;-)

1982 hatte ich nur ein z80-CP/M Board zur Verfügung. Und irgendwann eine 
TP-Raubkopie.

[(prx) A. K. (prx)]

PS: Die wirklich harten Kerle machen es so, dass es bei jeder 
Stringlänge und jedem Alignment auf jedem x86 Prozessor der letzten 30 
Jahre in jeweils kürzestmöglicher Zeit funktioniert!

[Carl D. (jcw2)]

A. K. schrieb:
> PS: Die wirklich harten Kerle machen es so, dass es bei jeder
> Stringlänge und jedem Alignment auf jedem x86 Prozessor der letzten 30
> Jahre in jeweils kürzestmöglicher Zeit funktioniert!

Genau das überlasse ich heute gern den harten Burschen, die den GCC 
nebst glibc und STL zusammenschrauben. Ich hab nämlich scon lang den 
Überblick über intels/AMDs CPU Zoo verloren. Und dann hab ich auch noch 
ARMs im Einsatz. War das schön früher auf der Mainframe. Ein fast in 
Stein gemeißelter Befehlssatz. Und heute: "welche Vektoreinheiten hätten 
sie denn gern?" "ich nehm die Blaue".

[chris_ (Gast)]

>Genau das überlasse ich heute gern den harten Burschen, die den GCC
>nebst glibc und STL zusammenschrauben.

Das sehe ich genau so. Deshalb verstehe ich das hier auch nicht so 
richtig:

http://www.heise.de/developer/meldung/Programmiersprachen-Ranking-Assembler-steigt-neu-in-TIOBEs-Top-10-ein-3263014.html

[Mark B. (markbrandis)]

Moby A. schrieb im Beitrag #4645665:
> Vielleicht solltest Du Dir dazu mal vergegenwärtigen, für welches
> Einsatzfeld Asm vermehrt zum Einsatz kommt. Da gehts eben nicht um PCs,
> sondern um
>
>> der wachsende Bedarf
>> an Software für Kleinstgeräte ... , wie sie im Internet der Dinge
>> zahlreich zum Einsatz kommen.

TCP/IP Kommunikation in Assembler? Na dann viel Spaß.

[Yalu X. (yalu) (Moderator)]

Führt die Assembler-Diskussion bitte in diesem Thread fort:

  Beitrag "Assembler wieder auf dem Weg nach vorn"

Dort ist sie besser aufgehoben.