Re: Pascal -> C

Nick Keighley wrote, On 22/10/08 11:54:
On 22 Oct, 10:28, Ian Collins <ian-n...@xxxxxxxxxxx> wrote:
Nick Keighley wrote:
On 22 Oct, 09:25, r...@xxxxxxxxxxxxxxxxxxxxxx (Richard Bos) wrote:
Nick Keighley <nick_keighley_nos...@xxxxxxxxxxx> wrote:
On 21 Oct, 15:32, r...@xxxxxxxxxxxxxxxxxxxxxx (Richard Bos) wrote:
Nick Keighley <nick_keighley_nos...@xxxxxxxxxxx> wrote:
On 21 Oct, 09:38, Ruud <Ruud.Baltis...@xxxxxx> wrote:

In my Pascal program I gathered all messages in one function. All
messages have their own number. One of the advantages of this method
is that if someone wants to change a messages, he only has to look in
one place.
and if you want to know what a message is it's never in the
place where you look...
Very long macro names can help.
=A0 =A0error (27);
and somewhere is
=A0 =A0 {27, "communications link is lost"}
hence a better macro might be
=A0 =A0 error (LINK_LOST);
I worked on a project where the error macros looked like this
=A0 =A0 error (SYSTEM_ERROR_COMMUNICATIONS_LINK_IS_LOST);
Or in this case, even better, use an enum.
why is an enum "better"?
It's cleaner, for starters. You have all your constants in one place
rather than a bunch of macros.
I can put all the macros in one place.
Or I can have multiple "namespaces" with error
macros specific to different sub-systems
declared local to those systems. (I have seen
this done and spent a fair amount of time cursing
the lunatic who thought of it. grep is your fiend)
#define SYSTEM_ERROR_BASE 1000
#define SYSTEM_ERROR_GENERAL (SYSTEM_ERROR_BASE + 1)
#define SYSTEM_ERROR_WONT_START (SYSTEM_ERROR_BASE + 2)
#define SYSTEM_ERROR_HALT_BY_COMMAND (SYSTEM_ERROR_BASE + 3)
#define SYSTEM_ERROR_HALT_BY_TRAP (SYSTEM_ERROR_BASE + 4)
So that's cleaner and less error prone than

enum SystemError
{
SYSTEM_ERROR_BASE = 1000,
SYSTEM_ERROR_GENERAL,
SYSTEM_ERROR_WONT_START,
SYSTEM_ERROR_HALT_BY_COMMAND,
SYSTEM_ERROR_HALT_BY_TRAP

};

?

ah, I should ahve stressed the second lot (the comms ones)
were in a different file (actaully different package)
from the general ones.

That does not make the enum approach any harder...
enum CommsErrors {
COMMS_ERROR_BASE = SYSTEM_ERROR_BASE + 10000,
...

Yes it has its downside but
on a large project there might be reasons for different
sub-systems to have semi-independent error list.

For this type of thing as long as they are integers within the range
supported for enum on the implementation I find it incredibly hard to
see a situation where you could use the #define approach and not the
enum approach.

I reality some of this was code generated by a CASE tool

Well, with auto-generated code you often don't care about looks :-)

"cleaness" of code is another on of those opinion
thingies

Indeed. I prefer the enum approach myself though.
--
Flash Gordon
If spamming me sent it to smap@xxxxxxxxxxxxxxxxx
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/
.

Relevant Pages

  • Preprocessor - Generate enumeration from two macros
    ... enum dg_abc { ... macros as shown below to generate some data types and data structures. ... One of the data types generated will be an enumeration. ... data group with the option to use the same element name in more than one ...
    (comp.lang.c)
  • Re: good Embedded C resources plz...
    ... But it depends on the quality of your compiler. ... >and even better when possible, instead of macros or enums, use consts ... const int ARRAY_SIZE=10; ...
    (comp.arch.embedded)
  • Re: How to handle bits of a byte in c ?
    ... the only good reason to use a macro is if your compiler is ... enum fruit_t string2enum{ ... else return unknown; ... Macros can make this a lot cleaner: ...
    (comp.programming)
  • Re: Standard C-macro scripting
    ... >>Macros are easy. ... It is just concat, stringify and expand. ... > your enum example: ... > #undef m ...
    (freebsd-hackers)
  • Re: Pascal -> C
    ... I worked on a project where the error macros looked like this ... So that's cleaner and less error prone than ... enum SystemError ... sub-systems to have semi-independent error list. ...
    (comp.lang.c)