ZFX + Developia

dot hat geschrieben:http://isocpp.org/forums/iso-c-standard ... -proposals ;)

CodingCat hat geschrieben:Ein weiteres Proposal wären übrigens Modifier Templates:

Code: Alles auswählen

template <modifier M>
M Foo* getFoo() M { return this->foo; }

Aber wer würde so etwas überhaupt verstehen, geschweige denn nutzen?

dot hat geschrieben:Und das wird von gängigen Compilern auch wirklich entsprechend geinlined, sodass kein Laufzeit if() mehr drin is!?

Was genau wäre denn ein Anwendungsfall für so ein Modifier Teamplate!? (Sollte es nicht eher Qualifier heißen? ;))

eXile hat geschrieben:

Krishty hat geschrieben:Hmm; was meinst du mit korrekter Textselektion?

Angenommen wir haben den Quelltext

Code: Alles auswählen

template <typename Type1, typename Type2>
MyClass(
	MyClass<Type1, Type2> const & theOther
) {
	return;
}

Ich klicke doppelt auf Type1 in der dritten Zeile. Selektiert wird s<Typ, also genau eine Selektion, die im zwei Zeichen nach links verrückt ist. Diese Differenz von zwei Zeichen gilt dann auch für alle nachfolgenden Zeilen. Das Problem tritt nur auf:

1. Wenn extrem Template-lastiger Code in der aktuellen Datei steht,
2. zuvor Intellisense einige legale Konstrukte für fehlerhaft erkannt hat, und
3. ich Visual Studio seit drei Tagen nicht geschlossen habe.

Wenn so ein Fall auftritt funktioniert auch ein go to definition nicht mehr in der aktuellen Quelltext-Datei. Bis zum Löschen der sdf-Datei bleibt das auch so bestehen.

CodingCat hat geschrieben:Ich wünsche mir ein layout_cast, das wie reinterpret_cast funktioniert, aber fehlschlägt, wenn das transitive Datenlayout von Quell- und Zieltyp nicht übereinstimmt [...]

/// Asserts layout-compatibility of the given (struct) members.
#define LEAN_LAYOUT_COMPATIBLE(s, m, t, n) static_assert( \
	offsetof(s, m) == offsetof(t, n) && sizeof(reinterpret_cast<s*>(0)->m) == sizeof(reinterpret_cast<t*>(0)->n), \
	#s "::" #m " is not layout-compatible with " #t "::" #n)

/// Asserts size-compatibility of the given (struct) types.
#define LEAN_SIZE_COMPATIBLE(s, t) static_assert( \
	sizeof(s) == sizeof(t), \
	#s " is not size-compatible with " #t)

//Header
struct RenderableMaterialTechnique
{
	beGraphics::Setup *Setup;
	const AbstractRenderableEffectDriver *EffectDriver;
};

// Module
struct RenderableMaterial::Technique
{
	lean::resource_ptr<beGraphics::Setup> Setup;
	lean::resource_ptr<AbstractRenderableEffectDriver> Driver;
};
LEAN_LAYOUT_COMPATIBLE(RenderableMaterialTechnique, Setup, RenderableMaterial::Technique, Setup);
LEAN_LAYOUT_COMPATIBLE(RenderableMaterialTechnique, EffectDriver, RenderableMaterial::Technique, Driver);
LEAN_SIZE_COMPATIBLE(RenderableMaterialTechnique, RenderableMaterial::Technique);

CodingCat hat geschrieben:Ja, sie hätten schreiben sollen An application should return zero to suppress default message handling.

Krishty hat geschrieben:Das Krasse ist, dass ja scheinbar Default Handling stattfindet, denn sonst hätte sich mein Fenster nie vergrößern, verkleinern oder sonstwas lassen – wahrscheinlich nicht einmal erzeugen lassen. Eine Pest, dass man erstmal das halbe Windows-Subsystem verstehen muss um zu begreifen, was ein return bedeutet.

Krishty hat geschrieben:Nachdem ich eine Stunde lang die Ursache gesucht habe, warum ich WM_SIZE nur einmal beim Start und danach niemals wieder erhalte, weiß ich nun: DefWindowProc() muss immer und für jede Nachricht aufgerufen werden – und nicht bloß für die, mit denen man nichts anzufangen weiß, und die man ganz unten unter dem default-Schild vergräbt.

Krishty hat geschrieben:Bis heute hat mich der MSDN-Text An application should return zero if it handles this message immer dazu verleitet, tatsächlich return 0; zu schreiben. Nachdem ich eine Stunde lang die Ursache gesucht habe, warum ich WM_SIZE nur einmal beim Start und danach niemals wieder erhalte, weiß ich nun: DefWindowProc() muss immer und für jede Nachricht aufgerufen werden – und nicht bloß für die, mit denen man nichts anzufangen weiß, und die man ganz unten unter dem default-Schild vergräbt.

Helmut hat geschrieben:Nein, nein. Das kann nicht sein. DefWindowProc macht für WM_SIZE garnichts. Bei WM_WINDOWPOSCHANGED musst du DefWindowProc aufrufen, um WM_SIZE zu erhalten, das steht aber auch in der Dokumentation.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms632652 hat geschrieben:It is more efficient to perform any move or size change processing during the WM_WINDOWPOSCHANGED message without calling DefWindowProc.

Schrompf hat geschrieben:Weil ich sie gelöscht habe. Also sowohl die Dame als auch ihren automatisch übersetzten Werbebeitrag.