Problem mit Variablen in einem einfachen Programm.

camper

size_t wird in <cstio>, <cstdlib>, <cstring> und <ctime> deklariert.

Sone schrieb:

size_t ist ein Groessentyp. Die Anzahl von Cents ist eine Groesse.

Nicht jeder mit einer Erleuchtung ist auch ein Prophet. Die meisten sind bloss Spinner.

Sone schrieb:

Edit: Ausserdem braucht man <cstring> fuer size_t fast nie einzubinden, da das die meisten anderen Header schon machen...

Keiner der anderen Standardheader bindet <cstring> ausdrücklich ein. Zudem ist "fast nie" gerade kein Grund, einen benötigten Header auszulassen.

Sone

Wutz schrieb:

Deine Behauptung ist falsch.

*lol*

Folgendes steht in einem Standardheader von MinGW (GCC 4.6.2):

#ifdef _WIN64//Ausnahme
_    _MINGW_EXTENSION typedef unsigned __int64 size_t;
#else
    typedef unsigned int size_t;
#endif /* _WIN64 */

Klar ist das im Standard nicht garantiert. Aber es einem Anfaenger so genau zu machen ist laecherlich unnoetig.

size_t ist ein Groessentyp. Die Anzahl von Cents ist eine Groesse.

Nicht jeder mit einer Erleuchtung ist auch ein Prophet. Die meisten sind bloss Spinner.

Ich sehe nach wie vor kein Problem, fuer eine Anzahl size_t zu verwenden. Klar war meine Formulierung bescheuert. Trotzdem sehe ich kein Problem.

Edit: Ausserdem braucht man <cstring> fuer size_t fast nie einzubinden, da das die meisten anderen Header schon machen...

Keiner der anderen Standardheader bindet <cstring> ausdrücklich ein.

Mit "das" meinte ich, size_t deklarieren. Edit: Jup, ich muss mich anders ausdruecken.
Denn bspw. binde ich <iostream>, <string> o. ae. ein, ist size_t deklariert. Ich musste noch nie wegen size_t explizit einen deiner genannten Header einbinden.

otze

Sone schrieb:

Ich sehe nach wie vor kein Problem, fuer eine Anzahl size_t zu verwenden. Klar war meine Formulierung bescheuert. Trotzdem sehe ich kein Problem.

Das Problem ist zum Beispiel, dass size_t nicht nur eine bestimmte Größe beschreibt, sondern die Größen von Speicherbereichen.

camper

Sone schrieb:

Klar ist das im Standard nicht garantiert. Aber es einem Anfaenger so genau zu machen ist laecherlich unnoetig.

Das eine ist korrekt, das andere nicht. Demnächst fängst du noch an, J.W. zu zitieren.

Sone schrieb:

camper schrieb:

Sone schrieb:

size_t ist ein Groessentyp. Die Anzahl von Cents ist eine Groesse.

Nicht jeder mit einer Erleuchtung ist auch ein Prophet. Die meisten sind bloss Spinner.

Ich sehe nach wie vor kein Problem, fuer eine Anzahl size_t zu verwenden. Klar war meine Formulierung bescheuert. Trotzdem sehe ich kein Problem.

Das Problem fängt damit an, dass du die zu lösende Aufgabe nicht kennst. Was ist z.B. mit negativen Geldbeträgen? Je nach Aufgabenstellung ist so etwas sinnvoll oder eben auch nicht. Ein Warenpreis wird (m.E.) nie negativ sein, ein Kontostand ist das schon mal. Und überhaupt, bloss weil das Programm auf einem alten Rechner läuft, soll ich nicht mit hohen Millionbeträgen (in Euro) umgehen können?

Sone schrieb:

camper schrieb:

Sone schrieb:

Edit: Ausserdem braucht man <cstring> fuer size_t fast nie einzubinden, da das die meisten anderen Header schon machen...

Keiner der anderen Standardheader bindet <cstring> ausdrücklich ein.

Mit "das" meinte ich, size_t deklarieren. Edit: Jup, ich muss mich anders ausdruecken.
Denn bspw. binde ich <iostream>, <string> o. ae. ein, ist size_t deklariert. Ich musste noch nie wegen size_t explizit einen deiner genannten Header einbinden.

In diesem Forum geht es um C++, vorzugsweise solches, das auch noch standardkonform ist. Nicht um deine persönlichen Erfahrungen. Die können vielleicht Indiz, aber niemals Grund sein.
Irgendwann werden die Header sicher auch noch in Bezug auf size_t aufgeräumt werden. Wäre ja z.B. kein Problem, intern einen anderen Bezeichner wie __size_t oder so zu verwenden.

Sone

[InGedanken]Haette ich bloss einfach int genommen, einfach int![/InGedanken]

Ist ja gut.

camper

benimus schrieb:

SeppJ schrieb:

Wie immer: float ist der ungeeignetste Datentyp für Geld. Die vermeintliche Ähnlichkeit ist rein optisch, logisch ist ein sehr großer Unterschied.

Und welcher typ wäre passender?

Nur zum Verständnis:
Gleitkommawerte wie float und double bieten eine Genauigkeit, die von der absoluten Größe des dargestellten Wertes abhängt. D.h. der relative Fehler des Wertes ist (näherungsweise) konstant.
Das macht diese Typen geeignet für wissenschaftlich-technische Berechnungen, denn dort arbeitet man für gewöhnlich mit Größen, die einen gewissen bekannten Fehler relativ zur ihrer Größe aufweisen.

Finanzanwendungen sind da völlig anders: Geldbeträge sind in den allermeisten Fällen (wenn wir mal von Schätzwerten absehen) exakte (und diskrete) Größen. Und auch Rechenergebnisse (selbst wenn sie als Ergebnis eines Rundungsschrittes entstehen) sind exakt bzgl. dessen, was sie darstellen.
Für derartige Berechnungen sind integrale Typen oder auch Festkommatypen, wie es sie in einigen Sprachen gibt, geeignet.
Je nach Aufgabentyp wird man für gewöhnlich Rechnungen mit einer gewissen Grundeinheit durchführen, von der bekannt ist, dass hiervon keine Bruchteile auftreten können. Das können Euro sein, cent, vielleicht auch 1/100 cent (kennt man z.B. von Telefonkostenabrechnungen mit Einzelverbindungen) oder etwas anderes Aufgabenspezifisches.

" long double " und " long long " sind geignet um Geldwerte darzustellen und spielen auch perfekt mt dem Standard zusammen. Wer absehbar größere, oder genauere Geldwerte darstellen muss kann ja hier weiter lamentieren und andere Typen nutzen.

Gruß und Kuss,
Furble Wurble

Swordfish

camper schrieb:

Das können Euro sein, cent, vielleicht auch 1/100 cent (kennt man z.B. von Telefonkostenabrechnungen mit Einzelverbindungen) oder etwas anderes Aufgabenspezifisches.

... wie zB. 1/10 pip (1 pip = 10^-4 x der Standardeinheit einer Währung) am forex Markt.

Furble Wurble schrieb:

" long double " und " long long " sind geignet ...

Eine Floating point variable ist in Finanzanwendungen nie geeignet - wie " long " sie auch sein möge.

Sone

Furble Wurble schrieb:

" long double " und " long long " sind geignet um Geldwerte darzustellen und spielen auch perfekt mt dem Standard zusammen. Wer absehbar größere, oder genauere Geldwerte darstellen muss kann ja hier weiter lamentieren und andere Typen nutzen.

Nope, long double ist eien Fliesskommazahl und damit unpassend (wie schoen von camper beschrieben).

Allerdings schlage ich die GMP vor, wenn es um deutsche und US-Staatsverschuldungen geht

hustbaer

Sone schrieb:

Man sollte auf cent-Basis rechnen (nicht einlesen umbedingt). Macht bei Programmierergehaelten sowieso mehr sinn

Mit Scaling-Factor 100 zu rechnen ist wohl eine ziemlich dumme Idee.

Wenn man bloss Addieren und Subtrahieren muss UND immer nur mit Währungen zu tun hat deren Untereinheit (Cent, Pence etc.) einen Wert von 1/100, 1/20 oder sowas hat, dann kann man u.U. damit wegkommen.
Wenn man multiplizieren oder dividieren muss (Rabatte, Steuern, Zinsen etc.), dann hat man verloren.
Und wenn man die Software mal nach Kuwait, Bahrain, Tunesien etc. verkaufen will, dann hat man auch verloren (Untereinheit mit Wert 1/1000).

So lange man mit Addieren und Subtrahieren auskommt bietet sich ein Scaling-Factor von 10000 an. Damit deckt man im Moment alles ab, und hat auch ziemlich gute Chancen in Zukunft nicht auf die Nase zu fallen. Und dann natürlich mindestens mit int64, obwohl auch das in bestimmten Situationen grenzwertig werden könnte.

Und sobald man irgendwas machen möchte was auch nur in Richtung Buchhaltung geht sollte man sich gefälligst das passende Gesetz besorgen und genauestens umsetzen.

Vermutlich ist dann die vernünftigste Variante gleich einen eigenen Datentyp zu definieren, denn dann muss man z.B. zu jeder Zahl auch mit abspeichern ob sie bereits gerundet wurde, und auf wie viele Stellen.

Sone

hustbaer schrieb:

Sone schrieb:

Man sollte auf cent-Basis rechnen (nicht einlesen umbedingt). Macht bei Programmierergehaelten sowieso mehr sinn

Mit Scaling-Factor 100 zu rechnen ist wohl eine ziemlich dumme Idee.

Seid ihr eigentlich alle doof oder so? Sorry, aber das ist verdammt nochmal ein Anfaengerprogramm. Wenn wir eine professionelle International-Erwerbbare Software entwickeln moechten, sagt das doch...

Eisflamme

Das ist halt das Gute. Wenn TE sich hier alles durchliest, jeder Anmerkung bis ins Detail nachgeht und sie umsetzt, dann kann er sein Programm auch als eine professionelle, international erwerbbare Software vermarkten.

SeppJ

Nur mal so zur Anmerkung: Es ist ja auch nicht so, dass man das alles selber erfinden müsste, wenn man eine professionelle, international erwerbbare Software schreiben wollte. Geldklassen gibt es wie Sand am Meer, teils sogar von Juristen geprüft. Zum Beispiel gibt es da was von Intel für lau.

hustbaer

Sone schrieb:

hustbaer schrieb:

Sone schrieb:

Man sollte auf cent-Basis rechnen (nicht einlesen umbedingt). Macht bei Programmierergehaelten sowieso mehr sinn

Mit Scaling-Factor 100 zu rechnen ist wohl eine ziemlich dumme Idee.

Seid ihr eigentlich alle doof oder so? Sorry, aber das ist verdammt nochmal ein Anfaengerprogramm. Wenn wir eine professionelle International-Erwerbbare Software entwickeln moechten, sagt das doch...

Und in einem Anfaengerprogramm muss man absichtlich doof sein?
Zwei Nullen mehr hinschreiben und int64_t statt int/size_t/anderer-noch-blödsinnigerer-Typ ist jetzt viel Aufwand oder was?

Kurz: bist du wieder mal bekifft? Oder bist du grundsätzlich immer so weit von jeglicher Peilung entfernt?

camper

Irgendein Integertyp dürfte für den OP völlig ausreichen. Und wenn er dann noch mitnimmt, das float&co. immer die falsche Abstraktion für Geld ist, bin ich zufrieden.

Ein Progamm wie

#include <iostream>
using namespace std;

const int MwstSatz = 19; // in Prozent

int main()
{
    double tmp = 0;
    cout << "Geben sie einen Nettopreis ein (Euro): ";
    cin >> tmp;                                      // nicht so toll, weil auch sinnlose Einnahmen wie 1.3453e-1 möglich sind, eine bessere Eingabe erfordert aber etwas mehr Aufwand
    int Netto = tmp * 100 + .5;                      // in Cent
    int Steuer = ( Netto * MwstSatz + 50 ) / 100;    // dito, Runden nicht vergessen
    int Brutto = Netto + Steuer;
    cout << "Der Bruttopreis beträgt " << ( Brutto / 100 ) << " Euro und " << ( Brutto % 100 ) << " Cent.\n";
}

wäre völlig in Ordnung.

hustbaer

camper schrieb:

Irgendein Integertyp dürfte für den OP völlig ausreichen. (...)

Natürlich hast du Recht.

Micht hat nur die absolute Aussage von Hacker genervt - "man sollte auf cent-Basis rechnen" - das ist halt völliger Quatsch.
Man kann in Cent rechnen, und es ist viel besser als mit floats zu rechnen. Man sollte aber mit dem rechnen was man braucht, und das wird (in realen Anwendungen) kaum jemals Cent sein.

Er könnte ja auch sagen "du könntest mit Cent rechnen". Aber Hacker ist halt Hacker, weniger als Superlativ geht anscheinend nicht.

Wurstinator

@ benimus:

Man muss die Variablen nicht am Anfang deklarieren, also ihren Typ aufschreiben. Es wird leichter zu lesen und ist erlaubt dies erst zu tun, wenn du sie auch benutzt:

#include <iostream> 
using namespace std; 

const int MwstSatz = 19; 

int main() 
{ 
    cout << "Geben sie einen (positiven) Nettobetrag in Cent ein: " << endl;
    unsigned int Netto; 
    cin >> Netto; 
    unsigned int Steuer = MwstSatz * Netto / 100; 
    unsigned int Brutto = Netto + Steuer; 
    cout << "Der Bruttopreis betraegt (bei " << MwstSatz << "% Mwst): " << Brutto << endl; 
    cin >> Brutto; 
}

Sone

Wurstinator schrieb:

deklarieren, also ihren Typ aufschreiben

Wo bleibst du Wutz? Seine Behauptung ist falsch

_matze

Sone schrieb:

Seid ihr eigentlich alle doof oder so? Sorry, aber das ist verdammt nochmal ein Anfaengerprogramm.

Sagt der richtige. Wie oft hast du hier absoluten Anfängern, die noch nicht mal ein Hello World hinkriegen, irgendwelchen dicken Template-Kram hingeklatscht (wahrscheinlich nur um anzugeben, wie viel du doch schon kannst), mit dem die offensichtlich überhaupt nichts anfangen können? An die eigenen Nase fassen und so. :p

Tachyon

camper schrieb:

size_t wird in <cstio>, <cstdlib>, <cstring> und <ctime>

In <cstddef> nicht? Dann stimmt mein doofes 14882-2011 pdf irgendwie nicht mehr.