Warum programmiert ihr in C?

[volkard]

__-- schrieb:

volkard schrieb:

Eigentlich hatte ich eine Widerlegung meiner Aussage auf Seite 24 erwarte, wo ich schrieb, warum sowohl Anfänger- als auch Profi-Code in C++ die Tendenz hat, schneller als gleichwertiger Code in C zu sein.

also ich denke wir können uns darauf einigen, dass man in c mehr aufwand betreiben muß um auf die gleiche performance zu kommen.

Nein.
Ich meine da eine relativ neue Entwicklung, nämlich "zero cost" exception handling.
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat_ugn_unw/Exception-Handling-Control.html

there is no overhead for exception handlers if no exception is raised

Recht neue Technik das, daher noch nicht in die C-Gemeinde allgemein durchgedrungen, fürchte ich.
In beiden Sprachen muß man die Rückgabe von malloc, fopen und so immer mit if noch überprüfen. In C++ wirft man eine Exception, in C returnt man.
Aber in C müssen alle Funktionen auf allen Ebenen mit if ihre Kinder überprüfen. Das muß man in C++ nicht, an passender Stelle steht beliebig viele Ebenen häher ein passendes catch. Effekt: viele ifs gespart und ersetzt durch gar nichts.
Also wird C++-Code von einem Programmierer, der auch in C zuhause ist, und nicht auf std::string und cout angewiesen ist, vermutlich schneller werden als gleichwertiger C-Code.

[c++istlangsam]

Natürlich ist C++ langsamer und Aufwendiger als C.

C:

#include <stdio.h>

int main(int argc, char *argv[])
{
   printf("C rulez!!!!!!!");
   return 0;
}

C++:

#include <iostream>
#include <string>
#include <ctime>

class Hello
{
public:
Hello(const std::string&);
void print();

private:
std::string str;
void doSomethingUseless();
};

Hello::Hello(const std::string &str) : str(str)
{
}

void Hello::print()
{
int i;
for(i = 0; i < str.length(); i++)
{
doSomethingUseless();
std::cout << str[i];
}
}

void Hello::doSomethingUseless()
{
time_t now;
time(&now);

while( time(NULL) <= (now + 10));

}

int main(int argc, char *argv[])
{
Hello *h;
h = new Hello("C++ sucks\nEcht lahm das ganze");
h->print();
delete h;
return 0;
}

[this-*gt*that]

knivil schrieb:

Wir hatten schon lange keinen so langen Thread C vs. C++. Fuer gewoehnlich sind sie im C++ Bereich zu finden. Und nicht nur das, allein die Qualitaet der Beitraege sucht seines Gleichen.

Sind die Mods alle im Urlaub? Oder stehen die einfach auf Threads mit einer Trolldichte jenseits von Gut und Böse?

Scheppertreiber schrieb:

ich hoffe nur, Deine Kenntnisse sind besser wie Dein Deutsch.

Welch Ironie.

[looool]

this->that schrieb:

knivil schrieb:

Wir hatten schon lange keinen so langen Thread C vs. C++. Fuer gewoehnlich sind sie im C++ Bereich zu finden. Und nicht nur das, allein die Qualitaet der Beitraege sucht seines Gleichen.

Sind die Mods alle im Urlaub? Oder stehen die einfach auf Threads mit einer Trolldichte jenseits von Gut und Böse?

Scheppertreiber schrieb:

ich hoffe nur, Deine Kenntnisse sind besser wie Dein Deutsch.

Welch Ironie.

Der Gameboy wieder ...

[Spassvogel]

Möchtest du nicht noch dein Password preisgeben?

[Ausnahmekoenner]

[quote="volkard]
Aber in C müssen alle Funktionen auf allen Ebenen mit if ihre Kinder überprüfen.[/quote]
Und genau das ist der grundlegende Irrtum. Muss man nämlich nicht. Und das hat auch nichts mit unsauberem Programmierstil zu tun. Wenn z.B. Josef so eine geniale Funktion erfindet, wie diese hier:

void TranslateMessage(char** Buffer){
/* ... */

und dabei Hans die (mündliche) Zusage gibt, dass TranslateMessage garantiert funktioniert, wenn Buffer nicht NULL und mindestens BUFSIZE groß ist, dann braucht die Funktion von Josef nicht noch extra

if(Buffer)
 /* ... */

abfragen, wenn ihm Hans garantiert, niemals NULL reinzustecken.
Ein uneingeweihter Dritter (DAU) kann dann zwar immer noch NULL reinstecken.
Aber was, wenn gar nicht vorgesehen ist, dass je jemand anderer als der zuverlässige Hans die Funktion benutzen wird? -> Ergo: Überflüssige Doppelt- und Dreifachprüfung eingespart Kein Compiler der Welt könnte eine derartig überflüssige Doppele Überprüfung wegoptimieren, weil er von Josef's und Hans mündlicher Vereinbarung nichts weiß.
Aber was meinst Du, müsste wohl eine (hypothetische) DAU-sichere std::string::TranslateMessage(char** Buffer) Funktion tun?
Es bliebe ihr nicht erspart, dem ahnungslosen Aufrufer zuzutrauen, dass er eine NULL reinsteckt, und müsste dementsprechend die if() Abfrage, auf die das C-Team Josef + Hans verzichten konnte, implementieren. Oder man musste einen Exception-Handler für diesen Fall installieren (==Parallel-Thread) mit gigantischem Kontext-Wechsel Overhead (der momentane Zustand der Register muss zwischengespeichert werden, der Exception-Handler wird in die CPU geladen, nach Beendigung seiner Arbeit kann man nur noch abort() oder exit() aufrufen, da zu dem Zeitpunkt, als die Exception auftrat, der Stack in einem gänzlich zufälligen Zustand war, und es wird wohl auch die Freigabe von System-Handles oft genug zum Problem. Man kann gar nicht mehr genau eingrenzen, woher der Fehler überhaupt kam, und ein Ent-Buggen der Anwendung wird dementsprechend erschwert (idR unmöglich). Ganz zu schweigen von garantierten Deadlocks in Multi-Thread Anwendungen, die man sich mit Exceptions einbrockt.
Also, derartige (mündliche) Optimierungsmöglichkeiten wie in C hat man mit C++ gar nicht. Dort werden einem Exceptions & Co. jedenfalls von der Runtime aufgezwungen, ob man will oder nicht.
mfg

[grobgesagt]

C++ ist eine übermüllte scheisse ... bei dem man mehr Abstraktion und Sicherheit gewinnen wollte und doch nichts erreichte hat, was der C Programmierer schon gar nicht braucht! Ihr C++' er kommt immer mit Argumenten die einfach nicht überzeugen!
Und das letzte Argument von Volkard ist gar nicht nennenswert.

[Ränkeschmied]

Ausnahmekoenner schrieb:

... Aber was meinst Du, müsste wohl eine (hypothetische) DAU-sichere std::string::TranslateMessage(char** Buffer) Funktion tun? ..

Meinst du das ernst?
Du vergleichst also die sichere C++ Variante mit der unsicheren C Variante?
Oder gehst du davon aus, dass C++'ler so degeneriert sind, dass sie nicht miteinander kommunizieren können und deshalb die erste Variante nicht in Frage kommt?

[comment]

Sie ist nur so unsicher wie der Programmierer der schreibt!

[rotf-äh]

knivil schrieb:

Wir hatten schon lange keinen so langen Thread C vs. C++. Fuer gewoehnlich sind sie im C++ Bereich zu finden. Und nicht nur das, allein die Qualitaet der Beitraege sucht seines Gleichen.

siehste, hat c mehr Kante als c++ bzw. c--

[volkard]

Ausnahmekoenner schrieb:

volkard schrieb:

Aber in C müssen alle Funktionen auf allen Ebenen mit if ihre Kinder überprüfen.

Und genau das ist der grundlegende Irrtum. Muss man nämlich nicht. Und das hat auch nichts mit unsauberem Programmierstil zu tun. Wenn z.B. Josef so eine geniale Funktion erfindet, wie diese hier:

void TranslateMessage(char** Buffer){
/* ... */

und dabei Hans die (mündliche) Zusage gibt, dass TranslateMessage garantiert funktioniert, wenn Buffer nicht NULL und mindestens BUFSIZE groß ist

Das ist klar.
Aber sauviele Funktionen werden am Ende abgefragt werden müssen, weil innendrin oder in deren Kinder doch irgendwo syscalls lauern. Hast Du schonmal versucht, die *notwenignen* ifs alle einzubauen, statt sie wie üblich schlicht zu ignorieren?

Ich rede nicht von unsinnigen Tests. Die sinnigen Tests. Die Notwendigen. Die, die schiefgehen können, weil eine Datei verschwunden ist, ein Puffer nicht allokiert werden konnte, ein Thread nicht erstellt werden konnte, eine Schriftart nicht geladen werden konnte und so weiter...

Und von den sinnigen Tests gibt es noch ausreichend viele. Und die haben wir in C++ zu Nullkosten, aber in C muß man dafür zahlen. Also kann man in C++ schnelleren Code bauen als in C.

[Cönner]

Das mit den zero-cost-exceptions geht in C auch:

#define QUOTEME_(x) #x
#define QUOTEME(x) QUOTEME_(x)
#define THROW(msg) { fprintf(stderr, "%s in " __FILE__ ": " QUOTEME(__LINE__) "\
\n",(msg));exit(255);}

Wenn ein Fehler auftritt muss das Programm sowieso beendet werden.

Du wirst wahrscheinlich argumentieren, der Rückgabewert muss zuerst erst mit einem if der abgefragt werden und erst dann kann die Ausnahme geworfen (bzw. das Programm beenden) werden => zusätzliche Kosten.

Aber ich bin mir sicher, std::basic_fstream wurde irgendwie so geschrieben:

void // Rückgabewert auf seperater Zeile ist in C++ Pflicht
basic_ifstream::init(__filebuf_type ft)
{
  // Aufruf der C-Library des Systems um die Datei zu öffnen
  // Man beachte die schicke C++-Style-Kommentare
  // ...
  if (native_file_handle________ == 0)
    this->setstate(this_type________::failbit) // ruft eine komplexe Funktion auf,
                                               // die testet ob this->exceptions() auf
                                               // this_type________::failbit gesetzt ist und
                                               // wird dann eventuell eine exception werfen.
}

Ich will gar nicht nachschauen, welche Member alles in std::fstream implementiert sind, wenn der insgesamt eine Grösste von sizeof(std::fstream)=284 aufweist, wovon allein std::basic_streambuf<_CharT, _Traits> folgende enthält:

__c_lock                  _M_lock;
      __file_type               _M_file;
      ios_base::openmode        _M_mode;
      __state_type              _M_state_beg;
      __state_type              _M_state_cur;
      __state_type              _M_state_last;
      char_type*                _M_buf;         
      size_t                    _M_buf_size;
      bool                      _M_buf_allocated;
      bool                      _M_reading;
      bool                      _M_writing;
      char_type                 _M_pback;
      char_type*                _M_pback_cur_save;
      char_type*                _M_pback_end_save;
      bool                      _M_pback_init;
      const __codecvt_type*     _M_codecvt;
      char*                     _M_ext_buf;
      streamsize                _M_ext_buf_size;
      const char*               _M_ext_next;
      char*                     _M_ext_end;

Das alles für nll Funktionalität, versteht sich.

Folglich gilt für die files wie für die ausgabe wie für die strings wie für die gesamte Standardbibliothek folgendes: Sie ist zwar idiotensicher, aber inperformant. Lassen wir sie also für die weiteren Betrachtungen ausser acht.

Wie werden in C++ Threads implementiert? Man schreibt Wrapper um die Betriebssystemfunktionen in C.
Dann ist irgendwo ein C-Style Test
// initialisiere this->native_thread_ptr________ mit einem nativen Thread Pointer der offiziellen Funktion des Betriebssystems

if (this->native_thread_ptr________ == nullptr) // Jeder fähige C++-Programmierer hat irgendwo den templatigen nullptr-Trick liegen.
{ // neue Klammern gehören auf eine neue Zeile, alles andere ist Oracle Java-Style
  throw get_boost_from_this_boosty_library::i_can_t_create_the_thread_exception("Oh sorry, "
"the Thread creation failed, so I have to throw the "
"get_boost_from_this_boosty_library::i_can_t_create_the_thread_exception "
"exception"); // hier liegt ein unhandlicher C-Style-String im Speicher, weil 
// C++-Style-Strings noch mehr Overhead verursachen
}

Der Test ist in die Standard-Bibliothek ausgelagert, eine mündliche Abmachung zwischen dem Betriebssystementwickler und dem Ersteller der geschwindigkeitskritischen Anwendung ist verunmöglicht.

volkard schrieb:

Die, die schiefgehen können, weil eine Datei verschwunden ist, ein Puffer nicht allokiert werden konnte, ein Thread nicht erstellt werden konnte, eine Schriftart nicht geladen werden konnte und so weiter...

Datei habe ich oben gezeigt, den Thread auch und wenn eine Schriftart geladen wird gelten die vernichtenden Ausführungen immer noch.

DENN: Gtkmm, als einzige vernünftige C++ Komponentenbibliothek ist ein Wrapper von einer C-Library, Qt ist Performance-Bremse pur, wxWidgets kenne ich nicht (soll von Makros verseucht sein).

C wird verwendet um Bibliotheken zu schreiben, die von mehreren Sprachen benutzt werden können sollen, C++ bietet manchmal eine Wrapper dafür an.

Während du C folgendes schreibst, was zu deinem prophezeiten Overhead führt:

void foo(struct s *x) {
  // ...
  if (fail) { free(allocated_memory); return 1; 
  return 0;
}

// Aufruf:
if (foo(&x)) { /*  do exception handling */ }

würdest du in in C++ das schreiben:

void foo(s& x) // keine klassen, unnötiger overhead
{
  // ...
  if (fail)
  {
    // der Speicher wird vom Destruktor weggeräumt
    throw oops_i_fail_exception("..."); // <- hier steht eine ausführliche Problembeschreibung
  }
// ein return brauchts nicht, weil wir ja keinen succeed-Wert mehr haben
}

Aufruf:
foo(x)

Der fähige C-Programmierer übermittelt aber mündlich, was genau noch weggeräumt werden muss und dann sieht es so aus:

void foo(struct s *x) {
  // ...
  return fail;
}

// Aufruf:
if (foo(&x)) { free(allocated_memory); /* do exception handling */ }

// ich bin mir sicher, dass foo() jetzt _nicht_ fehlschlagen wird:
foo(&x); // ich habe eine überflüssige if-Abfrage vermieden, die in C++ gemacht wurde

Wie genau hast du das mit den exceptions gemeint?

[unfassbar]

Wenn ein Fehler auftritt muss das Programm sowieso beendet werden.

Danach hab ich aufgehört zu lesen.

Wirklich unfassbar, wie wenig Ahnung die Cler von den C++ Konzepten haben.

[volkard]

Cönner schrieb:

Das mit den zero-cost-exceptions geht in C auch:

#define QUOTEME_(x) #x
#define QUOTEME(x) QUOTEME_(x)
#define THROW(msg) { fprintf(stderr, "%s in " __FILE__ ": " QUOTEME(__LINE__) "\
\n",(msg));exit(255);}

Wenn ein Fehler auftritt muss das Programm sowieso beendet werden.

Nicht unbedingt. Außerdem hast Du so keinerlei close oder flush oder gracefully disconnet oder sowas gemacht. Um das hinzukriegen, mußt Du doch die Kosten zahlen.
Können wir uns darauf einigen, daß man ein Programm sinnvollerweise in recht viele kleine Funktionen zerlegt? Du mußt das return 255 (nicht exit!) den ganzen Aufrufbaum entlang hochreichen bis zur main, um überall die offenen Sachen schließen zu können. Deswegen brauchst Du über den ganzen Aufrufbaum hinweg die bösen ifs (mal das free weggelassen, das geschieht in C++ ja auch).

tuwas();//sicher fehlerfrei
if(!(rc=subfunktion(...)) return rc;//hier kann was schiefgehen
tuwas();//sicher fehlerfrei

In C++ reicht

tuwas();//sicher fehlerfrei
subfunktion(...);//hier kann was schiefgehen
tuwas();//sicher fehlerfrei

Das sind in C Mehrkosten, die Du nicht leugnen kannst.
OK, Du kannst sagen, daß Qt lahm wäre oder sowas. Aber der Hauptsatz der C++-Hasser, daß C++ vom Sprachdesign her prinzipiell langsamer wäre, ist hinfällig. Das Gegenteil ist sogar der Fall. C ist prinzipiell langsamer.

[volkard]

Cönner schrieb:

Aber ich bin mir sicher, std::basic_fstream wurde irgendwie so geschrieben:
...
Folglich gilt für die files wie für die ausgabe wie für die strings wie für die gesamte Standardbibliothek folgendes: Sie ist zwar idiotensicher, aber inperformant. Lassen wir sie also für die weiteren Betrachtungen ausser acht.

Ich bin nicht glücklich mit der stream-Bibliothek. Deswegen verwende ich sie privat auch nicht. Versuch doch mal, std::sort zu schlagen. Dann weißt Du, daß da auch brutale Geschwindigkeit zu finden ist.

Cönner schrieb:

Wie werden in C++ Threads implementiert? Man schreibt Wrapper um die Betriebssystemfunktionen in C.
Dann ist irgendwo ein C-Style Test
// initialisiere this->native_thread_ptr________ mit einem nativen Thread Pointer der offiziellen Funktion des Betriebssystems

if (this->native_thread_ptr________ == nullptr) // Jeder fähige C++-Programmierer hat irgendwo den templatigen nullptr-Trick liegen.
{ // neue Klammern gehören auf eine neue Zeile, alles andere ist Oracle Java-Style
  throw get_boost_from_this_boosty_library::i_can_t_create_the_thread_exception("Oh sorry, "
"the Thread creation failed, so I have to throw the "
"get_boost_from_this_boosty_library::i_can_t_create_the_thread_exception "
"exception"); // hier liegt ein unhandlicher C-Style-String im Speicher, weil 
// C++-Style-Strings noch mehr Overhead verursachen
}

Der Test ist in die Standard-Bibliothek ausgelagert, eine mündliche Abmachung zwischen dem Betriebssystementwickler und dem Ersteller der geschwindigkeitskritischen Anwendung ist verunmöglicht.

Hä? Was soll das? Was wird da verunmöglicht? Den einen Test brauchen wir beide. Oder willst Du mündlich abmachen, daß es grundsätzlich möglich ist, einen neuen Thread anzulegen? In C++ ist es nur diese eine if. In C sind es alle ifs den Aufrufbaum hinauf bis zur main().

Cönner schrieb:

volkard schrieb:

Die, die schiefgehen können, weil eine Datei verschwunden ist, ein Puffer nicht allokiert werden konnte, ein Thread nicht erstellt werden konnte, eine Schriftart nicht geladen werden konnte und so weiter...

Datei habe ich oben gezeigt, den Thread auch und wenn eine Schriftart geladen wird gelten die vernichtenden Ausführungen immer noch.

Welche vernichtenden Ausführungen?

Cönner schrieb:

Während du C folgendes schreibst, was zu deinem prophezeiten Overhead führt:

void foo(struct s *x) {
  // ...
  if (fail) { free(allocated_memory); return 1; }
  return 0;
}

// Aufruf:
if (foo(&x)) { /*  do exception handling */ }

würdest du in in C++ das schreiben:

void foo(s& x) // keine klassen, unnötiger overhead
{
  // ...
  if (fail)
  {
    // der Speicher wird vom Destruktor weggeräumt
    throw oops_i_fail_exception("..."); // <- hier steht eine ausführliche Problembeschreibung
  }
// ein return brauchts nicht, weil wir ja keinen succeed-Wert mehr haben
}

Aufruf:
foo(x)

Der fähige C-Programmierer übermittelt aber mündlich, was genau noch weggeräumt werden muss und dann sieht es so aus:

void foo(struct s *x) {
  // ...
  return fail;
}

// Aufruf:
if (foo(&x)) { free(allocated_memory); /* do exception handling */ }

// ich bin mir sicher, dass foo() jetzt _nicht_ fehlschlagen wird:
foo(&x); // ich habe eine überflüssige if-Abfrage vermieden, die in C++ gemacht wurde

Wie genau hast du das mit den exceptions gemeint?

Verstehe ich nicht. Welches if(fail)? Dein C++-Code hat doch weder Hand noch Fuß. Klassen erzeugen außerdem keinen Overhead.

[Cönner]

Die erste Aussage ist misslungen, entschuldigt.

std::sort schlagen, meinst du mit qsort? C hat eine kleinere Standardbibliothek als C++, deshalb verwende ich zusätzlich die GNU C Library, welche das mindestens so schnell kann (habs nicht gemessen).

volkard schrieb:

Cönner schrieb:

// initialisiere this->native_thread_ptr________ mit einem nativen Thread Pointer der offiziellen Funktion des Betriebssystems
if (this->native_thread_ptr________ == nullptr) // Jeder fähige C++-Programmierer hat irgendwo den templatigen nullptr-Trick liegen.
{ // neue Klammern gehören auf eine neue Zeile, alles andere ist Oracle Java-Style
  throw get_boost_from_this_boosty_library::i_can_t_create_the_thread_exception("Oh sorry, "
"the Thread creation failed, so I have to throw the "
"get_boost_from_this_boosty_library::i_can_t_create_the_thread_exception "
"exception"); // hier liegt ein unhandlicher C-Style-String im Speicher, weil 
// C++-Style-Strings noch mehr Overhead verursachen
}

Der Test ist in die Standard-Bibliothek ausgelagert, eine mündliche Abmachung zwischen dem Betriebssystementwickler und dem Ersteller der geschwindigkeitskritischen Anwendung ist verunmöglicht.

Hä? Was soll das? Was wird da verunmöglicht?

Wird nachher beschrieben. Die zentrale Aussage ist jedoch die folgende (Hauptsatz):
Der Test, welche man in C mit dem Rückgabewert macht, wird in C++ von der Funktion ausgeführt. Es ist also keine Geschwindigkeitseinbusse, ein if zu verwenden. Und weglassen ist in C++ nicht möglich.

volkard schrieb:

Welches if(fail)?

Mir fehlt ein typisches Beispiel für C++ exceptions.
Aus dem Kopf ist mir keines eingefallen und in http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.2 schreiben die nur folgendes hin:

void f10()
 {
   ...
   if (...some error condition...)
     throw some_exception();
   ...
 }

Ich will nur sagen: if (...some error condition...) kann man in C bei Bedarf weglassen, in C++ ist es immer da.

[Shade Of Mine]

Cönner schrieb:

std::sort schlagen, meinst du mit qsort? C hat eine kleinere Standardbibliothek als C++, deshalb verwende ich zusätzlich die GNU C Library, welche das mindestens so schnell kann (habs nicht gemessen).

Dann probier mal ein halbwegs generisches Sort in C zu schreiben. Es muss nicht so toll wie std::sort sein, aber wenigstens ein bisschen generisch sein, so dass ich nicht das komplette sort selber schreiben muss wenn ich etwas sortieren will.

Der Test, welche man in C mit dem Rückgabewert macht, wird in C++ von der Funktion ausgeführt. Es ist also keine Geschwindigkeitseinbusse, ein if zu verwenden. Und weglassen ist in C++ nicht möglich.

Das 1. if - ja. Aber du musst in C ja ueberall testen ob es erfolgreich war, da jede Funktion ja einen Fehler liefern kann. Du musst den Fehler ja per return durchreichen bis du ihn behandeln kannst. Das ist in C++ eben schneller, da du keine ifs hast und Compilermagie hier das erledigt.

[volkard]

Cönner schrieb:

std::sort schlagen, meinst du mit qsort? C hat eine kleinere Standardbibliothek als C++, deshalb verwende ich zusätzlich die GNU C Library, welche das mindestens so schnell kann (habs nicht gemessen).

Ist da ein qsort, das für jeden Vergleich eine Vergleichsfunktion aufrufen muß?
Falls ja: Das müssen wir in C++ nicht. Schneller.
Falls nein: Das muß wohl mal ausgemessen werden.
[/quote]

Cönner schrieb:

Der Test, welche man in C mit dem Rückgabewert macht, wird in C++ von der Funktion ausgeführt. Es ist also keine Geschwindigkeitseinbusse, ein if zu verwenden.

Klar. Die Funktionen zwischen hier un der main() brauchen das if aber nicht.

Cönner schrieb:

Und weglassen ist in C++ nicht möglich.

Klar.
Beispiel new(nothrow)

Cönner schrieb:

Ich will nur sagen: if (...some error condition...) kann man in C bei Bedarf weglassen, in C++ ist es immer da.

Da bin ich mir nicht so sicher.

[Cönner]

Shade Of Mine schrieb:

Dann probier mal ein halbwegs generisches Sort in C zu schreiben.

Hast du das nicht gesehen? `void *array' ist generisch.

Shade Of Mine schrieb:

Das 1. if - ja. Aber du musst in C ja ueberall testen ob es erfolgreich war, da jede Funktion ja einen Fehler liefern kann.

Wenn ich sicher bin, dass in der einen Funktion kein Fehler auftritt, kann ich mir das if sparen, in C++ geht das nicht

Meistens ist nur ein if vorhanden, das gibt schonmal den entscheidenden Geschwindigkeitsvorteil. Sobald mehrere if's vorhanden sind, benötigen C und C++ gleich lang (das letzt if wird gespart und beim Aufrufer hingeschrieben), ein weiterleiten der Fehler ist aber auch in C möglich.

[Cönner]

volkard schrieb:

Ist da ein qsort, das für jeden Vergleich eine Vergleichsfunktion aufrufen muß?
Falls ja: Das müssen wir in C++ nicht. Schneller.
Falls nein: Das muß wohl mal ausgemessen werden.

volkard schrieb:

Klar. Die Funktionen zwischen hier un der main() brauchen das if aber nicht.

Weiterleiten ist in C++ schneller, das gestehe ich ein. Ich sehe nur nicht ein, wo das (in C) so häufig gebraucht wird, dass es ein Problem wäre

volkard schrieb:

Beispiel new(nothrow)

In dem Fall schon (die hab ich vergessen), aber für jede Funktion eine nothrow-Überladung zu schreiben, bläht die Binary nur unnötig auf und ist so umständlich, dass das normalerweise beiseite geschoben wird.