ZFX + Developia

1. Krishtys schöne „Von-rechts-nach-links-Leseregel“ funktioniert leider nicht, sobald man Arrays benutzt:
   1. (&i)[3] ist eine Referenz auf ein 3-Array von ints,
   2. &(i[3]) ist ein 3-Array von Referenzen auf ints.
   Sollte man aber keine expliziten Array-Klammern im Typbezeichner haben, sollte die Leseregel aber wieder funktionieren.
2. Die Notation von Funktionen, die eine Referenz oder einen Pointer auf ein Array zurückgeben, ist relativ archaisch:

   Code: Alles auswählen

   // Gibt eine Referenz auf ein 3-Array von ints zurück
   int (& getThreeInts()) [3]
   {
   	static int theInts[3] = { 1, 2, 3 };
   	return theInts;
   }

   Das ganze gibt's hier auch in Aktion zu sehen.
3. Ich hatte mich schon einmal hier mit dem Zusammenspiel von Array-Referenzen und Templates befasst. Wie mir heute plötzlich aufgefallen ist, kann man das generalisieren und für eine Variante des „wie groß ist mein Array“-Problems benutzen:

   Code: Alles auswählen

   template <typename theType, size_t theSize>
   char (& AsArray(theType (&) [theSize])) [theSize];

   Code: Alles auswählen

   struct { int i; double d; } array[10];
   double * notAnArray;
    
   // Funktioniert.
   std::cout << sizeof(AsArray(array)) << std::endl;
   std::cout << sizeof(array) / sizeof(array[0]) << std::endl;
    
   // Funktioniert nicht; soll es auch nicht!
   // std::cout << sizeof(AsArray(notAnArray)) << std::endl;
    
   // Funktioniert; undefiniertes Verhalten. 
   std::cout << sizeof(notAnArray) / sizeof(notAnArray[0]) << std::endl;

   (Auch hier live und in Farbe). Im Gegensatz zu sizeof(…)/sizeof(…[0]) funktioniert es korrekterweise nicht mit Pointern. Es ist somit tatsächlich der Held den Gotham braucht typsicherer als das sizeof(…)/sizeof(…[0])-Konstrukt.

eXile hat geschrieben:Die Notation von Funktionen, die eine Referenz oder einen Pointer auf ein Array zurückgeben, ist relativ archaisch:

Code: Alles auswählen

// Gibt eine Referenz auf ein 3-Array von ints zurück
int (& getThreeInts()) [3]
{
	static int theInts[3] = { 1, 2, 3 };
	return theInts;
}

Das ganze gibt's hier auch in Aktion zu sehen.

eXile hat geschrieben:Ich hatte mich schon einmal hier mit dem Zusammenspiel von Array-Referenzen und Templates befasst. Wie mir heute plötzlich aufgefallen ist, kann man das generalisieren und für eine Variante des „wie groß ist mein Array“-Problems benutzen:
[...]
(Auch hier live und in Farbe). Im Gegensatz zu sizeof(…)/sizeof(…[0]) funktioniert es korrekterweise nicht mit Pointern. Es ist somit tatsächlich der Held den Gotham braucht typsicherer als das sizeof(…)/sizeof(…[0])-Konstrukt.

template <class T, size_t N>
inline size_t arraylen(T (&)[N]) // constexpr?
{
   return N;
}

// Funktioniert.
std::cout << arraylen(array) << std::endl;
 
// Funktioniert nicht; soll es auch nicht!
std::cout << arraylen(notAnArray) << std::endl;

C++11 hat geschrieben:The definition of a constexpr function shall satisfy the following constraints:
[...]
— each of its parameter types shall be a literal type;
[...]

CodingCat hat geschrieben:Worauf du hier hinaus willst, ist mir nicht ganz klar.

CodingCat hat geschrieben:Dieser ganze sizeof-Kram sollte eigentlich überhaupt nie mehr vorkommen.

std::array<D3D11_INPUT_ELEMENT_DESC> inputLayout = {1, 2, 3};

std::array<D3D11_INPUT_ELEMENT_DESC, 3> inputLayout = {1, 2, 3};

std::array<D3D11_INPUT_ELEMENT_DESC, 3> inputLayout = {1, 2};

D3D11_INPUT_ELEMENT_DESC inputLayout[] = {1, 2};

CodinCat hat geschrieben:Warum die Standard-Bibliothek noch immer keine arraylen-Funktion anbietet, ist mir genauso ein Rätsel wie ihre kryptische, streng iteratorbasierte Algorithmenschnittstelle.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf hat geschrieben:The definition of a constexpr function shall satisfy the following constraints:
[…]
— its return type shall be a literal type;
— each of its parameter types shall be a literal type;
[…]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf hat geschrieben:A type is a literal type if it is:
[…]
— a reference type referring to a literal type; or
— an array of literal type; or
[…]

eXile hat geschrieben:Ich wollte eigentlich auf gar nichts hinaus. ;) Ich fand es nur interessant, dass obiger Code von mir tatsächlich funktioniert; ich finde ihn ganz hübsch, was natürlich eine viel zu subjektive Einschätzung ist. :)

eXile hat geschrieben:

CodingCat hat geschrieben:Dieser ganze sizeof-Kram sollte eigentlich überhaupt nie mehr vorkommen.

Naja, vielleicht doch, wenn auch nur sehr, sehr selten. Machen wir halt ein ganz konkretes Beispiel. [...]

eXile hat geschrieben:Stattdessen schreiben wir

Code: Alles auswählen

D3D11_INPUT_ELEMENT_DESC inputLayout[] = {1, 2};

und übergeben als Array-Größe sizeof(asArray(inputLayout)). Keine Abhängigkeit mehr.

eXile hat geschrieben:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf hat geschrieben:The definition of a constexpr function shall satisfy the following constraints:
[…]
— its return type shall be a literal type;
— each of its parameter types shall be a literal type;
[…]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf hat geschrieben:A type is a literal type if it is:
[…]
— a reference type referring to a literal type; or
— an array of literal type; or
[…]

Und da das formal eine Referenz auf ein Array ist (und damit ja auch nicht zu einem Pointer verflacht werden kann!) sollte das keine Probleme geben.

Und ja, man sollte so etwas wie arraylen in die STL aufnehmen.

CodingCat hat geschrieben:Naja, diese Dopplung sizeof(AsArray(...)) erscheint mir nicht viel weniger fehleranfällig als sizeof(...) / sizeof(...).

CodingCat hat geschrieben:In beiden Fällen führt das intuitive Weglassen der zweiten Hälfte zu nicht zur Compile-Zeit erkennbarem Fehlverhalten.

CodingCat hat geschrieben:Obendrein ist sizeof(AsArray(...)) intuitiv absolut unverständlich?! ;)

CodingCat hat geschrieben:Stattdessen schreiben wir arraylen(inputLayout), noch eine Fehlerquelle weniger. ;)

CodingCat hat geschrieben:Das "überhaupt nie" bezog sich nicht auf std::array, sondern auf konsequentes arraylen() statt sizeof()-Gepfriemel.

CodingCat hat geschrieben:In den meisten Fällen ist constexpr ohnehin nicht notwendig.

eXile hat geschrieben:Ich wollte noch eine Variante, die auch zur Kompilierzeit funktioniert (und constexpr ist in Visual C++ ja noch nicht drin). Aber du hast recht, die Dopplung ist absolut unnötig und gehört weggekapselt in einer Funktion. ;)

template <typename T, size_t N>
char (& deduce_same_extent_char_array_type(T (&)[N]) )[N];

#define arraylen(a) sizeof(deduce_same_extent_char_array_type(a))

Krishty hat geschrieben:Am Arsch – Visual C++ ist manchmal so dumm, dass ich nur noch in Großbuchstaben programmieren will. Für den Fall von arraylen klappt es definitiv, ja. Aber glaub ja nicht, dass die Funktion, die den Wert als Parameter erwartet, den als constexpr weiterbenutzt – sogar dann, wenn sie komplett geinlinet wird, ist das bloßes Glücksspiel.

http://blogs.msdn.com/b/vcblog/archive/2012/06/15/10320846.aspx hat geschrieben:STL Bugs Fixed In Visual Studio 2012
The <initializer_list> header in the VC10 release candidate

http://connect.microsoft.com/VisualStudio/feedback/details/533464 hat geschrieben:We've fixed it by deleting <initializer_list> from VC11.

CodingCat hat geschrieben:In prä-constexpr halb-sechzehntel-C++11-Compilern wie MSVC10+ gibt es btw. auch das etwas umständlichere std::extent<decltype(a)>::value für Compile-Zeit-Kontexte.

virtual com_ptr<ID3D11InputLayout> createInputLayout(device, shadersignature) const = 0;

eXile hat geschrieben:Krishtys schöne „Von-rechts-nach-links-Leseregel“ funktioniert leider nicht, sobald man Arrays benutzt: