Warum sollte man C und C++ eigentlich nicht mischen... ?

cooky451

lk schrieb:

Das ist ja warum ich sie viel handlicher finde. Wenn "dir wird arbeit und denken abgenommen!" kommt, fliege ich schon vom Hocker, oder bin eben bereits am Boden.

C++ ist im Gegensatz zu C keine Sprache, bei der man nebenbei noch etwas über Computer lernt. C++ nimmt dir halt einiges ab. Das mag dir jetzt vielleicht noch doof und langweilig erscheinen, aber sobald du mal größere Projekte machst wirst du froh sein, RAII, Klassen, Templates, etc. pp. zu haben.

Edit:
Was ist denn hier los? oO

SeppJ

cooky451 schrieb:

Edit:
Was ist denn hier los? oO

Die Fragen sind leicht, aber die Antworten lang, deswegen gibt es gerade alle Antworten in der Vorteilspackung, 3 zum Preis von 1!

Skym0sh0

mal was ganz anderes:

in effective c++ erzählt scott meyers was von ausnahme sicherheit (wers gelesen hat, wird sich vielleicht an grundlegende und starke ausnahme sicherheit errinnern). unter anderen sagt er, dass eine funktion nur eine ausnahmesicherheit garantieren kann, wie die benutzte funktion mit der niedrigsten ausnahmesicherheit(kette und schwächstes glied, ihr wisst schon) und die ganzen C Funktionen bieten nichts in der hinsicht

was passiert denn wenn memcopy durch irgendwelche exceptions unterbrochen wird?
der zustand der vorher da war ist verändert und der der rauskommen sollte wird nie erreicht, es bleibt alles auf der strecke...

It0101

314159265358979 schrieb:

Bei Sockets und Threads kannst du boost verwenden, eine absolut moderne C++ Bibliothek.

Oh man... Dann ziehen sich alle den Boost::Heiligenschein über und im Hintergrund werkelt immernoch pthread_create oder _beginthread...

Und dann hinterher aber schön rumtun: Ja ich verwende nur C++ und keinnnnnnnn C ...

Also tut mir leid, aber manch einer hat hier im C++/C-Dont-Mix-It Wahn komplett den Faden verloren...

**
Jetzt neu im Angebot und frisch released:

"Boost::Heiligenschein"

Einfach instanziieren und nur noch freuen! :D**

ipsec

It0101 schrieb:

Oh man... Dann ziehen sich alle den Boost::Heiligenschein über und im Hintergrund werkelt immernoch pthread_create oder _beginthread...

Und dann hinterher aber schön rumtun: Ja ich verwende nur C++ und keinnnnnnnn C ...

Also tut mir leid, aber manch einer hat hier im C++/C-Dont-Mix-It Wahn komplett den Faden verloren...

Sehr witzig, wenn das OS nur eine C-Schnittstelle anbietet. Denkst du in irgendeiner anderen Sprache, die Kernelthreads anbietet, passiert intern etwas anderes? Würdest du denn auf die Idee kommen, du hättest C# und C gemischt, nur weil du System.Threading.Thread benutztest?

lk schrieb:

Habs schon mehrmals im Forum hier gehört (insbesondere auf mich verweisend), man solle C++ nicht mit C mischen.

Aber warum?

std::cout find ich im Gegensatz zu printf extrem unhandlich, die File IO streams genauso; bei denen verliert man doch sofort den Überblick was passiert. (Gleich bin ich auch so weit ein malloc(int) Enthusiast zu werden)
Bei sockets oder threads muss man sowieso mit C-ishem Zeug arbeiten.

C hat den Vorteil dass es sehr schnell ist und C++ ist dagegen sehr bequem.

Es macht dann Sinn C mit C++ zu mischen wenn die Performance sehr wichtig ist wie z.B. bei numerischen Berechnungen, da ist Objektorientierung nur unnötiger Balast.

Wenn du von C kommst (so wie ich) dann kommt es dir an vielen Stellen so vor als ob C deutlich besser ist... kämpfe dagegen an, bald wirst du schon denn Sinn in C++ Operationen sehen.

theta

Es macht dann Sinn C mit C++ zu mischen wenn die Performance sehr wichtig ist wie z.B. bei numerischen Berechnungen, da ist Objektorientierung nur unnötiger Balast.

Wenn du von C kommst (so wie ich) dann kommt es dir an vielen Stellen so vor als ob C deutlich besser ist... kämpfe dagegen an, bald wirst du schon denn Sinn in C++ Operationen sehen.

Ich mag gar nicht mehr drauf zu Antworten - einfach gesagt ist es einfach zu einfach gedacht.

Können wir uns darauf einigen:
Wenn C für schnellen Code benötigt wird, in dem Abschnitt C.
Wenn sicherer Code eher gefragt ist, sollte das in C++ einfacher gehen.

Sollte beides in einem Quelltext gefordert sein, die Funktionen entweder in C exclusiv-oder C++. Aber nicht Zeilenweise nach belieben C und C++ nutzen.

Soviel zum Ideal

Waren da nicht noch ein paar C++ Funktionen, die nur mit C-Strings funktionieren

viel Spass
f.-th.

pumuckl

It0101 schrieb:

Oh man... Dann ziehen sich alle den Boost::Heiligenschein über und im Hintergrund werkelt immernoch pthread_create oder _beginthread...

Siehe CStolls Post:

PS: Ja, es gibt Bereiche, wo es zu C-Lösungen keine Alternative gibt. Aber die sollte man möglichst lokal halten und hinter einem vernünftigen C++ Wrapper verstauen.

Und dann hinterher aber schön rumtun: Ja ich verwende nur C++ und keinnnnnnnn C ...

Es wäre blödsinn, das zu behaupten. Es geht nur darum, es nicht zu mixen. Und mit Mixen ist gemeint, innerhalb der selben Source/ der selben Funktion wahllos zwischen C- und C++-Mitteln hin und herzuspringen.

Also tut mir leid, aber manch einer hat hier im C++/C-Dont-Mix-It Wahn komplett den Faden verloren...

Wenn du damit meinst, dass manch einer die "Dont-Mix-It"-Aussage fehlinterpretiert (absichtlich oder unabsichtlich), dann hast du sicher recht

Skym0sh0 schrieb:

was passiert denn wenn memcopy durch irgendwelche exceptions unterbrochen wird?

Wie soll das denn geschehen?

Eisflamme

C ist nicht zwangsläufig schneller als C++, aber da man bei C++ oft das OOP-Paradigma verwendet hat man manchmal kleine Performanceverluste (die vermutlich ohne vtable aber auch entfallen, wenn der Compilter gut optimiert, was er wohl tut).

Es gibt auch einfach viel Code, der nicht klar als C oder C++ zu klassifizieren ist. Wenn man die Bibliotheken von C++ und C nicht nutzt und keine in C nicht vorhandenen Schlüsselwörter verwendet, dürfte man das als C-Code klassifizieren. Dann nutzt man aber cout zur Ausgabe und plötzlich ist das C++-Code.

Ergo: Zu sagen C ist schneller als C++ ist so wie zu sagen Äpfel sind gelber als Paprikas.

Mischen von printf und cout ist halt uneinheitlich und printf ist ganz einfach auch schlechter, weil es eben nicht typsicher ist. Das hat nicht Mal was mit der Performance zu tun, die Prüfungen erfolgen schließlich zur Compilezeit. Ich würde für Mikrocontroller-Programmierung evtl. auch das ein oder andere C++-Mittel weglassen, wenn es etwas Overhead generiert; aber z.B. vector für Arrays zu nutzen hat doch eigentlich keine Nachteile.

volkard

notsmart schrieb:

Es macht dann Sinn C mit C++ zu mischen wenn die Performance sehr wichtig ist wie z.B. bei numerischen Berechnungen, da ist Objektorientierung nur unnötiger Balast.

Nur, wenn man es falsch macht.

It0101

@Pumuckl:
Ich verwende auch C, wo ich es für richtig halte. Ob man nun um alles was C ist einen C++ Wrapper, womöglich sogar noch mit Overhead drumzimmern muss, ist eine andere Frage. Manchmal macht es Sinn, manchmal nicht.

Ich verwende gelegentlich sprintf... na und?

Was ich eigentlich sagen wollte:
Wenn man C verwendet, sollte man auch dazu stehen.
Und BOOST ist eben auch teilweise C ...

Daher find ich das lächerlich wenn hier Leute behaupten sie würden nicht mischen, aber eben doch durch Boost indirekt C-Code verwenden... Ich verwende C direkt, ich verwende Boost und ich stehe dazu und verteufele das nicht.

pumuckl

It0101 schrieb:

Was ich eigentlich sagen wollte:
Wenn man C verwendet, sollte man auch dazu stehen.
Und BOOST ist eben auch teilweise C ...

Das "ist" hier ist sehr ungenau. Boost verwendet intern C-Stil, ja. Bleibt ja auch nichts anderes übrig, wenn die OS-APIs in C geschrieben sind. Nach außen ist mir aber nicht bekannt, dass Boost irgendwo eine Schnittstelle im C-Stil hätte.

Daher find ich das lächerlich wenn hier Leute behaupten sie würden nicht mischen, aber eben doch durch Boost indirekt C-Code verwenden...

Indirekt ist hier das Schlagwort. Wie schon gesagt, mit "mischen" ist gemeint, dass man im gleichen Code C-Stil und C++-Stil verwendet. Es geht hier nicht um die gelegentliche Benutzung von Funktionen aus der C-Standardbibliothek, für die es in C++ keine Entsprechungen gibt. Es geht hier auch nicht darum, dass in gut abgegrenzten Bereichen aus Performance- oder anderen Gründen C-Code benutzt wird und diese Funktionen dann im C++-Code benutzt werden (so wie bei Boost). Es geht darum, in C++-Code auch die C++-Mittel zu benutzen, die es für die jeweilige Aufgabe gibt, und nicht im selben Code wild zu mischen.

C-Code hat seine Berechtigung in C++-Programmen, aber sauber getrennt und mit Vernunft eingesetzt. Das ist keine Mischung und nicht lächerlich. Lächerlich ist, ohne nachzudenken jeden kleine Fitzel C-Code von Anfang an zu verteufeln, und lächerlich ist genauso zu sagen, "dort ganz hinten in der Ecke steht ein Stück C-Code, also ist das eh ne Mischung und ich darf überall wild mischen".

It0101

pumuckl schrieb:

Indirekt ist hier das Schlagwort. Wie schon gesagt, mit "mischen" ist gemeint, dass man im gleichen Code C-Stil und C++-Stil verwendet.

Da kann ich im wesentlich mitgehen. Bleibt nur zu hoffen, dass alle die gleiche Definition verwenden wie du.
Wenn ich mich recht entsinne gibt es hier auch ein paar Kandidaten, die behaupten, komplett auf C zu verzichten, auch indirekt. Das mag bei Hello-World-Anwendungen funktionieren, aber sobald man im Multithreadingbereich, im Socketbereich und sonstwo unterwegs ist, wirds ganz schnell ganz schön dünn.

Kurzum: komplett ohne C geht es in der professionellen Softwareentwicklung nicht.

Was mir grad einfällt:

gibts eigentlich eine Variable Parameterliste in C++ à la "va_list" in C ?

314159265358979

Variadic Templates mit C++11

It0101

314159265358979 schrieb:

Variadic Templates mit C++11

Hmm sieht interessant aus

volkard

It0101 schrieb:

Wenn ich mich recht entsinne gibt es hier auch ein paar Kandidaten, die behaupten, komplett auf C zu verzichten, auch indirekt. Das mag bei Hello-World-Anwendungen funktionieren, aber sobald man im

Die reden Unfug.

cout << "hello, world!" << endl;

Das Stringliteral ist C. Und im Wahn, C zu meiden wurde endl statt '\n' verwendet, dabei ist das recht dumm, denn es macht noch heimlich ein flush, das kein Mensch braucht.

brotbernd

lk schrieb:

Ich bin eigentlich einer, der es kaum erwarten kann bis er Assembly lernt. Je mehr hardcore desto besser. (Hab mit C++ angefangen, dann richtung C#/Java(war nichts), dann eben C(leider werde ich mit Java an der Uni gequält), jetzt will ich eben assembly lernen.)

Das ist ja durchaus legitim, dass Du gerne "hardcore" programmierst, aber es lässt erahnen dass Deine Arbeiten sich bisher auf kleine Fummeleien in deinem Kämmerlein beschränken. Natürlich können es auch große Fummeleien sein, aber Zielgruppe von modernen C++ Methoden und Weisheiten oder generell die Lehre von OOP sind eher Leute, die in großen Projekten mit mehreren Leuten (und evtl. für viel Geld) arbeiten, oder sich eben in diese Richtung entwickeln wollen.
Natürlich kannst Du Dir als großer Assembler Fummler einen Namen machen, aber dann wird es immer einen geben, der dir sagen muss was genau du zu tun hast und der überlegt wie dein Gefummel in das Gesamtsystem integriert wird ohne dass es dem Rest des Teams auf die Nerven geht.

lk schrieb:

Wenn "dir wird arbeit und denken abgenommen!" kommt, fliege ich schon vom Hocker, oder bin eben bereits am Boden.

Tja.. nach der Uni wird Deine Arbeit aber verdammt viel Geld kosten und Geld für unnötige Arbeit will keiner bezahlen. Genauso will niemand unnötig für Arbeit bezahlen, die durch Denkfehler (die jeder macht) entstehen. Fehler macht man in jeder Programmiersprache und mit jeder Programmiertechnik, aber in der einen mehr und in der anderen weniger und vor allem billigere Fehler. Ein Compilezeitfehler ist natürlich lange nicht so schlimm wie ein Laufzeitfehler (zb. iostreams vs. printf).
Für alles was du an Fehlern durch geschicktes Programmieren nicht ausschließen kannst musst du Tests schreiben und ausführen. Es sei denn Du programmierst für dich selbst, dann kannst du Tests weglassen und sowieso arbeiten wie du willst. Dann hat sich die Frage auch erübrigt, dann machst Du das was Dir passt.

It0101 schrieb:

Oh man... Dann ziehen sich alle den Boost::Heiligenschein über und im Hintergrund werkelt immernoch pthread_create oder _beginthread...

Du findest das vielleicht witzig, aber genau das ist eines der wichtigsten Prinzipien der OOP und nennt man Kapselung. Ein unschönes aber einfach notwendiges OS Gefummel wird hinter einer schönen Schnittstelle verpackt, die eine einfache und vor allem fehlerfreie Verwendung bietet. Oftmals ist man einfach gezwungen C Techniken anzuwenden, weil man auf irgendeine C API angewiesen ist. C++ bietet mir aber die Möglichkeit diese unschönen Implementierungsdetails zu verstecken, entweder durch selber Schreiben oder durch die Verwendung einer der vielen vorhandener Bibliotheken.

lk

Ist die idee vom Programmieren denn eigentlich nicht, alles selbst zu machen? Die völlige Kontrolle zu behalten? Das ist ja was ich nicht leiden kann, wenn mir mit dem "du musst nicht mehr so viel denken" abgenommen wird. (-> Java/C#). Wenn da eine einzige funktion fehlt ist man am Ende, dann kommt als fertiges projekt sowas raus wie Windows; aus häppchen irgendwie zusammengekleistert. Bei Linux muss man auch vieles selbst machen, und die ganzen websites die 100% Garantie brauchen, laufen auf linux. Windows denkt natürlich, es ist einfacher wenn es arbeit abnimmt, ist es auch. aber dann kommt eben dieser mist raus.
(Betriebsysteme nur zur veranschaulichung, bitte jetzt nicht über das Fehlen von Mac OS X beschwehren)