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
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.
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