V
vinay.khankari
How to Print the complete source program as output of the program?
V
Victor Bazarov
Please google for "self-printing program". It is a fun problem to
solve, but IIRC, it doesn't have any portable solution.
V
P
Pavel Lepin
Victor Bazarov said:
Or, better yet, "quine".
Why not? What am I missing? Some of the C++ quines I've
found in a couple of minutes of googling (e.g., a David
Rogers' one on Gary Thompson's page) seem to be easily
adapted to be standard-compliant and reasonably portable.
V
Victor Bazarov
Pavel said:
Most of them involve ASCII coding. That's not portable.
V
J
Juha Nieminen
Victor said:
How many systems can you mention which are used today and which
do not use ASCII coding?
Heck, *no* C++ source code is portable to systems which do not
use ASCII coding because the source code itself uses ASCII coding.
?
=?ISO-8859-1?Q?Erik_Wikstr=F6m?=
I believe that IBM still uses EBCDIC on their z series machines.
Not unless it's not written on a machine which uses ASCII, besides I
don't think the C++ standard defines how the source should be encoded,
only which characters that can be expected to be recognised.
J
Jim Langston
Juha Nieminen said:
Sure it is. Take, for example, an AS/400 which uses EBCDIC. You can
download source code, which was encoded in ASCII, which the AS/400
communications will automatically convert to EBCDIC, giving you the same
source code but with different encoding.
What source code is encoded in isn't actually part of the source code, just
how it's transmitted/stored.
J
Jerry Coffin
I suppose that depends a bit on how you define "portable". Here's my
mildly edited version of David Roger's attempt:
---------------Start--------------------
#include <iostream>
#define Q(T) std::cout << T << "(" << #T << ");}";
int main()
{Q("#include <iostream>\n#define Q(T) std::cout << T << \"(\" << #T <<
\");}\";\n\nint main()\n{Q");}
---------------Finish-------------------
[Note: everything from the "{Q" to the end should be one line.]
I think this qualifies as "portable" the way most people use the term. I
believe it should work equally well with EBCDIC or ASCII.
In theory, it does have a couple of minor shortcomings: 1) the final
line in the output isn't terminated by a newline. 2) its source includes
characters not present in the ISO 646 character set, so it couldn't be
entered on an ISO 646 terminal (but I definitely do NOT want to get into
the ugliness of trigraphs...)
Other than that, you could theoretically rule it out because it writes
to standard output in translated mode, which allows an implementation
defined mapping between what you write and what really appears as the
output. Likewise, there's an implementation defined mapping from the
source character set to the execution character set. On a purely
theoretical basis, these allow it to produce essentially anything (or
nothing at all) as output.
OTOH, by most of these criteria virtually NO code is portable!
J
James Kanze
The ones I've seen don't suppose any particular coding. The
classical example is in "http://www.acm.org/classics/sep95/",
and there's nothing that depends on ASCII there.
J
James Kanze
They did the last time I looked.
(Strictly speaking, ASCII is dead, and no recent machine uses
it. But the encodings they do use, such as ISO 8859-1 or UTF-8,
do usually contain ASCII as a subset.)
There's a very definite reason why ftp has two modes: binary and
"ascii". Even between Windows and Unix, you need to map the
representation of '\n' (and possibly EOF).
The assumption for a self reproducing program, of course, is
that it will be compiled on the machine on which it runs, or
else that the output will be "translated" from the encoding used
on that machine to the encoding used by the machine with the
compiler. Translation which is necessary for the output of any
program generating text.
B
Bo Persson
James Kanze wrote:
:: On 2007-08-04 00:48, Juha Nieminen wrote:
::: Victor Bazarov wrote:
:::: Most of them involve ASCII coding. That's not portable.
:
::: How many systems can you mention which are used today and which
::: do not use ASCII coding?
:
:: I believe that IBM still uses EBCDIC on their z series machines.
:
: They did the last time I looked.
They sure do!
:
::: Heck, *no* C++ source code is portable to systems which do not
::: use ASCII coding because the source code itself uses ASCII coding.
:
:: Not unless it's not written on a machine which uses ASCII, besides
:: I don't think the C++ standard defines how the source should be
:: encoded, only which characters that can be expected to be
:: recognised.
:
: There's a very definite reason why ftp has two modes: binary and
: "ascii". Even between Windows and Unix, you need to map the
: representation of '\n' (and possibly EOF).
I can add a bit of trivia to this, by explaining what happens when you
ftp between a PC and a Z-series mainframe.
The "ascii" command tells the ftp processors (one at each end!) that
the *transfer* is done in text mode. It doesn't tell anything about
how the file is encoded at either end. At the Z-series end, the ftp
processor will translate "ascii" mode transfers to/from EBCDIC, when
communicating with a non-EBCDIC device.
This means that source code actually IS portable between ASCII and
EBCDIC, if you just transfer it properly.
Bo Persson
:: On 2007-08-04 00:48, Juha Nieminen wrote:
::: Victor Bazarov wrote:
:::: Most of them involve ASCII coding. That's not portable.
:
::: How many systems can you mention which are used today and which
::: do not use ASCII coding?
:
:: I believe that IBM still uses EBCDIC on their z series machines.
:
: They did the last time I looked.
They sure do!
:
::: Heck, *no* C++ source code is portable to systems which do not
::: use ASCII coding because the source code itself uses ASCII coding.
:
:: Not unless it's not written on a machine which uses ASCII, besides
:: I don't think the C++ standard defines how the source should be
:: encoded, only which characters that can be expected to be
:: recognised.
:
: There's a very definite reason why ftp has two modes: binary and
: "ascii". Even between Windows and Unix, you need to map the
: representation of '\n' (and possibly EOF).
I can add a bit of trivia to this, by explaining what happens when you
ftp between a PC and a Z-series mainframe.
The "ascii" command tells the ftp processors (one at each end!) that
the *transfer* is done in text mode. It doesn't tell anything about
how the file is encoded at either end. At the Z-series end, the ftp
processor will translate "ascii" mode transfers to/from EBCDIC, when
communicating with a non-EBCDIC device.
This means that source code actually IS portable between ASCII and
EBCDIC, if you just transfer it properly.
Bo Persson
J
Juha Nieminen
Bo said:
That's just ridiculous. I need an FTP program in order to compile
some source code?
J
Juha Nieminen
Erik said:
Ah, yes, I have a couple of those here.
Not.
B
Bo Persson
Juha Nieminen wrote:
:: Bo Persson wrote:
::: The "ascii" command tells the ftp processors (one at each end!)
::: that the *transfer* is done in text mode. It doesn't tell
::: anything about how the file is encoded at either end. At the
::: Z-series end, the ftp processor will translate "ascii" mode
::: transfers to/from EBCDIC, when communicating with a non-EBCDIC
::: device.
:::
::: This means that source code actually IS portable between ASCII and
::: EBCDIC, if you just transfer it properly.
::
:: That's just ridiculous. I need an FTP program in order to compile
:: some source code?
No, but you might need it to transfer your program to the mainframe.
It doesn't support floppies or USB-memories, and the operators won't
let you get even close to the CD-reader.
You could also use a terminal, and type it in again.
Bo Persson
:: Bo Persson wrote:
::: The "ascii" command tells the ftp processors (one at each end!)
::: that the *transfer* is done in text mode. It doesn't tell
::: anything about how the file is encoded at either end. At the
::: Z-series end, the ftp processor will translate "ascii" mode
::: transfers to/from EBCDIC, when communicating with a non-EBCDIC
::: device.
:::
::: This means that source code actually IS portable between ASCII and
::: EBCDIC, if you just transfer it properly.
::
:: That's just ridiculous. I need an FTP program in order to compile
:: some source code?
No, but you might need it to transfer your program to the mainframe.
It doesn't support floppies or USB-memories, and the operators won't
let you get even close to the CD-reader.
You could also use a terminal, and type it in again.
Bo Persson
J
Juha Nieminen
Bo said:No, but you might need it to transfer your program to the mainframe.
It doesn't support floppies or USB-memories, and the operators won't
let you get even close to the CD-reader.
You could also use a terminal, and type it in again.
Of course this raises the question of why you would even want to
run a self-printing program in a mainframe...
J
James Kanze
You need something to get it from the machine where it resides
to the machine where you want to compile it. If you write the
code using an editor on a z series machine, the editor saves it
in EBCDIC; if you output string constants in the program, they
are in EBCDIC. If the program is on a Unix machine or a PC,
however, you're going to have to start by transfering it to the
z series machine; the usual tool for transfering files between
machines is ftp.
J
Juha Nieminen
Btw, this is the shortest "non-portable" self-replicating valid C++
program I could come up with. It's "non-portable" because it assumes
ASCII codes are used and, most importantly, it assumes that the ASCII
value 10 is linefeed. Should work in most unix systems, though.
#include <cstdio>
int main(){char*s="#include <cstdio>%cint
main(){char*s=%c%s%c;std:rintf(s,10,34,s,34);}";std:rintf(s,10,34,s,34);}
program I could come up with. It's "non-portable" because it assumes
ASCII codes are used and, most importantly, it assumes that the ASCII
value 10 is linefeed. Should work in most unix systems, though.
#include <cstdio>
int main(){char*s="#include <cstdio>%cint
main(){char*s=%c%s%c;std:
rintf(s,10,34,s,34);}";std:rintf(s,10,34,s,34);}
W
Warp
Btw, this is the shortest "non-portable" self-replicating valid C++
program I could come up with. It's "non-portable" because it assumes
ASCII codes are used and, most importantly, it assumes that the ASCII
value 10 is linefeed. Should work in most unix systems, though.
#include <cstdio>
int main(){char*s="#include <cstdio>%cint main(){char*s=%c%s%c;std:rintf(s,10,34,s,34);}";std:rintf(s,10,34,s,34);}
program I could come up with. It's "non-portable" because it assumes
ASCII codes are used and, most importantly, it assumes that the ASCII
value 10 is linefeed. Should work in most unix systems, though.
#include <cstdio>
int main(){char*s="#include <cstdio>%cint main(){char*s=%c%s%c;std:
rintf(s,10,34,s,34);}";std:rintf(s,10,34,s,34);}
J
James Kanze
[...]
Or any other system, for that matter. It's not as if they are
particularly useful.
Of course this raises the question of why you would even want to
run a self-printing program in a mainframe...
Or any other system, for that matter. It's not as if they are
particularly useful.