define DATE "01.12.2015" trennen

[Peter (Gast)]

Hallo,

ich möchte ein symbol, welches in der IDE (EW ARM) definiert ist 
trennen.
Speich ich habe ein
#define DATA "01.12.2015"
und möchte nun drei integer Werte mit Tag, Monat und Jahr daraus direkt 
definieren.

Klar könnte ich das ganze auch vom Controller umsetzen lassen und ich 
selbst würde auch lieber gleich den String verwenden doch leider habe 
ich die "A"-Karte bekommen und darf von einem alten Kollegen ein 
komplett vermurxtes Projekt übernehmen.

Peter

[Jörg W. (dl8dtl) (Moderator)]

#define DATE "01.12.2015"

int getday(void) {
  return (DATE[0] - '0') * 10 + (DATE[1] - '0');
}

int getmonth(void) {
  return (DATE[3]  - '0') * 10 + (DATE[4] - '0') ;
}

int getyear(void) {
  return (DATE[6] - '0')  * 1000 +
    (DATE[7] - '0')  * 100 +
    (DATE[8] - '0')  * 10 +
    (DATE[9] - '0') ;
}

[PittyJ (Gast)]

sollte auch mit sscanf gehen. In etwa so (nicht getestet):
sscanf(DATE,"%d.%d.%d",&day,&month,&year);

[Rolf M. (rmagnus)]

PittyJ schrieb:
> sollte auch mit sscanf gehen.

Ob der Compiler das aber noch so optimiert kriegt, daß das komplett zur 
Compilezeit durchgeführt wird?

[JensM (Gast)]

Auf folgender Seite gibt es entsprechende Makros:

http://stackoverflow.com/questions/11697820/how-to-use-date-and-time-predefined-macros-in-as-two-integers-then-stri


Gruß JensM

[Peter (Gast)]

Hallo Jörg,

danke hat geklappt

Wusste gar nicht, dass der Preprozessor auf einzelne Zeichen eines 
defines zugreifen kann.

[Rufus Τ. F. (rufus)]

Peter schrieb:
> Wusste gar nicht, dass der Preprozessor auf einzelne Zeichen eines
> defines zugreifen kann.

Das ist nicht der Präprozessor. Wie kommst Du darauf?

[Frank M. (ukw) (Moderator)]

Peter schrieb:
> Wusste gar nicht, dass der Preprozessor auf einzelne Zeichen eines
> defines zugreifen kann.

Macht er auch nicht. Er ist nur ein Textersetzer.

  return (DATE[0] - '0') * 10 + (DATE[1] - '0');

Aufgelöst:

  return ("01.12.2015"[0] - '0') * 10 + ("01.12.2015"[1] - '0');

Gekürzt:

  return ('0' - '0') * 10 + ('1' - '0');

Terme ausgerechnet:

  return 1;

Das genau macht der Compiler.

Man hätte diese Funktionen übrigens auch als Makros schreiben können.

[Rolf Magnus (Gast)]

Frank M. schrieb:
> Man hätte diese Funktionen übrigens auch als Makros schreiben können.

Zumindest sollte man sie static deklarieren, damit nicht unnötig eine 
non-inline-Version für den Aufruf von außen erzeugt wird.

[Jörg W. (dl8dtl) (Moderator)]

In C++ kann man es auch komplett in Konstanten packen:

#define DATE "01.12.2015"

const int day = (DATE[0] - '0') * 10 + (DATE[1] - '0');
const int month = (DATE[3]  - '0') * 10 + (DATE[4] - '0') ;
const int year = (DATE[6] - '0')  * 1000 +
    (DATE[7] - '0')  * 100 +
    (DATE[8] - '0')  * 10 +
    (DATE[9] - '0') ;

In C geht das aber nicht, das gibt ein “initializer element is not 
constant”.

[Walter T. (nicolas)]

Frank M. schrieb:
> "01.12.2015"[0]

Sehr interessant. Ich wußte gar nicht, daß diese Schreibweise 
funktionieren kann.

[Chriss (Gast)]

C-Buch :-)

[Peter II (Gast)]

Walter T. schrieb:
>> "01.12.2015"[0]
>
> Sehr interessant. Ich wußte gar nicht, daß diese Schreibweise
> funktionieren kann.

du kannst sogar

0["01.12.2015"];

schreiben

[Johann L. (gjlayde)]

Jörg W. schrieb:
> In C++ kann man es auch komplett in Konstanten packen:

Hast du eine Erklärung, warum g++ 4.7 folgendes macht?

char c = "Hallo"[3];

.section  .text.startup,"ax",@progbits
  .type  _GLOBAL__sub_I_c, @function
_GLOBAL__sub_I_c:
  ldi r24,lo8(108)
  sts c,r24
  ret

  .size  _GLOBAL__sub_I_c, .-_GLOBAL__sub_I_c
  .global __do_global_ctors
.section .ctors,"a",@progbits
  .p2align  1
  .word  gs(_GLOBAL__sub_I_c)
.global  c
  .section .bss
  .type  c, @object
  .size  c, 1
c:
  .zero  1
  .ident  "GCC: (GNU) 4.7.2"

[Jörg W. (dl8dtl) (Moderator)]

Johann L. schrieb:
> Hast du eine Erklärung, warum g++ 4.7 folgendes macht?

Nö.  4.9 macht's nicht mehr:

        .file   "foo.C"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
.global c
        .data
        .type   c, @object
        .size   c, 1
c:
        .byte   108
        .ident  "GCC: (GNU) 4.9.3"
.global __do_copy_data

[Rolf Magnus (Gast)]

Walter T. schrieb:
> Frank M. schrieb:
>> "01.12.2015"[0]
>
> Sehr interessant. Ich wußte gar nicht, daß diese Schreibweise
> funktionieren kann.

Warum sollte sie nicht? "01.12.2015" ist vom Typ Array aus const char, 
und [0] ist die Schreibweise, um ans erste Element eines Arrays zu 
kommen. Kombiniere beides, und schon hast du das obige.
Es ginge z.B. auch:

const char* tmp = 3+"01.12.2015";
int monat = *tmp* 10+1 [tmp];

Zugegeben sehr unverständlich geschrieben. Hach, C kann so schön sein 
;-)

[Matthias H. (hallamen)]

Johann L. schrieb:
> Hast du eine Erklärung, warum g++ 4.7 folgendes macht?

g++ 4.7 mit -std=c++11 optimiert den Ausdruck. Wenn man schon C++11 
verwendet, kann man auch const durch constexpr ersetzen, damit ist eine 
Auswertung zur comile-time garantiert.

#define DATE "01.12.2015"

constexpr int day = (DATE[0] - '0') * 10 + (DATE[1] - '0');
constexpr int month = (DATE[3]  - '0') * 10 + (DATE[4] - '0') ;
constexpr int year = (DATE[6] - '0')  * 1000 +
    (DATE[7] - '0')  * 100 +
    (DATE[8] - '0')  * 10 +
    (DATE[9] - '0') ;

[Jörg W. (dl8dtl) (Moderator)]

Matthias H. schrieb:
> g++ 4.7 mit -std=c++11 optimiert den Ausdruck.

Optimiert wurde er ja oben auch, nur eben dieses seltsame
_GLOBAL__sub_I_c generiert, welches vermutlich als statischer
Konstruktor den Initialwert setzen soll, statt das gleich dem
Assembler zu überlassen.

Kann sein, dass der Artefakt nur beim AVR-GCC auftritt.

[Jörg W. (dl8dtl) (Moderator)]

Johann L. schrieb:
> Hast du eine Erklärung, warum g++ 4.7 folgendes macht?

Scheint übrigens eine reine GCC-4.7-Macke zu sein.  Ich habe hier auf
dem FreeBSD einen GCC 4.7 und einen 4.8 (Host-CC ist ja bei FreeBSD
inzwischen ohnehin Clang).

GCC 4.7:

        .file   "foo.C"
        .section        .text.startup,"ax",@progbits
        .type   _GLOBAL__sub_I_c, @function
_GLOBAL__sub_I_c:
.LFB1:
        .cfi_startproc
        movb    $108, c(%rip)
        ret
        .cfi_endproc
.LFE1:
        .size   _GLOBAL__sub_I_c, .-_GLOBAL__sub_I_c
        .section        .ctors,"aw",@progbits
        .align 8
        .quad   _GLOBAL__sub_I_c
        .globl  c
        .bss
        .type   c, @object
        .size   c, 1
c:
        .zero   1
        .ident  "GCC: (FreeBSD Ports Collection) 4.7.4"
        .section        .note.GNU-stack,"",@progbits

GCC 4.8:

        .file   "foo.C"
        .globl  c
        .data
        .type   c, @object
        .size   c, 1
c:
        .byte   108
        .ident  "GCC: (FreeBSD Ports Collection) 4.8.3"
        .section        .note.GNU-stack,"",@progbits

Was auch immer sie sich mit dieser Art Initialisierung gedacht haben.

[Peter (Gast)]

Das hier generiert der IAR Compiler

        #define SHT_PROGBITS 0x1

        EXTERN printf

        PUBLIC Tag
        PUBLIC main


        SECTION `.rodata`:CONST:REORDER:NOROOT(2)
        DATA
        DC8 "%i"
        DC8 0

//    1 
//    2 
//    3 #define DATE "01.12.2015"
//    4 

        SECTION `.rodata`:CONST:REORDER:NOROOT(2)
        DATA
//    5 const int Tag = (DATE[0]-'0')*10 + (DATE[1]-'0');
Tag:
        DC32 1
//    6 

        SECTION `.text`:CODE:NOROOT(2)
        THUMB
//    7 int main()
//    8 {
main:
        PUSH     {R7,LR}
//    9   printf("%i", Tag);
        LDR      R0,??main_0
        LDR      R1,[R0, #+0]
        ADR      R0,??main_0+0x4  ;; 0x25, 0x69, 0x00, 0x00
        BL       printf
//   10   return 0;
        MOVS     R0,#+0
        POP      {R1,R3}
        BX       R3               ;; return
        Nop      
        DATA
??main_0:
        DC32     Tag
        DC8      0x25, 0x69, 0x00, 0x00
//   11 }

        SECTION `.iar_vfe_header`:DATA:NOALLOC:NOROOT(2)
        SECTION_TYPE SHT_PROGBITS, 0
        DATA
        DC32 0

        END

[Joachim B. (jar)]

Jörg W. schrieb:
> return (DATE[0] - '0') * 10 + (DATE[1] - '0');

geiler Code, die Einsparung war zwar nicht umwerfend, aber immerhin 158 
Byte!

im Prinzip wusste ich es noch, nur war ich unsicher ob das mit _DATE_ 
und "21.05.2015" klappt

nur _DATE_ hat eine Besonderheit, es gibt bei Tag keine führende NULL

deswegen:
(__DATE__[4]==' ') ? ta = __DATE__[5] - '0' : ta = (__DATE__[4] - '0') * 
10 + __DATE__[5] - '0';

[Jörg W. (dl8dtl) (Moderator)]

Deja-vu:

Beitrag "Re: Andere Formatierung für _DATE_ odere andere Funktion?"

[Peter (Gast)]

Mit dem _DATE_ wäre ich auch etwas vorsichtig bei unterschiedlichen 
compilern, bei dem von IAR kommt bei _DATE_ raus: "Dec  3 2015"

[Jörg W. (dl8dtl) (Moderator)]

Peter schrieb:
> bei dem von IAR kommt bei DATE raus: "Dec  3 2015"

Ernsthaft?

Der Standard sagt:

6.10.8.1 Mandatory macros

The following macro names shall be defined by the implementation:

__DATE__ The date of translation of the preprocessing translation
         unit: a character string literal of the form "Mmm dd yyyy",
         where the names of the months are the same as those generated
         by the asctime function, and the first character of dd is a
         space character if the value is less than 10. If the date of
         translation is not available, an implementation-defined valid
         date shall be supplied.

[Paul B. (paul_baumann)]

Jörg W. schrieb:
> The following macro names shall be defined....

Soll defininiert werden...
Ist vielleicht aber nicht?

MfG Paul

Rolf Magnus schrieb:
> Hach, C kann so schön sein
> ;-)

Kann. Muß nicht.

[Frank M. (ukw) (Moderator)]

Jörg W. schrieb:
> Peter schrieb:
>> bei dem von IAR kommt bei DATE raus: "Dec  3 2015"
>
> Ernsthaft?
>
> Der Standard sagt:
>
>

> 6.10.8.1 Mandatory macros
> 
> The following macro names shall be defined by the implementation:
> 
> __DATE__ The date of translation of the preprocessing translation
>          unit: a character string literal of the form "Mmm dd yyyy",
>          where the names of the months are the same as those generated
>          by the asctime function, and the first character of dd is a
>          space character if the value is less than 10. If the date of
>          translation is not available, an implementation-defined valid
>          date shall be supplied.
>

Ich sehe da keinen Widerspruch, sondern eher die Bestätigung, dass sich 
IAR daran hält.

Mmm  = "Dec"
dd   = " 3" (mit führendem Leerzeichen, wenn dd < 10)
yyyy = "2015"

Also: "Mmm dd yyyy" <=> "Dec  3 2015"

Passt doch. Oder habe ich da etwas missverstanden?

[Peter (Gast)]

Ich würde auch sagen das das so korrekt ist.
zum Glück kann man bei iar die Variable aus der IDE $DATE$ in ein Symbol 
konvertieren und nutzen.
Da steht dann  03.12.2015 drin.

Die Variante von Jörg auf DeJa Vu ist etwas eleganter.

Peter

[Jörg W. (dl8dtl) (Moderator)]

Paul B. schrieb:
>> The following macro names shall be defined....
>
> Soll defininiert werden...

Paul, Englisch ist nicht so deine Stärke.  Standard-Kaudwerwelsch
erst recht nicht.

„shall“ in einem Standard ist eine bindende Verpflichtung.

Frank M. schrieb:
> Ich sehe da keinen Widerspruch, sondern eher die Bestätigung, dass sich
> IAR daran hält.

OK, oben hattest du zwischen „Dec“ und „3“ nur ein Leerzeichen.

Das mit dem führenden Leerzeichen (statt Vornull) ist ja in den weiter
oben beschriebenen Makros sauber abgefangen, d. h. diese Makros sind
portabel.  (Meine Variante hatte das nicht, aber der TE hatte ja
auch nicht _DATE_ geschrieben, sondern hatte die Vornull in seinem
DATE mit drin.)

Peter schrieb:
> zum Glück kann man bei iar die Variable aus der IDE $DATE$ in ein Symbol
> konvertieren und nutzen

Bei anderen Build-Systemen macht man das halt übers Makefile, sowas
war im oben verlinkten Thread ausgiebig diskutiert worden.

Die Variante, die rein mit dem C-Standard auskommt, hat aber natürlich
einen Bonus, da sie von keinerlei externem System abhängt.

[Frank M. (ukw) (Moderator)]

Jörg W. schrieb:
> OK, oben hattest du zwischen „Dec“ und „3“ nur ein Leerzeichen.

Frank M. schrieb:
> Also: "Mmm dd yyyy" <=> "Dec  3 2015"
                              ^^

Nö, 2 :-)

[Jörg W. (dl8dtl) (Moderator)]

Frank M. schrieb:
> Nö, 2 :-)

Frank, ich meinte doch nicht dich, sondern einen „Peter“, der weiter
oben behauptet hatte, der IAR würde das anders machen:

Beitrag "Re: define DATE "01.12.2015" trennen"

[Frank M. (ukw) (Moderator)]

Jörg W. schrieb:
> Frank, ich meinte doch nicht dich,

Achso, dachte ich nur, weils unter meinem Zitat stand.

> sondern einen „Peter“, der weiter
> oben behauptet hatte, der IAR würde das anders machen:
>
> Beitrag "Re: define DATE "01.12.2015" trennen"

Da lese ich:

Peter schrieb:
> Mit dem DATE wäre ich auch etwas vorsichtig bei unterschiedlichen
> compilern, bei dem von IAR kommt bei DATE raus: "Dec  3 2015"
                                                      ^^

Auch 2 :-)

Aber egal, ich denke mal, der IAR machts richtig.

[Jörg W. (dl8dtl) (Moderator)]

Frank M. schrieb:
> Auch 2 :-)

Hmm, Mift.  Sorry.  Ich habe hier die Forums-Variante mit
Proportionalschrift, und selbst wenn man das dort mit der Maus
markiert (siehe Screenshot), sieht man nur ein Leerzeichen.
Nur in der Monospace-Schrift sieht man es richtig.

> Aber egal, ich denke mal, der IAR machts richtig.

Ja, auf jeden Fall.

Sorry für die Konfusion.

[Frank M. (ukw) (Moderator)]

Jörg W. schrieb:

> Hmm, Mift.  Sorry.  Ich habe hier die Forums-Variante mit
> Proportionalschrift,

Sieht so aus, als ob diese Variante mehrfach hintereinander vorkommende 
Spaces zu einem Space "komprimiert". Sieht man auch an meinen beiden 
Pfeilen, die ich unter die Spaces positioniert hatte, um sie zu 
kennzeichnen. In Deinem Screenshot stehen sie ganz links am 
Zeilenanfang.

Hm, vielleicht ist das zu viel des Guten...

[Carsten S. (dg3ycs)]

Hi,

ist zwar schon grob OFF TOPIC, aber da die Anfangsfrage ja schon 
vollstaendig zur Zufriedenheit beantwortet ist sollte das klar gehen:

Jörg W. schrieb:
> Paul B. schrieb:
>>> The following macro names shall be defined....
>>
>> Soll defininiert werden...
>
> Paul, Englisch ist nicht so deine Stärke.  Standard-Kaudwerwelsch
> erst recht nicht.

Doch, seine Uebersetzung ist schon OK, nur seine (und deine!) 
Interpretation des deutschen Textes laesst dann zu wuenschen uebrig!
>
> „shall“ in einem Standard ist eine bindende Verpflichtung.

Genau wie das deutsche soll - zumindest im juristischen Sinne.
ALso wenn das Wort in Gesetzen, Verordnungen, Urteilen, Richtlinien, 
aber auch Arbeitsanweisungen, Normen / Standards usw. auftaucht.
Da gilt immer: "Soll == Muss wenn kann/moeglich"

Damit gilt, wenn immer dort "soll" steht, MUSS das gemacht werden so 
lange es keine ernstzunehmenden Verhinderungsgruende gibt. Erst wenn es 
diese ernsthaften Hindernisse gibt kann auf die Ausfuehrung verzichtet 
werden.

Halt im Gegensatz zum "muss", wo bei ernsthaften Verhinderungsgruende 
diese Hindernisse ebend zwingend beseitigt werden muessen um das 
aufgegebene Umzusetzen.(das es dennoch Grenzen gibt muss ich ja wohl 
nicht extra erwaehnen)

Daher ist sein uebersetzter Text also durchaus vom Sinn her mit dem 
englischen identisch!

Gruss
Carsten

[Jörg W. (dl8dtl) (Moderator)]

Carsten S. schrieb:

> Daher ist sein uebersetzter Text also durchaus vom Sinn her mit dem
> englischen identisch!

Allerdings hatte er im nächsten Satz angezweifelt, ob es wirklich
wäre.  Das klingt eher wie das umgangssprachlich-deutsche „das sollst
du doch aber so tun!“

Als Referenz die Beschreibung aus dem C-Standard selbst:

In this International Standard, ``shall'' is to be interpreted as a requirement on an
implementation or on a program; conversely, ``shall not'' is to be interpreted as a
prohibition.

Ich finde das etwas stärker bindend als die im Deutschen übliche
Verwendung von „soll“, aber das ist Ansichtssache.  Wenn man sowas
in einem Gesetzestext findet, dann hat's vermutlich in der Tat die
gleiche Bindungskraft.

[Paul B. (paul_baumann)]

Gut, dann sollte ich das anerkennen.
;-)

MfG Paul

[Konrad S. (maybee)]

Viele Spezifikationen nutzen RFC 2119 "Key words for use in RFCs to 
Indicate Requirement Levels".
https://www.ietf.org/rfc/rfc2119.txt

[Carsten S. (dg3ycs)]

Konrad S. schrieb:
> Viele Spezifikationen nutzen RFC 2119 "Key words for use in RFCs to
> Indicate Requirement Levels".
> https://www.ietf.org/rfc/rfc2119.txt

Ok,
dann bin doch ich der der falsch liegt...  ;-)

MUSS wäre dann die (sinngemäß) einzig 100% korrekte Übersetzung,
nicht bloß "muss wenn möglich%...

Gruß
Carsten

[Rolf M. (rmagnus)]

"Muss" heißt für mich "geht gar nicht anders" (wir müssen alle 
irgendwann sterben). "Soll" dagegen heißt, dass man zwar eine Wahl hat, 
aber schlimme Dinge passieren, wenn man das "soll" nicht beachtet (du 
sollst nicht stehlen). "Sollte" ist dann eine demgegenüber stark 
abgeschwächte Variante (ich sollte mal wieder mein Auto waschen).

[Johann L. (gjlayde)]

Jörg W. schrieb:
> Host-CC ist ja bei FreeBSD inzwischen ohnehin Clang.

Ist der inzwischen so viel besser als GCC?

[Jörg W. (dl8dtl) (Moderator)]

Johann L. schrieb:
> Jörg W. schrieb:
> Host-CC ist ja bei FreeBSD inzwischen ohnehin Clang.
>
> Ist der inzwischen so viel besser als GCC?

Was die genauen Beweggründe für diese Entscheidung waren, kann ich
dir jetzt nicht sagen.  Lässt sich sicher in einer Mailingliste
nachlesen.  Kann durchaus auch erstmal lizensmäßig von Interesse
sein (LLVM/Clang haben BSD-Lizenz, passen damit besser zu einem
BSD-Projekt als GCC).

Qualitätsmäßig fiel er zumindest dadurch auf, dass bei der Umstellung
auf Clang deutlich mehr an Warnungen kamen, die durchaus berechtigt
sind, d. h. Dinge, die der GCC nicht diagnostiziert hatte.  Auch sind
die Fehlermeldungen meiner Erinnerung nach detaillierter gewesen, da
hat GCC aber mittlerweile nachgezogen.