# Arrays -> dynamisch



## e9926044 (16. Feb 2007)

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 (16. Feb 2007)

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 (16. Feb 2007)

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 (16. Feb 2007)

Warum verwendest du keine Collection wie ArrayList?


----------



## SlaterB (16. Feb 2007)

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 (16. Feb 2007)

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 (16. Feb 2007)

Statt des vermurksten Vectors aber zB ArrayList nehmen.


----------



## Spacerat (16. Feb 2007)

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


----------



## WieselAc (16. Feb 2007)

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 (16. Feb 2007)

das ist bei der ArrayList genauso 

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


----------



## The_S (16. Feb 2007)

SlaterB hat gesagt.:
			
		

> 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 (16. Feb 2007)

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 (16. Feb 2007)

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 (17. Feb 2007)

Illuvatar hat gesagt.:
			
		

> 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 (17. Feb 2007)

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


----------



## AlArenal (17. Feb 2007)

moormaster hat gesagt.:
			
		

> 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 (17. Feb 2007)

AlArenal hat gesagt.:
			
		

> moormaster hat gesagt.:
> 
> 
> 
> ...



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


----------



## Beni (17. Feb 2007)

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 (17. Feb 2007)

moormaster hat gesagt.:
			
		

> 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 (17. Feb 2007)

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 (17. Feb 2007)

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 (23. Feb 2007)

Wildcard hat gesagt.:
			
		

> 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".


----------

