Arrays -> dynamisch

[e9926044]

Hallo,

ich möchte mir ein Array erstellen wie unten, aber nicht die fixe Größe angeben sondern eben wie unten und in einem anderen Programmteil dann in dieses Schreiben. Leider bekomme ich die Fehlermeldung "cannot find symbol".
Ich schätz mal das hängt damit zusammen, dass ich nicht die fixe Größe angeben, oder.
Vielleicht hat dajemand eine Idee.


VielenDANK.

lg
Hannes

int[] inputWerte = new int[bildGroesse-headerVariable];  // Array erstellen

inputWerte[bildGroesse-headerVariable] = b;                 // in Array schreiben

 

[SlaterB]

versuche mal
int x = bildGroesse-headerVariable;

das wird genauso wenig funktionieren, hat also mit Arrays nicht zu tun,

was sind das für zwei Variablen? wieso sollte der Compiler sie in dieser Situation finden?
er sagt dir dass er das nicht tut

 

[Guest]

Wie kann ich dann Arrays dynamisch erstellen?

ich möchte keine fixe Größe vorgeben sondern zur LAufzeit bestimmen wie groß das Array ist.

Vielen Dank

lg
HAnnes

 

[The_S]

Warum verwendest du keine Collection wie ArrayList?

 

[SlaterB]

ein Array wird im Grunde immer "erst zur Laufzeit dynamisch" erstellt,
anstelle new int[4] kannst du
new int[variable]
oder auch
new[operation()]
oder beliebiges anderes in Java erlaubtes schreiben

gerne auch
new int[(int) (Math.pow((variable1*34)-var2-var3, .................))]
usw.

 

[Spacerat]

Der "Vector" ist stets eine gute Wahl (naja... nicht immer, aber immer öfter...).

Der Vector hat nämlich mit Primitivtypen (boolean, byte, short, int, long, float und double) so seine Mühe, da ihm nur Objekte hinzugefügt werden können. Ab Java-Version 1.5 allerdings gibt es das sog. In- Outboxing, womit new Vector<Integer>() kein Prob mehr darstellen dürfte.
Wird letztens doch noch ein Array benötigt, kann man mit "int array[] = new int[vector.size()]" ein solches erstellen und mit "vector.copyInto(array)" dieses mit den aktuellen Daten füllen.

cu Spacerat

 

[Wildcard]

Statt des vermurksten Vectors aber zB ArrayList nehmen.

 

[Spacerat]

@Wildcard: Was ist denn am Vector vermurkst? (Ne... ehrlich... ohne sch... hab' keine Ahnung... :shock: )

 

[WieselAc]

Wenn ich das richtig im kopf hab, ist ein vektor intern ein array. Wenn es voll ist, wird es komplett in ein doppelt so großes array kopiert. Bin mir nicht so ganz sicher.

 

[SlaterB]

das ist bei der ArrayList genauso

aber die ArrayList hat keine synchronisierten Operationen
-> unsicher bei gleichzeitigen Zugriff mehrerer Threads, dafür schneller

 

[The_S]

das ist bei der ArrayList genauso

aber die ArrayList hat keine synchronisierten Operationen
-> unsicher bei gleichzeitigen Zugriff mehrerer Threads, dafür schneller

Was aber ohnehin kein A... merkt, wenn es nicht um Unmengen an Daten oder jede Millisekunde geht.

 

[Wildcard]

Es geht um die vermurkste API die nachträglich an die List Schnittstelle angepasst wurde.
Das hat zur Folge das der Vector zur Verwendung von Methoden verleitet die in List einen anderen Namen haben, wodurch er später nicht mehr austauschbar ist.

 

[Illuvatar]

Man sollte ja eh nicht schreiben
Vector<X> v = new Vector<X>();
sondern
List<X> l = new Vector<X>(); :bae:

Und @Hobbit: synchronized ist theoretisch schon ziemlich viel langsamer - du hast Recht, ein paar Aufrufe müssen schon zusammenkommen, damit mans merkt, aber wenn es ArrayList als Alternative gibt, warum Vector nehmen?

 

[Wildcard]

Man sollte ja eh nicht schreiben
Vector<X> v = new Vector<X>();
sondern
List<X> l = new Vector<X>(); :bae:

Sollte man....
leider zeigt die Erfahrung (auch in meiner Firma) das Leute die Vector statt ArrayList nehmen eben
Vector<x> v = new Vector<x> schreiben... :roll:

 

[moormaster]

Vector ist Bestandteil der API; wieso sollte man den in jeder Situation austauschbar halten?

 

[AlArenal]

Vector ist Bestandteil der API; wieso sollte man den in jeder Situation austauschbar halten?

Weil du heute nicht nicht weißt welche Anforderungen du morgen in deiner Anwendung umsetzen musst, darum wird allerorten gepredigt wo möglich gegen Interfaces und nciht gegen Klassen zu programmieren, weil das die Wartbarkeit des Codes erhöht, indem es nachträgliche Änderungen und Refactorings erleichtert / ermöglicht.

 

[moormaster]

Vector ist Bestandteil der API; wieso sollte man den in jeder Situation austauschbar halten?

Weil du heute nicht nicht weißt welche Anforderungen du morgen in deiner Anwendung umsetzen musst, darum wird allerorten gepredigt wo möglich gegen Interfaces und nciht gegen Klassen zu programmieren, weil das die Wartbarkeit des Codes erhöht, indem es nachträgliche Änderungen und Refactorings erleichtert / ermöglicht.

Das ist mit jeder besseren IDE mit Hilfe von Refactoring im Falle des Vector's genauso schnell erledigt.

 

[Beni]

Glaub ich nicht: stell dir mal vor du benutze eine Methode die nur der Vector bietet ("addElement" zum Beispiel), und jetzt versuch den Vector durch eine LinkedList zu ersetzen... da musst du all die Methodenaufrufe von Hand umbiegen.

 

[AlArenal]

Das ist mit jeder besseren IDE mit Hilfe von Refactoring im Falle des Vector's genauso schnell erledigt.

Du bedenkst nicht die Konsequenzen. Denk an eine API in der Methoden einen Vector zurückliefern oder als Parmeter erwarten. Gegen Interfaces programmieren heißt der übblichen Praxis zu folgen die Implementierung nach außen hin zu verbergen und nachträglich eine API zu ändern ist in "Hello World!" kein Problem, führt in der Praxis aber zu einem Rattenschwanz an Änderungen in allen darauf aufbauenden Projekten.

Es soll ja auch Leute und Firmen geben, die Librarys produzieren. Manche nur für internen Gebrauch, manche auch als Produkte...

 

[moormaster]

Ja gut wenn mans so sieht... ich hab eher die interne Verwendung der Vectorklasse im Kopf gehabt, ohne dass diese nach aussen hin in Rückgabewerten oder Parametern auftaucht.
Meistens existiert die Schnittstelle ja vor der Implementierung und dann taucht Vector da schon von Anfang an nicht nach "aussen" hin auf, weil dann ja eh mit eigenen (oder geeigneten vordefinierten) Schnittstellen gearbeitet wird.

 

[AlArenal]

Ich mache es intern aber auch nicht anders, denn alles was ich von einem Vector brauchen könnte ist im List-Interface enthalten. Mich interessiert ehrlich gesagt nicht ob etwas ein Vector oder eine ArrayList ist, ich will doch bloß was reinschieben, rausholen, schauen obs drin ist...

 

[Spacerat]

Es geht um die vermurkste API die nachträglich an die List Schnittstelle angepasst wurde.
Das hat zur Folge das der Vector zur Verwendung von Methoden verleitet die in List einen anderen Namen haben, wodurch er später nicht mehr austauschbar ist.

Das hab' ich so noch gar nicht gesehen, aber da ist durchaus was dran. Und äh ups, dann sollte wohl doch 'ne ArrayList verwendet werden.

Dummerweise hätte mir das aber auffallen müssen, als ich mir eine Sorted-List bauen wollte. Kurzerhand den Vector erweitert und überflüssige Methoden (z.B. alle, die mit index auf das Array zugreifen) einfach leer gelassen. Was solls, manchmal ist man halt selbst so dermassen mit 'nem Spaten gestreichelt, das man auf die einfachsten Sachen nicht kommt.

cu Spacerat

@Edit02032007: Bin da in Eclipse auch noch auf folgendes gestossen: "public class Vector<XX> extends Arraylist implements ...". Was soll das denn? Hab' so langsam das Gefühl, "Vector ist stets letzte Wahl".