The ProgrammerDude C to C++ Contest
Richard Heathfield
it is a valid C++ program whilst remaining a valid C program and without
hacking it around except for (a) changing identifier names; (b)
refactoring recursive main, and (c) adding casts.
Here is the program. Good luck, Chris. :-)
/* Please convert this program to C++ using the
* following rules:
*
* 1) the program must remain a valid C program.
* 2) you may refactor recursive main() - so I
* didn't bother to use one.
* 3) you may rename identifiers, including function
* names, as long as doing so does not change the
* output of the program.
* 4) you may add casts.
* 5) you can't change the program in any other way.
* That means you can't add header files, you can't
* add keywords, you can't change or remove comments,
* and you can't add whitespace or anything else.
* 6) I could have made this a lot harder!
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define a(b) #b
#define SPACE ' '
int main(void)
{
char *asm = a(asm);
char *protected = a(protected);
char *using = a(using);
char *b[28] = {0};
char title__of__the__program[81] = "C to C++ Translation\nONLY extra
casts and renaming of variables are allowed.\n\n\n\n\n";
auto i = strlen(protected) -
(sizeof SPACE //* we need a space\
in here somewhere */ sizeof (int
) + strlen(asm) + strlen(using));
if(strcmp(asm, "asm") != 0 || strcmp(protected, "protected") != 0 ||
strcmp(using, "using") != 0)
{
puts("Error!");
return EXIT_FAILURE;
}
b[0] = asm + 1;
b[1] = b[0] - 1;
b[2] = protected + 8;
b[4] = b[2] - 8;
b[5] = b[4] + 1;
b[6] = b[5] + 1;
b[7] = using + 4;
b[8] = b[5];
b[9] = b[0] - 1;
b[10] = b[0] + 1;
b[11] = b[10];
b[12] = b[2] - 4;
b[13] = b[12] - 3;
b[14] = b[0];
b[16] = b[2];
b[17] = b[16] - 6;
b[19] = b[7] - 1;
b[20] = b[2] - 6;
b[21] = b[20] + 1;
b[23] = b[7] - 4;
b[24] = b[23] + 1;
b[25] = b[2] - 4;
b[27] = b[25] + 1;
printf("%.*s\n",
sizeof title__of__the__program,
title__of__the__program);
while(i < sizeof b / sizeof b[0])
{
if(b[i] != NULL)
{
if(i == sizeof(char) / sizeof SPACE || i == sizeof b / sizeof b[0]
- 1)
{
putchar(toupper((unsigned char)b[i][sizeof(char)/sizeof
SPACE]));
}
else
{
putchar(tolower((unsigned char)b[i][sizeof(char)/sizeof
SPACE]));
}
}
else
{
putchar(SPACE);
}
i += strlen(protected) - (strlen(asm) + strlen(using));
}
putchar('.' * sizeof SPACE / sizeof(int));
putchar('\n');
return 0;
}
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Richard Heathfield
>
<snip>
> char title__of__the__program[81] = "C to C++ Translation\nONLY extra
> casts and renaming of variables are allowed.\n\n\n\n\n";
Line wrap caught me. Sorry. Change this to:
char title__of__the__program[81] =
"C to C++ Translation\nONLY extra casts and "
"renaming of variables are allowed.\n\n\n\n\n";
<snip>
John W. Krahn
>
> Well, I promised Chris a program which he could try to amend such that
> it is a valid C++ program whilst remaining a valid C program and without
> hacking it around except for (a) changing identifier names; (b)
> refactoring recursive main, and (c) adding casts.
>
> Here is the program. Good luck, Chris. :-)
>
By the way, were you one of those chaps I saw on the telly the other
night chasing a wheel of cheese down a hill?
P.S. Did you fix that cross-referencer program [K&R exercise 6-3] that
you posted at the end of May? <3CF74CD6...@eton.powernet.co.uk>
P.P.S. Good luck Chris.
P.P.P.S. ;-)
John
--
use Perl;
program
fulfillment
Bill Godfrey
> auto i = strlen(protected) -
> (sizeof SPACE //* we need a space\
> in here somewhere */ sizeof (int
> ) + strlen(asm) + strlen(using));
Which flavour of C is this? (C90, C99, etc)
Does changing...
stuff(); // stuff
to...
stuff(); /* stuff */
consitute a change of comment?
Bill, struct detail { int devil };
Richard Heathfield
>
> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>
> > auto i = strlen(protected) -
> > (sizeof SPACE //* we need a space\
> > in here somewhere */ sizeof (int
> > ) + strlen(asm) + strlen(using));
>
> Which flavour of C is this? (C90, C99, etc)
C90.
>
> Does changing...
> stuff(); // stuff
> to...
> stuff(); /* stuff */
> consitute a change of comment?
Yes.
Programmer Dude
> Well, I promised Chris a program which he could try to amend such that
> it is a valid C++ program whilst remaining a valid C program and without
> hacking it around except for (a) changing identifier names; (b)
> refactoring recursive main, and (c) adding casts.
Got it. It's a busy week, so maybe nothing until next week.
I did notice this...
> * 5) you can't change the program in any other way.
> * That means you can't add header files, you can't
> * add keywords, you can't change or remove comments,
> * and you can't add whitespace or anything else.
Can't change whitespace in the source for a whitespace-insensitive
language? Whitespace is whitespace, and it's all reduced to one
space before the *compiler* even sees it, so, I don't think I can
accept that as a condition.
> * 6) I could have made this a lot harder!
I'm sure. The point is, you have to work at it. You have to go out of
your way to create a program in C which will fail in C++. That alone
suggests--to me--the truth behind the original assertion (that, in a
pragmatic sense, C is a viable sub-set of C++).
Anyway, I'm looking forward to playing with this! Stay tuned!!
--
|_ CJSonnack <Ch...@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|
Opinions expressed herein are my own and may not represent those of my employer.
Programmer Dude
Programmer Dude wrote:
> It's a busy week, so maybe nothing until next week.
I did take a quick stab at it before going home. With two small
changes that don't alter the compiler input/output at all, it
compiles under C++ with no warnings of any kind. It produces
slightly different output than when compiled as C, though... ;-)
I'll play with it some more later!
Tim Sinkins
Programmer Dude wrote:
>
> Richard Heathfield wrote:
>
>
> > * 5) you can't change the program in any other way.
> > * That means you can't add header files, you can't
> > * add keywords, you can't change or remove comments,
> > * and you can't add whitespace or anything else.
>
> Can't change whitespace in the source for a whitespace-insensitive
> language? Whitespace is whitespace, and it's all reduced to one
> space before the *compiler* even sees it, so, I don't think I can
> accept that as a condition.
Yeh, I though this was an unreasonable condition which I hadn't
interpreted as being part of the test before the sample was posted.
Tim
Richard Heathfield
>
> Richard Heathfield wrote:
>
> > Well, I promised Chris a program which he could try to amend such that
> > it is a valid C++ program whilst remaining a valid C program and without
> > hacking it around except for (a) changing identifier names; (b)
> > refactoring recursive main, and (c) adding casts.
>
> Got it. It's a busy week, so maybe nothing until next week.
>
> I did notice this...
>
> > * 5) you can't change the program in any other way.
> > * That means you can't add header files, you can't
> > * add keywords, you can't change or remove comments,
> > * and you can't add whitespace or anything else.
>
> Can't change whitespace in the source for a whitespace-insensitive
> language? Whitespace is whitespace, and it's all reduced to one
> space before the *compiler* even sees it, so, I don't think I can
> accept that as a condition.
Fair enough. Perhaps I was trying to nail it down a bit too hard. You
may add whitespace, which gets you neatly around the comment challenge.
>
> > * 6) I could have made this a lot harder!
>
> I'm sure. The point is, you have to work at it.
Um, no. What I had to work at was finding a way to do this that I
thought you would consider fair.
> You have to go out of
> your way to create a program in C which will fail in C++.
Not really. Very few of my C programs would compile in C++ first time,
without significant amounts of hackery.
> That alone
> suggests--to me--the truth behind the original assertion (that, in a
> pragmatic sense, C is a viable sub-set of C++).
>
> Anyway, I'm looking forward to playing with this! Stay tuned!!
Enjoy. :-)
Programmer Dude
>> Can't change whitespace in the source for a whitespace-insensitive
>> language? Whitespace is whitespace, and it's all reduced to one
>> space before the *compiler* even sees it, so, I don't think I can
>> accept that as a condition.
>
> Fair enough. Perhaps I was trying to nail it down a bit too hard. You
> may add whitespace, which gets you neatly around the comment challenge.
Quite neatly, indeed, as it requires only adding a single space.
This post is an "early returns" sort of thing, as I haven't had a chance
to wade through that 'interesting' array assignment business or decypher
the complex expressions in the putchar()s.
As I mentioned last post, the few mods I'm going to present this post
make the code compile just fine. The problem is the output. ;-)
My first guess from a quick look is you're playing games with the type
(and hence sizeof) of literal characters. Once I decypher exactly what
you're doing, I'll know how successful a translation I can make.
In the meantime, I can give you something to chew on over the weekend
(I don't internet during the weekend, so I'm trading doxygen time now
for later! :-).
> Um, no. What I had to work at was finding a way to do this that I
> thought you would consider fair.
Honestly, I don't think you've managed that. Of the bits we can talk
about so far, only the array assignment seems playing fair, since there
is no "good coding practice" issue with that. There definitely is with
the other tricks. I have no doubt you'd be among the first to correct
any poster who wrote such code for clc.
Nevertheless, the task is to demonstrate (or fail to!) the high degree
of mapping between C and C++. Here's the yardstick I propose to apply
to the result:
A. We have the agreed upon rules regarding casting, whitespace,
a recursive main and, of course, variable names.
B. Input and Output of the two must be absolutely identical.
C. The semantics of the two must be absolutely identical.
D. The C++ program must be a completely legitimate C program.
E. The lexical difference must be as small as possible (ideally, but
impossibly, zero).
The middle three are easily judged, especially because they are absolute.
The first one shouldn't be too tough, but the last one may stretch out
the thread. I've a great shareware file-comparing tool I use frequently
and will be using here. To that end, I re-formatted your code to make
it clearer for me and to make comparing the result easier. You can view
both the re-formatted version (for correctness) and the current version
(discussed in this post) at:
original: http://www.Sonnack.com/WillCall/heathfield0.html
current: http://www.Sonnack.com/WillCall/heathfield1.html
>> You have to go out of your way to create a program in C which will
>> fail in C++.
>
> Not really. Very few of my C programs would compile in C++ first time,
> without significant amounts of hackery.
Why is that? Oh, I'll bet it's casts, eh?
What I mean by going out of your way is you've needed to resort to
some pretty hairy coding practice to present what you did. I mean,
really, comments directly against code? Or using variable *names*
as data? Tch, tch. ;-)
> Enjoy. :-)
I am! Let's begin!!
1. Line 42: (sizeof SPACE //* we need a space\
:-) Well, this one is already dead in the water.
Adding a space between the two "//" cures the problem, and meets
all five criteria above easily. (Wouldn't this fail in C99?)
2. Line 30: The array initializer is the one really legit trick so far.
Shortly expressed, it's this: char A[5] = "Hello";
My translation: char A[5] = {'H','e','l','l','o'};
Easily meets B, C & D. Doesn't do too well with E. Not covered
by A (or perhaps disallowed because not covered?). I claim it's
an item we (I) didn't consider and petitition for an amendment.
Rationale: the translation is clearly valid C, and I claim it is
in fact exactly what the original is syntactic sugar for. Consider
this analogy: is *(A+i) a valid translation of A[i]? I claim this
is an identical situation and throw myself on the mercy of the court.
3. Lines 21, 26-28 & 46-48. Using variable names as data?!?! You're
just lucky your client didn't want to include C keywords! My
translation is:
#define a(b) #b ==> not used
char* asm = a(asm); ==> char* Asm = "asm";
strcmp (asm, "asm") ==> strcmp (Asm, "asm");
Your #define adds nothing to the code in terms of reducing
maintenance or errors or in increasing expressiveness. The
need to sync the variable name and the parameter to the macro
are identical to the need to sync the variable name and
literal string. I claim the translation is is better C, as
it won't break if a search/replace mishap changes the variable name.
Lexically, the changes are minor. Semantically they don't exist.
Input/Output are unchanged. Variable name changes themselves
clearly fall under A. The source is (ahem) "C/C++" [bwg].....
So, now all I gotta do is figure out that b[] array stuff and those
nasty expressions in the putchar()s. ;-)
Thomas Stegen
> Richard Heathfield wrote:
[snip discussion]
I think this competition shows you both are right :)
Richard is showing that there is no one to one mapping
between C and C++ at most levels and Programmer Dude shows
that most changes are trivial in the real world (given reasonable
workplace rules for translation). The only thing
I can think of that would be impossible to get the same output
out of would be a quine that uses non-overlapping keywords[1].
1. If you decide to use this (non-overlapping keywords) phrase
you must pay me a penny :)
--
Thomas Stegen
http://www.geocities.com/thinkoidz
Richard Heathfield
>
> Richard Heathfield wrote:
>
> >> Can't change whitespace in the source for a whitespace-insensitive
> >> language? Whitespace is whitespace, and it's all reduced to one
> >> space before the *compiler* even sees it, so, I don't think I can
> >> accept that as a condition.
> >
> > Fair enough. Perhaps I was trying to nail it down a bit too hard. You
> > may add whitespace, which gets you neatly around the comment challenge.
>
> Quite neatly, indeed, as it requires only adding a single space.
Right.
> This post is an "early returns" sort of thing, as I haven't had a chance
> to wade through that 'interesting' array assignment business or decypher
> the complex expressions in the putchar()s.
The array assignment business is no big deal, actually. The complex
expressions aren't really all that complex, either.
>
> As I mentioned last post, the few mods I'm going to present this post
> make the code compile just fine. The problem is the output. ;-)
> My first guess from a quick look is you're playing games with the type
> (and hence sizeof) of literal characters. Once I decypher exactly what
> you're doing, I'll know how successful a translation I can make.
It's very simple, actually. In C, character constants have type int. In
C++, it's char. Thus, in C, sizeof ' ' / sizeof(int) is ***guaranteed***
to return 1, whereas in C++ it's going to return 0 except on
implementations where sizeof(int) is equal to sizeof(char), and such
implementations are very rare indeed. (Rare enough that a C++ programmer
who /assumed/ they were the same would be a candidate for a Nilges
T-shirt.)
> In the meantime, I can give you something to chew on over the weekend
> (I don't internet during the weekend, so I'm trading doxygen time now
> for later! :-).
Glad to be of service. :-)
> > Um, no. What I had to work at was finding a way to do this that I
> > thought you would consider fair.
>
> Honestly, I don't think you've managed that. Of the bits we can talk
> about so far, only the array assignment seems playing fair, since there
> is no "good coding practice" issue with that. There definitely is with
> the other tricks. I have no doubt you'd be among the first to correct
> any poster who wrote such code for clc.
There's nothing "wrong" with any of the code as such. The biggest
stretch is probably the stringizing, and yet I /have/ used the
stringization of identifiers in C programs before now, for good and
sensible reasons. (Consider, for example, mapping strings to functions.)
>
> Nevertheless, the task is to demonstrate (or fail to!) the high degree
> of mapping between C and C++. Here's the yardstick I propose to apply
> to the result:
>
> A. We have the agreed upon rules regarding casting, whitespace,
> a recursive main and, of course, variable names.
Right.
>
> B. Input and Output of the two must be absolutely identical.
Right.
>
> C. The semantics of the two must be absolutely identical.
Right.
>
> D. The C++ program must be a completely legitimate C program.
Right.
>
> E. The lexical difference must be as small as possible (ideally, but
> impossibly, zero).
Errrr. This is your wiggle room, your weaseling-out option - yes? :-)
> The middle three are easily judged, especially because they are absolute.
> The first one shouldn't be too tough, but the last one may stretch out
> the thread.
Quite so.
> I've a great shareware file-comparing tool I use frequently
> and will be using here. To that end, I re-formatted your code to make
> it clearer for me and to make comparing the result easier. You can view
> both the re-formatted version (for correctness) and the current version
> (discussed in this post) at:
>
> original: http://www.Sonnack.com/WillCall/heathfield0.html
> current: http://www.Sonnack.com/WillCall/heathfield1.html
I do Usenet offline, but I'll try to remember to go check this out when
I next log on.
>
> >> You have to go out of your way to create a program in C which will
> >> fail in C++.
> >
> > Not really. Very few of my C programs would compile in C++ first time,
> > without significant amounts of hackery.
>
> Why is that? Oh, I'll bet it's casts, eh?
Mostly casts (or rather, the absence of them!), but partly variable
names (C++ uses some rather handy words as keywords, unfortunately).
There are other important differences between the languages which happen
not to affect me.
I suspect that, as C99 becomes more common, my C programs will become
even less C++-friendly. In any event, good C code isn't necessarily good
C++ code, so it's a moot point anyway - I'd have to look at every line
to see whether I consider it good practice in C++, so from my point of
view there's no real *value* in the notion that C is a practical subset
of C++.
>
> What I mean by going out of your way is you've needed to resort to
> some pretty hairy coding practice to present what you did. I mean,
> really, comments directly against code? Or using variable *names*
> as data? Tch, tch. ;-)
I plead guilty to the first but not the second. The second is a
technique I have used in real code for a good reason.
>
> > Enjoy. :-)
>
> I am! Let's begin!!
>
> 1. Line 42: (sizeof SPACE //* we need a space\
> :-) Well, this one is already dead in the water.
Yeah, you changed the rules on me. :-) Still, I'll take that hit.
>
> Adding a space between the two "//" cures the problem, and meets
> all five criteria above easily. (Wouldn't this fail in C99?)
Yes. I wondered if you'd notice. :-)
>
> 2. Line 30: The array initializer is the one really legit trick so far.
> Shortly expressed, it's this: char A[5] = "Hello";
> My translation: char A[5] = {'H','e','l','l','o'};
A cunning solution, which I'll accept, even though it breaks rule A.
>
> Easily meets B, C & D. Doesn't do too well with E. Not covered
> by A (or perhaps disallowed because not covered?).
Rule A was meant to be exclusive.
> I claim it's
> an item we (I) didn't consider and petitition for an amendment.
You can have this one, because I think it was clever of you to think of
it.
>
> Rationale: the translation is clearly valid C, and I claim it is
> in fact exactly what the original is syntactic sugar for. Consider
> this analogy: is *(A+i) a valid translation of A[i]? I claim this
> is an identical situation and throw myself on the mercy of the court.
Yes yes yes yes yes yes yes yes yes. Can't you take "yes" for an answer?
:-)
>
> 3. Lines 21, 26-28 & 46-48. Using variable names as data?!?! You're
> just lucky your client didn't want to include C keywords! My
> translation is:
>
> #define a(b) #b ==> not used
> char* asm = a(asm); ==> char* Asm = "asm";
> strcmp (asm, "asm") ==> strcmp (Asm, "asm");
>
> Your #define adds nothing to the code in terms of reducing
> maintenance or errors or in increasing expressiveness.
At this point, I think you're weaseling out. No, really. There *are*
good reasons to do stringizing of identifiers, and those strings might
even be stored externally to the program, in a file. Thus, changing the
variable names really can break the system.
> The
> need to sync the variable name and the parameter to the macro
> are identical to the need to sync the variable name and
> literal string.
Right.
> I claim the translation is is better C, as
> it won't break if a search/replace mishap changes the variable name.
Sorry, but I can't agree here, for reasons already stated.
> Lexically, the changes are minor. Semantically they don't exist.
Yes, they do, because you have broken the semantic link between the name
of the variable and the value of the string to which it points.
<snip>
Edward G. Nilges
Sorry to see my courtesy was wasted on you, Richard.
Anthony Ventimiglia
> Well, I promised Chris a program which he could try to amend such that
> it is a valid C++ program whilst remaining a valid C program and without
> hacking it around except for (a) changing identifier names; (b)
> refactoring recursive main, and (c) adding casts.
>
> Here is the program. Good luck, Chris. :-)
>
> /* Please convert this program to C++ using the
> * following rules:
> *
> * 1) the program must remain a valid C program.
> * 2) you may refactor recursive main() - so I
> * didn't bother to use one.
> * 3) you may rename identifiers, including function
> * names, as long as doing so does not change the
> * output of the program.
> * 4) you may add casts.
> * 5) you can't change the program in any other way.
> * That means you can't add header files, you can't
> * add keywords, you can't change or remove comments,
> * and you can't add whitespace or anything else.
> * 6) I could have made this a lot harder!
You couldn't have made it any easier.
Any ANSI C is Valid C++, it might not be very good or effective C++, but it
is C. Read Stroustrup, Every example in the K&R book should compile in a
Standard C++ compiler.
Even if it wasn't valid C++, it's bad to place any restrictions on a
conversion to C++, because you're encouraging poor C++ style.
Jos A. Horsmeier
news:ioVO8.15715$qL5.8...@news4.srv.hcvlny.cv.net...
> >>>>On Sunday 09 June 2002 04:04 pm, Richard Heathfield boldly stated:
> > Well, I promised Chris a program which he could try to amend such that
> > it is a valid C++ program whilst remaining a valid C program and without
> > hacking it around except for (a) changing identifier names; (b)
> > refactoring recursive main, and (c) adding casts.
> You couldn't have made it any easier.
>
> Any ANSI C is Valid C++, it might not be very good or effective C++, but
it
> is C. Read Stroustrup, Every example in the K&R book should compile in a
> Standard C++ compiler.
Have you tried compiling Richard's program using a compliant C++
compiler? Just for the fun of it? Guess not ...
kind regards,
Jos aka j...@gen.nl
Richard Heathfield
>
> Richard Heathfield <bin...@eton.powernet.co.uk> wrote in message news:<3D0B03BF...@eton.powernet.co.uk>...
> >
> > It's very simple, actually. In C, character constants have type int. In
> > C++, it's char. Thus, in C, sizeof ' ' / sizeof(int) is ***guaranteed***
> > to return 1, whereas in C++ it's going to return 0 except on
> > implementations where sizeof(int) is equal to sizeof(char), and such
> > implementations are very rare indeed. (Rare enough that a C++ programmer
> > who /assumed/ they were the same would be a candidate for a Nilges
> > T-shirt.)
>
> Sorry to see my courtesy was wasted on you, Richard.
Courtesy is never wasted. My comment, incidentally, refers to your
apparent belief that all the world uses the same platform, language, and
programming paradigm as you, or at least that they ought to.
While we're on the subject of courtesy, please learn to snip out bits of
an article which you are not addressing (and, to avoid the charge of
selective quotation, indicate where snippage has been made). Your
consistent failure to do this is a discourtesy to every single user of
this newsgroup.
Al Dunbar
"Edward G. Nilges" <spino...@yahoo.com> wrote in message
news:f5dda427.02061...@posting.google.com...
Ahhh, so there is the "Nilges T-shirt" comment. Worse has been said about me
without causing me to regret having tried to be courteous. Get a sense of
humour, Edward.
/Al
Anthony Ventimiglia
> Have you tried compiling Richard's program using a compliant C++
> compiler? Just for the fun of it? Guess not ...
>
> kind regards,
Yeah and first off, my Standard compliant C compiler won't compile it
either. Big deal reserved words and bad type declaration. Use vim and make
and the errors pretty much fix themselves.
Ben Pfaff
> Yeah and first off, my Standard compliant C compiler won't compile it
> either.
What is your compiler and how did you invoke it? I suspect that
you failed to invoke it in a standards compliant mode.
Richard Heathfield
What reserved words? Are you sure you compiled it as a C program? None
of the identifiers I used for variable names are reserved words in C.
Tim Sinkins
Anthony Ventimiglia wrote:
>
> >>>>On Sunday 16 June 2002 04:51 am, Jos A. Horsmeier boldly stated:
>
> > Have you tried compiling Richard's program using a compliant C++
> > compiler? Just for the fun of it? Guess not ...
> >
> > kind regards,
>
> Yeah and first off, my Standard compliant C compiler won't compile it
> either. Big deal reserved words
It might be a good idea, if you're going to come late to a thread that
you read all of its history first. I realise it's hard for this thread
as its originator is called something else, but we've (they, as I did
not
contribute) already been down the path of C programs using C++ reserved
words as variable names and how this affects the C is a subset of C++
claim.
Tim
Anthony Ventimiglia
>
> What reserved words? Are you sure you compiled it as a C program? None
> of the identifiers I used for variable names are reserved words in C.
>
asm is reserved in gcc, and // is standard C99, so right there you have
your first two errors.
Thomas Stegen
Gcc is waaay beside the point. if Gcc complains when in standard
compliant about asm, then gcc is broken. (Gcc is not broken in this
respect.)
ke...@hplb.hpl.hp.com
Anthony Ventimiglia <shep...@pack.0f.wo1v35> writes:
>>>>>On Monday 17 June 2002 01:38 am, Richard Heathfield boldly stated:
>
>>
>> What reserved words? Are you sure you compiled it as a C program? None
>> of the identifiers I used for variable names are reserved words in C.
>
> asm is reserved in gcc,
(blinks)
int main( int asm, char **argv ) { return 0; }
That compiled OK. But then I remembered to tell gcc to play wearing the
ANSI colours.
> and // is standard C99,
And?
--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
Richard Heathfield
The asm keyword is not, however, reserved in C. The gcc compiler is not
entitled to reserve it when in conforming mode. If it does so, it is the
compiler that is broken, not the program.
You are correct that // is standard C99, of course; had it not been, I
might not have been so quick to back down on the whitespace issue (see
elsethread).
Dan Tex1
>Date: 6/16/02 8:50 PM Pacific Daylight Time
>Message-id: <j0dP8.23459$qL5.1...@news4.srv.hcvlny.cv.net>
>
>>>>>On Sunday 16 June 2002 04:51 am, Jos A. Horsmeier boldly stated:
>
>> Have you tried compiling Richard's program using a compliant C++
>> compiler? Just for the fun of it? Guess not ...
This is a REAL question... Does a Standard Compliant C++ compiler actually
exist?
Dan :-)
Programmer Dude
>> I haven't had a chance to wade through that 'interesting' array
>> assignment business or decypher the complex expressions in the
>> putchar()s.
>
> The array assignment business is no big deal, actually. The complex
> expressions aren't really all that complex, either.
No, but neither do they give up their 'secrets' at first glance. ;-)
Didn't get a chance to get into this weekend, but soon...
> There's nothing "wrong" with any of the code as such. The biggest
> stretch is probably the stringizing, and yet I /have/ used the
> stringization of identifiers in C programs before now, for good and
> sensible reasons. (Consider, for example, mapping strings to functions.)
Hmmm. Okay, I can see that. I still say it's not a good solution unless
you're quite sure none of them will *ever* collide with reserved names.
Seems to me a more bullet-proof solution would be better. (On the other
hand, when stringizing *function* names I'd suspect collision would be
a lot less likely.)
>> E. The lexical difference must be as small as possible (ideally, but
>> impossibly, zero).
>
> Errrr. This is your wiggle room, your weaseling-out option - yes? :-)
No. That I would lose this contest in the literal sense was always a
given. C is NOT--properly speaking--a sub-set of C++; that was never
the issue. The contention is how close C is to being a subset of C++.
I never expected to *win*, only to demonstrate how close I could come.
That final criteria, "E", is one of the measures of that closeness.
> I suspect that, as C99 becomes more common, my C programs will become
> even less C++-friendly. In any event, good C code isn't necessarily good
> C++ code, so it's a moot point anyway - I'd have to look at every line
> to see whether I consider it good practice in C++, so from my point of
> view there's no real *value* in the notion that C is a practical subset
> of C++.
I agree with all of that. I never write C with C++ mind (and obviously
vice-versa). (Although, come to think of it, I DO tend to avoid keywords
used in C++.)
>> Or using variable *names* as data? Tch, tch. ;-)
>
> I plead guilty to the first but not the second. The second is a
> technique I have used in real code for a good reason.
Okay, but it goes against everything I know about design. I think
I would seek an alternate solution; I'd always be afraid some change
in the language or app spec would change and break the whole system.
>> 2. Line 30: The array initializer is the one really legit trick so far.
>> Shortly expressed, it's this: char A[5] = "Hello";
>> My translation: char A[5] = {'H','e','l','l','o'};
>
> A cunning solution, which I'll accept, even though it breaks rule A.
Thanks!
>> 3. Lines 21, 26-28 & 46-48. Using variable names as data?!?! You're
>> just lucky your client didn't want to include C keywords! My
>> translation is:
>>
>> #define a(b) #b ==> not used
>> char* asm = a(asm); ==> char* Asm = "asm";
>> strcmp (asm, "asm") ==> strcmp (Asm, "asm");
>>
>> Your #define adds nothing to the code in terms of reducing
>> maintenance or errors or in increasing expressiveness.
>
> At this point, I think you're weaseling out. No, really. There *are*
> good reasons to do stringizing of identifiers, and those strings might
> even be stored externally to the program, in a file. Thus, changing the
> variable names really can break the system.
Under normal circumstances, what would you think of a program where just
changing a variable name breaks the system?
>> I claim the translation is is better C, as it won't break if a
>> search/replace mishap changes the variable name.
>
> Sorry, but I can't agree here, for reasons already stated.
Okay, we'll leave this in play and let others contribute. We can, for
now, consider this a divergence (meaning: failure).
>> Lexically, the changes are minor. Semantically they don't exist.
>
> Yes, they do, because you have broken the semantic link between the name
> of the variable and the value of the string to which it points.
I see your point. (I still think it's a Bad Idea. ;-) What if your
client decided they also wanted words like "for" and "while"?? But
this contest isn't about good code verses bad code, so for now, I'll
take the hit on this one.)
Tim Sinkins
Programmer Dude wrote:
>
>
> I agree with all of that. I never write C with C++ mind (and obviously
> vice-versa). (Although, come to think of it, I DO tend to avoid keywords
> used in C++.)
But could this be because they are in the main, 'generic'.
One doesn't use words like buff and value in code, not because they
might be keywords, but because if you did use them, you'd have one
in each function and have 100s of them.
Tim
>
CBFalconer
Why not have 100s of them? That's what local scopes do. If I
want a 'next' or a 'buff' in a routine, I define it right there.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Richard Heathfield
>
> Richard Heathfield wrote:
>
>
> > There's nothing "wrong" with any of the code as such. The biggest
> > stretch is probably the stringizing, and yet I /have/ used the
> > stringization of identifiers in C programs before now, for good and
> > sensible reasons. (Consider, for example, mapping strings to functions.)
>
> Hmmm. Okay, I can see that. I still say it's not a good solution unless
> you're quite sure none of them will *ever* collide with reserved names.
I think I can be reasonably sure that none of my functions will ever
collide with reserved names. Otherwise, the program wouldn't compile.
:-)
> Seems to me a more bullet-proof solution would be better. (On the other
> hand, when stringizing *function* names I'd suspect collision would be
> a lot less likely.)
Quite so. That's my point, really - it's a valid technique. And new,
protected, asm, etc, are all valid function names in C. That I used them
as object names here is neither here nor there.
>
> >> E. The lexical difference must be as small as possible (ideally, but
> >> impossibly, zero).
> >
> > Errrr. This is your wiggle room, your weaseling-out option - yes? :-)
>
> No. That I would lose this contest in the literal sense was always a
> given. C is NOT--properly speaking--a sub-set of C++; that was never
> the issue. The contention is how close C is to being a subset of C++.
How about this? "C and C++ share a large common subset." I think we can
agree on that, can't we?
> I never expected to *win*, only to demonstrate how close I could come.
> That final criteria, "E", is one of the measures of that closeness.
Understood.
>
> > I suspect that, as C99 becomes more common, my C programs will become
> > even less C++-friendly. In any event, good C code isn't necessarily good
> > C++ code, so it's a moot point anyway - I'd have to look at every line
> > to see whether I consider it good practice in C++, so from my point of
> > view there's no real *value* in the notion that C is a practical subset
> > of C++.
>
> I agree with all of that. I never write C with C++ mind (and obviously
> vice-versa). (Although, come to think of it, I DO tend to avoid keywords
> used in C++.)
The very first C program I ever tried to port to C++ used both 'new' and
'delete' all over the shop. Pure coincidence, of course, but fortunate
in that it gave me my first clue that porting between the two is *not*
guaranteed to be simple at any level.
> >> Or using variable *names* as data? Tch, tch. ;-)
> >
> > I plead guilty to the first but not the second. The second is a
> > technique I have used in real code for a good reason.
>
> Okay, but it goes against everything I know about design. I think
> I would seek an alternate solution; I'd always be afraid some change
> in the language or app spec would change and break the whole system.
Fair point, but I think it'll be a long time before they change the C
rules on stringizing.
<snip>
> >> 3. Lines 21, 26-28 & 46-48. Using variable names as data?!?! You're
> >> just lucky your client didn't want to include C keywords! My
> >> translation is:
> >>
> >> #define a(b) #b ==> not used
> >> char* asm = a(asm); ==> char* Asm = "asm";
> >> strcmp (asm, "asm") ==> strcmp (Asm, "asm");
> >>
> >> Your #define adds nothing to the code in terms of reducing
> >> maintenance or errors or in increasing expressiveness.
> >
> > At this point, I think you're weaseling out. No, really. There *are*
> > good reasons to do stringizing of identifiers, and those strings might
> > even be stored externally to the program, in a file. Thus, changing the
> > variable names really can break the system.
>
> Under normal circumstances, what would you think of a program where just
> changing a variable name breaks the system?
I'd think "ah, this must be a C vs C++ thread". :-)
>
> >> I claim the translation is is better C, as it won't break if a
> >> search/replace mishap changes the variable name.
> >
> > Sorry, but I can't agree here, for reasons already stated.
>
> Okay, we'll leave this in play and let others contribute. We can, for
> now, consider this a divergence (meaning: failure).
I don't think it's a failure at all, if by exploring these issues we can
help people reading this thread to understand more about how C and C++
are related and how they differ. Let's look on the bright side, shall
we?
>
> >> Lexically, the changes are minor. Semantically they don't exist.
> >
> > Yes, they do, because you have broken the semantic link between the name
> > of the variable and the value of the string to which it points.
>
> I see your point. (I still think it's a Bad Idea. ;-) What if your
> client decided they also wanted words like "for" and "while"??
Well, they wouldn't, because, in the only remotely sensible application
I can think of for this trick, they'd be using the strings to get a way
to call the functions by name, you see, so their picking and choosing
would be constrained by C rules anyway.
> But
> this contest isn't about good code verses bad code,
Quite so. :-)
> so for now, I'll take the hit on this one.)
>From my point of view, we're just about done. I've shown that it's
possible (and in fact quite easy) to write C code that isn't easily
portable to C++ code, you've shown that a little creativity can get
around some of the obstacles, and we both agree (I think) that C and C++
have a large common subset. Everybody wins, yes?
Tim Sinkins
CBFalconer wrote:
>
> Tim Sinkins wrote:
> > Programmer Dude wrote:
> > >
> > > I agree with all of that. I never write C with C++ mind (and
> > > obviously vice-versa). (Although, come to think of it, I DO
> > > tend to avoid keywords used in C++.)
> >
> > But could this be because they are in the main, 'generic'.
> >
> > One doesn't use words like buff and value in code, not because
> > they might be keywords, but because if you did use them, you'd
> > have one in each function and have 100s of them.
>
> Why not have 100s of them? That's what local scopes do. If I
> want a 'next' or a 'buff' in a routine, I define it right there.
You've obviously never had a problem with one of them and then
wanted to do a global search to see where it's used. It's a right
PITA trying to find the ones that you need when you get 500 matches.
Of course this doesn't happen if the var is really only used in
the proc, but it does if it's passed to a function which uses
the same name, which is then passed to a function .....
Tim
Programmer Dude
> One doesn't use words like buff and value in code, not because they
> might be keywords, but because if you did use them, you'd have one
> in each function and have 100s of them.
Actually, I use buff and buf all the time without problems. Names
like that are always used in small, local scopes. Vars with larger
scopes always have more descriptive names.
Do you make up different names for your loop indexing variables?
CBFalconer
> CBFalconer wrote:
> > Tim Sinkins wrote:
> > >
> > > One doesn't use words like buff and value in code, not because
> > > they might be keywords, but because if you did use them, you'd
> > > have one in each function and have 100s of them.
> >
> > Why not have 100s of them? That's what local scopes do. If I
> > want a 'next' or a 'buff' in a routine, I define it right there.
>
> You've obviously never had a problem with one of them and then
> wanted to do a global search to see where it's used. It's a right
> PITA trying to find the ones that you need when you get 500 matches.
What global search? I said local scope. It CAN'T be used
outside, unless specifically passed out, and I can control/see
that.
Juliet
> This is a REAL question... Does a Standard Compliant C++
> compiler actually exist?
Just one: <http://www.edg.com/cpp.html>
--
< http://www.reactos.com/ > Open source clone of Windows NT. Current
Don't stand, REACT! version 0.0.19. C, C++ and ASM developers
and beta testers are welcome!
Tim Sinkins
CBFalconer wrote:
>
> Tim Sinkins wrote:
> > CBFalconer wrote:
> > > Tim Sinkins wrote:
> ... snip ...
> > > >
> > > > One doesn't use words like buff and value in code, not because
> > > > they might be keywords, but because if you did use them, you'd
> > > > have one in each function and have 100s of them.
> > >
> > > Why not have 100s of them? That's what local scopes do. If I
> > > want a 'next' or a 'buff' in a routine, I define it right there.
> >
> > You've obviously never had a problem with one of them and then
> > wanted to do a global search to see where it's used. It's a right
> > PITA trying to find the ones that you need when you get 500 matches.
>
> What global search? I said local scope. It CAN'T be used
> outside, unless specifically passed out,
this is the point. It can be passed out and if the recipient then
uses the same name..... you have to search for it globally.
> and I can control/see
Naming conventions are not made for you, they're made for the next
person who picks up your code, or more relevantly, for the person
who wrote the code that you have just picked up.
You've either lived an extreamly sheltered life (I get the impression
this isn't the case) or you've been extreamly lucky in your (ex)-
colleagues. I don't live in such a world, often the structure of the
code that I've been asked to work on is appaling, because it has been
written by somone with no specific training. If you'd had to fix an
application where close to 200 modules had the same parameters
and these modules nested to a depth of 6 or 7, you'd see the benefit
in encouraging more uniqueness in variable names.
I'm not for one minute suggesting that this idea is the greatest
things around, it's just that it's simple and easy to explain to
a newby. Trying to explain the nuances of local/global scope to
the Geography grad, that the company have just employed as a
programmer, is like using the ashtray on a motorbike (OK I will
conceed, I am not a good teacher) so one doesn't bother and sticks
with things that are relatively easy to explain. Of course if the
newby sees you not using the rule that you just taught him, he will
stop using it as well.
Is that all clear now
Tim
Tim Sinkins
Programmer Dude wrote:
>
> Tim Sinkins wrote:
>
> > One doesn't use words like buff and value in code, not because they
> > might be keywords, but because if you did use them, you'd have one
> > in each function and have 100s of them.
>
> Actually, I use buff and buf all the time without problems.
I never said it created problems.
> Names like that are always used in small, local scopes. Vars with larger
> scopes always have more descriptive names.
In your code and in mine yes. You should see some of the **** I am
asked to work on - see my reply to Chuck.
> Do you make up different names for your loop indexing variables?
Often I do yes. It aids the 'self-commenting' :-)
Tim
CBFalconer
> CBFalconer wrote:
> > Tim Sinkins wrote:
> > > CBFalconer wrote:
> > > > Tim Sinkins wrote:
> > ... snip ...
> > > > >
> > > > > One doesn't use words like buff and value in code, not because
> > > > > they might be keywords, but because if you did use them, you'd
> > > > > have one in each function and have 100s of them.
> > > >
> > > > Why not have 100s of them? That's what local scopes do. If I
> > > > want a 'next' or a 'buff' in a routine, I define it right there.
> > >
> > > You've obviously never had a problem with one of them and then
> > > wanted to do a global search to see where it's used. It's a right
> > > PITA trying to find the ones that you need when you get 500 matches.
> >
> > What global search? I said local scope. It CAN'T be used
> > outside, unless specifically passed out,
>
> this is the point. It can be passed out and if the recipient then
> uses the same name..... you have to search for it globally.
>
> > and I can control/see
>
> Naming conventions are not made for you, they're made for the next
> person who picks up your code, or more relevantly, for the person
> who wrote the code that you have just picked up.
>
>
> Is that all clear now
The inverse is actually true. I am going to use Pascal to
illustrate, just to annoy.
PROCEDURE a(VAR buff : abuffer); BEGIN .... END;
....
PROCEDURE z(VAR buff : abuffer); BEGIN .... END;
....
PROCEDURE whatzit;
buff : abuffer;
BEGIN
....
a(buff);
....
z(buff);
....
END;
If, for some reason, I want to see where buff is used, I simply
search for "buff" in the sources, and there they are. If I rename
the variable in a ... z then I have to search the code for each
procedure, search that procedure for the new name, etc.
With C I can see whether or not the usage is VAR by the funny
little ampersand in the whatzit procedure call to a etc. However
I have to discard other references in the called procedures, so it
comes out a wash on the average.
The same applies if I am working from the output of a XREF.
I can also use the scope rules to specifically hide a global
within a function, should the mood strike, and thus make it hard
for me to foul a precious variable.
Is that all clear now?
Tim Sinkins
CBFalconer wrote:
>
> The inverse is actually true. I am going to use Pascal to
> illustrate, just to annoy.
It doesn't annoy me, but it doesn't help me. I don't do pascal
> PROCEDURE a(VAR buff : abuffer); BEGIN .... END;
> ....
> PROCEDURE z(VAR buff : abuffer); BEGIN .... END;
> ....
> PROCEDURE whatzit;
>
> buff : abuffer;
>
> BEGIN
> ....
> a(buff);
> ....
> z(buff);
> ....
> END;
>
> If, for some reason, I want to see where buff is used, I simply
> search for "buff" in the sources, and there they are. If I rename
> the variable in a ... z then I have to search the code for each
> procedure, search that procedure for the new name, etc.
If I'm understanding, then this is fine if each 'buff' is in the same
tree. But it isn't, from the 200 modules in my example there were 40
different buffs, each nesting to a depth of 5. I wasn't for one minute
suggesting that the buffs in each nesting-chain should be different,
but that each chain should use a different name.
> With C I can see whether or not the usage is VAR
don't understand the terminology.
> by the funny little ampersand in the whatzit procedure call to a etc.
Nope, none of the names had a funny little ampersand, they are all
arrays so they were already addresses. What point are you making?
> However I have to discard other references in the called procedures,
> so it comes out a wash on the average.
Don't understand this.
> The same applies if I am working from the output of a XREF.
>
> I can also use the scope rules to specifically hide a global
> within a function, should the mood strike,
Don't see the connection. It matters not what the name of the
global is for you to be ablet to do this. In any case I would
caution against such a move unless it were well commented.
> and thus make it hard
> for me to foul a precious variable.
>
> Is that all clear now?
Nope. It's clear that you don't agree with my suggestion about
variable naming. It's not clear why you seem to have extrapolated
this into some assumptions about my level of understanding of
the underlying principles.
Tim
Thomas Stegen
>
> CBFalconer wrote:
>
>
>
>>With C I can see whether or not the usage is VAR
>>
>
> don't understand the terminology.
>
Passed by reference.
Programmer Dude
>>> One doesn't use words like buff and value in code, not because they
>>> might be keywords, but because if you did use them, you'd have one
>>> in each function and have 100s of them.
>>
>> Actually, I use buff and buf all the time without problems.
>
> I never said it created problems.
Sure you did. You're saying using the same variable name in different
scopes makes it difficult to trace a chain of usage. That's a problem.
I understand what you're saying, but I've never found myself passing
the same value down a lot of levels. One or three, perhaps, but not
many, so I just don't have the issue with needing to trace a name. At
least, not often enough to adjust my naming style.
I can say that in nearly three decades of programming, I've never felt
I needed to do a global search to find all uses of a passed value. The
tools I use make it trivially simple to follow the actual thread of
execution. Only time I do global greps is to find, well, global names.
Might just be a style thing.
> In your code and in mine yes. You should see some of the **** I am
> asked to work on - see my reply to Chuck.
I did. You seem to be holding this up as a programming defensive measure
to deal with newbies. If it works for you, then wonderful!
>> Do you make up different names for your loop indexing variables?
>
> Often I do yes. It aids the 'self-commenting' :-)
Yeah, so do I if they're meaningful or exist for more than a few lines.
But in the middle of a for() loop, I tend to use 'ix'.
Programmer Dude
gotten around to finishing my attempts to convert your program. Today
is kinda booked, but hopefully tomorrow I can finish.
Richard Heathfield wrote:
>> I still say it's not a good solution unless you're quite sure none
>> of them will *ever* collide with reserved names.
>
> I think I can be reasonably sure that none of my functions will ever
> collide with reserved names. Otherwise, the program wouldn't compile.
Well, THAT was quite circular of you. ;-)
>> Seems to me a more bullet-proof solution would be better. (On the other
>> hand, when stringizing *function* names I'd suspect collision would be
>> a lot less likely.)
>
> Quite so. That's my point, really - it's a valid technique. And new,
> protected, asm, etc, are all valid function names in C. That I used them
> as object names here is neither here nor there.
Right. My point is, what happens when your client asks you to add to
the list of "new", "protected" and "asm" the keywords "static" and "auto"?
Then your solution breaks.
>> That I would lose this contest in the literal sense was always a
>> given. C is NOT--properly speaking--a sub-set of C++; that was never
>> the issue. The contention is how close C is to being a subset of C++.
>
> How about this? "C and C++ share a large common subset." I think we can
> agree on that, can't we?
Absolutely; we always have. My contention has always been that the subset
is SO large--especially compared to any two other distinct languages--that
folks should lighten up on the anti-C/C++ reactions.
As I said:
>> I never expected to *win*, only to demonstrate how close I could come.
>> That final criteria, "E", is one of the measures of that closeness.
>
> Understood.
And if I can manage to come very, very close when one of the Big Stars
of clc is deliberately making a non-C++ C program....well, that's good
enough for me! ;-)
> The very first C program I ever tried to port to C++ used both 'new' and
> 'delete' all over the shop. Pure coincidence, of course, but fortunate
> in that it gave me my first clue that porting between the two is *not*
> guaranteed to be simple at any level.
A fix would take me (or you) less than five minutes. I've got a GREAT
search and replace tool (WinGrep). Simple change of case of the first
letter would do the trick.
>> Okay, but it goes against everything I know about design. I think
>> I would seek an alternate solution; I'd always be afraid some change
>> in the language or app spec would change and break the whole system.
>
> Fair point, but I think it'll be a long time before they change the C
> rules on stringizing.
I didn't mean the stringizing rules, but the keywords of the language
and the specification of the application. As I said, what happens when
you decide you want "static" or "extern" or "auto"?
>> Under normal circumstances, what would you think of a program where
>> just changing a variable name breaks the system?
>
> I'd think "ah, this must be a C vs C++ thread". :-)
;-)
>> Okay, we'll leave this in play and let others contribute. We can, for
>> now, consider this a divergence (meaning: failure).
>
> I don't think it's a failure at all, if by exploring these issues we can
> help people reading this thread to understand more about how C and C++
> are related and how they differ. Let's look on the bright side, shall
> we?
Oh, sure. I just meant, it's a failure on my part to come up with a
translation acceptable to you.
>> I see your point. (I still think it's a Bad Idea. ;-) What if your
>> client decided they also wanted words like "for" and "while"??
>
> Well, they wouldn't, because, in the only remotely sensible application
> I can think of for this trick, they'd be using the strings to get a way
> to call the functions by name, you see, so their picking and choosing
> would be constrained by C rules anyway.
If I follow, you're saying they wouldn't be allowed to pick C keywords
because they would break the system. That's exactly my objection to
the design. You're putting a completely unnecessary *language* constraint
in place to pull off a "clever" design. Is this really good coding? A
less clever solution doesn't have that constraint.
> From my point of view, we're just about done. I've shown that it's
> possible (and in fact quite easy) to write C code that isn't easily
> portable to C++ code,...
Given some fairly powerful restrictions! Loosening of those restrictions
would give me an easy victory.
> ...you've shown that a little creativity can get around some of the
> obstacles,...
(Could get around ALL of them by breaking my own rules. :-)
> ...and we both agree (I think) that C and C++ have a large common
> subset. Everybody wins, yes?
Yep!
Richard Heathfield
>
> I expended my supply of braineons on the Nilges thread, so I haven't
> gotten around to finishing my attempts to convert your program. Today
> is kinda booked, but hopefully tomorrow I can finish.
Don't sweat it. I really do think that all the necessary points have
been made, on both sides.
>
> Richard Heathfield wrote:
>
> >> I still say it's not a good solution unless you're quite sure none
> >> of them will *ever* collide with reserved names.
> >
> > I think I can be reasonably sure that none of my functions will ever
> > collide with reserved names. Otherwise, the program wouldn't compile.
>
> Well, THAT was quite circular of you. ;-)
Thanks. :-)
>
> >> Seems to me a more bullet-proof solution would be better. (On the other
> >> hand, when stringizing *function* names I'd suspect collision would be
> >> a lot less likely.)
> >
> > Quite so. That's my point, really - it's a valid technique. And new,
> > protected, asm, etc, are all valid function names in C. That I used them
> > as object names here is neither here nor there.
>
> Right. My point is, what happens when your client asks you to add to
> the list of "new", "protected" and "asm" the keywords "static" and "auto"?
> Then your solution breaks.
No, not really, because I explain to Mr Client that his requirement is
broken, since the purpose of the mapping is to allow a user to call a
function by naming it, and you can't have functions called static and
auto.
>
> >> That I would lose this contest in the literal sense was always a
> >> given. C is NOT--properly speaking--a sub-set of C++; that was never
> >> the issue. The contention is how close C is to being a subset of C++.
> >
> > How about this? "C and C++ share a large common subset." I think we can
> > agree on that, can't we?
>
> Absolutely; we always have. My contention has always been that the subset
> is SO large--especially compared to any two other distinct languages--that
> folks should lighten up on the anti-C/C++ reactions.
Ooooooh, we can't have that. What on *earth* would we find to talk about
all day?
>
> As I said:
>
> >> I never expected to *win*, only to demonstrate how close I could come.
> >> That final criteria, "E", is one of the measures of that closeness.
> >
> > Understood.
>
> And if I can manage to come very, very close when one of the Big Stars
> of clc is deliberately making a non-C++ C program....well, that's good
> enough for me! ;-)
If I'd known a clc Big Star was getting involved, I'd have backed out
earlier on to give him plenty of room.
>
> > The very first C program I ever tried to port to C++ used both 'new' and
> > 'delete' all over the shop. Pure coincidence, of course, but fortunate
> > in that it gave me my first clue that porting between the two is *not*
> > guaranteed to be simple at any level.
>
> A fix would take me (or you) less than five minutes.
No, it actually took me several hours of head-scratching. I genuinely
believed, at the time, that all C programs were C++ programs. I couldn't
understand for the life of me why the program wouldn't compile. (Yes,
call me Mr Naive, but there you go.)
> I've got a GREAT
> search and replace tool (WinGrep). Simple change of case of the first
> letter would do the trick.
Heh - I don't think it was around in 1991. Even if it were, I didn't
have a copy.
>
> >> Okay, but it goes against everything I know about design. I think
> >> I would seek an alternate solution; I'd always be afraid some change
> >> in the language or app spec would change and break the whole system.
> >
> > Fair point, but I think it'll be a long time before they change the C
> > rules on stringizing.
>
> I didn't mean the stringizing rules, but the keywords of the language
> and the specification of the application. As I said, what happens when
> you decide you want "static" or "extern" or "auto"?
You clue-by-four the client until he realises his requirement is broken.
:-)
<snip>
> >> I see your point. (I still think it's a Bad Idea. ;-) What if your
> >> client decided they also wanted words like "for" and "while"??
> >
> > Well, they wouldn't, because, in the only remotely sensible application
> > I can think of for this trick, they'd be using the strings to get a way
> > to call the functions by name, you see, so their picking and choosing
> > would be constrained by C rules anyway.
>
> If I follow, you're saying they wouldn't be allowed to pick C keywords
> because they would break the system.
No, not because they'd break the system, but because their requirement
is based (like your objection, I suspect) on a misunderstanding of the
system. Since the whole point of the string-to-function mapping is to
allow a user to decide what function to call by naming it, it's a bit
pointless to provide a mapping where the function end of the mapping
/cannot/ exist.
> That's exactly my objection to
> the design. You're putting a completely unnecessary *language* constraint
> in place to pull off a "clever" design. Is this really good coding? A
> less clever solution doesn't have that constraint.
There is no language constraint at all - as long as you're using C, of
course. :-)
>
> > From my point of view, we're just about done. I've shown that it's
> > possible (and in fact quite easy) to write C code that isn't easily
> > portable to C++ code,...
>
> Given some fairly powerful restrictions! Loosening of those restrictions
> would give me an easy victory.
Sure, and playing darts is easy if you're allowed to walk up to the
board and stick 'em in by hand.
>
> > ...you've shown that a little creativity can get around some of the
> > obstacles,...
>
> (Could get around ALL of them by breaking my own rules. :-)
>
> > ...and we both agree (I think) that C and C++ have a large common
> > subset. Everybody wins, yes?
>
> Yep!
An end of it! Hallelujah! :-)
Tim Sinkins
Programmer Dude wrote:
>
> Tim Sinkins wrote:
>
> I can say that in nearly three decades of programming, I've never felt
> I needed to do a global search to find all uses of a passed value.
Strange I do it all the time (not just passed values, global ones
as well), always have. Times were the tools were nowhere near as
good as now - I once have to fix a bug in some code which contained
a 'page' number that was sometimes wrong. The b****** who had
written the code stored this value in a global var called 'p'.
The search tool did not have a 'find complete word' option.
Jeeze it was a bugger to fix.
> The
> tools I use make it trivially simple to follow the actual thread of
> execution. Only time I do global greps is to find, well, global names.
> Might just be a style thing.
Yep, it's what works for me
Tim
Programmer Dude
>> I can say that in nearly three decades of programming, I've never felt
>> I needed to do a global search to find all uses of a passed value.
>
> Strange I do it all the time (not just passed values, global ones
> as well), always have. Times were the tools were nowhere near as
> good as now -
True (although unix regular expressions have been around a while).
> I once have to fix a bug in some code which contained a 'page'
> number that was sometimes wrong. The b****** who had written the
> code stored this value in a global var called 'p'. The search
> tool did not have a 'find complete word' option. Jeeze it was a
> bugger to fix.
A wonderful illustration of the problem with globals! And also a
good illustration of how NOT to do them when you DO do them. ;-)
--
|_ CJSonnack <Ch...@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|
Opinions expressed herein are my own and may not represent those of my employer.
Programmer Dude
> Here is the program. Good luck, Chris. :-)
The biggest issue was the stringizing technique. Everything else was
ultimately fairly easy to solve. Here's the code (with some minimal
reformating for line-spacing)(to keep this shorter and more managable
(like my hair), I'll post another post with discussion).
/* Please convert this program to C++ using the
* following rules:
*
* 1) the program must remain a valid C program.
* 2) you may refactor recursive main() - so I
* didn't bother to use one.
* 3) you may rename identifiers, including function
* names, as long as doing so does not change the
* output of the program.
* 4) you may add casts.
* 5) you can't change the program in any other way.
* That means you can't add header files, you can't
* add keywords, you can't change or remove comments,
* and you can't add whitespace or anything else.
* 6) I could have made this a lot harder!
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define a(b) #b
const int SPACE = ' ';
int main (void)
{
char* Asm = "asm";
char* Protected = "protected";
char* Using = "using";
char* b[28] = {0};
char title__of__the__program [81] =
{ 'C',' ','t','o',' ','C','+','+',' ','T',
'r','a','n','s','l','a','t','i','o','n',
'\n','O','N','L','Y',' ','e','x','t','r',
'a',' ','c','a','s','t','s',' ','a','n',
'd',' ','r','e','n','a','m','i','n','g',
' ','o','f',' ','v','a','r','i','a','b',
'l','e','s',' ','a','r','e',' ','a','l',
'l','o','w','e','d','.','\n','\n','\n','\n',
'\n' };
auto i = strlen(Protected) -
(sizeof SPACE / /* we need a space\
in here somewhere */ sizeof (int
) + strlen(Asm) + strlen(Using));
if ( strcmp (Asm, "asm") != 0
|| strcmp (Protected, "protected") != 0
|| strcmp (Using, "using") != 0)
{
puts ("Error!");
return EXIT_FAILURE;
}
b[ 0] = Asm + 1;
b[ 1] = b[ 0] - 1;
b[ 2] = Protected + 8;
b[ 4] = b[ 2] - 8;
b[ 5] = b[ 4] + 1;
b[ 6] = b[ 5] + 1;
b[ 7] = Using + 4;
b[ 8] = b[5];
b[ 9] = b[ 0] - 1;
b[10] = b[ 0] + 1;
b[11] = b[10];
b[12] = b[ 2] - 4;
b[13] = b[12] - 3;
b[14] = b[ 0];
b[16] = b[ 2];
b[17] = b[16] - 6;
b[19] = b[ 7] - 1;
b[20] = b[ 2] - 6;
b[21] = b[20] + 1;
b[23] = b[ 7] - 4;
b[24] = b[23] + 1;
b[25] = b[ 2] - 4;
b[27] = b[25] + 1;
printf ("%.*s\n", sizeof title__of__the__program,
title__of__the__program);
while (i < sizeof b / sizeof b[0])
{
if (b[i] != NULL)
{
if (i == sizeof(char) / sizeof SPACE
|| i == sizeof b / sizeof b[0] - 1)
{
int ch = b[i][sizeof(char)/sizeof SPACE] ;
putchar (toupper((unsigned char)ch));
}
else
{
int ch = b[i][sizeof(char)/sizeof SPACE] ;
putchar (tolower((unsigned char)ch));
}
}
else
{
putchar (SPACE);
}
i += strlen (Protected) - (strlen(Asm) + strlen(Using));
}
putchar ('.' * sizeof SPACE / sizeof(int));
putchar ('\n');
return 0;
Programmer Dude
> I really do think that all the necessary points have been made, on both
> sides.
I pretty much agree. This is my final rebuttal, and the reply to your
original post comprises my, as they apparently say on that game show,
"final answer". ;-)
>> My point is, what happens when your client asks you to add to
>> the list of "new", "protected" and "asm" the keywords "static" and
>> "auto"? Then your solution breaks.
>
> No, not really, because I explain to Mr Client that his requirement is
> broken, since the purpose of the mapping is to allow a user to call a
> function by naming it, and you can't have functions called static and
> auto.
And in C++ you can't have functions named "protected" or "asm", I see
what you're saying.
Seems to me a far better system involves taking ones putative functions
completely out of the collision zone by using case or underbars.
[shrug] Well, we agree this isn't about ideal (or not) solutions, but
about converting code. In the case of this technique and a client who
insists on functions named "asm" and "protected" (but not "static" or
"auto"), you cannot make a straight-to-C++ translation.
> If I'd known a clc Big Star was getting involved, I'd have backed out
> earlier on to give him plenty of room.
Heh. I always liked the line about the opera singer's voice filling the
room. So much so people got up and left to make room for it. ;-)
>> I've got a GREAT search and replace tool (WinGrep). Simple change of
>> case of the first letter would do the trick.
>
> Heh - I don't think it was around in 1991. Even if it were, I didn't
> have a copy.
If you do much programming in the Winders environment, I can't recommend
it highly enough. I use it constantly. It does recursive directory
scanning, multiple filespecs, remembers past searches, shows you the
output colorized, and you can double-click a grep'd line to open the
source in your favorite editor (vim for both of us, I believe) at that
line. You can save search results as RTF files (keeping the colorizing).
And you can do simple replacements on the searched for strings.
He does implement basic regexp for searching, and you can use that or
simple string matching (faster). If I had any complaint it would be
that replacement is simple, not complex. That is, you can't bracket
part of the search pattern and use it in the replacement.
Well worth the shareware fee! Plus, the guy's a Brit!!
> You clue-by-four the client until he realises his requirement is broken.
> :-)
Clue-by-four! I like it. Can I apply that logic in getting the client
to simply uppercase his function names? :-) It makes for a far more
robust system and lets him use his precious "Static" and "Auto"!
>> Loosening of those restrictions would give me an easy victory.
>
> Sure, and playing darts is easy if you're allowed to walk up to the
> board and stick 'em in by hand.
They complain when I do that at the bar. ;-(
Alright, anyway, he come de final answer!
--
|_ CJSonnack <Ch...@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|
Opinions expressed herein are my own and may not represent those of my employer.
Programmer Dude
1: #define SPACE ' ' ==> const int SPACE = ' ';
Maintains semantics (although is lexically fairly different).
Is a 100% valid C solution (and the preferred C++ solution).
2: (array initializer) changed per previous discussion
3: char* asm = a(asm); ==> char* Asm = "asm"; // solution #1
char* asm = a(asm); ==> char* Asm = a(Asm); // solution #2
Breaks your solution, but allows the program to be compiled as
a C++ program with a minor lexical change. This is the biggest
"failure" to translate, but as I feel this is a very small
problem domain and other solutions exist, I don't feel too bad
about it. A *small* change (per #2) to the customer requirement
would allow this to work exactly as originally written and open
the function domain to "static", "auto" et alii.
4: (sizeof SPACE //* we need a space\ ==> (sizeof SPACE / /* we ...
Addition of a single space. Identical semantics, minor lexical
change, better code (doesn't break under C99).
Four changes, two trivial (#1 & #4), one simple (#2) and one biggie (#3).
The only change that, in any way, alters the semantics is #3.
And I think that in a small program *designed* to be non-translatable,
only one significant change is not too bad. Not too bad at all.
So whadda ya think, can we stop haranguing people about using the
"C/C++" symbol? (Or even agree they probably really do mean "C and/or
C++"?)
In closing: this was fun!!! ;-)
Jim Rogers
By that I mean languages whose syntax is not inherited from C.
Program translation to another language is much more fun
and interesting when the two languages have different
syntactic roots.
Jim Rogers
Programmer Dude
[grin] For interesting values of "interesting"!
Okay, what algorithm do you propose we implement?
Jim Rogers
> [grin] For interesting values of "interesting"!
Yes. English being a very irregular language, interesting
has many "interesting" meanings.
> Okay, what algorithm do you propose we implement?
I was thinking it would be interesting to implement a **simple**
manufacturing simulation. This simulation would model a
factory that uses Just-In-Time manufacturing rules for its two
manufacturing lines. One line produces subassemblies consumed
by the other line. Between the two lines is a small inventory
area capable of holding no more than five subassemblies.
When the inventory area is full the producer must suspend.
When the inventory area is empty the consumer must suspend.
I would like to see how such a problem is solved using various
languages. I will provide a solution using Ada, with the
producer and consumer being separate tasks and the inventory
area being a shared buffer.
Jim Rogers
CBFalconer
IMO this is just the standard producer/consumer problem, with a
configurable count of buffers, and some fairly trivial concurrency
constructs, such as semaphores or monitors.
Jos A. Horsmeier
news:3D13A454...@mmm.com...
> Jim Rogers wrote:
>
> > How about opening the next contest to non-C languages.
> > By that I mean languages whose syntax is not inherited from C.
> >
> > Program translation to another language is much more fun
> > and interesting when the two languages have different
> > syntactic roots.
>
> [grin] For interesting values of "interesting"!
>
> Okay, what algorithm do you propose we implement?
That reminds me ... does anyone remember that wonderful little
program named 'polyglot'? It was a paged size mixture of C,
Pascal and Cobol (and possibly some other language, I can't
remember). When fed to a C, Pascal or Cobol compiler, they
all generated valid code and when the code was run, the
famous 'hell world' output was printed ...
It was a clever combination of hiding the other languages
in one language's comments. I've never seen it since ...
kind regards,
Jos aka j...@gen.nl
Richard Heathfield
Given that the whole point of this thread was to establish whether or
not C programs were C++ programs given a minimal amount of tweaking, I
don't think a vastly different language would be a great idea.
Having said that, if you simply want to compare implementations of a
particular algorithm in multiple languages, that's a worthy exercise in
itself.
Richard Heathfield
>
<snip>
>
> And I think that in a small program *designed* to be non-translatable,
> only one significant change is not too bad. Not too bad at all.
You did very well indeed, but of course we both know the gloves were on.
>
> So whadda ya think, can we stop haranguing people about using the
> "C/C++" symbol? (Or even agree they probably really do mean "C and/or
> C++"?)
No, we can't stop. Or rather, I won't stop. :-)
>
> In closing: this was fun!!! ;-)
Good. :-)
Jim Rogers
> Jim Rogers wrote:
>
>>How about opening the next contest to non-C languages.
>>By that I mean languages whose syntax is not inherited from C.
>>
>>Program translation to another language is much more fun
>>and interesting when the two languages have different
>>syntactic roots.
>>
>
> Given that the whole point of this thread was to establish whether or
> not C programs were C++ programs given a minimal amount of tweaking, I
> don't think a vastly different language would be a great idea.
>
> Having said that, if you simply want to compare implementations of a
> particular algorithm in multiple languages, that's a worthy exercise in
> itself.
Yes, that is my goal. I suspect it should be done in another thread.
I think it would be instructive to see how a common problem such as
the consumer/producer problem I suggessted is implemented in several
languages.
The goal is clearly not to establish that one language is better than
another, but to demonstrate different approaches and implementations
to a well understood problem. My hope is that we can all learn
something by being exposed to different language solution techniques.
Jim Rogers
John W. Krahn
>
> That reminds me ... does anyone remember that wonderful little
> program named 'polyglot'? It was a paged size mixture of C,
> Pascal and Cobol (and possibly some other language, I can't
> remember). When fed to a C, Pascal or Cobol compiler, they
> all generated valid code and when the code was run, the
> famous 'hell world' output was printed ...
>
> It was a clever combination of hiding the other languages
> in one language's comments. I've never seen it since ...
http://perlgolf.sourceforge.net/cgi-bin/PGAS/post_mortem.cgi?id=3#art
http://perlgolf.sourceforge.net/cgi-bin/PGAS/post_mortem.cgi?id=4#art
Have examples of two programs that work in C, Perl, Befunge and
Brainfuck.
:-)
John
--
use Perl;
program
fulfillment
Richard Heathfield
>
<snip>
>
> The goal is clearly not to establish that one language is better than
> another, but to demonstrate different approaches and implementations
> to a well understood problem. My hope is that we can all learn
> something by being exposed to different language solution techniques.
This does indeed sound like a good idea not just for one thread, but for
several. Probable in series rather than in parallel, though! :-)
The producer/consumer one sounds like it'll make a fair start, but we
could then perhaps move on to other algorithms.
Why don't you start a new thread when your producer/consumer is ready?
Then we can see what the take-up is like; if it's high, we can perhaps
take that as a sign that people would like to see more of the same.
Jos A. Horsmeier
news:3D1513A3...@acm.org...
> "Jos A. Horsmeier" wrote:
[ polyglot: ]
> > It was a clever combination of hiding the other languages
> > in one language's comments. I've never seen it since ...
> http://perlgolf.sourceforge.net/cgi-bin/PGAS/post_mortem.cgi?id=3#art
> http://perlgolf.sourceforge.net/cgi-bin/PGAS/post_mortem.cgi?id=4#art
>
> Have examples of two programs that work in C, Perl, Befunge and
> Brainfuck.
Yuck, these are so awfully nasty! ;-)
thanks for the links,
Jos aka j...@gen.nl
Programmer Dude
>> And I think that in a small program *designed* to be non-translatable,
>> only one significant change is not too bad. Not too bad at all.
>
> You did very well indeed, but of course we both know the gloves were on.
[grin] I'm not sure if you mean kid gloves or boxing gloves... ;-)
>> So whadda ya think, can we stop haranguing people about using the
>> "C/C++" symbol? (Or even agree they probably really do mean "C and/or
>> C++"?)
>
> No, we can't stop. Or rather, I won't stop. :-)
Drat! (Although NOW at least I know why!! :-)
Programmer Dude
> My hope is that we can all learn something by being exposed to different
> language solution techniques.
A fine idea!