3. Problem mit fopen()

Problem mit fopen()

  • D

    nimm doch einfach fstream:

    fstream x("bla", ios::in);
x.close();
x.open ("bla", ios::out);
x.close();
x.open ("bla", ios::in|ios::out|ios::binary);
    0
  • C

    OK, ok, ich kann ja immer noch später wechseln, aber jetzt soll erstmal das laufen.
    Ich seh in der C++-Lösung für mich halt im Gegensatz zu anderen nützlichen Templates wie die STL-Container keine Vorteile.

    ChrisM

    0
  • D

    Original erstellt von ChrisM:
    **
    Ich will nur, dass mein fopen() mit "t" geht... 🙂
    **

    wenn in der anleitung steht, es geht, ist's vielleicht ein fehler in der lib an sich? update?

    0
  • D

    schon mal von RAII gehört?

    0
  • C

    @davie: Ist VC 6.0 Standard. Kann da echt ein Fehler in der Standardbibliothek drin sein, bei so einer uralten Funktion, die ja schon seit VC 1.0 wahrscheinlich dabei ist?

    ChrisM

    0
  • D

    mal shcnell mit dem gcc getestet:

    //Test 1:
FILE *bar = fopen("test.txt", "tw");
bar == 0

//Test 2:
FILE *bar = fopen("test.txt", "wt");
bar != 0

    😃

    0
  • C

    Jetzt gehts bei mir auch 😃

    Können die sowas net in die Doku schreiben?

    In addition to the above values, the following characters can be included in mode to specify the translation mode for newline characters (MSDN unter fopen())

    "Included" heißt für mich, entweder vorne oder hintendran!

    ChrisM

    0
  • C

    PS: Hab ich vergessen: Danke! 🙂

    0
  • S

    es mag dich überaschen, aber es gibt kein 't'

    t ist immer default mäeßig an - dh wenn du explizit die datei als binary behandeln willst, dann musst du b als 2. oder 3. Zeichen des zweiten parameters angeben. (sollte dieser parameter nur aus 2 zeichen bestehen, dann muss b natürlich das zweite zeichen sein)

    kleiner Tipp an alle:
    Die MSDN ist gut, wenn man etwas über Microsoft Produkte wissen will, aber wenns um C++ geht, dann vertraue ich lieber auf etwas echtes.

    PS:
    sorry, aber warum willst du nicht C++ programmieren?
    fstream ist so mächtig - da würde ich mich nie mit FILE* rumschlagen!!

    kann es sein, dass du lern-faul bist?

    0
  • C

    kann es sein, dass du lern-faul bist?

    Gut möglich. 😃

    Ist bei STLPort auch eine neue Version von fstream dabei?

    ChrisM

    0
  • R

    Original erstellt von ChrisM:
    Ich seh in der C++-Lösung für mich halt im Gegensatz zu anderen nützlichen Templates wie die STL-Container keine Vorteile.

    hast natürlich recht, C Filehandling ist eh viel besser

    hier ein paar Beispiele, die dies schön zeigen

    class foo
{
  friend std::ostream &operator<<(std::ostream&,const foo&);
//...
};

void bar(std::ostream &out) {
  foo baz(/*...*/);
  //...
  out << baz << endl;
  //...
}

    das lässt sich natürlich eben so leicht mit C Filehandling darstellen 😉

    oder ein weiteres schönes Beispiel

    template<class T> void foo(std::ostream &out,const T¶m)
{
  out << param << endl;
}

    das ist natürlich auch ganz leicht mit C Filehandling 😉

    0
  • M

    Wie einigen bereits bekannt ist, HASSE ich ja I/O. Wie war das noch? Man sollte keine fstreams als Member haben, oder so (hab ich ma gehört, hatte auch Probleme mit irgendsowas). Ich gehöre außerdem zu der Spezies, die möglichst nur bool? getline(istream&,string&) verwenden. Da ist ChrisM's anti-iostream Einstellung doch irgendwo verständlich. Für binäre Dateien is aber eh open(), creat(), close(), read(), write() am coolsten 😉

    EDIT: nein, memory mapping rulet

    [ Dieser Beitrag wurde am 26.04.2003 um 14:41 Uhr von Mr. N editiert. ]

    0
  • V

    Wie war das noch? Man sollte keine fstreams als Member haben, oder so (hab ich ma gehört, hatte auch Probleme mit irgendsowas).

    ist mir neu. begründe mal.

    bool?

    istream

    0
  • M

    @volkard: zum ersten Punkt: habs vergessen
    zum zweiten: ah. erscheint logisch aber trotzdem sinnlos (wer macht schon getline(cin, s) >> i;?)

    0
  • D

    1. Weil fstreams sich nicht kopieren lassen. Für Volkard ist das, wenn ich mich richtig erinnere, natürlich kein Grund, weil seine Klassen sich idR auch nicht kopieren lassen.

    2. Ist aber nicht logisch, ist sogar falsch, weil 'basic_istream<charT,traits>&' richtig ist.

    0
  • R

    @Daniel E.
    dann schreibt man einen nicht trivialen cctor und schon kann man kopieren

    class foo
{
  std::ofstream bar;
public:
  foo(const char *x) : bar(x) { }
  foo(const foo &obj)
   : bar(obj.bar.rdbuf())
  { }
};
    0
  • D

    Original erstellt von kingruedi:
    dann schreibt man einen nicht trivialen cctor und schon kann man kopieren

    Dein Code ist so verdammt nichttrivial, dass nicht mal meine anwesende Compilersammlung ihn versteht.

    Dateideskriptoren geben (mir?) logisch keinerlei sinnvolle Kopiersemantik vor. Was soll man drunter verstehen? Schreiben 2 'kopierte' Dateihandler in die gleiche Datei? Schreibt erst mal Handler1, dann kommt Handler2 und macht alles wieder platt? [Bisher arbeite ich sowieso noch auf einer Datei; wieso sollte man das auf Programmiersprachenebene trennen?] Das Konzept 'copy' aka 'cp', dass man auf Dateiebene hat, macht etwas anderes, es vergibt einen neuen Namen.

    0
  • N

    Original erstellt von Mr. N:
    Man sollte keine fstreams als Member haben, oder so

    Und was spricht gegen eine Referenz auf einen fstream?

    [ Dieser Beitrag wurde am 27.04.2003 um 00:20 Uhr von nman editiert. ]

    0
  • V

    ein ding, das sinnvollerweise nen fstream als member hat, läßt sich sinnvollerweise auch nicht kopieren. sehe da kein problem.

    0
Anmelden zum Antworten