Jammer-Thread

[Artificial Mind]

Ich benutze wieder #define für Konstanten. Mit einer const-Variable hat man entweder unzählige Duplikate oder das Static Initialization Order Fiasco. C++ kriegt nicht einmal die einfachsten Dinge hin. So ein Sauhaufen; es ist echt zum Heulen.

Für non-strings würden es doch Enums auch tun oder?

[Krishty]

Ja; aber nicht für float oder double.

[B.G.Michi]

Dann nimm Macros. Ich versteh das ganze Anti-Macro-Gebashe nicht so ganz... sie sind ein Teil der Sprache C++ und wenn sie der bester/einfachste/schnellste Weg sind um ein Ziel zu erreichen, warum sie nicht verwenden? Alles andere hält nur unnötig auf. Und wenn dir in 2 Jahren was besseres einfällt, oder MSVC constexpr vernünftig unterstützt kannst du das immer noch ändern.

[dot]

[...] sie sind ein Teil der Sprache C++ und wenn sie der bester/einfachste/schnellste Weg sind um ein Ziel zu erreichen, warum sie nicht verwenden?[...]

Sie mögen Teil der Sprache C++ sein, aber sie sind nunmal nur sehr sehr selten eine gute Lösung und noch viel seltener der beste Weg, um ein Ziel zu erreichen. Gerade float und double Konstanten sind ein schönes Beispiel: Makros sind nicht typsensitiv. Natürlich kannst du einfach pro Konstante ein Makro für jeden verschiedenen Typ anbieten. Von den üblichen Problemen, wie beispielsweise der Tatsache, dass der Präprozessor Dinge wie Scope völlig ignoriert, abgesehen, funktioniert das aber z.B. überhaupt nicht, sobald templates ins Spiel kommen. Und einfach nur eine allgemeine Konstante vom Typ double führt schnell ineffizientem Code, sobald sie zusammen mit floats benutzt wird da der Compiler alles mit Konvertierungsoperationen pflastern muss...

[Krishty]

dot, ich weiß von dir noch aus einem Optimierungs-Thread, dass du Konstanten wie INF und NaN für double und float anlegst. Sagen wir also, du hast eine Konstante Constants<float>::nan.

Die wirst du, gerade wenn du mit Template-Spezialisierungen arbeitest (um alle Konstanten generisch abstrahiert ansprechen zu können), nicht im Header definieren können, sondern in einer einzigen Übersetzungseinheit (landläufig in einer .cpp).

Falls du jetzt eine andere Konstante haben willst, die auf diesen Werten aufbaut, rennst du ins Fiasco. Ich brauche z.B. ständig einen zu NaN initialisierten Vec3D, aber wenn ich die Konstante

  Vec3D const nanVec = { Constants<float>::nan, Constants<float>::nan, Constants<float>::nan };

anlege, und das in einer anderen Übersetzungseinheit (selbstverständlich!), ist die Initialisierungsreihenfolge undefiniert. Obwohl es POD ist. Obwohl der Compiler es statisch auflöst. Obwohl alles direkt ins Read-Only Data Segment wandert (außer bei Visual C++ ohne Optimierungen; da löst sogar POD-Initialisierung mit statischen Parametern eine Laufzeitinitialisierung aus).

Wenn du Glück hast, ist nanVec voll Nullen und du bemerkst den Fehler sofort. Wenn du Pech hast, steht wirklich NAN drin, aber nur, so lange der Compiler in der richtigen Reihenfolge kompiliert. Und eines Tages geht dein Programm kaputt weil in allem, das eigentlich mit NAN und INF gefüllt sein sollte, plötzlich 0 steht. Ohne Warnung oder Verdacht.

Was nutzt mir Typsicherheit wenn in meinen Konstanten nicht einmal die Werte stehen, die ich eigenhändig in aller Deutlichkeit zugewiesen habe? Ein Ausweg wäre, die Konstanten static zu deklarieren. Dann bekommt jede Übersetzungseinheit eine eigene Kopie, und die wird in der #include-Reihenfolge initialisiert. Geht aber nicht mit Templates. Und eben dieser jeder Einheit ihre eigene Kopie-Effekt ist aber bei nicht-Konstanten völlig irreführend und ebenso gefährlich. („Ich habe dieser Variable eben 3 zugewiesen. Warum steht immernoch 0 drin?!“)

Dann kommen noch Compiler-spezifische Erweiterungen wie __declspec(selectany). Aber wie viele hier wissen denn schon, was die machen und wofür die da sind? Und hat die andere Plattform sowas auch?

Diese Fehler finde ich kein Bisschen weniger widerlich als die, die einem mit Makros drohen. Aber ich kann jedem in zwei Minuten erklären, wie Makros funktionieren und was an ihnen gefährlich ist – bis jemand C++’ Modulsystem und die resultierenden Randfälle bei globalen Variablen und Templates verstanden hat, vergeht meist mindestens ein Tag. Darum jetzt eben Makros.

P.S.: Auch constexpr wird daran nichts ändern. Das ist einfach ein Aspekt, in dem C++ fubar ist.

tl;dr:

  // a.cpp
  float const nan = 1.0e38f * 10.0f * 0.0f;

  // b.cpp
  Vec3D const nanVec = { nan, nan, nan };

wird nicht funktionieren, und du nennst Makros heimtückisch.

[CodingCat]

Aktuell ist die landläufige C++-Lösung, aus den Konstanten Funktionen mit entsprechendem Rückgabewert zu machen. constexpr wird hier den Auswertungszeitpunkt festlegen. Die Tatsache, dass man dann Funktionen mit vollkommen unsinniger Bloat-Aufrufnotation hat, ärgert mich mindestens so sehr wie die Makroalternative, aber immerhin funktioniert es dann zuverlässig.

[Krishty]

Ah; danke – dann tut sich ja doch noch was :-) Trotzdem hasse ich Datenzugriffe durch Text. Wenn ich an b von a will, schreibe ich a.b, und nicht a.b(). Konstanten sind Daten, kein Code. Aber bitte; wenn es funktioniert, muss es nicht schön sein.

(Ich halte mich hier der Diskussion zuliebe mit allem Compiler-Misstrauen gegenüber Datenfaltung, Auflösung statischer Initialisierungen, usw. zurück. Also geht bitte nicht darauf ein, dass ich nicht glaube, dass irgendein Compiler constexpr vor 2020 so effizient umsetzt wie Makros.)

[CodingCat]

Aber bitte; wenn es funktioniert, muss es nicht schön sein.

Doch, eigentlich muss es das. Aber die Tatsache, dass so vieles in der richtigen Form unvergleichlich hässlicher und unintitiver ist als in der falschen Form (und deshalb die falsche Form im allgemeinen Code-Körper konsequent vorherrscht), zieht sich ja schon länger wie ein roter Faden durch die Sprache.

[dot]

Und in C++14 gibt's dann variable templates... ;)

[CodingCat]

Und in C++14 gibt's dann variable templates... ;)

Wetten wir, dass deren Initialisierung unordered ist? :twisted:

Nachträgliche Anmerkung: Bisher finde ich nichts dergleichen im aktuellen Draft; weder zur Auswertungsreihenfolge von globalen constexpr-Variablen, noch zur Initialisierungsreihenfolge von Variable Templates.

[Artificial Mind]

Der VS 2013 Optimizer stürzt bei Code ab der wie folgt aussieht:

Code: Alles auswählen

do {
...
} while (...);
while (a < aEnd) {
*a++ = ...
}

Soll im RTM gefixt sein: https://connect.microsoft.com/VisualStu ... ls/800094/

Was betrifft das? Etliche Funktionen aus Qt 5.1.1 was ich gerade für VS12 kompilieren will.

Mehr Jammer: Leute die ihre Fragen mit Visual Studio 2012 taggen und dann Fehlermeldungen haben die 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\...' beinhalten.

[Krishty]

Visual Studio 2010 installiert. Benötigt .NET Framework.

Oh.

Ich musste während der Installation drei Mal neu starten. Danach musste ich 60 Sicherheitsupdates mit 330 MiB Größe installieren. Ich warte jetzt seit einer Stunde, dass das fertig wird. Und wozu? Wo ist Visual C++’ Benutzeroberfläche .NET?

Verfickte Bloatware

Visual Studio 2012 installiert. Benötigt .NET Framework 4.5.

Oh.

Diesmal ohne Neustart, aber dafür mit 253 MiB Sicherheitsupdates. FUCK MY LIFE

Mehr Jammer: Leute die ihre Fragen mit Visual Studio 2012 taggen und dann Fehlermeldungen haben die 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\...' beinhalten.

Die Versionsnummer nicht durch die Jahreszahl zu ersetzen war die bescheuerteste Entscheidung von MS überhaupt. Es war absehbar, dass das jeder verwechseln wird. „Das 2010er Produkt ist Version 10; das 2012er Produkt ist Version 11; und das 2013er Produkt ist Version 12.“ Sind das Autisten im Marketing?!

Ich liefere meine Software übrigens schon lange nicht mehr mit Versionsnummern aus, sondern mit dem Erstelldatum.

[kaiserludi]

Der VS 2013 Optimizer stürzt bei Code ab der wie folgt aussieht:

Code: Alles auswählen

do {
...
} while (...);
while (a < aEnd) {
*a++ = ...
}

Soll im RTM gefixt sein: https://connect.microsoft.com/VisualStu ... ls/800094/

Was betrifft das? Etliche Funktionen aus Qt 5.1.1 was ich gerade für VS12 kompilieren will.

Mehr Jammer: Leute die ihre Fragen mit Visual Studio 2012 taggen und dann Fehlermeldungen haben die 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\...' beinhalten.

Wäre ich VS2013, ich würde da genauso abstürzen, weil mir als Compiler speiübel werden würde bei der Klammersetzung :twisted:

[eXile]

Da wir gerade bei Bug-O-Rama sind: Hat jemand schon mal diesen Bug gesehen oder gemeldet?

Code: Alles auswählen

template <typename Type, Type>
class MyClass {};

template <template <typename Type, Type> class TemplateClass>
void test() {}

int main(int argc, char * argv[])
{
	test<MyClass>();

	return 0;
}

Wie man sieht, gar keine Besonderheiten (keine variadic templates, keine decltypes, nichts besonderes). Das ist definitiv eine Regression und funktioniert mit Visual Studio 2012 ohne Probleme. Im November CTP stürzt es bereits ab. In der Visual Studio 2013 RC stürzt es auch ab. Fehlermeldung ist ein standardmäßiger internal compiler error, sowohl auf x86 wie auch x64:

1>------ Build started: Project: test, Configuration: Debug x64 ------
1> main.cpp
1>main.cpp(10): fatal error C1001: An internal error has occurred in the compiler.
1> (compiler file 'msc1.cpp', line 1468)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1> Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
1> INTERNAL COMPILER ERROR in 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\AMD64\CL.exe'
1> Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Kann mir gerade jemand sagen, ob

Microsoft (R) C/C++ Optimizing Compiler Version 18.00.20617.1 for x64

der aktuellste Compiler ist, den man testen kann?

Ich habe mal nach „(compiler file 'msc1.cpp', line 1468)“ gesucht, und von den fünf Ergebnissen sind zwei Fehlermeldungen zu variadic templates (hier nicht benutzt), eine Fehlermeldung zu decltype (hier auch nicht benutzt) und zwei vollkommen unrelatierte Fehlermeldungen. Irgendjemand wird das doch schon gemeldet haben?

Übrigens stürzt auch ab:

Code: Alles auswählen

#include <iostream>

template <typename Type, Type>
class Class1 {};

template <template <typename Type, Type> class Class1Type>
class Class2
{
public:
	template <template <typename OtherType, OtherType> class OtherClass1Type>
	void test(Class2<OtherClass1Type> & theOther)
	{
		return;
	}
};

int main(int argc, char * argv[])
{
	Class2<Class1> c1;
	Class2<Class1> c2;

	c2.test(c1);
	
	return 0;
}

Dieses Beispiel ist aber etwas komplizierter als das obere.

[Artificial Mind]

Ich kann dir nur sagen dass Microsoft bei vielen dieser Bugs den folgenden 'Fix' vorschlägt (bis zum RTM):

Code: Alles auswählen

#pragma optimize( "", off )

// Problematische Funktion

#pragma optimize( "", on )

[eXile]

Ich kann dir nur sagen dass Microsoft bei vielen dieser Bugs den folgenden 'Fix' vorschlägt (bis zum RTM):

Code: Alles auswählen

#pragma optimize( "", off )

// Problematische Funktion

#pragma optimize( "", on )

Danke für den Tipp, das wird für die Zukunft bestimmt noch einmal nützlich sein. In diesem Falle trat der von mir beschriebene Bug aber mit so ziemlich allen Einstellungen (x86, x64; Debug, Release) auf. Noch vor der code generation schmeißt der einen internal compiler error.

[Schrompf]

Es ist deprimierend, hier mitzulesen. Es ist noch deprimierender, wenn ich das heimlich vom Arbeitsrechner aus tun muss, weil meine Hardware letzte Woche gestorben ist. Der neue Rechner ist unterwegs, aber genau genommen kann ich mir den gar nicht leisten... Indie-Entwicklung stinkt.

[antisteo]

Im Heise-Forum behauptet jemand, der GLSL-Compiler säße auf der Grafikkarte.

[eXile]

Fassen wir mal zusammen:

1. PC/Windows: OpenGL soll alle Mantle-Features als OpenGL-Extensions bekommen, und zwar mit gleicher Geschwindigkeit (Quelle).
2. PC/Linux: Wohl dito. Zumindest von Nvidia bin ich es gewohnt, alle Extensions auch unter Linux zu haben. Wie sieht es da mit AMD aus?
3. XBox One: Kein Mantle (Quelle).
4. PlayStation 4: Kein Mantle (Quelle).

Und nun? Die erste Frage ist, worauf sich Johan Andersson dann in seiner Präsentation bezogen hat, als er „cross platform“ gesagt und geschrieben hat. Da er direkt davor von Konsolen gesprochen hat, bin ich davon ausgegangen, dass er die Platformen PC/Windows, XBox One und PlayStation 4 damit meinte. Da letztere beiden jetzt wohl weg sind, bleibt nur noch die Interpretation von „cross platform“ als PC/Windows und PC/Linux. Auf welchen es auch OpenGL gibt. Mit allen Mantle-Extensions. Mit zumindest versprochen gleicher Performance.

Und jetzt erklärt mir bitte mal einer, warum man Mantle braucht.

[glassbear]

Fassen wir mal zusammen:

1. PC/Windows: OpenGL soll alle Mantle-Features als OpenGL-Extensions bekommen, und zwar mit gleicher Geschwindigkeit (Quelle).
2. PC/Linux: Wohl dito. Zumindest von Nvidia bin ich es gewohnt, alle Extensions auch unter Linux zu haben. Wie sieht es da mit AMD aus?

AMD unter Linux mit dem Catalyst ist eine Katastrophe.
OpenGL mit AMD ist ... suboptimal.

Vielleicht pushen die Mantle, damit der OpenGL-Treiber nicht auf Vordermann gebracht werden braucht :lol:

[spobat]

Welcher state?

Code: Alles auswählen

com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

[Chromanoid]

Geiler Fund :)

[joggel]

Sagt mal, ist das nicht gefährlich? Ich habe bei dieser Zeile ein ganz ungutes Gefühl:

Code: Alles auswählen

*mSetting = getSetting();

wobei mSetting wie folgt deklariert wurde:

Code: Alles auswählen

Setting* mSetting;
// und die  Funktion getSetting() hat folgende Deklaration
Setting getSetting()

[Florian Keßeler]

Solang mSetting irgendwo zwischdurch initialisiert wird und auf ein gültiges Setting-Objekt zeigt ist da kein Problem.

[joggel]

Ja, stimmt. Es wurde vorher initialisiert.
War irgendwie ein Denkfehler. Die Funktion gibt ja eine Kopie zurück, und diese Kopie wird eben nochmal Kopiert, und überschreibt den Inhalt der originals welches sich vorher bei <mSetting> befand...
Gut-gut-guuuuut

[Krishty]

Welcher state?

Code: Alles auswählen

com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

Fehlt da nicht was?

Code: Alles auswählen

com.sun.java.swing.plaf.nimbus.InternalFrame.InternalFrameTitlePane.InternalFrameTitlePaneMaximizeButton.WindowNotFocusedState

Außerdem: Quelle?

[Chromanoid]

Nein, das Baby ist mit dem langen Namen (ohne Punkte) so in der JRE zu finden. Ich nehme an, das hat evt. etwas mit sehr strengen Benamungsregeln, Generierung oder Maschinenlesbarkeit zu tun.

Wenn man googled findet man diesen lustigen Beitrag :)
http://www.pushing-pixels.org/2007/11/0 ... me-is.html

sehr geiler stackoverflow beitrag dazu
http://stackoverflow.com/questions/1869 ... 589#891589

[Krishty]

Danke :-) Die seriösest anmutende Quelle, die ich gefunden hatte, war die hier :(

[Chromanoid]

Achso, ja ich hab hier Eclipse (Java) offen, da musste ich nur kurz einmal CTRL+SHIFT+T drücken...
PS: So gestört so lange Namen aussehen, ich finde lange Namen besser als kryptische Kürzel oder ähnliches.

[Schrompf]

Gestern kam meine schicke neue Hardware an. Seit etwa 10 Jahren bin ich eigentlich nur noch Datennomade, indem ich Festplatten auf neue Hardware oder lebende Betriebssysteme auf neue Festplatten umpflanze. Aber hier geht das nicht... irgendeiner der alten Mainboard-Treiber crasht beim Booten auf der neuen Hardware. Irgendjemand eine Idee, was ich da tun könnte, ohne das OS neu zu installieren?