Seite 99 von 255

Re: Jammer-Thread

Verfasst: 19.12.2012, 17:24
von simbad
Na es gibt bei den GNU compilern irgendwo einen switch, der dazu führt, das mangelnder Speicher wie in C mit einem NULL-pointer angezeigt wird und nicht mit einer exception.

Re: Jammer-Thread

Verfasst: 19.12.2012, 17:30
von CodingCat
simbad hat geschrieben:Na es gibt bei den GNU compilern irgendwo einen switch, der dazu führt, das mangelnder Speicher wie in C mit einem NULL-pointer angezeigt wird und nicht mit einer exception.
Ja, bezüglich Exceptionspezifikation hat das wohl denselben Effekt. Einen Nullzeiger will ich dann aber genauso wenig, sondern vielmehr einen debugbaren Crash - der Fall soll ja gerade nie eintreten. Für Fälle, in denen solches Null-Fehlerverhalten notwendig ist, gibt es immer noch die nothrow-Überladungen. Eventuell bietet es sich an, weitere throw-Überladungen hinzuzufügen, sollte mal wirklich mit fehlschlagenden und behandelbaren Allokationen zu rechnen sein (für die STL bräuchte man in diesem Fall ein entsprechendes Allocator-Template).

Re: Jammer-Thread

Verfasst: 19.12.2012, 18:51
von Helmut
CodingCat hat geschrieben:Aber new wirft praktisch nie!

Code: Alles auswählen

// neu
void* operator new(std::size_t size) throw(); // für C++11 Compiler noexcept statt throw()
Wie kann das denn sein? Was würde denn dann passieren, wenn man das in einer Endlosschleife aufrufen würde?

Re: Jammer-Thread

Verfasst: 19.12.2012, 19:03
von CodingCat
Sollte eine Allokation mal wirklich nicht ausgeführt werden können, wird zunächst der new_handler aufgerufen, sofern von der Anwendung einer registriert wurde. Wenn dieser signalisiert, dass nichts zu machen ist, würde die Standardimplementierung des Operators dann eine Ausnahme werfen. Das würde in diesem Experiment zu undefiniertem Verhalten führen (weil die Standardimplementierung natürlich keine noexcept-Spezifikation hat):
C++11 §15.4 4 hat geschrieben:If any declaration of a function has an exception-specification that is not a noexcept-specification allowing all exceptions, all declarations, including the definition and any explicit specialization, of that function shall have a compatible exception-specification.
Das heißt, bei der gezeigten noexcept-Deklaration ist eine eigene Implementierung des Operators verpflichtend. Diesen würde man so implementieren, dass er in dem Fall, in dem die Standardimplementierung eine Ausnahme wirft, das Programm unterbricht (Debug) oder außerplanmäßig beendet (Release).

Der ganze Punkt ist ja, Fehlerbehandlung für Fehlerfälle, die in der Praxis nicht auftreten, aus dem Programm zu streichen. Ein Operator, der im Fehlerfall Null zurückgibt, ist hier in keiner Weise hilfreich, weil er allenfalls zur Fehlerverschleppung führt.

Re: Jammer-Thread

Verfasst: 19.12.2012, 19:13
von antisteo
Ab Januar sind elektronische Zertifikate für die elektronische Steuererklärung verpflichtend.

Fazit: Ich musste eine Signatur beantragen.
Die Formulare sind komplett auf Java-Applets basierend, deshalb hier die Problemliste:
- Ich will kein Java auf meiner Maschine aufgrund der Sicherheitslücken
- Mit dem OpenJDK funktioniert Elster nicht
- Mit dem Chromium-Browser funktioniert Elster nicht
- Auf Linux lässt sich das offizielle Sun Java nicht mehr als Browser-Plugin installieren (wohl aufgrund der Sicherheitslücke)
- Elster funktioniert nicht mit dem NextGeneration-Plugin-Interface, das klassische Browser-Plugin ist aber nicht mehr im Package enthalten
- Auf Windows 8 funktionierte sowohl Java6 als auch Java7 nicht, jedes mal Meldungen, dass das Programm nicht funktioniert
- Zwischenfazit: Keiner meiner Rechner (Linux, Windows8, beide 64 Bit mit IE10, FF 17, Chromium) war in der Lage, das Java-Applet zu öffnen
- Ich bin dann in den Computerpool der Uni gegangen
- Dort war eine zu alte Firefox-Version installiert
- Mit Windows 7 und Internet Explorer 9 hat es dann schließlich geklappt

Vielen Dank, bayrisches Finanzministerium.

Warum konnten die die Bestätigung der elektronischen Signatur nicht einfach als Zusatzfunktion in ElsterFormular einbauen? Da ist es doch auch clientseitig ausgeführter, vertrauenswürdiger Code.

Re: Jammer-Thread

Verfasst: 19.12.2012, 19:53
von antisteo
In 2 Tagen ist Release von gwX und wir haben es in der langen Entwicklungszeit nicht geschafft, auch nur ein wirklich durchdachtes, spielbares Szenario zu bauen.
Alles nur Techdemo der vielen Objekte, die man im Spiel benutzen kann.

Re: Jammer-Thread

Verfasst: 19.12.2012, 23:18
von Alexander Kornrumpf
antisteo hat geschrieben:Ab Januar sind elektronische Zertifikate für die elektronische Steuererklärung verpflichtend.

Fazit: Ich musste eine Signatur beantragen.

Vielen Dank, bayrisches Finanzministerium.
Und wieder einmal rechnet sich der Steuerberater :)

Re: Jammer-Thread

Verfasst: 20.12.2012, 08:26
von antisteo
Alexander Kornrumpf hat geschrieben:
antisteo hat geschrieben:Ab Januar sind elektronische Zertifikate für die elektronische Steuererklärung verpflichtend.

Fazit: Ich musste eine Signatur beantragen.

Vielen Dank, bayrisches Finanzministerium.
Und wieder einmal rechnet sich der Steuerberater :)
Ja.
Aber bis es richtig los geht, will ich es selber mal gemacht haben, um zu wissen, wie das funktioniert.

Re: Jammer-Thread

Verfasst: 20.12.2012, 14:34
von RazorX
ceGUI ist was den DirectX11 Renderer angeht inkompatibel zum Win8 SDK. Sitze gerade daran das D3DX Framework durch die neuen Elemente zu ersetzen.

Re: Jammer-Thread

Verfasst: 21.12.2012, 20:52
von glassbear
Schon krass, wie weit OpenGL teilweise hinter DX11 zurueckhaengt: http://www.pcgameshardware.de/Benchmark ... d-1041404/

Re: Jammer-Thread

Verfasst: 22.12.2012, 12:42
von CodingCat
Expression-SFINAE, keine Chance in VC 2010: decltype(*make_lval<T>()) wird für T = unsigned int einfach zu T&. Gratulation. VS 2012 IntelliSense versteht es, VC 2012 also hoffentlich auch.

Re: Jammer-Thread

Verfasst: 22.12.2012, 13:25
von dot
glassbear hat geschrieben:Schon krass, wie weit OpenGL teilweise hinter DX11 zurueckhaengt: http://www.pcgameshardware.de/Benchmark ... d-1041404/
Auch wenn ich persönlich lieber mit Direc3D arbeite: Sieht mir so aus als wär entweder der Benchmark schlecht programmiert oder die verwendeten OpenGL Treiber nicht ganz so optimal wie die Direct3D Treiber. Höchstwahrscheinlich hauptsächlich ersteres und ein wenig letzeres. Auf irgendeinen inhärenten Performancenachteil von OpenGL kann man aus diesem Test imo jedenfalls nicht schließen...

Re: Jammer-Thread

Verfasst: 22.12.2012, 15:39
von Krishty
Ich installiere auf einer blanken Windows-7-Installation Updates und TrustedInstaller springt auf 2.443.768 KiB Speicherverbrauch. WTF

Und jetzt fängt schon das Pagen an, weil ich hier ja nur 4 GiB habe … WTF WTF WTF

Re: Jammer-Thread

Verfasst: 23.12.2012, 21:38
von antisteo
Bei meinem Android-Telefon friert der Sound ein, sobald ich ein Dubstep-Lied im WEBM-Format anschaue.
Beispieldatei (falls ihr es selber testen wollt): http://www.file-upload.net/download-696 ... .webm.html

Re: Jammer-Thread

Verfasst: 24.12.2012, 13:33
von CodingCat
Der C-Präprozessor in MSVC ist intelligenter, als es der Standard verlangt (man könnte auch sagen, nicht standardkonform):

Code: Alles auswählen

#include <iostream>
 
#define con_do(a, b) a, b
#define con(a, b) con_do(a, b)
#define onetwo 1, 2
#define threefour 3, 4
 
void foo(int a, int b, int c, int d)
{
    std::cout << a << b << c << d;
}
 
int main()
{
    // MSVC ersetzt "korrekt", GCC meldet Fehler, weil der Standard
    // die Expansion von a und b bereits in con vorschreibt
    foo( con(onetwo, threefour) );
    return 0;
}
Dank dieses "Bugs"/"Features" kann ich in MSVC mit dem Präprozessor Variadic Templates emulieren, portabel ist die Emulation damit aber leider nicht mehr. Dieses Problem ließe sich übrigens leicht fixen, indem man den Operator ## auch für ein Whitespace-Token erlaubt, aber so weit hat natürlich mal wieder niemand gedacht. :evil:

Re: Jammer-Thread

Verfasst: 24.12.2012, 13:47
von dot
MSVC unterstützt mittlerweile doch Variadic Templates? :P

Re: Jammer-Thread

Verfasst: 24.12.2012, 14:06
von CodingCat
Dein MSVC vielleicht. Mein MSVC hat nicht mal Range-based For. :-/

Ich habe aber soeben eine Lösung gefunden, die auch unter gcc funktioniert:

Code: Alles auswählen

#include <iostream>
 
#define assert_no_va_args()
#define con_do(a, b) a, b
#define con(a, b, ...) con_do(a##__VA_ARGS__, b##__VA_ARGS__) assert_no_va_args(__VA_ARGS__)
#define onetwo 1, 2
#define threefour 3, 4
 
void foo(int a, int b, int c, int d)
{
    std::cout << a << b << c << d;
}
 
int main()
{
    // MSVC ersetzt "korrekt", GCC meldet Fehler, weil der Standard
    // die Expansion von a und b bereits in con vorschreibt
    foo( con(onetwo, threefour) );
    return 0;
}
Und ja, hässlicher geht es nicht mehr. Naheliegender wäre da noch can_do(##a, ##b). Aber selbst das haben sie vergeigt: Weil die Konkatenation keine gültigen Präprozessortokens ergibt, ist das Verhalten undefiniert. Glückwunsch, ein einfacher Operator zur Expansionsverzögerung hätte genügt.

Re: Jammer-Thread

Verfasst: 27.12.2012, 14:19
von CodingCat
Ich finde partout keinen eleganten Weg, Funktionstemplategruppen für bestimmte Typen zu instantiieren. Meine aktuelle Zwischenlösung:

Code: Alles auswählen

// Funktionstemplates
template <class X> X foo(int, float);
template <class X> Y<X> bar(X&);
// mehr Templates ...

void absorb(...) { }
typedef void (*absorbfun)();

// Intantiierungsfunktion
template <class X>
void InstantiateXFunctions()
{
   absorb
   (
      (absorbfun) foo<X>,
      (absorbfun) bar<X>,
      // mehr Templates ...
   );
}

// Intantiierung für bestimmte Typen
template void InstantiateXFunctions<Baz>();
template void InstantiateXFunctions<Fam>();
Traurig, aber im Moment das einzig Sinnvolle, das mir einfällt.

Re: Jammer-Thread

Verfasst: 27.12.2012, 16:36
von dot
Was genau bezweckst du denn damit? Möglicherweise ist friend eine Lösung!?

Code: Alles auswählen

template <typename T> void f();
template <typename T> int g();

template <typename T>
class InstantiateStuff
{
  friend void f<T>();
  friend int g<T>();
};
EDIT: Ok, das bringt vermutlich gar nix...

Re: Jammer-Thread

Verfasst: 27.12.2012, 16:45
von CodingCat
dot hat geschrieben:Was genau bezweckst du denn damit?
Die Instantiierung aller gelisteten Funktionstemplates, ohne dass ich diese für jeden Typen wiederholen muss. Im Grunde will ich dasselbe Verhalten wie bei der expliziten Instantiierung von Klassentemplates mit statischen Memberfunktionen, nur eben für Funktionengruppen außerhalb von Klassen.

Re: Jammer-Thread

Verfasst: 27.12.2012, 22:53
von Florian Keßeler
Lesen bildet:
Light userdata (unlike heavy userdata) have no per-value metatables. All light userdata share the same metatable
Und ich suche seit fast zwei Tagen nach dem Grund, warum meine Light-Userdaten in Lua ohne erkennbaren Grund ihre Metatabellen ändern.

Re: Jammer-Thread

Verfasst: 30.12.2012, 01:15
von eXile
Kurze Frage: Wenn ihr unter Visual Studio 2012 die Hintergrundfarbe für Breakpoint (Enabled) ändert und dann ein paar Breakpoints setzt, ändert sich dann die Zeilenfarbe der Zeilen, in denen ihr einen Breakpoint gesetzt habt? Bei mir nämlich nicht; und so langsam frage ich mich, was ich hier noch umstellen muss.

Re: Jammer-Thread

Verfasst: 30.12.2012, 16:30
von Schrompf
Eigentlich nicht, aber ich nicht sicher. Benutze mal die (lebensnotwendige) Suchfunktion im Theme-Editor und lass Dir alle Möglichkeiten zu Breakpoints auflisten. Ich hab hier nur die deutsche Version, da kommen bei "halt" auch irgendwelche "Texteditor - Haltepunkt erweitert"-Optionen, von denen ich keine Ahnung habe, ob und wo die verwendet werden.

Re: Jammer-Thread

Verfasst: 31.12.2012, 04:38
von eXile
Ich hab's! Unter Options → Debugging → General → Highlight entire source line for breakpoints and current statement anschalten.

Hat nur über 9000 Mannstunden in den Visual Studio Optionen und eine Windows-Neuinstallation gebraucht, bis ich das gefunden habe.

Alles wieder voller Farben beim Debuggen!

[youtube]gzlmQLbr1Y4[/youtube]

Re: Jammer-Thread

Verfasst: 05.01.2013, 13:34
von CodingCat
Wusstet ihr, wo sich injected-class-names überall tummeln?

Code: Alles auswählen

struct Foo { };

template <class Foo>
struct Bar : public ::Foo
{
    typedef Foo foo;
};

Bar<int>::foo i = 2; // Fehler: foo hat Typ ::Foo, injizierter Typname der Basisklasse verdeckt Template-Parameter
Eine nette Nebenentdeckung dieser unerfreulichen Überraschung ist, dass Typnamen von Basisklassen-Template-Instanzen innerhalb des Templates der abgeleiteten Klasse gar nicht erneut durch Wiederholung der Template-Argumente eingeführt werden müssen. Tatsächlich hängen die injizierten Typnamen von Basisklassen wie typedefs der Basisklasse in der abgeleiteten Klasse und müssen nur als abhängige Typen ausgezeichnet werden:

Code: Alles auswählen

template <class X>
struct Foo { };
 
template <class X>
struct Bar : public Foo<X>
{
//  typedef Foo foo; geht nicht, da Foo in Foo<X> injiziert wurde, der Inhalt
//  von Foo<X> jedoch erst zum Instantiierungszeitpunkt von Bar bekannt wird

    // Deshalb geht jedoch folgendes, womit sich ein Haufen Redundanz loswerden lässt:
    typedef typename Bar::Foo foo;
};
Eine weitere eindrückliche Demonstration des grausigen, von C ererbten C++-Kompilationsmodells, das Template-Programmierung zu einer schier unerlernbaren Kunstform macht. Die Notwendigkeit von typename, das Abwälzen von Compileraufgaben auf den Programmierer und die damit verbundene Unprüfbarkeit von isoliertem Template-Code - all das macht es unwahrscheinlich, dass Templates je einen brauchbaren Zustand erreichen werden.

Re: Jammer-Thread

Verfasst: 05.01.2013, 15:20
von Krishty
CodingCat hat geschrieben:Eine weitere eindrückliche Demonstration des grausigen, von C ererbten C++-Kompilationsmodells, das Template-Programmierung zu einer schier unerlernbaren Kunstform macht. Die Notwendigkeit von typename, das Abwälzen von Compileraufgaben auf den Programmierer und die damit verbundene Unprüfbarkeit von isoliertem Template-Code - all das macht es unwahrscheinlich, dass Templates je einen brauchbaren Zustand erreichen werden.
Schon; aber ich sehe Vererbung hier als das größere Problem. Ja; Templates sind furchtbar hässlich realisiert – aber Vererbung mit den tausend Möglichkeiten von Sichtbarkeit, Verdeckung, und Verstecken sehe ich als weitaus komplexer an. Die C++-Paragraphen z.B. über das Verhalten von friend bei Vererbung gehören mit zu dem Härtesten das man sich geben kann; und während ich bei jedem C++-Template-Problem für eine eigene Programmiersprache sofort wüsste, wie man es besser machen kann, habe ich vor Vererbung so enorme Angst, dass ich sie am liebsten einfach weglassen würde.

Re: Jammer-Thread

Verfasst: 07.01.2013, 12:32
von CodingCat
Für diese unfassbare Intelligenz lieben wir IntelliSense.
DumbSense.png

Re: Jammer-Thread

Verfasst: 07.01.2013, 23:54
von Schrompf
Die IGF-Nominierungen sind raus. Und keine Spur von Splatter :-( Es war gewissermaßen zu erwarten, rein statistisch gesehen bei >500 Einreichungen. Aber wenn ich dann manche der Spiele in "Excellence in Visual Arts" sehe, die ihre Grafik primär mit einfarbigen Rechtecken bestreiten, deprimiert mich das doch.

Re: Jammer-Thread

Verfasst: 08.01.2013, 09:25
von CodingCat
Ja, gerade gestern gesehen. Wahrscheinlich ist es bei dieser Masse von Einsendungen schon reine Glückssache, ob sich die Einsendung überhaupt jemand ansieht. :/

Re: Jammer-Thread

Verfasst: 08.01.2013, 11:50
von Toa
Ich möchte dieses [1] lowpoly Modell :cry:

[1] https://www.assetstore.unity3d.com/#/content/5095