WCM Forum

WCM Forum (http://www.wcm.at/forum/index.php)
-   Programmierung (http://www.wcm.at/forum/forumdisplay.php?f=17)
-   -   Speicher und Funktionen in C (http://www.wcm.at/forum/showthread.php?t=108593)

thyrver 12.09.2003 14:36

Speicher und Funktionen in C
 
Hi.
Ein Funktionsaufruf:

funktion(argument1);

Wird argument1 im Speicher neu angelegt? Und falls ja, ist nicht dann ein Pointer auf argument1 weniger speicherverbrauchend (falls argument1 zum Beispiel eine Struktur wäre)?

Mir ist klar, dass funktion(&argument1) die Möglichkeit hat argument1 zu ändern, funktion(argument1) kann das hingegen nicht. Oder seh ich das falsch?

Danke für eure Mühe.

--
lg
fabsi

sagi 12.09.2003 14:40

Ja. du hast das absolut richtig verstanden.

mfg

c.

thyrver 12.09.2003 15:20

Danke. :)

Und was ist zu bevorzugen? Die Übergabe eines Pointers auf den Inhalt, oder des Inhalt selbst (bzw. eine Kopie des Inhalts)?

Oder von welchem Standpunkt aus ist was zu bevorzugen eurer Meinung nach? (Das ichs mir selbst aussuchen kann wie ichs mach ist mir klar, aber es hat sicher wer Erfahrungen mit der einen oder anderen Methode, und die interessieren mich.)

mit Dank im Voraus.
--
lg
fabsi

Stona 12.09.2003 17:35

...das kommt draufan...

wenn du sichergehen willst/musst, dass eine funktion einen übergabewert nicht verändern darf (aus welchen gründen auch immer, hab täglich damit zu tun :D), würd ich immer den "call-by-value" bevorzugen.

wenn das allerdings keine rolle spielt, sondern eher speichereffizienz, ist es besser, die referenz (&value) zu übergeben

Who-T 14.09.2003 10:03

Zitat:

wenn du sichergehen willst/musst, dass eine funktion einen übergabewert nicht verändern darf [...], würd ich immer den "call-by-value" bevorzugen.
Code:

void foo (const void* value)
{
 // damn shit I cannot change the value...
}

so würd ich das machen, denn hier kann ich sichergehen dass der wert read only ist (und für den, der die funktion benutzt ist es auch übersichtlicher)


Zitat:

sondern eher speichereffizienz, ist es besser, die referenz (&value) zu übergeben
jein
bsp:

sizeof (short*) ist bei mir zb 4
sizeof (short) ist bei mir 2

sprich würd ich die referenz übergeben hätt ich dann meine originalvariable mit 2 + einen pointer mit 4 bytes -> 6 bytes.

call by value hätt ich 2 shorts -> 4 bytes

kikakater 14.09.2003 11:30

1) Call by Address setzt das Präparieren der Struktur (=Versorgen der Datenfelder mit Werten) voraus. D.h. ein Call bei Address ist im Fall einer Struktur generell zu bevorzugen, da ich vorher eine definierte Versorgung der Datenfelder sicherstellen muss. Dies zwingt zu sorgfältiger Programmierung.

2) Ein weiterer Grund ist die Verwaltung der Informationen (Struktur) im Computerspeicher. Ein Array aus Strukturen oder eine verkettete Liste bzw. ein Baum aus Strukturen kann besser verwaltet werden als das Anlegen von einzelnen Strukturen. Die Übergabe erfolgt aus dem Array/der Liste/dem Baum oder aus einer Kopie UNTER VORHERIGER Versorgung der Strukturkopie und Übergabe eines Zeigers darauf.

Punkt 1 bezieht sich auf die Disziplin beim Programmieren
Punkt 2 auf die Praxis, Geschwindigkeit und Effizienz bei der Speicherorganisation

Es ist ein Muss eine Struktur vor der Übergabe mit korrekten Werten zu versorgen, insofern ist die zusätzliche Übergabe der Daten der Struktur über den Stack (Call by Value) ein Unsinn erster Ordnung.

mfg
Kikakater

thyrver 14.09.2003 11:33

ich habs nicht mit char oder int datentypen zu tun sondern mit Strukturen, die ihrerseits wieder strukturen, int arrays, einfachen int Datentypen enthalten. Wenn der Pointer auf meine Struktur seine 4 Byte hat kann ich damit leben, die Struktur hat sicher ein Vielfaches davon wenn ich sie selbst übergebe.

Die Methode den Übergabewert als Konstante zu übergeben gefällt mir. Danke für den Tip. :)

Warum interessiert mich das? Ich überleg mir bei einem Softwareprojekt den Funktionsaufrufen ein einheitliches Aussehen zu verpassen, und zerbreche mir den Kopf, was das Beste sein könnte.

Danke für eure Antworten @Stona & @Who-T.

Will noch wer seine Erfahrungen mitteilen?

Stona 14.09.2003 11:44

noch ne infos zur übergabe von Arrays an andere Funktionen (wenn du's nicht weisst oder dich interessiert):


wenn du ein array als parameter übergibst wird - egal ob du schreibst

funktion (&array[0]);

oder

funktion (array);

immer ein pointer auf das erste element des arrays übergeben (auch im fall zwei), d.h. du kannst ein array nicht als kopie übergeben.

Pointer und Arrays in C sind ja sehr eng miteinader verwandt.

@Who-t

hast natürlich recht ;) aber siehst, seine daten sind viel großer ale ne adresse (ich wusste das natürlich) :p

kikakater 14.09.2003 12:06

Zitat:

Original geschrieben von Stona
...das kommt draufan...

wenn du sichergehen willst/musst, dass eine funktion einen übergabewert nicht verändern darf (aus welchen gründen auch immer, hab täglich damit zu tun :D), würd ich immer den "call-by-value" bevorzugen.

wenn das allerdings keine rolle spielt, sondern eher speichereffizienz, ist es besser, die referenz (&value) zu übergeben

Call by Address ist nicht gleich Call by Reference.

Die Referenz ( function_name (data_type &reference) ) bedeutet eine Übergabe einer Adresse unter syntaktischer Verwendung einer Datenvariablenschreibweise innerhalb der Funktion ! Das ist der Unterschied zu Call by Address.

Call by Reference existiert nur in C++, nicht jedoch in C.

Der Aufruf mit einem Ampersand '&' unter C ist die Übergabe einer Adresse und nicht einer Referenz.

thyrver 14.09.2003 12:21

@kikakater
Wieso ist das ein Muß die Strukturen mit korrekten Werten zu Versorgen? Reicht das Anlegen eines Pointers auf eine Struktur (in main() ) und das anschliessende "anlegen" von Speicher und zuweisen von Werten in initStruktur(pStruktur) (als funktionsaufruf in main()) nicht aus?

@Stona
Ja, das wußte ich schon. :)

Ahja, es geht um reinen C Code, es kommt (ausser C++ Kommentaren :-) ) nix C++ mässiges vor.


Meine Dankbarkeit weitet sich auch auf kikakater aus.


Alle Zeitangaben in WEZ +2. Es ist jetzt 23:13 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag