bufferedWriter



  • hackglobal schrieb:

    was mache ich wenn der buffer voll ist und und die write funktion noch einmal geschrieben wird?

    Die Daten auf/in die "Sink" schreiben?

    hackglobal schrieb:

    was will der interviewer eigentlich rausfinden, wenn er dich einen bufferedwriter implementieren laesst?

    Ob der Kandidat überhaupt programmieren kann.
    Ob der Kandidat eine relativ einfache Vorgabe fehlerfrei implementieren kann.
    Ob der Kandidat von der Form her halbwegs sauberen, lesbaren Code schreiben kann.
    Ob der Kandidat dazu neigt Dinge unnötig kompliziert zu machen.
    Ob der Kandidat dazu neigt Dinge zu einfach zu machen.
    Ob der Kandidat die Standard-Library kennt und verwendet.

    Evtl. auch ob der Kandidat schlau genug gleich nachzufragen welche Art von Daten der Buffered-Writer überhaupt buffern soll, welches Interface dieser Buffered Writer zur Verfügung stellen muss, welches er vom seiner "Sink" verlangen darf/soll etc.



  • hackglobal schrieb:

    zwischen vector<char> und string ist kaum ein performance unterschied...
    memcpy jedoch improved den speed.

    Den Grossteil des memcpy -Vorteils wird nicht memcpy selbst ausmachen, sondern dass du jetzt eine "schlauere" (dafür auch kompliziertere) Kopierschleife hast.
    Statt memcpy könntest du dann vermutlich genau so gut auch std::copy oder - je nach Compiler - auch gleich eine selbstgeschriebene Schleife nehmen.



  • Die Daten auf/in die "Sink" schreiben?

    ja, die sink ist eine TCP verbindung... dh der buffer muesste fuer die zeit blockiert werden...

    kann ich eine art double buffer bauen, falls waehrend dem senden ueber tcp dei write funktion noch einmal aufgerufen wird?



  • mit std::copy wuerde das dann wie folgt aussehen?

    std::copy(str.begin()+copy_index, str.begin()+copy_index+size, buffer.begin()+buffer_index);
    

    was ist der vorteil von std::copy?



  • was ich so sehe ist memcpy schneller als std::copy! stimmt das? warum soll man dann std::copy nehmen?


  • Mod

    hackglobal schrieb:

    kann ich eine art double buffer bauen, falls waehrend dem senden ueber tcp dei write funktion noch einmal aufgerufen wird?

    Möglich ist das. Ob du das machen kannst, kannst am besten du selbst beantworten.

    hackglobal schrieb:

    was ist der vorteil von std::copy?

    Dass es keine Nachteile gegenüber memcpy hat, aber man damit ein paar Sachen machen kann, die mit memcpy nicht gehen.

    hackglobal schrieb:

    was ich so sehe ist memcpy schneller als std::copy! stimmt das? warum soll man dann std::copy nehmen?

    Wie siehst du das? Das sollte intern zu memcpy optimiert werden. Vergleichst du etwa unoptimierten Code?



  • hackglobal schrieb:

    tntnet...das war ja nur um den string auszugeben fuers debuging....

    das eigentlich flush soll ueber das netzwerk passieren...

    was mache ich wenn der buffer voll ist und und die write funktion noch einmal geschrieben wird?

    was will der interviewer eigentlich rausfinden, wenn er dich einen bufferedwriter implementieren laesst?

    Was interessiert mich ein Interviewer. Du hast eine Frage zum bufferedWriter gestellt und ich habe das kommentiert.

    Wäre ich Interviewer und würde so eine Frage stellen, dann würde ich prüfen wollen, ob einer blind einen bufferedWriter auf std::iostream (bzw. std::ostream) schreibt oder eher nachfragt. Ich will Leute haben, die mit denken.



  • hackglobal schrieb:

    Die Daten auf/in die "Sink" schreiben?

    ja, die sink ist eine TCP verbindung... dh der buffer muesste fuer die zeit blockiert werden...

    kann ich eine art double buffer bauen, falls waehrend dem senden ueber tcp dei write funktion noch einmal aufgerufen wird?

    Die Frage stellt sich schon mal nur wenn du asynchron sendest.
    Sendest du asynchron?

    Ansonsten: ja, klar kannst du double-buffering verwenden. Oder triple-buffering. Oder N-fach-buffering.
    Fragt sich nur ob es notwendig bzw. überhaupt sinnvoll ist.



  • nein, sende synchron...



  • Und wie soll dann write() aufgerufen werden während noch gesendet wird?
    Aus nem anderen Fred etwa?
    Dann fehlt da aber noch einiges...


Log in to reply