Pascal -> C

[Ruud]

Hallo allemaal,
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.

The function is declared as follow:
function zin(by : byte) : string;

A line calling the function can look like as simple as
this:
writeln(zin(12));

So far I have found a replacement for this function but I'm not
satisfied with it. I defined a 'char pst[255]' and the function 'void
zin(int by)' fills pst with the wanted message. But that means I now
need two lines instead of one:
zin(12);
printf("%s", pst);

Of course I tried to turn 'void zin(int by)' into a funtion that
returns a value so I could combine those two line to something like
'printf("%s", zin(12));' but I either got an compilation error or only
nonsense appeared on the screen.

In the meanwhile I found a solution in the form of
char *zin[20] = { "..", ""..." etc. }
printf("%s", zin[12]);

But that works fine for fixed messages but what about messages that
are generated by a function on the fly?

Any help is welcome!
--
___
/ __|__
/ / |_/ Groetjes, Ruud Baltissen
\ \__|_\
\___| http://Ruud.C64.org

[Richard Heathfield]

Ruud said:

<snip>

Of course I tried to turn 'void zin(int by)' into a funtion that
returns a value so I could combine those two line to something like
'printf("%s", zin(12));' but I either got an compilation error or only
nonsense appeared on the screen.

Why not modify zin to return (a pointer to the first character of) the
string?

const char *zin(int msg)
{
static char pst[MAX_LENGTH]; /* define MAX_LENGTH at your convenience */

const char *msglist[] =
{
"Hello",
"Goodbye",
"Whatever"
};
size_t count = sizeof msglist / sizeof msglist[0];
if(msg >= 0 && msg < count)
{
strcpy(pst, msglist[msg]);
}
else
{
/* presumably this is where your machine-generated messages are
generated, and loaded into pst
*/
}

return pst;
}

Now printf("%s", zin(12)) becomes legal - but beware! The static buffer
means that you've only got one storage area for "the current message", so
printf("%s %s", zin(12), zin(1)) will very likely not do what you want it
to do. If that's a problem, you need to think about passing a buffer into
the function.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Nick Keighley]

On 21 Oct, 09:38, Ruud <[e-mail]:

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.

error (27);

and somewhere is
{27, "communications link is lost"}

hence a better macro might be
error (LINK_LOST);

I worked on a project where the error macros looked like this
error (SYSTEM_ERROR_COMMUNICATIONS_LINK_IS_LOST);

But this was internationalising (I18Ning) the actual output
strings.

The function is declared as follow:
function zin(by : byte) : string;

A line calling the function can look like as simple as
this:
writeln(zin(12));

So far I have found a replacement for this function but I'm not
satisfied with it. I defined a 'char pst[255]' and the function 'void
zin(int by)' fills pst with the wanted message. But that means I now
need two lines instead of one:
zin(12);
printf("%s", pst);

you could return static strings

const char* zin (int n)
{
switch (n)
{
case 1: return "link lost";
break;
case 2: return "O2 over pressure";
break;
default:
return "bad error code";
}
}

printf ("%s", zin(12));

Of course I tried to turn 'void zin(int by)' into a funtion that
returns a value so I could combine those two line to something like
'printf("%s", zin(12));' but I either got an compilation error or only
nonsense appeared on the screen.

show your code

In the meanwhile I found a solution in the form of
char *zin[20] = { "..", ""..." etc. }
printf("%s", zin[12]);

yep. Or

struct String_tab_entry
{
int n;
const char *str;
};

String_tab_entry string_tab [] =
{
{12, "tile lost"},
{99, "intruder"},
(101, "fire"},
};

Then search the array. The strings then don't have to be contiguous
or even ordered. (tho' ordered can make the search faster)

But that works fine for fixed messages but what about messages that
are generated by a function on the fly?

In that case you need a buffer of some sort. This is fairly
standard C problem. Solutions are

1. use a static buffer

const char* zin (int n, const char* arg)
{
static char buffer [256];

switch (n)
{
case 1:
sprintf (buffer, "link lost %s", arg);
return buffer;
}
}

Multiple calls may be a problem

printf ("%s %s", zin(12), zin(13));

2. pass a buffer

const char* zin (int n, char *buffer, const char* arg)
{ switch (n)
{
case 1:
sprintf (buffer, "link lost %s", arg);
return buffer;
}
}

3. malloc a buffer (but then someone has to clean up
afterwards).

4. Make zin() a lot cleverer (Untested code!)

#include <stdarg.h>

typedef void PrintFunc (const char*);

void zin (int n, PrintFunc *print, const char *format, ...)
{
va_list args;
va_start (args, format);
char buffer [256];
vsprintf (buffer, format, args);
print (buffer);
}

void print (const char *s)
{
printf ("%s", s);
}

zin (23, print, "link lost %d", link_id);
This is a bit untidy. But the point is you can pass arbitary
arguments to zin() using stdarg functionality. You can
also pass function arguments to do the actual i/o.

Without knowing more about your app I can't go any furthur.
Hope I've given you some ideas.
--
Nick Keighley

[Richard Bos]

Nick Keighley <ni******************@hotmail.comwrote:

On 21 Oct, 09:38, Ruud <[e-mail]:

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.

error (27);

and somewhere is
{27, "communications link is lost"}

hence a better macro might be
error (LINK_LOST);

I worked on a project where the error macros looked like this
error (SYSTEM_ERROR_COMMUNICATIONS_LINK_IS_LOST);

Or in this case, even better, use an enum.

Richard

[Ben Bacarisse]

I was not going to post this but now the issue has come up twice it
seems worth it...

Nick Keighley <ni******************@hotmail.comwrites:

On 21 Oct, 09:38, Ruud <[e-mail]:

<snip>

>But that works fine for fixed messages but what about messages that
are generated by a function on the fly?

In that case you need a buffer of some sort. This is fairly
standard C problem. Solutions are

1. use a static buffer

const char* zin (int n, const char* arg)
{
static char buffer [256];

switch (n)
{
case 1:
sprintf (buffer, "link lost %s", arg);
return buffer;
}
}

Multiple calls may be a problem

printf ("%s %s", zin(12), zin(13));

If you are stuck with this interface and need the above to work you
can, of course, allow a fixed number of "multiple" calls buy writing:

#define N_BUFFERS 3

const char* zin(int n, const char* arg)
{
static char buffers[N_BUFFERS][256];
static int nb = 0;
char *buffer = buffers[nb++];
nb %= N_BUFFERS;

/* code as before... */
}

but this has a relatively high "yuck" coefficient.

--
Ben.

[Nick Keighley]

On 21 Oct, 15:32, [e-mail] (Richard Bos) wrote:

Nick Keighley <[e-mail]:

On 21 Oct, 09:38, Ruud <[e-mail]:

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.

* *error (27);

and somewhere is
* * {27, "communications link is lost"}

hence a better macro might be
* * error (LINK_LOST);

I worked on a project where the error macros looked like this
* * error (SYSTEM_ERROR_COMMUNICATIONS_LINK_IS_LOST);

Or in this case, even better, use an enum.

why is an enum "better"?

--
Nick Keighley

[Nick Keighley]

On 21 Oct, 15:33, Ben Bacarisse <[e-mail]:

I was not going to post this but now the issue has come up twice it
seems worth it...



Nick Keighley <[e-mail]:

On 21 Oct, 09:38, Ruud <[e-mail]:

<snip>

But that works fine for fixed messages but what about messages that
are generated by a function on the fly?

In that case you need a buffer of some sort. This is fairly
standard C problem. Solutions are

* *1. use a static buffer

* *const char* zin (int n, const char* arg)
* *{
* * * *static char buffer [256];

* * * *switch (n)
* * * *{
* * * * * *case 1:
* * * * * * * * sprintf (buffer, "link lost %s", arg);
* * * * * * * * return buffer;
* * * *}
* *}

* *Multiple calls may be a problem

* * * *printf ("%s %s", zin(12), zin(13));

If you are stuck with this interface and need the above to work you
can, of course, allow a fixed number of "multiple" calls buy writing:

* * #define N_BUFFERS 3

* * const char* zin(int n, const char* arg)
* * {
* * * * static char buffers[N_BUFFERS][256];
* * * * static int nb = 0;
* * * * char *buffer = buffers[nb++];
* * * * nb %= N_BUFFERS;

* * * * /* code as before... */
* * }

but this has a relatively high "yuck" coefficient.

too true!

I tend to live with the static buffer. Live with
fact I *may* overflow it. And never have statements
with multiple uses of "zin()".

--
Nick Keighley

[Ruud]

Hallo allemaal,
@Richard:

you need to think about passing a buffer into the function.

That is one of the things I tried that did work. But passing a buffer
appeared a bit clumsy to me.
As I already mentioned, my original funtion 'zin' (FYI: Dutch for
'sentence') contains some concatinations with other variables which I
like to keep. So I think I have no choice then using this solution.
@Nick:

show your code

char pst[255];

main(int argc, char *argv[])
{
int by;

printf("\n\n\n");

for (by = 0; by < 2; by++)
printf("%s\n", szin(by));

return(0);
}
char szin(int w)
{
char *c;

switch(w)
{
case 0 : strcpy(pst, "Unknown/incorrect placed Directive");
break;
case 1 : strcpy(pst, "Line ended incorrectly");
break;
default : strcpy(pst, "?????????");
}

c = pst;
return(*c);
}
The above compiles fine but produces the nonsence. I'm quite sure it
has to do with 'c = pst' but what is wrong, I have no idea. 'pst' on
itself is a pointer (AFAIK). I can return '*c' but returning 'pst'
causes an error.
After writing the above I found a piece of code that explained some
things.

c = pst;

strcpy(pst, "abcdefgh");
c = pst;
printf("-1- %s\n", pst);
printf("-2- %c\n", *c);
printf("-3- %s\n", *c);
c = &pst[1];
printf("-4- %c\n", *c);
printf("-5- %s\n", *c);

return(*c);

Line -1- outputted 'abcdefgh', -2- 'a' and -4- 'b'. -3- and -5-
produce nonsence. Still the question: why can't I return 'pst'?
@Ben & Nick:

Thanks for the info but, being a beginner, these are things I don't
understand completely yet.
--
* * ___
* */ __|__
* / / *|_/ * * Groetjes, Ruud Baltissen
* \ \__|_\
* *\___| * * *http://Ruud.C64.org

[Richard Heathfield]

Ruud said:

Hallo allemaal,
@Richard:

>you need to think about passing a buffer into the function.

That is one of the things I tried that did work. But passing a buffer
appeared a bit clumsy to me.
As I already mentioned, my original funtion 'zin' (FYI: Dutch for
'sentence') contains some concatinations with other variables which I
like to keep. So I think I have no choice then using this solution.
@Nick:

>show your code

char pst[255];

main(int argc, char *argv[])
{
int by;

printf("\n\n\n");

for (by = 0; by < 2; by++)
printf("%s\n", szin(by));

return(0);
}
char szin(int w)

char *szin(int w)

{
char *c;

switch(w)
{
case 0 : strcpy(pst, "Unknown/incorrect placed Directive");
break;
case 1 : strcpy(pst, "Line ended incorrectly");
break;
default : strcpy(pst, "?????????");
}

c = pst;
return(*c);

return c;

Or just:

return pst;

Either will do.

<snip>

>
c = pst;

strcpy(pst, "abcdefgh");
c = pst;
printf("-1- %s\n", pst);
printf("-2- %c\n", *c);
printf("-3- %s\n", *c);

*c is a char, not a char *. %s expects a char *, not a char.

Still the question: why can't I return 'pst'?

You can.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Bos]

Nick Keighley <ni******************@hotmail.comwrote:

On 21 Oct, 15:32, [e-mail] (Richard Bos) wrote:

Nick Keighley <[e-mail]:

On 21 Oct, 09:38, Ruud <[e-mail]:

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.

Richard

[Nick Keighley]

On 22 Oct, 09:25, [e-mail] (Richard Bos) wrote:

Nick Keighley <[e-mail]:

On 21 Oct, 15:32, [e-mail] (Richard Bos) wrote:

Nick Keighley <[e-mail]:
On 21 Oct, 09:38, Ruud <[e-mail]:

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)
#define COMMS_ERROR_BASE (SYSTEM_ERROR_BASE + 10000)
#define COMMS_ERROR_LINK_LOST (COMMS_ERROR_BASE + 1)
#define COMMS_ERROR_BER_HIGH (COMMS_ERROR_BASE + 2)
#define COMMS_ERROR_FRAMING (COMMS_ERROR_BASE + 3)
#define COMMS_ERROR_UNKOWN_ADDRESS (COMMS_ERROR_BASE + 4)
--
Nick Keighley

[Ian Collins]

Nick Keighley wrote:

On 22 Oct, 09:25, [e-mail] (Richard Bos) wrote:

>Nick Keighley <[e-mail]:

>>On 21 Oct, 15:32, [e-mail] (Richard Bos) wrote:
Nick Keighley <[e-mail]:
On 21 Oct, 09:38, Ruud <[e-mail]:
>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
};

?

--
Ian Collins

[Ruud]

Hallo Richard & Spiro,

char *szin(int w)

Spiro just emailed me the same in a PM. And this works!
Thank you both !!!

Having a good look at it it is all logical. 'printf' expects an
pointer and '*szin' returns one, something 'szin' didnit.
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org

[Nick Keighley]

On 22 Oct, 10:28, Ian Collins <[e-mail]:

Nick Keighley wrote:

On 22 Oct, 09:25, [e-mail] (Richard Bos) wrote:

Nick Keighley <[e-mail]:
On 21 Oct, 15:32, [e-mail] (Richard Bos) wrote:
Nick Keighley <[e-mail]:
On 21 Oct, 09:38, Ruud <[e-mail]:

>>>>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 lookin
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. Yes it has its downside but
on a large project there might be reasons for different
sub-systems to have semi-independent error list.

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

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

--
Nick Keighley

A coding theorist is someone who doesn't think Alice is crazy.

[Nick Keighley]

On 22 Oct, 09:15, Ruud <[e-mail]:

As I already mentioned, my original funtion 'zin' (FYI: Dutch for
'sentence')

there was I thinking it was named after the PTI in Star Ship Troopers!

--
Nick Keighley

[Michael]

Ruud wrote:

Hallo allemaal,
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.

The function is declared as follow:
function zin(by : byte) : string;

A line calling the function can look like as simple as
this:
writeln(zin(12));

So far I have found a replacement for this function but I'm not
satisfied with it. I defined a 'char pst[255]' and the function 'void
zin(int by)' fills pst with the wanted message. But that means I now
need two lines instead of one:
zin(12);
printf("%s", pst);

Of course I tried to turn 'void zin(int by)' into a funtion that
returns a value so I could combine those two line to something like
'printf("%s", zin(12));' but I either got an compilation error or only
nonsense appeared on the screen.

In the meanwhile I found a solution in the form of
char *zin[20] = { "..", ""..." etc. }
printf("%s", zin[12]);

But that works fine for fixed messages but what about messages that
are generated by a function on the fly?

Any help is welcome!
--
___
/ __|__
/ / |_/ Groetjes, Ruud Baltissen
\ \__|_\
\___| http://Ruud.C64.org

pascal:
function zin(by : byte) : string;

c++:
string zin(unsigned char by);
pascal
writeln(zin(12));

c++:

cout<<zin(12);
No pure C solution is available because pure C has no string type.

[Flash Gordon]

Nick Keighley wrote, On 22/10/08 11:54:

On 22 Oct, 10:28, Ian Collins <[e-mail]:

>Nick Keighley wrote:

>>On 22 Oct, 09:25, [e-mail] (Richard Bos) wrote:
Nick Keighley <[e-mail]:
On 21 Oct, 15:32, [e-mail] (Richard Bos) wrote:
>Nick Keighley <[e-mail]:
>>On 21 Oct, 09:38, Ruud <[e-mail]:

>>>>>>>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 sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Ian Collins]

Flash Gordon wrote:

Nick Keighley wrote, On 22/10/08 11:54:

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

Indeed. I prefer the enum approach myself though.

And don't forget if you use enums, you can compile your code with a C++
compiler to make sure you only use valid values :)

--
Ian Collins

[Ruud]

Hallo Michael,

pascal:
function zin(by : byte) : string;

c++:
string zin(unsigned char by);

pascal
writeln(zin(12));

c++:

cout<<zin(12);

No pure C solution is available because pure C has no string type.

Very interesting indeed, thank you!

--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org