Hallo, ich will das gesamte Array mit einem Wert befüllen.
1 | #define PARAMETER_BUFF_SIZE 50
|
2 | |
3 | uint16_t parameter_id[PARAMETER_BUFF_SIZE]={0xFFFF}; |
So sollte es eigentlich klappen? Bei µVision leider nicht, hier wird nur "parameter_id[0]=0xFFFF".
|
Forum: Compiler & IDEs Array initialisieren in Keil![]() Hallo, ich will das gesamte Array mit einem Wert befüllen.
So sollte es eigentlich klappen? Bei µVision leider nicht, hier wird nur "parameter_id[0]=0xFFFF". :
Verschoben durch Moderator
Mein Array ist cool schrieb: > hier wird nur "parameter_id[0]=0xFFFF" Ja, und der Rest wird mit 0 befüllt. So will es die ISO-Norm. Falls gcc mit ISO C99:
uint32_t clean_code = 0; schrieb: > Falls gcc Der TE fragte nach Keil. > mit ISO C99: Die Initialisierung von Indexbereichen ist nicht ISO, sondern eine GCC-Erweiterung. Aber vielleicht hat der Keil-Compiler ja ein ähnliches Feature. Mein Array ist cool schrieb: > #define PARAMETER_BUFF_SIZE 50 > > uint16_t parameter_id[PARAMETER_BUFF_SIZE]={0xFFFF}; Ungetesstet, sollte aber mit keil, gcc, und ein paar anderen gehen, dank constructor attribut extension dieser Compiler:
Bei dem Gerödel frage ich mich auch wegen der Lesbarkeit, warum es denn nicht die gemeine Schleife tun soll. Und schneller wird es vermutlich auch nicht sein. Yalu X. schrieb: > uint32_t clean_code = 0; schrieb: >> Falls gcc > > Der TE fragte nach Keil. > >> mit ISO C99: > > Die Initialisierung von Indexbereichen ist nicht ISO, sondern eine > GCC-Erweiterung. Aber vielleicht hat der Keil-Compiler ja ein ähnliches > Feature. Zumindest Keil armclang v6 kann wohl GCC spezifischen Code übersetzen: http://www2.keil.com/mdk5/compiler/6/ Für armcc v5 sind einige extensions implementiert, weiß aber nicht wie vollständig das ist. Lutz schrieb: > Bei dem Gerödel frage ich mich auch wegen der Lesbarkeit, warum es denn > nicht die gemeine Schleife tun soll. Und schneller wird es vermutlich > auch nicht sein. Das sehe ich ganz genau so. All die ach so oberschlauen C-Programmierer, die am liebsten Typdeklaration+Variablendefinition+Initialisierung in ein einziges Statement quetschen wollen, verlassen sich eisern darauf, daß: 1. das ganze Initialisieren von RAM-Bereichen (nicht nur ausnullen) im Startupcode präzise erledigt wird, 2. es NIEMALS einen zweiten Systemanlauf nach dem Power-Up oder ein Nachinitialisieren von Teilfunktionen nach Teilausfällen geben darf. Dabei vergessen diese Leute ganz, daß es in jedem Fall irgend eine Schleife geben muß, egal ob im Startup oder in den Init-Routinen der eigentlichen Firmware. Kurzum, RAM-Vorbelegungen gibt es nirgendwo umsonst. W.S. W.S. schrieb: > Das sehe ich ganz genau so. > > [blahfasel] > > W.S. Und wo liegt da nun das Problem dabei? |
|