Beiträge von Ringding

  • Probleme mit Return

    sizeof liefert immer nur Konstanten, in deinem zweiten Fall (sizeof(*number)) also sizeof(float) (sofern numbers ein float* ist). Man kann in C einfach nicht die Größe eines mit malloc allozierten Blocks herausfinden.

  • funktions-prototype in c ?

    Ich versteh die Angabe gar nicht. Da ist so viel weggelassen, dass ich mir den Rest nicht zusammenreimen kann.

    Etwas komisch kommt mir die Zeile mit dem "int ..., (*snapfptr)();" vor. Wolltest du da nicht ein typdef schreiben? So erzeugst du eine globale Variable.

    sauzachn: Der C-Compiler macht aber normalerweise nur Warnings.

  • Kann man Java auf Maschinencode compilieren?

    Zitat von Plantschkuh!

    Und da wird dynamisch immer wieder neu kompiliert?


    So ist es.

    Zitat

    Pffft. Als ob man Compilern nicht sagen koennte, fuer was fuer eine CPU man kompilieren will. Ich sag nicht, dass es notwendigerweise ueblich ist, aber man muss schon Aepfel mit Aepfeln vergleichen.


    Naja, aber man braucht dann für jede CPU ein eigenes Binary. Oder man hat diesen Dispatch-Trick wie der Intel-Compiler, der aber auch nicht gratis ist. Außerdem habe ich beim GCC bisher immer feststellen müssen, dass die Optimierung auf genau meine CPU die Sache langsamer gemacht hat :o.


    Zitat

    Mit Trampolines und branch prediction sollte man diesen Effekt praktisch gratis kriegen, glaub ich. Inlining ist super, aber insbesondere, weil es je nach Aufrufkontext tolle globale Optimierungen erlaubt. Ob sich ein JIT die aber leisten kann, stell ich in Frage. (Du magst da aktuelle Literatur kennen.)


    Hotspot inlined sehr aggressiv; das macht einen Riesenunterschied. Genau, v.a. wegen der globalen Optimierungen.

    Zitat

    Welche Java-Version genau? Und hast du eh mit vergleichbaren Optimierungsflags kompiliert? Faktor 4 kann da eventuell hinkommen.

    java version "1.6.0_05"
    Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
    Java HotSpot(TM) 64-Bit Server VM (build 10.0-b19, mixed mode)

    Ja, hab schon auf die Flags geschaut. Fairerweise muss ich sagen, dass bei diesem speziellen Benchmark wahrscheinlich hauptsächlich der Memory-Allokator gefordert ist, und der ist bei Hotspot nahezu unschlagbar. Aber wieso das bei denen so viel langsamer ist als bei mir, verstehe ich trotzdem nicht.

  • Kann man Java auf Maschinencode compilieren?

    Zitat von Plantschkuh!

    Im Allgemeinen gibt es allerdings nicht viele Gruende, warum ein JIT besseren Code produzieren sollte als ein Ahead-of-time-Compiler (im Gegenteil).

    Natürlich gibt es die. Der JIT weiß, welche Codepfade wie oft durchlaufen werden und kann entsprechend optimieren (geht mit PGO für C/C++ auch, zumindest wenn das halbwegs konstant ist; ist es aber üblicherweise). Der JIT weiß, auf welcher CPU er läuft. Z.B. kann er auf einem Uniprocessor-System teure atomic instructions weglassen. Nachdem's kaum mehr Uniprocessor-System gibt, wird das zwar weniger relevant, aber maschinenspezifische Optimierung kann immer noch einiges bringen. Der JIT kann virtual function calls durch statische ersetzen (und inlinen), wenn keine Klassen geladen sind, die diese Methoden überschreiben können. Und es gibt sicher noch viele mehr. Aber vor allem das mit dem Inlining von virtuellen Funktionen ist in Java ein wesentlicher Performance-Faktor.


    Zitat

    Gibts da belastbare veroeffentlichte Messungen?

    Naja, es gibt http://shootout.alioth.debian.org/. Den Ergebnissen traue ich allerdings nicht sonderlich - hab gerade selber einen Benchmark davon ausprobiert (binary_trees), und bei mir war die Java-Version ziemlich genau doppelt so schnell wie die GCC C-Implementation. Auf der Page ist angegeben, dass die Java-Version 1.7 mal so lang braucht.

  • SQL Server 2005

    Wenn ich einen SQL Server 2005 hätte, würde ich es sogar für dich ausprobieren. Aber solange du keine Fehlermeldungen vom Server empfangen kannst, bist du soundso aufgeschmissen; also kümmere dich erstmal darum — der Rest erledigt sich dann von selbst.

  • Eingabefeld

    Oh, du hast ja eh das 6.0er, hab ich schon wieder ganz vergessen. Also ich schreib das kurz mal auf. Zum Glück hab ich noch ein 6.0er installiert zuhause... Machen wir's am besten in einem ganz frischen Projekt, dann ist es am einfachsten nachzuvollziehen.

    Ich mach also ein neues Dialog based Projekt mit dem AppWizard. Ich habe es inputtest genannt. Danach:

    • Mit dem Dialogeditor IDD_INPUTTEST_DIALOG öffnen
    • Eine Edit Control erzeugen. (IDC_EDIT1)
    • Ctrl+W
    • Auf's Class Info Tab wechseln.
    • "Add Class... | New..."
    • Für Name verwende ich "CMyEdit", als Base class CEdit. Ok.
    • ClassWizard schließen.
    • Ctrl + Doppelklick auf die Edit Control.
    • Bei Category "Control" auswählen, bei Variable type "CMyEdit". Genannt hab ich's m_myedit.
    • Dann kommt eine Meldung, dass man ein #include machen muss.
    • Also F7 drücken und in dem File, wo der Fehler kommt (inputtestDlg.h) oben #include "myedit.h" einfügen.
    • Dann in der ClassView (die Baumansicht der Klassen) auf CMyEdit rechtsklicken und "Add Windows Message Handler..." auswählen.
    • Hier kann man jetzt leicht WM_GETDLGCODE auswählen. Auf "Add and Edit" klicken.
    • So, jetzt muss nur noch das "return CEdit::OnGetDlgCode();" um ein "| DLGC_WANTALLKEYS" erweitert werden.
    • Fertig.

    Wenn du das Ding jetzt startest, den Cursor ins Eingabefeld setzt und Return drückst, wird nichts passieren, weil der Tastendruck jetzt an die Editbox geht und nicht wie normalerweise an den Ok-Button. Lustigerweise wirkt das nur bei einer einzeiligen Edit Control. Wenn man bei den Properties "Multiline" auswählt, dann wird plötzlich das "Want Return" wirksam. Warum das so komisch ist, weiß ich jetzt auch nicht. Der Spy++ ist in solchen Fällen immer ein unverzichtbares Werkzeug ;)

  • Eingabefeld

    Also entweder ich bin zu blöd dazu, oder sie haben mit VS 2003 die IDE noch mehr verkrüppelt als ich dachte. In Visual Studio 6.0 ist es recht einfach, sich das in einem MFC-Projekt so zusammenzuklicken, dass das Event an der richtigen Stelle von der richtigen Klasse gehandelt wird. Mit 2003 und Nachfolgern schaffe ich das nicht mehr...

  • Eingabefeld

    Sieht nach MFC aus. Irgendwie ging das mit Message Reflection, aber ich weiß nicht mehr genau, wie.

    Allerdings fällt mir auf, dass man bei den Properties von einem normalen Edit Control bei den Properties im Dialogeditor ein "Want Return" einstellen kann.

  • Eingabefeld

    Du musst die WndProc der Control, die diese Keys haben will, so ändern, dass sie auf WM_GETDLGCODE mit gesetztem DLGC_WANTALLKEYS antwortet. Im reinen C-API würde man das wohl so machen, dass man mit SetWindowLongPtr die Adresse der WndProc umbiegt auf eine eigene, die dann die ursprüngliche aufruft. Mit MFC geht's glaub ich irgendwie einfacher, kann mich aber nicht mehr genau erinnern, wie.

  • Rekursive RegEx?

    Wer Algorithmen und Formale Sprachen besucht hat, weiß, dass die Sprache der "wohlgeformten Klammerausdrücke" nicht regulär ist. Somit kann sie auch nicht von einer regular expression abgedeckt werden.

  • Ascii

    Relativ kompakt z.B. so

    Die Dezimalschreibweise verunschönt das ganze ein wenig, aber sowas ist nie schön ;)

    EDIT: Ah, du machst das mit C++ streams. Na das lässt sich doch sicher auch irgendwie gewinnbringend einsetzen...

  • Ascii

    Sowas ähnliches wirst du brauchen. Da bastelst du dir dann halt noch ne schöne Schleife, und fertig ist das.

    Code
    void show_ascii(int c)
{
    printf("%02x : %c\n", c, (char) c);
}

    Z.B. so: (den Rest lass ich dir als Hausaufgabe)

    Code
    int i;
    for (i=32; i<48; i++)
        show_ascii(i);


    Ergibt