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

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

  • ?

    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.

    0
  • P

    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 🙂

    0
  • ?

    Skym0sh0 schrieb:

    was passiert denn wenn memcopy durch irgendwelche exceptions unterbrochen wird?

    Wie soll das denn geschehen?

    0
  • E

    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.

    0
  • V

    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.

    0

  • @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.

    0
  • P

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

    0

  • 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 ?

    0
  • 3

    Variadic Templates mit C++11 😉

    0

  • 314159265358979 schrieb:

    Variadic Templates mit C++11 😉

    Hmm sieht interessant aus 😉

    0
  • V

    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.

    0
  • B

    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.

    0
  • L

    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)

    0
  • N

    lk schrieb:

    Ist die idee vom Programmieren denn eigentlich nicht, alles selbst zu machen?

    Meinst du das wirklich ernst? Was für einen Sinn hat es, selbst noch einmal alles neu zu programmieren, was professionelle Entwickler schon viel besser, schneller, sicherer programmiert haben, als man es selbst je schaffen wird?

    lk schrieb:

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

    Abstraktion ist was Gutes. Es hat keinen Sinn, jedes Mal neu über die grundlegendsten Boilerplate-Dinge wie Speicheranforderung nachzudenken. Das ist nur fehleranfällig, mühsam und macht den Code hässlich. Du solltest auch von deiner Sichtweise wegkommen, Low-Level-Programmierung sei so viel anspruchsvoller als abstrakte Herangehensweisen.

    lk schrieb:

    Windows denkt natürlich, es ist einfacher wenn es arbeit abnimmt, ist es auch. aber dann kommt eben dieser mist raus.

    Nach "C vs. C++" und "Java-Programmierer müssen nicht denken" braucht dieser Thread sicher nicht auch noch einen "Windows ist doof"-Flamewar 🙄

    0

  • Nexus schrieb:

    lk schrieb:

    Ist die idee vom Programmieren denn eigentlich nicht, alles selbst zu machen?

    Meinst du das wirklich ernst? Was für einen Sinn hat es, selbst noch einmal alles neu zu programmieren, was professionelle Entwickler schon viel besser, schneller, sicherer programmiert haben, als man es selbst je schaffen wird?

    Das wird vor allem schlicht und ergreifend sehr sehr teuer... 😃

    0

  • volkard schrieb:

    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.

    Diese "\n"-Marotte hab ich letztens bei einer Nachhilfeschülerin gesehen...
    Sie behauptete, der Kurs an der Uni würde C++ heißen und dann behauptete sie auch noch, der Prof würde die Studenten zwingen "\n" statt std::endl zu nutzen...

    Dann musste ich ihr leider erklären dass Professoren selten wirklich Ahnung von C oder C++ haben... 😃

    0
  • S

    It0101 schrieb:

    volkard schrieb:

    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.

    Diese "\n"-Marotte hab ich letztens bei einer Nachhilfeschülerin gesehen...
    Sie behauptete, der Kurs an der Uni würde C++ heißen und dann behauptete sie auch noch, der Prof würde die Studenten zwingen "\n" statt std::endl zu nutzen...

    Dann musste ich ihr leider erklären dass Professoren selten wirklich Ahnung von C oder C++ haben... 😃

    Der Prof hat aber recht!

    0
  • P

    Shade Of Mine schrieb:

    It0101 schrieb:

    volkard schrieb:

    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.

    Diese "\n"-Marotte hab ich letztens bei einer Nachhilfeschülerin gesehen...
    Sie behauptete, der Kurs an der Uni würde C++ heißen und dann behauptete sie auch noch, der Prof würde die Studenten zwingen "\n" statt std::endl zu nutzen...

    Dann musste ich ihr leider erklären dass Professoren selten wirklich Ahnung von C oder C++ haben... 😃

    Der Prof hat aber recht!

    Nur wenn er erklärt, warum. Und wenn er genauer klarmacht wo endl keinen Sinn macht (und wo es Sinn macht).

    0
  • V

    It0101 schrieb:

    Diese "\n"-Marotte hab ich letztens bei einer Nachhilfeschülerin gesehen...
    Sie behauptete, der Kurs an der Uni würde C++ heißen und dann behauptete sie auch noch, der Prof würde die Studenten zwingen "\n" statt std::endl zu nutzen...

    Dann musste ich ihr leider erklären dass Professoren selten wirklich Ahnung von C oder C++ haben... 😃

    Kein Wunder, daß Du lauter schlechte Seiten an C++ findest.

    #include <iostream>

int main()
{
    using namespace std;
    for(int i=0;i<10000000;++i)
        cout<<"hello, world\n";
}

    volkard@localhost ~/src/testcpp $ g++ -O3 -march=native main.cpp && time (./a.out > /dev/zero)

real	0m1.329s
user	0m0.877s
sys	0m0.007s

    und

    #include <iostream>

int main()
{
    using namespace std;
    for(int i=0;i<10000000;++i)
        cout<<"hello, world"<<endl;
}

    volkard@localhost ~/src/testcpp $ g++ -O3 -march=native main.cpp && time (./a.out > /dev/zero)

real	0m9.176s
user	0m2.886s
sys	0m4.883s

    Noch Fragen?

    0
  • P

    It0101 schrieb:

    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.

    Diejenigen, die das alles begründen können und nicht einfach sinnlos nachplappern, was sie meinen gelesen zu haben, werden das ziemlich genauso sehen 😉 Leider gibt es den einen oder anderen, die Ratschläge zu einzelnen spezifischen Codebeispielen gleich als absolutes Dogma interpretieren und das dann entweder bei jeder unpassenden Gelegenheit anbringen oder aber gegen die "unangebrachte allgemeine Beschränkung" auf die Barrikaden steigen ohne zu sehen, dass solche Ratschläge nicht immer überall anzuwenden sind sondern Ausnahmen haben.

    0
Anmelden zum Antworten