 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Markus Bauer
Guest
|
 Posted: Fri Apr 08, 2005 10:00 am Post subject: Tabellenfeld? |
 |
|
Hallo!
In C++ moechte ich eine Tabelle implementieren (bzw. habe ich schon).
Diese besteht aus einem Array Felder.
Diese ist wiederum definiert:
class Field
{
private:
// Kein Kopieren erlaubt
Field(Field&);
protected:
DWORD m_dwType;
union
{
BOOL m_bVal;
CString *m_strVal;
long m_lVal;
double m_dVal;
};
public:
Field();
virtual ~Field();
enum { FIELD_NULL = 0, FIELD_BOOL = 1, FIELD_LONG = 4, FIELD_STRING
= 8, FIELD_DOUBLE = 9 };
void SetVal(BOOL);
void SetVal(CString&);
void SetVal(long);
void SetVal(double);
};
Die Klasse kann also verschiedene Datentypen halten, die sind per
m_dwType angegeben und die eigentlichen Daten haelt eine union.
Das Setzen der Variablen ist jetzt ganz einfach: Ueberladung.
Aber wie sieht es aus, wenn ich die Daten abfragen will? Radikale void*
Pointer fuer GetValue() & Co scheinen mir sehr kriminell, und fuer jeden
einzelnen Datentyp eine eigene Funktion ist auch nicht wirklich elegant.
Zuerst habe ich einfach die union und m_dwType public gehabt, da hatte
ich das Problem nicht, aber jetzt ueberarbeite ich das ganze und das
passt natuerlich nicht mehr wirklich (also public ist IMHO ebenso eine
schlechte Idee)
Wie loest man das am besten in C++?
Danke
Markus
PS: Die Variante mit den verschiedenen Zugriffsfunktionen waere ja gar
nicht soo schlecht, wenn ich nicht bei jeder Abfrage extra zuerst den Typ
abfragen muesste und dann in einer switch-Abfrage die korrekten
Daten...Oder ist es vielleicht klug, eine "Transferstruktur", die alle
Typen beinhaltet, zu benutzen?
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
 |
Torsten Robitzki
Guest
|
| Posted: Fri Apr 08, 2005 10:56 am Post subject: Re: Tabellenfeld? |
|
|
Markus Bauer wrote:
| Quote: | Hallo!
In C++ moechte ich eine Tabelle implementieren (bzw. habe ich schon).
Diese besteht aus einem Array Felder.
Diese ist wiederum definiert:
|
Darf ich das Kommentieren? ;-)
| Quote: | class Field
{
private:
// Kein Kopieren erlaubt
Field(Field&);
|
Warum nicht, das würde die Klasse als "generischen Wertebehälter"
nützlich machen. Zuweisung und default Konstruktion hast Du erlaubt.
Warum 'protected'?
Warum nicht vom Unten stehenden, unbenannten Aufzählungstypen?
| Quote: | union
{
BOOL m_bVal;
CString *m_strVal;
long m_lVal;
double m_dVal;
};
public:
Field();
virtual ~Field();
|
Soll
| Quote: |
enum { FIELD_NULL = 0, FIELD_BOOL = 1, FIELD_LONG = 4, FIELD_STRING
= 8, FIELD_DOUBLE = 9 };
void SetVal(BOOL);
void SetVal(CString&);
void SetVal(long);
void SetVal(double);
};
Die Klasse kann also verschiedene Datentypen halten, die sind per
m_dwType angegeben und die eigentlichen Daten haelt eine union.
Das Setzen der Variablen ist jetzt ganz einfach: Ueberladung.
|
Ja.
| Quote: | Aber wie sieht es aus, wenn ich die Daten abfragen will? Radikale void*
Pointer fuer GetValue() & Co scheinen mir sehr kriminell, und fuer jeden
einzelnen Datentyp eine eigene Funktion ist auch nicht wirklich elegant.
|
Ob Du nun eine Interface hast, das dich den gespeicherten Typen erfragen
läßt und für jeden Typen ein Interface, mit dem Du dann sicher (und ggf.
mit Typprüfung) auf den Wert zugreifen kannst, oder ob Du nun einen
void* anhand eines Aufzählungstypens herum castest, es läuft prinzipiell
immer auf das gleiche (mit mehr oder weniger Sicherheit und Komfort) hinaus.
| Quote: | Zuerst habe ich einfach die union und m_dwType public gehabt, da hatte
ich das Problem nicht, aber jetzt ueberarbeite ich das ganze und das
passt natuerlich nicht mehr wirklich (also public ist IMHO ebenso eine
schlechte Idee)
Wie loest man das am besten in C++?
|
In dem man wo immer möglich solche any-Typen erst gar nicht verwendest  .
| Quote: | Danke
Markus
PS: Die Variante mit den verschiedenen Zugriffsfunktionen waere ja gar
nicht soo schlecht, wenn ich nicht bei jeder Abfrage extra zuerst den Typ
abfragen muesste und dann in einer switch-Abfrage die korrekten
Daten...Oder ist es vielleicht klug, eine "Transferstruktur", die alle
Typen beinhaltet, zu benutzen?
|
Beim Zugriff auf einzelne Felder hast Du doch eine bestimmte Erwartung
an den Inhalt (und den Typen) des Feldes. Entweder Du sagst, da muß
jetzt ein string stehen und Du fragst den Wert über die Funktion
asString() ab (wenn der Typ dann nicht String ist, hast Du einen Fehler
zur Laufzeit erkannt) oder Du musst sowieso mit allen Typen umgehen
können. Wahrscheinlich ist aber, das die Funktion, die mit allen Typen
umgehen können muß auch mit einer textuellen Repräsentation leben kann
und dann könnte Die eine Funktion a la asText() helfen.
mfg Torsten
P.S. guck dir mal http://www.boost.org/doc/html/any.html an.
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Markus Schaaf
Guest
|
| Posted: Fri Apr 08, 2005 10:58 am Post subject: Re: Tabellenfeld? |
|
|
"Markus Bauer" <mc_mc_mc (AT) lycos (DOT) de> schrieb:
| Quote: | Die Klasse kann also verschiedene Datentypen halten, die sind per
m_dwType angegeben und die eigentlichen Daten haelt eine union.
|
Schau Dir mal bitte http://www.boost.org/doc/html/variant.html an!
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Stefan Reuther
Guest
|
| Posted: Fri Apr 08, 2005 6:24 pm Post subject: Re: Tabellenfeld? |
|
|
Hallo,
Markus Bauer wrote:
| Quote: | class Field
{
private:
// Kein Kopieren erlaubt
Field(Field&);
|
Das lautet im Originalprogramm hoffentlich 'Field(const Field&)'? Aber
ich würde Kopieren dennoch erlauben.
| Quote: | void SetVal(BOOL);
void SetVal(CString&);
void SetVal(long);
void SetVal(double);
};
Die Klasse kann also verschiedene Datentypen halten, die sind per
m_dwType angegeben und die eigentlichen Daten haelt eine union.
Das Setzen der Variablen ist jetzt ganz einfach: Ueberladung.
|
IMHO eine schlechte Idee. Mit dem obenstehenden ist 'SetVal(1)' z.B.
mehrdeutig, weil die long- und die double-Signatur passt. Und vermutlich
auch die BOOL-Signatur (warum eigentlich nicht 'bool'?).
Außerdem soll das sicherlich 'const CString&' sein, damit man auch Dinge
wie 'SetVal("Name: " + irgendwas.GetName())' schreiben kann. Aber auch
hier schießt dir die Überladung ins Bein. 'SetVal("foo")' ruft dann
nämlich die bool-Signatur auf.
Alles in allem halte ich es für besser, explizit Namen zu vergeben. Also
'SetIntVal(long)', 'SetStringVal(std::string)', 'SetFloatVal(double)',
'SetBoolVal(bool)'.
| Quote: | Aber wie sieht es aus, wenn ich die Daten abfragen will? Radikale void*
Pointer fuer GetValue() & Co scheinen mir sehr kriminell, und fuer jeden
einzelnen Datentyp eine eigene Funktion ist auch nicht wirklich elegant.
|
Für das Abfragen würde ich ebenfalls eigene Funktionen verwenden. Warum
soll das nicht elegant sein?
| Quote: | PS: Die Variante mit den verschiedenen Zugriffsfunktionen waere ja gar
nicht soo schlecht, wenn ich nicht bei jeder Abfrage extra zuerst den Typ
abfragen muesste und dann in einer switch-Abfrage die korrekten
Daten...
|
Wie sonst? Entweder du hast eine Operation, die den exakten, statisch
getypten Wert braucht. Dann musst du natürlich vorher prüfen, ob du auch
einen Wert dieses Typs hast. Oder du hast Operationen, die "ungetypt"
ablaufen können (z.B. der Ausgabe eines Field-Objektes ist der Typ egal,
oder evtl. ein operator!=, der auch auf beliebige Field-Objekte
angewendet werden kann), dann sollte die Klasse Field die zur Verfügung
stellen.
Eine Möglichkeit wäre noch, Typprüfung und Extraktion in einem Aufwasch
zu erledigen, analog dynamic_cast:
long*
Field::asLong()
{
if (m_dwType == FIELD_LONG)
return &m_LVal;
else
return 0;
}
| Quote: | Oder ist es vielleicht klug, eine "Transferstruktur", die alle
Typen beinhaltet, zu benutzen?
|
Die Klasse 'Field' ist doch bereits genau diese Transferstruktur.
Stefan
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Markus Schaaf
Guest
|
| Posted: Fri Apr 08, 2005 8:35 pm Post subject: Re: Tabellenfeld? |
|
|
"Stefan Reuther" <stefan.news (AT) arcor (DOT) de> schrieb:
| Quote: | private:
// Kein Kopieren erlaubt
Field(Field&);
Das lautet im Originalprogramm hoffentlich 'Field(const Field&)'?
|
Warum das denn? Ich schreibe das auch immer so, weshalb mehr tippen?
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Torsten Robitzki
Guest
|
| Posted: Fri Apr 08, 2005 10:15 pm Post subject: Re: Tabellenfeld? |
|
|
Markus Schaaf wrote:
| Quote: | "Stefan Reuther" <stefan.news (AT) arcor (DOT) de> schrieb:
private:
// Kein Kopieren erlaubt
Field(Field&);
Das lautet im Originalprogramm hoffentlich 'Field(const Field&)'?
Warum das denn? Ich schreibe das auch immer so, weshalb mehr tippen?
|
Damit man auch Kopien von Konstanten machen kann? Bzw. von Ausdrücken,
die sich nur an konstante Referenzen binden lassen.
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Markus Schaaf
Guest
|
| Posted: Fri Apr 08, 2005 10:40 pm Post subject: Re: Tabellenfeld? |
|
|
"Torsten Robitzki" <MyFirstname (AT) Robitzki (DOT) de> schrieb:
| Quote: | private:
// Kein Kopieren erlaubt
Field(Field&);
Das lautet im Originalprogramm hoffentlich 'Field(const Field&)'?
Warum das denn? Ich schreibe das auch immer so, weshalb mehr tippen?
Damit man auch Kopien von Konstanten machen kann?
|
Bitte lesen: Es geht darum, _keine_ Kopien zu machen.
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Torsten Robitzki
Guest
|
| Posted: Fri Apr 08, 2005 10:50 pm Post subject: Re: Tabellenfeld? |
|
|
Markus Schaaf wrote:
| Quote: | "Torsten Robitzki" <MyFirstname (AT) Robitzki (DOT) de> schrieb:
private:
// Kein Kopieren erlaubt
Field(Field&);
Das lautet im Originalprogramm hoffentlich 'Field(const Field&)'?
Warum das denn? Ich schreibe das auch immer so, weshalb mehr tippen?
Damit man auch Kopien von Konstanten machen kann?
Bitte lesen: Es geht darum, _keine_ Kopien zu machen.
|
Ah! Ok, es ging darum, _keine_ Kopie zu machen :-)
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Stefan Reuther
Guest
|
| Posted: Sat Apr 09, 2005 10:36 am Post subject: Re: Tabellenfeld? |
|
|
Markus Schaaf wrote:
| Quote: | "Stefan Reuther" <stefan.news (AT) arcor (DOT) de> schrieb:
private:
// Kein Kopieren erlaubt
Field(Field&);
Das lautet im Originalprogramm hoffentlich 'Field(const Field&)'?
Warum das denn? Ich schreibe das auch immer so, weshalb mehr tippen?
|
Hmmm. Ich hatte den Eindruck, dass der Compiler auf die Idee kommen
könnte, einen 'Field(const Field&)' selber zu synthetisieren. Das ist
aber nicht der Fall. Insofern ziehe ich diesen Einwand zurück.
Wenn natürlich 'Field' kopierbar wird, was ich für sinnvoll halte, dann
sollte der Kopierkonstruktor wieder einen const-Parameter bekommen.
Stefan
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Rolf Magnus
Guest
|
| Posted: Sat Apr 09, 2005 10:24 pm Post subject: Re: Tabellenfeld? |
|
|
Stefan Reuther wrote:
| Quote: | Markus Schaaf wrote:
"Stefan Reuther" <stefan.news (AT) arcor (DOT) de> schrieb:
private:
// Kein Kopieren erlaubt
Field(Field&);
Das lautet im Originalprogramm hoffentlich 'Field(const Field&)'?
Warum das denn? Ich schreibe das auch immer so, weshalb mehr tippen?
Hmmm. Ich hatte den Eindruck, dass der Compiler auf die Idee kommen
könnte, einen 'Field(const Field&)' selber zu synthetisieren.
|
Nein, denn mit oder ohne const ist das ein Kopierkonstruktor, und den
erzeugt der Compiler nur dann, wenn man nicht selbst einen hinschreibt.
| Quote: | Das ist aber nicht der Fall. Insofern ziehe ich diesen Einwand zurück.
|
Schön ;-)
| Quote: | Wenn natürlich 'Field' kopierbar wird, was ich für sinnvoll halte, dann
sollte der Kopierkonstruktor wieder einen const-Parameter bekommen.
|
Im Normalfall ja.
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Thorsten Nitz
Guest
|
| Posted: Sun Apr 10, 2005 6:22 pm Post subject: Re: Tabellenfeld? |
|
|
Markus Bauer schrieb:
| Quote: | In C++ moechte ich eine Tabelle implementieren (bzw. habe ich schon).
Diese besteht aus einem Array Felder.
Diese ist wiederum definiert:
class Field
{
private:
// Kein Kopieren erlaubt
Field(Field&);
protected:
DWORD m_dwType;
union
{
BOOL m_bVal;
CString *m_strVal;
|
Warum hier ein Zeiger und nicht einfach "CString m_strVal wie bei den
anderen Komponenten auch? Die Objekte der Klassen std::string (aus
Standard-C++) und CString aus der MFC sind nicht größer als ein Zeiger.
Überzeuge Dich mit std::cout << sizeof CString; selbst.
Man sollte sich überlegen, ob man eine eigene long-Variante einfügt, da
alle long-Werte sich auch verlustlos in der ebenfalls vorhandenen
double-Variante speichern lassen.
| Quote: | double m_dVal;
};
public:
Field();
virtual ~Field();
enum { FIELD_NULL = 0, FIELD_BOOL = 1, FIELD_LONG = 4, FIELD_STRING
= 8, FIELD_DOUBLE = 9 };
void SetVal(BOOL);
void SetVal(CString&);
void SetVal(long);
void SetVal(double);
};
Die Klasse kann also verschiedene Datentypen halten, die sind per
m_dwType angegeben und die eigentlichen Daten haelt eine union.
Das Setzen der Variablen ist jetzt ganz einfach: Ueberladung.
Aber wie sieht es aus, wenn ich die Daten abfragen will? Radikale void*
Pointer fuer GetValue() & Co scheinen mir sehr kriminell,
|
void*-Pointer sind in der Tat kriminell. Wenn man die in Verbindung mit
Vererbung benutzt, bekommt man sehr leicht kaum zu findende Fehler. Dann
lieber alles, was durch das "void*"-Interface soll, von einer
gemeinsamen Basisklasse B erben lassen und einen B*-Zeiger benutzen.
| Quote: | und fuer jeden
einzelnen Datentyp eine eigene Funktion ist auch nicht wirklich elegant.
PS: Die Variante mit den verschiedenen Zugriffsfunktionen waere ja gar
nicht soo schlecht, wenn ich nicht bei jeder Abfrage extra zuerst den Typ
abfragen muesste und dann in einer switch-Abfrage die korrekten
Daten...Oder ist es vielleicht klug, eine "Transferstruktur", die alle
Typen beinhaltet, zu benutzen?
|
Tja, da Du die Typinformation selbst verwalten möchtest, kommst Du um
den switch nicht herum.
Typische Varianten:
a) Richtige Variante anhand Paramnetertyp
aa) Aufrufer muss mit passendem Typ zugreifen
void GetVal(long& result) {
assert (m_dwType == FIELD_LONG);
result = m_lVal;
);
usw.
ab) Aufrufer ruft mit Wunschtyp, Klasse Field konvertiert ggfls.
void GetVal(long& result) {
switch (m_dwType) {
case FIELD_LONG:
result = m_lVal;
break;
case FIELD_DOUBLE:
result = static_cast
break;
case FIELD_CSTRING:
result = sscanf("%d", *m_strVal); // ungetestet, ich weiß jetzt
// grad nicht genau, wieviel Strenchen da hin müssen.
// Ist aber eh plattformspezifisch, also bitte selbst
// in die Hilfe kucken.
break
// usw.
}
);
b) Wunsch-ErgebnisTyp im Methodenname:
long GetAsLong() {
switch (m_dwType) {
case FIELD_LONG:
return m_lVal;
break;
case FIELD_DOUBLE:
return static_cast<long>(m_dVal);
break;
// usw., siehe ab)
}
c) Daten-Typinformation in Klassenhierarchie verpacken:
struct Field {
virtual void set(long x) = 0;
virtual void set(double x) = 0;
virtual long getAsLong() = 0;
virtual double getAsDouble() = 0;
};
class LongField: public Field {
long data;
public:
virtual void set(long x) {data = x;};
virtual void set(double x) {data = static_cast<long>(x);};
virtual long getAsLong() = {return data;};
virtual double getAsDouble() {return static_cast<double>(data);};
};
class DoubleField: public Field {
double data;
public:
virtual void set(long x) {data = static_cast<double>(x);};
virtual void set(double x) {data = x;};
virtual long getAsLong() = {return static_cast<double>(data);};
virtual double getAsDouble() {return data;};
};
D.h., was in b) die einzelnen Fälle eines switch waren, wird hier auf
die Methoden verschiedener Klassen verteilt. Das bietet sich
insbesondere an, wenn der Typ (bei Dir der Wert von m_dwType) nur einmal
beim Anlegen des Fields bestimmt wird und sich dann nicht mehr ändert.
Man spricht das Objekt dann immer als Field an. Zur Anzeige nimmt man
die asString-Zugriffsfunktionen, in anderen Kontexten entsprchend die
asWunschtyp-Funktionen. Falls man ausnahmsweise doch den konkreten Typ
braucht, gibt es den dynamic_cast:
Field* pf = ...;
if ( dynamic_cast<LongField>(pf) != 0)
// pf zeigt auf ein LongField
Welche dieser Varianten für Dich am besten passt, hängt davon ab, was Du
genau machen willst. Variante aa) setzt z.B. voraus, dass man immer mit
dem passenden Typ zugreift. Variante c) kann den enthaltenen Wert in
jeder beliebigen Repräsentation liefern. Meist findet man diese
Flexibilität elegant, aber vielleicht hast Du Gründe, das zu verbieten.
Tschö, wa!
Thorsten
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Tibor Pausz
Guest
|
| Posted: Mon Apr 11, 2005 5:38 am Post subject: Re: Tabellenfeld? |
|
|
Markus Bauer <mc_mc_mc (AT) lycos (DOT) de> wrote:
| Quote: | class Field
....
};
|
Meiner Meinung nach ist das schlichtweg ein kompletter Designfehler. In
C++ spricht sehr sehr selten etwas für unions, eben nur dann wenn man
unbedingt mit C kompatibel sein muß. Sonst läßt man lieber die Finger
davon und benutzt Vererbung, dafür gibt es dieses Sprachmittel.
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Torsten Robitzki
Guest
|
| Posted: Tue Apr 12, 2005 9:12 pm Post subject: Re: Tabellenfeld? |
|
|
Thorsten Nitz wrote:
| Quote: | Markus Bauer schrieb:
In C++ moechte ich eine Tabelle implementieren (bzw. habe ich schon).
Diese besteht aus einem Array Felder.
Diese ist wiederum definiert:
class Field
{
private:
// Kein Kopieren erlaubt
Field(Field&);
protected:
DWORD m_dwType;
union
{
BOOL m_bVal;
CString *m_strVal;
Warum hier ein Zeiger und nicht einfach "CString m_strVal wie bei den
anderen Komponenten auch? Die Objekte der Klassen std::string (aus
Standard-C++) und CString aus der MFC sind nicht größer als ein Zeiger.
Überzeuge Dich mit std::cout << sizeof CString; selbst.
|
Ich glaube, das in unions nur PODS gespeichert werden können.
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
M G Berberich
Guest
|
| Posted: Sun Apr 24, 2005 4:43 pm Post subject: Re: Tabellenfeld? |
|
|
On Sun, 10 Apr 2005 20:22:30 +0200, Thorsten Nitz <T.Nitz (AT) epost (DOT) de> wrote:
| Quote: | Man sollte sich überlegen, ob man eine eigene long-Variante einfügt, da
alle long-Werte sich auch verlustlos in der ebenfalls vorhandenen
double-Variante speichern lassen.
|
Das funktioniert nur wenn die Mantisse des double mindestens soviel
Bit hat wie das long. Ist das irgendwo garantiert?
MfG
bmg
--
"Des is völlig wurscht, was heut beschlos- | M G Berberich
sen wird: I bin sowieso dagegn!" | [email]berberic (AT) fmi (DOT) uni-passau.de[/email]
(SPD-Stadtrat Kurt Schindler; Regensburg) | www.fmi.uni-passau.de/~berberic
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Rolf Magnus
Guest
|
| Posted: Mon Apr 25, 2005 10:33 am Post subject: Re: Tabellenfeld? |
|
|
M G Berberich wrote:
| Quote: | On Sun, 10 Apr 2005 20:22:30 +0200, Thorsten Nitz <T.Nitz (AT) epost (DOT) de> wrote:
Man sollte sich überlegen, ob man eine eigene long-Variante einfügt, da
alle long-Werte sich auch verlustlos in der ebenfalls vorhandenen
double-Variante speichern lassen.
Das funktioniert nur wenn die Mantisse des double mindestens soviel
Bit hat wie das long. Ist das irgendwo garantiert?
|
Nein.
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
