Beiträge von shabby

    Zitat von dose

    Gilt eigentlich für alle...bissl Javascript können/verstehen schadet auch nicht, und ab und zu muß man billigst-Redirections "austricksen" :)

    Ich find es nur seltsam, dass man mittendrinn einmal Java decompilieren muß (passt irgendwie nicht so ins Konzept). Klar is es nicht sooo schwer, aber auf die Sache mit der relativen Adresse (bei 10) oder dem htaccess file kommt man z.b. u.U. nicht sofort drauf. Ist es eigentlich in reality schwierig ein file zu finden, wenn man kein directory listing bekommt (a'la level 8) ?

    Ich hab übrigens eine ganz nette Lösung gefunden:

    XTL wird zwar glaub ich nicht mehr wirklich maintained, dafür kann man "stream-like" in Sun's XDR bzw. GIOP CDR Format Dateien und Memory-Buffer beschreiben.
    Plattformunabhängige Serialization von allen Primitves++ und STL Strings und Containern kommt mit, eigene Routinen dürfen sowohl member als auch global sein.
    Nur für die Speicherverwaltung der char*/vector<char>-Buffer muß man nen Wrapper schreiben.

    Zitat von jjan


    Bewährte portable Bibliotheken, die dieses Problem lösen, kenne ich leider auch nicht ... die MFC stellen AFAIK diese Funktionalität zur Verfügung, aber damit bist du natürlich auf Wintel beschränkt.

    http://lists.boost.org/MailArchives/boost/msg24288.php erwähnt eben noch die CommonC++ und das etwas bessere eternity-it (das ich durchaus als Alternative zum CArchive ansehen würde). Interessanterweise wurde die Boost Serialization (nach anscheinend längerer Diskussion und Entwicklung) gestoppt.

    Zitat von jjan


    Allerdings gibt es einen Eintrag im comp.lang.c++ FAQ, der genau dieses Thema behandelt, ist recht interessant zu lesen:
    http://www.parashift.com/c++-faq-lite/serialization.html


    [Score 5, Informative]

    Eine letzte Frage sei mir verziehen:

    Zitat von 96' working draft

    The value representation of floating-point types is implementation-defined ...

    Zitat von Serial FAQ

    Note: the floating point differences are the most subtle and tricky to handle. It can be done, but you'll have to be careful with things like NaN, over- and under-flow, #bits in the mantissa or exponent, etc.


    Bedeutet das, dass ich die Repräsentation von Fließkommazahlen auf allen Systemen kennen (d.h. die Repräsentation ist maschinenabhängig) und entsprechend konvertieren muß, oder ist die Repräsentation compilerabhängig (d.h. sie muß logisch und nicht bitwise konvertiert werden) ?
    Nochmalige Entschuldigung für die absolute Irrelevanz meiner Postings (und das noch dazu in den Ferien ! - aber vor Mittag ist mir der See einfach zu kalt...)

    Danke Hal für deine Bemühungen, obwohl Sie nicht ganz das Problem adressiert haben
    (sprich: memcpy kannte ich auch)

    Das eigentliche Problem ist, dass du selbst für ein simples Serialisierungsmodul eine Menge faden Kram schreiben mußt -Zum Beispiel write und read Methoden für alle primitiven Datentypen. (char* sind zum Beispiel etwas aufwendiger, weil die Länge irgendwie mitgespeichert und beim auslesen wieder ein buffer angelegt werden muß usw. ) - und ne Menge schwierigen (STL-Container, Probleme mit Pointern ...).
    Was ich nicht unbedingt will.

    Zitat von hal
    Code
    char buffer[4711];
    float foo=42.678;
    memcpy(mycharbuffer, &foo, sizeof(foo));

    Erstens hätte ich eigentlich gerne eine komplette Klasse (mit unterstützung für STL-Container wenns geht) aus einer halbwegs populären Bibliothek (um den "reinvent the wheel" effekt zu vermeiden)

    Zweitens kann ich mir nicht vorstellen, dass nicht wenigstens schon einer sich an das leidige "primitive Datentypen in einen Buffer schreiben" Problem rangemacht hat (d.h. ich weiß, dass es wer getan hat, kanns aber nicht mehr finden).

    Drittens weiß ich nicht, ob floats die selben Plattform-Probleme haben wie z.B. ints (also LE/BE). Weiß dass jemand ??

    P.S. ist 4711 nicht die Zahl, wegen der manche Leute bei Sysprog wegen abschreibens Punkteabzug bekommen haben ;) ?

    [edit] Naja, CommonC++ geht ja vielleicht doch, aber STL wird halt nicht unterstützt, außerdem hat der Author viele unnötige häßliche Makros benützt, und endian save ist es wie schon erwähnt auch nicht (was mir ja eigentlich wurscht ist, aber es geht ums PRINZIP)

    Kann mir jemand einen Vorschlag machen, wie ich Objekte, vorallem aber die Primitives (z.B. int und double) plattformunabhängig in einen char* buffer "schreiben" bzw. "lesen" kann ??
    Hintergrund: Ich würde gern die BerkeleyDB ausprobieren, und die benutzt nun mal Paare typenloser void* Pointer.

    Ich meine also keine toString Funktion, sondern etwas in der Art von java's serialize. Mit den Standardstreams funktioniert dass glaub ich nicht.

    Manuell haben wir das ganze eh schon in SE-Linux angeschnitten, aber eigentlich muß es dass doch auch als Library geben. (Vorallem die float/double Konvertierungen stell ich mir manuell eher schwierig vor).

    Eine Library wäre also fein, aber in die Boost (ansonsten wirklich nett) ist Persistence anscheinend nicht aufgenommen worden, eternity verwaltet das Archiv selber (und gibt keine Zugriffsmöglichkeit auf den Buffer) und die GNU CommonC++ Implementation des Problems halte ich im großen und ganzen für verabscheungswür
    dig (wirklich !, außerdem schreibt der die eingebauten Datentypen über nen Cast rein, dass schaff ich selber auch).

    Der Thread ist zwar schon etwas älter, vielleicht wird der (etwas zu lang geratene) Thread ja trotzdem von jemanden gelesen ...

    Zitat von jjan

    Eben, ich wusste bis vor kurzem auch noch nicht, was FMH bedeutet, hab dann aber festgestellt, dass ich ein Spezialist darin bin ... ;))

    Function Management Header,
    Foederatio Medicorum Helveticorum oder
    Fahrrad mit Hilfsmotor ?
    Ich tipp mal auf letzeres

    Zitat von Dave2003


    und ob man etwas auf der cmd-shell löscht oder im explorer ist egal, keines greift "direkter" auf eine datei zu, beide sind gleichwertig.

    Wirklich ? Geht es auch, dass das del (unter win) auf der Kommandozeile den Umweg über den Papierkorb nimmt (um Frustration zu vermeiden) ?
    Das wäre auch unter Linux nicht uninteressant (so ein rm * kann manchmal ziehmlich schmerzen), allerdings ist es eh einfach machbar. (Nur es macht einfach keiner, weil es ja eigentlich "nicht wirklich notwendig" ist )

    Interessantere Frage: Ich greife unter Linux auf Windows FAT32-Partitionen zu, und hab da einige Probleme wegen der Case-Insenstivity (z.B. mit den autotools). Die files und verzeichnisse kann man nicht irgendwie strikt case-sensitive machen, oder ?

    nur eine Anmerkung: dein Script funktioniert leider (und das ist so ne kleine Schwäche vom Shell-Script) nicht für Dateinamen mit Leerzeichen, da <space> als field seperator für die liste benutzt wird, die ls zurückliefert.
    selber kein shell script experte, kenn ich nur die triviale lösung mit
    $> for FILE # (für alle Argumente)
    und
    $> "$FILE" # (Anführungszeichen um die Argumente)
    im Body,
    Aufruf:
    $> imgren /mydir/*

    Oder mit Perl, da isses easy:

    Perl
    #!/usr/bin/perl
    my $counter = 0; my $dir = shift;
    opendir MYDIR, "$dir" or die "Can't open directory $dir: $!\n";
    my @files = readdir MYDIR;
    foreach (@files) {
        next if "$_" eq "$counter.jpg" || -d $_  || ! /\.jpg$/;
        $counter++ while -e "$counter.jpg";
        rename "$_","$counter.jpg" or die "Couldn't rename $_: $!\n";
    }    
    closedir MYDIR;


    (auch hier gehts sicherlich schöner)

    edit: ohne blöde klammern liest es sich gleich viel freundlicher

    Irrlicht: Wenn dein Projekt 'gone open-source' ist, wäre es dann möglich mal den Source-Code anzuschauen - auf irrlicht.sourceforge.net find ich den Code nämlich nicht.
    Schreibst du die Engine alleine (ist das nicht ein bisserl mühsam ?) ?

    also C sollte in Punkto Programmiereffizienz, Debugging, Modularität und so weiter wohl für keinen eine ernsthafte Konkurrenz zu Java sein. Nachdem ich den umgekehrten Weg gegangen bin, finde ich C ziehmlich grauslich, vorallem was Speicherschutz (bei mir Segfaultet vom xmms bis hin zu rm! wirklich alles ab und zu), dynamische Datenstrukturen (generische Collections in ANSI C gehören ganz klar in die Kategorie "verbrechen an der Menschheit") und Namespaces (Alles in einem riesigen Symboltable) angeht. Außerdem liefert der Compiler viel schlechtere Fehlermeldungen. Absoluter Hassfaktor: unions.
    Als Gegenbeispiel: kann sich das ein Javaprogrammierer antun?:


    Selbst in der kleinen Funktion können schon vier Segfaults auftreten. Ganz abgesehen davon, dass man (imho) nich feststellen kann, ob eine beliebige Struktur vom Client schon initialisiert wurde (eine Abfrage gegen (void*) 0 hilft auch nichts, wenn der Pointer munter z.B. auf 0xFFFFFF (void*-1) zeigt. Außerdem gibts keine Möglichkeit festzustellen, welchen Typ ein Pointer hat.
    JA, es ist schnell, verdammt schnell, aber mir kommt vor manche von euch freuen sich, weils so eine tolle Programmiersprache ist.
    Ich weiß ja nicht, wer von euch OOP gemacht hat, aber die Beispiele von dort möchte ich in reinem C (ohne ++) nicht realisieren.
    Und C++ ist für meinen Geschmack ein bisserl zu kompliziert und auf rückwärtskompatibel getrimmt (wie so vieles).
    Java ist auf jeden Fall eine wunderschöne objektorientierte Sprache - dass es langsam ist, es keine gscheiden Graphiklibraries usw. gibt und es damit vermutlich nicht allzu praxistauglich ist, sei eine andere Geschichte.

    P.S.: Pointer braucht man nicht.Klar, sogar mit brainfuck kannst du alles programmieren. Viel wichtiger: Pointer sind ein direkter Zugriff auf den Speicher, der außerhalb des Systemnahen Programmierens nicht gerade für ein stabiles System sorgt.
    Aber: Pointer funktionieren schon ein bisserl anders als Referenzen, eben eine direkte Referenz auf den Speicher.

    Zitat

    Original geschrieben von Jimmy
    ich verwende eine Pinnacle PCTV und bin recht zufrieden damit... geht sowohl unter win also auch unter linux ohne Probleme,
    das einzige was ich da noch nicht zamgebracht hab ist unter linux nen TV Stream mit (h)asciicam als ASCII art anzuschauen das Programm will die Karte einfach nicht erkennen.. vielleicht ist jemanden was aehnliches pasisert? http://ascii.dyne.org/

    ähmm, problemlos ;) ?
    ich hab zwei monate gebraucht
    vorallem deshalb, weil die neuen PCTV karten mit dem MT universal chipsatz erst unter bttv 0.101 unterstützt wird, was vermutlich noch in keinem kernel release drinnen ist.

    frage: hattest du auch das problem mit geflippten bildern bei der aufnahme über vcr ?

    ansonsten ist die karte ganz fein, unter windows funktioniert auch alles ganz easy - 100 Euro

    Unter linux funktioniert auch als super wenn du die neue bttv Version als modul kompilierst (auch easy)