Stilfrage zu meinem Code

Columbo

Das habe ich natürlich für Fließkommazahlen geschrieben.

Und ich habe nicht vor, ADL oder Unterstützung für vorzeichenlose Skalare zu ergänzen, um den TE nicht zu verwirren.

hustbaer

schrieb:

knivil schrieb:

Btw. Programmieren ist nicht wie Klavierspielen.

c.rackwitz schrieb:

Wenn du selber Code schreibst, musst du ihn auch verstehen. Code ist kein Haufen von wahllos zusammengeschmissenen Buchstaben und Zeichen, Code ist Logik pur. Du musst genau wissen, warum du wo und welches Zeichen setzt.

Nur um das spezifische Beispiel mal nicht unkritisiert zu lasse: Inwiefern nicht? Denkst du etwa, ein Komponist schmeißt wahllos Noten und Pausen in einen Topf?

Nicht völlig wahllos, nein.

Hat aber auch niemand behauptet. "Völlig wahllos zusammenschmeissen" ist nicht die Negation von "ganz genau wissen warum man wo was wie macht". Und "ganz genau wissen warum man wo was wie macht" kann ein Komponist nicht immer, denn sonst könnte er nie was neues komponieren. So könnte man nichtmal nen erfolgreichen Remix von irgendwas basteln.

Du scheinst recht gerne Aussagen falsch verstehen zu wollen. Bloss peinlich wenn du beim Kritisieren dann dumme Fehler machst.

volkard

Sone schrieb:

Wieso erstellst du einen vector mit fester Größe für zwei Variablen? Das muss doch schöner gehen. Eine Differenz-Funktion ist übrigens einfach so zu implementieren:
template<typename T>
T difference( T a, T b )
{
    return std::abs(a - b);
}
(Ein Bilderbuchbeispiel für ein Funktionstemplate)

Aber ganz schlechter Stil. Was Du implememntiert hast, wäre wohl absulute_difference, wobei man als Anwender wohl lieber abs(a-b) schreibt, also absolute_difference(a,b). difference(a,b) muss a-b sein,

Columbo

Aber ganz schlechter Stil.

Das ist der bequemlichkeit wegen kurz gehalten. Der TE hat ebenfalls Differenz geschrieben, ich habe nur sein Wort genommen und übersetzt.

Daher habe ich einen Vector genommen, von dem man die Zahlen nach jedem Durchlauf verwenden kann.

Das ist überflüssig. Ein vector ist ein dynamisches Array.
Edit: Nun gut, du kennst ja nichts anderes...

Columbo

Trifft es nicht schon dieses simple Programm:

#include <iostream>

int main()
{
	double min;
	std::cin >> min;
	double max = min;

	for( double current; std::cin >> current; )
		if( current > max )
		{
			max = current;
			std::cout << "Groesster bisher eingegebener Wert!\n";
		}
		else if( current < min )
		{
			min = current;
			std::cout << "Kleinster bisher eingegebener Wert!\n";
		}
}

Du hast ja in deinem Anfangsposting Code gepostet, der offensichtlich noch mehr macht - war das Teil der Aufgabenstellung?

volkard

schrieb:

for( double current; std::cin >> current; )

Das entwertet die Stärke des for-Schlüsselworts für die Verbesserung der Lesbarkeit typischer for-Schleifen.

Columbo

Bei mir hat es nicht mal für einen müden Schmunzler gereicht. Dagegen war der heilige Grahl in der Bluse definitiv ein Brüller.

Ernst kannst du das wohl kaum meinen.

volkard

schrieb:

Ernst kannst du das wohl kaum meinen.

Doch.

Columbo

volkard schrieb:

schrieb:

Ernst kannst du das wohl kaum meinen.

Doch.

Gut. Ich sehe ja, dass du (aus gutem Grund) die for-Schleife tatsächlich nur als Zähl-Schleife nutzt. Alles andere wäre das Zusammenpressen mehrerer Zeilen auf Eine durch den Missbrauch der for-Schleife.

Also

double current;
while( std::cin >> current )

Ich sah nun die obige Schleife als sehr gut lesbar an. Na gut, wenn du so konsequent in deinen Prinzipien bist - ich versuche die for-Schleife nicht zu missbrauchen, und habe fast nirgends eine stehen (weil ich keine Zählschleifen habe) . Aber das sah ich als absolut in Ordnung an.

schrieb:

ich versuche die for-Schleife nicht zu missbrauchen, und habe fast nirgends eine stehen (weil ich keine Zählschleifen habe)

Ist beides veraltet. Heutzutage schreibt man

for (int i : range(0, 10))
  // mach was mit i

und

for (double d : istream_range<double>(std::cin))
  // mach was mit d

Die Helferklassen zu schreiben ist trivial.

volkard

c++11kiddy schrieb:

schrieb:

ich versuche die for-Schleife nicht zu missbrauchen, und habe fast nirgends eine stehen (weil ich keine Zählschleifen habe)

Ist beides veraltet. Heutzutage schreibt man
for (int i : range(0, 10))
  // mach was mit i

Hab damit keine supi Erfahrungen gemacht, weil sie ruck zuck eklig werden, wenn die Schleifen nicht ganz so einfach sind.

Columbo

Beides völliger Unsinn.
(Und mit Unsinn beziehe ich mich auf die Lesbarkeit, die sich dadurch kein Stück verbessert hat)

Edit: Ich mache erstmal noch keine Aussagen bezüglich Performance...

volkard schrieb:

Hab damit keine supi Erfahrungen gemacht, weil sie ruck zuck eklig werden, wenn die Schleifen nicht ganz so einfach sind.

Man muss daran auch nicht pragmatisch festhalten.

Einfache Schleifen einfaches for.
Komplizierte Schleifen komplexes for.

schrieb:

Edit: Ich mache erstmal noch keine Aussagen

Columbo

Jetzt darf ich Aussagen tätigen.
Edit: Folgende Implementierung ist natürlich vereinfacht.

#include <iostream>

template< typename Type >
struct range_impl
{
	Type a, b;

	range_impl( Type a, Type b ):
		a{a}, b{b} {}

	struct Proxy
	{
		Type val;

		Proxy( Type m ):
			val(m) {}

		bool operator!=( Proxy const& p ){ return val != p.val; }
		Proxy& operator++(){ ++val; return *this; }
		Type operator*() { return val; } // prvalue
	};

	Proxy begin() { return a; }
	Proxy end() { return b; }
};

template< typename Type >
range_impl<Type> range( Type a, Type b ) { return {a, b}; }

int main()
{
	unsigned value = 0;
	auto first = clock();

	for( auto i : range_impl<unsigned>(0, 1 << 31 ) )
		value += i;

	std::cout << "Time: " << clock() - first << " value: " << value << '\n';

	value = 0; first = clock();

	for( unsigned i = 0; i != 1 << 31; ++i )
		value += i;

	std::cout << "Time: " << clock() - first << " value: " << value << '\n';
}

Ergibt, dass deine Variante ohne Optimierungslevel etwa 1.1 bis 1.2 mal mehr Zeit braucht. (Getestet auf Clang 3.3 und GCC 4.9)

Edit: Deine Variante ist natürlich nur etwas langsamer ohne Optimierung. Mit Optimierung wird wahrscheinlich die zweite Schleife wegoptimiert... daher macht das Beispiel wenig sinn...

BIOSzillator

@ *
Danke. Ich wusste gar nicht, dass man eine for Schleife so benutzen kann.
In deinem Beispiel wurde das Problem der Initialisierung der beiden Variablen min und max gelöst, worüber ich die ganze Zeit schon nachgedacht habe.
Und das ist genau das, was ich in meinem Anfangspost gemeint hatte. Wenn ich dann soetwas lese, ist es plötzlich logisch für mich.
"Wenn ich nicht möchte, dass die Variablen immer wieder initialisiert werden, muss die Initialisierung außerhalb der Schleife statt finden."

Zu deiner Frage, warum mein Code mehr macht, als in der Aufgabe stand:
Die Aufgabe hat aufeinander aufgebaut. Die Aufgabe, um die sich der Thread handelt ist Nr. 6.
Hier mal die genauen Aufgabenstellungen:

1. Schreiben Sie ein Programm, das aus einer while-Schleife besteht, die bei jedem Schleifendurchlauf zwei int-Werte einliest und diese dann ausgibt. Verlassen Sie das Programm, wenn zum Beenden ein '|' eingegeben wurde.

2. Ändern Sie das Programm so, dass die Ausgabe lautet: „Der kleinere Wert ist: “, gefolgt von der kleineren der beiden Zahlen und weiter „Der größere Wert ist:“, gefolgt von dem größeren Wert.

3. Erweitern Sie das Programm so, dass es die Zeile „Die Zahlen sind gleich“ ausgibt, wenn die Zahlen gleich sind.

4. Ändern Sie das Programm so, dass es double-Werte statt int-Werte verwendet.

5. Ändern Sie das Programm so, dass es erst die größere und dann die kleinere Zahl ausgibt und anschließend die Zeile „Die Zahlen sind fast gleich“, wenn die beiden Zahlen sich um weniger als 1,0/10.000.000 unterscheiden.

6. Ändern Sie jetzt den Schleifenrumpf, sodass er bei jedem Schleifendurchlauf nur einen double Wert einliest. Definieren Sie zwei Variablen um festzuhalten, welcher Wert bisher der kleinste und bisher der größte war. Geben Sie nach jedem Schleifendurchlauf den eingegebenen Wert aus. Wenn es der bisher kleinste Wert war, schreiben Sie nach der ausgegebenen Zahl „bisher der kleinste Wert“, und wenn es der bisher größte Wert war, schreiben Sie nach der Zahl „bisher der größte Wert“.

@Hustbaer

Ich glaube, dass du einen etwas falschen Eindruck vom Remixen und dem Musik machen ansich hast.
Vielleicht habe ich deinen Post ja auch nur falsch verstanden, jedoch klingt deine Aussage nach:
"Kein Musikproduzent weiß was er da macht, denn ansonsten könnte es keine neue Musik mehr geben."

Als Musiker muss man genau so wissen, was man mit den 12 Noten macht, die einem zur Verfügung stehen. Jeder der sich mal etwas mit Musiktheorie beschäftigt hat, weiß was ich meine.
Ganz Kritisch wird es im Mixing und Mastering. Wenn man da etwas falsch macht, klingt es ganz schnell, ganz schön scheiße.
Es soll jetzt hier aber nicht weiter um Musik gehen. Nur als Ergänzung...

schrieb:

Jetzt darf ich Aussagen tätigen.
[...]
Ergibt, dass deine Variante selbst mit -O2 immer noch etwa 1.1 bis 1.2 mal mehr Zeit braucht. (Getestet auf Clang 3.3 und GCC 4.9)

Nächstes Mal bitte richtig messen, danke.

Ich bin überzeugt, dass, wenn du zuerst die normale for-Loop testest und dann die range-based, dass dann die range-based schneller ist.

Wieso? Weil erst std::cout << "Time: " aufgerufen wird, was dazu führt das die Bibliothek geladen werden muss und dann erst clock(). Das zweite Mal ist sie schon da.

Aber es ist sinnlos zu messen, denn beide erzeugen den gleichen Assemblercode, deshalb sind beide gleich schnell.

Darum bleibe bei:

schrieb:

Edit: Ich mache erstmal noch keine Aussagen

Columbo

Edit: Blödsinn.

Aber es ist sinnlos zu messen, denn beide erzeugen den gleichen Assemblercode, deshalb sind beide gleich schnell.

Verlinke mal GCC Explorer.

schrieb:

ohne Optimierung:

Wayne?

Und warum kannst du nicht gcc-Explorer verlinken?

http://gcc.godbolt.org/#{%22version%22%3A3%2C%22filterAsm%22%3A{%22labels%22%3Atrue%2C%22directives%22%3Atrue%2C%22commentOnly%22%3Atrue}%2C%22compilers%22%3A[{%22source%22%3A%22namespace%20{\ntemplate%20%3Ctypename%20Type%3E%20struct%20range_impl%20{\n%20%20Type%20a%2C%20b%3B\n\n%20%20range_impl%28Type%20a%2C%20Type%20b%29%20%3A%20a{%20a%20}%2C%20b{%20b%20}%20{}\n\n%20%20struct%20Proxy%20{\n%20%20%20%20Type%20val%3B\n\n%20%20%20%20Proxy%28Type%20m%29%20%3A%20val%28m%29%20{}\n\n%20%20%20%20bool%20operator!%3D%28Proxy%20const%20%26p%29%20{%20return%20val%20!%3D%20p.val%3B%20}\n%20%20%20%20Proxy%20%26operator%2B%2B%28%29%20{\n%20%20%20%20%20%20%2B%2Bval%3B\n%20%20%20%20%20%20return%20*this%3B\n%20%20%20%20}\n%20%20%20%20Type%20operator*%28%29%20{%20return%20val%3B%20}%20%2F%2F%20prvalue\n%20%20}%3B\n\n%20%20Proxy%20begin%28%29%20{%20return%20a%3B%20}\n%20%20Proxy%20end%28%29%20{%20return%20b%3B%20}\n}%3B\n\ntemplate%20%3Ctypename%20Type%3E%20range_impl%3CType%3E%20range%28Type%20a%2C%20Type%20b%29%20{\n%20%20return%20{%20a%2C%20b%20}%3B\n}\n}\n\nvoid%20f%28int%29%3B\n\nvoid%20a%28%29%20{\n%20%20for%20%28auto%20i%20%3A%20range_impl%3Cunsigned%3E%280%2C%201%20%3C%3C%2031%29%29\n%20%20%20%20f%28i%29%3B\n}\nvoid%20b%28%29%20{\n%20%20for%20%28unsigned%20i%20%3D%200%3B%20i%20!%3D%201u%20%3C%3C%2031%3B%20%2B%2Bi%29\n%20%20%20%20f%28i%29%3B\n}%22%2C%22compiler%22%3A%22%2Fopt%2Fclang-3.3%2Fbin%2Fclang%2B%2B%22%2C%22options%22%3A%22-O3%20-std%3Dc%2B%2B11%22}]}

Columbo

Wayne?

Ich werde doch keine Optimierung anschalten. Dann bist du doch bei diesem Beispiel im Nachteil.

Edit: NAtürlich, bei deinem GCC-Explorer-Beispiel ist Optimierung angebracht.

Hier:

int main()
{
	unsigned value = 0;
	auto first = clock();

	for( unsigned i = 0; i != 1u << 31u; ++i )
		value += i;

	auto time = clock() - first;
	std::cout << "Time: " << time << " value: " << value << '\n';

	value = 0; first = clock();

	for( auto i : range_impl<unsigned>(0, 1u << 31u ) )
		value += i;

	time = clock() - first;
	std::cout << "Time: " << time << " value: " << value << '\n';
}

Ausgabe, ohne Optimierung versteht sich:

Time: 5220916 value: 3221225472
Time: 14310359 value: 3221225472

Columbo

Abgesehen, dass natürlich die Abbruchbedingung eigentlich Quark ist (1 << 31 ist bei 32-Bit int s im Zweierkomplement $-2^{31}$ ...), macht das alles keinen Unterschied.
Keiner benutzt das, solange nicht klar feststeht, das beide immer dieselbe Performance haben. Assembler auf -O2/3 hin oder her. Wie sieht es mit VC++ aus? Optimiert VC++ 2012 das ganze auch so schön wie die neuesten GCC- und Clang-Versionen?