Ist dieser Code "schön"?

C++ Forumbot

Dieser Thread wurde von Moderator/in SideWinder aus dem Forum DOS und Win32-Konsole in das Forum C++ (auch C++0x) verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

HighLigerBiMBam

Das define kannst du entfernen, sowie include string und limits. Ich sehe nicht das diese in deinem Code verwendet werden.

vikenemesh

Oh danke, hatte ich noch übersehen.
Ansonsten stimmt jetzt alles?

Das mit dem Variablendeklaration so lange wie möglich hinauszögern lässt sich auch auf inchar anwenden.
und der flush war nur vonnöten, weil du die Zeile noch nicht fertig geschrieben hast. Jetzt brauchts den nicht mehr.

Bei dem Hinweis zu int count[26]={0} habe ich einen Fehler gemacht, ich hätte bei mir nämlich std::vector<int> count(26) verwendet und da ist automatisch alles auf 0. Ich habe irgendwie gedacht, das sei selbst bei POD-Arrays der Fall...

Errors könntest du auf cerr ausgeben.

Viel mehr fällt mir eigentlich nicht auf.

wx++

Der C++-Header heißt cctype

SeppJ

Das file.close(); brauchst du nicht. Der Destruktor des fstream-Objekts schließt die Datei. Nutze dies.

vikenemesh

Danke an alle.
In Zukunft werde ich die Tipps dann umsetzten.

DocShoe

Vielleicht wäre std::map<char,unsigned int> hübscher als ein rohes C-style Array. Damit musst du keinen Index mehr verbiegen und hast eine direkete Zuordnung von Buchstabe zu dessen Anzahl.

zeusosc

encourriage schrieb:

Das carriage return macht deinen Code unportabel, lass das.

?? Das ist nicht ganz richtig, geschichtlich gesehen ist der cursor bei der
ausgabe von \n nicht nach vorne gesetzt worden,..
Der carrier musste nach vorne mittels \r gesetzt werden.
Halt die pure Funktionalität der Steuerungszeichen (ASCII) ist Aufgrund von
Abwärtskompatibilität bei Konsolenanwendungen (und EXAKT bei externer perephiere) heute noch zu Gewährleisten.

Daher ist die genannte "unportabilität" eigentlich nur durch verwendung eines unvollständigen satzes an steuerzeichen vorhanden...

grüße

du könntest noch return -1; für "Nicht genug Parameter" und return -2; für "Dateifehler" machen.

Beim Parameterfehler sollte er sagen wie es richtig geht.

Shade Of Mine

zeusosc schrieb:

?? Das ist nicht ganz richtig, geschichtlich gesehen ist der cursor bei der
ausgabe von \n nicht nach vorne gesetzt worden,..
Der carrier musste nach vorne mittels \r gesetzt werden.
Halt die pure Funktionalität der Steuerungszeichen (ASCII) ist Aufgrund von
Abwärtskompatibilität bei Konsolenanwendungen (und EXAKT bei externer perephiere) heute noch zu Gewährleisten.

Daher ist die genannte "unportabilität" eigentlich nur durch verwendung eines unvollständigen satzes an steuerzeichen vorhanden...

Blödsinn. Sorry.

Prinzipiell stimmt es ja was du schreibst - aber das ist alles irrelevant. \n ist die korrekte Schreibweise hier. Denn dafür sorgt das System. \r\n kann zuviel machen (muss aber nicht). zB auf OS 9 wäre \r\n falsch.

Deshalb: \n ist die korrekte und portable Form.

Shade Of Mine schrieb:

Deshalb: \n ist die korrekte und portable Form.

Ist nicht eher std::endl die korrekte und portable Form? Macht halt leider noch ein flush dazu, sollte hier aber nicht weh tun. Ich kenne es so, dass die Zeilentrenner wie folgt sind: Windows \r\n, Linux \n, MacOS \r.

Shade Of Mine

fdgdfg schrieb:

Shade Of Mine schrieb:

Deshalb: \n ist die korrekte und portable Form.

Ist nicht eher std::endl die korrekte und portable Form? Macht halt leider noch ein flush dazu, sollte hier aber nicht weh tun. Ich kenne es so, dass die Zeilentrenner wie folgt sind: Windows \r\n, Linux \n, MacOS \r.

Nein \n in einem Text-Kontext ist schon OK. Wenn du mit einer binaer Datei (ios::binary) arbeitest, ist \r\n und \n unter windows unterschiedlich - im Text-Kontext nicht.

Und unter OS X hast du auch \n als Line Ending. \r war unter OS 9

Frage: wenn \n unter Windows durch \r\n ersetzt wird, wäre dann ein \r\n selbst dort falsch? Es müsste doch zu \r\r\n geändert werden.

Shadow of Mine hat es doch schon erläutert. Der einzige Grund für das Text-Flag bei Dateioperationen, ist der unterschiedliche Zeilenumbruch. Ein Zusätzliches Carriage Return \r tut aber nicht weh. Es veranlasst ja nur, dass der Cursor an den Zeilenanfang geht, dort ist er aber schon.

Nexus

Paul Müller schrieb:

Ein Zusätzliches Carriage Return \r tut aber nicht weh.

Kommt wohl sehr drauf an, wie der Editor das interpretiert. Warum überhaupt ein '\r' zuviel, wenn '\n' reicht?

#include <iostream>
#include <fstream>
#include <cctype>
#include <map>

typedef std::map<char, int> Occurrences;

int main(int argc, char *argv[])
{
	if (argc < 2)
	{
		std::cerr << "Zu wenig Parameter uebergeben" << std::endl;

		return -1;
	}

	std::ifstream file("a.txt");

	if (!file.good())
	{
		std::cerr << "Datei konnte nicht geoffnet werden" << std::endl;

		return -2;
	}

	Occurrences occurrences;

	for (int i = 0; i < 26; ++i)
	{
		occurrences['A' + i] = 0;
	}

	int counted = 0;

	while (!file.eof())
	{
		char ch = file.get();

		if (isalpha(ch))
		{
			++occurrences[toupper(ch)];

			++counted;
		}
	}

	std::cout.precision(3);

	for (Occurrences::iterator it = occurrences.begin(); it != occurrences.end(); ++it)
	{
		std::cout << it->first << " = " << it->second << " (" << (static_cast<float>(it->second) / counted) * 100.f << "%)" << std::endl;
	}
}

abc.w

trzrtztr schrieb:

...

Schön
Persönlich mag ich statt

if (!file.good())

so was:

if (0 == file.good())

Und statt

for (int i = 0; i < 26; ++i)

das:

size_t i = 0u;
...
for (i = 0u; i < 26u; ++i)

ints mag ich überhaupt nicht

Nexus

abc.w schrieb:

Persönlich mag ich statt
if (!file.good())
so was:
if (0 == file.good())

Nicht nur, dass du 0 statt false nimmst, auch die explizite Abfrage boolscher Werte und das Literal auf der linken Seite... Finde ich sehr übel.

Werner Salomon

trzrtztr schrieb:

int counted = 0;

    while (!file.eof())
    {
        char ch = file.get();
        // ..

.. es sollte doch bei Funktionen, die einen Fehler zurück liefern, normal sein, dass man zuerst die Funktion aufruft und erst danach schaut, ob ein Fehler aufgetreten ist - oder?
Nur beim Lesen aus einem Stream scheinen viele anderer Meinung zu sein.

Mit der obigen Konstruktion wird als letztes Zeichen ein EOF gelesen, was implizit in einem char konvertiert wird - hoffentlich ist es kein Buchstabe, dann fällt es nicht auf und erst danach geht der Stream in den Zustand EOF. Hätte der Stream während des Lesens einen Fehler (Datei auf einem Server, Netztstecker fliegt raus) dann entpuppt sich obiges als Endlos-Schleife, weil der Stream zwar nach FAIL aber nie mehr nach EOF geht.

Korrekt wäre hier z.B. ein

for( char ch; file >> ch; ) {
        // ...

Gruß
Werner

Ist dieser Code &quot;schön&quot;?

Ist dieser Code "schön"?