Es sollen 6 Zahlen eingegeben werden. Nach jeder Eingabe muss geprüft werden ob die Zahl bereits vorhanden ist. Wenn ja, muss eine andere Zahl eingegeben werden.
Hier mein aktueller Code. Ner leider ist hier ein Bug drin. Wenn ich eine vorhandene Zahl eingebe, komme ich in die Abfrageschleife. Nur hier wird nicht geprüft ob die vorhandene Zahl schon vorhanden ist. Ich habe hier ein Katze jagt Schwanz Problem....
[HIGHLIGHT="Java"]import java.util.Scanner;
public class Eingabe
{
public static void main (String[] args)
{
Scanner sc = new Scanner(System.in);
int i;
int z;
int[]zahlen = new int[6];
// Zahleneingabe
for(i=0; i<zahlen.length;i++)
{
System.out.print("Bitte geben Sie die " +(i+1) + ". Zahl ein: ");
zahlen = sc.nextInt();
// Durchlaufe die Schleife und Prüfe
// System.out.println("Aktueller Zähler: "+i);
for(z=0;z<i;z++)
{
if(zahlen==zahlen[z])
{
do
{
System.out.println("Meldung: die " +zahlen +" ist bereits eingegeben worden");
System.out.print("Bitte geben Sie die " +(i+1) + ". Zahl ein: ");
zahlen = sc.nextInt();
}
while(zahlen==zahlen[0]);
}
[HIGHLIGHT="Java"]
// for schleife anfang
int input;
do{
System.out.print("Geben Sie eine Zahl ein, die es bisher nicht gab: ");
input = sc.nextInt();
}
while(arrayContains(zahlen,input));
zahlen[count] = input;
// for-Schleife ende
[/HIGHLIGHT]
[HIGHLIGHT="Java"]private boolean arrayContains(int[] array, int target){
for(int i = 0;i<array.length;i++){
if(array == target){
return true;
}
}
return false;
}[/HIGHLIGHT]
Hier meine Variante:
[HIGHLIGHT="Java"] // Durchlaufe die Schleife und Prüfe
// System.out.println("Aktueller Zähler: "+i);
for(z=0;z<i;z++)
{
if(zahlen==zahlen[z])
{
System.out.println("Meldung: die " +zahlen +" ist bereits eingegeben worden");
i--; // diese Zeile hier ist ausschlaggebend
break;
}
}[/HIGHLIGHT]
Ungetestet, wie immer.
Wobei ich sowas nicht empfehlen würde Ark.
Wenn man eine for-Schleife sieht
for(int i = 0; i<x;i++)
geht man immer davon aus, dass das ganze x mal durchlaufen wird.
Da drin dann eine Manipulation von i einzubauen finde ich design-technisch nich so sauber.
So könnte man's doch machen (und auch noch gut aufteilen): [HIGHLIGHT="Java"]import java.util.Scanner;
public class Eingabe
{
public static void main (String[] args)
{
Scanner sc = new Scanner(System.in);
int i;
int z;
int[]zahlen = new int[6];
// Zahleneingabe
for(i=0; i<zahlen.length;i++)
{
System.out.print("Bitte geben Sie die " +(i+1) + ". Zahl ein: ");
zahlen = sc.nextInt();
while(indexOf(0, i-1, zahlen, zahlen) != -1) {
{
System.out.println("Meldung: die " +zahlen +" ist bereits eingegeben worden");
System.out.print("Bitte geben Sie die " +(i+1) + ". Zahl ein: ");
zahlen = sc.nextInt();
}
}
}
public static int indexOf (int ersterIndex, int letzterIndex, int[] zahlen, int gesuchteZahl)
{
for (int i = ersterIndex; i <= letzterIndex; i ++)
{
if (zahlen == gesuchteZahl)
{
return i;
}
}
// nicht gefunden
return -1;
}
}[/HIGHLIGHT] hdi, Dein Beispiel geht wahrscheinlich schief, wenn jemand 0 eingibt, oder?
Ebenius
private ist ein access modifier, so wie public (kennst du wahrscheinlich).
Heisst nur: Diese Methode ist nur in dieser Klasse sichtbar.
..und falls du jetzt meinen Code nutzt: Bedenke was Ebenius sagte:
Das ganze funzt nicht wenn man eine 0 eingibt, weil am Anfang das Array lauter
nullen hat!
Also entweder du füllst es mit -1, oder wenn man jede x-beliebige Zahl eingeben darf,
nimm die Version von Ebenius
War schon wieder zu langsam.
Das geht ja ab hier.
Ist also erledigt:
Oh, Hilfe,
ich bin leicht überfordert mit den vielen Antworten )
Um diesen Code gings mir.
Der zweite Teil ist mir unklar. (Auch unklar wie der komplette Sourcecode dann aussieht.
[highlight="Java"]
// for schleife anfang
int input;
do{
System.out.print("Geben Sie eine Zahl ein, die es bisher nicht gab: ");
input = sc.nextInt();
}
while(arrayContains(zahlen,input);
zahlen[count] = input;
// for-Schleife ende
[/highlight]
[highlight="Java"]private boolean arrayContains(int[] array, int target){
for(int i = 0;i<array.length;i++){
if(array == target){
return true;
}
}
return false;
}[/highlight]
geht man immer davon aus, dass das ganze x mal durchlaufen wird.
Da drin dann eine Manipulation von i einzubauen finde ich design-technisch nich so sauber.
Einen Anfänger mit der JLS (Java Language Specification) erschlagen zu wollen ist zwar eine super Idee, konfliktiert aber irgendwie mit dem Gedanken, diesem helfen zu wollen. Findest Du nicht auch?
Einen Anfänger mit der JLS (Java Language Specification) erschlagen zu wollen ist zwar eine super Idee, konfliktiert aber irgendwie mit dem Gedanken, diesem helfen zu wollen. Findest Du nicht auch?
Auf jeden Fall, das ist toal egal. Alleine schon die Signatur der Methode ist unmissverständlich.
Sie liefert zurück ob eine Zahl in einem Array vorhanden ist.
Ob du breakst oder direkt per return rausreichst, wayne...
Aber deine for-Schleife führt den Programmierer beim Betrachten hinter's Licht,
von daher bleibe ich bei meiner Meinung.
(Wobei ich nicht vorhab eine fette Diskussion zu starten, so eine Todessünde ist
es nun auch wieder nicht.. Kein Stress )
Vor allem ist es besser, die Funktionalität, einen Eintrag eines Arrays zu suchen, auszugliedern. Davon abgesehen ist das Modifizieren der Laufvariable einer for-Schleife meist unschön und verwirrt den Programmierer meist mehr als es ihm bringt. Besonders einem Anfänger würde ich nicht dazu raten, weil er dann noch weniger durchblickt.
@Leroy: Und ich les deinen Post 17 mal weil mir nicht klar ist was du jetzt eig. sagen willst xD
Aber anscheinend doch nix gegen mich, d.h. ich kann mir das übertriebene Offtopic-Gemetzel
ersparen, das ich jetzt gleich gestartet hätte...
Es stimmt schon, dass man die Suche auslagern kann/sollte. Aber wenn es darum geht, Code mit minimalen Redundanzen im Gesamtsystem zu entwerfen, sollte man hier besser gleich zum Collections-Framework greifen.
Da aber die Aufgabe hier nur darin bestand, eine weitere Implementierung für ein schon seit Jahrhunderten gelöstes Problem zu bieten, habe ich das so schnell und einfach wie möglich eingebaut.
Und wo da das Problem mit der i-Dekrementierung sein soll, weiß ich auch nicht: Mit Ende der i-Schleife liegen genau zahlen.length unterschiedliche Zahlen in zahlen vor, also genau das, was im Schleifenkopf beschrieben ist.
Es geht hier glaub ich nich so um Redundanz sondern um Lesbarkeit.
Ein Anfänger baut nun mal schnell einen Bug in einen Algo, der nur ein Array
auf eine Zahl prüft, wenn diese Funktionalität mitten in einem anderen Algo drinsteckt.
Das hat nichts mit Frameworks zu tun, das ist einfach "organisiertes Arbeiten", wenn
man es vollkommen abgehoben ausdrücken möchte
Und wo da das Problem mit der i-Dekrementierung sein soll, weiß ich auch nicht: Mit Ende der i-Schleife liegen genau zahlen.length unterschiedliche Zahlen in zahlen vor, also genau das, was im Schleifenkopf beschrieben ist.
Das ist recht einfach gesagt. Bei einer for-Schleife mit i:=0, i<n geht jeder Normalnutzer von genau n Schleifendurchläufen aus. Wenn man dieses Verhalten in der Mitte der Schleife ändert, handelt es sich um einen Spezialfall in dem die Schleife mit einem Index mehrfach durchlaufen werden kann. Das widerspricht dem üblichen Verhalten des Konstrukts und verwirrt besonders einen Anfänger schnell, deswegen lässt man das in der Regel sein.
wer hat hier was von verwirrung der Anfänger gesagt?
[highlight=Java]
import java.util.*;
public class _ {
public static void main(String... _) {
Scanner sc = new Scanner(System.in);
Collection<Integer> a;
for(a=new TreeSet<Integer>(); a.size()<6; a.add(sc.nextInt())){
System.out.println("Bisher eingegebene Zahlen: "+a);
}
System.out.println("Ende: "+a);
}
}
[/highlight]
find's ohne die ganzen + - irgendwie übersichtlicher
Andrey dieser Code macht aber nicht das was er will oder?
Oder verweigert so ein TreeSet irgendwie eine bereits enhaltene Zahl?
Mir ist durchaus klar dass dein Code eher eine Art "Witz" sein soll, aber
mich interessiert ob das tatsächlich die vollständige Lösung für sein Problem ist.
Jedes Set beinhaltet jeden Eintrag nur einmal. Wenn ich also zum zweiten mal die Zahl 7 einfüge, dann wird sie nicht nochmal eingefügt. Dem entsprechend wird auch size() keinen höheren Wert zurückliefern als vor dem Versuch des Einfügens des Duplikats. Das Resultat besteht aus n >= 6 Eingaben und einem Set mit genau 6 verschiedenen Werten.
Aha, da sieht man mal dass ich in über 1 gutem Jahr intensivem Java noch niemals ein Set
benutzt habe :autsch: Obwohl ich es oft hätte gebrauchen können, wenn es sich so
verhält. Tja, manchmal haste Pech.
@Leroy: Und ich les deinen Post 17 mal weil mir nicht klar ist was du jetzt eig. sagen willst xD
Aber anscheinend doch nix gegen mich, d.h. ich kann mir das übertriebene Offtopic-Gemetzel
ersparen, das ich jetzt gleich gestartet hätte...
