I need to develop a simple portable C++ program Billing_Unit. It reads some parameters (telefone number, etc.) and returns the price of call and rest of free minutes.
I decided to get data for Billing_Unit from standart input, and output result to standart output.
I developed two test units: Test_Unit_Source and Test_Unit_Destination.
I decided to organize a consecutive performing of my program units:
Test_Unit_Destination: Reads the call costs and the rest of free minutes, stores it to database.
Test_Unit_Source | Billing_Unit | Test_Unit_Destination
Simplified Test_Unit_Source:
#include <stdio.h>
#include <iostream>
#include <fstream>
#include <string>
#define SUCCESS_RESULT 0
#define ERROR_RESULT 1
using namespace std;
int main() {
signed char buf;
string Name_File;
ifstream inp_file;
inp_file.open("temp.txt",std::ios::binary);
if (!inp_file) return ERROR_RESULT;
do {
buf=inp_file.get();
cout<<buf;
} while (!inp_file.eof());
return SUCCESS_RESULT;
}
Simplified Billing_Unit - it must be portable:
#include <iostream>
#define SUCCESS_RESULT 0
#define ERROR_RESULT 1
int main() {
signed char var;
unsigned long res;//cents
signed char next_call;
while (!EOF_USERS) {
std::cin >> input_data;
...
//calculations
...
std::cout << result;
}
std::cout << EOF_USERS;
return SUCCESS_RESULT;
}
Simplified Test_Unit_Destination:
#include <stdio.h>
#include <iostream>
#include <fstream>
#include <string>
#define SUCCESS_RESULT 0
#define ERROR_RESULT 1
using namespace std;
int main() {
signed char buf;
ofstream out_file;
out_file.open("out.txt",std::ios::binary);
if (!out_file) return ERROR_RESULT;
while (!EOF_USERS) {
cin >> buf;
out_file << buf;
}
return SUCCESS_RESULT;
}
Actually Test_Unit_Source and Test_Unit_Destination can be united in one program unit. It depends on my decision.
Is it a good organization of my project? What is the best organization of this project? May be it's better to set input parameters for Billing_Unit through command line, but I don't know how to return the result in this case.
Your design fits perfectly into the model of unix-like languages: by writing your program as a filter that reads stdin
and writes to stdout
you're giving users the flexibility to easily pre- or post-process the data.
For example, as you've written it, you can simply run
Billing_Unit < input_file > output_file
But suppose the input data is in the wrong format. Then you can run
reformat_data < input_file | Billing_Unit > output_file
And you can change the output format with
Billing_Unit < input_file | sort_by_customer > output file
These are simple examples, but I hope they show you how easy it is to work with a program like yours.
If you do plan to run your program directly from the shell like this, be sure that any error messages are written to stderr
instead of stdout
. That will separate them from your output data, so they won't be processed as input by the next command.