Vector Liste (Zahlen in Wörter ausgeben lassen - und anders herum)

kralo9

manni66 schrieb:

Skym0sh0 schrieb:
return 0x0;
Funktioniert das Programm besser, wenn man die Null hexadezimal zurück liefert?

Sicher nicht.

Skym0sh0

kralo9 schrieb:

manni66 schrieb:
Skym0sh0 schrieb:
return 0x0;
Funktioniert das Programm besser, wenn man die Null hexadezimal zurück liefert?
Sicher nicht.

Klar tuts das. Probiers mal, das macht dich zum Ultra-M3g4-H3xxx00rZ!

kralo9

Skym0sh0 schrieb:

kralo9 schrieb:
manni66 schrieb:
Skym0sh0 schrieb:
return 0x0;
Funktioniert das Programm besser, wenn man die Null hexadezimal zurück liefert?
Sicher nicht.
Klar tuts das. Probiers mal, das macht dich zum Ultra-M3g4-H3xxx00rZ!

D4$ 1$7 J4 M41 V011 1337 !!!

Columbo

Aus Spaß für alle Zahlen < 100:

#include <stdexcept>
#include <string>

std::string from_number( unsigned i )
{
	char const* einer []{ "null", "ein", "zwei", "drei", "vier", "fuenf", "sechs", "sieben", "acht", "neun",
	                      "zehn", "elf", "zwoelf", "dreizehn", "vierzehn", "fuenfzehn", "sechszehn", "siebzehn", "achtzehn", "neunzehn" };
	char const* zehner[]{ "zwanzig", "dreissig", "vierzig", "fuenfzig", "sechzig", "siebzig", "achtzig", "neunzig" };

	if( i < 20 )
		if(i == 1)
			return "eins";
		else
			return einer[i];
	else if( i < 100 )
	{
		std::string suffix = zehner[i/10-2];

		auto rest = i%10;
		if( rest )
			return std::string{einer[rest]} + "und" + suffix;

		return suffix;
	}

	throw std::invalid_argument{""};
}

#include <iostream>

int main()
{
	for( unsigned i = 0; i != 100; ++i )
		std::cout << from_number(i) << '\n';
}

martini3k1

Vielen, vielen Dank schon mal für die hilfreichen Antworten. Habe es zwar noch nicht wirklich hinbekommen, aber jetzt kann ich weitersuchen /-arbeiten.

Nathan

Dereferenzierungsoperator, musst du unbedingt {} als Konstruktorsyntax verwenden.
Diese Syntax ist unter gewissen Umständen einfach nur lästig und kann zu ungewollten Ergebnissen führen, weswegen man dann doch auf () ausweichen muss, was dazu führt, dass die "vereinheitlichte Initialisierung" gar nicht mehr vereinheitlicht ist, und man direkt () hätte verwenden können.
Und deine Exceptionfehlermeldungen sind einfach nur informativ.

Columbo

Nathan schrieb:

Und deine Exceptionfehlermeldungen sind einfach nur informativ.

Das sollen sie nicht sein. Bei Exceptions reicht der Typ.
Edit: Ich würde nicht auf die Idee kommen, dem User die Exception-Fehlermeldung auszugeben - und was soll ich sonst damit?

Eigentlich sollte man vielleicht doch einen leeren String zurückgeben.

Dereferenzierungsoperator

Wen meinst du?

Ja, Marcus hat mich schlussendlich umbenannt.

Diese Syntax ist unter gewissen Umständen einfach nur lästig und kann zu ungewollten Ergebnissen führen, weswegen man dann doch auf () ausweichen muss, was dazu führt, dass die "vereinheitlichte Initialisierung" gar nicht mehr vereinheitlicht ist, und man direkt () hätte verwenden können.

Siehe diesen GotW-Artikel, insbesondere Abschnitt 3/4.

Nathan

Arcoth schrieb:

Nathan schrieb:

Und deine Exceptionfehlermeldungen sind einfach nur informativ.

Das sollen sie nicht sein. Bei Exceptions reicht der Typ.
Edit: Ich würde nicht auf die Idee kommen, dem User die Exception-Fehlermeldung auszugeben - und was soll ich sonst damit?

Eigentlich sollte man vielleicht doch einen leeren String zurückgeben.

Es ist für dich klarer.
Wenn du ein riesiges Projekt hast und irgendwo in deiner main ein invalid argument auftauchst, weißt du dann direkt, woher das kommt?
Nein. Deshalb kurz in einer Fehlermeldung wenigstens den Funktionsnamen erwähnen.

Diese Syntax ist unter gewissen Umständen einfach nur lästig und kann zu ungewollten Ergebnissen führen, weswegen man dann doch auf () ausweichen muss, was dazu führt, dass die "vereinheitlichte Initialisierung" gar nicht mehr vereinheitlicht ist, und man direkt () hätte verwenden können.

Siehe diesen GotW-Artikel, insbesondere Abschnitt 3/4.

Ja, Herb Sutter bringt Argumente dafür. Toll. Und?
Das einzige Argument, was für mich zählt ist der "vexing parse".
Ich verwende keine structs ohne Konstruktor und schreibe keinen generischen Code, der irgendetwas initialisieren soll.
Um initializer_list-Konstruktoren aufzurufen, verwende ich natürlich {}, die Arrayinitialisierung zählt für mich dazu.
Aber in allen anderen Fällen, nutz ich (). Ich erwisch so immer die richtigen Konstruktoren und hat für mich auch keine negativen Effekte.

Columbo

Nein. Deshalb kurz in einer Fehlermeldung wenigstens den Funktionsnamen erwähnen.

Habe ich gerade perfekten und an deine Gewohnheiten angepassten Code liefern wollen? Das war auf die Schnelle hin konstruiert, und kein universales Etwas!

Wenn du ein riesiges Projekt hast und irgendwo in deiner main ein invalid argument auftauchst, weißt du dann direkt, woher das kommt?

Wieso will ich nur wissen, woher das kommt? Ich möchte auch wissen, wann der Fehler auftrat, was das Funktionsargument war, ich möchte den Call-Stack sehen, usw. Kurz: Ich möchte debuggen.

Hast du es jetzt nötig, einen nebenbei geschriebenen, funktionierenden Code auf solche lächerlichen Nebensächlichkeiten zu analysieren, die nicht mal irgendwelche Allgemeingültigkeiten sind? Wenn du das unbedingt ausdiskutieren willst, öffne einen neuen Thread, aber fülle den hier nicht mit so einer Kritik.

Aber in allen anderen Fällen, nutz ich (). Ich erwisch so immer die richtigen Konstruktoren und hat für mich auch keine negativen Effekte.

Wen interessiert es, was du benutzt? Du benutzt, was du benutzt, und ich tue, was ich für richtig halte. Du krempelst das hier irgendwie zu einer Diskussion über Uniform-Initialization um.

Verstehe mich bitte nicht falsch - - das hat hier alles einfach nichts zu suchen, es war nur ein Beispiel für den TE, an dem ich immer noch nichts auszusetzen habe. Außer, dass man wohl einen leeren String zurückgeben könnte, anstelle einer Exception.

Arcoth schrieb:

Nein. Deshalb kurz in einer Fehlermeldung wenigstens den Funktionsnamen erwähnen.

Habe ich gerade perfekten und an deine Gewohnheiten angepassten Code liefern wollen? Das war auf die Schnelle hin konstruiert, und kein universales Etwas!

Wie das war kein universales Etwas?

Wenn du ein riesiges Projekt hast und irgendwo in deiner main ein invalid argument auftauchst, weißt du dann direkt, woher das kommt?

Wieso will ich nur wissen, woher das kommt? Ich möchte auch wissen, wann der Fehler auftrat, was das Funktionsargument war, ich möchte den Call-Stack sehen, usw. Kurz: Ich möchte debuggen.

Naja, beim invalid_argument weiß man eigentlich, sobald man die Funktion weiß wo das Problem an der Sache ist und muss nicht großartig debuggen.

Hast du es jetzt nötig, einen nebenbei geschriebenen, funktionierenden Code auf solche lächerlichen Nebensächlichkeiten zu analysieren, die nicht mal irgendwelche Allgemeingültigkeiten sind? Wenn du das unbedingt ausdiskutieren willst, öffne einen neuen Thread, aber fülle den hier nicht mit so einer Kritik.

Hast recht, gehört hier nicht hin.

Aber in allen anderen Fällen, nutz ich (). Ich erwisch so immer die richtigen Konstruktoren und hat für mich auch keine negativen Effekte.

Wen interessiert es, was du benutzt? Du benutzt, was du benutzt, und ich tue, was ich für richtig halte. Du krempelst das hier irgendwie zu einer Diskussion über Uniform-Initialization um.

Eigentlich hat mich an {} nur gestört, dass das für einen Anfänger evtl. unverständlich ist. Warum ich das nicht geschrieben habe, sondern stattdessen diese Diskussion losgetreten habe, weiß ich auch nicht.

Belli

Was für Anfänger (un)verständlich ist, und was nicht, hat Sone noch nie interessiert ...

Columbo

Belli schrieb:

Was für Anfänger (un)verständlich ist, und was nicht, hat Sone noch nie interessiert ...

Und was genau war daran nicht verständlich? Um die vier Zeichen?

Und nicht einmal die. Dass ich einen String erzeuge, um zwei weitere an ihn dranzuhängen, ist intuitiv klar.

Belli

Ich habe hier nichts konkret kritisiert, sondern nur geäußert, was mir in anderen, älteren Postings/Threads oft aufgefallen ist.

Das Thema Ausgabe von Zahlen als Text hatten wir schon mal im Forum