# Ein alter C-Versuch *lol*



## Moartel (7. Oktober 2001)

Ich habe eben mal meine alten Files durchgekämmt und bin da auf meinen ersten (und einzigen) Versuch in der Sprache C gestoßen. Ich habe damals ein kleines Proggie zur Primzahlenberechnung (ich weiß dass das ne Kinderei ist, aber zum C++-lernen ganz nett) geschrieben und wollte es nach C übersetzen. Dann hab ich das ganze durch so nen alten Borland C-Compiler gejagt und rausgekommen ist das hier.
Ausführung auf eigene Gefahr. Nur mal das man sieht was alles komisches rauskommen kann wenn man null Ahnung davon aht was man tut.


----------



## Thomas Kuse (3. November 2001)

das is doch nich wirklich ne primzahlen berechnung..

was arbeitest du denn da im speicher rum?? er printet da irgendwelche exe-dateien aus.


----------



## Moartel (3. November 2001)

> _Original geschrieben von .:jOki:. _
> *das is doch nich wirklich ne primzahlen berechnung..
> 
> was arbeitest du denn da im speicher rum?? er printet da irgendwelche exe-dateien aus. *


Ich weiß selber dass das ne wirklich Promzahlenberechnung ist. Sollte es aber werden.
Was ich da angestellt habe weiß ich selber nicht. Ich wüsste es aber sehr gerne. Ich weiß nur dass der Rechner ziemlich oft piept wenn man das Programm startet. Wie dieser Unfall zustande gekommen ist weiß ich selbst nicht. Ich habe den Code damals aber mehrmals hintereinander kompiliert um sicherzugehen dass das kein Zufallsprodukt ist.


----------



## Xeragon (3. November 2001)

IIRC ist ein bestimmtes ASCII-Zeichen als ein Piepsen implementiert. Ich tippe mal drauf dass du irgendwo in nicht initialisiertem Speicher rumliest (z.b. überschrittene Array-Boundary).
Hast du den Source-Code vielleicht noch?


----------



## Moartel (3. November 2001)

Jo, ich glaube ich hab den gefunden. Kann aber ned garantieren dass er es 100%ig ist. Ich habe den Turbo C-Compiler genommen den es bei Borland kostenlos im "Museum" gibt. 
Source hänge ich einfach mal an.


----------



## Xeragon (3. November 2001)

Abgesehen vom Stil (kein einrücken *g*) ist der Code nicht mal so falsch. Du hast nur printf(i) anstatt printf("%8d", i) verwendet


----------



## Moartel (3. November 2001)

> _Original geschrieben von Xeragon _
> *Abgesehen vom Stil (kein einrücken *g*) ist der Code nicht mal so falsch. Du hast nur printf(i) anstatt printf("%8d", i) verwendet  *


Nix gegen meinen Stil, ok?   
Ich weiß dass der mies ist. Bin dabei mir einen besseren anzugewöhnen.


----------



## Xeragon (3. November 2001)

Hehe, üb mal brav weiter . Und weil mir so fad ist, hab ich auch gleich noch eine hoffentlich schönere und garantiert schnellere Variante geschrieben:


```
#define MAX_PRIME 25000

void ShowPrimes(void);

int main()
{
	ShowPrimes();
	std::cin.get();
	return 0;
}

void ShowPrimes(void)
{
	// Primzahlenerkennung mit Hilfe des Sieb des Eratosthenes
	std::bitset<MAX_PRIME+1> fPrime;
	fPrime.set();
	fPrime.set(1, false);

	for(unsigned int i=2; i < fPrime.size(); ++i)
	{
		if(fPrime[i])
		{
			for(unsigned int j=i; j < fPrime.size(); j+=i)
				fPrime.set(j, false);
			std::cout.width(8);
			std::cout << i;
		}
	}
}
```


----------



## Moartel (3. November 2001)

Danke, bei Gelegenheit werd ich das mal ausprobieren.
Bin aber nimmer so auf C. Will eher mal richtig C++ lernen, oder mich intensiv mit Java beschäftigen, wenn da nur nicht die Schule wäre....


----------



## Xeragon (4. November 2001)

Naja, eigentlich ist das ja C++, aber man könnte es noch in eine schöne CPrimGen-Klasse kapseln


----------



## Kimble (28. Dezember 2001)

warum machst du dir's so schwer, schreib unter der #include Anweisung:

```
using namespace std;
```
dann steht nich über all std::x da!


----------



## Xeragon (28. Dezember 2001)

Das wird zwar teilweise gemacht, eliminiert aber wieder den Sinn von namespaces, deswegen sollte man es besser nicht machen.
Wenn man schon using verwendet, dann beser z.b. using std::cout, um nur cout in den globalen namespace zu holen.


----------



## Kimble (28. Dezember 2001)

aha,
schon wieder was gelernt ;-) !


----------



## sven_raven (28. Dezember 2001)

aber ich würde ja statt *#define MAX_PRIME 25000* lieber *const unsigned short MAX_PRIME = 25000* benutzen. damit das nicht vom Präprozessor einfach ausgetauscht wird sondern vom compiler auch überprüft ^^
*mit gerade gelerntem klugscheiss*


----------



## Xeragon (28. Dezember 2001)

Hmm, ja obwohl das bei so einem Programm nichts ausmacht, is es besser den Präprozessor zu vermeiden. Wenn du aber schon auf so was bestehst, dann musst du auch den Generator schon in eine (od. mehrere) Klassen packen, um schon OO zu bleiben ;-)

Abgesehen davon ist sowohl von short als auch von unsigned nur dringenst abzuraten -> nimm int


----------



## sven_raven (28. Dezember 2001)

wat wieso?
es handelt sich doch dabei um eine konstante!
Diese kann nur den ihr einmal zugewiesenen Wert haben! Und da die Zahl positiv is -> unsigned!
Und weil die Zahl 25000 in den Bereich eines Short Int fällt nehme ich auch short dafür! Denn short belegt nur 2 Bits.
Int is von compiler zu compiler unterschiedlich! Manchma reserviert der 2 Bits und manchma 4...
Darum würde ich lieber zwischen short (int) und long (int) differzieren anstatt nur int zu schreiben! 

Aso und bei klassen bin ich noch nicht... von OOP hab ich noch =0= plan


----------



## Xeragon (28. Dezember 2001)

> _Original geschrieben von |®/\vEñ| _
> *wat wieso?
> es handelt sich doch dabei um eine konstante!
> Diese kann nur den ihr einmal zugewiesenen Wert haben! Und da die Zahl positiv is -> unsigned!
> Und weil die Zahl 25000 in den Bereich eines Short Int fällt nehme ich auch short dafür! Denn short belegt nur 2 Bits.!*


short belegt zwar nur zwei Bytes, doch int(32) ist normalerweise auf 32-Bit Architekturen schneller. Abgesehen davon schreibt der Standard vor, dass immer mit int gerechnet wird -> es erfolgt stets eine implizite Standardkonvertierung. 
Wegen unsigned: Wenn man unsigned verwenden muss um das letze Bit herauszuquetschen, ist das normalerweise ein Indiz dafür, das der gewählte Typ zu klein ist. Außerdem kann es aufgrund von impliziten Standardkonvertierungen zu Fehlern kommen, die schwer zu finden sind z.b.: 

```
unsigned i=23343;
int j=-123;

i+=j; // Ergebnis ist doch eigentlich positiv, aber -> siehe unten
```
Eigentlich sollte der Ausdruck keine Probleme bereiten oder? ABER: j wird implizit als unsigned interpretiert und das Ergebnis ist vollkommen falsch



> _Original geschrieben von |®/\vEñ| _
> *Int is von compiler zu compiler unterschiedlich! Manchma reserviert der 2 Bits und manchma 4...
> Darum würde ich lieber zwischen short (int) und long (int) differzieren anstatt nur int zu schreiben! *


Wenn du noch auf einer 16-Bit Plattform arbeitest... Gott steh dir bei. Inzwischen kann man ruhigen Gewissens annehmen, dass jeder mit zumindest 32-Bit arbeitet. Abgesehen davon würde der 16-Bit int ja wie schon gesagt auf diesen Plattformen ausreichen und wiederrum eine implizite Konvertierung verhindern, die bei long passieren würde. 


> _Original geschrieben von |®/\vEñ| _
> *
> Aso und bei klassen bin ich noch nicht... von OOP hab ich noch =0= plan *


Hehe

BTW: Das Quoting auf dem Board ist grauenhaft.


----------



## sven_raven (28. Dezember 2001)

hmm also ich kann ja nur dass schreiben was ich gelesen habe... und gelesen habe ich dass man nie int nehmen soll sondern immer short oder long


----------



## Xeragon (28. Dezember 2001)

Das hängt wohl immer vom Fall ab, wenn du nur auf einer Plattform arbeitest ist es im Prinzip egal.


----------



## Thomas Kuse (28. Dezember 2001)

mhhh wegen geschwindigkeit?? also bitte so schnell reizt du c++ ja nich aus, ausservielleicht beim sortieren eines mega-arrays mit bubblesort


----------



## Xeragon (28. Dezember 2001)

Nicht unbedingt deswegen, aber warum sollte man die Geschwindigkeit vergeuden?
Abgesehen davon sollte man implizite Konvertierungen vermeiden, weil sie in größeren Projekten extrem kompliziert zu debuggen sind (mal ehrlich, wer würde schon auf das problem mit dem unsigned kommen, wenn er ein riesiges Projekt vor sich hätte?)


----------



## Thomas Kuse (28. Dezember 2001)

hehe hab mich heute darüber belesen!!

is schon wunderlich  kommt man gar nicht drauf


```
int i,k;
int j;
i=2;
k=3;
j = i+++k; /* i+ (++k); i=2,k=4,j=6 */
j = (i++)+k; /* i=3,k=4,j=6 */
j = i++ +k; /* i=4,k=4,j=7 */
j = (i+k)++; /* ist verboten */
```

auch diese sachen sind sehr wichtig zu wissen, wenn man debuggt


----------



## Xeragon (28. Dezember 2001)

Hmm, obwohl das mit dem Post-Increment/Decrement-Operatoren ist doch noch etwas einfacher zu verstehen ;-) als "stille" interpretationen als unsigned


----------



## Thomas Kuse (28. Dezember 2001)

k hast recht! das andere is wirklich tückisch


----------

