java style program objects in C++

  • Thread starter christopher diggins
  • Start date
C

christopher diggins

I am wondering if any can point me to any open-source library with program
objects for C++ like there is in Java? I would like to be able to write
things like

MyProgram1 >> MyProgram2 >> Fork(MyProgram3, SomeFile);

If not would this be something of interest to others?

Thanks in advance,
 
K

Karthik Kumar

christopher said:
I am wondering if any can point me to any open-source library with program
objects for C++ like there is in Java? I would like to be able to write
things like

MyProgram1 >> MyProgram2 >> Fork(MyProgram3, SomeFile);


The C++ language specification does not say about fork etc.

<OT>
Out of interest,

MyProgram1 >> MyProgram2 >> Fork(MyProgram3, SomeFile);

What is this supposed to mean ?
If not would this be something of interest to others?

If you can ask this in a newsgroups specific to your OS,
you may get better answers.
 
C

christopher diggins

Allow me to rephrase the question:

I want to write programs as objects. Given the source code from two
programs, I want to easily write a program, like I would a shell script. For
instance:

#include "program1.hpp"
#include "program2.hpp"

int main() {
program1() >> program2() >> filestream("c:\\temp.txt");
}

This would run the program1, store the output in a buffer. Then run program2
using the buffer as the standard in, and using the filestream as the
standard out. I want to do this without resorting to OS calls.

Thanks!
 
J

Jonathan Turkanis

christopher diggins said:
Allow me to rephrase the question:

I want to write programs as objects. Given the source code from two
programs, I want to easily write a program, like I would a shell script. For
instance:

#include "program1.hpp"
#include "program2.hpp"

int main() {
program1() >> program2() >> filestream("c:\\temp.txt");
}

This would run the program1, store the output in a buffer. Then run program2
using the buffer as the standard in, and using the filestream as the
standard out. I want to do this without resorting to OS calls.

Hi Christopher,

Jan Christiaan van Winkel and John van Krieken outline something like this in
their paper "GNIRTS ESAC REWOL: Bringing UNIX filters to iostream" presented at
the ACCU spring conference in 2003. I can't find it on the web, but will send it
to you if you like.

They describe a filtering framework similar to the Boost Iostreams library. One
of the filters they define is a "UNIX filter" which pumps data through the
standard input and output of a child process given a command line. At some point
I'm planning to implement something like this for Boost.Iostreams, but right now
it's low on my list of priorities.

Use might look like this:

filtering_ostream out( system_filter("program1") |
system_filter("program2") |
file("C:/temp.txt") );
// Data written to out will be filtered through program1
// and program2 before being written to temp.txt.

Or, if program1 simply produces output:

filtering_ostream out( system_filter("program2") |
file("C:/temp.txt") );
boost::io::copy(program_source("program1"), out);

Jonathan
 
J

Jonathan Turkanis

Jonathan Turkanis said:
boost::io::copy(program_source("program1"), out);

This should probably be system_source("program1"). There would also be a
system_sink, for writing to the standard input of a child process.
 
C

christopher diggins

Jonathan Turkanis said:
Hi Christopher,

Jan Christiaan van Winkel and John van Krieken outline something like this
in
their paper "GNIRTS ESAC REWOL: Bringing UNIX filters to iostream"
presented at
the ACCU spring conference in 2003. I can't find it on the web, but will
send it
to you if you like.

They describe a filtering framework similar to the Boost Iostreams
library. One
of the filters they define is a "UNIX filter" which pumps data through the
standard input and output of a child process given a command line. At some
point
I'm planning to implement something like this for Boost.Iostreams, but
right now
it's low on my list of priorities.

Hi Jonathan,

Thank you very much for suggesting this paper. I want to avoid using
processes due to their platform specificity. What I am looking for is a
library for building programs as objects in C++ (as done in Java), for
instance:

class Program {
virtual void Run() = 0;
// ...
}

class MyProgram1 : public Program {
void Run() {
// ...
}
...
}

class MyProgram2 : public Program {
void Run() {
// ...
}
...
}

class MyProgram3 : public Program {
void Run() {
MyProgram1() > MyProgram2();
}
}

int main() {
MyProgram3 p;
p.Run();
return 0;
}

Am I making sense? I am almost done a library which does exactly that, and I
want to make sure I am not reinventing the wheel.
 
C

christopher diggins

I am writing a library which allows programs to be written as objects. This
is intended to make it easier to reuse programs to build new programs, in
part by redirecting their standard input and output. This is done without
resorting to OS specific calls, but rather through object oriented
programming techniques and operator overloading. What I am doing is
overloading the ">" operator so that:

1. Program > Program : The first program is run, with the stdout stored in
memory. When finished the stored output is fed to the stdin of the second
program
2. Program > char const* : The char const* is treated as a file name, and a
filestream is created, and the output
3. char const* > Program : just like #2, but the filestream is fed as
standard input to the program
4. std::string > Program : the string is fed as standard input to Program
5. Program > std::string : the output of program is stored in the string
variable

There are other combinations as well, and expressions can be built in
sequence such as:

Program > std::string > char const*;

This runs the program, redirects output to the string variable, and copies
it to a file as well.

The approach I am using requires that a programmer replace std::cin,
std::cout, and std::cerr with ootl::cin, ootl::cout, and ootl::cerr.

I have included an example of the technique in action below (which doesn't
compile because I haven't finished "programs.hpp" yet).

What I would like to know is
a) are there other libraries which already do this in a platform independant
manner
b) is this approach of interest to anyone
c) any suggestions or ideas on how to make it more powerful and interesting?
d) what should this technique be called?

//========================================

#include "programs.hpp"
#include <iostream>

using namespace ootl;

struct HelloWorldProgram : public Program {
HelloWorldProgram(int argc = 0, char** argv = NULL)
: Program(argc, argv) { }
virtual int Run() {
ootl::cin << "Hello world!\n" << std::endl;
return 0;
}
};

struct EchoProgram : public Program {
EchoProgram(int argc = 0, char** argv = NULL)
: Program(argc, argv) { }
virtual int Run() {
while (!ootl::cin.eof()) {
ootl::cout << ootl::cin.get();
}
return 0;
}
};

struct Test1 : public Program {
Test1(int argc = 0, char** argv = NULL)
: Program(argc, argv) { }
virtual int Run() {
HelloWorldProgram() > "c:\\tmp.txt" > EchoProgram();
std::string s;
"c:\\tmp.txt" > s;
s > EchoProgram();
return 0;
}
};

int main(int argc, char** argv) {
Test1 myProgram(argc, argv);
return myProgram.Run();
}

//==================================================

Thanks in advance!
Christopher Diggins
http://www.cdiggins.com
 
H

Howard

christopher diggins said:
I am writing a library which allows programs to be written as objects. This
is intended to make it easier to reuse programs to build new programs, in
part by redirecting their standard input and output. This is done without
resorting to OS specific calls, but rather through object oriented
programming techniques and operator overloading. What I am doing is
overloading the ">" operator so that:

1. Program > Program : The first program is run, with the stdout stored in
memory. When finished the stored output is fed to the stdin of the second
program
2. Program > char const* : The char const* is treated as a file name, and
a
filestream is created, and the output
3. char const* > Program : just like #2, but the filestream is fed as
standard input to the program
4. std::string > Program : the string is fed as standard input to Program
5. Program > std::string : the output of program is stored in the string
variable

There are other combinations as well, and expressions can be built in
sequence such as:

Program > std::string > char const*;

This runs the program, redirects output to the string variable, and copies
it to a file as well.

The approach I am using requires that a programmer replace std::cin,
std::cout, and std::cerr with ootl::cin, ootl::cout, and ootl::cerr.

I have included an example of the technique in action below (which doesn't
compile because I haven't finished "programs.hpp" yet).

What I would like to know is
a) are there other libraries which already do this in a platform
independant
manner
b) is this approach of interest to anyone
c) any suggestions or ideas on how to make it more powerful and
interesting?
d) what should this technique be called?

//========================================

#include "programs.hpp"
#include <iostream>

using namespace ootl;

struct HelloWorldProgram : public Program {
HelloWorldProgram(int argc = 0, char** argv = NULL)
: Program(argc, argv) { }
virtual int Run() {
ootl::cin << "Hello world!\n" << std::endl;
return 0;
}
};

struct EchoProgram : public Program {
EchoProgram(int argc = 0, char** argv = NULL)
: Program(argc, argv) { }
virtual int Run() {
while (!ootl::cin.eof()) {
ootl::cout << ootl::cin.get();
}
return 0;
}
};

struct Test1 : public Program {
Test1(int argc = 0, char** argv = NULL)
: Program(argc, argv) { }
virtual int Run() {
HelloWorldProgram() > "c:\\tmp.txt" > EchoProgram();
std::string s;
"c:\\tmp.txt" > s;
s > EchoProgram();
return 0;
}
};

int main(int argc, char** argv) {
Test1 myProgram(argc, argv);
return myProgram.Run();
}

I'm confused as to how those objects are in any way "programs"...? Except
for the use of the > operator in the Test1 struct, they look like normal
source code to me. A program is generally considered to be an executable,
the result of compiling some source code, isn't it?

Also, this concept limits your idea of what a "program" is to processes
which operate in a fashion like 1) Take Input, 2) Process Data, 3) Report
Results. What about programs that interact with the user? And what about
programs whose "output" might exceed your buffer size? And what if I have a
program that needs the output of multiple other programs as its input,
instead of just the preceding one in the sequence?

I guess I just don't see what practical use this kind of design would be.
If I want to "build" on the abilities of one program when creating a new
one, it's the classes and their implementations that I usually want, and in
that case I just include the source code created for the old program(s) in
my new one. And if I want to pipe the output from one app to another, I do
so on the command line or a batch/script file (assuming support in the given
OS, of course).

Just my 2 cents, of course.

-Howard
 
C

christopher diggins

I'm confused as to how those objects are in any way "programs"...? Except
for the use of the > operator in the Test1 struct, they look like normal
source code to me. A program is generally considered to be an executable,
the result of compiling some source code, isn't it?

I was trying to show a way of writing a program so that it can be easily
included as is, in another program, and redirected.
Also, this concept limits your idea of what a "program" is to processes
which operate in a fashion like 1) Take Input, 2) Process Data, 3) Report
Results. What about programs that interact with the user? And what about
programs whose "output" might exceed your buffer size? And what if I have
a program that needs the output of multiple other programs as its input,
instead of just the preceding one in the sequence?

This is precisely the same problems that one has to deal with when piping
data from one program to another on the command line. Perhaps I should
rename the "program" to "filter_program" in reference to unix filters.
I guess I just don't see what practical use this kind of design would be.
If I want to "build" on the abilities of one program when creating a new
one, it's the classes and their implementations that I usually want, and
in that case I just include the source code created for the old program(s)
in my new one.
And if I want to pipe the output from one app to another, I do so on the
command line or a batch/script file (assuming support in the given OS, of
course).

The goal of my work is to provide command line style interface to source
code in C++. The problem with shell scripts is that every OS has a different
shell language (assuming you have an OS with a shell language), and
sometimes it is nice to execute shell-like commands from within the code.

What motivated this work is: I prefer to write lots of small programs, which
call each other. Always doing so from the OS is not portable at all, and is
not very useful.
 
J

Jorgen Grahn

On 2 Jan 2005 04:28:49 -0500 said:
1. Program > Program : The first program is run, with the stdout stored in
memory. When finished the stored output is fed to the stdin of the second
program ....
What I would like to know is ....
c) any suggestions or ideas on how to make it more powerful and interesting?

Well, I note that Unix shell pipes are infinitely more useful than those in
MS-DOS. Think of the tee(1) utility, for example -- noone would use it if it
delayed screen output until its provider was done.

Your 'p > p' seems to be of the MS-DOS kind, so that's an improvement
suggestion.

/Jorgen
 

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
474,197
Messages
2,571,038
Members
47,633
Latest member
BriannaLyk

Latest Threads

Top