To Print the source program as output

[vinay.khankari]

How to Print the complete source program as output of the program?

[Victor Bazarov]

vi************@gmail.com wrote:

How to Print the complete source program as output of the program?

Please google for "self-printing program". It is a fun problem to
solve, but IIRC, it doesn't have any portable solution.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Pavel Lepin]

Victor Bazarov <v.********@comAcast.netwrote in
<f8**********@news.datemas.de>:

vi************@gmail.com wrote:

>How to Print the complete source program as output of
the program?

Please google for "self-printing program".

Or, better yet, "quine".

It is a fun problem to solve, but IIRC, it doesn't have
any portable solution.

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.

--
....the pleasure of obedience is pretty thin compared with
the pleasure of hearing a rotten tomato hit someone in the
rear end. -- Garrison Keillor

[Victor Bazarov]

Pavel Lepin wrote:

Victor Bazarov <v.********@comAcast.netwrote in
<f8**********@news.datemas.de>:

>vi************@gmail.com wrote:

>>How to Print the complete source program as output of
the program?

Please google for "self-printing program".

Or, better yet, "quine".

>It is a fun problem to solve, but IIRC, it doesn't have
any portable solution.

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.

Most of them involve ASCII coding. That's not portable.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Juha Nieminen]

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?

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?=]

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.

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.

--
Erik Wikström

[Jim Langston]

"Juha Nieminen" <no****@thanks.invalidwrote in message
news:46***********************@news.song.fi...

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?

Heck, *no* C++ source code is portable to systems which do not
use ASCII coding because the source code itself uses ASCII coding.

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.

[Jerry Coffin]

In article <f8**********@news.datemas.de>, v.********@comAcast.net
says...

vi************@gmail.com wrote:

How to Print the complete source program as output of the program?

Please google for "self-printing program". It is a fun problem to
solve, but IIRC, it doesn't have any portable solution.

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!

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Aug 3, 4:49 pm, "Victor Bazarov" <[e-mail]:

Pavel Lepin wrote:

Victor Bazarov <[e-mail] in
<f8vd4n$[e-mail]>:

[e-mail] wrote:
How to Print the complete source program as output of
the program?

Please google for "self-printing program".

Or, better yet, "quine".

It is a fun problem to solve, but IIRC, it doesn't have
any portable solution.

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.

Most of them involve ASCII coding. That's not portable.

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.

--
James Kanze (GABI Software) email:james.kanze:gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Aug 4, 1:30 am, Erik Wikström <[e-mail]:

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.

(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.)

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).

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.

--
James Kanze (GABI Software) email:james.kanze:gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Bo Persson]

James Kanze wrote:
: On Aug 4, 1:30 am, Erik Wikström <[e-mail]:
:: 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

[Juha Nieminen]

Erik Wikström wrote:

> 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.

Ah, yes, I have a couple of those here.

Not.

[Juha Nieminen]

Bo Persson wrote:

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... :P

[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::printf(s,10,34,s,34);}"; std::printf(s,10,34,s,34);}

[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::printf(s,10,34,s,34);}"; std::printf(s,10,34,s,34);}

--
- Warp

[James Kanze]

On Aug 5, 8:22 pm, Juha Nieminen <[e-mail]:

[...]

Of course this raises the question of why you would even want to
run a self-printing program in a mainframe... :P

Or any other system, for that matter. It's not as if they are
particularly useful.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]