Jammer-Thread

[dot]

(Und ich liebe den Formelsatz. In LaTeX formuliere ich mathematisch was geht, nur weil es schön aussieht. :mrgreen: )

Mir geht's genauso :lol:

[Alexander Kornrumpf]

(Und ich liebe den Formelsatz. In LaTeX formuliere ich mathematisch was geht, nur weil es schön aussieht. :mrgreen: )

Mir geht's genauso :lol:

Die innere Schönheit einer mathematischen Formulierung hat doch mit LaTex nichts zu tun. Mit Stift und Papier würde ich es genauso machen. Dass man das mit Word nicht tut spricht eher gegen Word als für LaTex.

Ich bin immer wieder, wenn ich mit Word arbeiten muss erstaunt wie sehr es suckt. Nicht nur bei Formeln, sondern auch bei Dingen, die eigentlich Words Kernkompetenz sein sollten.

[CodingCat]

Ich kann mich nicht entscheiden.

Code: Alles auswählen

// Variante 1 (Aktuell)
resource_ptr<SomeResource> someResource = bind_resource( new SomeResource(...) ); // OK
resource_ptr<SomeResource> someResource = new SomeResource(...); // Ressourcen-Leck
// Keine _ungewöhnlichen_ Vorkehrungen für ausnahmesichere in-place Konstruktion
resourceMonster( dangerous stuff ..., bind_resource( new SomeResource(...) ).get(), ... dangerous stuff );

Code: Alles auswählen

// Variante 2
resource_ptr<SomeResource> someResource = new SomeResource(...); // OK
resource_ptr<SomeResource> someResource = bind_resource( new SomeResource(...) ); // Falsch, denn ...
resource_ptr<SomeResource> someResourceRef2 = someResource; // ... zerstört SomeResource mit someResourceRef2, crasht mit Zerstörung von someResource
// Zusätzliche Vorkehrungen für ausnahmesichere in-place Konstruktion
resourceMonster( dangerous stuff ..., secure_resource( new SomeResource(...) ).get(), ... dangerous stuff );

Code: Alles auswählen

// (Variante 3: Lieber nicht, weil inkonsistent)
resource_ptr<SomeResource> someResource = new SomeResource(...); // OK
resource_ptr<SomeResource> someResource = bind_resource( new SomeResource(...) ); // OK
// Zusätzliche Vorkehrungen für ausnahmesichere in-place Konstruktion
resourceMonster( dangerous stuff ..., secure_resource( new SomeResource(...) ).get(), ... dangerous stuff );
resourceMonster( dangerous stuff ..., bind_resource( new SomeResource(...) ).get(), ... dangerous stuff ); // Auch möglich

Im Optimalfall würde new einen resource_ptr zurückgeben, aber so weit sind wir mit C++ wohl dann doch noch nicht.

(In 100 Jahren könnte man zumindest new für Ressourcen protected machen und eine variadic perfect-forwarding Ressourcenerzeugungsfunktion bereitstellen.)
(Wenn Microsoft mit Windows 29 nicht noch vor vollendeter C++11-Implementierung endgültig auf Wolkendiagramme umsattelt.)

[eXile]

Meiner Meinung nach Variante 1. Das ergibt die Analogie resource_ptr = shared_ptr, bind_resource = make_shared und halt get in beiden Fällen.

Wer make_shared nicht benutzt ist eben auch selber schuld ;)

[CodingCat]

Inzwischen tendiere ich auch dazu, einfach eine entsprechende Template-Wrapper-Funktion zur Ressourcenerzeugung als Alternative zu bind_resource . new anzubieten. Am expliziten bind_resource stört mich im Moment vor allem, dass sich die Ressourcenallokation durch die zusätzliche Binde-Umklammerung im Quelltext furchtbar sperrig gestaltet.

Schade ist, dass mit der variadischen Wrapper-Funktion bei der Ressourcenerzeugung die bisweilen sehr vielzähligen Parameternamen im IntelliSense verloren gehen.

[Krishty]

Zustände

nicht mehr Bäumen gleich; nein

Zustandswälder

so dunkel, dass man sie nur Schritt für Schritt erkunden kann

wo ferne Wirkungen aus allen Richtungen schnattern und grunzen

und die Schwärze nur vom Kreischen der Allokatoren zerrissen wird

schmierige Getter und Setter umschmiegen meine Füße

während sie im Patternsumpf versinken

wenn man mich fragte, woran ich arbeite … ich wüsste es nicht mehr

ich will aufwachen

aber es geht nicht

es geht einfach nicht mehr

der Wahnsinn hat meinen Kopf mit seinen knochigen Fingern fest umschlungen

ich beginne zu erkennen

[CodingCat]

Code: Alles auswählen

#define LEAN_NEW_RESOURCE_FUNCTION_TPARAMS \
   class Resource
#define LEAN_NEW_RESOURCE_FUNCTION_DECL \
   inline resource_ptr<Resource, true> new_resource
#define LEAN_NEW_RESOURCE_FUNCTION_BODY(call) \
   { return resource_ptr<Resource, true>( new Resource##call, resource_ptr<Resource, true>::bind_reference ); }

// Defines: template<class Resource> inline resource_ptr<Resource, true> new_resource(...)
LEAN_VARIADIC_PERFECT_FORWARDING_T(LEAN_NEW_RESOURCE_FUNCTION_DECL, LEAN_NEW_RESOURCE_FUNCTION_TPARAMS, LEAN_NOTHING, LEAN_NEW_RESOURCE_FUNCTION_BODY)

Darum liebe ich Visual C++. Wer wissen möchte, welches Grauen sich dahinter verbirgt, klicke hier. Die neue Ressourcenerzeugungssyntax ist damit:

Code: Alles auswählen

new_resource<ResourceType>(arg1, arg2, ...)

[CodingCat]

Dieser ganze C++-Text-Include-Schlamassel ärgert mich inzwischen so sehr, dass ich ernsthaft darüber nachdenke, einen Precompiler zu schreiben, der mir nur noch die Größe privater, vollständig opaker (vorwärtsdeklarierter) verschachtelter Member-Strukturen (entsprechend deren Definition in den Übersetzungsheiten) automatisch in den zugehörigen Headers aktualisiert, und mich so endgültig von gigantischen, für den Nutzer des jeweiligen Moduls vollkommen irrelevanten Abhängigkeitsketten befreit. Das ganze sähe etwa so aus:

Code: Alles auswählen

// Header
class SomeModule : public nonassignable
{
public:
   struct Members;

   SomeModule(...);
   SomeModule(const SomeModule&);
   ~SomeModule();

   // ... Public interface ...
   void someMethod();

private:
   forward_val<Members, 24> m;
};

// Compilation Unit
struct SomeModule::Members
{
   // ... Private members' definitions ...
};

SomeModule::SomeModule(args ...)
   : m(args ...)
{
}

SomeModule::SomeModule(const SomeModule &right)
   : m(right.m)
{
}

SomeModule::~SomeModule()
{
}

void somePrivateMethod(SomeModule::Members &m)
{
   m->someValue = doSthPrivate();
}

void SomeModule::someMethod()
{
   somePrivateMethod(m);
   m->someOtherValue = doSth();
}

Sollte die im Header angegebene Größe nicht mit der tatsächlichen Größe von Members übereinstimmen, so kann der jeweilige C++-Compiler dazu gebracht werden, eine entsprechende Fehlermeldung auszugeben, die die tatsächliche Größe für eine automatische Korrektur enthält.

Die Vorteile liegen auf der Hand:

• Die Headers enthalten bis auf die automatisch aktualisierte (und selten veränderte) Größe nur die öffentliche Schnittstelle.
  (Im Rahmen der Speicherverwaltung ist die Größe eigentlich auch Teil der öffentlichen Schnittstelle, das Problem ist, dass die genaue Größe in C++ in so vielen Fällen nicht spezifiziert ist, was eine automatische (Compiler-abhängige!) Aktualisierung zwingend notwendig macht.)

• Keine privaten Abhängigkeiten, die unkontrollierbar in Nutzermodule hineingeschleppt werden.

• Keine Speicherindirektion/-fragmentierung.

• Private Methoden können nach Belieben in Form von freien Funktionen hinzugefügt werden.
  (Inzwischen bin ich mir sogar sicher, dass freie Funktionen immer ausreichend und klarer sind.)

• Einheitlicher Zugriff auf Members in privaten und öffentlichen Methoden, ohne dass öffentliche Methoden mit der Weiterleitung entsprechender Aufrufe in PImpl-Methoden für noch mehr Redundanz sorgen.

Natürlich ließe sich dieses Muster auch in Teilen umsetzen. Letztlich sind wir auf den ersten Blick nicht mehr allzu weit weg von objektorientierter Programmierung in C. Tatsächlich behalten wir jedoch alle wichtigen Errungenschaften von C++: Konstruktion, Destruktion und Ausnahmesicherheit. Die Lösung erlaubt sogar Stack-Allokation und in-place Komposition. Eine mögliche Implementierung für forward_val habe ich hier online.

[simbad]

Mach ich mit meinem UML-Tool.
Habe dort den Code-Generator selbst gebaut und brauche mich seitdem nicht mehr darum kümmern, welche Header hinzukommen, welche Pfade die haben, auch System-Header.
Und wenn ich Klassen von einem Paket in ein anderes transferiere störts auch keinen.

Ohne diese Möglichkeit würde ich kein großes Projekt mehr machen.

[CodingCat]

Hm, das liest sich etwas missverständlich. Hast du a) eine Header-Verwaltung oder b) einen Code-Generator für das beschriebene in-place PImpl-Muster gebaut? Mein Problem ist nämlich nicht, Abhängigkeiten zu verwalten, sondern Abhängigkeiten grundsätzlich zu vermeiden.

[simbad]

Ich weiß zwar nicht, was daran missverständlich ist.

Ich benutze ein UML-Tool.
Ich habe dafür einen Code-Generator geschrieben, der mir aus dem UML-Modell den Code generiert, was der Name Code-Generator ja eigentlich schon sagt.
Und der Code-Generator ist intelligent genug um die im Model hinterlegten Informationen auszuwerten und dann die Listen der Include-Anweisungen so zu organisieren, das es

1. immer passt.
2. Es mir egal ist wie komplex die Abhängigkeiten sind.

Das UML-Tool dient ja der Beschreibung des Systems. Es hilft daher auch bei der Identifizierung von zu komplex geratenen Modulen und was weiß ich nicht noch allem. Man dokumentiert damit eben was das System macht.
Nur lässt sich die Komplexität ja nicht reduzieren, wenn das System eben komplex ist.

Mir isses halt wurscht wie komplex das System ist, das ich kreiere. Mein Code-Generator erzeugt die Quellen/Header-Files und eben auch die Include statements. Ich muss mich also nicht über die Komplexität ärgern und kann mich der eigentlichen Aufgabe widmen.

That's all.

[CodingCat]

Eben, deshalb war es missverständlich. Du antwortest "Mach ich mit meinem UML-Tool." und beschreibst dann genau das Gegenteil von dem, was ich anstrebe. ;)

[simbad]

Ich bin offensichtlich senil. :(
Das passiert mir schon das zweite Mal. Muss mal tief in mich gehen und mal meinen Geisteszustand überprüfen.

[CodingCat]

Nein, wir haben uns nur missverstanden. Das ist ja gerade das Großartige am Web 2.0, dass sich Missverständnisse durch Interaktion klären lassen.

That's all. ;)

[simbad]

OK.
Zweiter Ansatz

Code: Alles auswählen

class CInterface {

};

class CSpeziell : public CInterface {



};


CInterface * CreateSpeziell() {
    return (new CSpeziell);
}

Nach aussen ist nur die Interface Klasse bekannt. Damit kann die spezielle implementierung beliebig komplex sein. Die Methoden im Interface sind abstract und damit braucht man auch keine Wrapper oder ähnliches. Inlines kann man wenn nötig ins interface packen.

[CodingCat]

Ja, das ist ja der klassische Ansatz. Ich mag ihn aus drei Gründen nicht: Nur dynamische Allokation auf einem festgeschriebenen Heap, somit weder automatische Lebensdauer noch Speicherlokalität (betrifft Stack-Allokation und Komposition). Jeder Aufruf über die öffentliche Schnittstelle ist ein virtueller Aufruf, emittiert also überflüssigen Code und schränkt die Möglichkeiten der Optimierung durch den Compiler ein. Sinnvolle Vererbungshierarchien werden unmöglich (betrifft im Optimalfall nur einen Bruchteil aller Klassen).

Das, was meinem oben beschriebenen Ansatz am nächsten kommt, ist das Standard-PImpl-Muster. Dieses lässt sich problemlos soweit anpassen, dass es abgesehen von der Speicherlokalität alle im Eingangspost genannten Anforderungen und Muster erfüllt.

[Schrompf]

Bestimme die notwendige Bitbreite eines Integers, wenn Du Minimal- und Maximalwert gegeben hast. Das ist eine permanente Gratwanderung, man steht immer mit einem Bein im Overflow. Und log() und Konsorten verbieten sich eh, weil auch die Genauigkeit eines doubles nicht den Bereich eines 64bit-Integers abdeckt.

Nuja, man soll sich nicht beschweren. Ich hab wieder einiges über Fallstricke der Computermathematik gelernt.

[dot]

http://msdn.microsoft.com/en-us/library/fbxyd7zd.aspx ;)

[Lynxeye]

Code: Alles auswählen

63 - __builtin_clz(max | 1)

[Schrompf]

Jaja, lasst mich doch in Ruhe... :-) Hier heißt es halt jetzt:

Code: Alles auswählen

    size_t exponent = 0;
    while( (1ull << exponent) <= diff )
      ++exponent;

Gleich der nächste Spaß. Das schreibt sich das werte Konsortium auf die Flaggen, gut für große Datenmengen geeignet zu sein. Immerhin seien ja schon Punktwolken von 10GB Größe aufgetreten! Oho! Schön, dass sie dann ihr Binärformat so kleinteilig auslegen, dass man zwei drei ineinandergestapelte Stream-Klassen braucht, um mal plain Daten rauslesen zu können. Es gibt pro File einen Header, in dem die Filepos des XML-Teils drinsteht. Natürlich am Ende des Files. Also der erste Hüpfer. Dann unterbrechen sie die Daten alle 1020 Byte für eine 4Byte-CRC. Man kann den Platten heutzutage ja auch nicht trauen! Auftritt erste Stream-Klasse. Wir parsen den XML-Teil und bekommen pro Scan oder Bild einen Verweis auf eine Binary Section. Sprung zurück an den Anfang des Files. Wer jetzt aber schon Daten erwartet, denkt zu einfach. Wir machen einen Header pro Binary Section auf. Dort drin verweisen wir auf ein Root Level Index Package, dass mehrere Chunks verwaltet und auf Sub Level Index Packages verweist, worin dann File Offsets von Data Packages stehen, in denen die Daten enthalten sind, aber nie mehr als 64kb auf einmal. Und alle Packages dürfen in beliebiger Reihenfolge auftreten.

Wer auch immer 10GB Daten verwalten will, erbricht an dieser Stelle herzlich auf den Boden und schreibt sein eigenes Format. Dagegen nimmt sich dieses ganze "Meta-Sprache mit XML bauen"-Gedöns mit seinen Typdefinitionen und Indirektionen wie ein erlässliches Übel aus - ist ja auch heutzutage üblich geworden. Niemand speichert mehr seine Daten direkt in XML-Strukturen, wenn er was auf sich hält. Das ganze Format stinkt nach einem Konsortium "jung-gebliebener" 50jähriger Ingenieure ohne Hobby.

[kimmi]

Was ist eigentlich aus den schönen bBinärformaten geworden .... . Beziehen sich die Größen eigentlich auf die Filegrößen oder auf die tatsächliche Anzahl vorhandener Punkte? Mehr als 1000 braucht man da wohl kaum, um 10 GB groß zu werden :).

Gruß Kimmi

[Krishty]

1>------ Build started: Project: XXX, Configuration: Debug x64 ------
1>XXX.vcxproj : error MSB4014: The build stopped unexpectedly because of an internal failure.
1>XXX.vcxproj : error MSB4014: Microsoft.Build.Exceptions.BuildAbortedException: Build was canceled. MSBuild.exe could not be launched as a child node as it could not be found at the location "C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe". If necessary, specify the correct location in the BuildParameters, or with the MSBUILD_EXE_PATH environment variable.
1>XXX.vcxproj : error MSB4014: at Microsoft.Build.BackEnd.NodeManager.AttemptCreateNode(INodeProvider nodeProvider, NodeConfiguration nodeConfiguration)
1>XXX.vcxproj : error MSB4014: at Microsoft.Build.BackEnd.NodeManager.CreateNode(NodeConfiguration configuration, NodeAffinity nodeAffinity)
1>XXX.vcxproj : error MSB4014: at Microsoft.Build.Execution.BuildManager.PerformSchedulingActions(IEnumerable`1 responses)
1>XXX.vcxproj : error MSB4014: at Microsoft.Build.Execution.BuildManager.HandleNewRequest(Int32 node, BuildRequestBlocker blocker)
1>XXX.vcxproj : error MSB4014: at Microsoft.Build.Execution.BuildManager.IssueRequestToScheduler(BuildSubmission submission, Boolean allowMainThreadBuild, BuildRequestBlocker blocker)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Was ist das für eine Welt, in der mein Compiler nicht mehr funktioniert, wenn ich nach Windows-Updates nicht neustarten will

————

Bestimme die notwendige Bitbreite eines Integers, wenn Du Minimal- und Maximalwert gegeben hast. Das ist eine permanente Gratwanderung, man steht immer mit einem Bein im Overflow. Und log() und Konsorten verbieten sich eh, weil auch die Genauigkeit eines doubles nicht den Bereich eines 64bit-Integers abdeckt.

Hach; als ich das vor ein paar Jahren mal gemacht habe, hat es mich auch angekotzt. Allein, wie der Wertebereich nach der Division von [10, 12] durch [2, 3] aufgefächert ist, ließ sich kaum noch lesbar in Templates beziffern. Dazu kam, dass viele for-Schleifenzähler einen Zombie-State brauchten, um festzustellen, wann sie abzubrechen haben.

Ich will einfach nur fähige statische Analyse.

————

Und jedes Mal, wenn ich das Katzenjammern über öffentliche Schnittstellen lese, wünsche ich, ich hätte Zeit, weiter an meiner Programmiersprache zu werkeln. Aber andererseits ist das eh alles für’n Arsch bevor ich ausreichend Programmiererfahrung habe.

We're counting the stars; we're counting the stars; we're not very far …

[CodingCat]

Undo-Stacks sind aus Sicht der automatisieren Ressourcenverwaltung eine Katastrophe. Da sie in der Regel vor allem anderen konstruiert werden, verschwinden sie auch als letztes. Tatsächlich werden sie jedoch erst nach Erzeugung der übrigen Ressourcen mit massig Referenzen auf dieselben gefüllt, welche am Ende gefälligst alle noch vor den Ressourcen zu verschwinden haben.

[CodingCat]

Zurück in Qt. Die Model-View-Architektur für Hierarchien ist wirklich gotterbärmlich. Man könnte meinen, bei Qt/Nokia brüteten alleine 3 Mitarbeiter den ganzen Tag darüber, wie sie die Inkonsistenz durch gezielte Vergrößerung des Zustandsraumes weiter maximiert bekämen.

Konkret: Jedes Modell muss eine parent()-Methode überschreiben, die nur anhand des gegebenen Kindindex den Elternindex richtig erraten muss. Ist ja nicht so, dass diese Information überall implizit gespeichert wäre. Jetzt soll ich ernsthaft ein weiteres "View-"Parallelmodell aufbauen und aktuell halten, nur weil die Säcke zu faul waren, das Elternelement aus ihren eigenen versumpften Zustandsuniversen herauszufischen?

You Pinstripe barbarians, I’ll sue the council for every penny it's got! I’ll have you hung and drawn and quartered…a - and whipped and boiled… and then I’ll chop you up to little bits! Until… until... until you’ve had enough! And Then I’ll do it some more. And when I’ve finished I’ll take all the little bits and I’ll… I’ll - I’ll jump on them! And I’ll carry on jumping on them until I get blisters... or I can think of something even more unpleasant to do and then I’ll ...

[CodingCat]

Use a map!

[eXile]

first at all it is an academic paper... what we have seen is that it was never ever able
to produce high quality trees for 1mio polygons in 10ms. it was more in the range
of 100ms. and that is not that bad.

I guess you are right. If it sounds too good to be true it probably is too good to be true. It would also explain why NVIDIA never released the "Simpler and Faster HLBVH with work queues" code or the earlier hlbvh code.

So far for the reproducibility of academic work ... Kindoff strange NVIDIA published this in the first place.

Akademische Paper enthalten nie Fehler und morgen ist Ostern.

[CodingCat]

Noch nicht genug Compiler-Bugs? Bitte sehr! :evil:

Code: Alles auswählen

int& some_global_int()
{
	static int num;
	return num;
}

template <class Type>
int fun(int &i = some_global_int()) { return 6; }

template <>
int fun<int>(int &i) { return 2; }

template <>
int fun<float>(int &i) { return 3; }

int main()
{
	fun<int>();
	fun<float>(); // error C2440: 'default argument' : cannot convert from 'int *' to 'int &'
}

(Tritt auf, sobald zwei verschiedene Spezialisierungen von fun instanziiert werden.)

(Ja, instanziiert!)

(Ja, mit Zeigern geht es.)

[Krishty]

Schonmal zwei unterschiedliche cpp-Dateien gleichen Namens in einem Visual C++-Projekt gehabt?

[eXile]

Schonmal zwei unterschiedliche cpp-Dateien gleichen Namens in einem Visual C++-Projekt gehabt?

Nein. Da ich gerade zu faul zum Testen bin, meine Hypothese: Das bringt den Abhängigkeitenverwalter von MSBuild durcheinander und er kompiliert nur eine von beiden Dateien? Der Linker rotzt einen mit „warning LNK4042: object specified more than once; extras ignored“ an.

Ich rege mich gerade über etwas auf, was meiner Meinung nach eine der schlechtesten Ideen der letzten 10 Jahre war. thumbs.db-Dateien. Nachdem nunmehr die letzte Windows-XP-Maschine hier abgeschafft wurde, habe ich in einer Reinigungsaktion alle diese Dateien entfernt. Sogar auf einer Treiber-CD habe ich welche gefunden! Und das NVIDIA Graphics SDK installiert auch gleich zwei mit!

Jetzt darf ich meine Datenträger nie wieder an ein Windows-XP-System anschließen. Ist ja wie eine Infektion.

[CodingCat]

Schonmal zwei unterschiedliche cpp-Dateien gleichen Namens in einem Visual C++-Projekt gehabt?

Ja, jedes Mal wieder ein Erlebnis. In den meisten Fällen hilft es, in den Property Pages unter C/C++ / Output Files die Eigenschaften ASM List Location, Object File Name und XML Documentation File Name auf $(IntDir)%(RelativeDir) umzustellen. :-/

Und nein, das Problem ist wohl nicht MS Build, sondern einfach die verfehlte Standardkonfiguration. (Richtig solide, so dass es für ALLE Projekte funktioniert, kriegt man es meines Wissens gar nicht, weil %(RelativeDir), wie der Name schon sagt, auch absolute Pfade annehmen kann.)