Wie wird in C gekapselt?

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.

berniebutt

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

pointercrash**

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

Bashar

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.

pointercrash**

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.

DrGreenthumb

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.

berniebutt

Da haben wir offensichtlich wieder so eine Purismus-Debatte C vs. C++. Muss nicht sein und bringt wenig!

"Möglichst C++ einsetzen, weil sicherer und transparenter" ist klar. Aber, für viele einfache Zwecke sind z.B. die alten C-Strings und deren Funktionen oft genauso gut oder sogar besser als std::string. Wer WinApi ohne MFC, VCL, ... einsetzt, bleibt ohnehin sehr nahe an C, wird aber für eigene Teilaufgaben C++ nehmen.

daddeldu! - ich habe fertig! :p

pointercrash**

rogerpilco schrieb:

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

Schon ein wenig, aber eigentlich wollte ich darauf hinaus, daß es im Prinzip beliebig ist, von welcher Ebene man aus eine andere Form der Abstraktion zu erreichen versucht.

rogerpilco schrieb:

In C gut zu kapseln ist wohl weit mehr ein Krampf als in C++ was ähnliches zu entwickeln.

C bietet etliche Mechanismen, um Daten zu kapseln und Funktionspointer gehören zu den Basistypen. Da ist kein Krampf bei, sondern ich finde es sogar übersichtlicher.

rogerpilco schrieb:

Vergiss nicht du kannst auch C mit Klassen programmieren

Das wäre mir aber neu.

rogerpilco schrieb:

... es ist nicht schön aber durchaus vom Erfinder der Sprache auch so gewollt.

"C mit Klassen" ist eine Mißbrauchsmethode eines C++ Compilers. Das sind so die Projekte des Grauens, wenn C- Programmierer anfangen und erstmal eine abstrakte Klasse anlegen und dann so alles reinwerfen, was ihnen einfällt.

rogerpilco schrieb:

In C was zu entwickeln macht halt nach einer gewissen Größe bei weiten nicht so viel Spaß wie mit C++.

Das ist doch blanker Humbug. Es ist genauso möglich, in C++ chaotische Klassenwüsten aufzuziehen, wie in C ein paar gepflegte Libs anzulegen. Das ist kein Sprachmerkmal, sondern eine Frage der persönlichen Methodik.

rogerpilco schrieb:

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.

Ach ja? Selbst, wenn Du mehrere C++- Compiler findest, die Portierungsfalle STL verdirbt den Spaß. C++ ohne STL, da fehlt dann schon recht viel und was überbleibt, brauch' ich nicht unbedingt.

Tim schrieb:

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...

Ja, der Umgang mit den GObjects sieht schon recht merkwürdig, zumindest unhandlich aus. Insofern wundere ich mich eher, daß es nicht mehr "ich mach's toller als GLib"- Typen gibt.
Objective-C sieht da wirklich netter aus, aber das Problem ist die allgemein nicht vorhandene Compilerunterstützung.

Pass mal auf du Maulheld,

wenn irgendwas an deinem Gebrabbel dran wäre dann nenne doch mal die ach so großen neuen Projekte wo die Entwickler lieber C anstelle von C++ einsetzten?

Ich bin mal sehr gespannt auf die Liste.

pointercrash() schrieb:

Ach ja? Selbst, wenn Du mehrere C++- Compiler findest, die Portierungsfalle STL verdirbt den Spaß. C++ ohne STL, da fehlt dann schon recht viel und was überbleibt, brauch' ich nicht unbedingt.

lol. bitte bleib bei c und laber nicht blöd vor dich hin.

Hi

Ich gebe pointercrash() recht !
Ich beschreibs mal so... wenn ich faul bin benütze ich C++ ,wen ich Programmieren will und dabei noch was lernen kann, kann ich auf OOP verzichten.
Ich selber mag OOP nicht. Abstraktion möchtegern kapselung.. abgesehen von der übersicht. Wie pointercrash() gesagt hat auch in C kann ein Project übersichlich gestaltet werden, und sogar noch besser.

@maulheld

Pass mal auf du Maulheld,

wenn irgendwas an deinem Gebrabbel dran wäre dann nenne doch mal die ach so großen neuen Projekte wo die Entwickler lieber C anstelle von C++ einsetzten?
Ich bin mal sehr gespannt auf die Liste.

nanah ..

Zum bsp. Linux - Unix - Windows. Das sind riesige Projekte, zwar nicht zu 100% in C geschrieben, do sicher zu 80%.

Wenn du schon dein Maul aufreisst, dann bitte mit deinem Nick.

lowbyte

lowbyte_ schrieb:

Ich gebe pointercrash() recht !

bei allen argumenten die er in seinem letztem post geschrieben hat?