Wie wird in C gekapselt?

pointercrash**

~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

@pointercrash()

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.

SideWinder

Warum C++ hat in einem Kernel nix verloren.

Warum nicht? Wenn man RTTI, Exceptions, etc. mal außen vorlässt?

MfG SideWinder

pointercrash**

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

Schaumschläger schrieb:

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.

Dein Problem ist, dass du ausser "Desktop" einfach nichts kennst.

_matze

Es muss ja bei mittelgroßen bis großen Projekt nicht die Entscheidung 'nur C' oder 'nur C++' getroffen werden. Bei uns ist es so, dass der ganze UI-Kram in C++ (MFC) geschrieben ist (und leider auch noch viel LabView), die ganze Basis aber größtenteils in C. Das sind dann Dinge wie Bildverarbeitung, sonstige mathematische Funktionen, verschiedene Geräteansteuerungen usw. Bei uns müssen Daten möglichst performant in kleinen Zeitfenstern verarbeitet werden, und damals wurden Vergleichsmessungen angestellt, die ergeben haben, dass der C-Compiler unter bestimmten Umständen einfach performanteren Code ausgespuckt hat. Ob das heute immer noch so ist, weiß ich nicht. Das war vor meiner Zeit in der Firma und vermutlich so ca. 5-10 Jahre her (so lange also auch wieder nicht). Da wir die SW bald umstrukturieren werden (u.a. wird LabView endlich rausfliegen ), werden solche Tests vermutlich wieder stattfinden. Aber egal, worauf ich hinaus will, ist dass es durchaus auch in Desktopanwendungen eine Daseinsberechtigung für C geben kann, da logischerweise keine Desktopanwendung nur aus UI-Code besteht (Hello World mal ausgenommen). Von unseren 500.000 LOC (+ mehrere tausend VIs) ist ein beträchtlicher Teil in C geschrieben. Damit hätten wir also schon mal eine mittelgroße Desktop-Anwendung mit großem C-Anteil. These widerlegt! Und auch in C kann man übersichtlich programmieren und kapseln, wie schon erwähnt wurde.

Auf den Wiki-Eintrag zu verweisen, in dem ja höchstens vage eine Tendenz dargelegt wird, ohne irgendwelche konkreten Zahlen o.ä., und dann ganz selbstverständlich zu behaupten, dass natürlich "keiner auf die Idee kommen würde", finde ich jedenfalls arm.

hi
sehr gut ausgedrück. das ergänzt meine ansichten.
wie matze gesagt hat..wer sich immer auf wiki verlässt..dem kann ich nicht helfen. und für ein argument (juhu ich habe bei wiki etwas fefunden das deine posts widerlegt) finde ich arm.

lowbyte

Sagt mal könnt ihr nicht lesen

Es darum wenn man eine NEUE Anwendung mittleren bis größerem Umfangs entwickeln will was nichts mit Systemprogrammierung oder embedded zu tun dann würde Niemand auf die Idee kommen heute noch dafür C einzusetzen und diese These unterstützt auch der Wikieintrag. Alle sehen es also so ausser die Fanboys hier, is doch mal wieder komisch. Es ging auch nie um ein paar ausgelagerte Berechnungen hier zählt der Großteil der Software. Ob das nun Desktop- oder Serversoftware ist spielt keine Rolle.

Ok, welche großen Anwendungen sind denn neu mit C realisiert worden die nicht Systemprogrammierung und nicht für embedded sind? Laut eurem Getrolle müssen das ja schon eine ganze Menge sein, ich bin gespannt auf die bekannten Namen *lach Ich wette nicht mal 10% von der C++ Software wird das sein, wenn überhaupt.

Und jetzt kommen wieder das rumgedruckse ich lach mich jetzt schon krumm.

Hi

Das sind deine Ansichten ... und weil du einfach keine Argumente mehr hast, auser deinem Wiki Eintrag (du Fanboy), musst du gleich mit Beleidigungen um dich schwingen !? Du tust mir echt leid ...

Alle sehen es also so ausser die Fanboys hier, is doch mal wieder komisch. Es ging auch nie um ein paar ausgelagerte Berechnungen hier zählt der Großteil der Software. Ob das nun Desktop- oder Serversoftware ist spielt keine Rolle.

Es ging hauptsächlich mal um :Wie wird in C gekapselt ?
Aber dazu müsste man schon lesen können. (Wen du schon alles so genau nehmen willst !)

TOR(The Onion Router) ist zu bsp. ein grosse Projekt, und das ist in C geschrieben.

lowbyte

_matze

-)-)_-) schrieb:

Sagt mal könnt ihr nicht lesen

Wir schon.

Es darum wenn man eine NEUE Anwendung mittleren bis größerem Umfangs entwickeln will

Definiere 'neu'. Darf die Entwicklung vor maximal 2 Jahren begonnen haben? Oder 5? 10? Wenn jetzt irgendein Programm in einer neuen Version 10 rauskommt, ist das dann neu oder zählt die erste Version von '89?

Es ging auch nie um ein paar ausgelagerte Berechnungen hier zählt der Großteil der Software.

In meinem Beispiel (darauf beziehst du dich ja) geht es nicht um ein paar ausgelagerte Berechnungen, sondern locker 50% der ganzen SW. Reicht das oder postest du gleich, dass mindestens 60% Anteil erforderlich ist, um den C-Anteil des Projekts gelten zu lassen?

Ok, welche großen Anwendungen sind denn neu mit C realisiert worden die nicht Systemprogrammierung und nicht für embedded sind?

Sicher nicht so viele. Da wird C++ deutlich vor C kommen. Bei reinen Klickibunti-Desktop-Anwendungen kann man auch sehr gut gegen C++ argumentieren. Da gibt es mittlerweile gute Alternativen wie C# (wenn es Windows ist und nicht portabel sein muss). Aber es ging doch hier um Kapselung, und die kann natürlich auch in den von dir ausgeklammerten Bereichen vorkommen und wichtig sein. Im Übrigen habe ich mich nur dagegen gewehrt, dass "keiner auf die Idee kommt". Hatte ich auch genauso geschrieben. Wie kann man das falsch verstehen? Kannst du nicht lesen??

Alle sehen es also so ausser die Fanboys hier

Ich bin kein Fanboy. Ich bin sogar ziemlich froh, wenn wir bald viel C- und vor allem LabView-Kram loswerden und C++- und C#-lastigeren Code haben. Ich wollte nur loswerden, dass sowohl Kapselung in C als auch damit (teils oder ganz) realisierte Desktopanwendungen möglich sind.

Hi

Da stimme ich ja auch zu.. dass C++ sicher in Zukunft, und schon vor ein paar Jahre für grosse Projekte bevorzugt wird, für zumindest den grössten Teil der SW.
Aber du kannst nicht abstreiten das auch grosse Projekte in C aufgezogen werden können. Ich denke einfach das sich eine App für klick-bunti-Desktopanwendung in C++ viel leichter realisieren lässt, durch abstraktheit, weniger Programmierfehler (Bufferoverflow stack,heap), manche sagen durch die übersicht durch OOP, Team(arbeit) etc.. etc.

Im gegensatz zu C++ sehe ich bei C den performanteren Machinen-Code den ein C Compiler je nach hersteller generieren kann, (wovon wir mal von einem optimalen Source-Code ausgehen) und genau das ist der nachteil der abstrahierung/kapselung genauer gesagt der OOP.
Wie pintercrash() schon mal sagte. Ich hänge mich lieber in eine Library, anstat mich darauf zu verlassen das die Blackbox das schon hinbiegen wird.

Es lässt sich auch nicht abstreiten das in manchen Bereichen einfach C Pflicht ist, und andere Programmiersprachen nichts verloren haben (wenn es den auch möglich wäre). Und dazu gehört ne Menge !

Aber ich schweife hier schon wider mächtig vom Thema ab. Deshalb ist für mich der Thread closed. Ich denke, jede Sprache hat seine vor und nachteile. Keine Sprache ist somit wegzudenken ....

lowbyte

lowbyte_ schrieb:

Hi

Da stimme ich ja auch zu.. dass C++ sicher in Zukunft, und schon vor ein paar Jahre für grosse Projekte bevorzugt wird, für zumindest den grössten Teil der SW.

richtig

lowbyte_ schrieb:

Aber du kannst nicht abstreiten das auch grosse Projekte in C aufgezogen werden können.

Können schon, macht aber keiner mehr.

lowbyte_ schrieb:

Ich denke einfach das sich eine App für klick-bunti-Desktopanwendung in C++ viel leichter realisieren lässt, durch abstraktheit, weniger Programmierfehler (Bufferoverflow stack,heap), manche sagen durch die übersicht durch OOP, Team(arbeit) etc.. etc.

korrekt

lowbyte_ schrieb:

Im gegensatz zu C++ sehe ich bei C den performanteren Machinen-Code den ein C Compiler je nach hersteller generieren kann, (wovon wir mal von einem optimalen Source-Code ausgehen) und genau das ist der nachteil der abstrahierung/kapselung genauer gesagt der OOP.

Das ist absoluter Humbug, da von OOP nach dem Kompilieren nix relevantes übrig bleibt.

lowbyte_ schrieb:

Wie pintercrash() schon mal sagte. Ich hänge mich lieber in eine Library, anstat mich darauf zu verlassen das die Blackbox das schon hinbiegen wird.

Wer heute alles selbst mach hat verloren, dazu ist die IT zu komplex geworden.

lowbyte_ schrieb:

Es lässt sich auch nicht abstreiten das in manchen Bereichen einfach C Pflicht ist, und andere Programmiersprachen nichts verloren haben (wenn es den auch möglich wäre). Und dazu gehört eine Menge !

Eher eine kleinere Teilmenge der ganzen produzierten Software und halt in den Nischen Embedded, System und paar kleine Bibliotheken.

lowbyte_ schrieb:

Aber ich schweife hier schon wider mächtig vom Thema ab. Deshalb ist für mich der Thread closed. Ich denke, jede Sprache hat seine vor und nachteile. Keine Sprache ist somit wegzudenken ....

richtig

Hi

bewertung schrieb:

lowbyte_ schrieb:

Im gegensatz zu C++ sehe ich bei C den performanteren Machinen-Code den ein C Compiler je nach hersteller generieren kann, (wovon wir mal von einem optimalen Source-Code ausgehen) und genau das ist der nachteil der abstrahierung/kapselung genauer gesagt der OOP.
Das ist absoluter Humbug, da von OOP nach dem Kompilieren nix relevantes übrig bleibt.

Ich will dir nicht zu nahe treten, doch weisst du von was du da sprichst ?
Nah gut ich nehme das mal so hin, doch das trift nicht in jeder (Situation) zu.
Ich habe meine Satz vorhin auch nicht direkt auf die OOP bezogen.

bewertung schrieb:

lowbyte_ schrieb:

Wie pintercrash() schon mal sagte. Ich hänge mich lieber in eine Library, anstat mich darauf zu verlassen das die Blackbox das schon hinbiegen wird.
Wer heute alles selbst mach hat verloren, dazu ist die IT zu komplex geworden.

Da bin ich getrennter Meinung. Die Library muss ja nicht von mir sein.
Mir passt das Wort BLACKBOX einfach nicht

lowbyte

*john 0

pointercrash() schrieb:

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.

Wundersame These: Den Comeau Compiler bekommt man zu vertretbaren Preisen auf beliebige Plattformen portiert, wenn es dafür einen C-Compiler gibt.

pointercrash**

~john schrieb:

pointercrash() schrieb:

... daß ich für kleinere MCUs nichtmal gegen viel Geld einen Compi kriege.

Wundersame These: Den Comeau Compiler bekommt man zu vertretbaren Preisen auf beliebige Plattformen portiert, wenn es dafür einen C-Compiler gibt.

Aha, den kannte ich noch nicht. Hast Du schon Erfahrungen damit gemacht, ob die Ports wirklich ohne Federlesens auf verschiedenen Plattformen identisch funktionieren? Und wie sieht der erzeugte C- Code aus, kann man den noch halbwegs debuggen?
Dann wär' das durchaus eine erprobenswerte Option.

lowbyte_ schrieb:

Da bin ich getrennter Meinung. Die Library muss ja nicht von mir sein.
Mir passt das Wort BLACKBOX einfach nicht

Mir ging's um die Komplexität von Compilern und deren Drumherum. Da ist C leichter überprüfbar und profitiert davon, daß Libs (= ausgelagerte Komplexität) eigentlich immer als Source vorliegen. Natürlich schreibe ich die Libs nicht alle selbst, aber wenn mal was nicht so klappt wie gedacht, kann ich das selber debuggen.

Achja, und nochwas fällt mir ein. Der Vorteil von C++ soll ja sein, daß man sich Behandlungsroutinen, die identisch sind, mehrfach instanziiert. Toll, klappt auch gut. Unter C hatte ich per Macros die Funktionsnamen redefined und den gleichen Kram mehrfach includiert - geht auch, wenn auch deutlich umständlicher. Zur Runtime war aber das C- Compilat etwa achtmal schneller, als sein C++- Bruder. Beides mit dem gleichen GCC für den SH8 gebencht. Ob das in anderen Anwendungsfällen auch so ist, weiß ich nicht. Aber Komfort kostet Rechenzeit.

OMG kwt

pointercrash() schrieb:

Aber Komfort kostet Rechenzeit.

Da hast du im allgemeinen Recht, dies trifft aber nicht auf das OOP von C++ zu, da dieses nicht mehr existiert sobald du kompiliert hast. Lass dir das mal von den Profis hier genauer erklären. Wenn du sowas produziert hast dann liegt das nicht an C++ sondern eher daran dass du anscheinend extrem schlecht programmiert hast.

Wenn du weiter bei der Meinung bleibst das C++ wegen OOP x mal langsamer ist als C oder nur doppelt so langsam werden sie dich hier fachlich auseinander nehmen. Bitte beschäftige dich ein wenig wie OOP in C++ umgesetzt wurde und die wirst sehen das davon unterm Strich nichts übrig bleibt also auch keine große Performance kostet, tut mir leid.

pointercrash**

oppcpp schrieb:

Lass dir das mal von den Profis hier genauer erklären. Wenn du sowas produziert hast dann liegt das nicht an C++ sondern eher daran dass du anscheinend extrem schlecht programmiert hast.

Davon gehe ich auch aus, aber mir fiel nichts Besseres ein, war aus einem C++- Lehrbuch abgepinselt.

Aber eigentlich war mir gar nichts am c vs. cpp gelegen, klar kann man in cpp besser kapseln und wie man in C kapselt, ist ausreichend erörtert - viel mehr gibt's ja nicht.

*john 0

pointercrash() schrieb:

Aha, den kannte ich noch nicht. Hast Du schon Erfahrungen damit gemacht, ob die Ports wirklich ohne Federlesens auf verschiedenen Plattformen identisch funktionieren?

Der Comeau Compiler gilt als der Compiler, der der ISO Norm am nächsten kommt bzw. diese komplett umsetzt. ISO C++ Code sollte daher auf jeder Plattform problemlos übersetzt werden. Ich selbst habe den Compiler noch nicht für Projekte genutzt, aber er gilt in der C++ Community als faktische Referenz Implementation der ISO Norm.

pointercrash() schrieb:

Und wie sieht der erzeugte C- Code aus, kann man den noch halbwegs debuggen?

Es werden "#line" Directiven genutzt, darüber hinaus ist das Name Mangling komplett verschieden. Das Debugging ist ergo nicht so einfach, wie mit einem reinem C++ Compiler mit passenden Debugger.

pointercrash() schrieb:

Dann wär' das durchaus eine erprobenswerte Option.

Zum Testen muß man sich den Compiler kaufen, da die online Tryout Variante effektiv nur dazu taugt zu testen, ob der Compiler einen bestimmten Code verarbeitet. Für die verbreiteten Plattformen kostet eine Lizenz US$50.

P.S. C99 unterstützt der Compiler ebenfalls.