Warum programmiert ihr in C?

Wenn du C und C++ code mischt, so wie es auch Stroustrup durchaus begrüßt wenn die Funktionen gut gekapselt sind, dann würde für die meisten hier eine Welt zusammenbrechen. Die sind sich hier selbst nicht einig was nun das beste ist. Zuerst wollte C++ das bessere C sein, dann sollte es bloss nix mit C zu tun haben und so weiter und so fort.

Das Problem ist nicht C++, sondern das offensichtlich ein Grossteil der Cler KEINE Ahnung hat von C++.

Auch scheinen sie Komplexe zu haben. Es weiss eh jeder, dass C++ in jeder Hinsicht ueberlegen ist und drum verteidigen sie so aggressiv und polemisch ihr kleines C. Suess

It0101

nöööööööö schrieb:

Wenn du C und C++ code mischt, so wie es auch Stroustrup durchaus begrüßt wenn die Funktionen gut gekapselt sind, dann würde für die meisten hier eine Welt zusammenbrechen.

ganz genau: Auf die Kapselung kommt es an. Wenn Funktionalität sauber, z.B. in einer Klasse, gekapselt ist, ist doch völlig wurst ob drinnen C oder C++ zum Einsatz kommt. Und wenn in dem Anwendungsfall C-Code oder sogar Assembler-Code Performance-Vorteile bringt, dann ist das aus meiner Sicht absolut legitim.

Das die Only-STL-C++-Fanboys ( will jetzt hier keine Namen nennen ) vielleicht dann einen Herzinfarkt erleiden, ist mir relativ Wumpe, aber ich kenn das von dir angesprochene Problem aus dem Forum hier sehr gut

Wer in seinen C++ Code C einbaut, hat einfach keine Ahnung. Das sind dann auch die Leute, die printf() fuer ueberlegener halten als Streams.

It0101

trolldetector schrieb:

Wer in seinen C++ Code C einbaut, hat einfach keine Ahnung. Das sind dann auch die Leute, die printf() fuer ueberlegener halten als Streams.

Von printf ist hier nicht die Rede... es geht um Performance.
Bei Dateizugriffen und Textausgaben nutze ich auch nur streams...

Wo sieht denn C++ Code mit STL, Boost, Templates etc besser aus? Da gruseln sich doch selbst die alten Hasen für solch einem Code.

It0101 schrieb:

nöööööööö schrieb:

Wenn du C und C++ code mischt, so wie es auch Stroustrup durchaus begrüßt wenn die Funktionen gut gekapselt sind, dann würde für die meisten hier eine Welt zusammenbrechen.

ganz genau: Auf die Kapselung kommt es an. Wenn Funktionalität sauber, z.B. in einer Klasse, gekapselt ist, ist doch völlig wurst ob drinnen C oder C++ zum Einsatz kommt. Und wenn in dem Anwendungsfall C-Code oder sogar Assembler-Code Performance-Vorteile bringt, dann ist das aus meiner Sicht absolut legitim.

Das die Only-STL-C++-Fanboys ( will jetzt hier keine Namen nennen ) vielleicht dann einen Herzinfarkt erleiden, ist mir relativ Wumpe, aber ich kenn das von dir angesprochene Problem aus dem Forum hier sehr gut

Du bist der erste vernünftige C++ Coder den ich hier gesehen habe

It0101 schrieb:

trolldetector schrieb:

Wer in seinen C++ Code C einbaut, hat einfach keine Ahnung. Das sind dann auch die Leute, die printf() fuer ueberlegener halten als Streams.

Von printf ist hier nicht die Rede... es geht um Performance.
Bei Dateizugriffen und Textausgaben nutze ich auch nur streams...

Dann nenn mir mal ein Beispiel, wo C gegenueber C++ schneller ist.

It0101

Zum Beispiel benötigte ich vor längerer Zeit mal eine sehr spezielle Liste. Eine Spezialanwendung sozusagen.

Das von mir selbst programmierte maßgeschneiderte Template mit C-Code war 2% schneller als der dafür am besten geeignete STL-Container...

Manche STL-Container und Klassen sind einfach zu oversized, so dass eine C-Implementierung für Spezialfälle dann durchaus Sinn macht.

Nur als Beispiel... Es gibt sicher in anderen Bereichen noch mehr Beispiele dafür, die nicht mal unbedingt Spezialanwendungen sein müssen.

Michael E.

Inwiefern war das C-Code und inwiefern war er schneller als entsprechender C++-Code? Kann man in C++ nicht mehr eigene Container schreiben?

It0101 schrieb:

Zum Beispiel benötigte ich vor längerer Zeit mal eine sehr spezielle Liste. Eine Spezialanwendung sozusagen.

Das von mir selbst programmierte maßgeschneiderte Template mit C-Code war 2% schneller als der dafür am besten geeignete STL-Container...

Manche STL-Container und Klassen sind einfach zu oversized, so dass eine C-Implementierung für Spezialfälle dann durchaus Sinn macht.

LOL. Und was hat das jetzt mit C++ zu tun? Du vergleichst gerade C mit der STL. Merkst was?
Wenn ein STL Container nicht passt, dann schreibt man sich halt einen. Nur deshalb gleich auf das unkomfortable C umsteigen, macht Null Sinn.

Wieder einmal zeigen die Cler, dass sie einfach keine Ahnung haben und nicht mal wissen, dass C++ einfach eine Obermenge ist. Wenn ich gleichwertigen Code habe, dann ist der in C++ mindestens genauso schnell und wenn ich C++ spezifische Konstrukte habe, dann ist der Nachbau in C MAXIMAL gleich schnell.

It0101

Erklär das hier mal den Fanboys... Für die meisten ist hier C++ untrennbar mit der STL verbunden Und selbst deine Ansicht, sich selbst nen Container zu schreiben wird hier nicht von vielen unterstützt. Das is praktisch Blasphemie

Es gibt sogar Fälle wo man mit C++ Standardmitteln über 30x langsamer als mit C-Mitteln ist. Komfort kostet halt meist Performance und die STL ist bei weitem nicht das Allheilmitteln als das es hier oft angepriesen wird.

Das Optimum aus Performance und Komfort bekommt man wenn man C mit Klassen schreibt und die ganze STL weg lässt.

Ach wie schnell und sparsam wären unsere Systeme wenn alles in sauberen C geschrieben wäre. Dann würde die System auch mit schnellerer Hardware schneller werden und nicht immer langsamer.

Michael E.

It0101 schrieb:

Erklär das hier mal den Fanboys... Für die meisten ist hier C++ untrennbar mit der STL verbunden Und selbst deine Ansicht, sich selbst nen Container zu schreiben wird hier nicht von vielen unterstützt. Das is praktisch Blasphemie

Blödsinn. Wenns auf 2% Performance ankommt, kannst du dir ruhig ne eigene Liste schreiben. Du musst mir mal einen zeigen, der dir da widerspricht.

amuesierter schrieb:

It0101 schrieb:

Zum Beispiel benötigte ich vor längerer Zeit mal eine sehr spezielle Liste. Eine Spezialanwendung sozusagen.

Das von mir selbst programmierte maßgeschneiderte Template mit C-Code war 2% schneller als der dafür am besten geeignete STL-Container...

Manche STL-Container und Klassen sind einfach zu oversized, so dass eine C-Implementierung für Spezialfälle dann durchaus Sinn macht.

LOL. Und was hat das jetzt mit C++ zu tun? Du vergleichst gerade C mit der STL. Merkst was?
Wenn ein STL Container nicht passt, dann schreibt man sich halt einen. Nur deshalb gleich auf das unkomfortable C umsteigen, macht Null Sinn.

Wieder einmal zeigen die Cler, dass sie einfach keine Ahnung haben und nicht mal wissen, dass C++ einfach eine Obermenge ist. Wenn ich gleichwertigen Code habe, dann ist der in C++ mindestens genauso schnell und wenn ich C++ spezifische Konstrukte habe, dann ist der Nachbau in C MAXIMAL gleich schnell.

träum weiter

It0101 schrieb:

Erklär das hier mal den Fanboys... Für die meisten ist hier C++ untrennbar mit der STL verbunden Und selbst deine Ansicht, sich selbst nen Container zu schreiben wird hier nicht von vielen unterstützt. Das is praktisch Blasphemie

Red dich hier nicht raus. DU vermischst hier einfach total verschiedene Sachen. Bei deinem Verstaendnis wette ich, dass du die 2% einfach willkuerlich genannt hast, oder falsch gemessen hast.

Sag doch mal, was das fuer eine "Spezialliste" gewesen sein soll. Und am besten zeig mal deinen Code mit der Messung.

Michael E.

g56zh5433 schrieb:

Es gibt sogar Fälle wo man mit C++ Standardmitteln über 30x langsamer als mit C-Mitteln ist.

Hier hat schonmal jemand vom Faktor 36 geredet. Ich hätte mal gerne ein Beispiel, bei dem auch nur der Faktor 10 rauskommt.

Das Optimum aus Performance und Komfort bekommt man wenn man C mit Klassen schreibt und die ganze STL weg lässt.

Weil generische Programmierung sooo langsam ist Auch hier: Beispiel.

It0101

int FindC( char *cText, char c )
{
    char *p = cText;
    while ( *p )
        if ( *p++ == c )
            return p - cText - 1;
    return -1;
}

Diese Funktion sucht nach einem Character in einem String.
Diese Funktion ist z.B. ca. 30% schneller als die STL-Variante mit std::string::find( .. )!

Kann ja jetzt jeder selber ausprobieren.
std::string ist ja sicherlich das bevorzugte Mittel der C++-Fanboys

(bei mir getestet mit MSVC-Compiler - für gcc war ich zu faul ^^ )

It0101

Michael E. schrieb:

g56zh5433 schrieb:

Es gibt sogar Fälle wo man mit C++ Standardmitteln über 30x langsamer als mit C-Mitteln ist.

Hier hat schonmal jemand vom Faktor 36 geredet. Ich hätte mal gerne ein Beispiel, bei dem auch nur der Faktor 10 rauskommt.

Das Optimum aus Performance und Komfort bekommt man wenn man C mit Klassen schreibt und die ganze STL weg lässt.

Weil generische Programmierung sooo langsam ist Auch hier: Beispiel.

Also Faktor 10 oder gar 36 halte ich für totalen Schwachsinn... Meistens sind beide Lösungen gleichermaßen schnell.

Michael E.

It0101 schrieb:

int FindC( char *cText, char c )
{
    char *p = cText;
    while ( *p )
        if ( *p++ == c )
            return p - cText - 1;
    return -1;
}
Diese Funktion sucht nach einem Character in einem String.
Diese Funktion ist z.B. ca. 30% schneller als die STL-Variante mit std::string::find( .. )!

Das ist ja schon fast ein Armutszeugnis. Gefordert war Faktor 30, als Antwort kamen angebliche 30%, aber in der Realität ist std::string schneller

#include <iostream>
#include <string>
#include <boost/date_time/posix_time/posix_time_types.hpp>
using namespace std;
using namespace boost::posix_time;

int FindC( const char* const cText, const char c )
{
    const char* p = cText;
    while ( *p )
        if ( *p++ == c )
            return p - cText - 1;
    return -1;
} 

int main()
{
	const char* const foo = "Dies ist mein supertoller String, in dem was gesucht werden muss";
	string bar = foo;
	int runs = 10000000;
	unsigned long counter = 0;

	ptime start = microsec_clock::local_time();
	for(int i = 0; i < runs; ++i)
	{
		counter += FindC(foo, 'w');
		//counter += (bar.find('w'));
	}
	time_duration duration = microsec_clock::local_time() - start;
	cout << counter << endl;
	cout << duration.total_milliseconds() << " ms";
}

mit FindC ca. 518ms, mit string::find ca. 410ms.

VS 2008 /Ox /I "D:\boost\boost_1_42" /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /FD /EHsc /MT /Fo"Release\" /Fd"Release\vc90.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt