Nabend zusammen. Ich möchte ein Array erstellen deren Länger ich erst zur Laufzeit weiss. meine Frage komm ich da um die malloc Funktion herrum?
Du kannst das Array auch vorher mit der maximal vorkommenden Größe deklarieren. Ist zwar speicherverschwendung aber wenn du genug hast... Ansonsten halt malloc. Was stört dich daran?
Solche Dinge sollte ma alles seinlassen. Ein Controller is kein PC der fallsndas Duzend Giga wweg waere, nochmals beliebig viel Gigas von der Platte holen kann. Auf controllern sollte man dynamisches Memory generell vermeiden.
Tobi88 schrieb: > Nabend zusammen. > Ich möchte ein Array erstellen deren Länger ich erst zur Laufzeit weiss. > meine Frage komm ich da um die malloc Funktion herrum? Natürlich. Wenn es nur ein Array ist, dann allokiere es * mit der maximal vorkommenden Länge * mit der Länge, die du dir auf dem µC gerade noch leisten kannst (je nachdem was zutrifft). Mehr als diesen Speicher hast du sowieso nicht. Und mehr kann die malloc auch nicht besorgen.
T. roll schrieb: > Solche Dinge sollte ma alles seinlassen. Ein Controller is kein PC der > fallsndas Duzend Giga wweg waere, nochmals beliebig viel Gigas von der > Platte holen kann. Auf controllern sollte man dynamisches Memory > generell vermeiden. Und warum? Speicher ist immer begrenzt, egal ob man X Gigabyte oder 256 Byte hat. Man muß in jedem Fall wissen (und verstehen) was man tut! Es kann auch bei knappen Speicher durchaus gute Gründe geben Speicher dynamisch zu verwenden. Harry
Tobias Wagner schrieb: > Oder mit new: > > int i = 20; > int *array = new int(i); das geht? dachte das wäre nur in java möglich
ich brauche dies für ein Protokoll in dem ich keine Rohdaten mit einer festen Länge vorgeben. Ein Ausschnitt aus dem Protokoll soll ungefähr so aussehen: |Anfang|LaengeRohdaten|Rohdaten|Ende| ------------------------------------- 1Byte 1Byte x-Byte 1Byte Ich möchte aber nich ein Array mit 255 Byte anlegen wenn die rohdaten nur 10 byte haben. ich möchte das Array mit Hilfe von "LaengeRohdaten" anlegen sodass das Array auch nur soo groß ist wie ich e für die Rohdaten brauche. p.S dieser Auschschnitt spiegelt nicht das ganze Protokoll wieder sondern nur den relevanten Ausschnitt
Tobi88 schrieb: > Ich möchte aber nich ein Array mit 255 Byte anlegen wenn die rohdaten > nur 10 byte haben. Nochmal. Hast du noch etwas in deinem Programm, welches du dynamisch verwalten musst? Wein nein, dann lege es statisch an. Du hast in deinem µC nicht mehr Bytes zur Verfügung als er hat. Ob dieser Speicher jetzt brach liegt, oder ob du diesen Speicher in ein fixes Array steckst, welches immer existiert, ist Jacke wie Hose. Du sparst dir aber selbst und deinem µC eine Menge Ärger, wenn du das tust. Denn was tust du denn, wenn du von malloc den Speicher nicht bekommst? Und nur so als Hinweis: du wirst von malloc WENIGER Speicher zugeteilt bekommen, als du durch statische Allokierung erreichen kannst. Denn die dynamisch allokierten Speicherblöcke verwalten sich ja auch nicht von alleine. Ganz abgesehen davon, dass die Verwaltung einfacher ist. > Ich möchte aber nich ein Array mit 255 Byte anlegen > wenn die rohdaten nur 10 byte haben. Aber 255 können vorkommen? Wenn ja, dann musst du auch damit rechnen, dass dem so ist und ein entsprechendes Array bereitstellen. Da ist es einfacher, IMMER ein Array der Länge 255 zu haben, von dem dann halt nur 10 Bytes benutzt werden. Dann hast du wenigstens Zahlen mit denen du rechnen und operieren kannst anstatt irgendwelcher Speicheranforderungen, die gut gehen können oder auch nicht.
Der springende Punkt ist das Worst-Case-Szenario. Damit muss dein Programm klar kommen. Alles andere ist dann nur noch Vereinfachung dieses Worst-Case Szenarios. Und wenn dann eben Speicherbereiche nicht benutzt werden, dann werden sie halt nicht benutzt. Aber ob die jetzt nicht allokiert sind, oder ob sie programmtechnisch gesehen zum Array gehören - ist Jacke wie Hose. Interessanter wird es, wenn derselbe Speicher zu verschiedenen Zeiten zu unterschiedlichen Zwecken benötigt wird. Aber selbst dann kann man das mit einer union wunderbar handhaben. Genau das ist die ursprüngliche Idee hinter einer union.
Im gcc-Forum gab es letzte Woche das Selbe Thema. Heraus kam, das nichts für dynamische Allokierung spricht, aber vieles für statische.
Tobi88 schrieb: > Tobias Wagner schrieb: >> Oder mit new: >> int i = 20; >> int *array = new int(i); > das geht? dachte das wäre nur in java möglich In C++ gibt es new, in C allerdings nicht. Bsp: http://www.willemer.de/informatik/cpp/dynamic.htm
Wieviele der Rohdaten koennen denn kommen ? Ein Stueck, oder mehr? Falls nur ein Stueck, dann alloziere die 255 bytes fest. Dh statisch.
Dynamsiche Speicherverwaltung ist nur bei grossen Controllern sinnvoll (z.B. ARM), da es doch einiges an Aufwand bedeutet, diesen zu erstellen, dann zu Prüfen ob du ihn bekommen hast und was machen falls nicht. Hinzu kommt noch die Heap-Fragmentierung, wenn du an mehreren Stellen dynamisch arbeitest... Ich vermeide wenn möglich selbst bei den ARM-Controllern und C++ dynamische Arrays, obwohl es oft Situationen gibt, bei denen es durchaus Sinn machen würde. Aber hier hast du keinen PC der mit RAM nur so Überquilt... (was ist heute Standart? >8GB...)
Hallo, der einzige Grund für dynamische Speicherverwaltung wäre, dass ein Speicher, der für Aufgabe A gebraucht wird, zu einem andern Zeitpunkt für Aufgabe B genutzt werden kann - aber nur dann, wenn völlig ausgeschlossen ist, dass beide Aufgaben gleichzeitig zu bearbeiten sind. In allen anderen Fällen interessiert nur die maximale Grösse, entweder steht die zur Verfügung oder eben nicht, dann handelt es sich um eine Fehlkonstruktion und das wird sich auch irgendwann bemerkbar machen. Gruss Reinhard
Also derzeit brauche wirklich nur ca 10 Byte Rohdaten. Da ich aber nich weiss welche Funktionen hinzukommen und ich gerne das ding abwaerts kompatibel gestalten wuerde. Waere es schoen das empfangyarray zur laufzeit erstellen zu lassen.
Tobi88 schrieb: > Also derzeit brauche wirklich nur ca 10 Byte Rohdaten. Da ich aber nich > weiss welche Funktionen hinzukommen und ich gerne das ding abwaerts > kompatibel gestalten wuerde. Waere es schoen das empfangyarray zur > laufzeit erstellen zu lassen. Du hast es immer noch nicht. Das ist alles nicht die entscheidende Frage. Die entscheidende Frage lautet: Welche Datengröße kann maximal vorkommen? Du MUSST dich bei kleinem begrenztem Speicher auf irgendeine Maximalgröße festlegen. Ob du willst oder nicht. Denn bei irgendeiner Größe ist der vorhandene Speicher nun mal zu Ende. Was du ganz sicher nicht haben willst, ist ein Programm von dem niemand sagen kann, wo seine Grenzen liegen. Entweder das Programm kann maximal Datensätze von 256 Bytes bearbeiten oder es kann das nicht. Entweder das Maximum liegt bei 128 oder es tut es das nicht (weil kleiner). Aber irgendeine garantierte Größe brauchst du. Niemand hat etwas davon, wenn du heute Datensätze mit einer Länge von 128 Bytes noch bearbeiten kannst und wenn der Benutzer dann (ich erfinde jetzt mal was) 5 Adressen eingegeben hat, dann sinkt diese Grenze auf 100 Bytes. Davon hat keiner was. Bei einem µC geht es in der Regel um GARANTIERTE Werte. Bei einem PC ist das anders. Der hat ein virtuelles Memory Management. Wenn deine Daten den physikalisch verfügbaren Speicher sprengen, dann geht die Verarbeitung etwas langsamer (weil die Festplatte zum Speichern mit dazu genommen wird), aber das Programm läuft nach wie vor weiter. Bei einem µC in der AVR-Klasse hast du diesen Luxus aber nicht. Entweder das Programm kommt mit der Datenmenge klar, oder es schmiert ab. Und genau deswegen WILL man garantierte Größen haben. Ob das Hinzufügen von Funktionen an deinem Speicherverbrauch noch etwas verändert, hängt nicht zuletzt auch vom µC ab (über den du noch nichts gesagt hast). Bei einem AVR kannst du Programmcode hinzufügen, wegen der Harvard-Architektur, das ändert deswegen am Speicherverbrauch im SRAM nicht viel. Werden die verfügbaren SRAM-Größen größer als 2 oder 4 KByte (um mal eine Größenordnung zu nennen), dann entspannt sich die Situation zusehends. Aber mit wenig SRAM muss man ein wenig konservativer an die Sache rangehen. Da gilt dann nur noch: Was hab ich verfügbar und wieviel brauche ich im schlimmsten Fall.
Masl schrieb: > Heraus kam, das nichts für dynamische Allokierung spricht, aber vieles > für statische. Da kann man nur Zustimmen. Und noch dazu die Fehlersuche die bei dynamischer verwaltetem Ram nötig wird, willst du nicht wirklich machen. Du weißt dann nie an welcher Stelle du mit dem Debugger einen Wert nachlesen kannst. Was steht gerade Wo. Warum steht im Stack plötzlich eine 0x0000 wo eigentlich die Rücksprungaddresse der letzten Funktion stehen müsste,...... Das sieht dann anders aus wenn man mal auf Controllern unterwegs ist, die eine MMU und einem passendes Betriebssystem haben. Hier wären wir dann aber bei größeren ARM oder X86 Prozessoren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.