Wie wird in C gekapselt?
-
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.
-
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
-
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?
-
Hi
Nein das habe ich nicht geschriben !
lowbyte
-
Hi
Noch was, richtiger Hardcore C++ Code sieht in meinen Augen sehr unübersichtlich aus ! Da schreibe ich lieber ein bisschen mehr, und verstehe was hinter her abgeht.
lowbyte
-
~Maulheld schrieb:
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?
OK, momentan werden die meisten Projekte in C (Platz 1) und Java (Platz 2) umgesetzt, in der Statistik kommt allerdings die Projektgröße nicht zur Geltung.
Ungeachtet dessen spielt die LOC- Größe immer noch keine Rolle, wie die iX- Kernels zeigen. Thorvalds hat sich mehrfach begründet dagegen verwehrt, auch nur eine Zeile C++ in den Kernel zu lassen, das finde sogar ich zu kategorisch.omfg noob schrieb:
lol. bitte bleib bei c und laber nicht blöd vor dich hin.
Ich hab einen Tasking- Compiler und einen GCC auf zwei Brettchen geworfen, die ich gerade in der Schublade hatte (eins war ein SH8, anderes weiß ich nicht mehr). Das konnte ich gerade mal parallel ein paar hundert Zeilen weit compilieren, dann war das vorbei, weil ich mir was aus der STL gepflückt hatte, was unter Extension lief und der andere Compiler nichtmal bearbeiten wollte. Das war zwar nur exemplarisch, aber ich hab's überprüft und nicht vertieft, sondern drauf gepfiffen und bin bei C geblieben - bist Du jetzt glücklich?
-
Hi
Thorvalds hat sich mehrfach begründet dagegen verwehrt, auch nur eine Zeile C++ in den Kernel zu lassen, das finde sogar ich zu kategorisch.
Warum C++ hat in einem Kernel nix verloren.
-
Warum C++ hat in einem Kernel nix verloren.
Warum nicht? Wenn man RTTI, Exceptions, etc. mal außen vorlässt?
MfG SideWinder
-
lowbyte_ schrieb:
Warum C++ hat in einem Kernel nix verloren.
Naja, aber seine Begründungen dagegen sind z.T. schon etwas hanebüchen.
Ich bin ein gebranntes Kind in Sachen Compilerbugs und erfahrungsgemäß macht man sich um so abhängiger von dem, was ein Compiler macht, je höher dessen Abstraktionsgrad ist. Insofern ist mir eine C-Lib lieber, die ich selber durchforsten kann, als mich blind darauf zu verlassen, daß die Blackbox wirklich das Richtige aus meiner Source bastelt.
Wäre meine Argumentation, aber ja, richtig, C++ im Kernel eher nicht, v.A., weil ich keine Notwendigkeit dafür sehe.Da fällt mir ein, was macht denn unsere PrettyOS- Crew gerade, ich glaube, die haben C++ genommen oder täusche ich mich da?
-
Hierfür wird C aktuell eingesetzt alles andere sind Hobbyprojekte oder dient dem Lernen. Keiner würde auf die Idee kommen mit C eine mittlere bis große Desktopanwendung zu programmieren.
Wenn es wirklich anders sein sollte dann ist es ja wohl kein Problem für die "Maulhelden" hier den Wikieintrag zu ändern. Also entweder daß so hinnehmen oder Wiki ändern mit stichhaltigen Argumenten.
Und los ihr Schaumschläger http://de.wikipedia.org/wiki/C_%28Programmiersprache%29#Verwendung