long long int auf 32-bit-Linux-vs-64-bit-Linux-und MPFR

Wie genau funktioniert ein 32-bit-Linux-system Griff long long int im Vergleich zu 64-bit-Linux?

Auf meinem 32 bit-system verwende ich ein C++ - wrapper für die MPFR-Datentyp; dieser wrapper hat ein Konstruktor definiert long int aber nicht long long int. Dennoch, auf die 32-bit-system ist dieser code nur funktioniert:

long long int i=5LL;
mpreal myVar(i);
cout<< "this was constructed with a long long int:" <<myVar <<endl;

Wie ist das möglich? Funktioniert die 32-bit gcc nur irgendwie Stimmen die long long int zu sagen long int für die die mpreal Daten Typ hat haben einen Konstruktor? Wenn der obige code ausgeführt wird, auf 64-bit-Linux-dann wird der compiler mit einem Fehler führt, über den Bau wird mehrdeutig.

Ich weiß, dass einige Leute sagen mir nicht zu verwenden long long int überhaupt auf 64 bit, aber leider bin ich mit einer anderen Bibliothek (odeint), wo dieser eingebaut ist, um den code zu konstruieren, die meine gegeben multiprecision-Datentyp dieser Weise, so glaube ich nicht, ich kann die Dinge ändern.

Ist long long int genau das gleiche wie long int auf 64-bit überhaupt? , Verliere ich Daten wenn ich cast zu long int? wenn ich z.B. meine eigenen Konstruktor wie:

mpreal(const long long int u, mp_prec_t prec, mp_rnd_t mode)
{
    mpfr_init2(mp,prec);
    mpfr_set_si(mp, u, mode);
}
  • Die Konstruktoren sind mehrdeutig?
  • error: call of overloaded 'mpreal(long long int)' is ambiguous. Es ist einfach nicht definiert, auf gebaut aus einem long long int, aber trotzdem auf 32 bit gcc funktioniert einfach irgendwie, aber nicht auf 64-bit-linux. Es sei denn, ich Schreibe meine eigenen Konstruktor für den Bau von long long int in die mpreal.h, wie in meinem OP.
  • Aus wiki: On 32-bit Linux, DOS, and Windows, int and long are 32-bits, while long long is 64-bits. On 64-bit Linux, int is 32-bits, while long and long long are 64-bit. Ich denke, das erklärt vielleicht die situation, mpreal wie es aussieht, überprüft, ob die 32-bit-und falls ja, definiert einen Konstruktor für int64_t (was ist long long int auf 32-system). Aber für 64x system long int und long long int sind die gleiche Sache, so dass im Prinzip niemand sollte die Fütterung in long long int also ich denke, so ein Konstruktor definiert?
  • Wo genau tritt das problem in odeint (Datei-und linenumber)?
  • /odeint/boost/numeric/odeint/stepper/runge_kutta_dopri5.hpp:300: Fehler: Aufruf des überladenen 'mpreal(long long int)' ist mehrdeutig
  • odeint/boost/numeric/odeint/stepper/runge_kutta_dopri5.hpp:301: Fehler: Aufruf des überladenen 'mpreal(long long int)' ist mehrdeutig
  • auch die gleichen Fehler beim 302, 303
  • Siehe unten meine Antwort auch, und Autor von MPFRC++ in holoborodko.com/pavel/mpfr/#comment-7444. Aber wäre es möglich in odeint zu use types with explicit number of bits: int32_t, int64_t from stdint.h. Then move from x32 to x64 would be painless als Autor von MPFRC++ suggeriert? Vielleicht ist dies eine Menge Arbeit..ich weiß nicht.

InformationsquelleAutor fpghost | 2012-12-04
  1. 1

    Ich fragte den Autor, der mpreal.h über das (die vollständige Antwort ist unter http://www.holoborodko.com/pavel/mpfr/#comment-7444), Erstens in Bezug auf den Bau einer neuen Konstruktor für long long int auf einem 64x system:

    >Functions “mpfr_set_ui/si” should be fine.
>Basically constructor for “long long int” should be equivalent to “long int” one.

>GNU GCC system makes porting from x32 to x64 a little bit messy. It automatically  
>upgrades integer types to x64 bits, which could easily break code being ported.

>The best workaround for GCC would be to use types with explicit number of bits:  
>int32_t, int64_t from stdint.h. Then move from x32 to x64 would be painless.

>However neither authors of MPFR nor developers of numeric libraries follow this    
>standard using “long long int”, “long int”, “intmax_t” all of which means different 
>things on x32 and x64 in GCC world.

>There is some macro-logic in mpreal.h which tries to make things smooth:
>(a) for x32 builds we define additional constructors for int64_t (aka “long long int” 
>or “intmax_t” ) 
>(b) for x64 builds we remove constructors for such type since “long int” is already 
>64bit wide.

>Macro MPREAL_HAVE_INT64_SUPPORT plays only “suggestive” role, it is undefined 
>automatically for x64 builds on GCC to avoid clash among integer types.

>The better way would be to detect bit resolution of all integer types at compile time  
>(using macros or meta-magic similar to boost) and add suitable routines to mpreal 
>class. This could easily grow to be more complex than mpreal itself :) .

>Maybe I will come up with better solution in future versions, any suggestions are 
>welcome.

    Also denke ich Bau in meinen Konstruktor von der OP zu beheben Dinge arbeiten Sie OK, auf einem x64-system, müssen aber wieder entfernt werden, wenn Sie gehen zurück zum x32-system, sonst wird es eine Kollision verursachen. Der Grund dafür ist, dass MPREAL_HAVE_INT64_SUPPORT makro wird definiert, auf 32x und Konstruktoren für int64_t (aka long long int auf 32x) bekommen definiert, so dass das hinzufügen eines weiteren solchen Konstruktor wird eine Kollision verursachen; dies ist auch der Grund, warum mein code funktionierte einfach out of the box auf einem 32 system. Auf einem 64x system MPREAL_HAVE_INT64_SUPPORT makro nicht definiert ist und solche Konstruktoren werden entfernt, da long int ist schon 64bit breit, so gab es keine Notwendigkeit für den Autor, um eine long long int Konstruktor.

    InformationsquelleAutor fpghost
  2. 0

    • Für die Größen der verschiedenen Arten, überprüfen Sie die C-standard, long long zu vertreten hat, die mit mindestens 64 bits.

    • Um zu sehen, was der compiler wirklich macht mit dem code, die Sie verwenden können, z.B. objdump -D auf die binäre (oder der mittleren-Objekt-Datei).

    • Auf 32-bit-arch Sie wird verlieren Daten, wenn Sie Stimmen aus long long zu long.

    • Soweit ich es verstehe, sind die compiler haben eventuell Probleme zu entscheiden, welcher Konstruktor zu verwenden ist (im Grunde nicht entscheiden kann, ob ctor(int) oder ctor(long int)).

    EDIT:

    #include <stdint.h>
...
uint64_t x = 5;
mpreal myVar(i);

    arbeitet als c-tor(uint64_t) definiert ist (oder besser gesagt eine eindeutige übereinstimmung gefunden werden kann) - denn auf 64bit arch die (unsigned) long int entspricht uint64_t (für glibc es tatsächlich so definiert). Der Fehler ergibt sich aus den Regeln-compiler verwendet, wenn Umgang mit überladenen Funktionen - für weitere Informationen siehe die C++11-standard/Entwurf.

    Generell, wenn Sie wollen, dass Ihr code portabel, sollten Sie mit dem Typen in inttypes.h oder stdint.h - die C99 - d.h. uintXX_t und intXX_t. Diese Typen sind garantiert, um die genaue Breite, siehe den wiki-link oben für mehr Infos.

    • Ich denke, auf einem 32x system MPREAL_HAVE_INT64_SUPPORT wird definiert (bereits als Teil der mpreal.h) und in diesem Fall ein Konstruktor vorhanden ist, wird die 64-bit -long long int. Auf die 64-bit-system würde man normalerweise nicht verwenden long long int, sondern nur long int wie beide sind 64 bit sowieso, also in diesem Fall mpreal.h hat nicht explizit definiert, so wird ein Konstruktor. Ich habe meine eigene, wie gezeigt, in den OP, das ist im wesentlichen der gleiche wie der long int Konstruktor, und die Dinge zusammenzustellen. Auf 64x ich glaube nicht, dass diese Stimmen aus long long int zu long int Daten verliert.
    • Rechts, auf 64bit lli -> li nicht die Daten verloren gehen (abhängig von der tatsächlichen Arten breiten, aber ich glaube li ist in der Regel ein quad-Wort von 64-bit-Architekturen).
    InformationsquelleAutor peterph
Schreibe einen Kommentar