T* blub();

Kann ich irgendwie herausfinden, welche Größe das zurückgebene Array hat? Irgendwie muss ich Größe ja bekannt sein, denn beim Aufruf von delete[] weiß das Programm bzw. das Betriebssystem ja auch, wie viel es freigeben muss.
Momentan nutze ich folgendes Konstrukt, wobei int die Größe des Arrays ist:

std::pair<T*, int> blub();

Besonders schön finde ich das jetzt nicht, von daher wollte ich fragen, ob man das normalerweise anders macht bzw. was die beste Möglichkeit ist.

Die beste Möglichkeit ist IMHO std::vector mit RVO/NRVO, aber das kommt auf den Anwendungszweck an.

Da wären noch einige Fragen:
-Wofür?
-Muss die Größe dynamisch sein?

Zu delete[]: Das ist dem Compiler überlassen, wie er die Größeninformation bekommt, da kann man meines Wissens nicht eingreifen. Für malloc()/free() gilt das Gleiche.

Rückgabe ist allerdings ein potentielles Problem, da eine teure Kopie entstehen könnte. Mit (N)RVO oder spätestens C++11-Move-Semantik ist das Problem aber vom Tisch. Und vorher kann man, um sicher zu gehen, z.B. Output-Parameter mit Referenzen verwenden.

@Wofür?:
Ich berechne z.B. die SVD einer Matrix A und gebe (u.a.) die Singulärwerte als Array zurück. Da der Rang von A nicht maximal sein muss, ist die Größe des Arrays beim Aufruf der Funktion unbekannt. Nachträglich muss ich keine Werte mehr manipulieren oder hinzufügen oder Ähnliches, sondern eigentlich nur lesen.

@wxSkip:
Mir fällt noch eine Möglichkeit ein:
ein struct definieren, dass T* und int enthält.

std::vector kommt mir für meinen Zweck etwas aufgebläht vor. Gibt es bei vector eine Methode, die den Zeiger auf das erste Element zurückgibt. Ich sehe nämlich gerade keine. Aber das wäre nützlich, da ich bereits Methoden geschrieben hab, die T* und die Größe als Parameter übergeben bekommen. Von daher vermute ich, dass std::array für mich geeigneter ist.

Erstmal danke für die schnellen Antworten.

@Wofür?:
Ich berechne z.B. die SVD einer Matrix A und gebe (u.a.) die Singulärwerte als Array zurück. Da der Rang von A nicht maximal sein muss, ist die Größe des Arrays beim Aufruf der Funktion unbekannt. Nachträglich muss ich keine Werte mehr manipulieren oder hinzufügen oder Ähnliches, sondern eigentlich nur lesen.

@wxSkip:
Mir fällt noch eine Möglichkeit ein:
ein struct definieren, dass T* und int enthält.

std::vector kommt mir für meinen Zweck etwas aufgebläht vor. Gibt es bei vector eine Methode, die den Zeiger auf das erste Element zurückgibt. Ich sehe nämlich gerade keine. Aber das wäre nützlich, da ich bereits Methoden geschrieben hab, die T* und die Größe als Parameter übergeben bekommen. Von daher vermute ich, dass std::array für mich geeigneter ist.

Deine Möglichkeit ist eine umständliche Variante deines std::pair<>-Vorschlags. Für den Pointer brauchst du nur &vec[0] zu schreiben - daher ist vector auch perfekt für dich geeignet .

Gibt es bei vector eine Methode, die den Zeiger auf das erste Element zurückgibt.

vector<T>::iterator i = vec.begin(); // Zeiger aufs 1. Element.

vector<T>::iterator i = vec.begin(); // Zeiger aufs 1. Element.

Nein, Iterator aufs erste Element. Er schreibt doch schon explizit, dass er Funktionen hat, die Pointer plus Größe des Arrays entgegennehmen.

vector<T> (data, &data[size]);

schreiben oder kann das zu Problemen führen, da data[size] ja eigentlich nicht existiert? Aber durch & wird darauf ja gar nicht zugegriffen oder?

vector<T> (data, data + size);

...weil zuerst data[size] ausgewertet wird...

Hmmmm...

Caligulaminus' Bauch sagt: Da wird nichts ausgewertet, sondern schlicht und ergreifend eine Adresse errechnet.

Ich finde

vector<T> (data, data + size);

auch schöner.

Ob auf etwas "zugegriffen" wird, oder nicht, ist vollkommen egal, da der Standard sagt, dass man keine ungültigen Adressen erzeugen oder rumreichen darf.
(Ausnahme: man kann und darf undefinierte Adressen erzeugen, indem man einen Zeiger erzeugt ohne ihn zu initialisieren. Man darf diesen Zeiger dann aber nur überschreiben, und auch nicht z.B. rumreichen oder kopieren.)

D.h. &data[size] wäre grundsätzlich problematisch.

Wäre, weil es genau für das "one past last element" von Arrays eine grosse dicke Ausnahme im Standard gibt: man darf die Adresse des "one past last element" erzeugen und auch rumreichen.
Diese Ausnahme existiert, um eine gängige Praxis zu legalisieren: das Arbeiten mit Zeigerpaaren, von denen der "end" zeiger eben genau eins hinter das letzte Element zeigt.

Dadurch ist &data[size] also doch wieder legal.

( &data[size + 1] bleibt aber dennoch falsch, ganz egal ob man nun auf das Element zugreift oder nicht. Einzige Ausnahme wäre innerhalb von sizeof()/typeid() oder ähnlichen Konstrukten, wo so-gut-wie alles erlaubt ist.)

Dadurch ist &data[size] also doch wieder legal.

Hast du einen Beleg dafür? Ich weiß, dass man data + size genau wegen dieser Ausnahme berechnen darf, aber ich sehe noch nicht, woraus dann die Legalität von &data[size] folgt.

Meine Meinung (ohne Recherche): data[size] ist nicht definiert, weshalb ein Zeiger darauf ebenfalls nicht definiert ist.

[..]der Standard sagt, dass man keine ungültigen Adressen erzeugen oder rumreichen darf.[..]
[..]grosse dicke Ausnahme[..]
[..]man darf die Adresse des "one past last element" erzeugen und auch rumreichen.[..]

Hmmm... elegant is dann aber doch anders. Naja - gewachsene Systeme halt...

Legal oder illegal, es wird nichts ausgewertet, sondern lediglich eine(pseudo-)Adresse errechnet.

Legal oder illegal, es wird nichts ausgewertet, sondern lediglich eine(pseudo-)Adresse errechnet.

Wenn der Code illegal ist, sprich UB hat, kann er auch die Adresse von Barack Obama berechnen und daraufhin Shakespeare zitieren. Und das alles sogar, bevor die pöse Zeile erreicht wird.

Aber...

data[size] wird erstmal zu *(data + size) .
D.h. als erstes kommt mal der Array-to-Pointer decay von "data", und danach die Addition. Beides noch unproblematisch. Danach kommt der böse *.

Nur das Ergebnis davon ist erstmal noch ne Lvalue (vom Typ T& wenn ich nicht ganz daneben liege). In &data[size] holen wir uns dann die Adresse von dieser Lvalue.

Die Frage ist also: dürfen wir auch Lvalue-Referenzen auf "one past (the) last element" erzeugen? Ich sehe keinen Grund der dagegen spricht, also behaupte ich einfach mal: ja, dürfen wird

EDIT:
Hier auch zum gleichen Thema:
http://stackoverflow.com/questions/988158/take-the-address-of-a-one-past-the-end-array-element-via-subscript-legal-by-the
Siehe Antwort von Adam Rosenfield, Zitat aus §6.5.3.2, paragraph 3

The unary & operator yields the address of its operand. If the operand has type ‘‘type’’, the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue. Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator. Otherwise, the result is a pointer to the object or function designated by its operand.

hustbaer schrieb:

[..]der Standard sagt, dass man keine ungültigen Adressen erzeugen oder rumreichen darf.[..]
[..]grosse dicke Ausnahme[..]
[..]man darf die Adresse des "one past last element" erzeugen und auch rumreichen.[..]

Hmmm... elegant is dann aber doch anders. Naja - gewachsene Systeme halt...

Sagen wir einfach mal es ist praktisch

[..]kann er auch die Adresse von Barack Obama berechnen[..]

Oder die meines Nachbarn...

Meine Aussage ist: es wird nichts "ausgewertet" (i.e. dereferenziert) sondern nur die Adresse meines Nachbarn errechnet. Es findet also nichts gefährliches oder aufwendiges statt.

Sagen wir einfach mal es ist praktisch

Michael E. schrieb:

[..]kann er auch die Adresse von Barack Obama berechnen[..]

Oder die meines Nachbarn...

Meine Aussage ist: es wird nichts "ausgewertet" (i.e. dereferenziert) sondern nur die Adresse meines Nachbarn errechnet. Es findet also nichts gefährliches oder aufwendiges statt.

Man kann wohl schwer mit nicht-standard Vokabular argumentieren, was der Standard als UB definiert oder nicht.

Das da ist z.B. UB:

void foo()
{
    int* p = new int; // OK
    int* p2; // OK
    delete p; // OK
    p2 = p; // BAM, oida - UB!
}

Das da IMO auch:

void bar()
{
    int* p; // OK
    int* p2 = p; // BIG BADABOOM, UB!
}

Nach deiner Argumentation dürfte in beiden Fällen nix passieren.
Laut Standard ist trotzdem beides UB, da man nur Zeigerwerte auf gültige Objekte (bzw. wieder mit der "one past last" Ausnahme) rumreichen darf.

The unary & operator yields the address of its operand. If the operand has type ‘‘type’’, the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue. Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator. Otherwise, the result is a pointer to the object or function designated by its operand.

Klingt stichhaltig für C (auch wenn ich aus dem "except that the constraints on the operators still apply" noch nicht so ganz schlau werde). Wahrscheinlich kann man davon ausgehen, dass es dann in C++ ebenso legal ist. Danke für die Recherche.

Ist hustbaer Österreicher(Wiener?)?

Österreicher ja, Wiener nein.
Wieso, wegen des "BAM, oida"? Das schreib ich nur weil ich es witzig finde, bin aber kein angehöriger der Gruppe die sich neuerdings als "Krocha" bezeichnet (früher auch als "Dumme Proleten" bekannt - k.A. wieso die nen neuen Namen erfinden mussten ).