Beiträge von Plantschkuh!

    Zitat von \LaTeX

    Also auf der einen Seite [Zwei Additionen und ein Derefenzieren] und auf der anderen Seite [3 Multiplikationen und zwei Additionen].


    Naja, zwei Additionen und nix ist unoptimiert sicher billiger als zwei Additionen und irgendwas... Und den Speicherzugriff hast du bei beiden Varianten dabei.

    Zitat von jeuneS2

    in der internen Darstellung der meisten Compiler ist a[i] das gleiche wie *(a+i) - sofern die Elemente des Arrays die Größe 1 haben, versteht sich.


    Mehr noch: Laut C-Standard sind a[i] und *(a+i) völlig äquivalent. Das geht sogar so weit, daß man statt array[index] genauso auch index[array] schreiben darf, da die Addition ja kommutativ ist...
    Und die Größe der Array-Elemente ist unerheblich, da Zeiger-Offsets immer automatisch in Elementen, nicht in Bytes ö.ä. gezählt werden.

    Hab jetzt auf der Basis von deinem mal das zusammengezimmert:


    Sollte funktionieren, solang nirgends #ifdef KACK in einem Kommentar oder String vorkommt und #ifdef KACKs nicht geschachtelt sind. Du mußt nur in der Zeile "ifkack #ifdef\ +__cplusplus" das __cplusplus durch den Namen deines Makros ersetzen.
    Und ja, die Regel für #else war in meiner ersten Version redundant, sollte nur andeuten, daß ein #else explizit nicht ausgegeben werden soll.
    \n steht für ein Newline (Zeilenende), . für ein beliebiges Zeichen außer Newline. D.h. alle Zeichen, die nicht Teil von einem #ifdef oder sowas sind, sollen ausgegeben werden, wenn der flag 0 ist.

    Und schließlich: http://www.eskimo.com/~scs/C-faq/q10.18.html

    Zu Perl äußer ich mich nicht, aber hier ist eine potentielle primitive Lösung mit lex (ja, die erste Zeile gehört eingerückt):


    Usage:

    Code
    lex foo.l && gcc lex.yy.c -lfl && ./a.out < input.c > output.c


    wobei foo.l obiger Lex-Source ist und input.c das zu transformierende Programm.

    Edit: Das tut jetzt übrigens alle #ifs und #ifdefs raus. Falls nur #ifdef für bestimmte Makros gemeint war, dann wirds bissi komplizierter.

    Es ist völlig legitim, x nicht mit malloc, sondern mit dem Adreßoperator & zu initialisieren, solang das Objekt, auf das x zeigt, eine hinreichend lange Lebensdauer besitzt (wenn es global ist, dann ist das der Fall, denn globale Objekte leben über das ganze Programm).
    Dann mußt du x nicht gesondert freigeben.

    Iteratoren gehen sehr wohl mit maps. Für ein map<Key, T> liefert der Iterator den Elementtyp pair<const Key, T>, du kannst also alle Paare durchlaufen.
    Oder meinst du mit "die Iteratoren durchzulaufen geht ja nicht", daß das für deine Problemstellung nichts bringt? Das könnte sein, dann wäre es allerdings interessant zu wissen, was der Zusammenhang zwischen deinen maps und dem Ausgabefile ist.

    Wenn sich der gcc unter DOS gleich verhält wie unter Unix (was ich stark annehme), dann brauchst du nicht nur -L, sondern auch -l.
    -L gibt an, wo nach Libraries gesucht werden soll, aber *welche* Libraries du wirklich verwenden willst, mußt du auch noch extra mit -l angeben. Also wenn dein File libfoo.a heißt, dann tu noch -lfoo dazu. Wenn der Name des Files nicht wie übrlich mit lib anfängt, brauchst du noch irgendeinen zusätzlichen Flag.

    Mit \enlargethispage sehe ich keinen Effekt auf die Fontgröße...
    Es geht aber mit:

    Code
    \fontsize{12.5pt}{14pt}\selectfont

    , dafür muß man entweder mit \DeclareFontShape rumtun oder bindet einfach das Package type1cm ein. Das erste Argument von \fontsize ist die Fontgröße, das zweite die baseline skip, also der Abstand zwischen den Grundlinien aufeinanderfolgender Zeilen. Damit muß man wohl bissi spielen, damit es gescheit ausschaut.
    Und das ganze stellt nur den "normalen" Font um, nicht die Überschriften und ähnliches, aber bei so geringfügigen Änderungen (0.5 oder 1 Punkt) kann man die wohl auch gleich lassen, und es paßt noch immer visuell.

    Zitat von sommeralex

    meinapfel = (struct a*)malloc(sizeof(apfel));


    Jetzt (bevor du dir was unnötiges antrainierst) ist übrigens auch die richtige Zeit, dir gleich das casten abzugewöhnen. Die Funktion malloc gibt einen (void *) zurück, in C wird dieser anstandslos automatisch in alle anderen Objektpointertypen umgewandelt.
    Der einzige Grund, malloc zu casten, ist, wenn du vorhast, deinen C-Code auch irgendwann mit einem C++-Compiler zu compilieren. Was wohl nur selten der Fall ist.
    Man kann auch den sizeof-Ausdruck ändern, sodaß er unabhängig vom Typ ist: sizeof *meinapfel (d.h. die Größe des Objekts, auf das meinapfel zeigt).
    Insgesamt ergibt sich das Muster

    Code
    var = malloc(n * sizeof *var);


    für einen passenden Variablennamen und ein passendes n; das finden viele Leute elegant und hübsch und relativ robust gegenüber Fehlern.

    Hoi! Ein Bruder von mir schreibt gerade seine Diplomarbeit in Latex (bzw. ist gerade fertig und macht jetzt das Schlußlayout). Jetzt hat er sich in den Kopf gesetzt, daß er das ganze gerne nicht in einer Fontgröße von 12 pt haben möchte, sondern in 12.5 oder eventuell 13 pt. Frage: Wie kriegt man das hin?
    In plain Tex gibt es ja \magnification, mit dem das vielleicht gehen würde, aber mein Latex frißt das nicht. Vorschläge? Wäre sehr dankbar.

    Das ist jetzt nicht konkret auf deine Frage bezogen, aber http://www.eskimo.com/~scs/C-faq/top.html ist recht interessant. Und falls du deinem Buch nicht so ganz traust oder es mit einem anderen ergänzen willst: http://users.powernet.co.uk/eton/clc/cbooks.html

    Zu deinem Code: Es ist nicht gerade hilfreich, wenn du unkompilierbaren Code postest. Etwas wie struct object p {...}; kann es in C zum Beispiel nicht geben. Du meinst vielleicht

    Code
    struct object /* Definition des Typs "struct object" */
    {
        ...
    };
    
    
    struct object p; /* Deklaration des Objekts p vom obigen Typ */


    oder gleich zusammengezogen

    Code
    struct object
    {
        ...
    } p; /* Typdefinition und Deklaration eines Objekts dieses Typs */

    Und zu deiner Frage: Deklarationen sind sowohl außerhalb von Funktionen als auch zu Beginn jedes Blocks erlaubt. Zuweisungen und sonstige Statements sind nur innerhalb von Funktionen erlaubt.

    Eine nackte Deklaration außerhalb einer Funktion deklariert ein Objekt, das über die gesamte Laufzeit des Programms exisitert. Werden solche file-scope-Variablen nicht explizit initialisiert, so initialisiert sie der Compiler mit 0 (vom richtigen Typ, also 0 oder '\0' oder 0.0 oder NULL). Explizit dürfen sie nur mit bestimmten Arten von konstanten Ausdrücken initialisiert werden, deren Wert der Compiler zur Übersetzungszeit berechnen kann.
    Nackte Deklarationen innerhalb von Funktionen deklarieren Variablen, die am Beginn des Blocks erzeugt und am Ende des Blocks zerstört werden. Diese werden nicht implizit initialisiert, explizit dürfen sie auch mit nichtkonstanten Ausdrücken initialisiert werden.

    D.h.

    Code
    int i = 3; /* Deklaration mit konstanter Initialisierung */


    ist sowohl innerhalb als außerhalb von Funktionen erlaubt.

    Code
    int i; /* Deklaration */
    i = 3; /* Zuweisung */


    sowie

    Code
    int i = 3; /* Deklaration mit konstanter Initialisierung */
    int j = i; /* Deklaration mit nichtkonstanter Initialisierung */


    sind nur innerhalb einer Funktion erlaubt.


    Du versuchst hier, die Adresse einer lokalen ("automatischen" im C-Speak) Variable zurückzugeben. Das ist nicht erlaubt, da das Objekt "neu" am Ende seiner Lebensdauer, hier am Ende der Funktion, zerstört wird. Der Zeiger auf das zerstörte Objekt ist somit ungültig.
    Die richtige Deklaration der Funktion ist übrigens struct angestellter *funktionsname(parameter), also ohne "neu".


    Das geht so, ja. Allerdings kriegst du damit auch keinen Pointer auf ein Objekt, das länger lebt. Wenn du aus Funktion F mit dieser Funktion einen neuen Angestellten erzeugen läßt, lebt dieser auch (höchstens) bis ans Ende von Funktion F.

    Für Objekte, die über Funktionsaufrufe hinaus leben sollen, gibt es nur static (aber nur, wenn man sich sicher ist, was es tut und wieso man das haben will) oder malloc und Konsorten (realloc/calloc).

    char to int kann folgendes heißen:

    • Zwischen einer (!) Dezimaliffer und der dazugehörigen Zahl soll konvertiert werden, also '0' <-> 0, ..., '9' <-> 9. (Dafür einfach '0' addieren oder subtrahieren.)
    • Zwischen einem String (!), der eine Zahl in dezimaler (oder sonstiger) Darstellung codiert, soll konvertiert werden, also etwa "123" <-> 123. (Für die eine Richtung gibt es sprintf und Freunde, für die andere strtol und Freunde.)
    • Zwischen einem Zeichen und dem (ASCII-)Zeichencode dieses Zeichens soll umgewandelt werden, z.B. '0' <-> 48. (Dafür gibt es einfache Zuweisungen.)


    Eventuell lassen sich auch andere plausible Interpretationen von "char to int" finden. Ist deine gewünschte dabei? Falls nicht, bitte näher und mit Beispielen erläutern.

    Edit: OK, es ist also offenbar der zweite Punkt gemeint. Nimm die erwähnten Bibliotheksfunktionen; itoa ist nicht Standard und wird nicht auf allen Plattformen zur Verfügung stehen.

    Du könntest die Funktion filter verwenden:

    Code
    qsort [] = []
    qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x
        where
            elts_lt_x = filter (< x) xs
            elts_greq_x = filter (>= x) xs


    Allerdings gilt das vielleicht als geschummelt, da filter üblicherweise wiederum über list comprehensions definiert ist. Falls dem so ist, dann ersetze es durch eine selbstgeschriebene Funktion myfilter, die nicht mit list comprehensions, sondern rekursiv arbeitet.

    Und noch ein total arrogant herablassender Tip: Wenn du für Schule/Uni/sonstwas Haskell lernen sollst, dann lerne Haskell. Wenn du es nicht lernen sollst, aber trotzdem Probleme damit lösen sollst, dann sag deinem Lehrer/Professor/sonstwas, daß du mit dieser Art von Aufgabenstellung nicht einverstanden bist.

    Es gibt ein Package namens ulem mit einem Befehl \sout fürs Durchstreichen, das hat mal für mich ganz gut funktioniert. Weiß nicht, wie es sich mit dem Mathe-Modus verträgt.
    Du könntest auch einfach \not m probieren, aber der Strich ist meistens nicht optimal plaziert.