#message

"Does anyone here ever use #message in other compilers?"

I kind of doubt it, since it is not part of Standard C.

"Does anyone here ever use #message in other compilers?"

I kind of doubt it, since it is not part of Standard C.

#error and #warning are the standard message directives. #error stops processing, #warning emits the warning and continues processing.

There was a thread a couple of weeks ago where someone had code with a "#pragma echo".

Thanks for the response.
I realize it is not in the kernigan richie book, but I have seen it in other compilers and other books.
It can be useful, though I understand that if someone did not know it existed, they would not use it.
For and example of its use, if you want to test the version of something and do different things based on what you find in a header, then you print a message as some you may want to reserve warnings for things people really should take care of.

What are your thoughts?

"#error and #warning are the standard message directives."

To my knowledge, #warning is not part of Standard C either.

its simple

#ifdef I_WANT_AN_ERROR_MESSAGE
I screwed up
#endif

Will work just fine

Erik

"What are your thoughts?"

My thoughts are to not use facilities or extensions that are not part of the standard language unless there is absolutely no other way to accomplish a task. Since Standard C lacks a facility for echoing anything other than error messages (using #error), I echo build variation messages to a user using the command shell. I specify what I want to build to the make tool, which then passes the appropriate macro values to the compiler (subsequently choosing appropriate values and conditional compile paths in the C source and header files) and uses the shell for echoing messages telling the user what it's doing.

I should have been more clear, here is an example.

At the top of your code you have the following #defines

#define DEBUG
#define PORT_PINS_ON ..... // there may be lots of these
//#define PUT_IN_IMPORTANT_CUSTOMER_CODE

in your code you put:
#ifdef DEBUG
#message "Compiled in debug"
//c debug source code
#else
#message "No debug"
//c debug source code
#endif

#ifdef PUT_IN_IMPORTANT_CUSTOMER_CODE
#message "The customer will be happy you put back in their code, this code slows things down during debug or masks an issue so you took it out, but all is well now"
//c debug source code
#else
#message "You just compile this code in a way that makes the cusomer mad, but is not a big deal to you"
//c debug source code
#endif

When you compile your code, you see:
Compiled in debug
You just compile this code in a way that makes the cusomer mad, but is not a big deal to you

Both of these conditions are not errors. You might argue that the customer code is a warning, but it would have been nice to know that you compiled in debug instead of having to burn a chip and test it to find out.

This is just an example. Sometimes if your code is made to run in many different ways based on the hardware you run the code on, it helps to get messages.

I may be naive, but that sounds like you are not using MicroVision2.
If you want to use the ide, then I think what you suggest may be complicated (could be wrong on this though)

"If you want to use the ide, then I think what you suggest may be complicated"

Although I haven't actually tried it, I think it should be quite easy using the Custom Translation facility...?

"...that sounds like you are not using MicroVision2."

Ah yes, you are correct. Given the number of different processors and toolchains I deal with, I don't use anybody's IDE except for simulation/debug. Just like I design firmware to be as processor-independent as I possibly can, I use a build environment that is as toolchain-independent as I can possibly get it. I can't afford to be hamstrung dealing with vendors' IDE idiosyncrasies for editing, building, etc.

"If you want to use the ide..."

Now why would I want to do that? ;-)

"...then I think what you suggest may be complicated (could be wrong on this though)"

I think you'd be right (but I could be wrong).

I see your logic.
I was given, a month to develop lots of code, and some sample code written in this environment that did some of the things I wanted.

That made it easy for me to decide; use the sample code and the ide. Now I am fine tuning.

I said, "I don't use anybody's IDE..."

I don't mean to imply that Keil's IDE is bad, so don't get me wrong. Keil's IDE is nice as far as IDEs are concerned.

Now if all vendors plugged into a common flexible IDE like Eclipse, I might start using an IDE.

To my knowledge, #warning is not part of Standard C either.

Your knowledge is apparently correct. At least from skimming the n869 draft for ISO C99, I don't see #warning mentioned. I was under the delusion it had been added for C99. But apparently not, and #warning is still just a non-standard extension (common or not).

At the top of your code you have the following #defines

Hold it right there. You're causing yourself problems you don't need by doing it this way. Definitions of macros used to control build features of the code don't belong into the source code itself. Once they're in there, they're needlessly hard to get out again, as you're just finding out.

I would strongly suggest you use flags passed to the compiler on its invocation instead (-DDEBUG=1 etc., for most C compilers). That way, they'll be plainly visible to you in the make run's screen output (and in the .lst file, too). The visible hint won't be quite as wordy as your #message, but it's right there in front of your eyes.

In uV2 you would use multiple targets in the same project, using the same set of source files, but with different flags each, to achieve the same effect.