Überlanger Array



  • Hallo zusammen,

    wir brauchen in einer Anwendung float Arrays mit einer Länge die die 2 oder 4 Milliarden Grenze sprengen. Kiste hat 96GB RAM. Sollte also nicht das Problem sein. Problem ist nun, dass ich keine Längen angeben kann die größer sind als int max oder so.

    Wie kann ich das umgehen? App ist 64Bit


  • Mod

    Dann machst du wohl was falsch. vector nimmt als Argument eine size_t. Falls dieser in einer 64 Bit Implementierung nur 32 Bit hätte, wäre das ein (krasser) Fehler in der Implementierung. Das wäre doch sehr, sehr unwahrscheinlich.



  • Auf einer Kiste mit viel RAM kann ich im 64-Btit-Modus solche großen Vektoren erzeugen. Du nicht? Machst Du vielleicht etwas falsch?



  • Er spricht von Arrays und nicht von vector. Solche Trollantworten immer.


  • Mod

    nwp3 schrieb:

    Er spricht von Arrays und nicht von vector. Solche Trollantworten immer.

    Leute, die zwischen den Zeilen lesen können, hätten erkannt, das krümelkacker und ich eine unterschwellige Botschaft in unsere Antworten eingebaut haben.



  • nwp3 schrieb:

    Er spricht von Arrays und nicht von vector. Solche Trollantworten immer.

    Er wäre schon reichlich doof, wenn er ein echtes, auf dem Stack liegendes Array nehmen würde.

    Und eines mit new zu allozieren, dessen Länge mit einer Konstante vom Typ int festgelegt wird (wobei int auf der Implementierung wohl 32 Bit groß ist), wäre auch bescheuert.



  • Und eines mit new zu allozieren, dessen Länge mit einer Konstante vom Typ int festgelegt wird

    new fordert keine Konstanten für Array-Größen, und ist auch nicht auf int beschränkt.


  • Mod

    Oberon_0 schrieb:

    Und eines mit new zu allozieren, dessen Länge mit einer Konstante vom Typ int festgelegt wird

    new fordert keine Konstanten für Array-Größen, und ist auch nicht auf int beschränkt.

    Eben! Das heißt, der TE hat irgendwo etwas falsch gemacht, wenn er auf Integergrößenbeschränkungen trifft. Wahrscheinlich mindestens int size; . Höchstwahrscheinlich sogar noch float array[size]; .



  • Oberon_0 schrieb:

    Und eines mit new zu allozieren, dessen Länge mit einer Konstante vom Typ int festgelegt wird

    new fordert keine Konstanten für Array-Größen, und ist auch nicht auf int beschränkt.

    Habe ich das gesagt? Ich habe doch explizit auf int als Typ des Literals o.ä. hingewiesen! (Zu denken, new erfordert Konstanten...)



  • Sone schrieb:

    Habe ich das gesagt? Ich habe doch explizit auf int als Typ des Literals o.ä. hingewiesen! (Zu denken, new erfordert Konstanten...)

    Wenn das Literal nicht mehr in einen int hineinpasst, wird es automatisch long long.



  • nwp3 schrieb:

    Er spricht von Arrays und nicht von vector.

    Im Kontext von so riesigen float-Anhäufungen ist das für mich gleichbedeutend. In jedem Fall ist da die dynamische Speicherverwaltung (direkt oder indirekt) zu verwenden. Ein std::vector kapselt ja nur ein solches Array.

    denker schrieb:

    Sone schrieb:

    Habe ich das gesagt? Ich habe doch explizit auf int als Typ des Literals o.ä. hingewiesen! (Zu denken, new erfordert Konstanten...)

    Wenn das Literal nicht mehr in einen int hineinpasst, wird es automatisch long long.

    Ab C++11 ja. Sonst sollte man wahrscheinlich den LL-Suffix nehmen. Ich meine mich zu erinnern, dass der GCC sonst nur bis (unsigned) long geht und danach eine Warnung (bei -Wall) ausgibt, wenn der Wert betragsmäßig zu hoch ist, um in (unsigned) long reinzupassen. Der LL-Suffix hatte da aber die Compilererweiterung "long long" getriggert. 🙂



  • denker schrieb:

    Sone schrieb:

    Habe ich das gesagt? Ich habe doch explizit auf int als Typ des Literals o.ä. hingewiesen! (Zu denken, new erfordert Konstanten...)

    Wenn das Literal nicht mehr in einen int hineinpasst, wird es automatisch long long.

    Hab' ich völlig vergessen, stimmt.

    The type of an integer literal is the first of the corresponding list in Table 6 in which its value can be represented.

    Allerdings hast du doch Unrecht. Es wird zuerst zu einem long , oder nicht?


Log in to reply