Simplicity has a future

T

Tomás

Keith Thompson posted:
int main(void)
{
int new;
return 0;
}


Smart. If pedantry is what you're after, then:


If I copy-paste your C code, and then go through it for:

(a) Use of C++ keywords

(b) Inconsistencies between C and C++


And then compile it, I guarantee that the C++ version won't be slower or
require more memory.


-Tomás
 
T

Tomás

Richard Heathfield posted:
foo *foo_create(int bar)
{
foo *new = malloc(sizeof *new);
if(new != NULL)
{
new->bar = bar;
}
return new;
}

specifically to remind me, should I ever try to use a C++ compiler on
the code, that I'm making a big mistake.


A facility as simple as "find and replace" solves the keyword problem.


-Tomás
 
T

Tomás

Old Wolf posted:


JKop wrote that code, not me. Why are you referring me to someone else's
code?

This is the second time you have mistakenly associated me with this JKop
character, and I explained to you the last time that there's no relation.

Next time I find someone who posts from the same country as you, and uses
the same news reader as you, shall I assume that that person is you?



JKop again.



JKop again. (However it's intriguing what he said about "binding a
pointer to a temporary").




JKop again. (Here he's confused about const member functions).





JKop again. (Here he's confused with "return by value").





JKop again.


-Tomás
 
K

Keith Thompson

Tomás said:
Keith Thompson posted:

Smart. If pedantry is what you're after, then:

If I copy-paste your C code, and then go through it for:

(a) Use of C++ keywords

(b) Inconsistencies between C and C++

And then compile it, I guarantee that the C++ version won't be slower or
require more memory.

I agree that it's very likely, but I don't see how you can guarantee
it without a lot more caveats.

If I run the program on a faster computer than you do, mine will
probably be faster than yours. If I use a better compiler than you
do, mine will likely be faster than yours. Many compiler suites that
include C and C++ compilers use different frontends for the two
languages; the C frontend might happen to generate better code than
the C++ frontend.

All else being equal, there's no reason I know of to assume that a
program written in the common subset of C and C++ will be more
efficient when compiled as C than when compiled as C++ (or vice
versa). I'm not confident enough of that to offer to consume any
headgear.
 
R

Richard Heathfield

Tomás said:
Richard Heathfield posted:



A facility as simple as "find and replace" solves the keyword problem.

Yes, but the problem with simple solutions is that they are sometimes too
simple. For example, s/new/newobject/g is a simple fix, but quite likely to
result in tears.
 
F

Friedrich Dominicus

SuperKoko said:
Try to write OOP with GObject in C, and you'll see that C++ would be
better for that task.

Well and much better would be using Objective-C...

Yes, simplicity attracts people.
As far as people use only simple things, they are happy, and there have
no reason of learning a complex language.
But when they write complex things, they realize that a complex
language in fact helps a lot, and simplifies their program.
The complex language must not be C++. And one can have a lot of the
"nice stuff" in other language far better packaged.
And, if you read the C99 standard, you'll see that C is not so simple
that it seems to be (even if it is simplier than C++).
That's too true unfortuntatly.

Regards
Friedrich
 
B

Ben Pfaff

Tomas said:
Richard Heathfield posted:


A facility as simple as "find and replace" solves the keyword problem.

Yes, and at the same time it screws up all the comments that use
"new" as an English word.
 
R

Richard Heathfield

Tomás said:
If I copy-paste your C code, and then go through it for:

(a) Use of C++ keywords

(b) Inconsistencies between C and C++


And then compile it, I guarantee that the C++ version won't be slower or
require more memory.

But the C++ version may well be a very different program as a result of your
changes, so the comparison will no longer be valid.

But if you want to give it a go, please feel free. In fact, if you like, I
won't ask you to make the following C program a faster, tighter C++
program. I will merely ask you to change it sufficiently to make it legal
C++ whilst leaving its essential character untouched, so that comparison
between the C and C++ object file translations will be meaningful. The
program must, of course, remain valid C. To leave its essential character
unchanged, I must ask that you observe 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.
4) you may add casts and modify whitespace.
5) you can't change the program in any other way.
6) the output of the program must remain unchanged, of course.


#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define a(b) #b
#define SPACE ' '

int main(void)
{
const char *asm = a(asm);
const char *protected = a(protected);
const char *using = a(using);
const 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",
(int)sizeof title__of__the__program,
title__of__the__program);

while(i < sizeof b / sizeof b[0])
{
if(b != NULL)
{
if(i == sizeof(char) / sizeof SPACE ||
i == sizeof b / sizeof b[0] - 1)
{
putchar(toupper((unsigned char)
b[sizeof(char)/sizeof SPACE]));
}
else
{
putchar(tolower((unsigned char)
b[sizeof(char)/sizeof SPACE]));
}
}
else
{
putchar(SPACE);
}
i += strlen(protected) - (strlen(asm) + strlen(using));
}

putchar('.' * sizeof SPACE / sizeof(int));
putchar('\n');

return 0;

}
 
F

Flash Gordon

Ben said:
Yes, and at the same time it screws up all the comments that use
"new" as an English word.

Or even worse messages that are output to the user.

Please enter then newobject price:
 
G

Guest

Richard said:
Tomás said:
If I copy-paste your C code, and then go through it for:

(a) Use of C++ keywords

(b) Inconsistencies between C and C++


And then compile it, I guarantee that the C++ version won't be slower or
require more memory.

But the C++ version may well be a very different program as a result of your
changes, so the comparison will no longer be valid.

But if you want to give it a go, please feel free. In fact, if you like, I
won't ask you to make the following C program a faster, tighter C++
program. I will merely ask you to change it sufficiently to make it legal
C++ whilst leaving its essential character untouched, so that comparison
between the C and C++ object file translations will be meaningful. The
program must, of course, remain valid C. To leave its essential character
unchanged, I must ask that you observe 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.
4) you may add casts and modify whitespace.
5) you can't change the program in any other way.
6) the output of the program must remain unchanged, of course.


#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define a(b) #b
#define SPACE ' '

int main(void)
{
const char *asm = a(asm);
const char *protected = a(protected);
const char *using = a(using);
const 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",
(int)sizeof title__of__the__program,
title__of__the__program);

while(i < sizeof b / sizeof b[0])
{
if(b != NULL)
{
if(i == sizeof(char) / sizeof SPACE ||
i == sizeof b / sizeof b[0] - 1)
{
putchar(toupper((unsigned char)
b[sizeof(char)/sizeof SPACE]));
}
else
{
putchar(tolower((unsigned char)
b[sizeof(char)/sizeof SPACE]));
}
}
else
{
putchar(SPACE);
}
i += strlen(protected) - (strlen(asm) + strlen(using));
}

putchar('.' * sizeof SPACE / sizeof(int));
putchar('\n');

return 0;

}


c.c: In function ‘main’:
c.c:17: error: type defaults to ‘int’ in declaration of ‘i’
c.c:20: error: expected ‘,’ or ‘;’ before ‘)’ token
c.c:64: error: implicit declaration of function ‘toupper’
c.c:69: error: implicit declaration of function ‘tolower’

That's compiling as C, not as C++.
 
J

James Dow Allen

The notion that C++ is "better" than C because it is (almost) a
superset,
is a very bad notion and should be stamped out. (C++ of course is not
an exact superset anyway, but that dead horse is already being beaten
to death again in another subthread.)

Dennis Ritchie's famous comments on adding new keywords to C may shed
some light on why adding features to a language is not an unmixed
blessing:
This is an essay on why I do not like X3J11 type qualifiers....
Let me begin by saying that I'm not convinced that even the pre-December
qualifiers (`const' and `volatile') carry their weight; I suspect that what
they add to the cost of learning and using the language is not repaid in
greater expressiveness.
... Nevertheless, I don't argue for the extirpation of qualifiers, if only because
it is too late.

For those who want to read the entire essay, Google search for its most
famous line:
Noalias must go. This is non-negotiable.

If supersets are so good, why didn't PL/1 catch on? It was sort of
a superset of Fortran, Cobol and some Algol.

Frankly, I find it much more fun to program in a simple language!
(And a happy programmer is a productive programmer!)
Look Tomas,
you should restrain from insulting other people just because they refuse
to learn all the complexities of C++.

No, we should all be grateful that such an awesome genius condescends
to spend time in this newsgroup, of the Language for Dummies. :)
C has less surprises, less to learn, and uses FAR LESS MEMORY.
... HUMAN MEMORY, a far more precious resource than RAM!

Transparency is what I like! We know exactly what malloc() and free()
do, but may have to study an inheritance maze to guess about
new and delete. Implicit deletes horrify me; I'd probably add
unnecessary
explicit delete's just to call attention!

I have tried to get into the C++ spirit. Once I read a magazine
article about
a general purpose delete routine. If an object contains a pointer to
another object do you delete that object also? To me, this is
obviously
a decision to be made by the programmer on the spot, but the writer
seemed to feel programmers should call his general-purpose routine
that made the decision with a crude heuristic! (IIRC, he deletes it
iff
it isn't null or a self-pointer.)
People that reject a language where they can't possibly know what
are they calling, aren't stupid. The contrary is true. They just
follow the KISS principle!

KEEP IT SIMPLE!

jacob

Glad to hear from someone who agrees with me!

James
 
I

Ian Collins

Harald said:
Richard said:
Tomás said:

If I copy-paste your C code, and then go through it for:

(a) Use of C++ keywords

(b) Inconsistencies between C and C++


And then compile it, I guarantee that the C++ version won't be slower or
require more memory.

But the C++ version may well be a very different program as a result of your
changes, so the comparison will no longer be valid.

But if you want to give it a go, please feel free. In fact, if you like, I
won't ask you to make the following C program a faster, tighter C++
program. I will merely ask you to change it sufficiently to make it legal
C++ whilst leaving its essential character untouched, so that comparison
between the C and C++ object file translations will be meaningful. The
program must, of course, remain valid C. To leave its essential character
unchanged, I must ask that you observe 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.
4) you may add casts and modify whitespace.
5) you can't change the program in any other way.
6) the output of the program must remain unchanged, of course.


#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define a(b) #b
#define SPACE ' '

int main(void)
{
const char *asm = a(asm);
const char *protected = a(protected);
const char *using = a(using);
const 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",
(int)sizeof title__of__the__program,
title__of__the__program);

while(i < sizeof b / sizeof b[0])
{
if(b != NULL)
{
if(i == sizeof(char) / sizeof SPACE ||
i == sizeof b / sizeof b[0] - 1)
{
putchar(toupper((unsigned char)
b[sizeof(char)/sizeof SPACE]));
}
else
{
putchar(tolower((unsigned char)
b[sizeof(char)/sizeof SPACE]));
}
}
else
{
putchar(SPACE);
}
i += strlen(protected) - (strlen(asm) + strlen(using));
}

putchar('.' * sizeof SPACE / sizeof(int));
putchar('\n');

return 0;

}



c.c: In function ‘main’:
c.c:17: error: type defaults to ‘int’ in declaration of ‘i’
c.c:20: error: expected ‘,’ or ‘;’ before ‘)’ token
c.c:64: error: implicit declaration of function ‘toupper’
c.c:69: error: implicit declaration of function ‘tolower’

That's compiling as C, not as C++.

My C compiler gave several screens of errors and warning before giving up.
 
R

Richard Heathfield

Harald van D?k said:
Richard said:
Tomás said:
If I copy-paste your C code, and then go through it for:

(a) Use of C++ keywords

(b) Inconsistencies between C and C++


And then compile it, I guarantee that the C++ version won't be slower
or require more memory.

But the C++ version may well be a very different program as a result of
your changes, so the comparison will no longer be valid.

But if you want to give it a go, please feel free. In fact, if you like,
I won't ask you to make the following C program a faster, tighter C++
program. I will merely ask you to change it sufficiently to make it legal
C++ whilst leaving its essential character untouched, so that comparison
between the C and C++ object file translations will be meaningful. The
program must, of course, remain valid C. To leave its essential character
unchanged, I must ask that you observe 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.
4) you may add casts and modify whitespace.
5) you can't change the program in any other way.
6) the output of the program must remain unchanged, of course.


#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define a(b) #b
#define SPACE ' '

int main(void)
{
const char *asm = a(asm);
const char *protected = a(protected);
const char *using = a(using);
const 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",
(int)sizeof title__of__the__program,
title__of__the__program);

while(i < sizeof b / sizeof b[0])
{
if(b != NULL)
{
if(i == sizeof(char) / sizeof SPACE ||
i == sizeof b / sizeof b[0] - 1)
{
putchar(toupper((unsigned char)
b[sizeof(char)/sizeof SPACE]));
}
else
{
putchar(tolower((unsigned char)
b[sizeof(char)/sizeof SPACE]));
}
}
else
{
putchar(SPACE);
}
i += strlen(protected) - (strlen(asm) + strlen(using));
}

putchar('.' * sizeof SPACE / sizeof(int));
putchar('\n');

return 0;

}


c.c: In function ?main?:
c.c:17: error: type defaults to ?int? in declaration of ?i?


That's not an error. It's perfectly legal C90.
c.c:20: error: expected ?,? or ?;? before ?)? token

I forgot a line-splice \ when splitting the line for Usenet. Sorry about
that.
c.c:64: error: implicit declaration of function ?toupper?
c.c:69: error: implicit declaration of function ?tolower?

Those aren't errors (in C90) either. Both of those functions return int, and
neither is variadic.
That's compiling as C, not as C++.

I'll take the hit on the splice, which is trivially fixable. The others are
only errors in C99, which doesn't count.
 
R

Richard Heathfield

Ian Collins said:
My C compiler gave several screens of errors and warning before giving up.

Try it again, fixing the trivial error on line 20 (for which I apologise).
Any errors you get then will be either because you have managed to dig up a
C99 compiler from somewhere (and I don't claim that the program is valid
C99), or because your compiler is simply issuing diagnostics for the sake
of it. Modulo the linesplice accident, the program is, as far as I'm aware,
a legal C90 program.
 
R

Richard Heathfield

Richard Heathfield said:
I'll take the hit on the splice, which is trivially fixable. The others
are only errors in C99, which doesn't count.

I've changed my mind. I really should read my own code before posting!

There is no line splicing error on line 20. *All* the reported errors would
appear to be irrelevant to a C90 compiler.
 
G

Guest

Richard said:
Ian Collins said:


Try it again, fixing the trivial error on line 20 (for which I apologise).
Any errors you get then will be either because you have managed to dig up a
C99 compiler from somewhere (and I don't claim that the program is valid
C99),

You claimed the program was valid C. Silly me for assuming you would
refer to an older standard without stating so.

That aside, though, your rules are obviously intentionally
unreasonable, as it is entirely possible to modify your program to make
it valid C++ without modifying either its "essential character" or its
output.
 
I

Ian Collins

Richard said:
I'll take the hit on the splice, which is trivially fixable. The others are
only errors in C99, which doesn't count.
Hang on a minute, you're posting code that won't compile as C99 and
asking the audience to convert it to C++? Given your original rules, it
can't be morphed to C99, let alone C++.

I'm sure I could turn my C99 compiler back to C90, but why bother?
Maybe if you can explain the usefulness to mankind of the code, I might
give it a go....
 
R

Richard Heathfield

Harald van D?k said:
You claimed the program was valid C.

It is.
Silly me for assuming you would refer to an older standard without stating
so.

It is certainly silly to assume that everyone has started using C99 even
though almost nobody has a conforming C99 compiler.
That aside, though, your rules are obviously intentionally
unreasonable, as it is entirely possible to modify your program to make
it valid C++ without modifying either its "essential character" or its
output.

Go on then.
 
I

Ian Collins

Richard said:
Ian Collins said:




Try it again, fixing the trivial error on line 20 (for which I apologise).
Any errors you get then will be either because you have managed to dig up a
C99 compiler from somewhere (and I don't claim that the program is valid
C99), or because your compiler is simply issuing diagnostics for the sake
of it. Modulo the linesplice accident, the program is, as far as I'm aware,
a legal C90 program.
One good reason for passing C though a C++ compiler:

"/tmp/x.c", line 16: Error: Cannot use const char[82] to initialize
char[81].
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,786
Messages
2,569,626
Members
45,328
Latest member
66Teonna9

Latest Threads

Top