Boost C Wiki - Electronic Circuits Projects Diagrams Free

BeeBop · 21st January 2009, 06:49 PM

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

BoostC tiny Wiki - Open Circuits

russ_hensel · 28th January 2009, 04:43 PM

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 · 29th January 2009, 09:36 AM

Quote:

Originally Posted by 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.

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

Pommie · 29th January 2009, 02:14 PM

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,

Code:

/*
* 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 · 29th January 2009, 02:33 PM

"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 · 29th January 2009, 02:46 PM

Quote:

Originally Posted by russ_hensel

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 · 29th January 2009, 02:49 PM

Quote:

Originally Posted by Pommie

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 · 29th January 2009, 02:56 PM

Quote:

Originally Posted by russ_hensel

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

Do you often answer in riddles?

Mike.

futz · 29th January 2009, 04:01 PM

Quote:

Originally Posted by Pommie

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 · 29th January 2009, 05:11 PM

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 · 29th January 2009, 06:09 PM

Quote:

Originally Posted by 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....

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 · 29th January 2009, 11:49 PM

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.

*The New Hacker's Dictionary

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

***Ibsen, Henrik quote - The majority is always wrong; the minority is rarely right....

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

Pavius · 30th January 2009, 08:10 AM

Quote:

Originally Posted by Pommie

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:

Code:

#if 0

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

#endif

Pommie · 30th January 2009, 01:37 PM

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 · 30th January 2009, 02:39 PM

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

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar
Title	Starter	Forum	Replies	Latest
What do you think of an Electronics Wiki site?	ElectroMaster	Chit-Chat	49	12th August 2008 05:59 PM
Wiki images	Mikebits	Electronics Wiki	4	8th August 2008 10:04 AM
Electronics Wiki - About the site	ElectroMaster	Electronics Wiki	0	7th August 2008 12:51 PM
The Junebug featured on the Swordfish BASIC Wiki	blueroomelectronics	Micro Controllers	4	5th July 2008 07:01 AM
signal boost+treble boost circuit	mlugg	Electronic Projects Design/Ideas/Reviews	8	30th September 2007 04:10 PM

21st January 2009, 06:49 PM	#1
BeeBop	Boost C Wiki Just to let you all know there is now a Boost C Wiki online at: BoostC tiny Wiki - Open Circuits

28th January 2009, 04:43 PM	#2
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.

29th January 2009, 02:14 PM	#4
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, Code: /* * 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. Last edited by Pommie; 29th January 2009 at 02:16 PM.*

29th January 2009, 02:33 PM	#5
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.

29th January 2009, 05:11 PM	#10
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....

29th January 2009, 11:49 PM	#12
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. The New Hacker's Dictionary 'Snark: It's Mean, It's Personal, and It's Ruining Our Conversation' by David Denby - Los Angeles Times Ibsen, Henrik quote - The majority is always wrong; the minority is rarely right.... **Roman numerals - Wikipedia, the free encyclopedia

30th January 2009, 01:37 PM	#14
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.

30th January 2009, 02:39 PM	#15
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 __________________ Please post questions to the forums. PM's are for personal communication. BCHS/3v0's Tutorials Junebug USB PIC programmer kit., USB Bit Whacker, The 15 Minute Printed Circuit Board! (+drill time)