Boost C Wiki

[BeeBop]

Just to let you all know there is now a Boost C Wiki online at:

**broken link removed**

 

[russ_hensel]

I am the author of a good bit of it. It is still new and small, we could use some help adding to it. Also consider linking topics here to it, if they are good reference topics. Forums and Wikis are complementary sources, Forums for q and a and discussion, Wiki's for "resolved' issues.

 

[BeeBop]

I am the author of a good bit of it. It is still new and small, we could use some help adding to it. Also consider linking topics here to it, if they are good reference topics. Forums and Wikis are complementary sources, Forums for q and a and discussion, Wiki's for "resolved' issues.

Hi Russ, welcome here!
Yes I noticed... thanks for starting it.

 

[Pommie]

Can I mention something that really bugs me. In the document you link to in the wiki, C-Styles it uses the block rem instead of line rem.

For example,

/*
* Find the last element in the linked list
* pointed to by nodep and return a pointer to it.
* Return NULL if there is no last element.
*/
    node_t *
tail(nodep)
    node_t *nodep; 		/* pointer to head of list */
{
    register node_t *np; 	/* advances to NULL */
    register node_t *lp; 	/* follows one behind np */
    if (nodep == NULL)
        return (NULL);
    for (np = lp = nodep; np != NULL; lp = np, np = np->next)
        ; 			/* VOID */
    return (lp);
}

This is just so annoying and wrong. Single line comments should use the line comment (//) not the block comment. How on earth do I block comment this code so I can try a different version. If I put /* at the beginning of this code and */ at the end it should be remmed out but as the idiotic programmer has used block rem on single lines I can't use it as it was intended.

And, this is from a document on C styles! It makes me wonder who wrote it and would advise that you should find a better one.

BTW, I love BoostC.

Mike.

 

[russ_hensel]

comments on comments

"wrong" so cold.

Correct is open to a lot of interpertation. I programmed professionally for a long time and none of us could agree on much ( this was not in C, where I am a beginner )

Since it is a wiki, why not write a bit about your version of the truth?

To answer your question block comments should be implemented by the IDE, highlight the area to comment and press something <buttion, icon, magic key>, each line is commented by a // at the beginning of the line. See netbeans for one of the many ide's that does this.

You will notice that all my block comments are of this form. I have asked the BoostC team to add it to their IDE.

If it were up to me I would eliminate the /* */ style of commenting. But I would leave it for those who like it.

I put a comment on the end of the line if it comments only that line, I use a block comment for comments that are too long or apply to a block of code. I think it make sense, but opinions differ.

We agree about boostc which is a much bigger issue.

 

[Pommie]

To answer your question block comments should be implemented by the IDE, highlight the area to comment and press something <buttion, icon, magic key>, each line is commented by a // at the beginning of the line. See netbeans for one of the many ide's that does this.

We'll have to agree to differ on this point, C files are text files and should be editable in any text editor. The idea of an IDE that block rems by using line rem is just as bad as the opposite way around. When I unrem it, how will the IDE know which lines I want left commented? The two types of comments were designed into the language because both are needed.

Anyway, welcome to the forum and good job on the wiki. When I get some time I'll try to contribute.

Mike.

 

[russ_hensel]

We'll have to agree to differ on this point, C files are text files and should be editable in any text editor. The idea of an IDE that block rems by using line rem is just as bad as the opposite way around. When I unrem it, how will the IDE know which lines I want left commented? The two types of comments were designed into the language because both are needed.

Anyway, welcome to the forum and good job on the wiki. When I get some time I'll try to contribute.

Mike.

Out of heat, light will come. I am often wrong. But this time.....

Thanks for the welcome.

 

[Pommie]

Out of heat, light will come. I am often wrong. But this time.....

Do you often answer in riddles?

Mike.

 

[futz]

This is just so annoying and wrong. Single line comments should use the line comment (//) not the block comment.

Have to agree. Using block comments everywhere is just strange.

 

[BeeBop]

I've downloaded that PDF, and will have to take a look.

I do agree, that block comments on a line are annoying...

and I prefer the opening brace on the same line, rather than the line below, but then I think that issue is style....

 

[3v0]

I've downloaded that PDF, and will have to take a look.

I do agree, that block comments on a line are annoying...

and I prefer the opening brace on the same line, rather than the line below, but then I think that issue is style....

I agree on the comments.

The opeing brace is a mixed issue in my mind. For teaching I use the open brace on its own line because it is easier to see the code block. At the same time it would be nice to have that line back.

 

[russ_hensel]

The final comment on comments

OK you guys are forcing me into full troll* mode, I am going to have to get a bit snarky** with you.
I have googled the practice a bit, and that combined with the fact that 3 of 4 posters disagree with me only proves that I am right as the majority is always wrong***

The idea that code should be editable in any old junky editor ( u guys probably like 6 **** ), or even that code should be editable is so 20 th century ( over, yesterday's news..... )

It is tempting to loose (post) this argument on the piclist.com where people seem to think all coding should be in asm unless you are a wimp. They could probably spin this out to 1000 posts. Any of you guys post there? Just what I thought.

Finally, if nothing else, my use of footnotes shows the superiority of my view.

***broken link removed**

**'Snark: It's Mean, It's Personal, and It's Ruining Our Conversation' by David Denby - Los Angeles Times

*****broken link removed**

****Roman numerals - Wikipedia, the free encyclopedia

 

[Pavius]

This is just so annoying and wrong

You cannot understand how important sticking to ANSI is until you have to compile a large project with different compilers. // is not ANSI C - sure, most compilers support it but some don't.

If you want to "comment out" the aforementioned block of code, just use preprocessor directives:

#if 0

/* do some arbitrary thing */
do_something();

#endif

 

[Pommie]

I'm going to have to disagree again, quoting a standard set in 1989 as the way it should be done when every C compiler vendor has realized there is a better way is just being pedantic. As this was a thread about pic chips, Microchip recognizes the importance of identifying commented code and turns it green. Code that is commented with a #if does not change colour and so is not immediately recognized as removed. I suspect this is the same for most vendors.

I'll be interested if you can identify a compiler that was written in the last 5 years (a millennium in computer terms) that does not support the line comment.

Mike.

 

[3v0]

Agreed.

I am not a big advocate of strict compliance to ANSI C on microprocessors.

The ANSI standard does not address some issures that are important to embedded systems. For this reason sources are specific to the compiler vendor ANSI or not.

After a little googling I found the ISO 9899 standard C. Maybe it is less dated then ANSI C.

ISO 9899 comliance is required by MISRA C guide.

MISRA C guide: In 1998, the UK's Motor Industry Software Reliability Association established a set of 127 guidelines for the use of C in safety-critical systems.
​

It is said the coding in compliance with MISRA-C guidelines is about as close as you can get to an "embedded C" standard. I am going to give it a closer look.

3v0

 

[Pavius]

Microchip recognizes the importance of identifying commented code and turns it green... I suspect this is the same for most vendors.

I understand your point regarding "moving forward". However, I myself do not see the cost of sticking to ANSI C - only the benefit. Taking Microchip (we're talking about MPLAB i assume) as an example for a C editor vendor is just plain funny. MPLAB is such a dated, simplistic, amateur and at many times agonizing environment to develop C. Any modern IDE recognizes #if 0 blocks and allows for syntax coloring (visual studio, eclipse, visual slickedit, emacs, etc)

 

[Pommie]

You may understand my point but you choose to pick out one part of my reply and criticize it. You did not answer my main query, can you identify a compiler written in the last 5 years that doesn't support line rem?

As for MPLAB being dated, you are correct. However, I just checked codeblocks and it colour codes comments (block or line) but does not colour code #if 0s. Maybe that is retarded as well!!

Thinking about it, how would VC know to colour code a #if as the editor wouldn't know the outcome of the boolean expression?

Mike.

 

[Pavius]

By saying that i understand your point, i mean that you are right to assume that probably all C compilers written recently support //. However, since #if 0 blocks support the functionality you claimed was missing, i just think i'd rather stick to ANSI C in this case. To each his own

As for editors, #if 0 always evaluates to false (just like #if 1 always evaluates to true) - therefore editors know to color the block. Moreover, recent editors even support evaluating the boolean expression themselves so things like #ifdef SOME_CONDITION will actually be checked per instance and colored accordingly. This supports nice features like showing only code that will not be excluded by the preprocessor.