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

SeppJ

Die C-Standardbibliotheksfunktionen funktionieren nicht mit C++-Objekten und machen dann schlimme Dinge. Und aufgrund der fehlenden Typenprüfung bei diesen Funktionen merkt man es erst zur Laufzeit.

Und wer malloc statt vector für dynamische Arrays verwendet der ist einfach nur automasochistisch. Darf man gerne sein, aber Programmieren ist auch immer eine Gemeinschaftsarbeit und man sollte seine Selbstbestrafungsphantasien nicht dort ausleben, wo es andere betreffen kann.

edit: Zu langsam. Nun hast du wenigstens die Gründe 4x wiederholt bekommen.

lk

Nexus schrieb:

lk schrieb:

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.

printf() & Co. haben einige Probleme: Sie bieten keine Typsicherheit (falsches Flag ist UB), während Streams schon zur Kompilierzeit (!) Typen überprüfen können. Ausserdem funktioniert printf() nicht mit benutzerdefinierten Datentypen. Als Alternative für formatierte Eingabe wird in C++ oft Boost.Format genannt.

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.

Nexus schrieb:

C-Casts -> 4 C++-Castoperatoren

Welche Vorteile - mal die zusätzlich verbrannten 3kcal nicht beachtend - bringen die Dinger überhaupt?

Dass

SeppJ schrieb:

Die C-Standardbibliotheksfunktionen funktionieren nicht mit C++-Objekten und machen dann schlimme Dinge. Und aufgrund der fehlenden Typenprüfung bei diesen Funktionen merkt man es erst zur Laufzeit.

Um ein objekt an stdout cia std::cout zu verfüttern brauch man auch erst sowas wie toString()...

SeppJ schrieb:

Und wer malloc statt vector für dynamische Arrays verwendet der ist einfach nur automasochistisch. Darf man gerne sein, aber Programmieren ist auch immer eine Gemeinschaftsarbeit und man sollte seine Selbstbestrafungsphantasien nicht dort ausleben, wo es andere betreffen kann.

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

314159265358979

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.

Und dafür fällst du auf die Nase, wenn du dich mal vertippst. Sehr schön. Viel Zeit mit Debugging verschwendet. Aber nimm doch einfach meine Version von printf. :p

lk schrieb:

Welche Vorteile - mal die zusätzlich verbrannten 3kcal nicht beachtend - bringen die Dinger überhaupt?

Sie drücken aus, was du vorhast - Fehlererkennung und Lesbarkeit.

lk schrieb:

Um ein objekt an stdout cia std::cout zu verfüttern brauch man auch erst sowas wie toString()...

Nö. Überlad den Operator <<.

CStoll

lk schrieb:

Nexus schrieb:

lk schrieb:

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.

printf() & Co. haben einige Probleme: Sie bieten keine Typsicherheit (falsches Flag ist UB), während Streams schon zur Kompilierzeit (!) Typen überprüfen können. Ausserdem funktioniert printf() nicht mit benutzerdefinierten Datentypen. Als Alternative für formatierte Eingabe wird in C++ oft Boost.Format genannt.

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.

Wenn du wirklich darauf stehst, dich ohne Hilfsmittel in die Innereien deines Computers durchzugraben, wünsche ich dir viel Spaß damit. Aber dort unten bist du wirklich auf dich alleine gestellt (und UB bedeutet häufig, daß das Programm unter Testbedingungen reibungslos läuft und im realen Einsatz ohne erkennbaren Grund abstürzt oder mysteriöse Fehler erzeugt).

SeppJ schrieb:

Die C-Standardbibliotheksfunktionen funktionieren nicht mit C++-Objekten und machen dann schlimme Dinge. Und aufgrund der fehlenden Typenprüfung bei diesen Funktionen merkt man es erst zur Laufzeit.

Um ein objekt an stdout cia std::cout zu verfüttern brauch man auch erst sowas wie toString()...

Du brauchst nur einen passenden Ausgabe-Operator bereitzustellen, den Rest erledigt der Compiler für dich (das heißt auch, daß du nicht im gesamten Programm irgendwelche Formatstrings ändern oder Ausgabefunktionen austauschen mußt, nur weil du von int umstellst auf long oder BigInt).

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

Dann wünsche ich dir viel Spaß mit Assembler - bei deiner Einstllung ist das wohl das richtige Gebiet um sich auszutoben.

wxSkip

lk schrieb:

Nexus schrieb:

lk schrieb:

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.

printf() & Co. haben einige Probleme: Sie bieten keine Typsicherheit (falsches Flag ist UB), während Streams schon zur Kompilierzeit (!) Typen überprüfen können. Ausserdem funktioniert printf() nicht mit benutzerdefinierten Datentypen. Als Alternative für formatierte Eingabe wird in C++ oft Boost.Format genannt.

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.

Warum solltest du denken, wenn du es nicht musst? Dieser Ansatz ist nicht grundsätzlich verkehrt, sofern du sagen kannst, dass es nicht mit Performance-/Lesbarkeitsnachteilen oder sonstigen Nachteilen verbunden ist.

lk schrieb:

Nexus schrieb:

C-Casts -> 4 C++-Castoperatoren

Welche Vorteile - mal die zusätzlich verbrannten 3kcal nicht beachtend - bringen die Dinger überhaupt?

Größere Typsicherheit; man sieht, was man macht; verschiedene Verfahren, die in C nur zum Teil bei einem Cast verwendet werden und wenn, dann abhängig von der gerade durchgeführten Konversionsart.

lk schrieb:

SeppJ schrieb:

Die C-Standardbibliotheksfunktionen funktionieren nicht mit C++-Objekten und machen dann schlimme Dinge. Und aufgrund der fehlenden Typenprüfung bei diesen Funktionen merkt man es erst zur Laufzeit.

Um ein objekt an stdout cia std::cout zu verfüttern brauch man auch erst sowas wie toString()...

Nein, man überlädt den std::ostream &operator<<(std::ostream &in, Type value) für den Typ Type .

lk schrieb:

SeppJ schrieb:

Und wer malloc statt vector für dynamische Arrays verwendet der ist einfach nur automasochistisch. Darf man gerne sein, aber Programmieren ist auch immer eine Gemeinschaftsarbeit und man sollte seine Selbstbestrafungsphantasien nicht dort ausleben, wo es andere betreffen kann.

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

Wenn du meinst, auch solche Leute werden gebraucht, dennoch sollten sie irgendwann bei Assembler aufhören, noch mehr frickeln zu wollen...

EDIT: OMG, 2 Posts zu langsam...

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 ?