Warum programmiert ihr in C?

[OMGOMG]

OMG Volkard lass es einfach. Auch du wirst hier niemanden mehr das missratene C++ schmackhaft machen. C++ ist genauso angenehm wie Durchfall. Es gibt unter den bekannten Progammiersprachen kaum einen größeren Schrott als C++. Wenn du irgendwann mit dem Studium fertig bist und vielleicht mal in der realen Welt ein Projekt abbekommst dann wähle bitte nicht C++ als erste Sprache.

[volkard]

Cönner schrieb:

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.

Es ist aber auch sehr selten, daß man einen syscall nicht testen muß, ob er geklappt hat. Aber auch da bin ich mit meinen Klassen nicht verbohrt. Zum Beispiel bin ich so frech, niemals zu prüfen, ob ein CloseHandle funktioniert hat (das muß aber unser kleines Geheimnis bleiben, wenn Du das im C++-Forum ausplauderst, werde ich vielleicht gesteinigt).
Das Aufblähen hier ist als ein space-time tradeoff zu betrachten. Das zero-cost exception handling übrigens auch. Für PCs empfehle ich es. Für embedded Kisten mit arg wenig Speicher natürlich nicht.

[Zusammenfassung]

Ich fasse zusammen:

Die, die gegen C++ trollen, haben die Sprache und ihre Konzepte nicht verstanden.
Die, die sachliche Argumente für C++ bringen, haben beide Sprachen und deren Konzepte verstanden - ist ja bei C auch nicht so schwierig.

[dot]

Is doch eh klar. Für jemanden der C++ und die Konzepte dahinter verstanden hat gibts keinen Grund gegen C++ zu trollen

[kenner der programmierer]

dot schrieb:

Is doch eh klar. Für jemanden der C++ und die Konzepte dahinter verstanden hat gibts keinen Grund gegen C++ zu trollen

zum glück gibts ja keine guten c-coder (sonst würden sie ja dieses für sie zu anspruchsvolle c++ verstehen)

[C pfund]

Also ich programmier in C#, zählt das auch?

[Zustimmer]

Zusammenfassung schrieb:

Ich fasse zusammen:

Die, die gegen C++ trollen, haben die Sprache und ihre Konzepte nicht verstanden.
Die, die sachliche Argumente für C++ bringen, haben beide Sprachen und deren Konzepte verstanden - ist ja bei C auch nicht so schwierig.

Trifft den Nagel aufn Kopf

[Rudías]

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.

bool <T>::operator==(<T>) ist ja auch bestimmt keine Vergleichsfunktion.

[volkard]

Rudías schrieb:

bool <T>::operator==(<T>) ist ja auch bestimmt keine Vergleichsfunktion.

Natürlich war eine gemeint, die nicht inline ist.

//C
#include <stdlib.h>
#include <stdio.h>
#include <time.h>

#define SIZE (1024*1024*64)

int comp(const void* a,const void* b){
	return *(unsigned int*)a-*(unsigned int*)b;
}

int main(){
	unsigned int* arr=malloc(SIZE*sizeof(unsigned int));
	int i;
	unsigned int hash=0;
	clock_t start,end;
	for(i=0;i<SIZE;i++)
		arr[i]=rand();
	start=clock();
	qsort(arr,SIZE,sizeof(unsigned int),comp);
	end=clock();
	for(i=0;i<SIZE;i++){
//		printf("%8x\n",arr[i]);
		hash+=3*hash+arr[i];
	}
	printf("hash: %8x\n",hash);
	printf("%f secs",(end-start)/(double)CLOCKS_PER_SEC);
	return 0;
}

//C++
#include <cstdlib>
#include <cstdio>
#include <ctime>
#include <algorithm>
using namespace std;

#define SIZE (1024*1024*64)

struct comp{
	bool operator()(unsigned int const& a,unsigned int const& b){
		return a<b;
	}
};

int main(){
	unsigned int* arr=(unsigned int*)malloc(SIZE*sizeof(unsigned int));
	int i;
	unsigned int hash=0;
	clock_t start,end;
	for(i=0;i<SIZE;i++)
		arr[i]=rand();
	start=clock();
	sort(arr,arr+SIZE,comp());
	end=clock();
	for(i=0;i<SIZE;i++){
//		printf("%8x\n",arr[i]);
		hash+=3*hash+arr[i];
	}
	printf("hash: %8x\n",hash);
	printf("%f secs",(end-start)/(double)CLOCKS_PER_SEC);
	return 0;
}

//C++-func
#include <cstdlib>
#include <cstdio>
#include <ctime>
#include <algorithm>
using namespace std;

#define SIZE (1024*1024*64)

/*struct comp{
	bool operator()(unsigned int const& a,unsigned int const& b){
		return a<b;
	}
};*/
bool comp(unsigned int const& a,unsigned int const& b){
	return a<b;
}

int main(){
	unsigned int* arr=(unsigned int*)malloc(SIZE*sizeof(unsigned int));
	int i;
	unsigned int hash=0;
	clock_t start,end;
	for(i=0;i<SIZE;i++)
		arr[i]=rand();
	start=clock();
	sort(arr,arr+SIZE,comp);
	end=clock();
	for(i=0;i<SIZE;i++){
//		printf("%8x\n",arr[i]);
		hash+=3*hash+arr[i];
	}
	printf("hash: %8x\n",hash);
	printf("%f secs",(end-start)/(double)CLOCKS_PER_SEC);
	return 0;
}

Zugegeben, der Test ist gemein und künstlich. Er soll nur den Effekt der Komparator-Klasse als Template-Argument darstellen.

Bei mir kommt übrigens raus, aber nicht stabil, weil ich so viel Mist nebenher laufen habe.
qsort: 19.8s
std::sort mit Funktionszeiger: 16.8s
std::sort mit Komparatorklasse: 8.6s

[volkard]

Cönner schrieb:

std::sort schlagen, meinst du mit qsort?

Nein, qsort hatte ich eigentlich als Kandidaten gar nicht in Erwägung gezogen wegen der Funktionsaufrufe. Ich meinte mit allen zur Verfügung stehenden Mitteln, solange Dein Verfahren auf Vergleichen basiert.

std::sort ist normalerweise so schnell, daß ich es nicht schneller hinkriege (vergleichsbasierend). Ich will nicht ausschließen, daß Du es schaffst. Aber vermutlich brauchst Du schon ein paar Tage dafür, wenn nicht mehr. Aber dann würdest auch Du sagen, daß std::sort verflixt schnell ist.

[__--]

@volkard

okay also vergleichen wir jetzt eine sort funktion mit geinlineter vergleichsfunktion (was dann auch pro zu sortierendem datentyp eine eigene funktion erfordert) vs. normaler vergleichsfunktion

derart ungleiche vergleiche sehe ich besonders gerne... evtl. erklärst uns nächstes mal den unterschied zwischen einem segelflieger und nem a380

[volkard]

__-- schrieb:

@volkard
okay also vergleichen wir jetzt eine sort funktion mit geinlineter vergleichsfunktion (was dann auch pro zu sortierendem datentyp eine eigene funktion erfordert) vs. normaler vergleichsfunktion

Ja, klar. Als noch ausstehende Klarstellung zu

Cönner schrieb:

Ups, das erste Zitat (Performanz von qsort) habe ich gar nicht beantwortet.
Also ja, es muss jedesmal eine Funktion ausgeführt werden, die Sortierung ist aber `arbitrary' (für Standardtypen gibts natürlich ne andere).
Und in C++ muss auch immer ein Funktionsobjekt aufgerufen werden (im Notfall kann es mit __force_inline ein ganz kleines bisschen schneller sein als mein qsort)

nebst

volkard schrieb:

Zugegeben, der Test ist gemein und künstlich. Er soll nur den Effekt der Komparator-Klasse als Template-Argument darstellen.

(Damit ist gemeint, daß wir jetzt eine sort funktion mit geinlineter vergleichsfunktion (was dann auch pro zu sortierendem datentyp eine eigene funktion erfordert) vs. normaler vergleichsfunktion vergleichen tun, um mal zu schauen, was das Inlinen hier bringen bewirken könnte. Das ist doch auch für C-Leute ein wichtiges Ergebnis. Es heißt, daß man gelegentlich es nicht bei qsort bewenden lassen darf, sondern in die #define-#include-Trickkiste greifen muß, und speziell angepaßte Sortierfunktionen instanziieren. Freu Dich doch darüber, daß ich Dir so spannendes Wissen vor die Füße lege.)

[__--]

ja gebe zu, der vergleich hat mich schon ein bischen überrascht. ändert aber nichts daran, dass nicht die sprache (c) sondern die umsetzung/implementation langsam ist

[volkard]

__-- schrieb:

ja gebe zu, der vergleich hat mich schon ein bischen überrascht. ändert aber nichts daran, dass nicht die sprache (c) sondern die umsetzung/implementation langsam ist

~(Genau das sage ich über cout und Konsorten. )~
Diesbezüglich sind wir ganz einer Meinung. Deswegen legte ich auch Wert darauf, in der Auswertung
qsort
std::sort mit Funktionszeiger
std::sort mit Komparatorklasse
zu schreiben und nicht C, C++-func und C++, wie ich die Dateien genannt hatte.

[cuser123]

Ich programmiere in C weil ich damit die meiste Kontrolle über mein Programm habe und man schnell zum Ziel kommt.

[lowbyte-]

Mann könnte ja auch einfach sagen, dass die C++ troller keine Ahnung haben wie man in C richtig Software implementiert!

Nichts gegen C++.

Beide Sprachen haben ihre stärken und schwächen. Deshalb könnt ihr langsam ein close darunter setzen.

[knivil]

rotf-äh schrieb:

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

C-- -> http://www.cminusminus.org/ wird als Zwischensprache beim Kompilieren von Haskell benutzt und hat wenig mit dem Thema zu tun.

__-- schrieb:

ja gebe zu, der vergleich hat mich schon ein bischen überrascht. ändert aber nichts daran, dass nicht die sprache (c) sondern die umsetzung/implementation langsam ist

Ach? Haben aber nicht alle wegen Performance auf der Sprache herumgehackt? Die Sprache an sich hat selten was Geschwindigkeit zu tun, sie ist eben nur eine Sprache definiert in irgendeinem Textdokument.

Irgendwie verstehe ich die ganzen Argumente nicht mehr. Um was gehts eigentlich?

[mngbd]

volkard schrieb:

Damit ist gemeint, daß wir jetzt eine sort funktion mit geinlineter vergleichsfunktion (was dann auch pro zu sortierendem datentyp eine eigene funktion erfordert) vs. normaler vergleichsfunktion vergleichen tun, um mal zu schauen, was das Inlinen hier bringen bewirken könnte. Das ist doch auch für C-Leute ein wichtiges Ergebnis.

Zumindest ich wüsste das gerne. Gibt es da verlässliche Vergleichsdaten?

[__--]

knivil schrieb:

Ach? Haben aber nicht alle wegen Performance auf der Sprache herumgehackt?

kann auch sein das sich bei anderen eingabedaten/array größen andere werte ergeben. worüber sich die c'ler aufregen ist nicht die umsetzung eines sort... es ist das paket, der overhead usw... das muß deswegen auch nicht langsamer sein.

und dann gibt es auch einfach noch einen aspekt den man nicht wegdiskutieren kann und das ist geschmack :p

[totalerstuss]

Lasst euch doch von den Dumpfbacken hier nicht erzählen man bekommt in C nicht einen schnellere Implementierung eines qsort hin als in C++, das ist totaler Quatsch.

Wenn du willst ist dein C Programm IMMER schneller als ein C++ Programm, das mag vielleicht nicht immer der große Faktor sein aber hier zu behaupten C++ ist schneller als C ist der größte Humbug den ich seit langem gelesen habe. Vielleicht mag das noch für irgendwelche Standardimplementierungen manchmal hinhauen aber nicht wenn man selbst implementiert und optimiert, da ist C naturbedingt näher an der Maschine dran als C++.