Wie wird in C gekapselt?
-
Meine Tante Puhvogel in Schleswig-Holstein hat immer gesagt: "Jung, diene Sorgen un Otje sien Geld!"
Hattu C++? Muttu nehmen, wenn du kapseln willst!
Wer es will kriegt OOP auch mit reinem C hin. Versucht das aber mal mit einem alten BASIC-Interpreter nur mit gotos. 
Oder anders gefragt: "Hat da jemand den Schuss nicht gehört?" 
-
DrGreenthumb schrieb:
player424 schrieb:
C ist für Funktionale Programmierung geschaffen worden.
ja nee is klar
btw: Es gibt auch Pizza und Schnitzel für den Toaster. Da sollte Kuchen doch auch gehen. Aber da passt die Analogie noch weniger.
Zumindest aber kann man Kuchen im Kühlschrank backen.
-
berniebutt schrieb:
Meine Tante Puhvogel in Schleswig-Holstein hat immer gesagt: "Jung, diene Sorgen un Otje sien Geld!"
Hattu C++? Muttu nehmen, wenn du kapseln willst!
Wer es will kriegt OOP auch mit reinem C hin. Versucht das aber mal mit einem alten BASIC-Interpreter nur mit gotos. Oder anders gefragt: "Hat da jemand den Schuss nicht gehört?" Besser hätte man es kaum formulieren können
-
player424 schrieb:
berniebutt schrieb:
Meine Tante Puhvogel in Schleswig-Holstein hat immer gesagt: "Jung, diene Sorgen un Otje sien Geld!"
Hattu C++? Muttu nehmen, wenn du kapseln willst!
Wer es will kriegt OOP auch mit reinem C hin. Versucht das aber mal mit einem alten BASIC-Interpreter nur mit gotos. Oder anders gefragt: "Hat da jemand den Schuss nicht gehört?" Besser hätte man es kaum formulieren können
also nochmal zusammengefasst: In C kann man nicht kapseln oder OOP'en und man soll gefälligst eine andere Sprache nehmen.
-
Wenn man gar mit Assembler OOP-Konzepte umsetzen kann, sollte das mit C auch möglich sein. So ähnlich wurde C++ damals vor etwa 20 Jahren auch entwickelt.
Man hatte C und man kannte damals schon andere OOP-Sprachen.
Erst hat man versucht mit C die OOP nachzubilden und war nicht ganz glücklich.
Dann hat man Zusatztools entwickelt, die es ermöglichten mit einem C-Compiler einfacher C++ Quelltext zu übersetzen.
Kurz danach oder etwa zur gleichen Zeit kamen auch die erste C++ Compiler ( Zortech ? ) auf den Markt.
Etwa 10 Jahre hat es dann gebraucht bis dann C++ nicht nur eine Erweiterung von C war. Ob das nun mangelnde Absprache der Normenkommitees war oder Absicht, wer weiss
Kurz vor der Jahrtausendwende begannen dann die ersten C++ Gurus von einer eigenständigen Sprache C++ zu sprechen.MfG f.-th.
-
f.-th. schrieb:
Wenn man gar mit Assembler OOP-Konzepte umsetzen kann, sollte das mit C auch möglich sein.
Ja.
f.-th. schrieb:
So ähnlich wurde C++ damals vor etwa 20 Jahren auch entwickelt.
Vor 30 Jahren.
f.-th. schrieb:
Man hatte C und man kannte damals schon andere OOP-Sprachen.
[ironie]Oh ja, sehr viele. [/ironie]Simula und Smalltalk. Aber Struppi kannte Simula.
f.-th. schrieb:
Erst hat man versucht mit C die OOP nachzubilden und war nicht ganz glücklich.
Ein Satz, den ich so stehen lassen kann.
f.-th. schrieb:
Dann hat man Zusatztools entwickelt, die es ermöglichten mit einem C-Compiler einfacher C++ Quelltext zu übersetzen.
Naja. Nein. Er hat einen Präprozessor geschrieben, der aus C++-Code C-Code macht. Oder meinstest Du das mit deinem sprachlichen Konstrukt?
f.-th. schrieb:
Kurz danach oder etwa zur gleichen Zeit kamen auch die erste C++ Compiler ( Zortech ? ) auf den Markt.
Ja, zwei Jahre oder so.
f.-th. schrieb:
Etwa 10 Jahre hat es dann gebraucht bis dann C++ nicht nur eine Erweiterung von C war. Ob das nun mangelnde Absprache der Normenkommitees war oder Absicht, wer weiss
Kurz vor der Jahrtausendwende begannen dann die ersten C++ Gurus von einer eigenständigen Sprache C++ zu sprechen.Nö, gar nicht. Aber schwierig zu belegen. Ich such mal.
-
Man sollte nicht versuchen in C OOP zu machen dafür gibt es C++. Wenn der letzte Mikrocontroller auch C++ kann hat sich das mit C eh erledigt. Ausser zur Pflege von alter Software wird C dann nicht mehr benötigt. ja selbst GPUs verstehen schon C++. Der Trend hin weg von C zu C++ ist also auch für die kleinsten Chips zu erkennen. Mal ehrlich vermissen wird es niemand, jede Sache die mit C geht geht auch in C++ wenn man es denn unbedingt braucht, nur das man hier wieder den Vorteil hat es richtig gut kapseln zu können.
-
Na, ohne viel nachzusehen ging das doch mit der Trefferquote im vorigen Beitrag
Weiss nicht ob ich das Tool noch hab und das Medium noch lesbar ist, das dem C-Compiler von Microsoft ( ? ) etwa 1990 zu C++ verhelfen sollte. Hab damals aber nicht viel oder gar nicht damit gespielt.
MfG f.-th.
-
volkard schrieb:
Allerdings soll man sich nicht mit langsamen und undurchschaubaren Tricks in C eine kleine Privatsprache bauen, die beinahe C++ riecht, aber dann doch ganz anders gekocht werden muß.
Einfach C nehmen.signed.
-
Es ist gerade die hervorragende Leistung der Entwickler von C++, die weitere Einsatzfähigkeit von C voll beibehalten zu haben - auch gemischt!
Also nimmt man Kapseln und OOP von C++ und - wenn man will - anderes von C. :p
-
Hi
Also wen man schon OOP will, sollte man doch gleich C++ nehmen.
Klar kann man soetwas in C auch realisieren (OOP), doch man muss doch nicht gleich das Rad neu erfinden.
Mit Beiden Programmiersprachen kann man alles erreichen, das sollte ja klar sein.
Doch geht es ja hier um OOP und Kapselung. Und wen man jetz ein reines C Project etwicklen will, das dazu noch recht gross wird, und ein OOP aufbau haben soll, dann ist die Sprache C definitiv das falsche. Da es schnell unübersichtlich wird und viel zu viel Code entsteht der durch die erreichung von OOP Code in C erreicht werden will.
Meine Ansichten sind daher, wer OOP programmieren will soll auch eine Sprache lernen oder einsetzen die OOP mit sich bringt. C++ / oder was auch immer.
Ich selber bin ein C nar. und nur weil man mit C nicht OOP programmieren kann ( wer nicht einen eigenen objektorientierten Ansatz programmieren will) heisst das noch lange nicht das man C verbannen soll ! Oder hat jemand von euch schon mal einen microcontroller mit C++ angesteuert ? Ausser Symbian und ... kenne ich auch kein OS das in C++ geschriben wurde. Sondern mit C und Assembler. Von wegen C verbannen. Und zum schluss... C++ wurde auch mit C und Assembler entwickelt ... mit was sonnst!lowbyte
-
Tim schrieb:
volkard schrieb:
Allerdings soll man sich nicht mit langsamen und undurchschaubaren Tricks in C eine kleine Privatsprache bauen, die beinahe C++ riecht, aber dann doch ganz anders gekocht werden muß.
Einfach C nehmen.signed.
Mal ketzerisch gefragt, wo endet C, wo beginnen die schmutzigen "Privatsprachen- Tricks" für Euch?
In eine struct functionpointer und Datenblock (als union of structs z.B) zu packen, ist ja durchaus probat, erfüllt einen gewissen Kapselungsanspruch, aber auch andere Kennzeichen der OOP. Kann man viel drumrum stricken, ohne das Schema in seiner Konsistenz zu stören. Sieht als ASM aufgelöst nicht viel anders aus, als "echte OOPs" (hab' allerdings zuletzt Delphi vor 10 Jahren zerlegt, weiß nicht, wie's bei aktuellem Zeug ausschaut), in der Source differiert's deutlicher, meist mehr Schreibarbeit auf C- Basis.
Der Vorteil für mich besteht darin, daß ich damit Sachen bauen kann, die sich mit minimalem Aufwand portieren lassen, solange ich bei C89 bleibe, wobei ich zugeben muß, daß ich mich normalerweise nicht um die OS- Basis schere, sondern auf Lib- Basis auf Controllerhardware zugreife. Die Erfahrungen, die ich da mit C++ gesammelt habe, waren eher abschreckend, weil das Einstiege in Mixprojekte C/C++ waren. Meist hatten sich da wohl schon zwei oder drei Entwickler zuvor erschossen.
Naja, und die Abdeckung von C++- Compilern für kleine Embeddeds ist wirklich noch nicht toll.Also, was soll dagegen sprechen, sich mit C sowas zurechtzuschnitzen und wo zieht ihr die Grenze?
berniebutt schrieb:
Es ist gerade die hervorragende Leistung der Entwickler von C++, die weitere Einsatzfähigkeit von C voll beibehalten zu haben - auch gemischt!
Sowas hatte ich befürchtet
-
Ich glaube hier erliegen einige einem Denkfehler. Wenn man in C ein Objektsystem baut, dann nähert man sich nicht unbedingt an C++ an. Der Einwurf, man solle doch gleich C++ nehmen, gilt natürlich nur, wenn das Objektsystem dem von C++ ähnelt.
-
Bashar schrieb:
Ich glaube hier erliegen einige einem Denkfehler. Wenn man in C ein Objektsystem baut, dann nähert man sich nicht unbedingt an C++ an. Der Einwurf, man solle doch gleich C++ nehmen, gilt natürlich nur, wenn das Objektsystem dem von C++ ähnelt.
Das ist schon sehr "fielosofisch" oder wie Garfield das mal sagte. Letzlich kommen ASM- instructions raus, also ein Prozessor weiß davon gar nix.
Ich halte mich nichtmal bewußt von C++ fern, sondern nur des Gedankens wegen, daß ich für kleinere MCUs nichtmal gegen viel Geld einen Compi kriege. Dafür kann ich in fast alle C- Compis mit ein paar #ifdef s meinen Kram unterbringen.
So, what should be wrong with it
-
Du willst nicht ernsthaft damit argumentieren das eh alles nur ASM wird. Ja wieso legen wir nicht gleich den Maschinencode im Speicher ab sind doch eh alles nur 0 und 1. *kopfschlag
In C gut zu kapseln ist wohl weit mehr ein Krampf als in C++ was ähnliches zu entwickeln. Vergiss nicht du kannst auch C mit Klassen programmieren wenn du es unbedingt brauchst, es ist nicht schön aber durchaus vom Erfinder der Sprache auch so gewollt.
In C was zu entwickeln macht halt nach einer gewissen Größe bei weiten nicht so viel Spaß wie mit C++. C++ ist nicht umsonst immer noch extrem verbreitet, gelle? Und keiner wird freiwillig ein Projekt in C hochziehen wenn auch C++ genommen werden könnte, denn das wäre ja schön blöd und ein schönes Armutszeugnis als Entwickler.
-
Hi
@basahr
Ich glaube hier erliegen einige einem Denkfehler. Wenn man in C ein Objektsystem baut, dann nähert man sich nicht unbedingt an C++ an. Der Einwurf, man solle doch gleich C++ nehmen, gilt natürlich nur, wenn das Objektsystem dem von C++ ähnelt.
Das ist natürlich klar... Doch ich glaube du wirst hier nicht einer finden, der sich seinen eigenen vollständigen OO Ansatz Programmiert.
Vieleicht ein Teil, oder dort wo es sich zumindest lohnt.Schlussendlich wie Pointercrash schrieb :
... wie Garfield das mal sagte. Letzlich kommen ASM- instructions raus, und nur das versteht ein Prozessor.
lowbyte_
-
pointercrash() schrieb:
Tim schrieb:
volkard schrieb:
Allerdings soll man sich nicht mit langsamen und undurchschaubaren Tricks in C eine kleine Privatsprache bauen, die beinahe C++ riecht, aber dann doch ganz anders gekocht werden muß.
Einfach C nehmen.signed.
Mal ketzerisch gefragt, wo endet C, wo beginnen die schmutzigen "Privatsprachen- Tricks" für Euch?
Beginnen tun sie für mich z.B. bei http://de.wikipedia.org/wiki/GLib
Das ist natürlich nicht unbedingt "privat" weil ein großes un bekanntes Projekt. Aber wenn sich nun jeder zweite C-Programmier nun seine glib bauen würde...
Anderes Beispiel sind Leute die sich zur Lebensaufgabe gemacht haben C-Programmierern mit Lisp/Scheme-Ansätzen auf den Sack zu gehen und am liebsten jedes dreckige Skalar in eine Liste packen, es könnten ja mal zwei werden und dann müsste man den Code an drei Stellen ändern...pointercrash() schrieb:
In eine struct functionpointer und Datenblock (als union of structs z.B) zu packen, ist ja durchaus probat, erfüllt einen gewissen Kapselungsanspruch, aber auch andere Kennzeichen der OOP. Kann man viel drumrum stricken, ohne das Schema in seiner Konsistenz zu stören.
Fürs Protokoll: Den ASM-Teil gelöscht.
pointercrash() schrieb:
Der Vorteil für mich besteht darin, daß ich damit Sachen bauen kann, die sich mit minimalem Aufwand portieren lassen, solange ich bei C89 bleibe, wobei ich zugeben muß, daß ich mich normalerweise nicht um die OS- Basis schere, sondern auf Lib- Basis auf Controllerhardware zugreife. Die Erfahrungen, die ich da mit C++ gesammelt habe, waren eher abschreckend, weil das Einstiege in Mixprojekte C/C++ waren. Meist hatten sich da wohl schon zwei oder drei Entwickler zuvor erschossen.
Naja, und die Abdeckung von C++- Compilern für kleine Embeddeds ist wirklich noch nicht toll.Das klingt für mich soweit nach C. Abstrahierung von HW-Spezifika um die "User"-Software einheitlich zu halten. Sollte gängige Praxis sein, ist es leider nicht.
-
Tim schrieb:
pointercrash() schrieb:
Mal ketzerisch gefragt, wo endet C, wo beginnen die schmutzigen "Privatsprachen- Tricks" für Euch?
Beginnen tun sie für mich z.B. bei http://de.wikipedia.org/wiki/GLib
Das ist natürlich nicht unbedingt "privat" weil ein großes un bekanntes Projekt. Aber wenn sich nun jeder zweite C-Programmier nun seine glib bauen würde...also glib an sich ist ok, solange es nicht zu viele leute nachprogrammieren?
Anderes Beispiel sind Leute die sich zur Lebensaufgabe gemacht haben C-Programmierern mit Lisp/Scheme-Ansätzen auf den Sack zu gehen
hast du wirklich jemals so ein Programm gesehen (ich jedenfalls nicht), oder sagst du das nur weil du in meinem geposteten Beispiel das böse Wort "sexp" gelesen hast?
-
DrGreenthumb schrieb:
Tim schrieb:
pointercrash() schrieb:
Mal ketzerisch gefragt, wo endet C, wo beginnen die schmutzigen "Privatsprachen- Tricks" für Euch?
Beginnen tun sie für mich z.B. bei http://de.wikipedia.org/wiki/GLib
Das ist natürlich nicht unbedingt "privat" weil ein großes un bekanntes Projekt. Aber wenn sich nun jeder zweite C-Programmier nun seine glib bauen würde...also glib an sich ist ok, solange es nicht zu viele leute nachprogrammieren?
O.K. im Sinne von grenzwertig akzeptabel. Ich hätte mich dagegen gesträubt sowas (mit)zuentwickeln. Man könnte ja auch gleich ObjC nehmen. Aber es ist grenzwertig akzeptabel weil ein bekanntes Projekt in das ich mich mit ausreichend Resourcen aus Internet und Buch einarbeiten kann. Wenn jeder sich ein derartiges System aufbaut ist letzteres einfach nicht mehr gegeben und es bleibt, sorry, einfach nur Hirnsuppe nach Gusto übrig.
DrGreenthumb schrieb:
Tim schrieb:
Anderes Beispiel sind Leute die sich zur Lebensaufgabe gemacht haben C-Programmierern mit Lisp/Scheme-Ansätzen auf den Sack zu gehen
hast du wirklich jemals so ein Programm gesehen (ich jedenfalls nicht), oder sagst du das nur weil du in meinem geposteten Beispiel das böse Wort "sexp" gelesen hast?
Ich habe ausreichend Leute _hier_ gesehen um zu wissen, dass es sie gibt. In der beruflichen Praxis hab ich sowas nicht gesehen, aber auch hier blieb mir, Gott sei Dank, die "ich bin soviel geiler als glib"-glib erspart.
-
Es hat schon seinen Gründe warum keine großen Projekte mehr mit reinem C gemacht werden, es sei denn es gibt nur C für die Plattform.