We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I am writing a header file with a series of #define statements, and since I use the '(' & ')' to surround many-many things, I comment these parenthesis pairings to ensure the correct matching set with some "ASCII Art" as seen below.
Using the Keil ARM IDE, I was getting funny/odd behavior where I had to re-define a #define value twice (redundantly redundant) before it 'found' the value...
// // ____________________________________________ // / __________________________________________ \ // / / ____ ________________________________ \ \ // / / / \ / \ \ \ #define SFR_T1_BASE_ADDR (*( (vu32 *) ( SFR_T1_BASE ) ) ) #define SFR_T1_BASE_ADDR (*( (vu32 *) ( SFR_T1_BASE ) ) ) #define SFR_T1_CR1 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CR1 ) ) ) #define SFR_T1_CR2 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CR2 ) ) ) #define SFR_T1_SMCR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_SMCR ) ) ) #define SFR_T1_DIER (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_DIER ) ) ) #define SFR_T1_SR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_SR ) ) ) #define SFR_T1_EGR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_EGR ) ) ) #define SFR_T1_CCMR1 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCMR1 ) ) ) #define SFR_T1_CCMR2 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCMR2 ) ) ) #define SFR_T1_CCER (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCER ) ) ) #define SFR_T1_CNT (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CNT ) ) ) #define SFR_T1_PSC (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_PSC ) ) ) #define SFR_T1_ARR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_ARR ) ) ) #define SFR_T1_RCR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_RCR ) ) ) #define SFR_T1_CCR1 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCR1 ) ) ) #define SFR_T1_CCR2 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCR2 ) ) ) #define SFR_T1_CCR3 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCR3 ) ) ) #define SFR_T1_CCR4 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCR4 ) ) ) #define SFR_T1_BDTR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_BDTR ) ) ) #define SFR_T1_DCR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_DCR ) ) ) #define SFR_T1_DMAR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_DMAR ) ) )
But after doing this ASCII art of 'comments pairing' on other #defines, I figured out why I had to double-up on (in this example) the SFR_T1_BASE_ADDR' value.
The '\' line continuation character in my 'ASCII art' was actually continuing the per-line "//" commenting so now this art looks like this... (and isn't as "pretty" as the above example either):
// // // ____________________________________________ // / __________________________________________ \ // / / ____ ________________________________ \ \ // / / / \ / \ \ \ // | | | | | | | | #define SFR_T1_BASE_ADDR (*( (vu32 *) ( SFR_T1_BASE ) ) ) #define SFR_T1_CR1 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CR1 ) ) ) #define SFR_T1_CR2 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CR2 ) ) ) #define SFR_T1_SMCR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_SMCR ) ) ) #define SFR_T1_DIER (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_DIER ) ) ) #define SFR_T1_SR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_SR ) ) ) #define SFR_T1_EGR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_EGR ) ) ) #define SFR_T1_CCMR1 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCMR1 ) ) ) #define SFR_T1_CCMR2 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCMR2 ) ) ) #define SFR_T1_CCER (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCER ) ) ) #define SFR_T1_CNT (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CNT ) ) ) #define SFR_T1_PSC (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_PSC ) ) ) #define SFR_T1_ARR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_ARR ) ) ) #define SFR_T1_RCR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_RCR ) ) ) #define SFR_T1_CCR1 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCR1 ) ) ) #define SFR_T1_CCR2 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCR2 ) ) ) #define SFR_T1_CCR3 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCR3 ) ) ) #define SFR_T1_CCR4 (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_CCR4 ) ) ) #define SFR_T1_BDTR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_BDTR ) ) ) #define SFR_T1_DCR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_DCR ) ) ) #define SFR_T1_DMAR (*( (vu32 *) ( SFR_T1_BASE + OFFSET_TIMx_DMAR ) ) )
I didn't know that it was ANSI standard for the '\' continuation to continue the double-slash "\\" per-line commenting.
I've always thought of the // scope as being a comment until the End-of-Line marker(s) (either the LF or LF+CR pair) has been reached... and was not continuable
Is this an error in the Keil IDE, or is this an error in my understanding of the "//" comment usage?
If it IS allowed to continue via the '\' character, then what is the point of using it versus the standard /* comment block */ ?
// This is a stupid example \ of a comment block which \ uses the non slash-asterisk \ asterisk-slash combination \ and it is allowed in Keil's \ <-- continue back-slash IDE "C/C++" compiler! <--- treats this as a comment due to the above '\' character.
Help me get clarification on this! (My 'ego troubles' are on edge)
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
p.s. When using the < pre > and < b > for showing 'code' in red, the underscore ('_') character doesn't show up in this forum.
The standard comes to the rescue, and I mean the C99 standard. The examples for the 'Comments' section (6.4.9) state that:
//\ i();
is a two-line comment. Even more interesting:
/\ \ j();
is a two-line comment too...
Oops, typo. I meant
/\ / j();
is a two-line comment too..