Wie wird in C gekapselt?

[lowbyte_]

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.

[lowbyte_]

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.

[lowbyte_]

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

[bewertung]

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

[lowbyte_]

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.

[omgomg]

OMG kwt

[oppcpp]

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.

[*john 0]

pointercrash() schrieb:

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

Bei so etwas ist es extrem wahrscheinlich, daß der Code nicht wirklich dasselbe getan hat, sondern nur das gleiche Ergebnis produziert hat.

[ficky]

C ist doch nur was für Fickler.

[malnachgedacht]

Hier mal ein Beispiel was man mit C in Verbindung mit der Speicherverwaltung alles falsch machen kann.

unsigned char *get_line(int fd)
{
    int i;
    unsigned char *line;
    line = (char*)malloc(1);
    for (i=1; line[i]!=’\n’ || line[i]!=’;’; i++)
    {
        read(fd, &line[i], 1);
        line = (char*)realloc(line, 1);
    }
return line;
}

• Die zugehörige Dokumentation wurde nicht gelesen.
• Der zugehörige Header <stdlib.h> wurde nicht angegeben.
• Die daraufhin generierten Warnungen des Compilers ». . . makes a pointer from
  an int . . . « wurden durch Typ-Casting weggedrückt, weil sie nicht verstanden
  wurden und daher störten.
• Es wurde ein falscher Typ beim Typ-Cast angegeben.
• Die daraufhin erfolgten Warnmeldungen ». . . incompatible pointer types . . . «
  wurden ignoriert.
• Der gezwungenermaßen vom Compiler angenommene Ausweichtyp int als
  Rückgabetyp kann ungeeignet sein und zu schweren Fehlern des Programms führen.
  Der Typ-Cast ändert nichts daran – der repariert hier überhaupt nichts.
• Auch im Aufrufer von get_line() war keine Freigabe des Speichers durch
  free vorgesehen.
• In keinem Fall wird die retournierte Adresse auf Fehlschlag geprüft.
• Der Rückgabewert von read wird nicht geprüft.
• Der Inhalt des Speicherbereiches wird auf einen bestimmten Inhalt geprüft, bevor
  dieser überhaupt mit Daten gefüllt wird.
• Der Index beginnt mit [i=1] und adressiert ein nichtexistierendes zweites Byte
  des Speicherplatzes schon zu Beginn.
• Die Schleife läuft ewig, weil || statt && verwendet wurde.
• Der Aufruf von realloc ist sinnlos, da der Speicherplatz in seiner Größe von
  bereits 1 Byte nicht verändert wird.
• Der Index adressiert fortlaufend nichtexistierenden Speicherplatz.
• Das Byte, das read() einfüllt, wird niemals geprüft, da der Index i jeweils
  zuvor erhöht wird.
• Ein Anfordern von nur ein Byte Speicherplatz ist grundsätzlich grober Unfug.
• Die Verwendung dieser Funktionen zum Lesen einer Zeile ist Unfug, solange die
  Zeilenlänge nicht wesentlich größer als 30000 Byte sein kann.

[Fototoast]

Warum braucht ihr Kapselung um OO zu programmieren?

[lowbyte_]

Hi

Ficky schrieb

C ist doch nur was für Fickler.

Und du hast keine Ahnung ! Also labere nicht.

lowbyte

[ochnö]

lowbyte_ schrieb:

Und du hast keine Ahnung ! Also labere nicht.

Geh doch nicht auf das Getrolle ein

[Interessenhalber]

In C wird über da Modulkonzept gekapselt. So sind in einzelnen Übersetzungseinheiten z.B. die static Variabeln nur dort sichtbar. Das weiß man nach ein paar Tagen C lernen und ich kann nicht verstehen wie dadurch so ein riesen Thread entstehen kann?