Arrayinitialisierung nur per define möglich



  • ; Listing generated by Microsoft (R) Optimizing Compiler Version 15.00.21022.08 
    
    	TITLE	C:\Users\Dennis\Desktop\test.c
    	.686P
    	.XMM
    	include listing.inc
    	.model	flat
    
    INCLUDELIB LIBCMT
    INCLUDELIB OLDNAMES
    
    CONST	SEGMENT
    _a	DD	05H <------ zumindest speicher verbraucht das const int
    CONST	ENDS
    PUBLIC	_main
    ; Function compile flags: /Ogtpy
    _TEXT	SEGMENT
    _main	PROC
    ; File c:\users\dennis\desktop\test.c
    ; Line 5
    	mov	eax, 15					; 0000000fH
    ; Line 6
    	ret	0
    _main	ENDP
    _TEXT	ENDS
    END
    


  • ^^ haste den code auch mal ganz ohne die 'const' ausprobiert. ich wette da kommt das gleiche raus.

    rüdiger schrieb:

    Im übrigen sind defines auch beim debuggen nervig.

    allerdings, da sind sie echt mies!
    🙂



  • fricky schrieb:

    ^^ haste den code auch mal ganz ohne die 'const' ausprobiert. ich wette da kommt das gleiche raus.

    rüdiger schrieb:

    Im übrigen sind defines auch beim debuggen nervig.

    allerdings, da sind sie echt mies!
    🙂

    Na dann erklär mal wie Sachen, die im zu kompilierenden Quelltext nicht auftauchen
    können das Debuggen beinflussen. Das ist wirklich hanebüchen.



  • fricky schrieb:

    ^^ haste den code auch mal ganz ohne die 'const' ausprobiert. ich wette da kommt das gleiche raus.

    Das ist anders, da ohne das const die sache veränderlich ist, und so theoretisch geändert werden kann(logisch, nicht?). Da die variable aber static ist und nirgends sonst genutzt wird, kann sie eigentlich entfernt werden, das wird sie aber wohl aus sicherheitsgründen nicht.

    Und dass die variable im speicher sein sollte ist auch klar sonst wäre ja &constVar unmöglich.



  • wurst schrieb:

    Und dass die variable im speicher sein sollte ist auch klar sonst wäre ja &constVar unmöglich.

    Der Compiler kann ja einfach entscheiden, ob er die Konstante in den Speicher packt, je nachdem ob man ihre Adresse anspricht oder nicht.



  • Scheppertreiber schrieb:

    fricky schrieb:

    ^^ haste den code auch mal ganz ohne die 'const' ausprobiert. ich wette da kommt das gleiche raus.

    rüdiger schrieb:

    Im übrigen sind defines auch beim debuggen nervig.

    allerdings, da sind sie echt mies!
    🙂

    Na dann erklär mal wie Sachen, die im zu kompilierenden Quelltext nicht auftauchen
    können das Debuggen beinflussen. Das ist wirklich hanebüchen.

    Denk doch bitte einmal nach, bevor du dich hier so aufführst. Es ist genau das Problem, dass es im Quelltext vorkommt, aber nicht beim "zu kompilierenden Quellcode". Für ein #define wird im Debugbuild kein Symbol angelegt, für ein enum oder ein const schon.

    @fricky
    Bei einem nicht const int kommt in diesem Fall natürlich das gleiche raus. Aber es ging ja um die Behauptung, dass bei einem const immer Speicher angelegt oder gar abgefragt werden muss. 🙂



  • Leider nicht überall 😮
    Und wenn ich jetzt auch bedenke das es ja wirklich _statisch_ ist(kompilation...) finde ich das auch verschwenderrisch.



  • Scheppertreiber schrieb:

    Na dann erklär mal wie Sachen, die im zu kompilierenden Quelltext nicht auftauchen
    können das Debuggen beinflussen. Das ist wirklich hanebüchen.

    wenn man durchs program steppt, sieht man bei enums das symbol, bei #defines nur den nackten zahlenwert. ganz furchtbar ist das debuggen, wenn man function-like macros hat. da geht fast gar nichts. d.h. macros, wenn sie als funktionsersatz dienen, müssen vorher gut getestet sein. genau so mit inline-funktionen. die sträuben sich auch oft gegen den debugger.

    wurst schrieb:

    Und dass die variable im speicher sein sollte ist auch klar sonst wäre ja &constVar unmöglich.

    kommt auf die verwendung an. so wie in rüdis code, wird überhaupt keine variable benötigt. also kann er sie komplett rausschmeissen.
    🙂



  • wurst schrieb:

    Leider nicht überall 😮
    Und wenn ich jetzt auch bedenke das es ja wirklich _statisch_ ist(kompilation...) finde ich das auch verschwenderrisch.

    das kann aber auch ein vorteil sein. wenn einem die platzierung wichtig ist, haben const-objekte schon ihre berechtigung:

    const char html[] = "<html><head>....</html>";  // 3 kB oder mehr
    ...
    // webserver auf einem microcontroller mit 8kB RAM und 256 kB FLASH
    if (request_received)
    {
       http_send (html, sizeof(html)-1);
    }
    ...
    

    ^^die webseite landet im read-only bereich (flash, ROM, ect), der viel grösser ist als der read-write memory (RAM).
    🙂



  • Aber hier ist ja das verhältnis zw. adressgröße und daten auch kleiner. Bei nem int oder einzelnem char-wert ist das meisten schlechter.



  • Er definiert die Stringlänge gleich 2mal, einmal durch SIZE und dann durch
    die Initialisierung des Strings. Es gibt nur recht wenige Spezialfälle wo so
    etwas Sinn machen könnte.

    ?

    #include <stdio.h>
    #include <string.h>
    
    int main() {
    	enum { SIZE=5 };
    	char array[SIZE] = "Test";
    	printf("1. %s\n", array);
    	strncpy(array, "Blah", SIZE-1);
    	printf("2. %s\n", array);
    	return 0;
    }
    

Anmelden zum Antworten