Eine Sprache = Nur ein mittel zum Zweck

[Perice]

Ja C++ ist schon seit längerem auf dem absteigendem Ast. Spätestens mit der Einführung der neuen .NET Technologie und dem Erstarken von C# hat die Relevanz von C++ im Alltag drastisch abgenommen. Die Zukunft auf der Microsoft Plattform wird langfristig eine Zukunft ohne C++ sein und für systemnahe Programmierung gibt es geeignetere Sprachen als C++, beispielsweise C. C++ wurde also quasi der Boden unter den Füßen weggezogen, wenn du so willst.

[volkard]

Perice schrieb:

und für systemnahe Programmierung gibt es geeignetere Sprachen als C++, beispielsweise C.

Ja, genau mein Punkt.

Technisch gesehen ist das totaler Unfug. Für systemnahe Programme ist C++ enorm viel geeigneter als C. Wenn man die 20K für Exceptions nicht bezahlen mag, darf man halt keine nehmen. Wenn man die 500k für cout nicht bezahlen mag, darf man es eben nicht nehmen. Wenn man den bloat durch parallele fast gleiche Templates nicht haben mag, muß man sie halt meiden. Meistens reicht es bereits, eine Millisekunde lang nachzudenken und sich an cheshire cat classes erinnern.
Aber trotzdem denken viele Leute, C++ sei irgendwie systemweiterweg als C. Wenn der Sourcecode identischen asm-Code erzeugt, ist da nix weiter weg. Und man hat die zusätzliche Möglichkeit, wegen der viel besseren Verständlichkeit ordentlicher Objektorientierung verdammt viel bessere Programme/Treiber/Kernels oder wasauchimmer zu bauen. Auch hier wieder wäre ist die Bescheidenheit der Schlüssel.

Realistisch gesehen kannst Du echt recht haben.

[u_ser-l]

hier zahlt es sich tatsächlich aus, daß die "Objektorientierung" von C++ eher ein "namespace feature" als eine echte Objektprogrammierung ist.

[HabenDerSindDasSeit]

volkard schrieb:

Auch hier wieder wäre ist die Bescheidenheit der Schlüssel.

Oder deutsch...

[Bulli]

Perice schrieb:

Ja C++ ist schon seit längerem auf dem absteigendem Ast. Spätestens mit der Einführung der neuen .NET Technologie und dem Erstarken von C# hat die Relevanz von C++ im Alltag drastisch abgenommen. Die Zukunft auf der Microsoft Plattform wird langfristig eine Zukunft ohne C++ sein und für systemnahe Programmierung gibt es geeignetere Sprachen als C++, beispielsweise C. C++ wurde also quasi der Boden unter den Füßen weggezogen, wenn du so willst.

Klar, deswegen ist auch hier im C++-Forum täglich so viel los. Und deshalb gibt es jeden Tag einen Neuling der fragt, wie er am besten C++ lernt. Und deshalb kommen ja auch jedes Jahr neue Compiler-Versionen von MS, Intel, Codegear und GNU auf den Markt, weil immer weniger Leute C++ brauchen.

[kirschens]

volkard schrieb:

Perice schrieb:

und für systemnahe Programmierung gibt es geeignetere Sprachen als C++, beispielsweise C.

Ja, genau mein Punkt.

Technisch gesehen ist das totaler Unfug. Für systemnahe Programme ist C++ enorm viel geeigneter als C. Wenn man die 20K für Exceptions nicht bezahlen mag, darf man halt keine nehmen. Wenn man die 500k für cout nicht bezahlen mag, darf man es eben nicht nehmen. Wenn man den bloat durch parallele fast gleiche Templates nicht haben mag, muß man sie halt meiden. Meistens reicht es bereits, eine Millisekunde lang nachzudenken und sich an cheshire cat classes erinnern.
Aber trotzdem denken viele Leute, C++ sei irgendwie systemweiterweg als C. Wenn der Sourcecode identischen asm-Code erzeugt, ist da nix weiter weg. Und man hat die zusätzliche Möglichkeit, wegen der viel besseren Verständlichkeit ordentlicher Objektorientierung verdammt viel bessere Programme/Treiber/Kernels oder wasauchimmer zu bauen. Auch hier wieder wäre ist die Bescheidenheit der Schlüssel.

Realistisch gesehen kannst Du echt recht haben.

Aufgrund der mangelnden kompilierberkeit von c++ in auf embeddeten System stellt C immer noch die erste Wahl der Programmiersprachen für Systemitgergation mittels Hardwarenaher Systeme dar. Was nutzt einem eine der Sprachen die mit allen der Mitteln des Programmierenden zur verfügung gestellt hat,, wenn mann doch nur einen Bruchteil bietet der imprinzieb dem entsprechen tut was die erstere hat? Der von C++ erzeugte assembeler code wird nämlich auch nicht identischer im C Coder dargestellt, wenn ein optimierter C Code generiert wird. Da kann C++ nur hinterher hinken. Wie schon das alte Sprichwort sagt. Mit C++ kann man sich ein Bein weg scheißen und dann ist man deutlich lahmsamer!

[Gast]

Bulli schrieb:

Perice schrieb:

Ja C++ ist schon seit längerem auf dem absteigendem Ast. Spätestens mit der Einführung der neuen .NET Technologie und dem Erstarken von C# hat die Relevanz von C++ im Alltag drastisch abgenommen. Die Zukunft auf der Microsoft Plattform wird langfristig eine Zukunft ohne C++ sein und für systemnahe Programmierung gibt es geeignetere Sprachen als C++, beispielsweise C. C++ wurde also quasi der Boden unter den Füßen weggezogen, wenn du so willst.

Klar, deswegen ist auch hier im C++-Forum täglich so viel los. Und deshalb gibt es jeden Tag einen Neuling der fragt, wie er am besten C++ lernt.

Ich weiss, wilde Spekulation, aber es könnte ja vielleicht daran liegen, dass die domain c-plusplus.net ist?

[player4245]

naja c wurde ja gott sei dank dem "tollen" comitee zu alt sonst hätten sie das auch noch so verschandelt

[Gast]

Nene, C wird schon noch aktiv verunstaltet.

[player4245]

wirklich? wie?

[Senfkohl]

C++ ist nichts halbes und nichts ganzes. Wie schon gesagt, kann man natürlich mit C++ genauso systemnahmen Code schreiben wie mit C. Aber wenn man dies tut, nutzt man lediglich die Sprachfeatures von C++, die es aus C übernommen hat, ergo kann man auch gleich bei C bleiben. Für den Highlevel- und Userbereich gibt es bekanntlich weitaus komfortablerer und effektivere Sprachen als C++. Man muss sich also fragen was C++ für eine Daseinsberechtigung hat. Wirklich sinnvolle Einsatzgebiete gibt es für diese Sprache heutzutage kaum noch.

[u_ser-l]

für Resourcen-kritische Mittel- und Großprojekte ist C++ nach wie vor mit die erste Wahl.

[volkard]

Senfkohl schrieb:

C++ ist nichts halbes und nichts ganzes. Wie schon gesagt, kann man natürlich mit C++ genauso systemnahmen Code schreiben wie mit C. Aber wenn man dies tut, nutzt man lediglich die Sprachfeatures von C++, die es aus C übernommen hat, ergo kann man auch gleich bei C bleiben.

Nein. Man benutzt Klassen und Templates und und und.

Beispiel von voriger Woche:
Für ein wenig mathematiklastiges Zeugs möchte ich sehr schnell Quadratzahlen generieren.
Kleines Meßprogramm, um zu sehen, ob JedesmalQuadrieren oder UngeradeZahlenAufsummieren besser ist.

#include <iostream>
#include <ctime>

using namespace std;

class SquareGenerator{
	private:
	int value_;
	int step_;
	public:
	SquareGenerator(){
		value_=1;
		step_=1;
	}
	inline void step(){
		step_+=2;
		value_+=step_;
	}
	int value(){
		return value_;
	}
};

int main()
{
	int sum=0;
	clock_t start=clock();
	for(int o=0;o<1000000;++o){
#if 1
		for(int i=1;i<10000;++i)
			sum+=i*i;
#else
		for(SquareGenerator s;s.value()<100000000;s.step())
			sum+=s.value();
#endif
	}
	cout<<clock()-start<<'\n';
	cout<<sum<<'\n';
    return 0;
}

macht mit #if 1

L6:
	movl	$1, %edx
	.p2align 2,,3
L7:
	movl	%edx, %eax
	imull	%edx, %eax
	addl	%eax, %ebx
	incl	%edx
	cmpl	$10000, %edx
	jne	L7
	incl	%ecx
	cmpl	$1000000, %ecx
	jne	L6

Der Code sieht überzeugend aus.

Aber macht mit #if 0

L6:
	movl	$1, %eax
	movl	$3, %edx
	.p2align 2,,3
L7:
	addl	%eax, %ebx
	addl	%edx, %eax
	addl	$2, %edx
	cmpl	$99999999, %eax
	jle	L7
	incl	%ecx
	cmpl	$1000000, %ecx
	jne	L6

Kann man da auch nur im gerinsgten sehen, daß

for(SquareGenerator s;s.value()<100000000;s.step())
			sum+=s.value();

statt entsprechendem C-Code verwendet wurde, der mir aufgewürdet hätte, die Quadratzahlenlogik mit der sie benutzenden Logik zu vermischen? Nein. Alles sauber und hundertprozentig wegoptimiert.
C++ erlaubt es, daß man viel weiter abstrahiert, als es in C möglich ist, und doch kommt der gleiche Code raus. Mit C++ muß man keine Zusatzkosten für Abstraktion zahlen.

[player4245]

also ich persönlich mag C ja lieber als c++, denn es ist eine kompakte sprache.

[+fricky]

hustbaer schrieb:

Irgendwie finde ich die Argumentation "schlechter weil mehr Features" etwas komisch. Die liesse sich genauso auf LINQ oder andere neue C# Features anwenden. Aber jeder liebt LINQ. Wieso liebt dann nicht jeder den neuen C++ Standard

vielleicht liegts daran, dass LINQ ein an sich separates element ist, das zwar in die .NET-sprache(n) integriert, aber einen ganz bestimmten, fest umrissenen zweck erfüllen soll (ähnlich embedded-SQL in anderen sprachen). z.b. .NET-anwendungen, die nix mit datenbanken machen, werden davon nicht berührt. dem gegenüber erscheinen die neuerungen des C++ standards als wildes, unausgegorenes durcheinander. teilweise wurde versucht, mängel zu beseitigen, andererseits wurde an vielen ecken neues drangeflickt, wovon heute noch niemand ahnen kann, welche konsequenzen das mal haben wird. wahrscheinlich wird's zu 'ner radikalen änderung führen, wie in zukunft in C++ programmiert wird.

[volkard]

+fricky schrieb:

vielleicht liegts daran, dass LINQ ein an sich separates element ist, das zwar in die .NET-sprache(n) integriert, aber einen ganz bestimmten, fest umrissenen zweck erfüllen soll (ähnlich embedded-SQL in anderen sprachen). z.b. .NET-anwendungen, die nix mit datenbanken machen, werden davon nicht berührt.

so ähnlich wäre mein idealbild der c++-anwendungen. was man nicht braucht, verwendet man einfach nicht.

+fricky schrieb:

wahrscheinlich wird's zu 'ner radikalen änderung führen, wie in zukunft in C++ programmiert wird.

ich denke, die neuerungen im c++-standard sind alle berechtigt und sehr sehr toll. nur krankt c++ an forderung, zu allen älteren standard und sogar zu c kompatibel sein zu wollen.
ohne den ballast sollte man mal versuchen, eine sprache zu bauen, die konsequent das zero-abstraction-overhead-prinzip durchzieht (macht c++ nämlich nicht) und noch dazu einfach ist (ist c++ nämlich nicht).
egal, wie es ausgeht, der neue c++-standard wird mit sicherheit ganz enorme auswirkungen auf die anderen großen sprachen und zukünftige sprachen haben. es wird außerdem wie damals bei den templates wohl zehn jahr dauern, bis man die ganzen möglichkeiten entdeckt, die drin stecken.
manche sachen wie die rvalue referenzen schreien danach, eine neue sprache zu bauen, die das kann, aber nicht so gefrickelt ist. initializer lists, die ihre größe nicht zur compilezeit kennen, das ist doch zum heulen!, aber die syntax ist der richtige weg.

[+fricky]

volkard schrieb:

+fricky schrieb:

vielleicht liegts daran, dass LINQ ein an sich separates element ist, das zwar in die .NET-sprache(n) integriert, aber einen ganz bestimmten, fest umrissenen zweck erfüllen soll (ähnlich embedded-SQL in anderen sprachen). z.b. .NET-anwendungen, die nix mit datenbanken machen, werden davon nicht berührt.

so ähnlich wäre mein idealbild der c++-anwendungen. was man nicht braucht, verwendet man einfach nicht.

naja, bei z.b. sowas LINQ wirste aber nur vor die wahl gestellt, wenn du's mit datenbanken zu tun kriegst. und die ist einfach nur: benutze ich's, oder mach' ich aus irgendwelchen gründen eine konventionelle lösung. aber in C++ gibts selbst für kleinkram viele verschiedene möglichkeiten, das gleiche zu tun und jede hat ihre ganz eigenen sonderbaren nebeneffekte. das macht C++ sogar im kleinen schon sperrig und schwer benutzbar.

volkard schrieb:

aber die syntax ist der richtige weg.

...vielleicht. wenn man chinesisch mag.

[volkard]

+fricky schrieb:

volkard schrieb:

aber die syntax ist der richtige weg.

...vielleicht. wenn man chinesisch mag.

Naja, beim von mir genannten, ist es ok, würde ich sagen.
Vector<int> v(5); lege ein Array an mit 5 Elementen.
Vector<int> v{5}; lege ein Array an mit nur einem Element, nämlich 5.
Die Idee ist gut und damit lassen sich etliche seltsame Schnittstellen dahingehend vereinfachen, daß man nicht mehr ins Handbuch gucken muß, auch in Basic und vielen anderen Sprachen.

Aber klar gibt es auch Seiten, die man wirklich nur dulden kann in der Annahme, daß die Kompatibilität zu bestehendem Code die oberste Maxime ist:

Explicit conversion operators
Standard C++ added the explicit keyword as a modifier on constructors to prevent single-argument constructors to be used as implicit type conversion operators. However, this does nothing for actual conversion operators. For example, a smart pointer class may have an operator bool() to allow it to act more like a primitive pointer: if it includes this conversion, it can be tested with if(smart_ptr_variable) (which would be true if the pointer was non-null and false otherwise). However, this allows other, unintended conversions as well. Because C++ bool is defined as an arithmetic type, it can be implicitly converted to integral or even floating-point types, which allows for mathematical operations that are not intended by the user.
In C++0x, the explicit keyword can now be applied to conversion operators. As with constructors, it prevents the use of those conversion functions in implicit conversions. However, language contexts that specifically require a boolean value (the conditions of if-statements and loops, as well as operands to the logical operators) count as explicit conversions and can thus use a bool conversion operator.

Und die schreien danach, daß man alte Zöpfe abschneidet.

[quadratulending]

volkard schrieb:

#include <iostream>
#include <ctime>

using namespace std;

class SquareGenerator{
	private:
	int value_;
	int step_;
	public:
	SquareGenerator(){
		value_=1;
		step_=1;
	}
	inline void step(){
		step_+=2;
		value_+=step_;
	}
	int value(){
		return value_;
	}
};

int main()
{
	int sum=0;
	clock_t start=clock();
	for(int o=0;o<1000000;++o){
#if 1
		for(int i=1;i<10000;++i)
			sum+=i*i;
#else
		for(SquareGenerator s;s.value()<100000000;s.step())
			sum+=s.value();
#endif
	}
	cout<<clock()-start<<'\n';
	cout<<sum<<'\n';
    return 0;
}

Der SquareGenerator ist langsamer, unleserlicher und nicht mal const correct. Und die Klammerung deutet auch eine gespaltene persönlichkeit hin. :p

[u_ser-l]

... und weitere Mehrfachbelegungen syntaktischer Elemente: extern, auto, [], und wieviele unterschiedliche Bedeutungen ":" haben wird, wer will es zählen?

Was ich nach wie vor sehr in C++ vermisse, ist eine einfache Möglichkeit, das Typsystem zu umgehen, etwa, indem fehlende Typangaben in Variablen- und Funktionsdeklarationen implizit als ein besonderer Typ "dontcare" angenommen werden, der die Typprüfung des Compilers für diese Variable, Funktion o.ä. aufhebt, sodaß bei Bedarf für rapid prototyping ein "late bindung" Stil programmiert werden kann.

Das wäre mal was

Was gibt es denn in C++0x Neues, das nicht in der einen oder anderen Form in der einen oder anderen Programmiersprache schon lange realisiert wäre?