Dateiinhalte vergleichen

In C++ gibt es zum Glück vorgefertigte Algorithmen die das für einen 
machen:

1

#include <iterator>

2

#include <fstream>

3

#include <algorithm>

4

5

int main () {

6

  std::ifstream i1 ("test1.txt");

7

  std::ifstream i2 ("test2.txt");

8

  std::ofstream o ("test3.txt");

9

10

  std::transform (std::istream_iterator<char> (i1),

11

          std::istream_iterator<char> (),

12

          std::istream_iterator<char> (i2),

13

          std::ostream_iterator<char> (o), [](char a, char b) { return b-a; });

14

}

Korrektur, so ist besser:

1

#include <iterator>

2

#include <fstream>

3

#include <algorithm>

4

5

int main () {

6

  std::ifstream i1 ("test1.txt");

7

  std::ifstream i2 ("test2.txt");

8

  std::ofstream o ("test3.txt");

9

10

  std::transform (std::istreambuf_iterator<char> (i1),

11

          std::istreambuf_iterator<char> (),

12

          std::istreambuf_iterator<char> (i2),

13

          std::ostreambuf_iterator<char> (o), [](char a, char b) { return b-a; });

14

}

Ist von den C++ Heinis eigentlich noch keiner auf die Idee gekommen, den 
ganzen ++ Sprachsumpf mal zu entschlacken? Das sah vorher ja schon so 
geschwätzig aus wie Pascal. So wäre es schon lesbarer:

1

let std::

2

{

3

  int main () {

4

    ifstream i1("test1.txt");

5

    ifstream i2("test2.txt");

6

    ofstream o("test3.txt");

7

8

    transform (istreambuf_iterator<char> (i1),

9

          istreambuf_iterator<char> (),

10

          istreambuf_iterator<char> (i2),

11

          ostreambuf_iterator<char> (o), [](char a, char b) {

12

            return b-a; }); }

13

}

Einen Haufen überflüssige Tastaturanschläge eliminiert!

Und Programme wie Winmerge sind nicht zulässig weil...?

Linux diff macht sowas.

C-- schrieb:
> Ist von den C++ Heinis eigentlich noch keiner auf die Idee gekommen, den
> ganzen ++ Sprachsumpf mal zu entschlacken? Das sah vorher ja schon so
> geschwätzig aus wie Pascal. So wäre es schon lesbarer:
Auf die Idee sind schon viele gekommen. Allerdings widerspricht das der 
Anforderung, erweiterbar zu sein. Prinzipiell geht das zwar:

1

#include <iterator>

2

#include <fstream>

3

#include <algorithm>

4

5

using namespace std;

6

7

int main () {

8

  ifstream i1 ("test1.txt");

9

  ifstream i2 ("test2.txt");

10

  ofstream o ("test3.txt");

11

12

  transform (istreambuf_iterator<char> (i1),

13

          istreambuf_iterator<char> (),

14

          istreambuf_iterator<char> (i2),

15

          ostreambuf_iterator<char> (o), [](char a, char b) { return b-a; });

16

}

Aber davon ist dringend abzuraten, siehe 
http://stackoverflow.com/questions/1452721 .

Da C++ erweiterbar sein soll, gibt es eben Dinge wie namespaces, damit 
es bei der Verwendung vieler Komponenten (Libraries) keine 
Überschneidungen gibt. Man muss die Dateien einzeln #include'n, weil es 
im Gegensazu zu Pascal mehr als 5 Libraries gibt und das automatische 
#include'n aller Libraries viel zu langsam wäre.
Um also eine universelle erweiterbare Sprache zu erhalten, muss man eben 
öfter mal std:: eingeben. Das ist übrigens in quasi allen neueren 
Sprachen auch so, in java muss man dinge wie "java.io." davorschreiben, 
in ruby "Net.", und sogar in C behilft man sich mit prefixen, so fangen 
zB alle Gtk-Funktionen mit "gtk_" an. Das ist der Preis, den man für 
eine universelle Sprache zahlen muss. Ist ja schön dass das in Pascal 
kürzer geht, aber dafür kann man da halt nicht so viel machen. Achja, 
und zeig doch mal ein echtes Pascal-Programm was das in so kurz kann.

Dr. Sommer schrieb:
> using namespace std;
>
> int main () {
>   ifstream i1 ("test1.txt");

> Aber davon ist dringend abzuraten

Wobei man das natürlich nicht nur mit der groben Kelle global, sondern 
auch lokal und spezifisch verwenden kann (und dann ist es, je nach 
Kontext, nicht mehr böse).

Dr. Sommer (Gast) schrieb:

C-- schrieb:
>> Ist von den C++ Heinis eigentlich noch keiner auf die Idee gekommen, den
>> ganzen ++ Sprachsumpf mal zu entschlacken? Das sah vorher ja schon so
>> geschwätzig aus wie Pascal. So wäre es schon lesbarer:

> Auf die Idee sind schon viele gekommen. Allerdings widerspricht das der
> Anforderung, erweiterbar zu sein. Prinzipiell geht das zwar:

1

#include <iterator>

2

#include <fstream>

3

#include <algorithm>

4

5

using namespace std;

6

7

int main () {

8

  ifstream i1 ("test1.txt");

9

  ifstream i2 ("test2.txt");

10

  ofstream o ("test3.txt");

11

12

  transform (istreambuf_iterator<char> (i1),

13

          istreambuf_iterator<char> (),

14

          istreambuf_iterator<char> (i2),

15

          ostreambuf_iterator<char> (o), [](char a, char b) { return b-a; });

16

}

Ja, sowas meinte ich.

> Aber davon ist dringend abzuraten, siehe
> http://stackoverflow.com/questions/1452721 .

Den Einwand verstehe ich nicht so ganz.

Lesen wir mal aus deinem Link:

"Everything works fine, you can call Blah() from Foo and Quux() from Bar 
without problems. But one day you upgrade to a new version of Foo 2.0, 
which now offers a function called Quux(). Now you've got a conflict: 
Both Foo 2.0 and Bar import Quux() into your global namespace."

Wer hindert denn den Compiler daran hierfür einfach eine Warnung 
auszuwerfen? Wenn er plötzlich mehrere Funktionen gleichen Namens 
findet, wäre es doch ein leichtes den Anwender mit einer Warnung dazu zu 
bewegen, entsprechende Funktionen EINZELN dann mit einem "std:: .." zu 
versehen und dadurch einem möglichen Konflikt aus dem Weg zu gehen.

Wo also soll das Problem sein? Warum den Quelltext unnütz aufblähen, 
wenn es gar nicht sein müsste?

Oder wie wäre es mit dieser Methode die er hier verwendet hat:
Beitrag "[C++] Array verliert Werte"

1

using std::cout;

2

using std::cin;

3

using std::endl;

4

using std::flush;

5

using std::string;

6

using std::ifstream;

7

using std::ofstream;

8

using std::istringstream;

9

using std::istream_iterator;

10

11

...

12

13

  string tmpStr;

14

  ifstream inputStream;

15

16

  if(configFile != "") {

17

    cout << "Loading configuration file " << configFile << endl;

18

    inputStream.open(configFile.c_str());

19

    do {

20

      getline(inputStream, tmpStr);

21

      cout << "line: " << tmpStr << endl;

22

23

...

Warum nicht so?


> Ist ja schön dass das in Pascal
> kürzer geht, aber dafür kann man da halt nicht so viel machen. Achja,
> und zeig doch mal ein echtes Pascal-Programm was das in so kurz kann.

Nein, ich sagte doch bereits, Pascal ist noch geschwätziger.

C-- schrieb:
> Wer hindert denn den Compiler daran hierfür einfach eine Warnung
> auszuwerfen?
Das zB:

Library A:

1

namespace LibA {

2

  void foo(int a);

3

  void bar(int a);

4

}

Library B:

1

namespace LibB {

2

  void bar(char a);

3

}

Programm:

1

using namespace LibA;

2

using namespace LibB;

3

4

int main () {

5

  bar (27);

6

}

Ist das jetzt eine Warnung? Fehler? Oder doch Absicht? Besonders spaßig 
wenn LibA::foo erst in einer späteren Version hinzukam. Das kann der 
Compiler nicht wissen. Daher "using namespace" gleich bleiben lassen.

C-- schrieb:
> Oder wie wäre es mit dieser Methode die er hier verwendet hat:
Ja, das geht. Wird auch zB in Java so gemacht.

C-- schrieb:
> Nein, ich sagte doch bereits, Pascal ist noch geschwätziger.
Uhps.

1

using namespace LibA;

2

using namespace LibB;

3

4

int main () {

5

  bar (27);

6

}

.. Compiler message: WARNING! You have used function

>>>>>> bar (27); <<<<<<

in line .. This function seems to resist in more than ONE Namespaces you 
included in your sourcecode! Please use scope Operator :: to clear this 
out!

error; no source code compiled

C-- schrieb:
> error; no source code compiled
Das ist aber schlecht, weil dann eine Menge korrekter C++ Code nicht 
mehr kompilierbar wäre.

Nach dem Tod von P. Ostrich bleibt für mich eigentlich nur noch folgende 
Frage über.

Wenn:

>datei1.txt = Inhalt. 121212021
>datei2.txt = Inhalt. 121212121
>Ergebiss:
>datei3.txt = Inhalt. 000000100

ergibt, was soll dann bei:

datei1.txt = Inhalt. 121212121
datei2.txt = Inhalt. 121212021
herauskommen?
Etwa
datei3.txt = Inhalt. 000000100
?

Nebenbei bemerkt: Ich finde es immer wieder toll, wie aus völlig 
unzureichenden "Ergüssen" -zig Zeilen Code entstehen.

Dr. Sommer (Gast) schrieb:

C-- gast schrieb:
>> Oder wie wäre es mit dieser Methode die er hier verwendet hat:

1

using std::cout;

2

using std::cin;

3

using std::endl;

4

using std::flush;

5

using std::string;

6

using std::ifstream;

7

using std::ofstream;

8

using std::istringstream;

9

using std::istream_iterator;

10

11

// ...

> Ja, das geht. Wird auch zB in Java so gemacht.

Gut. Nur warum insgesamt so umständlich wie hier etwas spezielles zu 
erlauben bzw. zu konkretisieren (mit vielen Ausnahmen) anstatt etwas 
allgemein zu erlauben (using std;) und NUR im Konfliktfall (Compiler 
Warning) explizit diese Allgemeinheit für eine bestimmte Funktion dann 
zu widerrufen und damit die Konkretisierung zu verlanden (zu erzwingen) 
Bsp. Libxy::foo(), um Zweideutigkeiten auszuschließen?

Wie oben gezeigt würden Quelltexte um einiges besser lesbar sein bei 
gleichzeitig weniger Schreibaufwand. Warum also der Zwang so umständlich 
C++ Quelltexte zu schreiben?

> Das ist aber schlecht, weil dann eine Menge korrekter C++ Code nicht
> mehr kompilierbar wäre.

Für alten Code würde sich doch gar nichts ändern. Der ist ja in der Form 
lib::function(), also eindeutig und wird nach wie vor compiliert. Neuer 
C++ Code, der vereinzelte Mehrdeutigkeiten hätte, könnte dann wie hier 
geschrieben werden

1

#include <iterator>

2

#include <fstream>

3

#include <algorithm>

4

5

using namespace std;

6

using namespace LibA;    // for void ifstream (int a)

7

8

int main () {

9

  ifstream i1 ("test1.txt");

10

  ifstream i2 ("test2.txt");

11

  ofstream o ("test3.txt");

12

13

  transform (istreambuf_iterator<char> (i1),

14

          istreambuf_iterator<char> (),

15

          istreambuf_iterator<char> (i2),

16

          ostreambuf_iterator<char> (o), [](char a, char b) { return b-a; });

17

18

19

// ..

20

21

LibA::ifstream ("a");

22

23

// ..

24

25

26

}

Beim Compilieren würde klar, es gibt mindestens eine Funktion (hier 
ifstream()), die nicht eindeutig zuzuordnen wäre. Jetzt könnte man den 
Programmierer dazu anhalten nach einem Vorrangschema nur diejenigen 
Funktionen zu konkretisieren, die von der Regel abweichen. Also z.B. 
eher spezielle Funktionen im Namespace mittels Scope zu kennzeichnen, 
wie hier

LibA::ifstream ("a");

Der Rest bleibt wie gehabt.

Ja, das funktioniert so sogar. Leider kann es so immer noch 
Überraschungen mit Overloads geben, wie im Beispiel in 
Beitrag "Re: Dateiinhalte vergleichen" wenn 
LibA::bar nachträglich hinzukam. Der Code ist korrekt und muss es auch 
bleiben (=> kein Compiler Fehler) aber dennoch wird plötzlich die 
falsche Funktion aufgerufen. Das Problem entsteht, wie im 
Stackoverflow-Artikel erklärt, wenn Funktionen nachträglich hinzukommen. 
Dann muss man allen die Libraries verwendenden Code anpassen, um die 
neuen Uneindeutigkeiten zu beseitigen - schlecht. Da lieber konsistent 
überall LibA:: davorschreiben, dann ist es eindeutig und wird es auch 
bleiben.
Das nächste Problem ist dass der "std" namespace jede Menge interne 
Bezeichner enthält. Die will man eigentlich auch nicht im globalen 
namespace haben.

Außerdem wird der Code durch explizite Namespaces sogar lesbarer. z.B.:

1

int main (int argc, char* argv []) {

2

  Gtk::Main m (&argc, &argv); // Aha, hier wird das Gtk-Main-Objekt angelegt. Gehört zur Gtk-Library.

3

}

vs.

1

using namespace Gtk;

2

/* ... viel code ... */

3

int main (int argc, char* argv []) {

4

  Main m (&argc, &argv); // Main?? Was soll das sein? Nicht lesbar.

5

}

In kurz: Mit "using namespace std;" handelt man sich nur Probleme ein. 
Und ein paar mal "std::" einzugeben ist kein Beinbruch. Das kannst du 
dir ja auf eine Schnelltaste legen wenn es gar zu schlimm ist.

Immer noch unklar!

Der Begriff "vergleichen" sagt Garnichts aus!

Die Addition von 1 und 2 ergibt 3.

Die Addition von 250 und 9 ergibt ebenfalls 9 - hoppla, wie informativ.

Sorry latürnich 3.

P. Ostrich schrieb:
> Am liebsten wäre es mir auch in C, aber C++ geht auch
>
> Aer dann werd ich mal mit dem gegebenen vesuchen was zu machen
> Dank euch allen schonmal

Die Frage hättest Du dir doch wirklich sparen können, es sei denn du 
hast auf eine komplette Lösung deiner Hausaufgabe gehofft.

"compare two files in C" liefert doch unzählige hits in google, als 
erstes

http://www.c4learn.com/c-programs/c-program-to-compare-two-textdata-files-in-c-programming.html

Da du C willst, kanst Du C oder möchtest es lernen -- dann ist es doch 
wohl nicht schwer den Code anzupassen.

Klingt wie nach Hausaufgabe. Kein normal denkender Entwickler nimmt für 
sowas C, sondern a) schon fertige tools wie diff.... oder macht das mit 
einem Einzeiler Perl oder sonstiger Scriptsprache.

Und wer da mit barok-verbloatetem  C++ ankommt sollte besser auf 
Schuhverkäufer umschulen.

Oben: "Ich verkürze mal den C++-Code" der danach genau verbloatet ist. 
Erst mal eine Tonne includes für eine Trivialaufgabe. LOL. Lasst die 
Finger von den Rechnern und schult auf Erntehelfer o.ä um.

WAs soll denn hochgezählt werden?

Und hast du auch die Kritik an dem Code gelesen und verstanden?
Beitrag "Re: Dateiinhalte vergleichen" ff.

Es geht auch um die Definition von chr1 und chr2 als int.

Meinst du eine bestimmte Position?

Dann schau dir mal fseek an: 
http://www.cplusplus.com/reference/cstdio/fseek/